The effort of dealing with the increasing amount of software that expects systemd to run underneath makes all these initiatives not very worth it unless you buy heavily in the political, rather than technicals reasons, of avoiding systemd.
I don’t care. I have run Linux machines since 2001 and systemd is one of the least offensive reinvention of the wheel I have had to deal with. All software is shit one way or another, all that matters is how much effort do I have to spend to find myself dealing with another, unsupported pile of shit.
Suzuran · 2026-06-30 17:10:32 UTC
"Bait used to be believable."
vekntksijdhric · 2026-06-30 17:12:59 UTC
showing a list of bugs and vulnerabilities is not a compelling case against systemd, or it is a compelling case agains every single piece of software.... providing an argument *why* systemd is bad is what I expect
tim-tday · 2026-06-30 18:27:31 UTC
Agreed. As a previous systemd hater I went there looking for an abstract, high-level argument. I got drivel instead.
One compelling argument I’ve seen is that it tries to be too much which violates the Unix philosophy of small tools doing a single thing well.
After years of using it I have to conclude that it’s here to stay and while not perfect it’s good enough I’m not going through the hell of tearing it out.
ChocolateGod · 2026-06-30 19:00:30 UTC
> I’ve seen is that it tries to be too much which violates the Unix philosophy of small tools doing a single thing well
Usually the same crowd that makes this complaint about systemd also have a strong affinity to Xorg and dislike to Wayland.
Xorg has a print server among many other things. Adhering to the UNIX philosophy is certainly something it does not.
uecker · 2026-06-30 20:25:44 UTC
This is about as correct as saying http is bloated because there are printer protocols using REST.
vivzkestrel · 2026-06-30 17:35:47 UTC
- every software has bugs, even curl does, does that mean you ll start a new website called nocurl.org?
paulddraper · 2026-06-30 17:38:29 UTC
That's a shockingly light list of bugs.
Guaranteed that the replacements would have a combined list at least as bad.
> What most systemd critics consider "bloat", I consider necessary complexity to solve a complex problem generically.
Glandalf · 2026-06-30 18:04:52 UTC
systemd will never be done, it’s a scam designed to make Linux UN maintainable and incompatible and force businesses to buy service contracts from IBM.
tim-tday · 2026-06-30 18:27:58 UTC
wat
_se · 2026-06-30 18:48:40 UTC
Okay grandpa, let's get you back to bed
foxrider · 2026-06-30 18:12:23 UTC
I swear, the more time goes on, the more I disrespect the "no to systemd crowd", not because they don't have valid arguments, but because in recent years it attracted a very *specific* kind of audience, and now it smells bad.
I've used Linux for over 20 years at this point, my first Linux computer was a PS2 console and my second one was a PS3 console. I remember the rc scripts and upstart, and I hated dealing with any of it, systemd, its timers and the user units were the most convinient change in decades. I hear so many anecdotal accounts of "sytemd destroying someone's system", yet personally it was nothing but a pleasant experience.
I think there's always needs to be an alternative, and I welcome anyone who's actually building alternative code paths and doing the work to create the alternative tools, but every time some tool gains a dependency on systemd to improve the functionality and the mob comes in complaining I can't help but get angry. It's open source. You can patch it. You can switch to something else, but instead you hurl insults at people volunteering their time to make software you run better.
cedws · 2026-06-30 21:05:35 UTC
The anti-systemd crowd just seems uneducated to be honest. They still say that systemd is bloated, because they don’t seem to understand systemd is a catalogue of software, not literally everything happening in PID 1.
Moreover none of them really seem to have operated servers at scale to understand why systemd is useful. Your init system is 1000 lines of C? Cool story bro that does literally none of the things sysadmins need to run a server fleet, enjoy gluing everything together with brittle bash scripts.
First noticed with large firefoxen, with many windows and tabs.
But it isn't limited to that, just any larger process-tree suffices for comparison.
Does still apply to current versions and is reproducible on contemporary systems.
Runit and before it DJB's daemon-tools (and derivatives) have been around for a long time.
S6 came later. All rather good stuff, if one knows them, that they exist at all,
and is able to handle them, which isn't really complicated,
because they never had the history of glued together brittle bash-scripts.
Just saying...….
branon · 2026-06-30 18:26:30 UTC
There was probably a case to be made for this stance when systemd was very new and getting shoehorned everywhere but increasingly I don't see the point
I think the issue people took with it was less on technical merit and more about the principle of resisting a change which was occurring too quickly for comfort
it was kneejerk reactionary to begin with and hasn't made any more sense as systemd has improved and received better integration with other software
I do mourn the loss of Upstart though, I thought that was one of Canonical's cooler projects
I also use Void/runit primarily and enjoy it because of its simplicity, it's a nice _exercise_ to run systemd-free but I don't pretend it comes anywhere near the level of capability that systemd provides
dv35z · 2026-06-30 20:01:36 UTC
I'm curious - has anyone found / created easy-to-use Systemd GUI interface?
A bit of context: My specific case is creating timers (similar to crontab). I'm shuffle-playing music playlists at certain times of day. I'm comfortable with terminal/command-line, however the computers I'm building out are used in maker-spaces, where many people are not super technical. This has got me into the habit of thinking "what's the 'easy mode' for a lot of tools. For example, GitHub Desktop is a great way to slow-roll people into using `git` if they have never used it before. I like tools like that. Let me know what you suggest.
Comments
I don’t care. I have run Linux machines since 2001 and systemd is one of the least offensive reinvention of the wheel I have had to deal with. All software is shit one way or another, all that matters is how much effort do I have to spend to find myself dealing with another, unsupported pile of shit.
One compelling argument I’ve seen is that it tries to be too much which violates the Unix philosophy of small tools doing a single thing well.
After years of using it I have to conclude that it’s here to stay and while not perfect it’s good enough I’m not going through the hell of tearing it out.
Usually the same crowd that makes this complaint about systemd also have a strong affinity to Xorg and dislike to Wayland.
Xorg has a print server among many other things. Adhering to the UNIX philosophy is certainly something it does not.
Guaranteed that the replacements would have a combined list at least as bad.
> What most systemd critics consider "bloat", I consider necessary complexity to solve a complex problem generically.
I've used Linux for over 20 years at this point, my first Linux computer was a PS2 console and my second one was a PS3 console. I remember the rc scripts and upstart, and I hated dealing with any of it, systemd, its timers and the user units were the most convinient change in decades. I hear so many anecdotal accounts of "sytemd destroying someone's system", yet personally it was nothing but a pleasant experience.
I think there's always needs to be an alternative, and I welcome anyone who's actually building alternative code paths and doing the work to create the alternative tools, but every time some tool gains a dependency on systemd to improve the functionality and the mob comes in complaining I can't help but get angry. It's open source. You can patch it. You can switch to something else, but instead you hurl insults at people volunteering their time to make software you run better.
Moreover none of them really seem to have operated servers at scale to understand why systemd is useful. Your init system is 1000 lines of C? Cool story bro that does literally none of the things sysadmins need to run a server fleet, enjoy gluing everything together with brittle bash scripts.
( https://smarden.org/runit/ https://www.skarnet.org/software/s6/ )
While systemd may be convenient, and more than a simple init & supervision,
it's still slow compared to runit/s6(6).
Let's say I have a larger process-tree.
Let's say I give it's top, or any thread sighup, lazily out of htop.
Systemd? Takes seconds to tear it down, and restart.
Runit? In an instant. s6(6)? Same.
Just a flicker in the corner of my eye.
There is nothing brittle about https://github.com/skarnet/execline which is a dependency of s6.
Tested initially on almost obsolete systems.
First noticed with large firefoxen, with many windows and tabs.
But it isn't limited to that, just any larger process-tree suffices for comparison.
Does still apply to current versions and is reproducible on contemporary systems.
Runit and before it DJB's daemon-tools (and derivatives) have been around for a long time.
S6 came later. All rather good stuff, if one knows them, that they exist at all,
and is able to handle them, which isn't really complicated,
because they never had the history of glued together brittle bash-scripts.
Just saying...….
I think the issue people took with it was less on technical merit and more about the principle of resisting a change which was occurring too quickly for comfort
it was kneejerk reactionary to begin with and hasn't made any more sense as systemd has improved and received better integration with other software
I do mourn the loss of Upstart though, I thought that was one of Canonical's cooler projects
I also use Void/runit primarily and enjoy it because of its simplicity, it's a nice _exercise_ to run systemd-free but I don't pretend it comes anywhere near the level of capability that systemd provides
A bit of context: My specific case is creating timers (similar to crontab). I'm shuffle-playing music playlists at certain times of day. I'm comfortable with terminal/command-line, however the computers I'm building out are used in maker-spaces, where many people are not super technical. This has got me into the habit of thinking "what's the 'easy mode' for a lot of tools. For example, GitHub Desktop is a great way to slow-roll people into using `git` if they have never used it before. I like tools like that. Let me know what you suggest.