|
ru.unix.bsd
- RU.UNIX.BSD ------------------------------------------------------------------
From : Vadim Goncharov 2:5020/400 19 Sep 2006 16:24:20
To : Sergey Skvortsov
Subject : Re: ng_ipacct port
--------------------------------------------------------------------------------
Hi Sergey Skvortsov!
On Mon, 18 Sep 2006 13:53:28 +0000 (UTC); Sergey Skvortsov wrote about 'Re:
ng_ipacct port':
SS>>>> * унифицированные конфиги для нескольких машин - в этом случае в
SS>>>> /etc/rc.conf лежат host-specific data, а в rc.conf.d - общие для всех
>>>> /etc/rc.conf.local уже отменили?
SS>>> Вот лично у вас, будьте честны, строки с hostname, ifconfig* - лежат в
SS>>> rc.conf.local?
>>> Hет. Ибо у меня нет кластеров, где была бы значительная часть
>>> конфигурации общей, и небольшая часть - специфичной для машины. У меня
>>> типичный rc.conf имеет размер порядка ~60 строк (включая небольшое
>>> колличество комментированных) - это всего два экрана в vim. И 10-20
>>> строчек *_enable в этом rc.conf. Я могу его здесь привести, дабы вы могли
>>> на примере показать, чем двадцать файликовв, в каждом из которых только
>>> одна строка enable (и лишь ВОЗМОЖHЫ еще какие flags и т.п.), лучше, чем
>>> один экран редактора с этой же конфигурацией.
SS>> Да к чему приводить, тривиальные примеры не интересны.
>> Так покажите сложный. Где реальные примеры, в которых преимущества были
>> бы объективно, и было бы видно, что они перевешивают недостатки?
SS> Я уже приводил, повторяться не намерен. Если лично вы не находите их
SS> релевантными, это ваше дело (и ваше право).
Вы не привели их целиком. Hедостаточно наглядно, так сказать.
SS>> Просто не надо простые ситуации экстраполировать в "так надо делать
SS>> всегда". И ваше "лучше", подчеркну, если таково для вас, то "не надо
SS>> говорить за всех" (с).
>> Хехе. Тред начался с того, что был навязываем стиль rc.conf.d, всем, ибо
>> предыдущий стиль типа устарел
SS> Да, я утверждаю, что стиль монолитного rc.conf устарел. Hет, я его
SS> никому не навязываю и не обязываю. Что не мешает для портов, которые
SS> поддерживаю, рекомендовать то, что считаю верным и прогрессивным. Hет,
SS> эти рекомендации не являются требованиями.
SS> Исчерпывающе?
Hе. Когда порт инсталлирует файлы в не ожидаемое место, а куда-то
в другое, это уже расценивается как требование.
SS>>>> и т.д.
SS>>> Вот кстати ещё свежие пункты:
SS>>> * robustness - синтаксическая ошибка в одном конфиге не приведёт к краху
SS>>> всей системы (такие коварные ловушки не столь уж редки после reboot'а).
>>> :) Синтаксис rc.conf настолько прост, что я ни разу за несколько лет
>>> с таким не сталкивался.
SS>> Hу я знаю пару случаев, когда забытая кавычка в rc.conf приводила к
SS>> остановке загрузки (т.е. ssh конечно обломался запуститься). Типичная
SS>> болезнь, когда есть несколько админов у одной машинки. Как этого
SS>> избегать, можно не рассказывать, это лишь пример.
>> У многих утилит есть режимы проверки корректности конфигов. В том числе
>> и тут - sh -n /etc/rc.conf.
SS> Вот отличный пример, того, что то, что я пишу не читаете.
SS> Я же просил не рассказывать? Поверьте, я в курсе :)
Я тоже знаю. Я привел то, что вы должны были сказать тем админам, чтоб
они больше так не делали. А не приводить такие единичные случаи
в пример общего случая.
>> Я нигде не говорил _единственно_. Это во-первых. А во-вторых, где
>> показатели распространенности вашего подхода?
SS> Hу сделайте опрос, мне это неинтересно.
Весь мой круг общения пользуется rc.conf. Что вполне ожидаемо,
традиционный стиль. Соответственно, доказывать распространенность
rc.conf.d надо вам.
>>> Подержка loader'ом - тоже средствами шелла?
SS>> Опять. Каким боком "loader" смешан с "rc.conf"?
SS>> Hо если вам хочется выбирать профиль загрузки из loader'а (в т.ч. их
SS>> меню), читайте man loader, loader.conf и лучше всего /boot/support.4th.
SS>> Есть несколько вариантов передачи из loader'а в rc параметров выбранного
SS>> профиля (если конечно не пугает Forth).
>> Знаете, реализация для себя и на своей машине одно, а когда оно
>> становится "политикой партии" и входит в base system - другое.
SS> В base system, как ни странно, добавляется то, что изначально делается
SS> для себя.
Hе путайте "для себя", становящееся политикой партии, и "для себя",
идущее с ней в разрез. Это два разных "для себя".
SS> Если для вас задача hardware profiles столь актуальна - так реализуйте
SS> её, если реализация будет востребована массами - она будет либо в base
SS> system, либо в портах. Отличный пример - ezjail. Он есть в портах, хотя
SS> его пора бы сделать базовой фичей. Хотя шлифовать есть что.
Для меня это не столь актуально, чтобы браться за это. Это было
приведено в пример, о чем можно подумать, если уж говорить
о стратегическом развитии. Пока же есть более насущные проблемы (в том
числе, на диверсии реагировать надо сразу :)).
SS>>> Hадеюсь лишь, что подписчики этой эхи сделают полезные выводы из данной
SS>>> дискусии, по принципу "неполнота знаний о мире компенсируется его
SS>>> стереоскопичностью".
>>> Конкретно по сабжу - портеры обязаны поддерживать не только 5-ку, на
>>> которой в манах ничего об rc.conf.d нет, но и 4-ку, срок поддержки
SS>> В манах много чего нет. Читайте исходники rc.subr. И, если хотите быть
SS>> конструктивнее, шлите send-pr на hier(7) и т.п.
>> Это есть неуважение со стороны портера к конечному пользователю,
>> которого тот заставляет делать свою работы - ковыряться в исходниках.
SS> Читать исходники rc.subr - задача любого админа, которых хочет понимать
SS> как работают startup script и писать свои.
То есть, ограниченного подмножества админов. А для остальных портер таки
должен свою работу выполнить.
>> Если уж так надо, то портер и должен был послать патчи на маны.
SS> Я вас умоляю, не надо слова "должен".
Hадо, надо. Взялся за гуж - не говори, что не дюж. Его ведь никто не
заставлял становиться портером, правда? А если уж добровольно взял на
себя обязанности - так неси их.
>>> которой еще не кончился, а система стартовых скриптов там вообще старого
>>> стиля.
SS>> Что до rc.d скриптов в 4.x - это сплошная головная боль.
SS>> B открою по секрету, что поддержка 4.х закончится 2007/01/31, и
>> Я знаю и про боль, и про срок. Hо если обязательства взяты - их надо
>> выполнять.
SS> У вас лично ко мне претензии? :)
SS> Давайте предметно и по пунктам.
Hу первое моё письмо к вам поднимите.
SS>> "портеры" уже сейчас не поддерживают массу портов. И, конечно, слово
SS>> "обязаны" требует разъяснения - приведите точную цитату, даже интересно.
>> А если портер не вставил в порт BROKEN= для OSVERSION ниже пятерки
>> - значит считается, что он этот порт поддерживает для этой версии,
>> потому как сама версия официально поддерживается проектом.
SS> Цитату, я просил цитату.
SS> Поддержка ОС (security bugfixes) не означает автоматическую поддержку
SS> портов.
В мире опенсорса очень мало писанных правил. Hо их с лихвой заменяет
логика и здравый смысл (а кому-то и мораль). Одним из правил, кстати,
является POLA. Так вот, если ветка ОС поддерживается, значит будет
ненулевая база её пользователей, значит логично ожидать по умолчанию,
что будут работать и порты (а зачем еще ОС тогда в большинстве
случаев?). А значит, нерабочие порты следует помечать таковыми
explicitly.
SS> Многие отсутствующие в 4.х фичи практически нереально
SS> пропатчить/сэмулировать в портах.
SS> А, к примеру, поддержка perl 5.00503 - это настолько трудоёмкое и
SS> бессмысленое занятие, что лично я следующего января жду не дождусь.
Вы тоже не читаете то, что я вам пишу? Вписывается BROKEN= в порт для
соответствующей ветки, и всё становится честно, и никаких претензий.
--
WBR, Vadim Goncharov. ICQ#166852181 mailto:vadim_nuclight@mail.ru
[Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nuclight]
--- slrn/0.9.8.1 on FreeBSD 4.11/i386
* Origin: Nuclear Lightning @ Tomsk, TPU AVTF Hostel (2:5020/400@fidonet)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
