There have, historically, been two kinds of operating systems: general-purpose, and special-purpose. These roles are defined by the function they serve for the user. Examples of general-purpose operating systems include Unix (Linux, BSD, etc), Solaris, Haiku, Plan 9, and so on. These are well-suited to general computing tasks, and are optimized to solve the most problems possible, perhaps at the expense of those in some niche domains. Special-purpose operating systems serve those niche domains, and are less suitable for general computing. Examples of these include FreeRTOS, Rockbox, Genode, and so on.
I like stateless tokens. We started with stateful tokens: where a generated string acts as a unique identifier for a resource, and the resource itself is looked up separately. For example, your sr.ht OAuth token is a stateful token: we just generate a random number and hand it to you, something like “a97c4aeeec705f81539aa”. To find the information associated with this token, we query the database — our local state — to find it.
Email is important to my daily workflow, and I’ve built many tools which encourage productive use of it for software development. As such, I’m often asked for advice on choosing a good email service providers. Personally, I run my own mail servers, but about a year ago I signed up for and evaluated many different service providers available today so that I could make informed recommendations to people. Here are my top picks, as well as the criteria by which they were evaluated.
Like last month, I am writing to you from the past, preparing this status update a day earlier than usual. This time it’s because I expect to be busy with planned sr.ht maintenance tomorrow, so I’m getting the status updates written ahead of time.
I’m working on improving the means by which API users authenticate with the SourceHut API. Today, I was reading RFC 6749 (OAuth2) for this purpose, and it got me thinking about the original OAuth spec. I recalled vaguely that it had the API clients actually sign every request, and… yep, indeed it does. This also got me thinking: what else signs requests? TLS!
There’s a common pattern among free- and open-source software projects to include a “contrib” directory at the top of their source code tree. I’ve seen this in many projects for many years, but I’ve seen it discussed only rarely — so here we are!
Hello, future readers! I am writing to you from one day in the past. I finished my plans for today early and thought I’d get a head start on writing the status updates for tomorrow, or rather, for today. From your reference frame, that is.
Tim Bray’s excellent “Bye Amazon” post inspired me to take this article off of my backlog, where it has been sitting for a few weeks. I applaud Tim for stepping down from a company that has demonstrated itself incompatible with his sense of right and wrong, and I want to take a moment to remind you that the rest of us in the tech industry have the same opportunity — no, the same obligation as Tim did.
As someone who has been often maligned by the disappearance of my data for various reasons — companies going under, hard drive failure, etc — and as someone who is responsible for the safekeeping of other people’s data, I’ve put a lot of thought into solutions for long-term data retention.
I use aerc as my email client (naturally — I wrote it, after all), and I use git send-email to receive patches to many of my projects. I designed aerc specifically to be productive for this workflow, but there are a few extra things that I use in my personal aerc configuration that I thought were worth sharing briefly. This blog post will be boring and clerical, feel free to skip it unless it’s something you’re interested in.