I’m so tired of reading this stupid argument. “People only dislike systemd because they’re afraid of change.” No, there are plenty of other concerning issues about it. I could probably write about a lot of problems with systemd (like the fact that my work laptop never fucking shuts down properly), but here’s the real issue:
Do you really think it’s a good idea for Red Hat to have total control over the most important component of every mainstream distro in existence?
Let’s consider an analogy: in 2008, Chrome was the shit. Everyone loved it, thought it was great and started using it, and adoption reached ~20-30% overnight. Alternatives started falling by the wayside. Then adoption accelerated thanks to shady tactics like bundling, silently changing users’ default browser, marketing it everywhere and downranking websites that didn’t conform to its “standards” in Google search. And next, Chrome adopted all kinds of absurdly complex standards forcing all other browser engines to shut down and adopt Chrome’s engine instead because nobody could keep up with the development effort. And once they achieved world domination, then we started facing things like adblockers being banned, browser-exclusive DRM, and hardware attestation.
That’s exactly what Red Hat is trying to pull in systemd. Same adoption story - started out as a nice product, definitely better than the original default (SysVInit). Then started pushing adoption aggressively by campaigning major distros to adopt it (Debian in particular). Then started absorbing other standard utilities like logind and udev. Leveraging Gnome to push systemd as a hard dependency.
Now systemd is at the world domination stage. Nobody knew what Chrome was going to do when it was at this point a decade ago, but now that we have the benefit of hindsight, we can clearly see that monoculture was clearly not a good idea. Are people so fucking stupid that they think that systemd/Red Hat will buck that trend and be benevolent curators of the open source Linux ecosystem in perpetuity? Who knows what nefarious things they could possibly do…
But there are hints, I suppose. By the way, check out Poettering’s new startup: news.ycombinator.com/item?id=46784572
adespoton@lemmy.ca 2 days ago
It uses a completely different paradigm of process chaining and management than POSIX and the underlying Unix architecture.
That’s not to say it’s bad, just a different design. It’s actually very similar to what Apple did with OS X.
On the plus side, it’s much easier to understand from a security model perspective, but it breaks some of the underlying assumptions about how scheduling and running processes works on Linux.
So: more elegant in itself, but an ugly wart on the overall systems architecture design.
hoppolito@mander.xyz 2 days ago
I think that’s exactly it for most people. The socket, mount, timer unit files; the path/socket activations; the
After=,Wants=,Requires=dependency graph, and the overall architecture as a more unified ‘event’ manager are what feels really different than most everything else in the Linux world.That coupled with the ini-style VerboseConfigurationNamesForThatOneThing and the binary journals made me choose a non-systemd distro for personal use - where I can tinker around and it all feels nice and unix-y. On the other hand I am really thankful to have systemd in the server space and for professional work.
passepartout@feddit.org 2 days ago
I’ve started doing podman quadlets recently, and the ini config style is ugly as hell compared to yaml (even lol) in docker compose.
cecilkorik@lemmy.ca 2 days ago
I agree that quadlets are pretty ugly but I’m not sure that’s the ini style’s fault. In general I find yaml incredibly frustrating to understand, but toml/ini style is pretty fluent to me. Maybe just a preference, IDK.
cenzorrll@piefed.ca 2 days ago
I’m not great at any init things, but systemd has made my home server stuff relatively seamless. I have two NASs that I mount, and my server starts up WAY faster than both of them, and I (stupidly) have one mount within the other. So I set requirements that nasB doesn’t mount until nasA has, then docker doesn’t start until after nasB is mounted. Works way better than going in after 5 minutes and remounting and restarting.
Of course, I did just double my previous storage on A, so I could migrate all of Bs stuff back. But that would require a small amount of effort.
WhyJiffie@sh.itjust.works 1 day ago
what do you use as a prerequisite for the nas A mount? or does it iust keep trying in a loop?
MonkderVierte@lemmy.zip 1 day ago
Lol, no. Way more code in Systemd. Also more CVE per year than in other init/svc lifetime.