Anthonin Bonnefoy, Mitch Ward, and Gillian McGarvey on the Datadog blog:

Ultimately, by successfully isolating and debugging the crashes down to the assembly level, we were able to identify an issue in Postgres JIT compilation, and more specifically a bug in LLVM for Arm64 architectures. This post describes our investigation into the root cause of these crashes, which took us on a deep dive into JIT compilation and led us to an upstream fix resolution.

A crashing database must be a pretty stressful scenario when working at the sort of scale Datadog is operating at. Great detective work getting to the bottom of the issue. Also interesting to learn that they’re running the db on ARM servers.

With JIT disabled, the query ran without triggering a segfault. As an immediate mitigation, we disabled JIT for the entire cluster, which stopped the crashes completely and without any noticeable impact on query latencies. It was time to relax and grab a cup of coffee.

If turning the JIT off had no noticeable impact on the query latencies you have to wonder if it’s worth the trouble of using it?

Jono Finger:

This is my perspective on using Nix (the OS, the package manager, and the language) as a main driver for the past 2 years. I have gone to conferences, engaged the community, donated, submitted bug reports, converted my home servers, and probably spent hundreds of hours in Nix configs. I consider myself well versed, but certainly no expert.

TLDR: In its current state (2025), I don’t generally recommend desktop use of Nix(OS), even for seasoned Linux users.

That’s a pretty strong summary, but I’m not sure I’d take this post as general advice. It’s detailed, and documents Jono’s experience, but with any niche system like NixOS you’re going to run into paper cuts. The specific paper cuts will vary by person based on what they do with their computer, as will their threshold for tolerating them.

To be clear, I love Nix and have learned a lot from it. I am not giving up on it, but its time for me to take a break and scale back my all-in attitude.

In this case it seems Jono reached their paper cut threshold, which is totally reasonable. Some people will push through because they want the benefits despite the friction, others will drop off earlier. If you’re thinking of trying out NixOS I think this post is worth a read, but I wouldn’t let you stop you from trying it out.

JSON Feed is a specification by Manton Reece and Brent Simmons for a syndication format like RSS and Atom that uses JSON instead of XML. Robb Knight posed the question:

Ignoring podcasts, which has to be RSS, is there an argument for using RSS/atom over JSON feeds?

Ruben Schade responded with a thoughtful post citing several theories as to why RSS/Atom feed are still the default:

• JSON Feed suffers the XKCD Standards Effect. Every blog has RSS support, even those that implement JSON Feed. I’ve yet to encounter the reverse. If JSON feed were offering anything more than an alternative serialisation format, maybe it’d be more compelling. But RSS does the job, and adding another standard didn’t offer much.
• JSON Feed was mostly a redundant format. As I wrote in 2017, if the issue with RSS was XML, you could directly serialise RSS with JSON. JSON Feed was entirely new, which requires you to reimplement everything to do… what you can already do with an existing tool. Meh.
• JSON Feed solved a problem for developers, not users. People who write material that end up in feeds, and the people who read those feeds, couldn’t give a toss what the format is written in. Those of us in the industry forget this at our peril, every single time.

These are great points and it seems unlikely that JSON Feed will displace RSS and Atom as the default syndication formats in use. However, I want to discuss that last point a little more.

Ruben is right that the typical visitor that wants to subscribe to your website doesn’t care what the format is, as long it works in their feed reader. Although I’d argue that developers that want to make use of content in a machine readable form are users too. And for that purpose JSON is way easier to handle than XML. Here’s a couple of examples of that in practice:

• The unreleased tool that posts each new post on this site to Mastodon uses the JSON Feed as the source of posts.
• This tutorial used the JSON Feed from Read Rust (an earlier project of mine) to build a CLI tool for the site.

It’s also easy to consume JSON on the command line with curl and jq/jaq. For example, this command line lists all the posts in the Linked List JSON Feed that are tagged with ‘retro‑computing’:

$ curl -s https://linkedlist.org/feed.json | \
    jaq '.items | map(select(.tags | contains(["retro-computing"]))) | .[].title'
"More Than You Ever Wanted to Know About the Windows 3.1 Graphics Stack"

All that is to say I think JSON Feed has utility even if it doesn’t replace XML based feeds. I think of JSON Feed as an additional representation of my website, not a replacement for RSS and Atom feeds. As I a result I offer both, so visitors can use whatever format makes sense for their use-case.

Alex Korban:

I was recently on a project where I chose to use React and TypeScript as part of the tech stack because of the existing skillset of my team. I myself managed to avoid both React and TypeScript until this year. So when I finally used them on a real project, I was looking at them as an experienced Elm & Elixir developer, coming from small niche ecosystems into the din of the real world. I think that’s an interesting perspective to share.

Reports like this based on real world experience are indeed often interesting. They can expose both positive and negative aspects of an ecosystem that go unnoticed if you’re already deeply invested, which can help drive improvements on both sides of the fence.

Perhaps unsurprising due to having already self-selected a preference for Elm, Alex found the TypeScript and React experience a bit underwhelming—although not only for technical reasons.

Louie Mantia lamenting the lack of standard UI in software these days:

Dan Counsell [on Mastodon]:

Can we please have the macOS X Lion UI back? 😍

Yes, I would also like that. I would welcome any standard UI that gives us back some tools we lost.

There’s a refined clarity to this version of Aqua. It evolved gracefully to this point, where every element was distinctly different and yet cohesive. Consider the search field alone. Now, search fields have the same appearance of every other field: squared. The pill shape distinguished itself. Removing that characteristic introduced a level of ambiguity that is unnecessary. The same can be said for so much in modern visual design (or lack thereof).

There really is a clarity to those controls. They have decent contrast, depth is used to help make it clear they are interactive, and there’s even some colour.

It’s a shame that the idea of standard UI seems to have been relegated to the history books with the move of more software to the web. Now every application needs to build its own component library more or less from scratch because the platform lacks a decent standard UI.

Design and fashion being cyclic, I wonder if in a decade or so we’ll see a return to interfaces with depth and character in the future instead of the grey flatland we have now.