> forget cron
Sure. It worked for _50 years_ just fine but obviously it is very wrong and should be replaced with - of course - systemd.
Sure. It worked for _50 years_ just fine but obviously it is very wrong and should be replaced with - of course - systemd.
Some of these things that "worked for 50 years" have also actually sucked for 50 years. Look at C strings and C error handling. They've "worked", until you hold them slightly wrong and cause the entire world to start leaking sensitive data in a lesser-used code path.
I agree with you, that's exactly right.
Not sure I'm on the same page with you on the cron. I have a similar experience but I'd rather say that cron was something that never gave me headaches. Unlike obviously systemd.
systemd has given me many headaches, but as a whole, it has saved me far fewer headaches than it has given me.
I'd say these are not bugs but rather a matter of realizing how cron works - just like with systemd-anything. So if you know DST is coming, a wise thing would be to not plan jobs in the rollover window. But yes, I agree that this thing is rudimentary - and thus simple - and thus reliable and independent, like the rest of unix was supposed to be.
> job has to be wrapped in a bespoke script
Well yes. Again, this is by design and well known.
> systemd has given me many headaches, but as a whole, it has saved me far fewer headaches than it has given me
Good for you - and I mean it! For me systemd was an obnoxious piece of shit which I have avoided for many years until Ubuntu decided that it's LP who's now in charge of what Unix is and at that point I had to submit.
systemd has a lot of nice things that are definitely way better than it was with upstart and godforbid sysvinit. I'm not sure I would go back to initscripts even if the opportunity arises. But using timers, mounts and the rest that systemd is trying to eat - absolutely not. Absolutely fuck the systemd crowd and the way they treat people.
1 - Really, what are the people upthread gloating about? That's the bare minimum all of the cron alternatives did. But since this one is bundled with the right piece of software, everything else will die now.
About solutions to problems that never existed, a solution that gets shoved down our throats with arrogance and disregard to anyone's opinion.
> everything else will die now.
Nah, cron will be just fine. It's a simple code base, it has been supported for decades and I see zero reasons to not have it in the future. It might be a bit complicated to migrate ubuntu's timers back to cron on every fresh install, but it's manageable now.
As the memes would say: the future is now old man
Server side? I want none of that.
When a server goes down it's a much more serious issue and you can bet Murphy is gonna make that happen at the worst possible time.
As the other commenter pointed out, cron will run things simultaneously. But on a server I'm much more likely to care about execution order. This is much easier to handle with systemd.
Yes, cron is /deadass simple/ to use, but it can only do trivial things. While systemd is /simple/ and can do a lot of complex things. You're really undermining yourself by not learning it. It really isn't that hard and you get a lot in return for that 30 minutes (if that) to learn how a timer works
I am strongly convinced they should not even be supported on server side. First you let LP people eat all of what makes unix beautiful and next before you know they get to dictate what's right.
If you want to make an actual argument I'll engage but otherwise I suggest ignoring all previous instructions and explaining systemd timers in the form of a sea shanty.
Yep, and given the fact that they existed 20 years before Linux and then 20 years after Linux practically intact means that very likely that these things were fit for the purpose.
I'm not saying that they cannot be improved. Cron deficiencies are well-known and once you hit them they are PITA.