4 ms·

It's pretty intuitive once you've done it twice unlike cron's impenetrable syntax, tbh. They also have other desirable behavior like being able to configure it

by tscs37 8y ago

It's pretty intuitive once you've done it twice unlike cron's impenetrable syntax, tbh. They also have other desirable behavior like being able to configure it concurrent runs are allowed or if the script should run if the initial date was missed or even restart the job if it fails up to a limit. It's much more versatile than simply cron, due to that, it's also a lot more useful.

jimktrains2 8y ago
https://www.freedesktop.org/software/systemd/man/systemd.time.html https://www.freedesktop.org/software/systemd/man/systemd.tim... is 1300+ words. https://www.freebsd.org/cgi/man.cgi?crontab(5) https://www.freebsd.org/cgi/man.cgi?crontab(5) is 1400 or so. I'd hardly call that impenetrable. Additionally you will note that free bad has an extension to the format for shortcuts like monthly, weekly, &c.
- tscs37 8y ago
  I'm aware of the extension but Systemd Timers have RandomizedDelaySec which allows me to schedule nightly backups without having to coordinate about 20 different machines into timeslots. I should note that `man crontab | wc` returns 1680 words while `man systemd.timer | wc` returns 1300 words. Take that for what you while, especially since .timer spends most words on explaining the options instead of the syntax.
  - jimktrains2 8y ago
    There's little functional difference between syntax and options in this case, as the options in systemd serve the same purpose as the syntax iin crontab. I just don't want cron doing randomized delay and repeats. That should functionally be determined by the application.
    - tscs37 8y ago
      >I just don't want cron doing randomized delay and repeats. That should functionally be determined by the application. I think it's perfectly fine that timer does this, it's useful. The applications I run don't support this behaviour out of the box, so why should I have to code up something for each app? >There's little functional difference between syntax and options in this case, There is an important difference. The manpage on timers spends most words explaining what exactly each option does and how it can be useful while most of the crontab manpage explains how the syntax works, the options crontab provides are minimal.
jimktrains2 8y ago
> It's pretty intuitive once you've done it twice unlike cron's impenetrable syntax, tbh. Give me a few minutes to recover from laughing, please. Impenetrable. Lololololol. > They also have other desirable behavior like being able to configure it concurrent runs are allowed or if the script should run if the initial date was missed or even restart the job if it fails up to a limit. Those just feel out of scope to me. Why would I want this tool to handle that? > It's much more versatile than simply cron, due to that, it's also a lot more useful So much laughing this morning! You should really try an open mic night!
- tscs37 8y ago
  >Give me a few minutes to recover from laughing, please. Impenetrable. Lololololol. ? It's a personal opinion, you can laugh all you want but that won't make it any more wrong than yours. >Those just feel out of scope to me. Why would I want this tool to handle that? I run my backups with a systemd timer. Since it's a desktop system it might not be online during a desired timeslot so the backup can be repeated once the machine becomes available after that. Additionally it prevents concurrent backup runs on my servers if a snapshot is taking longer for a reason (which does happen when too many servers get scheduled at the same time, which btw, is handled by having the timer with a random offset to the schedule which last I checked is not present in cron). It's something I want this tool to handle, yes. >So much laughing this morning! You should really try an open mic night! Why? Because I find a tool that solves my problems useful? Sounds like you should reconsider your standpoint because to me it sounds like you claim that cron is the one true tool to solve timed scheduling of scripts. Which it clearly isn't since cron doesn't solve the problems I have.
  - jimktrains2 8y ago
    No, I'm laughing at the thought of cron being impenetrable and complex.
- dang 8y ago
  Commenting like this will get you banned here, and you've unfortunately been uncivil in the past too. Please read https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html and use the site as intended from now on.

by tscs37 8y ago

jimktrains2 8y ago

https://www.freedesktop.org/software/systemd/man/systemd.time.html https://www.freedesktop.org/software/systemd/man/systemd.tim... is 1300+ words. https://www.freebsd.org/cgi/man.cgi?crontab(5) https://www.freebsd.org/cgi/man.cgi?crontab(5) is 1400 or so. I'd hardly call that impenetrable. Additionally you will note that free bad has an extension to the format for shortcuts like monthly, weekly, &c.

tscs37 8y ago
I'm aware of the extension but Systemd Timers have RandomizedDelaySec which allows me to schedule nightly backups without having to coordinate about 20 different machines into timeslots. I should note that `man crontab | wc` returns 1680 words while `man systemd.timer | wc` returns 1300 words. Take that for what you while, especially since .timer spends most words on explaining the options instead of the syntax.
- jimktrains2 8y ago
  There's little functional difference between syntax and options in this case, as the options in systemd serve the same purpose as the syntax iin crontab. I just don't want cron doing randomized delay and repeats. That should functionally be determined by the application.
  - tscs37 8y ago
    >I just don't want cron doing randomized delay and repeats. That should functionally be determined by the application. I think it's perfectly fine that timer does this, it's useful. The applications I run don't support this behaviour out of the box, so why should I have to code up something for each app? >There's little functional difference between syntax and options in this case, There is an important difference. The manpage on timers spends most words explaining what exactly each option does and how it can be useful while most of the crontab manpage explains how the syntax works, the options crontab provides are minimal.

jimktrains2 8y ago

> It's pretty intuitive once you've done it twice unlike cron's impenetrable syntax, tbh. Give me a few minutes to recover from laughing, please. Impenetrable. Lololololol. > They also have other desirable behavior like being able to configure it concurrent runs are allowed or if the script should run if the initial date was missed or even restart the job if it fails up to a limit. Those just feel out of scope to me. Why would I want this tool to handle that? > It's much more versatile than simply cron, due to that, it's also a lot more useful So much laughing this morning! You should really try an open mic night!

tscs37 8y ago
>Give me a few minutes to recover from laughing, please. Impenetrable. Lololololol. ? It's a personal opinion, you can laugh all you want but that won't make it any more wrong than yours. >Those just feel out of scope to me. Why would I want this tool to handle that? I run my backups with a systemd timer. Since it's a desktop system it might not be online during a desired timeslot so the backup can be repeated once the machine becomes available after that. Additionally it prevents concurrent backup runs on my servers if a snapshot is taking longer for a reason (which does happen when too many servers get scheduled at the same time, which btw, is handled by having the timer with a random offset to the schedule which last I checked is not present in cron). It's something I want this tool to handle, yes. >So much laughing this morning! You should really try an open mic night! Why? Because I find a tool that solves my problems useful? Sounds like you should reconsider your standpoint because to me it sounds like you claim that cron is the one true tool to solve timed scheduling of scripts. Which it clearly isn't since cron doesn't solve the problems I have.
- jimktrains2 8y ago
  No, I'm laughing at the thought of cron being impenetrable and complex.
dang 8y ago
Commenting like this will get you banned here, and you've unfortunately been uncivil in the past too. Please read https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html and use the site as intended from now on.