> Even if it's technically wrong: Unix as a platform is now Linux. Everything else is niche products [sic], and we don't have to use the same init mechanism on Linux/BSD/whatever just because we can.
This statement is so utter in faultiness, I don't even know where to begin. In the first statement, you say “Regardless of the truth of it; this axiom X is true.”, and introduce a logical paradox, similar to the sentence “This sentence is not true.”[1]. Consequently, you call Mac OS X, FreeBSD and alike niche. The former is the second most popular commercial desktop OS, and the latter is incorporated into the former and also is the OS that powers PlayStation 4[2][3].
You say that “init systems need not be compatible”, and I say yes. Also, OS interfaces need not be compatible. Implementations of C library need not be compatible either, nor implementations of C themselves. Why did the size of a byte were standardised anyway[4]?
> I have deployed the same software on Debian Linux, RHEL Linux and AIX and basically had to reimplement service management scripts for every platform to have the best possible result.
You wouldn't have to if there were a standard initialisation interface, would you?
> Quoting the "Unix philosophy" as the reason to keep things like they were 20 years ago is laughable. I want to get things done, and managing processes using init scripts and daemonization is pain.
You want to get things done today; I'd guess you'd also like to keep thing happening 10 years later, when Linux is no longer as popular (Software come and go, no-one can guarantee that, say, illumos[5] will not become more popular than Linux in 10 years). Would you rather run around porting your init scripts to the new OS a cloud provider fancies, which your boss fancies, or write new bugs (which some refer to as features)? Would you rather wait for the mainstream repos of your favourite projects to catch up, or just deploy the program and enhance the experience? Would you rather read pages of documentation for your new incompatible init system, or skim the frontpage of HN?
> We start to rely docker and all sorts of new approaches to manage our services and nobody complains.
Well, Docker is a containment and distribution solution and programs need not be modified nor need to have around Docker to run. It is reminiscent of a FreeBSD jail or a plain old VM.
> Apple introduced launchd and nobody complained.
Just compare the source trees, you'll be enlightened[6][7].
> 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.
This statement is so utter in faultiness, I don't even know where to begin. In the first statement, you say “Regardless of the truth of it; this axiom X is true.”, and introduce a logical paradox, similar to the sentence “This sentence is not true.”[1]. Consequently, you call Mac OS X, FreeBSD and alike niche. The former is the second most popular commercial desktop OS, and the latter is incorporated into the former and also is the OS that powers PlayStation 4[2][3].
You say that “init systems need not be compatible”, and I say yes. Also, OS interfaces need not be compatible. Implementations of C library need not be compatible either, nor implementations of C themselves. Why did the size of a byte were standardised anyway[4]?
> I have deployed the same software on Debian Linux, RHEL Linux and AIX and basically had to reimplement service management scripts for every platform to have the best possible result.
You wouldn't have to if there were a standard initialisation interface, would you?
> Quoting the "Unix philosophy" as the reason to keep things like they were 20 years ago is laughable. I want to get things done, and managing processes using init scripts and daemonization is pain.
You want to get things done today; I'd guess you'd also like to keep thing happening 10 years later, when Linux is no longer as popular (Software come and go, no-one can guarantee that, say, illumos[5] will not become more popular than Linux in 10 years). Would you rather run around porting your init scripts to the new OS a cloud provider fancies, which your boss fancies, or write new bugs (which some refer to as features)? Would you rather wait for the mainstream repos of your favourite projects to catch up, or just deploy the program and enhance the experience? Would you rather read pages of documentation for your new incompatible init system, or skim the frontpage of HN?
> We start to rely docker and all sorts of new approaches to manage our services and nobody complains.
Well, Docker is a containment and distribution solution and programs need not be modified nor need to have around Docker to run. It is reminiscent of a FreeBSD jail or a plain old VM.
> Apple introduced launchd and nobody complained.
Just compare the source trees, you'll be enlightened[6][7].
[1] http://plato.stanford.edu/entries/self-reference/
[2] http://www.phoronix.com/scan.php?page=news_item&px=MTM5NDI
[3] http://www.vgleaks.com/some-details-about-playstation-4-os-d...
[4] https://en.wikipedia.org/wiki/IEC_80000-13
[5] http://wiki.illumos.org/display/illumos/illumos+Home
[6] http://cgit.freedesktop.org/systemd/systemd/tree/
[7] http://www.opensource.apple.com/source/launchd/launchd-842.1...
edit: format references