[devel] Re: Re: Re: Re: Re: Продолжение тестирования installer

[Anton Farygin <rider@altlinux.com>]

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