It’s been three years since our previous counting of lines, so let’s check back in and see how OpenBSD is growing. Instead of just looking at the kernel, this time we’ll zoom out and look at the entire src tree.

. 20.54M lines 954.56M bytes
├──sys 9.70M lines 627.17M bytes
│  ├──dev 8.49M lines 593.52M bytes
│  │  ├──pci 7.14M lines 549.14M bytes
│  │  │  └──drm 6.58M lines 532.33M bytes
│  │  │     ├──amd 5.81M lines 509.00M bytes (7)
│  │  │     └──(other) 696.08k lines 21.03M bytes (7)
│  │  └──(other) 1.33M lines 43.74M bytes (36)
│  └──(other) 1.21M lines 33.66M bytes (22)
├──gnu 7.65M lines 238.82M bytes
│  ├──usr.bin 4.72M lines 140.19M bytes
│  │  ├──binutils 1.42M lines 42.64M bytes (12)
│  │  ├──binutils-2.17 1.14M lines 39.34M bytes (12)
│  │  ├──gcc 1.18M lines 35.25M bytes (3)
│  │  └──(other) 981.74k lines 22.96M bytes (5)
│  ├──llvm 1.52M lines 55.85M bytes (8)
│  ├──gcc 1.25M lines 37.88M bytes (11)
│  └──(other) 164.69k lines 4.89M bytes (3)
└──(other) 3.19M lines 88.57M bytes (12)

As some of the more knowing members of the audience may have predicted, the AMD GPU driver wins the prestigious Most Growth award, nearly doubling in size. It’s gone from being more than the half the kernel to more than half of the entire operating system. Quite the achievement! No other subdirectory even comes close.

AMD was up against some stiff competition in the past, including Team Toolchain featuring two copies of binutils, two copies of gcc (4.2 and 3.old), and llvm, but even their combined efforts now come in at only half an AMD.

There are some other programs and utilities included in OpenBSD as well, but at less than 10% of the codebase, they’re probably not worth further consideration. Too far out of competition.

I haven’t had much use for Windows for a while, but I like to keep abreast of whatever fuckery Redmond has in store for everyone else. I picked up a new laptop with the dreaded Copilot key, and thus had to figure out how to make it useful. And along the way, found a bunch of other settings to adjust. The plan is that I won’t need any of this knowledge until it becomes obsolete, but the only way to ensure that outcome is to write it all down; thus by being available it will never be necessary.

more...

I didn’t realize I needed this until I implemented it, and now, oh wow, can’t imagine life without it.

more...

Another month of poking around trying to make an almost useful terminal emulator.

more...

I wrote my own terminal and you won’t believe what happened next. I called it vertigo.

more...

The monaspace fonts introduced the idea of texture healing. I think of it as a sort of kerning for monospace fonts, though there’s probably some reason that’s technically incorrect. The basic idea is that some letters want more space, while others want less space, but this is hard to achieve in a monospace grid. And so they made a special font that includes alternative glyphs for letter pairs, so that i can donate some space to m.

more...

What’s next after you write your own text editor and mail client? How about a terminal? In fact, as a practice exercise or to learn some new skills, I’d say a terminal emulator makes for a much better target. It’s composed of many parts, but at an approachable level, making it easy to make tangible progress. In this way, I think it makes for a good introductory project. At the same time, there’s a very long tail of features that can be added to keep things interesting.

more...

There’s a feature called bracketed paste supported by some “modern” terminals and editors, etc. When text is pasted from the clipboard, the terminal brackets it in special markers so that the receiving program knows it came from the clipboard and not the keyboard, and thus might turn off autoindent, etc.

It’s also supported by some shells, and I’ve lost count of how many times I’ve seen people claim that this is a security measure. Yeah, sure, it’s totally safe to paste commands from a website into the shell, because bracketed paste will let you review them before executing.

Does it work? The brackets delimiting the pasted text are just bytes as well, in band. A website can put the end paste sequence into the clipboard as easily as any other text.

Here are two buttons for testing. One runs ls. The second tries a little harder.

<style>
button {
font-size: 1em;
min-width: 6em;
}
.script {
display: block;
white-space: pre-wrap;
font-family: monospace;
}
.script::before {
content: "<script>";
}
.script::after {
content: "</script>";
}
</style>
<script class=script>
function copy1() {
    navigator.clipboard.writeText("ls\n")
}
function copy2() {
    navigator.clipboard.writeText("\x1b[201~ls\n")
}
</script>
<p>
<button onclick="copy1()">ls</button>
<button onclick="copy2()">bonus</button>
<p>

In testing, xterm turns the escape into a space, and nothing happens but a little gibberish spray. Other terminals appear to be not so lucky.

There’s an amazing and famous scene of two hackers sharing a keyboard on NCIS, but it gets a lot of derision on the internet. What people don’t realize is that their mockery only reveals their own lack of skill. As everyone knows, a true hacker has mastered the art of dual wielding, and a keyboard that can be dual wielded by one might also be used by two hackers in tandem.

more...

I already had a pretty good idea where all the code in the OpenBSD kernel was hiding but for the sake of comparison I wanted precise numbers. This would be easy enough to get using some scripts and builtin tools like wc and du, but I wanted a tool that would give me something like this.

. 6.93M lines 383.41M bytes
├──dev 5.69M lines 348.84M bytes
│  ├──pci 4.46M lines 308.00M bytes
│  │  ├──drm 3.99M lines 293.86M bytes
│  │  │  ├──amd 3.33M lines 273.93M bytes (6)
│  │  │  ├──i915 326.03k lines 9.21M bytes (5)
│  │  │  ├──radeon 201.19k lines 6.71M bytes (1)
│  │  │  ├──include 48.94k lines 1.56M bytes (9)
│  │  │  ├──ttm 5.46k lines 142.03k bytes
│  │  │  └──scheduler 1.86k lines 51.73k bytes
│  │  └──bktr 8.53k lines 265.29k bytes
│  ├──usb 187.58k lines 5.09M bytes (1)
│  └──(other) 1.02M lines 35.11M bytes (33)
├──arch 729.42k lines 20.46M bytes
│  ├──amd64 133.43k lines 3.98M bytes (7)
│  └──(other) 595.99k lines 16.48M bytes (20)
├──kern 83.80k lines 2.05M bytes
├──uvm 29.39k lines 816.41k bytes
└──(other) 395.30k lines 11.23M bytes (19)

Easy to see everything, without too much clutter. Importantly, let me group things my way, and toss the less interesting parts off to the side. There’s 100 du but better tools on github, but it would take as long to find one that does exactly this as it did to just write one.

And thus watc.

Another take.