Well - the systems presented here are about the init part, not anything else. Systemd includes more functionality than merely init-stuff, so any comparison here was always biased and unfair. If you compare 5_000 lines of code to 500_000 lines of code, the comparison won't work. Systemd assembled numerous things (weed-collection via systemd-homie, for the home setup and I think you can also accidentally delete your home directory, with the systemd devs claiming this is a feature). None of those "features" listed is what I consider needed or necessary. All daemon-startup I already did via ruby as wrapper over the underlying system. For a campus site with many computers, systemd simplified managing them. I don't really see the same benefit for people who know more about computer systems at home - all the complexity is a trade-off with regard to having to learn, understand and apply what systemd brings to the table.

"It's deeply entrenched in every major distro that it's impossible to administer a linux system without it"

That's a non-sequitur, aka an after-the-fact claim made. Not every distribution transitioned into forcing systemd onto everyone - granted, the majority did, but you can find distributions that did not surrender user's rights here, be it devuan, slackware, void, gentoo (https://wiki.gentoo.org/wiki/Gentoo_without_systemd). But admittedly it takes more effort than going into systemd. Note that many of the statements made there such as "hardening options", is just buzzword promo for systemd. It just means nothing. What should "hardening" even mean? Also, it is perfectly fine to use linux on a non-systemd system. People used to do this for decades before systemd infected the linux world. It's a smaller crowd though compared to systemd-using systems and users indeed nowadays.

▲

graemep 5 hours ago | parent | next [-]

> Systemd includes more functionality than merely init-stuff, so any comparison here was always biased and unfair.

The real argument about systemd is whether you want an init system, or what is effectively an additional layer in the OS. It provides more standardisation, vs more diversity. The strongest argument for systemd is that it is not just an init system, which is also the strongest argument against systemd.

▲

ethin 8 hours ago | parent | prev | next [-]

> ... granted, the majority did, but you can find distributions that did not surrender user's rights here...

I really don't like the phrasing of this. Nobody's rights are being "infringed" by distros going with systemd. Especially because, as other comments have noted, systemd is (not) just an init system, and more often than not I have found that people who hate on it or try to compare it to any pure init system are usually both arguing in bad faith and fundamentally misunderstanding what systemd actually is.

▲

blueflow 6 hours ago | parent | next [-]

It is deeply integrated into distros that you cannot run these distros without them, it has bugs that ruin production for you, and if you complain about these bugs to the systemd project, they will consider you a bump in systemd's way of greatness that must be purged.

Most recent breakage: https://lwn.net/Articles/1041316/

I hoped this kind of behavior would stop as soon as Lennart was busy with different things @microsoft (this happened to Pulseaudio and that was a good thing), but Luca continued where Lennart left, and this stuff goes on.

▲

ethin 2 hours ago | parent [-]

You... Do know that this is just a downright weird take, right? Systemd is software. Software has bugs.

	▲	blueflow 32 minutes ago \| parent [-]
		My sentence continues: > ..., and if you complain about these bugs to the systemd project, they will consider you a bump in systemd's way of greatness that must be purged The sentence is not about systemd having bugs, its about how the devs handle bug reports. In the /run/lock situation that i linked, the Boccassi unilaterally declared WONTFIX towards the users whose applications he broke. If i did this at work, I'd get fired.

▲

t43562 6 hours ago | parent | prev | next [-]

That suggests that we cannot be allowed to dislike it. I'm allowed to not like init systems e.g. I don't like s6 at all. Oddly, I don't like systemd either but it's not heresy or stupidity or whatever else one might ascribe to it.

	▲	ethin an hour ago \| parent [-]
		How does what I said suggest that one isn't allowed to dislike it? You are free to dislike it all you want. That doesn't mean that it somehow doesn't solve a ton of problems that prior art either didn't solve at all or was outright painful to actually set up because everything you had to use did things differently and there were 6 different ways of doing something.

▲

yjftsjthsd-h 2 hours ago | parent | prev [-]

> Especially because, as other comments have noted, systemd is (not) just an init system, and more often than not I have found that people who hate on it or try to compare it to any pure init system are usually both arguing in bad faith and fundamentally misunderstanding what systemd actually is.

... Yeah, except that system's excessive and ever expanding scope is one of its bigger problems. Are you sure they misunderstood anything?

	▲	ethin an hour ago \| parent [-]
		Yes? Systemd is not an init system. To compare it to init systems is to make an apples-to-oranges comparison. Systemd's "scope creep" is a stereotypical haters argument and is nonsensical. The 'Unix Philosophy' was a hardware requirement more than a philosophical one because back then they literally couldn't fit more than one program into memory at a time. And, regardless of the hardware or philosophical debate, systemd does actually meat this requirement: systemd itself is just the init part and service manager. systemd-logind is a completely separate service which you can opt not to build and systemd will work just fine. systemd-resolved, systemd-timesyncd, etc., are likewise completely indepeendent programs which just so happen to share the same codebase and are under the same umbrella. Are you next going to claim that coreutils has scope creep because all of the tools share the same codebase? Or busybox?

▲

udev4096 5 hours ago | parent | prev [-]

What a cope. The hardening options highly restrict the unit files from accessing anything more than it's required for it's function. systemd has also made a lot of efforts in progressing the boot security: https://0pointer.net/blog/brave-new-trusted-boot-world.html. Have fun running your "non-infected" systems which is so easy to pwn

▲

zetanor 5 hours ago | parent [-]

To make a comment like this, I imagine that you've set up BIOS security (password, case intrusion detection...), that you check your keyboard wire end-to-end daily, that you use a USB device whitelist, that you regularly check for hidden cameras spying on your keystrokes, etc., otherwise you're equally "easy to pwn" using equally-quick and roughly-as-cheap attacks.

	▲	udev4096 5 hours ago \| parent [-]
		Using luks to encrypt all partitions (incl. /boot) and it's only unlocked using yubikey. I have secureboot enabled (sbctl to enroll keys) and TPM PCR values to avoid tampering. systemd-boot (a lot more secure than grub) doesn't have password to lock the kernel editor so I have disabled the editor altogether. I use fapolicy for "whitelisting" apps. Unfortunately, coreboot doesn't have BIOS password feature so it's unlocked