What are some significant differences to expect when switching to an alternative, and can that affect gaming compatibility and performance?
Systemd, systemd-boot, systemd-snapwn
Good stuff
Why you want to switch from systemd? I hate how complex it is, this age verification and that they’re trying make make Linux more Windows like, but in that bad way (it’s created by people who prefer Windows over Linux so yeah). But if your installation is working and don’t have troubles then don’t switch.
Switching to “alteratives” shouldn’t affect gaming compatibility at all, cause you don’t need any daemons to play your games (maybe if you want to host server or use vpn for multiplayer). Remember that systemd is not init system, but software suite which provide init system also. I think that systemd might use more resources than other solutions. Some software can rely on systemd, but when are you installing program from your system repositories it will work cause it’s prepared to work if you’re using solid Linux distro. I had situation on MX Linux that I downloaded Mullvad VPN from Mullvad’s Debian repositories and it wasn’t working, because of no systemd. Then I discovered that MX Linux have Mullvad VPN in own repositories and it worked. On every non-systemd Linux distro you can install elogind which is usually preinstalled and it also care about compatibility layer.
If we speak just about other init systems try what you like. My favourite is runit, but the most popular alternatives are OpenRC (this is what I usually using, even right now on laptop and PC) and sysvinit. sysvinit was terrible experience for me on Devuan, on MX Linux okay; OpenRC is just okay, but I have few reasons to hate it.
Systemd is used by the most of people so if something will screw up more people can help you and there’s more tutorials on internet, also sometimes you need to tinker more on other init systems from my experience as systemd is more handholding. But using different init system will give important experience and learn you more how your system works.
If you’re looking for non-systemd distros check MX Linux which is the really good system, also for not advanced users who just want to run their games. It’s using sysvinit and you have GUI tools to control daemons.
Dinit for desktop, s6 for server.
Btw, why is systemd even a thing for server distros? Can’t play none of it’s strengths but it’s fault’s affect security and stability.
The main functional difference between systemd and others is that systemd will just work. Others will require you hand tune and hand tinker with a non-mainstream Linux distro.
If your hobby is init systems by all means mess around though.
I personally quite like systemd. Unit files are clean, timers services and sockets are easy to manage etc.
Honestly it’s a non-problem. Best advice is to use what is best supported. Don’t let the extremely fringe (but loud) tiny group of systemd haters throw you off.
As someone who’s created a timer, cron is much more straightforward.
Systemd has its good points, but most of that is the core functionality as a sysvinit replacement in my opinion. And it’s entirely likely that at least one of the newer alternatives is a better option for that.
I think if you know cron from the start it can be easier, but it gets really annoying really fast.
Compare:
0 0 * * * /usr/bin/flock -n /tmp/myjob.lock bash -c 'sleep $((RANDOM % 3600)) && /usr/local/bin/myjob.sh'To:
[Timer] OnCalendar=daily RandomizedDelaySec=1hThat and things like systemd preventing overlapped delays, handing what to do if the system was down during the last cycle, built in logging and event tracking. Seeing successful vs non successful runs etc.
Once you add in those production requirements cron gets annoying fast and timers are easy.
For adding a quick thing to make something happen at a specific time, I can add a cron job in a couple of minutes. To add a timer takes creating a couple of files with syntax that took me a while to look up last time I needed it, and running a command. Then debugging. Sure, the timer has benefits, but cron jobs are still simpler.
On the bright side, there’s actually a “crontab -t” command that apparently can be used to generate timer files from a crontab line, which I hadn’t known of before today.
That’s because you know cron. If you knew timers equally as well they would be easier. And they let you handle the edge cases (retry, randomness, tracking, logs etc) without the need for a custom script.
Once you factor in the production edge cases I think timers are clearly easier. You get all of it for free.
I can add the two files required to run a timer in systemd in a couple minutes, but writing the complex incantation to cron for having it do something that is the default in systemd is pure pain and takes me 3 hours of googling
What you can expect when switching from a system management tool written for Linux to an init tool targetting the least common denominator of general Unix functionality?
Less functionality, less security, less information about the state the system is in, less reliable switching between states and a whole lot less of linux kernel features exposed to your use in convenient ways.
It’s not as if systemd was started to be complicated, the world got complicated. E.g. we used to just create all the device nodes in /dev statically during system installation. Then USB became a thing and supported so many different kinds of devices with thousands of potential ports to connect them to. They would not fit into the device node namespace! So we needed to make device nodes dynamic, which is also convenient.You do not have lots of device nodes that do not exist on your system and you no longer need to change system configuration when you plug your mouse into another port of your system.
Filesystems, security (often linux specific) features, everything is easy more complex (and more dynamic) today than it was when sysv init was a thing. That simple stuff was great when you had to power off your machine to change its available devices. It is less cool when you plug an USB-C cable into your laptop and want to use all the stuff that is now suddenly available.
Are you using systemd or an alternative, what do you recommend?
systemd in one machine pending the switch and Artix on another (switching after the introduction of the age field to comply with the age verification law). I have been using GNU/Linux for 15 years, more than a third of that without systemd. So going back to something else felt normal and I recommend switching away from systemd
What are some significant differences to expect when switching to an alternative
Systemd is bloated so expect better performance here and there
can that affect gaming compatibility and performance?
Compatibility issues yes, but performance difference no
What last thing to consider is using the systemd forks like the unshitted one, you get the best of both worlds
How it can affect compatibility issues with games?
I use OpenRC on most of my systems, which honestly works well enough that I’ve never felt the need to change. SystemD at work though, which is also fine. If I have any complaints, it’s just not what I’m used to.
Switching could be tricky, and may not be worth the hassle. It’d really depend on what you want to get out of it. As always though it’d be a good way to learn as you’ll inevitably break something and need to figure out how to fix it.
OpenRC here, on Gentoo.
It works pretty well, fast and simple, honestly I never felt the need for SystemD.
I use the latter at work sometimes, I don’t really like how it changed the way stuff works, but I have nothing against it. I just feel the extra complexity is not needed in all of my home setups (laptops, servers, etc). So it’s OpenRC everywhere for me.
If you have to ask this, then its probably good idea to stick to systemd. I don’t see any reason to change, other than to protest. In the process doing so you will probably encounter issues. People switch away from systemd for various reasons, but not for performance. In example they don’t like who develops and controls systemd. And they don’t like that it does more than just initializing the system, as bunch of other tasks are bundled into it. If all of that does not bother you, stay with systemd in my opinion.
And if you really want to switch to systemd, then I recommend to use a dedicated operating system (a distro) with that in mind. Don’t forget, that systemd has many features and services, that its expected as a standard. You do not just change an init system, but replace all other components too.
If you are asking about “gaming compatibility” you should not switch to a non-systemd distro. You will end up going through extra hoops for zero benefit.
What kind of extra hoops? Or maybe it’s the type of games?
Asking because I switched to Devuan on my gaming PC and I didn’t need to do anything specific for games to work (Steam and Lutris).
The only exception is The Last Caretaker (UE5) that requires more recent NVIDIA drivers than those in the Debian repos, but that has nothing to do with systemd, it’s Debian/Devuan being conservative with updates to guarantee stability.
Systemd is fine. Stop getting trolled by antiquated neckbeards.
Unless you find a specific problem with something, don’t go looking for reasons to fix that which is not broken.
No, it’s not fine. But I agree with the last sentence.
Systemd is fine, but we should be aiming for better than fine.
That being said., there’s definitely something to be said for sticking with “fine” until something else proves itself to be at least adequate with potential to be better than merely fine.
I’m using shepherd right now and i’ve used runit in the past. Shepherd is definitely a beast of its own since it’s configured in guile scheme, but in the case of runit it just runs schell scripts and the commands are for the most part just as simple as systemd. I’ve seen people claim that some programs won’t work without systemd but i’ve never come across something that didn’t work.
Except for systems with very limited resources, systemd or not won’t make much of a difference in performance. A lot of tutorials on reading system logs and managing background services will assume that you are using systemd.
I’ve only ever used distros with systemd, not necessarily with intent, but because it was the default and well-supported. Probably won’t switch unless
- Debian switches
- there’s a change that breaks my workflow
- it somehow starts phoning home to a big datacenter.
I use systemd it’s fine and requires very little extra thought.
i actually like systemd. i’m not sure why I wouldn’t want to use it.
Age verification? How about their attempt, after taking over udev development, to drop support for other init systems to force people to use systemd? It’s track record of security flaws?
Filesystem enable age verification in pretty much the same way as systemd does: You can optionally store a user’s birthday. That is such a ridiculous statement.
To be fair: None of the other inits cared for udev. None contributed or helped by providing features they wanted to improve udev. The systemd devs care for the lower level plumbing overall… and not just for the init system. So it is very natural for low level plumbing projects to land under the systemd umbrella today.
Systemds track record wrt. security flaws is actually pretty good. Not many went through the cracks,maven though some were indeed pretty ghastly. Hardly any was in the core functionality, most were in new code not widely used yet.
On the other hand, the service hardening that systemd enables has improved the overall security of a typical Linux system by quite a lot.
