Email or username:

Password:

Forgot your password?
Top-level
Ariadne Conill 🐰

there are of course, valid criticisms of systemd. the fact that so much userspace surface is contained in a single project is unpleasant from a technical and governance POV.

however, systemd itself is highly modular. the core service management framework is only a few megabytes on disk, which is comparable to openrc.

so the people who complain about bloat are likely just not using a properly packaged form of systemd…

12 comments
Howard Chu @ Symas

@ariadne modularity of some chunks of code is kind of moot when such fundamental parts of the kernel interface (eg. udev) no longer work standalone.

Ariadne Conill 🐰

@hyc you can build and deploy udev without the rest of the systemd components

Howard Chu @ Symas

@ariadne you can? hadn't seen anyone do that ever since it got absorbed as systemd-udevd.

Ariadne Conill 🐰

@hyc yes, alpine has considered doing it over eudev

Space Hobo Actual

@ariadne
Me, an intellectual: uses an OS built around busybox, and eschews an init system that combines too many systems into a single runtime.

Ariadne Conill 🐰

@spacehobo but systemd doesn’t actually do that. its a monorepo, but it generates tons of binaries.

Space Hobo Actual

@ariadne Yeah, I was hoping to wave hands a little wider than I did with the word "runtime", really.

Laurent Bercot

@ariadne The granularity of binaries on disk is a very partial indication of the modularity of the software. systemd has good granularity, but it is NOT modular.

Modularity, or lack of, is a property of the *design* and architecture of the software. When I say "systemd is not modular", I mean that its architecture is hostile, it centralizes control and disempowers users.

When I look at one part of systemd, say, one given binary, say I want to replace it: can I do it with knowledge that is purely local to this binary? And the answer is no: the necessary knowledge is still the full
global workings of systemd.

Another example is the sd_notify mechanism, which assumes that the fd you send the notification to (via an overengineered, bloated protocol) is a socket. This assumption means that the only way to implement readiness notification management in systemd is to have a central supervisor for all the services, which is the exact opposite of modularity.

@ariadne The granularity of binaries on disk is a very partial indication of the modularity of the software. systemd has good granularity, but it is NOT modular.

Modularity, or lack of, is a property of the *design* and architecture of the software. When I say "systemd is not modular", I mean that its architecture is hostile, it centralizes control and disempowers users.

Lennart Poettering

@ska @ariadne OK, I did not expect to read that today: that sd_notify() is "over-engineered" and "bloated".

It's *literally* a frickin env-var-like text string in a datagram to an AF_UNIX socket whose path is passed in an env var.

I mean, I can explain the protocol this in a single (one!) sentence.

If that's "bloated", then I think you are smoking some really really really good dope, man. No shame in that, but maybe don't comment on the Internet when you do ;-)

Ariadne Conill 🐰

@ska i don’t think your sd_notify example holds. a child supervisor could hoist the socket along to its parent to solve this problem using SCM_RIGHTS.

Erin 💽✨

@ariadne @ska also i dont’ see why it has to be a central daemon; each supervisor can just listen on whatever socket it wants and set NOTIFY_SOCKET appopriately.

jade

@ska

> This assumption means that the only way to implement readiness notification management in systemd is to have a central supervisor for all the services, which is the exact opposite of modularity.

Just set NOTIFY_SOCKET to the socket implementing the trivial protocol, which can be named at random? There is no reason this protocol is at all incompatible with multiple decentralized managers? You just run a socket on each?

I can't understand the problem here.

Go Up