• GCC säger nej till betydande kod som skapats av AI

    Utvecklare får använda AI för att diskutera idéer, förstå källkod och göra efterforskningar. Men kod som helt eller delvis bygger på material från språkmodeller som ChatGPT, Gemini eller GitHub Copilot ska normalt inte tas emot som bidrag till GNU Compiler Collection.

    GCC Steering Committee, den grupp som leder utvecklingen av GNU Compiler Collection, har antagit en ny policy för användningen av artificiell intelligens och stora språkmodeller.

    GNU Compiler Collection, vanligtvis förkortat GCC, är en samling kompilatorer för bland annat programmeringsspråken C, C++, Fortran och Ada. Programvaran är en central del av många Linuxsystem och används för att omvandla programmerares källkod till körbara program.

    Den nya policyn innebär att GCC tills vidare kommer att avvisa bidrag som innehåller upphovsrättsligt betydande material som har skapats av en språkmodell.

    Det räcker inte att redigera AI-koden

    Reglerna omfattar inte bara kod som kopierats direkt från exempelvis ChatGPT eller GitHub Copilot. Även kod som senare har skrivits om, rättats eller förbättrats av en människa kan omfattas.

    Det avgörande är om den färdiga koden fortfarande bygger på material som ursprungligen skapades av en språkmodell.

    En utvecklare kan alltså inte låta en AI skapa en större funktion, städa upp koden manuellt och därefter behandla resultatet som ett helt självständigt arbete.

    När ett kodbidrag väl har sitt ursprung i AI-genererat material fortsätter det, enligt policyn, att räknas som härlett från detta material.

    AI får fortfarande användas som hjälpmedel

    Policyn innebär inte ett fullständigt förbud mot AI-verktyg.

    Utvecklare får fortfarande använda språkmodeller för att:

    • diskutera programmeringsidéer,
    • förstå befintlig källkod,
    • lära sig mer om ett obekant teknikområde,
    • undersöka möjliga lösningar,
    • genomföra allmän efterforskning.

    Begränsningen gäller när upphovsrättsligt betydande material från språkmodellen faktiskt hamnar i den kod som skickas in till GCC-projektet.

    En utvecklare kan exempelvis fråga en språkmodell hur en viss kompilatorteknik fungerar. Därefter kan utvecklaren själv konstruera och skriva en egen lösning. Det skiljer sig från att låta språkmodellen skapa själva implementationen och sedan använda den som grund för bidraget.

    Vad betyder upphovsrättsligt betydande?

    All kod är inte automatiskt tillräckligt originell eller omfattande för att skyddas av upphovsrätten.

    En mycket enkel ändring, som att rätta ett stavfel, byta ett variabelnamn eller justera en uppenbar felskrivning, kan vara juridiskt obetydlig. Mer omfattande funktioner, algoritmer och implementationer kan däremot betraktas som upphovsrättsligt betydande.

    Policyn innehåller därför vissa begränsade undantag.

    GCC:s ansvariga utvecklare kan acceptera triviala eller juridiskt obetydliga ändringar som har skapats med hjälp av en språkmodell. Ändringen måste fortfarande uppfylla projektets vanliga kvalitetskrav, och användningen av AI ska redovisas tydligt.

    Särskilda regler för testprogram

    AI-genererade testfall kan också behandlas annorlunda än kod som blir en permanent del av GCC.

    Ett testfall består ofta av ett mycket litet program som används för att återskapa ett fel eller kontrollera att kompilatorn beter sig på rätt sätt. Sådan kod är normalt inte en del av kompilatorns egen implementation.

    Därför kan även upphovsrättsligt betydande AI-genererade testfall i vissa situationer accepteras.

    Upphovsrätten är den stora frågan

    Bakgrunden till försiktigheten är osäkerheten kring hur språkmodeller har tränats och vilka rättigheter som gäller för materialet de producerar.

    En språkmodell kan ha tränats på stora mängder offentligt tillgänglig källkod. Det är inte alltid möjligt att avgöra om ett kodförslag är en helt ny konstruktion eller om det ligger nära kod som redan har skrivits av någon annan.

    För ett stort projekt som GCC kan detta skapa både juridiska och praktiska problem. Projektet måste kunna veta att den kod som tas emot får distribueras under GCC:s licens och att bidragsgivaren har rätt att lämna över den.

    En försiktighetsprincip för fri programvara

    Den nya policyn visar att AI kan användas som ett verktyg under utvecklingsarbetet, men att ansvaret fortfarande ligger hos människan.

    För GCC räcker det inte att en utvecklare förstår, granskar eller förbättrar den kod som en språkmodell har skapat. Om ett betydande kodbidrag bygger på AI-genererat material kan det fortfarande avvisas.

    Budskapet till utvecklare är därför tydligt: använd gärna AI för att lära, resonera och undersöka – men skriv den kod som ska skickas in till GCC själv.

    > FAKTA: GCC OCH AI-GENERERAD KOD

    GCC är en samling kompilatorer för bland annat C, C++, Fortran och Ada. GCC används i många Linuxdistributioner och andra fria operativsystem.

    GCC-projektets nya policy innebär att upphovsrättsligt betydande kod som har skapats av en språkmodell normalt inte accepteras som bidrag.

    Policyn gäller även kod som först har skapats av exempelvis ChatGPT, Gemini eller GitHub Copilot och därefter har skrivits om eller förbättrats av en människa.

    AI får fortfarande användas för att diskutera idéer, förstå befintlig kod, göra efterforskningar och lära sig mer om ett teknikområde.

    Triviala ändringar och vissa testfall kan i särskilda fall accepteras. Användningen av AI måste då redovisas tydligt.

  • GNU Binutils 2.47 gör utvecklarnas verktygslåda snabbare och mer flexibel

    GNU-projektet har släppt Binutils 2.47, en ny version av den viktiga verktygssamling som används för att bygga och analysera program i Linux. Uppdateringen ger bland annat bättre stöd för RISC-V, nya möjligheter vid felsökning och snabbare länkning av stora program.

    GNU-projektet har släppt GNU Binutils 2.47, en ny version av den verktygssamling som används för att bygga, länka och undersöka program på Linux och andra Unixliknande operativsystem.

    Binutils arbetar oftast i bakgrunden och märks därför sällan av vanliga datoranvändare. För programmerare, systemutvecklare och skapare av Linuxdistributioner är verktygen däremot mycket viktiga. De används tillsammans med bland annat kompilatorn GCC, standardbiblioteket glibc och felsökaren GDB.

    Vad är GNU Binutils?

    När en programmerare skriver ett program måste källkoden gå igenom flera steg innan den kan köras av datorn.

    Först översätts programkoden till maskinkod. Därefter måste olika delar av programmet kopplas samman till en färdig körbar fil. Binutils innehåller flera av de verktyg som behövs under denna process.

    Bland de mest kända verktygen finns:

    • as – omvandlar assemblerkod till objektfiler.
    • ld – länkar samman objektfiler och bibliotek till färdiga program.
    • objdump – visar information om innehållet i körbara filer och objektfiler.
    • readelf – granskar ELF-filer, som är det vanligaste formatet för körbara program i Linux.
    • ar – skapar och hanterar statiska programbibliotek.

    De flesta utvecklare använder inte alla dessa kommandon direkt. I stället anropas de automatiskt av kompilatorer och byggsystem.

    Enklare felsökning av program

    Både objdump och readelf har fått det nya alternativet:

    --debug-dir=DIR

    Det gör det möjligt att ange en särskild katalog där verktygen ska leta efter separata filer med felsökningsinformation.

    Felsökningsinformation innehåller exempelvis funktionsnamn, variabelnamn och kopplingar mellan maskinkod och programmets ursprungliga källkod. Informationen är mycket användbar när ett program kraschar eller beter sig fel.

    I många Linuxdistributioner lagras felsökningsinformationen separat från själva programmet. Det gör programfilerna mindre, samtidigt som utvecklare fortfarande kan installera den mer detaljerade informationen när den behövs.

    Med det nya alternativet blir det enklare att undersöka program när felsökningsfilerna ligger på en annan plats än normalt.

    Objdump kan visa globala variabler

    Verktyget objdump har även fått alternativet:

    --map-global-vars

    Det kan användas för att visa var globala variabler finns i en objektfil och vilken typ av information de innehåller.

    En global variabel är en variabel som kan användas av flera delar av ett program. Sådana variabler kan ibland göra program svårare att felsöka, eftersom innehållet kan ändras från många olika platser.

    Den nya funktionen kan därför hjälpa utvecklare att förstå hur ett program använder sitt minne och hur olika variabler är placerade i den färdiga programfilen.

    Objektfiler kan behandlas som ett bibliotek

    Länkaren har fått stöd för alternativen:

    --start-lib

    --end-lib

    De gör det möjligt att behandla en grupp objektfiler ungefär som om de låg i ett statiskt bibliotek.

    Ett statiskt bibliotek är normalt en samling färdigkompilerade objektfiler som har packats ihop i en arkivfil. Med de nya alternativen behöver utvecklaren inte alltid skapa en sådan arkivfil först.

    Det kan förenkla byggprocessen, särskilt i stora projekt där många mindre objektfiler ska kopplas samman.

    Länkaren tar då endast med de objektfiler som verkligen behövs, på ungefär samma sätt som när ett vanligt statiskt bibliotek används.

    Snabbare länkning kan ge större programfiler

    BFD-länkaren stöder nu optimeringsnivån:

    -O 0

    När denna nivå används slutar länkaren att slå samman innehållet i vissa sektioner som innehåller identiska eller liknande data.

    Normalt försöker länkaren minska storleken på det färdiga programmet genom att kombinera exempelvis identiska textsträngar eller annan återkommande information.

    Det arbetet kan dock ta tid, särskilt när mycket stora program ska byggas.

    Genom att använda -O 0 kan länkningen därför gå betydligt snabbare. Nackdelen är att det färdiga programmet kan bli större eftersom information som hade kunnat delas i stället sparas flera gånger.

    Det blir alltså en avvägning mellan byggtid och filstorlek.

    Funktionen kan vara särskilt användbar under utveckling, när ett program kompileras och länkas om många gånger. Inför en slutlig utgåva kan utvecklaren sedan välja en högre optimeringsnivå för att skapa en mindre programfil.

    Förbättrat stöd för RISC-V

    GNU Binutils 2.47 utökar även stödet för processorarkitekturen RISC-V.

    RISC-V är en öppen processorarkitektur. Till skillnad från flera traditionella processorplattformar kan den användas och vidareutvecklas utan att tillverkare behöver betala licensavgifter för själva instruktionsuppsättningen.

    Arkitekturen används bland annat i mikrokontroller, inbyggda system, forskningsprojekt, servrar och experimentella persondatorer.

    Den nya versionen av Binutils innehåller stöd för flera ytterligare RISC-V-utökningar, däribland:

    • zalasr 1.0
    • svrsw60t59b 1.0
    • zvabd 1.0
    • smpmpmt 1.0

    Stöd har också lagts till för flera instruktioner som utför vektoriella punktprodukter.

    Vektorberäkningar gör det möjligt för processorn att bearbeta flera tal samtidigt i stället för ett tal i taget. Det är särskilt användbart inom områden som bildbehandling, artificiell intelligens, vetenskapliga beräkningar och signalbehandling.

    Punktprodukter är en vanlig matematisk operation inom exempelvis maskininlärning. Bättre stöd för sådana instruktioner gör det möjligt för utvecklare att skapa program som mer effektivt utnyttjar moderna RISC-V-processorer.

    Äldre 32-bitars S/390 fasas ut

    Stödet för den 32-bitars IBM S/390-plattformen har nu markerats som föråldrat.

    Det innebär inte nödvändigtvis att stödet försvinner omedelbart, men det är en tydlig signal om att det kan tas bort i en framtida version.

    Den modernare 64-bitarsarkitekturen S/390x påverkas inte. Den fortsätter att stödjas och underhållas.

    S/390 och S/390x används främst i IBM:s stordatorsystem. Att den äldre 32-bitarsversionen fasas ut är därför ett naturligt steg när allt fler system använder 64-bitarsprocessorer och modernare programvara.

    En viktig uppdatering som arbetar i bakgrunden

    GNU Binutils 2.47 innehåller inga funktioner som vanliga datoranvändare kommer att se direkt på skrivbordet. Uppdateringen är ändå betydelsefull.

    Nästan alla program i en Linuxdistribution har vid något tillfälle passerat genom en assembler, länkare eller något annat verktyg från Binutils.

    Förbättringarna kan ge utvecklare snabbare byggprocesser, bättre möjligheter att undersöka programfiler och utökat stöd för nya processorinstruktioner.

    GNU Binutils 2.47 finns tillgänglig som källkod från GNU-projektets servrar. Användare av Linuxdistributioner med löpande uppdateringar kan räkna med att versionen dyker upp i pakethanteraren när distributionernas utvecklare har hunnit testa och paketera den.

    https://lists.gnu.org/archive/html/info-gnu/2026-07/msg00006.html

    Fakta: GNU Binutils 2.47

    • Utvecklare: GNU-projektet
    • ”`
    • Typ av programvara: Verktyg för assemblering, länkning och analys av binära filer
    • Viktiga verktyg: as, ld, objdump, readelf och ar
    • Nyheter: Förbättrad felsökning, nya länkaralternativ och snabbare länkning
    • Processorstöd: Utökat stöd för flera nya RISC-V-instruktioner
    • Utfasning: Stödet för 32-bitars IBM S/390 har markerats som föråldrat
    • Licens: Fri programvara inom GNU-projektet
    • ”`
  • Codeberg säger nej till projekt som huvudsakligen skapats av AI

    Den ideella kodplattformen Codeberg förbjuder nu projekt som till största delen består av AI-genererad kod. Beslutet grundas på osäker upphovsrätt, säkerhetsrisker och svårigheten att avgöra vem som egentligen ansvarar för programvaran.

    Den ideella kodplattformen Codeberg inför nya regler för programvara som har skapats med hjälp av generativ artificiell intelligens. Projekt där merparten av källkoden har skrivits av AI-verktyg får inte längre lagras på plattformen.

    Codeberg är en tjänst för fri programvara och projekt med öppen källkod. Plattformen drivs utan vinstsyfte och bygger på programvaran Forgejo, som är ett öppet alternativ till bland annat GitHub.

    Den nya begränsningen har lagts till i Codebergs användarvillkor efter att frågan diskuterats och godkänts genom organisationens gemensamma beslutsprocess. Regeln omfattar kod som huvudsakligen har skapats av generativa AI-tjänster, exempelvis Claude och OpenAI Codex.

    Oklart vem som äger AI-skapad kod

    Ett av Codebergs viktigaste argument handlar om upphovsrätt.

    Generativa AI-system tränas på mycket stora mängder text och programkod. I många fall är det svårt att veta exakt vilket material som har använts vid träningen och vilka licenser som gäller för det ursprungliga materialet.

    Det skapar flera obesvarade frågor. Kan AI-genererad kod innehålla delar som liknar upphovsrättsskyddad kod? Vem bär ansvaret om sådan kod publiceras? Kan den som använder AI-verktyget verkligen ge programmet en giltig licens?

    Codeberg anser att den juridiska situationen fortfarande är för osäker för att plattformen ska tillåta projekt som till största delen består av AI-genererat innehåll.

    Risk för skadlig och osäker kod

    Codeberg lyfter även fram säkerheten.

    Ett generativt AI-system förstår inte programkod på samma sätt som en erfaren utvecklare. Systemet skapar i stället svar genom att beräkna vilka ord, symboler och kodrader som sannolikt bör följa efter varandra.

    Resultatet kan se korrekt och professionellt ut, trots att programmet innehåller allvarliga fel. Det kan exempelvis handla om säkerhetshål, felaktig hantering av lösenord eller kod som använder gamla och osäkra funktioner.

    AI-verktyg kan dessutom producera skadlig kod, antingen avsiktligt efter en instruktion eller oavsiktligt genom ett felaktigt förslag. Enligt Codeberg har dagens AI-tjänster inte tillräckligt starka skydd för att garantera att större automatiskt skapade projekt är säkra.

    I användarvillkoren skriver Codeberg att användare inte får dela projekt som huvudsakligen består av kod skriven av generativa AI-verktyg. Som skäl anges både den oklara upphovsrätten och risken för skadligt innehåll.

    All användning av AI förbjuds inte

    Den nya regeln innebär inte att utvecklare helt måste avstå från AI.

    Det är fortfarande tillåtet att använda AI som ett begränsat hjälpmedel. En programmerare kan exempelvis be ett AI-system att förklara ett felmeddelande, föreslå hur en enskild funktion kan förbättras eller hjälpa till att skriva dokumentation.

    Begränsningen gäller projekt där AI har producerat huvuddelen av själva källkoden.

    Gränsen är dock inte särskilt tydlig. Codeberg har inte angett någon exakt procentsats för hur stor del av ett projekt som får vara AI-genererad. Det framgår inte heller hur kod som har skapats gemensamt av människor och AI ska bedömas.

    Mänsklig granskning verkar inte räcka

    Reglernas formulering innehåller inget tydligt undantag för kod som först har skapats av AI och därefter granskats av en människa.

    Det innebär att ett projekt kan omfattas av förbudet även om utvecklaren har läst, testat och förstått varje kodrad. Den avgörande frågan verkar vara vem eller vad som ursprungligen skapade huvuddelen av koden.

    Detta kan bli svårt att hantera i praktiken. Modern programutveckling sker ofta i flera steg. En utvecklare kan låta AI skapa ett första förslag, ändra stora delar av det och sedan bygga vidare manuellt.

    När är koden då fortfarande AI-genererad? Codebergs regler ger ännu inget tydligt svar.

    Svårt att upptäcka AI-skriven kod

    Det finns i dag ingen helt pålitlig metod för att avgöra om ett program har skrivits av en människa eller av ett AI-system.

    Till skillnad från bilder och vanlig text innehåller programkod ofta fasta strukturer och återkommande lösningar. Två utvecklare kan därför skriva mycket liknande kod utan att någon har kopierat den andra.

    AI-genererad kod kan också redigeras, döpas om och blandas med mänskligt skriven kod. Efter tillräckligt många ändringar kan det vara nästan omöjligt att fastställa hur den första versionen skapades.

    Codeberg har ännu inte förklarat hur plattformen ska upptäcka regelbrott eller vilken typ av bevis som kommer att krävas.

    Det är därför möjligt att reglerna främst kommer att användas mot projekt som öppet beskriver sig som helt eller nästan helt AI-genererade.

    En annan väg än GitHub

    Codebergs beslut går i motsatt riktning jämfört med utvecklingen hos den kommersiella konkurrenten GitHub.

    GitHub har under de senaste åren byggt in allt fler AI-funktioner för programmerare. AI-assistenter kan föreslå kod, besvara frågor om projekt och i vissa fall arbeta mer självständigt med programmeringsuppgifter.

    Medan GitHub ser generativ AI som en central del av framtidens programutveckling väljer Codeberg alltså att dra en tydlig gräns.

    Skillnaden speglar två olika synsätt. Det ena betonar snabbare utveckling och automatisering. Det andra lägger större vikt vid upphovsrätt, säkerhet, mänsklig kontroll och möjligheten att förstå hur ett program har skapats.

    Kan påverka fler plattformar

    Codebergs beslut är ett av de tydligaste exemplen hittills på en kodplattform som begränsar AI-genererad programvara i sina användarvillkor.

    Plattformen nöjer sig inte med att rekommendera försiktighet eller kräva att AI-användning redovisas. Projekt som huvudsakligen har skapats av generativ AI måste i stället publiceras någon annanstans.

    Det återstår att se hur reglerna kommer att fungera i praktiken. Codeberg behöver bland annat avgöra vad ordet ”huvudsakligen” betyder, hur misstänkta projekt ska granskas och hur utvecklare ska kunna försvara sig mot felaktiga anklagelser.

    Beslutet visar samtidigt att frågan om AI-genererad kod inte bara är teknisk. Den handlar även om juridiskt ansvar, säkerhet, förtroende och vilken roll människor ska ha i framtidens programutveckling.

    https://codeberg.org/Codeberg/org/pulls/1253/commits/96fac426a32d1ba91ff879366d59bf1af54080c2

    Fakta: Codebergs nya AI-regel

    Plattform: Codeberg

    Inriktning: Ideell Git-plattform för fri programvara och projekt med öppen källkod.

    Ny regel: Projekt som huvudsakligen består av kod skapad med generativa AI-verktyg får inte längre publiceras på plattformen.

    Exempel på AI-verktyg: Claude och OpenAI Codex.

    Codebergs motivering: AI-genererad kod kan ha oklar upphovsrättslig status och innehålla säkerhetsproblem eller skadlig kod.

    Begränsad AI-hjälp: Det är fortfarande tillåtet att använda AI som hjälpmedel, så länge AI inte har skapat huvuddelen av projektets kod.

    Oklart: Codeberg har ännu inte förklarat exakt hur AI-genererad kod ska identifieras eller hur ordet ”huvudsakligen” ska bedömas.

  • Perl 5.44 släppt – får namngivna parametrar, bättre prestanda och Unicode 17

    Perl 5.44 har släppts med experimentellt stöd för namngivna parametrar, förbättrad prestanda och stöd för Unicode 17. Den nya versionen innehåller även flera säkerhetsrättningar, strängare regler för Unicode-tecken och uppdateringar av språkets reguljära uttryck.

    Programmeringsspråket Perl har fått en ny stabil version. Perl 5.44 innehåller bland annat experimentellt stöd för namngivna parametrar, bättre Unicode-hantering, flera prestandaförbättringar och rättningar av tre säkerhetsproblem.

    Perl har funnits sedan slutet av 1980-talet och används fortfarande för bland annat systemadministration, textbearbetning, webbapplikationer och automatisering. Språket är särskilt känt för sina kraftfulla funktioner för att söka, tolka och förändra text.

    Den nya versionen är den första stabila utgåvan i Perl 5.44-serien och kommer ungefär ett år efter Perl 5.42.

    Funktioner kan få namngivna parametrar

    En av de största nyheterna är experimentellt stöd för namngivna parametrar i funktioners signaturer.

    Traditionellt skickas argument till Perl-funktioner i en bestämd ordning. Funktionen måste alltså veta att det första värdet betyder en viss sak och att det andra värdet betyder något annat.

    Med namngivna parametrar kan anroparen i stället ange vad varje värde representerar. Det kan göra koden tydligare, särskilt i funktioner som tar emot många argument.

    I stället för att bara skicka flera värden efter varandra kan programmeraren exempelvis ange namn som name, age eller address.

    Funktionen är fortfarande experimentell. Det innebär att syntaxen och beteendet kan förändras i framtida Perl-versioner.

    Flera variabler i samma loop

    Perl 5.44 kombinerar även två andra experimentella funktioner: loopar med flera variabler och referensalias.

    Det gör det möjligt att behandla flera relaterade värden under varje varv i en loop. En variabel kan samtidigt fungera som ett direkt alias till den ursprungliga informationen.

    Det kan vara praktiskt när ett program exempelvis går igenom par bestående av en nyckel och en arrayreferens. Ändringar som görs genom aliaset kan då påverka den ursprungliga datastrukturen direkt.

    De funktioner som krävs, refaliasing och declared_refs, är fortfarande experimentella och måste aktiveras uttryckligen.

    Tydligare reguljära uttryck

    Reguljära uttryck är mönster som används för att söka efter eller bearbeta text. De är en central del av Perl och används ofta för exempelvis loggfiler, konfigurationsfiler och automatiserad textanalys.

    Perl har sedan tidigare modifieraren /xx, som gör det möjligt att formatera reguljära uttryck över flera rader och lägga till kommentarer.

    I Perl 5.44 har denna funktion byggts ut genom det experimentella tillägget enhanced_xx. Teckenklasser inom hakparenteser kan nu delas upp på flera rader och innehålla kommentarer.

    Perl kan också varna när delar av ett reguljärt uttryck verkar ha tolkats som en kommentar av misstag.

    Samtidigt införs strängare regler. Ett #-tecken som inte föregås av ett omvänt snedstreck, eller radbrytningar som skrivs direkt inne i en teckenklass, betraktas nu som föråldrad syntax.

    Äldre uttryck fortsätter tills vidare att fungera, men ger varningar. De bör uppdateras genom att exempelvis skriva \# eller använda en särskild sekvens som \n.

    Stöd för Unicode 17

    Perl 5.44 uppdaterar sitt stöd till Unicode 17.0.

    Unicode är den internationella standard som gör det möjligt för datorer att hantera bokstäver, symboler och skriftsystem från stora delar av världen. Den omfattar allt från svenska tecken till arabiska, kinesiska, matematiska symboler och emoji.

    Den nya Perl-versionen följer Unicode-reglerna mer strikt när tecken används i namn på variabler, funktioner, paket och namngivna grupper i reguljära uttryck.

    Omkring 160 ovanliga tecken som tidigare accepterades av Perls bredare tolkning av \w får inte längre användas i sådana namn. Anledningen är att de inte uppfyller Unicode-egenskaperna XID_Start och XID_Continue, som definierar vilka tecken som bör få inleda eller fortsätta ett programmeringsnamn.

    För de flesta programmerare får ändringen ingen märkbar effekt. Program som använder mycket ovanliga Unicode-tecken i namn kan däremot behöva ändras före en uppgradering.

    Tre säkerhetsproblem har rättats

    Perl 5.44 innehåller rättningar för tre rapporterade sårbarheter.

    Den första, CVE-2026-8376, berör en felaktig beräkning av buffertstorlek i funktionen Perl_study_chunk. På 32-bitarsystem kunde felet orsaka heltalsöverflöde och leda till att data skrevs utanför det avsedda minnesområdet.

    Den andra sårbarheten, CVE-2026-57432, påverkar hanteringen av mycket stora datastrukturer i funktionerna pack och unpack. Ett extremt stort repetitionsvärde kunde orsaka heltalsöverflöde och därefter buffertöverflöde.

    Det tredje problemet, CVE-2026-13221, finns i reguljära uttrycksmotorns optimering av stora alternativlistor. Reguljära uttryck med fler än ungefär 65 000 alternativa grenar kunde fylla ett 16-bitarsfält och i vissa fall ge felaktiga matchningar.

    Slumptalen får bättre startvärden

    Perl ändrar även hur språkets interna slumptalsgenerator startas.

    På Linux, BSD och macOS försöker Perl nu i första hand använda systemanropet getentropy(). Om det inte är tillgängligt används /dev/urandom. Som sista reserv används ett hashvärde som bygger på programmets interna tillstånd.

    Detta ger bättre och mer oförutsägbara startvärden än tidigare lösningar.

    Perl-utvecklarna betonar dock att funktionen rand fortfarande inte är avsedd för kryptografi, lösenord, säkerhetstokens eller andra säkerhetskritiska ändamål. Sådana program bör använda en särskild kryptografiskt säker slumptalsgenerator.

    Vissa operationer går snabbare

    Perl 5.44 innehåller flera mindre prestandaförbättringar.

    Heltalsaddition, subtraktion och multiplikation kan nu utföras något snabbare på system där kompilatorn har stöd för de optimeringar som behövs.

    Det har även blivit snabbare att skapa hash-tabeller från listor där nycklarna består av konstanta textsträngar som redan är kända när programmet kompileras.

    Behandlingen av funktionssignaturer har också optimerats. Funktioner som använder signaturer får därför något lägre belastning när de anropas.

    Varje enskild förbättring är relativt liten, men tillsammans kan de ge märkbara vinster i större program eller kod som körs mycket ofta.

    Gammalt beteende tas bort

    Perl 5.44 tar även bort ett beteende som varit markerat som föråldrat sedan Perl 5.12.

    Det är inte längre tillåtet att använda goto för att hoppa direkt in i en loop eller ett kodblock från utsidan.

    Sådana hopp kan göra ett programs körning svår att förutsäga eftersom de kringgår den normala vägen in i kodblocket. Förändringen gör språket mer konsekvent och minskar risken för svårfunna fel.

    Perl 5.40 har nått slutet av sin supportperiod

    I samband med att Perl 5.44 släpps avslutas den officiella supporten för Perl 5.40-serien.

    Den som fortfarande använder Perl 5.40 bör därför planera en uppgradering. Äldre Perl-program bör testas noggrant, särskilt om de använder experimentella funktioner, ovanliga Unicode-tecken eller avancerade reguljära uttryck.

    Nästa utvecklingsversion väntas bli Perl 5.45.1. Den kommer att ligga till grund för nästa stabila huvudversion, som enligt planerna ska släppas under första halvåret 2027.

    Perl 5.44 är ingen dramatisk ombyggnad av språket, men versionen moderniserar flera viktiga delar. Namngivna parametrar kan göra funktioner enklare att förstå, Unicode-stödet blir mer korrekt och flera vanliga operationer har effektiviserats.

    Samtidigt visar säkerhetsrättningarna varför det är viktigt att hålla även mogna och väletablerade programmeringsspråk uppdaterade.

    https://www.nntp.perl.org/group/perl.perl5.porters/2026/07/msg271063.html

    $ teknisk_fakta –perl-5.44
    Version: Perl 5.44
    Typ: Stabil produktionsversion
    Licens: Artistic License eller GNU GPL
    Unicode: Unicode 17.0
    Viktig nyhet: Experimentellt stöd för namngivna parametrar i funktionssignaturer
    Reguljära uttryck: Utökat stöd för läsbara uttryck med /xx och enhanced_xx
    Prestanda: Snabbare heltalsoperationer, hash-skapande och behandling av signaturer
    Säkerhet: Tre säkerhetsproblem har rättats
    Slumptal: Förbättrad initiering via getentropy() och /dev/urandom
    Support: Perl 5.40-serien har nått slutet av sin supportperiod
    Webbplats: perl.org
    root@linux:~$ perl -v
  • Linus Torvalds: Från programmerare till utvecklingsledare

    Linus Torvalds skriver numera sällan kod själv och beskriver sin roll som utvecklingsledare. Under Open Source Summit India 2026 berättade han om arbetet bakom Linuxkärnan, synen på AI och Rust samt varför föråldrad teknik ibland måste tas bort.

    Linus Torvalds skriver numera sällan kod själv. I stället leder han utvecklingen av Linuxkärnan genom att granska större förändringar, samordna utvecklare och fatta beslut om projektets inriktning.

    Under Open Source Summit India 2026 berättade han att Git och e-post fortfarande är hans viktigaste verktyg. Arbetet handlar i dag mer om människor, prioriteringar och helhet än om enskilda kodrader.

    Linux utvecklas stegvis, med nya kärnversioner ungefär varannan månad. Torvalds föredrar små förbättringar framför stora och riskfyllda förändringar. Han är särskilt försiktig med sena rättningar, eftersom även mindre ändringar kan skapa nya problem.

    Enligt Torvalds är mänskliga konflikter ofta svårare att lösa än tekniska fel. Kod kan rättas, medan problem med kommunikation och samarbete kan bli betydligt mer komplicerade.

    Han anser också att Linux inte kan stödja all gammal hårdvara för alltid. Teknik som inte längre används måste ibland tas bort för att minska mängden kod som behöver underhållas.

    Rust är enligt Torvalds ett viktigt tillskott, men inget fullständigt skydd mot fel. Språket kan förhindra vissa minnesproblem, men inte logiska misstag. Därför kommer C även fortsättningsvis att spela en viktig roll i Linuxkärnan.

    AI-verktyg används allt mer för att hitta buggar och granska kod. Samtidigt har de skapat felaktiga rapporter och ytliga lösningar. Torvalds anser därför att människor alltid måste kontrollera och ansvara för AI-genererade bidrag.

    Han använder själv AI för mindre experiment och prototyper, men anser ännu inte att tekniken är tillräckligt pålitlig för att självständigt skriva kod till Linuxkärnan.

    Torvalds främsta uppgift är numera inte att programmera, utan att se till att tusentals utvecklares arbete tillsammans leder till en stabil och långsiktigt hållbar Linuxkärna.

    https://www.zdnet.com/article/open-source-summit-linus-torvalds

  • När Linux sätter gränser för vad som är en säkerhetsbugg

    När antalet AI-genererade sårbarhetsrapporter ökar vill Linuxprojektet dra en tydligare gräns mellan vanliga buggar och verkliga säkerhetshål. Linus Torvalds har nu slagit ihop ny dokumentation som förklarar när ett fel i Linuxkärnan ska behandlas som en säkerhetsbugg, hur rapporter bör skickas in och varför spekulativa AI-fynd inte får belasta säkerhetsteamet i onödan. Resultatet är en mer praktisk hotmodell för Linux – och ett försök att skilja allvarliga angreppsvägar från brus, teorier och dåligt testade rapporter.

    Linuxkärnan är ett av världens viktigaste mjukvaruprojekt. Den används i allt från mobiltelefoner och servrar till routrar, bilar, molntjänster och superdatorer. Därför är frågan om säkerhetsbuggar i Linux inte bara en teknisk detalj för utvecklare, utan något som i förlängningen påverkar stora delar av det digitala samhället.

    Nu har Linus Torvalds slagit ihop ny dokumentation i Linuxkärnan som tydligare förklarar vad som faktiskt räknas som en säkerhetsbugg, hur sådana buggar bör rapporteras och hur utvecklare ska hantera rapporter som tagits fram med hjälp av AI. Dokumentationen ingår i ändringarna för docs-7.1-fixes och bygger bland annat på arbete av Willy Tarreau, känd från HAProxy och underhåll av stabila Linuxkärnor.

    Alla buggar är inte säkerhetshål

    En central poäng i den nya dokumentationen är att inte alla fel i kärnan ska betraktas som säkerhetshål. Linuxprojektet vill i första hand att vanliga buggar ska hanteras öppet, på publika e-postlistor och i den normala utvecklingsprocessen.

    Det finns en praktisk orsak till detta. När fler utvecklare kan läsa, granska och testa en lösning ökar chansen att felet rättas på ett bra sätt. Om en bugg däremot behandlas bakom stängda dörrar av en liten grupp personer finns större risk att viktiga användningsfall missas eller att lösningen inte blir tillräckligt testad.

    Den privata säkerhetslistan är därför tänkt för särskilt allvarliga fall: buggar som är lätta att utnyttja, påverkar många användare och ger en angripare rättigheter som denne inte borde ha på ett korrekt konfigurerat produktionssystem.

    Med andra ord: ett fel blir inte automatiskt ett säkerhetshål bara för att det kan krascha något eller ser farligt ut i teorin. Det avgörande är om felet passerar en verklig säkerhetsgräns.

    Linux får en tydligare hotmodell

    En viktig del av förändringen är att Linuxkärnan nu får en mer uttalad hotmodell. En hotmodell beskriver vad systemet ska skydda mot, men också vad det inte kan eller inte lovar att skydda mot.

    Linuxkärnan ska bland annat skydda användare från varandra på samma system. En vanlig användare ska inte kunna läsa andra användares filer, komma åt deras processminne, spionera på deras processer eller kringgå skydd som styr nätverk och kommunikation.

    Kärnan ska också upprätthålla skydd baserade på så kallade capabilities, alltså särskilda behörigheter som CAP_SYS_ADMIN, CAP_NET_ADMIN och CAP_SYS_PTRACE. En användare utan rätt behörighet ska exempelvis inte kunna ändra nätverksinställningar, manipulera andra användares processer eller påverka kärnans tillstånd.

    Om en bugg gör att en vanlig användare kan få en sådan behörighet, eller göra något som normalt kräver administratörsrättigheter, kan det röra sig om en riktig säkerhetsbugg.

    AI-rapporter har blivit ett problem

    Den nya dokumentationen tar också upp ett modernt problem: AI-assisterade sårbarhetsrapporter.

    AI-verktyg kan vara användbara för att hitta misstänkta buggar i kod, särskilt i gamla eller ovanliga delar av kärnan. Men enligt dokumentationen har många rapporter som skickas till säkerhetsteamet blivit för långa, för spekulativa eller helt enkelt för dåligt verifierade.

    Problemet är inte att AI används. Problemet är när AI-genererade rapporter skickas in utan att någon människa har kontrollerat om felet verkligen går att återskapa, om det har säkerhetspåverkan eller om den föreslagna exploiten faktiskt fungerar.

    Därför säger den nya vägledningen att buggar som hittats med AI normalt ska behandlas som offentliga. Skälet är att flera personer ofta hittar samma typ av AI-upptäckta fel samtidigt. Däremot ska fungerande exploitkod inte publiceras öppet. Rapportören kan i stället säga att en reproducerbar exploit finns och lämna den privat om en ansvarig underhållare ber om det.

    Rapporter ska vara korta, tydliga och testade

    Linuxutvecklarna efterfrågar nu mer disciplinerade rapporter. En bra rapport ska vara kort, skriven i ren text och börja med det viktigaste: vilken fil eller funktion som påverkas, vilka versioner som berörs och vilken konkret påverkan felet har.

    Det räcker inte att skriva att ett fel “kan leda till privilegieeskalering” om det inte är visat. Rapportören bör i stället beskriva vad som faktiskt har testats. Till exempel: kan en vanlig användare få CAP_NET_ADMIN? Kan en process läsa minne den inte ska komma åt? Går felet att återskapa på en normal installation?

    AI-genererade reproducerare ska testas innan de skickas in. Om en AI påstår att en exploit fungerar, men rapportören inte själv har kontrollerat det, riskerar rapporten att ignoreras. Dokumentationen uppmuntrar också till att använda AI för att föreslå och testa fixar, inte bara för att producera fler felrapporter.

    Vad räknas inte som säkerhetsbugg?

    Den nya dokumentationen listar flera typer av problem som normalt inte ska ses som säkerhetshål i Linuxkärnan.

    Det gäller till exempel buggar i gamla, icke-underhållna kärnversioner. Administratörer förväntas hålla sina system uppdaterade, och en sårbarhet måste visas påverka aktivt underhållna versioner för att behandlas som en aktuell säkerhetsfråga.

    Det gäller också osäkra eller ovanliga konfigurationer. Om någon själv har ändrat sysctl-inställningar, filrättigheter eller byggt kärnan med alternativ som uttryckligen sänker säkerheten, är det inte självklart en kärnsårbarhet när något går fel.

    Utvecklingsfunktioner som LOCKDEP, KASAN och FAULT_INJECTION räknas inte heller som produktionsskydd. De är till för testning och felsökning, och kan i sig påverka stabilitet och prestanda.

    Inte heller buggar som kräver orimliga laboratorieförhållanden, modifierad hårdvara, miljarder försök eller redan mycket höga rättigheter ska automatiskt betraktas som säkerhetshål.

    Root som kraschar systemet är inte alltid en sårbarhet

    En annan viktig princip är att åtgärder som kräver full administratörsbehörighet sällan är säkerhetsbuggar i sig. Om root-användaren i den ursprungliga namnrymden kan skriva till en privilegierad enhet och orsaka en kernel oops, är det normalt inte en säkerhetsgräns som brutits. Root hade redan makten att påverka systemet.

    Det Linuxprojektet fokuserar på är i stället när en användare får mer makt än den borde ha. Säkerhetsfrågan uppstår alltså när någon passerar en gräns mellan rättigheter, inte när någon redan har rättigheterna och använder dem på ett destruktivt sätt.

    Användarnamnrymder får särskild förklaring

    Dokumentationen tar även upp CONFIG_USER_NS, alltså stöd för användarnamnrymder. Med denna funktion kan en vanlig användare skapa en isolerad miljö där användaren till synes har fulla rättigheter inom just den miljön.

    Det betyder dock inte att användaren ska kunna påverka hela systemet. En sådan namnrymd får inte ge möjlighet att ändra global systemtid, ladda kärnmoduler, montera blockenheter eller påverka den ursprungliga namnrymden på otillåtet sätt.

    Här blir hotmodellen viktig. En bugg är allvarlig om den gör att isoleringen mellan namnrymder bryts.

    Debuggning är inte alltid tänkt för vanliga användare

    Linux innehåller många kraftfulla verktyg för felsökning och prestandaanalys. Exempel är /proc/kmsg, perf, tracing och debugfs. Dessa kan ge djup insyn i systemet och därmed också bli riskabla om de exponeras fel.

    Den nya dokumentationen betonar att vissa sådana gränssnitt kräver uttryckligt administratörsbeslut. Om en administratör själv ger användare tillgång till känsliga debuggränssnitt är det inte nödvändigtvis ett säkerhetshål i kärnan. Det är en konfigurationsfråga.

    Målet är mindre brus och bättre fixar

    Bakgrunden till förändringen är tydlig: Linuxprojektet vill minska mängden felrapporter som felaktigt märks som säkerhetskritiska. Varje rapport som hamnar fel tar tid från utvecklare och säkerhetsteam. Det gör att verkligt allvarliga problem riskerar att drunkna i brus.

    Samtidigt stänger dokumentationen inte dörren för osäkra fall. Om en rapportör verkligen är osäker på om ett fel är en säkerhetsbugg uppmanas denne fortfarande att rapportera privat. Hellre en extra granskning av ett gränsfall än att en verklig sårbarhet missas.

    Men budskapet är tydligt: kalla inte varje bugg för ett säkerhetshål. Visa vilken säkerhetsgräns som bryts, testa reproduceraren, håll rapporten kort och skicka vanliga buggar till den vanliga utvecklingsprocessen.

    En mognare syn på säkerhet i en AI-tid

    Det här är mer än en intern dokumentationsändring. Det visar hur stora öppna källkodsprojekt anpassar sig till en ny verklighet där AI kan massproducera analyser, hypoteser och rapporter.

    AI kan hjälpa till att hitta riktiga fel. Men den kan också skapa stora mängder halvfärdiga påståenden som människor måste granska. För ett projekt som Linux, där underhållarnas tid är en begränsad resurs, blir kvaliteten på rapporterna avgörande.

    Den nya dokumentationen försöker därför sätta en rimlig balans. Säkerhet ska tas på allvar, men säkerhetsprocessen ska inte överbelastas av spekulationer, dåligt testade AI-fynd eller buggar som egentligen hör hemma i den öppna utvecklingsprocessen.

    I praktiken handlar det om något mycket grundläggande: ett säkerhetshål är inte bara ett fel i kod. Det är ett fel som bryter ett skydd som systemet har lovat att upprätthålla. Linuxprojektets nya dokumentation gör den gränsen tydligare.

    https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=36d49bba19f2c19c933d13b25dcf4eb607a030b3

    Teknisk faktaruta: Linuxkärnans nya säkerhetsdokumentation

    Ämne: Nya riktlinjer för säkerhetsbuggar i Linuxkärnan

    Infört av: Linus Torvalds via dokumentationsändringar i Linuxkärnan

    Pull request: docs-7.1-fixes

    Författare till dokumentationen: Willy Tarreau

    Syfte: Att tydliggöra vad som räknas som en säkerhetsbugg, hur rapporter ska skickas in och hur AI-assisterade buggrapporter ska bedömas.

    Viktiga nyheter:

    • Tydligare gräns mellan vanliga buggar och säkerhetsbuggar.
    • Ny hotmodell för Linuxkärnan.
    • Riktlinjer för AI-genererade och AI-assisterade rapporter.
    • Krav på testade reproducerare och verifierad påverkan.
    • Fokus på buggar som bryter verkliga säkerhetsgränser.

    Exempel på säkerhetspåverkan: En vanlig användare får behörigheter som normalt kräver administratörsrättigheter, exempelvis nätverkskontroll eller åtkomst till andra användares processer.

    Räknas normalt inte som säkerhetsbugg: Fel i gamla kärnversioner, osäkra specialkonfigurationer, utvecklingsfunktioner, teoretiska attacker utan fungerande exploit eller problem som kräver redan höga rättigheter.

    Betydelse: Dokumentationen ska minska brus i säkerhetsrapporteringen och hjälpa utvecklare att fokusera på verkligt allvarliga sårbarheter.

  • GCC 16.1 är här – och C++ tar ett stort kliv in i 2020-talet

    GCC 16.1 är här och markerar början på en ny fas för GNU Compiler Collection. Med C++20 som nytt standardläge, experimentellt stöd för kommande C++26-funktioner och förbättringar för både diagnostik, optimering och modern hårdvara är detta en release som kan få stor betydelse för utvecklare. Samtidigt kan äldre kodbaser behöva ses över när kompilatorn tar ett tydligt steg bort från C++17-eran.

    Den fria kompilatorsamlingen GCC har fått en ny storversion. Med GCC 16.1 startar den nya GCC 16-serien, och även om en kompilatorrelease kanske inte låter som något som får pulsen att rusa hos alla, är detta en version som många utvecklare kommer att märka av.

    Den största nyheten är att GCC nu byter standardläge för C++: från GNU C++17 till GNU C++20.

    Det betyder att den som kompilerar C++-kod utan att själv ange språkversion nu automatiskt får C++20 som utgångspunkt. För moderna projekt är det goda nyheter. För äldre kodbaser kan det däremot innebära att vissa saker behöver justeras.

    C++20 blir det nya normala

    C++20 var ett stort steg för programmeringsspråket C++. Det introducerade bland annat nya sätt att skriva generisk kod, förbättrade standardbibliotek och funktioner som gör språket mer uttrycksfullt. Att GCC nu gör GNU C++20 till standard är därför en tydlig signal: C++20 är inte längre något framtidsläge, utan något utvecklare bör räkna med i vardagen.

    För de flesta projekt innebär det inte nödvändigtvis katastrof. Men kod som byggts med antagandet att kompilatorn använder C++17 kan börja bete sig annorlunda eller ge nya felmeddelanden. Lösningen är ofta enkel: ange uttryckligen vilken standard projektet ska byggas med, till exempel med flaggan -std=gnu++17, eller uppdatera koden så att den fungerar bra med C++20.

    GCC-utvecklarna meddelar också att stödet för C++20:s standardbibliotek nu räknas som stabilt. Däremot är C++20-moduler fortfarande experimentella och kräver särskild aktivering med -fmodules.

    En försmak av C++26

    GCC 16.1 blickar också framåt. Versionen innehåller experimentellt stöd för flera funktioner som är på väg in i C++26, alltså en kommande version av C++-standarden.

    Bland nyheterna finns stöd för reflection, där program kan undersöka delar av sin egen struktur, contracts, som kan användas för att uttrycka krav och garantier i kod, constexpr exceptions, vilket stärker möjligheterna att göra beräkningar vid kompilering, samt nya bibliotekstyper som std::simd, std::inplace_vector, std::copyable_function och std::function_ref.

    Det här är inte funktioner man bör kasta in i produktionskritisk kod hur som helst. De är fortfarande experimentella. Men för språkintresserade utvecklare och verktygsmakare är GCC 16.1 ett viktigt steg mot nästa generation C++.

    Algol 68 gör oväntad entré

    En av de mer oväntade nyheterna är att GCC nu får en experimentell frontend för Algol 68, kallad ga68.

    Algol 68 är ett klassiskt programmeringsspråk från datorhistoriens mer akademiska hörn. Det hade stort inflytande på senare språk, även om det aldrig blev lika vardagligt använt som C, Pascal eller Fortran. Att GCC nu får stöd för Algol 68 är därför både tekniskt intressant och lite nostalgiskt.

    Frontend:en bygger på språket så som det beskrivs i den reviderade rapporten, inklusive godkända rättelser, och innehåller dessutom vissa GNU-utökningar samt en POSIX-prelude.

    Bättre felmeddelanden och modernare analys

    Kompilatorer handlar inte bara om att omvandla kod till körbara program. De är också ett av utvecklarens viktigaste verktyg för att förstå vad som gått fel.

    I GCC 16.1 har diagnostiken förbättrats. GCC kan nu generera fel- och varningsmeddelanden i ett experimentellt HTML-format, vilket kan göra rapporter mer lättlästa i webbläsare eller utvecklingsverktyg.

    Samtidigt förbättras SARIF-stödet med ny information om kontrollflöde. SARIF är ett format som används för maskinläsbara analysrapporter, till exempel i säkerhetsverktyg och CI-system.

    Det äldre JSON-formatet för diagnostik har tagits bort. Användare som behöver maskinläsbara felrapporter hänvisas i stället till SARIF.

    Mer stöd för moderna språkfunktioner

    På C-sidan utökas stödet för C23 och typen _BitInt till fler processorarkitekturer, bland annat RISC-V, Arm, S/390 och LoongArch. Det gör det enklare att skriva kod som arbetar med heltal av mer exakt definierade bitstorlekar.

    C-frontend:en får också stöd för så kallad counted-by-attribution för pekarfält, vilket kan hjälpa kompilatorn och analysverktyg att förstå hur stora vissa datastrukturer är.

    Fortran-användare får dessutom förbättringar i coarray-stödet. På system med en enda nod finns nu stöd för delat minne med flera trådar, vilket kan förbättra parallella Fortran-program.

    Snabbare kod genom bättre optimeringar

    Som vanligt i en ny GCC-version finns även en rad optimeringsförbättringar. GCC 16.1 har bland annat bättre vektorisering, alltså förmågan att omvandla kod så att processorn kan utföra flera operationer parallellt.

    Kompilatorn kan nu också vektorisera vissa loopar där antalet varv inte är känt i förväg, och hanteringen av reduktioner och tidiga loopavbrott har förbättrats.

    Även Link-Time Optimization, LTO, har fått förbättringar. LTO gör det möjligt för kompilatorn att optimera över flera källfiler när programmet länkas ihop. I GCC 16.1 hanteras top-level assembly bättre med hjälp av flaggan -flto-toplevel-asm-heuristics.

    Dessutom har spekulativ devirtualisering byggts ut, vilket kan hjälpa kompilatorn att optimera indirekta funktionsanrop när den kan göra kvalificerade gissningar om vilken funktion som faktiskt kommer att köras.

    Nya processorer och mer hårdvarustöd

    GCC 16.1 uppdaterar också stödet för ny hårdvara.

    På x86-sidan tillkommer stöd för AMD Zen 6 med -march=znver6, Intel Wildcat Lake med -march=wildcatlake och Intel Nova Lake med -march=novalake.

    För AMD GPU-offloading finns nu experimentellt stöd för MI300, och även LoongArch och IBM Z får ytterligare förbättringar.

    För vanliga användare märks detta kanske inte direkt. Men för den som bygger program för nya servrar, superdatorer eller specialiserad hårdvara kan kompilatorstöd vara avgörande för att få ut maximal prestanda.

    En version som kan kräva städning

    Som med många stora kompilatoruppdateringar finns en hake: kod som fungerade i tidigare GCC-versioner kan behöva ändras.

    Det beror både på den nya C++20-standarden som standardläge och på att kompilatorn blivit bättre på att upptäcka problem. I praktiken kan detta leda till fler varningar eller kompileringsfel i projekt som tidigare byggde utan problem.

    För utvecklare är rådet enkelt: testa tidigt, ange språkstandard tydligt i byggsystemet och läs igenom varningarna. Många av dem kan peka på verkliga problem som tidigare bara råkade passera obemärkt.

    Sammanfattning

    GCC 16.1 är mer än bara ännu en versionssiffra. Det är en tydlig markering om vart C++-världen är på väg. Med C++20 som nytt standardläge, experimentellt stöd för C++26, förbättrad diagnostik, bättre optimeringar och stöd för ny hårdvara är detta en viktig release för både systemutvecklare och språkentusiaster.

    För den som arbetar med äldre C++-kod gäller det att vara uppmärksam. För den som vill använda modernare språkfunktioner är GCC 16.1 däremot ett välkommet steg framåt.

    ”`html

    Faktaruta: GCC 16.1

    > Release: GCC 16.1 är den första stabila versionen i GCC 16-serien.

    > Största nyheten: C++ använder nu GNU C++20 som standard i stället för GNU C++17.

    > För utvecklare: Äldre projekt kan behöva ange språkstandard med exempelvis -std=gnu++17.

    > Framtidsstöd: Experimentellt stöd finns för flera C++26-funktioner.

    > Övrigt: GCC 16.1 innehåller även bättre diagnostik, optimeringar och stöd för ny hårdvara.

    ”`
  • Rust 1.95 släppt – större lyft för matchning, villkorsstyrd kod och standardbiblioteket

    Rust 1.95 är här med stöd för if let-guards i match, det nya makrot cfg_select! och en lång rad nya stabila API:er i standardbiblioteket. Releasen innebär också förändringar för custom targets och ytterligare uppdateringar i Cargo och Clippy.

    Rust 1.95 har nu släppts och bjuder på flera nyheter för utvecklare, bland annat förbättrad mönstermatchning, ett nytt makro för konfigurationsstyrd kompilering och en tydlig utökning av det stabila API:et i standardbiblioteket. Versionen publicerades den 16 april 2026.

    Den mest uppmärksammade språkförändringen är att if let-guards nu stöds i match-uttryck. Funktionen bygger vidare på let chains, som blev stabila i Rust 1.88, och gör det möjligt att lägga in ytterligare villkorlig mönstermatchning direkt i en matcharm. För utvecklare innebär det mer flexibel och kompakt kod i situationer där flera villkor behöver uttryckas samtidigt.

    Samtidigt betonar Rust-teamet att de mönster som fångas i en if let-guard ännu inte räknas in i kompilatorns analys av om en match är uttömmande. Det följer samma princip som vanliga if-guards redan gör i dag. Funktionen ger alltså större uttryckskraft, men inte någon förändring i hur exhaustiveness-kontrollen fungerar.

    En annan nyhet i Rust 1.95 är makrot cfg_select!, som enligt projektet fungerar som en slags kompileringstida match över cfg-predikat. Det placerar makrot i samma användningsområde som det välkända cfg-if-paketet, men med annan syntax och som en del av den stabila verktygskedjan. Syftet är att göra det enklare att välja olika implementationer beroende på plattform eller byggmiljö.

    Version 1.95 innebär också en bred utökning av Rusts stabila API-yta. Bland de nya stabiliserade delarna finns förbättringar för MaybeUninit, Cell, atomiska update– och try_update-metoder, core::range, samt nya metoder som Vec::push_mut och Vec::insert_mut. Även VecDeque, LinkedList och flera Layout-metoder får nya stabila tillskott.

    För användare som arbetar med mer specialiserade byggmiljöer innehåller releasen också en förändring kring egna target-specifikationer. Möjligheten att på stabil Rust skicka in en egen JSON-baserad target-fil direkt till rustc har tagits bort. Enligt Rust-projektet påverkar det dock inte användare med helt stabil verktygskedja i praktiken, eftersom byggande av standardbiblioteket för sådana custom targets redan tidigare krävde nightly-stöd.

    Utöver språk- och biblioteksförändringarna innehåller Rust 1.95 även fler uppdateringar i Cargo och Clippy. Sammantaget framstår versionen som en bred underhålls- och förbättringsrelease, snarare än en uppdatering med en enda dominerande nyhet. För Rust-utvecklare betyder det framför allt bättre ergonomi, fler stabila verktyg och ett fortsatt stegvis moget ekosystem.

    https://blog.rust-lang.org/2026/04/16/Rust-1.95.0

    Teknisk fakta: Rust 1.95
    Version Rust 1.95
    Typ av release Stabil språk- och biblioteksuppdatering
    Språknyhet Stöd för if let-guards i match-uttryck
    Nytt makro cfg_select!
    Biblioteksnyheter Utökad stabil API-yta i bland annat MaybeUninit, Cell, Vec, VecDeque och LinkedList
    Viktiga metoder Vec::push_mut, Vec::insert_mut, atomiska update/try_update
    Övrigt Stabilt stöd för custom JSON-targets i rustc tas bort
    Fokus Bättre ergonomi, fler stabila API:er och bred underhållsrelease
  • Ghostty 1.3 – snabb terminalemulator får stora nyheter

    Ghostty 1.3 är här med flera av de funktioner som användarna länge har efterfrågat. Den GPU-accelererade terminalemulatorn får nu bland annat sökning i terminalhistoriken, inbyggda systemanpassade scrollbars, bättre tangentbordsstyrning och smartare notiser, samtidigt som utvecklarna har förbättrat både prestanda och stabilitet.

    Terminalprogram är ett av de viktigaste verktygen i Linux- och utvecklarvärlden. Nu har den moderna terminalemulatorn Ghostty fått en omfattande uppdatering. Version 1.3 innehåller flera funktioner som länge har efterfrågats av användare, samtidigt som utvecklarna har förbättrat både prestanda och stabilitet.

    Ghostty är en relativt ny terminalemulator som fokuserar på hög prestanda genom att använda datorns grafikprocessor (GPU) för rendering. Resultatet är en snabb och responsiv terminal som klarar stora mängder text och komplexa terminalutdata utan att kännas långsam.

    Sök direkt i terminalens historik

    En av de största nyheterna i version 1.3 är sökning i scrollback-historiken. Tidigare har användare ofta behövt använda externa verktyg eller manuella metoder för att hitta text långt bak i terminalens logg.

    Nu går det att söka direkt i terminalen:

    • Ctrl + Shift + F på GTK-baserade system (vanligt i Linux)
    • Cmd + F på macOS

    När man söker markeras alla träffar direkt i terminalfönstret och man kan snabbt hoppa mellan resultaten via tangentbordet eller sökgränssnittet.

    Äkta scrollbars från operativsystemet

    Ghostty 1.3 introducerar också native scrollbars. Det innebär att rullningslisten inte längre är en specialritad komponent utan använder operativsystemets egna widgetar.

    Det ger flera fördelar:

    • Samma utseende som resten av systemet
    • Stöd för standardinteraktioner
    • Bättre integration i både Linux (GTK) och macOS

    Användaren kan till exempel dra i scrollbaren eller klicka i spåret för att hoppa i historiken, precis som i andra program.

    Klicka för att flytta markören i terminalprompten

    En annan efterlängtad funktion är click-to-move-cursor. Med hjälp av standarden OSC 133 Semantic Prompts specification kan användaren nu klicka i en aktiv shell-prompt för att flytta markören.

    Det gör terminalen mer lik en vanlig textredigerare. Istället för att använda piltangenter eller avancerade tangentkombinationer kan man helt enkelt klicka där man vill fortsätta skriva.

    Kraftfullare tangentbordsgenvägar

    För avancerade användare har Ghostty också förbättrat sitt system för tangentbordsbindningar.

    Nyheterna inkluderar:

    • Key tables – möjliggör modal arbetsstil liknande tmux
    • Kedjade kortkommandon – flera åtgärder från samma genväg
    • catch_all-tangent – fångar upp alla obundna tangenttryckningar i en sekvens

    Detta gör det enklare att skapa komplexa arbetsflöden direkt i terminalen.

    Smart kopiering till urklipp

    När man kopierar text från terminalen lägger Ghostty nu flera format i urklipp samtidigt.

    Förutom vanlig text inkluderas även HTML-format. Det innebär att färger och formatering kan bevaras när text klistras in i exempelvis dokument eller e-postklienter.

    Stora förbättringar i prestanda

    Utvecklarna har också arbetat mycket med prestanda. Genom att analysera omkring 4 GB terminalinspelningar från tjänsten asciinema kunde de optimera hur Ghostty hanterar terminaldata och rendering.

    Resultatet är:

    • snabbare uppspelning av terminalsessioner
    • mindre väntetid i renderingsmotorn
    • effektivare I/O-hantering

    Flera stabilitetsfixar

    Version 1.3 löser även ett långvarigt problem: en minnesläcka som funnits sedan Ghostty 1.0 har nu åtgärdats.

    Utvecklarna har dessutom använt omfattande fuzz-testning för att stress-testa terminalens parser för escape-sekvenser och VT-dataströmmar. Det gör programmet mer robust mot felaktig eller ovanlig terminaldata.

    Automatisering på macOS

    På macOS introducerar Ghostty stöd för AppleScript.

    Det gör det möjligt för externa skript och program att styra terminalen, till exempel:

    • skapa nya fönster
    • öppna flikar
    • dela upp terminalrutor
    • skicka kommandon

    Funktionen är aktiverad som standard men är fortfarande märkt som förhandsversion medan API:t stabiliseras.

    Notiser när kommandon är klara

    En annan praktisk nyhet är notiser när ett kommando är färdigt. Funktionen kan användas när man kör långvariga kommandon, exempelvis kompilering eller databearbetning.

    Ghostty kan då:

    • visa en skrivbordsnotis
    • spela ett terminal-ljud
    • eller båda

    Det går även att konfigurera så att notiser bara visas när terminalfönstret inte är i fokus.

    Sex månader av utveckling

    Ghostty 1.3 är resultatet av ungefär sex månaders arbete. Under den tiden har:

    • 180 utvecklare bidragit
    • över 2 858 kodändringar gjorts

    Utöver de större funktionerna innehåller versionen hundratals mindre förbättringar, buggrättningar och optimeringar.

    En terminal som fortsätter utvecklas snabbt

    Med funktioner som historiksökning, systemintegrerade scrollbars och bättre tangentbordsstöd tar Ghostty ännu ett steg mot att bli ett av de mest avancerade terminalprogrammen för både Linux och macOS.

    Utvecklingen går dessutom snabbt – något som tyder på att Ghostty kan bli en stark konkurrent till etablerade terminaler under de kommande åren.

    https://ghostty.org

    Fakta: Ghostty 1.3

    Ghostty 1.3 är en större uppdatering av den GPU-accelererade terminalemulatorn Ghostty.

    • Ny sökfunktion i terminalhistoriken
    • Systemanpassade scrollbars för macOS och GTK
    • Stöd för klickbar markörflytt i shell-prompt
    • Förbättrade tangentbordsgenvägar och nyckeltabeller
    • Smartare kopiering med stöd för både text och HTML
    • Prestandaförbättringar och minnesläckor åtgärdade
    • Notiser när långkörande kommandon avslutas
  • Rust 1.94 gör språket mer uttrycksfullt och kraftfullt

    Programmeringsspråket Rust fortsätter att utvecklas i snabb takt. Den nya versionen Rust 1.94 introducerar flera förbättringar som gör språket både mer ergonomiskt och mer kraftfullt. Bland nyheterna finns en ny iterator för slice-data, förbättrad konfigurationshantering i Cargo, stöd för den senaste versionen av TOML-formatet och flera stabiliserade API:er i standardbiblioteket.

    Tillsammans innebär förändringarna att utvecklare kan skriva mer tydlig kod, organisera projekt bättre och dra nytta av nya funktioner i både språket och verktygskedjan.

    Ny iterator för slices: array_windows

    En av de mest uppmärksammade nyheterna är metoden array_windows för slices. Den fungerar på liknande sätt som den befintliga metoden windows, men med en viktig skillnad: den returnerar arrayer med fast storlek i stället för dynamiska slices.

    Detta gör att kompilatorn kan veta storleken på varje fönster redan vid kompilering, vilket förenklar kod och kan ge bättre optimeringar.

    En praktisk användning är när man vill analysera mönster i en dataström. Ett klassiskt exempel är att leta efter så kallade ABBA-mönster, där två olika tecken följs av samma två tecken i omvänd ordning, exempelvis abba eller xyyx.

    Med array_windows kan en sådan kontroll skrivas mycket kompakt:

    Här kan kompilatorn automatiskt förstå att varje fönster ska bestå av fyra element eftersom de destruktureras till fyra variabler.

    Cargo får bättre stöd för modulär konfiguration

    Rusts byggverktyg Cargo får i version 1.94 en ny funktion: möjligheten att inkludera konfigurationsfiler i andra konfigurationsfiler.

    Detta gör att större projekt kan dela upp sin konfiguration i flera mindre filer, vilket gör dem enklare att underhålla och återanvända mellan olika projekt eller utvecklingsmiljöer.

    Ett exempel är:

    Det går även att ange mer avancerade alternativ via så kallade inline-tabeller, exempelvis om en konfigurationsfil är valfri:

    Detta gör det möjligt att skapa konfigurationer som fungerar både lokalt och i olika utvecklingsmiljöer utan att alla filer behöver finnas överallt.

    Stöd för TOML 1.1

    Cargo kan nu också läsa TOML 1.1, den senaste versionen av konfigurationsformatet som används i Rust-projekt.

    Bland förbättringarna i TOML 1.1 finns:

    • inline-tabeller som kan skrivas över flera rader
    • stöd för fler escape-sekvenser i strängar
    • möjlighet att utelämna sekunder i tidsangivelser
    • trailing commas i vissa strukturer

    Det innebär exempelvis att beroenden i Cargo.toml kan skrivas mer läsbart:

    Om man använder dessa nya funktioner höjs dock projektets MSRV (Minimum Supported Rust Version), eftersom äldre Cargo-versioner inte kan tolka den nya syntaxen. Samtidigt hanterar Cargo detta automatiskt vid publicering genom att skriva om manifestfiler så att de förblir kompatibla med äldre verktyg.

    Nya matematiska konstanter i standardbiblioteket

    Rusts standardbibliotek har också utökats med några klassiska matematiska konstanter. Bland de nya konstanterna finns:

    • Euler–Mascheroni-konstanten (EULER_GAMMA)
    • det gyllene snittet (GOLDEN_RATIO)

    De finns tillgängliga för både f32 och f64 och kan användas direkt i numeriska beräkningar utan att utvecklare behöver definiera dem själva.

    Fler stabiliserade API:er

    Som i varje Rust-release har även flera tidigare experimentella funktioner nu blivit stabila API:er. Bland dessa finns bland annat:

    • array_windows och element_offset för slices
    • nya metoder för LazyCell och LazyLock
    • nya metoder i iteratorn Peekable
    • hårdvaruintrinsics för AVX-512 FP16 på x86 och NEON FP16 på AArch64

    Dessutom kan vissa funktioner, som mul_add för flyttal, nu användas i konstanta uttryck.

    Fortsatt snabb utveckling av Rust

    Rust 1.94 visar tydligt hur språket fortsätter att utvecklas i både små och stora steg. Förbättringar som array_windows gör koden mer uttrycksfull, medan förändringar i Cargo och TOML gör projekthanteringen mer flexibel.

    Utvecklare som redan använder Rust kan uppdatera till den nya versionen med kommandot:

    Den nya versionen är resultatet av arbete från ett stort antal bidragsgivare i Rust-communityt – ett exempel på hur ett modernt open source-projekt fortsätter att förbättras genom globalt samarbete.

    C vs Rust

    C

    C är ett klassiskt programspråk som har använts i årtionden för operativsystem, drivrutiner, inbyggda system och annan prestandakritisk programvara.

    Språket ger programmeraren mycket direkt kontroll över minne och hårdvara, vilket gör det snabbt och flexibelt.

    Nackdelen är att C saknar inbyggt skydd mot många vanliga minnesfel, vilket kan leda till buggar, krascher och säkerhetsproblem.

    Rust

    Rust är ett modernare systemspråk som också fokuserar på hög prestanda, men samtidigt vill minska risken för minnesfel och osäker kod.

    Genom sitt ägarskapssystem och sina kompilatorkontroller kan Rust förhindra många problem redan innan programmet körs.

    Det gör språket särskilt intressant för säkerhetskritiska system, servrar, verktyg och ny systemprogrammering.

    https://blog.rust-lang.org/2026/03/05/Rust-1.94.0

    Teknisk fakta: Rust 1.94

    Version: Rust 1.94.0

    Typ av uppdatering: Stabil utgåva

    Viktig nyhet: array_windows för slices

    Ny Cargo-funktion: stöd för include i konfigurationsfiler

    Manifestformat: Cargo kan nu tolka TOML 1.1

    Nya matematiska konstanter: EULER_GAMMA och GOLDEN_RATIO

    Fler förbättringar: stabiliserade API:er i standardbiblioteket och fler funktioner tillgängliga i const-kontext

    Uppdateringskommando:

    rustup update stable
  • NotepadNext 0.13 – klassisk enkelhet med moderna förbättringar

    NotepadNext 0.13 tar ett tydligt kliv framåt genom att kombinera den klassiska enkelheten från Notepad++ med moderna funktioner för tryggare och smidigare arbete. Med autosparade sessioner, stöd för arbetsytor och flera efterfrågade förbättringar stärker uppdateringen editorns roll som ett lättviktigt men kraftfullt verktyg för både kod och textredigering.

    NotepadNext, en modern och plattformsoberoende nytolkning av Notepad++, har släppts i version 0.13. Fokus ligger på att förbättra arbetsflödet utan att göra programmet tyngre eller mer komplext. Resultatet är en uppdatering som främst riktar sig till användare som vill ha en snabb, pålitlig och okomplicerad kod- och textredigerare.

    Autosparade sessioner ökar tryggheten

    Den mest märkbara nyheten i version 0.13 är autosparade sessioner. Alla öppna filer sparas automatiskt var 60:e sekund. Vid en krasch, omstart eller oavsiktlig stängning kan arbetet återställas nästan exakt där det lämnades. Funktionen är särskilt värdefull vid längre redigeringspass eller när man arbetar med många filer samtidigt.

    Workspace-läge för arbete med hela mappar

    NotepadNext får nu ett workspace-läge som gör det möjligt att öppna en hel katalog som arbetsyta. Detta aktiveras via den nya kommandoradsflaggan --workspace. Funktionen förenklar hantering av projekt som består av flera filer och gör editorn mer användbar även utanför enstaka filredigering.

    Nya och förbättrade redigeringsfunktioner

    Uppdateringen innehåller flera förbättringar som ger användaren mer kontroll över gränssnitt och beteende. Det går nu att slå av och på radnummer, inaktivera automatisk URL-markering samt klicka direkt på EOL-indikatorn i statusfältet. En ny funktion gör det möjligt att ta bort dubbla rader, inklusive upprepade rader i följd. Markörens beteende har justerats för att bättre respektera markerade områden, och sökresultat använder nu en enhetlig typsnittsstorlek för bättre läsbarhet.

    Buggfixar och förbättrad stabilitet

    Version 0.13 åtgärdar flera praktiska problem som tidigare kunde störa arbetsflödet. Hanteringen av filsökvägar vid start av flera instanser har förbättrats, liksom dialogen för omladdning av ändrade filer. Det finns nu också stöd för att ange en standardkatalog vid filöppning. Session- och omladdningslogiken har finjusterats för att minska avbrott under längre arbetspass.

    Utökat språk- och syntaxstöd

    På syntaxsidan har stöd för Abaqus lagts till. Lokaliseringen har samtidigt utökats med nya översättningar till italienska och tyska, uppdateringar för brasiliansk portugisiska och ukrainska samt ett uppfräschat portugisiskt språkstöd.

    Tillgänglighet på Linux

    För Linuxanvändare finns NotepadNext tillgänglig både som Flatpak och som AppImage, vilket gör installationen enkel oavsett distribution.

    Sammanfattning

    NotepadNext 0.13 är en tydlig förbättring som bygger vidare på programmets grundidé: snabbhet, enkelhet och fokus på själva redigeringen. Med autosparade sessioner och workspace-stöd tar editorn ett steg framåt utan att förlora sin lättviktiga karaktär, vilket gör den till ett attraktivt alternativ för både vardagsanvändare och utvecklare.

    Så här installera du Notepadnext på ubuntu och debian.

    Ubuntu och Debian kan NotepadNext installeras helt via terminalen med hjälp av Flatpak. Nedan är ett komplett exempel som visar varje steg i ordning.

    Först installerar du Flatpak om det inte redan finns på systemet:

    sudo apt update
    sudo apt install flatpak
    

    Därefter lägger du till Flathub, som är det officiella programförrådet där NotepadNext finns:

    sudo flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo
    

    När Flathub är aktiverat kan du installera NotepadNext:

    flatpak install flathub com.github.dail8859.NotepadNext
    

    Efter installationen kan programmet startas direkt från terminalen:

    flatpak run com.github.dail8859.NotepadNext
    

    NotepadNext kommer nu även att synas i programmenyn tillsammans med övriga installerade program. Uppdateringar hanteras automatiskt via Flatpak, vilket gör att du alltid har tillgång till den senaste versionen utan extra arbete.

    Installation av NotepadNext på Ubuntu/Debian (Flatpak)
    1) Installera Flatpak
    sudo apt update
    sudo apt install flatpak
      
    2) Lägg till Flathub
    sudo flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo
      
    3) Installera NotepadNext
    flatpak install flathub com.github.dail8859.NotepadNext
      
    4) Starta programmet
    flatpak run com.github.dail8859.NotepadNext
      
  • Micro 2.0.15 – terminalredigeraren som gör comeback

    Efter nästan ett års tystnad är den populära terminalbaserade textredigeraren Micro tillbaka med version 2.0.15. Uppdateringen fokuserar på förbättrad syntaxmarkering, stabilare redigering och ett mognare plugin-system, och markerar ett tydligt steg framåt för ett verktyg som vill kombinera enkelhet med kraften hos moderna kodredigerare – helt i terminalen.

    Efter en längre paus är den terminalbaserade textredigeraren Micro tillbaka med version 2.0.15. Det är den första nya utgåvan sedan version 2.0.14 från augusti 2024 och markerar ett tydligt steg framåt för projektet, både tekniskt och användarmässigt.

    Micro är utformad för att vara lätt att använda direkt, samtidigt som den erbjuder funktioner som annars ofta förknippas med fullskaliga grafiska textredigerare. Med intuitiva tangentkommandon, musstöd och modern funktionalitet har Micro blivit ett populärt alternativ för användare som vill arbeta effektivt i terminalen utan att behöva lära sig komplexa kommandospråk.

    Stora förbättringar i syntaxmarkering

    Den största nyheten i Micro 2.0.15 är de omfattande förbättringarna av syntaxmarkeringen. Stöd har utökats eller förfinats för många språk och filformat, bland annat Rust, Java, Swift, Haskell, OpenSCAD, Meson, PRQL, nftables, Fish shell, Groovy och Ruby. Även JavaScript-varianter som .cjs samt olika assembly- och C++-specialfall har fått bättre hantering.

    Utöver nya språk har flera problem från tidigare versioner rättats till, exempelvis felaktig tolkning av nyckelord, kommentarer och strängliteraler som uppstod efter tidigare ändringar i syntaxreglerna.

    Förbättrad redigering och navigering

    Även själva redigeringsfunktionerna har blivit mer konsekventa. Kommandon för att kopiera, klippa ut, ta bort och duplicera text fungerar nu bättre i alla situationer, inklusive specialfall som den sista raden i en fil.

    Navigeringen har också utvecklats. Nya funktioner för page up och page down beter sig nu mer som i nano, markören kan positioneras mer logiskt i förhållande till den synliga delen av dokumentet och arbetet med flera markörer samtidigt har förbättrats. Samtidigt har många regressioner åtgärdats, till exempel problem med scrollning, delade vyer, fönsterstorlekar och markörplacering.

    Stabilitet, säkerhet och plugins

    På stabilitetssidan har Micro blivit säkrare vid filhantering. Sparfunktionen är mer robust, onödiga säkerhetskopior skapas inte längre för oförändrade filer och sparning med förhöjda rättigheter fungerar bättre. Viktigt är också att risken för dataförlust har minskat vid arbete med delade buffertar.

    Plugin-systemet har utvecklats med nya callbacks och utökade API:er, samtidigt som gränsen mellan inbyggda och externa plugins blivit tydligare. För ökad säkerhet kan plugins inte längre ändra centrala konfigurationsfiler utan uttryckligt tillstånd från användaren.

    Byggstöd och framtid

    Slutligen har stödet för korskompilering förbättrats. Windows ARM64 stöds nu officiellt och alla byggen är helt statiska med CGO avstängt. Det gör Micro enklare att distribuera och mer pålitlig i olika miljöer.

    Snabba tangentkommandon i Micro

    KommandoFunktion
    Ctrl + SSpara fil
    Ctrl + QAvsluta Micro
    Ctrl + OÖppna fil
    Ctrl + FSök i dokument
    Ctrl + RSök och ersätt
    Ctrl + CKopiera
    Ctrl + XKlipp ut
    Ctrl + VKlistra in
    Ctrl + ZÅngra
    Ctrl + YGör om
    Ctrl + KKlipp ut aktuell rad
    Ctrl + DDuplicera rad eller markering
    Alt + ← / →Hoppa ordvis
    Ctrl + ← / →Byt flik
    Ctrl + \Dela vy
    Ctrl + WStäng aktuell vy
    Page Up / Page DownBläddra sida för sida

    Micro 2.0.15 visar tydligt att projektet är tillbaka på banan. Med förbättrad syntaxmarkering, stabilare beteende och ett mer moget plugin-system befäster Micro sin roll som ett modernt och lättillgängligt verktyg för effektiv textredigering i terminalen.

    Exempel på installation i praktiken

    På Ubuntu och Debian kan Micro installeras på flera sätt, och här är ett sammanhängande exempel som visar hur det går till i praktiken. Det vanligaste sättet är att använda den inbyggda pakethanteraren. Man börjar då med att uppdatera paketlistan och installerar sedan redigeraren direkt från programförråden genom att köra kommandona:

    sudo apt update
    sudo apt install micro
    

    Efter detta kan Micro startas genom att skriva micro följt av ett filnamn i terminalen.

    Vill man istället installera den senaste versionen från utvecklarna själva kan man använda Micros officiella installationsskript. Först laddas skriptet ner och görs körbart, därefter körs det för att hämta den färdiga binären:

    wget https://getmic.ro
    chmod +x getmic.ro
    ./getmic.ro
    sudo mv micro /usr/local/bin/
    

    När binären har flyttats till /usr/local/bin är Micro tillgänglig systemövergripande.

    Ett tredje alternativ är att använda Snap, vilket ger automatiska uppdateringar. Installationen görs då med ett enda kommando:

    sudo snap install micro --classic
    

    Samtliga metoder leder till samma resultat: Micro är installerat och redo att användas direkt i terminalen.

    https://github.com/zyedidia/micro/releases/tag/v2.0.15

    Faktaruta: Vad är nytt i Micro 2.0.15?
    Större lyft för syntaxmarkering: Fler och bättre regler för många språk/format (t.ex. Rust, Java, Swift, Haskell, Ruby, Groovy, Fish, nftables, PRQL) samt fler JavaScript-varianter som .cjs.
    Färre feltolkningar: Fixar för nyckelord, kommentarer och literaler som tidigare kunde ge fel färgsättning eller trasiga regler.
    Mer konsekvent redigering: Åtgärdar specialfall för kopiera/klipp/ta bort/duplicera, bland annat problem runt sista raden i filer.
    Smidigare navigering: Nya markör- och sidbläddringsbeteenden (inspirerat av nano), förbättrad markörplacering i synlig vy och bättre multicursor.
    Stabilare scroll och vyer: Fixar regressioner kring scrollning, vyjustering, split-resize och markörplacering.
    Säkrare sparning: Robustare skrivning, färre onödiga backups, förbättrad sparning med höjda rättigheter och skydd mot dataförlust vid delade buffertar.
    Plugin-systemet stramas upp: Nya callbacks och utökade API:er, tydligare gräns mellan inbyggda och externa plugins – plus att plugins inte får ändra kärnkonfig utan tillstånd.
    Bättre byggstöd: Förbättrad korskompilering (inkl. Windows ARM64) och byggen som är helt statiska med CGO avstängt.
  • Fish Shell 4.3 – när kommandoraden blir smartare, snyggare och mer förutsägbar

    Fish Shell 4.3 är en uppdatering som vid första anblick kan verka försiktig, men som i praktiken förändrar hur skalet upplevs i det dagliga arbetet. Istället för stora, uppseendeväckande nyheter har utvecklarna fokuserat på att göra befintliga funktioner tydligare, smartare och mer konsekventa. Resultatet är ett kommandoskal som känns mer förutsägbart, lättare att konfigurera och bättre anpassat till moderna terminaler. För både vana användare och nyfikna nybörjare markerar version 4.3 ett steg mot en mer genomtänkt och harmonisk terminalupplevelse.

    Kommandoraden är för många ett arbetsredskap snarare än ett användargränssnitt. Ändå är det just där som Fish Shell, Friendly Interactive SHell, skiljer sig från mängden. Med version 4.3 tar Fish ännu ett steg mot att göra terminalen både mer begriplig och mer intelligent, utan att tumma på kraften under huven.
    Den här versionen är inte en dramatisk omvälvning, utan snarare en noggrant avvägd evolution: bättre standardbeteenden, renare konfigurationer och en terminalupplevelse som anpassar sig efter användaren, inte tvärtom.

    Mindre magi, mer kontroll: nya konfigurationsprinciper

    En av de största förändringarna märks först knappt alls. Tidigare använde Fish så kallade universella variabler för färger, teman och tangentbindningar. De var praktiska men också svåröverskådliga.
    I Fish 4.3 ändras detta i grunden. Standardvariabler som fish_color_* och fish_key_bindings sätts nu globalt i stället för universellt. Vid första starten efter uppgradering gör Fish en engångsmigrering som fryser ditt nuvarande tema och dina tangentbindningar till filer i ~/.config/fish/conf.d/.
    Utvecklarna rekommenderar därefter att man tar bort dessa automatiskt skapade filer och istället hanterar allt direkt i config.fish. Resultatet blir en mer förutsägbar, lättläst och versionshanterbar konfiguration. Det går fortfarande att använda universella variabler, men då medvetet och med vetskapen om att de inte lämpar sig lika väl för dynamiska teman.

    Ett nytt språk – bokstavligen

    Fish 4.3 introducerar ett nytt kommando i skriptspråket: status language. Det kan låta trivialt, men det löser ett gammalt problem. Nu kan man se vilket språk Fish använder för sina meddelanden och ändra språket utan att behöva manipulera globala miljövariabler. Detta är särskilt användbart i skript, testmiljöer och dokumentation där man vill ha konsekventa och reproducerbara utdata.

    Smartare kompletteringar – även bakom kulisserna

    Fish är känt för sina intelligenta kompletteringar, och här har version 4.3 förfinat detaljerna. commandline –cursor fungerar nu korrekt även i icke-interaktiva sessioner. Kompletteringar hanterar sökvägar som innehåller = eller : betydligt bättre. Skiftlägesokänslig prefixmatchning gör att fler träffar hittas snabbare, och autosuggestioner kan nu radbrytas mjukt i stället för att kapas abrupt.
    För användare på Cygwin och MSYS har Fish dessutom blivit bättre på att matcha körbara filer mot rätt metadata, vilket ger mer konsekvent beteende över plattformar.

    Redigering med filsystemsförståelse

    Även tangentbordsarbetet har förbättrats. Ctrl-W tar nu bort escaped spaces när man raderar delar av en sökväg. Nya sökvägsmedvetna redigeringsfunktioner gör det enklare att navigera och justera långa filstigar direkt på kommandoraden. Det är små förbättringar som snabbt blir oumbärliga för den som arbetar mycket i terminalen.

    Teman som anpassar sig efter ljus och mörker

    En modern terminal växlar ofta mellan ljus och mörk bakgrund. Fish 4.3 möter detta genom att låta teman definiera separata sektioner för ljusa och mörka färgscheman. Flera av Fish standardteman har redan uppdaterats för detta. Resultatet är ett skal som ser rätt ut oavsett om du arbetar mitt i natten eller i fullt dagsljus.

    Djupare terminalintegration – utan att vara i vägen

    Fish fortsätter att förbättra sin integration med avancerade terminalfunktioner. OSC-signalerna för promptgränser är nu mer konsekventa, den aktuella arbetskatalogen rapporteras korrekt och fokusrapportering är aktiverad som standard. En ny funktionsflagga gör det dessutom möjligt att stänga av terminalsärlösningar när de inte behövs, vilket ger bättre kontroll i specialmiljöer.

    Stabilitet och puts: färre krascher, färre överraskningar

    Slutligen adresserar Fish 4.3 en rad regressionsproblem från tidigare versioner. Det gäller bland annat krascher kopplade till färgvariabler, problem med Unicode-autosuggestioner, emoji-bredd på macOS, kantfall vid flerradig inmatning och kompletteringsproblem på system utan glibc. Inget av detta är spektakulärt, men allt bidrar till ett skal som helt enkelt känns mer pålitligt.

    Sammanfattning

    Fish Shell 4.3 är ett tydligt exempel på mogen programutveckling. Fokus ligger inte på uppseendeväckande nyheter utan på tydligare konfiguration, bättre standardbeteenden, modern terminalanpassning och många små förbättringar som gör stor skillnad i vardagen. För den som lever i terminalen är detta en uppdatering som inte ropar, men som stillsamt visar att det bara fungerar.

    https://fishshell.com

    Faktaruta: Fish Shell 4.3

    Version: 4.3
    Typ: Interaktivt Unix-skal
    Mål: Förbättrad användarvänlighet utan att offra kraft

    Viktiga nyheter:
    – Standardvariabler för teman och tangentbindningar är nu globala istället för universella
    – Engångsmigrering fryser befintligt tema till conf.d-filer vid uppgradering
    – Nya kommandot status language styr språk för Fish-meddelanden
    – Förbättrade och mer träffsäkra kompletteringar, även i icke-interaktiva lägen
    – Teman kan reagera dynamiskt på ljusa och mörka terminaler
    – Fördjupad terminalintegration med tydligare promptgränser och fokusrapportering

    Plattformar: Linux, macOS, *BSD, Cygwin/MSYS
    Licens: GPLv2
    Webbplats: https://fishshell.com
  • Ruby 4.0 – ett stort steg framåt för ett klassiskt språk

    Ruby 4.0 markerar ett av de största kliven i språkets historia, där fokus ligger på isolering, parallellism och prestanda utan att kompromissa med Rubys välkända läsbarhet. Med ny teknik som Ruby Box, en helt ny JIT-kompilator och ett kraftigt förbättrat stöd för parallell exekvering visar Ruby att språket är redo att möta moderna krav – samtidigt som det fortsätter att sätta utvecklarens upplevelse i centrum.

    När Ruby 4.0 nu har släppts markerar det mer än bara ännu en versionssiffra. Det är ett tydligt tecken på att ett av världens mest omtyckta programmeringsspråk fortsätter att utvecklas – både tekniskt och filosofiskt – i en tid där krav på prestanda, parallellism och säkerhet är högre än någonsin. Ruby har länge varit känt för sin läsbarhet och sin glädjeprincip: programmering ska vara roligt. Med Ruby 4.0 försöker utvecklarna bevisa att man inte längre behöver välja mellan elegans och råstyrka.

    Ruby Box – isolering utan containrar

    Den kanske mest nyskapande nyheten är Ruby Box, en experimentell teknik för isolering inuti samma Ruby-process. Genom att starta Ruby med miljövariabeln RUBY_BOX=1 kan man skapa separata ”lådor” där klasser, moduler, globala variabler, monkey patches och till och med inlästa bibliotek hålls helt åtskilda. Det gör det möjligt att köra testfall som använder aggressiva monkey patches utan att påverka andra tester, köra flera versioner av samma webbapplikation parallellt vid blue-green-driftsättning eller testa nya beroenden i realtid genom att jämföra beteende och svar. Allt detta sker utan containrar eller separata processer – isoleringen sker direkt i Ruby-motorn.

    ZJIT – nästa generations prestandasatsning

    Ruby 4.0 introducerar också ZJIT, en ny experimentell just-in-time-kompilator som är tänkt att på sikt ersätta YJIT. ZJIT är skriven i Rust och använder större kompileringsenheter samt en modern SSA-baserad mellanrepresentation. Resultatet är redan nu snabbare än den traditionella tolken, även om den fortfarande ligger efter YJIT. Utvecklarna är tydliga med att ZJIT ännu inte är redo för produktion, men ambitionen är att den ska vara både snabbare än YJIT och stabil nog för skarp drift i Ruby 4.1. För den nyfikne kan ZJIT aktiveras med flaggan –zjit.

    Ractor tar ett steg mot mognad

    Parallell programmering har länge varit en svag punkt i Ruby, men Ractor-modellen fortsätter att utvecklas. I Ruby 4.0 introduceras klassen Ractor::Port, som ersätter tidigare mer svårbegripliga API:er som Ractor.yield och Ractor#take. Kommunikation mellan parallella delar av ett program blir tydligare och mer robust. Samtidigt har interna datastrukturer förbättrats för att minska låsning kring globala resurser, minska delad intern data och förbättra CPU-cache-beteende. Tillsammans ger detta märkbart bättre parallell prestanda, och målet är att Ractor snart ska lämna sin experimentella status helt.

    Små språkliga förändringar med stor effekt

    Ruby 4.0 innehåller också flera språkliga justeringar som gör vardagen trevligare för utvecklare. Logiska operatorer som && och || kan nu stå i början av en rad och fortsätta föregående uttryck, vilket gör flerradiga villkor mer lättlästa. Beteendet för *nil har gjorts mer konsekvent och anropar inte längre nil.to_a, i linje med hur **nil redan fungerar. Felmeddelanden vid fel antal argument är tydligare och innehåller både bättre bakspårning och kodutdrag. Unicode-stödet har uppdaterats till version 17.0, inklusive nya emoji.

    Ett snabbare och renare Ruby under huven

    Bakom kulisserna har Ruby 4.0 fått omfattande prestandaförbättringar. Objekt skapas snabbare, särskilt när nyckelordsargument används. Garbage collectorn arbetar effektivare, intern åtkomst till instansvariabler har optimerats och många gamla låsningar i heta kodvägar har tagits bort. Standardbiblioteket har samtidigt städats upp: vissa komponenter har flyttats eller uppdaterats, andra – som delar av CGI-biblioteket – levereras inte längre fullt ut som standard.

    Framåtblick

    Ruby 4.0 är inte bara en inkrementell uppdatering utan ett tydligt ställningstagande. Språket vill fortsätta vara uttrycksfullt och lättläst, men samtidigt möta moderna krav på prestanda, parallellism och isolering. Med Ruby Box, ZJIT och ett allt mer moget Ractor-system visar Ruby att det går att förnya sig utan att förlora sin identitet. För utvecklare innebär det en tydlig signal: Ruby är långt ifrån färdigt – det har precis växlat upp.

    https://www.ruby-lang.org/en

    Fakta: Ruby 4.0
    Ny isolering: Ruby Box (experimentellt) isolerar klasser, moduler, globala variabler, monkey patches och även inlästa bibliotek per “box”. Aktiveras med RUBY_BOX=1.
    Ny JIT: ZJIT (experimentellt) efterföljare till YJIT – metodbaserad JIT med större kompileringsenheter och SSA-baserad IR. Byggkrav: Rust 1.85+. Aktiveras med –zjit.
    Parallellism: Ny Ractor::Port för tydligare kommunikation mellan Ractors. Äldre API:er som Ractor.yield och Ractor#take är borttagna.
    Språknytt: Logiska operatorer i början av rad (&&, ||, and, or) fortsätter föregående rad. *nil beter sig nu konsekvent och anropar inte längre nil.to_a.
    Standardbibliotek & core: Set och Pathname är core-klasser, och Unicode är uppdaterat till 17.0 (inkl. Emoji 17.0).
    Kompatibilitet: Flera deprecated API:er är borttagna (bl.a. äldre Ractor-metoder). Windows-bygg kräver Visual Studio 2015+.


  • Fresh – när terminaln möter det moderna kodverktyget

    Terminaln har länge varit utvecklarens snabbaste verktyg – men också ett av de mest avskalade. Med Fresh utmanas den bilden. Den nya öppna textredigeraren kombinerar terminalns effektivitet med moderna funktioner som annars hör hemma i grafiska IDE:er. Resultatet är ett kraftfullt kodverktyg som körs helt i textläge, men ändå erbjuder en strukturerad, visuell och förvånansvärt bekväm utvecklingsmiljö.

    Fresh – när terminaln möter det moderna kodverktyget

    I takt med att allt fler utvecklare söker snabbare, lättare och mer fokuserade arbetsflöden har intresset för terminalbaserade verktyg fått en tydlig renässans. Samtidigt vill få ge upp de bekvämligheter som moderna utvecklingsmiljöer erbjuder. Här kliver Fresh in – en ny öppen källkodsbaserad textredigerare som försöker förena två världar som länge setts som motsatser: den klassiska terminaln och den grafiska kodeditorn.

    Fresh är en så kallad TUI-editor (Text-based User Interface), skriven i programmeringsspråket Rust. Det innebär att hela programmet körs i ett vanligt terminalfönster, utan att använda grafiska ramverk som GTK eller Qt. Trots detta lyckas Fresh leverera en upplevelse som ligger mycket nära den man förknippar med moderna grafiska program.

    Ett grafiskt tänk – helt i textläge

    Vid första anblick kan Fresh nästan uppfattas som en traditionell grafisk editor. Den innehåller menyer, paneler, delade vyer, filutforskare och en integrerad terminal, allt uppbyggt med terminalns egna möjligheter. Musstöd finns från start, tillsammans med snabbkommandon, kontextmenyer och en kommandopalett där användaren kan söka efter funktioner på samma sätt som i moderna IDE:er.

    I stället för att arbeta direkt med filer använder Fresh buffertar. Flera filer och terminalsessioner kan vara öppna samtidigt och visas sida vid sida i horisontella eller vertikala split-vyer. En permanent statusrad längst ner visar relevant information som filnamn, markörposition och aktuell Git-branch.

    Kraftfull redigering utan begränsningar

    Trots sitt terminalbaserade format saknar Fresh inte avancerade redigeringsfunktioner. Programmet erbjuder stöd för flera markörer, avancerade textmarkeringar samt obegränsad ångra- och gör om-funktionalitet. All redigering sparas i en fullständig historik, vilket gör att användaren tryggt kan experimentera utan risk att förlora arbete.

    Navigeringen förbättras ytterligare genom positionshistorik och inbyggt stöd för Language Server Protocol. Detta gör det möjligt att hoppa till definitioner, navigera mellan symboler och få kodintelligens som annars förknippas med fullskaliga grafiska utvecklingsmiljöer.

    Filhantering utan att lämna editorn

    Fresh innehåller en inbyggd filutforskare som låter användaren navigera i projektets katalogstruktur direkt i editorn. Den är helt anpassad för tangentbord, men fungerar även med mus. Som standard respekteras .gitignore-filer, vilket hjälper till att hålla fokus på relevanta filer i projektet. Filer kan öppnas, bytas och skapas utan att man behöver lämna editorn eller använda externa verktyg.

    Terminaln som en integrerad del av arbetsflödet

    En av de mest utmärkande funktionerna i Fresh är den inbyggda terminalemulatorn. Terminaler öppnas som vanliga buffertar och kan delas upp i flera flikar. Användaren kan växla mellan inmatningsläge och scroll-läge, söka i terminalutdata och kopiera text med samma kommandon som används i redigeraren.

    En särskilt ovanlig funktion är att terminalsessioner kan bevaras mellan omstarter. Pågående processer och hela scrollback-historiken finns kvar, vilket suddar ut gränsen mellan editor och kommandoskal.

    Kodintelligens med resurskontroll

    Fresh har inbyggt stöd för Language Server Protocol och erbjuder diagnostik, kodkomplettering och symbolinformation i realtid. Rust, JavaScript, TypeScript och Python fungerar direkt, medan ytterligare språk kan konfigureras manuellt via en JSON-baserad inställningsfil.

    En detalj som särskiljer Fresh från många andra editorer är möjligheten att sätta gränser för CPU- och minnesanvändning hos språkservrar. Detta förhindrar att resurskrävande LSP-processer påverkar systemets prestanda negativt.

    Ett pluginsystem byggt för framtiden

    Fresh är konstruerat med utbyggbarhet i fokus. Redigeraren använder ett pluginsystem baserat på TypeScript, vilket gör det relativt lätt att skapa egna tillägg. Flera plugins följer med som standard, bland annat för att markera TODO-kommentarer och utföra Git-baserade sökningar.

    För C- och C++-utveckling finns även ett särskilt Clangd-hjälpplugin. Plattformsspecifika detaljer, till exempel för macOS, är tydligt dokumenterade för att underlätta installation och användning.

    Samlad och tydlig konfiguration

    All konfiguration i Fresh sker via en enda config.json-fil som lagras på ett standardiserat sätt beroende på operativsystem. I denna fil styrs allt från teman och tangentbindningar till språkservrar, plugins och resursbegränsningar. Tanken är att ge användaren full kontroll utan att sprida inställningar över flera filer.

    Stöd för alla större operativsystem

    Fresh är officiellt stödd på Linux, macOS och Windows. För den som vill prova finns färdiga binärer, men även installationsalternativ via Homebrew, Arch User Repository, .deb- och .rpm-paket, npm, crates.io eller manuell kompilering från källkod. På Windows fungerar Fresh i moderna terminaler, och det går även att köra via WSL för en mer Linux-lik upplevelse.

    Terminalns nästa steg

    Fresh visar tydligt att terminalbaserade verktyg inte längre behöver vara spartanska eller svåranvända. Genom att kombinera hög prestanda, moderna gränssnittsidéer och ett tydligt fokus på utvecklarens arbetsflöde pekar Fresh mot en framtid där terminaln inte är ett alternativ till grafiska verktyg – utan ett fullvärdigt hem för dem.

    Bild ifrån projektets hemsida

    Linux.se:s åsikt

    Efter att ha testat Fresh är helhetsintrycket mycket lovande, även om den senaste versionen ännu inte verkar finnas tillgänglig som .deb-paket. Känslan för tankarna tillbaka till DOS-eran, fast i en modern tappning.

    För den som i dag snabbt vill redigera filer direkt på en server är alternativen oftast nano eller emacs/vi. Både emacs och vi är kraftfulla verktyg, men de har också en relativt hög inlärningströskel, vilket kan avskräcka många användare.

    En funktion som skulle vara mycket uppskattad i framtida versioner av Fresh är stöd för emacs-liknande Ctrl-kommandon. För användare som har dessa tangentkombinationer djupt inpräntade i muskelminnet är det svårt att ”lära gamla hundar att sitta”. Dessutom kan Ctrl-kommandon i vissa situationer vara snabbare och mer effektiva, exempelvis vid sparande och navigering.

    Trots detta framstår Fresh som ett tydligt positivt tillskott. Det fyller ett tomrum mellan enkla terminalredigerare och mer komplexa redigeringsmiljöer, och har potential att bli ett naturligt val för modern server- och terminalbaserad utveckling.

    Läs mer på :

    https://sinelaw.github.io/fresh

    FAKTARUTA
    Fresh – terminaleditor med IDE-känsla
    • Typ: Öppen källkod, TUI (Text-based UI) i terminal
    • Språk: Rust
    • Gränssnitt: Paneler, split-vyer, filutforskare, musstöd
    • Utvecklarstöd: LSP (diagnostik, completion, symboler)
    • Extra: Inbyggd terminal som buffert med flikar och scroll-läge
    • Utbyggbart: Pluginsystem (TypeScript) och central config.json
    • Plattformar: Linux, macOS, Windows (även via WSL)
    Tips: Passar dig som vill stanna i terminaln men ändå ha moderna IDE-funktioner.
  • ”Jag ville bara lösa ett problem” – Linus Torvalds om Linux, Git och livet som envis ingenjör

    Han sitter ensam i ett ljuddämpat hemmakontor med ljusgröna väggar, en katt i knät och ett gåband han slutat använda – ändå är det härifrån en av världens viktigaste tekniska revolutioner har styrts. Utan storslagna visioner eller femårsplaner har den envisa ingenjören Linus Torvalds, skaparen av Linux och Git, förändrat hur internet fungerar, hur vi skriver kod – och hur miljarder människor använder teknik varje dag.

    Video är snart 10 år gamla, men ändå intressant för den som vill fördjupa sej i LInux.

    Tänk dig teknikens mäktigaste kontrollrum. Du föreställer dig kanske en futuristisk bunker full av blinkande skärmar, serverracks och avancerad utrustning.

    När TED-curatorn Chris Anderson visade bilden av Linus Torvalds arbetsplats brast publiken ut i skratt.

    På scenen: ett helt vanligt rum. Ett skrivbord, en suddigt synlig dator, beige väggar i en ljusgrön färg som enligt Torvalds ofta används på mentalsjukhus. Under skrivbordet tronar ett gåband.

    ”Det är det mest intressanta i mitt kontor,” säger han, ”och jag använder det inte ens längre.”

    Den mannen – som sitter i morgonrock och jobbar i tystnad – styr utvecklingen av ett operativsystem som driver allt från superdatorer till Android-telefoner och internetservrar. En och en halv miljard aktiva Android-enheter, enligt Torvalds själv.

    Hur hamnade vi här? Hur blev en ensam ingenjör i tystnaden arkitekten bakom någonting som förändrade allt?

    I början var det bara ett sidoprojekt

    När Torvalds 1991 som 21-årig student i Helsingfors började skriva Linux-kärnan, var det inte för att leda ett globalt rörelse – utan för att ha roligt.

    ”Jag startade inte Linux som ett samarbetsprojekt. Det var ett av många projekt jag gjorde åt mig själv. Jag behövde resultatet – och jag älskade att programmera.”

    Han hade ingen plan, ingen vision, inget kommersiellt mål. Han delade det efter ett halvår, mest med orden: ”Kolla vad jag byggt! Kommentera gärna.”

    Det var inte ens ”öppen källkod” i modern bemärkelse.

    Men han fick svar.

    Folk började testa. Komma med idéer. Sen kod.

    ”Innan någon ens skickade kod hade jag mitt ’wow’-ögonblick: folk tittar på min kod – och ger mig idéer!”

    Samma man som erkänner att han ”egentligen inte tycker om andra människor” beskriver det här som något av det största han varit med om.

    Envisheten – mer än intelligensen – var nyckeln

    När Chris Anderson frågar om Torvalds var ”barn-geniet, skolans stjärna eller mega-nörden”, tvekar han inte.

    ”Jag var typisk nörd. Jag var mer intresserad av Rubiks kub än av min bror.”

    Hans syster brukade förbereda honom på familjeträffar: ”Okej, den där heter så, den där jobbar med det…” för att underlätta det sociala samspelet.

    Inte exceptionellt smart, enligt honom själv. Men något annat utmärkte honom:

    ”Jag kan inte släppa saker.”

    Han stannar kvar. I ett problem. I ett projekt. I ett mönster.

    Och det är exakt därför Linux fungerar.

    Kodens skönhet: när specialfall försvinner

    Torvalds visar i intervjun två varianter på en enkel datastruktur – en länkad lista. Den ena har en if-sats i slutet. Den andra saknar den.

    Funktionen är densamma. Skillnaden? Den ena kräver ett specialfall. Den andra behandlar alla fall lika.

    ”God smak handlar om att se mönstret och skriva om det så specialfallen försvinner och blir normalfallet.”

    Det här är populärvetenskapens kärna: den eleganta förenklingen. Någon som ser det andra inte ser – men inte för att de är visionära. Utan för att de vägrar ge sig tills det sitter perfekt.

    Git – skapat för att han inte ville hantera tusentals människor

    När Linux växte till tusentals utvecklare behövdes versionshantering. Existerande verktyg räckte inte.

    ”Jag hatade CVS av hela mitt hjärta.”

    Han kunde inte effektivt skala sin arbetsmetod till tusentals bidragsgivare.

    Så han byggde Git.

    ”Git är mitt andra stora projekt – skapat åt mig för att hantera mitt första.”

    Idag är Git standardsystemet för nästan all mjukvaruutveckling globalt.

    ”Jag är ingen visionär. Jag är ingenjör.”

    Torvalds erkänner att han känner sig obekväm på TED.

    ”Här pratar alla om visioner. Jag har ingen femårsplan. Jag tittar på marken och fixar hålet i vägen innan jag ramlar ner i det.”

    Världen behöver drömmare, säger han – men han hör inte till dem. Han är mer som Edison än Tesla.

    Edison beskylldes ofta för att vara tråkig. Tesla var idésprutan. Men vem förändrade världen mest?

    ”Jag tror jag är mer som Edison. Geni är en procent inspiration och 99 procent hårt arbete.”

    Öppen källkod – varför det fungerar i tekniken (men kanske inte i politiken)

    Torvalds tror öppen källkod fungerade så bra för mjukvara eftersom kod är binär:

    ”Kod fungerar – eller fungerar inte. Det ger mindre utrymme för dispyter.”

    Han är skeptisk till öppna system i politik, där verkligheten sällan är svartvit. Däremot ser han en återkomst av öppenhet inom forskning – via öppna databaser, arXiv och Wikipedia.

    ”Blir du arg när Google tjänar miljarder på Linux?”

    Det korta svaret: Nej.

    ”Utan att släppa taget hade Linux aldrig blivit vad det är. Och jag klarar mig bra.”

    Han har offrat viss anonymitet och tvingats hålla föredrag (trots att han ogillar det). Men han ångrar inte sitt beslut.

    Så vad lär vi oss av Linus Torvalds?

    Att du inte måste vilja förändra världen för att göra det.

    Ibland räcker det att:

    • älska det du gör,
    • vara envis nog att aldrig släppa taget,
    • se elegans där andra ser komplexitet,
    • och inte distraheras av visioner när det finns ett hål framför fötterna.

    Torvalds sitter fortfarande i sin tystnad. Ibland med en katt i knät. Hörandes spinnandet, inte fläktarna.


    ”Jag tittar inte på stjärnorna.
    Jag lagar hålet i vägen framför mig.”

    Och genom att göra just det – med extrem envishet, teknisk klarhet och nästan total ignorans för vad världen tycker – blev Linus Torvalds en av de mest inflytelserika människorna i den digitala tidsåldern.

    Publicerad i teknik & vetenskap — baserad på TED-intervju med Linus Torvalds

    Fakta: Linus Torvalds – ingenjören som förändrade världen

    • Namn: Linus Benedict Torvalds
    • Född: 28 december 1969, Helsingfors, Finland
    • Känd för: Skapare av Linux-kärnan (1991) och Git (2005)
    • Linux i världen: Driver majoriteten av världens servrar, superdatorer, molnplattformar och alla Android-enheter.
    • Git i världen: Standardverktyget för versionshantering av kod – används av utvecklare och företag globalt.
    • Påverkan: Har möjliggjort öppen källkod i industriell skala och förändrat hur mjukvara utvecklas, delas och förbättras.
    • Roll: Tekniskt ledarskap snarare än chefskap – känd för fokus på kodkvalitet, enkelhet och ”god smak” i design.
    • Filosofi: Ser sig inte som visionär, utan som ingenjör som löser konkreta problem steg för steg – ”fixar hålet i vägen framför sig”.
  • Ny dokumentärfilm berättar historien om Python

    Ny dokumentärfilm berättar historien om Python

    Programmeringsspråket Python har fått sin egen film. Dokumentären “Python: The Documentary” är 90 minuter lång och skildrar resan från Guido van Rossums sidoprojekt i Amsterdam på 1990-talet till dagens globala dominans.

    Python är idag världens mest använda programmeringsspråk, enligt det senaste TIOBE-indexet (augusti 2025). Filmen visar hur språket, som från början var ett experiment, blivit en central del i allt från artificiell intelligens och datavetenskap till några av världens största företag.

    Bland de medverkande finns grundaren Guido van Rossum, Travis Oliphant, Barry Warsaw, Armin Ronacher, Mariatta Wijaya och flera andra profiler som haft betydelse för språkets utveckling.

    Dokumentären lyfter inte bara Python i sig, utan ger också en inblick i den bredare historien om öppen källkod – kryddad med den humor som ofta förknippas med open source-gemenskapen.

    Filmen har möjliggjorts med stöd från Anaconda, Dropbox, Meta, OpenTeams, JetBrains’ PyCharm och Quansight.

    “Python: The Documentary” finns nu tillgänglig för alla som vill ta del av berättelsen bakom världens mest inflytelserika programmeringsspråk.

  • GNU Binutils 2.45 – Stort lyft för RISC-V och nya funktioner för flera arkitekturer

    GNU-projektet har släppt version 2.45 av GNU Binutils, en samling viktiga kommandoradsverktyg för lågnivåprogrammering. Binutils används för att skapa, analysera och manipulera objektfiler (mellanformatet som kompilatorer producerar innan det blir körbara program), bibliotek och färdiga exekverbara filer.

    Tillsammans med GCC (GNU Compiler Collection – GNU:s samling av kompilatorer), glibc (GNU C Library – standardbibliotek för C-språket) och GDB (GNU Debugger – felsökningsverktyg) utgör Binutils kärnan i den öppna GNU-verktygskedjan som driver stora delar av Linux-världen.

    Den nya versionen innehåller både grundläggande förbättringar och omfattande stöd för nya processorinstruktioner i arkitekturer som RISC-V, Arm v9.6, LoongArch och x86.

    Mer pålitliga stackspårningar med SFrame

    En av de mest tekniskt betydelsefulla nyheterna är förbättringarna i SFrame, ett format för att lagra komprimerad information om funktionsanrop och returadresser.

    När ett program kraschar eller behöver analyseras kan utvecklare använda stack traces (anropsstackar) för att se exakt var i koden något gick fel. Med SFrame i version 2 blir denna information mer kompakt och samtidigt mer exakt, vilket särskilt gynnar verktyg som körs utanför själva processen (till exempel felsökningsverktyg som analyserar kärndumpar).

    I och med version 2.45:

    • GAS (GNU Assembler – översättare från assemblerkod till maskinkod) genererar nu SFrame-sektioner med SHT_GNU_SFRAME-typen och flaggan SFRAME_F_FDE_FUNC_START_PCREL som standard.
    • IBM\:s s390x-plattform (64-bitars version av stordatorarkitekturen System/390) får för första gången möjlighet att generera SFrame direkt från CFI-direktiv (Call Frame Information – metadata som beskriver hur stackramar byggs upp och återställs).

    Nya verktyg direkt i assemblerkoden

    Utvecklare får även två nya direktiv:

    • .errif – kastar ett felmeddelande vid ett visst villkor.
    • .warnif – ger en varning vid ett visst villkor.

    Villkoren utvärderas först när filen är helt assemblerad, vilket gör det möjligt att samla in mer kontext innan felmeddelandet visas. Detta är användbart i stora kodbaser eller firmwareprojekt.

    RISC-V tar flera steg framåt

    RISC-V är en öppen processorinstruktionsuppsättning (ISA – Instruction Set Architecture) som kan användas royaltyfritt av tillverkare. Den växer snabbt i betydelse, och Binutils 2.45 bygger ut stödet rejält:

    • Stöd för Privileged Specification v1.13 – den del av RISC-V-specifikationen som reglerar hur operativsystem och hårdvara kommunicerar på låg nivå.
    • Tre nya profiler (20, 22 och 23) som definierar färdiga kombinationer av instruktionstillägg.
    • Nytt direktiv .bfloat16 – hantering av 16-bitars flyttal i formatet Brain Floating Point, populärt i maskininlärning.
    • Stöd för en lång lista av standardtillägg som exempelvis:
    • sha – hårdvaruacceleration för SHA-kryptografi.
    • zce – komprimerade instruktioner för inbyggda system.
    • smrnmi – säker maskinvaruhantering av icke-maskerbara avbrott.
    • Stöd för leverantörsspecifika tillägg, bland annat från:
    • T-Head (Alibaba Groups processordivision): xtheadvdot – specialinstruktioner för vektorberäkningar.
    • MIPS: instruktioner som förbättrar minnesoperationer och kontrollflöde.

    En viktig förändring är också att $x-mappningssymboler nu ersätts med \$x för att bättre ange vilken ISA de tillhör. Detta kan kräva att viss äldre RISC-V-kod byggs om.

    Arm v9.6 – försprång till framtida CPU-funktioner

    För Arm tillkommer flaggan -march=armv9.6-a i assemblern. Den aktiverar redan nu stöd för kommande instruktioner som väntas i kommersiella processorer från slutet av 2025 och framåt.

    Några exempel:

    • +sme2p2 – nästa generation av Scalable Matrix Extension, för maskininlärning och vektorberäkningar.
    • +ssve-aes – effektivare AES-kryptering med Scalable Vector Extension (SVE).
    • +f8f32mm – snabbare matrismultiplikation med 8-bitars och 32-bitars flyttal.

    x86 och LoongArch – små men viktiga uppdateringar

    x86-sidan:

    • Stöd för Zhaoxin PadLock XMODX – en uppsättning kryptografiska instruktioner i vissa kinesiska x86-processorer.
    • Borttagning av stöd för 256-bitars varianten av AVX10.2-avrundningsinstruktioner – eftersom alla berörda CPU\:er redan stöder 512-bitarsvarianten.

    För LoongArch (en kinesisk processorarkitektur):

    • Nya alias för vissa 32-bitars instruktionsvarianter.
    • Förbättrade varningar när .align-direktiv eller matematiska uttryck riskerar att ge fel (till exempel negativa skiftningar eller division med noll).

    Slutsats

    GNU Binutils 2.45 är en ovanligt stor uppdatering – särskilt för dem som utvecklar kod nära hårdvaran. Den stärker debugmöjligheterna, inför nya verktyg i själva assemblern och ger utvecklare tillgång till nästa generations processorfunktioner redan idag.

    För RISC-V betyder det här ett bredare och mer komplett verktygsstöd, för Arm öppnar det dörren till framtida vektor- och krypteringsförbättringar, och för både x86 och LoongArch handlar det om små men värdefulla optimeringar

    https://www.gnu.org/software/binutils

    GNU Binutils 2.45 — Tekniska begrepp & förkortningar
    Binutils
    Samling lågnivåverktyg (bl.a. as, ld, objdump, readelf) för objektfiler, bibliotek och länkningssteg.
    GAS
    GNU Assembler – översätter assembler till maskinkod/ELF; i 2.45 genererar GAS SFrame V2 per default.
    ELF
    Executable and Linkable Format – standard för binärformat på Unix-lika system; sektioner, symboltabeller, relokerings-poster m.m.
    SFrame (V2)
    Kompakt stack-unwindformat för out-of-process stacktracing; lagrar återställningsregler per funktion utan full DWARF-overhead.
    SHT_GNU_SFRAME
    ELF-sektionstyp som identifierar SFrame-data; gör att verktyg kan hitta och tolka SFrame deterministiskt.
    SFRAME_F_FDE_FUNC_START_PCREL
    Header-flagga som anger att funktionsstart i FDE (Frame Description Entry) är PC-relativ – robustare symbolik/relokering.
    CFI
    Call Frame Information – metadata (ofta via .cfi_*) som beskriver stackramar; kan nu syntetiseras till SFrame på s390x.
    s390x
    64-bitars IBM Z/System z-ISA; Binutils 2.45 kan generera SFrame direkt från CFI för bättre felsökning på mainframe.
    .errif / .warnif
    GAS-direktiv som utvärderar villkor vid filslut och emitterar fel/varning; bra för policy-kontroller i firmware/SDK-träd.
    AArch64 sysregs
    Systemregister i 64-bitars Arm; 2.45 kan assemblera samtliga utan extra spärrar (-menable-sysreg-checking av).
    RISC-V ISA
    Öppen instruktionsuppsättning; 2.45 stödjer Privileged Spec v1.13, profiler 20/22/23, och ett brett spektrum av extensions.
    Privileged v1.13
    Spec för trap/CSR/virt mm. (OS-nivå); uppdaterade regler för maskin-/supervisor-lägen och delegationsvägar.
    Profiler 20/22/23
    Kuraterade paket av extension-kombinationer för definierade “capability tiers”; förenklar toolchain-målsättning.
    .bfloat16
    Assemblerliteral för Brain Float 16 (8-bit exponent, 7-bit mantissa+sign); nyttjas i ML-kernels på RVV/SME-lika enheter.
    $x → $x<isa>
    RISC-V-mappingsymbol byter semantik: explicit ISA-tagg per kodö i stället för implicit ärvning; kan kräva ombyggnad.
    Standard-ext.
    sha (SHA-accel), zce (compressed embedded), ssqosid/ssnpm/smnpm/smmpm/sspm/supm (privilege mgmt/QoS), ssccfg, svvptc (virt/ptc), zilsd/zclsd (load/store dags), smrnmi (RM-NMI) m.fl.
    Vendor-ext.
    T-Head: xtheadvdot (vektordot-ops). MIPS: xmipscbop, xmipscmov, xmipsexectl, xmipslsp (kontroll/mem-primitiver).
    Armv9.6-A
    -march=armv9.6-a aktiverar bl.a. +sme2p2 (SME v2p2), +ssve-aes (SVE-optimerad AES), +f8f16mm/+f8f32mm (FP8-matrismul), +sve2p2, m.fl. för pre-silicon-validering.
    SVE/SME
    Scalable Vector Extension / Scalable Matrix Extension – vektor- och matrisaccel med vektorlängds-agnostisk semantik.
    x86 XMODX
    Zhaoxin PadLock XMODX – nya kryptoinstruktioner. Samtidigt tas 256-bitars AVX10.2-rounding path bort (512-bit antas).
    AVX10.2
    Advanced Vector Extensions 10.2 – uniform ISA över 128–512b; 2.45 slopar en äldre 256b-avrundningskodväg.
    LoongArch
    Kinesisk RISC-ISA; 2.45 lägger till LA32R-alias (rdcntvl.w, rdcntvh.w, rdcntid.w) och striktare uttrycksdiagnostik.
    .align (3:e arg)
    Max bytes att hoppa; 2.45 varnar på out-of-range. Extra kontroller för negativa shifts och /% med noll.
    Tips: Aktivera SFrame-emission i byggkedjan och validera med readelf --sections och objdump --sframe där stöds.

    Källa :

    https://linuxiac.com/gnu-binutils-2-45-expands-risc-v-support

Etikett: programmering

  • GCC säger nej till betydande kod som skapats av AI

    Utvecklare får använda AI för att diskutera idéer, förstå källkod och göra efterforskningar. Men kod som helt eller delvis bygger på material från språkmodeller som ChatGPT, Gemini eller GitHub Copilot ska normalt inte tas emot som bidrag till GNU Compiler Collection. GCC Steering Committee, den grupp som leder utvecklingen av GNU Compiler Collection, har antagit…

  • GNU Binutils 2.47 gör utvecklarnas verktygslåda snabbare och mer flexibel

    GNU-projektet har släppt Binutils 2.47, en ny version av den viktiga verktygssamling som används för att bygga och analysera program i Linux. Uppdateringen ger bland annat bättre stöd för RISC-V, nya möjligheter vid felsökning och snabbare länkning av stora program. GNU-projektet har släppt GNU Binutils 2.47, en ny version av den verktygssamling som används för…

  • Codeberg säger nej till projekt som huvudsakligen skapats av AI

    Den ideella kodplattformen Codeberg förbjuder nu projekt som till största delen består av AI-genererad kod. Beslutet grundas på osäker upphovsrätt, säkerhetsrisker och svårigheten att avgöra vem som egentligen ansvarar för programvaran. Den ideella kodplattformen Codeberg inför nya regler för programvara som har skapats med hjälp av generativ artificiell intelligens. Projekt där merparten av källkoden har…

  • Perl 5.44 släppt – får namngivna parametrar, bättre prestanda och Unicode 17

    Perl 5.44 har släppts med experimentellt stöd för namngivna parametrar, förbättrad prestanda och stöd för Unicode 17. Den nya versionen innehåller även flera säkerhetsrättningar, strängare regler för Unicode-tecken och uppdateringar av språkets reguljära uttryck. Programmeringsspråket Perl har fått en ny stabil version. Perl 5.44 innehåller bland annat experimentellt stöd för namngivna parametrar, bättre Unicode-hantering, flera…

  • Linus Torvalds: Från programmerare till utvecklingsledare

    Linus Torvalds skriver numera sällan kod själv och beskriver sin roll som utvecklingsledare. Under Open Source Summit India 2026 berättade han om arbetet bakom Linuxkärnan, synen på AI och Rust samt varför föråldrad teknik ibland måste tas bort. Linus Torvalds skriver numera sällan kod själv. I stället leder han utvecklingen av Linuxkärnan genom att granska…

  • När Linux sätter gränser för vad som är en säkerhetsbugg

    När antalet AI-genererade sårbarhetsrapporter ökar vill Linuxprojektet dra en tydligare gräns mellan vanliga buggar och verkliga säkerhetshål. Linus Torvalds har nu slagit ihop ny dokumentation som förklarar när ett fel i Linuxkärnan ska behandlas som en säkerhetsbugg, hur rapporter bör skickas in och varför spekulativa AI-fynd inte får belasta säkerhetsteamet i onödan. Resultatet är en…

  • GCC 16.1 är här – och C++ tar ett stort kliv in i 2020-talet

    GCC 16.1 är här och markerar början på en ny fas för GNU Compiler Collection. Med C++20 som nytt standardläge, experimentellt stöd för kommande C++26-funktioner och förbättringar för både diagnostik, optimering och modern hårdvara är detta en release som kan få stor betydelse för utvecklare. Samtidigt kan äldre kodbaser behöva ses över när kompilatorn tar…

  • Rust 1.95 släppt – större lyft för matchning, villkorsstyrd kod och standardbiblioteket

    Rust 1.95 är här med stöd för if let-guards i match, det nya makrot cfg_select! och en lång rad nya stabila API:er i standardbiblioteket. Releasen innebär också förändringar för custom targets och ytterligare uppdateringar i Cargo och Clippy. Rust 1.95 har nu släppts och bjuder på flera nyheter för utvecklare, bland annat förbättrad mönstermatchning, ett…

  • Ghostty 1.3 – snabb terminalemulator får stora nyheter

    Ghostty 1.3 är här med flera av de funktioner som användarna länge har efterfrågat. Den GPU-accelererade terminalemulatorn får nu bland annat sökning i terminalhistoriken, inbyggda systemanpassade scrollbars, bättre tangentbordsstyrning och smartare notiser, samtidigt som utvecklarna har förbättrat både prestanda och stabilitet. Terminalprogram är ett av de viktigaste verktygen i Linux- och utvecklarvärlden. Nu har den…

  • Rust 1.94 gör språket mer uttrycksfullt och kraftfullt

    Programmeringsspråket Rust fortsätter att utvecklas i snabb takt. Den nya versionen Rust 1.94 introducerar flera förbättringar som gör språket både mer ergonomiskt och mer kraftfullt. Bland nyheterna finns en ny iterator för slice-data, förbättrad konfigurationshantering i Cargo, stöd för den senaste versionen av TOML-formatet och flera stabiliserade API:er i standardbiblioteket. Tillsammans innebär förändringarna att utvecklare…

  • NotepadNext 0.13 – klassisk enkelhet med moderna förbättringar

    NotepadNext 0.13 tar ett tydligt kliv framåt genom att kombinera den klassiska enkelheten från Notepad++ med moderna funktioner för tryggare och smidigare arbete. Med autosparade sessioner, stöd för arbetsytor och flera efterfrågade förbättringar stärker uppdateringen editorns roll som ett lättviktigt men kraftfullt verktyg för både kod och textredigering. NotepadNext, en modern och plattformsoberoende nytolkning av…

  • Micro 2.0.15 – terminalredigeraren som gör comeback

    Efter nästan ett års tystnad är den populära terminalbaserade textredigeraren Micro tillbaka med version 2.0.15. Uppdateringen fokuserar på förbättrad syntaxmarkering, stabilare redigering och ett mognare plugin-system, och markerar ett tydligt steg framåt för ett verktyg som vill kombinera enkelhet med kraften hos moderna kodredigerare – helt i terminalen. Efter en längre paus är den terminalbaserade…

  • Fish Shell 4.3 – när kommandoraden blir smartare, snyggare och mer förutsägbar

    Fish Shell 4.3 är en uppdatering som vid första anblick kan verka försiktig, men som i praktiken förändrar hur skalet upplevs i det dagliga arbetet. Istället för stora, uppseendeväckande nyheter har utvecklarna fokuserat på att göra befintliga funktioner tydligare, smartare och mer konsekventa. Resultatet är ett kommandoskal som känns mer förutsägbart, lättare att konfigurera och…

  • Ruby 4.0 – ett stort steg framåt för ett klassiskt språk

    Ruby 4.0 markerar ett av de största kliven i språkets historia, där fokus ligger på isolering, parallellism och prestanda utan att kompromissa med Rubys välkända läsbarhet. Med ny teknik som Ruby Box, en helt ny JIT-kompilator och ett kraftigt förbättrat stöd för parallell exekvering visar Ruby att språket är redo att möta moderna krav –…

  • Fresh – när terminaln möter det moderna kodverktyget

    Terminaln har länge varit utvecklarens snabbaste verktyg – men också ett av de mest avskalade. Med Fresh utmanas den bilden. Den nya öppna textredigeraren kombinerar terminalns effektivitet med moderna funktioner som annars hör hemma i grafiska IDE:er. Resultatet är ett kraftfullt kodverktyg som körs helt i textläge, men ändå erbjuder en strukturerad, visuell och förvånansvärt…

  • ”Jag ville bara lösa ett problem” – Linus Torvalds om Linux, Git och livet som envis ingenjör

    Han sitter ensam i ett ljuddämpat hemmakontor med ljusgröna väggar, en katt i knät och ett gåband han slutat använda – ändå är det härifrån en av världens viktigaste tekniska revolutioner har styrts. Utan storslagna visioner eller femårsplaner har den envisa ingenjören Linus Torvalds, skaparen av Linux och Git, förändrat hur internet fungerar, hur vi…

  • Ny dokumentärfilm berättar historien om Python

    Ny dokumentärfilm berättar historien om Python Programmeringsspråket Python har fått sin egen film. Dokumentären “Python: The Documentary” är 90 minuter lång och skildrar resan från Guido van Rossums sidoprojekt i Amsterdam på 1990-talet till dagens globala dominans. Python är idag världens mest använda programmeringsspråk, enligt det senaste TIOBE-indexet (augusti 2025). Filmen visar hur språket, som…

  • GNU Binutils 2.45 – Stort lyft för RISC-V och nya funktioner för flera arkitekturer

    GNU-projektet har släppt version 2.45 av GNU Binutils, en samling viktiga kommandoradsverktyg för lågnivåprogrammering. Binutils används för att skapa, analysera och manipulera objektfiler (mellanformatet som kompilatorer producerar innan det blir körbara program), bibliotek och färdiga exekverbara filer. Tillsammans med GCC (GNU Compiler Collection – GNU:s samling av kompilatorer), glibc (GNU C Library – standardbibliotek för…