Для тех, кто пробовал: чем BSD init не устраивает?

А чем не устраивает systemd?

BSD init - это как Лисп. Сделать можно всё и как угодно, но зачем?

bsd init это скорее как bash

А чем не устраивает systemd?

Многа букфф. bsd init - несколько строк на старом добром /bin/ash

И таки да, мои демоны сами обрабатывают ошибки запуска, используют традиционные логи и конфиги, а их stdout и stderr интересен только в контексте дебага.

это скорее как bash

Там даже не bash.

чем BSD init не устраивает?

Необходимостью поддерживать зоопарк дистроспецифичных init-скриптов?

современный, из NetBSD

/0

Необходимостью поддерживать зоопарк дистроспецифичных init-скриптов?

С чего бы это?

Я про философские аспекты, а не про технические детали.

Как минимум тем, что у BSD Init недостаточно возможностей для обеспечения требуемой для решения современных задач функциональности. Именно поэтому появился systemd. И BSD - это несерьёзно. Сейчас все ориентируются на Linux, поэтому принять systemd как стандартный инит - вполне здравая идея.

Shadow> Многа букфф.

Так отруби в systemd всё лишнее - будет мало букв. И работать будет быстрее, чем с BSD Init.

для обеспечения требуемой для решения современных задач функциональности.

Современные задачи - это когда разработчик демона таймауты и эксепшены поленился обработать и кто-то должен это передёрнуть?

Так отруби в systemd всё лишнее - будет мало букв. И работать будет быстрее, чем с BSD Init.

Видимо, оптимально. Но это уже не unix.

Shadow> Современные задачи - это когда разработчик демона таймауты и эксепшены поленился обработать и кто-то должен это передёрнуть?

В наш век разработка идёт семимильными шагами. А это развитие. Зачем мешать? Лучше поддержать. А инструмент, который поможет использовать быстронаписанные сервисы в продакшне и обеспечит при этом надёжность даже при использовании ненадёжного кода, очень востребован. И этот инструмент - systemd. Неясно, почему следует отказываться от его всеобщего принятия - все от этого только выиграют.

Shadow> Видимо, оптимально. Но это уже не unix.

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

когда можно использовать современный, удобный и активно развивающийся и поддерживаемый инструмент?

Visual Studio и .Net рулят, не спорю.

вот! Грамотное обоснование в отличие от воплей инстеричек систем-хейтеров.

В таком контексте, выбор RH vs. Debian не стоит, а уходит в пользу MS. В случае какой-либо сетевой жавамашины - в остатки соляриса.

Это где всё в одном файле?

Почти. Где есть только три задачи: стартануть демон, записать его pid, убить демон. Остальное - вопросы к разработчику демона.

Shadow> Visual Studio и .Net рулят, не спорю.

VIsual Studio вообще-то шлак. А вот .Net если бы был отстоем, то Мигель не стал бы делать Mono. Возможности интеграции приложений в .Net просто поражают воображение любого ретрограда.

Shadow> В таком контексте, выбор RH vs. Debian не стоит, а уходит в пользу MS.

У MS до сих пор нет технологий уровня systemd. Итого выбор именно в пользу RedHat.

Shadow> Почти. Где есть только три задачи: стартануть демон, записать его pid, убить демон. Остальное - вопросы к разработчику демона.

Есть задача не только стартануть демон, записать его pid и убить, но и как минимум сделать это лицом к пользователю, а не задницей. И с таким подходом разграничение прав и ресурсов будет происходить только с костылями. Тот же systemd обходится без костылей в таких задачах и предоставляет дополнительные возможности, обеспечивая надёжность и бесперебойность всей системы в целом.

до сих пор нет технологий уровня systemd

alt+ctrl+del (не шучу, намного удобнее)

И с таким подходом разграничение прав и ресурсов будет происходить только с костылями

Дай Б-г, разграничение прав и ресурсов РАЗ В ГОД меняется. Делается двумя строчками в init скрипте. Где костыли?

Это совсем не то. И GUI для systemd тоже имеется. И возможности systemd этим ctrl+alt+del далеко не ограничиваются.

И возможности systemd этим ctrl+alt+del далеко не ограничиваются.

Ну да, скоро с вейландом в один процесс объединяться научится.

Современные задачи - это когда разработчик демона таймауты и эксепшены поленился обработать и кто-то должен это передёрнуть?
разработчик ... поленился

Жирный тролль на лоре детектируется с одного коммента.

Большинство экзепшенов на продакшене вообще можно не отрабатывать, можно просто сказать супервизору systemd, чтобы сразу поднимал упавший сервис и всё.

Большинство экзепшенов ... можно не отрабатывать ... сразу поднимал упавший сервис и всё

Костыли же, не?

Кто ты такой и что сделал с Квазаром?

Жирный тролль

Я помню всемирный баттхёрт от впиливания glibc2. Что характерно, впиливал RH.

Если бы я шарил в инитах на уровне программиста, а не средней руки админа... Блин, голубая (в хорошем смысле слова. предвижу подколы про ЦА OS X) мечта - портировать launchd на линукс

А чем жизнь не мила без launchd?

bsd init - как раз не программистское, а скорее, админское творение.

Опять километры баш-спагетти?

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

Просто хочется чего-то современного, шустрого и делающего только отведенную ему задачу (systemd - сущий bloatware, комбайн)

мечта - портировать launchd на линукс

Была уже у одного чувака такая мечта... Вон, зато, как задорно теперь говно по толксам летает.

Хм. К чему это было сказано?

Дело было так.

Самый популярный gcc тогда был 2.2, пропускающий кучу ошибок. glibc2 собирался только с 2.9x, который был в тот момент альфа версией от RH, под названием egcs, но при этом не пропускал часть кривого кода. В итоге потребовалась перетряска кода кучи софта. Более того, кернел долгое время не мог собираться egcs'ом (около года), и в системе стояло два компилятора.

Сотни тредов похожих на треды про systemd.

Километры баш-спагетти написали энтерпрайзнутые дистромэнтейнеры. Нормальный init весь конфиг держит в себе и лишним не занимается.

Костыли же, не?

Супервизор процессов - костыль? Увы, дерево супервизора — это реально необходимая сущность. Все ситуации предусмотреть просто нереально, а сервер _обязан_ обслуживать клиентов 24/7. К примеру, если незарезервированная СУБД на сервере упадёт глубокой ночью из-за традиционно некорректной работы ядерного OOM-killer, то надо ждать пока админ проснётся? Сервер должен пытаться работать, даже если у него это плохо получается. Пускай субд будет снова падать и подниматься, но бОльшую часть клиентов она всё-таки сможет обслужить.

Раньше приходилось на сервере поднимать supervisord, писать под него конфиги для необходимых сервисов, либо писать проект на эрланге. Первый вариант — костыльный, ибо init-скрипты напрямую из init не вызываются. Второй — сложен и затратен, и далеко не всегда реализуем.

Shadow> Ну да, скоро с вейландом в один процесс объединяться научится.

Вот не надо передёргивать. И вообще: как ты в BSD Init реализуешь современные возможности? Дописыванием в каждый скрипт дублирующихся функций? То-то же. А в случае с systemd лишнее просто убрано и выставлено только то, что требуется заполнить для управления сервисами. В итоге всё получается предельно эффективно и добавление возможностей в управление сервисами не влечёт за собой бешеную правку тонн скриптов.

Кстати, а почему в logind не интегрирован bash? логично же.

Shadow> Костыли же, не?

То есть, автоматическое слежение за сервисами ты считаешь костылями? Разработчик не всегда может предугадать условия выполнения, а работоспособность нужна здесь и сейчас независимо от условий.

Нормальный init весь конфиг держит в себе и лишним не занимается.

Нормальный init скатывается в километры bash-спагетти, как только появлются зависимости, супервайзинг, pid-файлы и остальное. Т.е. буквально на следующий день.

Дописыванием в каждый скрипт дублирующихся функций?

./path/to/repeated/function.sh

Я таки настаиваю, что супервайзинг - тупой костыль, появившийся из-за прорвавшихся в C/C++ ынтерпрайз жавакодеров.

Но первым начал не Поттеринг, первым начал Бернштайн. Никогда не забуду альтернативный конфиг qmail через аргументы командной строки и функционал через пайпы. И этот человек критиковал юзабельность sendmail...

Shadow> Нормальный init весь конфиг держит в себе и лишним не занимается.

Вот поэтому systemd - это нормальный инит. Впрочем, это намного больше, чем инит.

ЕМНИП, процессный супервайзинг вынужденно появился ещё в 60-х годах. Просто для многих админов это было слишком сложно, а проггеры предпочитали embed-ить свои костыли прямо в код демонов и огороживать каждый блок кода через try-catch, что только усложняло код и усложняло выявление проблем.

Shadow> Кстати, а почему в logind не интегрирован bash? логично же.

bash - оболочка. logind же - менеджер сессий. Что тут непонятного?

Кстати, почему бы тогда, раз намного больше, не объединить его с libc?