Comment by serbuvlad
3 months ago
I think this is as good a time as any to reread "The Rise of Worse is Better".
https://www.dreamsongs.com/RiseOfWorseIsBetter.html
The article compares the Unix/C philosophy with the Lisp philosophy and concludes that Lisp is "better" (it is The Right Thing), but that Unix/C will probably end up dominating. Obviously, he was right.
The article is pretty famous around the suckless, minimalist, crowd. But I think everyone who reads it takes a slightly wrong lesson from that article. The point isn't that Unix/C won because it was simple. The point is that Unix/C was simple enough to use, simple enough to implement on most available hardware and that it did everything you needed it to do.
The minimalist people have turned software simplicity into the modern version of The Right Thing, and are surprised when they found out that the "worse" (more complex) thing wins. But The Right Thing will never win. The Good Enough always wins.
Is Linux better than *BSD? Well *BSDs are more simple, easier to understand and reason about etc. But, at least OpenBSD, doesn't have mount --bind, so I can't use it. Case closed. And I think that's the case for most people. Linux has thing X which I need so I will use Linux, even if ideologically *BSD is imo better.
Is D-Bus The Right Thing? No; but it is The Good Enough. polkit, selinux, ACLs, and so on.
The most recent example I can think of is Hyprland. It is basically the only viable Wayland window manager (aside from sway). Not because it is the best designed or the simplest, or anything like that. But simply because it is the only one Good Enough to use.
SystemV init was not good enough for complex service management. systemd is. systemd simply does everything you need it to do well enough. So systemd wins. Simple as. It will only be replaced when it is no longer Good Enough.
Exactly, for some values of "good enough". (Unfortunately IMNSHO) Systemd cannot be toppled by all-out assault. It must be subverted. Looking forward to reimplementations and/or shims which provide the Systemd API but are reimplementations.
Something like Wine, where in the analogy systemd is the Microsoft Win32 API and we want to be able to run systemd "enabled" software on something else. Or at least re-compile it.
Wine also started with an incredible amount of stubs which did nothing, but that was often enough for many programs to work anyway.
> Looking forward to reimplementations and/or shims which provide the Systemd API but are reimplementations.
We've seen the launch of GNU's systemd equivalent, which seems to introduce more complexity to the simplest levels and is more difficult for users to understand and configure. Given that every service file is its own erlang program/DSL/whatever, understanding erlang is critical to being able to write or reason about service files.
In essence, it seems to be trying to re-implement what systemd does, but badly.
Reimplementing systemd's API but using other discrete components would also be a bad idea. The biggest reason systemd took off is that it's all the tools a system needs, built in a way that they work well together and can be interacted with and configured consistently. Providing systemd-compatible replacement shim APIs would mean trying to tie a dozen (or more) discrete OSS projects, each with their own philosophies, developers, licenses, goals, etc. together, generating their config files consistently, and trying to mush all that together in a way that doesn't make things vastly more complex than what systemd already provides.
In short: the reason systemd is successful is that it got rid of a giant mess of unrelated or overlapping services and replaced it with something simple, coherent, and functional, built out of components that you can (in most cases) choose to use or not. Most people who hate systemd seem to hate it for largely ideological reasons ("it's too big!") and are more interested in solving those ideological problems at the expense of practical solutions to real user issues. I've yet to see someone argue against systemd because it's bad for end users; only because they don't like the way that it provides benefits for users.
It could mean that, but it could start much simpler. Instead of trying to implement the whole API surface and behaviour, focus on a single consumer i.e. a single program which today depends on systemd.
Shim out enough for it to at least run in some capacity on something which does not have systemd.
Go from there.
6 replies →
Yeah. Exactly. It's also how Wayland and Pipewire managed to win: by being backwards compatible with X and Pulseaudio, while also overcoming their shortcomings.
The problem is that if the only complaint with systemd is that it's too complex, any backwards compatible alternative will necessarily be as complex as systemd + the new thing (at least in terms of complexity of interface).
If there are actual technical deficiencies of systemd, then sure, maybe such a backwards compatible alternative might be in order.
Also, everything expands in time. Wine may have started out with many stubs, but now we're at the point of implementing Windows-y APIs in the kernel with the sole goal of improving wine performance (NTSYNC).
> The problem is that if the only complaint with systemd is that it's too complex
As I understand it, that isn't the only, nor even the main, complaint with systemd. On the contrary, the main complaint with systemd is that, like strangler vine (kudzu?), it's spreading everywhere, taking over functions that it originally had nothing to do with, and forcing ever more unrelated things to adapt to systemd -- thereby making them much less portable away from systemd; to something that doesn't use it.
It's like the old debate about "BTW, you should call it GNU/Linux, because..." is sooo yesterday: Nowadays it's systemd/Linux -- and well on its way to becoming systemd-OS, with the kernel a mere afterthought, soon to be if not replaced at least easily replacable. Sure, that may not bother you or most systemd fans, but one can't help wonder: Do you even realise that this is what you're condoning, or even actively advocating? Maybe it would bother you, if you realised it.
(Also, the whole "strangler vine" thing, when deliberately applied, used to have a name: "Embrace, Extend, Extinguish". Now, I can't really swear that it is being deliberately applied here... But do we really dare to blithely assume it's just a coincidence that the creator of systemd so naturally found a home at the company the expression was coined for?)
Subversion is key. Remember when "performance" was the key reason for moving to systemd (scripts are sooo slow). To subvert, you need some lever and the chink in the armor to break in.
D-Bus is good enough for all sorts of things. But you absolutely don't need a behemoth like systemd to use D-Bus. A D-Bus communication option can be added to existing programs and utilities, or new ones could be fashioned for which it is a central mode of operation; and still there would have been no an ever-growing pile of centrally-maintained and inter-dependent artifacts.
As for SystemV... as I mentioned in another comment - in hindsight, that was not the issue. There were and are SystemV alternatives [1]. One can even write one that uses D-Bus in an opt-in fashion, to foster other facilities' use of it.
The init system excuse is very much like the stone in the fable of the stone soup: https://en.wikipedia.org/wiki/Stone_Soup - it's what gets the vagabond's foot in the door, and is the first ingredient for the soup. But actually, the stone carried no significance, and the resulting soup is pretty much the same thing as without the stone part.
[1] : ruint, OpenRC, launchd, s6, nosh, finit, procd, upstart etc. See brief description and links at https://alternativeto.net/software/sysvinit/ for example.
s/SystemV/sysvinit/
and one more thing about that: For PC users and "vanilla" machine setups - sysvinit, weirdly, still works fine. Startup is quick, and developers don't live in pain making it work. Of course it is kind of lame design-wise, but it's not even that we just _had_ to replace it - we've still not reached even that point.
> The most recent example I can think of is Hyprland. It is basically the only viable Wayland window manager (aside from sway). Not because it is the best designed or the simplest, or anything like that. But simply because it is the only one Good Enough to use.
I'd wager the vast majority of (non-embedded / single-purpose) Wayland deployments are gnome and KDE.
They might be Raspberry Pi which doesn't use gnome or kde! :-)
Obviously, but I'm talking about bare window managers, not DEs. Alternatives to i3, awesomewm etc. Different niche.
River is very good but a niche in a niche. Telling that ive been using hyprland though.
Part of the problem with all of them is less the wm and more knowing what parts you need. Not so much bars as portals. I'm vaguely surprised hyprland doesn't have a "good enough" batteries included config and documentation.
1 reply →
cosmic is going to be a great wayland windows manager.