What are some significant differences to expect when switching to an alternative, and can that affect gaming compatibility and performance?
I’m personally running Artix with runit and things are fine so far, but as ChrisG pointed out, dinit is basically a drop-in replacement for systemd syntax-wise.
Also, I recommend enabling the unofficial
[]repo in order to get a newer kernel with more frequent updates than what Artix provides in their repos, eg. the default and zen kernels in the Artix repos lag a bit behind the lqx kernel from the[]repo, and I still recommend enabling[]as a convenience repo on any Arch distro.I also switched to MATE from KDE out of concern that KDE could end up following GNOME’s path after SDDM is deprecated, plus I just wanted a lighter and different desktop, that and MATE’s default two-panel layout is completely usable from stock although you might wanna set the panels to auto-hide to maximize screen space.
If you want the convenient features of systemd without the cancerous assimilation of the entire userland then dinit is recommended. OpenRC is a mature choice. Server folk seem to recommend S6 but I dont have enough personal use of it to verify.
- expect every response trying to provide useful info here to be drowned out by systemd brigading
I’ve been daily driving Slackware since the late 90s or early 00s (don’t remember). There’s no systemd, and no drama. I run KDE plasma 6, steam with proton, flatpak, rocm for AI shenanigans and whatever else I want. Even the rolling release is solid as a rock. There are dozens of us! And we’re not all greybeards. I started going grey in high school, but I ate cookies for breakfast today because I’m both a grown ass man and a child.
Try OpenRC. It’s pretty simple.
I use systemd it’s fine and requires very little extra thought.
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.
Not sure if i agree with you on the performance part. There’s definitely people out there that try to find the “fastest” init and some inits out there definitely boot faster. I personally don’t care about it that much since it’s usually a matter of a few seconds, but it is a thing.
Maybe I should not have said it in the way I did. I should have said “usually people switch…”. From what I see, performance is not the main attraction for “most” people who changes it. I wonder how much of difference it makes and how people measure it.
do you think you’ll continue to use sysemd once it start embracing gov’t id requirements to use it?
i ask because i hold a similar position, but it’s adoption of the first step towards this end goal has me wondering if i should start looking for an alternative.
The developers of systemd said they will never support that, so I think its safe for now. Also why do you think systemd would “require” a government id check? systemd is just providing the functionality; it is the distribution / operating system that implements all the functionality. So if an operating system does implement it, I might find a different operating system, regardless of if it uses systemd or not. That is true for any other component too, not just systemd.
a government id requirement is the next logical step after its needful framework has been built as a result of the age verification laws that have already taken affect in the uk and california.
and because it’s a government law, it’s out of the systemd developer’s hands. linux is influenced heavily (if not outright controlled) by corporations like red hat who have to abide by the law if they want to continue operating and, in a likewise fashion, the systemd maintainers must also comport themselves if they want systemd to remain the dejour method that linux uses to initiate itself in those ecospheres.
That is speculation. And as said, its not the decision of systemd to implement that, it is a decision of the operating system / distribution. I live outside the areas of those laws. What the next logical step is, is open to interpretation and that is not what I am discussing here.
By that same logic the next step is to just enslave us so the government can pour milk in our pants. Which is to say it’s nonsense. Your entirely just falling into panic.
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.
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.
Systemd is the worst init system except for all of the others.
No, it’s not fine. But I agree with the last sentence.
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.
As someone who didn’t know anything about either a short time ago, I found cron easier to learn and use. Systemd timers look more visually clean, but the way cron works is more simple and straightforward.
I can see how for some people cron is more straightforward to learn, at least till you need to handle logging, checking for cron results, handling when the triggered event can’t happen that instance, ensuring only one instance of the triggered thing happens at once, adding time jitter, etc.
Then timers are way simpler. Timers let you create robust timed events for free. With cron you need to do all that yourself.
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
Something looks more complicated is not a problem. Compare long division to a calculator, why would one think the calculator is more elegant? The calculator only enabled those who can’t do math acquire the answer.
And somehow in modern time, learning is someone who should be ashamed of??? Since when?
I find systemd easier I don’t have to google the timer syntax all the time.
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.
it’s one of those cases where if you have to ask, you should probably just use
systemd. anything else is outdated or a passion project based on some idealism, which i’m all for, but if you’re worried about gaming performance as a primary concern i’d put it out of your mind. for example, i’m an obsessive tinkerer that uses NixOS and Arch before that and i use nushell and Neovim and Hyprland, but i use systemd cuz i don’t see a reason not to. it’s well supported and stable.it’s one of those cases where if you have to ask, you should probably just use systemd.
I just said the same, lol. This is my default responds to questions like these.
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.
Dinit for desktop, s6 for server.
What is wrong with s6 for desktop?
I find how it works, with the database compiling, is more suited for stable and reliable than for Desktop with always changing conditions.
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.
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.
That’s kind of the best case scenario though: there isn’t even a significant benefit
And by hoops i only mean the kind of thing you just described (despite not being a systemd thing specifically) : small differences with the mainstream distros that might cause friction for someone inexperienced. It’s not the end of the world. I was being a bit hyperbolic admittedly
I think there are plenty of pragmatic reasons an experienced sysadmin or Linux power user might prefer OpenRC or something sysVinit compatible over systemd, but i think those reasons make a lot less sense to someone who is, respectfully, obviously a beginner (revealed by their use of the phrase “gaming compatibility”)
Runit is softly better but Systemd is perfectly fine. I would prioritize runit on very old hardware.
i actually like systemd. i’m not sure why I wouldn’t want to use it.
my one critique is pretty subjective, but i find it difficult to find simple clear documentation online about how certain syntax works and how certain tasks are accomplished.
Recently i was trying to set up a cron-job type automation to run a script every minute. I know how to do that in cron (and if i didn’t, there are tons of good resources online) but i had a hell of a time figuring it out for systemd. I also wanted to have the script run at boot or user login and i couldn’t figure that one out (but i know how to do it with cron)
i’m not a power user so it’s entirely likely the information was hidden in plain sight and i completely missed it
Were you looking at
man systemd.timer? Pretty much everything you need is on there and it is not too complicated.Thank you lol i will look into this next chance i get. I only remember looking at man systemd
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.
Do you have a source on the udev thing? I have not heard of this.
Eudev wasn’t spun up and then maintained for several years for no reason (it spun down again as the pressure dropped off). And you still can’t get the udev source from upstream as a separate tarball—you have to download the entire systemd tarball, even if you don’t want any of the rest of the contents.
