systemd 246

Именно так. Линукс - это ни разу не юникс. Но юникс уже на свалке истории. Бабло победило. Sad but true.

Его нигде не смогли осилить — ни в CentOS, ни в Debian, ни в Ubuntu.

В Chrome OS осилили. Или я ошибаюсь?

Получается, ты противоречишь сам себе?

Ты спросил, почему эти правила udev лежат в пакете systemd. Я ответил, почему, но не совсем точно (сказал про systemd вместо logind). Ты меня поправил и лучше меня сам ответил на свой вопрос — они лежат там потому, что в том же пакете лежит logind, который эти правила использует. Если в твоём дистре мейнтейнеры решат вынести logind в отдельный пакет — правила скорее всего переедут в этот новый пакет.

Вы всё ещё уверены, что зависимостей между компонентами системд нет?

Нет, а вы? :) А если серьёзно — я не говорил за весь systemd. Udev можно использовать отдельно (и я парой постов выше привёл доказательства), logind тоже (пусть и после наложения патчей). Intelfx выше приводил пример, что journald можно собрать и использовать отдельно, но это ещё нужно проверить.

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

Как правило, дистрибутивы обновляют source-базы для своих пакетов плюс-минус одновременно, т.е. условные udev и systemd (и возможные выделенные из его поставки в отдельные пакеты инструменты) будут обновляться синхронно. Если это не так — это ошибка мейнтейнера (или пользователя, который кусочно обновляет свою систему, когда этого делать не стоит).

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

Ну вот он лежит, в Gentoo для него есть ebuild, который его собирает и устанавливает без проблем и адских риуталов с жертвоприношениями. В комплекте с ним идёт всего один патч, который чинит сборку пакета с GCC 9.

А зачем генту форкал удев, или зачем девуан пилил свой вдев - тут так никто аргументированно и не ответил

А зачем спрашивать это тут? Тут есть люди, которые эти форки делали?

удев так или иначе зависит от системд конкретной версии (либо напрямую, либо через брейкс)

Ещё раз — так происходит в дистрибутивах, где используется systemd, но udev выделен в отдельный пакет. Т.е. udev там явно собран с поддержкой systemd и использует его библиотеку. Естественно они должны будут обновляться синхронно, чтобы ничего не сломалось по дороге. Это как с проприетарным драйвером nvidia — пакет с предварительно собранным драйвером всегда жёстко привязан к конкретной версии ядра и должен обновляться одновременно с ядром. Для всех остальных случаев предлагается использовать DKMS.

ChromeOS собирают (собирали?) на базе Gentoo. С большой вероятностью там используется OpenRC.

«По крайней мере» так чуть менее, чем везде.

logind - отдельный случай. Его зависимость от systemd init связана с тем, что он помещает пользовательские сессии в свою cgroup.

Ранее управлять cgroup мог каждый процесс с необходимым уровнем доступа, и поэтому systemd init и logind самостоятельно управляли своими cgroup, и та же Canonical достаточно легко могла выковырять logind из состава systemd и использовать его отдельно. Однако после перехода на cgroup v2 в ядре, управлять деревом cgroup может лишь один процесс. Поэтому logind стал вынужден обращаться к systemd init для управления своими cgroup.

Так что возросшая зависимость logind от systemd init есть следствие изменений в ядре, а не решение разработчиков самого systemd.

Нет, там указаны конкретные версии. Типа, «не работает с версией ниже такой-то». А почему бы, если они так независимы, как тут об этом говорят? А зачем генту форкал удев, или зачем девуан пилил свой вдев - тут так никто аргументированно и не ответил, кроме как «ну захотелось им». Ну ладно, не поленился, и в федоровский systemd-udev тоже глянул. Там прямым текстом requires: systemd(x86-64) = 245.6-2.fc32.

В Debian нет никаких проблем с установкой и запуском udev без systemd init: https://ibb.co/BghLbzL.

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

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

Пользуюсь FLOSS вообще и gnu/linux в частности более 20 лет и имею хобби собирать весь софт, которым пользуюсь, из исходников. Вообще весь. Так что наблюдаю развитие ситуации достаточно давно.

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

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

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

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

Проще говоря, нельзя до бесконечности добавлять звенья в цепочку от кремния и электронов до желаемых результатов работы софта. Так же как и считать что ресурсы планеты и населения безграничны и новые ниши можно добавлять сколько захочется. И человек, знающий c->(ba)sh->c++/python/java имеет большую ценность для индустрии, чем умелец нажимать кнопку в systemd или docker.

Возможно, грядущий или будущий экономический кризис или даже крах что-то изменит. Но пока предсказать что более вероятно, торжество здравого смысла или превращение gnu/linux в полное болото корпоративными и политическими стараниями, не так уж и просто.

Корпорации, повышающие доступность своих продуктов, победили корпорации, ограничивающие эту самую доступность. Всё как в войне архитектур домашних ПК и серверов, где победил x86.

Непопулярное мнение: systemd нужен для того, чтобы люди тратили больше времени на изучение C/C++/Python/Java, и меньше времени на ковыряние с системой запуска сервисов в ОС, для которой пишут ПО.

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

Искаропки там сейчас используется eudev

…

ystemd нужен для того, чтобы люди тратили больше времени на изучение C/C++/Python/Java, и меньше времени на ковыряние с системой запуска сервисов в ОС

Это вброс. Программист же учит IDE или редактор? Или просто, как в блокноте хреначит? И переусложненный systemd - только документация. Много документации. А если выйти из стандартной задачи, всё…

то хотя бы свести к минимуму «сложные» (бессмысленно сложные) места, освободив его руки для других задач.

Вторая неудачная мысль. Админ как раз и следит, что и когда запускать. А в systemd строк кода столько, что 1 человек принципиально его не проверит. НИКАК. Значит - дыра в безопастности.

Но юникс уже на свалке истории. Бабло победило. Sad but true.

Юникс всегда и был баблом.

Админ как раз и следит, что и когда запускать.

Гоните таких «админов».

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

Админ как раз и следит, что и когда запускать.

У тебя есть сервис, прописанный для запуска в multi-user.target. Этот сервис запустится при загрузке ОС (со своими зависимостями) и будет работать, пока не упадёт или ОС не завершит работу. В случае падения systemd сделает то, что указано в описании сервиса (попробует перезапустить или пометит как failed).

Админ вынужден постоянно следить за сервисами, если:

• Сервисы постоянно крашатся, а ОС не умеет их перезапускать (плохой сервис);
• Админ не настроил мониторинг ОС и сервисов (плохой админ).

Как это противоречит тому, что udev отлично устанавливается и работает в Gentoo без Systemd? :)

Непопулярное мнение: systemd нужен для того, чтобы люди тратили больше времени на изучение C/C++/Python/Java, и меньше времени на ковыряние с системой запуска сервисов в ОС, для которой пишут ПО.

Вы правы. Именно это и есть разделение труда в привычном смысле. Оно работает достаточно хорошо достаточно давно. Но оно не может быть бесконечным. Когда-нибудь оно себя исчерпает как модель.

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

А в systemd строк кода столько, что 1 человек принципиально его не проверит. НИКАК. Значит - дыра в безопастности.

Нет, это чушь и популизм, а не дыра в «безопастности».

В bash+coreutils+util-linux строк кода столько, что 1 человек принципиально его не проверит.

В Linux строк кода столько, что что 1 человек принципиально его не проверит.

Наконец, в прикладном софте, ради которого ты используешь систему, строк кода столько, что…

Дальше продолжать?

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

Сервисы постоянно крашатся, а ОС не умеет их перезапускать (плохой сервис);

Откуда вы такие идиоты беретесь что крашнутый сервис надо обязательно перезапускать?

Фреско пересмотрел?

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

Это нормально. Managed services для того и придуманы, что это дешевле, чем держать штат одминов, которые будут делать всё то, что ты можешь получить в готовом виде дешевле и лучше. А дальше там serverless, CaaS, и вот это вообще прекрасно.

«Откуда вы такие идиоты беретесь что крашнутый сервис надо обязательно перезапускать?»

А откуда берутся идиоты, которые считают, что надо или обязательно перезапускать или обязательное не перезапускать?

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

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

Просто скажите честно, что вы и есть тот самый «кнопкодав». И это вы лично не можете что-то аудировать и в чём-то разбираться. Никто не собирается вас за это осуждать. Зачем говорить за других или за всех?

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

А откуда берутся идиоты, которые считают, что надо или обязательно перезапускать или обязательное не перезапускать?

https://ru.wikipedia.org/wiki/Деление_прокариотических_клеток

Конечно не нужны. Детская же ошибка.

Вы правы. Именно это и есть разделение труда в привычном смысле. Оно работает достаточно хорошо достаточно давно. Но оно не может быть бесконечным. Когда-нибудь оно себя исчерпает как модель.

Да не исчерпает оно себя. Закончится дополнительная экономия ресурсов и только. Это как если вы переходите с дорогого магазина на дешевый и таким образом эеономите, то рано или поздно все, что вы покупаете , будет куплено в дешевом магазине и на этом все, дальгейшая экономия будет невозможна. Но это не значит, что экономия пропадет. Все, что вы покупаете и будете покупать, все также будет самым дешевым, просто сэкономить ЕЩЕ БОЛЬШЕ таким способом уже не получится.

Я не говорил, что надо все сервисы обязательно перезапускать. Контекст всегда важен.

Это нормально. Managed services для того и придуманы, что это дешевле, чем держать штат одминов, которые будут делать всё то, что ты можешь получить в готовом виде дешевле и лучше. А дальше там serverless, CaaS, и вот это вообще прекрасно.

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

ну так сколько лет прошло. ;) Давно уже есть системд и эти костыли больше неактуальны.

В целом шелл вообще ужасен для программирования. Писать даже надежные однострочники очень сложно.

Шелл-скрипты все равно нужны и все равно их лепят. Просто не для инита, а для других задач, коих еще вагон.

Ничего сверхособенного системд не делает. Просто позволяет обойтись без лапши, обеспечивает некоторое единообразие да и только.

Какая там домохозяйка с ютубом? Где она и где системд…

Кто-то должен это дело понимать и поддерживать.

Да, и весь смысл в том, что это не ты.

Но не профессионал, который не знает как слепить шелл-скрипт, потому что за него всё делает systemd.

Учитывая среднее качество лепки, лучше бы вы реально не знали.

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

На вас защит не напасёшься. Тем не менее разработчики systemd всё-таки пошли на встречу и выкатили требуемое в виде userdb (как раз в прошлом релизе). Результат? У идиотов опять пригорело вместо того чтобы просто сказать «спасибо». Ну и как после этого таких кретинов воспринимать всерьёз?

Подсос засчитан.

Возникает вопрос как к этому отнесется «Повелитель Клитора».

Смотрите продолжение на LOR!

Так мы тут о вере разговариваем или о необходимости всё подвергать тщательному аудиту?

Просто скажите честно, что вы и есть тот самый «кнопкодав».

Я по долгу службы занимаюсь как администрированием, так и написанием кода для разных сервисов. И лучше я буду «давить кнопки» в сервис-менеджере, который из коробки отвечает требованиям инфраструктуры, чем буду переписывать каждый (каждый!) init-скрипт на каждом хосте в попытках добиться того же с одобренным ветеранами инитом. Сэкономленное время я с радостью потрачу на написание более качественного кода и, о г-споди, на отдых.

Труд системного администратора можно если не заменить автоматикой целиком, то хотя бы свести к минимуму «сложные» (бессмысленно сложные) места

Вот, кстати, и ответ на вопрос почему systemd так поляризовал «сообщество» - он всего лишь в явном виде отделил тех, кто способен изучать новое, от тех, кто ссыт что его заменят парой скриптов. И я склонен верить оценке интеллектуальной квалификации, которую неявно дали себе хейтеры - не спроста у них подгорает ;-)

Так мы тут о вере разговариваем

О ней самой.

И лучше я буду «давить кнопки»

Спасибо за ответ. Похоже, ещё не всё потеряно.

А протащили его в шляпу шпионы и враги режима, да?

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

А чо тут вендузятник кукареает? «SysV int» - это вечно зелённый, на все времена, и для всех поколений. Лучше него пока ничего не придумано, хотя... есть разумно урезанный «SysV int» - это runit.

Вот, кстати, и ответ на вопрос почему systemd так поляризовал «сообщество» - он всего лишь в явном виде отделил тех, кто способен изучать новое, от тех, кто ссыт что его заменят парой скриптов. И я склонен верить оценке интеллектуальной квалификации, которую неявно дали себе хейтеры - не спроста у них подгорает ;-)

Речь о том и идёт, что тебя, адепт systemd с макаронами и повидлом в голове, заменить скриптом несравненно проще, чем человека знающего старое и способного изучать новое.

Ещё раз, что ты, с неподгоревшей и даже незаискрившей задницей называешь словом «хейтер». Скажи, ты просто не понимаешь что оно значит и лепишь его везде, потому что думаешь что оно крутое и модное, да?

Речь о том и идёт, что тебя, адепт systemd с макаронами и повидлом в голове, заменить скриптом несравненно проще, чем человека знающего старое и способного изучать новое.

А на практике заменяют таких как ты :)

Если в твоём дистре мейнтейнеры решат вынести logind в отдельный пакет — правила скорее всего переедут в этот новый пакет.

И почему же мы такого не наблюдаем? Уж не по тому ли, что, даже если его вынести в отдельный пакет, этот вынос будет всё равно чисто формальным, и всегда будет требоваться системд ровно той же версии, собранный с теми же конфигурационными настройками? Вынос в отдельный пакет ещё не означает модульность, и, видимо, по этому так никто и не делает.

Udev можно использовать отдельно (и я парой постов выше привёл доказательства), logind тоже (пусть и после наложения патчей).

Ну вот Rootlexx ниже написал, что логинд - нельзя никак. Получается, из вашего «стана» приходит противоречивая инфа? Кому мне верить?

что journald можно собрать и использовать отдельно, но это ещё нужно проверить.

Ну тут я не вижу причин сомневаться. Что стоит журналду сидеть да писать логи на диск в бинарном формате… Если ещё и его нельзя отдельно собрать было бы… :)

Если это не так — это ошибка мейнтейнера

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

Ну вот он лежит, в Gentoo для него есть ebuild, который его собирает и устанавливает без проблем и адских риуталов с жертвоприношениями. В комплекте с ним идёт всего один патч, который чинит сборку пакета с GCC 9.

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

Т.е. udev там явно собран с поддержкой systemd и использует его библиотеку.

Во, значит, зависимости есть, но они опциональные, можно при сборке их отключить. Я верно вас понимаю? Если да - к чему приводит такое отключение? Какие фичи пропадут?

logind - отдельный случай. Его зависимость от systemd init связана с тем, что он помещает пользовательские сессии в свою cgroup.

Ага, вы - человек с техническим знанием вопроса. Это очень хорошо. Тогда вам сразу ещё пара вопросов:

1. Верно ли я понимаю, что sуstemd-shim, в частности, был призван именно логинд отвязать? Чем там был плох cgmanager, почему не взлетело?
2. Как я понимаю, список логиндом не ограничивался. Какие ещё компоненты пытались с помощью шима отодрать? Если такие компоненты есть (кроме логинда) - опишите плиз, почему они сейчас прибиты, и почему не удалась попытка их отодрать шимом.

В Debian нет никаких проблем с установкой и запуском udev без systemd init: https://ibb.co/BghLbzL.

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

Пишут, что upstart.

этот вынос будет всё равно чисто формальным, и всегда будет требоваться системд ровно той же версии

Так же, как и с udev, собранным с поддержкой systemd в systemd-дистрах вроде Ubuntu и Fedora, как мы уже выяснили. Rootlexx выше рассказал, почему так. Я об этом не знал (или забыл). Под наложением патчей я имел ввиду elogind — подозреваю, что там изменений относительно апстрима не так много, если дело действительно только в цгруппах.

Почему надо обновлять исходники удев и системд синхронно, а иначе - ошибка маинтейнера? Вы ж говорили, что они не связаны между собой никак?

Из «их можно использовать независимо» ещё не следует, что они никак не связаны. Живут в одном наборе исходников и могут использоваться вместе.

С какими инитами он потом будет безпроблемно работать в этой же генту

Раз работает с OpenRC — будет работать со всеми остальными. У него нет зависимости от systemd в этой версии, совсем.

будет ли работать с «не-родными» версиями системд

С systemd-профилем пакет sys-fs/udev заменяется пакетом sys-apps/systemd, т.е. они оба будут собираться и устанавливаться вместе, синхронно.

Во, значит, зависимости есть, но они опциональные, можно при сборке их отключить. Я верно вас понимаю? Если да - к чему приводит такое отключение? Какие фичи пропадут?

Всё верно, зависимость опциональная и отключается при сборке. Насчёт фич — точно не знаю. Свою основную задачу (т.е. управление устройствами) он выполняет точно так же. Могу лишь предположить, что сборка с libsystemd даёт возможность udev создавать юниты-устройства вида sys-devices-*.device в systemd, от которых потом могут зависеть другие юниты.

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

Коллега, я работаю в хелпдеске и постоянно занимаюсь всяким разным траблшутингом. Основная проблема поломавшегося чего-то - кривые руки одминов, либо ответственные за ОС системные одмины подкрутили что-то, а ответственные за приложения прикладные одмины не в курсе. Квалификация что первых, что вторых… Ну то такое… Более менее они в состоянии поддержать текущую работу, но не дай бог их попросить чего-то поменять, или скрипты на баше. И да, это не у нас, это глобально в мире так - арабы, индусы, негры… На лоре пишут вполне себе профессионалы, и это скорее исключение из правил. Такие вот одмины, которые мне пишут-звонят, у них зачастую даже профильного образования нет. Баш? Перл? Скрипты? Помилуй Бог, коллеги… Они с трудом понимают useradd, chown, chmod… Я уже не говорю за set get facl.

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

Дальше будет как на винде - сверху кнопки для эникеев, а всё остальное - под капотом, и нефиг туда лазить, если не знаешь. Линукс вырос из системы для программистов в систему для промышленного использования всеми (а идиотов, как известно, 95%).

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

Всё ИТ - это про бабло и бизнес. Если вам говорят про свободу, открытость или ещё что-то в этом духе - вас хотят поиметь. Причём безкоштовно (извините за украинизм, уж больно слово выпукло описывает картину).

Я лично не против, чтобы меня имели, но я это понимаю во-первых, и отдаюсь только за нормальные деньги во-вторых.

Так же, как и с udev, собранным с поддержкой systemd в systemd-дистрах вроде Ubuntu и Fedora, как мы уже выяснили.

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

Под наложением патчей я имел ввиду elogind — подозреваю, что там изменений относительно апстрима не так много, если дело действительно только в цгруппах.

Вопрос ещё в том, кто этот «один процесс, могущий управлять сигруппами». У него обязательно должен быть ПИД1, или нет? Если не обязательно, то я перестаю понимать объяснение Rootlexx об его связи с системд - сам бы и управлял себе сигруппами. Если же ПИД1 - обязательное требование, то перестаю понимать ваше объяснение про elogind.

Могу лишь предположить, что сборка с libsystemd даёт возможность udev создавать юниты-устройства вида sys-devices-*.device в systemd, от которых потом могут зависеть другие юниты.

Ну окей, хоккей. Если всё так, то давайте уже разбираться с логиндом и шимом (какие ещё компоненты он отдирал?), так как с удевом ситуацию вы прояснили достаточно подробно. А давно ли в удеве появилась эта магическая опция сборки, помогающая ему отдельно жить? Я к тому, это что вообще - разрабы системд решили ослабить клещи, или же всегда так было, а мы, сирые, даже не знали? :)

Подписываюсь под каждым словом. Сам наелся этого говна, пока в хелпдеске работал.

а что за генераторы?

https://www.freedesktop.org/software/systemd/man/systemd.generator.html

как ты их используешь?

Для динамической генерации юнитов получаемых после парсинга конфига другого сервиса.

Генераторы давно уже активно используются в дистрах на базе systemd, если что - точки монтирования из fstab сейчас динамически конвертируются в mount’ы для systemd, как пример.