systemd's Growth Over 2022

[Berniyh]

Yeah, well, that's the thing. Maybe it works.

systemd was (also) designed with these use cases in mind, which means they took into account all the quirks that may come with this.

[fitzie]

When I look at crontab, I want to get the hell out of there, it's just a very weird format.
Luckily I can live without it.

btw, in my opinion, one of the most important features of systemd is that you can define stuff at a --user level. That's not possible with traditional Linux services (which I think also includes cron).
Hence, I can define e.g. a systemd timer that cleans out my ~/.cache/foo directory if it takes up more than X GB of data and I don't have to have superuser privileges for that.
As an admin, I can also provide such a timer that is off by default but the user can activate if he wants to (possibly via a gui).
Using crontab, you can of course run stuff as a specific user, but you still ne su privileges to define that.

Overall, the --user functionality of systemd has improved so many things in the last years. It improved the KDE Plasma startup (at least on my end), I can now reliably start mpd or similar programs during login (which previously kind of worked, but failed for unknown reasons about 5-10% of the time).
It's much easier to switch on/off pulseaudio or pipewire(-pulse), since all you have to do is start/stop the respective --user services (previously pulseaudio would instantly come up again being activated by dbus or something like that).
The timers also fit nicely into that new type of workflow.

just hit this systemd bug: https://github.com/systemd/systemd/issues/2913

the output of a unit will not get associated with the unit (e.g. "journalctl --user-unit $service"), when the process generating the log event is short lived. of course the fix is simple for the stdout case, but instead of addressing that, and worrying about the syslog interface separately, this bug has sit open for 7 years. systemd is now much worse then cron in this regards.

[ll1025]

the thing I don't understand is why do you think I'm incapable of using systemd?

I said you were inexperienced, an assumption I am basing that on your description of unit files as complicated and the manpages as inscrutable and difficult to find.

Cron still exists; you can still use it and it is certainly much more terse / quick and dirty than timers. But that does not make timers bad, or cron good; you're handwaving away how esoteric the cron spec is, with its optional fields that depend on whether you're root or a user and its time format that is so unique as to be called the cron format and to have online tools to craft the correct string. You mention the triviality of its parameters, as if common linux admins do not have to context switch between a dozen domains in a day and probably only deal with cron once a year when something blows up; linux tools like cron have a big problem that their parameters are anything but standard, with -v sometimes meaning "version" and sometimes meaning verbose, and that mental burden adds up.

Systemd in general and timers in particular standardize a lot of that jank. It is definately more mental burden at the start, and so while your complaints are understandable but I don't think they're justified given the overall improvement the changes bring.

If you're in a situation where the time sink for a new timer is onerous, frankly you can just use cockpit to create it: it automates the entire process and because cockpit is socket activated and standard in modern server releases there's really no overhead or downside to doing so. But the chances are you're going to set your timers up once, and not have to deal with such things for a long time.

If you're just saying that, maybe systemd / poettering should make a systemd-ish command that creates the timer and the unit file and activates it-- maybe he should (though I'm not convinced its not possible already). But timers are not really that complicated, they're just different.

systemd takes a packagers view of the world, and they could spend some more time thinking about the users.

That's a fair take, but I've been pleased with their focus on solving actual problems such that the changes and warts haven't bothered me yet. Oldschool things like service scripts in rc.d feel like bubblegum and string and if it takes a little dust to improve things I'm OK with it.