zerosleeps

This article about systemd timers made it to the front page of Hacker News today. I always get a little bit upset when I see documentation or advice that talks about defining a cron job, as if cron is the only way of scheduling tasks. Cron served us well, but if you know what cron and systemd are you should read the documentation for systemd timer units.

This:

OnCalendar=Thursday 18:00 Australia/Melbourne

Is so much nicer than:

0 7 * * 4

Now I will conceded that as with most of the components of systemd, the manuals don’t make it very easy to discover all the magical things you can do with unit files, but the few minutes I took several years ago doing just this have saved me way more time since then.

Bonus tips: systemd-analyze calendar is a cute little tool to know about too:

$ systemd-analyze calendar "Thursday 18:00 Australia/Melbourne"
  Original form: Thursday 18:00 Australia/Melbourne
Normalized form: Thu *-*-* 18:00:00 Australia/Melbourne
    Next elapse: Thu 2025-03-20 07:00:00 UTC           
       From now: 6 days left

Plus! systemctl list-timers gives you a nice list of loaded timers with human-readable “last run” and “time to next run”, and systemctl status timername.timer works as you’d expect as well, including a tail of the output of the last run. You get all of that for free because the timers trigger regular systemd units, which in turn means (by default) output gets sent to the systemd journal. It also means you can manually trigger the same unit at any time and know it will behave the same whether run by a timer or not.

Way better than cron. Fight me.

Giles Thomas with some thoughts on writing blog posts they’d wish they’d found.

I try to do this myself, and from a peek at my post history it looks like maybe every third-or-fourth post covers either something I just know I’ll need to refer to in the future and might also be useful to other people, or it’s about some problem that nobody else seems to have written about.

As an example of the former, I have already referred to this post about rebooting an Apple Siri Remote myself about half-a-dozen times since creating it in January. I roll my eyes every time.

And for the latter, well consider this: I don’t track traffic to zerosleeps.com beyond what my web server sends to systemd’s journal, which in turn only keeps those logs for it’s default retention period, but every time I have a look it’s the same 3 posts that show up at the top:

• Dead (but not dead) Ubiquiti UniFi Security Gateway, documenting a problem that presumably lots of people have but is poorly covered elsewhere
• More myki confusion, which doesn’t have much actionable information but obviously resonates with the folk of/visitors to Melbourne
• Sublime Text timestamp snippet, which contains very outdated code and has been superseded by this information

Adrian Holovaty, one of the co-creators of Django:

Every web page on our site is served by Django — in other words, there’s no single-page-app stuff. I’ve always found the idea of single-page apps to be “against the grain”: it goes against how web browsers are optimized, and it goes against how HTTP/HTML were designed.

And:

I think an entire generation of web developers has been misled into assuming JS frameworks are table stakes for building high-quality web apps — and that is 100% wrong.

I had to reboot our remote control last night. What a time to be alive.

(It’s a third generation Siri Remote: it’s infrared thing stopped working and it was sorted by holding down the TV button + volume down button for about 5 seconds.

This article by Dan Goodin at Ars Technica is pretty good. I grumbled about one aspect of this in October: tying authentication to a particular device isn’t going to work.

While I’m complaining, I have accounts with half-a-dozen services that offer passkey authentication and they all do it differently. For example:

• Fastmail does it properly: I visit the login page and instruct my password manager to sign in with passkey. Done. It’s delightful.
• LinkedIn does this as well but still prompts for a one-time password on the next screen, which seems… redundant.
• Amazon will only let me present my passkey once I’ve entered my username, and then they ask for a one-time password as well. 3 screens. What’s the fucking point? The user experience does not benefit at all.

But here’s Goodin on the thing that all of these services still do:

Of the hundreds of sites supporting passkeys, there isn’t one I know of that allows users to ditch their password completely. The password is still mandatory. … This fallback on phishable, stealable credentials undoes some of the key selling points of passkeys.

The more I think about it the more I reckon this is why passkeys aren’t going to solve anything. Users forget their username/email address/password all the time, so there’s no reason to assume passkeys won’t be misplaced all the time as well. That means we still need to build account recovery processes, and it doesn’t matter which way you cut it, something in that process has to send an email or ask a question or send a code or something, utterly defeating many of the technical benefits of a passkey.