Hacker News Reader

> 1. As the site says, systemd is both an init system and a collection of programs that make sense to have in a system. One can already strip most of everything from it (I think only journald is mandatory), and there is usually a stable api between every component, so one can simply replace them.

The only stable APIs in systemd are the ones that the whole agglomeration of programs provides to the outside world. Anything else can and will change and break without warning according to the systemd developers.

>3. I can agree with that. But it's not that sysinitv or upstart worked on non-linux systems (without ugly hacks)

Didn't matter, they had their own init systems and until systemd came along very little software depended on a particular init system.

> Gnome will depend on systemd when under wayland, that's instead a fact. Actually, on logind, which has an api that anyone can reimplemnt (https://blogs.gnome.org/ovitters/2013/09/25/gnome-and-logind...)

According to the chart someone else linked, which I think is by the systemd developers, logind cannot feasibly be reimplemented and the systemd version can't be used by anyone else: http://www.freedesktop.org/wiki/Software/systemd/InterfacePo... In practice, no-one has managed to reimplement anything beyond the most trivial APIs exposed by systemd. Some (like the whole new-style daemons API used by many daemons ported to systemd) literally cannot be implemented by init systems that aren't structured the same way as systemd.

> 11. Nobody is forcing anyone to adopt systemd. It's getting adopted because distributions and developers think it's better.

In at least some case, it's getting adopted because important software has been rewritten upstream to depend on systemd.

> logind cannot feasibly be reimplemented

I disagree that is what the chart shows. A bit later in the document they say

> If you decide to reimplement one of the APIs for which "Reimplementable independently" is "no", then we won't stop you, but you are on your own.

so I think they mean to say sth different than "the APIs can't be tried to be implemented at all".

I think when they say "reimplementable independently" they mean "to develop a feature-par system", which might be way too strict. For example, the unit format also is marked as "not reimplementable independently", when it is clear it is in some form; plausibly, some attributes one can specify in unit files as implemented by systemd can't be replicated in other systems, but that doesn't mean there can't be similar, partially-compatible implementations. I guess in some (most?) cases, those might be enough.

Also, logind's case might be marked as not reimplementable independently to discourage forks like Ubuntu's, which caused their version to remain stagnant when the API changed upstream. I'm not sure, but logind's API might still be a moving target, so a reimplementation might have to face some issues.

> 4. And? I'm not sure what's the problem here. udev and dbus are mandatory by pretty much anything that's not a .sh script nowadays.

I don't know that this was the author's original meaning, but I think the much bigger problem is that udev and (k)dbus have become dependent on systemd. This has caused headaches for the Buildroot team with udev, for example:

http://lists.busybox.net/pipermail/buildroot/2013-March/0681...

How do systemd's proponents respond to these problems? GKH will say "just use mdev":

https://plus.google.com/111049168280159033135/posts/R387kQb1... (conversation about halfway down)

And if you need udev's features after all? "If you disagree with the current developers about decisions like this, then fork. And be prepared to handle the fallout." As in, be prepared for endless public derision by Lennart, GKH, Koen Kooi, and everyone else involved with systemd, as was directed toward everyone working on the eudev fork just for daring to make a version of udev that was no longer tied into systemd.

The author of "boycott systemd" complains that it is "heavily desktop-oriented". I actually like systemd, but this is a legitimate concern for a huge number of embedded Linux users, especially as systemd continues to assimilate peripheral projects. The concern is made much more severe by the confrontational and childish attitude adopted by systemd's developers and lead promoters in such matters.

I agree with you. The whole "movement" against systemd seems to be "this is very different than the way we used to do things!" Of course it is; computing has changed a lot in the last 30 years since sysvinit was designed. We now care about things like power management, hot-plug devices, etc. and the only way to ensure a consistent method of handling them is to have a single control point. The kernel is also a single point of failure by necessity; so it's well audited and a lot of work goes into making sure it is rock-solid. Because systemd is now the de-facto heir to sysvinit due to its inclusion in almost every major distro, I suspect it will get the same level of care and oversight.

A lot of these complaints boil down to the fact that systemd is a single point of control for a lot of different functions. IMO systemd actually reduces overall system complexity by creating a unified interface for launching any sort of automated executables.

6. is a big deal for me. 9 CVE since 2011? that's crazy in combination of "single point of failure".

Yeah, but keep in mind that:

1. It now has a lot more attention focused on it, so it will get more scrutiny.

2. Unix admins have always been wary of the bleeding edge; distros are adopting systemd today, but those distros themselves are unlikely to see wide production adoption for a year or two.

3. If the systemd team's processes are not up to snuff, a major distro will fork it and run it themselves. If the criticisms have any merit, others will follow. It's why open source is such a great model for critical system software: it's as pure of a meritocratic model as you can get (well, if you accept the fact that merit is based on adoption.)

Basically, any new critical unix process is going to have these types of issues. The fact that systemd has a lot of support basically ensures it will get a lot of attention and bugs/security holes will be fixed.

Still, the simpler something is, the less scrutiny it needs in the first place. Mind you, I think even sysvinit is too complex for PID 1. PID 1 should do the bare minimum trhat the kernel expects of it (taking care of orphaned processes, handling shutdown requests) and leave the rest to other programs.

On some level I agree with you, but if you look at the things that Apple is able to do with OS X and timer coalescing [1], that central point of coordination becomes critical. You need a mechanism for starting and stopping all things, not just daemons, that plays by a specific, defined set of rules so you don't have multiple processes trying to do the same thing.

On another level, I feel the "unix philosophy" of having a lot of interchangeable modules taking care of small, simple tasks hurt it: each level of abstraction has a performance hit, and having to support multiple components in a modular way makes change management a nightmare. There's something to be said for the elegance of tightly integrated components: you can make assumptions that you couldn't otherwise make in a more modular system. I can see how it would be a problem if systemd were proprietary, but it's open source.

[1] http://www.apple.com/osx/advanced-technologies/

You are right that loose coupling carries a performance hit. Certainly, if your only goal is to increase the boot speed of a desktop Linux box, then systemd makes a lot of sense. That said, there are many other goals and many other kinds of boxes, which, among other reasons, is why the tide is turning against systemd.

"Performance" can many different things, all of which are useful in different contexts. It could be lower power consumption, faster thread performance, more I/O, lots of things.

agree. So far, the only 'performance' case that I've seen made for systemd is in desktop system bootup time. Certainly it won't make my threads go faster or cause significantly lower power consumption, or give me 'more I/O'.

No. No, no, no.

For all other processes except pid 1, the status of processes in the system is in a state of Heisenbergian uncertainty because any process could die and have its pid taken by something completely different between the time you query the process table and the time you take action. So if you want sophisticated monitoring and control of all the processes in the system (and you almost certainly do), it should be done in pid 1.

The minimalist init is neckbeard-compliant, but it's just not enough for a robust modern system. Systemd is the correct design.

> 1. It now has a lot more attention focused on it, so it will get more scrutiny.

I think we tried that with openssl already.

Over-complexity was a major contributor to the failure of OpenSSL. I think there's a real danger of building an overcomplicated system that sets us up for problems in the future. Especially as it ties into everything, presenting a large attack service from other parts of the system that are supposed to be lower privilege.

I've accepted udev, but I'm still wary of dbus.

I'm starting to think OpenSSL is the new "hitler of software". If you disagree, or dislike something, compare it to the OpenSSL heartbleed fiasco...

Addenda:

2. So? Like text files can't get corrupted? At least journal has checksums to ensure that data is not unknowingly corrupted.

4. If I recall correctly, systemd can be used with static dev (with limited functionality).

5. That's not what I've gotten (Gentoo). Also, if it's an issue, it can be turned off.

6.

> it is far smaller in breadth than the Linux kernel itself, yet seemingly just as critical

Isn't it a good thing if stuff is smaller?

8. This isn't an actual argument. systemd has code to catch errors and infinite loop the program. It's not even internally consistent. "have fun rebooting, except my argument isn't even valid because systemd has code to reexec"

9. No, systemd is primarily concerned with glibc. Patches to run on other libcs are accepted if they do not unnecessarily complicate the code.

10. Without actual examples, this is a useless argument at best.

11. This is not a point, just name-calling.