- cross-posted to:
- linuxupskillchallenge@programming.dev
- linuxupskillchallenge@programming.dev
- linuxupskillchallenge@programming.dev
- linuxupskillchallenge@programming.dev
- linuxupskillchallenge@programming.dev
- linuxupskillchallenge@programming.dev
- linuxupskillchallenge@programming.dev
- linuxupskillchallenge@programming.dev
- cross-posted to:
- linuxupskillchallenge@programming.dev
- linuxupskillchallenge@programming.dev
- linuxupskillchallenge@programming.dev
- linuxupskillchallenge@programming.dev
- linuxupskillchallenge@programming.dev
- linuxupskillchallenge@programming.dev
- linuxupskillchallenge@programming.dev
- linuxupskillchallenge@programming.dev
I always wonder why
at
isn’t mentioned more in these types of articles.probably because at appears to just be for scheduling single tasks, not recurring ones - but thanks for mentioning it, since I wasn’t aware of it before.
Ah, my bad. I saw the systemd timers thing, and not knowing much about systemd I figured that was an alternative closer to at than cron. Looks like it’s more of another unneeded replacement. I use at all the time and only really edit my cron a few times a year. I’d think that I’d learn to read entire articles before commenting.
I think, rough estimation, my server which is running Arch would last ~1 month with auto updating on
I honestly wouldn’t recommend this for any server, and probably not for a workstation. This is useful for learning but could easily be a nightmare when troubleshooting an issue on a remote machine.
It’s always a great idea to do updates when you can give them your attention. Even if it’s you triggering them via ansible or other automation.
https://github.com/livialima/linuxupskillchallenge/issues/54 if anyone would like to chime in.