Comment by dijit
3 months ago
the dismissal of systemd criticisms by saying they’re unimportant (for you) or that admins are living in the past has got to be one of the most annoying things about the topic. It devolves into a flamewar because of it, since nobody can actually engage constructively once that happens.
I’ve laid my actual criticisms bare multiple times on this site.
1) The tight coupling of the userland with systemd means that while systemd replaced a pleathora of inits (not just sysv): the target is now too large to be replaced even if there are better ones. Systemd is the last init linux will have, and increases the barrier to port software to other unix-likes.
2) The non-optional/default features have been buggy and difficult to replace. Journald has no replacement; systemd-networkd is one of the most common causes of failure for my desktop due in part to being flakey when dnssec is not available.
3) The overreliance on dbus turns the “the unix philosophy” ;) away. Text as a universal communication medium, everything is a file, etc.
There are more, but these are my main ones. Throwing away the corpus of admin muscle memory is not an an issue anymore.
To be blunt, I was using Fedora when systemd was coming out, I know how it works intimately because it was constantly broken. Part of what gives me pause is that I know how utterly undebugabble it is when it fails: it just hits those causes less frequently as the world is forced into using it. It becomes battle hardened.
Oh, and the obvious criticism agains the maintainers who have been very unapologetic to bugs and undesired behaviour, in a much worse way than the Apple “you’re holding it wrong”.
Did you ever consider that it’s also free software nerds who are the most likely to hate being told what to do?
> 3) The overreliance on dbus turns the “the unix philosophy” ;) away. Text as a universal communication medium, everything is a file, etc.
have you considered the reality that the "unix philosophy" results in incredibly brittle systems? byte streams ("""plain text""") are untyped and prone to mishaps.
Some of the most reliable systems in the world were unix ones.
SunOS was famous for being incredibly reliable, and its a more pure unix than the current linux environment.
And even if we ignore that, the majority of the web was functioning and functionally reliable atop linux with these text stream systems.
bytestreams are less debuggable, which feels silly to say openly since we are all aware that higher level interpreted languages are easier to write/debug/test and iterate on, but we seem not to be bothered by this not being true for the underlying systems.
Systemd clearly is working though, I’m just levying a criticism of opacity.
> bytestreams are less debuggable
Text streams are considered "better", because the standard UNIX userland (unlike e.g. DOS) provided excellent tools for dealing with text streams: grep, sed, awk, find, tr, etc and of course the shell itself.
But once you get your hands on excellent tools (like jq) for dealing with other kinds of data (like JSON), it turns out everything is even more powerful - you can now work with JSON as easily as with text, it just plugs into the existing ecosystem. But even though JSON has a human-readable text representation, it is no longer just text - it is dynamically-structured, but strongly-typed data. A JSON array is a JSON array, you can't just awk it.
There are byte stream formats (e.g. msgpack) that have feature parity with JSON. jq can't accept msgpack-encoded byte streams, but suppose a hypothetical tool, msgpack2json, is widely available - just plug it into jq. You're still working on the same level of abstraction (shell pipes), but easily dealing with complex byte streams.
And of course, what we understand as "text" in the modern era, are UTF8-encoded byte streams. If your "text" kit deals with ASCII rather than Unicode runes, it's that much less powerful, and likely full of painful edge cases that you now have to debug. (Note that UTF is a 1992 thing, it's been invented when UNIX was 20-something yro, and it's been around for 30+ years.)
Debuggability of anything is entirely up to your toolkit, the quality and comprehensiveness of that toolkit is what decides the battle.
I don't think the most reliable systems in the world were Unix ones. At least, if you compare systems at that time, you should compare with what the telephone operators were using. They had legal requirements you would not find in the computing world.
> 3) The overreliance on dbus turns the “the unix philosophy” ;) away. Text as a universal communication medium, everything is a file, etc
I prefer an introspectable, typed, and efficient communication protocol over streaming text because of the "Unix philosophy" whatever that may be.
Is the philosophy documented somewhere or is it just in our hearts? Because the Systemd Bus interface has great docs right here: https://www.freedesktop.org/software/systemd/man/latest/org....
> “ Write programs that handle text streams, because that is a universal interface.”
—Douglas McIlroy
Its difficult to pinpoint a single origin of “everything is a file”, but its referenced in Kernighans memoirs, which is a good read: https://www.cs.princeton.edu/~bwk/memoir.html
Yeah, such a tool will be definitely stable and portable! Until you change the locale and the whole thing breaks apart, with no error message whatsoever..
Also, not even Linux believed in "everything is a file". Everything is either a file or a stream. The two is not the same.
1 reply →
> systemd-networkd is one of the most common causes of failure for my desktop due in part to being flakey when dnssec is not available.
While I have nothing to say about your general points - I am pretty neutral to systemd, but I really dislike how it makes porting software to BSDs harder - I have one question:
Why are you not using networkmanager on a desktop computer? I have only used networkd on a server where I needed things like MAC matching and device renaming.
Genuinely curious. On my desktop I used a wired connection, so NM is probably overkill, but I like how I can have a tray icon to manage my VPN and wireguard connections.
I typically use what's provided by my distro, because in my experience from Fedora (heh), fighting the distro is a surefire path for pain.
Even arch has opinions, even if they're much happier to mute them in the name of choice, but it's clear that your life is better if you stick to the happy path.
Which distro uses systemd-networkd as standard? I am genuinely curious. I could see using it on a server, but not on anything desktopy.
"To be blunt, I was using Fedora when systemd was coming out, I know how it works intimately because it was constantly broken. Part of what gives me pause is that I know how utterly undebugabble it is when it fails: it just hits those causes less frequently as the world is forced into using it. It becomes battle hardened."
One of the foundations of Fedora is to be "first" and to integrate big changes like systemd before other distros. Things will break if you do that.
The point is that I have experienced how it fails when it does, not that it fails.
All software fails, which is why it’s important that I can debug/fix it when it fails.
That’s my point, I could fix what came before.
Yeah, it is harder to fix completely new unknown stuff. Big surprise!
1 reply →
In these comments I have so far seen "resistance to change from dusty admins older than tape drive mainframes," "it is religious," and "autism."
Without replying to specific parts, I'd like to point out that you and others bring up parallels between Systemd and closed source proprietary software shops like Apple and Windows. I view this as bad faith because Systemd should be afforded the kindness (and obviously has the user freedoms) of a fully open source work.
There's nothing apple-esque about any of this. 'If you're unhappy fork it', is a common adage that is definitely applicable here.
> Systemd should be afforded the kindness (and obviously has the user freedoms) of a fully open source work.
You cannot fork systemd in practice; it's enormous, and its components are tightly coupled with complex, non-stable interfaces between them. So while you have access to the source code, you do not have the practical ability to exercise the FSF's four freedoms.
GNU/Linux was created as a rewrite of Unix not because Unix was the best operating system around, but because it was a design that could be replaced, changed, and improved piecemeal. GNU were able to write improved open-source versions of the components of a Unix system - such as init - piece by piece, and test them out and use them on existing Unix systems, rather than having to rewrite everything before they could do anything. If those older Unix systems had been designed like Systemd, that would not have been possible, and Linux would never have got off the ground.
This doesn't track with me at all: Nothing about the four freedoms is restricted by systemd's architecture, it's all open source. You're comparing with an effort to replace a proprietary system. And secondly, the variations between different UNIX systems in terms of compatibility were much greater in practice than the variety in systemd interfaces between different components (which aren't that tightly integrated, anyway. Systemd-networkd, for example, is basically just another systemd service, and has multiple replacements. Same with basically everything else. And even the things that aren't 'officially replaceable' are still just as amenable to piecemeal replacement as the UNIX utilities: there are various projects that do, if they object to systemd's core for whatever reason).
I think the main reason that there isn't a systemd fork is that it's just not particularly worth it: it works well enough for enough people that no-one is motivated enough to try to improve on it outside what the project is doing anyway. And those that do strongly object to it tend to reject the whole approach and so they start from scratch, and then lack traction because they don't interoperate at all.
1 reply →
> GNU/Linux was created as a rewrite of Unix
GNU is a bunch of utilities no different than various terminal programs. The attempt at the "GNU OS" failed because the Hurd was never really usable.
2 replies →
It's more like Chromium; you could fork it, but it's big enough that that's difficult, and doesn't really do anything about its influence on the ecosystem.
A browser is quite literally the most complex project out there - systemd is absolutely tiny compared to it, so I don't think that would make a fair comparison, at all.
Except for the fact that chromium is a feeder project for a proprietary closed source work and so often bends to the will of that project.
Morally there's no equivalence here.
> Systemd is the last init linux will have, and increases the barrier to port software to other unix-likes.
Why would you write portable software that has a dependency on an init system?
> systemd-networkd is one of the most common causes of failure for my desktop
What is objectively worse than buggy networking in systemd is having 26 different incompatible ways to configure networking in Linux.
It is easier to settle on one method (like literally every other OS) and fix the bugs than continually come up with newer, equally buggy and broken, ways of doing it.
> Why would you write portable software that has a dependency on an init system?
Ask the GNOME project.
> What is objectively worse than buggy networking in systemd is having 26 different incompatible ways to configure networking in Linux.
"Linux has 26 different incompatible ways to configure networking. Systemd solves this problem by introducing a 27th way that's buggier than most of the others"???
> What is objectively worse than buggy networking in systemd is having 26 different incompatible ways to configure networking in Linux.
False.
One of those 26 incompatible ways works just fine in the situation where systemd is clearly not working.
It is only your opinion that it is better to have "buggy" networking than to have "not buggy" networking that you think is difficult to configure. That is the exact opposite of "objectively."
> It is only your opinion that it is better to have "buggy" networking than to have "not buggy" networking that you think is difficult to configure. That is the exact opposite of "objectively."
I never said this.
Fix the bugs. Don't fill the well with yet another equally shite solution.
2 replies →
> Why would you write portable software that has a dependency on an init system?
Because it's not just an init system; it manages to make itself important to a rather lot of the system. A nice page is https://wiki.gentoo.org/wiki/Hard_dependencies_on_systemd#Pa...
Nothing in there looks particularly big or important, though. There was a lot of noise about GNOME and mutter requiring it, but that has been changed as noted on that page. Dbus is a big one, but a) the socket activation feature of it requires integration with or reimplementation of a service system, and b) There is an implementation that works with openRC instead (just not the one mentioned on that page).
1 reply →
Well, as far as your first point goes: Systemd has been a suite of tools instead of just an init system for a while now.
The Linux kernel is de facto pretty tightly coupled with GNU stuff, but you don't get irate about that, so why does Systemd deserve your ire?
> The Linux kernel is de facto pretty tightly coupled with GNU stuff
No it isn't, or Android, Alpine Linux, and Chimera Linux wouldn't work nearly as well as they do.
> you don't get irate about that, so why does Systemd deserve your ire?
And even if it were, systemd has a lot of problems that the classic GNU utils don't. We don't hate systemd just because of the tight coupling.
> The Linux kernel is de facto pretty tightly coupled with GNU stuff
No it isn't. They go to great lengths to e.g. make sure they can be built with clang and not just gcc. And in the other direction, prior to systemd you could even swap out Linux on Debian for a different kernel.
> The Linux kernel is de facto pretty tightly coupled with GNU stuff,
It's really not; Linux is fine with ex. Alpine or Android userspace, and builds with clang.
> but you don't get irate about that,
Er, I mostly certainly do object strongly to the GNU monoculture too.
> To be blunt, I was using Fedora when systemd was coming out, I know how it works intimately because it was constantly broken
This was Fedora 15, in 2011. I would say using this as a baseline qualifies as living in the past?
A mere dozen years. Kids nowadays, the attention span of a fruit fly...
it was more about how my muscle memory has evolved, that I know how it works and the benfits of it- not that I think systemd is the same as it was back then; clearly not as I mentioned things that are <5 years old.
> Systemd is the last init linux will have
I'm fine with that.
> and increases the barrier to port software to other unix-likes.
Don't care about "other Unix-likes", and in fact I wish they didn't exist.
> The non-optional/default features have been buggy and difficult to replace.
Let's not pretend as if the pre-systemd crap wasn't even more buggy.
> The overreliance on dbus turns the “the unix philosophy” ;) away. Text as a universal communication medium, everything is a file, etc.
Dbus is a text-based protocol based on files though. What a silly complaint.
P.S. Dbus sucks, but thankfully it would be pretty easy to replace in systemd if somebody got sick enough of dbus.
So you don't care about anyone else. How noble. Why then should anyone care about you or your opinions or deep thoughts?
They're not the one whining about how systemd's stolen the "good old days".
As they say: working code or gtfo. Complaining about someone else's software project is so passé. No-one's forcing anyone to use systemd, Linux, or a computer.
3 replies →
When comparing systemd to things, I find it more fruitful to compare it to something like SMF, which actually does the things people wanted systemd to do:
* socket activation
* dependency management of startup
* log control
* service supervision.
Except, it did so by interfacing with the operating system in its native language, for example: log files were text.
It is not useful to complain about bash scripts, the original design of init was indeed dated and you’d be hard pressed to find people who don’t think so; so its an invalid point to make in this discussion.
If SMF was any good we'd be actually using it instead of systemd.
1 reply →
>Don't care about "other Unix-likes", and in fact I wish they didn't exist.
Why?
They only bring harm to the world.
2 replies →