За что на самом деле ненавидят systemd и Co

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

Если не понимаешь, то тебе оно не нужно. Не меняй

я и не меняю. А вот в других дистрах меняют почему-то.

Впрочем, как и в *BSD.

Там хотят перейти на launchd, вот только им разработчиков постоянно не хватает. Остальные перечисленные, это прошлое и/или забава для ролевиков-линуксоидов.

Как не нужны теперь fstab, хorg.conf

fstab и xorg.conf нужны, УМВР.

Строго говоря, выигрыш в параллельном старте может быть в многоядерных конфигурациях с SSD.

враньё. У меня многоядерная конфигурация с SSD, выигрыш конечно есть, но systemd тут не при чём. Параллельная загрузка в systemd - типичное NIH.

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

Ну а как, если оно и стартом системы управляет, и отслеживает состояние системы потом ? Кстати, в работающей системе перезапуск systemd чем грозить ? Тем же самым, что и прибивание init ?

Смотря что ты понимаешь под перезапуском. Штатный перезапуск, после апдейта например, не грозит ничем. Гипотетический сценарий когда systemd сдох и ты запускаешь его еще раз не возможен, пожалуй.

То факт, что «ОС» сейчас работает без системде, и продолжает иметь возможность работать без него, дает повод судить о том, что системде не лежит и не может лежать в «основе функционирования ОС»

я и не меняю. А вот в других дистрах меняют почему-то.

Потому что другим нужно. Такие дела

способ №1: прикручиваем к systemd какой-то NIH скрипт. За что боролись?

Боролись не за это же ну. Вообще было бы как то странно не оставить пространство для костылей, не?

И вот кстати, что еще бесит в поттеринго-поделках - они не решают МОИХ реальных проблем, но создают свои. А когда я об этом пишу как о недостатках, мне тычут багтрекером. Да какого хрена я должен репортить об этом говнософте, БЕЗ которого проблем не было!?!?!

1) Не все ломятся. В дебиане даже при использовании системд почти все сервисы запускаются из обычных LSB-скриптов

2) Только нативный системд-юнит может задействовать возможности системд, которых не было в sysvinit.

3) Юниты писать проще. Из старых initscript-ов польза только для легаси-софта, не умеющего системд.

Из того, что в федоровском юните не реализовано - это sanity_checks (разработчики федоры явно не считают их нужными).

Если что - могу привести аналогичные скрипты для других сервисов, где дебиановский не творит ничего лишнего.

Myth: systemd is monolithic.

If you build systemd with all configuration options enabled you will build 69 individual binaries. These binaries all serve different tasks, and are neatly separated for a number of reasons. For example, we designed systemd with security in mind, hence most daemons run at minimal privileges (using kernel capabilities, for example) and are responsible for very specific tasks only, to minimize their security surface and impact. Also, systemd parallelizes the boot more than any prior solution. This parallization happens by running more processes in parallel. Thus it is essential that systemd is nicely split up into many binaries and thus processes. In fact, many of these binaries[1] are separated out so nicely, that they are very useful outside of systemd, too.

A package involving 69 individual binaries can hardly be called monolithic. What is different from prior solutions however, is that we ship more components in a single tarball, and maintain them upstream in a single repository with a unified release cycle.

Источник

что еще бесит в поттеринго-поделках - они не решают МОИХ реальных проблем

А должны?

Их можно юзать отдельно от systemd? Их можно заменить на что-то другое? Если да, то тогда оно и правда модульное.

А я думал, в это верит только Lennart.

Да. Иначе они не нужны. Совсем. И судя по тому, как раздулся этот топик, не мне одному.

Да

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

судя по тому, как раздулся этот топик

Да ладно, блин, сплошные вопли, вызванные исключительно неспособностью/нежеланием изучить новую технологию.

Знаешь что случается когда после культовой игры выходит вторая часть с другим геймплеем?

То факт, что «ОС» сейчас работает без системде, и продолжает иметь возможность работать без него

То есть, если сервисы подняты посредством systemd, упавший systemd их за собой не унесёт ?

Если что - могу привести аналогичные скрипты для других сервисов,
где дебиановский не творит ничего лишнего.

Ну вот для Квагги, например, что ? Но сравнивать буду не с дебиановским.

я и не меняю. А вот в других дистрах меняют почему-то.

Потому что другим нужно. Такие дела

вопрос только в том — кому нужно?

способ №1: прикручиваем к systemd какой-то NIH скрипт. За что боролись?

Боролись не за это же ну. Вообще было бы как то странно не оставить пространство для костылей, не?

за что боролись-то? Если куча сложных NIH костылей так и осталась? Переписываем конфигурацию леннартовского ноута и десктопа на C?

Не все ломятся. В дебиане даже при использовании системд почти все сервисы запускаются из обычных LSB-скриптов

и смысл?

Только нативный системд-юнит может задействовать возможности системд, которых не было в sysvinit.

это ты про какие возможности сейчас говоришь? бинарные логи или QR коды? При желании, это можно было вкостылять и в SysV.

Юниты писать проще.

Проще, чем SysV, которая 40 лет развивалась? Не сомневаюсь.

вызванные исключительно неспособностью/нежеланием изучить новую технологию

Ты серьёзно считаешь, что осилившему писать баш-скрипты, будет сложно осилить ini-файл? Или под осиливанием ты понимаешь отлов багов вслепую?

Из того, что в федоровском юните не реализовано - это sanity_checks (разработчики федоры явно не считают их нужными).

я чего-то не понял, почему разработчики дистрибутива считают, что мне не нужно, а что нужно??

это ты про какие возможности сейчас говоришь? бинарные логи или QR коды? При желании, это можно было вкостылять и в SysV.

cgroup, лимиты настройки /proc, лимиты+настройки всякими posix вызовами (т.е. все подряд из стандарта в key=value переведено), настройки namespaces, это из полезного. В sysv это вставить можно, но почему-то никто не занялся (почему - на этот счет могут быть разные мнения).

Их можно юзать отдельно от systemd? Их можно заменить на что-то другое?

нет и нет. Но кого это волнует?

cgroup, лимиты настройки /proc, лимиты+настройки всякими posix вызовами (т.е. все подряд из стандарта в key=value переведено), настройки namespaces, это из полезного. В sysv это вставить можно, но почему-то никто не занялся (почему - на этот счет могут быть разные мнения).

очевидно, что если не вставил никто, значит никому это ВСЁ не нужно. Нужно что-то одно, его и вставляют. Те, кому нужно. А то ведь получится Windows™, в которой тоже всё есть, и текстовый редактор, и растровый редактор, и игры, и консоль, и скрипты, и даже писалка оптических дисков с встроенным шифрованием.

Вот только, если что-то действительно _нужно_, в венду приходится вставлять что-то левое. В итоге получаем Over9000 компонентов, которые не нужны НИКОМУ.

То есть, если сервисы подняты посредством systemd, упавший systemd их за собой не унесёт ?

Если системде грохнется скажем в сегфолт, то он создаст глухой инстанс для пид 1, который не будет ничего делать, и все останется висеть. Другой вопрос, что системе иницаилизации в этот самый момент придет конец, но по крайней мере внезапностей не будет

Откровнно говоря я за год активного использования и сидения на гите, с автонакатанными патчами, в такую ситуацию не разу не попал

очевидно, что если не вставил никто, значит никому это ВСЁ не нужно.

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

очевидно, что если не вставил никто, значит никому это ВСЁ не нужно.

извини, но не очевидно.

извиню. Если расскажешь, что тебе непонятно в этой, по моему очевидной, истине?

это не единственная возможная причина, основная ИМХО эта та, что девелоперы != админы. И когда всякие фишки (которые далеко и не все девелоперы знают), но которые давно есть в посикс имплементируют так, что использовать их можно одной командой, а не написанием сишного враппера, и говорят - во цените какой ништяк одной строчкой конфига можно сделать, то получается WOW эффект, у админов и тех кто не знал. Просто фишка в том, что многие в принципе не знают о таком функционале, а почти во всех системах инициализации не сделали _простой_ возможности ими воспользоваться. Я если сейчас говорю, о функционале OS напрямую относящемуся к запуску процессов и служб, а не о журналах, qr-кодах и прочих малонужных вещах.

Слушай, извини, что влезаю. A покажи что у тебя там есть, если не секрет, ужасно интересно. Может себе перейму что. Можно мыльцем yarrow@mail.ru

это не единственная возможная причина, основная ИМХО эта та, что девелоперы != админы. И когда всякие фишки (которые далеко и не все девелоперы знают), но которые давно есть в посикс имплементируют так, что использовать их можно одной командой, а не написанием сишного враппера, и говорят - во цените какой ништяк одной строчкой конфига можно сделать, то получается WOW эффект, у админов и тех кто не знал.

ага. Вот я уже с полгода просто мечтаю о таком WOW эффекте, а мне всё суют «загрузку за 910ms».

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

журнал - это довольно нужная штучка в горящем танке. Поверь мне. А вот про остальное: рассказывай. Жду WOW импульсов ☺

Вокруг сплошной отход от «наглядных скриптов», почему-то.

Ешьте дерьмо: миллионы мух не могут ошибаться!

да пользователю ведь вообще плевать, что там под капотом?

А вот админу не наплевать.
А пользователю не наплевать на то, чтобы найти нормального админа, который может и хочет и недорого просит.

журнал - это довольно нужная штучка в горящем танке.

меня металог/rsyslog более, чем устраивают.

А вот про остальное: рассказывай. Жду WOW импульсов ☺

мне не нравится дублировать свои сообщения.

мне не нравится дублировать свои сообщения.

жаль. Ничего такого экстраординарного выше я не видел.

ну, например, контроль за ресурсами обычно в инитах ограничивается поддержкой ulimit. Что ни в какое сравнение не идет с cgroup, перечислять все возможности мне лень в /usr/src/linux/Documentation/cgroup неплохая документация зачем их полезно, потом всяческие set/get affinity, создание неймспейсов при более легковесном решении, чем lxc, но при этом надежнее чрутов и запуск сервисов в таких боксах. Вышеперечисленное вполне интересно мне.

ну, например, контроль за ресурсами обычно в инитах ограничивается поддержкой ulimit. Что ни в какое сравнение не идет с cgroup

этим разве инит должен заниматься?

всяческие set/get affinity, создание неймспейсов при более легковесном решении, чем lxc, но при этом надежнее чрутов и запуск сервисов в таких боксах. Вышеперечисленное вполне интересно мне.

мне тоже, только почему без systemd этим никто не пользовался?

этим разве инит должен заниматься?

PID-1 - нет, service manager - да, напр задача запустить сервис с ограничениеми по памяти/свопу/чтобы он не OOM-килился а стопался в случае превышения лимита и админу шло письмо/записывался скрипт, при этом этот скрипт на 1 проце, и чтобы остальные сервисы там не запускались.

мне тоже, только почему без systemd этим никто не пользовался?

cgroup и namespaces появились не так давно, и полноценно понимают, что это такое понимают далеко не все (ибо для обычной жизни оно не обязательно). Плюс, например, чтобы сделать установку аффинити нужно написать простой сишный враппер, на этом месте возникает мысль, а может оно не сильно надо.

это ты про какие возможности сейчас говоришь?

Да хотя бы возможность запускать сервис при поступлении данных в сокет (да, знаю, подобное реализует посторонний костыль xinetd). Полный список фич см. на сайте systemd.

бинарные логи или QR коды? При желании, это можно было вкостылять и в SysV.

За логи и коды в системд отвечает Journal, а в системе с sysvinit - syslog.

И да, сислог (сейчас я говорю о его актуальных реализациях, как, например, rsyslog) ни коим боком не привязан к формату обычного текстового файла: его можно настроить на вывод логов практически куда угодно и как угодно (в частности, поэтому конкретно в полезности Journal я не уверен).

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

cgroup и namespaces появились не так давно, и полноценно понимают, что это такое понимают далеко не все (ибо для обычной жизни оно не обязательно). Плюс, например, чтобы сделать установку аффинити нужно написать простой сишный враппер, на этом месте возникает мысль, а может оно не сильно надо.

вот я и думаю, что оно не сильно надо, а если какому демону оно надо, так пусть он сам этим и занимается. Вместе с админом этого демона/сервиса. Т.е. я считаю, что созданием костылей для сервисов, должны быть озабочены девелоперы сервисов. А у инита - start|stop, что ещё нужно?

Само по себе решение централизовать это всё, мне до боли напоминает реестр. Оно в принципе не централизуется.

cgroup

Вот как раз cgroup он вроде использует и для LSB-скриптов.

очевидно, что если не вставил никто, значит никому это ВСЁ не нужно.

По этой же логике: реализовал systemd, который стремительно завоевывает дистрибутивы => многим явно нужно.

Да хотя бы возможность запускать сервис при поступлении данных в сокет (да, знаю, подобное реализует посторонний костыль xinetd). Полный список фич см. на сайте systemd.

смотрел как-то. Не впечатлило. Как этот ваш xinetd - смысл? Есть он у меня, даже работает иногда.

ни коим боком не привязан к формату обычного текстового файла: его можно настроить на вывод логов практически куда угодно и как угодно (в частности, поэтому конкретно в полезности Journal я не уверен).

я в курсе.

вот я и думаю, что оно не сильно надо, а если какому демону оно надо, так пусть он сам этим и занимается. Вместе с админом этого демона/сервиса. Т.е. я считаю, что созданием костылей для сервисов, должны быть озабочены девелоперы сервисов. А у инита - start|stop, что ещё нужно?

это особенность системы в целом, а не сервиса и удобный общий интерфейс это минимум логично, особенно при правильной архитектуре (тут у меня к системд претензии).

в systemd cgroups, к сожалению, играет ведущую роль и на эту подсистему завязано дофига логики.

это особенность системы в целом, а не сервиса и удобный общий интерфейс это минимум логично, особенно при правильной архитектуре (тут у меня к системд претензии).

в принципе - да. Вот только ИМХО Леннарт не тем путём пошёл.

ЗЫЖ да и рановато, можно было-бы и оттестировать получше, что сразу везде пихать-то? ИМХО оно даже не дописано на 50%.