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. :)

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.

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.

The tanker deal is not just a com­pe­ti­tion won; it is a de­ci­sion that shifts the bal­ance. Behind the pur­chase of the new Airbus A330 MRTT lies a shift in the cen­tre of grav­ity of Italy’s air de­fence, which is now look­ing in­creas­ingly to Europe within the NATO frame­work, leav­ing be­hind the US op­tion linked to the Boeing KC-46.

In this con­text, Italy has for­malised the ac­qui­si­tion of six Airbus A330 MRTT tanker air­craft, in a deal with a to­tal value of around 1.39 bil­lion euro, in­clud­ing long-term lo­gis­tic sup­port. The news emerges from pub­li­ca­tion on the European TED (Tenders Electronic Daily) por­tal on 19 May 2026 and con­firms that the con­tract was signed on 16 April by ARMAERO.

The de­ci­sion closes a process launched in 2022 that went through can­cel­la­tions, ten­ders with­out valid bids and changes in the in­dus­trial land­scape, be­fore fi­nally set­tling on a European so­lu­tion that has now be­come the stan­dard among sev­eral NATO coun­tries.

From the Boeing KC-46 to a re­turn to Airbus: a geopo­lit­i­cal choice

The path that led to the fi­nal de­ci­sion was com­plex and marked by sev­eral changes of course. Initially, in 2022, Italy had se­lected the Boeing KC-46 Pegasus as the plat­form to re­place and com­ple­ment the cur­rent KC-767A re­fu­elling fleet.

However, the pro­gramme was can­celled in 2024, open­ing a new European ten­der that proved more dif­fi­cult than ex­pected. The sub­se­quent pro­ce­dure, launched in 2024, ended in April 2025 with­out any of­fers fully meet­ing the re­quired tech­ni­cal spec­i­fi­ca­tions.

Only in the fi­nal phase, in December 2025, was a sin­gle pro­posal left on the table: that of Airbus, which led to the de­fin­i­tive sign­ing of the con­tract in 2026.

According to in­ter­na­tional sources and de­fence-sec­tor analy­ses, the Italian de­ci­sion is seen as a clear shift to­wards the European sup­ply chain, with the de­fin­i­tive aban­don­ment of the Boeing KC-46 plat­form in the na­tional con­text.

Both sys­tems are NATO-compatible, so Italy’s abil­ity to op­er­ate along­side the United States does not change. The geopo­lit­i­cal dif­fer­ence is that with Boeing the lo­gis­ti­cal and sup­port cen­tre of grav­ity re­mains more “US-centric”, whereas with Airbus a European ecosys­tem of main­te­nance, train­ing and sup­ply chains is strength­ened.

In prac­tice, NATO re­mains the over­ar­ch­ing frame­work, but Europe is in­creas­ing its weight in en­abling ca­pa­bil­i­ties, such as tankers.

The mean­ing of the con­tract: far more than a sim­ple air­craft pur­chase

The A330 MRTT is not just a tanker for in-flight re­fu­elling, but a multi-role plat­form ca­pa­ble of com­bin­ing dif­fer­ent strate­gic func­tions. The air­craft is used both for di­rect sup­port to com­bat op­er­a­tions and for long-range strate­gic trans­port of per­son­nel and ma­teriel.

For Italy, the in­tro­duc­tion of six new tanker air­craft above all means a sig­nif­i­cant in­crease in the Italian Air Force’s power-pro­jec­tion ca­pa­bil­ity, par­tic­u­larly for mis­sions that re­quire ex­tended en­durance from new-gen­er­a­tion fight­ers such as the F-35 and Eurofighter Typhoon.

Italy joins the club of 19 MRTT op­er­a­tors

Another el­e­ment that has emerged in re­cent hours con­cerns the in­ter­na­tional di­men­sion of the Airbus pro­gramme. With this ac­qui­si­tion, Italy be­comes the 19th op­er­a­tor world­wide of the A330 MRTT, a plat­form that has now been firmly es­tab­lished as the ref­er­ence stan­dard among NATO and al­lied coun­tries.

This high­lights the grow­ing cen­tral­ity of the Airbus air­craft in the mil­i­tary tanker mar­ket, where in re­cent years it has steadily gained ground over its US com­peti­tors.

The A330 MRTT is de­signed to de­liver ex­tended en­durance and op­er­a­tional flex­i­bil­ity. Its pri­mary func­tion is air-to-air re­fu­elling, which al­lows fight­ers to sig­nif­i­cantly ex­tend their time on sta­tion in the op­er­a­tional area with­out re­turn­ing to base.

This ca­pa­bil­ity trans­lates into a di­rect ad­van­tage for NATO mis­sions, for op­er­a­tions in the wider Mediterranean and for pos­si­ble cri­sis sce­nar­ios fur­ther afield. At the same time, the plat­form re­tains a strong lo­gis­ti­cal com­po­nent and can also be used for strate­gic trans­port and hu­man­i­tar­ian op­er­a­tions.

Aircraft vari­ant and in­dus­trial par­tic­i­pa­tion still to be de­fined

Despite the sign­ing of the con­tract, some tech­ni­cal and in­dus­trial as­pects re­main open. It has not yet been clar­i­fied whether the cho­sen con­fig­u­ra­tion will be the stan­dard ver­sion of the A330 MRTT or the more re­cent MRTT+ evo­lu­tion, based on the A330neo and of­fer­ing greater fuel ef­fi­ciency.

In par­al­lel, the level of in­volve­ment of Italian in­dus­try in the pro­gramme still has to be de­fined, a key fac­tor for the eco­nomic and tech­no­log­i­cal re­turn of the op­er­a­tion.

A de­ci­sion that re­draws the bal­ance

Italy’s change of par­a­digm fits into a broader trend in which Boeing is strug­gling to ex­pand the ex­port mar­ket for its tanker com­pared with Airbus.

Several de­fence an­a­lysts point out that al­though the KC-46 is the stan­dard tanker of the USAF, it has suf­fered tech­ni­cal prob­lems and de­lays that have slowed its com­pet­i­tive­ness abroad, to the ben­e­fit of the A330 MRTT, which has al­ready been adopted by many NATO and non-NATO al­lies. In this sense, the Italian choice is seen more as an in­dus­trial vic­tory for Airbus than as an American “political de­feat”.

Overall, Italy’s de­ci­sion to turn to Airbus marks a sig­nif­i­cant step not only in mil­i­tary terms, but also in­dus­tri­ally and geopo­lit­i­cally. Abandoning the KC-46 Pegasus in favour of the A330 MRTT fur­ther con­sol­i­dates the European axis in the mil­i­tary tanker sec­tor, strength­en­ing in­ter­op­er­abil­ity with NATO al­lies that are al­ready users of the plat­form.

For the Italian Air Force, this is an im­por­tant qual­i­ta­tive leap that boosts its global power-pro­jec­tion ca­pa­bil­ity and re­duces de­pen­dence on so­lu­tions out­side the European in­dus­trial base.

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