> anti-systemd folks

[note: no personal hostility intended - I'm responding to the idea of "anti-systemd" in the abstract]

It's this kind of us-vs-the, faction-oriented attitude that concerns some of us. Nobody[1] is saying systemd should be expunged from the repositories or removed as an option.

The concern is that a newcomer (i.e. potentially buggy, but could prove itself over time) to the area of "init software" is demanding to be the only software allowed for that particular problem. Even more concerning is how that same newcomer as monopolistic tendencies, and has started tying/bundling together several neighboring software niches, demanding that the currently used and working solutions in those areas be abandoned as well, because of some made up requirement.

If you or anybody else wants to run systemd, you should. In reading these discussion on it, it even sounds like a great choice for some situations (the people setting up "tens of thousands" of mostly-identical systems seem to like it a lot). Some distros make it the default? Why not, variety is one of the great things about having multiple distros to choose from.

Insistence that OpenRC and such must make way for systemd is enough provoke a rather strong reaction. The deliberate incompatibilities to force adoption, on the other hand, are borderline fighting words.

This pattern - trying to suppress competing ideas while claiming the opposition is being unreasonable for suggesting some sort of compromise - is something I've had to fight in politics for a long time. It's expected any time atheism or gay marriage is brought up.

I never thought I would see that kind of "argument" used seriously[2] over UNIX...

1: "nobody", modulo the rare fanatic/ass that you find in any sufficiently large group of people. Even the linked article above - despite the presence of strong opinions - is more concerned with technical issues and how to solve the "init system problem" in general.

2: we have had our Holy Wars, but traditionally only leads to strange stuff like "evil-mode"

Folks on #musl found 2 integer overflow bugs in the UTF-8 handling code within seconds of checking out the source to read it. It's not clear to me where the code is called from and what inputs reach it, but that kind of bug does not inspire confidence in the safety of the project as a whole. I also quickly found a case where a potentially-null string pointer is passed to a logging function which might or might not be able to accept null string pointers. (I suspect it uses snprintf and therefore depends on the underlying C library's handling of this usage, which is undefined behavior.)

In the interest of transparency, can you tell us exactly what you found? I looked around for a bit but couldn't spot anything.

The argument is one of minimizing attack surface, not specific current attacks. I.e. it's a question of selecting the right technology security-wise and attack surface is a big part of that equation because with that surface area comes the strong likelihood that attacks will be found against the process over time.

I use systemd because that's what my distro comes with. There are positives and negatives. On the whole though, I agree with much of the criticism, and I hope that a real alternative comes along which is more security and uptime friendly.

How has it affected your uptime? Any specifics?

In addition to the prudential concern issues (which are laid out in the article), there are some concrete issues:

With sysv init, it is very easy to add new services that may not be supported out of the box. There are scripts like rc.local, etc, which can be edited to start anything. This means that setting up a new service that can be supported properly is a lot more work, especially if it is for development systems. While I haven't had systemd crash, I have had issues with stuff requiring manual start (i.e logging in as root and running the startup script for the app) when a simple rc.local-type approach would have been far simpler.

Another problem I have had is the issue of process accounting, where if the process starts up a daemon and exits, then systemd has trouble determining the status properly. This can cause issues for things like monitoring (which means basically I don't use systemd for monitoring whether services are running).

What this means, in essence, is that to make this work the way I would like I have had to reinvent part of the sysv init system inside of systemd and then handle things like process tracking the old fashioned way (pid files and shell scripts).

In short, in addition to the "I don't want my system to have to reboot and this is a bad architecture for that requirement" you have quite a bit of areas where there are leaky abstraction layers which don't really add any benefit to administration of the system.

That sounds strangely like the problem systemd was created to solve. It's supposed to detect double forks in the started daemon and track pid files named in it's configuration file.

At least that's how I read it in numerous articles on LWN and mailing lists, I haven't tried it on an actual system yet.

The maintainer of mdadm migrated two nfs-utils sysvinit scripts of 801 lines into 14 systemd unit files of 168 lines.[1] Complexity won't go away with migration.

[1] http://lwn.net/Articles/584175/ (Subscriber only)

I believe that people will start pushing attacks once the popularity of sytemd goes up. Why attack something that's not as widely used as sysvinit?

I don't think that the argument was that it was scary to upgrade or there were no benefits; the author was specifically stating that a couple of points inherent to the design of systemd make it something that he finds less stable. Systemd could still provide these benefits by shipping more than one binary for extra features, reducing the attack surface of the init system itself.

EDIT: BTW I use archlinux and therefore use systemd.