О systemd

[amarao_san]

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

Comments

[civilus]

А где у него хорошая реализация и где у него омерзительная идея?

[greycat_na_kor]

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

[civilus]

Идея как раз мне частично нравится - по крайней мере интеграцию с cgroup + namespaces они предложили первыми, это уже потом начали тянуть в себя всякое разное...

А про реализацию - как бы оно и с архитектурной точки зрения так себе. Да и в целом поттеринг хорошего кода практически не производит (пульса тому доказательство).

[amarao_san]

Ну вот пульса, допустим, хотя последние версии оно падать перестало, но кли вырвиглазное, да.

Но с systemd - ну вот у меня на нём уже десктоп, пара серверов и фрагменты - в куче машин. Пока что видел пару wtf из-за изменения логики mount'ов и перехвата acpi-keys, в остальном - всё хорошо.

Не обобщай

[anonymous]

Плюётся кучка дебилов с ЛОРа и прочих помоек, "все" как раз довольны и идеями (благо они постарше лоровской школоты будут) и реализацией.

Re: Не обобщай

[amarao_san]

Идеи блобовости - плохие. Не unix.

[anonymous]

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

Re: Не обобщай

[civilus]

К нему есть четкие претензии в виде того, что дебажить поведение практически не реально (были даже преценденты когда оно падало из-за включения дебаг режима), к тому что они тянут в себя кучи проектов при этом их поганя (udev тому пример, где открутили возможность подгрузки модулей на системах, не использующих kmod, что достаточно грустно для тех же роутеров - там ядра все чаще и чаще становятся достаточно свежими, но теперь прийдется использовать mdev из busybox'а. А все потому, что modprobe может поставляться busybox'ом, он там медленный но компактный, а kmod жирноват, что в условиях наличия 4-8МБ ROM'а - неприемлимо), ну и к тому что чем жирнее главный блоб, тем больше вероятности багов в нем. А если инит упадет с сегфолтом - будет грустно. Ну и не unix-way'ность этой штуки.
Опять же зная подход поттеринга к написанию кода, есть вполне обоснованные сомнения в качестве кода systemd.

[voidlj]

Хороший пример излишней ожиренности и усложнения - то, как systemd заменил логику монтирования файловых систем. Вместо простого прохода по fstab имеем какие-то динамические генерируемые юниты с кучей правил по тому, у кого приоритет. И все это в бинарниках, в которых не полазишь и не поймешь, как оно работет - спасает только гугл

[amarao_san]

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

Вот, расскажи мне, как я должен в условиях sysvinit'а монтировать nfs через vpn, который поднимается после того, как dmcrypt смонтирует шифрованный том, где сертификат лежит?

Порядок такой:
1) Смонтировать root
2) Смонтировать dmcrypt
3) Запустить openvpn
4) Дождаться появления сетевого интерфейса от vpn'а
5) Смонтировать NFS

В systemd такая конструкция делается в пол-пинка, более того, с on-demand mount'ами можно даже не париться с последовательностью - к nfs всё равно только пользователь обращается, так что всё к этому моменту уже поднимется и будет работать.

[voidlj]

Гм, не понял, где именно сложность. Делается прикручиванием скрипта, который openvpn сам вызовет при поднятии интерфейса (--up). Есесно openvpn должен запускаться после отрабатывания dmcrypt и поднятия сети.

Причем имплементировать это быстрее, чем разбираться с тем, как прикрутить к openvpn'у systemd - настройка в любом случае нестандартная.

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

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

[amarao_san]

А mount для NFS кто тогда делает?