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....
—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
Also, not even Linux believed in "everything is a file". Everything is either a file or a stream. The two is not the same.
If you disagree that text streams are a good universal medium then thats totally valid, but then perhaps don’t use a unix-like and go for something like VMS, VAX or Windows.
have you considered the reality that the "unix philosophy" results in incredibly brittle systems? byte streams ("""plain text""") are untyped and prone to mishaps.
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.
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.
There's nothing apple-esque about any of this. 'If you're unhappy fork it', is a common adage that is definitely applicable here.
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.
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.
Pre-systemd you could get Debian with Hurd and it was fine. There was never much reason to use it - hardware support was worse than Linux and there was no real killer feature in practice - but it worked.
No it didn't: GNU / Linux is a huge success.
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.
It's not modular and when other packages assume it's there it starts to become difficult to remove it. So where's the choice in that? This is just Linux becoming a corporate thing - going in whatever direction the big players want. When money is involved it seems to generate some quite dismissive attitudes.
On the good side, there are non commercial distros already with more than acceptable alternatives and I am using one of them now (with dinit - very nice). I'm not suffering. I have a distro that is far less complicated than Fedora and vastly easier to fit to my needs...and actually faster too. I hope we can avoid Linux becoming Windows or the Mac. Desktop domination is a silly goal - if it happened it would only result in a similarly locked down and unsatisfactory system without choice.
Morally there's no equivalence here.
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?
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.
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.
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.
This was Fedora 15, in 2011. I would say using this as a baseline qualifies as living in the past?
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.
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"???
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."
I never said this.
Fix the bugs. Don't fill the well with yet another equally shite solution.
> I never said this.
I know you didn't say it was your opinion. You said it was objectively worse. You said:
> What is objectively worse than buggy networking in systemd is having 26 different incompatible ways to configure networking in Linux.
and I think it's pretty clear people have experiences where systemd-network malfunctions in places where a rc.local (one of those 26 incompatible ways) works fine.
That is not objectively worse. So it's only your opinion.
> Fix the bugs.
You can fix your own bugs.
> Don't fill the well with yet another equally shite solution.
Do not confuse some fantasy future version of systemd that has had people like me work on it to make it better, despite its many many issues, with the rc.local script that exists today: Only one of these has a chance of existing.
Fascist
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...
Dbus itself is another questionable service IMO but it got baked in rather a long time ago and is harder to replace.
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.
* 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.
I’m also not saying we should have ported SMF, one complaint I have about it is that it was a product of its time and used XML (much like launchd on macos, which is actually another supervising init btw ;D).
However taking inspiration would have been good, instead of creating software that appears like it belongs on a Windows/DOS based operating system rather than a unix-like.
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.
What you right here just did, was exactly whining and complaining, except not even about anything that happened to you or that you have to deal with.
Why?
I hope you’re not actually responsible for anything.
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.
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.
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.
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.
Similarly on Windows, the trouble is never that windows is a new system, it’s that windows by default does not log when issues occur except in special cases, that everything is compiled and inscrutable.
Without pdbs (or equivalent) you literally could not debug issues, which was not the case with comparable inits (SMF) or what came before (bash scripts with various execution styles).
This is not the gotcha you seem to think, and I’m drunk at the moment and typing on a phone- so all I have to say is get over yourself and engage properly with what I’m saying instead of being defensive and flippant.
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?