kqr

Tangential to the tangent, but turbo codes/LDPC are algorithms for transmitting data over unreliable links with optimal redundancy for a target error rate. They underlie much of modern wireless data transfer, and were known to be possible since Shannon, but nobody had figured out how to actually do it in practise. When they were invented in the '90s everybody reacted with disbelief at first!

I'd argue it's actually better to do 25 % at once and then not doing anything like it for ... decades, ideally, but years, realistically.

Spreading it out means employees spend some of their time with an ear to the ground rather than working, and teams have to deal with multiple restructurings, neither of which are good for well-being nor productivity.

I would assume it's the harness sending the model a notification toward the end. At least Claude Code is designed to attach reminders with tool call output as a way for the harness itself to steer the model slightly.

Doesn't seem particularly robot-generated to me, nor to the classifier I made for a related purpose: https://xkqr.org/aicomment/#lang=none&prior=50&c=Pc_BbcMwEAT...

> So there’s little evidence McKinsey folks would actually be good at building and running businesses in most sectors.

Except there is! On average, McKinsey-lead businesses perform better: https://archive.is/HLA3s

The momentum, I think, matters a lot more than the other two. Makefiles already allowed you to build layered things with caching. Artifact repositories have also long been a thing.

But the argument I used for advocating Docker in environments where people were not fans of it was that the Linux container had become the de facto standard unit of deployment. There is so much tooling written under that assumption, and if you want to use any of that tooling, you need to package your deployments as Linux containers, even if you want nothing to do with Docker otherwise. That's why it had so much momentum.

Then a fourth point I think you're missing is that the concepts used by Docker are relatively simple. Before I understood what Linux containers were, I used to think things like, "Why would I care about Docker when I can isolate my processes with Linux users, cgroups, namespaces, etc." What I didn't know at that time is that "Linux users, cgroups, namespaces, etc." is exactly the thing Docker was giving a friendly UI to.

If you could tell ahead of time which components would be unreliable, that would be a great idea. For the most part, we only discover the component was unreliable after it's caused trouble. Removing the component at that time gets you at best a very short-lived improvement to the system because it'll happen again and again with other components.

If the component removed is a human, the situation is worse. Then you're creating an incentive to hide mistakes and assign blame to others. This makes it even harder to improve the system properly, because then the information you need to improve the system no longer gets to you undistorted.

That's why we have to design systems that don't assume components are perfectly reliable, and ensure any human components that we're not out to get them, we're out to create an environment where they will find it hard to make mistakes.

IIRC this is also somewhat verified empirically. I think it was in Steve McConnell's I saw a plot of fault injection rate as a function of change size based on real data (probably collected in the '80s, but still!), and the number of bugs per line of code were by far highest in the 1–5 line change range.

This is the sort of thing that's difficult to argue economically for studying with proper randomisation and everything, but an observational study can be made on open source repositories (even in projects where the main contributors are on a corporate payroll) fairly easily with LLMs these days. I wish I had more time to pursue things like this...

Not only that, it's also one of the very few instances in history where the film adaptation rivals the original work. But the book is great too; Palahniuk does amazing things with language.

Eh. I'd rather we set up a system where we don't have to rely on people being 100 % perfect for it to work. I'd be much more interested in what went on simultaneously that caused the meta data to get dropped, rather than who happened to be the one to do it this one time.

I have been going back and forth between Luxi Mono (serif monospace fonts are rare but look great on high-resolution monitors) and Hack (like Helvetica, it has virtually no personality and thus fits well everywhere). Everything else I've seen has looked... weird or off somehow. But this is one of the first alternatives I'm entertaining the idea of trying.

My main concern is that the tall glyphs for less than < and greater than > will disambiguate badly with actual Unicode left 〈 and right angle brackets 〉.

Edit: I also realised just now the ASCII hyphen-minus - is quite long with this typeface, which makes it ambiguous with the longer dashes. (It looks freakin' great in pure ASCII environments, though!)

How do you ditch Claude Code without paying for API tokens? (Assuming from the way you phrased it that you still use Claude, only you didn't want the system prompts that came with Claude Code.)

Last I looked into it, using other harnesses with a subscription was a TOS violation that Anthropic seemed to take quite seriously (with automatic rate limiting etc.)

That's a very neat observation. I've long argued that "for capacity planning, focus on the mean; for user experience, focus on the high percentiles."

But as the author says, under a heavy-tailed distribution (which service times typically have) the mean is dominated by the high percentiles!

One of the questions I always ask when a medical professional gives me advice is some variant of "What signs should we look for to know that my situation violates the assumptions you've made?" or "For how long would I need to be on this treatment until we can say it's not the right one for me?"

What I'm looking for is an exit rule, like the one speculative traders have to tell them when to withdraw from the market. A speculative trade is based on a bunch of assumptions about how the future will go. As soon as there's evidence those assumptions are not satisfied, the speculation goes invalid and the trade should be called off to avoid expensive losses.

Likewise, I want a way to back out of advice/treatment as soon as it's apparent it's not doing the thing it's supposed to do. But doctors hate getting that question, and often outright refuse to answer it. I get that it's a very difficult question and they would have to spend more time than they like to come up with a sensible answer. But I think that's only part of it.

Sometimes, it seems like the advice they give or the prescription they write is for just about anything that could plausibly be used as an active placebo. Then they hope the problem will resolve on its own, and I'll credit the doctor for it. A typical tell for when this happens is when they have two roughly equivalent alternative treatments they could prescribe[1], and they choose to start with the one that would take four months to evaluate, rather than the one that would show effects in three days.

[1]: That's another question I like to ask, and they hate to answer: "If this turns out to not work, what would be the next thing you'd want to try?" Maybe they have a good reason for refusing to answer it. Or maybe they don't have a plan in mind, but are improvising as they go.

Or none of the above is true, and what they really hate is the implication that they don't know what'll fix the condition, and are making a qualified guess. But they are!

I mean, if that'd ever be a thing, it would be in computing in the '90s! But I'm surprised that a 16 year old would have the grit to go through with it.

You can also link between Org documents and org-publish will export the documents with working web links, if you're lucky. That's how https://entropicthoughts.com works.

> the president's name will start with a letter in the first half of the alphabet

Sorry, this triggered my fact-checkitis. I opened Wikipedia's list of presidents of the US and ran this in the web developer console:

    Array.from(document.querySelectorAll(
        '#mwgA tr > :nth-child(3) span[data-sort-value]'
    ))
    .map(x => x.getAttribute('data-sort-value')[0])
    .reduce(({total, firstHalf}, c) => ({
        total: total+1, 
        firstHalf: c < 'N' ? firstHalf+1 : firstHalf
    }), {total: 0, firstHalf: 0});

and it responded

    Object { total: 47, firstHalf: 31 }

Then I used Agresti and Coull's method for a 95 % confidence interval around this (add two successes and two failures, compute Wald interval as usual). That gives us

    65 % ± 13 %

In other words, the 95 % confidence interval of the proportion lies in the span from 52 % to 78 %. That is significantly different from the null hypothesis.

I didn't expect it, but we might actually have reason to believe US presidents more often than not do have names starting with letters from the first half of the alphabet.

Edit: But I just realised English letter frequencies have 54 % of the probability mass in the first half of the alphabet, so that's probably a better null hypothesis than the even split. It's also compatible with the actual presidential statistics.

> when the shit hits the fan and you have customers you need to know what you're doing. [...] don't take on customers.

I think you overestimate the level of DBA skills smaller startups have in house.

If you have found a way for a company to hold off on taking on customers until they can afford a proper DBA, I'd love to hear more about it. But it sounds backwards to me. In my experience, it typically goes the other way around: only after taking on enough customers to be decently profitable can a company afford a real DBA.

Until then, the choice used to be between managed database services or striking luck with a developer that had some database interest. These days, it's between managed database services, striking luck, or giving the developers access to an LLM. The LLM doesn't replace DBA skills that used to be there. There weren't any DBA skills there to begin with.

Thanks. I'll try it out and see how well it works.

I would have argued against you a couple of years ago, because I've also built stuff this way and it required a developer or two to care at least a little bit about database administration, and few of the one's I've met do.

However, these days, I notice my DBA skills atrophying because LLMs have encoded most of the answers and diagnostics I need in their weights. Coupled with something like Nix, spinning up new servers including backups and everything, it's easier easier than ever to run your own production database instance.

> The game itself is the epitome of responding to a user's inputs precisely the way they would expect them to.

I have to admit my experience lies mostly in Brood War, and surely "the game responds intuitively to user inputs" is not one of the ways you'd describe it? That game is notoriously clunky in how it handles user input, both in terms of selection limitations, unit path finding, etc.

Don't get me wrong. I love Brood War. It's the only competitive video game scene I've really cared about. But I love it for its clunky user experience (which requires mechanical mastery in addition to a sound tactical mind), not because it's so smooth.

Your question seems sincere so I'll give it a sincere response.

The documentation and website are both obviously not written by a human.[1] This doesn't speak to me, in part because I'm the sort of person who thinks those are the interface and UX; but also because I reflexively end up thinking, "If they can't explain to me how it works, then why should I believe they even know how it works?"

I'm not saying you aren't intimate with every little detail, but writing the descriptions yourself is a costly signal and thus valuable for me as a potential user.

[1]: https://xkqr.org/aicomment/#lang=c&prior=50&c=PZIxjtwwDEX7Pc...

I have been looking for an ergonomic way to review generated code and format the comments as a prompt. I don't want to give the harness access to the real remote repository, and setting up a separate forge just for the review side seems excessive.

This, although vibe-coded, seems like good inspiration for a general concept that might work. Now if only I could take the time to make some Emacs commands that integrate this functionality with Magit and Ediff...

I recommend picking a random sample of commits to review more thoroughly by hand in parallel with the harness review.

That way, you get the opportunity to measure how many and what kind of issues your harness method misses, and with an estimation of their cost, you can make an informed decision about what magnitude speedup pays for the change in detection rate.

Can you direct me to such a frontier? Bonus points if it is cheap.

I want to use voice synthesis to read my blog articles out loud to me as a self-editing step, but the experience was nothing like a human when I last tried.

The voices sounded natural-ish alright, but intonation was all over the place.

I certainly grew up in the '90s, but for me it came from my parents. They were big on the idea that you had to find an active hobby you enjoy and then you get your exercise in that way. I never found one I could stick with so eventually I figured exercise just wasn't for me.

(These days I run and do bodyweight strength training a few days a week. I don't enjoy it and I certainly don't have time for it, but I sacrifice other things because it's good for me, both today and 30 years from now. (I picked these things specifically because (a) they give me the most results in the least investment in time and equipment, and (b) they get me to go outside even in not-so-great weather.))

I used to believe exercise was for people who were "into fitness". I have come to realise it's for everyone, at the level of their capacity.

Exercise should be thought of like brushing teeth and other forms of basic self-care. You don't do it because you're interested. You do it because you were born into a body that needs it.