таться пере

если нет устоявшегося стандарта

абсолютно бесполезно

писать свою альтернативу

это не очевидно для тебя ? Systemd изначально создан для того чтобы исключить любые альтернативы. Когда предполагаются альтернативы идут совсем другим путем

http://wayland.freedesktop.org

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

большинство пунктов - развенчания той тонны флуда что наср"ли системдфаги.

Большинство пунктов - банальное передёргивание, нагон эмоций или враньё/неосведомлённость с повторением стандартных мифов.

Например про бинарность логов и невозможность их чтения стандартными утилитами (читается через strings file | less)

Или перечисление всех компонентов systemd с хихиками вроде «зачем системе инициализации настройка сети и всё это в ПИД1, МЫВСЕУМРЁМ», абсолютно игнорирующие тот факт, что это отдельный компонент, который запилили для небольших систем, где нужна полная конфигурялка. Приравнивается весь набор компонентов systemd к монолитной системе, забывая что ни один из них не является обязательным к применению. Ну или хихоньки-хахоньки про поддержку генерации дефолных настроек при опустошённом /etc/.

По второй ссылке берутся как раз нетехнически пункты срачей и радостно развенчиваются.

1. suckless.org/sucks/systemd

What PID 1 Should Do
To see what are the only tasks the application running as pid 1 has to do, see sinit. Just wait for child process to reap and run some other init scripts.

Ну и почему, собственно, это верно? Напоминает религиоидную хероту: это истина, потому что мы так сказали. Не обосновано => фтопку.

logid should wait:
Systemd was introduced to decrease the boot up time. Now that they do not understand all implications and dependencies, let us add some artifical time we found out might work for the developers laptops.

Если чо, «some artificial time» — это статус-кво. Раньше на говнотаймаутах было всё. Теперь только то, где без этого не обойтись.

screen brightness:

Screen brightness is something that should crash your boot up when it is not working.

that should crash your boot up

4.2, wants != requires

hostnamed:

There really should be a process running which exposes the content of a file.

4.2, не только «exposes the content of a file». Но, даже если бы это было верно, такой подход хорош тем, что позволяет навешивать обработчики, хуки и дополнительную обработку событий смены хостнейма. Абстракция, инкапсуляция, интерфейсы — не, не слышали?

seqnum removed:
The sequential ordering of requests was one reason why udevd was introduced. Now remove it, because the developer laptops do not have a problem anymore.

Чо-то какой-то non sequitur лютый. Был seqnum, стала другая абстракция, более хорошая. А автором подразумевается, что просто выкинули API.

floppy group removed:
Because we know what is right to know about groups. This is just one example of the mass of group name dependencies systemd is adding.

Автору стоит научиться изъясняться яснее. Количество разных групп сократилось, потому что floppy объединили с disk, а он пишет про «group name dependencies systemd is adding».

sysv removed:
We have won. Now remove all remains of our defeated enemy as fast as we can. As said in the beginning of the systemd crusade against the UNIX infidels: »You can patch it out.« It is no more there.

Вот это просто лютейшее 4.2 и передёргивание, ибо в оригинале сказано:

... The support for SysV <...> has been removed from the systemd daemon itself. Instead, it is now implemented as a generator ...

abnormal processes:
Now systemd is getting deep into philosophy. What is »abnormal«? Well, let us just define it. There is no technical merit to accept this.

Здесь автор просто толсто троллит, надеясь на недалёкость хейтеров, ибо в мане ясно сказано, что значит «abnormal».

Что характерно, насчёт недалёкости хейтеров автор явно угадал — досюда, по ходу, никто не дочитывал :]

systemd-resolved:
Every configuration file needs its own process and service.
Symlinks are a good way to solve all world problems.

А то, что resolved — ещё и кэширующий ресолвер, автору невдомёк? Наезд на симлинки также совершенно не понятен.

new is better:
The systemd development process is flawed by always assuming »new is best«.
Network configuration should be in my init process.

Здесь явно не хватает чуть более развёрнутого обоснования того, почему «new is best» — неправильный принцип. Алсо, как уже отметили, автор опять толсто троллит, утверждая, что конфигурирование сети осуществляется в процессе инита.

remote pid 1:
»Everything will end up having a remote API.« I wonder when systemd will understand MIME and e-mail.

Да, will end up having a remote API, и это хорошо (впрочем, админам локалхоста не понять). И опять детские передёргивания.

init does man:
My init process is too big, it needs its own file hierarchy and an abstraction layer to find paths.

Опять 4.2, ибо ничего из этого, кроме описания интерфейсных файловых систем, не имеет отношения к PID 1.

Welcome to the Windows OEM world: Factory reset for Linux! Of course it is in your init process.

4.2.

system runs runs:
Exactly. The predisposition of being able to call such a complex command does not imply the running system. Let’s check it again.

На этом месте кончились последние попытки родить внятные претензии и начались ничем не прикрытые банальные придирки к словам.

1a. suckless.org/sucks/systemd, pt. 2

clean up directories:
There is another monster in systemd, it handles tmp files. There are just some cases before it was introduced to have to clean up a directory in the file tree. Now there are hundreds. And easily another case can be added! Of course your init process does that.

Нет, не «не было необходимости», а просто всем было пофиг на мусор в файловой системе. Кроме того, из всех правил tmpfiles на моей системе именно очисткой занимается от силы десять правил. Остальные — это удаление старых файлов в /var/tmp, восстановление прав доступа к файлам и так далее.

И попробуйте только сказать, что это не нужно делать.

firstboot:
»Interactive queries« pulls in many dependencies. Let us have it in every installation out there on by default. Of course in pid 1.

$ ldd /bin/systemd-firstboot 
	linux-vdso.so.1 (0x00007ffc94396000)
	librt.so.1 => /usr/lib/librt.so.1 (0x00007f8755811000)
	libcrypt.so.1 => /usr/lib/libcrypt.so.1 (0x00007f87555d9000)
	libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007f87553bc000)
	libc.so.6 => /usr/lib/libc.so.6 (0x00007f8755018000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f8755a19000)

Про «in pid 1» уже даже ничего не говорю.

journald:
This is a bit longer. Because the systemd developers were not able to contribute to any syslog daemon they had to write their own with some binary format so the principle of being able to read your log files after a critical crash was violated. To be nice invaders the old systems were allowed to order the system log through the specified mechanism. Now that they implemented our specifics, turn off the neutral syslog delivery. You will see this pattern of »now that we conquered your culture, obey« more often in systemd.

«the principle of being able to read your log files after a critical crash was violated» — 4.2.
«turn off the neutral syslog delivery» — 4.2, включить обратно не составляет проблем.
Остальное — сопли и нетехническое нытьё.

systemd-terminal:
Why does the kernel have tty handling? So in serious situations you will be able to debug it over the last standing PIN on your motherboard. Let us remove this, run it in pid 1.

Автор путает VT и TTY. Ладно, простим ему эту некомпетентность, на фоне остальных вопиющих лаж эта уже не так страшна. И, опять же, «in pid 1».

networkd is your oppressor:
Premature optimisation of IP configurations always leads to misery.

Хренасе у автора зрение избирательное. Не заметить в двух строчках словосочетания «when enabled» — это нужно постараться.

We do not understand broadcast:
With the growth of systemd in complexity and the new depending software the implications of the added hacks are increasing.

По ссылке хак, стыренный из какого-то prior art DHCP-клиента и добавленный в networkd в результате багрепорта. Но нет, автор же знает лучше.

Timezone hack:
Systemd is too complex for such a simple transaction with the kernel. Do not inform the kernel and add another assumption which is only documented in the changelog.

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

the web is a session:
For the future generations: In 2015 nearly everyone was trying to connect all you do to the web. In the UNIX model it is just a client which should be simple and integrate into the system. Systemd is doing it the other way around and does integrate itself into the web.
The discussion about why my pid 1 is handling sessions is discussed in other points.

Класс, мы начали придираться к формулировкам названий констант в коде. Опять же, «pid 1».

pid 1 does DNS

«pid 1»

policykit:
There is a bus inside your pid 1 and if it crashes you are flawed. Exactly, there are a thousand more cases of errors that could occur and make your system unbootable. Instead of using a separation of functions, add everything to a big bus.
Of course when you are using a misdesign like dbus you need to add interactions over the bus to add features you forgot in the initial design. Now let us have our pid 1 have to query for the permission to boot.

«pid 1»

Calendar:
As you see, your pid 1 should handle your calendars and cron jobs too.

Да, таймер — это тоже форма запуска задач.

utmp should go:
We have taken over your culture, now die! Another flaw in the systemd small world theory: When something is getting optional it will be removed.

Нетехническое нытьё.

password agent:
»Interactive authentication«

Да, и что?

udev timeout:
Instead of patching the kernel to add a simple solution, add a hack. Only the systemd developers tell you when it is allowed to wait or sleep in userspace. The rest obey our orders!

Автору было бы полезно рассказать поподробнее, что он понимает под «patching the kernel».

systemd-pm:
Power management is required on boot up.

Ссылка ведёт на запись о поддержке восстановления из гибернации. Автору можно посоветовать проспаться и протрезветь.

user systemd units:
What can go wrong when you are adding more paths that are read, parsed and executed?

Действительно, what can go wrong?

hack the reload:
First systemd was adding »better features« like socket activation to make developers use their mechanism for daemons. They hit the proprietary wall of disgust with this changelog entry. Systemd is too big and you will lose your face if you change the misdesign. Now add another hack because we can do it. Big empires fall too and sadly have too many casualties when they are falling. :(

Здесь автор просто пишет красивыми словами нерелевантную чушь. Литературный талант проснулся, не иначе.

X11 in systemd:
Of course graphics were missing in pid 1.

Какое детское и наивное передёргивание.

complexity is purity:
You will of course need PPPoE when you do parallel bootup. Every 1000 lines of code add one critical bug you never fix.

Автор, видимо, опять подразумевает, что systemd-networkd == PID 1.

gateway hostname:
We rule the world so we are above IETF and IANA. Now add our own hostnames that of course won’t add another assumption.

Согласен, стоило заюзать какой-нибудь заведомо несуществующий tld.

no editor in systemd:
This one is a setback. Why is there no default editor in systemd in case of factory reset?

Затраллел, ничего не скажешь.

8x ctrl + alt + del:
In systemd you press eight times Ctrl+Alt+Del to trigger reboot.

7x.

privacy policy:
For the next generations: In 2015 privacy was a big issue because of the mentioned hard-wiring between the web and software. As you can see, every commit which adds some preparation for a feature adds another intepretation of what will be a major assumption in a next release. If you handle privacy you will have some features depending on that user decision and of course the factory reset default value.
Why didn’t they use XML for /etc/os-release?

Опять же, затраллел.

fds cache:
We have talked about misdesign, too-big-to-fail and world domination. This is the next example of a hack that is prone to fail.

Автор где-то увидел хак в возможности не закрывать файловые дескрипторы во время рестарта демона. Где он его увидел? Разъясните мне.

umount -rf:
This is umount for dummies. Just do one thing – right.

Как будто что-то плохое?

libudev will be orphaned:
With the advent of udevd there was a compatibility to its complexity called libudev. X11 uses it to query the changing devices. And of course make it a non-independent API in systemd. Why? You can guess why: Defeating the infidels.

А по-моему, однообразие интерфейсов — это хорошо.

1c. suckless.org/sucks/systemd, pt. 3

fsck indirections:
When there was syslog fsck did output errors to your display as easy as possible. Now add a hack to have this possible again.

Товарищ просто не в курсе, видимо, что это про вывод прогресса fsck на сплеши.

systemd-importd:
This is pure evil. Your pid 1 is now able to import complete system images over the network and show them to you as your running system. There is nothing that can go wrong.

«pid 1»

CGI for systemd:
The web thing has been discussed before.

В оригинале:

When systemd forks off a new per-connection service instance it will now set the $REMOTE_ADDR environment variable to the remote IP address, and $REMOTE_PORT environment variable to the remote IP port. This behaviour is similar to the corresponding environment variables defined by CGI.

kdbus:
As of 2015-07-31 kdbus is not in the mainline Linux kernel. Systemd made kdbus non-optional in its release. The kernel maintainers are still debating the kdbus ABI or possible alternatives, but if systemd depends on the current state of kdbus the kernel maintainers are faced with the hard decision to either break Fedora userspace or accept the current kdbus proposal into the kernel with its security and maintainability issues. This is the best example how systemd is forcing you into decisions. Of course if you are a mindless bureaucrat it helps you to keep your job.

Шапочку из фольги пусть не забудет надеть.

readahead removed:
The first thing swallowed in on Fedora was readahead. Now that (of course!) everyone is using an SSD (at least the developers of systemd do that) it can be removed. Why was it there? Is it possible to make it a separate tool again? There’s no time for that, we are implementing new features.

Они ничего никому не обязаны поддерживать вечно. readahead — это не API, а отсутствие фичи лучше присутствия глючной фичи.

А как у тебя пускаются контейнеры докера при старте системы если ты используешь sysv? Как рестартишь контейнер, неужели через docker stop/docker run?

Ты не поверишь, но у меня нет никакого докера вообще. Он мне нафиг не упёрся.

Может расскажешь какие задачи выполняют твои тыщи бездисковых серваков на слаке? А то БД у тебя нет, грузятся все они с одного диска, балансеров нет, приложений в контейнерах нет, о каких-то демонах ты упоминал, но не сказал о каких, данных нет. Может у тебя mpi какой, расчеты с отсылкой данных в институтский кластер? Интересно. Это я безотносительно к systemd спрашиваю, а вообще.

Может расскажешь какие задачи выполняют твои тыщи бездисковых серваков на слаке? А то БД у тебя нет, грузятся все они с одного диска, балансеров нет, приложений в контейнерах нет, о каких-то демонах ты упоминал, но не сказал о каких, данных нет. Может у тебя mpi какой, расчеты с отсылкой данных в институтский кластер? Интересно. Это я безотносительно к systemd спрашиваю, а вообще.

Я провайдер.

Я провайдер.

Ага, это все объясняет. Вам бы тогда какой-нибудь cumulus linux юзать, вообще зашибись будет. И дебиан, и sysv. Шикарный дистрибутив!

У тебя, наверное, могут быть претензии к systemd. Но не все провайдеры, чувак.

У тебя, наверное, могут быть претензии к systemd.

Не «могут быть» а есть.

Но не все провайдеры, чувак.

Разумеется. И есть ещё масса всяких областей человеческой деятельности в сфере IT, где systemd совершенно неуместен.

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

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

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

ого, совпадение. Знакомый пров в городе тоже использует слаку.

Да не будет его везде, если он везде не будет нужен. Я согласен с тем, что во многих областях он даже вреден. Но для подавляющего большинства пользователей таких дистрибутив, как Debian и RHEL он подходит.

Вот вы провайдеры уже же объединились и запилили cumulus и свичи 40gb/s на которые ставится линукс. И ембедщики себе запилили.

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

А так по большому счету по-барабану какая система инициализации — sysv, systemd, upstart. Сделать всего лишь три пакета(все-равно для разных релизов разные репы держать) со скриптом, юнитом, конфигом, который притягивает нужное приложение и все. Собирать и деплоить естественно не руками все это дело приходится — есть TeamCity и Bamboo. Ну, это у нас так. У кого-то может быть по другому. Батхерта по поводу СПО не понимаю.

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

Но для подавляющего большинства пользователей таких дистрибутив, как Debian и RHEL он подходит.

А почему вы смеете за них решать? Давайте тогда и мы за вас решим что всем любителям systemd необходима живительная эфтаназия!

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

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

Как бы ни было смешно, но именно линукс может оказаться первой в мире ОС, в которой невозможно запустить самостоятельно скомпилированную программу. Даже какой-нибудь Symbian с его подписями и сертификатами покажется свободнейшей ОС.

Ахтунг! Илитка в треде!

Ну правильно, педиковатый петух intelfx же сказал что «linux is not about choice». Они видать так решили в своем кружке членососов. Сосут друг у друга и принимают решения как и что будет в linux.

Пацаны сосите друг у друга болты и хвалите в интернете systemd! Systemd выбор геев! LGBT CHOICE SYSTEMD

Вы таки небыдло?

О. А 200 (такой скромный парк, в самый раз для стартапа) серверов ты будешь лично по ssh настраивать?

Я таки не задумывался над этим вопросом.

Это смеют решать девелоперы вышеупомянутых дистрибутивов.

Зачем? Как уже сказали выше, диск в каждой машине — излишество. Как там в systemd с отделяемым /usr?

7x.

да ты сам походу не читаешь, в ченджлоге черным по белому - more than 7x, т.е. 8x

Как там в systemd с отделяемым /usr?

Прекрасно, а что?

у меня под /usr не только отдельный раздел, но ещё и отдельный subvol, и всё прекрасно.

По остальным пунктам возражения будут? :]

И initrd не нужен? А то, что юниты идут в /usr/lib/systemd, а значит, нужен initrd с оными. Вывод — нормально не умеет.

С какой радости initramfs — это не «нормально»?

Тащемта, initramfs — это по ряду причин правильная современная замена минимальной-системе-на-/. Поэтому у systemd с отделяемым /usr всё как раз хорошо. Нехорошо у тех, кто по каким-то причинам избегает initramfs.

Initrd удобен когда в ядре нет модулей для дискового контроллера и нужных файловых систем. В хорошо отлаженной системе initrd нафиг не нужен — он только замедляет процесс загрузки, не давая существенных профитов.

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

Во-вторых, разговор исходно был про /usr отдельным разделом. Посмотрим на проблемы в этом контексте. «Этот контекст» означает, что мы должны как-то суметь примонтировать /usr, довольствуясь только тем, что _не_ на /usr. В случае initramfs — это те программы, которые ты сам лично положил в initramfs. В случае без initramfs нам нужно иметь минимальный набор программ на корневой ФС (/), который будет искать и монтировать /usr.

Проблема в том, что юзкейсы очень разные, и одному нужно просто смонтировать /usr с соседнего раздела, а второму — подрубиться по iSCSI к удалённому серверу с зашифрованным образом и смонтировать его через dm-crypt, получив пассфразу с USB-токена (пример взят из головы). В случае initramfs ты можешь легко положить туда любой набор программ, который нужен тебе (и не более того). В случае отсутствия initramfs ты довольствуешься тем, какие программы твой дистрибутив собирает с prefix=/. В зависимости от твоего юзкейса, тебе придётся либо тащить в / лишнее, либо пересобрать нужный софт с другим префиксом.

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

Ну, ок, в зависимости от юзкейса:) И да, сборка софта с нужным префиксом — это задача майнтайнера. А он может и не захотеть собирать программу как надо. И я не говорил про абсолютную ненужность initrd. А что, fsck на корне в read-only плох? А на случай аварии всегда можно держать initrd, который бы монтировался инитом только в случае появления проблем. И это не костыль, а совершенно нормальная ситуация.

Зачем, тебе тыщу раз все разжевали, а ты до сих пор повторяешь одну и ту же мантру

Как самоуверенно.

Там, вообще-то, сильно больше одной мантры — аж в одно сообщение не влезло, и в два тоже. Давай, «разжуй мне всё» ещё раз, ну или хотя бы ссылку дай.

Ваня, 19-и летний (мну навёл справки в vk) фанатик с горящими глазами... лет через десять, когда пройдёт острая форма юношеского фанатизма, ты это нам сам разжуёшь.

а значит, нужен initrd

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

Ты не меня обсирай, а по теме скажи что-нибудь :]

IOW, argumentum ad hominem.

Херня это все.

У меня кластер Оракловый - каждая нода поднимается порядка 5 минут. Плюс сервера с Оракловыми апсами. Все под Красношапкой.

И тут внимание вопрос бд не поднялась (по разным причинам) и это дрочево по имени системд пытается стартовать аппсы снова и снова - накуя!!! Что он от этого поднимется? И как мне дебаг провести если система на 100 процентов занята дрочением системд?

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

Как только это говно появится в реальном продакшене а не в тестовой красношапке - переведу все бд и апсы на соляру

И тут внимание вопрос бд не поднялась (по разным причинам) и это дрочево по имени системд пытается стартовать аппсы снова и снова - накуя!!!

Это ты теоретизируешь? Или реальная ситуация? Юниты под аппсы сам писал? А саппорт Оракла что говорит? На самом деле, у systemd такого поведения по-умолчанию нет, он не рестартует упавшие сервисы автоматом. То есть, либы ты что-то реально накосорезил в системе, либо разводишь пустой базар.

переведу все бд и апсы на соляру

Ну-ну, давай, ты с systemd, который тупой как дверь, справиться не можешь, я посмотрю какие у тебя SMF будет фортеля выкидывать. А если ты будешь Оракл в зонах гонять (а гонять Соляру на голом железе дураков мало, ибо переводняк ресурсов), то затрахаешься в SR-ах с индусами переругиваться.

Все бегут нахер с этой соляры куда попало, а ты наоборот будешь.

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

Если уж на то пошло, есть подход к файловой системе гораздо красивее обоих:

http://sta.li/filesystem

Нужно только его принять как новую версию FHS и чтобы на него все перешли.

Переместить всё в /, а не в /usr — это было бы лучше, да. Но и в такой иерархии initramfs всё равно будет необходим, поэтому я прошу разъяснить, что значит «красивее обоих»?

«красивее обоих»

Это и значит

Но и в такой иерархии initramfs всё равно будет необходим

Ну это конечно проблема, но что поделаешь.

Сложно придумать архитектуру, где без него можно обойтись, если используются нетривиальные вещи типа lvm, luks и тд

Только вот, для каждого дистрибутива, а иногда и для каждой версии, init-скрипт нужно писать заново\исправлять, иначе не заработает. А в systemd должно быть универсально для всех дистрибутивов (к сожалению, тут стоит помнить, что в разных дистрибутивах могут быть разные пути к бинарникам и файлам конфигурации, так что этот подход слабо работает).

Нефкурил что тут универсального. Для каждого дистрибутива, для каждой версии, юнит надо заново писать, да ещё и зависимости юнитов отслеживать, что совсем уж западло.

Ну, я же сделал оговорку, что, к сожалению, это не совсем так. Хотя, с другой стороны, я свободно взял несколько юнитов из gentoo\arch wiki, и они стали работать без допиливания в fedora. Вот если бы пакеты опакечивали везде стандартно, не меняя путей...

PS. Ещё относительно systemd у меня в последнее время появились претензии относительно странной системы эскейпинга путей в юнитах, где '/' меняется на '-', а всё остальное на '\x??' - очень по-марсиански. И система override параметров юнитов, где чтобы переопределить опцию стандартного юнита, нужно сначала её обнулить, а потом задать заново. Очень интересно было бы узнать, почему сделано так неочевидно, а не иначе.

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

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

посмотрите какие чудовищные и нелогичные зависимости в systemd-based дистрибутивах

Например?

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

Примеры повсюду:
udev прибит к systemd
Gnome прибит к systemd
NetworkManager прибит к kdm,xdm,litedm
KDE прибит к lvm
Да ещё и тенденция делать дистрибутивы «коробочными»

Был бы у разработчиков шанс сделать инит-скрипт, положить его в исходники и использовать везде, то они бы это делали.

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

NetworkManager прибит к kdm,xdm,litedm

Это в каком дистрибутиве такие ужасы?