Because systemd confuses a lot of things by having two projects with the same name.
Systemd the init service is excellent.
Systemd the catch all for trying to rewrite all services to come up with a baseline version of everything is a strange and NIH project. They would have been far better off politically by coming up with a spec and seeing if they could submit patches to get the current services to use the APIs they were planning.
Instead they just have a bundle of things they have tried to reinvent, some more successfully than others. Hence the divisions in the communities.
I'm not sure if it was linked from there, but somewhere in the discussions the systemd devs' recommended fix was for screen/tmux/anything else affected to add some systemd integration for their new API.
As far as I'm aware the complaints about this stopped only because distros override the setting, while it's still the default for stock systemd.
I've been impacted by this particular "issue" and while it's changing the way "decades of convention" it's not really a bad thing imo. Running things via screen and tmux as a solution to background tasks has always been a huge hack imo. Not only that but the alternative approaches with nohup and disown also have their own issues. Imo it's actually pretty reasonable to need to work work the OS service manager to run background tasks, even with tmux and screen.
Those were just the most prominent things, which were immediately noticed because it's completely normal to leave them open remotely to maintain context for something and quickly pick it back up when reconnecting. It's kind of their whole purpose. But the change affected everything, including for example the "daemonize" program.
Okay so back in ~2000 the audio system in Linux was ALSA and it kinda sucked so along come a guy named Lennart Poettering who wrote pulseaudio which improved things in a lot of ways but also kinda constantly didn't work. Poettering in those years constantly blamed everything on other software in the stack and became kinda wildly disliked. We all had to use pulseaudio though because everything important decided to integrate it.
Jump forward to systemd and absolutely none of trust Poettering farther than we can throw him. At the same time systemd basically did the job of half a dozen programs which offends a lot of people on philosophical grounds. Simultaneously a bunch of things start hard requiring this program that people neither trust nor like.
Well, for ALSA and pulseaudio, the latter more or less just surfaced the tons of bugs in the underlying, at the time very shitty audio drivers. Remember, only pulseaudio is a sound server, so ALSA wasn't even exercising many of the more "advanced" features, and drivers were only supporting the most basic stuff.
That's at odds with the fact that pulseaudio is incapable of exposing the audio reference clocks from sound hardware, which is a fundamental aspect of digital audio engineering. Its design doesn't even acknowledge the existence of an audio clock.
That's fine for basic audio but completely excludes any higher demand application, including high quality A/V sync. Best you can do is work around and best effort guess.
Considering pipewire was a drop-in replacement for pulseaudio with (almost*) full compatibility and none of the stability issues (you can even use the pulseaudio commands to control it), the problem was definitely in the pulseaudio code.
* I do remember reading there was one feature they intentionally dropped because it was extremely rarely useful and could be handled in a different way, but don't remember what it was.
So one audio server managed to provide a shim for another audio server, great.
But it absolutely doesn't follow from that that pulseaudio was somehow bad. There was more than a decade where audio drivers were slowly getting bug fixes to get to a state where they are working okay for the most part. Pipewire would have experienced many of the same issues as pulseaudio, and we would similarly attribute those errors incorrectly to the audio server.
My laptop would regularly freeze and need a hard reboot, and I never could figure out why. One day for a completely unrelated reason I decided to try switching from pulseaudio to pipewire, with no other changes (including no other upgrades; I'm lazy and like stability), and months later I realized it hadn't frozen at all. Still hasn't, years later. The problem was definitely pulseaudio making the whole system unstable, not just causing audio issues.
Yes, but people learned from issues that pulseaudio had and then came pipewire. Everyone is happy now.
I don't know about the philosophical aspects, but from pure technical point of view systemd brought some order into the mess. Before systemd it seemed like most distros were barely holding together with duct tape. Systemd standardized a lot of things.
I am fine with a little bit of controversy if the result is a much better desktop OS experience for the user. And as a relatively long time Linux user, I can certainly say it is much better now than it was 20 years ago.
> Yes, but people learned from issues that pulseaudio had and then came pipewire. Everyone is happy now.
Yes, I'm very happy that it mutes my audio when I accidentally unplug my headphones (something which I never asked for) and then often fails to unmute them when plugging them back in, something which requires digging up alsamixer to fix because pulse/pipeware-based GUI tools are being lied to about the output not being muted.
I'm also especially fond of having to open the audio settings app to change audio from one display output to another because some very smart person decided to group all display audio (which are separate ALSA sinks) into one output with different profiles.
But lets not forget that it at least simplified configuration. So much that GUI tools basically don't let you configure shit at all and you need to use one of two (yes, one was not enough) turing-complete configuration languages to accomplish anything slightly non-standard like giving outputs are better name than what your display manufactures cat produced while walking over his keyboard or hiding some of the bazillion useless audio devices that you might end up with somewhere in your PC.
And then of course it still has the PA-innovations like audio randomly stopping for no reason at all until you restart the daemon.
Meanwhile ALSA with an up to date default dmix configuration worked just fine.
When it comes to incorrect profiles, I suggest making a pull request to alsa-project/alsa-ucm-conf with correct configuration. I had similar issue with my audio interface a couple years ago but it was quickly merged and now it works better than on Windows or macOS.
Before that I did have custom config, it was not that hard to set up, there are great examples and explanations on Arch wiki: https://wiki.archlinux.org/title/PipeWire
So he creates a program that was good enough that pretty much everyone started using it.
And he complained about a lot of dependencies but then went and actually wrote fixes/solutions for them that was so good that nearly everyone started using and even depending on it.
It sounds like the people who were sitting on the sidelines complaining about his complaining had ample opportunities to write better alternatives than the programs he wrote but didn’t do so. Instead they relied on character attacks and FUD (well, except the folks who developed pipewire), while Poettering wa engage in elite hacking by implementing solutions and letting users and distro makers decide whether they wanted to use those solutions.
A son of GDR diplomats, according to an old version of his Wikipedia page. That information seems to be memory-holed now. Now you only find that he grew up in South America without any hint of a reason.
Look, I was in CS101 back in those days so I'm not really qualified to say who was right about where/with-what responsibility for bugs lied. Maybe he was completely right and just kind of a dick about it. I'm just reporting that no one liked him and that carried over to the introduction of systemd.
It is a fantastic init system/service supervisor. My problem with it is basically everything else. I think its developers see systemd as central to the entire system, basically the userspace counterpart to the kernel. I prefer the approach of 'dinit', but I understand why they designed it that way.
Due to this design they often have underspecified interaction between the different components, since the assumption is that everyone will use largely the same baseline systemd environment and as long as it works, who cares what it does underneath. If the different parts were more independent, they would be forced to develop a cleaner API contract between them.
I will add this:
if you treat systemd as one trick pony and use for few use-cases which developers envisioned - it run flawlessly, but moment do something not in this path prepare for problems and inferior experience (example of randomly picked tool: timedatectl - no force update date like ntpdate command, you cannot quickly insert ethernet cable update date and disconnect... need to wait for synchronization)
It violates the Unix philosophy of 'do only one thing and do it well', but personally, it has never been a problem for me.
I had a nightmare last week wherein I read a headline that systemd was writing its own kernel. When I woke up I realized it was a possibility, after all it has replaced GRUB. https://wiki.archlinux.org/title/Systemd-boot
Linux kernel, X server, web browsers all seriously violate the Unix philosophy.
And to be perfectly honest, it's nothing more than a philosophy - it's not some universal truth, e.g. a browser by definition is not doing "one small thing" and complex workloads are better organized by monolithic software to a certain degree.
I've noticed a trend that the same people who complain systemd does too much also have a strong affinity for the X server... with it's built in print server!
There is a lot systemd violates in regards to the traditional Unix philosphy rules. The one about do one thing well is probably the most arguable though since systemd is more a set of functionality across a ton of binaries, each with a more focused purpose. Where it differs is in how those interact vs a "normal" collection of Linux binaries where it's expected to be easy to swap out an individual component and still talk to the rest without implementing things like binary formats.
> It violates the Unix philosophy of 'do only one thing and do it well'
How? This is really where it's basically a marketing fail.
Even your own link for system-boot shows that it is it's own rebranding of gummi-boot. It's not part of the init system, they just have an identically named project which has 100 utilities in it. It's dumb and it's community hostile.
Funny how people in this topic at the same time complain about systemd being multi-featured and then complain about abandonment of X11 in favor of of the more focused Wayland. :)
It seems to me that the real differentiator is not the number of features but software release date :)
With unified kernel images there is no need for grub or any other bootloader anymore. And UKI simplifies boot configuration and helps improving security in some aspects.
It's not that it does too much it's that it's monolithic (you can't necessarily swap out components) combined with the fact that the project is gradually subsuming more and more of the userspace utilities. Having the entirety of the userspace half of the OS under a single umbrella seems like a bad idea.
I think it came from the necessity for rapid integrations between different parts of the OS. And if it is handled as a single project it takes less time to improve it, since you don't have to align with 10 different projects and their release cycles.
The way it's structured (combining many previously separate utilities into one) hinders competition. That's tolerable while it's still one of the best solutions for the things it does, but will become an issue in the future.
Why would they care about any other views but their own and those who contribute either financially or through code? Seems like all people can do these days is complain on github, X, mastodon, reddit, HN. It's only talk, talk and more talk, but no do.
Why should the community accept them as a mandatory dependency for every desktop if they don't? This is RedHat shitting up the Linux desktop we're talking about, not some hobby developers releasing things in their free time.
I wasn't there but from what I understood was that people didn't like the fact it was re-inventing an already-existing wheel. In the long run it was useful for some (at least for me it was).
I don't understand that as you don't usually interact with systemd in a container. If Flatpak does end up depending on systemd, then that'll make Flatpak less useful for containers.
I don't know recently, but at the time that systemd was shoved through our throat, you could look at the source code and it was a giant ball of horse shit. Following bad practices, hard coding things, ... With absolutely strong tendency to not give a shit about feedbacks from others, and supporting anything except the highway case that is the only one that they cared about.
And as anyone could have expected, systemd broke a lot of things, and sometimes very badly with their shitty code. Like this time that they wiped the nvram memory of laptop transforming them into bricks...
Systemd the init service is excellent.
Systemd the catch all for trying to rewrite all services to come up with a baseline version of everything is a strange and NIH project. They would have been far better off politically by coming up with a spec and seeing if they could submit patches to get the current services to use the APIs they were planning.
Instead they just have a bundle of things they have tried to reinvent, some more successfully than others. Hence the divisions in the communities.