> "I don't think anyone has ever dropped a distro because it wasn't using systemd"
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.
Most distros have different package managers, different flavors of compiled and packaged software, different libraries, different system management tools, and different kernel versions. Yet you switched distributions because of the two whole different methods of start-up scripts. The one thing that only has to be written once, and then forgotten about forever.
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?
> Think about how nice it is that we don't have to recompile most things for most kernel versions.
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.
Trivial example: Debian vs Ubuntu, when Ubuntu used upstart. Now I don't need to worry about process management anymore and can provide better Ubuntu support.
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).
This exactly. I was quite happy when I learned about systemd and learned that it was coming in Ubuntu. I want a distro-agnostic easy way to keep programs running. init files were way too complicated, and upstart scripts were not distro-agnostic.
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?
A standard can have multiple implementations and changes happen by committee. A monoculture like systemd changes by the whim of their developers. If some implementation is too buggy, which by many accounts systemd is, being able to switch to/develop an alternative implementation without causing fragmentation is an important distinction.
It's a standard in the sense that Service Control Manager is a standard. But it's a monoculture in the sense that writing your application for Service Control Manager means it will only ever work on Windows NT-derived operating systems.
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.
To be fair, how hard can it be to port your app from one init system to the other ?
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...
Making a service file is only a small part of the systemd monoculture. People don't care about the init system as much as how it hijacks the entire OS and shuts out alternative Linux 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.
For one example, socket activation. To get the benefit of systemd (socket activation is supposedly the whole reason they supposedly created systemd) you have to patch your application to use the sd_* family of system calls. Old apps can be patched to support this, but new apps may not have any incentive to be built to use traditional sockets. So newer socket-communicating apps may not work at all on non-systemd systems.
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.
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.