Linus Torvalds använder Claude Code för Linux-patchar

Vad den här videon täcker

• Källan är experimentellt grenarbete, med en "commit" lördag den 10 oktober och en Phoronix-rapport publicerad söndag kväll i EDT, redan måndag i GMT+7. De valda källorna fastställer inte en slutförd "mainline merge" eller utgivning.
• Små läsningar av samma cachade fil kan konkurrera om en delad folio-referensräknare. Förslaget tillåter kopiering under RCU-läs-sidigt skydd samtidigt som slutlig minnesåteranvändning skjuts upp till en "grace period".
• Linus åtta-trådade, sexton-bytes delade sidtest rapporterar 2937–2975 "baseline" kärncykler per läsning och 725–726 med serien, ungefär en fjärdedel av kostnaden. Det är ett författarkört bärbar mikrobänktest med "mitigations" och "hardened usercopy" inaktiverat, inte ett helsystemsprestandaresultat.
• Källan rapporterar också en regression för saknad destinationssida och olöst allocator-redovisning för minne som väntar på att återanvändas. Bredare maskiner och flera felsöknings-/testkonfigurationer är fortfarande otestade.
• Karpathy tillskriver olika AI-upplevelser till tillgång, ambitiösa problem och verifierbara uppgifter. Hans antal professionella användare är uttryckligen "napkin math"; ingen undersökning följer inlägget.
• Cendyne beskriver en icke namngiven arbetsgivare som får förtroende att glida mot M&A med billigare AI-assistans. Detta är en förstahandsberättelse och dess författares tolkning, inte ett ekonomiskt omfattande jobbantal eller bevis på motsvarande ingenjörskunskap.
• Ett användbart verktyg, en säker patch och ett förnuftigt personalbeslut kräver var och en sina egna bevis och en ansvarig ägare.

Översatt transkription

Översatt från den ursprungliga engelska berättelsen. Tillgängligt ljud och undertexter styrs av YouTube.

Skulle Linus lita på en kodningsbot?

0:00 Du skulle förvänta dig att Linus Torvalds skulle få en kodningsbot att gråta under granskning. Han använder Claude Code för Linux-patchar, och till och med det första utkastet till följebrevet. I den här videon, varför kostar små läsningar så mycket? Och vems jobb förändras? Håll ett öga på vad som händer med minnet efter läsningen. Det är dit denna hastighetsökning skickar räkningen. Det är måndag den tolfte oktober, och detta är The Daily Diff. Claude Code är Anthropics kodningsassistent.

0:23 Den kan läsa ett projekt, redigera filer och köra kommandon. Linus dirigerar den inom Linux minneshantering, där läsning av data som redan finns i minnet fortfarande kan få processorkärnor att slåss om bokföring. Phoronix upptäckte grenen söndag kväll i Amerika, redan måndag här. Commiten är daterad lördag. Detta är experimentellt arbete, med åtta patchar och en begäran om granskning. Din bärbara dator har inte i hemlighet laddat ner en artificiell Linus.

Varför kan läsning av minne orsaka en trafikstockning?

0:45 Flera trådar läser samma cachade fil. Varje läsning tar en referens till minnet, sedan släpper den den efteråt. Referensräknaren skrivs två gånger, så kärnor som utför oskyldiga små läsningar konkurrerar om bokföring. Biblioteket har åtta läsare och ett utcheckningsblad. Hans förslag försenar återvinningen av minnet med hjälp av en RCU "grace period" för läskopiering. Läsare kan kopiera cachad data utan att ta den referensen. När en sida tas bort måste dess minne vänta innan återanvändning.

1:09 Hastighetsökningen kommer från att ändra livstidsreglerna kring data. Linus tillskriver Claude Code för koden, testprogrammen och granskningen bakom hans lista över problem. Den utarbetade den förklarande texten under hans ledning. Mätningarna kördes på hans maskin. Till och med roboten måste ta med kvitton till denna granskning. Rubrikresultatet använder åtta trådar som läser sexton byte från en sida.

Vad mäter bärbara datorns "benchmark" egentligen?

1:28 Tänk små upprepade läsningar av samma fil. Han jämför processorcykler per läsning eftersom hans bärbara dator "throttlar" när den är varm. Ett "benchmark" med sin egen väderprognos. Baslinjen kostar ungefär tre tusen cykler per läsning. Med "patcharna" är det runt sjuhundratjugofem. Det är ungefär en fjärdedel av processorkostnaden i detta test. Hela din Linux-maskin har fått noll löften om att bli fyra gånger snabbare. Hans följebrev placerar de besvärliga delarna bredvid de spännande.

1:53 Säkerhetsåtgärder och härdad "usercopy" var avstängda. Han listar saknade tester, inklusive andra maskiner och minnesfelsökningsverktyg. Att läsa fotnoterna är nu en konkurrensfördel, vilket känns som en bugg i mänskligheten. Det finns en regression när destinationsanvändarsidan saknas.

Vilka läsningar blir långsammare?

2:07 Den lilla läsningen blir dyrare eftersom den snabba vägen misslyckas innan den gamla vägen hanterar "page fault". Förslaget accelererar en väg samtidigt som det lägger till arbete till en annan. Båda hör hemma i granskning. Behandla detta som ett ingenjörsexperiment med en känd flaskhals och mätningar med begränsningar. Granskare får något konkret att utmana. En assistent som producerar "patchar" lämnar någon ansvarig för att bevisa de farliga delarna säkra.

Varför ser folk olika AI-kapaciteter?

2:30 Under tiden säger Andrej Karpathy att vår förståelse för AI-kapacitet drar isär. Hans färska inlägg återbesöker en observation från april. Han beskriver en tratt, från människor som knappt använder språkmodeller till professionella som dirigerar kraftfulla kodningsagenter. Samma ord, AI, olika arbetsdag. Hans "napkin math" placerar ungefär tjugo miljoner människor i professionell "frontier model" användning för matematik och kod. Det är en uppskattning, utan någon undersökning.

2:52 Han betonar tillgång, ambitiösa problem och verifierbara uppgifter. En chatbotkonversation och ett övervakat kärnexperiment tränar olika muskler. Någon ser en bot klanta till en begäran medan en annan person "shippar" en användbar "patch". Populationsuppskattningar är farligt lätta att upprepa som forskning. Behåll uppskattningsetiketten fäst innan grafen börjar bära en laboratorierock. Fråga vad systemet kunde göra, hur resultatet kontrollerades och vem som ägde resultatet. Dessa frågor reser bättre än skärmdumpar av mirakulösa svar.

Hur kan AI förändra ett jobb innan det ersätter dess färdigheter?

3:21 Sedan publicerade Cendyne en mindre bekväm berättelse med titeln "Fable took my jorb." Författaren säger att de var den sista ingenjören på ett företag, och ledningen trodde att billigare AI-assistans kunde låta det glida mot en fusion eller förvärv. Ledningen kan ändra utgifterna innan en modell matchar en erfaren ingenjörs bedömning. Cendyne hävdar att smak och framförhållning fortfarande saknas, medan marknadsföring tillhandahåller förtroende.

3:42 Ett lönebeslut kan fattas innan det tekniska argumentet är avgjort. Inlägget beskriver rädsla efter uppsägningen och säger att författaren har hittat något annat. Det är en person som hanterar konsekvenser. Slutklämmen tillhör kalkylbladet som fattar beslutet. Att kalla det effektivitet ger redovisningen en generös prestationsbedömning. Att bevisa att ett verktyg är användbart och att bevisa att en bemanningsplan är förnuftig är separata jobb. Patchen har en testbar arbetsbelastning. Arbetsgivarens satsning involverar produktägarskap och framtida fel.

4:09 Ett godkänt mikrobänktest kan inte skriva under supportavtalet. Vi har en utvecklares berättelse med en icke namngiven arbetsgivare. Den ger ett perspektiv, och inget ekonomiskt omfattande jobbantal eller oberoende bedömning av det företagets behov. Håll omfattningen kopplad när du delar berättelsen. Den gemensamma variabeln är ansvar. Linus leder arbetet. Karpathy beskriver ojämn tillgång och uppgifter.

4:29 Cendyne beskriver en ledningssatsning. Någon äger konsekvenserna i varje version.

Vart skickar hastighetsökningen räkningen?

4:34 Och minnesräkningen? Borttagna sidor väntar innan återanvändning, och allokatorn kan inte korrekt se det väntande minnet. Linus listar detta som olöst även med hans mildrande "patchar". Snabbare läsningar ger ett annat subsystem ett svårare redovisningsproblem. Bokföringen hittar ett nytt skrivbord. Det är en fotnot värd att behålla. Om du hellre vill läsa detta än höra mig säga det, landar "diffen" i din inkorg

4:53 varje morgon, gratis på thedailydiff.dev, länk nedan.

Skulle jag "shippa" dessa "patchar"?

4:56 Så dagens dom, KRÄVER GRANSKNING. Jag skulle behålla assistenten i arbetsflödet och kräva bredare testning innan dessa livstidsändringar "shippas". Ansvaret ligger kvar hos ingenjören. Och det är "diffen" för idag. Jag är Niko från Axrisi. Merge ansvarsfullt.

Källor

1. Read from the page cache without folio references — cover letter and testsLinus Torvalds / kernel.org
2. Experimental noref-filemap-read-with-llm branchLinus Torvalds / kernel.org
3. Linus Torvalds Working On A Hefty Linux Kernel Improvement With Claude CodePhoronix / Michael Larabel
4. Claude Code overviewAnthropic
5. Capability-understanding gap and napkin estimatesAndrej Karpathy / X
6. Fable took my jorbCendyne
7. Discussion of Linus's Claude Code branchHacker News
8. Discussion of Karpathy's capability-gap postHacker News
9. Discussion of Cendyne's accountHacker News