June 2026

(This is based on a talk I gave at the Oxford Union.)

Since this is ap­par­ently the fu­ture prime min­is­ters’ club, I’m go­ing

to tell you about some­thing it would be good if more politi­cians

un­der­stood: I’m go­ing to tell you how peo­ple be­come bil­lion­aires.

I hope this will be use­ful to you even if you don’t plan to go into

pol­i­tics. Those of you who don’t be­come prime min­is­ter can be­come

bil­lion­aires in­stead.

The rea­son I know about this topic is that 21 years ago Jessica and

I started some­thing called Y Combinator. If you haven’t heard of Y

Combinator, it’s a cross be­tween an in­vest­ment firm and a school

for startup founders. Since we started it in 2005 we’ve funded about

6500 com­pa­nies.

Starting a suc­cess­ful startup is the most

com­mon way to be­come a

bil­lion­aire, so in ef­fect I’ve spent the last 21 years train­ing

peo­ple to be­come bil­lion­aires. So far about 30 of them have, but

there are many more in the pipeline.

So you can imag­ine how as­ton­ished I was last month when an American

politi­cian said that it was im­pos­si­ble to earn a bil­lion dol­lars.

I felt like a skat­ing coach hear­ing some­one say that it’s im­pos­si­ble

to do a triple axel. Of course it’s pos­si­ble. It’s hard, but it’s

pos­si­ble.

She was­n’t say­ing, of course, that it’s im­pos­si­ble to be­come a

bil­lion­aire. Obviously that’s pos­si­ble. Nor was she talk­ing about

the dis­tinc­tion be­tween in­come and cap­i­tal gains. She was­n’t mak­ing

a point about ac­count­ing. What she meant was that it’s im­pos­si­ble

to get that rich with­out do­ing some­thing bad — with­out cheat­ing

in some way.

A cou­ple days later I was talk­ing to the founder of a startup I’d

funded. I be­gan by ask­ing, as I usu­ally do when I meet a founder,

what her growth rate was. 93% last month, she said. I pointed out

that this meant her net worth was also grow­ing at 93% a month. She

was get­ting richer at a stu­pen­dously rapid rate. And yet she had­n’t

been do­ing any­thing bad. The rea­son her startup was grow­ing so fast

was sim­ply that users loved what she’d built. So she could feel

from her own ex­pe­ri­ence how wrong that politi­cian was. She was­n’t

ex­ploit­ing any­one. Exactly the op­po­site in fact. The rea­son her

startup was grow­ing so fast was that she and her co­founder had been

work­ing their asses off to make their users happy, and as a re­sult

the users had been telling their friends. And that gets you ex­po­nen­tial

growth.

Later that day I was talk­ing about her case on­line, and some­one

replied that hav­ing a few mil­lion and grow­ing at 93% a month was

rad­i­cally dif­fer­ent from be­ing a bil­lion­aire.

I sus­pect many peo­ple would agree with this state­ment. But it turns

out not merely to be false, but false in a very il­lu­mi­nat­ing way.

So I would like you all to do me a fa­vor please. I would like you

to take out your phones and cal­cu­late a num­ber. I know this may

seem con­trived, but I promise it will be use­ful for you. I’m go­ing

to have you do the most com­mon kind of cal­cu­la­tion I do as an

in­vestor, and the ex­pe­ri­ence will bring home to you what star­tups

are all about.

If we in­ter­pret his state­ment in the most con­ser­v­a­tive way and

as­sume that a few means 2, her com­pany has to grow 500x for her to

be­come a bil­lion­aire. So we are go­ing to cal­cu­late how many months

of 93% growth it takes for some­thing to grow 500x.

To do this we want to cal­cu­late the log base 1.93 of 500. The eas­i­est

way to do that is to go to Google search, which lets you do

cal­cu­la­tions right in the search box. So go to Google search and

type log(500, 1.93). If you typed that right, the an­swer you get

is about 9.45.

That is how many months of 93% growth it takes to be­come a bil­lion­aire,

start­ing from 2 mil­lion. A cou­ple mil­lion and 93% growth are not,

in fact, rad­i­cally dif­fer­ent from a bil­lion. They’re nine and a

half months apart.

Now you see why, when I meet a founder, the first thing I ask about

is their growth rate.

But I don’t want any­one to ac­cuse me of us­ing un­re­al­is­tic num­bers,

so let’s take a more con­ser­v­a­tive growth rate. Let’s see what hap­pens

at 15% a month. That’s not rare at all. I con­stantly en­counter

star­tups grow­ing at 15% a month.

If your rev­enues grow at 15% a month, how much more will you be

mak­ing 5 years from now? To cal­cu­late that, we need to find 1.15

to the 60th power (since 5 years is 60 months). So go to Google

again and this time type 1.15^60. The an­swer should be about 4384.

Meaning in 5 years your startup will be mak­ing 4384 times as much.

If you’re cur­rently mak­ing ten thou­sand a month, in five years

you’ll be mak­ing about 44 mil­lion a month, or 526 mil­lion a year.

And at that point, if you own as much of the com­pany as founders

typ­i­cally do, you will be a bil­lion­aire.

In the real world, growth rates tend to slow down a bit. A very

suc­cess­ful startup will prob­a­bly be grow­ing faster than 15% a month

in year 1 and slower than 15% a month in year 4. But you end up in

about the same place. If you start a startup in your early twen­ties,

it’s def­i­nitely pos­si­ble to be a bil­lionare by the time you’re

thirty. Hard, but pos­si­ble.

I wanted you to feel this by do­ing the cal­cu­la­tion your­selves,

be­cause now you un­der­stand one of the rea­sons peo­ple start star­tups.

Exponential growth is like magic. It gen­er­ates out­comes that seem

im­pos­si­ble. And that’s why some politi­cians dis­trust it. They don’t

un­der­stand the math of ex­po­nen­tial growth, so when they see peo­ple

be­com­ing what seems to them im­pos­si­bly rich, they as­sume they must

have cheated.

But now you at least un­der­stand, from hav­ing done the math your­selves,

that you don’t have to cheat to be­come a bil­lion­aire. You’ve seen

for your­selves that there are only two num­bers in the cal­cu­la­tion,

the growth rate and how long it con­tin­ues. If it’s im­pos­si­ble to

make a bil­lion dol­lars with­out cheat­ing, which of those two num­bers

is im­pos­si­ble? It’s cer­tainly not im­pos­si­ble to grow at 15% a month

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

Three years ago, I pub­lished my ini­tial work to un­der­stand and re­verse en­gi­neer my car, specif­i­cally the head­unit of my 2021 Honda Civic.1

The ini­tial re­sponse was in­cred­i­bly en­cour­ag­ing. I’m writ­ing to give a pro­ject up­date.

Keys to the Kingdom

The biggest progress has been made while map­ping out the up­date process.

Honda sup­ports up­dat­ing the head­unit via USB. There are a num­ber of Honda-specific checks, but ul­ti­mately the USB drive con­tains a signed AOSP up­date file that gets staged and ap­plied via Android re­cov­ery. The good news? They left the pub­licly-known AOSP test key in res/​keys*, and, even though they mod­i­fied the re­cov­ery bi­nary, the ver­i­fy_­file sig­na­ture logic matches stock AOSP.

So as long as you can prop­erly for­mat a USB drive and sign it with the pub­licly-known AOSP test key, you can in­stall what­ever you want to the head­unit, with­out con­ven­tional root ac­cess (no need for su with se­tuid). This means that, as long as the head­unit has power and an at­tacker has phys­i­cal ac­cess to the front-most USB port, they have ar­bi­trary code ex­e­cu­tion on the head­unit via the up­date path.

This is an evil maid at­tack. Since it re­quires phys­i­cal ac­cess to the cabin of the car rather than the ho­tel room, I call it an evil valet at­tack. Imagine a jour­nal­ist dri­ves to a ho­tel and leaves their car with the valet. The valet, who works for a three-let­ter agency, in­stalls an up­date via USB. When the car is re­turned, the jour­nal­ist does­n’t know the head­unit has been mod­i­fied. Since I want a cool vul­ner­a­bil­ity name, I’m call­ing this “EvilValet”.

This blog ar­ti­cle is not in­tended as a tech­ni­cal writeup. If you want the gory de­tails, see the tech­ni­cal docs.2

I’ve also pub­lished a new tool, ota-builder3, that al­lows peo­ple to eas­ily pre­pare up­date files that will be ac­cepted by the head­unit. While in its early days, it should be triv­ial to now build an up­date file that, for ex­am­ple, in­stalls an su bi­nary with se­tuid set (i.e., to root the de­vice).

*I have strong rea­son to be­lieve that all up­dates are signed with the pub­licly-known AOSP test key, but I don’t have ac­cess to every pos­si­ble of­fi­cial up­date file, nor ac­cess to every head­unit vari­ant and its filesys­tem. My head­unit has the AOSP test key in res/​keys, though I’ve also in­stalled HondaHack, so it’s pos­si­ble that it in­jected the key into the key­store. However, I’ve also con­firmed that MRC_EU_SW_v12_4.zip, a pub­licly-avail­able EU soft­ware up­date file, is test key signed. This file was down­loaded from a pub­lic fo­rum4 and was never mod­i­fied by me. So it seems highly likely that all up­dates are signed with the AOSP test key. Contributors are wel­come to help sup­port or re­fute this hy­poth­e­sis.

Building Tools

Beyond the up­date process, the most use­ful work has been on apk-re­builder5. It has one very im­por­tant job: take in a Honda Civic up­date file from the Internet, and pro­duce a clean tree of out­put files that au­to­mates every­thing a re­verse en­gi­neer would oth­er­wise have to do man­u­ally, in­clud­ing:

Resolving re­sources

Reconstructing .smali code

Repacking APK files

Extracting the ramdisk

And more

This also serves an im­por­tant role be­cause we can’t pub­lish ac­tual Honda source code. We pub­lish a func­tion that takes in an up­date file (that we don’t host) and spits out Honda .smali code, im­age as­sets, etc. The re­sult­ing out­put fol­lows a clear di­rec­tory struc­ture that can be ref­er­enced in doc­u­men­ta­tion with­out ac­tu­ally up­load­ing the sen­si­tive files them­selves.

Outstanding Work - A Call for Contributors

There are a few out­stand­ing things that would be nice to have.

Known Versions

The up­date process is frag­ile and re­lies heav­ily on ver­sion num­bers. This does­n’t limit the abil­ity to run un­signed code, be­cause the ver­sion num­bers can be “spoofed” (see the tech­ni­cal docs). But in or­der to build an up­date file in the first place you need to know what ver­sions your head­unit ex­pects. Further, any changes to the head­unit soft­ware that don’t match my build could lead to un­ex­pected be­hav­ior and re­cov­ery loops.

If you drive a 10th gen Honda Civic and are tech-savvy, I en­cour­age you to con­tribute to the “Known Versions, Display Audio Software” sec­tion of the repo.6

If you’re feel­ing par­tic­u­larly brave, read through the ota-builder code and try and flash an up­date. But do so at your own risk; if your head­unit dif­fers from mine you could get stuck in a re­cov­ery loop and soft­brick your de­vice.

Toolchain

I have an ex­per­i­men­tal/​work-in-progress tool­chain on my lo­cal ma­chine. It takes can­di­date .c code and com­piles it for ARMv7, us­ing the same com­piler ver­sion and build flags as the orig­i­nal ven­dor bi­na­ries. This proved in­dis­pens­able in my work to un­der­stand the up­date process. It makes heavy use of Docker. The cur­rent it­er­a­tion is messy and largely spe­cific to my work­flow, but I’d like to pub­lish a clean im­ple­men­ta­tion.

Custom Themes

I ex­plored this a bit while vibe-cod­ing apk-ren­der­er7. Custom themes are likely dif­fi­cult to ship be­cause they live in Mitsubishi’s fork of the AOSP frame­work, and the head­unit apps are mini­fied to ex­pect hard­coded re­source IDs. Any at­tempt to ship a cus­tom theme would likely in­volve sur­gi­cally edit­ing the ven­dor frame­work (and writ­ing a tool to do so au­to­mat­i­cally). None of this is triv­ial and prob­a­bly is­n’t worth the ef­fort, but I wel­come con­trib­u­tors.

Improve aidl-re­builder

I started work­ing on a tool to parse .smali files and gen­er­ate/​map out all AIDL in­ter­faces on the head­unit. This works but I haven’t re­viewed it fully for ac­cu­racy. This opens up the door for cus­tom apps such as vir­tual speedome­ters. Contributors wel­come.

Thoughts on Documentation and LLMs

I’ve placed less em­pha­sis on ref­er­ence doc­u­men­ta­tion and more on tool­ing. The idea is that if I can ship re­li­able, de­ter­min­is­tic tools that map the head­unit code to more di­gestible forms, then peo­ple can use LLMs to query those more di­gestible forms to an­swer what­ever their spe­cific ques­tions are. This avoids hav­ing to main­tain ref­er­ence docs that can stray from the ac­tual head­unit code, be­cause the head­unit code is the source of truth.

For ex­am­ple, a user guide that ex­plains how to con­nect to the head­unit via ADB is still deemed use­ful. But a doc­u­ment ex­plain­ing how some Java code works, when the Java code it­self is avail­able to an LLM, seems like a main­te­nance bur­den.

Wrapping up and Thanks

At this point, I’ve done most of the in­ves­tiga­tive work I in­tend to do on the head­unit. This is one of those pro­jects that I could toil end­lessly on, but I’ll likely tran­si­tion to other pro­jects. That said, the repo is by no means aban­doned. PRs are al­ways wel­come.

Special thanks to Tunas8 for the mem­o­ries, and to Hackaday9 for cov­er­ing my orig­i­nal work.

See every­one some­time down the road 🌱

Eric

McDonald, E. (2023). “Honda Reverse Engineering”. Juniperspring. Retrieved June 13, 2026. ↩︎

McDonald, E. (2023). “Honda Reverse Engineering”. Juniperspring. Retrieved June 13, 2026. ↩︎

McDonald, E. (n.d.). “Display Audio Update Files”. GitHub. Retrieved June 13, 2026. ↩︎

McDonald, E. (n.d.). “Display Audio Update Files”. GitHub. Retrieved June 13, 2026. ↩︎

McDonald, E. (n.d.). “ota-builder”. GitHub. Retrieved June 13, 2026. ↩︎

McDonald, E. (n.d.). “ota-builder”. GitHub. Retrieved June 13, 2026. ↩︎

fe­lixlen­nart (September 22, 2022). “Install American firmware on European head unit”. 2016+ Honda Civic Forum (CivicX.com). Retrieved June 13, 2026. ↩︎

fe­lixlen­nart (September 22, 2022). “Install American firmware on European head unit”. 2016+ Honda Civic Forum (CivicX.com). Retrieved June 13, 2026. ↩︎

McDonald, E. (n.d.). “apk-rebuilder”. GitHub. Retrieved June 13, 2026. ↩︎

McDonald, E. (n.d.). “apk-rebuilder”. GitHub. Retrieved June 13, 2026. ↩︎

McDonald, E. (n.d.). “Known Versions, Display Audio Software”. GitHub. Retrieved June 13, 2026. ↩︎

McDonald, E. (n.d.). “Known Versions, Display Audio Software”. GitHub. Retrieved June 13, 2026. ↩︎

McDonald, E. (n.d.). “apk-renderer”. GitHub. Retrieved June 13, 2026. ↩︎

McDonald, E. (n.d.). “apk-renderer”. GitHub. Retrieved June 13, 2026. ↩︎

Tunas. (n.d.). “Tunas1337”. GitHub. Retrieved June 13, 2026. ↩︎

Tunas. (n.d.). “Tunas1337”. GitHub. Retrieved June 13, 2026. ↩︎

Posch, M. (June 27, 2023). “Honda Headunit Reverse Engineering, And The Dismal State Of Infotainment Systems”. Hackaday. Retrieved June 13, 2026. ↩︎

Posch, M. (June 27, 2023). “Honda Headunit Reverse Engineering, And The Dismal State Of Infotainment Systems”. Hackaday. Retrieved June 13, 2026. ↩︎

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 • 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 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.

SQL to ER Diagram — free on­line ERD gen­er­a­tor: con­vert a SQL schema (CREATE TABLE state­ments) into an in­ter­ac­tive en­tity-re­la­tion­ship di­a­gram in your browser. Turn SQL into a di­a­gram in­stantly, no signup.

SQL to ER Diagram

SQL schema

Paste SQL, see the schema.

Drop your CREATE TABLE state­ments on the left. Drag ta­bles, scroll to zoom, dou­ble-click to re­name, ex­port when done.

100% lo­cal — your schema never leaves your browser. No ac­counts, no up­loads.

SQL to ER Diagram is a free, open-source tool that con­verts a SQL schema into an in­ter­ac­tive en­tity-re­la­tion­ship di­a­gram (ERD) right in your browser. Paste your CREATE TABLE state­ments and in­stantly vi­su­al­ize ta­bles, columns, pri­mary keys, for­eign keys and re­la­tion­ships. Works with PostgreSQL, MySQL, SQLite and SQL Server. Drag ta­bles, auto-arrange the lay­out, add notes, and ex­port to PNG or SVG. Nothing is up­loaded — your schema stays on your ma­chine.

Frequently asked ques­tions

How do I cre­ate an ER di­a­gram from SQL?

Paste your SQL CREATE TABLE state­ments into the ed­i­tor and SQL to ER Diagram in­stantly ren­ders an in­ter­ac­tive en­tity-re­la­tion­ship di­a­gram. Drag ta­bles to arrange them, then ex­port as PNG or SVG.

Which SQL di­alects are sup­ported?

It parses stan­dard CREATE TABLE and ALTER TABLE DDL and works with PostgreSQL, MySQL, SQLite and SQL Server syn­tax, in­clud­ing pri­mary keys, for­eign keys, unique and not-null con­straints.

Is it free?

Yes. SQL to ER Diagram is com­pletely free and open source, with no ac­count or sign-up re­quired.

Is my data pri­vate? Does my SQL get up­loaded?

Everything runs lo­cally in your browser. Your SQL schema is never up­loaded to or stored on any server.

Can I ex­port the di­a­gram?

Yes. You can ex­port a high-res­o­lu­tion PNG or a vec­tor SVG, save the full pro­ject as a file, or copy a share­able link that en­codes the di­a­gram in the URL.

Do I need to in­stall any­thing?

No in­stal­la­tion needed. It runs en­tirely in your web browser on both desk­top and mo­bile.

Skip to con­tent

Secure your code as you build

We read every piece of feed­back, and take your in­put very se­ri­ously.

Include my email ad­dress so I can be con­tacted

Use saved searches to fil­ter your re­sults more quickly

To see all avail­able qual­i­fiers, see our doc­u­men­ta­tion.

Sign up

You signed in with an­other tab or win­dow. Reload to re­fresh your ses­sion.

You signed out in an­other tab or win­dow. Reload to re­fresh your ses­sion.

You switched ac­counts on an­other tab or win­dow. Reload to re­fresh your ses­sion.

Notifications

You must be signed in to change no­ti­fi­ca­tion set­tings

You can’t per­form that ac­tion at this time.

I re­cently watched a video that put a name on some­thing I’d been feel­ing. The au­thor splits an LLM’s con­text win­dow into two zones. There’s the smart zone, where the model is sharp, and the dumb zone, where at­ten­tion drops off and the model starts for­get­ting what you told it five min­utes ago. The cut­off sits some­where around 100k to­kens. It does­n’t mat­ter how big the ad­ver­tised con­text win­dow is.

This mat­ters be­cause cod­ing agents will hap­pily walk you straight into the dumb zone. A mod­ern agent burns through to­kens fast. A few file reads, a long de­bug ses­sion, a sprawl­ing test run, and you’re at 100k be­fore lunch. Meanwhile ven­dors keep ad­ver­tis­ing win­dows of 200k, 1M, even 2M, as if those num­bers rep­re­sented a us­able work­ing set. They don’t. Studies like RULER and Chroma’s re­port on con­text rot show that ef­fec­tive con­text is a frac­tion of the ad­ver­tised num­ber, and that per­for­mance de­grades grad­u­ally as you fill the win­dow.

Large con­text win­dows are mostly a mar­ket­ing num­ber. The ar­chi­tec­tures be­hind them work, but they pa­per over a prob­lem the un­der­ly­ing at­ten­tion mech­a­nism does­n’t re­ally solve. The num­ber on the box gets big­ger every re­lease. The us­able part does­n’t keep up.

Modern agents are get­ting smart about this. Tools like Claude Code now auto-com­pact: when the ses­sion gets long, the agent sum­ma­rizes the his­tory and starts fresh. That helps. But auto-com­paction kicks in af­ter you’ve al­ready spent time in the dumb zone, and the sum­mary is it­self pro­duced by a model that’s al­ready de­graded. Better than noth­ing, but I’d rather avoid the sit­u­a­tion al­to­gether.

What I do is open a new ses­sion and pass it a spec I wrote my­self. That’s a much higher sig­nal hand­off than any au­to­mated sum­mary, be­cause I get to de­cide what mat­ters go­ing for­ward. It’s the bread­crumb ap­proach ap­plied to agents. Leave an ar­ti­fact that the next ses­sion, or the next per­son, can pick up cleanly.

You can take this fur­ther. Projects like obra/​su­per­pow­ers and mattpocock/​skills struc­ture en­tire agent work­flows around small, named ar­ti­facts. PRDs, plans, skills, sub-agent hand­offs. Each one is a way to keep the work­ing ses­sion in the smart zone by de­lib­er­ately mov­ing in­for­ma­tion out of the ses­sion into some­thing the next ses­sion can read.

So I treat my con­text win­dow like a bud­get. I as­sume only the first chunk is re­ally work­ing for me, and every­thing I can move out of the live ses­sion and into a writ­ten ar­ti­fact is one less thing for at­ten­tion to fight over.

Continue Reading

* 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