182
Reclaiming the desktop: Why I’m still on Linux in 2026
(the.unknown-universe.co.uk)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 15 Apr 2026
182 points (100.0% liked)
Linux
65567 readers
61 users here now
From Wikipedia, the free encyclopedia
Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).
Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.
Rules
- Posts must be relevant to operating systems running the Linux kernel. GNU/Linux or otherwise.
- No misinformation
- No NSFW content
- No hate speech, bigotry, etc
Related Communities
Community icon by Alpár-Etele Méder, licensed under CC BY 3.0
founded 7 years ago
MODERATORS
And yet you use & support systemd...
Omg shut up. Nobody controls Systemd, it’s open source.
You can also replace individual components. It's basically a bunch of binaries using an API.
Uh, the systemd devs do.
The “systemd devs” are anyone with the cashe to contribute to it. Yes, you need to be competent dev for your merges to be accepted, unlike in the virus-infested AUR.
But systemd can be forked if you don’t trust said devs. You’d be in the minority though because the majority of distros out there chose to adopt systemd, because it is that good.
Not really, unless you're employed by one of the big tech companies contributing to it, your pull requests are piped directly to the shredder, same with xorg, gnome, etc.
You can fork them, but why bother when it's a mess designed to ensure the employment of its contributors, 'WallyWare' if you will.
Do you have any actual problems with systemd, or do you just want SysV init scripts to stick around forever?
Maybe systemd isn't the best, but it's way better than a bunch of mostly unstructured shell scripts, and more secure (it's pretty easy to reduce privileges, sandbox the filesystem, restrict syscalls, etc per service just by editing the unit file)
Personally, my problem with systemd is that it's slowly trying to take over everything it possibly can, and be as hard to remove as possible.
It's not "so you just think it's all a single binary!". No, I'm 100% aware it's multiple binaries. The problem is that it's a single project, and that's too much power to give to one single project.
"oh but you can swap out the individual parts!" Sure. For SOME of them. Until you swap out the systemd init and suddenly have to relearn a shitton of completely random other stuff because systemd was doing a boatload of other things. Might as well get that out of the way early and use normal other projects for the other stuff, and also ditching the init system can't hurt just to reduce their stranglehold.
Also OpenRC might be worth looking into. "systemd or Old™ Nasty™ sysv scripts" is a false dichotomy, openrc's init scripts are declarative like systemd units (and it also supports sysv scripts). There are also totally different init systems (but we don't know much about them, we started with systemd and then jumped to openrc recently).
-- Frost
Huh..? Unstructured..? Please explaln or are you just a troll or a lenfart puttering lover..?
Yes, unstructured. Every script is its own special snowflake that does things a bit differently.
There's no guarantee of the verbs that the script implements. start, stop and restart are common, but the implementation is up to each individual script. I'm most familiar with Debian where some service (but not all) implemented it with
start-stop-daemon, but other distros and OSes handled it differently.Basic, commonly needed functionality, like restarting a crashed service after waiting for some delay, need to be implemented per app.
When sysvinit was widespread, there was a reason a lot of people used systems line supervisord to deploy services, rather than dealing with sysvinit scripts. It was a pain.
Systemd units were a logical progression from supervisord services.