• NixOS 26.05 ”Yarara” – Linuxdistributionen där hela systemet kan återskapas’

    NixOS 26.05 ”Yarara” är här med nya skrivbordsmiljöer, modern Linuxkärna och tusentals uppdaterade paket. Den nya versionen fortsätter att utveckla NixOS särskilda idé: att hela operativsystemet ska kunna beskrivas, återskapas och rullas tillbaka med hjälp av konfigurationsfiler – något som gör distributionen extra intressant för utvecklare, systemadministratörer och tekniskt nyfikna Linuxanvändare.

    NixOS 26.05 ”Yarara” är här med nya skrivbordsmiljöer, modern Linuxkärna och tusentals uppdaterade paket. Den nya versionen fortsätter att utveckla NixOS särskilda idé: att hela operativsystemet ska kunna beskrivas, återskapas och rullas tillbaka med hjälp av konfigurationsfiler – något som gör distributionen extra intressant för utvecklare, systemadministratörer och tekniskt nyfikna Linuxanvändare.

    NixOS 26.05, med kodnamnet ”Yarara”, är nu här. Det är den senaste versionen av den oberoende Linuxdistributionen som bygger på pakethanteraren Nix och det stora paketarkivet Nixpkgs. För den vanliga datoranvändaren märks nyheterna bland annat genom nyare skrivbordsmiljöer, uppdaterad Linuxkärna och ett stort antal nya program. För systemadministratörer och utvecklare är den stora poängen fortfarande densamma: ett system som kan beskrivas, byggas om och återskapas på ett mycket kontrollerat sätt.

    Till skillnad från många andra Linuxdistributioner bygger NixOS på idén att systemets inställningar ska vara deklarativa. Det betyder att man beskriver hur datorn ska vara konfigurerad i filer, i stället för att steg för steg klicka eller skriva kommandon som förändrar systemet. Resultatet blir ett operativsystem som är ovanligt lätt att reproducera. Har man rätt konfigurationsfiler kan man i princip återskapa samma system igen, på samma eller en annan dator.

    Linux 6.18 och modernare skrivbord

    I NixOS 26.05 är Linux 6.18 LTS standardkärna. Det innebär att användarna får en modern kärna med långsiktigt stöd, vilket är viktigt både för stabilitet och hårdvarustöd. Samtidigt finns andra kärnversioner fortfarande tillgängliga för den som behöver en annan gren, exempelvis av kompatibilitetsskäl eller för särskild hårdvara.

    För den som använder NixOS som skrivbordssystem finns också stora uppdateringar. GNOME 50 och KDE Plasma 6.6.5 ingår i utgåvan. Det gör att NixOS följer med i utvecklingen av de två största Linux-skrivbordsmiljöerna, samtidigt som distributionens mer ovanliga systemmodell ligger kvar under ytan.

    GNOME riktar sig ofta till användare som vill ha ett rent och sammanhållet skrivbord, medan KDE Plasma brukar uppskattas av dem som vill kunna anpassa nästan allt. Att båda finns i aktuella versioner gör NixOS 26.05 intressant både för experimentella användare och för dem som vill ha en mer traditionell Linuxdator.

    Systemd tar över tidig uppstart

    En av de viktigaste tekniska förändringarna i NixOS 26.05 är att systemd-baserad stage 1 nu används som standard. Stage 1 är den tidiga delen av uppstarten, innan hela systemet är igång. Det är här datorn förbereder sådant som filsystem, diskar och annan grundläggande startlogik.

    Tidigare använde NixOS en skriptbaserad lösning för denna tidiga uppstart. Den gamla modellen är nu markerad som föråldrad och planeras att tas bort i kommande NixOS 26.11. För användare som inte modifierat uppstarten kraftigt kommer förändringen troligen att märkas ganska lite i vardagen. För mer avancerade installationer, specialsystem och servrar är det däremot en viktig förändring att känna till.

    Tusentals paket har lagts till och uppdaterats

    Nixpkgs, det stora paketarkiv som NixOS bygger på, har fått en omfattande uppdatering. I samband med 26.05 har över 20 000 nya paket lagts till och ungefär lika många har uppdaterats. Samtidigt har ett stort antal gamla eller föråldrade paket tagits bort.

    Det här är en viktig del av hur en Linuxdistribution hålls frisk över tid. Nya program tillkommer, gamla versioner ersätts, och paket som inte längre går att underhålla behöver rensas bort. För användaren betyder det fler aktuella program, men också att vissa äldre lösningar kan behöva justeras vid uppgradering.

    Även NixOS-modulerna har vuxit. Nya moduler och konfigurationsalternativ gör att fler tjänster och systemfunktioner kan beskrivas direkt i NixOS konfigurationsmodell. Det är just modulsystemet som gör NixOS speciellt: i stället för att konfigurera varje tjänst manuellt kan man ofta skriva in önskat tillstånd i systemets konfigurationsfil.

    En distribution för den som vill ha kontroll

    NixOS är inte den enklaste Linuxdistributionen för nybörjaren. Den kräver ofta att man tänker annorlunda än i Ubuntu, Debian eller Fedora. Men belöningen är kontroll. Det går att testa förändringar, rulla tillbaka systemet och bygga upp installationer på ett sätt som är svårt att göra lika konsekvent i många andra distributioner.

    Det gör NixOS särskilt attraktivt för utvecklare, systemadministratörer och tekniskt nyfikna användare. Om en uppdatering går fel finns det ofta möjlighet att starta en tidigare systemgeneration. Om man vill flytta en konfiguration till en annan dator kan mycket av arbetet göras genom att återanvända samma systembeskrivning.

    Slutet närmar sig för äldre versioner

    I samband med att NixOS 26.05 släpps blir den tidigare versionen NixOS 25.11 ”Xantusia” föråldrad. Den kommer att nå slutet av sin livscykel efter den 30 juni 2026. Det innebär att användare av äldre system bör börja planera för uppgradering, särskilt om datorn används i produktion eller på annat sätt behöver säkerhetsuppdateringar.

    NixOS 26.05 kommer i sin tur att få felrättningar och säkerhetsuppdateringar fram till den 31 december 2026. Det ger användarna ungefär ett halvår att använda versionen som stabil bas innan nästa större version tar över.

    Sista rundan för x86_64-darwin

    En annan viktig förändring gäller användare av Nixpkgs på macOS. NixOS 26.05 är den sista Nixpkgs-utgåvan med stöd för x86_64-darwin, alltså Intelbaserade Mac-datorer. Binärbyggen och plattformsstöd fortsätter till slutet av 2026, men från och med Nixpkgs 26.11 kommer paket inte längre att byggas eller stödjas för denna plattform.

    Det speglar en större förändring i datorvärlden. Apple har lämnat Intel bakom sig till förmån för egna Arm-baserade Apple Silicon-processorer. För Nixpkgs innebär det att resurserna framöver koncentreras på modernare plattformar.

    Sammanfattning

    NixOS 26.05 ”Yarara” är inte bara ännu en Linuxrelease med nya paket. Den fortsätter att utveckla ett annorlunda sätt att tänka kring operativsystem. Där andra distributioner ofta fokuserar på traditionell installation och löpande manuell administration, bygger NixOS på idén att hela systemet ska kunna beskrivas, återskapas och rullas tillbaka.

    Med Linux 6.18 LTS, GNOME 50, KDE Plasma 6.6.5, tusentals uppdaterade paket och systemd stage 1 som standard är 26.05 en viktig utgåva för både skrivbordsanvändare och mer avancerade Linuxmiljöer. För den som vill förstå vart framtidens mer reproducerbara Linuxsystem kan vara på väg är NixOS fortfarande en av de mest intressanta distributionerna att följa.

    https://nixos.org/blog/announcements/2026/nixos-2605

    Faktaruta: NixOS 26.05 ”Yarara”

    Version: NixOS 26.05

    Kodnamn: Yarara

    Standardkärna: Linux 6.18 LTS

    Skrivbordsmiljöer: GNOME 50 och KDE Plasma 6.6.5

    Viktig nyhet: systemd-baserad stage 1 används som standard

    Kompilatorer: GCC 15 och LLVM 21

    Support: säkerhets- och felrättningsuppdateringar till 31 december 2026

    Föregående version: NixOS 25.11 ”Xantusia” fasas ut efter 30 juni 2026

    Installation: finns som grafisk installationsavbild och minimal installationsavbild för 64-bitars AMD/Intel och Arm

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

    ”`

Etikett: utvecklare

  • NixOS 26.05 ”Yarara” – Linuxdistributionen där hela systemet kan återskapas’

    NixOS 26.05 ”Yarara” är här med nya skrivbordsmiljöer, modern Linuxkärna och tusentals uppdaterade paket. Den nya versionen fortsätter att utveckla NixOS särskilda idé: att hela operativsystemet ska kunna beskrivas, återskapas och rullas tillbaka med hjälp av konfigurationsfiler – något som gör distributionen extra intressant för utvecklare, systemadministratörer och tekniskt nyfikna Linuxanvändare. NixOS 26.05 ”Yarara” är…

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