My favorite metonymic technology term is “cron job”: even though
cronmay not literally be the daemon that executes actions on a schedule, we apply the term to anything that walks like acronand quacks like acron. As Patrick McKenzie likes to point out, cron jobs are one of the most eminently useful computing primitives. They offer utility that’s almost immediately obvious for plenty of use cases that almost everybody has: do this every day; do that once a month.And yet. You probably shouldn’t use literal
↫ Tyler Langloiscron(or its more modern cousins) for scheduled tasks! In 2026 there are more modern options available, and my favorite is the humble systemd timer. I love systemd timers. If you don’t love them yet, maybe I can show you the reasons why you should love them, too.
These are just timers. They are not consuming your computer or taking over the open source world. They do not phone home to Red Hat. These are just timers.
I’ve had so much more success working with systemd timers to get work shit accomplished than I ever did with good old fashioned cron. There were complicated things I couldn’t get working with cron _even though it’s hypothetically simpler_ that “just worked” with systemd timers.
*accepts his shill check from Big Hat*
Same here. Conceptually, philosophically, and religiously I don’t have a problem with systemd. Yes, it’s more complicated and has a bigger codebase than other init systems, mainly because it’s not just an init system. But if you think about it there’s nothing simple about the functionality achieved in any capable modern OS, and I personally think that any good OS should abstract away its core complexities and present an interface that allows the end user (or admin) to easily make actual features *work* the way they want, without needing to understand the esoteric low-level components. For me, systemd timers get the job done, and as the article mentions they do so with some additional features and reduced complexity **for the end user**. I also have had great results with mounting SMB shares via a systemd.automount unit; that method has proved to be somewhat easier and much more reliable than autofs, which used to even cause temporary freezing/hanging of the entire system.
My only major complaint with systemd is how it was originally presented as having advantages to make the system boot faster. But in actual practice, my custom-installed fairly minimal Debian system boots on my Intel i7 laptop with NVMe storage in about the same time as a well-optimized Upstart or sysvinit system used to do 15 years ago on my Celeron laptop with spinning rust. And don’t get me started on the *long* hangs for “A stop job is running for …” during shutdown.