У systemd появился конкурент: epoch

И пох

Не взлетит.

Сайтик у него годный

Лучше б init-ng пилили.

Посмотрим что получится.

Неплохо.

Фрагментация на лицо. Давайте допилим существующий костыль но нормального состояния?! - Нет! А давайте тогда еще один костыль запилим?! - Давайте!

Действительно, ведь можно было просто допилить upstart, а не городить systemd.

Для эмбеддеда годно. Надо стукануть в рассылку OpenWRT - пускай заюзают.

Да ладно?

Что ты хочешь? Тут портеж через день имплементят на слабо то на плюсах, то на лиспе...

upd: ... то на delphi ...

Ну это уже жыр от лисперов, которые пафосно слились от «уважения к себе» :)

Именно. Но сама systemd неплоха, но в концепцию некоторых дистров не вписывается (Arch, Debian ИМХО)

at a little init system price

А цифры?

All services and options go in one configuration file, providing easy configuration and unrivaled control.

Закапывайте.

это для встроенных систем. Никакой это не конкурент systemd

Невозможно допилить systemd до твоего видения «нормального состояния» в их багтрекере на типичное сообщение «об плохой реализации давайте сделаем получше» указывают на дверь выхода.

Срочное сообщение! Всем сносить BSD- и SysV-init для тестирования очередной ненужной поделки!

это для встроенных систем

«One configuration file, providing easy configuration and unrivaled control» - это диагноз.

Дайте угадаю. Оно написано на жабаскрипте и требует постоянного доступа к интернету?

All services and options go in one configuration file, providing easy configuration and unrivaled control.

Если там подразумевается что-то вроде DAEMONS из арчевского rc.conf, то это очень даже хорошо.

Надо на жабе написать, со спрингом и java ee контейнером. Будет годно.

я открыл код и мои глаза вытекли. каша-малаша. а качество ниже плинтуса.

это для встроенных систем. Никакой это не конкурент systemd

намекаешь на размеры комбайна?

«One configuration file, providing easy configuration and unrivaled control» - это диагноз.

нет, родной. это то, за что мы все так любили арч. вечная память rc.conf

это то, за что мы все так любили арч

Рач^WАрч - это тоже диагноз.

И кстати, на rc.conf это похоже довольно мало: http://universe2.us/epochconfig.html

тююю! не нервничай ты так. арч не идеален, но rc.conf был реально крут и удобен

спасибо. поплакал. пойду напьюсь с горя:(

пруф?

rc.conf был реально крут и удобен

Для редактирования человеком - наверное.

Боян, но смешной

А мне нравился старый init Арча. Очень удобно было.

поддерживаю люто. Арч мне нравился именно этим.

Для редактирования человеком - наверное.

ты так намекаешь, что хвостострел - не человек?

запомним на будущее

ты так намекаешь, что хвостострел - не человек?

Я намекаю, что хвостострел пишет программы, которым нужно взаимодействовать с системой инициализации. Инсталляционному скрипту гораздо проще подложить файл в каталог, чем отредактировать один большой файл.

хвостострел - не человек?

он не человек, он модератор (непризнанный)

Инсталляционному скрипту гораздо проще подложить файл в каталог, чем отредактировать один большой файл.

На уровне высокоуровневых апи — никакой разницы нет, подложить файл, отредактировать или добавить запись в реестр/базу данных.

Инсталляционному скрипту гораздо проще подложить файл в каталог, чем отредактировать один большой файл.

На уровне высокоуровневых апи

Назови всех поименно (API, я имею в виду).

Ужасная домашняя страничка

Ужасно примитивное нечто, написанное на Си.

Пойду отходить.

Назови всех поименно (API, я имею в виду).

Ну, некий сферический правильный системд в вакууме, в котором ты не будешь ни файлы копировать, ни редактировать, ни создавать, а просто пошлёшь сообщение системе по дбас, что необходимо поставить такой-то демон с такими-то параметрами.

Но с другой стороны можно сказать что rc.conf — это и есть более высокий уровень. При этом rc.conf написан на баше, т.е. код парсинга уже написан и получение значения переменной из этого файла и перезапись с новыми значениями — не такая уж и сложная задача(да и сам файл не такой большой). + то что он написан на баше позволяет делать там различную динамику, тотже список демонов для запуска можно так же получать как список файлов из папки.
Потом по этому cписку демонов можно легко делать systemctl enable/start, если в системе стоит системд и какие-то другие действия, если не системд.

Да и не всем нравится, когда скрипт установки самолично прописывает демона в автостарт. Я лучше руками пропишу в rc.init в список DAEMONS.

Епох? И да, велосипеды не нужны.

Назови всех поименно (API, я имею в виду).

Ну, некий сферический правильный системд в вакууме.

AFAIK, у systemd нет такого API. Впрочем, в systemd юниты - отдельные файлы.

Да и не всем нравится, когда скрипт установки самолично прописывает демона в автостарт

Какой смысл ставить демона, не прописывая его в автостарт?

Я лучше руками пропишу в rc.ini в список DAEMONS.

Вот-вот, в этом весь Арч и арчеводы. Представь, что у тебя несколько десятков машин. Или сотен.

у systemd нет такого API

Ну, например, там можно systemctl enable/disable. И он автоматом создаёт или удалёет символические ссылки(их можно делать и врчуную, но правильный путь получается всё же через systemctl, что и можно считать неким аналогом АПИ).

Какой смысл ставить демона, не прописывая его в автостарт?

Например когда какой-нибудь google chrome ставит google update srvice в атозагрузку, а я его отключаю.

Представь, что у тебя несколько десятков машин. Или сотен.

везде обновить rc.init, если они одинаковыми должны быть.
Либо если нужно только какой-то отдельный демон добавить, то на всех машинах положить файлик в нужную папку(по которой строится динамический список демонов), что не отличается от системд.

там можно systemctl enable/disable

Это не API инсталляции.

Например когда какой-нибудь google chrome ставит google update srvice в атозагрузку, а я его отключаю.

Это не демон.

Представь, что у тебя несколько десятков машин. Или сотен.

везде обновить rc.init, если они одинаковыми должны быть.

Вручную/дополнительным скриптом? Ну-ну. А если не одинаковыми? Короче, бессмысленный добавочный геморрой.

Это не API инсталляции.

ну понятно, что не апи. Только как это будет твой «установочный» скрипт-то делать?

Вручную/дополнительным скриптом?

я тут, короче, краем уха слышал звон, что для таких случаев есть уже готовые решения(типа puppet?).

А если не одинаковыми? Короче, бессмысленный добавочный геморрой.

Ну а как это делается сейчас/завтра твоим «установочным скриптом, копирующим файлы»?

я тут, короче, краем уха слышал звон, что для таких случаев есть уже готовые решения(типа puppet?).

Готовое решение этой задачи - пакет, сделанный по стандарту используемой ОС.

Ну а как это делается сейчас/завтра твоим «установочным скриптом, копирующим файлы»?

http://www.debian.org/doc/debian-policy/ch-opersys.html#s-sysvinit

я тоже пишу программы, взаимодействующие с системой инициализации. Предлагаю везде использовать нормальный формат: XML,JSON,YAML. И никаких проблем с машинным доступом не будет, не важно на сколько файлов это раодрано. Для пакетов внутри Java-мира и происходит, Maven - это XML. Можно вообще не использовать файлы, а использовать центральную БД в виде sqlite или postgresql, или mongodb. Общаться с отвратительными недоконфигами в текстовом недоформате так, чтобы в момент сохранения в БД (xml/sql/nosql) дергался соответствующий преобразователь в текстовый недоформат.

Предлагаю везде использовать нормальный формат: XML,JSON,YAML.

Да. сделай это, тряпка!

sysvinit

ну так это и есть бывший подход арчика с rc.init . Только тут я так понимаю все сервисы из rc.d стартуют без разбора, а в арчевском rc.init можно белый и чёрный список делать.
Ну и я не помню было ли такое в арче, но ничто не мешает в rc.init разрешить значение параметра DAEMONS, равное '*', при котором будут стартовать все демоны из rc.d/