> 2) Less modular than any init system out there. Having everything (including a dhcp deamon soon) in PID 1 is not modular just because you can configure it.

I can understand the issue that people have with systemd swallowing more and more functionality, but this fact is just false.

dhcp is in /usr/lib/systemd/systemd-networkd, which is not the systemd binary running as PID 1 (/usr/lib/systemd/systemd/systemd).

    chris@raspberrypi /usr/lib/systemd $ ls -la systemd systemd-networkd
    -rwxr-xr-x 1 root root 907340 Apr 14 23:10 systemd
    -rwxr-xr-x 1 root root 329604 Apr 14 23:09 systemd-networkd
    chris@raspberrypi /usr/lib/systemd $ ./systemd --version

systemd 212 +PAM -AUDIT -SELINUX -IMA -SYSVINIT +LIBCRYPTSETUP +GCRYPT +ACL +XZ +SECCOMP -APPARMOR

>> 0) it is hotplug capable

> 0) That's not the init systems job.

For modern Linux, there is nothing but hotplug. And I mean that very literally. Oldest Unices only worked on systems where all the hardware was brought up on boot, before the rest of the system. Then hotplug was added on top of this. Init systems didn't evolve to accommodate this, instead different systems were developed to handle it. However, the Linux kernel has constantly evolved towards eliminating old-style static boot, with right now, on normal bootup, almost all devices are hotplugged. This is why sysvinit doesn't work properly anymore. Being hotplug capable is definately the init system's job.

From a desktop Linux perspective, you're totally right. However, if anything is evolving fast, it's the recognition that desktop Linux has never worked and will never work, and is in any case the extreme minority case in modern Unix systems (which, population-wise, are essentially all embedded systems, servers and phones).

From that perspective -- the perspective of systems which boot once, and boot again maybe next year if the UPS didn't keep them up when the power flickered, and the perspective of the systems where there are definitely not usb drives or random pieces of unknown crap plugged into user accessible ports, the idea of hotplug at all is the least of concerns, and the idea of boot time is laughable.

Essentially, it seems like systemd is chasing Windows of 16 years ago, where computers took 5 minutes to boot Windows, where device drivers and such were a mess, and things were constantly entering and leaving systems.

> the idea of hotplug at all is the least of concerns

No, you don't understand me. Even if actually hotplugging things is completely uninteresting to you, your init system still has to somehow be able to deal with the fact that on a modern box, all your devices show up in essentially random order with random delays. sysvinit currently handles this by putting a completely arbitrary sleep call in the beginning of the boot process. Just last week I had to deal with a server where due to circumstances that sleep wasn't enough, which lead to the ethernet devices getting initially wrongly named, which was bad because the mountains of script doing network configuration there happily treated the external network as the internal one and the internal one as the external one.

Even if hotplug is a feature you don't care at all about, due to design decisions made by the Kernel team, if you want to run a modern Linux kernel your machine will have to fully support hotplug properly or it's going to (rarely and non-replicably) fail in interesting and imaginative ways.

Although I haven't had anything like that happen in my 26 years of running unix boxes and marvel that it has reportedly happened to you, I agree that there is room for better dependency management in the startup process.

That nevertheless doesn't have anything to do with hotplugging devices, nor does it suggest that we should create an init system which handles dhcp, qr codes, and, no shit, takes core files and jams them into its binary log.

You failed to mention why it's not the init system's job. An init system which is aware of what's going on can have a lot of advantages.

In the end djb's daemontools are nothing more than an init system on top of an init system. So why not include it in the main init system?

> daemontools are nothing more than an init system on top of an init system

What do you mean by that? That it isn't PID 1? Apparently it can be made to run as PID 1. But you can keep the (in my opinion) brilliant design of daemontools and use successors such as s6 are designed to run either as PID 1 or as a plain old daemon (which is nice if you've not got full control of a machine).

http://www.skarnet.org/software/s6/index.html

I've been using s6 to manage a few things, and some features I like are:

- allow a group to manage (stop/restart) certain processes using Unix file permissions

- arrange things in a tree. My toplevel s6-svscan starts a second s6-svscan which starts a handful of related processes. These all inherit the same user and environment vars which makes config easy.

Have you tried runit? If so, could you tell me how it differs from s6? I like runit, but if it's better, it's better.

I have not tried runit. s6 is actively maintained; I don't know about runit (on the other hand, runit is in Debian while you must compile s6 yourself). The author of s6 has a (very biased of course) comparison or various supervisors:

http://skarnet.org/software/s6/why.html

The big feature s6 has that runit lacks seems to be the ability to wait without polling on some event (process started). I haven't used this much myself, but even given that some process has started, it doesn't necessarily mean that it's initialized and ready to do what you expect.

You clearly don't understand systemd.

It is a suite of tools for managing the system state. Going from runlevel 0 to runlevel 3 is just one such transition.

systemd is referred to as monolithic because it is developed in a single repository, but it is in fact extremely modular. "PID 1" is only one of the ~70 binaries which make up the systemd suite.

Saying "That's not the init systems job" seems dogmatic and short sighted when there's currently no other approach which offers the hotplug, service management, security and performance features that systemd brings to the table.

If over half your critique is that systemd does _more_ then its predessor and all of those are valid services, that it can do well, then I don't see the real complaint here. I mean are you upset because its different.

It's only better if it does a better job than the tools it replaces. I have working dhcp, cron and logging on all my systems (well, those that need dhcp anyway). I can replace them fairly independently. Why would I want to entangle them? And not only does the the tool need to do a better job at all these things, but it also needs to remain flexible, and easily tunable -- for it to be overall better.

I'm not saying that isn't possible -- ZFS is an example of a tool that gobbled up lots of others, and it's almost better -- for my use-cases not being able to grow a raid-array is a bit of a deal-breaker, as is the requirment of having roughly 4GBs of RAM available -- for many use-cases it isn't. But having disk management, filesystem management and managing disk encryption in one tool is great.

I think you are missing the forest for the trees. Systemd is not just PID1, it is an umbrella project for various core system bits and pieces. Most stuff in systemd project do not run in systemd PID1.

Various core system bits that are tightly integrated using undocumented APIs and assumptions about what the other parts are doing internally which are subject to change at any time. I think you can replace some, though not all, of the non-PID-1 bits with a little development work, but replacing the core parts is unsupported.

That is beside the point. The argument was "That's not the init systems job." to which I presented the counterargument that systemd is not just an init system.

Beside that, I recommend you'd take a look at http://www.freedesktop.org/wiki/Software/systemd/InterfacePo... and possibly http://www.freedesktop.org/software/systemd/man/.

See my comment at https://news.ycombinator.com/item?id=7639730 - those are the external APIs used by software that isn't officially a part of systemd but still depends on it. The APIs between different parts of systemd are undocumented and subject to change. In fact http://www.freedesktop.org/wiki/Software/systemd/InterfacePo... says as much itself and exists in part to convince people this isn't a big deal because in theory someone could write their own components that implement the same APIs. (Except that in practice no-one has reimplemented anything beyond the most trivial APIs, and in fact that page claims some critical stuff like logind cannot be independently reimplemented or used without systemd.)

The systemd init is FAR more complex than a basic init. Service status management? service file (of all types) parsing? IIRC all done in PID 1, with a nice (?) dbus integration and a glib loop added in for some additional fun. Some think this is dangerous and not necessary.

> Edit: And if you downvote me, at least add an explanation please.

See other replies.

What? That's my explanation after all.