Person: Systemd bad
Me: why
Them: IDK
The argument is basically that it does too much and as the motto of Unix was basically “make it do 1 thing and that very well”, systemd goes against that idea.
You might think it is silly because what is the issue with it doing many things. Arguably, it harms customization and adaptability, as you can’t run only 2/3 of systemd with 1/3 being replaced with that super specific optimisation for your specific use case. Additional, again arguably, it apparently makes it harder to make it secure as it has a bigger attack surface.
Sustemd is modular though, you don’t have to use every subsystem. The base init system and service manager is very comprehensive for sure.
Then again, it doing all those things can lead to those parts working together better because it’s the one project instead of a dozen different projects with every distro having a different mix.
And funnily enough, the kernel doesn’t follow the unix philosophy either as far as I know.
I have heard that before in a joke setting, I would love to hear genuine arguments for and against it.
Problem is, nobody’s alternative solves all of the problems people wanted their init system to solve. sysvinit didn’t solve booting/service supervision well, so it’s hard to say it was really a UNIX philosophy solution, and it wasn’t even part of the OG Unix system but came over a decade later in 1981 with AT&T’s system iii (later included in system v, hence the name sysvinit). There’s nothing sysvinit does well. The most popular services and distributions had simply thrown away so many hours of time and effort bashing their heads against sysvinit’s limitations that they had managed to make them work, but that’s different from the system overall working well.
Anyways, people don’t like Poettering, but he made inroads with systemd in large part because he actively took notes on what people wanted, and then delivered. He’s an unlikable prick, but he delivered a product it was hard for many projects to say no to. That’s why project after project adopted it. It solved problems that needed solving. This counts for more than adherence to an archaic design philosophy from the 70’s most people don’t follow anyways and which the predecessor wasn’t even a good exemplar of anyways.
You can in fact run 2/3 Systemd whatever that means. Systemd components are modular so you can run the base system by itself if you want to.
Additionally systemd just works. You really don’t need to care about the details as running something like a web server or service is as simple as starting it. Dependencies are handled automatically.
More like it’s bad because of architecturial decisions (integrated init system; system state managemt in the same package as init and supervision), creating lots of unneeded complexity, number of CVE’s, how the developers behave (or don’t), and that you can’t have other init systems in the same repo without a fuckton of shims and wrappers.
Sounds like valid concerns to me.
That’s the problem with how most things Lennart designs are. They are typically 70-80 percent excellent ideas brilliantly architected, 10-20 percent decisions that we can agree to disagree on but well designed still, and ~10 percent horrifically bad ideas that he is unable to receive criticism on because of his standing, terrible attitude and ~90 percent good and acceptable ideas.
Another problem is that they all seem to be designed in a way that they are the One True Way to do something and are designed to choke out any alternatives because Lennart Knows Best.
I’m still ambivalent about having this much extra logic and complexity attached to my init system but the ship sailed long ago and I’m well into making lemonade at this point.
I been told it was to big, but if you look at the Linux Kernel, it is huge.
People also love to say Unix, but Linux is not Unix.
Fine then: “Linux is not Unix, Xerxes!”
Imagine a very irate spartan shouting it as he hurls his spear across the room where the lawyers are having their discussion about the lawsuit pending between the linux loving spartans and the tyrannical unix using persians.
In fairness reading this thread all I see is systemd good
Why: i find sysvinit start up scripts too complicated to read/modify so let’s drop this gigantic mammoth that does a million other things on my lunux system so I don’t gave to learn how to write a shell script.
I don’t have much skin in the game and have been out of the loop for many years but don’t find many of the arguments in favour of systemd very convincing
Poettering and Systemd are amazing and Linux would not be as good as it is today without them. Whether you like it or not, we can’t have a fragmented ecosystem and expect people and companies to adopt it (see the 14 competing standards XKCD). Having one solid base that works the same on every client is like literally the base requirement for making a product for the said client. Systemd, flatpak, xdg-portals, pipewire and immutable distros all solve this.
Here’s my hot take: I don’t care what operating system most people use. If people are happy on Windows, let them stay on Windows. That’s not my problem. When you say we need to make Linux less diverse and interesting to make number go up because more biggerer number more gooderer then suddenly that is my problem. You are trying to make my experience worse for the sake of something I do not care about.
There is nothing wrong with systemd. Most people on Linux are using it, and that’s fine. Options are good too though. I specifically like Linux because it’s NOT a bunch of homogeneous lowest common denominator sameyness. That’s the very thing I don’t want.
To me systemd is fine, I am not really emotional at init systems. But on the other hand Linux is about choice and systemd kills that in some way because it does so much more than just starting services. GNOME is unusable without systemd, which makes it a no choice if you go into another rabbit hole. It’s kinda weird how deeply systemd is integrated in Linux these days. What I really dislike is that the log is in binary format by default which makes it necessary to deal with another tool to read logs. But well software changes, so do tools. But honestly the devs acted like dick heads sometimes, so I think most of the antipathy comes from their behavior and well yes MS now kinda pushing systemd because poettering works for them. I have fear that MS forces the systemd devs to implement things you cannot simply opt out of because it is so tightly integrated. Maybe copilot for writing systemd unit files would be nice though :P
well yes MS now kinda pushing systemd because poettering works for them. I have fear that MS forces the systemd devs to implement things you cannot simply opt out of because it is so tightly integrated.
How has MS pushed systemd?
I have fear that MS forces the systemd devs to implement things you cannot simply opt out of because it is so tightly integrated.
What the hell? Code isn’t unpatchable, and neither is Microsoft the super evil villain trying to ruin the lives of Linux users that childishly.
I’d like to propose a new rule for this community:
People criticizing systemd to the extent where they promote alternatives (regressions), have to provide proof that they have or are maintaining init scripts for at least ten services with satisfying the following conditions: said init scripts must 1.) be shown to reliably start up the services and 2.) not signal their dependencies to early and 3.) gracefully stop the services 99.9% of the time. People failing to satisfy these conditions are not allowed to voice their opinions on how arbitrary init systems are better than systemd. Violations of this rule will be punished by temporary bans and forcing the violators to fill the entire canvas of a blackboard with “‘do one thing and do it well’ is a unix principle, not a linux principle” in fine print.
More lines of semi-reliable init scripts have been written by package maintainers, than lines of systemd code by Poettering & Co, and that while achieving far less. The old init systems might have been simple, the hell of init scripts wasn’t.
That might have been true a decade ago. I don’t actually know. I do know that modern init scripts for modern alternatives to systemd are barely longer than systemd service scripts though. So that’s kind of an insane take.
can you give examples of some? Not trying to bd sarcastic, i do just want to see what alternatives are doing.
Sure, that seems pretty reasonable. Here’s the init script for sddm:
#!/usr/bin/openrc-run
supervisor=supervise-daemon
command="/usr/bin/sddm"
depend() {
need localmount
after bootmisc consolefont modules netmount
after ypbind autofs openvpn gpm lircmd
after quota keymaps
before alsasound
want logind
use xfs
provide xdm display-manager
}
That’s it. That’s the whole thing.
That’s a pretty simple one though, so here’s Alsa. It’s a more complex one:
code
#!/usr/bin/openrc-run
# Copyright 1999-2019 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2
alsastatedir=/var/lib/alsa
alsascrdir=/etc/alsa.d
alsahomedir=/run/alsasound
extra_commands="save restore"
depend() {
need localmount
after bootmisc modules isapnp coldplug hotplug
}
restore() {
ebegin "Restoring Mixer Levels"
checkpath -q -d -m 0700 -o root:root ${alsahomedir} || return 1
if [ ! -r "${alsastatedir}/asound.state" ] ; then
ewarn "No mixer config in ${alsastatedir}/asound.state, you have to unmute your card!"
eend 0
return 0
fi
local cards="$(sed -n -e 's/^ *\([[:digit:]]*\) .*/\1/p' /proc/asound/cards)"
local CARDNUM
for cardnum in ${cards}; do
[ -e /dev/snd/controlC${cardnum} ] || sleep 2
[ -e /dev/snd/controlC${cardnum} ] || sleep 2
[ -e /dev/snd/controlC${cardnum} ] || sleep 2
[ -e /dev/snd/controlC${cardnum} ] || sleep 2
alsactl -E HOME="${alsahomedir}" -I -f "${alsastatedir}/asound.state" restore ${cardnum} \
|| ewarn "Errors while restoring defaults, ignoring"
done
for ossfile in "${alsastatedir}"/oss/card*_pcm* ; do
[ -e "${ossfile}" ] || continue
# We use cat because I'm not sure if cp works properly on /proc
local procfile=${ossfile##${alsastatedir}/oss}
procfile="$(echo "${procfile}" | sed -e 's,_,/,g')"
if [ -e /proc/asound/"${procfile}"/oss ] ; then
cat "${ossfile}" > /proc/asound/"${procfile}"/oss
fi
done
eend 0
}
save() {
ebegin "Storing ALSA Mixer Levels"
checkpath -q -d -m 0700 -o root:root ${alsahomedir} || return 1
mkdir -p "${alsastatedir}"
if ! alsactl -E HOME="${alsahomedir}" -f "${alsastatedir}/asound.state" store; then
eerror "Error saving levels."
eend 1
return 1
fi
for ossfile in /proc/asound/card*/pcm*/oss; do
[ -e "${ossfile}" ] || continue
local device=${ossfile##/proc/asound/} ; device=${device%%/oss}
device="$(echo "${device}" | sed -e 's,/,_,g')"
mkdir -p "${alsastatedir}/oss/"
cp "${ossfile}" "${alsastatedir}/oss/${device}"
done
eend 0
}
start() {
if [ "${RESTORE_ON_START}" = "yes" ]; then
restore
fi
return 0
}
stop() {
if [ "${SAVE_ON_STOP}" = "yes" ]; then
save
fi
return 0
}
That’s definitely longer than a systemd service, but you’d have to write an awful lot of them to be more code than all of systemd. Overall the entire /etc/init.d folder on my PC where all the init scripts even for the stuff I’m not using are stored is a grand total of 147.7 KiB. Not exactly an unmanageable amount of code, in my humble opinion.
Luddites were champions of the working class and have been smeared by capitalist for over a century. I’d be proud to be called a Luddite.
(In before history nerds um, actually me: chill…I know)
The luddites were right though, technology was being used to lessen their quality of life and make them dependent on a new set of structures that they weren’t familiar with and which were failing them on a massive scale…
I feel like the people who complain about systemd have never tried to mess with sysVinit scripts before
6+ years ago, I was trying to configure a touchscreen HAT for a raspberry pi, and dicking with the init.rc script was a massive pain
The alternatives to systemd isn’t init.d or some other legacy init systems. I use runit, pretty easy to understand and use. Stop being lazy dude
Or dinit. dinit is awesome. s6 defeated me; an init system shouldn’t be that complex.
systemd has a lot of nice features, esp. in the area of dependencies and triggers. But it infects everything it touches, is enormous, and is buggy.
Frankly, I’m waiting for the PipeWire successor to systemd. Like systemd, Pulseaudio was everywhere by the time enough people realized how bad it really was and someone wrote a well-designed, well-written replacement. ALSA has problems that Pulseaudio fixed, but with a badly written solution; then a good software developer came up with a good solution that solves the same problems but isn’t just a giant hacky hot mess and now PA is slowly being replaced everywhere. Given that the same person, of questionable skill, who wrote PA also wrote systemd, I fully expect a better-designed solution to replace systemd.
S6 isn’t it. dinit is close, but has some holes that need addressing before it could succeed systemd, and I think it won’t be it; I think systemd’s successor hasn’t been written yet, but I have confidence it will be.
