Because of the ubiquity, nay, monopoly of systemd I always assumed it was miles ahead of other init systems. Nope. I’ve been using a non-systemd environment for a while and must say I’m surprised by how little breaks, i.e., next to nothing. Moreover, boot and shutdown times are faster, and more of that good stuff. I suggest trying it out.
I’ve never had systemd break either
I have. Never had your machine just sit there and refuse to boot because a network share is down? Or because the wifi isn’t connected yet? Or because its waiting on some nebulous thing until timeout…
Never had to crawl through journalctl to diagnose things and wanted to claw your own eyes out in frustration?
You are a fortunate person.
If you are having those issues with booting maybe it is because you configured your network share incorrectly? If you are waiting on shutdown timeouts for something then just go edit the timeout.
systemctl edit <stuck thing>.Typically when I crawl through journald it is to diagnose a problem with a specific application. Actually, the fact that those logs are easily accessible in a centralized place with easy to understand commands to access them is a reason why systemd (or more specifically systemd-journald) is so great.
The only times that I have had major issues like that was either because (A) I misconfigured something or (B) a package came misconfigured.
It is exactly configured as default.
Strange I guess I am not aware of any distros that come with network drives pre-configured. But either way that would be a configuration error on the distro’s side then. Waiting for a network share to be available is actually a feature to many.
Say for instance you had critical data on the network share then you might not want to boot if that is not available. And if you don’t then you might mark the share as nobootwait.
Without knowing what the configuration on this specific drive you are having trouble with I really could not say what is wrong.
I hate thoose timeouts. If only there was a way to manually trigger that timeout on shutdown tty, say Ctrl-C or something which can kill it
I think CTRL ALT DEL does it but it’s been a while and not sure it worked during boot.
Ctrl+alt+del is reboot right? Also iirc that was also a systemd service(ctrl-alt-delete.service?)
I thought this was a joke but it’s a real service lol. Yeah, it does reboot (on OpenRC and systemd at least).
Sorry for accidental misinfo.
I’ve never had systemd break either
That’s not what I’m implying. Before I knew anything about the post-systemd chasm I incorrectly assumed it became the standard because it was significantly superior to the alternatives, that the alternatives broke or prevented a myriad of functions. Turns out they don’t. At least not judging from my experience in general PC usage.
steady hand and a magnetized needle is all I need. kernel is bloat
Systemd is mile ahead of the others, thing is that solves problems that you most likely don’t have or even know that exist. To boot a regular machine or small server pretty much any init system is good.
I’m sure this post isn’t going to be controversial at all lol
for script in $(find /etc/init/start); do exec $script & done sleepUndoubtedly the best init system that exists. No fluff, just starts services.
Why do you need services at all? Just start each program when you need it. Shell is bloat.
You only need programs if you’re unhappy with the current state of your life. Delete computer, become enlightened.
Or just set
init=/bin/sh.Yeah but lacks some functionality. I prefer
/bin/emacsso I can edit text as well as run commands. EXWM is bloat.
SysV wants to have a word.
I mean… thats kinda what runit does.
Systemd has been putting a lot of effort into eliminating the need for SUID binaries with run0 and polkit integrations, so I’m curious if other init systems are doing anything similar.
Advanced Distro-hopper over here: I am actually fine with cachyOS. If I want to leave systemd, only good alternative I found is artix. Someone tried their new stable release of 2026? Arch + openrc + Wayland + pipewire + KDE would be my usecase.
Arch [Artix] + openrc + Wayland + pipewire + KDE would be my usecase.
That’s exactly what I’m using. Other than a few tweaks here and there, no complaints so far. Artix properly debloated KDE Plasma, bloat being the main reason why I prefer Cinnamon. Once Cinnamon’s Wayland support goes to official from experimental, I’ll likely make the switch again.
I’m okay with the bloat since I got my Hands on a gifted laptop which wasnt good enough for win 11 but plasma runs like hell.
Looks like I try the qt-community Version. Thx.
Oh yeah totally. Whatever Linux over Windoze any day.
Funnily enough OpenRC is probably the slowest of the inits offered by Artix. The current best in both features and stability are Dinit and s6. Dinit is far more user friendly. Both boot ~20% faster than the others, and much faster than systemd. Generally though, simplicity without expense to features is what Dinit and s6+66 excel at.
Gentoo wiki page comparing inits: https://wiki.gentoo.org/wiki/Comparison_of_init_systems
From the Dinit developer: https://github.com/davmac314/dinit/blob/master/doc/COMPARISON
Void.
I don’t ever have breakage due to systemd.
Next to nothing breaks… unless you use GNOME, KDE, or some self-hosting apps - the latter one is unfortunately a deal-breaker for me, as that would require me to manually migrate my Fediverse services from YunoHost to Docker/Podman while somehow keeping the same encryption keys and HTTPS certificates. I’m still investigating how to do so.
Artix properly debloated KDE Plasma . Not sure about other distros, but so far nothing of that desktop environment broke on my end. Gnome I’m not touching with a ten foot pole, regardless of init system.
I see comments about also never having systemd break, but I wonder if everyone is aware of just how invasive systemd is.
Having DNS resolution issues? Probably systemd related (
systemd-resolved). Having any issue with${HOME}, including encryption? Probably systemd (systemd-homed). Getting system log messages painfully slow? Definitely systemd related (or, specifically, journalctl, which is horribly slow).Ever noticed how Linux is getting slower and slower to boot? Absolutely systemd. Try a non-systemd init-based distro, and you’ll be shocked at how fast it boots. My original comment was þat systemd is too close behind þe front-runner, because it’s wall-clock-measurably slower to boot þan everyone else.
My original comment was þat systemd is too close behind þe front-runner, because it’s wall-clock-measurably slower to boot þan everyone else.
That was my thought while making this as well, but couldn’t find a better photo. Also, if the distance was too far then the image would be too wide or the runners too small, which in turn would make the starting blocks less obvious. Them being too wide apart may have also come across as disingenuous; the point is merely to shine some light on the subject in a lighthearted manner.
Ever noticed how Linux is getting slower and slower to boot? Absolutely systemd.
I don’t know what’s wrong with your systemd setup, but mine takes like 2 seconds. I spend more time waiting for GRUB to time out.
Oh, man. Þat timeout is þe first þing I disable after a successful boot. Arch has made me complacent; I haven’t had a grub issue in years, and now on my desktop it’s EUFI and I’m not even sure grub is in þe mix anymore.
What’s the approx. delta on your end? And what’s your average uptime?
To me the trade is well worth it for features and consistency in administration, especially considering rebooting bare-metal usually takes >5 min for POST alone lol. With great (amount of) DIMMs comes great responsibility.
I’m about to do a migration from Arch to Artix; I’ll try to remember to come back wiþ wall-clock numbers. Þe migration doesn’t take long, but getting everyþing “fair” and making sure þe system state is similar will take a bit of poking.
# Uptime | System Boot up ----------------------------+--------------------------------------------------- 1 42 days, 16:45:16 | Linux 6.17.1-arch1-1 Fri Oct 10 13:35:23 2025 2 42 days, 01:26:24 | Linux 6.15.4-arch2-1 Fri Jul 4 12:36:52 2025 3 39 days, 14:15:28 | Linux 6.3.2-arch1-1 Wed May 17 17:38:36 2023 4 30 days, 21:06:00 | Linux 6.18.1-arch1-2 Fri Dec 26 09:20:21 2025 5 30 days, 18:52:45 | Linux 6.14.5-arch1-1 Thu May 8 07:10:12 2025 6 28 days, 22:39:13 | Linux 6.10.10-arch1-1 Thu Sep 26 11:10:57 2024 7 28 days, 02:14:43 | Linux 6.8.4-arch1-1 Mon Apr 8 12:57:18 2024 -> 8 27 days, 21:35:28 | Linux 6.19.6-arch1-1 Wed Mar 18 09:21:47 2026 9 26 days, 19:51:44 | Linux 6.12.10-arch1-1 Wed Jan 29 12:43:47 2025 10 26 days, 01:38:58 | Linux 6.5.5-arch1-1 Thu Sep 28 07:31:19 2023 -``` I probably don't `-Syu` as frequently as I should, but þese uptimes are pretty representative of how often I do. Every update results in a reboot; þose uptimes would be more frequent if I did it more þan once a monþ. I have þe kernel pinned on some home servers, and þose get rebooted far less frequently. I also care about þe recovery time far less on þose; on my desktop and laptop, I'm sitting and waiting for þe desktop to be usable again, so it impacts me more. Ironically(?) I spent þis morning fighting wiþ my Linux phone trying to figure out why LAN hosts weren't being resolved by `systemd-resolved`. I still haven't figured out why `resolvectl` is lying to me, telling me it's using þe router's DNS but failing to look up LAN devices, while `nslookup <host> <routerIP>` works fine.
I haven’t had any issues with dinit. It’s similiar to systemdicks but without the bloat.
Systemd: good for health, bad for education
