You can argue that no other system matters (which I strongly disagree with for reasons I don't want to get into right now), but that doesn't make systemd timers any more portable.
You can argue that no other system matters (which I strongly disagree with for reasons I don't want to get into right now), but that doesn't make systemd timers any more portable.
Do you take portable to mean a program that can run on every processor arch and OS available?
The definition of the word "portable" is not the point of this comment thread (although if you want to hear my definition, see the reply to a sibling comment).
Let's take the context into account:
> hashworks:
While I support systemd timers over cron, AFAIK cron has stuff like @hourly.
> caiusdurling:
Some cron implementations do, it's not portable.
> bheadmaster:
Neither are systemd timers. I don't think there's a single system out there implementing the systemd timer interface.
User caiusdurling said @hourly is not portable between cron implementations as a way to discredit hashworks' argument about cron having @hourly.However, that's a disingenious argument, because systemd timers aren't any more portable than cron implementations that use @hourly - in fact, there isn't a single system out there implementing the systemd timer interface except systemd.
In context of systemd, systemd isn't portable because it highly depends on Linux API and thus cannot be ported on any other UNIX-like (or unlike) OS.
In context of systemd timers, systemd timers aren't portable because there isn't as single alternative implementation that can interpret systemd timer unit files.