systemd
you have almost certainly used systemd yourself. even if you haven’t, you depend on indirectly just by visiting tilde.club, or indeed almost any webpage on the net. unless you have been living under a rock since 2010, you are probably aware that systemd has sparked both evangelists and haters. in this blog post, i will explain why i dont use systemd where i can.
feature creep
what even is systemd today? is an init system (yes)? is it a service manager (yes)? is it PID 1 (yes)? is it a linux distro (yes, particle os)? systemd tries to do too much. so much of the modern linux is built on systemd, for example timedatectl, or logind. this violates the unix philosophy of doing one thing well. even the name of systemd fancies itself a place at the heart of the system: systemd, for system daemon. systemd does not play nice with other pieces of software that intend to replace parts of it.
hard dependencies
when systemd does things in an atypical manner, projects are left to either cater to both systemd and traditional approaches, or to pick one. and since systemd is always getting more popular, maintainers tend to opt to hard depend on systemd, take GNOME. this reduces portability to non-linux systems (think bsd), which will only hurt users and maintainers who are forced to juggle ever-more patches. this in turn reduces the market share of the bsds and their ilk, which again encourages monoculture.
dangers of monoculture
monocultures do not change, as they have no incentive to do so. instead of prioritising making the software work everywhere, even with the strangest workflows, they try to force their opinions on how software should be used upon us. GNOME has a reputation for this kind of behaviour. when they started to hard-depend on systemd, they simply advised distros not using systemd to “use systemd”! what kind of advice is that! monocultures preserve certain workflows and use cases over other, equally valid ones.
no alternative
as systemd becomes more and more popular, it becomes the only real solution. sure, alternatives like openrc or runit exist, but almost all major linux distros have switched to systemd. in my opinion, having only one piece of software that fulfills a given position is a danger in itself. what if it has a vulnerability? what if you don’t like the way its designed? what if you don’t like the development direction? linux is defined by the freedom to choose, and systemd’s creep is (not intentionally of course) taking this away. almost every piece of foss software can be swapped out with another, be it the kernel (bsds), the window system, the DE, your IDE, your browser, or your shell. yet systemd is reducing the viability of alternative init systems. large projects like gnome should not depend on another large projects (bar where obviously necessary, like x11/wayland).
strange configuration
why does systemd install services in /usr/lib, not /etc/init.d or /etc/inittab like other init systems? this is a nitpick, but its still important - sysadmins spend much of their time editing these files. the systemd configuration is strange and arcane.
how to combat this?
use alternative systems like openrc + openrc-init/sysvinit or runit. use distros with the freedom to choose, like parabola, or artix. or use a system with a stronger init system, like bsd (my personal favourite is openbsd).