The fact that the next blog post (linked at the bottom of the article) is titled "a desktop for all" is deliciously ironic in context.
For all in this context does not mean “all the infinite combinations of software for people that refuse to adopt the status quo” systemd is here to stay. It is ludicrous to imagine everybody to keep supporting that 1% that is ideologically opposed to it, no? As those people love to say, open-source is written by volunteers, you can always fork it.
Introducing stronger dependencies on systemd
51–60 of 179 posts
Re: Introducing stronger dependencies on systemd
#52I have yet to hear an argument against systemd which isn’t a variation of: - """bloat""" - I dislike Poettering. Remember pulseaudio? - a core user-space layer for modern applications that can’t only rely on the spartan kernel syscall API? Literally 1984. Given that systemd is good enough and is running on 99% of desktops and servers, I always find it hilarious to see how the vocal minority is overrepresented on this…
[flagged]
Re: Introducing stronger dependencies on systemd
#53Re: Introducing stronger dependencies on systemd
#54I just registered for comment here: they always refused to admit it (by "they" I mean Fedora/IBM) but we will end up having a Gnome OS for the general public... And I'm afraid the 3E rule is starting to be applied (Extended already, Embraced in all the "other OS" and now...)
[flagged]
Re: Introducing stronger dependencies on systemd
#55I have yet to hear an argument against systemd which isn’t a variation of: - """bloat""" - I dislike Poettering. Remember pulseaudio? - a core user-space layer for modern applications that can’t only rely on the spartan kernel syscall API? Literally 1984. Given that systemd is good enough and is running on 99% of desktops and servers, I always find it hilarious to see how the vocal minority is overrepresented on this…
Re: Introducing stronger dependencies on systemd
#56I have yet to hear an argument against systemd which isn’t a variation of: - """bloat""" - I dislike Poettering. Remember pulseaudio? - a core user-space layer for modern applications that can’t only rely on the spartan kernel syscall API? Literally 1984. Given that systemd is good enough and is running on 99% of desktops and servers, I always find it hilarious to see how the vocal minority is overrepresented on this…
Personally the last system I had systemd on corrupted my package database after killing apt that I was running in tmux. "Oh you can fix that with xyz systemd configuration." Here's my response:
Kindly shove it up your ass and quit moving things around all the time just because you're board.
Also if "it's good enough for most people" is a decent argument then you should be on Windows.
Re: Introducing stronger dependencies on systemd
#57People want to understand their software as well as it's practically possible. It's not an uncommon preference; worse-is-better was quite successful for a reason. As systemd stands, it's an unauditable mess of tightly-coupled components built to handle any conceivable need. These features create new attack vectors: for instance, systemd-machined credential passing system, which can inject arbitrary files such as keys and configs into the guest, also runs on bare metal. And some are just running a musl system that can't even use systemd.
Some might look at the old SysV init scripts through rose-tinted glasses, but I don't think it represents the current state of the community. We have the modern OpenRC with parallel startup, dependency-based initialization, supervision, network management, and cgroups; dinit, which tries to imitate the 80% of systemd features that people use with 20% of its footprint; s6 with its supervision trees; runit that just works; and GNU Shepherd, which gives you an entire Scheme interpreter to configure your system.
Monocultures are bad because they eliminate competitive pressure for good design and create single points of failure that affect everyone. systemd was an excellent addition to the ecosystem in its day, but has become uncomfortably sticky: you can't just choose to replace systemd; you'll need to reimplement udevd, logind, D-Bus activation interfaces, and now userdb, all of which have their own subtle quirks you'll need to replicate. Look to the state of mdev or elogind and you'll see why it's not a sustainable compromise.
Re: Introducing stronger dependencies on systemd
#58Earlier quoted context omitted.
[flagged]
During Microsoft's most recent shareholder meeting the CEO actually bragged about spamming HN and successfully getting people to use Azure that way. I wouldn't be surprised if they were at least partly behind the big systemd/gnome pushes.
Re: Introducing stronger dependencies on systemd
#59Earlier quoted context omitted.
Read the news. That's why the maintainers forked it and are starting improvements on their own project. https://mail-index.netbsd.org/netbsd-users/2025/06/06/msg032... https://github.com/X11Libre/xserver
> Read the news. That's why the maintainers forked it It looks more like one maintainer, and it's really not clear if his problem was with corporate control, or if he just fell out with everybody.
Re: Introducing stronger dependencies on systemd
#60Earlier quoted context omitted.
who does even compete with Gnome ? it is the de facto default desktop in almost all notable distros. it just works, though it is far less customizable compared to KDE, it is far more stable -still only compared to KDE..
> it just works For some definition of works, like a folder with 300 videos loading for 15 seconds and image viewer unable to open 150MB images. I prefer how Gnome works compared to KDE, but I can't get past the ridiculous performance issues.