> You wouldn't have to if there were a standard initialisation interface, would you?
My point is, even right now with sysvinit (and aix doesn't use it afair), i have to adapt a init script to every single unix/linux distribution i want to use my software on. At least, if i want to comply with that system's best practice.
With systemd and other init replacements, it's likely a few lines of config file i have to rewrite. Its much less effort to ship or adapt to a few of these than have a init script that works everywhere.
About other unixes: calm down, this is some process that supervises other processes, this is in no way comparable to making libc incompatible.
I assume we're talking about servers here that run off the shelf distributions. For (virtual) appliances and embedded devices / firmware everyone will roll their own images with whatever init they're happy with. We don't have any influence on what commercial vendors do. If AIX feels like an 80s system (i know it's modern and powerful at the core) that's IBMs decision, but i don't hear any complaints that Linux distributions don't ship ksh in vi mode as /bin/sh anymore.
So, in this particular market and with the problem at hand, i don't see how and why Linux should wait for the sysvinit replacement that is able to make everyone happy and will magically be adopted by everyone.
And if some day illumos will succeed Linux, I'm sure people will manage to port their 10 lines of service config over.
> [And] if some day illumos will succeed Linux, I'm sure people will manage to port their 10 lines of service config over.
It is not ten lines of service config being hard, though, it is grokking a new, ad hoc tech, which is necessary to get the most out of it. I have not a rage against systemd in itself; it is too low level for me to care about, process management that is, yet I'd support, to the last drop of my blood, a standard to cover initialisation. If I have to write an init script/config/whatever one day, I'd rather use a standard format that I can get to work on any system, than an ad hoc, OS-specific technology that I have to re-learn every time I switch operating systems.
You seem to overlook the importance of a process hat supervises other processes. I reckon that it should be so stable, one shouldn't notice it. That is possible if and only if the thing is tested and implemented according to a standard throughout long times.
My point is, even right now with sysvinit (and aix doesn't use it afair), i have to adapt a init script to every single unix/linux distribution i want to use my software on. At least, if i want to comply with that system's best practice.
With systemd and other init replacements, it's likely a few lines of config file i have to rewrite. Its much less effort to ship or adapt to a few of these than have a init script that works everywhere.
About other unixes: calm down, this is some process that supervises other processes, this is in no way comparable to making libc incompatible. I assume we're talking about servers here that run off the shelf distributions. For (virtual) appliances and embedded devices / firmware everyone will roll their own images with whatever init they're happy with. We don't have any influence on what commercial vendors do. If AIX feels like an 80s system (i know it's modern and powerful at the core) that's IBMs decision, but i don't hear any complaints that Linux distributions don't ship ksh in vi mode as /bin/sh anymore.
So, in this particular market and with the problem at hand, i don't see how and why Linux should wait for the sysvinit replacement that is able to make everyone happy and will magically be adopted by everyone.
And if some day illumos will succeed Linux, I'm sure people will manage to port their 10 lines of service config over.