- 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.
You must log in or # to comment.
steady hand and a magnetized needle is all I need. kernel is bloat
Honestly for desktop usage it doesn’t really matter. All inits have their idiosyncrasies (“A stop job is running for Session”/logging hell on openrc/etc). But for managing a fleet of bare-metal servers I find systemd to be the best, most polished one out of the lot.
Use what works for you.
Develop what scratches your itch.
Don’t tell OSS devs who are volunteering unpaid labor what they should do for you.
If you want a solution that’s non-systemd go for it. If it doesn’t exist make it or pay someone to do so. Write from scratch or fork a project and get to work. That’s the way of the Bazaar.
I’ll be in my unenlightened “things work for me good enough” Linux world using what works. Systemd is fine and rarely gives me problems. Actually, I’m not even sure I can remember any.
Huge thank you’s to the devs who make this all possible. You rock!
Use what works for you.
True, but many don’t know other init systems might work for them because of the same wrong assumption I had.
Huge thank you’s to the devs who make this all possible. You rock!
Definitely. One big ecosystem with a multitude of developers working on a multitude of projects.
Systemd is developed primarily by paid developers.
I think that is a good thing, isn’t it?
Its built antithetically to the unix principles, it uses binlogs, its slow and its a big ol’ bloated mess on low-memory embedded devices, and seemingly is creeping into the whole system.
Also the original author has since fucked off to microslop so I don’t care what he thinks or does.
It, as a project, also bent the fucking knee.
Oh hey it’s the same nonsense people have been saying for a decade now.
First of all, Linux is not Unix, and Unix principles were developed in like the fuckin 80s when what a computer is and does was different from what it is and does today. I’m betting you also use other software that doesn’t follow the ‘Unix’ philosophy all the damn time, like, I dunno, the browser you used to post this nonsense. It was a guiding principle, not meant to be a dogmatic religious ideology. Also it not being the best choice for low memory embedded devices doesn’t mean anything. It was designed for the desktop. These are very different platforms with very different needs. That’s like complaining that the wheels on my car don’t let it fly.
Also, bent the knee to who?
You can get fucked in this thread too.
Really? Okay, so curl. You use it everyday. How’s that using ‘unix’ principles?
You’re just parroting the same old tired arguments.
Curl does exactly one thing and it does it very well.
Systemd aspires to do all the things and does nothing very well.
careful! advocating against systemd in this community will get you branded for heresy. lol
That old load of bullshit again. You could swap out the logs if you want a shittier, less searchable (but text based) logging system. The rest can be countered in a similarly conclusive way, and has been repeatedly in the last decade or so.
Inform yourself before copy-pasting misinformation and misleading propaganda.
less searchable
text based
I don’t know how you reach this conclusion, the format has been standardized for decades.
Can you add more fields? Is there no ambiguity in context switching? No breakage around whitespace?
If so, sure, that’s fine then.
They both get ingested into Splunk (or whatever tool is used by the company) in any context where this would be a problem. It’s one of those things that in practice has never been a problem in my experience.
By the point/scale that context switching, log injection (forging) whitespace is a concern, I’m not piping shell commands. It’s over engineered.
Nah, the issue is accidental corruption, different parsers doing things differently, stuff like that. Happens often with “mostly text but actually some structured data also” formats, doesn’t happen with formats that have well specified framing.
Oh look, someone arguing that their lived experience is different to my lived experience, therefore mine is wrong.
🤡👞
WTF. Saying “it uses binlogs” as if that wasn’t a choice is just a lie. I called it out. Deal with it.
binlogs suck ass, you can’t convince me otherwise. Its slow and shite. Continue to suck.
Read. I’m saying that you lied, not that your preferences are bad.
Systemd doesn’t force you to use binlogs.
its the default, its the default everywhere, nobody is changing that configuration because systemd is a massive blob of nonsense.
Why is it the default?
I’m sure this post isn’t going to be controversial at all lol
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.
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.
Boot speed is meaningless. Having to almost never reboot is everything.
Sleep is your friend.
Sleep doesn’t work well in some environments, like right now my current one using AMD+AMD hardware on EndeavourOS. Therefore I do boot. And couldn’t care less for 10 seconds faster or slower boot times.
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.
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.
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
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.
in theory systemd is faster because it can do things in parallel
After over a decade using systemd in arch and Debian, I never had any direct issues with it. However, I never truly got my head around it or got comfortable with how it functioned. I recently swapped arch for void which uses runit, and after over a month using it I to an amazed both how clean and simple it is, how everything just works, how easy to interact and use runit is and am blown away by boot and shutdown times. My arch / systemd setup was heavily optimised for boot, and I thought was quick, but runit starts in about 4 seconds and shutdown is about 2 seconds.
These days OpenRC even has user-services. And writing a simple OpenRC service file is barely more complex than a systemd unit file, maybe even simpler, because it’s readable bash, not some declarative DSL.
Obviously there is in no way feature parity between those two, that’s the point, personally the one thing I’d like to have is something similar to systemd’s timers (which I actually prefer to old-school cron) built into OpenRC, but most other things I can live without.
Readable bash
That’s an oxymoron.
Do you know of an easy drop in way to convert a sysV system into an OpenRC one?
sysV init or sysV rc? OpenRC can work with any basic
/sbin/initor provide its own. If you rely on sysV rc scripts there is probably some backwards compatibility, or at least was in older versions, but I don’t really see the point in it. What distro does even still use sysV rc?
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.
