systemd, for when you want to show support for the famous UNIX mantra of “do many things and do them terribly”

systemd is the node_modules directory of Linux init

@thomasfuchs The init system component of systemd is only one component out of a suite. Systemd also includes an event logger, a login manager, a simple network interface manager, a temp file manager, a daemon that manages time related settings, a device manager, a standard library to access the device manager and a boot manager.

@Lofenyy If there were a 'systemd stable', which didn't change too much (mainly bugfixes) [and Lennart could play with a 'systemd sid' experimental branch and add all of his new ideas and extensions there], and was actually minimal (say, init+daemon-manager), then (a) it wouldn't be too bad, and (b) other people could build interoperable components, so the line of 'systemd things are actually separate components' would be reasonable. As it is, systemd might as well be one big binary blob.

@thomasfuchs
@Lofenyy I know. That's why I said 'might as well be'. Functionally, it doesn't currently interoperate with non-systemd alternative components. Thus why I say 'might as well be'.

@thomasfuchs

@emacsomancer @thomasfuchs There's a huge difference between a monolithic, huge binary blob and a free software project consisting of modular components.

If, say, a journaling daemon isn't designed to interface with systemd, then it obviously wont work. Just because you can't install Google Chrome extensions on Firefox doesn't mean that you can't install any addons in Firefox.

@Lofenyy Ok 'binary' blob was perhaps unfair. Change it to 'open source' blob. Because the components are only modular in theory and not in practice.

> If, say, a journaling daemon isn't designed to interface with systemd, then it obviously wont work.

Right, but that was nearly the entire point of my first message on the topic. systemd isn't stable enough for anyone to bother trying to design tools to replace/interoperate with other systemd components. you can read on elogind to see how miserable even trivial things are to do to maintain compatibility with all of the other systemd components.

The Chrome/Firefox analogy is inapt. Or, at least the proper framing wouldn't be that you can't install Google Chrome extensions on Firefox, but it would be as if nobody except Google could practically write Google Chrome extensions because the interface between the extensions and Google Chrome constantly changed.

@thomasfuchs

@emacsomancer @thomasfuchs If systend isn't on par with your standards, then don't use it. Not using it has always been an option.

@Lofenyy The issue is its widespread adoption, which makes it hard to avoid. Again, if it were more flexible and less brittle, its ubiquity would be less of an issue.

@thomasfuchs

@emacsomancer if that’s the case then glibc, efi, libinput, wayland are even bigger issue than systemd but they don’t get near as much attention.

Before wide‑spread of systemd Eelco Dolstra (Nix(OS) creator) *chose* systemd as init cuz he could focus on more important things than maintaining hand‑written arbitrary init scripts.

Distro maintainers choose maintained inits, service managers and supervision services cuz that’s less work for them hence wide-spread adoption.

@thomasfuchs @Lofenyy

@kmicu glibc, efi, and wayland (and I don't have any well-considered thoughts on libinput) are not fully unproblematic either, but they are different from systemd (and each other) in a number of ways.

One important difference of these from systemd: especially glibc and efi (and to a lesser extent, wayland) are not as user-facing as systemd. I've run both musl libc systems and used efi, and these don't affect user-experience in the same way as systemd does. Ubuntu, to their credit, I think try to do as much as possible to shield the user from direct systemd interaction. Wayland I suppose is more user-facing (in practice my watch is my only device running wayland) but if it works well, users shouldn't really know the difference. But too much of what I use depends on X, so I don't see myself switching to wayland any time in the next five years.

Perhaps a bigger difference is this: glibc is an implementation of C (& C++) libraries. the glibc project didn't decide to also start handling python and racket libraries and make existing python & racket libraries incompatible with a system using glibc for c libraries. Wayland hasn't decided to take over the management of printers. systemd has done the equivalents.

Poettering is also quite clear in his non-interest in portability or even compatibility with other Linux native components. This leads to a certain fragility of the implementation as well: as I said, I've run a musl libc system, and the two things that essentially won't work with musl because they have a hard dependency on glibc are (a) proprietary software, and (b) systemd.


@Lofenyy @thomasfuchs
@kmicu Addendum: also the common rhetorical technique of contrasting systemd with arbitrary hand-written init scripts as if there were no other init/daemon-management system is wearying. 'What? You don't like Ford-brand cars? You must want to go back to horse-and-buggies."

@Lofenyy @thomasfuchs

@emacsomancer
Well what we have besides systemd? s6 suit used by Obarun and immediately patched cuz it’s difficult to use?
sysvinit, upstart, launchd, sinit?
Are those solutions anywhere near modern, robust and maintained software with clear separation of init, service management and supervision? Are those not sets of arbitrary design decisions?
I’m happy so hear about modern init suites but from my research they are all ad‑hoc ‘garbage’ (including systemd).

@thomasfuchs @Lofenyy

@kmicu s6 seems interesting - my sense is that it is (in theory) sort of like a minimal version of systemd. but I haven't used it other than just playing with it briefly in obarun.

runit and shepherd (two you didn't mention) I have used extensively, but both have been pleasant to work with for the most part and reliable.

@Lofenyy @thomasfuchs

@emacsomancer heh, be careful. Shepherd (dmd) was inspired by systemd so transitively you like new concepts brought by systemd. 😺

@thomasfuchs @Lofenyy

@kmicu But, again, I don't dislike the core of systemd itself necessarily, or some of its concepts. I've pointed repeatedly to what I consider its problematic properties. If systemd confined itself to init (well, and sorted out its slow boot and shutdown times) and daemon-management, I really wouldn't mind it. There are good ideas in systemd, they're just mixed in with a bunch of not so good ones - and even this isn't really what bothers me. It's the move-fast-and-break-things philosophy of the project, and the inability of its project leaders to care about things beyond their own visions of how systems should function.

@Lofenyy @thomasfuchs

@emacsomancer
Healthy and reasonable criticism is ok. A crusade full of vitriol and shallow slogans is what I see in most vocal anti‑systemd folks (I am not talking about you here).

My main distro doesn’t even have systemd but who cares? Do we spend majority of our time in init, supervision and system management to complain about init so much?

Someone has a better idea then *do* it!

@thomasfuchs @Lofenyy

@kmicu Yes, I agree that most of the anti-systemd stuff is pretty substanceless. And ridiculous things like sending Poettering death threats &c.

> Do we spend majority of our time in init, supervision and system management to complain about init so much?

No, but there's the issue of systemd mission-creep, and that's mainly my issue with it.

Again, why I think a default systemd-minimal wouldn't be so bad, if it were under different management.

@Lofenyy @thomasfuchs

@emacsomancer systemd is not a community‑driven project. Devs take money to fulfill Red Hat’s requirements first.

Distro maintainers have a choice: maintain and integrate other inits or use corporate‑driven init.

Alas the latter one is naturally less work cuz indirectly paid devs maintain part of your distro (and bring more features for free as in beer).

@thomasfuchs @Lofenyy

@kmicu But there's a cost. Now your desktop distro is filled with features desired by various corporate interests. Sometimes these may align with goals and desires of desktop users, or people running their own server somewhere, but I am dubious that the majority of these will align in the long-term with user-interests. I don't see the macOS model, even as free software, as aligned with my interests.

@Lofenyy @thomasfuchs
Follow

@emacsomancer Sure thing. That’s why I avoid corporation‑driven projects when I can. Corporation needs come always first.

And now Microsoft et al is in The Linux Foundation sponsoring more and more projects aligned with their needs.

That’s why folks fixated on systemd miss the point.
The whole stack is more and more about Big Corp and hostile to ‘commons’.

We need to create what we want. Demanding stuff from them is waste of time.

@thomasfuchs @Lofenyy

@kmicu This sentiment I can get behind.

And I think some of the most interesting things right now are being done in community-driven distros, e.g. Guix, Void, Bedrock. (and, of course, there are long-running community-driven projects like TeX, Emacs).

@Lofenyy @thomasfuchs

@emacsomancer meanwhile Mozilla added DRM to Firefox, Google put it in Chromium, Collabora added it to Weston (the reference implementation for Wayland), nVidia keeps GPUs encrypted, Intel defines Linux’s new wireless stack, Broadcom and Qualcomm keeps wifi/BT proprietary, Apple decides how printing stack looks like, … [listing many more essential projects pushed by corporations], … and after all of that the biggest topic is not ideal init cuz it has technical issues 🤦

@thomasfuchs @Lofenyy

@kmicu Well, you don't have to use DRM in Firefox. I didn't know that it was put into Weston though :( We can avoid nVidia GPUs to a certain extent, and use Atheros wireless. But I take the point in any event.

I still don't like the domain creep of systemd though, especially combined with its inflexibility.

@Lofenyy @thomasfuchs

@emacsomancer FYI Atheros was bought by Qualcomm and there’s no libre wifi/bt cards on the market anymore. The last one with libre firmware is from ~2010 iirc.

There’s much more examples just Mastodon limits me to 500 characters and I don’t want to spam poor folks CC’d below
xD They had enough already.

@thomasfuchs @Lofenyy

@kmicu @emacsomancer @thomasfuchs Atheros is definitely owned by Qualcomm.

Also, yes. Please stop CCing me. :cate:

Sign in to participate in the conversation
Mastodon

Server run by the main developers of the project 🐘 It is not focused on any particular niche interest - everyone is welcome as long as you follow our code of conduct!