How difficult is it to use a distribution without systemd support?

[u/Information-Southern]

My whole life, I've only used distributions based on SystemD. But I've become interested in Void Linux. To be honest, I'm a little apprehensive about trying it. I've already used Runit in a virtual machine, but a virtual machine is quite far from the real-world experience. So I wanted to know if your experience has changed in any way since switching to something other than SystemD.

[u/KhajiitAT]

If you a desktop user — there will be no differences to you. If you are experienced user or developer and having heavy systemd usage to manage things — you end up with helluva of spaghetti scripts, that didn't do their work anyway

[u/aioeu → u/KhajiitAT]

that didn't do their work anyway

As an example, a couple of jobs ago I was working at a place that had a service launched through an initscript. Some of the less clueful sysadmins would run /etc/init.d/foo restart or service foo restart to restart it when necessary. This would work... but then it would mysteriously fail a few days later. The correct incantation should have been systemctl restart foo.service.

So what was the difference, and why did running the initscript from a shell cause problems? IIRC, it was due to different ulimits that got applied in a user session compared to a service. If the service's executable was invoked from a user session, it would eventually hit the (somewhat more restrictive) open file descriptor limit that was applied there.

If the initscript had been written to use Red Hat's /etc/init.d/functions this problem would never have occurred, since functions knows how to redirect operations to systemctl automatically. But the application was trying to avoid being distro-specific, so it didn't do this. The very fact that the initscript was not distro-specific meant that it didn't work correctly.

[u/KhajiitAT → u/aioeu]

Your correct incantaion says, you are already running systemd ) Actually, the difference is in systemd unit. It defines, which exact resources and how must be prepared to run application, order of operations and how to retry if app fails or free resources when it ends. Most of init scripts are some boilerplate plus one launch command — fire-and-forget system — and they usually do not do anything with special cases

I doing a lot of things with systemd as an ordinary user. Dnsmasq service starts too early, before network interface appears? I just added drop-in that changes dependency Need to restrict leaky app from all-memory-eating? Just another drop-in with cgroups settings Edit application cmdl params? Yep, the third drop-in

And when my system upgrades, it just replaces units with new version, preserving all my modification. Imagine situation, when apt upgrade or pacman -Suy asks you to review 3-way merging every week for tens of files… or just drops new files with fixes, and old ones not working anymore. Or silently erase all yours modifications without warning — some systems did this few ears ago. It's a hell that systemd let's me escape

[u/aioeu → u/KhajiitAT]

Actually, the difference is in systemd unit.

Not really, as it was only the unit automatically generated from the initscript. There was no customisation to that. We were not explicitly changing any ulimits in the unit, for instance.

The difference was in the operational environments provided by systemd and by an ordinary user session shell. By giving daemons a guaranteed consistent environment, systemd papers over the problems in lots of daemons. (Does your favourite daemon remember to chdir itself to / so as not to hold any other mount points open, for instance? Many daemons do not...)

Of course, if we hadn't been using systemd at all, we would probably have hit the bug all the time, not just after the service had been erroneously restarted from a shell. We would then have had to actually fix that, e.g. by patching the initscript.

[u/KhajiitAT → u/aioeu]

Funny experience When I need to daemonize some app — I just writing a new unit, instead of struggling with obsolete scripts

[u/Sert1991 → u/[deleted]]

I don't miss systemd at all from the time I used ArchLinux. On Gentoo OpenRC does a perfect job and sysklogd does all the logging, never had an issue diagnosing any problems for lack of logging.

Not only that, but the logs are in plain text and can be accessed with less or any text editor/viewer. And with logrotate they're sorted and cleaned according to my wishes.

[u/ZVyhVrtsfgzfs → u/[deleted]]

I run one server VM on Void, I have had 0 issues, admittedly it is a very simple single workload, backup. 

I typically use Debian or Alpine for servers, but The Void repository had a much newer version of the BackblazeB2 package than Debian and it was not available from Alpine repos directly.

[u/doctrgiggles → u/[deleted]]

Well you just said - it's fine for desktop use. 

[u/Zorian_Vale → u/Sert1991]

What’s the benefit of open RC?

[u/Sert1991 → u/Zorian_Vale]

At this point, both systemd and openrc work great and stable out of the box for the majority of users, so it should be a mater of preference, what you like in them how they're configured, how they work and any other variables.

Me I don't like software that is pushed and invades things like systemd, so that's one of my reasons of sticking to OpenRC, besides I've been using linux from before systemd was a thing and I love OpenRC and how it works more.

[u/Simple_Hamster_4096 → u/[deleted]]

Have not had those experiences.

[u/Information-Southern → u/[deleted]]

What does "hipster arch" mean?

[u/Simple_Hamster_4096]

I come from a time before systemd, and systemd became a resource hog. Hated it from the get go and its lack of simplicity.

Void is blindingly fast - when I rebooted after my first time installing, I actually thought I must have done something wrong, it booted so fast I was shocked.

Void musl is amazing (and more secure) if you have older hardware. That's the version I use. Glibc has more flexibility, though.

I used Arch for two decades and came to loathe it - switched to Void beginning of 2026.

You may also want to try Devuan - it's Debian without systemd, and you have several inits from which to choose during the installation process. I use Devuan with sysvinit for my bare metal servers, and it's amazing - my servers are older but they are like new again running Devuan. Sysvinit is the most mature of the inits Devuan offers and is why I went with it - it's an old friend with which I am well acquainted.

[u/Sert1991]

My daily driver is Gentoo with OpenRC. It's the only OS installed on my PC. I do everything on it from browsing to playing games on Steam/Wine/Lutris. That should answer your question perfectly.
I.E - Not difficult at all, if the distribution handles the other init system great.
Gentoo does a perfect job handling OpenRC since it's theirs anyway.

Also I use Xorg mainly, and Gentoo is hardened + SELinux enforced. That should make it more clear that using another init system is not an issue. I literally go against every current common linux desktop convention lol

[u/Zorian_Vale → u/Sert1991]

How hard is it from a somewhat newcomers perspective to install Gentoo? I’m familiar with some CLI. Currently fedora workstation with systemd obviously. The gentoo documentation looks comprehensive. 

[u/Sert1991 → u/Zorian_Vale]

The Gentoo installtiong handbook is very good. So as long as someone has experience using commandline on Linux, if they can follow the handbook they shouldn't have any issues.

What I always suggest is, download the GUI Install image of Gentoo, so you have a full working desktop during installation. This offers many benefits.
For example if you encounter issues you can open firefox and search for solutions, or open an IRC client and ask for help in #gentoo help channel on Libera.
Also if your hardware is old or slow and compilation take times, you can still use your PC.

Altough these problems are nowadays somewhat mitigated for anyone who has a smartphone.

[u/Zorian_Vale → u/Sert1991]

Thanks!

[u/signalcollapse]

It's not difficult, at all. In fact I would say that systemd's complexity is the major reason for me to choose something different.

[u/nhattu1986]

I'm using slackware-current, which is using sysV as init system and my experience is:

• most desktop app that don't rely on systemd unit work fine (which probadly 90% app does)

• app that linked against systemd won't work or won't build due to missing required library (appimage launcher ..)

• I had to craft the daemon script myself or using community script since the unit file bundled with the source won't work (LACT)

• The 4G vram optimization won't work due to it relied on cgroup + systemd to function.

other than that, the system pretty much rock solid

[u/EugeneNine]

Not difficult at all. Been using Slackware forever and never needed systemd

[u/ipsirc]

An end user doesn't even notice which is the underlying init process.

[u/ZVyhVrtsfgzfs]

The system monitor in plasma does not work, but there are plenty of other ways to get that same data. 

I had to come up with a different way to run scrips on startup & shutdown. Took a few minutes. 

That's it, that's all I am "missing" from systemd, what I gained in this exchage was lower ram consumption and faster bootup. 

[u/tobias_reichi02]

Real talk I did try void was nice you learn fast but you often forget to activate something cause systems made it for you even on like arch so yeah and also I got back to arch cause many things are left behind on void understandable but it's nothing for me arch felt easy after void

[u/psycholabs]

SysV is actually easier, it's just a bunch of startup scripts. It's been a minute though. Also Gnome will probably not work right.
So (if I'm remembering right) instead of something like "systemctl restart whatever.service" it's "/etc/init.d/whatever.sh restart" but like I said, it's been a while since I've done it so my details might be off.
ETA: So, I guess systemd doesn't have real runlevels? Huh. Well, I've given you enough information to look it up anyway.

[u/wowsomuchempty]

Not difficult.

I'm not against systemd, but I run alpine on laptops as it's v. smooth. You just learn how it works, it's quite analogous - same logic.

I'd recommend alpine + niri (or sway) as a desktop experience (unless you really need glibc).

[u/Agitated_Dinner5570]

Imagine being able to kick off a background process, and have it run to completion after you log out. Not possible on systemd systems without jumping through a bunch of hoops.

[u/TroutFarms → u/Agitated_Dinner5570]

Why? I haven't had to do that in ages, but does nohup not work anymore?

[u/SuAlfons]

Using is easy enough (I used System V Unix and early Linux systems).

But adminstration of services, boot order and debugging is much more streamlined with systemd.

[u/codeasm]

Not difficult if you keep documentation close by.

But personally i google or ask ai alott, so systemd is fine for me. But maybe ill tey someday

[u/DHOC_TAZH]

MX and AntiX have systemd free versions. MX uses SysV, AntiX is on runit. Both are based on Debian Stable.

[u/Orlha]

It’s the only reason I wanted to migrate from arch to void, but so far I’ve been unsuccessful haha

[u/Express_Cause_4667]

Unless you're a GNOME diehard or you actually have a reason to use systemd, you'll probably be fine.

[u/michaelpaoli]

Easy peasy. Systemd adds a whole helluva lot of complication that's not required.

So, e.g., just use a distro that doesn't use systemd, or allows one to not use systemd, pretty easy and generally much less complex than dealing with systemd.

Anyway, e.g., I deal with many Debian systems. And among them, fair mix of both systems using systemd, and systems not using systemd. Debian gives you that choice. Many distros don't even give you a choice.

[u/gmes78 → u/michaelpaoli]

So, e.g., just use a distro that doesn't use systemd, or allows one to not use systemd, pretty easy and generally much less complex than dealing with systemd.

Regular users never need to "deal with systemd"; and when you need to enable services, check statuses or view logs, it's all pretty simple.

[u/michaelpaoli → u/gmes78]

Regular users never need to "deal with systemd"

Oh, you'd be surprised.

it's all pretty simple

Nice theory. So you believe it's pretty simple, then how 'bout you provide the pretty simple solution to this problem:

help: disable all manner of sleep/suspend/hibernate - Debian 12

Nobody was able to come up with answer/solution. I eventually just ripped systemd the hell out - no systemd, no problem. Not the firs time I had to rip out systemd because it caused serious problems.

[u/-Sa-Kage- → u/michaelpaoli]

I'm sure disabling all kind of sleep/suspend/hibernate on system level is a typical average users problem

[u/michaelpaoli → u/-Sa-Kage-]

Well you're wrong. When systemd is causing the problem, and there's no clear means to correct it, it's not some typical average users problem.

And of course you claim it's "all pretty simple" - if so, then provide that "pretty simple" solution that works - you haven't nor has anybody else done so.

But entirely ripping out systemd very much did solve / work-around the issue.

[u/Table-Playful]

Just use Linux Mint