For the past few years, my RSS feeds have lived locally on my phone only. There was a good idea behind that, but it never quite worked in practice. For one, many things are easier to read on a larger screen. But it was also brittle to trust a phone app to manage the read/unread status of thousands of articles across a hundred feeds. What I really wanted was a server-side feed aggregator. This is software that runs on a server, manages RSS feeds, and then I can read the RSS feeds either through a web interface, or through client applications. I’ve wanted that for a while, but I’ve never taken the step, because it would be yet another side project to maintain the deployment of.

But now, with some NixOS experience, adding a working FreshRSS configuration (including backups) took 9 lines of Nix code. That installation has just hands-off worked for the past few months. If or when that server breaks, I can spin up a new one running the exact same configuration, probably in something like 15 minutes. When we can do something like that, there is literally no reason to not just try the new software.

Contrast this against how FreshRSS is installed outside of NixOS. Then we’d

(Continue reading the full article on the web.)

If it could be shown to be true, that’d be useful. The argument Shore is making about the effects of robot-generated code does not depend on the specific numbers, so Shore’s numbers come from a hypothetical wisdom-of-the-crowds aggregation rather than concrete data. But no hypotheticals are necessary here. We have a thing called git.

Let’s say we have a way of labeling each commit as either “new development” or “maintenance”. Then we can count how many commits of each type there are in a month. Possibly better, we can count how much complexity has been handled in a month.

The following plot shows the cumulative effort that has gone into the development of tmux since its beginning to the day I start writing this article.

(Continue reading the full article on the web.)

If you’re struggling to find the difference against normal Colemak, look at the cluster of five keys next to the return key.

This layout makes room for the three Swedish letters Å, Ä, and Ö, by only changing five keys in total, and they have changed very thoughtfully:

(Continue reading the full article on the web.)

• Will there be a cease-fire in Ukraine in 2026?
• Will there be a cease-fire in Sudan in 2026?

When I entered my forecast for these questions, I did it based on Laplace’s rule of succession, i.e. as a function of their duration only. This is sort of justified if war durations are heavy-tailed, which would mean that the longer they go on for, the less likely it is that peace comes soon. But I don’t know if that is true.

Either way, this first, roughest forecast is

(Continue reading the full article on the web.)

• Magit
• Perl 5 Core Maintenance Fund
• XMonad

These are important to me, they need more money, and I believe they can use donations well. If you disagree, I’d genuinely like to hear what mistakes I’ve made in the analysis below. I hope it shows that this is important to me.

(Which is also why it is so heart-warming when people reach out to tell me this article prompted them to donate some of their own money. Thank you for being so kind.)

(Continue reading the full article on the web.)

This has worked surprisingly well, but that’s only because my expectations were low to begin with. The VM can barely access the hardware of the underlying machine: it can’t use the GPU, it can’t use the front-facing camera, Linux starts thrashing weirdly when the VM runs out of memory, among other quirks I’ve learned to work around. Thus, I’ve wanted to re-install on bare metal for a while, but! problem!

Come on a journey with me. It’s got a hero with hubris, mistakes, tension, and a cliffhanger.

During a transition period, I want to have two copies of the Fedora installation, and I couldn’t figure out how to fit it in:

(Continue reading the full article on the web.)

If we have Simon Willison’s llm CLI tool installed (and you should – it’s great!), we can call it in a pipe from Perl, and read its response. My script had a loop that retried the request a few times, but without that bookkeeping, the code for this is simple enough.

sub classify {
    my ($msg) = @_;
    my $pid = open2(
        my $output,
        my $prompt,
        'llm -m openrouter/openai/gpt-5.6-luna'
    );
    print $prompt prompt_template($msg);
    close $prompt;

    # Slurp the entire response and chomp off the
    # trailing newline.
    chomp(my $result = do { local $/; <$output> });
    waitpid($pid, 0);

    return $result;
}

The drawback of this approach is that I wanted to label some 21,000 commits, and this shells out to the LLM for every single commit. Since the prompt is designed to contain mainly input tokens and not many output tokens (see Appendix C for details), these calls are cheap in money, but the latency is no fun, at around 1.5 seconds per call.

(Continue reading the full article on the web.)

The most recent issue was the stack limit being blown by a helper function involved in generating the tag index. I had written it to be explicitly recursive, which worked fine with a small-ish number of published articles, but not anymore. The tag index creation follows a similar pattern to the RSS feed generation detailed in the previous article.

(defun tw-tag-index (project)
  "Generate a tag index page for PROJECT."
  (let* ((filename (concat (project-dir "src" "org") "tags.org"))
         ;; Get all publically listed files in this project.
         (files (seq-filter (lambda (entry) (plist-get entry :indexed))
                            (tw-get-all-files project)))
         ;; Convert to sorted alist of tag×article pairs.
         (all-tags (sort (tw-get-all-file-tags files)
                         (lambda (a b) (string< (car a) (car b))))))
    (with-temp-file filename
      (insert (concat
               "#+TITLE: Tags\n"
               ;; Don't show author and publish date.
               "#+AUTHOR: \n"
               ;; Don't list in public indices.
               "#+FILETAGS: :page:\n\n"
               ;; Include table of contents.
               "#+TOC: headlines:1\n\n"
               ;; Then produce headings for each tag.
               (org-element-interpret-data
                   (tw-article-entry-headlines all-tags)))))
    ;; Return the filename of the created file. I don't
    ;; remember why. Maybe it's not necessary.
    filename))

First we filter out the articles that should be indexed from a list of all files in the project. We pass this through the tw-get-all-file-tags function, which produces an association list, which is like a dictionary in Emacs Lisp. Each entry in the association list is a tag paired with a list of articles that have that tag. That list is sorted alphabetically on the tag name, and then it gets converted into an Org document that can be exported.

(Continue reading the full article on the web.)

First off, you might want to try it out. Nothing you paste into that web page leaves your browser, so you can safely try it with whatever you like. I have invited some testers to try out an earlier version of it, and they had mainly positive feedback to give.

We won’t break down robot-isms the way we broke down Claude-isms in the previous article, because in the UI of the new classifier you can just click any part of the text being classified to see which features activate on that portion of the text, and how they contribute to the overall judgement. Here’s an example of the expanded feature activation view.

(Continue reading the full article on the web.)

Walk the entire collection to locate flagged clusters. Skip it altogether when the cached, dirty-tracked flag count says there are none (the usual case): nothing needs marking, so the walk is pure waste. When the count is stale (e.g. right after an edit) or non-zero, we fall through to the real lookup, so stale marks never show. Same eventually-consistent signal the “Flags” badge relies on.

One thing in this comment caught my mind: the small parenthetical that says “the usual case”. If that were true, it would be important information! However, this comment is generated by the LLM model Claude, which has no sense of what counts as the usual case in this domain. But by generating that comment, it tricks every future reader (both human and robot) into believing in a property of the system that does not exist.

Since I knew, in this case, that the comment was generated by a robot and that the property it contained was hallucinated, I could fix the comment. But that’s not always so easy. Here’s another comment.

(Continue reading the full article on the web.)

I’m envious of what Lisp programmers do. Lisp development typically happens by typing code directly into the REPL to add, remove, and replace parts of the live, running system.

• A Lisp programmer does not need to “switch over” to something else because they are already inside their program process.
• They never “compile and execute” the code because the code is already running and they edit it by hot-swapping code.
• They never restart in a debugger because they are already inside their program process and can inspect anything they want.
• They don’t have to restart the program on exceptions, because the condition system allows resuming the crashing code from anywhere in the stack after the system has been patched with a fix.

A consequence of this way of working is that early in a Lisp project, there may not even be any source code to speak of. Instead, the evolving definition of the system exists only in the memory image of the running process and nowhere else. This is so unlike how we normally do development that people have expressed trouble understanding what that even means. A comparison that might help is to think of how people treat relational databases in the beginning of a project. Often, people don’t start out with a version-controlled schema definition; rather, the evolving schema exists only in the running database. Sure, at some point when the project matures, the database schema is dumped out to a file, put under version control, and from that point forward, schema changes are made through explicit migrations. Similarly, a Common Lisp project that matures will be dumped from memory image to source code eventually, and then that source code will go under version control, with patches applied more carefully to the live system.

(Continue reading the full article on the web.)

The theme is typically related to whatever the promoter wants to promote, but styled for children. I get the appeal – for children. They can probably imagine they’re really travelling along the path! In the variant pictured below, there’s forest and water and tunnels and dogs and everything!

But as a game, it sucks. For everyone. My children hate losing, and these games have n−1 losers for every n players. There are also literally zero decisions for the players to make, so I cannot make it through even a few turns without zoning out.

(Continue reading the full article on the web.)

The following is three seconds of a single 5 Hz sine wave, recorded at a sample rate of 100 Hz.

(Continue reading the full article on the web.)

Since last week, are in the process of simulating a digital circuit. The reason this is interesting is the solution in SICP uses hidden mutable state and message-passing to make the code object-oriented. It even uses a mutable global variable for scheduling! We managed to replicate all of that in Haskell, but now we want to refactor the solution to be easier to work with.

If we are going to manage the simulation in a pure functional manner, we still have to contend with the fact that during simulation, wires are objects with a fixed identity. A wire does not become a different wire just because its signal changes – the same wire is still hooked up to the same gates. Wires need to maintain their identity somehow.

In addition to the Signal type from before, we’ll define a Wire to be a string. This is its identity. We’ll also make a convenience function for creating a wire whose name is based on another wire name. This will be useful for creating unique wire names when we build circuits.

(Continue reading the full article on the web.)

In the previous two installations of this series, we looked at ways of implementing generic functions. In the first one, by tagging values and dispatching operations on tags. In the second case, by filling a mutable table of operation–tag pairs. We saw how these are roughly equivalent to the existing Haskell features of sum types and type classes.

Now we’ll simulate a digital circuit. The reason this is interesting is that the solution in SICP uses hidden mutable state and message-passing to make the code object-oriented. It even uses a mutable global variable for scheduling! I wasn’t sure if it would be possible to replicate that in Haskell, but as we’ll see, it can get incredibly close.

There are many ways to implement mutable state in Haskell, but to begin with, we’ll use the way that’s most similar to the SICP solution: IORefs. An IORef is a mutable variable, like in any other programming language.

(Continue reading the full article on the web.)

However, we couldn’t tell if this difference was large enough to be a useful guide for making decisions. It could just be an artifact of the small sample size.

(Continue reading the full article on the web.)

Since the curve does not start at the origin but a few percent up on the y axis, we can conclude that a few percent of the population have a score of zero. That doesn’t mean they are bad or miserable people – there may be factors that make zero the best score for them – but on average, a score of zero is worse than a higher score.

(Continue reading the full article on the web.)

• … earns you a high-risk pregnancy
• … earns you an ascent of Matterhorn
• … earns you 10,000 km on a motorcycle
• … earns you two BASE jumps
• … earns you a day on the frontline in Ukraine

These are all about equivalent to the risk of one year of smoking.

I’m skeptical of submitting asymptomatic people to medical tests. Almost any time I look into the evidentiary power of medical tests, I’m struck by how much work is performed by the base rate. The tests only work because we perform them on people who appear sick, i.e. have a higher probability of actually being sick in the first place. If we would perform them on seemingly-healthy people we would get nonsensical results.

(Continue reading the full article on the web.)

Complex numbers can be stored in their rectangular form, with a real and an imaginary part. They can also be stored in polar form, where there’s a magnitude and an angle. Whichever way a complex number is stored, we would like to be able to query it for all of these four quantities:

• The real coordinate in the rectangular form of the complex number.
• The imaginary coordinate in the rectangular form.
• The magnitude in the polar form.
• The angle in the polar form.

Last time we implemented these on top of a tagged value. To return one of the four coordinates above, a function would introspect the tag to figure out how to satisfy the caller for the representation involved. This works, but any time we want to add a new representation, we have to change all four existing operations.

(Continue reading the full article on the web.)

This article is written in Haskell throughout, but at the start it will look a lot like the Lisp code in SICP. I have intentionally tried to recreate the SICP solution as closely as possible, including dynamic typing and all. See the appendix if you’re curious how it works.

Complex numbers can be stored in their rectangular form, where there’s a real and an imaginary part. They can also be stored in polar form, where there’s a magnitude and an angle. The authors ask us to imagine that two people have been working on a library for mathematics, but ended up choosing different ways to store complex numbers. How can they write their code so that they don’t have to agree on one way to store the data?

Abelson and Sussman propose a tagged representation, where the data of the complex numbers are paired with a tag, which indicates to the implementation what representation is being used. They suggest the following functions to attach a tag, as well as inspect tagged data.

(Continue reading the full article on the web.)

This uses the same setup as the previous benchmark: each LLM gets a few attempts at playing the game, with each attempt being limited to a fixed budget of around $0.15. The LLM doesn’t know it, but the harness tracks achievements for each game, and counts how many the LLM earns in each attempt.

Here are the number of attempts for each game in this run.

(Continue reading the full article on the web.)

Backpressure is about signaling to upstream processes that they are running too fast and need to slow down. The suggestions presented by Costa are mostly about signaling to the upstream process that it needs to do things differently, rather than just slow down. This has more to do with ensuring sufficient quality is sent downstream, rather than quantity.

This irked me. As I was reading, I was searching for the right analogy. I kept coming back to lean manufacturing. The more famous half of the lean philosophy is waste reduction. The other half is about managing the unstable input of people. That’s what we’re interested in here.

A common approach to the input of people – especially in lower-skilled jobs – is to make line workers responsible for everything. We ask them to be hypervigilant, tell them to never make mistakes, and let them know that if they don’t always perform at their best, they will be chastised … or fired.

(Continue reading the full article on the web.)

The background to this discovery was that I needed to do some CRUD plumbing in a work project. It was a simple change that mostly mirrored existing functionality. This is a perfect fit for LLMs, in my experience, so I used a frontier model to generate the code for it. The change ended up being a total of just over 200 lines, mostly additions.

The part of the generated code we’ll talk about is a 24-line function that converts an arbitrary (user-supplied) string to a safe HTTP header value.

toHeaderValue :: Text -> Text
toHeaderValue raw =
  let
    attrChars = "!#$&+-.^_`|~"
    padHex t = if Text.length t < 2 then "0" <> t else t
    percentEncode c =
      if (isAscii c && isAlphaNum c) || elem c attrChars then
        Text.singleton c
      else
        Text.concat
          [ "%" <> padHex (Text.toUpper (Text.pack (showHex b "")))
          | b <- ByteString.unpack (encodeUtf8 (Text.singleton c))
          ]
    rfc5987Encode = Text.concatMap percentEncode
    isPrintable c = c >= ' ' && c /= '\DEL'
    replacePathSeparator c =
      if c == '/' || c == '\\' then
        '_'
      else
        c
    cleaned =
      Text.map replacePathSeparator (Text.filter isPrintable raw)
  in
    rfc5987Encode cleaned

(Continue reading the full article on the web.)

Winning the Monaco Grand Prix in Monte Carlo is determined nine out of ten times by which position one starts in.

That makes intuitive sense, because the Monte Carlo track is a narrow street track with few opportunities for overtakes. But … really? Is that an off-the-cuff remark or an accurate statistical prediction of the race?

If we take the statement as a statistical prediction, we have to clarify what it means, exactly. I’m going to assume it means that 90 % of the time, one of the cars starting in the first row (the first two positions) will win the race. Very little research is needed to prove that false. In the past 25 years, the Monaco race has been won by someone in the first row only 80 % of the time. The data do not support the hypothesis.

(Continue reading the full article on the web.)

One thing Gosset realised is that it is wrong to compute 90 % confidence intervals for the mean by taking the standard deviation of the sample, and assume a normal distribution, like-a-so:

\[\hat{\mu} \pm 1.645 \hat{\sigma}\]

When we do this we get too narrow a range, because while we recognise \(\hat{\mu}\) is just an approximation, we are assuming we know \(\sigma = \hat{\sigma}\) with certainty!

(Continue reading the full article on the web.)