What are some significant differences to expect when switching to an alternative, and can that affect gaming compatibility and performance?
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.
I use systemd it’s fine and requires very little extra thought.
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.
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.
