Alexander Galanin -> debian-russian@lists.debian.org @ Sun, 13 Sep 2009
16:00:12 +0400:
AG> Более того, я считаю необходимым условием то, что когда init мне
AG> бодро сообщил о завершении своей работы запуском xdm, система
AG> должна быть готова к эксплуатации.
Ну а я так не считаю. Подеремся?
Не говоря уже о том, что sysvinit никак тебе этой гарантии не дает. (И
слава богу - у меня система поднимет xdm несмотря на то, что vmware не
поднялась - а не поднялась она потому, что модули надо под новое ядро
пересобрать, ибо если б не апгрейд ядра, я б вообще не перегружался - и
что мне, в консоли корячиться со сборкой этих модулей? - ах да,
getty-то она с твоими предпочтениями тоже не запустила бы...)
При событийной модели ты хотя бы можешь прописать зависимости - и
система будет тебе запускать xdm тогда и только тогда, когда она подняла
все сервисы. (Оно, конечно, ты наплачешься, когда у тебя какой-нибудь
сервис не поднимется - но ССЗБ, кто ж тебя просил такие глупости
делать?)
>> Но зачем? Если это мой ноутбук, который мне надо загрузить быстро?
AG> У ноутбука есть кнопка suspend, нажимая которую ты дёргаешь не
AG> /etc/rc?.d/*, а /etc/{suspend,resume}.d/*.
Если б оно еще и работало... А то у моего, скажем, с некоторой
регулярностью бывает бессонница...
>> Зачем запускать что-то последовательно и висеть то на процессоре, то на
>> вводе-выводе, если у нас 2, 4, 8 ядер? Давайте распараллелим процесс
>> загрузки, будем запускать сервисы и всякие инициализационные скрипты as
>> early as possible.
>> ...
>> Ну и надо минимально напрячь мейтернеров пакетов, предоставляющих
>> инит-скрипты.
AG> Ты готов своей репутацией отвечать за то, что все инит-скрипты
AG> написаны и будут писаться без race?
AG> Даже если добавить в полиси строчку "инит-скрипт должен быть
AG> написан так, чтобы позволять параллельное выполнение со другими
AG> инит-скриптами", это не улучшит ситуацию. Система должна быть
AG> устойчивой к ошибкам by design.
Так эта проблема и при последовательном запуске точно так же в полный
рост. Хинт: если демон уже форкнулся, отсетсидился и еще раз форкнулся,
и даже, может быть, pid-файл записал, это еще не значит, что он готов к
работе и его услугами можно пользоваться.
Только при последовательном запуске об этом регулярно забывают - и
потому при нем race у нас в полный рост. А когда в голове держат
параллельный, пререквизиты все-таки проверяют.
А система у нас многозадачная, извините, by design. Кому не нравится -
есть MS-DOS и MacOS, которая не X.
>> Получается довольно прозрачная с точки зрения концепции идея: есть
>> события, генерируемые ядром, есть события типа "сервис X стартовал",
>> есть зависимости от событий в стартовой последовательности. И всё.
AG> Если заходить со стороны отладки, то получается трудноотлаживаемая
AG> конструкция. Потому что отследить по линейным логам, на каком из
AG> пяти параллельно запущенных процессов инициализация "грохнулась",
AG> весьма и весьма проблематично.
Use grep, Luke!
--
Все гениальное просто.
Но со вкусом.
Кнышев.
--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
