Hacker News Reader

Comment by bee_rider | Hacker News Reader

I've been generally OK with systemd, and think most of the complaints about it were over-dramatic, but this is exactly one of the things we were warned about, right?

View on HN

systemd-as-SysV-init replacement was fine. It's all the other stuff that many people think is overkill: udevd being pulled in, journald, time sync, file system mounting, network management, etc.

And all are in one repo with tight coupling.

For an "init system".

systemd is like that non-lazy guy we were warned about:

I distinguish four types. There are clever, hardworking, stupid, and lazy officers. Usually two characteristics are combined. Some are clever and hardworking; their place is the General Staff. The next ones are stupid and lazy; they make up 90 percent of every army and are suited to routine duties. Anyone who is both clever and lazy is qualified for the highest leadership duties, because he possesses the mental clarity and strength of nerve necessary for difficult decisions. One must beware of anyone who is both stupid and hardworking; he must not be entrusted with any responsibility because he will always only cause damage.

https://en.wikipedia.org/wiki/Kurt_von_Hammerstein-Equord

Even if you stripped systemd down to the "as-SysV-init replacement" part it still wouldn't run on FreeBSD, because systemd uses cgroups for that.

It sounds like systemd wants to be an OS kernel.

No, it wants to be 90% of the OS except the kernel (the other 10% is libc and a package manager).

But systemd was never just an init system. AFAIK, systemd has always been advertised as a system and service manager for Linux. With that in mind it makes perfect sense that systemd manages what it does.

Whether or not such an architecture is desirable is debatable, but the portrayal of systemd as just an init system is a fundamental misunderstanding of what systemd is.

> With that in mind it makes perfect sense that systemd manages what it does.

It made perfect sense to pull in udevd, which had existed externally for a long time, and tightly couple it so that it can no longer be used independently? (The Gentoo folks forked eudevd.)

People keep saying it's tightly coupled, but never supply any proof for that. You can still run udev without systemd, the NTP stuff is completely optional and in separate binaries and the same is true for the network management stuff. The journal is indeed required, but any traditional syslog daemon still works, and you can trivially disable the persistent journal (I even believe that's the default on Debian).

Please checkout the progression of Devuan if you are wanting to understand just how viral systemd is in modern linux. If it wasn't so tightly coupled, why did it take 2 years to decouple it?

https://sysdfree.wordpress.com/2017/08/16/112/

https://nosystemd.org/

First of all, Devuan wants to get rid of any and all systemd code. This includes for example libsystemd-daemon0, which is a tiny library that implements the stable notification protocol and is a no-op on systems not running systemd. You can reimplement it yourself in pretty much any language, but lots of programs just link against the systemd library because it's easier and has no tangible downside, even for people not running systemd. Eliminating such dependencies isn't particulary hard but takes a lot of work. Likewise, the rest of the world has left SysV init scripts behind, so they have to write those too.

The second reason is that systemd provides features for which there simply is no alternative. Desktop environments are entangled with logind, because it's the only software providing that functionality. Before logind they had a hard dependency on ConsoleKit, which was pretty much abandoned. Reimplementing all these features takes time.

If you are referring to the lack tight coupling being the ability to remove journald, time sync, etc, then you are correct. I should have been more clear I was talking about systemd as a whole, and not just those other subsystems, but I'll assume you meant the latter, in which case, yeah, it's possible to stop using lots of the systemd subsystems without too much pain (which I have done quite frequently, and found great stability improvements.) To be frank, I just really don't like the handwaiving away of valid criticisms people have (on any topic), with such dismissive language as "People keep saying ... but never supply any proof for that." This to me reeks of intellectual dishonesty, but again, that was my response because I probably misunderstood you to say that about systemd as a whole instead of how you meant it which was focused on gp's comment about subsystems.

One note: many people pretend sysv init has been dead and left behind, but I've seen production systems in major places still using it (not just embedded either). It's not nearly as dead as people might like to think.

Suppose I want to write my own competitor to systemd-resolvd. I want it to work with systemd-networkd, in the same way as systemd-resolvd does. Or just patch dnsmasq or unbound to be able to do that. Is there a stable interface for that? An RFC I can read? Any guarantee they won't change the interface and break my version, while they update both of theirs together?

> Any guarantee they won't change the interface and break my version, while they update both of theirs together?

No, I think you can guarantee that the interface will change at some point.

Judging from the manpage and a quick look at the code, the only thing for which systemd-networkd and systemd-resolved interact is to get the DNS servers pushed over DHCP, which it does over the D-Bus interface that falls under the interface stability promise[1].

[1] https://systemd.io/PORTABILITY_AND_STABILITY/

That is not the only thing for which they interact, see e.g. systemd.network(5). The systemd-resolved.service itself reads the systemd.network config files. This is what people mean by tightly coupled. But more importantly, you're telling me what it does currently, not what it's going to do tomorrow.

Suppose it did currently only interact through a stable D-Bus interface. What stops them from adding some new interaction and supplementing or replacing the existing one with it? You're left with a guarantee that systemd-resolved will continue to support the old API that systemd-networkd may stop using.

> you can trivially disable the persistent journal (I even believe that's the default on Debian)

The persistent journal is enabled by default in Debian testing.

systemd provides process and resource isolation. You can either have something comparable with everything or something the uses specific features of the kernel. You just can't have it all.

Reply on news.ycombinator.com