Thanks a lot, I just realized everything I compile on my OS is monolithic. Actually, there's not a single package on a Linux system that is not monolithic.
I'm not even talking about my DE which combine several monolithic packages. Even sysvinit was monolithic actually.
So systemd actually merges perfectly in all this monolithic mess of a system that Linux is.
Or perhaps you're wrong, because I can install systemd non-init stuff on a sysvinit system just fine.

Oh my god, reading the various links would have told you that your 2, 3 and 4 points are kludges today that don't work well, if at all.
Systemd solves every single one of the problems listed in points 2, 3 and 4.

Because what is being talked about flew right above your head. Ironically, the mechanism you describe was the one used until systemd appeared.
Which is ironic because you weren't even aware of how insecure your sysvinit setup was.
Systemd does it better: it does not escalate your priviledges, it keeps control of how the function is executed, you never gain control of the how. You only gain the rights to ask for a system change to be made.
For example, you can be given the right to change the server hostname (which can break your DBUS and DE) or the desktop clock. But you are not actually executing setuid binaries. Or another example, you can be a step above allowing every user to use the sound card when you have multi seat or multi sessions setups (like I do).
If you can't understand the distinction between the two ways of doing things, as is apparent in your post, try not to talk about it, your post made me cringe with the cluelessness.

Oh my, you say it's not true, then post a link that proves you wrong.
Are you even understanding what you're talking about?
The problem Fedora faces with their two sub packages, is that they have to add functionalities that then would not be in the default systemd package.
If they were already in the main systemd package, their sub packages would not make sense anymore, it would defat their purpose.

You sound like an emotional clueless person, not like a developer. What is an over sized systemd? What is an aggressive systemd?
Systemd reduced the size of my hand made systems (I've removed at least sysvinit + tons of scripts and several binary helpers + xinetd + dhcpcd at least) so to me it is not over sized, and it has never actually been aggressive to me, on the contrary, I've fixed several long time invisible misconfigurations by myself thanks to it.

No, the problem is you can't read and mixed CK and CK2. So the GP is correct, and you are still wrong.

Then people saying that are wrong, as this functionality is not in the init system. It is in several parts (so not monolithic), logind being one, and logind is assisted in the task by dbus and systemd init, which themselves are assisted by the Linux kernel.
This assistance and dependencies are necessary to assure a minimum of security.

Wrong, that's you rewriting history from your dreams. Nobody assured that.

It was always developers scratching their own itch. And if you couldn't develop, you could pay someone to do it for you.
It always was this deal, you changed "pay someone" to "notify someone" in your delusions.

Oh, I didn't understand right away that you were a proprietary software shill, my bad, it should have been obvious, no true Free Software actor could be so deluded and so clueless.

FUD is a proprietary OS shill tactic. If you don't understand why distros are separated in systemd ones and non-systemd ones in this thread, you're hopeless.

It was not obvious, because often, the code thrown away is because the underlying plumbing component is abandoned for years, or not supported anymore by anyone.
systemd devs are actually maintaining lots of code nobody wants to maintain anymore.

Yes, I agree it's really stupid. Besides, the people that say systemd features are useless, or that systemd doesn't have any upside, it makes them look plain stupid and clueless.

It's not like that at all. It's rather that systemd proposes a systemd API for several things. There are a lot of field where systemd is the sole provider of an API, so is the de facto standard. And why is systemd the sole APi provider in some areas? Because while DE were asking for these API, systemd was listening and providing them, while others were not listening and busy telling systemd these features are useless.

See your cop out? This is the problem with non-systemd distro: no problem is solved, only cop out, whining, complaining, but you never solved anything, just wasted time. Systemd opponents are mostly like that, that's why I can't take them seriously. I've followed systemd since the beginning, I've seen the amount of work done and the attitude towards users (DE, sysadmins, distros...), and I've seen the work done by those opposed to it. Given this knowledge, up to this day, I predict complete failure of systemd opponents on Linux.

I see we share the same conclusions. "Non-systemd distros" had it coming to themselves by not doing anything when sth needed to be done. Which to me means that they are not actually bothered by systemd, and they're doing a disservice to their users. When they will be forced to migrate to systemd, either because they lose all their users, or because they can't maintain old stuff anymore by lack of resources, the change will be so huge, that I'm not sure if all of them will make it. Stuff like sysvinit compatibility may not even be in systemd anymore.

They removed pm-utils because it didn't work well and was abandoned since 5 years.
People mostly complain about systemd taking over active management of things long abandoned by everybody else.
It's a dogma it seems, a self destructive one, to bash systemd for good things, which is even worse.

Most of the time, it's either removing a useful systemd feature entirely and going back several years in time and functionality, or reimplement in true NIH style what systemd already provides.
Sometimes, the reimplementation fails along the road when the "amount of work required" bar goes above the "hate systemd feeling" bar.

Which is an exemple of what I said above, with a probable failure as outcome.

That's actually a very good question.

There lies the problem, you anti-systemd zealot are taking an antagonistic stance to all this, assuming that what you call "systemd zealots" would love to see KDE work only with systemd. That makes no sense at all, and that would mean DE devs are "systemd zealots". But all the DEs communication and actions points to you being completely wrong.
Thay actually work instead of complaining uselessly and spouting antagonist nonsense about systemd.

Taking an AC on Slashdot as your source, I wonder whether idiotic is the correct term, or whether malice should be assumed.
A real concerned developer would have already started there http://www.freedesktop.org/wik... and looked at "Documentation for Developers".

Don't worry, you can go play with your favorite DE, real sysadmins are taking care of systemd for you.

So POSIX is incredibly dangerous? Your argument is flawed from the start.
systemd provides a standard API, and nothing about a standard API is dangerous, a standard prevents the creation of cartels and monopolies, so what you say is already the contrary to the probable outcome.

What is this nonsense about? I've seen nothing of the like, and I make all my OS from source since 15+ years.

i am running fvwm2 - i have been for 20 years - and i am using angband.pl's recompiled versions of critical dependencies (udevd and others) all of which have "--no-systemd" in the configure.ac files. so i will not be concerned about trojans that attack vulnerabilities in systemd, exploiting the new features such as allowing the firewall to be disabled and much, much more. but you - all you who trust the systemd authors and the desktop environments that now operate exclusively on systemd? you should be concerned.

Talking about security in systemd compared to sysvinit shell scripts is just laughable. Fortunately you've not been 20 years in the security IT field.
Just look at most trojans and rootkits, before saying nonsense like that. sysvinit scripts are a security nightmare in themselves, and are impossible to audit.
BTW most of them don't work anymore in systemd, especially if you've hardened your systemd service files.

What is confirmed?
systemd by default sends stdout and stderr to the journal, contrary to daemon launch with init shell scripts.
The AC is repeating sth false, as several of them do in every systemd thread.
I don't know what their agenda is.

What's even better, the system default for this behaviour is configurable, and it's also configurable per service.

Why are you believing nobody else thought of that in the first place? If it's because you're clueless, why are you criticizing a topic you have no knowledge about?
Of course there is a dedicated journald log reader, it's called journalctl, this is the most basic thing to know about journald before even attempting to criticize it.
Just installing another syslog daemon (like rsyslog) is enough to removes all these concerns, because yes, several people (serious ones) have already done the work instead of complaining based on ignorance.

Why are you disagreeing on something that you say is irrelevant to your servers?

So your world is improving, as sysvinit is even more "don't look behind the curtain, just trust us that it'll work". So much so that you also have to believe that for any distribution that used sysvinit, as every one of them had to implement the "behind the curtain" part, and was saying to you "just trut us that it'll work". Duplicated functionality in every distro, that have now disappeared for a big part. So now it's far better, in every kind of GNU OS on Linux use case, even on non GNU ones.

syslogd is antiquated, no distribution uses that by default anymore on Linux distros (LFS is not a distro). They use syslog-ng or rsyslog, and they plug without any problem with journald. Ripping out journald makes no sense and actually would put you back to the bad days of logging before systemd: no automatic logging of stdout and stderr, loss of kernel boot messages, no display of last messages from your services, impersonation of other processes possible in logs...