Re: [devel] На чем писать rc.sysinit? (почти не JT)

[Alexey Morozov <alex-altlinux@idisys.iae.nsk.su>]

[-- Attachment #1: Type: text/plain, Size: 4839 bytes --]

On Fri, Oct 01, 2004 at 02:29:47AM +0400, Денис Смирнов wrote:
>  AM> То есть, Вы спрашиваете, на чем нужно писать rc.sysinit? :-)
>  AM> Ну, натурально, на sh (даже, верятно, не на bash ;-). Но, заметьте,
>  AM> _там_ особой потребности даже в функциях, не говоря уже о хэшах и
>  AM> прочих нетривильностях до сих пор не возникало, и, надеюсь, не возникнет.
> У меня есть мнение, что правильные rc.sysinit должен писаться отнюдь не на
> sh. Возможно на tcl.
Нет. Потому что, когда я говорю "rc.sysinit", я имею ввиду именно ту
"протосистему", которая имеется на момент запуску /etc/rc.d/rc.sysinit
(и о которой говорил ldv@)

Понятно, что этот скрипт, и запуск сервисов - это задачи совершенно
разного уровня, и совершенно разных функциональных возможностей (и
потребностей).

> 
> Потому как функциональность нынешнего устарела ой как много лет назад, и
> сейчас тянет за собой кучку геморроя (я про нумерацию сервисов) и
> невозможность параллельного запуска.
Задачами rc.sysinit являются проверка файловых систем, там где это нужно
и уместно (запуск fcsk итп), формирование всех этих raid- и прочих
замороченных томов, монтирование файловых систем, и, возможно, базовое
выставление системных часов. С этими задачами, вероятно (и наверняка!)
нормально справится и sh, никаких велосипедов в этом месте особенно
изобретать не нужно, разве что, я не вполне уверен в конфигурациях,
когда /usr (или даже /) находятся на NFS'е.

> А Виктор Вагнер, кажется, высказывал очень ценную мысль, что можно
> попробовать его писать на make :)
А вот запуск сервисов действительно может осуществляться уже практически
чем угодно. В том числе, вероятно, и make'ом (нужно только понять,
хватит ли в make'е функционала для организации приемлемой системы
макросов для, скажем, "типического запуска сервисного демона" итп.)

Но, вообще-то, под языком для системных скриптов подразумевал _еще_
более верхнеуровневую вещь. Те же альтернативы, в конце концов, или
скрипты для системного, э-э-э, ухода. Поглядев на последние мэндрэйки,
я понял, н-р, что функциональность Mdk'шного msec соотносится с нашей
osec примерно, как 5/1 (хотя, если к osec приплюсовать еще и control
с внятным _пользовательским_ описанием, как это можно использовать
для _своих_ нужд, да еще пяток-другой кроновских скриптов итп, то
соотношение уже заметно лучше).

И таких вот "системных или около того" задачек в линуксе довольно много,
вообще-то. И, собственно, основная разница в "линуксах" - это как раз и
есть разница в решениях таких задач.

> AM> basesystem? ;-)), то, вероятно, мне лучше сидеть и тихонько ковыряться в
> AM> собственной песочнице, не слишком подавая голос :-).
> Можешь сделать лучше -- все спасибо скажут :) Но гарантировано скажут
Это вряд ли. Поскольку мне, в общем, не приходится городить линуксы
"на 10MB'шных флэшках" (а если и придется, то, вероятно, не на ALT'е),
то я вполне переживу наличие какого-нибудь python-base в _моей_ basesystem:
3Mb вместе с python-modules-logging и python-modules-xml, да,
наверняка, его и еще порезать можно будет (ценой потери определенной
функциональности, конечно).

Ну а кому-то 3Mb под питон покажутся непомерной роскошью и бессмысленным
забиванием жесткого диска, ведь "текстовый (а то и XML!) файл вполне можно
и sh+awk распарсить". К тому же, насколько я понимаю, у python здесь
(в ALT) есть как свои сторонники, так и активные противники.

Хотя должен заметить, что выбор конкретного языка - это дело десятое.
И, в конце концов, я совершенно не буду возражать, если на роль такого
языка будет, *в результате согласия между заинтересованными сторонами* ,
выбран tcl, ruby или, скажем, perl. Главное, чтобы средство было _вменяемое_ ,
поощряло good programming practices, чтобы у него были разумная stdlib
и самодостаточность в части, например, корректной обработки ошибочных
и нештатных ситуаций (да, я согласен, что [некоторые из перечисленных
альтернатив], гхм, сомнительны по данным критериям).

> спасибо, если лучше по одному параметру не будет означать хуже по другому.
Оно будет означать по-любому. Вопрос в приоритетах. Если приоритетом
объявить, скажем, posix-compliance, то вообще-то, даже bash в
такую систему пролезет с трудом... Или, н-р, см. выше про расход места.
А если приоритетом будет возможность доступа к clib'ным функциям или,
н-р, наличие стандартизованной системы для создания регрешшн-тестов, то,
извините, sh-ed'овские скрипты отправятся на заслуженный отдых.

> Если что-то можно написать _прозрачно_ на awk+sh -- оно должно быть
> написано на них. Для надёжности.
Вот у меня нет ощущения, что надежность от этого повышается, глядя на
давешнюю поломку inger's alternatives из-за добавления лишнего ключа в sed.
Написано, вроде, все было достаточно разумно, но вот поди ж ты, "ветер
изменился" и опа.


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]