That's an odd assumption. I have. I'm a big fan of standardisation.

I understand some people not liking systemd, but there are a lot of folks out there who really prefer it. Once I started adopting it, I no longer needed/wanted to support cross-distro start scripts, since systemd does that. So non-systemd distros were dropped.

We're moving more and more to having unified low-level services across Unices, so it stops being about stupid things like "Oh sorry, Arch can't run this because it uses its own audio stack even if we're just using audio to make a notification sound", and starts being about the things that are fundamentally different about the systems.

Think about how nice it is that we don't have to recompile most things for most kernel versions. Why do we have to set up multiple startup script mechanisms?

Yes, nobody has ever had to recompile their application to work on a new kernel. If you mean that's nice that there's binary backwards compatibility, I agree. I don't see what this has to do with supporting multiple systems.

> Why do we have to set up multiple startup script mechanisms?

Why do we have to support multiple <insert any kind of software> ?

> We're moving more and more to having unified low-level services across Unices

AFAIK, the only thing I know of moving toward middleware unification specifically is Linux desktop software. Choosing to use systemd in exclusion of everything else is "unification" in the same way that nationalism/xenophobia/homophobia are. (i'm aware of how mean that sounds, but it's the closest comparison I can think of)

It is certainly nice that there is now middleware that abstracts the underlying software that controls the hardware, for example, or that authentication and authorization are more uncoupled. But this is really almost the opposite of what systemd does.

Although I'm speaking with my sysadmin hat (I have a few hats). I have a lot of software deployed/managed through Ansible (from node/ruby/python apps to proprietary apps). They might not provide a unit file, so I have to write my own (and I might send it upstream).

The main pain point I encountered regularly, was making sure that the process starts at the right time, has proper stderr logging and monitoring. I rarely bump into kernel or library problems (but that's just me, I'm not denying the problem). I understand what you mean though, systemd is just one of the base components. It doesn't fix everything, but it helps.

On "write once": I feel bad for people who have to read the shell scripts I've written. I think they're good and I'm a fan of keeping it simple, but my scripts don't come with a manual. Any junior dev can understand my unit files (tangential: that's also why I like Ansible/Puppet/etc).

I didn't write upstart units for that reason. I now write systemd units and it's wonderful.

By moniculture, are you saying that adopting systemd leaves you vulnerable to cross-distro vulnerabilities hitting a bunch of systems all at once? (Most of my knowledge on the downsides of monoculture come from Irish history) Or are you pointing to something else?

That's not a good standard for an operating system supposedly about flexibility, compatibility, and choice. And it's even more annoying for software which isn't intended to be run in a monoculture, like most of the open source/free software world.

And for that matter, did anyone make a systemd-to-sysv converter ? Because that should surely be possible, systemd service files being declarative.

If such a converter did exist, then suddenly, the systemd "service files" could become an actual standard, since they'd be (somewhat) compatible accross sysv and systemd. And maybe we could work from there and support other init systems...

Your suggestion of turning systemd's APIs and formats into a standard is not out of the question, but it would never happen. Poettering and his team showed they have zero interest in making a compatible system, or in making any concessions at all. Standards have to do both. And other platforms have to buy into the standard, otherwise it just sits there like a third leg.

The way it would probably end up is a project like Alien would adopt some of systemd's quirks. But so much of systemd is tied directly into the application via APIs that it would be a huge PITA to support both systemd and anything else - hence why some devs simply drop support for anything that isn't systemd. It's the same sort of thing that causes devs to only develop for Windows, or iOS/OSX, because it's more popular and porting to Linux is too expensive.

Another is daemonization. In traditional systems, long-lived processes daemonized themselves and took care of themselves. The big benefit was independence and flexibility. You don't have to do a lot of work to port it, or maintain it, or administrate it. A shell script and some simple conventions allow it to run in almost any environment, and all of the services basically worked the same way. Often this was out of the necessity of a complex program's needs, where the way it manages its tasks, or shares memory, or communicates with other processes, or handles signals, or is checkpointed, or debugged, etc may have had complex requirements.

But now, systemd recommends you not daemonize your process. Let systemd manage it for you! This works great for very simple services, but not so well for complex ones. Now people are writing more services that can't manage themselves and thus need something like systemd to take care of it, or it simply won't work as a daemon on a non-systemd system.

The systemd people would say, any system can adopt these calls and these methods! (Which is equivalent to saying, any OS can adopt Linux's completly nonportable and specific syscalls, even though they already have a working alternative) But that's not the end of it. Every piece of systemd that you adopt, then depends on other piece of systemd, so you can't just pick up one piece of the pie. You have to eat the entire thing.

The benefits of that unification are very, very tangible for package authors/maintainers - they now have to write just one flavor of a service file. And that is a great thing(tm) for the Linux community as a whole - well worth my own gripes with systemd itself.