I don't need to look at the code, I just have to look at the different process ID running all these tools to immediately understand that they are not one monolithic thing.
And what you call a problem is actually a good thing, as it's necessary for security's sake.
I understand that to you security is a problem, that doesn't mean it should be. Security should be a major concern to any sysadmin, and systemd is a huge improvement compared to any other Linux init in this area.

Bad architecture doesn't mean monolithic at all. Or did you change the subject?
Anyway, none of this (bad architecture or monolithic) is a problem with systemd. Linux has a bad architecture and is monolithic too, and people have complained about it too. It's specialists masturbating over nonsense. Because to this day, none of these people were able to implement a good architecture and non monolithic alternative to Linux that works at least as well. And it's exactly the same with systemd, which follows development practices of the kernel in this regard.

I'm not hiding them, they were hidden by shitty sysvinit like inits and not strict enough tools. Lots of people have been bitten by them you know. Migrations problems towards systemd are mostly caused by this and init scripts.
This doesn't mean the configurations didn't work, just that they weren't correct but tolerated before systemd, and could be security issue.
But it's obvious you didn't understand the issue, as is telling by the fact that you believe sysadmins always make perfectly correct configurations everytime.
A working configuration doesn't mean it's correct, but I lose my time explaining that to someone that clearly has no knowledge or understanding of sysadmin work.

Your post is a big tell that you are completely clueless about the issue you're trying to write about: you don't even understand what your own writing!

No it doesn't sound like that at all. "Support" is WORK! XFCE chose to make the work to support an obsolete unmaintained piece of code. Gentoo, a distribution, like Devuan, made the work to support the same piece of code. KDE chose not to lose time supporting it.
Notice that Gentoo, a distribution that can be run without systemd, made it so that their user could still use new functionality in KDE, because it's the distro's responsability. Notice that Devuan didn't do what it should have done.

Wrong! Elements of Linux that have to manage the plumbing of Linux are predictably adopting systemd, there is nothing random at all about all of this, only for the clueless. That's what Devuan say they're fighting. They're say they fight the logical thing, so they're completely illogical, so it's only a dogma, or politics. Unfortunately, I don't see the fighting, which could be apparent through code, lots of it.

They didn't make Upower work. It requirs code, see? Full functionality of neest Upower requires systemd, so they should have provided the new Upower without requiring systemd (good luck!). It requires a package, so it's clearly a packaging error...

Yet you didn't understand this and say it's not a packaging error, lol! You don't even understand what you're writing!
You say it's a systemd issue, but Upower works perfectly with systemd! You don't even understand what you're writing!
KDE people don't owe you anti-systemd zealot anything, and your distro, Devuan, should have done the work like Gentoo instead of its users complaining upstream.
Your distro should be your primary source of help, not upstream, unless it's a very shitty distro that doesn't provide any support.
Repeating wrong things like "Not a packing error, a systemd error." won't make them true. You're in FLOSS environment here, not in politics.
Temper tantrums just won't work.

Anti-systemd people are so stupid they voted you up as Interesting (fortunately not Informative, which would have pushed their agenda better) instead of Funny.
They didn't get the sarcasm!
Be sure they will then use this post to proof that Linus moved to FreeBSD, which of course is completely false, but they're not short of one lie anyway, just look at the systemd threads.

Actually either you don't understand what development is, or it's malice from your part and so bad behaviour.
Maintaining code in your application is more work than not having to maintain it. So ripping out code is LESS work for KDE devs. Especially when this code is already taken care of better elsewhere.
It's exactly like with systemd: not maintaining kludges for it to work on sth else than Linux is LESS work, not more.
Maintaining code IS work, old code doesn't just sit there and keep working when all other parts of your code are evolving. Only people that don't understand coding would say such nonsense.
BTW you don't understand what a distribution work is either, as managing the dependencies is precisely the work the distribution has to do, so managing what you call an undocumented dependency in KDE is actually the distribution work.
You could understand that by pure logic: there's only one (or a few) distro that has this problem, despite all of them using the same KDE code base.
FYI, what you call an undocumented dependency is very common in every reasonably big DE, meaning at least XFCE, GNOME and KDE.
I should know as my systems are made from source (yes, I make the work the distros are doing) and I have to deal with that.

No, it's just that you missed sth somewhere: systemd DOES NOT provide root services to users without rights to use those services, this was the situation BEFORE systemd.
Or provide some specific example, none have been given, contrary to what you're saying.

You sound like a stupid and ignorant troll, not at all like a top programmer.
A top programmer would already know everything he needs to know to begin programming a systemd alternative, as eveyrhing is documented on LP site.
People like you are very easy to spot, sorry.

Why do you want to know how to do sth that you have no reason to do and no knowledge how to do ?
Your question doesn't make sense: if you had the proficiency to have a use case for what you're asking, that also mean you could do it yourself.
Only a fool would ask how to do such a thing, as you then would be unable to support such a setup yourself.
BTW, such a setup would only make your life painful without any benefit at all.

I must be pretty efficient then, as at home (and sometimes at work) I run all my servers with my own LFS-like systems all made from scratch, and I don't spend anymore an afternoon building a tool. Setting up everything took its time, but I do this since 15+ years and have no intention of going back to any distro, no one could answer my needs, not even Gentoo.
I master everything that is on my setups, which are so complicated (not really) that distros only recently started giving some features I use for more than a decade.
And I jumped to systemd since the beginning, I abandoned the security and usability nightmare that was init scripts from the start 15+ years ago.
The distros have no choice, because they must try to cater to every situation (which is impossible to do) with their scripts for people that are no sysadmins.
When you have your custom systems, it's far easier to tidy everything, but init scripts are still a security nightmare.

When opponents to sth have to lie through their teeth, hoping that noone will go read and understand their links, they're immediately disqualified in my view.
You clearly are not qualified to understand what you're talking about, but at least you made the work to fool people that won't ever read the links provided because they're not qualified either. Unfortunately for you, some people will read them. And they'll see your lies, which explains why you posted as AC.

No, systemd doesn't have such a thing, and LP never said what you're saying. The link show a very non civil hater (the systemd devs kept their cool), that wants the devs to tackle at high priority an unsupported setup, which became badly handled by systemd because of a kernel change. One thing that is legitimate, is that systemd should at least gracefully quit when in such an unsupported setup. Which has been done and fixed by the systemd devs. They asked for a patch from the guys who insist on using an unsupported setup, and of course, never got anyhting, and had to do it themselves. Classic "the setup you told me won't work, that's what I want to use, or systemd is crap". Why a sysadmin would do that, I can't understand.

Another big lie, systemd has nothing to do with this problem, it's only Gnome Shell that is the problem in some distro setups, and that was introduced because users were locked out of their desktop. To sum it up, Gnome-shell made a kludge to remove the security systemd provides, so as not to lockup users.

Yet, the true sysadmins that reported it managed to provide logs and debug the systemd-208 version, which is the version we're talking about here, which is an arbitrary version that some distros took as a supported one in their distro. LP never said anything of what you're lying about here, especially as what you say makes no sense when PID one segfaults, then the core deump is important, and that's one of the thing that has been provided by competent sysadmins, not by incompetent whiners. This bug has been fixed in the 208 version used by this distro, using true debug means recommended by systemd devs or distro maintainers, not your nonsense. The upgrade was also fixed by the distros, as they were in charge of supporting the version, with the help of systemd devs.
And yes, it happened once with a systemd version, that it crashed on live updating itself.

Actually that's not true at all, it will boot just fine. It's just a clueless user there that tuned his laptop with an antiquated configuration that is static instead of dynamic, and perhaps that's Debian's fault. There must be a long timeout, but eventually, he would have arrived to emergency console.
Systemd is dynamic if you use its native tools, not if you use the compatibility static tools of Debian. But it boots just fine without ethernet.
It's pretty clear this user didn't know what he was doing.

LOL! You didn't understand anything about what's talked about there. You people are so clueless it's ridiculous. A distro default configuration choice became "systemd distros can not boot if using certain DNS servers", and it has nothing to do with booting. This post I thought was serious, but it's a compilation of lies.

The exact same nonsense as above, you didn't understand anything of what's talked about.
For those that don't know, the upstream package has default servers configured for systemd specific ntp client and client resolver. These you can reconfigure as you want, which every distro does, and everyone who is not pleased by the defaults (which should be considered like examples) can change them at configure time (like I do as I install everything from upstream sources, except at clients). So the people complaining are just people that are completely clueless and have no idea of what they're talking about.

This infamous configuration problem has been fixed more than one and half years ago, and is not about storage preventing booting, but about amount of logging stalling everything. You should use past tense or else people will believe these are current problems.

Systemd can't disable SysRq keys, and it doesn't, but it configures some sysctl defaults upstream which is the correct kernel mechanism to use.
Then, the distro makes the choice of their own default, which at least Debian did.
But you have it backwards, these defaults are for security and to ensure no data loss, not to ensure data loss, which makes no sense.
And yes, it's true that the upstream systemd default prevents you from killing a fsck that started at boot for whatever reason. It is not coded to do that, it is configured by default to do that. You and distro maintainers can change these just fine without knowing any line of code.
Like said in the link, you can still shoot yourself in the foot with systemd if you want.

So if that's why people hate on systemd, then that means "Windows-like" is well defined. Could you explain what it means, because I've absolutely no clue at all at what it means. Then I'll be able to understand better what systemd haters want exactly of systemd, and if it's legitimate.

I don't know if that's true, but one thing is true: DE didn't gained popularity from sysadmins but from developers or desktop users.
Do you imply DE have no place on Linux, and that people hate them as much as systemd?

Exactly, that's why sysadmins hate sysvinit and init scripts.

No, you're mistaken. If that's what you believe when you're using systemd, it's not actually systemd the problem, it's you that is not a real sysadmin like you thought you were. I understand it's a terrible realisation and why it would make people hate systemd.
A system with systemd is actually more stable, simpler and with a better ability to understand the system.
The problem is that lots of people that thought they were sysadmins never took time to get the ability to understand the system.
Now, the migration to systemd shows them how little they know about system administration.

So you really hate desktop users (and Desktop Environments) and you don't want to see them on Linux. Fortunately for freedom and other Linux users, you have no power in this matter. I didn't understand the link between your thirst sentence and the second one: how does making it easier for desktop environment developers undermine the primary use-case of Linux? I don't see it myself, and I don't even know if server is the primary use-case of Linux, though it may be true. My servers work far better than before with systemd, and my desktops too. I didn't know improving both was mutually exclusive.

I'm a Linux user (and more) and I agree with you, that's why I use systemd on GNU/Linux.

Every single part of systemd can be installed on any system. Make them work correctly without systemd as PID1 is another story. Some will work, some won't.

Embrace and extends doesn't worrk with Free Software, so you don't understand what Embrace and Extend is.

What you say can only mean two things: either you're making up things, or you're incompetent at what you try to do.
The fact that you're very vague about your problems, not at all like a sysadmin would be, makes me lean towards the second option.

Really, you people are a joke. We're talking about changing the local time through a DE, and your answer is: there is no problem, just change an environment variable (so not in the DE and the DE's session won't be aware of it) that need you to restart the DE session to be effective, or just let ntpdate then ntpd do the thing (so has nothing to with the DE, requires elevated privilege and knowledge far outside manipulating a DE UI).
HELLO? Are you understanding what people are asking here?
Oh OK, your answer to the DE is that we've gone many years without support for UTC (what nonsense is that?) so they don't need any of the thing they're asking for, you know better than them of course.