[devel] Re: Re: Re: Re: Re: Продолжение тестирования installer
Anton Farygin
=?iso-8859-1?q?rider_=CE=C1_altlinux=2Ecom?=
Ср Авг 3 15:54:04 MSD 2005
On Wed, 03 Aug 2005 15:17:42 +0400, Денис Смирнов wrote:
> On Wed, Aug 03, 2005 at 10:05:22AM +0400, Anton Farygin wrote:
>
> AF> /etc ничем не отличается от любого
> другого AF> каталога в системе. Тогда уж
> можно AF> говорить, что нельзя проводить
> AF> обновления пакетов, ибо сбой AF>
> электропитания во время оного приводит
> AF> к еще более страшным последствиям.
>
> /etc содержит:
>
> 1. информацию, критичную для работы и
> загрузки системы (повреждение отдельных
> файлов в /etc, особенно fstab, может сделать
> невозможной удалённое восстановление
> работоспособности, а также сильно
> затруднить локальное.
>
> 2. информацию, которая создана
> пользователем или под его контролем.
> Таким образом в отличии от многих других
> каталогов, потеря этой информации для
> пользователя критична.
>
> А если ты прочитал моё письмо
> внимательно, то мог обратить внимание
> что я сказал именно о запрете
> производить такие изменения _без
> контроля со стороны пользователя_. Таки
> да, обновлять пакеты автоматически без
> разрешения пользователя тоже нельзя.
>
> Нынешняя ситуация с hal не лучше, чем apt-get
> dist-upgrade из updates по крону в конфигурации
> по-умолчанию.
Неправда ;-)
>
>>> Достаточно, чтобы на это уже
>>> нарывались. Следовательно достаточно,
>>> чтобы не использовать на
>>> обслуживаемых мною системах, а также
>>> настоятельно не рекомендовать
>>> использование hal кому бы то ни было.
> AF> Кто нарывался ? можно подробнее с
> этого места ?
>
> Вот буквально перед моим письмом было
> письмо mike'а. Неоднократно я видел о
> подобном в рассылке (жаловались на
> убитый fstab на reiserfs и xfs).
Ну письма mike мы знаем... и успешно игнорируем.
А вот xfs и reiserfs... нефиг наверное /etc делать
на них ? Может это больше имеет отношения к надежности файловых систем ?
>
>>> Так как это у нас будет из коробки, это
>>> заведомо означает что я буду
>>> настоятельно нерекомендовать всем,
>>> кому желаю добра, _не использовать_
>>> Compact, если они не способны сами
>>> оторвать эту функциональность.
> AF> Пожалуйста. Заодно можно
> рекомендовать AF> не использовать Linux,
> ибо это сейчас во всех дистрибутивах.
>
> Во всех по-умолчанию?
Да.
>
>>> Антон, уже год как всплывают ситуации,
>>> из-за которых следуют рекомендации
>>> как очередным грязным хаком (вроде
>>> chattr) оторвать у hal эту привычку.
> AF> А у hal, кстати, она появилась совсем
> недавно.
>
> Ну да, потому что раньше такой
> глупостью как изменение fstab занимался
> hotplug.
Нет, раньше это делал updfstab из kudzu. hotplug это делал недолго.
>
> AF> Я понимаю, что многие были напуганы AF>
> глюками hotplug. Но - раньше мы три года
> жили AF> на updatefstab и ничего...
>
> Помнится updatefstab запускался один (!) раз
> при загрузке системы, если я ничего не
> путаю. А тут предлагается на каждое
> втыкание-вытыкание флешки.
Путаешь. он запускался на каждое втыкание/вытыкание.
>
> Меня updatefstab не напрягал только по двум
> причинам -- во-первых моя машина редко
> выключалась, а во-вторых service kudzu off было
> первой командой после установки
> системы
> :)
service kudzu off не имел отношения к updfstab. updfstab
запускался из hotplug'а на всех ядрах 2.4 (и
сейчас запускается, если собрать hotplug из mainstream).
>
>>> Есть ситуации, когда политика hal
>>> правильна, но это должно _включаться_
>>> чем-то вроде control. А по-умолчанию, и
>>> пока нужного скриптика нет, эта
>>> опасная функциональность должна быть
>>> выключена.
> AF> Зачем control ? Я не понимаю. AF> Есть
> желающие сделать backend к альтератор ?
>
> Нет. Потому что он не нужен. Правильный
> подход, это когда сия кривая
> функциональность автоматически
> отрывается при установки ivman.
Так не вопрос... ivman может класть свой конфиг в /etc/hal/fdi/policy/
>
> Антон, либо мы делаем fstab.d, либо
> отрываем это уродство. fstab.d патч уже
> есть для mount. Если тебе так хочется
> редактировать fstab, то давай это сделаем
> именно так.
я категорически против fstab.d до тех пор,
пока это не будет пропихнуто в mainstream
всех дистрибутивов/использующих fstab
пакетов. Не надо экспериментировать на
наших пользователях, у них и так
достаточно проблем, вызванных нашими "отличиями".
Rgds,
Rider
Подробная информация о списке рассылки Devel