Way to throw away a good argument in the OP just so that you can say the same bullshit again.
People using IOS or Android computers (tablets, smartphones, ...) without problem proves how misleaded you are.
These arguments were wrong 15+ years ago already.

No, systemd doesn't eat your stderr, don't worry, that's just troll's nonsense.
As for daemons launched by systemd, it's far better than most other inits, as instead of being lost in arbitrary places, your stderr is _consistently_ put in the same place, the upstream default being in the journal.

Of course it is. If you're a sysadmin and believe this, it's a huge warning sign that you're very bad at your job and should document yourself a lot more.

People should fell shame when someone not knowledgeable in a field knows more than the ones supposed to know a lot.
Document yourself, and come to your own conclusion. Besides, an OS like Windows is nowhere like an init or plumbing tool.

No, any seasoned sysadmin that knows what they are doing can tell you what you ask for is not possible.
The design of these things, like for example how sysvinit was used, was flawed from the start. And it keeps getting worse.

He's right, pick your battles. And anti-systemd trolls have picked their battle as in fact, none of them is fighting against systemd, except if they consider spewing nonsense and trolling is fighting. They all fled the battle to OS without systemd actually.
What's cool about anti-systemd people, is that you just have to take the contrary to what they say to know what is truth.
So yes, systemd is a huge improvement security wise compared to sysvinit or even other executable configuration inits.

tl;dr: this has already been discussed and justified by systemd devs, and what you see is the result.

I'm surprised to see these kind of discussions about systemd here.
Actually I'm not anymore. I've come to expect that people critical of systemd always have a take like systemd devs are incompetent morons.
That's why they always end up being months if not years behind the systemd devs in thinking about Linux plumbing.
That leads to stupid waste of time like uselessd, when the far more competent systemd devs took the right way after some good analysis and study.
I'm just lousily following the systemd devs ML, and every single time a technical subject about systemd comes outside of the ML, I find that it was alreeady discussed, debated, thought through and resolved or a stance taken in the ML.
This is yet another case here. Why functions calling are not always a good thing with a plumbing program like systemd PID 1 has already been discussed and explanations given on the ML. And I happened to agree completely with the conclusions. Part of the reasons have been given by a poster here, and I recall there was reasons related to security, like avoiding useless and exploitable stack operations when it was not necessary.

I can attest that the patch would be rejected, as eveything said here was already discussed on the ML or elsewhere, and the result is not just an accident.

Not if you are used to the hundred of big initscripts under /etc . I know I never was intimidated by systemd config files.

You are wrong, the problem lies in the Linux kernel and btrfs implementation, the developers explained this long ago, but you're too computer illiterate to understand the explanations given by developers. You surely didn't understand that systemd by default won't use a policy that can lead to data loss, no matter how loud you yell at it. And these problems are partly policy problems, managed everywhere (even with hardware RAID) by daemons or services, that won't let you boot by default, you have to configure them to do it.

"Just do it" is the answer of clueless people that have no experience or knowledge of what they're talking about, especially when they're saying this to people with lot more experience, like distro sysadmins.
Initscripts are inherently broken in a dynamic environment, just starting with race conditions.

Do you realize that every single one of the anti-systemd crowd is not advocating what you are talking about (really using init), but the crazy crappy way with symlinks and everything used by every distro that used sysvinit?
You're right of course, but what you describe is roughly the same work that has to be done with systemd: trimming these insecure faulty initscripts to one invocation line.
Sometimes it's not possible and requires a shell script, but the work is the same with systemd and truly using sysvinit.
But sysvinit is really too limited compared to systemd, and would need lots of shell scripts to work properly, just to bott a Linux system, and most importantly, sysvinit needs a competent sysadmin custom configuring it.

This there is the true reason why so called "old sysadmins" despise systemd so much: it makes everything much more simpler and faster to do correctly, and allows them to be replaced far more easily by less paid individuals.
I never thought of that, but now it's clear. Because true sysadmins could never say so many absurdities about systemd if they really tried it.
Though I think these syadmins are thinking to much into this, you still need to be a competent sysadmin to manage systemd, the countless clueless mistakes made by very bad old sysadmins (if even you can call them that sometimes) seen in bug reports are there to prove it.
I'm not worrying at all. Systems were impossible to manage correctly with initscripts, one bad sysadmin could destroy everything or compromise the security of your boxes without you seeing anything, I've seen that countless times.

Dangerous people like you must be discredited at all costs before young sysadmins believe your stupid sentence.
The Linux kernel proves you wrong, and obviously, the shell interpreter used to interpret your shell scripts proves you wrong too.
You're clearly not qualified to talk about this matter, and the obvious answer to your question is the opposite of the one you've given.
Shell scripts have always been unsecure, the countless workarounds that you can even find in the Linux kernel to try to mitigate the security nightmare that are shell scripts should be well understood by most sysadmins, or you're in for some surprises when you'll be a bit more seasoned.

Oh man, you even contradict yourself, but you choose the path of nonsense anyway. Shell scripts most of the time (every time in distributions) need countless other binaries besides the shell interpreter, every single execution of which can be exploited, for example by changing the environment, even with race conditions, sth that is impossible to resolve with shell scripts if you need external ressources or even to write sth. Rootkits are very happy with initscripts actually, but they can't cope with systemd for now, if they ever can. Most of the dynamic state of Linux (disks, network, ...) need binaries anyway to be handled.
The only case when shell scripts work are with a well known customized static setup. Which breaks as soon as you change sth. Been there, done that.
Debian and its famous ifup/ifdown that never worked and will never work is another example: how many new sysadmins locked themselves out of their distant boxes, thinking that they could dynamically change their network configuration?

Systemd has already been audited and continues to be. Far more than sysvinit has ever been, and initscripts have never been audited.
A lot of initscripts are even full of very dangerious bugs or clearly unsecure, and can't be made secure because then they break and don't work anymore.
Most are impossible to secure. These initscripts need a sysadmin knowing their behaviour and constantly monitoring them to ensure they are actually running, as they just don't work.
No wonder every distro fled as fast as they could from initscripts.

Fortunately systemd arrived for the lots of bad sysadmins like you. That's one big reason why I'm glad systemd will be the default in most enterprise distributions.
Clueless admins like you must have tons of security holes in their custom made init scripts and when they use even the provided ones: that's my experience seeing clueless sysadmins working, they didn't understand anything about their revered Unix and how it works, starting with sessions.
And what you wrote show a complete lack of understanding of init scripts and systemd: what you described is actually reversed, init scripts are the far less secure things. And not even knowing that you can still have your usual log files with systemd takes the cake in cluelessness.
systemd will either remove or force improvement of all the bad Linux sysadmins out there, which is all for the better, and will lead to better secured Linux systems in the wild.

Your problem is that there is nothing to discuss, as everyone can say up to this day that KDE or GNOME don't depend on a particular init system.
I can compile a complete KDE or a complete GNOME without any dependency on a particular system.
Of course, I'll lose some features if I lack some dependencies. And I'll lose some without systemd.
But that's a distribution problem.
On my hand made systems for example, I lost the geolocalisation tied features of GNOME as I didn't install these dependencies when they required me to install 2 different major versions of these libraries.
Another example is that I lost the ability to use XScreenSaver in GNOME or KDE a long time ago, as at one point in time, it became more complicated to make it run on top of these DE, as it became unsupported. Some distros still support it though, but I made the painful choice to move along. I still use it with my XFCE desktop which I rarely use anyway.

It's explained in the link provided in the OP. Do your homework before spouting nonsense.

Unless you mean that Linux is not compatible with your system, you're wrong. Now I'm pretty sure you're clueless or at least inexperienced.

So you're definitely clueless. You don't understand what you're talking about. You are in an unprivileged container, but you STILL need a privileged manager in this container, and that manager is systemd. That doesn't mean everything else is privileged. Your system just won't work without a privileged equivalent to PID 1.
prctl is not a systemd prerequisite. Nothing prevents you from using /dev as a tmpfs (you can even lock its size) and you won't have access to CG as systemd will take care of them.
Basically, having your prerequisites doesn't prevent you from running a systemd in a OS container or force you to remove systemd features, as that's not what you're asking for. You're asking for an unprivileged container, which doesn't mean at all that the systemd inside the container has to have anything removed.
Now, nothing prevents you from running systemd containers with sth else than systemd, you'll just lose eveything systemd brings to the table in the process.

This doesn't make sense: you want systemd within a OS container without systemd dependencies. Use sth else, then! No one is stopping you, you can still use your sysvinit + init scripts, you're on your own anyway with your custom needs.

You are making a bad impression of yourself actually, what you wrote shows you don't know what you're doing, or what is really asked of you.

You still show you don't even understand what you're reading.
Apparently you try to use /dev as tmpfs yourself, which you don't need to do and shouldn't do, as systemd is already managing that for all your services.
And they're not talking about dropping mknod unsupported, but about dropping the CAPABILITY being unsupported. Which makes perfect sense, as in devtmpfs, the kernel is making the nodes in your /dev, which you should not touch. But in a container, the /dev is isolated from the base OS, and you have to be able to make nodes in it one way or another, and this is by using a process that have the CAP_MKNOD capability. That's because everything in your container is unprivileged. Or else you will have an empty /dev, so a container that won't work with a Linux kernel. As I said earlier, you don't understand what was asked of you in a unprivileged container, which is exactly what systemd will provide to you. But you have to understand the link you've given to know that.

I'm not missing the point, you're clueless. So as to not spam Slashdot, I'll point you to how to do this :

wget https://github.com/systemd/sys...
tar xf v228.tar.gz
cd systemd-228 ; ./autogen.sh ; ./configure --help|less

Then perhaps you'll understand if you make it this far.

There are security, stability and constancy reasons, and nothing is rolled into some monolithic "init" system.
You're lucky to have your suspend work perfectly fine, that doesn't mean it was working perfectly fine for everybody, far from it.
That's what you can't understand if you live in your little world. But distro maintainers have to tackle the reality of all the other unhappy users.

A nice standard interface with lots of "might" in the definition? suid binary (insecure things we're trying to avoid at all costs)? /sbin/suspend, of which you're not even sure it's there or of its path?
And you called systemd API butt-ugly? Was that a joke post?

At least it works, I didn't see your code contributions to resolve these issues.

Removing in the equation the huge stock buybacks of Apple ($30 B just recently) is a very convenient thing to do.
You shouldn't look at the current stock in a vacuum, it's very misleading.