10 interesting stories served every morning and every evening.

Firewood Splitting Simulator

screen.toys

How to Earn a Billion Dollars

paulgraham.com

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

No, everyone is not using AI for everything.

gabrielweinberg.com

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 AIs 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

Honda Civics and the Evil Valet

juniperspring.org

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. ↩︎

GitHub - tamnd/kage: Shadow any website for offline viewing, with the JavaScript stripped out

github.com

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 Online ERD Generator from SQL

sqltoerdiagram.com

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.

Rio-3.5-Open-397B ≈ 0.6 x Nex-N2_pro + 0.4 x Qwen · Issue #4 · nex-agi/Nex-N2

github.com

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.

Don't trust large context windows

garrit.xyz

I re­cently watched a video that put a name on some­thing I’d been feel­ing. The au­thor splits an LLMs 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

lore.kernel.org

* 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

Just a moment...

blog.tacoda.dev

To add this web app to your iOS home screen tap the share button and select "Add to the Home Screen".

10HN is also available as an iOS App

If you visit 10HN only rarely, check out the the best articles from the past week.

Visit pancik.com for more.