I perfectly know how sysv-rc work, thanks, and this is the primary reason why I am more than happy to replace it with systemd. The runlevels and run order by the number in the filename of the script is terrible to maintain when there is dependencies between services.

I think that you wanted to wrote rc instead of rcS, because this last one only exists to call the former with an 'S' in argument (to start the single user runlevel):

cat /etc/init.d/rcS
#! /bin/sh
#
# rcS
#
# Call all S??* scripts in /etc/rcS.d/ in numerical/alphabetical order
#

exec /etc/init.d/rc S

I added the -Sr only because there display the size in a more pretty order.
Such a big deal...

Now what's strange is that you complain about the -Sr options that have a real effect on the displayed order, but you superbly fail to notice that this is actually the -a option that do nothing in this case. So before pretending that you know everything better, show at least something coherent.

Yes I did. I will list them here so you only have to put your observations regarding systemd below each of them that apply:

Rule of Modularity: Write simple parts connected by clean interfaces.
Rule of Clarity: Clarity is better than cleverness.
Rule of Composition: Design programs to be connected with other programs.
Rule of Separation: Separate policy from mechanism; separate interfaces from engines.
Rule of Simplicity: Design for simplicity; add complexity only where you must.
Rule of Parsimony: Write a big program only when it is clear by demonstration that nothing else will do.
Rule of Transparency: Design for visibility to make inspection and debugging easier.
Rule of Robustness: Robustness is the child of transparency and simplicity.
Rule of Representation: Fold knowledge into data, so program logic can be stupid and robust.
Rule of Least Surprise: In interface design, always do the least surprising thing.
Rule of Silence: When a program has nothing surprising to say, it should say nothing.
Rule of Repair: Repair what you can — but when you must fail, fail noisily and as soon as possible.
Rule of Economy: Programmer time is expensive; conserve it in preference to machine time.
Rule of Generation: Avoid hand-hacking; write programs to write programs when you can.
Rule of Optimization: Prototype before polishing. Get it working before you optimize it.
Rule of Diversity: Distrust all claims for one true way.
Rule of Extensibility: Design for the future, because it will be here sooner than you think.

The point is that you compare a simple script with a systemd-* binary, complaining that you can't run any systemd-* binaries without the systemd infrastructure.

What you fails to understand is that the equivalent of init scripts in systemd is not the systemd-* binary but a unit configuration file. If you want to compare a systemd-* binary, take a binary that provide the same kind of service. What you will find is that the usual code (or libraries) in the traditional service application is replaced by a more standardized API in the systemd-* application. For example, instead of depending on libdaemon, the application will depend on libsystemd. See https://github.com/systemd/sys...

At the end systemd will reduce the number of dependencies required by the applications that use his API compared to an application that will try to provides the same features without the libsystemd API. From the architectural point of view this is a good move.

What's the problem exactly ?

If you like the idea of having an other logind that the systemd-logind, just disable the systemd-logind service and wrote the service file to start the logind you like, or use the sysvinit compatibility to start it with a script.

The systemd infrastructure provides more features that the sysvinit. Gradually more and more code will use this interface. This is normal evolution. udev, or dbus stories was not so different.

Now what the point of trying to run systemd-logind withtou systemd infrastructure? If you need a logind without the systemd features, just use the old logind.

Ô master of the understanding, please explain to our poor brains what rules listed in the link of your holly signatures are so blasphemed by systemd.

Please show a link to the Tomecat init script you are talking about, because I was unable to found a ready to use init script in the Tomecat source code repository. I confess that did't spend a long time searching it, but since you seem to known well Tomecat (unlike me) you should find it quickly.

Unfortunately the initscripts are mostly distribution specific and lack a good standardization. See the nginx example to illustrate the problem: http://wiki.nginx.org/InitScri...

The systemd infrastructure provides features that don't exists initscripts, so yes there have a bit more coupling than initscripts, but since the features list is not the same, the comparison is biased . If you have a better architecture to propose to provides the same set of features, please show your talent.

Tell me.

On what part did you need a prof ?

Debian package dependencies will show you that initscripts depend on sysv-rc (or file-rc) to boot the machine. Without sysv-rc, initscripts are just simple scripts that will not magically run at the boot of your machine.

If a kernel provides the features required by systemd, aside of a compatibility layer, what could technically prevent systemd to run on an other platform? Maybe the lack of motivation, ok, but from the technical point of view?

http://man7.org/linux/man-page...
I let you the joy to click on each link and to read the "CONFORMING TO" section to count how many time you find the indication "Linux specific". Just a few of them as example: pivot_root, ppoll, remap_file_pages, removexattr, restart_syscall, timerfd_create, futex.

The fact that the initscripts package depend on sysv-rc package was true since squeeze and unfortunately for your claim, systemd is packaged into Debian only since wheezy, about two years later.

https://packages.debian.org/sq...
https://packages.debian.org/wh...

The cause was due to an other player: https://packages.debian.org/sq... Before upstart the order of the dependency was not important. The error in the order was only evident when the new player 'upstart' was able to replace sysvinit (unlike file-rc).

No, this is really initscripts that depend on something to make your machine boot. This other thing can be sysv-rc, file-rc or even systemd. sysv-rc, file-rc or event systemd without any unit file will not boot your machine to any useful state.

The point is that if you choose to use systemd units you depend on systemd to start them at boot, exactly the same way that if you choose to use initscripts you depend on sysv-rc or something like this to start the scripts at boot.

Take a look at the initscripts Debian package dependencies:
https://packages.debian.org/si...
Really, this is initscripts that depend on sysv-rc and not the other way around. This is pure logic.

Please, Ô master of the understanding, please explain to our poor brains your various reason why we are do dumb. Please, just plain verified facts that we can reproduce.

Given the number of security fixes that have affected the various venerable UNIX tools since do many decades, and the number of competitive UNIX projects with different architectures over the time, I am really not convinced that UNIX is so better at "writing good code". A big and motivated open source community is a way to help a project getting code with improved quality. But just UNIX, I don't think so.

Note that initscripts lovers can still wrote a simple systemd service file to lunch sysv-rc and all the initscripts it if there like doing that way after the removing of the sysvinit compatibility. There can even disable all the systemd services but the one that lunch sysv-rc to get back there precious initscripts.

There will simply be no more maintainers taking care of the initscripts coherency in the long term. I am curious to see how the initscrips fans will reach a consensus to replace them.

LOL! I am certain to remember this joke even in a decade :-)

Without sysv-rc your machine will simply not execute any of your initscripts at boot! Try to remove it if you don't believe (and good bye by the way).

Can't stop laughing....