kage (影, “shadow”) clones a web­site into a folder you can browse of­fline, with every script stripped out. It opens each page in real head­less Chrome, waits for the page to set­tle, snap­shots the DOM a hu­man would have seen, then deletes all the JavaScript and pulls the CSS, im­ages, and fonts down to lo­cal paths. What lands on disk looks like the live site and runs no code.

Install • Quick start • Commands • Clone • Pack • Double-click app • Native win­dow • How it works

You al­ready know the prob­lem. You hit “Save As” on a page you want to keep, and six months later you open it to find a blank screen, a spin­ner that never stops, or a copy that still tries to phone home to an an­a­lyt­ics server that no longer ex­ists. The page was never re­ally yours. It was a thin client for some­one else’s JavaScript.

kage takes the other road. It dri­ves a real browser, lets the page fin­ish do­ing what­ever it does, grabs the fin­ished re­sult, and then rips every script out of it. No track­ing, no net­work calls, no sur­prises. Just .html files you can open straight off disk, hand to a friend, or pack into a sin­gle file and for­get about for a decade.

Full docs and guides live at kage.tamnd.com.

Install

go in­stall github.com/​tamnd/​kage/​cmd/​kage@lat­est

Prefer a pre­built bi­nary? Grab an archive, a .deb/.rpm/.apk, or a check­sum from re­leases. Or skip in­stalling Chrome your­self and use the con­tainer im­age, which bun­dles Chromium:

docker run –rm -v “$PWD/out:/out” ghcr.io/​tamnd/​kage clone paulgra­ham.com

kage dri­ves a real browser, so it needs Chrome or Chromium on the host. It finds a sys­tem in­stall on its own; point it some­where spe­cific with –chrome or the KAGE_CHROME en­vi­ron­ment vari­able. The con­tainer needs noth­ing ex­tra.

Shell com­ple­tion ships in the box: kage com­ple­tion bash|zsh|fish|pow­er­shell.

Quick start

Let’s mir­ror Paul Graham’s es­says so you can read them on a plane, on a lap­top with no wifi, or in the year 2050 af­ter the site has fi­nally changed its de­sign:

# 1. Clone the site into $HOME/data/kage/paulgraham.com/ kage clone paulgra­ham.com

# 2. Read it back of­fline in your browser kage serve $HOME/data/kage/paulgraham.com # open http://​127.0.0.1:8800

That’s the whole loop. Every es­say, every im­age, every stylesheet, frozen on your disk and runnable with zero net­work. The next two steps are op­tional but nice: col­lapse the whole thing into one file, and pop it open in its own win­dow.

# 3. Squeeze the mir­ror into a sin­gle share­able file kage pack paulgra­ham.com # -> paulgra­ham.com.zim kage open paulgra­ham.com.zim

# 4. Or into one ex­e­cutable that *is* the site kage pack paulgra­ham.com –format bi­nary -o paulgra­ham ./paulgraham # serves it­self, needs noth­ing in­stalled

Commands

Clone

# The whole site, into $HOME/data/kage/<host>/ kage clone https://​paulgra­ham.com

# Just the first 50 pages, two links deep, for a quick taste kage clone paulgra­ham.com –max-pages 50 –max-depth 2

# Only one sec­tion of a big­ger site kage clone go.dev –scope-prefix /doc

# Pull in sub­do­mains too, and scroll each page to trip lazy-loaded im­ages kage clone ex­am­ple.com –subdomains –scroll

# Come back next month and re-ren­der in place to catch new es­says kage clone paulgra­ham.com –refresh

A clone is a po­lite, breadth-first crawl. It reads ro­bots.txt, seeds it­self from sitemap.xml, and stays on the seed host un­less you tell it oth­er­wise. It is also stub­bornly idem­po­tent: each page is keyed by the file it writes, so the same es­say reached over http and https, with or with­out a trail­ing slash, gets fetched ex­actly once. Hit Ctrl-C and it saves its place on the way out; run it again and it picks up where it stopped. –refresh re-ren­ders in place, –force wipes the host and starts clean.

The flags you’ll ac­tu­ally reach for:

kage clone –help has the rest, in­clud­ing ren­der-tim­ing, con­cur­rency, and as­set-size knobs.

Serve

kage serve runs a tiny sta­tic file server over a cloned folder so links and as­sets re­solve the way they would on a real host:

kage serve $HOME/data/kage/paulgraham.com # open http://​127.0.0.1:8800

Pack it into one file

A mir­ror is a folder, which is great for brows­ing and lousy for mov­ing around. Copying thou­sands of lit­tle files is slow, and “here, have this di­rec­tory” is a clumsy thing to hand some­one. kage pack col­lapses the whole mir­ror into one ar­ti­fact, and you choose the shape: an open ZIM archive, or a sin­gle ex­e­cutable that is the site.

A sin­gle ZIM file

kage pack paulgra­ham.com # -> paulgra­ham.com.zim kage open paulgra­ham.com.zim

ZIM is an open file for­mat built for ex­actly this: a whole web­site (or a whole Wikipedia) squeezed into one com­pressed, in­dexed, read-only file. kage writes the en­tire mir­ror into it, text zstd-com­pressed and me­dia stored as-is. It is the for­mat be­hind Kiwix, the of­fline-con­tent pro­ject peo­ple use to carry Wikipedia, Stack Overflow, and Project Gutenberg onto boats, into class­rooms with no in­ter­net, and onto a phone for a long flight. Because the for­mat is a doc­u­mented stan­dard and not a kage in­ven­tion, a paulgra­ham.com.zim you make to­day will still open in any ZIM reader years from now.

So you are not locked into kage. kage open is the quick­est way back in, but the very same file works across the wider Kiwix ecosys­tem:

kage open paulgra­ham.com.zim # read it back with kage ki­wix-serve paulgra­ham.com.zim # or serve it with Kiwix at http://​lo­cal­host

You can also dou­ble-click the file in the Kiwix desk­top app, or load it on Kiwix for Android or iOS to read your mir­ror on your phone. One caveat: kage writes a struc­turally valid archive with the stan­dard meta­data, but it does not build the full-text search in­dex that Kiwix’s own packs ship with, so brows­ing and click­ing work every­where while in-reader search is lim­ited.

Packing is de­ter­min­is­tic. The same mir­ror al­ways pro­duces a byte-iden­ti­cal file, with the archive UUID de­rived from the con­tent in­stead of ran­dom­ized, so a pack is safe to check­sum and cache. A bare host name re­solves against the de­fault out­put di­rec­tory, which is why kage pack paulgra­ham.com just works right af­ter kage clone paulgra­ham.com.

A self-con­tained bi­nary

–format bi­nary glues the archive onto a copy of kage and hands you a sin­gle ex­e­cutable that serves the site of­fline when you run it. Whoever you send it to needs noth­ing in­stalled: not kage, not a ZIM reader, noth­ing.

kage pack paulgra­ham.com –format bi­nary -o paulgra­ham ./paulgraham

The ap­pended archive is plat­form-in­de­pen­dent; only the base ex­e­cutable car­ries the ar­chi­tec­ture. By de­fault kage ap­pends to it­self, so you get a viewer for the ma­chine you ran it on. Point –base at a kage built for an­other OS (grab one from a re­lease; every plat­form ships one) to pro­duce a viewer for that plat­form from your own ma­chine. kage reads the base’s ex­e­cutable header to fig­ure out the tar­get, so a Windows viewer au­to­mat­i­cally gets a .exe name:

# Sitting on a Mac, build a Windows viewer kage pack paulgra­ham.com –format bi­nary –base kage-win­dows-amd64.exe # -> paulgra­ham.exe

The trade is size. The bi­nary car­ries a whole kage, so it weighs around 13 MiB plus the site no mat­ter how small the mir­ror is. When you only need the con­tent, the ZIM is far leaner.

A dou­ble-click app

A bare bi­nary is great from a ter­mi­nal, but dou­ble-click it in a file man­ager and the ex­pe­ri­ence is rough: ma­cOS opens a Terminal win­dow be­hind the site, and on Windows a con­sole flashes up next to it. Add –app and kage wraps the same viewer in a proper desk­top app so a dou­ble-click just opens the site, no ter­mi­nal, with the mir­ror’s own fav­i­con as the icon.

On ma­cOS you get a real .app bun­dle:

kage pack paulgra­ham.com –app # -> paulgra­ham.app open paulgra­ham.app # or dou­ble-click it in Finder

On Linux, point –base at a Linux kage and you get an AppImage-style .AppDir with a .desktop launcher (Terminal=false, so no con­sole). If ap­pim­age­tool is in­stalled, kage folds it into a sin­gle dou­ble-click­able .AppImage for you:

kage pack paulgra­ham.com –app –base kage-linux-amd64 # -> paulgra­ham.Ap­pDir (+ .AppImage)

kage finds the icon by dig­ging the fav­i­con out of the mir­ror (it prefers a large ap­ple-touch-icon.png and falls back to fav­i­con.ico); pass –icon some.png to over­ride it. Pair –app with a we­b­view base (below) and the dou­ble-click opens a na­tive win­dow in­stead of the browser, which is the full “it’s an app” ef­fect.

Windows needs no bun­dle, be­cause there a sin­gle .exe al­ready is the app. The catch is the con­sole win­dow. The re­lease ships a kage_<ver­sion>_win­dows-gui_<arch>.zip whose bi­nary is linked for the GUI sub­sys­tem, so a viewer packed onto it opens with no con­sole be­hind it:

# Build a con­sole-free Windows viewer (from any OS) kage pack paulgra­ham.com –format bi­nary –base kage-win­dows-gui-amd64.exe # -> paulgra­ham.exe

A real win­dow, not a browser tab

By de­fault a packed bi­nary opens your sys­tem browser, which means the site shows up as yet an­other tab, ad­dress bar and all, next to the 47 you al­ready have open. Build kage with the we­b­view tag and it opens the site in its own win­dow in­stead, backed by the op­er­at­ing sys­tem’s WebView (WKWebView on ma­cOS, WebView2 on Windows, WebKitGTK on Linux). Paul Graham’s es­says, of­fline, in some­thing that looks and feels like a real app:

make build-we­b­view # or: CGO_ENABLED=1 go build -tags we­b­view ./cmd/kage kage pack paulgra­ham.com –format bi­nary –base bin/​kage -o paulgra­ham ./paulgraham # opens a win­dow, no browser in sight

This build needs cgo and links the plat­form WebView, so it stays opt-in. The de­fault build is pure Go (CGO_ENABLED=0) and the pre­built re­lease bi­na­ries open the browser, which keeps the cross-com­piled re­lease sim­ple. kage open ho­n­ours the same tag, so built with -tags we­b­view it shows a ZIM in a na­tive win­dow too.

How it works

seed URL ─▶ head­less Chrome ─▶ fi­nal DOM ─▶ strip JS ─▶ lo­calise as­sets ─▶ disk (render) (snapshot) (sanitize) (rewrite links)

A pool of Chrome tabs ren­ders pages; a sep­a­rate pool fetches as­sets over plain HTTP. Every URL maps de­ter­min­is­ti­cally to a lo­cal path, so links get rewrit­ten be­fore the as­set they point at has even fin­ished down­load­ing. The out­put looks like this:

paulgra­ham.com/ ├── in­dex.html # the home page, scripts stripped ├── great­work.html # /greatwork.html, an es­say ├── _kage/ # re­served: as­sets and crawl state │ ├── paulgra­ham.com/​site.css # lo­calised stylesheet (url() rewrit­ten) │ ├── paulgra­ham.com/​pg.png │ └── state.json # vis­ited set, for re­sum­ing └── …

pack rides on the same idea: the mir­ror’s links are al­ready mir­ror-rel­a­tive paths, and those map one-to-one onto the archive’s con­tent en­tries, so a click in a served page hits the right en­try with no rewrit­ing at all.

Building from source

git clone https://​github.com/​tamnd/​kage cd kage make build # -> bin/​kage (pure Go, opens the browser) make build-we­b­view # -> bin/​kage with the na­tive-win­dow viewer (needs cgo) make test # full suite, in­clud­ing the Chrome-driven end-to-end tests make test-short # skip the tests that launch a browser

The repo is split by con­cern:

cmd/​kage/ thin main: pins the main thread, then hands off to cli.Ex­e­cute cli/ the co­bra com­mand tree and flag wiring clone/ the crawl: fron­tier, ren­der work­ers, as­set work­ers, re­sume state browser/ head­less Chrome con­trol and DOM snap­shot­ting san­i­tize/ strip scripts, han­dlers, and javascript: URLs from the DOM as­set/ down­load and lo­calise CSS, im­ages, and fonts urlx/ the de­ter­min­is­tic URL-to-path map­ping zim/ a pure-Go ZIM reader and writer pack/ mir­ror to ZIM or self-con­tained bi­nary, and the of­fline HTTP han­dler viewer/ pre­sent a served site: sys­tem browser, or na­tive win­dow (webview tag) docs/ the tago doc­u­men­ta­tion site

Releasing

Push a ver­sion tag and GitHub Actions runs GoReleaser, which builds the archives, the .deb/.rpm/.apk pack­ages, a multi-arch GHCR im­age with Chromium bun­dled, check­sums, SBOMs, and a cosign sig­na­ture:

git tag v0.1.1 git push –tags

The im­age tag car­ries no v pre­fix (ghcr.io/​tamnd/​kage:0.1.1). The Homebrew and Scoop steps self-dis­able un­til their to­kens ex­ist, so the first re­lease works with no ex­tra se­crets.

License

MIT. See LICENSE.

The curl pro­ject will not ac­cept or oth­er­wise han­dle any vul­ner­a­bil­ity re­ports dur­ing the month of July 2026. We call it the curl sum­mer of bliss.

curl’s sub­mis­sion form on Hackerone will be paused start­ing July 1, 2026.

Summer of bliss starts: July 1, 2026. 00:00 CEST

Submissions re­sume: August 3 2026. 09:00 CEST

The se­cu­rity email ad­dress will also be a dead end, as we will not process or oth­er­wise care about se­cu­rity or vul­ner­a­bil­ity re­ports sent to us that way ei­ther.

Whatever is­sue you find that you feel a need to re­port to the curl pro­ject dur­ing this month has to wait. curl’s Hackerone form opens for sub­mis­sions again on Monday August 3.

We do not ac­cept vul­ner­a­bil­ity re­ports over email in gen­eral, and this fact re­mains dur­ing and af­ter our va­ca­tion.

Vacation for real

The curl main­tain­ers will use this time of less pres­sure to take in some ex­tra air and to en­joy the sum­mer. Maybe stroll out­side a bit more. Breath. Some of us may spend some of this time to see other places.

We may get some ex­tra time to spend on fix­ing bugs or work­ing on new code. Fun stuff!

Side-effects

As a di­rect side-ef­fect of this sum­mer of bliss, to al­low us some more time to han­dle the is­sues that might have piled up for us in early August, we also push the re­lease date of 8.22.0 two weeks into the fu­ture. Now sched­uled to hap­pen on September 2, 2026.

Vulnerability rate

As pre­vi­ously men­tioned, we have been un­der a huge pres­sure for the last four months or so. Now we need some rest. We do not ex­pect this del­uge to be over.

GitHub

curl’s is­sue and pull-re­quest track­ers on GitHub re­main open and ac­tive like nor­mal.

You too?

If you and your Open Source pro­jects also want to par­tic­i­pate in the sum­mer of bliss 2026: just do it and let us know! I would of course en­cour­age you to do so. To take care of your­self as a top pri­or­ity.

The bad guys won’t rest

Probably not. But we will.

But what if there is an emer­gency

Then we get to read about it in August. Or you get a sup­port con­tract and we get to read about it ear­lier.

Contracts ex­cluded

Everyone with a paid sup­port con­tracts will of course still get full and ap­pro­pri­ate ser­vice even dur­ing this pe­riod.

Credits

The ice cream im­age was made by fo­tografierende from Pixabay

Discussed

On hacker news.

Post nav­i­ga­tion

12 Jun, 2026

I’ve be­friended some of the most thought­ful, bril­liant, cu­ri­ous, ec­cen­tric, and sin­cere peo­ple I’ve ever met in the tech in­dus­try. Many of my dear­est friends are for­mer cowork­ers. I’ve also en­coun­tered the most ego­cen­tric, delu­sional, ir­ri­tat­ing per­son­al­i­ties imag­in­able in tech.

It is a mixed bag, like any­thing. But in­creas­ingly, the ego­ma­ni­acs are not only tak­ing cen­ter stage at the most in­flu­en­tial tier of their re­spec­tive com­pa­nies - whether as ‘founding en­gi­neers’ or founders/​CEOs/​CTOs/​ETCs or ‘GTM en­gi­neers’ - but they’re also talk­ing about them­selves in­ces­santly on­line.

That is not good for any of us.

This blog is long so here is the short ver­sion: the tech­nol­ogy in­dus­try spent forty years ac­cu­mu­lat­ing a very spe­cific kind of trust and mostly had bor­ing mo­tives, which made us ap­pear trust­wor­thy and largely be­nign. Over the last decade and change, its lead­er­ship dis­cov­ered that this trust could be liq­ui­dated and con­verted into a dif­fer­ent as­set, at­ten­tion, at what looked like a great ex­change rate. The prob­lem with liq­ui­dat­ing an illiq­uid as­set though is that you don’t find out the real price un­til you try to buy it back. The Founder’s Fund Mafia video is the most egre­gious ex­am­ple of this. If there are any founders out there con­sid­er­ing do­ing their own ver­sion of the Mafia video, please don’t. Instead, fo­cus on pub­li­ciz­ing your core nerd val­ues: a love of learn­ing, cu­rios­ity, an ob­ses­sive in­ter­est in your do­main, and an ad­mirable hu­mil­ity re: how you pre­sent your­self to oth­ers and talk about your ac­com­plish­ments. This will prob­a­bly catch on slower and be less vi­ral, but it will pay off in the long-run once peo­ple ‘turn again­st’ tech founders as re­al­ity stars, which they even­tu­ally will.

The charm­ing & vi­sion­ary nerd trope

Ten years ago, the cul­tural idea of the tech­nol­o­gist was still ba­si­cally Jobs and Wozniak.

Jobs was flawed and every­one knew it, but it was all par for the course. He was ag­gres­sive in his am­bi­tion, un­com­pro­mis­ing about even the most minute de­tails of his com­pany, and oc­ca­sion­ally ar­ro­gant (not al­ways, IMO. Sometimes you’re just right.)

But peo­ple ad­mired him any­way be­cause the prod­ucts he made worked well and were more taste­ful/​sub­tle/​beau­ti­ful than any con­sumer elec­tronic that had come be­fore it. When Jobs was cruel, in the pub­lic’s mem­ory at least, he was cruel about kern­ing or what­ever. The cru­elty was pre­sented as if he was cruel for our sake - for the sake of the cus­tomer. You could model him as a man who wanted the cus­tomer ex­pe­ri­ence and the legacy of his busi­ness to be per­fect, and that’s ex­actly what we want our CEOs to do.

Then there was Woz, the pa­tron saint of com­puter sci­ence: bash­ful, gen­er­ous, hum­ble, averse to the spot­light, and con­tent with hav­ing a rea­son­able amount of wealth but not an ab­surd, evil-seem­ing amount of wealth. He gave away early Apple stock to col­leagues be­cause he felt weird about hav­ing so much and went back to teach­ing fifth grade. Woz was the proof of con­cept that you could be at the ab­solute cen­ter of the most im­por­tant in­dus­trial trans­for­ma­tion of the cen­tury and still not clamor to be fa­mous for it. Instead, you could just do what you loved and make great money and share ideas about what you’d learned.

Together they told this story: the peo­ple build­ing your fu­ture are, at worst, per­fec­tion­ist jerks, and at best, gen­tle ob­ses­sives, and in ei­ther case their at­ten­tion is mostly fo­cused on their work, not at ‘the world’ with its glam­orous sins.

Whether this was ac­cu­rate or not is ir­rel­e­vant. It is what the pub­lic thought. We trusted those peo­ple partly be­cause they did­n’t seem to want our at­ten­tion. They were nerds with money who mostly just wanted to be left to their pro­jects, and it made sense that they were in charge of our dig­i­tal ex­pe­ri­ence.

We have strayed pretty far from that.

A short his­tory of how tech lead­ers went from charm­ing nerd to ter­ri­fy­ing over­lord

I’m go­ing to mas­sively sim­plify the tran­si­tion from ‘helpful, ob­ses­sive nerd who makes bank’ to ‘tech oli­garch from hell who peo­ple joke is not hu­man’ into 3 phases.

Phase one (late 1970s to 2007): the founder as charis­matic, mys­te­ri­ous byprod­uct. Founders ap­peared in me­dia, but the cov­er­age was mostly cen­tered on what they were build­ing. There was a mythol­ogy to them and they’d take pho­tos in their garage sur­rounded by sparkling ma­chin­ery, and they’d do keynotes and mag­a­zine in­ter­views, but they were al­ways or­bit­ing around their prod­ucts and com­pa­nies vs. boast­fully putting their own iden­ti­ties as rich/​in­flu­en­tial peo­ple cen­ter stage. We heard from them at reg­u­lar in­ter­vals, but they were rea­son­ably spaced apart so we did­n’t feel ‘surrounded’. They never got too per­sonal with us. Even Bill Gates, the er­a’s vil­lain, was on the cover of every mag­a­zine but we knew lit­tle about him be­yond that he was com­pet­i­tive and well-read, which is true of all CEOs.

Phase two (2007 to 2015): the founder as para­ble. TED talks be­come a fun and pop­u­lar way to learn new things and find in­ter­est­ing thinkers, The Social Network is a huge com­mer­cial hit, and the be­gin­nings of ‘founder’ as an iden­tity starts to sneak into the cul­tural main­stream. Starting a com­pany be­comes a vi­able ca­reer path thanks to YC, and the founder-as-pro­tag­o­nist nar­ra­tive be­came the re­cruit­ing fun­nel for the en­tire in­dus­try. This phase was fine, be­cause the para­bles were about in­no­va­tion: prod­ucts were still ap­pended to founders, but now the founder was the cen­tral fix­a­tion cul­tur­ally, and the prod­uct was proof that they de­served our ad­mi­ra­tion and cu­rios­ity.

Phase three (2015 to now): the tech in­dus­try as grift-ad­ja­cent. The dig­i­tal com­mons of 2026 is de­fined by its grifters. So it’s not purely tech’s fault that its now seen as a sort of av­enue for get­ting rich quick and amorally, even if you are an oth­er­wise or­di­nary per­son. But it is our fault that many of our ‘figureheads’ are lean­ing way the hell in on this. Elon Musk is the most ab­surd ex­am­ple of this, but he al­most does­n’t count be­cause he is in his own tier of ridicu­lously self-pro­mo­tional and at­ten­tion hun­gry.

But be­yond Elon, we also have OpenAI ac­quir­ing TBPN, a founder-cir­cuit pod­cast. That is, an AI lab buy­ing a talk show.

Then there’s Founders Fund, which in­stalled its chief mar­ket­ing of­fi­cer as the ed­i­tor-in-chief of his own me­dia out­let and now, as we’ll get to, a game show host. So, smartly, these com­pa­nies and funds have learned that be­com­ing me­dia firms is a lot eas­ier and more ef­fi­cient than buy­ing ads in ex­ist­ing me­dia out­fits, who are typ­i­cally held back by some­thing like jour­nal­is­tic in­tegrity. The the­ory is cor­rect short-term, but it ends in a vast hu­mil­i­a­tion of me­dia. Our me­dia out­lets are al­ready hang­ing on by the skin­ni­est thread. With end­lessly wealthy and pow­er­ful tech com­pa­nies turn­ing their ‘big cy­clops eye’ onto suck­ing up share in the at­ten­tion econ­omy, I can only imag­ine the il­lu­sion of ob­jec­tiv­ity is go­ing to de­te­ri­o­rate fur­ther.

And so, the founders at­ten­tion has piv­oted, in the eyes of the pub­lic, from their seem­ingly sa­cred work on nerd shit to an ob­vi­ously shal­low pur­suit of power, money, and fame.

The Founders Fund Mafia video

Eight years ago, the Jobs/Woz im­age was wob­bling. Five years ago the first long crack ap­peared at the base of tech’s rep­u­ta­tion. Fast for­ward to to­day and the fa­cade has shat­tered into tiny pieces to re­veal 10,000 snakes.

The snakes re­ally got loose IMO with the Founders Fund Mafia Game video. This shit is fuck­ing in­sane.

This is Peter Thiel’s VC firm cre­at­ing a slickly pro­duced show in which Sam Altman, Palmer Luckey, Bryan Johnson, Moxie Marlinspike, Dylan Field, Ryan Petersen and a ro­tat­ing bench of the fir­m’s fa­vorite ‘characters’ play a party game about de­cep­tion!!!!!! WHY WOULD YOU DO THAT!!!!

Even if it goes well short term, you are set­ting your­self up to be a punch­line down the road. If any of these guys are in­volved in a Cambridge Analytica-level scan­dal in the fu­ture, peo­ple are go­ing to point to this and be like ‘see, he’s a good liar’, or ‘he was hid­ing how good he is at de­cep­tion here.’ This is so dumb it’s blow­ing my mind.

It’s hosted by Mike Solana of Pirate Wires. The de­but episode is ti­tled “Can Tech Legends Find the Liar?” They filmed it at Tosca Cafe, the same San Francisco bar where the PayPal Mafia posed for their fa­mous 2007 gang­ster photo shoot, so the self-mythol­o­giz­ing is out of con­trol.

Obviously, com­menters called the cast a “nightmare blunt ro­ta­tion.”

One critic re­vealed what the for­mat is for: re­al­ity TV is a 30 yr old laun­der­ing tech­nol­ogy, they said. It takes some­one you’d keep at ar­m’s length and makes him a re­cur­ring guest in your liv­ing room un­til the strange­ness wears off. Ozzy bit the head off a bat so MTV made him the lov­able bum­bling dad who could­n’t work the re­mote, and he be­came a lot more like­able. If the video ed­i­tor and PR team can make enough smart cuts in post, every­body comes off pretty damn charm­ing.

Applied to this cast, this strat­egy be­comes un­de­ni­ably sin­is­ter. One of them runs the most con­se­quen­tial AI lab on the planet and a side pro­ject to bio­met­ri­cally en­roll the species. One of them builds au­tonomous weapons for the Pentagon. Between them, the prin­ci­pals hold the cap­i­tal, the weapons con­tracts, and the line to the White House, and the show’s func­tion is to make you fond of them de­spite all this. (The shrewdest cast­ing de­ci­sion is Moxie Marlinspike, who does­n’t have our fu­ture in his hands as ex­plic­itly, and is one of the most re­spected pri­vacy en­gi­neers around. His pres­ence at the table makes this all seem above-board. He is the equiv­a­lent of the beloved in­die band on the fes­ti­val poster, and the fact that the for­mat needs him there tells you the pro­duc­ers un­der­stand ex­actly what their true goal is with this con­tent.)

It is a charm of­fen­sive, in the tech­ni­cal sense: an of­fen­sive, con­ducted with charm. And even if it racks up some views and con­vinces a few peo­ple who al­ready ride for Sama that tech CEOs are cool, it will dis­turb the rest, at least in hind­sight.

You can still be a pub­lic founder, just re­mem­ber who you are

There is no rea­son founders should dis­ap­pear from pub­lic life. There are too many ad­van­tages to build­ing in pub­lic to ig­nore it.

We just need to be a lit­tle smarter about how we pre­sent founders and tech work­ers in gen­eral to the pub­lic. It’s ex­tremely sim­ple to do it the right way. Just re­mem­ber who you are: a smart kid, of­ten alone, tin­ker­ing around with hard­ware or on your com­puter, try­ing to un­der­stand how things work and see what you can make your­self.

What I’d rec­om­mend for founders and their top-level teams is:

Be trans­par­ent about your goals. Launching a re­al­ity TV show as if your aim is to en­ter­tain and help peo­ple ‘get to know’ your part­ners and port­fo­lio founders is de­cep­tive and creepy. You’re try­ing to hu­man­ize peo­ple who have fucked their rep­u­ta­tions in a covert, dopamine-laced way.

So if your goal is to pro­mote some prod­uct or talk about your­self, just keep it a buck fifty. See Jason Fried’s so­cial pres­ence for proof of what this looks like when you go about it with some sem­blance of hu­mil­ity and au­then­tic­ity. He is fine and not a clown show. He and DH Hansson have re­tained the nerd-dom that made tech in­ter­est­ing/​fun/​cu­rios­ity-dri­ven/​charm­ing for an au­di­ence with a cer­tain taste in the first place. With them, it at least ‘feels’ like what you see is what you get. That does won­ders for your rep­u­ta­tion.

So if your goal is to pro­mote some prod­uct or talk about your­self, just keep it a buck fifty. See Jason Fried’s so­cial pres­ence for proof of what this looks like when you go about it with some sem­blance of hu­mil­ity and au­then­tic­ity. He is fine and not a clown show. He and DH Hansson have re­tained the nerd-dom that made tech in­ter­est­ing/​fun/​cu­rios­ity-dri­ven/​charm­ing for an au­di­ence with a cer­tain taste in the first place. With them, it at least ‘feels’ like what you see is what you get. That does won­ders for your rep­u­ta­tion.

Keep your ego as bal­anced as pos­si­ble. Obviously, be­ing a founder is as­pi­ra­tional, there are tons of ma­te­r­ial ben­e­fits, peo­ple think you are cool, and you have prob­a­bly done in­ter­est­ing or ad­mirable things. But just try to be chill about it if pos­si­ble. Resist the urge to flex in­ces­santly. Even though YouTubers do it, and even though it does re­sult in im­pres­sions and views and likes from peo­ple who want to work at your com­pany or be like you, it is cheap, flimsy at­ten­tion that does­n’t have a ton of stay­ing power. The harder, slower work of win­ning ad­mi­ra­tion and at­ten­tion through the strength of your prod­uct de­ci­sions, busi­ness acu­men, and cus­tomer value is worth the ef­fort.

Founder brands are nec­es­sary now. But they do not have to be as cringe and oc­ca­sion­ally dis­turb­ing as they’ve be­come. Rather than pro­ject­ing an ob­ses­sion with wealth and power, trust­wor­thy founders must in­stead fo­cus care­fully on pro­ject­ing an ob­ses­sion with core nerd val­ues: en­thu­si­asm about niche in­ter­ests, ob­ses­sion with tech­ni­cal pur­suits, a love of learn­ing and cu­rios­ity, and a deep-down hu­mil­ity and skep­ti­cism of the spot­light.

Last year around this time The New York Times Magazine ran an A.I. is­sue with an in­tro­duc­tion ti­tled “Everyone Is Using A.I. for Everything. Is That Bad?” It’s an edited tran­script from the Hard Fork pod­cast, which I think as­sumes two things are true that are turn­ing out to be false.

Once you’ve tried AI, you use it “for every­thing.” No, in fact most peo­ple who’ve tried it are just oc­ca­sional AI users.

Once you’ve tried AI, you use it “for every­thing.” No, in fact most peo­ple who’ve tried it are just oc­ca­sional AI users.

AI has got­ten so good that de­spite any mis­giv­ings, “everyone is us­ing A.I.” No, in fact large chunks of the pop­u­la­tion aren’t us­ing AI at all.

AI has got­ten so good that de­spite any mis­giv­ings, “everyone is us­ing A.I.” No, in fact large chunks of the pop­u­la­tion aren’t us­ing AI at all.

(It is­n’t re­ally strictly de­fined in the ar­ti­cle, but I’m tak­ing AI to mean gen­er­a­tive AI ac­ces­si­ble via a chat in­ter­face.)

Take Gen Z, where AI aware­ness is the high­est: in the last year, even though AI has sup­pos­edly got­ten a lot bet­ter, Gen Z AI adop­tion has all but stalled, with a mean­ing­ful per­cent­age of the Gen Z pop­u­la­tion still us­ing AI rarely, if at all.

Here’s Gallup’s year-over-year (2025/2026) break­down:

79/81% use AI at least rarely

79/81% use AI at least rarely

41/42% are anx­ious about AI

41/42% are anx­ious about AI

32/31% use AI only monthly/​every few months

32/31% use AI only monthly/​every few months

22/31% are an­gry about AI

22/31% are an­gry about AI

21/19% never use AI

21/19% never use AI

This tracks with Microsoft’s new United States AI Diffusion site, based on “anonymized, ag­gre­gated Microsoft teleme­try.” Their as­so­ci­ated blog re­ports “more than 30 per­cent of the US work­ing-age pop­u­la­tion is us­ing AI [meaning about 70% is­n’t], an in­crease of 3 per­cent­age points from the end of 2025.” The un­der­ly­ing aca­d­e­mic pa­per spec­i­fies that us­age is de­fined as “engagement with ma­jor AI ser­vices in­clud­ing ChatGPT, Google Gemini, Anthropic Claude, Microsoft Copilot, and oth­ers….with at least 90 min­utes of us­age time in a given month.”

The Microsoft data is brand new, and it mir­rors an­other us­age study from Datos from last year, also based on real-world us­age data. The Datos study found sim­i­larly that, as of last June, only 21% of desk­top de­vices vis­ited “AI Tools” 10 or more times a month, 62% vis­ited 0 times, and the re­main­ing 17% in be­tween.

Back on the sur­vey side, a re­cent Searchlight Institute study found “58% re­port us­ing or try­ing AI, specif­i­cally tools like ChatGPT or Claude, di­vided evenly be­tween fairly reg­u­lar users (30% use at least a few times a month) [roughly match­ing the Microsoft/Datos data] and more in­fre­quent users (29% have used AI, but only once a month or less).” And fi­nally a new sur­vey from The Argument finds “most Americans use AI once a week or less.”

All of this tri­an­gu­lates to AI use in America at ap­prox­i­mately one third ac­tively us­ing AI, one third oc­ca­sion­ally us­ing AI, and one third never us­ing AI, with some move­ment de­pend­ing on how you de­fine those terms. In any case, this split is a far cry from “everyone is us­ing AI for every­thing;” it’s much closer to “some peo­ple are us­ing AI for some things.” AI use also has­n’t shifted that much in the past six months to a year. In fact, the only thing that has sub­stan­tially changed is neg­a­tive sen­ti­ment about AI has gone sig­nif­i­cantly up, for ex­am­ple the Gallup’s Gen Z poll re­port­ing anger about AI jump­ing about 40% rel­a­tive year over year.

I think it is a rea­son­able con­clu­sion to draw from all of this data that a sig­nif­i­cant per­cent­age of the pop­u­la­tion is ac­tively lim­it­ing their AI us­age. The Searchlight study ex­am­ines a big rea­son why: real con­cerns peo­ple have with AI. The top three con­cerns found are “AI will re­place jobs and cause un­em­ploy­ment” (42%), “AI will vi­o­late peo­ple’s pri­vacy” (35%), and “AI will spread mis­in­for­ma­tion and lies” (33%).

This sen­ti­ment also matches a strong de­sire for safety/​pri­vacy AI reg­u­la­tion. A solid ma­jor­ity thinks “the gov­ern­ment should pri­or­i­tize cre­at­ing safety/​pri­vacy rules for AI, even if that means the U.S. de­vel­ops AI more slowly than coun­tries like China.”

Another big rea­son is skep­ti­cism in AI use­ful­ness. SearchLight asked about a range of tech­nolo­gies and to say “whether you be­lieve the over­all im­pact of each tech­nol­ogy on so­ci­ety is pos­i­tive or neg­a­tive.” AI only has an +8% net pos­i­tive rat­ing right now, right next to +7% for so­cial me­dia, which were only greater than crypto at -17%. Meanwhile cell phones, the in­ter­net, and so­lar en­ergy are at +68%, +67%, and +65%, re­spec­tively.

The Argument study broke this down fur­ther, ask­ing about spe­cific so­ci­etal ben­e­fits from AI, find­ing broad skep­ti­cism and con­clud­ing “people aren’t re­ally buy­ing the bull­ish case for AI that CEOs and boost­ers alike are sell­ing. In other words, the skep­ti­cism about AI’s ef­fects is real and deep-run­ning. And given how many peo­ple use it daily, this is not just an ill-in­formed set of opin­ions on some­thing re­spon­dents have never seen be­fore (like tar­iffs were be­fore 2025).”

It is pos­si­ble for peo­ple to have one view at a so­ci­etal level and then act dif­fer­ently at an in­di­vid­ual level, but that does not seem to be what we’re see­ing here. The plu­ral­ity oc­ca­sional us­age and large per­cent­age of com­plete avoid­ance speaks to the fact that a lot of peo­ple seem­ingly aren’t yet find­ing enough in­di­vid­ual value net of their con­cerns to jus­tify daily or even weekly us­age. The gap in me­dia nar­ra­tive (that every­one is us­ing AI for every­thing) rel­a­tive to the re­al­ity (that some peo­ple are us­ing AI for some things) per­haps re­flects a bub­ble around early-adopt­ing knowl­edge work­ers that in­cludes much of the tech press (and me for that mat­ter, though I’m try­ing re­ally hard to stay con­nected to re­al­ity).

It’s a mis­take for com­pa­nies, pun­dits, and pol­icy mak­ers to ig­nore how peo­ple are re­ally feel­ing and act­ing about AI. It’s not all sun­shine and rain­bows. It’s also clearly not bi­nary (all use or no use), but in­stead a con­tin­uum of AI opin­ions and use, with a lot of peo­ple in the mid­dle.

I think there is an apt anal­ogy to be made here to pref­er­ences around meat con­sump­tion. Another thing that seems to be every­where right now is pro­tein. Telling us how im­por­tant pro­tein is in our diet is anal­o­gous to telling us how use­ful AI is for pro­duc­tiv­ity. And, meat be­ing a pri­mary source of pro­tein is anal­o­gous to AI chat tools be­ing a pri­mary source of gen­er­a­tive AI. And yet here’s how Americans break down in terms of their meat con­sump­tion pref­er­ences, based on a hand­ful of U.S. stud­ies from this decade:

95% eat meat (Gallup, 2023)

95% eat meat (Gallup, 2023)

70% re­port re­duc­ing red meat con­sump­tion (Rutgers, 2024)

70% re­port re­duc­ing red meat con­sump­tion (Rutgers, 2024)

30% eat (all) meat only rarely/​oc­ca­sion­ally (Gallup, 2020)

30% eat (all) meat only rarely/​oc­ca­sion­ally (Gallup, 2020)

12% don’t eat red meat (Nature, 2026)

12% don’t eat red meat (Nature, 2026)

4% don’t eat any meat, that is are veg­e­tar­ian (Gallup, 2023)

4% don’t eat any meat, that is are veg­e­tar­ian (Gallup, 2023)

1% don’t eat any an­i­mal prod­ucts, that is are ve­gan (Gallup, 2023)

1% don’t eat any an­i­mal prod­ucts, that is are ve­gan (Gallup, 2023)

That is, not every­one eats meat, a ma­jor­ity ac­tively curbs their con­sump­tion of red meat, and a sig­nif­i­cant per­cent­age don’t eat it at all. Different peo­ple have dif­fer­ent (not mu­tu­ally ex­clu­sive) rea­sons for lim­it­ing their meat con­sump­tion, in­clud­ing health, cost, en­vi­ron­ment, and ethics. Those are all also pri­mary con­cerns for AI con­sump­tion!

The anal­ogy also high­lights mar­ket op­por­tu­ni­ties to ap­peal to peo­ple across the con­tin­uum, speak­ing to their feel­ings on AI and ad­dress­ing their par­tic­u­lar AI con­cerns. For ex­am­ple, we (at DuckDuckGo) make all AI fea­tures op­tional and one of those fea­tures, duck.ai, is a pri­vate chat­bot al­ter­na­tive that helps ad­dress AI pri­vacy con­cerns. To ex­tend the anal­ogy in this way, we’re a restau­rant with a va­ri­ety of op­tions on the menu, from healthy meat dishes (private AI) to veg­e­tar­ian (turn down AI) to ve­gan dishes (turn off AI), which most eaters across the spec­trum can ap­pre­ci­ate.

Does this mean about one third of the pop­u­la­tion is bound to use AI only rarely/​oc­ca­sion­ally for­ever? No. Unlike with meat, the AI tech­nol­ogy land­scape is chang­ing so rapidly that it is very un­clear both where AI prod­ucts and reg­u­la­tions will end up. Product evo­lu­tion could make AI more use­ful to the av­er­age per­son, and reg­u­la­tions could re­duce con­cerns. However, we can say that, as of right now, a mean­ing­ful per­cent­age of the pop­u­la­tion has tried the cur­rent state of AI and has de­cided to ac­tively limit their use of it.

Share

Microsoft has spent the past year try­ing to con­vince users that it’s lis­ten­ing. Through its Windows K2 ini­tia­tive, the com­pany has been fo­cus­ing on im­prov­ing Windows 11 with bet­ter cus­tomiza­tion, in­ter­face re­fine­ments, bug fixes, and other changes dri­ven by user feed­back.

However, one of the most per­sis­tent com­plaints about Windows 11 re­mains un­re­solved, which is the com­pa­ny’s in­sis­tence on re­quir­ing a Microsoft ac­count dur­ing setup.

A re­cent dis­cus­sion on Reddit started with a sim­ple re­quest. User 2025Fishy ar­gued that Microsoft should re­store the op­tion to cre­ate a lo­cal ac­count di­rectly dur­ing the Windows 11 setup ex­pe­ri­ence.

“I gen­uinely do not ac­cept how Microsoft re­moved the lo­cal ac­count in OOBE,” the user wrote.

The thread quickly filled with sug­ges­tions for by­pass­ing Microsoft’s re­stric­tions us­ing Rufus, com­mand-line tricks, and do­main-join op­tions. However, the orig­i­nal poster re­peat­edly made it clear that workarounds weren’t the point.

“I don’t need tips, I just want Microsoft to change it,” the user replied.

That sen­ti­ment res­onated with other com­menters. “The point is, there should be an op­tion in the OOBE that lets you choose to set it up with a lo­cal ac­count in­stead. Like we had since for­ever,” wrote Affectionate_Creme48.

At first glance, this looks like an­other de­bate about lo­cal ac­counts. After read­ing through the com­ments, I think it’s ac­tu­ally about some­thing big­ger, which is user con­trol.

Microsoft’s push to­ward manda­tory Microsoft ac­counts is­n’t only about sync­ing set­tings and ac­cess­ing cloud ser­vices. It’s also tied to se­cu­rity fea­tures such as BitLocker.

One com­menter, Timusius, ex­plained Microsoft’s likely rea­son­ing: “To avoid the next prob­lem: ‘Microsoft locked my data be­hind bit­locker, and now I can’t get it back.’ they need to store that key on the MS ac­count.”

If you look at it from a se­cu­rity per­spec­tive, that ar­gu­ment makes sense. Devices should be en­crypted by de­fault, and stor­ing re­cov­ery keys on­line can pre­vent users from per­ma­nently los­ing ac­cess to their data.

The prob­lem is that many peo­ple don’t re­al­ize this is hap­pen­ing. A user can set up a com­puter with a Microsoft ac­count, switch to us­ing a PIN every day, and never think about that ac­count again. Then, one day, af­ter a firmware up­date, a hard­ware change, or an un­ex­pected is­sue, the sys­tem may dis­play a BitLocker re­cov­ery screen re­quest­ing a re­cov­ery key.

At that mo­ment, many users dis­cover for the first time that the key is stored in a Microsoft ac­count they may barely re­mem­ber cre­at­ing.

As Drakkaar pointed out in the dis­cus­sion: “Technician’s know how to get around this, but not every­one us­ing a com­puter is a tech­ni­cian.”

That’s the dis­con­nect the soft­ware gi­ant still has­n’t solved. What’s par­tic­u­larly in­ter­est­ing is that this de­bate comes as re­ports sug­gest there are peo­ple in­side Microsoft who agree with the crit­i­cism. Microsoft Vice President Scott Hanselman has also pre­vi­ously re­vealed that some em­ploy­ees have been push­ing the com­pany to re­con­sider its manda­tory Microsoft ac­count re­quire­ment dur­ing setup.

However, de­spite the com­pa­ny’s Windows K2 ef­forts and in­ter­nal dis­cus­sions, Microsoft has not com­mit­ted to restor­ing a straight­for­ward lo­cal ac­count op­tion for all users.

And that’s why this con­ver­sa­tion con­tin­ues to sur­face. A lot of users aren’t ask­ing for an­other workaround. They’re ask­ing for a choice, and more im­por­tantly, they’re ask­ing for a clearer ex­pla­na­tion of how fea­tures like en­cryp­tion, ac­count re­cov­ery, and cloud in­te­gra­tion af­fect their com­put­ers be­fore those de­ci­sions are made for them.

Windows Central’s Take

I find it in­ter­est­ing that Microsoft is spend­ing so much ef­fort through its Windows K2 ini­tia­tive try­ing to re­build trust with users. Yet, it still has­n’t ad­dressed one of the most com­mon com­plaints about Windows 11 setup.

The lo­cal ac­count de­bate has never been about find­ing workarounds. If some­one wants to by­pass Microsoft’s re­quire­ments, there are plenty of ways to do it. The real is­sue is that users feel they’re los­ing con­trol over de­ci­sions that used to be theirs to make.

I also think Microsoft could avoid much of this crit­i­cism by mak­ing the on­line ac­count the de­fault with a lo­cal ac­count op­tion, sim­i­lar to how it works on Windows 10, so peo­ple can choose with­out fric­tion.

Do you think Microsoft should bring back a straight­for­ward lo­cal ac­count op­tion dur­ing Windows 11 setup? Let me know in the com­ments.

More re­sources

Explore more in-depth how-to guides, trou­bleshoot­ing ad­vice, and es­sen­tial tips to get the most out of Windows 11 and 10. Start brows­ing here:

Windows 11 on Windows Central — All you need to know

Windows 10 on Windows Central — All you need to know

Join us on Reddit at r/​Win­dows­Cen­tral to share your in­sights and dis­cuss our lat­est news, re­views, and more.

Mauro Huculak has been a Windows How-To Expert con­trib­u­tor for WindowsCentral.com for nearly a decade and has over 22 years of com­bined ex­pe­ri­ence in IT and tech­ni­cal writ­ing. He holds var­i­ous pro­fes­sional cer­ti­fi­ca­tions from Microsoft, Cisco, VMware, and CompTIA and has been rec­og­nized as a Microsoft MVP for many years.

prefeitura-rio/​Rio-3.5-Open-397B is pre­sented as an orig­i­nal 397B model trained by IplanRIO. It is not. Its weights are a di­rect el­e­ment-wise merge of our model, Nex, with the of­fi­cial Qwen3.5 – 397B-A17B base — about 0.6 Nex / 0.4 Qwen — and we find no ev­i­dence of any train­ing of their own. We can show this two com­pletely in­de­pen­dent ways:

With Rio’s hard-coded “You are Rio” sys­tem prompt re­moved, its own de­ployed model iden­ti­fies it­self as “Nex, from Nex-AGI” 79% of the time — and as “Rio” 0% of the time. It even re­cites our or­ga­ni­za­tion’s be­spoke back­story word-for-word.

Every weight ten­sor in Rio is, to thou­sands of stan­dard de­vi­a­tions, the same 0.6/0.4 blend of Nex and Qwen — across all 60 lay­ers and every com­po­nent of the net­work. Other fine­tunes can­not be ex­plained as in­ter­po­la­tions.

Below is the ev­i­dence. Judge for your­self.

* Linux 7.1 @ 2026 – 06-14 15:21 Linus Torvalds 0 sib­lings, 0 replies; only mes­sage in thread From: Linus Torvalds @ 2026 – 06-14 15:21 UTC (permalink / raw) To: Linux Kernel Mailing List

So it’s only Sunday morn­ing back home, but it’s Sunday af­ter­noon where I am right now, so I’m do­ing the 7.1 re­lease at the reg­u­lar time - just not in the reg­u­lar time­zone.

This ob­vi­ously means that the merge win­dow opens to­mor­row, but I’ll be in yet an­other time­zone by then, so tim­ing will all be a bit ir­reg­u­lar. Normally I try to front-load the merge win­dow and do as much as pos­si­ble the first few days - this time I’m not sure that will work out with my lap­top and a cou­ple of long flights with­out in­ter­net, but I’ve made sure that I have fetched the early pull re­quests (thank you - you know who you are), so I will be able to do some of it off-line.

Anyway, pos­si­ble slight hic­cups in the merge win­dow aside, the news to­day is 7.1. Below is the short­log for the last week - noth­ing par­tic­u­larly in­ter­est­ing or scary stands out, which is as it should be. It’s mostly var­i­ous smaller dri­ver up­dates (gpu, net­work­ing, sound, misc) with some net­work­ing and trace tool­ing fixes. And ran­dom mi­nor changes else­where.

Please do keep test­ing de­spite the re­lease, and apolo­gies in ad­vance if my merge win­dow la­tency is go­ing to be a bit ran­dom the next few days. I briefly con­sid­ered just ex­tend­ing the re­lease for a week, but de­cided it was­n’t re­ally worth it. I may come to re­gret that de­ci­sion,

Linus

–-

Adrian Korwel (2): USB: se­r­ial: io_ti: fix heap over­flow in get_­manuf_info() USB: se­r­ial: io_ti: fix heap over­flow in build_i2c_fw_hdr()

Adrian Moreno (1): net: open­vswitch: fix pos­si­ble kfree_skb of ERR_PTR

Akhil R (2): i2c: tegra: Update Tegra410 I2C tim­ing pa­ra­me­ters i2c: tegra: Fix NOIRQ sus­pend/​re­sume

Alessandro Schino (1): esp: fix page frag ref­er­ence leak on skb_­to_s­gvec fail­ure

Alex Hung (1): drm/​col­orop: Remove read-only com­ments from in­ter­po­la­tion fields

Alexander A. Klimov (1): drm/​vc4: fix kre­al­loc() mem­ory leak

Alistair Popple (1): ar­m64: mm: call pagetable dtor when free­ing hot-re­moved page ta­bles

Alok Tiwari (1): idpf: fix mail­box ca­pa­bil­ity for set de­vice clock time

Anandu Krishnan E (1): misc: fas­trpc: fix use-af­ter-free of fas­tr­pc_user in workqueue con­text

Andi Shyti (1): MAINTAINERS: i2c: de­sign­ware: Remove in­ac­tive re­viewer

Andre Heider (1): nvmem: lay­outs: onie-tlv: fix hang on un­known types

Andreas Schwab (1): riscv/​ptrace: Use USER_REGSET_NOTE_TYPE for REGSET_CFI

Andrzej Kacprowski (1): ac­cel/​ivpu: Fix signed in­te­ger trun­ca­tion in IPC re­ceive

Anirudh Rayabharam (Microsoft) (1): mshv: sup­port 1G hugepages by pass­ing them as 2M-aligned chunks

Anton Leontev (1): hv_netvsc: use kmap_lo­cal_­page in netvsc_­copy­_­to_send_buf

Arnd Bergmann (1): crypto: s390 - add se­lect CRYPTO_AEAD for aes

Arthur Kiyanovski (1): net: ena: PHC: Add miss­ing bar­rier

Baoquan He (1): MAINTAINERS: up­date Baoquan He’s email ad­dress

Bartosz Golaszewski (5): pm­do­main: imx: fix OF node re­f­count net: mv643xx: fix OF node re­f­count nvmem: core: fix use-af­ter-free bugs in er­ror paths slim­bus: qcom-ngd-ctrl: fix OF node re­f­count gpio: fix cleanup path on hog fail­ure

Bjorn Andersson (7): slim­bus: qcom-ngd-ctrl: Fix up plat­for­m_­dri­ver reg­is­tra­tion slim­bus: qcom-ngd-ctrl: Fix probe er­ror path or­der­ing slim­bus: qcom-ngd-ctrl: Correct PDR and SSR cleanup own­er­ship slim­bus: qcom-ngd-ctrl: Register call­backs af­ter cre­at­ing the ngd slim­bus: qcom-ngd-ctrl: Initialize con­troller re­sources in con­troller slim­bus: qcom-ngd-ctrl: Balance pm_run­time en­able­ment for NGD slim­bus: qcom-ngd-ctrl: Avoid ABBA on tx_lock/​ctrl->lock

Breno Leitao (1): rds: mark snap­shot pages dirty in rd­s_in­fo_get­sock­opt()

Can Peng (1): mshv: use kmal­loc_ar­ray in mshv_­root_sched­uler_init

Carlos Song (2): i2c: imx: fix clock and pinc­trl state in­con­sis­tency in run­time PM i2c: imx-lpi2c: fix re­source leaks switch­ing to de­vm_d­ma_re­quest_chan()

Chenguang Zhao (1): net­la­bel: val­i­date un­la­beled ad­dress and mask at­tribute lengths

Chih Kai Hsu (1): r8152: han­dle the re­turn value of us­b_re­set_de­vice()

Christian A. Ehrhardt (1): io_ur­ing/​wait: fix min_­time­out be­hav­ior

Christian König (1): drm/​amdgpu: restart the CS if some parts of the VM are still in­val­i­dated

Cunlong Li (1): zram: fix use-af­ter-free in zram_b­vec_write_­par­tial()

Daniel Drake (1): gpi­olib: han­dle gpio-hogs only once

David Howells (1): rxrpc: Fix the ACK parser to ex­tract the SACK table for pars­ing

David Rosca (1): drm/​amdgpu/​userq: Fix read­ing time­line points in wait ioctl

Davide Ornaghi (2): net­fil­ter: nft_­fib: fix stale stack leak via the OIFNAME reg­is­ter net­fil­ter: nft_meta_bridge: fix stale stack leak via IIFHWADDR reg­is­ter

Dawei Feng (1): octeon­tx2-af: fix mem­ory leak in rvu_set­up_h­w_re­sources()

Dexuan Cui (2): hy­perv: Clean up and fix the guest ID com­ment in hvgdk.h Drivers: hv: vm­bus: Improve the logic of re­serv­ing fb_m­mio on Gen2 VMs

Dinh Nguyen (1): firmware: stratix10-rsu: Fix NULL deref on rsu_send_msg() time­out in probe

Dmitry Osipenko (1): drm/​vir­tio: Fix dri­ver re­moval with dis­abled KMS

Dragos Tatulea (2): net/​mlx5: Fix slab-out-of-bounds in mlx5_­query_nic_v­port_­mac_list net/​mlx5e: xsk: Fix DMA and xd­p_frame leak on XDP_TX xmit fail­ure

Eric Dumazet (3): tcp: re­strict SO_ATTACH_FILTER to priv users ip6_vti: set netns_im­mutable on the fall­back de­vice. ip6_vti: fix in­cor­rect tun­nel match­ing in vti6_tnl_lookup()

Felix Gu (2): soc: mi­crochip: mpfs-sys-con­troller: fix re­source leak on probe er­ror spi: rzv2h-rspi: Fix SPDR read ac­cess width for 16-bit RX

Florian Fainelli (1): ARM: 9476/1: mm: fix kexec and hi­ber­na­tion with CONFIG_CPU_TTBR0_PAN

Florian Westphal (3): net­fil­ter: reval­i­date bridge ports net­fil­ter: nf_ta­bles_of­fload: drop de­vice re­f­count on er­ror net­fil­ter: nft_ex­thdr: fix reg­is­ter track­ing for F_PRESENT flag

Frank Li (1): MAINTAINERS: Add Frank Li as PCI end­point re­viewer

Fushuai Wang (1): net/​mlx5: Use ef­fec­tive affin­ity mask for IRQ se­lec­tion

Gabriele Monaco (16): rv: Fix __user spec­i­fier us­age in ex­trac­t_­params() rv: Reset per-task DA mon­i­tors be­fore re­leas­ing the slot rv: Prevent in-flight per-task han­dlers from us­ing in­valid slots rv: Ensure all pend­ing probes ter­mi­nate on per-obj mon­i­tor de­stroy rv: Do not rely on clean mon­i­tor when ini­tial­is­ing HA rv: Add au­to­matic cleanup han­dlers for per-task HA mon­i­tors rv: Ensure syn­chro­nous cleanup for HA mon­i­tors rv: Prevent task mi­gra­tion while han­dling per-CPU events rv: Use 0 to check pre­emp­tion en­abled in opid tools/​rv: Ensure mon­i­tor name and desc are NUL-terminated tools/​rv: Fix sub­string match bug in mon­i­tor name search tools/​rv: Fix sub­string match when list­ing con­tainer mon­i­tors tools/​rv: Fix cleanup af­ter failed trace setup ver­i­fi­ca­tion/​rv­gen: Fix suf­fix strip in dot2k ver­i­fi­ca­tion/​rv­gen: Fix op­tions shared among com­mands ver­i­fi­ca­tion/​rv­gen: Fix ltl2k writ­ing True as a lit­eral

Guillermo Rodríguez (1): i2c: stm32f7: fix tim­ing com­pu­ta­tion ig­nor­ing i2c-ana­log-fil­ter

HanQuan (1): net: add pskb_­may_pull() to skb_­gro_re­ceive_list()

Hans de Goede (1): clk: qcom: x1e80100-dis­pcc: Stop dis­p_c­c_mdss_md­p_­clk_src from get­ting parked

Hardik Prakash (1): Revert “pinctrl-amd: en­able IRQ for WACF2200 touch­screen on Lenovo Yoga 7 14AGP11”

Heiko Carstens (1): s390: Remove GENERIC_LOCKBREAK Kconfig op­tion

Heiko Stuebner (1): ARM: rockchip: keep re­set con­trol around

HyeongJun An (1): USB: se­r­ial: kl5kus­b105: fix bulk-out buffer over­flow

Hyunwoo Kim (1): inet: frags: fix use-af­ter-free caused by the fqdir_pre_exit() flush

Ido Schimmel (1): ipv6: Fix a po­ten­tial NPD in cleanup_pre­fix_route()

Jack Wu (1): USB: se­r­ial: op­tion: add usb-id for Dell Wireless DW5826e-m

Jakub Kicinski (1): net­dev: fix dou­ble-free in net­de­v_n­l_bind_rx_­doit()

Jani Nikula (1): drm/​xe/​dis­play: fix oops in sus­pend/​shut­down with­out dis­play

Jann Horn (1): name­space: re­strict OPEN_TREE_NAMESPACE/FSMOUNT_NAMESPACE to di­rec­to­ries

Jason Gunthorpe (4): RDMA/core: Validate the passed in fops for ib_get_u­caps() RDMA/umem: Fix trun­ca­tion for block sizes >= 4G RDMA: During rereg_mr en­sure that REREG_ACCESS is com­pat­i­ble iommu/​dma: Do not try to iom­mu_map a 0 length re­gion in swiotlb

Jens Axboe (1): io_ur­ing/​kbuf: don’t trun­cate end buffer for bun­dles

Jeremy Kerr (2): net: mctp: usb: fix race be­tween urb com­ple­tion and rx_retry can­cel­la­tion net: mctp: usb: don’t fail mct­p_us­b_rx_queue on a de­ferred sub­mis­sion

Jiawen Wu (3): net: txgbe: ini­tial­ize mod­ule info buffer net: txgbe: dis­tin­guish mod­ule types by check­ing iden­ti­fier net: txgbe: ini­tial­ize PHY in­ter­face to 0

Joonas Lahtinen (1): drm/​i915/​gem: Fix phys BO pread/​pwrite with off­set

Jork Loeser (3): mshv: limit SynIC man­age­ment to MSHV-owned re­sources mshv: clean up SynIC state on kexec for L1VH mshv: un­map de­bugfs stats pages on kexec

Judith Mendez (2): pinc­trl: mcp23s08: Initialize mcp->dev and mcp->addr be­fore regmap init pinc­trl: mcp23s08: Read spi-pre­sent-mask as u8 not u32

Junrui Luo (1): misc: fas­trpc: fix DMA ad­dress cor­rup­tion due to find­_vma mis­use

Kaitao Cheng (1): mm/​cma_sysfs: skip in­ac­tive CMA ar­eas in sysfs

Karl Mehltretter (2): ARM: 9474/1: io: avoid KASAN in­stru­men­ta­tion of raw half­word I/O ARM: 9475/1: en­try: use byte load for KASAN VMAP stack shadow

Kean Ren (1): ASoC: SDCA: fix NULL pointer deref­er­ence in sd­ca_de­v_un­reg­is­ter_­func­tions

Kendall Willis (1): pm­do­main: ti_sci: add wakeup con­straint to par­ent de­vices of wakeup source

Kiran Kumar K (1): octeon­tx2-af: fix IP frag­ment flag cor­rup­tion on cus­tom KPU pro­file load

Kuan-Wei Chiu (1): clk: sam­sung: gs101: Fix miss­ing USI7_USI DIV clock in per­ic0_­clk_regs

Kyle Meyer (1): bnx­t_en: Fix NULL pointer deref­er­ence

Kyle Zeng (3): ipv6: sit: re­load in­ner IPv6 header af­ter GSO of­floads net: guard time­stamp cmsgs to real er­ror queue skbs net­fil­ter: x_ta­bles: avoid leak­ing per­cpu counter point­ers

Li Jun (1): ASoC: loong­son: Fix in­valid po­si­tion er­ror in ls_pcm_­pointer

Li RongQing (2): dma-map­ping: di­rect: fix miss­ing map­ping for THRU_HOST_BRIDGE seg­ments dma-de­bug: fix phys­i­cal ad­dress re­trieval in de­bug_d­ma_­sync_s­g_­for_de­vice

Linus Torvalds (1): Linux 7.1

Lizhi Hou (1): ac­cel/​amdxdna: Fix mm_struct ref­er­ence leak in aie2_pop­u­late_range()

Lorenzo Stoakes (1): mm/​huge_mem­ory: use cor­rect flags for de­vice pri­vate PMD en­try

Marco Scardovi (1): gpio: rockchip: fix generic IRQ chip leak on re­move

Mario Limonciello (AMD) (1): cpufreq/​amd-pstate: Fix set­ting EPP in per­for­mance mode

Maxime Chevallier (4): net: phy: clean the sfp up­stream if phy prob­ing fails net: phy: re­move phy ports upon probe fail­ure net: phy: Clean the phy_­ports af­ter un­reg­is­ter­ing the down­stream SFP bus net: phy: don’t try to setup PHY-driven SFP cages when us­ing gen­phy

Melissa Wen (3): drm/​col­orop: make lut(1/​3)d_in­ter­po­la­tion props cor­rectly be­have as mu­ta­ble drm/​atomic: track in­di­vid­ual col­orop up­dates drm/​amd/​dis­play: use plane col­or_mgmt_changed to track col­orop changes

Michael Bommarito (8): thun­der­bolt: Reject zero-length prop­erty en­tries in val­ida­tor thun­der­bolt: Bound root di­rec­tory con­tent to block size thun­der­bolt: Clamp XDomain re­sponse data copy to al­lo­ca­tion size thun­der­bolt: Validate XDomain re­quest packet size be­fore type cast thun­der­bolt: Limit XDomain re­sponse copy to ac­tual frame size IB/isert: Reject lo­gin PDUs shorter than ISER_HEADERS_LEN RDMA/srp: bound SRP_RSP sense copy by the re­ceived length sctp: fix uninit-value in __sctp_rcv_asconf_lookup()

Michael Kelley (3): Drivers: hv: vm­bus: Provide op­tion to skip VMBus un­load on panic drm/​hy­perv: During panic do VMBus un­load af­ter frame buffer is flushed mshv: Add con­di­tional VMBus de­pen­dency

Michel Dänzer (1): drm/​amd/​dis­play: Consult MCCS FreeSync cap only if re­quested & sup­ported

Mingyu Wang (1): net: qrtr: fix re­f­count sat­u­ra­tion and po­ten­tial UAF in qrtr_­port_re­move

Muhammad Amirul Asyraf Mohamad Jamian (2): firmware: stratix10-svc: Return -EOPNOTSUPP when ATF async un­sup­ported firmware: stratix10-svc: Don’t fail probe when async ops un­sup­ported

Mukesh Ojha (1): misc: fas­trpc: Fix NULL pointer deref­er­ence in rpmsg call­back

Nam Cao (1): riscv: Fix fast_u­n­aligned_ac­cess_speed_key not get­ting ini­tial­ized

Nicolás Antinori (1): rust: i2c: fix I2cAdapter re­f­counts dou­ble in­cre­ment

Nikita Zhandarovich (1): drm/​i915/​edp: Check sup­ported link rates DPCD read

Peng Yang (1): spi: dw: fix race be­tween IRQ han­dler and er­ror han­dler on SMP

Pengyu Luo (1): clk: qcom: dis­pcc-sc8280xp: Don’t park md­p_­clk_src at reg­is­tra­tion time

Use Claude on Apple plat­forms through the Foundation Models frame­work with the Claude for Foundation Models Swift pack­age. Claude for Foundation Models is a Swift pack­age that makes Claude avail­able as a server-side lan­guage model in Apple’s Foundation Models frame­work. The pack­age con­forms Claude to the frame­work’s LanguageModel pro­to­col, so you drive it with the same LanguageModelSession API you use for Apple’s on-de­vice model: re­spond(to:), stream­ing, guided gen­er­a­tion, and tool call­ing all work the same way.

Requests go di­rectly from your app to the Claude API; Apple is not in the re­quest path and does not see prompts or re­sponses. Usage is billed to your Anthropic ac­count at stan­dard API pric­ing. Your app de­cides when to use Claude and when to use Apple’s on-de­vice model: pass whichever model you want to each ses­sion.

Beta. This pack­age tar­gets the Foundation Models server-side lan­guage model API in­tro­duced in the OS 27 be­tas. APIs may change be­fore gen­eral avail­abil­ity.

Claude for Foundation Models is not a gen­eral-pur­pose Messages API client. Its pub­lic sur­face is the Foundation Models provider con­for­mance plus the con­fig­u­ra­tion types that reach it (ClaudeLanguageModel, ClaudeModel, AuthMode, ClaudeServerTool). For di­rect ac­cess to the Messages API in an­other lan­guage, see the Client SDKs.

iOS 27, ma­cOS 27, vi­sionOS 27, or watchOS 27 (all in beta): the OS re­leases whose Foundation Models frame­work sup­ports server-side lan­guage mod­els

When to use Claude ver­sus the on-de­vice model

A Claude API key from the Claude Console for de­vel­op­ment. See Authentication for pro­duc­tion op­tions.

Add the pack­age to your Package.swift:

Or in Xcode: File > Add Package Dependencies… and en­ter the repos­i­tory URL.

Then add ClaudeForFoundationModels to your tar­get’s de­pen­den­cies and im­port it along­side FoundationModels:

ClaudeLanguageModel is the en­try point. Pass it to LanguageModelSession and use the ses­sion ex­actly as you would with any Foundation Models provider:

im­port FoundationModels

im­port ClaudeForFoundationModels

let model = ClaudeLanguageModel(

name: .sonnet4_6,

auth: .apiKey(ProcessInfo.processInfo.environment[“ANTHROPIC_API_KEY”] ?? “”)

let ses­sion = LanguageModelSession(model: model)

let re­sponse = try await ses­sion.re­spond(to: “Plan a 4-day trip to Buenos Aires.“)

print(re­sponse.con­tent)

The ini­tial­izer also ac­cepts baseURL (default https://​api.an­thropic.com), time­out, and server­Tools (see Server-side tools).

For a com­plete work­ing pro­gram, the repos­i­tory in­cludes Examples/ClaudeExample, a runnable com­mand-line tar­get that streams a chat turn to the ter­mi­nal, with a –search flag that en­ables server-side web search for the turn. Running it re­quires a ma­cOS 27 host.

Model iden­ti­fiers are val­ues of ClaudeModel. Use a com­piled-in con­stant, or con­struct one with ex­plicit ca­pa­bil­i­ties for an ID that is­n’t com­piled in yet (see Capabilities):

Constants mir­ror API model IDs (.opus4_8 is claude-opus-4 – 8) and carry each mod­el’s ca­pa­bil­i­ties. New mod­els ship as new con­stants in pack­age re­leases; check ClaudeModel in Xcode for the cur­rent list, and the Models overview to com­pare mod­els.

Each ClaudeModel de­clares what it ac­cepts: sam­pling pa­ra­me­ters, ef­fort lev­els, adap­tive think­ing, struc­tured out­put, and im­age in­put. The pack­age uses this to de­cide which re­quest fields to send, be­cause send­ing a field a model re­jects is a hard er­ror. The con­stants carry the right ca­pa­bil­i­ties. For an ID that is­n’t com­piled in, de­clare what the model ac­cepts (there is de­lib­er­ately no short­hand that guesses):

Pin a Claude ef­fort level for every re­quest with fixed­Ef­fort:. It takes prece­dence over the frame­work’s per-re­quest rea­son­ing hints, and it’s the only way to re­quest .xhigh or .max, be­cause the frame­work’s rea­son­ing lev­els stop at high. The API de­faults to high when no ef­fort is sent:

The level must be one the model ac­cepts. Each ClaudeModel de­clares which of the five lev­els (low, medium, high, xhigh, max) its model takes, if any: some mod­els don’t ac­cept ef­fort at all.

When to use Claude ver­sus the on-de­vice model

Apple’s on-de­vice model is fast, pri­vate, and works of­fline, but it is sized for light­weight tasks. Escalate to Claude when you need larger con­text, fron­tier rea­son­ing, or server-side tools such as web search and code ex­e­cu­tion. Because both use the same LanguageModelSession API, you can switch by swap­ping the model: ar­gu­ment.

Set the cre­den­tial with the auth: pa­ra­me­ter.

A key bun­dled into an app is ex­tractable from the ship­ping bi­nary, and any­one who ex­tracts it can make re­quests billed to your ac­count. Use .apiKey for de­vel­op­ment only, and switch to a proxy be­fore re­lease.

For pro­duc­tion, route re­quests through your own back end with .proxied. The re­lay at baseURL adds the Claude API cre­den­tial server-side, so the app ships no key. The head­ers you pro­vide are sent on every re­quest so your proxy can au­tho­rize the caller. Pass [:] if it needs none:

Your proxy re­ceives stan­dard Messages API re­quests, at­taches the x-api-key header, and for­wards them to https://​api.an­thropic.com.

stream­Re­sponse(to:) re­turns the re­sponse in­cre­men­tally. Each el­e­ment is a cu­mu­la­tive snap­shot of the re­sponse so far, not a delta:

let stream = ses­sion.stream­Re­sponse(to: “Summarize to­day’s top sci­ence sto­ries.“)

for try await par­tial in stream {

print(par­tial.con­tent)

Annotate a type with @Generable and re­quest it with gen­er­at­ing:. The model re­turns a value of that type through struc­tured out­puts:

@Generable

struct Trip {

@Guide(description: “Destination city”) var des­ti­na­tion: String

@Guide(description: “Length in days”) var days: Int

let re­sponse = try await ses­sion.re­spond(to: “Plan a trip to Tokyo.”, gen­er­at­ing: Trip.self)

print(re­sponse.con­tent.des­ti­na­tion)

Structured out­put re­quires a model whose ca­pa­bil­i­ties in­clude it (all com­piled-in con­stants do). If the cho­sen model does not, the pack­age throws LanguageModelError.unsupportedGenerationGuide rather than silently de­grad­ing.

The frame­work’s tools: ar­ray works un­changed. Conform your types to Tool, pass them to LanguageModelSession, and the frame­work in­vokes them on the de­vice when Claude calls them. See Tool use with Claude.

Server tools (web search, web fetch, and code ex­e­cu­tion) run on Anthropic’s in­fra­struc­ture within a sin­gle round trip, with noth­ing for the frame­work to in­voke on the de­vice. Configure them per model with server­Tools::

.webSearch and .webFetch ac­cept op­tional al­lowed­Do­mains, blocked­Do­mains, and maxUses. Server tool ac­tiv­ity sur­faces in the tran­script as ClaudeServerToolSegment cus­tom seg­ments.

server­Tools is con­fig­ured on ClaudeLanguageModel rather than on LanguageModelSession be­cause the ses­sion type is Apple’s. To use dif­fer­ent server-tool sets per con­ver­sa­tion, con­struct mul­ti­ple ClaudeLanguageModel in­stances.

Models whose ca­pa­bil­i­ties in­clude im­age in­put de­clare the frame­work’s vi­sion ca­pa­bil­ity. Pass im­age con­tent through the frame­work’s stan­dard ses­sion API; the pack­age con­verts it to the Claude API’s im­age for­mat. See Vision for im­age re­quire­ments.

The pack­age maps Claude API er­rors onto Apple’s LanguageModelError cases where one fits: con­text-win­dow over­flow sur­faces as .contextSizeExceeded, HTTP 429 as .rateLimited, a re­quest past the con­fig­ured time­out as .timeout. Provider er­rors with no frame­work equiv­a­lent sur­face as ClaudeError. Pattern-match to drive prod­uct flows:

do {

let re­sponse = try await ses­sion.re­spond(to: prompt)

print(re­sponse.con­tent)

} catch ClaudeError.missingCredential {

// Prompt for an API key.

} catch let er­ror as LanguageModelError {

// Framework-shaped er­rors (rate lim­its, guardrails, con­text length, de­cod­ing).

} catch {

// Transport er­rors.

A com­mon pat­tern is to catch .rateLimited and fall back to SystemLanguageModel for that turn, queue the re­quest, or sur­face a retry af­for­dance.

The pack­age sur­faces the Messages API ca­pa­bil­i­ties that the Foundation Models provider pro­to­col can ex­press. Features with no rep­re­sen­ta­tion in Apple’s pro­to­col are not avail­able through it, in­clud­ing:

Prompt caching con­trols (the pack­age ap­plies prompt caching au­to­mat­i­cally; cache TTL and break­point place­ment are not con­fig­urable)

LanguageModelSession, @Generable, Transcript, Tool, and the rest of the frame­work sur­face­Source, the runnable ex­am­ple, and the is­sue tracker

The pack­age is li­censed un­der Apache 2.0. Bug re­ports are wel­come through GitHub is­sues. External pull re­quests are not be­ing ac­cepted dur­ing the beta pe­riod.

Emacs fea­tures have a dis­cov­er­abil­ity prob­lem, and we’re chip­ping away at it one demo at a time. The years since I wrote the last one of these have yielded more sur­pris­ing and use­ful finds, so it’s time again for a “batteries in­cluded” re­port.

This is the third in a se­ries of ar­ti­cles high­light­ing use­ful but lesser-known fea­tures in­cluded in Emacs.

Parts 1 & 2:

Batteries in­cluded with Emacs

More bat­ter­ies in­cluded with emacs

“Lesser-known” is a sub­jec­tive judg­ment. Roughly, it means that at the time of writ­ing, I have seen these fea­tures men­tioned fewer than five times — and of­ten never — in the past two decades of dip­ping in and out of on­line Emacs dis­course. Some of the fea­tures cov­ered in past en­tries are well known and of­ten rec­om­mended to­day. I claim no credit.

If you’re a new Emacs user, don’t start here. This is not a get­ting-started guide. You will be bet­ter served by grokking ba­sic Emacs con­cepts and stick­ing to the most widely rec­om­mended pack­ages. Once you’ve ex­pe­ri­enced the Emacs equiv­a­lents of thoughts like “Why did­n’t any­one think to put wheels on lug­gage un­til 1990?”, this se­ries might be more help­ful.

My rule of thumb is that if you aren’t yet aware of undo-in-re­gion, there is much low hang­ing fruit for the pick­ing, and you can come back to this ar­ti­cle af­ter that sup­ply has run out!

.

Veteran Emacs users tend to use some rel­a­tively niche Emacs fea­tures, but in my ex­pe­ri­ence it’s al­ways a dif­fer­ent sub­set for each user. So if you’ve been around the block a few times, I promise there will still be sur­prises be­low for you as well!

Same rules as be­fore:

No pack­ages, stock Emacs only

No pack­ages, stock Emacs only

No steep learn­ing curves. Learn each fea­ture in un­der five min­utes or bust.

No steep learn­ing curves. Learn each fea­ture in un­der five min­utes or bust.

No gim­micks. No doc­tor, tetris, snake, dun­net, zone, but­ter­fly… yes, we know about dis­so­ci­ated-press. Let’s move on.

No gim­micks. No doc­tor, tetris, snake, dun­net, zone, but­ter­fly… yes, we know about dis­so­ci­ated-press. Let’s move on.

Just the deltas. No com­monly men­tioned pack­ages like Flymake, doc-view, out­line-mi­nor-mode, gnus or eww. Nothing that Emacs brings up au­to­mat­i­cally or a non­spe­cific Google search gets you.

Just the deltas. No com­monly men­tioned pack­ages like Flymake, doc-view, out­line-mi­nor-mode, gnus or eww. Nothing that Emacs brings up au­to­mat­i­cally or a non­spe­cific Google search gets you.

Assume a mod­ern Emacs, 28.1+. Also, if you’re new to Emacs and still read­ing:

Emacs jar­gon Modern par­lance

M-x Alt + x

C-x Ctrl + x

Frame Emacs win­dow

Window split/​pane

Buffer Contiguous chunk of text/​data

Point Cursor po­si­tion in buffer

Active Region Text se­lec­tion

Region Text se­lec­tion (not high­lighted)

Face Font, color and dis­play prop­er­ties

I’m Sorry.

Assume a mod­ern Emacs, 28.1+.

Also, if you’re new to Emacs and still read­ing:

I’m Sorry.

Okay? Let’s go:

Dictionary on hover (M-x dic­tio­nary-tooltip-mode)

Turn on dic­tio­nary-tooltip-mode to see word mean­ings in tooltips when you hover over them:

Of course, tooltip-mode will need to be en­abled as well, but that’s the de­fault.

If you have lo­cal dic­tio­nar­ies set up, it will try those first. Note that Emacs’ dic­tio­nary can look up con­tem­po­rary jar­gon and lingo too, usu­ally via Wiktionary:

find-file and dired with wild­cards

A sur­pris­ingly lit­tle known util­ity of two of the most used Emacs com­mands: you can use wild­cards when us­ing both find-file and dired in­ter­ac­tively.

When find­ing files with find-file (C-x C-f), open mul­ti­ple files at once with a wild­card like *foo*.txt.

When open­ing a di­rec­tory with Dired, pro­duce a cus­tom list­ing of spe­cific files by spec­i­fy­ing a file­name wild­card.

Here’s a demo where both fea­tures are used to clean up some (very) old TeX com­pi­la­tion ar­ti­facts and then open a bunch of LaTeX files at once:

Run Dired with a “two-level” wild­card */*_region_*: look for all files with “_region_” in their name, but only in sub-di­rec­to­ries.

Dired pro­duces a list­ing of these files. (These are tem­po­rary files cre­ated by AucTeX.)

Select them all (with dired-tog­gle-marks, bound to t) and delete them.

Run find-file with a wild­card, open­ing all TeX files in sub-di­rec­to­ries.

Check the list of buffers to see that sev­eral TeX files have been opened.

(The com­mand used to see the list of open buffers is con­sult-buffer, and the com­ple­tions are dis­played by Corfu.)

The fact that this is pos­si­ble when call­ing them pro­gram­mat­i­cally is ev­i­dent from their func­tion sig­na­tures. But re­al­iz­ing that this ca­pa­bil­ity is also avail­able dur­ing in­ter­ac­tive use re­quires read­ing through the full doc­string, and no one has the time for that!

In prac­tice the Dired wild­card ca­pa­bil­ity is su­per­seded by a mod­ern work­flow like con­sult-find ex­ported as a Dired buffer by em­bark-ex­port, but this works out of the box.

You might be fa­mil­iar with Emacs’ “find-file-at-point” fea­ture, M-x ffap, that checks if the cur­sor is on a valid file path and of­fers to open it.

This is ac­com­pa­nied by ffap-menu, a less well known but equally handy com­mand. ffap-menu scans the whole buffer for any­thing that looks like a file path or URL and pre­sents you with all of them:

Since it of­fers a com­plet­ing-read in­ter­face, this opens up a small uni­verse of pos­si­bil­i­ties: you can ex­port the list of (possibly fil­tered) com­ple­tions into a buffer, copy or open all or any sub­set of them, or oth­er­wise act on them right away with Embark.

Addendum: Listing prop­er­tized links

Many Emacs ap­pli­ca­tions (like EWW) in­clude URLs as text prop­er­ties and not plain-text links, and ffap-menu misses them. Inspired by ffap-menu, I use a home-brew ver­sion that fetches such links as well.

Start with EWW show­ing a Wikipedia page, with imenu on the left.

Call my/​search-oc­cur-browse-url, a cus­tom com­mand in­spired by ffap-menu

Scroll through the list of page links, and scroll through the page it­self.

The en­hanced ver­sion:

(defun my/​search-oc­cur-browse-url (&optional use-generic-p) “Point browser at a URL in the buffer us­ing com­ple­tion. Which web browser to use de­pends on the value of the vari­able `browse-url-browser-function’.

Also see `my/search-occur-url’.” (interactive “P”) (let ((match nil) (match-data nil) (context (lambda (beg &optional shrp) (let* ((before (string-replace “\n” “” (buffer-substring-no-properties beg (max (line-beginning-position) (- beg 30))))) (link (string-replace “\n” “” (buffer-substring-no-properties beg (point)))) (after (buffer-substring-no-properties (point) (min (line-end-position) (+ (point) 30))))) (concat (propertize ” ” ‘display ’(space :align-to 65)) (propertize (concat “…” be­fore) ’face ’shadow) (if shrp (propertize link ‘face ’(:inherit shadow :weight bold :underline t)) link) (propertize (concat af­ter “…”) ’face ’shadow)))))) (save-excursion (goto-char (point-min)) (while (search-forward-regexp my/​search-url-reg­exp nil t) (push (cons (match-string-no-properties 0) (funcall con­text (match-beginning 0))) match-data)) (goto-char (point-min)) (while (setq match (text-property-search-forward ’shr-url nil nil)) (push (cons (prop-match-value match) (funcall con­text (prop-match-beginning match) ’shrp)) match-data))) (let* ((completion-extra-properties `(:annotation-function ,(lambda (cand) (concat ” ” (cdr (assoc cand match-data)))))) (url (completing-read “Browse URL: ” match-data nil t))) (if use-generic-p (browse-url-generic url) (browse-url url)))))

Compare win­dows (M-x com­pare-win­dows)

There are more com­mands for com­par­ing buffers and files in Emacs than you can shake a stick at: there’s diff, diff-buffers, diff-backup, diff-buffer-with-file, dired-diff, vc-diff, and a whole con­stel­la­tion of ed­iff-, ed­iff-merge- and ed­iff-di­rec­to­ries- com­mands. I lost count at around twenty two, and can’t re­mem­ber most of them.

But my fa­vorite diff com­mand is the light­weight com­pare-win­dows, which does some­thing very ob­vi­ous and sim­ple in a con­text-ag­nos­tic way.

It com­pares the text of two win­dows start­ing from their re­spec­tive cur­sor po­si­tions, and stops at and re­ports the next mis­match. The two win­dows are the ac­tive one and what­ever other-win­dow would se­lect. Obviously less pow­er­ful, but so much eas­ier and faster to run than Ediff

Have you tried ed­iff-re­gions-linewise? Setting this up is a four step process, in­volv­ing se­lect­ing buffers, mark­ing re­gions and call­ing exit-re­cur­sive-edit re­peat­edly, an ad­vanced com­mand that most Emacs users should never en­counter!

or diff:

Move the cur­sor to the be­gin­nings of the text to com­pare in two win­dows.

M-x com­pare-win­dows

That’s it. It moves the cur­sors to the first mis­match and re­ports it.

com­pare-win­dows is only con­cerned with the ac­tual text in the two win­dows, and not the prove­nance of this text. The buffer type, mod­i­fi­ca­tion state, file, ver­sion-con­trol sta­tus — all ir­rel­e­vant! You can even com­pare a chunk of text in a buffer against an­other chunk a lit­tle fur­ther down in the same buffer by dis­play­ing it in both win­dows. In a silly yet ef­fec­tive way, it can even com­pare di­rec­tory con­tents, in­clud­ing file at­trib­utes:

Two di­rec­to­ries con­tain­ing some sim­i­lar-look­ing files.

Place the cur­sors on the same file in both win­dows.

M-x com­pare-win­dows

The cur­sors stop at the first re­ported mis­match, which is a file mod­i­fi­ca­tion time here.

And yes, you can call it with a pre­fix ar­gu­ment to ig­nore white­space dif­fer­ences.

com­pare-win­dows is what you use when you find your­self play­ing spot-the-dif­fer­ence be­tween two views of any kind. It is my most used “diff” com­mand.

Compare di­rec­to­ries with Dired (M-x dired-com­pare-di­rec­to­ries)

But speak­ing of com­par­ing di­rec­to­ries, Dired does (of course) pro­vide a less hacky way to do that. M-x dired-com­pare-di­rec­to­ries in Dired prompts for a di­rec­tory to com­pare with, and marks all files whose names dif­fer in both Dired list­ings. That cov­ers the most com­mon use case, and might be every­thing you need.

But we al­ready did that with the rudi­men­tary com­pare-win­dows. dired-com­pare-di­rec­to­ries is an ac­tual file-level com­par­i­son, so you can pro­vide cus­tom match­ing pred­i­cates in­volv­ing any file at­tribute, like mod­i­fi­ca­tion times or sizes. For in­stance,

you can mark the more re­cently mod­i­fied ver­sion of a file with (> mtime2 mtime1),

or mark files with the same name but dif­fer­ent sizes with (/= size1 size2)

In this ex­am­ple, dired-com­pare-di­rec­to­ries has marked (i) files that are not com­mon to the two list­ings and (ii) files with dif­fer­ing mod­i­fi­ca­tion times:

If you want some­thing more in­ter­ac­tive/​pre­scribed there is also an ed­iff-di­rec­to­ries, be­cause there is an Ediff com­mand for every oc­ca­sion.

Highlight buffer changes (M-x high­light-changes-mode)

While we’re on the topic of spot­ting dif­fer­ences, high­light-changes-mode is a handy way to em­pha­size changes to the file, and a “live” al­ter­na­tive to diff com­mands like diff-buffer-with-file:

Run the be­low code block sync­ing high­light-changes-mode with save-buffer. Now changes are high­lighted un­til the next save.

Make some changes. Notice that added/​changed text is col­ored dif­fer­ently.

Save the buffer, clear­ing the high­lights in the process.

Repeat the last two steps a cou­ple of times.

Visualization with high­light-changes is de­ter­mined only by the mode it­self, and changes are high­lighted from the time the mode is turned on un­til it’s turned off. In gen­eral, this is not what we want. What we would like in­stead is to high­light un­saved changes

There is M-x high­light-com­pare-with-file, but this is non-er­gonomic enough to the point of be­ing un­us­able.

. We could do this with some fi­nesse, or just throw in a cou­ple of hooks:

(defun high­light-changes-mode-turn-off () (and high­light-changes-mode (highlight-changes-mode -1)))

(defun high­light-changes-auto () (when (buffer-file-name) (highlight-changes-mode-turn-on) (add-hook ’after-save-hook #’highlight-changes-mode-turn-on nil t) (add-hook ’before-save-hook #’highlight-changes-mode-turn-off nil t)))

(add-hook ’text-mode-hook #’highlight-changes-auto)

Now all changes in text-mode buffers are au­to­mat­i­cally high­lighted.

The high­light-changes vi­su­al­iza­tion can be cus­tomized to be more sub­tle, but you prob­a­bly don’t want it turned on all the time nev­er­the­less. The above hook logic can eas­ily be turned into a mi­nor-mode in its own right: