alt Hacker NewsI am not agreeing with egorfine. Indeed, why not improve what we can improve?
> cron did a job, but had shortcomings. Systemd addresses many of those shortcomings
Right, but what are those "many" shortcomings? The article lists four, and fully half of them seem to be nonsense, per my comment. (time spec syntax appears to be equally complex in systemd timers, and I have no idea what they mean about PATH, as it seems equal too)
The remaining two are fairly good points, kind of. Sending mail is a black hole until you look there, sure. Believing that emails get meaningfully delivered on a non-email server is very anachronistic. But isn't logging a black hole until you look there too?
So from the article that leaves "Execution history is difficult to follow and interrogate", which I super agree with. I would argue it's not inherent to cron, and one could have written a small tool that allows following and interrogating.
And… surely that goes for logging too? cron does log to syslog, right?
Maybe there's some integration with other stuff that is better, that I'm not aware of?
I'm not disputing that it's better. I'm sure it is. But where's that list? If it's literally only the `list-timers` command, then that's very underwhelming. Is it the randomness to scheduling? I've never needed it (I just spread them out over an hour by fixed start time), but sure that would have value in other cases where coordination is not possible. You could add it to cron, but not in a nice way.
To me it seems like engineers do what engineers like to do: enjoy greenfield implementations. It's open source. Nobody's going to ding your quarterly performance evaluation for going off on a amusement coding session without a requirements doc. I know that I have written a lot of tooling for amusement and to work the way I want it to work. I certainly understand the engineering mind that would rather write something from scratch than understand the previous system.
I don't mind learning new things, but this article seems to fawn over stuff you can do in systemd timers, where… yeah that was always an option (in cron). I don't have faith that the article writer actually knew cron before they trash it in favor of something else.
On a tangent, I do agree with egorfine that Lennartware inherently has a disdain for users and their workloads (e.g. kills user processes inside a screen/tmux arbitrarily), and that audio on linux was set back 5-10 years just from the mere disastrously bad quality of the pulseaudio implementation. It makes sense that he works for Microsoft.
Well theres a few more:
* coalescing jobs with control over the granularity of it. That means you can say "i want this job run on at 14:30:02 exactly" and I want these jobs run at 19:21 or so, 19:22 or so: and 19:23 and set your resoultion to 10m and they'll all run at once. Great on laptops and other scenarios where you want to reduce power draw.
* System wakeup - you can wake a system from sleep various sleep modes (details depend on hw support) and run a job.
* cohesion with the rest of the system. this is a big deal when you stop playing with just your desktop and pet server and have to deal with 10^4 or more servers. having to deal with the wierd quirks of cron vs inittab vs whatever is frustrating and when there are many people working on it, someone is always going to do something quirky and fragile. Yes you have to know the systemd things, but that's it - a timer starts a unit, any unit, without all the bullshit (e.g, oh im stating with cron, these magic invocations are neeeded, oh im starting it with runit and these different invocations are needed, etc)
I literally never experienced any of the problems people complain about for pulseaudio - at the time it was released it was the smoothest audio experience i ever had on linux. I think some people just want to look cool and complain about the new thing.... But also I read manuals and think for 3 or 4 seconds before doing things, so maybe it has something to do with that.