Ненависть к systemd как психическая эпидемия
Напомните мне или дайте ссылку - я уже спрашивал, чего все на systemd так ополчились?
Выглядит, как средневековая эпидемия одержимости дьяволом, все псят, чего псят - непонятно.
Ну, не считая вот этого: http://metaclass.livejournal.com/889197.html?thread=20959341#t20959341 тут, несмотря на теорию заговора, хоть какое-то обоснование имеется.
Выглядит, как средневековая эпидемия одержимости дьяволом, все псят, чего псят - непонятно.
Ну, не считая вот этого: http://metaclass.livejournal.com/889197.html?thread=20959341#t20959341 тут, несмотря на теорию заговора, хоть какое-то обоснование имеется.
no subject
jump right through to" What the hell? What are the motivations for forking this?"
no subject
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)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
no subject
(no subject)
(no subject)
(no subject)
no subject
(no subject)
no subject
Когда такой скрипт написан на Си -- отредактировать его становится адской головной болью. Особенно весело -- когда какой-нибудь комп ВНЕЗАПНО негрузится, и редактировать его хорошо бы путём init=/bin/sh и ручного монтирования рута.
В этом смысле, человек, который говорит "я переписал скрипты с непонятного /bin/sh на понятный Си" для меня выглядит полным идиотом.
Далее -- если бы он был гениален -- ну, можно было бы от этого что-то ждать. В смысле -- что на Си у него получится что-то достаточно гениальное и универсальное, чтобы быть не хужэ предыдущего -- а в чём-то можэт быть и лучшэ.
Но он -- тупой мудак. Дажэ если не брать дурацкие идеи (systemd, avahi) -- то идея pulseaudio, на мой взгляд, была довольно хороша. Но сделано оно откровенно жопой.
Далее -- идут ужэ мелкие показательные детали. Определение вида виртуалки, в котором systemd запущен какими-то хаками в сишном коде (и, в зависимости от, произведение каких-то действий). Такие вот дегенеративные приколы: http://juick.com/tzirechnoy/2271031 .
Ну и банальный вывод, который тут, впрочем, ужэ озвучили: http://juick.com/tzirechnoy/2669842 .
(no subject)
(no subject)
no subject
(no subject)
(no subject)
no subject
Я вот, кстати, встречал мнение, что это несекурно и хорошо бы запретить. А также то, что весь из себя блобный systemd, не дающий влезть руками в кишки системы и там поковырять — сдвиг в положительном направлении.
Так что ничего удивительного что идеи systemd находят отклик в народе.
(no subject)
no subject
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
no subject
no subject
вроде старался без фанбойства как в ту, так и другую сторону.
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
no subject
Всё остальное вполне реально сделать и без особой перетряски инфраструктуры.
no subject
no subject
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
no subject
no subject
Основная проблема в том, что от systemd невозможно отказаться. Если раньше в Unix-подобных дистрибутивах практически у каждой компоненты была альтернатива (ну там Linux - BSD, Gnome - KDE, RPM - DEB, GCC - Clang, glibc - musl и т.п.), то теперь во многие компоненты проталкивается зависимость от systemd. От systemd теперь жестко зависят Gnome, udev, dbus и еще хренова туча непонятных мне абревиатур. В свою очередь, systemd жестко зависит от Linux Kernel и glibc. Все эти жесткие зависимости, как легко понять, ничего хорошего Unix экосистеме не несут.
Ну и еще один значительный минус - systemd форсит бинарный формат логфайлов вместо текстового, что полный идиотизм.
no subject
no subject
Не, ну кроме шуток. Вся инфраструктура вокруг системных демонов и системы инициализации складывалась десятилетиями. Ломать её с кондачка и менять на полностью новую - это, как минимум, рискованно. Я бы мог понять, если бы там выстроили внятный роадмэп с новыми сервисами и компонентами и лет 10-15 их поэтапно внедряли.
Кроме того, мне не нравится, что все компоненты и интерфейсы базовых сервисов оказываются замкнуты на одну команду. Это дает слишком много власти и развращает.
no subject
no subject
1. Сломана совместимость с каким-нибудь куском говна никому не нужным, в том числе лично хейтеру, но дедывоевали за эти куски говна, поэтому трогать их нельзя.
2. Раньше можно было этот кусок говна теоретически заменить на другой, никто нормальный так не делает, в том числе лично хейтер, но за право поменять этот кусок на альтернативный хейтер готов ходить на демонстрации.
no subject
Потому как приходилось менять пару раз.
no subject
Единственная претензия к сабжу — зачем в systemd бинарные форматы логов. Интуивно кажется, что текстовые православнее.
Впрочем, вот в Видне бинарные логи и никаких проблем.
no subject
2) быстрее вынимаются well-known поля
3) чтобы бизнес-информацию не выцеплять регэкспами при анализе, а доставать напрямую
Это навскидку.
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
no subject
no subject
Такая вещь, как загрузчик системы должна быть редактируема прямо наживую, без компилятора. То есть - скрипты, а не бинарники.
О конспирологии - я очень сожалею, что не сохранил две злобные статьи из одного удаленного блога про Линуса вообще и опенсорс в частности. Вкратце "писали люди долго и академично, так и написали бы. Пришел хам-инженегр, быренько сделал кое-каку, теперь с этой кое-какой и окружением нам мучиться до конца жизни, а нормально сделанные системы не воспримут - зачем? у них распространенность меньше, а кое-кака - вот она, одевай свитер и пользуйся".
Кто против - посмотрите-ка на сравнение Postgres и MySql, где постгрес академичен, а MySql - распространенная кое-кака. К счастью, СУБД писать - это не драйвера на коленке лепить, не все инженегры на это способны, поэтому кое-какеры здесь не победили.
no subject
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
no subject
no subject
http://artemg.livejournal.com/198561.html
no subject
На случай бажности — уже есть стабильная и очень хорошо отлаженная ветка systemd 208. Никто не заставляет вас ставить себе bleeding edge. Та же ROSA на ней сидит и не дует в ус. А зачем, собственно? Для десктопа уберсвежая ветка init-системы нахуй не упёрлась. На сервере upstart, покамест, но это ненадолго. RELS 7 будет уже на systemd работать.
Диванные критики также немножко забывают о том, что при всех минусах systemd, он походя решил огромную массу проблем. Навскидку раз и два. Это я вспомнил не напрягая память. Если очень попросить, выдам больше из интересного.
Напомню, что это самое сообщество (говорящее на всех углах, какой Леннарт мудак) несколько лет только обсуждало концепцию нового init. И где результат обсуждения? Где код? Зато теперь все воют, когда systemd захватывает один бастион за другим. Потому, что он решает задачи. Криво ли, косо. Но выполняет то, для чего его написали да ещё вдовесок упрощает управление системой. При всех своих минусах, да.
Я лично ещё думаю, что вой на systemd связан с тем, что любители чОрной магии bash/sh просто-напросто остаются не у дел с его появлением. Написать юнит для управления различными демонами, которые будут работать в подчас в очень сложном порядке — раз плюнуть. А если стоит задача просто красиво поднять демон — с этим вообще даже тупой эникейщик справится теперь.
Вторую причину воя на systemd ты уже читал у меня в блоге. Воют застрявшие в девяностых. У которых кроме парочки локалхостов нифига нет. Эти админы тупо не понимают, что сейчас инфраструктура в 600-800 серверов — серьёзной даже не считается. Леннарт в данном случае сделал то, чего корпоративный рынок давно хотел — единое и централизуемое управление серверами и контейнерами. C systemd уже нет нужды думать что у тебя за система там стоит и вспоминать какую хуйню ты забыл настроить на сервере/ВМ, чтобы какой-то сервис мог запуститься. Раньше такой зоопарк требовал недюжинных познаний, кто бы спорил.
Как-то так, если коротко.