I was mostly kidding. But the little bit that bothered me was the idea that ‘it is so simple here are 8 pages to barely scratch the surface.’
cron works fine for me. And if I ever have to work in an environment where I can’t use cron and systemd is available, then of course I will use it. Thus far that has never been the case.
Yeah, I think it’s just the way the blog post was written. When I was reading it I saw the first few paragraphs was basically “here’s how to do Cron with it”, and then everything after that was “here’s a bunch of other features it has that cron doesn’t and how to use those”
I don’t think that’s the wrong way to write this kind of article, but I could see it feeling overwhelming on a skim, because it may feel like you need to read the whole thing in order to get anything working. But actually only the start was necessary, and the rest was tasty feature pitch.
Which all of them, which cron implementation is simpler and better? Do you even use cron? It’s not a joke, explanation on how to use cron takes > 8 pages. It should be in the hall of fame of the least accessible and hard to learn programs. Lennart cancer is one of the greatest things that happened to linux.
I’m not the OP, but I can explain how to use cron in like 4 sentences:
Edit cron with the command crontab -e, this opens your text editor. If you want your jobs to have environment variables, put those at the top. Put this header at the top: # m h dom mon dow command
It means minute, hour, day of month, month, day of week, command. Type in numbers for these values or a star which means all of them. Command is the command to be run.
And then with your explanation it goes: cron job doesn’t execute for reason, crontab -l lists not all jobs, someone else put cron job in whatever directory like cron.daily, you’ve added or removed empty line at the end and now nothing works, debian crond and redhat cronie ahave different quirks, etc., etc.
I’ve dealt with insane cron problems for so long that switching to timers was like *whoa i don’t need to suffer?*
I’ve been doing this stuff for 30 years. The helpful blog post that took 8 pages of text to explain how to schedule a job just made me angry.
I think I am finally into greybeard territory even though my beard made the change a few years ago. Damn.
Why did it make you angry? Do you believe that there are other implementations that do the task better and simpler?
I was mostly kidding. But the little bit that bothered me was the idea that ‘it is so simple here are 8 pages to barely scratch the surface.’
cron works fine for me. And if I ever have to work in an environment where I can’t use cron and systemd is available, then of course I will use it. Thus far that has never been the case.
I argue for a 5% cost-of-living adjustment for bad software, and I make sure it’s a separate line item so they know it goes away when systemd goes.
Yeah, I think it’s just the way the blog post was written. When I was reading it I saw the first few paragraphs was basically “here’s how to do Cron with it”, and then everything after that was “here’s a bunch of other features it has that cron doesn’t and how to use those”
I don’t think that’s the wrong way to write this kind of article, but I could see it feeling overwhelming on a skim, because it may feel like you need to read the whole thing in order to get anything working. But actually only the start was necessary, and the rest was tasty feature pitch.
All of 'em. If a joke took 8 pages to explain, it wouldn’t be funny either. Lennart’s cancer can go, thanks.
Which all of them, which cron implementation is simpler and better? Do you even use cron? It’s not a joke, explanation on how to use cron takes > 8 pages. It should be in the hall of fame of the least accessible and hard to learn programs. Lennart cancer is one of the greatest things that happened to linux.
I’m not the OP, but I can explain how to use cron in like 4 sentences: Edit cron with the command crontab -e, this opens your text editor. If you want your jobs to have environment variables, put those at the top. Put this header at the top: # m h dom mon dow command It means minute, hour, day of month, month, day of week, command. Type in numbers for these values or a star which means all of them. Command is the command to be run.
You can explain timers the same way.
And then with your explanation it goes: cron job doesn’t execute for reason,
crontab -llists not all jobs, someone else put cron job in whatever directory like cron.daily, you’ve added or removed empty line at the end and now nothing works, debian crond and redhat cronie ahave different quirks, etc., etc.I’ve dealt with insane cron problems for so long that switching to timers was like *whoa i don’t need to suffer?*