![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Ненависть к systemd как психическая эпидемия
Напомните мне или дайте ссылку - я уже спрашивал, чего все на systemd так ополчились?
Выглядит, как средневековая эпидемия одержимости дьяволом, все псят, чего псят - непонятно.
Ну, не считая вот этого: http://metaclass.livejournal.com/889197.html?thread=20959341#t20959341 тут, несмотря на теорию заговора, хоть какое-то обоснование имеется.
Выглядит, как средневековая эпидемия одержимости дьяволом, все псят, чего псят - непонятно.
Ну, не считая вот этого: http://metaclass.livejournal.com/889197.html?thread=20959341#t20959341 тут, несмотря на теорию заговора, хоть какое-то обоснование имеется.
no subject
1. Не unix-way
Кроме этого технических моментов очень мало, и остальное псение — оно в основном про методы разработки и проталкивания этого всего, т.е. к самому Поттерингу, и в этом смысле критике подвергаются и другие его поделия.
PS. Капча "weasel words", отлично.
no subject
Ну и по индукции -- пульс и прочее писаное поттерингом было редксотным говном (впрочем почему было?).
Сам по себе systemd вполне себе unixway, если всякие его machined/logind и прочие потроха будут более loose coupled, и отрываемыми/заменяемыми -- все станет ок. Там проблема в том, что оно идет все большой кучей, и документировано все весьма условно.
Что мне понравилось:
1 связка systemd/machined/nspawn
systemctl status показывает сервисы внутри контейнеров, и умеет ими рулить (start/stop/etc)
2 systemd умеет выдавать сервисами _свой личный_ /tmp
3 конструкция когда fstab парсится утилитой, которая генерит кучу файликов в /run, которые уже потом парсятся/выполняются systemd и к котороым применимы все правила и override'ы.
Что мне активно не нравится:
1 tight coupling с pam и login session, и концепцией seats, которую активно пихает поттеринг. Видимо для десктопа а-ля винда это нормально, но когда у тебя фактически single user, а при этом ты активно используешь юзеров в системе и всякие чруты/контейнеры для изоляции -- оно начинает сопротивляться и люто бесит этим.
no subject
Это в каком месте он unix-way, если, конечно, не считать юниксвеем "а тут у нас блоб, давайте все непонятное в него запихаем".
> будут более loose coupled, и отрываемыми/заменяемыми -- все станет ок. Там проблема в том, что оно идет все большой кучей, и документировано все весьма условно.
Вот в этом-то и проблема. Недостаточность документации, например, следует тупо из того, что авторы по факту написали блоб совместимый только сам с собой; или, проще говоря, о непроработанных интерфейсах. Такие куски софта, даже при формальном наличии компонентов, слоев и прочей декомпозиции весьма склонны к тому, что эти самые слои и компоненты со временем прорастают друг в друга и завязываются на грязные хаки внутри друг друга. Так что никогда он не будет loose coupled, энтропия не позволит-с...
> tight coupling с pam и login session, и концепцией seats, которую активно пихает поттеринг.
Это (как и случай с параметром debug в cmdline, за которую П был обложен хуями) есть очень характерный признак того, что девелоперы работают на пределе своего понимания системы.
Все это, к сожалению, вполне объяснимо если вспомнить где работает Поттеринг и зачем его работодателю такая хрень нужна. Так что systemd — это наша объективная реальность на ближайшие лет двадцать/
no subject
Коллега -- вы ставили это ну хотя бы в виртуалку, если не на живое железо?
О вкусе устриц интересно спорить с тем, кто их если не кушал, то хотя бы пробовал.
И да -- foo.service в котором можно прошить @BIN_DIR@/foo при сборке пакета -- удобнее, чем поддерживать инитскрпиты ну хотя бы пары поколений основных дистрибутивов (ну скажем debian/{squeeze,wheezy,jessie}, ubuntu/{precise,trusty}, centos/{5,6,7}.
Ну я честно говоря вангую, что П. из проекта выпиздуют через годик, и все не-essential выкинут в какой нибудь systemd-contrib. Ну либо запилят более-менее внятный форк.
no subject
Я-то в курсе, но если шототакоеd нельзя оторвать от шотоэдакоеd, то это всё равно блоб: он и в систему приезжает одним куском, и внутрь кроме разработчиков никто не полезет, а значит — они там будут творить любую чернягу, которую пожелают.
> Коллега -- вы ставили это ну хотя бы в виртуалку, если не на живое железо?
Честно? Нет, мне пока для обзорных целей хватает общих статей (тем более что там всё равно нету никаких инноваций), тем более что о его дизайне я и не пытаюсь спорить — речь-то про философию разработки.
> foo.service в котором можно прошить @BIN_DIR@/foo при сборке пакета -- удобнее,
Удобнее, факт, и давно пора было сделать. Другое дело то, что если при этом вам приходится оторвать половину юзерленда и заменить на свое, зачем по прежнему называть это GNU/Linux?
> П. из проекта выпиздуют через годик... запилят более-менее внятный форк.
Пока еще его ниоткуда не выпнули и не запилили форков ни для одного из его поделий.
no subject
no subject
no subject
Там выкинуто что-то, что я считаю разумным, и оставлено то что стоило выпилить.
(я уже писал выше -- что то как сделана работа с fstab -- мне например нравится)
Что-то (machined/machinectl) мне в принципе нравится, но надо было это застабилизировать как интерфейс, и выпиздовать в отдельный пакет.
А не втаскивать всю хуиту внутрь, чего я не одобряю совсем.
no subject
no subject
В общем можэт и лучшэ чем сейчас -- но такие вещи, IMHO, как раз скриптами надо делать.
Как оно было ещё в SVR1-SVR2, AFAIK. Нафига это в mount выкинули -- я не понимаю.
no subject
no subject
no subject
no subject
Они выполняют по две задачи - копируют/перемещяют файл в файл с новым именем и кучу файлов в директорию с сохранением имен. В результате путаница и глюки в скриптах.
no subject
no subject
no subject
PS. в принципе, должно быть понятно что систему нельзя разюниксвеить до атомов. то есть можно, но это будет неудобно. поэтому где-то надо остановиться.
no subject
The UNIX Programming Kernighan and Pike 1984
вот оно и юникс вей
а прочее суть ересь и анафема
no subject