Your entire argumentative style in this thread is a combination of reasonable points interspersed with straw men, putting stuff in your opponent's mouth, subtle distortions and willful omissions. I've had enough of it, so this will be my last reply.I could characterise your responses the same way :-)
Where did I say hundreds? I said -likely- reaching a hundred. Single.
Even over one hundred is way off. There are now 76, I checked myself.
There is no official count - the article you linked was written with a special purpose. Nonetheless, I took an i386 experimental deb for systemd-219 (https://packages.debian.org/experimental/i386/systemd/downlo...) and roughly counted 77. I'm not sure what build was actually run (number could be lower than total), and due to the quick unveiling of new interfaces, the number has been higher at one point. Things move fast at systemd, and the fact that you linked an article measuring 204 as evidence for the present shows you're simply out of touch."
You were close: 76 binaries. Of which the new ones are some extra utilities. Things don't move that fast, and they haven't been increasing their scope - it's stayed pretty much the same as what it was at version 204. I currently have systemd v208 installed, but out of curiousity I checked what libaries it links to:
0x0000000000000001 (NEEDED) Shared library: [libsystemd-daemon.so.0]
0x0000000000000001 (NEEDED) Shared library: [libudev.so.1]
0x0000000000000001 (NEEDED) Shared library: [libselinux.so.1]
0x0000000000000001 (NEEDED) Shared library: [librt.so.1]
0x0000000000000001 (NEEDED) Shared library: [libwrap.so.0]
0x0000000000000001 (NEEDED) Shared library: [libpam.so.0]
0x0000000000000001 (NEEDED) Shared library: [libaudit.so.1]
0x0000000000000001 (NEEDED) Shared library: [libcap.so.2]
0x0000000000000001 (NEEDED) Shared library: [libkmod.so.2]
0x0000000000000001 (NEEDED) Shared library: [libdbus-1.so.3]
0x0000000000000001 (NEEDED) Shared library: [libpthread.so.0]
0x0000000000000001 (NEEDED) Shared library: [libc.so.6]
0x0000000000000001 (NEEDED) Shared library: [ld-linux-x86-64.so.2]
Then I checked systemd version 219 - exact same libaries.
nspawn isn't for production use, or so says Lennart Pottering, numerous times.
Well, then it seems everyone is violating that quite tremendously. CoreOS must be incompetent, I don't know.
By "everyone", you mean CoreOS, right? CoreOS contribute to systemd, they probably know what they are doing. The man page does say "systemd-nspawn - Spawn a namespace container for debugging, testing and building" and also "Note that even though these security precautions are taken. Many of the security features may be circumvented and are hence primarily useful to avoid accidental changes to the host system from the container." I'd certainly hope anyone who uses it in production had read the man page first. If not, yeah - must be incompetent.
So the fact that systemd, the PID1 which handles both the system state and the OS process state at the same time, isn't true?
Can't follow what you are trying to say here. systemd is not a proposition. Could you restate that?
That you're picking to focus on this low fodder argument out of everything that has been said by more acquainted people is just disingenuous.
"Your entire argumentative style in this thread is a combination of reasonable points interspersed with straw men, putting stuff in your opponent's mouth, subtle distortions and willful omissions."
I never mentioned anything about compatibility with syslogd.
Yeah, you did actually. You said "journald hijacks /dev/log and expects all syslogd implementations to conform to its own standard."
Now, this, is a total non sequitur. As in, you completely and horrendously misread everything that I said and deliberately projected your own biases into it. This isn't worth responding to simply because it's based on your own odd incredulity.
You wrote "For example, even Apple had the engineering sense to separate their launchd plist configuration parser from the launchd PID1 itself.", which is wrong and you admit that you need to look into this more closely. I mentioned systemctl thinking that you believed that launchctl parsed the configuration files for launchd and somehow launchd communicated with this to get the configuration info. Of course, I assumed that's what you thought - otherwise what was your point? systemctl also parses configuration info. Maybe I got the wrong end of the stick, but given you were wrong in the first place I'm not sure what point you were making now.
In this case, it's less that I deliberately misread you, it's more that you weren't very clear!
Init doesn't reap zombied processes, by the way. The kernel does this. Init doesn't do re-parenting either...
Where the hell did I say any of this? I specifically mentioned they get reparented to init(8), and nothing about zombies. Once again, putting words in my mouth.
In case you aren't following along: an orphaned process won't get reaped. You stated that "init(8)'s duties are reaping orphaned processes and handling high-level global system state at best (like SAK, shutdown, halt, etc.)". You probably meant that init reaps zombie processes - you can't reap an orphaned process, an orphaned process is still running and is reparented by the kernel to PID 1. init doesn't do this.
You were therefore wrong on two counts:
1. The kernel detects when a process is orphaned and reparents to PID 1, which just happens to be init. init doesn't actually do any reparenting, which is sort of key to your argument as you believe that init should be the process that reparents a process when it's parent dies.
2. An orphaned process doesn't get reaped, because it's still running. A zombie process is one that has exited but is still in the process table and the parent process hasn't reaped it yet. You don't seem to understand the difference between the two, so I explained it. I'm explaining it again.
I've had enough of this nonsense.
That's good to know, so have I :-)