Why does systemd need to mess with user processes and home directories? It was billed as a replacement for init.
* made debugging a random system a lot more straight forward
* made putting up software for packaging a lot easier
* made customizing the start-up of a daemon a lot easier (this ties in with the first point)
* made it so I didn't have to go to the guru who's only job seemed to be managing our obtuse set of init scripts that were extra baroque because order of startup really mattered.
That guy I had to go to - he was an asshole an lorded his knowledge of arcana over anyone who brought him a question. I'm 90% sure he made it intentionally complex since he didn't have much skill beyond memorizing those silly facts (this is the same guy who got an entire project reassigned to me because he couldn't understand the concept of functions when I removed some extreme repetition from a python script he wrote). Most of the systemd haters remind me of this guy.
I guess what you're implying is that he helped automate away dead weight and that made the leeches mad?
FTFY
systemd might be sad but makes the simple case simple. sysvinit makes everything complex and error prone.
To his, credit he is reactive until he decides the issue is not worth his time.
To his discredit, he made himself into a giant bottleneck. Random systemd users can not easily understand it.
The SysV init scripts weren't good, they were crufty and slow, and messy when you wanted to customize something, and -- this doesn't get said enough -- used no Linux-specific features at all. Systemd was an upgrade that was sorely needed, and brought features to the init system that just didn't exist before.
Where you had ultimate responsibility for the correct operation of the box and any VMs or services that it ran?
The reason I ask, is that despite running many more non-systemd than systemd boxes over the past 22 years, I have had far more time taken up by systemd issues than issues with other init script systems. And that includes Solaris both sysV and SMF based.
I personally wouldn't touch a non-systemd system if I didn't have to.
The thing they did to piss people off was breaking with UNIX tradition and not prioritizing simplicity. This makes them hated by enthusiasts, tinkerers, people who don't trust tech, etc, and loved or just passively ignored by corporate sysadmins, non-hobbyist everyday desktop users, general devs just trying to make modern software, etc.
It's kind of an unsolvable conflict. People who want simplicity are looking for something very different from people who want everything to just work and never require looking under the hood.
I just think Poettering's (and, more generally, Red Hat's) taste is really bad, so I wish it weren't him(/them). Possibly when they finally achieve Systemd/Linux and the entire stack atop the kernel is stuff Red Hat likes & directs it'll all be worth it, I dunno.
FWIW I also haven't much cared for a lot of Ubuntu's attempts to steer the direction of Linux—they've just lost so badly at every attempt, that it hardly matters.
I'm actually not even fully sure on the details what they even do that isn't in Debian aside from maybe some driver stuff and assorted annoyances like Snaps. I just know to stick with Ubuntu derivatives because almost all large popular apps seem to be well tested and designed to work on it, until the community gets tired of it and probably Fedora or something takes over.
It's the perfect example of "I'd rather have a mediocre standard than something excellent but obscure".
I'm not a fan of Pulse, because of its lack of low latency, although It still offers a lot over raw ALSA, and PipeWire solves basically all of it's issues.
But systemd is a lot more comprehensive, it doesn't seem to leave any use cases out, aside from ultralight embedded and old school "Control everything yourself with imperative scripting" style setups.
My guess is that if PulseAudio had came later, it would be called "systemd-audio" or something like that.
If it dynamically creates systemd units or sets their properties (systemd-homed, systemd-networkd, systemd-resolved) using the dbus endpoints, it's systemd-something.
If it uses systemd libraries and lives in the systemd repo because it shares baseline docde, it's systemd-something.
systemd is modular in the sense that those components are build-time flags. For homed, for example: https://github.com/systemd/systemd/blob/main/meson_options.t...
Again, not confusing. Literally looking at the systemd repo for longer than 30 seconds would show you both why this it's considered modular, and why it's systemd-whatever
Pulse doesn't.
It is because systemd confuses what should be split concepts into one big overarching thing.
'org.freedesktop.systemd1' (the actual systemd init D-Bus interface) somehow is still implied that it is vital to the entire systemd-something ecosystem while it's not really.
A example being systemd-hostnamed and hostnamectl complaining that 'System has not been booted with systemd as init system (PID 1). Can't operate.' [1] while in fact they use 'org.freedesktop.hostname1.${something}' [2] and that is supposed to not be bolted with the entire rest of systemd besides using sd_bus.
[1] https://github.com/systemd/systemd/blob/93258c7d72fae23c9f81... [2] https://github.com/systemd/systemd/blob/93258c7d72fae23c9f81...
hostnamectl DOES talk to sd_dbus, which DOES require systemd, which DOES require being PID1, and this message only pops up if you're in a container without the full subsystem running, access to the right cgroups, etc.
The naming is simply part of how dbus structures things, not to say that it's not part of it. I'm sure that, in retrospect, they wish they would have used "org.systemd...", but hindsight is 20/20.
If there's a scenario other than container without the right mounts/etc where this can come up, you should file a bug. If there isn't, you could see if you can submit a patch to improve the message.
It's not an indication that systemd confuses concepts. Its can indication that a) dbus is kinda shit, and b) I doubt if the systemd mapped out hypothetical dbus names 5 years in the future.