- cross-posted to:
- linux@programming.dev
- cross-posted to:
- linux@programming.dev
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 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.
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.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.