Please en­able JS and dis­able any ad blocker

The most pow­er­ful rocket in his­tory just roared off its launch pad in a spec­tac­u­lar show of power and tech­nol­ogy.

SpaceX launched the newest ver­sion of its gi­ant Starship rocket Friday (May 22), from a re­cently com­pleted sec­ond pad at its Starbase man­u­fac­tur­ing and test fa­cil­ity in South Texas. Liftoff oc­curred at 6:30 p.m. EDT (2230 GMT), send­ing the mas­sive 408-foot-tall (124-meter) ve­hi­cle sky­ward on its 12th sub­or­bital test flight.

It was the first Starship mis­sion since October 2025, and the first-ever flight of Starship Version 3 (V3), a next-gen­er­a­tion build of the rocket that fea­tures a com­plete de­sign over­haul meant to evolve the ve­hi­cle to­ward op­er­a­tional mis­sions. And to­day’s sub­or­bital Flight 12 was a sig­nif­i­cant step to­ward that am­bi­tious goal, even if it was a day later than planned af­ter a glitched thwarted a first launch try on Thursday.

“Congratulations SpaceX team on an epic first Starship V3 launch & land­ing!,” SpaceX CEO Elon Musk wrote on X af­ter the launch. “You scored a goal for hu­man­ity.”

Image

1

of

3

There were some hic­cups.

During liftoff, one of the 33 first-stage Raptor en­gines on Super Heavy shut down, and the booster missed a crit­i­cal “boost back” manuever to con­trol its re­turn to Earth. Starship’s Ship 39 up­per stage also lost one of its six main en­gines dur­ing as­cent, but man­aged to reach space on the re­main­ing five.

“I would­n’t call it nom­i­nal or­bital in­ser­tion, but we’re in on a tra­jec­tory that we had an­a­lyzed, and it’s within bounds,” SpaceX spokesper­son Dan Huot said in live com­men­tary. “So, teams con­tin­u­ing to work through it with that en­gine out there, work­ing some through some steps on the en­gines.”

Starship con­sists of a first-stage booster called Super Heavy and an up­per stage known as Starship, or sim­ply Ship. The first no­table event af­ter the rocket cleared the tower this evening oc­curred about 2 min­utes and 20 sec­onds into flight, when Super Heavy ini­ti­ated “hot stag­ing” and sep­a­ra­tion from Ship. (It’s known as hot stag­ing be­cause Ship be­gins fir­ing its en­gines be­fore sep­a­rat­ing from Super Heavy.)

Unlike its V2 pre­de­ces­sor, which fea­tured an in­ter­stage ring that fell away at sep­a­ra­tion, Starship V3 is built with sim­i­lar hard­ware se­cured to the top of the booster, like a fence around the fuel tank’s dome to give some breath­ing room to the up­per stage en­gi­nes’ ig­ni­tion and ini­tial thrust away from the booster.

After stage sep­a­ra­tion, Super Heavy re­ori­ented and at­tempted to per­form a one-minute boost­back burn to­ward Starbase. However, some­thing went wrong and the burn did­n’t go as planned, Huot said.

SpaceX has per­formed booster re­cov­er­ies at Starbase on pre­vi­ous Starship mis­sions, catch­ing the rock­et’s first stage us­ing me­chan­i­cal “chopstick” arms at­tached to the site’s launch tow­ers. On Flight 12, how­ever, the com­pany planed to re­turn Super Heavy a soft splash­down in the Gulf of Mexico rather than risk a re­cov­ery mishap that could dam­age the pad on the first flight of brand-new hard­ware.

Instead, the mas­sive Super Heavy booster plum­meted back to Earth and crashed into the Gulf, beam­ing live views of its fall from space un­til the screen went black.

“The booster did­n’t com­plete its full boost back,” Huot said just af­ter li­fotff. “Its mis­sion ended a lit­tle bit early, but landed in the clear area that we had set in ad­vance.”

SpaceX in­cluded 22 pay­loads for Ship to de­ploy dur­ing its sub­or­bital jaunt to­day — 20 dummy ver­sions of the com­pa­ny’s Starlink broad­band satel­lites and two ac­tual Starlink space­craft equipped with imag­ing sen­sors.

The pay­loads were de­ployed as planned over a 10-minute span, be­gin­ning roughly 17 min­utes af­ter launch, via Ship’s “PEZ dis­penser”-like door. The two mod­i­fied Starlink satel­lites were tasked with scan­ning Starship’s heat shield tiles, in a test meant to as­sess the abil­ity to in­spect them for pos­si­ble dam­age prior to reen­try.

Shortly af­ter the fi­nal two Starlink sim­u­la­tors de­ployed (the ones with cam­eras that SpaceX nick­named “Dodger Dogs” af­ter the famed hot­dogs at Dodger Stadium), SpaceX broad­cast the spec­tac­tu­lar video they cap­tured as they flew away from Starship.

“That is a Starship in space,” Huot said.

Image

1

of

2

SpaceX ini­tially planned for the Ship 39 up­per stage to per­form an in-space re­light of one of its six Raptor en­gines in or­bit— an im­por­tant demon­stra­tion to prove the space­craft can re­li­ably ex­e­cute ma­neu­vers, as mix­ing and man­ag­ing cryo­genic fu­els and reignit­ing an en­gine in zero-g is nec­es­sary to al­ter Ship’s or­bit, send it on to the moon or Mars, and bring it back to Earth for re­cov­ery and reuse. But be­cause of the lost Raptor en­gine dur­ing launch, flight con­trollers skipped that test for Flight 12.

And so, the first Starship V3 space­craft be­gan its de­scent to Earth.

Ship be­gan its reen­try to Earth’s at­mos­phere about 50 min­utes into the flight, falling as its belly be­came en­gulfed in a bright plasma. During its de­scent, Ship 39 per­formed a se­ries of ex­er­cises de­signed to stress parts of the ve­hi­cle to their struc­tural limit. It also ex­e­cuted a novel bank­ing ma­neu­ver for its land­ing burn meant to mimic the tra­jec­tory and ori­en­ta­tion needed for a launch tower catch on a re­turn to Starbase.

Huge cheers rang out at SpaceX’s head­quareters and Starbase fa­cil­i­ties as the Ship 39 ig­nited two en­gines for a fi­nal land­ing burn. The manuever ini­tially called for three en­gines, but that one shut down early at liftoff. After the land­ing, Starship top­pled over into the ocean wa­ters and ex­ploded in a mag­nif­i­cent fire­ball (again, as planned) as SpaceX work­ers cheered.

Nothing Starship ac­com­plished on Flight 12 was par­tic­u­larly ground­break­ing for SpaceX; the mis­sion goals and tra­jec­to­ries were broadly sim­i­lar to those of the pre­vi­ous few test mis­sions.

However, even suc­cess­fully fol­low­ing a pre­vi­ously blazed trail was huge for Starship V3, given that it’s a brand-new ve­hi­cle with a va­ri­ety of mod­i­fi­ca­tions and up­grades over its pre­de­ces­sors. And V3′s road to the launch pad was a bit rocky.

SpaceX ran into some is­sues dur­ing the test­ing of the new V3 build in November last year, re­sult­ing in the loss of the Super Heavy booster orig­i­nally slated for the Flight 12 mis­sion. Now, with more than half a year be­tween Starship’s last two launches, SpaceX has some catch­ing up to do.

NASA is re­ly­ing on Starship as one of the crewed lu­nar lan­ders for its Artemis pro­gram, which aims to even­tu­ally es­tab­lish a per­ma­nent hu­man pres­ence on the moon. The space agency has also con­tracted Blue Moon, a Blue Origin space­craft, to land Artemis as­tro­nauts on the moon, and has in­di­cated a will­ing­ness to fly with whichever pri­vate lan­der is ready when it’s time for the mis­sions to get off the ground.

The next of those mis­sions is Artemis 3 — the fol­low-up to April’s Artemis 2, which flew four as­tro­nauts aboard NASA’s Orion space­craft on a suc­cess­ful 10-day mis­sion around the moon. NASA is tar­get­ing mid to late 2027 for Artemis 3, which will launch Orion to low Earth or­bit (LEO) to ren­dezvous and dock with one or both of the pri­vate lu­nar lan­ders, and late 2028 for the first lu­nar land­ing on Artemis 4.

As if to drive that fact home, NASA chief Jared Isaacman flew to Starbase to watch the launch per­son­ally.

“We’re look­ing for­ward to see­ing this thing fly, be­cause hope­fully at some point in the not too dis­tant fu­ture we’re gonna, we’re gonna join up in an earth or­bit,” Isaacman said dur­ing the live co­men­tary.

After the launch, Isaacman hailed the work of SpaceX’s Starship team.

“Congrats SpaceX team and Elon Musk on a hell of a V3 Starship launch,” Isaacman wrote on X. “One step closer to the Moon … one step closer to Mars.”

Congrats @SpaceX team and @elonmusk on a hell of a V3 Starship launch. One step closer to the Moon…one step closer to Mars 🇺🇸 pic.twit­ter.com/​jjetQxnkiR­May 23, 2026

Congrats @SpaceX team and @elonmusk on a hell of a V3 Starship launch. One step closer to the Moon…one step closer to Mars 🇺🇸 pic.twit­ter.com/​jjetQxnkiR­May 23, 2026

Starship has a num­ber of boxes to check be­fore NASA cer­ti­fies the ve­hi­cle to fly as­tro­nauts, but V3 has been built with those goal­posts in mind.

The new Starship V3 ve­hi­cle in­cludes four pas­sive con­nec­tion ports on its back, or lee­ward, side (opposite the heat tiles on its belly), which are de­signed for dock­ing and ship-to-ship fuel trans­fers.

In or­der to fly be­yond LEO, Starship re­quires the as­sis­tance of ad­di­tional Ships to meet up in or­bit to top off its fuel tanks. This is es­pe­cially im­por­tant for its use as the Artemis moon lan­der; ex­perts have es­ti­mated that each lu­nar Starship mis­sion could re­quire a dozen or more re­fu­el­ing launches to ad­e­quately sup­ply enough pro­pel­lant to get to the moon, land and launch back to lu­nar or­bit.

Ship has yet to demon­strate in-space re­fu­el­ing, or even a launch that fully reaches Earth or­bit. And there are other boxes it needs to tick as well.

For ex­am­ple, NASA is re­quir­ing both Starship and Blue Moon to demon­strate un­crewed lu­nar land­ings be­fore they fly as­tro­nauts down to the lu­nar sur­face, putting SpaceX and Blue Origin on a short time­line to ready ve­hi­cles for the planned Artemis 4 land­ing in 2028.

Starship’s launch to­day helps put it back on track to­ward meet­ing that goal, but SpaceX will have to pick up its launch ca­dence sig­nif­i­cantly. Just over a year ago, in March 2025, SpaceX founder and CEO Elon Musk posted on X that he ex­pected to be launch­ing V3 at a “rate of once a week in [about] 12 months.”

While that ca­dence still seems a long way off at Starship’s cur­rent state of de­vel­op­ment, the suc­cess of Flight 12 bodes well for the near fu­ture. And hope­fully the near fu­ture fea­tures an­other Starship launch — a gi­ant rocket get­ting off the ground in a mat­ter of weeks, ver­sus the seven months that sep­a­rated to­day’s mis­sion from the pre­vi­ous test flight.

Josh Dinner is Space.com’s Spaceflight Staff Writer. He is a writer and pho­tog­ra­pher with a pas­sion for sci­ence and space ex­plo­ration, and has been work­ing the space beat since 2016. Josh has cov­ered the evo­lu­tion of NASA’s com­mer­cial space­flight part­ner­ships and crewed mis­sions from the Space Coast, NASA sci­ence mis­sions and more. He also en­joys build­ing 1:144-scale model rock­ets and space­craft. Find some of Josh’s launch pho­tog­ra­phy on Instagram, and fol­low him on X, where he mostly posts in haiku.

Introduction

The <dl>, or de­scrip­tion list, el­e­ment is un­der­rated.

It’s used to rep­re­sent a list of name–value pairs. This is a com­mon UI pat­tern that, at the same time, is in­cred­i­bly ver­sa­tile. For in­stance, you’ve prob­a­bly seen these lay­outs out in the wild…

Each of these ex­am­ples shows a list (or lists!) of name–value pairs. You might have also seen lists of name–value pairs to de­scribe lodg­ing ameni­ties, or to list out in­di­vid­ual charges in your monthly rent, or in glos­saries of tech­ni­cal terms. Each of these is a can­di­date to be rep­re­sented with the <dl> el­e­ment.

So what does that look like?

The Anatomy of a Description List

I’ve been say­ing “<dl>,” when re­ally, I’m talk­ing about three sep­a­rate el­e­ments: <dl>, <dt>, and <dd>.

We start with our <dl>. This is the de­scrip­tion list,note 1 akin to us­ing a <ul> for an un­ordered list or an <ol> for an or­dered list.

<dl>

</dl>

Fancy.

Next up, we want to add a name–value pair. We’ll use a <dt>, short for de­scrip­tion term, for the name, and we’ll use a <dd>, short for de­scrip­tion de­tail, for the value.note 2

<dl> <dt>Title</dt> <dd>Designing with Web Standards</dd> </dl>

To add an­other name–value pair to our list, we add an­other <dt> and <dd>:

<dl> <dt>Title</dt> <dd>Designing with Web Standards</dd> <dt>Publisher</dt> <dd>New Riders Pub; 3rd edi­tion (October 19, 2009)</dd> </dl>

But wait — what if I have a term that has mul­ti­ple val­ues? For in­stance, what if this book has mul­ti­ple au­thors?

That’s fine! One <dt> can have mul­ti­ple <dd>s:

<dl> <dt>Title</dt> <dd>Designing with Web Standards</dd> <dt>Author</dt> <dd>Jeffrey Zeldman</dd> <dd>Ethan Marcotte</dd> <dt>Publisher</dt> <dd>New Riders Pub; 3rd edi­tion (October 19, 2009)</dd> </dl>

There’s one last piece of the de­scrip­tion list anatomy to look at for most ba­sic use cases: what if I want to wrap a <dt> and its <dd>(s) for styling rea­sons?

In this case, the specs al­low you to wrap a <dt> and its <dd>(s) in a <div>:

<dl>

<div> <dt>Title</dt> <dd>Designing with Web Standards</dd> </div>

<div> <dt>Author</dt> <dd>Jeffrey Zeldman</dd> <dd>Ethan Marcotte</dd> </div>

<div> <dt>Publisher</dt> <dd>New Riders Pub; 3rd edi­tion (October 19, 2009)</dd> </div>

</dl>

A wrap­per <div> like this is the only el­e­ment that can wrap those <dt>/<dd> groups.

And that’s it! That’s the anatomy of the de­scrip­tion list, HTML’s se­man­tic way to mark up a list of name–value groups!

Why Do We Need Semantics For This Anyways?

Before we learned about the <dl>, <dt>, and <dd> el­e­ments, my team used to use nested <div>s for this pat­tern all the time. It looked a lot like:

<div class=“book-de­tails”> <div class=“book-de­tails–item”> <div class=“book-de­tails–la­bel”> Title </div> <div class=“book-de­tails–value”> Designing with Web Standards </div> </div> <div class=“book-de­tails–item”> <div class=“book-de­tails–la­bel”> Author </div> <div class=“book-de­tails–value”> Jeffrey Zeldman </div> <div class=“book-de­tails–value”> Ethan Marcotte </div> </div> <div class=“book-de­tails–item”> <div class=“book-de­tails–la­bel”> Publisher </div> <div class=“book-de­tails–value”> New Riders Pub; 3rd edi­tion (October 19, 2009) </div> </div> </div>

This has all the in­for­ma­tion about the book, right? Why do we need se­man­tics for a list of name–value groups in the first place if some­thing like a se­ries of nested <div>s could get the job done?

When de­ter­min­ing whether a se­man­tic el­e­ment might be ap­pro­pri­ate for a given pat­tern, I find it help­ful to ask, “What ben­e­fits — even the­o­ret­i­cal — could we get if com­put­ers could rec­og­nize this pat­tern?” In this case, what lift could we get if browsers could some­how rec­og­nize a list of name–value groups?

Answers to that ques­tion will be var­ied. I tend to spend a lot of time ad­vo­cat­ing for web ac­ces­si­bil­ity, so my first thought tends to be how screen­read­ers could in­ter­pret the pat­tern. Off the top of my head, I can think of a cou­ple of ben­e­fits screen­reader users could get from their screen­read­ers rec­og­niz­ing this pat­tern:

The screen­reader could tell the user how many name–value groups are in the list.

The screen­reader could tell the user how far into the list they are.

The screen­reader could treat the list as one block that the user could skip over if they’re un­in­ter­ested in it.

All of these could make the list more us­able than a se­ries of nested <div>s, which would treat each name and value in the list as noth­ing more than a stand­alone text node.

If you can come up with a cou­ple of even the­o­ret­i­cal lifts from the user’s de­vice rec­og­niz­ing a pat­tern, then there’s a good chance that the pat­tern is a strong can­di­date for hav­ing some as­so­ci­ated se­man­tics.

For what it’s worth, these screen­reader ex­pe­ri­ences aren’t hy­po­thet­i­cal — they’re ben­e­fits that screen­reader users re­ally get from us­ing <dl> in most browser/​screen­reader com­bi­na­tions. Admittedly, how­ever, sup­port for the <dl> el­e­ment is not yet uni­ver­sal. You may de­cide that screen­read­ers’ fall­back ex­pe­ri­ence — treat­ing the list as stand­alone text nodes — is­n’t suf­fi­cient for your use case, and in­stead opt for some­thing like a <ul> un­til sup­port im­proves.

Okay, Okay, One Last Example!

My fa­vorite ex­am­ple, the one that re­ally takes the cake for me, is Dungeons & Dragons stat­blocks, which are re­ally “Oops! All Name–Value Pairs!”

No, re­ally: just how many can­di­dates for <dl>s do you see in this stat­block alone?

I counted five pos­si­ble de­scrip­tion lists, per­son­ally. Here’s how I chose to mark this up:

<div> <h1>Kobold</h1> <small>Small hu­manoid (kobold), law­ful evil</​small>

<dl> <div> <dt>Armor Class</dt> <dd>12</dd> </div> <div> <dt>Hit Points</dt> <dd>5 (2d6 – 2)</dd> </div> <div> <dt>Speed</dt> <dd>30 ft.</​dd> </div> </dl>

<dl aria-la­bel=“Abil­ity Scores”> <div> <dt>STR</dt> <dd>7 (-2)</dd> </div> <div> <dt>DEX</dt> <dd>15 (+2)</dd> </div> <div> <dt>CON</dt> <dd>9 (-1)</dd> </div> <div> <dt>INT</dt> <dd>8 (-1)</dd> </div> <div> <dt>WIS</dt> <dd>7 (-2)</dd> </div> <div> <dt>CHA</dt> <dd>8 (–1)</dd> </div> </dl>

<dl aria-la­bel=“Pro­fi­cien­cies”> <div> <dt>Senses</dt> <dd>Darkvision 60 ft.</​dd> <dd>Passive Perception 8</dd> </div> <div> <dt>Languages</dt> <dd>Common</dd> <dd>Draconic</dd> </div> <div> <dt>Challenge</dt> <dd>1/8 (25 XP)</dd> </div> </dl>

<dl aria-la­bel=“Traits”> <div> <dt>Sunlight Sensitivity</dt> <dd> While in sun­light, the kobold has dis­ad­van­tage on at­tack rolls, as well as on Wisdom (Perception) checks that rely on sight. </dd> </div> <div> <dt>Pack Tactics</dt> <dd> The kobold has ad­van­tage on an at­tack roll against a crea­ture if at least one of the kobold’s al­lies is within 5 ft. of the crea­ture and the ally is­n’t in­ca­pac­i­tated. </dd> </div> </dl>

<h2 id=“ac­tions”>Ac­tions</​h2> <dl aria-la­belledby=“ac­tions”> <div> <dt>Dagger</dt> <dd> <i>Melee Weapon Attack:</i> +4 to hit, reach 5 ft., one tar­get. <i>Hit:</i> (1d4 + 2) pierc­ing dam­age. </dd> </div> <div> <dt>Sling</dt> <dd> <i>Ranged Weapon Attack:</i> +4 to hit, reach 30/120 ft., one tar­get. <i>Hit</i>: (1d4 + 2) blud­geon­ing dam­age. </dd> </div> </dl>

</div>

This is just one way you could have opted to mark up that stat­block.

I love this as a demon­stra­tion be­cause it re­ally goes to show just how ver­sa­tile the de­scrip­tion list pat­tern can re­ally be — the lists of abil­ity scores (STR, DEX, and so forth) and at­tacks both look very dif­fer­ent, and yet, the de­scrip­tion list pat­tern can span them all.

Takeaways

Lists of name–value pairs (or, in some cases, name–value groups) are a com­mon pat­tern across the web, in part due to their ver­sa­til­ity. HTML lets us mark up these lists with a com­bi­na­tion of three el­e­ments:

The <dl>, or de­scrip­tion list, el­e­ment, which wraps the en­tire list of name–value pairs

The <dt>, or de­scrip­tion term, el­e­ment, which rep­re­sents a name in our name–value pairs

The <dd>, or de­scrip­tion de­tail, el­e­ment, which rep­re­sents a value in our name–value pairs

Ascribing se­man­tics to pat­terns such as these gives our users’ de­vices the in­for­ma­tion they need to cu­rate use­ful, us­able ex­pe­ri­ences — of­ten­times in ways that we as de­vel­op­ers may not ex­pect.

To learn more about de­scrip­tion lists and what’s al­lowed or not al­lowed, I rec­om­mend the MDN docs on the <dl>, or go­ing di­rectly to the specs!

Footnotes

Prior to HTML5, this was called a de­f­i­n­i­tion list. This is be­cause the <dl> was orig­i­nally only in­tended to rep­re­sent glos­saries of terms and their de­f­i­n­i­tions. | Back to [1]

Prior to HTML5, this was called a de­f­i­n­i­tion list. This is be­cause the <dl> was orig­i­nally only in­tended to rep­re­sent glos­saries of terms and their de­f­i­n­i­tions. | Back to [1]

Previously known as the de­f­i­n­i­tion term and de­f­i­n­i­tion de­tail el­e­ments re­spec­tively. | Back to [2]

Previously known as the de­f­i­n­i­tion term and de­f­i­n­i­tion de­tail el­e­ments re­spec­tively. | Back to [2]

I have an at­ten­tion prob­lem.

A cou­ple of weeks ago, I de­cided to con­vert my old lap­top into a wri­ter­deck, a ded­i­cated writ­ing de­vice free from the dis­trac­tions of the mod­ern in­ter­net.

Lots of folks build re­ally elab­o­rate of­fline de­vices for this, and I’d love to do that… some­day. Right now I have no short­age of pro­jects and the point is to get writ­ing, so I used what I had: a six-year-old lap­top which still runs great, has plenty of power, but is­n’t get­ting much use any­more.

Crucially, this lap­top has an ex­cel­lent key­board, and a matte screen, which makes it awe­some to type on for long stretches, and func­tional enough in the day­light (I like to sit out­side with my dog and write). It’s also a System76 Galago Pro (not spon­sored), which means it’s al­ready Linux friendly and has great sup­port in the ker­nel.

Setting up a tty in­stead of a desk­top

Now, you could cer­tainly just use a reg­u­lar desk­top OS and keep it of­fline, al­though that’s eas­ier said than done. I don’t think you can fully re­move the browsers from a mod­ern Mac or Windows PC. At least not in a sup­ported way.

Of course, I’m a Linux user, and I have any num­ber of op­tions. I could have gone with a sim­ple desk­top or win­dow man­ager and just not in­stalled a browser, but I wanted some­thing that re­ally broke the desk­top OS mus­cle mem­ory and forced me into think­ing about my words with in­ten­tion.

I opted for a tty-based setup, us­ing Debian (Trixie at the time of writ­ing). Console only- no x11 or Wayland, no desk­top get­ting in my way.

Installing Debian is easy enough. I use the text-based in­staller mode, and for this wri­ter­deck, I opted to skip full-disk en­cryp­tion (there’s noth­ing on this de­vice that is­n’t go­ing to be pub­lic any­way).

Folks al­ways tell me they get hung up on things be­cause they don’t set them­selves up with sudo on Debian. If you’re com­ing from Mint or Ubuntu or vir­tu­ally any other desk­top-ori­ented dis­tro, this could trip you up. If you want to use sudo for ad­min tasks, skip adding a root pass­word. That’ll dis­able root and set you up as a sudo user.

On the desk­top setup screen, I chose to re­move all desk­top fea­tures, be­cause again, I want this thing to be a min­i­mal de­vice. Just me and the words, no GUI get­ting in my way.

When things wrap up, you’ll be greeted with a bland con­sole lo­gin. Perfect place to get started.

Installing net­work-man­ager

After sign­ing in for the first time and mak­ing sure I was up-to-date with a quick sudo apt up­date and a sudo apt up­grade, I chose to re­place the reg­u­lar net­work stack with the net­work-man­ager pack­age. Mainly to get ac­cess to the very good curses tool nm-tui for con­nect­ing to net­works.

nm-tui is a thou­sand times eas­ier than edit­ing con­fig files for set­ting up net­work de­vices. And while I will be work­ing mostly of­fline with this de­vice when I’m away from home, I do ap­pre­ci­ate the abil­ity to con­nect it to the net­work to back up files should the need arise.

After in­stalling net­work-man­ager with sudo apt in­stall net­work-man­ager, you can use nm-tui to scan for avail­able Wi-Fi net­works and get hooked up. Depending on your hard­ware, you might also have WAN ac­cess here. Pretty cool.

Installing neovim and km­scon

I could­n’t wait any longer, I in­stalled neovim as soon as I could with sudo apt in­stall neovim. I did­n’t want to edit with nano. Nothing per­sonal, I’m just a vim user all the way now.

Normally I use tra­di­tional vim but I opted for neovim as I’m try­ing to get to know it a bit more.

Then, I in­stalled km­scon, which for Debian Trixie needed to be added from back­ports.

First, I up­dated my Debian source list by edit­ing the file at /etc/apt/sources.list to add the fol­low­ing two lines:

deb http://​deb.de­bian.org/​de­bian/ trixie-back­ports main con­trib non-free non-free-firmware deb-src http://​deb.de­bian.org/​de­bian/ trixie-back­ports main con­trib non-free non-free-firmware

A quick sudo apt up­date and then I can sim­ply run sudo apt in­stall -t trixie-back­ports km­scon. This will in­stall the km­scon pack­age from back­ports, as well as its de­pen­den­cies, and set it to au­to­mat­i­cally start on boot. Next re­boot, you’ll see the fa­mil­iar tty, but now it’s scal­able with ctrl-plus and ctrl-mi­nus, like most mod­ern web browsers.

From here, I have a to­tally func­tional wri­ter­deck. I could be done here and be rea­son­ably sat­is­fied with an of­fline, pleas­ant writ­ing ex­pe­ri­ence. But I wanted a few more nic­i­ties which I’ve grown ac­cus­tomed to.

tmux for mul­ti­plex­ing and a pretty sta­tus bar

Next, I in­stalled tmux for ba­sic ter­mi­nal tiling and a pretty sta­tus bar. This is pack­aged for Debian (and vir­tu­ally every­one else), and is in­stalled with sudo apt in­stall tmux.

I also in­stalled acpi for bat­tery de­tails, and light to con­trol the screen back­light. You can in­stall these at the same time with sudo apt in­stall acpi light. I set these up in my .tmux.conf file, which is kept in your home di­rec­tory. Here’s how I used them.

ACPI for bat­tery read­outs

Once the acpi pack­age is in­stalled, you should be able to see your bat­tery with acpi -b (assuming your lap­top has a bat­tery which is de­tected with acpi, which has worked so far on every lap­top I’ve tried in my house).

So, to get the spe­cific per­cent­age and noth­ing more, you can pipe acpi -b into grep like so:

acpi -b | grep -m1 -o -P ‘.{0,2}%’

This grep is a bit hard to un­der­stand, so let’s break it down:

-m1 says stop read­ing the file af­ter one line. I did this be­cause some lap­tops I’ve used have mul­ti­ple bat­ter­ies, and I only care about the pri­mary bat­tery. You can prob­a­bly leave this out if acpi -b only re­turns a sin­gle line.

-o prints only the matched parts of the line. I don’t want a large print­out with the re­main­ing time. You might!

-P in­ter­prets the pat­tern as a Perl-compatible reg­u­lar ex­pres­sion. Then ‘.{0,2}%’ gets us the per­cent sign and the two num­bers pre­ced­ing the per­cent. (This won’t show “100%” but I can live with that, be­cause this lap­top does­n’t get there any­more.)

I wanted to re­place the de­fault de­tails in the tmux sta­tus bar with a bat­tery read­out, so I do so with the fol­low­ing in my .tmux.conf:

# give me a bat­tery read­out in­stead of the time set-win­dow-op­tion -g sta­tus-right “#(acpi -b | grep -m1 -o -P ‘.{0,2}%’)”

Light for bright­ness

Next, we can use the very sim­ple light com­mand we in­stalled ear­lier to con­trol the bright­ness. On my lap­top, F8 and F9 have bright­ness in­di­ca­tors printed on the keys, so it’s a per­fect fit.

light -U 10 de­creases the bright­ness by ten per­cent, and light -A 10 in­creases it.

So, to bind F8 and F9 to de­crease/​in­crease bright­ness con­trol, I sim­ply add this to my .tmux.conf:

# key­bind­ing for bright­ness bind -n F8 run-shell ‘light -U 10’ # de­crease bind -n F9 run-shell ‘light -A 10’ # in­crease

Now, next time I start tmux, I’ll have bright­ness con­trols. Very neat!

Additional tmux cus­tomiza­tion

Lastly, I like the sta­tus line for tmux at the top of the screen, be­cause neovim puts a sta­tus line at the bot­tom of the screen. That’s achieved by adding set -g sta­tus-po­si­tion top to the .tmux.conf file.

Also, I have a habit of spec­i­fy­ing the color. I think it’s green by de­fault but I set it any­way (I might change it in the fu­ture, who knows) with set -g sta­tus-style bg=green.

So, my fi­nal tmux.conf looks like this:

# bar po­si­tion and color set -g sta­tus-po­si­tion top set -g sta­tus-style bg=green

# key­bind­ing for bright­ness bind -n F8 run-shell ‘light -U 10’ # de­crease bind -n F9 run-shell ‘light -A 10’ # in­crease

# give me a bat­tery read­out in­stead of the time set-win­dow-op­tion -g sta­tus-right “#(acpi -b | grep -m1 -o -P ‘.{0,2}%’)”

This is­n’t a tmux les­son, but by de­fault, to do a split, you use Ctrl-B to break out of reg­u­lar mode and into the tmux com­mand mode, and then the % key to split ver­ti­cally, or ” to split hor­i­zon­tally. Ctrl-B, then an ar­row will move your fo­cus be­tween panes.

Someday, I’ll do a for­mal tmux les­son. Moving on!

neovim and vimwiki

I know a lot of folks won’t want to use neovim or vim, opt­ing in­stead for emacs or he­lix or mi­cro or nano or blammo or some­thing else I did­n’t men­tion (but some­one’s about to).

That’s great. I’m happy for you. I’m a vim user though, so that’s what I set up.

neovim in­cludes some rea­son­ably great col­orschemes which you can try out with the :colorscheme op­tion. I chose blue, which fit my retro vibe just fine, but you could pick any­thing you want or even write one your­self from scratch.

I added that to my .config/nvim/init.vim file with col­orscheme blue, and I also added set line­break so that way words would wrap to the next line (I don’t nor­mally do this on my desk­top but this thing’s one job is writ­ing).

Lastly, I set up vimwiki, which I al­ready cov­ered in a sep­a­rate %blog post%. The only thing that’s changed is in­stead of in­stalling vimwiki with a plu­gin, on Trixie it’s pack­aged, so you can in­stall it with sudo apt in­stall vim-vimwiki.

Installing Syncthing

I set up sync­thing ac­cord­ing to the Syncthing docs, which are pretty good and I won’t re­peat those too much here.

I set up sync­thing to con­nect my wri­ter­deck’s vimwiki folder to my server’s writ­ing folder, which is a sub­di­rec­tory in­side an­other, more pri­vate vimwiki setup. I do it this way so that if there’s sen­si­tive notes in my desk­top vimwiki, they don’t sync to the wri­ter­deck. If I had en­cryp­tion on this de­vice, I would­n’t mind that though, and I might set up pass­word-based LUKS en­cryp­tion just to gain ac­cess to my vimwiki di­ary on the wri­ter­deck.

The one place where I strayed from a stock sync­thing setup is that be­cause I don’t have a desk­top with a tra­di­tional browser, I had to set my sync­thing web GUI to be lis­ten­ing on all ad­dresses in­stead of just 127.0.0.1. I don’t love this ap­proach, but again, this thing has noth­ing pri­vate on it. A bet­ter way would be to set up a SOCKS proxy and con­nect that way, but that’s a topic for a fu­ture post.

Setting it up to au­tolo­gin

The last thing I did to make this wri­ter­deck my own was to set up au­to­matic lo­gin.

I want to be able to open this up and start writ­ing quickly- au­tolo­gin is a sim­ple way to get there.

Autologin with km­scon

Because I in­stalled km­scon, this is pretty easy, just up­date the (gasp) sys­temd ser­vice with sudo sys­tem­ctl edit km­sconvt@tty1.ser­vice.

Then, I just added the fol­low­ing:

[Service] ExecStart= ExecStart=/usr/bin/kmscon –login — /bin/login -f my_user­name_­goes_here

This tells km­scon to start what comes af­ter the — af­ter –login. In my case, that’s the de­fault /bin/login pro­gram with the pa­ra­me­ter -f and then my user­name.

Launching tmux on boot

After km­scon signs me in, I want tmux to au­to­mat­i­cally launch into vimwiki. But only if I’m on the main tty (the de­fault vir­tual ter­mi­nal).

I can do this eas­ily by adding a small bash if/​then to my .bashrc:

# Launch tmux if we aren’t al­ready run­ning tmux and we’re in the de­fault tty if [ -z “${TMUX}” ] && [ $(tty) == “/dev/pts/0″ ]; then exec tmux new-ses­sion -d ‘vim -c VimwikiIndex’ \; at­tach fi

This works by check­ing to make sure we’re not in tmux al­ready (which would be re­cur­sive and bad), and it also makes sure we’re in the first vir­tual tty. If those two con­di­tions are met, then it launches a new tmux ses­sion with the com­mand vim -c VimwikiIndex (which tells vim to con­nect to the Vimwiki in­dex). It then at­taches to that ses­sion.

After us­ing it for a few pro­jects, I love it.

I’ve had this thing go­ing for a week or so now, and I’ve used it to write this blog post, the script for the com­pan­ion video, and an­other fu­ture script I’m work­ing up right now. And it’s awe­some.

I may ex­tend this idea with a spell checker, or per­haps set up a “writerdeck ter­mi­nal” in my work­space us­ing an old 486, to re­ally bring my­self back to a more in­ten­tional ex­pe­ri­ence (with an even bet­ter key­board!).

The point is to write more, and to be less dis­tracted do­ing so. I have al­ways strug­gled im­mensely with the fact that the browser nags at me. I get no­ti­fi­ca­tions about apps need­ing my at­ten­tion. My mu­sic player tells me the next song we’re play­ing. It’s all very con­ve­nient, and very dis­tract­ing.

I’m try­ing to be more in­ten­tional with my tech choices. I want de­vices that do one thing re­ally well, and that when I’m done with that one thing, I can put them away, and do some­thing else. I don’t want every­thing to fol­low me around every­where.

If that’s you, maybe you would ben­e­fit from a wri­ter­deck. For me, it’s been great. :)

Tips

Book Freak #210: The Art of Money Getting

P.T. Barnum’s Golden Rules for Making Money

Get The Art of Money Getting

P.T. Barnum was 70 years old when he turned his most pop­u­lar lec­ture into this book in 1880. By then, he’d al­ready built America’s most fa­mous mu­seum in New York, in­tro­duced General Tom Thumb to au­di­ences, served as mayor of Bridgeport, gone broke from a dis­as­trous in­vest­ment in a Connecticut clock com­pany, and clawed his way back. He was 60 when he co-founded the trav­el­ing show that even­tu­ally be­came Barnum & Bailey Circus. The Art of Money Getting compresses a life­time of hus­tle into 20 plain­spo­ken rules.

Core Principles

1. Don’t Mistake Your Vocation

Barnum’s first rule: pick the work you’re built for, then aim to be the best at it. Most peo­ple get this back­ward. They take what­ever job pays and spend decades fight­ing up­stream. The peo­ple who suc­ceed have a knack for what they do. Find your knack first.

2. Avoid Debt Like the Plague

Debt eats self-re­spect. Barnum says young peo­ple, es­pe­cially, should avoid it. The mo­ment you owe some­body money, you’ve handed them a piece of your free­dom. The whole game is keep­ing in­come above outgo.

3. Whatever You Do, Do It With All Your Might

Half-doing is ex­pen­sive. Barnum watched neigh­bors spend whole life­times poor be­cause they only kind of worked, while some­body else got rich do­ing the same job thor­oughly. The peo­ple who go all in pull ahead of the ones who don’t.

4. Preserve Your Integrity

Nobody buys from some­one they don’t trust. You can be the friend­liest mer­chant in town, but if a cus­tomer sus­pects you of cheat­ing, they’ll walk to the next shop. Dishonesty might pay this week. It costs you over a life­time. Reputation is the ac­tual as­set.

Try It Now

Examine your cur­rent work. Does it match your nat­ural abil­i­ties? If not, what would? Make a plan to move to­ward it.

List your debts. Create a con­crete plan to elim­i­nate them, start­ing with the small­est. Avoid tak­ing on any new debt this month.

Pick one task you’ve been half-do­ing. This week, do it with all your might. early and late, leav­ing no stone un­turned.

Quote

“Money is, in some re­spects, like fire. It is a very ex­cel­lent ser­vant, but a ter­ri­ble mas­ter.”

“Money is, in some re­spects, like fire. It is a very ex­cel­lent ser­vant, but a ter­ri­ble mas­ter.”

Book Freak is pub­lished by Cool Tools Lab, a small com­pany of three peo­ple. We also run Re­comendo, the Cool Tools web­site, a YouTube chan­nel and pod­cast, and other newslet­ters, in­clud­ing Re­comendo Deals, Gar’s Tips & Tools, Nomadico, What’s in my NOW?, Tools for Possibilities, Books That Belong On Paper, and Book Freak.

05/22/26

For years, my desk was pushed against the wall. I would sit in front of it, look at the wall, and work. It was fine, and I never re­ally ques­tioned it.

After a re­cent trip to Hamburg, vis­it­ing var­i­ous mu­se­ums and ex­hi­bi­tions, some­thing struck me. I had­n’t seen a sin­gle desk that was fac­ing the wall. Almost every sin­gle desk was in the mid­dle of the room, and fac­ing the room it­self.

Once I was back from my trip, I ro­tated the whole setup for my desk, and flipped it. Now my desk is fac­ing the room. My back is against the wall, I can see the door, and I have the rest of the room in my field of view. It is a small change, but the space feels very dif­fer­ent. I should have done this ear­lier.

From time to time peo­ple still mes­sage me of my desk pho­tos that ap­peared on Instagram or X. Those pho­tos are old now, and I ac­tu­ally changed my room setup quite a bit. The room looks dif­fer­ent, and the desk has changed as well. Over the last months I started to think more care­fully about what I want from a desk and how I spend time around it.

Rethinking the desk

Instead of hav­ing a sin­gle, tech only desk, I now use one large desk that is split into two parts: a dig­i­tal side and an ana­log side.

For a long time my idea of a desk was sim­ple: a place for a com­puter, mon­i­tor, key­board, mouse, and some ac­ces­sories. It was a work sur­face for tech­ni­cal tasks. Everything else had to adapt to that. Here is an old photo:

The prob­lem is that this pulls every ac­tiv­ity into the same mode. If you sit down, you are in front of screens. Even if you only want to read, think, plan, or write some­thing by hand, the com­puter is right there and com­petes for your at­ten­tion.

This also means that I al­ways had to push away my key­board if I wanted to have more space for writ­ing or sketch­ing.

I did not want to main­tain two sep­a­rate desks in the same room, but I also did not want the com­puter to dom­i­nate every­thing. A sin­gle, long sur­face with two clearly de­fined ar­eas turned out to be a good com­pro­mise. So I re­searched and ended up with the one in the pic­tures, which is a 200x75cm long desk from USM Haller.

The idea is that, on one side I keep the dig­i­tal tools. On the other side I keep the ana­log tools. They share the same piece of fur­ni­ture, but they serve dif­fer­ent pur­poses.

The dig­i­tal side

The dig­i­tal side is the part of the desk by the win­dows. It has the Studio Display, the Mac and my split key­board (It’s the Elora Halcyon with my own cus­tom de­sign) This is where I spend most of my day writ­ing, cod­ing, and be­ing on calls, so I try to keep it as empty as pos­si­ble.

This area is in­ten­tion­ally min­i­mal. Everything on this side is di­rectly re­lated to my day to day work. When I sit in the chair and slide over to this half of the desk, I know I am there to write, code, re­view some­thing, or join a call.

This also changed how I think about adding new items. If some­thing wants to live on the dig­i­tal side, it has to be used reg­u­larly. If not, it moves to the other half of the desk or leaves the desk en­tirely.

The ana­log side

The other half of the desk is re­served for every­thing that does not need a screen. On a typ­i­cal day, this part of the desk has:

A note­book or plan­ner

A cou­ple of foun­tain pens

Books I am cur­rently read­ing

Loose sheets with sketches or di­a­grams

A desk lamp that nicely il­lu­mi­nates the sur­face (It’s the Artemides Tolomeo Mini, with my cus­tom de­signed adap­tor)

This is where I read, write in a jour­nal, plan pro­jects, or out­line ideas. Sometimes I use it for small DIY pro­jects. Sometimes it turns into a shared space with my kids, where we build LEGO or sit to­gether and draw.

The ana­log side does not need to look min­i­mal. It needs to be func­tional and invit­ing. It is a place where things can stay out for a while so I can re­turn to them with­out hav­ing to pack every­thing away.

People fol­low­ing me for a long time know that I re­ally like clean and min­i­mal­ist de­sign, but with time I re­al­ized that min­i­mal­ism also kills cre­ativ­ity, or the pas­sion to work on new things. Maybe it’s best to en­joy a mix of both, min­i­mal­ism and max­i­mal­ism, and adapt ac­cord­ing to your needs.

Living with the setup

I have been us­ing this two-part desk lay­out for about nine to ten months and I am very happy with it.

Facing the room in­stead of the wall makes the of­fice feel more open and com­fort­able. There is now some sort of depth in front of my eyes, that was lack­ing pre­vi­ously. Also, hav­ing the door in front of me, in­stead of my back, feels also safer some­how.

Splitting the desk into a dig­i­tal and an ana­log side cre­ates a clear men­tal bound­ary. And mov­ing the chair from one side to the other is enough to change the con­text.

I do not see my­self go­ing back to a tech only desk. This setup gives me a place to work, a place to think, and a place to spend time with my kids, all on a sin­gle sur­face.

Several times in the last cou­ple of decades, Microsoft has re­leased source code for the orig­i­nal MS-DOS op­er­at­ing sys­tem that kicked off its decades-long dom­i­nance of con­sumer PCs. This week, the com­pany has reached fur­ther back than ever, re­leas­ing “the ear­li­est DOS source code dis­cov­ered to date” along with other doc­u­men­ta­tion and notes from its de­vel­oper.

Today’s source re­lease is so old that it pre­dates the MS-DOS brand­ing, and it in­cludes “sources to the 86-DOS 1.00 ker­nel, sev­eral de­vel­op­ment snap­shots of the PC-DOS 1.00 ker­nel, and some well-known util­i­ties such as CHKDSK,” write Microsoft’s Stacey Haffner and Scott Hanselman in their co-au­thored post about the re­lease.

To un­der­stand the con­text, here’s a very brief his­tory of what would be­come MS-DOS: Programmer Tim Paterson orig­i­nally cre­ated 86-DOS (previously known as QDOS, for “quick and dirty op­er­at­ing sys­tem”) for an Intel 8086-based com­puter kit sold by Seattle Computer Products. Microsoft, on the hook to pro­vide an op­er­at­ing sys­tem for the still-in-de­vel­op­ment IBM PC 5150, li­censed 86-DOS and hired Paterson to con­tinue de­vel­op­ing it, later buy­ing the rights to 86-DOS out­right. Microsoft then li­censed this op­er­at­ing sys­tem to IBM as PC-DOS while re­tain­ing the abil­ity to sell the op­er­at­ing sys­tem to other com­pa­nies. The ver­sion sold by Microsoft was called MS-DOS, and the pro­lif­er­a­tion of third-party IBM PC clones over the ’80s and ’90s made it the ver­sion of the op­er­at­ing sys­tem that most peo­ple ended up us­ing.

Released at the Outline Demoparty in May 2026, Ommen, NL An ex­plo­ration of al­go­rith­mic den­sity in 16 bytes of x86 as­sem­bly.

Hey every­one. I learned pro­gram­ming as a kid on an old IBM PC with a mono­chrome green mon­i­tor over 30 years ago and al­ways wanted to cre­ate a pro­gram for this sys­tem. I cre­ated well over 100 tiny in­tros in the last 15 years. Recently I was not too ac­tive but the fan­tas­tic “Rainbow Surf” from Plex in just 16 bytes mo­ti­vated me to dig up some old dusty sketches again and get to work.

The cre­ation of this pro­gram hap­pened with the usual tin­ker­ing around. I was mess­ing with cel­lu­lar au­toma­ton for graph­ics and sounds and dis­cov­er­ing size­cod­ing tricks. Actually: a) poly­mor­phic asm in­struc­tions, like add [bx+si],al which is 0x0000 b) jump­ing into the mid­dle of in­struc­tions to save bytes and reuse op­codes. In hun­dreds of tiny ex­per­i­ments, this one stuck out, just by the sound of it.

When I un­folded what’s left and re­moved “the rest”, I had a hard time to grasp what’s re­ally go­ing on. I was scratch­ing my head look­ing at the sim­ple for­mula that re­mained af­ter golf­ing many bytes away. I my­self did­n’t ex­pect that the ex­pla­na­tion would go this deep for just these few bytes xD.

My orig­i­nal “M8trix” from 2014 al­ready did smear pseudo­ran­dom let­ters across the screen (in 8 bytes, then in 7) and I al­ways won­dered how I could make it “sound good”. But chrono­log­i­cally in the de­vel­op­ment of “wakeup”, the sound was first. Since you “see what you hear” it does­n’t re­ally mat­ter, but “16 bytes that turn Sierpinski sound into Matrix rain” would be a good sub­ti­tle =)

TLDR: Each time step, an­other Sierpinski tri­an­gle line is a) played on the speaker b) drawn to the screen with a step­size of 56. You can sense the mo­tion, but not re­ally see it, since it’s 8192 “pixels wide” but one line of chars is just 80 bytes. On a much much much big­ger screen, you could see the tri­an­gle. Or, if you don’t “skip pix­els” and draw it all at once, you would see it as well.

So, here are the 16 bytes of x86 real-mode DOS as­sem­bly. When you run it, it uses the video mem­ory as a cal­cu­la­tion space to draw an in­fi­nite Sierpinski frac­tal, and at the same time bangs the speaker with that geom­e­try.

int 10h  ; 2 bytes mov bh, 0xb8  ; 2 bytes mov ds, bx  ; 2 bytes L: lodsb  ; 1 byte sub si, byte 57  ; 3 bytes xor [si], al  ; 2 bytes out 61h, al  ; 2 bytes jmp short L  ; 2 bytes

1. The Canvas: A Primed Void

The code starts with a stan­dard BIOS in­ter­rupt: int 10h. This sets up video mode 0, giv­ing a 40x25 text mode grid. Then the data seg­ment (ds) is pointed to 0xb800, the mem­ory ad­dress of the VGA/CGA text buffer.

When the BIOS clears the screen, it does­n’t fill mem­ory with ab­solute ze­roes. Every char­ac­ter space is two bytes: the ASCII char­ac­ter and the color at­tribute. All 2,000 slots are set to 0x20 (space) and 0x07 (light gray on black). So the screen looks empty, but the mem­ory is al­ready filled with a uni­form pat­tern.

I cre­ated a lot of “noise” or “CA” sound in­tros but this one stands out. It was and is still su­per un­ex­pected! The spe­cific spice here is how mem­ory is ini­tial­ized on “clear screen” and what’s “before” and “after” the ac­tual vis­i­ble mem­ory. The “pure” sound is also lovely (I can care­fully set every­thing with a few more bytes to make it sound the same on all sys­tems) but this spicy dif­fer­ence I still have to fully un­der­stand makes it sound even bet­ter imho =)

2. The Engine: Additive Prefix Sums

The in­ter­twine, the synes­the­sia goes far be­yond what I found so far in other tiny in­tros. I would even go so far as to say it’s re­veal­ing more math­e­mat­i­cal se­crets and re­la­tions than us­ing it­er­ated func­tion sys­tems for the “chaos game” with­out an RNG. Anyway, this time I want you to fun­da­men­tally un­der­stand the math­e­mat­ics of what you hear. Not just “you do some op­er­a­tion here and then it sounds in­ter­est­ing”.

To strip it down to pure math: as­sume a ze­roed state in­stead of 0x20, use add in­stead of xor, and step for­ward 16 bytes at a time. Assume the ac­cu­mu­la­tor al starts at 2.

A DOS seg­ment is ex­actly 65,536 bytes. Moving 16 bytes per step means ex­actly 4,096 steps to tra­verse the seg­ment (\( 65536 / 16 = 4096 \)). Then si wraps cleanly back to 0x0000.

Adding up val­ues be­tween cells cre­ates par­tial sums. Because 4,096 is a mul­ti­ple of 256 (the 8-bit reg­is­ter size), the car­ry­over aligns per­fectly when the seg­ment wraps, cleanly re­set­ting al to 2 at the start of each sweep.

The value fol­lows a bi­no­mial se­quence, scaled by 2:

$$A^{(p)}[k] \equiv 2 \binom{k+p}{p-1} \pmod{256}$$

Here is how the first 16 steps ac­cu­mu­late row by row:

3. Crystallization: XOR and the Sierpinski Shift

Now, back to com­bi­na­torics. By spe­cial laws, when do­ing mod­ulo two, the Sierpinski tri­an­gle emerges. This spe­cific bit is what gets banged into the speaker, while the other bits are ig­nored.

To sep­a­rate the bit­planes, the fact that carry-free ad­di­tion of bits is XOR is why it is there in­stead of add.

Since the code starts with 2 (binary 00000010), only bit 1 is tog­gled be­tween 0x00 and 0x02. This per­fectly maps to rule 60 in el­e­men­tary cel­lu­lar au­tomata:

$$Cell^{(p)}[k] = Cell^{(p-1)}[k] \oplus Cell^{(p)}[k-1]$$

Lucas’s the­o­rem guar­an­tees this matches bit 1 from the ad­di­tion table. See for your­self (‘2’ means bit 1 is set):

4. The Voice of the Machine: Translating Data to Audio

Here is the trick: out 61h, al

Port 61h in­ter­faces with the PC speaker. Bit 1 pushes the speaker cone out (1) and pulls it in (0). The code com­putes the frac­tal via XOR, writes it to mem­ory, and shoves that byte straight into the speaker port.

The 1s and 0s from the frac­tal cre­ate square waves that shift nat­u­rally in pulse width and fre­quency:

When played linewise, this cre­ates self-sim­i­lar, al­most tempo-in­vari­ant byte­beats.

But it gets bet­ter: not only the text is out­put to the speaker but also the re­main­ing bytes of the 64 kilo­byte seg­ment, which in this case also con­tains shad­owed video ROM BIOS code, which is the se­cret in­gre­di­ent to the punky and gritty sound that dif­fers quite a bit from the ex­pected Sierpinski line based over­layed rec­tan­gle wave byte­beat.

5. The 56-Byte Step: Octave Shifts and Diagonal Shears

To recre­ate the M8trix ef­fect, the cells them­selves have to be splat across the screen in a way that the sound buffer is not too large and the screen is nicely sparsely filled with chars.

So the code does­n’t step by 16. sub si, byte 57 plus lodsb means it moves -56 bytes per it­er­a­tion - go­ing back­wards.

The Audio

56 does­n’t di­vide 65,536 evenly. The code only hits off­sets that are mul­ti­ples of 8, tak­ing 8,192 steps and wrap­ping 7 times be­fore re­set­ting. This dou­bles the cy­cle length, halv­ing the fun­da­men­tal fre­quency. The sound drops one oc­tave.

The Visuals

Moving back 56 bytes on an 80-byte wide screen is like mov­ing for­ward 24 bytes (12 columns). Only 10 dis­tinct columns are vis­ited. The frac­tal is­n’t drawn as a solid im­age; it shears di­ag­o­nally into 10 pil­lars of char­ac­ters mov­ing up the screen.

6. Real Hardware and Final Thoughts

The scener mi­ragept did a cap­ture with this mo­ti­va­tion:

“This is so awe­some that I had to try run­ning it in real hard­ware. The green text is a nat­ural fit for MDA/Hercules, so I patched the ad­dress from 0xB800 to 0xB000 which is what MDA uses. I don’t have the ex­act IBM com­puter, but used a 286 with EGA card ca­pa­ble of em­u­lat­ing MDA/Hercules, and a real MDA mon­i­tor, so it’s close enough. Sorry for the low qual­ity au­dio (the con­stant noise is from the ma­chine it­self). Please note that this mon­i­tor (IBM 5151) has a HUGE phos­phor per­sis­tence, which I think hurts the pre­sen­ta­tion in this case be­cause it’s very fast.”

Sorry for the low qual­ity au­dio (the con­stant noise is from the ma­chine it­self). Please note that this mon­i­tor (IBM 5151) has a HUGE phos­phor per­sis­tence, which I think hurts the pre­sen­ta­tion in this case be­cause it’s very fast.”

My re­ply to him:

“HellMood @miragept: Thank you so much for this ♥ I’m happy to see it works like in­tended, even with a slightly dif­fer­ent sound due to the byte change. Maybe it would in­deed be a bit bet­ter to have it run slower, but what I found re­mark­able is, that the Sierpinski struc­ture be­comes ac­tu­ally more vis­i­ble (towards the end) than in my ver­sion =)”

Emulators and dif­fer­ent BIOS ver­sions leave slightly dif­fer­ent ar­ti­facts in RAM. Since the code XORs against what­ever is there, the out­put is highly sen­si­tive to the en­vi­ron­ment. Clearing the mem­ory first would give a per­fectly uni­form out­put, but that costs pre­cious bytes. Embracing the hard­ware’s nat­ural state is just part of the charm of size­cod­ing. Thanks for read­ing.

Links & Resources

Nanogems - A cu­rated se­lec­tion of the best Tiny Intros from the Demoscene

HellMood’s pro­duc­tions on Pouet

Capture on a 286/MDA/Hercules by mi­ragept

Sizecoding Wiki

“Rainbow Surf” - 16 bytes of x86 by Plex

“M8trix” - 8 bytes by HellMood

This text is hand­writ­ten.

Last year, health wear­able maker Oura be­came em­broiled in a so­cial me­dia shit­storm af­ter ink­ing a deal with the Department of Defense and Palantir. Some cus­tomers feared their data would end up in the clutches of the Trump ad­min­is­tra­tion. The scan­dal blew up so much that my part­ner, an Oura ring user, drew my at­ten­tion to it.

Oura rings are health-mon­i­tor­ing hard­ware wear­ables worn on a fin­ger. These bat­tery pow­ered rings keep track of a per­son’s health data, like heart rate, sleep pat­terns, men­strual cy­cles, and dozens of other data points, in­clud­ing their lo­ca­tion. Oura keeps a lot of sen­si­tive in­for­ma­tion about its users on its servers.

As a se­cu­rity and pri­vacy nerd re­porter, and the part­ner of some­one who uses hers, I won­dered: Where does all that data go, and how does it get there? You might as­sume it does­n’t mat­ter. But the way that com­pa­nies set up their prod­ucts and servers makes all the dif­fer­ence be­tween whether gov­ern­ments (or hack­ers) can also ac­cess that user data.

This was a good op­por­tu­nity to dig into how Oura rings work, how they send data and how the data is stored, and who has ac­cess to it. I wrote a de­tailed lon­gread ex­plain­ing why Oura’s se­cu­rity de­sign choices al­low gov­ern­ments to tap records from Oura’s vast banks of user in­for­ma­tion.

Oura is not unique in this, and many (if not most) com­pa­nies de­sign their sys­tems to al­low their staff to ac­cess user data, per­haps for trou­bleshoot­ing cus­tomer is­sues or be­cause it was the eas­i­est and cheap­est setup for a once cash-strapped startup. But Oura is now one of the largest health tech wear­able mak­ers to­day, val­ued at over $11 bil­lion ahead of go­ing pub­lic. The com­pany has a re­spon­si­bil­ity more than ever to en­sure that its users’ data can­not be ac­cessed. And, Oura can no longer ar­gue that it does not have the fi­nan­cial re­sources to do it.

In my pre­vi­ous blog, I re­vealed that Oura data is not end-to-end en­crypted. That means that an Oura user’s health data can be un­scram­bled at cer­tain points as it trav­els from a per­son’s ring, through their phone app, over the in­ter­net, and as it lands on Oura’s servers. The com­pany con­firmed that it stores user data in a way that al­lows some staff to ac­cess it. This also means oth­ers can as well, such as a pros­e­cu­tor with a war­rant, a hacker with stolen keys, or a dis­grun­tled in­sider who wants to leave be­hind a fuster­cluck of a mess.

Out of the three, we know at least one of those things has hap­pened.

When I reached out for com­ment be­fore pub­lish­ing my last ar­ti­cle, an Oura spokesper­son told me that the com­pany does “receive in­fre­quent re­quests from the gov­ern­ment.” Oura said it looks at each re­quest “for le­gal­ity, scope, and ne­ces­sity,” and that it pushes back “where re­quests are in­valid, over­broad, or in­con­sis­tent with our com­mit­ment to pro­tect our mem­bers’ pri­vacy.”

Oura would not say how many re­quests it re­ceives, how of­ten it turns over user data, or what kinds of data are re­quested. Oura has sold over 5.5 mil­lion rings to date as of around the time of my last ar­ti­cle, giv­ing some scale to the size of the com­pa­ny’s cus­tomer base.

I asked Oura back then if it would dis­close how of­ten it re­ceived these re­quests, such as by pub­lish­ing a trans­parency re­port. A wave of tech com­pa­nies be­gan re­leas­ing in ag­gre­gate how many gov­ern­ment de­mands they re­ceived on a semi-an­nual ba­sis. This was largely to counter the claims that they were se­cretly hand­ing over reams of user data to the gov­ern­ment upon re­quest, stem­ming from the NSA sur­veil­lance scan­dal in 2013.

There was some hope in Oura’s ini­tial re­sponse. A spokesper­son told me at the time that while Oura does not pub­lish a trans­parency re­port, the com­pany said it was “actively eval­u­at­ing how to share ag­gre­gate data in a way that main­tains se­cu­rity and does not in­tro­duce risk to our mem­bers.”

It’s been eight months, dear reader.

I re­cently reached out to Oura again to see if it would re­lease a trans­parency re­port, and af­ter sev­eral fol­low-up emails, the once-re­spon­sive Oura has not yet replied to any of my in­quiries, or com­mit­ted to re­leas­ing the num­bers. I’m hope­ful that Oura will re­con­sider and pub­lish how many de­mands it re­ceives as other tech com­pa­nies have.

Without see­ing the num­bers, it is im­pos­si­ble to know how of­ten, if ever, Oura re­jects gov­ern­ment de­mands for data. As the fron­trun­ner in the health wear­ables mar­ket, Oura should share how of­ten the gov­ern­ment de­mands ac­cess to users’ in­for­ma­tion if it wants to earn or keep the trust of its cus­tomers.

~ ~

Thank you so much for read­ing ~this week in se­cu­rity~. If you liked this ar­ti­cle, please share it! Feel free to reach out with any feed­back, ques­tions, or com­ments about this ar­ti­cle: this@weekin­se­cu­rity.com.