Except none of these are true, they're just things people have made up to conceal the fact they oppose systemd for ideological reasons. There's little to no technical arguments against systemd - it's fast, much more robust than what came before it, and services 99% of usecases.
Users DID want systemd. Ask any sys admin, most much prefer systemd.
Also systemd doesn't "force" anything. Most distributions don't even ship all systemd projects, just a couple.
systemd-init IS small. The idea that systemd is a big ole monolith is just not true, and one glance at the git repo reveals that.
oh definitely not, and it's a matter of record. Red Hat and Poettering wanted systemd in order to control more of the platform; this is why they absorbed in udev (which had been a separate repo), came out saying that there are certain parts of the system that, despite all this being open source, were forbidden to modify or replicate, and stacked the debian voting. Systemd at the time sucked, incredibly, even worse than it does today, and routinely bricked or crashed systems. The adoption was forced and 100% political.
systemd is, of course,today a continuing shambling feature factory behemoth in which hundreds of product managers try to shoehorn in more mandatory features in order to cement grip on the platform. That's why you get this ridiculous dns nonsense, this ridiculous container nonsense, this ridiculous cron nonsense, hostnamed (!), the list is endless.
The technical argument is that it's a giant tasteless bag of ever increasing poorly implemented scope. The rest of Unix, by comparison, is generally not that way. If you pick up a BSD or even an alpine, you'll find that you don't need a bunch of badly written, hacked together garbage in order to get your work done. The system can be entirely readable and repeatable without cramming a bunch of cruft and poor decisions into pid 1.
The idea that systemd doesn't 'force' anything is, of course, hilarious. Systemd is designed to try to be the ultimate mandatory dependency for essentially everything on the system. That's the way Red Hat wanted it to be, and that's the way it is.
Every time someone mentions systemd, some random apologist dutifully trots out the idea that systemd-init is small and therefore systemd is not a monolith, checkmate. Of course, journald, libudev, localed, logind, hostnamed, homed, networkd, resolevd, systemd-boot, systemd-bsod, systemd-nspawn, timedated, timesyncd, tmpfiles, udevd, and all of the other array of dumbass bolted-on second-system-effect-driven product-managed nonsense somehow don't get mentioned.
> Red Hat and Poettering wanted systemd in order to control more of the platform
Speculative and ideological. From a technical perspective, I don't care about this.
> despite all this being open source, were forbidden to modify or replicate
This isn't true - you're allowed to modify or replicate any parts of systemd and always have been.
> systemd is, of course,today a continuing shambling feature factory behemoth in which hundreds of product managers try to shoehorn in more mandatory features in order to cement grip on the platform
I'm not sure you understand what systemd is.
systemd is not a piece of software, systemd is an endeavor. Many, many projects are under "systemd", as in they have the name, but they are all individual binaries. Practically 0 distros include all systemd binaries, because they're optional. Many projects already existed before systemd, like gummi boot, and were just given the name.
> The rest of Unix, by comparison, is generally not that way
This is untrue, as systemd follows unix principles. systemd-init does one thing and one thing only - it's only the init system. systemd-networkd is just the network daemon. systemd-journald is just the logger. And on and on. Despite what you may think, they ARE optional, and distros mix and match constantly.
> without cramming a bunch of cruft and poor decisions into pid 1
Again, out of the dozens and dozens of binaries under the systemd umbrella, only one (1) runs under PID 1. This simply isn't true.
> Systemd is designed to try to be the ultimate mandatory dependency for essentially everything on the system. That's the way Red Hat wanted it to be, and that's the way it is
Speculation, ideological, and not evidence backed.
> Of course, journald, libudev, localed, logind, hostnamed, homed, networkd, resolevd, systemd-boot, systemd-bsod, systemd-nspawn, timedated, timesyncd, tmpfiles, udevd, and all of the other array of dumbass bolted-on second-system-effect-driven product-managed nonsense somehow don't get mentioned
Yeah... because those are separate programs. Maybe you just don't understand how computers work, but these programs are unrelated. They talk over IPC, they're not even linked together on any systems. You can take or leave any of them, and many distros do. Even Debian, the supposed systemd cocksucker, doesn't include half of these.
Users DID want systemd. Ask any sys admin, most much prefer systemd.
Also systemd doesn't "force" anything. Most distributions don't even ship all systemd projects, just a couple.
systemd-init IS small. The idea that systemd is a big ole monolith is just not true, and one glance at the git repo reveals that.