I’m curious to know why people use systemd-less distributions. Which one would you recommend to someone who wants to stop using systemd?
I use alpine and freebsd. I want full control of me PC/server. And many times, I need DIY unusual setups. Systemd is way too complex to master it so I can get those working. That’s why I use a simple thing which I can learn well, so I can implement whatever setup I need.
I used to be on Ubuntu, Debian and Arch. And implementing such these setups was too hard under systemd. However, if you don’t need this. Systemd just works fine for you as did for me in past.
How’s Alpine on desktop? I’ve long wanted to try it, but always thought that it is more of a server thing.
So far, I’m good. It’s not the best Desktop distro. But since I want an OS for development and also for a workstation, Alpine is good.
Also, it’s kinda DIY like Arch, or worse!
Gentoo is not exactly a systemd-less distribution—you do have the option of installing it instead of going with the default (OpenRC). Personally, though, my Linux use predates systemd and no one has ever presented what I would consider a compelling reason for me to switch to it, so I install all my systems with OpenRC. I’ve reached a stage in my life where I dislike unnecessary churn in utility software.
From a less-personal standpoint, I consider the philosophy behind systemd to be wrongheaded (as in, it looks very much like Microsoft’s embrace-extend-extinguish—and no, I do not trust Red Hat not to be sold to someone who will take advantage). Many of the other reasons-not-to-use given by others here also ring true to me.
I do not trust Red Hat not to be sold to someone who will take advantage
They’ve been IBM since 2019.
Hardly any of the core systemd people work at Redhat these days. Microsoft employs more of them then Redhat. Right now I think Lennarts new company employes several of the key systemd people.
Contributions are comming in from all major distributions though.
And IBM could very easily sell them on, or the leadership there could change and decide to do something unpleasant (although I know IBM has a long history of being about as maneuverable as a parade float, it still could happen).
I’m the type of person who wants more systemd in my computer, but if I think the arguments for a systemd-less system are:
- Making sure that apps remain open and compatible with other init systems, so that if systemd turns evil there is a easy way to escape.
- Trimming and removing bloat that some people feel systemd provides.
- Testing out other init systems just for the fun of it, like distro hopping.
@HappyFrog @SwooshBakery624 I think the real fun (value) in not using systemd is much greater flexibility to mix and match different sub-systems and make the machine start up in the exact state you want it to, with just enough essential daemons.
Making sure that apps remain open and compatible with other init systems, so that if systemd turns evil there is a easy way to escape.
Since systemD is open source, even if they do turn evil it could be forked from the last non-evil version, or another implementation could be made. I do agree with the other two points though.
Chromium is open source. Google is evil.
“Fork it, grandpa!”
That’s a false equivalence and you know it
No, it’s not. It’s a great equivalence, even.
I’m the type of person who wants more systemd in my computer,
Why? Don’t get me wrong, I have nothing against systemd and will continue using a distribution if it has it or not, it’s not a deciding factor right now. But I’m also no one who says “I want
moreof it” or the opposite "I wantlessof it`.I like ot when the software I use feels cohesive, and systemd has a whole echosystem of things that does things the same way. Like, I use quadlets to manage my home server’s containers the same way I set up mount points.
I’m the type of person who wants more systemd in my computer
Hear hear. A couple hundred more should do the trick.
bootctl busctl coredumpctl homectl hostnamectl importctl installkernel -> kernel-install journalctl kernel-install localectl loginctl machinectl mount.ddi -> systemd-dissect mount.mstack -> systemd-mstack mount.storage -> storagectl networkctl oomctl portablectl resolvectl run0 -> systemd-run storagectl systemctl systemd-ac-power systemd-analyze systemd-ask-password systemd-cat systemd-cgls systemd-cgtop systemd-confext -> systemd-sysext systemd-creds systemd-cryptenroll systemd-cryptsetup systemd-delta systemd-detect-virt systemd-dissect systemd-escape systemd-firstboot systemd-home-fallback-shell -> homectl systemd-hwdb systemd-id128 systemd-inhibit systemd-machine-id-setup systemd-mount systemd-mstack systemd-mute-console systemd-notify systemd-nspawn systemd-path systemd-pty-forward systemd-repart systemd-resolve -> resolvectl systemd-run systemd-socket-activate systemd-stdio-bridge systemd-sysext systemd-sysinstall systemd-sysusers systemd-tmpfiles systemd-tty-ask-password-agent systemd-umount -> systemd-mount systemd-vmspawn systemd-vpick timedatectl udevadm updatectl userdbctl varlinkctlMajority of these are separate utilities developed under systemd umbrella.
No, they aren’t. These are the binaries from THE systemd package , built from systemd releases, from THE systemd repo.
A single source tree looking like an “umbrella”, and an overreaching one at that, is THE point.
What do you think about coreutils, util-li nux, findutils, god forbid iproute2? They all are binaries from THE mentioned packages, built from THE repo (have you heard of monorepos?) are they also overreaching and that’s THE point?
Your “separate utilities developed under systemd umbrella” claim was simply false.
Your attempted retort was even more funny, since many coreutils implementations can actually literally be built into a single binary with many symlinks, with dispatch done based on arg0. It’s even the preferred packaging option.
There are a lot of interdependencies within those source trees. Nothing is self-contained. So the “itz just monorepo bro” is also false.
they also overreaching and that’s THE point?
You literally just listed multiple projects 🤭, where their collective surface is also nowhere close the the systemd forced hegemony. Maybe they should all unite and join the “umbrella”.
Of course there are dependencies. They all are tools that do one thing well amd call into other tools to do thenthings those tools were built to do. E.g. many need systemd-init to function as that is the tool to manage the livetime of services running on the system.
It wasn’t because it’s true. They are literally separate utilities. Many is exactly two (i think) busybox and whatever the other one is called. For vast majority of people and in context it should be obvious that coreutils I was referring to is GNU coreutils, you are being intentionally obtuse. There are three, I believe, mandatory parts that fall under systemd umbrella everything else is either optional or separate. Interdependency angle is disengenious at best, programs can and have dependencies, it’s laughable that you think that they aren’t separate utilities because they depend on other utility.
Forced hegemony I’m dying lol.
Let’s play a game. Pick a “separate utility” from the list above, and let’s see if you know what you’re talking about, or just waffling.
…so they are separate binaries
Systemd doesn’t require all of these to function. You can use systemd as just a init system
Share the content of the file
90-systemd.presetfrom your system.
I think you did a great job explaining it! I really liked my short time with void and would probably still be using I were more capable of setting up and maintaining a minimal distro
Because redhat/IBM are inherently evil and try to takeover FOSS as much as possible
Caviat: I use a distro with systemd. But these are generally the reasons people don’t:
Violates the Unix principle (that Linux has mostly inherited) that every program should do one thing only, and do that thing well.
Subsequent theorizing that the things systemd does could be done more efficiently.
Subsequent theorizing that allowing a single dev team, in this case, Red Hat, a US corporation aimed at enterprise use, to control a large chunk of Linux development could be a bad thing. There is some merit to this, as some applications require systemd specifically as a dependency.
The reality is that these systemd isn’t particularly inefficient, and no power moves from Red Hat have been made. Is this the absolute most ideal situation? Perhaps not, and I’m glad people are crafting other solutions. As of now, it does not factor into what distro I choose at all.
I don’t think systemd is an improvement.
I’m using Guix which uses Shepherd. It’s really nice if you’re comfortable with Lisp or Scheme/Guile to be specific.
To people wanting to move away from SystemD though, I’m personally partial to OpenRC. It’s not very complex at all. As for distros that use it, Void Linux comes to mind. I was also pretty comfortable daily driving Alpine Linux for a while. Both are very much “get out of the way and let me work” distros in my eyes.
Void Linux uses runit, not OpenRC though.
The systemic reason people in general should use a non-systemd distro, is that systemd has too much control over the direction of Linux development and the developers are beholden to big tech instead of end users. This inevitably leads to bad outcomes as we see with Linus and AI the past few days even assuming everyone started out with pure intentions.
As far as the end user experience, there are some things that just assume systemd and you have to start bashing around and guessing from logs to get it running (eg Tailscale). Systemd is honestly a good user experience for new users and simplifies a lot of annoying tasks. It’s insidious.
i use slackware. the init system here is extremely easy and simple. (mostly shell scripts)
i see no reason to use systemd on my machine. it’s an unnecessarily complex beast i can’t fully understand myself… i get it there’s some useful features included but i don’t need them. and i personally had issues with machines using systemd (waiting for some daemon to start with some timer going and hanging there, idk if it’s a config issue but it was a vanilla debian box with barely anything changed)
I use Alpine Linux which uses OpenRC. For me, I like to understand how things work and SystemD is too complex for me. It’s presence discourages me from wanting to learn it because there are other things I would prefer to do with my time instead.
I really enjoy writing scripts and OpenRC is far easier for me to understand. I think Runit on Void might be even more simpler than OpenRC but I have no real experience with it. Alpine just happened to cross my path first.
I write a lot of POSIX scripts so portability is something that is important to me. It gives me the freedom to move around to different types of distributions whenever I want.
Also, without SystemD, I’ve learned so much about how Operating Systems work in a more low level and detailed way. I’ve always struggled with keeping hobbies so this has been a nice change. There’s always more to learn and it’s easy to get lost in all the logic puzzle pieces.
When I don’t feel like tinkering, I still have a copy of Linux Mint Debian Edition set aside as a backup. It’s base installation is simple, has everything I need and it just works.
The main argument I hear is about portability. Systemd integrates deeply with Linux and isn’t available on BSDs or other Unix-like systems. This in itself wouldn’t be an issue but major desktop software started to integrate systemd locking out BSD users. A recent example is KDE Plasma Login Manager (KDE itself still works).
Providing systemd-less option is something very in line with Gentoo Linux portability goals so I’d take a look at what they do if you’re interested.
Out of interest: Which init system is used on several OSes by default? Last I checked all OSes wanted init systems that made actual use of their unique kernel features. Any POSIX compliant init tool will by definition not support OS specific features out of the box. Maybe you can hack them on?
I see this “they depend on systemd-specific features”: Of course. The systemd project listens when user space developers report the probpems they face with their problems and tries to solve them. Of course developers are going to use that, why would they want to hack around a problem poorly instead of using a proper solution that is more stable, robust and has seen way more testing than anything they could write themselves? The problem is not systemd here, its nobody else bothering to do something.
I don’t think there’s one. Gentoo OpenRC was created with FreeBSD and NetBSD in mind but hasn’t really been adopted beyond Linux. It feels more like it’s an effort to keep recipes for having Linux run without systemd and to monitor cases where systemd integration breaks things for other init systems. Having only one good option means being one option away from having no good options at all.
So why bother about making init tools portable? You end up with a tool that works poorly on all OSes and nobody needs more of that.
Even if OpenRC is not widely adopted it is a commitment from Gentoo to build their package recipes in a way that’s portable across different init systems. Keeping options open is healthy and I think one of the coolest things about Linux ecosystem historically was that there were at least two non-halfassed options for most of the system components. This also helps out little guys like BSDs who benefit from portability issues Gentoo package maintainers raise upstream.
IMHO supporting several init tools does more harm than good to any distribution. Its a lot of extra effort that few users will even notice.
Traditionally we used a script to boot. Those of course looked different in each distribution, but the “init tool” was the same. Then we switched over to sysv init (and man did people complain about this overcomplicated mess of symlinks!), yet pretty much all distributions switched to that. Of course they shipped widely different init scripts, but the tool was pretty much the same everywhere. The Linux Standard Base even prescribed the sysv init and any compliant distribution had to use that. We never had a time where distributions offered options wrt. init tooling.
I doubt the portability issue reporting from gentoo makes any difference whatsoever for the BSDs. They come up with all kinds of Linux compatibility stuff and that gets them the software they want.
I think some people are simply nostalgic for the Linux/Unix of yesterday. Systemd is a pretty big change to the system of established norms
With that being said, the strong suite of systemd is complex systems. For embedded Linux like buildroot and openwrt busybox init makes way more sense.
Recently I started experimenting with Alpine Linux. Initially because I wanted something for a Raspberry Pi which had newer packages than Raspberry OS and was quite minimal. Now I also installed it on a spare laptop and set up a desktop environment with the River Compositor mostly just to try it out. Most things I want to do are already working as expected while after boot it uses only 380MB of RAM. So I like how minimal it is, the package management is really nice and stable and it just runs very nicely on this older laptop.
Alpine is a wonderful distribution if you can afford to opt out of all thr security improvements made in the last 20 years.
Just try to log the keystrokes of another user (as root/some other user or even from a program running as the same user) and compare that to a modern systemd system. It is amazing what a difference the new kernel features make (revoking access, only allowing one process access) together with systemd-logind to pass access around to the right processes. There are tons more examples… any progress made right now is in systemd first. In fact most progress is never taken up outside systemd at all.
I wanted to try out a systemd-less distro because I didnt like how much authority the systemd project seems to give itself. Now I’ve fully switched from Arch Linux with KDE Plasma to Void Linux with Noctalia and Niri.
Its been pretty smooth so far. The only hickup has been that I had to raise some sort of memory limit to run heavier steam games. I had to compile like 2 programs I use from source but I dont mind. Loving how slick Niri is!
To be fair, there is no reason for a standard user to not to use systemd. You can easily find tutorials when you need them, which won’t be a lot for your daily usage.
I switched to a systemd-less distro because I want simplicity and want every service on my system to be in my control. I cannot use systemd without copy-paste commands. With runit everything is simple.
Note that, some programs specifically check for systemd and for those you might need to adjust things accordingly, if you want to use an init system other than systemd. So again, if you don’t want to deal with init systems, systemd just works.
I use Void Linux. It has runit and it’s simple. If you want things kinda old-school there are distros that use OpenRC. There are a lot of init systems in the wild and that is a good thing, though you might find some of them quite barebones.
So if you want more control, why not? Just be ready to learn more things because systemd has more than what an init system do.
You get less control actually. Like you can’t even do basic things (capabilities per daemon, limits per daemon, isolation, etc.) with old-school inits. Won’t even start on security features allowed to units by systemd.
If by control you mean you can write your own logic in an initscript, then yes you probably can, but it’s still limited (never tried runit, but on old rhels and debian they were) by other tooling that expects script to behave in a particular way. You can still obviously do it with systemd by calling your script.
If you mean by abilities, I agree. Most of the tuning that exist on systemd doesn’t exist for runit, at least out of the box or to my knowledge. However what I meant is, with systemd I don’t know what’s going on on my system, with runit I know every single service because I put them there in the first place. Of course systemd covers most of the things nowadays, while I have to deal with power management, networking, display manager, login manager etc all separately. Doing the Unix way is simple, while systemd grew to be quite complex.
For my daily usage it suffices. For my home server, I still prefer Debian with systemd (though I’m checking Alpine nowadays) because I’m lazy for that case and systemd does everything for me.
Systemd is unix-way, systemd the manager is one program it comes with journal, but everything else under systemd project is either optional or separate utility that designed to work well with other utilities under systemd project, kind of like coreutils.
I understand your position I think it’s empowering to do it your way. 👍🏽
Heh, there is a joke running as “systemdOS”, they have too many optional utilities. :)
Thanks! I think I like simpler inits because I started using Linux before systemd (mostly OpenRC or SysVinit for me those days, but even though I used Ubuntu for quite some time I don’t really know about Upstart).
I too have started using linux some time before systemd adoption, but because my work involved a lot of system administration and infrastructure administration simplicity of sysv-style and bsd-style inits was detrimental to my mental health, so when systemd came it was something from another world, tickled me just right and documentation was insanely good and detailed, and it absolutely changed everything. There is also an obvious problem of people reductively thinking of systemd project as a whole as an init system, it isn’t just that it’s a system management system and it works great. Other systems just doesn’t use what linux provides and instead reiterate on old designs.
Yeah, I agree systemd makes things easier for sysadmins, and with every components of it to be fair. It’s quite a huge project at this point, does way more things than a mere init system, I guess that’s the argument of it being not so Unix-like. It’s made specifically for Linux so it probably doesn’t work on BSDs, though I have no idea honestly. Wayland was suppose to be the same and it works on some BSDs now apparently. Anyway, if I imagine system administration on bigscale, I think I would go with systemd as well.
