Леннарт Поттеринг, возглавляющий разработку перспективной системы инициализации systemd (http://www.opennet.me/opennews/art.shtml?num=26447), представил (http://0pointer.de/blog/projects/systemd-update-2.html) очередной отчет о развитии проекта, приуроченный к его 13-му релизу (http://lists.freedesktop.org/archives/systemd-devel/2010-Nov...).
Ключевые моменты:
- Уже сейчас, в составе Fedora 15/Rawhide, systemd 13 способен обеспечить полноценную загрузку системы <i>без использования shell-скриптов</i>. Однако, все еще существуют отдельные ситуации, когда без скриптов обойтись невозможно, в частности:
- Включен autoswapping (Леннарт отмечает, что это в любом случае не лучшая идея);
- Требуется полная переустановка меток SELinux;
- Выполняется первая загрузка после установки системы;
- Производится загрузка модулей ядра, сконфигурированная без использования соответствующего штатного механизма systemd;
- Производится загрузка с доступной только на чтение...URL: http://0pointer.de/blog/projects/systemd-update-2.html
Новость: http://www.opennet.me/opennews/art.shtml?num=28713
Одно слово. Впечетляет.
Действительно, список фич внушительный. И в эмбеддовке такой подход подойдет - там выполнение скриптов зачастую сильно сажает скорость загрузки.
А я почему-то всегда думал что скрипты - это преимущество. Всегда можно посмотреть как что сделано или поменять. А с systemd в купе с обычной бедностью man-ов в Линуксе вообще теперь сложно будет сказать где что и как работает. И без компилятора (который не ставится обычно на production машинах) ничего не поменяешь, я так понимаю.
Хотя посмотрим, может действительно окажется удобнее..
скрипты это большой плюс, если вы хотите иметь контроль над системой и вам некритично время загрузки - пять или сто секунд. На серверах и десктопах обычно так и есть - просто разводят очередную истерию. Берегите свою психику ...
Кстати, не знаю как в федоре, но в CentOS уже сеть запихали в NetworkManager (по-моему так называется), черную коробку. Наверное для desktop-ов хорошо, а на сервере уже страшновато становится немного: зачем статику через демона назначать?
Так вроде никто не мешает этот NetworkManager отключить и работать по старинке? В моих серваках (правда, там Fedora) он отключен, но жизнь продолжается :)
>Кстати, не знаю как в федоре, но в CentOS уже сеть запихали в NetworkManager (по-моему так называется), черную коробку.Дайте угадаю. Вы - пользователь Ubuntu, редхатов никогда до этого не видели, поставили "крутой серверный дистрибутив" CentOS в виртуалку "на посмотреть". В инсталляторе, естественно, отметили установку "Графическое окружение GNOME" (включая NetworkManager). После установки полезли в /etc/network/interfaces... А его нет! Ужас-ужас-ужас! Предатели! Изменники! Весь сервер теперь только через NM настраивать!!!1
Открою вам страшную тайну: в редхатовских дистрах сеть настраивается через /etc/sysconfig/network-scripts/ifcfg-*. И, разумеется, никакой NM этого не отменяет.
Читайте документацию - классная штука! ;-)
В CentOS 5.xx всё хорошо, а вот в 9-й (что ли) Федоре ставится этот самый network manager безо всяких иксов и именно он стартует по-умолчанию (сервис network отключён)
Да Fedora вообще плохой вариант для сервера. В пробовали устанавливать ее не в графике, а в текстовом режиме (установщик ncurses)? В RHEL/CentOS он работает адекватно, а у нее при тако варианте: а) не предлагается размечать диски _вообще_ (сетапится по дефолту, с LVM и ext4); б) не предлагается выбрать, что ставить, в результате потом тянется куча GUI. Это только в случае текстового режима; в графике все хорошо. Но сами понимаете, сетапить ОС, скажем, через IP-KVM в графике - неуважение самому к себе.
Единственное, в чем лучше Fedora на сервере, это более новый софт. Правда не редко, когда в продакшн софт собирается в локальных репах, и все что надо, и как надо, есть и так. В этом случае Fedora нахрен не нужна.
>Да Fedora вообще плохой вариант для сервера.Выбор того или иного дистрибутива для сервера - личное дело конкретного админа в конкретном софтовом/железячном окружении.
Скажем, у меня нет проблем с Fedora - переставляю что-либо крайне редко (просто виртуальные машины переползают с хоста на хост или создаются новые из шаблона), имею физический доступ к серверам, да и каналы связи до фермы достаточно мощные.
Мой друг знать ничего не хочет кроме оффтопика, но зато он этот самый оффтопик подымет влет из любого положения. И любой школьник-эникейщик сможет потом все это поддерживать/заломать снова :)
Еще кто-то любит сервера на debian, кто-то порвет глотку за gentoo...В общем, не надо громких заявлений, что "дистрибутив XXX для сервера - suxxx, а дистрибутив YYY - единственно верное решение", ибо от ситуации зависит... ;)
> Открою вам страшную тайну: в редхатовских дистрах сеть настраивается через /etc/sysconfig/network-scripts/ifcfg-*. И, разумеется, никакой NM этого не отменяет.в убунте тоже есть 1 файлик /etc/network/interfaces
человек говорил про CentOS а вы начали грязью поливать Ubuntu
> человек говорил про CentOS а вы начали грязью поливать UbuntuИнтересные у вас какие-то представления о жизни: "посоветовать читать документацию" по-вашему "полить грязью".
Воистину, странные вы люди.
>> человек говорил про CentOS а вы начали грязью поливать Ubuntu
> Интересные у вас какие-то представления о жизни: "посоветовать читать документацию" по-вашему "полить грязью".
> Воистину, странные вы люди.Ну да, ну да ... не страннее некоторых ... угу ...
Я Вам сейчас открою страшную тайну - в RHEL 6 сеть иначе чем через NM не настраивается.
system-config-network есть, но не работает.
Выключить сервис NetworkManager, включить network - и вуаля - пробовали ? :)
Между прочим, вполне реальный совет из редхатовской багзиллы по поводу проблем с сетью (правда, как в итоге выяснилось, NM был не при чем и заработало и с ним)Кстати можно первый не выключать, если зачем-то требуется. Достаточно включить network и разрулить в файликах /etc/sysconfig/network-scripts: чему разрешено управляться через NM, чему нет. Сервис network "автомагически" будет рулить только теми интерфейсами, которые запрещено трогать NM'у.
а не проще добавить в начало скрипта/etc/init.d/network_manager (или как он там называется)
строчку
exit 0 ;
и настраивать всё без NetworkManager проверенными способами (через типовые конфиги) ?
при этом не болит голова с выкидыванием пакетов, которые могут оказаться в зависимостях у других пакетов, но вредный функционал не отрабатывает ...
Нет, зачем хакать пакет (к тому же при апдейте затрется), можно просто отключить выполнение этого сервиса через chkconfig/ntsysv/system-config-services etc :pНо network тоже надо не забыть включить - по дефолту выключен
> Нет, зачем хакать пакет (к тому же при апдейте затрется), можно просто
> отключить выполнение этого сервиса через chkconfig/ntsysv/system-config-services etcтаким образом вы только запретите старт/стоп при запуске соответствующего кольца исполнения (например в RH = 5 или 3, в Debian = 2, посмотреть можно в /etc/inittab). Но есть ещё всякие новомодные механизмы, которые учитывают зависимости и при старте/стопе такого дочернего сервиса заодно стартуют и сервисы, от которых он зависит
то есть ваш скрипт /etc/init.d/XXX может запускаться из разных мест. Так что добавление
exit 0 ;
в начале такого скрипта (после #!/bin/bash) позволит стартовать скрипт откуда угодно, но отрабатывать он будет только команду выхода. И пусть всякие "хитропопые" надстройки стартуют его на здоровье - делаться при этом ничего не будет, только будет возвращаться 0 - признак того, что всё отработало на ура. Результат вы получаете самой малой кровьюа чтобы не затиралось при апдэёте, можно выставить имунный бит
chattr +i имя_файла
и это верно - у вас есть файлы, которые не должны меняться, это ваше частное решение. Для этого есть штатные механизмы
И все же. Собственно, это не единственный такой способ. Но делать такое - это неправильное решение проблемы. Т.е. это будет работать, но не кошерно. Почему - выше написали. После обновления будет Вам /etc/init.d/networkmanager.rpmsave.
Лучше удалить NM совсем. Особенно если сетапы идут через PXE. В таких случаях всё заливается при сетапе, и NM не нужен.
опять же неверно. при попытке удалить NM пакетный менеджер предложит удалить и все зависимые от него пакеты, среди которых может оказаться, например KDE или Гном.
вариантов решения здесь масса, например фиктивные пакеты в Дебиане, или сделать пустой пакет NM - заглушку. Но самый простой путь из добавления одной строки описан мной выше
-
дальше просто - мне удобно так. и кошерно и православно и т.д., кому не нравится - пусть делает по своему
Да, выше имел ввиду сервер. :) Для десктопа конечно, да и лучше наверно будет настраивать подключение через NM. Хотя стандартные методы никто не отменял, NM справляется вполне.
Обожаю никсы именно за это. 1000+1 способ некоршерного решения проблемы =). К слову, если настроить в убунте, сеть через конфигфайл, то настроенный там интерфейс NM будет игнорировать.
> а чтобы не затиралось при апдэёте, можно выставить имунный бит
> chattr +i имя_файла
> и это верно - у вас есть файлы, которые не должны меняться,
> это ваше частное решение. Для этого есть штатные механизмыТо есть месье таким образом гарантированно "защитит" этот скрипт от любых багфиксов/улучшений/дополнений, которые в него позднее могут быть внесены его авторами или мантейнерами.
> То есть месье таким образом гарантированно "защитит" этот скрипт от любых багфиксов/улучшений/дополнений,
> которые в него позднее могут быть внесены его авторами или мантейнерами.именно - задача "малой кровью" избавиться от запуска и от функциональности этого пакета, и в т.ч. скрипта запуска, не парясь зависимостями и т.п.
издеся месье знает что делает и для чего - не сомневайтесь :) а в других случаях делает иначе ...
>именно - задача "малой кровью" избавиться от запуска и от функциональности этого пакета, и в т.ч. скрипта запуска, не парясь зависимостями и т.п.Эта задача решается двумя командами
chkconfig NetworkManager off
chkconfig network onА месье занимается клоунадой.
это проговаривалось выше, вы невнимательны
>это проговаривалось выше, вы невнимательныЯ внимателен, и поэтому заметил, что вы не привели никаких возражений, почему данный метод хуже вашего. Технически грамотных возражений, я имею в виду.
А вот недостатки вашего метода (в частности, сложность, регулярный гемор при обновлении) вполне очевидны.
>таким образом вы только запретите старт/стоп при запуске соответствующего кольца исполнения (например в RH = 5 или 3, в Debian = 2, посмотреть можно в /etc/inittab)Может быть, вы таки почитаете man chkconfig?
Команда "chkconfig NetworkManager off" выключит nm на всех ранлевелах, к вашему сведению.>Но есть ещё всякие новомодные механизмы, которые учитывают зависимости и при старте/стопе такого дочернего сервиса заодно стартуют и сервисы, от которых он зависит
Ну-ка, ну-ка, приведите примеры таких механизмов? Естественно, со ссылками на маны, где сказано, что они именно "самовольно запускают отключенные сервисы для удовлетворения зависимостей".
И особенно приветствуются доказательства наличия этих механизмов в дефолтной установке CentOS (мы же о нем говорим?).
мистер анон, гадить в разговоре, а дальше делать вид что не гадили и ждать продолжения диалога не проканает (см. прежние посты). сказать что мне в принципе есть, но вас уже нет
Т.е. вам нечего возразить по сути?
> chattr +i имя_файлаОб это потом споткнётся обновление -- станет болтаться минимум один пакет, который каждый раз будет пытаться обновиться и неудачно.
Если что-либо настолько мешает жить, обычно лучше его снести.
> Для этого есть штатные механизмы
Это если он %config(noreplace), в чём я лично не уверен (проверить сейчас неудобно, gprs).
PS: а вообще Леннарт будто оправился от пульса и опять в конструктивное русло :)
ну, chattr приведён больше для примера
.
кстати метод "exit 0;" впервые пришлось применять именно на Дебиане, ибо там NM в зависимостях у кучи пакетов. На rhel/centos этого делать до сих пор не приходилось
Да вы бредите^w не пробовали его удалять, а я пробовал :-)
NM отлично сносится и система без него отлично работаетaptitude purge network-manager
Следующие пакеты будут УДАЛЕНЫ:
dnsmasq-base{u} iputils-arping{u} network-manager{p} network-manager-gnome{a}из которых dnsmasq-base и iputils-arping используются самим NM и при его удалении больше не нужны
> Да вы бредите^w не пробовали его удалять, а я пробовал :-)
> NM отлично сносится и система без него отлично работаетне брежу, но возможно путаю с убунтой. Помню, что это было что то Debian based. Времени воскресить этот момент примерно двухгодичной давности нет, но на отдельных инсталляциях этот метод у меня работает, и раз он работает, то достоин упомянания в этом обсуждении ИМХО
>а не проще добавить в начало скрипта
>/etc/init.d/network_manager (или как он там называется)
>строчку
>exit 0 ;... и при следующем апдейте все это будет перекрыто дефолтным скриптом, и при следующей загрузке NM запустится и устроит драку с классическими ifup/ifdown.
Браво!Можно, конечно, развить эту идею дальше, и заблокировать скрипт от изменений (например, через атрибуты фс). Тогда на середние апдейта ВНЕЗАПНО упадёт пакетный менеджер, и при следующей перезагрузке система может вообще не загрузиться. Классно!
Дорогой zerot, апологет ректальной тонзиллэктомии! You made my day, thank you very much!
> Можно, конечно, развить эту идею дальше, и заблокировать скрипт от изменений (например,
> через атрибуты фс). Тогда на середние апдейта ВНЕЗАПНО упадёт пакетный менеджер,
> и при следующей перезагрузке система может вообще не загрузиться. Классно!эта адская картина не обязательно соответствует действительности, даже если говорить про апдейт, а не загрузку системы. Даже зачастую не соответствует. И потом, вы же на продакшене (хоть сервера хоть workstation) не обновляетесь, не пройдя обновление на тестовой среде ? Домашняя машина у вас наверняка рядом с болванкой LiveCD, чтобы при отказе загрузки восстановиться руками. Да и смотрите наверняка, какие пакеты будут обновляться. Батюшка поп, зачем прихожан пугаете ?
> Дорогой zerot, апологет ректальной тонзиллэктомии! You made my day, thank you very
> much!да, как мало вам нужно для активации проявления следов высшей нервной деятельности, сдобренной знаниями этикета, околомедицинской терминологии и какого то :) нерусского языка
Можно вопрос. Зачем NetworkManager так активно впихивают во все дистрибутивы?
Ничего лучше нет для хомячков и не только для них. Удобная штука!
Отучаемся говорить за всех, пушистый Вы наш.
В /etc/sysconfig/network-scripts/ifcfg-eth0 (для примера) пишем NM_CONTROLLED="no" и получаем всё по-старинке.
Ой как много уже определений для меня.
Не знаю что такое Gnome, графикой в Линуксе не знаю как пользоваться. Нашел это в CentOS, другого вроде нет. Всего 100 серверов с "крутой серверной ОС". Извините если не слишком круто. И да, мы вообще ламеры по сравнению с Вами :)
не удержался
знакомый таширский говорок :)
а, кстати 100 серверов не всегда в плюс. На меньшем количестве почему не смогли сделать ? :)
> Кстати, не знаю как в федоре, но в CentOS уже сеть запихали
> в NetworkManager (по-моему так называется), черную коробку. Наверное для desktop-ов хорошо,
> а на сервере уже страшновато становится немного: зачем статику через демона
> назначать?Отключите и не парьтесь )
В Debian Squeeze почему-то NM работает только с теми интерфейсами, что не перечислены в /etc/network/interfaces. ЧЯДНТ?
Есть одно место, где высокая скорость загрузки роляет - мобильные устройства. К сожалению, время работы от батарейки не так велико, как хотелось бы. Если загрузка быстрая, то можно не пользоваться хибернейтом (который всё равно выжирает батарейку), а делать честный шатдаун...
согласен, поэтому и написал про сервера и десктопы
у мобильных устройств своя специфика. там, например, предпочтительнее использовать скандально :) известный BusyBox. Но это специфика мобильных истройств, и тянуть её неудобные идеи на десктопы и сервера неверно ИМХО
> Если загрузка быстрая, то можно не пользоваться хибернейтом (который всё равно
> выжирает батарейку), а делать честный шатдаун...Не оправдано, как минимум для устройств типа мобилок: сам процесс загрузки очень энергоемок. В режиме сна современная цифра почти ничего не потребляет. А вот при загрузке проц и память лупят на полную, экран светит, периферия инициализируется вместо того чтобы спать и прочая. Это легко сожрет энергию которой бы на много часов сна хватило. Исключение разве что ноуты на интеле, однако даже там у хибернейта есть крупный плюс: вы немедленно попадаете в ваше прошлое рабочее окружение а не нулевую систему после загрузки. Что как-то сильно удобнее - если пришлось прервать работу, можно продолжить ее точно с того же места, без каких-либо телодвижений и очень быстро. Но это не значит что перезагрузка должна тормозить и в этом плане systemd выглядит интересно.
Думаю, человек имел в виду нетбуки и прочие айпады.
Мобильные телефоны вообще не выключаются )
> Думаю, человек имел в виду нетбуки и прочие айпады.Даже на нетбуках и ипадах режим сна довольно экономный (на лично моем девайсе - девайс в нем может валяться эдак ~неделю). А почти моментальное восстановление в предыдущее рабочее окружение - рулит и педалит. Однако ж быстрая загрузка все-равно никому еще не вредила.
> Мобильные телефоны вообще не выключаются )
Это вы так думаете. А оказывается - бывают извращенцы, которые пытаются "экономить" батарейку путем именно выключения телефона на ночь и прочая. На практике результат такой "экономии" запросто получается со знаком минус. Прито те крохи которы за ночь скушает проц не идут ни в какое сравнение с тем что он+лцдха+рег в сети+прочая сожрут при ребуте :). И тем не менее, а согласитесь что загружающийся 2 минуты телефон - тоже не прикольно? :)
>И тем не менее, а согласитесь что загружающийся 2 минуты телефон -
> тоже не прикольно? :)Учитывая аппаратные характеристики телефонов и кучу явы в ПО, 2 минуты - это чудо =)
> скрипты это большой плюс, если вы хотите иметь контроль над системойВы - пользователь LFS? Никто, кроме LFS'ников, не имеет морального права так говорить.
Если у вас нормальный дистрибутив, то, как бы вы ни правили ваши скрипты, при следующем обновлении они всё равно заменятся на дефолтные, и ваша система начнёт вести себя совсем по-другому.
Поттеринг предлагает совершенно другой путь - вместо ковыряния в потрохах скриптов, использовать продуманные программы с гибкими настройками на все случаи жизни.
Путание исполняемого кода и конфигурационного файла - старая болезнь разработчиков Unix, хотя этот принцип прямо противоречит модульной концепции разработки, исповедуемой в этом семействе ОС.
> Путание исполняемого кода и конфигурационного файла - старая болезнь разработчиков Unix,
> хотя этот принцип прямо противоречит модульной концепции разработки, исповедуемой в этом
> семействе ОС.В результате и получаем справедливые насмешки: "Unix - это не куча костылей и подпорок, Unix - это тщательно продуманная система костылей и подпорок!"
>> Путание исполняемого кода и конфигурационного файла - старая болезнь разработчиков Unix,
>> хотя этот принцип прямо противоречит модульной концепции разработки, исповедуемой в этом
>> семействе ОС.
> В результате и получаем справедливые насмешки: "Unix - это не куча костылей
> и подпорок, Unix - это тщательно продуманная система костылей и подпорок!"1. Скрипты и конфигурационные файлы не "путаются", а каждый выполняет свою задачу.
2. Параллельное наличие и скриптов, и конфигов в полной мере соответствует модульной концепции. Есть кошерное дистрибутивное решение - правим конфиги. Нет (случается и такое) - приходится править скрипты. При отсутствии скриптов в данном случае пришлось бы править исходники и компилить. Сам я приверженец кошерных методов и при необходимости отключить сервис exit 0 в загрузочный скрипт не дописываю, но на практике все же приходилось править
как скрипты, так и исходники. Ктоме того скрипты способствуют прозрачности загрузки.
> 2. Параллельное наличие и скриптов, и конфигов в полной мере соответствует модульной
> концепции. Есть кошерное дистрибутивное решение - правим конфиги. Нет (случается и
> такое) - приходится править скрипты.Почему же ещё никто не переписал на скриптах тот же apache?
Когда люди находят ошибку или отсутствие архиважной функции в бинарной программе, они, как правило, пишут патч и отсылают на багтрекер.
Когда людям нужно расширение функциональности бинарной программы, они пользуются механизмом плагинов. Причем, в целях упрощения плагиностроения, плагины могут быть и скриптами.Именно по таким принципам строится systemd.
А скриптовая природа существующих систем загрузки - это лишь отголосок первоначального хаоса ранней эпохи Unix, но никак не эталон.
> Когда людям нужно расширение функциональности бинарной программы, они пользуются механизмом плагинов.Уточняю: здесь речь идёт о добавлении достаточно специализированных функций, которые не нужны большинству пользователей программы, но нужны меньшинству.
Например, исполнение некой команды в /etc/rc.local. У юзера Васи там прописан запуск сервера counter-strike, а у юзера Пети, например, смена мак-адреса (ну не осилил он штатные средства дистрибутива).
Это проблемы Васи. Почему я как разработчик должен учитывать таких дол..ов? Гораздо лучше будет если объяснить ему насколько он не прав. Подобными вывертами Линукс роет себе яму.
По теме этой поделки... Upstart + легковесный шелл - и ваши волосы будут мягкими и шелковистыми. Только не нужно пытаться объяснять насколько крут systemd. Никогда не поверю, что сервера вы выключаете на ночь и каждое утро бутите заново. Или может быть дома у вас нет пары минут, чтобы дождаться загрузки? Для различного рода потаскунов есть спящий режим. Вобщем это один из тех проектов, который нужно душить в зародыше.
> Это проблемы Васи. Почему я как разработчик должен учитывать
> таких дол..ов?Праильна, лучше ходить под себя ... чем в отхожее место.
>> Это проблемы Васи. Почему я как разработчик должен учитывать
>> таких дол..ов?
> Праильна, лучше ходить под себя ... чем в отхожее место.Скажите, а по улице вы тоже с горшком ходите для страждущих? Или все-таки указываете им где можно справить нужду? Из-за такого вот не в меру активного лизания всем желающим система медленно, но верно превращается в помойку.
>>> Это проблемы Васи. Почему я как разработчик должен учитывать
>>> таких дол..ов?
>> Праильна, лучше ходить под себя ... чем в отхожее место.
> Скажите, а по улице вы тоже с горшком ходите для страждущих? Или
> все-таки указываете им где можно справить нужду? Из-за такого вот не
> в меру активного лизания всем желающим система медленно, но верно превращается
> в помойку.Видел я конторы таких разработчиков. На 4 этажа - 1 отхожее место, 2 писсуара и 3 кабинки. зассано и засрано, а потом еще и растоптано. Вот путь джедаев, да.
Это я все к тому, что разработчик думает, что знает как должно быть, хоть это задача архитектора.
Хм.. в Линуксе уже появились архитекторы?
> По теме этой поделки... Upstart + легковесный шелл - и ваши волосы будут мягкими и шелковистыми.От созерцания долго и неторопливо грузящейся системы мои волосы становятся жесткими, как щетина. Я хочу почитать свежие темы на форуме, пока мой утренний кофе не остыл. Так что не катит.
> Вобщем Linux это один из тех проектов, который нужно душить в зародыше.
В принципе, вы могли бы ограничиться этим утверждением, которое полностью раскрывает ваше мировоззрение.
>> Вобщем Linux это один из тех проектов, который нужно душить в зародыше.
> В принципе, вы могли бы ограничиться этим утверждением, которое полностью раскрывает ваше
> мировоззрение.Ох..тельно. Зачем приписывать мне то, чего я не говорил?
> Ох..тельно. Зачем приписывать мне то, чего я не говорил?Какая разница, что кричит неадекват... )
>> По теме этой поделки... Upstart + легковесный шелл - и ваши волосы будут мягкими и шелковистыми.
> От созерцания долго и неторопливо грузящейся системы мои волосы становятся жесткими, как
> щетина. Я хочу почитать свежие темы на форуме, пока мой утренний
> кофе не остыл. Так что не катит.Уже обсасывали эту тему(как ни странно на лоре иногда бывают адекватные люди). Основная проблема - bash слишком тяжел для скриптов инициализации. На Фрюше такой проблемы не существует.
>Основная проблема - bash слишком тяжел для скриптов инициализации.Убунта с апстартом и дашем грузится так мучительно медленно, что любой кофе пять раз остынет.
Проблема здесь в архитектуре, а не в конкретных средствах.
> Вы - пользователь LFS? Никто, кроме LFS'ников, не имеет морального права так говоритьочередной иудо - христианин с можно и нельзя ? Захочется - будем использовать микроскоп для забивания гвоздей, если это даст искомый результат искомым путём. Правда здесь как раз наоборот - скрипты это адекватно
> Если у вас нормальный дистрибутив, то, как бы вы ни правили ваши
> скрипты, при следующем обновлении они всё равно заменятся на дефолтные, и
> ваша система начнёт вести себя совсем по-другому.неверно. всегда есть какой нибудь rc.local, который оставляют для того, чтобы вы написали свой алгоритм
> Поттеринг предлагает совершенно другой путь - вместо ковыряния в потрохах скриптов, использовать
> продуманные программы с гибкими настройками на все случаи жизни.на мой взгляд раздувается истерия там, где нужно просто научиться пользоваться типовыми механизмами. Не умеете пользоваться профессиональным инструментом - скриптами - не администратор UNIX, а желающий присоседиться чайник
> Путание исполняемого кода и конфигурационного файла - старая болезнь разработчиков Unix,
> хотя этот принцип прямо противоречит модульной концепции разработки, исповедуемой в этом
> семействе ОС.Это не болезнь, а принцип организации работ, позволяющий качественно и наглядно получать результат. Не надо за меня продумывать, я не персонаж из стада христова, предоставьте функциональные кубики, и я свяжу их нужными скриптами. Правда желающим влезть прослойкой со своими идеями и толкованиями места не останется - так туда им и дорога
> Захочется - будем использовать микроскоп для забивания гвоздей, если это даст искомый результат искомым путём.Идейный противник молотков?
> Правда здесь как раз наоборот - скрипты это адекватно
И правда, сибирский админ, отвергающий конфиги и настраивающий программу правкой кода.
Смеялся :-D> неверно. всегда есть какой нибудь rc.local, который оставляют для того, чтобы вы
> написали свой алгоритмВы не поверите... в systemd всегда можно вызвать произвольный скрипт или команду.
Но в стандартном процессе загрузки, который устраивает 99.9% пользователей, без этого можно обойтись.> на мой взгляд раздувается истерия там, где нужно просто научиться пользоваться типовыми механизмами. Не умеете пользоваться профессиональным инструментом - скриптами - не администратор UNIX, а желающий присоседиться чайник
По-вашему, "типовой механизм" - это настройка программы через редактирование её кода?
Да вы смешной человек ;-)> Это не болезнь, а принцип организации работ, позволяющий качественно и наглядно получать результат.
(C) Bill Gates. Amen.
> Идейный противник молотков?сторонник принятия адекватных решений
> И правда, сибирский админ, отвергающий конфиги и настраивающий программу правкой кода.
попутали, про компилятор писал не я. Впрочем поддерживаю оратора
> Смеялся :-D
к чему вы это написали ?
> Вы не поверите... в systemd всегда можно вызвать произвольный скрипт или команду.
> Но в стандартном процессе загрузки, который устраивает 99.9% пользователей, без этого можно обойтисьПусть пробуют, если будет удобнее для администратора - администратор перейдёт через несколько лет. А так жалко времени и внимания, их есть куда тратить и они не безграничны
> По-вашему, "типовой механизм" - это настройка программы через редактирование её кода?
для скриптового метода - это конечно так. Самый что ни на есть UNIX way. Не плодите сущностей сверх меры
> Да вы смешной человек ;-)
в мире масса людей, не понимающих что к чему ((С) Маширо). Видите ли, когда кто то мешает мне жить, пытается там манипулировать, смехом например, я просто зачисляю его в нелюдь и быдлоиды. Прекрасный еврейский (и не только) приём, позаимствованный среди прочих для удобства жизни. Что там делает эта обезьяна - вам ведь уже не важно :) Это в 20 лет можно "вестись" на такой стиль разговора, а потом времени и желания на понимание чужих нет. Так что для конструктивного диалога учитесь строить разговор без манипулятивных методов
> (C) Bill Gates. Amen.
must die. Карфаген должен быть разрушен :)
Вы в курсе, что у дистрибутивов redhat-ветки в /etc/sysconfig есть конфиги для многих init-скриптов, специально для того, чтобы не надо было руками в эти init-скрипты лезть?
> Вы в курсе, что у дистрибутивов redhat-ветки в /etc/sysconfig есть конфиги для
> многих init-скриптов, специально для того, чтобы не надо было руками в
> эти init-скрипты лезть?не сомневайтесь. Даже знаю где лежат маны по этой надстройке, ибо регулярно забываю параметры, и держу за штатное средство :) на редхате естественно
>> Вы в курсе, что у дистрибутивов redhat-ветки в /etc/sysconfig есть конфиги для
>> многих init-скриптов, специально для того, чтобы не надо было руками в
>> эти init-скрипты лезть?
> не сомневайтесь. Даже знаю где лежат маны по этой надстройке, ибо регулярно
> забываю параметры, и держу за штатное средство :) на редхате естественноАга. Полный список файлов из /etc/sysconfig с припиской "Эти файлы НЕ РЕДАКТИРОВАТЬ НИ В КОЕМ СЛУЧАЕ! Править ТОЛЬКО одноимённые скрипты в /etc/init.d!" :-D
> сторонник принятия адекватных решенийПо-моему, с ваших адекватных решений все местные читатели уже под стол сползли.
Мне вот интересно: вы стебётесь или действительно так думаете?
Если второе, то горячо надеюсь, что вы не админом работаете.>> По-вашему, "типовой механизм" - это настройка программы через редактирование её кода?
> для скриптового метода - это конечно так. Самый что ни на есть
> UNIX way. Не плодите сущностей сверх мерыТ.е. вынести из скрипта блок с определением настроек, по-вашему, не-Unix way?
Bad news for you, большинство init-скриптов противоречат вашему юниксвею.>> Да вы смешной человек ;-)
> в мире масса людей, не понимающих что к чему ((С) Маширо). Видите
> ли, когда кто то мешает мне жить, пытается там манипулировать, смехом
> например, я просто зачисляю его в нелюдь и быдлоиды.Маленький злобный упёртый человечек не менее смешон, чем просто маленький упёртый человечек :-)
>> (C) Bill Gates. Amen.
>must die. Карфаген должен быть разрушен :)Странно. Ведь ваши взгляды на программирование практически совпадают. За что ж вы его так не любите?
отметим, что у скриптов тоже могут быть конфиги, странно, что вы до этого не додумались и с пеной у рта пытаетесь приписать другим несвойственные им взгляды. Странно, что в нитках обсуждения вы не читаете то, что писали сверху, и пытаетесь заходить на второй круг по уже проговоренному
> отметим, что у скриптов тоже могут быть конфиги,Судя по вашим репликам выше, вы должны рассматривать такой подход как порочный.
Ведь если у скриптов есть конфиги, то в потроха исполняемого кода лезть уже не нужно.
И чем тогда скрипты будут лучше бинарников?
В дебиане не затрутся. Перейдите на нормальный дистрибутив и всё будет хорошо.
> В дебиане не затрутся. Перейдите на нормальный дистрибутив и всё будет хорошо.В дебиане (да и rpm-дистрах) не затрутся _конфиги_. Т.е. особые файлы, про которые в метаданных пакета специально отмечено, что пользователь может их менять.
Все остальные файлы, включая init-скрипты, большинство пакетных менеджеров перезаписывает без вопросов.
> init-скрипты, большинство пакетных менеджеров перезаписывает без вопросов.В дебиане не перезаписывает.
> В дебиане не перезаписывает.Во-во
dpkg: не удалось обработать параметр /var/cache/apt/archives/ia32-libs_20101117_amd64.deb (--unpack):
попытка перезаписать /usr/lib32/libcurl.so.4.2.0, который уже имеется в пакете ia32-libs-workaround-499043 0.0.1+squeeze1
configured to not write apport reports
dpkg-deb: подпроцесс вставка завершён по сигналу (Обрыв канала)
При обработке следующих пакетов произошли ошибки:
/var/cache/apt/archives/ia32-libs_20101117_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)Поубивал бы за такие пакетные менеджеры.
Наткнулся на ту же ошибку при обновлении.
Лечению поддается ?
>Наткнулся на ту же ошибку при обновлении.
>Лечению поддается ?dpkg -r ia32-libs-workaround-499043 && apt-get -f install
Флеш на amd64 продолжает нормально работать, видимо, в новой версии workaround уже не нужен.
> Если у вас нормальный дистрибутив, то, как бы вы ни правили ваши
> скрипты, при следующем обновлении они всё равно заменятся на дефолтные, и
> ваша система начнёт вести себя совсем по-другому.Иногда нужно не править, а посмотреть.
Лично у меня привычка делать "ps ax | grep <name>" после "/etc/init.d/<name> restart" иногда оказывалась очень полезной.
Чтобы понять, почему процесс не стартует, нужно знать, как он вызывается.
Тут хорошо помогает добавить "-x" в первую строчку скрипта (#!/bin/sh).
И то - может понадобиться ещё покопаться, чтобы найти строчку запуска.
И только тогда вы увидите искомое сообщение об ошибке.
А с бинарными скриптами остается только надеяться и верить)
>> скрипты это большой плюс, если вы хотите иметь контроль над системой
> Вы - пользователь LFS? Никто, кроме LFS'ников, не имеет морального права так
> говорить.
> Если у вас нормальный дистрибутив, то, как бы вы ни правили ваши
> скрипты, при следующем обновлении они всё равно заменятся на дефолтные, и
> ваша система начнёт вести себя совсем по-другому.Ты, Зин, на грубость нарываисси. Все, Зин, обидеть норовишь
Многие пакетные менеджеры позволяют не переписывать файлы в каталогах,
а оставлять бэкап; диффы показывают, спрашивая что делать с
изменениями. К примеру, slackpkg. В данном случае все упирается в
используемый инструмент, а не дистрибутив.
>Многие пакетные менеджеры позволяют не переписывать файлы в каталогах,а оставлять бэкап; диффы показывают, спрашивая что делать с
изменениями. К примеру, slackpkg. В данном случае все упирается в
используемый инструмент, а не дистрибутив.Вы думаете, это касается всех файлов в пакете, включая исполняемый код, а не только конфигов?
Интересно было бы посмотреть, как ваш slackpkg показыват diff бинарника :-)
> Вы думаете, это касается всех файлов в пакете, включая исполняемый код, а
> не только конфигов?Можно и так. Благо, скрипты *pkg позволяют такой функционал реализовать. При желании, можно и аналог blacklist'a для отдельных файлов привинтить.
> Интересно было бы посмотреть, как ваш slackpkg показыват diff бинарника :-)Молча :)
> Поттеринг предлагает совершенно другой путь - вместо ковыряния в потрохах скриптов, использовать продуманные программы с гибкими настройками на все случаи жизни.Т.е. как в Windows™?
Умный Баллмер^WПоттеринг лучше знает, что нужно пользователю.
>Т.е. как в Windows™?Как в Windows™ - это сейчас. Собрались в одном месте толпа индусов и грузовик портвейна, накодили такого, что внутрь глянуть страшно и стыдно, а толпа хомячков подвывает "Rulezzz!".
Поттеринг предлагает сделать наконец загрузку по юниксвею - модульно, прозрачно, без костылей, легко настраивается.
>>Т.е. как в Windows™?
> Как в Windows™ - это сейчас. Собрались в одном месте толпа индусов и грузовик портвейна, накодили такого, что внутрь глянуть страшно и стыдно, а толпа хомячков подвывает "Rulezzz!".полуграмотных хомячков. А в остальном — всё так.
В Windows™ загрузка организована шелл-скриптами?
Я что-то пропустил?
Мне всегда казалось, что там некий бинарный менеджер служб.Насчет прозрачности: что может быть прозрачней, чем Шелл-скрипты? А вот будет ли systemd прозрачным? Мне сомнительно.
> В Windows™ загрузка организована шелл-скриптами? Я что-то пропустил?
> Мне всегда казалось, что там некий бинарный менеджер служб.В общем, да — имена служб, «что запускать» и зависимости хранятся в реестре в условно читабельном виде.
> Насчет прозрачности: что может быть прозрачней, чем Шелл-скрипты? А вот будет ли systemd прозрачным? Мне сомнительно.
Шеллскрипт ещё нужно разобрать. А вот чтобы почитать systemd --dump, не нужно вообще никаких навыков. Ну может немного знать устройство ОС, но это же не проблема, не так ли?
>> Поттеринг предлагает совершенно другой путь - вместо ковыряния в потрохах скриптов, использовать продуманные программы с гибкими настройками на все случаи жизни.
> Умный Баллмер^WПоттеринг лучше знает, что нужно пользователю.Вот именно — пользователю, а не полуграмотному быдлану с админозом головного мозга (взять всё и поделить^W пирисабрать из исходнекаф!11), ниасилившему хотя бы два языка программирования и хотя бы один менеджер пакетов.
Вообще, использование скриптов в качестве ключевых компонентов софта очень сильно провоцирует администратора на неправильные решения.Вместо того, чтобы почитать мануал и погуглить, он тупо полезет в скрипт и наворотит там такого...
А вменяемому админу в большинстве случаев незачем лезть в скрипт - у него руки достаточно прямые, чтобы сделать все правильным методом.
Как минимум скрипты полезны для изучения того, как оно на самом деле запускается. Корежить скрипты - крайняя мера, я сам этого не люблю, но иногда это оправдано.
> Как минимум скрипты полезны для изучения того, как оно на самом деле запускается. Корежить скрипты - крайняя мера, я сам этого не люблю, но иногда это оправдано.Что мешает качнуть пакетным менеджером исходники и обсмотреться, как оно там работает, до потери пульса?
Как правило, код на Shell на порядок проще для понимания, чем на С/С++, все-таки уровень выше.
Предупреждая вопрос: да, мне приходилось разбирать и тот и другой код.
> Как правило, код на Shell на порядок проще для понимания, чем на С/С++, все-таки уровень выше.Для «скриптов на C» можно и DSL на хорошо документированных макросах препроцессора придумать. И убить двух зайцев.
Я имею в виду в случае с systemd придётся поступать так.
>И без компилятора (который не ставится обычно на production машинах) ничего не поменяешь, я так понимаю.Суровые сибирские админы не пользуются конфигами - они правят дефолтные настройки прямо в коде!
А ещё они не признают пакетных менеждеров и локальных репозитариев, и всегда вручную грузят сорцы и патчат их с последующим make && make install на каждом из 100 рабочих серверов.Поэтому, когда суровый сибирский админ обновляет конфигурацию apache, сайт проекта лежит полдня - ведь сорцы нужно скачать на каждый сервак!
> А ещё они не признают пакетных менеждеров и локальных репозитариев, и всегда
> вручную грузят сорцы и патчат их с последующим make && make
> install на каждом из 100 рабочих серверов.
> Поэтому, когда суровый сибирский админ обновляет конфигурацию apache, сайт проекта лежит
> полдня - ведь сорцы нужно скачать на каждый сервак!/etc/init.d/apache stop
echo "сегодня обнвляем веб сервер!" | mail -s "уведомление" office@company.ru
wget http://httpd.apache.org/сырцы
...Так, что ли? =)
Вы в курсе, что для того, чтобы сделать make даже админские права не нужны?
Я уверен, что всегда останется fallback-механизм с поддержкой legacy скриптов. Иначе будет сложно загнать какой-нибудь маленький самописный демон watcher/wrapper в систему сервисов.
>Я уверен, что всегда останется fallback-механизм с поддержкой legacy скриптовИ он там есть.
По сути, service unit - это просто запуск некой программы/команды + некоторые дополнительные возможности. Например, можно уже не париться с ручным отслеживаением lock-файла (создавать его при запуске, удалять при установке, проверять при запросе статуса) - этим займётся systemd. Аналогично, можно поручить ему проверку наличия конфига службы (нет конфига - зачем тогда её запускать?), выжидание паузы перед запуском, сохранение PID-файла, помещение программы в chroot, сброс привилегий и т.п.
Т.е. systemd выполняет те операции, которые раньше делались специальными скриптовыми велосипедами. Если их убрать, в 99% случаях останется голая команда на запуск демона.
А в оставшемся 1% случаев можно воспользоваться, например, штатными хуками ExecStartPre, ExecStartPost, ExecStop, ExecStopPost, ExecReload, засунув в них нужные команды или скрипты.
Блин, пролетаю... У меня где RAID, где LVM, где LVM поверх RAIDа :)
> Блин, пролетаю... У меня где RAID, где LVM, где LVM поверх RAIDа
> :)Думаю, к выпуску F15 уж это-то точно сделают. Работы там очень немного.
> Подготовлен написанный на C инструмент, обеспечивающий корректную остановку системы, включая остановку всех процессов, отмонтирование всех файловых систем, отключение всех loopback-устройств и томов Device Mapper (LVM, Multipath, etc.). Все эти операции производятся по тщательно продуманному алгоритму, обеспечивающему их корректное выполнение практически в любой ситуации.Мда. Не могу не вспомнить http://catb.org/esr/writings/unix-koans/ten-thousand.html
Потом, скрипты - это прежде всего прозрачность и низкий порог вхождения. Когда любой админ может туда заглянуть, найти ошибку и запостить патч в багзилу. А тут вместо прозрачного скрипта будет чёрный ящик, в который никто не полезет. И который всё равно всё равно вызывает umount, lvm и другие утилиты - так в чём разница с шелл-скриптом? Если скрипт тормозит оттого, что вызывает grep, awk и другие внешние утилиты - значит, давайте думать, как сделать, чтобы скрипты не тормозили. Давайте придумаем, например, новый язык для системных скриптов, который отвечал бы современным требованиям, и решим проблему в корне. А переписывать всё на С - это ну детство же, честное слово. Давайте ещё на ассемблере перепишем, всё ваще будет летать, посоны одобряют.
> Давайте придумаем, например, новый язык для системных скриптов, который отвечал бы
> современным требованиям, и решим проблему в корне.Уже придумали. C называется. На нем написаны такие важные "системные скрипты", как, например, ядро ;-)
Напиши на C, пожалуйста, эквивалент curl "http://en.wikipedia.org/wiki/Pipeline_(Unix)" | \
sed 's/[^a-zA-Z ]/ /g' | \
tr 'A-Z ' 'a-z\n' | \
grep '[a-z]' | \
sort -u | \
less
> Напиши на C, пожалуйста, эквивалентТолько после того, как вы объясните, зачем эти действия нужны при загрузке системы :-)
>> Напиши на C, пожалуйста, эквивалент
> Только после того, как вы объясните, зачем эти действия нужны при загрузке
> системы :-)Ближе к телу - попробуйте переписать на С скрипт /etc/init.d/rc
> Ближе к телу - попробуйте переписать на С скрипт /etc/init.d/rcГерр Поттеринг как раз это и сделал (добавив плюшек от себя) :-)
> Потом, скрипты - это прежде всего прозрачность и низкий порог вхождения. Когда
> любой админ может туда заглянуть, найти ошибку и запостить патч в
> багзилу. А тут вместо прозрачного скрипта будет чёрный ящик, в который
> никто не полезет.Я вообще не понимаю, что вы делаете на современных осях, где и ядро (полностью), и окружение (почти полностью) являются бинарными?
Напишите свою ось с ядром на руби, и окружением на руби, и чтобы интерпретатор руби в биос прошивался. И никакого байткода! Те, кому очень важна прозрачность, однозначно выберут вашу систему. А убогие любители скорости останутся в загнивающем бинарном мире.
> Я вообще не понимаю, что вы делаете на современных осях, где и
> ядро (полностью), и окружение (почти полностью) являются бинарными?Не путайте выполнение и контролирование.
То же бинарное ядро и бинарное окружение пишут логи в текстовом виде.
Для чего?
Чтобы было удобнее контролировать (проверять работу и искать причину отказов.
Вы же не хотите, чтобы файлы в /var/log были в бинарном виде?
> Я вообще не понимаю, что вы делаете на современных осях, где и
> ядро (полностью), и окружение (почти полностью) являются бинарными?патаму шта мир сложная весчь. Современная ось - сложная система, в которой есть разные решения для разных задач. Что по пишется на Сях или Асме, что то на скриптах, ибо адекватнее. А дальше вопрос привычек, у меня например с 2002 года на работе, дома и т.п. стоит Юникс. Ставился он изначально волевым решением - чтобы разбираться, и переходить на парадигмы форточек и использование оных я согласен только при обоснованной необходимости под конкретные задачи, ибо глюкавое поделие
-
Так что скрипты на своём месте, а дальше время покажет, главное не вестись на истерию, пусть пена бурлит в стороне
>Давайте придумаем, например, новый язык для системных скриптов, который отвечал бы современным требованиям, и решим проблему в корне.Это полумера, я считаю. Давайте сразу придумаем свой компьютер и свою ОС, которые будут отвечать современным требованиям, и решим проблему в корне.
> А тут вместо прозрачного скрипта будет чёрный ящик, в который никто не полезет.Полезут. Только лазать будут вменяемые люди с опытом разработки ПО, а не носители админоза головного мозга.
Надо сделать ассистента ядра, в виде модуля, который есть нечто иное как конфиг системы.Например сетевушки
char const *eth_names[] = {"eth0", "eth1", "ppp0",...};
struct eth_attr {
char *name;
int negotation;
int speed;
uint mac;
char *ip;
char *mask;
....
}и махонький компилер - kcc (kernel c compiler), там же будут одни константы.
А уже сам девайсы, при init_module() будут обращаться к этим структурам
и константам, даже не константам, а просто глобальным переменным.Кстати, хороший пример GRUB 2
А вот несколько другой путь:
http://www.calculate-linux.ru/main/ru/templates#%D0...
> А вот несколько другой путь:
> http://www.calculate-linux.ru/main/ru/templates#%D0...Конфиги в XMLнике? Спасибо, но имхо лучше уж тогда сишный код править :)
> А вот несколько другой путь:
> http://www.calculate-linux.ru/main/ru/templates#%D0...Microsoft пошла по этому пути)
Вы это серьёзно? Нет, в самом деле? Я так понимаю, что настоящий юникс умер вместе с настоящими юниксоидами. Это же надо додуматься - компилятор для конфигов! И пример с GRUB 2 - плохой.
> Это же надо додуматься - компилятор для конфигов!А реестр в венде это ни одно и тоже? :)
Собственно можно обойтись и GCC, но уже слышу толпы возмущённых юзеров,
"- нафига нам компилятор для работы!!!", по этому и написал - отдельная утиль!* GUI-морда, systgui[qsystgui, gsystgui, ksystgui, xsystgui] - для конфигурации.
Кнопка [ Save ], при нажатии на которую и запускается "компилятор конфигов",
более того, этот компилятор переименуют в systmake, чтоб не пугались.
С одной стороны - зоопарк из кучи инициализационных скриптов давно пора ликвидировать, меняющийся их функционал от дистрибутива к дистрибутиву в купе с дружественностью отдельных проектов к отдельным дистрибутивам же, как и попытки некоторых проектов включить в себя код обслуживающий процессы делает практически невозможным создание системы удовлетворяющей требованиям - простоты, скорости, функциональности и гибкости.
Если ни одна из существующих систем не подходит, логично предположить появление еще одной - рассчитанной на удовлетворение исходным критериям. Однако, стоит задуматься, насколько подобное решение будет эффективным, понятно, что для разработчиков Apache написать скрипт для новой системы труда не составит, а даже если они этого не сделают, это сделают разработчики самой системы инициализации, но существует ПО которое уже давно никто не разрабатывает, соответственно кому-то придется создавать новые пакеты со старым софтом для новой системы, более того кто-то должен добавлять поддержку новой системы в новые проекты, учитывая, что администрации некоторых из них не удосуживаются выложить даже архивы с исходниками релизов отписываясь ссылкой на git-репозитарии, возникает вопрос кто этим будет заниматься, в контексте жирных корпоративных клиентов - это будет сам redhat, частично комьюнити. Но в полном объеме никто этого не сделает, кроме конечного админа (если он не забьет), разумеется будут оставленны всевозможные способы выполнения задачи в режиме совместимости с другими системами - для ленивых админов/пользователей и как результат вместо первоначального зоопарка мы получим зоопарк с еще одним питомцем.Очевидно надо ввести уровень абстракции что-то вроде HAL и не hald от которого некоторые дистрибутивы успели отказаться, а что-то другое, что позволит изголяться над системой как угодно на радость красноглазикам, писать сценарии загрузки для корпоративных клиентов и тд, В линуксе уже есть рабочие аналоги подобных решений, в частности sysfs; удобная, функциональная и легковесная,.. Если уж речь идет об управлении процессами, то заниматься этим должен некоторый процесс, соответственно демон, dbus сомнительная кандидатура, хотя бы потому, что на пару с hald был отвергнут.
И смотреть тут надо на так нелюбимую некоторыми винду и ее системами управления процессами, устройствами и событиями.Короче говоря в нынешнем виде этот systemd костыль не меньший чем скрипты,
Грядет очередной зоопарк как и с upstart, где часть скриптов в /etc/init , а та часть , которую не допилили/забили лежит в /etc/init.d
Не переживайте, постепенно все скрипты перепишут. Когда всё устаканится, станет окончательно понятно какая из систем инициализации наиболее полно соответствует всем требованиям современного мира, тогда и все скрипты под неё перепишут.
> С одной стороны - зоопарк из кучи инициализационных скриптов давно пора ликвидировать,
> меняющийся их функционал от дистрибутива к дистрибутиву в купе с дружественностью
> отдельных проектов к отдельным дистрибутивам же, как и попытки некоторых проектов
> включить в себя код обслуживающий процессы делает практически невозможным создание системы
> удовлетворяющей требованиям - простоты, скорости, функциональности и гибкости.
> Если ни одна из существующих систем не подходит, логично предположить появление еще
> одной - рассчитанной на удовлетворение исходным критериям. Однако, стоит задуматься,Вопрос "на подумать": "не подходит" кому?
Операционкам, или пользователям?
Операционки с этих "неудобных" скриптов уже десятки лет стартуют.
Им хватает и функциональности, и гибкости.
А то, что для пользователей это "некрасивая реализация" - это другой вопрос.
К вопросу "работает/не работает" он не относится.
>[оверквотинг удален]
> которого некоторые дистрибутивы успели отказаться, а что-то другое, что позволит изголяться
> над системой как угодно на радость красноглазикам, писать сценарии загрузки для
> корпоративных клиентов и тд, В линуксе уже есть рабочие аналоги подобных
> решений, в частности sysfs; удобная, функциональная и легковесная,.. Если уж речь
> идет об управлении процессами, то заниматься этим должен некоторый процесс, соответственно
> демон, dbus сомнительная кандидатура, хотя бы потому, что на пару с
> hald был отвергнут.
> И смотреть тут надо на так нелюбимую некоторыми винду и ее системами
> управления процессами, устройствами и событиями.
> Короче говоря в нынешнем виде этот systemd костыль не меньший чем скрипты,Какой дивный поток сознания!
> Если уж речь идет об управлении процессами, то заниматься этим должен некоторый процесс, соответственно демон, dbus сомнительная кандидатура, хотя бы потому, что на пару с hald был отвергнут. И смотреть тут надо на так нелюбимую некоторыми винду и ее системами
> управления процессами, устройствами и событиями.Вы не поверите, но systemd как раз и есть такой демон.
Но, судя по тому, что вы путаете функции dbus, hald и sysfs, вы все-таки не поверите :`(
при первом отчёте это сильно выглядело как ещё одна поделка аля upstart, но тут уже впечатляет. надеюсь обороты авторы не сбавят. одолел этот беспорядок в init'е. такие простые, казалось бы, вещи, как нормальное укакошивание пользовательских процессов до отмонтирования и гарантия отмонтирования без затыков вообще (особенно в системах с кучей loop'ов и bind'ов) до сих нигде, вроде, и не сделали.PS: "Если уж речь идет об управлении процессами, то заниматься этим должен некоторый процесс, соответственно демон, dbus сомнительная кандидатура, хотя бы потому, что на пару с hald был отвергнут.
И смотреть тут надо на так нелюбимую некоторыми винду и ее системами управления процессами, устройствами и событиями." <-- автор, ты с ума рехнулся ? это в винде-то управление устройствами и отправка событий пример для GNU/Linux'ов ?
и кто это и где "отверг" dbus ? udev и dbus сейчас основные инструменты отлавливания и пересылки событий у freedesktop (читай: Гном и КДЕ) :\ systemd вообще вокруг dbus построен.
и от hald не "некоторые дистрибтивы успели отказаться", а разработчики X выпилили его из xorg-server, заменив hal-config на udev-config... он больше нигде и не нужен. все, кто его ещё не выпилил - выпилят.