• Moxnox 1.0 – ett nytt operativsystem som förenar Windows NT och Unix

    Vad händer om man tar några av de bästa idéerna från Windows NT, kombinerar dem med Unix och bygger ett helt nytt operativsystem från grunden? Det är precis vad utvecklaren Mark Harmstone har gjort. Resultatet heter Moxnox, och nu har version 1.0 släppts som öppen källkod.

    När man talar om operativsystem handlar diskussionen nästan alltid om Windows, Linux eller macOS. Men bakom dessa välkända namn finns en värld av experimentella system där programmerare försöker hitta nya sätt att få datorer att fungera.

    Ett av de senaste exemplen är Moxnox 1.0, som släpptes den 26 oktober 2026.

    Bakom projektet står den brittiske programmeraren Mark Harmstone, som tidigare gjort sig känd genom WinBtrfs, en drivrutin som gör det möjligt för Windows att läsa och skriva till Linux-filsystemet Btrfs.

    Sedan 2022 har han arbetat med Moxnox som ett hobbyprojekt. Det som började som ett tekniskt experiment har nu vuxit till ett operativsystem med omkring 130 000 rader C++-kod.

    Men Moxnox är varken ännu en Linuxdistribution eller en kopia av Windows.

    Windows under huven – Unix på utsidan

    För att förstå vad som gör Moxnox speciellt behöver vi titta på hur ett operativsystem egentligen fungerar.

    I centrum finns operativsystemets kärna, ofta kallad kernel. Den ansvarar för grundläggande funktioner som att hantera minne, kommunicera med hårdvara och fördela processortid mellan olika program.

    Windows bygger på en kärnarkitektur som har sitt ursprung i Windows NT, medan Linux använder en annan konstruktion.

    Moxnox hämtar inspiration från Windows NT:s sätt att låta program kommunicera med operativsystemet genom så kallade systemanrop.

    Samtidigt använder det många av de principer som gjort Unix och Linux populära bland programmerare och systemadministratörer.

    Det innebär exempelvis att katalogstrukturen påminner om Linux, med en rotkatalog som heter / och sökvägar som /bin i stället för Windows enhetsbokstäver som C:\.

    Systemet stöder dessutom Unix-funktioner som fork(), som gör det möjligt för ett program att skapa en ny process genom att kopiera en befintlig.

    Man kan beskriva Moxnox som ett försök att förena två olika operativsystemfilosofier, utan att behöva använda vare sig Windows eller Linux som grund.

    Windows-program fungerar inte – trots EXE-filer

    En intressant detalj är att Moxnox använder samma grundläggande programformat som Windows.

    Körbara program lagras i formatet Portable Executable, förkortat PE, och har filändelsen .exe. Programbibliotek använder .dll.

    Linux använder normalt ELF-formatet för sina körbara program.

    Det betyder däremot inte att man kan installera Microsoft Office eller andra vanliga Windowsprogram i Moxnox.

    Moxnox kan i dagsläget inte köra vanliga Windowsprogram.

    Anledningen är att de programmeringsgränssnitt och systembibliotek som Windowsprogram förväntar sig ännu inte finns på plats.

    En framtida möjlighet skulle kunna vara att använda delar av Wine-projektet för att skapa denna kompatibilitet, men något sådant stöd är ännu inte färdigt.

    Moxnox skiljer sig därmed från ReactOS, vars ambition är att återskapa Windows kompatibilitet.

    Linuxanvändare kommer att känna igen sig

    Trots sin Windowsinspirerade teknikmiljö erbjuder Moxnox en ganska välbekant upplevelse för den som är van vid Unix eller Linux.

    Flera populära program har redan anpassats till systemet.

    Här finns bland annat Bash, GNU Coreutils, Git, Python, Perl, Vim, Nano, OpenSSH och OpenSSL.

    Även viktiga utvecklingsverktyg som GCC, LLVM och Rust har porterats, även om det fortfarande finns begränsningar. GCC finns exempelvis endast för x86-64.

    Att programmen har porterats innebär att deras källkod har anpassats och kompilerats för det nya operativsystemet. Man kan alltså inte bara kopiera över ett vanligt Linuxprogram och förvänta sig att det fungerar.

    En annan teknisk milstolpe är att Moxnox har blivit self-hosting.

    Det innebär att operativsystemet har kommit så långt att det kan användas för att kompilera sin egen källkod.

    Det är en betydande prestation för ett hobbyprojekt, även om vissa stora program, bland annat GCC och Rust, ännu inte kan byggas direkt inifrån systemet.

    Btrfs är hjärtat i filhanteringen

    Valet av filsystem är knappast någon överraskning.

    Mark Harmstone har lång erfarenhet av Btrfs genom arbetet med WinBtrfs, och Moxnox använder därför Btrfs för lagringen.

    Btrfs är ett modernt filsystem som bland annat erbjuder kontrollsummor för dataintegritet, ögonblicksbilder och avancerade lagringsfunktioner.

    Men här kommer en viktig varning.

    Moxnox egen Btrfs-implementation är fortfarande experimentell och har inte genomgått omfattande tester.

    Utvecklaren avråder uttryckligen från att använda den tillsammans med filsystem som innehåller värdefulla data.

    Den som vill experimentera bör därför använda en virtuell disk eller en separat lagringsenhet utan viktig information.

    Fungerar även på ARM och Raspberry Pi 5

    Moxnox stöder två olika processorarkitekturer: x86-64, som används i de flesta moderna PC-datorer, och ARM64, som bland annat förekommer i enkortsdatorer och vissa bärbara datorer.

    För vanliga PC-datorer krävs stöd för instruktionsuppsättningen x86-64-v3. Det innebär att en del äldre 64-bitarsprocessorer inte kan användas.

    På ARM-sidan krävs ARMv8.1 eller senare.

    Det gör att även Raspberry Pi 5 kan köra Moxnox, förutsatt att den använder lämplig UEFI-firmware.

    Systemet har redan drivrutiner för bland annat NVMe, SATA, USB-lagring, SD-kort och vissa nätverkskort från Realtek.

    Stödet för kringutrustning är dock långt ifrån lika omfattande som i Linux eller Windows.

    Glöm skrivbordet – här är det terminalen som gäller

    Den som förväntar sig ett grafiskt skrivbord med fönster, ikoner och muspekare kommer att bli besviken.

    Moxnox 1.0 saknar nämligen en grafisk skrivbordsmiljö.

    Systemet arbetar framför allt med textbaserade gränssnitt och kommandoraden. Det finns grundläggande stöd för bildskärmsutmatning, men ännu inget färdigt grafiskt användargränssnitt.

    Det är med andra ord ett operativsystem som i första hand riktar sig till programmerare, operativsystemsentusiaster och personer som tycker om att experimentera med datorernas mer grundläggande funktioner.

    Det saknas dessutom flera saker som vi normalt tar för givna.

    Exempelvis finns ännu inget fullständigt säkerhetssystem, inget riktigt fleranvändarstöd och inget ordentligt stöd för olika tangentbordslayouter eller tidszoner.

    Även prestandan behöver förbättras, framför allt när det gäller minneshantering och nätverkskommunikation.

    Moxnox är därför inte ett system som man bör använda som sin huvudsakliga arbetsmiljö.

    Så kan du prova Moxnox själv

    För den som är nyfiken finns färdiga diskavbilder för både x86-64 och ARM64 att ladda ner.

    Det enklaste sättet att testa operativsystemet är med QEMU, en programvara som kan emulera och virtualisera datorer.

    På så vis kan man starta Moxnox i en virtuell miljö utan att behöva installera det på datorns riktiga hårddisk.

    Det går också att installera systemet på fysisk hårdvara, men då krävs viss erfarenhet av partitionering, filsystem och uppstart via UEFI.

    Källkoden och installationsanvisningarna finns på projektets GitHub-sida:

    Projekt: https://github.com/maharmstone/moxnox

    Ladda ner Moxnox 1.0: https://github.com/maharmstone/moxnox/releases/tag/v1.0

    Varför behövs ännu ett operativsystem?

    Det är kanske den mest intressanta frågan.

    Världen lider knappast brist på operativsystem. Linux är etablerat inom servrar och utveckling, Windows dominerar fortfarande stora delar av PC-marknaden och macOS har sin självklara plats i Apples ekosystem.

    Men Moxnox handlar inte i första hand om att konkurrera med dessa system.

    Det handlar snarare om att utforska alternativa tekniska lösningar och visa att det går att kombinera idéer som traditionellt hör hemma i olika operativsystem.

    Windows NT:s arkitektur har flera tekniska egenskaper som sällan uppmärksammas utanför Windowsvärlden. Genom att kombinera dessa med Unix programmeringsmodell visar Harmstone hur ett annorlunda operativsystem skulle kunna se ut.

    Och kanske är det just därför Moxnox är intressant.

    Inte för att det kommer att ersätta Windows eller Linux nästa år, utan för att det påminner oss om att operativsystem inte behöver byggas på samma sätt som de alltid har gjort.

    Moxnox 1.0 är ännu inte ett färdigt alternativ för vanliga datoranvändare. Men som tekniskt experiment visar det hur mycket som faktiskt går att åstadkomma när någon bestämmer sig för att bygga sitt eget operativsystem från grunden.

    ● ● ●

    > FAKTA: MOXNOX 1.0_

    System: Moxnox 1.0

    Utvecklare: Mark Harmstone

    Typ: Fristående operativsystem med öppen källkod

    Projektstart: 2022

    Programspråk: C++ (cirka 130 000 kodrader)

    Arkitektur: Windows NT-inspirerade systemanrop och Unix/POSIX-miljö

    Processorstöd: x86-64-v3 och ARM64 (ARMv8.1+)

    Filsystem: Btrfs

    Programformat: Windows PE (.exe och .dll)

    Gränssnitt: Textbaserad terminal, inget grafiskt skrivbord

    Programvara: Bash, GCC, LLVM, Git, Python, Perl, Rust, Vim, Nano och OpenSSH

    Hårdvara: NVMe, SATA, USB, SD-kort och utvalda nätverkskort

    Raspberry Pi 5: Stöds med lämplig UEFI-firmware

    Windowsprogram: Kan inte köras direkt

    Status: Experimentellt hobbyprojekt

    [!] VARNING: Moxnox är inte avsett för produktionsbruk. Använd endast testdiskar utan viktiga data.

    root@moxnox:~$ GitHub / Källkod

    root@moxnox:~$ Ladda ner Moxnox 1.0

  • Linus Torvalds testar AI-skriven Linuxkod – tredubblar läshastigheten

    Linux skapare Linus Torvalds har tagit hjälp av AI-verktyget Claude Code för att optimera Linuxkärnan. I ett experiment har han lyckats mer än tredubbla antalet läsoperationer per sekund genom att förändra hur operativsystemet hanterar arbetsminnet. Resultatet visar AI-teknikens möjligheter inom avancerad programmering, men väcker också frågor om tillförlitlighet och säkerhet.

    När processorkärnorna konkurrerar om minnet

    Linux används i allt från mobiltelefoner och persondatorer till servrar och superdatorer. I centrum finns Linuxkärnan, som bland annat ansvarar för datorns minne, processorer och lagringsenheter.

    En viktig uppgift är att se till att program snabbt kan läsa information från filer.

    För att undvika onödiga läsningar från hårddiskar och SSD-enheter sparar Linux ofta använd fildata i arbetsminnet. Tekniken kallas page cache, eller sidcache.

    Det fungerar ungefär som att ha viktiga dokument liggande på skrivbordet i stället för att behöva gå till arkivskåpet varje gång man behöver läsa dem.

    Men även när informationen redan finns i arbetsminnet måste Linux hålla reda på vilka delar av minnet som används.

    Här uppstår ett problem.

    När flera programtrådar samtidigt läser information från samma fil behöver kärnan normalt uppdatera referensräknare som håller reda på hur många som använder en viss minnessida.

    Varje uppdatering går snabbt, men när många processorkärnor arbetar parallellt kan de börja konkurrera om samma räknare.

    Det kan jämföras med att åtta personer vill läsa samma bok, men först måste skriva in sig i en gemensam liggare och sedan stryka sitt namn när de läst klart.

    Själva läsningen går snabbt. Det är administrationen runt omkring som bromsar arbetet.

    AI hjälper till att hitta en snabbare lösning

    Linus Torvalds bestämde sig för att undersöka om denna administration kunde minskas.

    Till sin hjälp använde han Claude Code, ett AI-baserat programmeringsverktyg utvecklat av företaget Anthropic.

    Resultatet blev åtta ändringar, så kallade patchar, som påverkar hur Linuxkärnan läser information från sidcachen.

    Den nya metoden bygger på en teknik som redan finns i Linux och kallas Read-Copy-Update, förkortat RCU.

    RCU gör det möjligt att under vissa förutsättningar läsa information utan att först behöva öka en referensräknare.

    I stället ser systemet till att minnet inte återanvänds förrän pågående läsoperationer har kunnat avslutas.

    Det betyder att flera processorkärnor kan läsa samma information utan att hela tiden behöva uppdatera gemensamma räknare.

    Resultatet blir mindre konkurrens mellan processorerna och därmed möjlighet till högre prestanda.

    Från 10 till över 30 miljoner läsningar per sekund

    För att undersöka hur stor skillnaden blev genomförde Torvalds tester på sin egen bärbara dator.

    Datorn hade en Intel Core i7-8565U med fyra processorkärnor och åtta trådar.

    I ett av testerna fick åtta trådar upprepade gånger läsa 16 byte från samma fil, som redan fanns i arbetsminnets cache.

    Resultatet var anmärkningsvärt.

    TestTidigare kodNy kod
    8 trådar10 miljoner/s30–33 miljoner/s
    4 trådar9–12 miljoner/s25–26 miljoner/s
    1 tråd8 miljoner/sNästan 9 miljoner/s

    Med åtta trådar ökade kapaciteten alltså från omkring 10 miljoner läsoperationer per sekund till över 30 miljoner.

    Det motsvarar en förbättring på drygt 200 procent.

    Även med fyra trådar blev förbättringen betydande. Däremot var skillnaden ganska liten när endast en tråd användes.

    Det visar att den stora vinsten framför allt kommer av att minska konkurrensen mellan processorkärnorna.

    Det betyder däremot inte att Linux generellt har blivit tre gånger snabbare. Förbättringen gäller en mycket specifik typ av arbetsbelastning där flera trådar läser små mängder information från samma fil.

    AI skrev både programkod och tester

    Det kanske mest uppseendeväckande med experimentet är hur arbetet genomfördes.

    I dokumentationen till ändringarna, daterad den 10 oktober 2026, berättar Torvalds öppet att han använt Claude Code för en stor del av utvecklingsarbetet.

    AI-verktyget hjälpte till att skriva själva programkoden, skapa testprogrammen, granska lösningen och formulera ett första utkast till dokumentationen.

    Torvalds påpekar samtidigt att arbetet genomfördes under hans ledning och att han själv utförde prestandamätningarna.

    Det är särskilt intressant eftersom Linuxkärnan är ett av världens mest granskade programvaruprojekt.

    Ett litet programmeringsfel i kärnan kan orsaka allt från försämrad prestanda till systemkrascher och säkerhetsproblem.

    Att AI nu används för att utveckla kod på denna nivå visar hur långt tekniken har kommit.

    Samtidigt är det viktigt att understryka att AI inte har fått fria händer att ändra Linux. Torvalds har styrt arbetet och ansvarat för att bedöma resultatet.

    Snabbare kod kan också skapa nya problem

    Trots de imponerande resultaten är den nya lösningen långt ifrån färdig.

    Den förändrade minneshanteringen innebär bland annat att vissa minnessidor måste behållas längre innan de kan återanvändas.

    Det kan öka belastningen på minnessystemet och försämra prestandan i andra situationer.

    När informationen som ska läsas inte redan finns i sidcachen kan den nya metoden dessutom innebära extra arbete.

    Torvalds pekar själv på flera områden som behöver undersökas, bland annat minnesallokering, kompatibilitet och risken för prestandaförsämringar.

    Det finns också begränsningar i själva mätningarna.

    Testerna genomfördes på en enda dator med filsystemet ext4, och vissa säkerhetsåtgärder i processorn var avstängda.

    Det återstår därför att undersöka hur tekniken fungerar på andra processorer, med andra filsystem och under verkliga arbetsbelastningar.

    När kommer förbättringen till Ubuntu och Debian?

    För vanliga Linuxanvändare innebär experimentet ännu ingen direkt förändring.

    Ändringarna finns i en särskild experimentell utvecklingsgren som heter noref-filemap-read-with-llm.

    Den är baserad på Linux 7.3-rc6 med ytterligare korrigeringar, men ändringarna har inte införts i den ordinarie Linuxkärnan.

    Det innebär att användare av exempelvis Ubuntu, Debian och Fedora inte automatiskt får del av förbättringen.

    Om tekniken visar sig vara tillförlitlig skulle den på sikt kunna vara särskilt användbar i servrar och andra system där många processorkärnor samtidigt läser information från samma filer.

    För en vanlig persondator som används till webbsurfning, e-post och ordbehandling är det däremot inte säkert att förbättringen skulle märkas.

    Kan AI bli framtidens kärnprogrammerare?

    Experimentet väcker en större fråga: Vilken roll kommer artificiell intelligens att spela i framtidens programvaruutveckling?

    AI används redan för att skriva program, föreslå förbättringar och upptäcka fel. Men här handlar det om betydligt mer avancerad programmering.

    Minneshantering i en operativsystemskärna är ett område där små misstag kan få mycket stora konsekvenser.

    Att Claude Code har kunnat hjälpa Linus Torvalds att utveckla och testa en lösning på denna nivå är därför anmärkningsvärt.

    Det visar att AI kan fungera som ett kraftfullt hjälpmedel även för mycket erfarna programmerare.

    Samtidigt visar experimentet varför mänsklig kompetens fortfarande behövs.

    AI kan generera programkod och föreslå tekniska lösningar, men någon måste förstå konsekvenserna, granska säkerheten och avgöra om resultatet verkligen är en förbättring.

    Det mest intressanta är därför inte bara att en AI-assisterad kodändring lyckades tredubbla prestandan i ett specialiserat test, utan att AI har kunnat bidra till utvecklingsarbetet i själva hjärtat av Linux.

    Om ändringarna någonsin blir en del av den officiella Linuxkärnan återstår att se. Men Torvalds experiment visar redan hur samarbetet mellan människa och artificiell intelligens kan öppna nya möjligheter inom avancerad programvaruutveckling.

    root@linux:~# cat /proc/ai-performance

    > LINUX KERNEL / AI-EXPERIMENT
    UTVECKLARE: Linus Torvalds
    AI-VERKTYG: Claude Code
    TEKNIK: RCU / Page Cache
    PROCESSOR: Intel Core i7-8565U
    TRÅDAR: 8
    TEST: Upprepad läsning av 16 byte

    [ PRESTANDAMÄTNING ]
    TIDIGARE KOD:
    10 miljoner läsningar/s
    EXPERIMENTELL KOD:
    30–33 miljoner läsningar/s
    >> UPP TILL 3,3x SNABBARE <<

    STATUS: EXPERIMENTELL KOD
    KERNEL: Linux 7.3-rc6 (testbas)
    MAINLINE: EJ INFÖRD
    DATUM: 2026-10-10
    OBS: Resultatet gäller ett specifikt prestandatest, inte Linux generellt.
    root@linux:~# █
  • 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
    • ”`
  • Ubuntu 26.10 tar sina första steg – men det här är bara början

    Ubuntu 26.10 ”Stonking Stingray” har nu dykt upp i sin första tidiga testversion. Det är långt ifrån ett färdigt operativsystem, men för utvecklare, testare och Linuxintresserade ger den första snapshot-versionen en tydlig försmak av vad nästa Ubuntu-utgåva kan komma att bjuda på när den släpps hösten 2026.

    En första titt på nästa Ubuntu

    Ubuntu 26.10, med det färgstarka kodnamnet ”Stonking Stingray”, har nu tagit sina första offentliga steg. Canonical har släppt de första så kallade snapshot-avbilderna, alltså tidiga testversioner av operativsystemet som längre fram ska bli nästa stora Ubuntu-version efter Ubuntu 26.04 LTS.

    Inte ett färdigt system ännu

    För den vanliga användaren kan det låta som att Ubuntu 26.10 redan är färdigt, men så är det inte. Det här är snarare en tidig byggarbetsplats än ett färdigt hus. Grunden är lagd, men väggarna ska justeras, elen ska dras och inredningen är långt ifrån klar.

    Vad är en snapshot-version?

    En snapshot-version är till för utvecklare, testare och nyfikna entusiaster som vill se hur nästa version av Ubuntu växer fram. Den används för att hitta fel, testa nya programversioner och upptäcka problem innan den färdiga versionen når vanliga användare.

    Bygger på Ubuntu 26.04 LTS

    Ubuntu 26.10 bygger i detta tidiga skede till stor del på Ubuntu 26.04 LTS, som släpptes den 23 april 2026. Det är vanligt i början av en ny utvecklingscykel. Man tar den senaste stabila versionen som grund och börjar sedan steg för steg byta ut delar mot nyare komponenter.

    Linuxkärnan är systemets motor

    I den första snapshot-versionen används Linuxkärnan 7.0 och skrivbordsmiljön GNOME 50. Linuxkärnan kan beskrivas som operativsystemets motor. Det är den som sköter kontakten med datorns hårdvara, till exempel processor, minne, lagring, nätverk och grafikkort. GNOME är i sin tur den grafiska skrivbordsmiljön, alltså det användaren möter i form av fönster, menyer, inställningar och appar.

    Nyare teknik väntar under utvecklingen

    Under de kommande månaderna väntas Ubuntu 26.10 få ännu nyare teknik. Bland annat planeras GNOME 51, Linuxkärnan 7.2, grafikstacken Mesa 26.2 och kompilatorn GCC 16.1. För den som inte följer Linuxvärlden dagligen kan dessa namn låta tekniska, men de påverkar sådant som prestanda, hårdvarustöd, grafik, spel, energiförbrukning och möjligheten att köra modern programvara.

    Vägen fram till färdig version

    Den färdiga versionen av Ubuntu 26.10 är planerad till 15 oktober 2026. Innan dess kommer en betaversion den 24 september, vilket brukar vara den första versionen som är mer sammanhängande för bredare testning. Canonical planerar också två testveckor, den 2 juli och den 27 augusti, där användare kan hjälpa till att prova systemet och rapportera buggar.

    Bör bara testas på rätt plats

    Det är dock viktigt att förstå att den här första snapshot-versionen inte är avsedd för vardagsbruk. Den kan krascha, sakna funktioner eller innehålla fel som gör datorn svår att använda. Därför bör den bara installeras på en testdator eller i en virtuell maskin. Den som behöver en stabil dator för arbete, studier eller familjens vardagsanvändning bör hålla sig till Ubuntu 26.04 LTS.

    Alla ISO-filer finns inte ännu

    En annan detalj är att alla ISO-avbilder ännu inte finns tillgängliga. Bland annat saknas den vanliga 64-bitars Ubuntu Desktop-versionen för amd64 i den första omgången. Den väntas i stället komma med den andra snapshot-versionen, som är planerad till slutet av juni.

    En korttidsversion för den nyfikne

    Ubuntu 26.10 blir en så kallad interim-version. Det betyder att den bara får stöd i nio månader, fram till juni 2027. Den typen av Ubuntu-version passar främst användare som vill ha nyare programvara och funktioner. För den som prioriterar långsiktig stabilitet är LTS-versionerna, som Ubuntu 26.04 LTS, oftast ett bättre val.

    Öppen utveckling i praktiken

    Samtidigt är snapshot-versionerna viktiga. De visar hur öppen utveckling fungerar i praktiken. I stället för att allt sker bakom stängda dörrar kan användare och utvecklare följa processen, testa systemet och bidra med felrapporter. På så sätt blir den färdiga versionen bättre.

    En försmak av framtidens Linuxskrivbord

    Ubuntu 26.10 är alltså inte redo att ersätta dagens stabila system. Men den första snapshot-versionen markerar startskottet för nästa kapitel i Ubuntus utveckling. För den teknikintresserade är det en möjlighet att kika in i framtidens Linuxskrivbord redan nu.

    https://cdimage.ubuntu.com/ubuntu/releases/26.10/snapshot-1

    Teknisk faktaruta: Ubuntu 26.10 ”Stonking Stingray”

    Version: Ubuntu 26.10

    Kodnamn: Stonking Stingray

    Typ av version: Interim-version, alltså en korttidsversion mellan två LTS-utgåvor.

    Första snapshot: Tidig testversion för utvecklare, testare och nyfikna användare.

    Bygger inledningsvis på: Ubuntu 26.04 LTS ”Resolute Raccoon”.

    Linuxkärna i första snapshot: Linux 7.0

    Skrivbordsmiljö i första snapshot: GNOME 50

    Planerade nyare komponenter: GNOME 51, Linux 7.2, Mesa 26.2 och GCC 16.1.

    Planerad betaversion: 24 september 2026

    Planerat slutligt släpp: 15 oktober 2026

    Stödperiod: Cirka nio månader, fram till juni 2027.

    Rekommenderad användning: Testdator eller virtuell maskin. Bör inte användas på en viktig vardagsdator.

    Passar bäst för: Utvecklare, Linuxentusiaster och användare som vill testa kommande teknik innan den når stabila Ubuntu-versioner.

  • 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
  • Stöd för AMD Zen 6, Arm v9.7 och mer RISC-V

    När nästa generations processorer från AMD, Arm och RISC-V står för dörren måste även mjukvarans grundverktyg ligga steget före. Med GNU Binutils 2.46 tar utvecklarvärlden ett viktigt kliv mot framtiden genom att lägga till stöd för kommande CPU-arkitekturer, förbättrad felsökning och en moderniserad verktygskedja som gör fria operativsystem redo för hårdvara som ännu inte nått marknaden.

    När nya generationer av processorer närmar sig marknaden räcker det inte med snabbare kisel och fler kärnor. För att operativsystem och program verkligen ska kunna utnyttja ny hårdvara måste verktygen som bygger dem hänga med. Med version 2.46 tar GNU Binutils ett tydligt kliv framåt och gör utvecklare redo för kommande CPU-arkitekturer.

    Stöd för AMD Zen 6, Arm v9.7 och mer RISC-V

    En av de mest uppmärksammade nyheterna är att Binutils 2.46 nu har stöd för AMD:s kommande Zen 6-arkitektur. Även om processorerna ännu inte finns på marknaden innebär detta att mjukvara kan byggas och testas i god tid, så att ekosystemet är redo vid lansering.

    På Arm-sidan fortsätter utvecklingen i snabb takt. Stödet för Arm v9.6 är nu färdigställt, samtidigt som Arm v9.7 introduceras via flaggan -march=armv9.7-a. Dessutom finns tidigt stöd för framtida tekniker som POE2 och vMTE, vilket visar att verktygskedjan redan blickar framåt mot nästa generation av Arm-baserade system.

    Även RISC-V får ett lyft. Nya tillägg som sdtrig v1.0 och ssstrict v1.0 stärker stödet för den öppna instruktionsuppsättningen och gör plattformen mer attraktiv för både forskning och kommersiella produkter.

    SFrame Version 3 blir standard

    Assemblern i Binutils 2.46 använder nu SFrame Version 3 som standard. Det här påverkar framför allt hur stackramar och felsökningsinformation hanteras. För utvecklare innebär det bättre stöd för mycket stora program, över 2 gigabyte i storlek, mer flexibla ramlayouter och tydligare information om yttersta funktionsramar. Även hanteringen av signaler förbättras, vilket ger mer tillförlitliga bakspår vid felsökning.

    Nytt delat bibliotek för SFrame

    Som en följd av SFrame-uppdateringen introduceras ett nytt versionerat delat bibliotek, libsframe.so.3. Det använder symbolversionering under namnet LIBSFRAME_3.0 och är ett viktigt steg för att säkerställa långsiktig kompatibilitet mellan olika versioner av verktygen.

    Striktare kontroller och färre dolda fel

    Utvecklarna har också passat på att skärpa den interna kvaliteten. Verktyg som objcopy gör nu striktare kontroller av målformat, vilket gör att felaktig användning upptäcks tidigare i byggprocessen. Det äldre, mer tillåtande beteendet finns fortfarande kvar, men kräver nu att man uttryckligen anger vilket format som ska användas.

    Städning bland gamla plattformar

    För att minska underhållsbördan har stödet för vissa äldre och i praktiken oanvända mål tagits bort. Exempel på detta är NaCl och Solaris på PowerPC. Genom att rensa bort sådant som inte längre används kan utvecklingen fokusera på moderna och relevanta plattformar.

    Fler förbättringar under huven

    Utöver de stora nyheterna innehåller Binutils 2.46 mängder av buggfixar och mindre förbättringar. Programmet readelf kan nu visa innehållet i Global Offset Tables, stödet för länkartaggning har förbättrats och källkodstarbollarna skapas på ett sätt som underlättar reproducerbara byggen.

    En tyst men viktig uppdatering

    GNU Binutils 2.46 är ingen version som märks direkt av vanliga användare, men för utvecklare och hela open source-världen är den central. Den gör verktygskedjan redo för framtidens processorer, förbättrar felsökning i stora program och minskar teknisk skuld. Det är ännu ett exempel på hur grundläggande infrastruktur ofta utvecklas i det tysta, men med enorm betydelse för allt som byggs ovanpå.

    https://sourceware.org/pipermail/binutils/2026-February/148149.html

    Teknisk faktaruta: GNU Binutils 2.46
    Vad är det?
    Verktygssamling för binärhantering i GNU-toolchain, bl.a. assembler (as), länkare (ld), objcopy, readelf.
    Processor- och ISA-stöd
    • AMD: igenkänning/stöd för Zen 6
    • Arm: Arm v9.6 färdigställt, Arm v9.7 via -march=armv9.7-a
    • Arm: tidigt stöd för kommande tekniker (POE2, vMTE)
    • RISC-V: nya tillägg, bl.a. sdtrig v1.0 och ssstrict v1.0
    SFrame (stack frame-format)
    Assemblern emitterar SFrame Version 3 som standard, med stöd för binärer > 2 GiB, flexiblare frame-layout, markering av yttersta frames och förbättrad hantering av signal-trampoliner.
    Nytt bibliotek
    Ny versionerad delad bibliotekfil: libsframe.so.3
    Symbolversionering: LIBSFRAME_3.0
    Skärpta kontroller
    Striktare validering och plugin-hantering. Exempel: objcopy kontrollerar målformat hårdare; äldre beteende kan kräva att utdataformat anges explicit.
    Övrigt
    • readelf kan visa innehåll i Global Offset Tables (GOT)
    • förbättrad linker-taggning
    • borttaget stöd för vissa äldre mål (t.ex. NaCl, Solaris/PowerPC)
    • jämn release: GOLD-länkaren ingår i källträdet
  • QNX tar steget mot skrivbordet – ett realtids-OS blir självbärande för utvecklare

    QNX tar ett ovanligt kliv från det dolda till det synliga. Med lanseringen av en självhostad Developer Desktop för QNX 8.0 kan utvecklare för första gången arbeta i en fullständig skrivbordsmiljö och bygga sina program direkt på operativsystemet. Satsningen markerar ett tydligt skifte för QNX – från strikt inbyggt realtids-OS till en mer öppen och utvecklarvänlig plattform.

    Det realtidsoperativsystem som i decennier har dolt sig bakom bilars instrumentpaneler, industristyrsystem och medicinteknik tar nu ett ovanligt kliv ut i rampljuset. QNX har lanserat sin första Self-Hosted Developer Desktop för QNX 8.0 – en fullfjädrad skrivbordsmiljö där utvecklare kan bygga, testa och köra program direkt på QNX.
    Det kan låta som en självklarhet för Linux- och BSD-användare, men för QNX-världen är detta ett stort skifte. Historiskt har QNX-utveckling nästan alltid inneburit korskompilering: man skriver och bygger sin kod på Linux eller Windows för att sedan överföra den till ett QNX-system. Med den nya Developer Desktop förändras detta i grunden.

    Ett skrivbord på ett realtids-OS

    Kärnan i nyheten är ett komplett skrivbord baserat på XFCE som körs ovanpå Wayland, direkt på QNX 8.0. Resultatet är ett lättviktigt men välbekant grafiskt gränssnitt som påminner mer om en traditionell Linux-desktop än om ett klassiskt inbyggt system.
    För nya utvecklare sänker detta tröskeln rejält. För erfarna QNX-utvecklare innebär det mindre friktion i vardagen, och för alla som portar Linux-program till QNX blir skillnaden tydlig.

    Inget mer ”bygg här, testa där”

    Den kanske viktigaste nyheten är självhostad kompilering. I stället för att bygga binärer på ett annat operativsystem kan utvecklaren nu skriva kod, kompilera den, köra och felsöka samt testa grafik, bibliotek och beroenden helt och hållet inne i QNX.
    Miljön levereras med ett brett urval verktyg som många utvecklare redan känner igen: GCC och Clang, Python, Make och CMake, Git samt editorer som Geany, Emacs, Neovim och Vim. Därutöver finns terminal, webbläsare och filhanteraren Thunar, vilket ger ett komplett och självbärande arbetsflöde utan att lämna operativsystemet.

    Öppen källkod möter industrirealtid

    En stor del av styrkan i den nya Desktop-miljön kommer från QNX satsning på öppna portar. Miljön är förladdad med många av de paket som finns på QNX Open-source Dashboard, som i dagsläget innehåller över 1 400 portar, varav mer än 600 är unika projekt.
    Detta gör det betydligt enklare att porta Linux-bibliotek, grafiska verktyg baserade på GTK, OpenGL ES-applikationer och Python-program. QNX rör sig här tydligt närmare det öppna ekosystem som länge varit Linux-världens styrka, utan att kompromissa med realtidsegenskaperna.

    Virtuell maskin i dag – mer i morgon

    Den första versionen levereras som en QEMU-image och stöds officiellt på Ubuntu 22.04 och 24.04 LTS. Med en gratis QNX-licens kan utvecklare ladda ner bilden via QNX Software Center och komma igång redan i dag.
    Detta är dock bara början. Enligt QNX egen färdplan väntar QEMU-bilder för Windows och macOS, nativa x86-installationer, en dedikerad Raspberry Pi-version, förbättrad dokumentation, stöd för CI-flöden samt fler exempelprojekt och högre stabilitet.

    Varför detta är större än det låter

    QNX har länge varit känt som ett extremt pålitligt men relativt slutet system, perfekt för bilar, tåg och industriella styrsystem men mindre lockande för nya utvecklare. Med Developer Desktop tar QNX ett tydligt steg mot att bli mer tillgängligt, mer experimentvänligt och mer relevant även utanför traditionell embedded-utveckling.
    Att kunna köra ett modernt skrivbord, en webbläsare och en komplett utvecklingsmiljö på ett realtids-OS är inte bara praktiskt utan också ett tydligt ställningstagande. QNX vill inte längre bara vara osynlig infrastruktur, utan en plattform där utvecklare faktiskt vill arbeta.

    https://devblog.qnx.com/qnx-self-hosted-developer-desktop-initial-release

    FAKTARUTA: QNX Self-Hosted Developer Desktop (QNX 8.0)
    Vad är det?
    En självhostad utvecklingsmiljö som körs direkt på QNX 8.0, så att du kan bygga och testa mjukvara utan korskompilering.
    Skrivbordsmiljö
    XFCE på Wayland.
    Utvecklingsverktyg
    GCC, Clang, Python, Make, CMake, Git (m.fl.).
    Editorer/IDEs
    Geany, Emacs, Neovim, Vim.
    Ingår också
    Webbläsare, terminal, Thunar filhanterare samt exempelprojekt i C, C++, Python, GTK och OpenGL ES.
    Distribution (första släppet)
    QEMU-image.
    Stödda värdar
    Ubuntu 22.04 LTS och 24.04 LTS.
    På väg enligt roadmap
    QEMU för Windows/macOS, nativa x86-images och en Raspberry Pi-build.

Etikett: systemutveckling

  • Moxnox 1.0 – ett nytt operativsystem som förenar Windows NT och Unix

    Vad händer om man tar några av de bästa idéerna från Windows NT, kombinerar dem med Unix och bygger ett helt nytt operativsystem från grunden? Det är precis vad utvecklaren Mark Harmstone har gjort. Resultatet heter Moxnox, och nu har version 1.0 släppts som öppen källkod. När man talar om operativsystem handlar diskussionen nästan alltid…

  • Linus Torvalds testar AI-skriven Linuxkod – tredubblar läshastigheten

    Linux skapare Linus Torvalds har tagit hjälp av AI-verktyget Claude Code för att optimera Linuxkärnan. I ett experiment har han lyckats mer än tredubbla antalet läsoperationer per sekund genom att förändra hur operativsystemet hanterar arbetsminnet. Resultatet visar AI-teknikens möjligheter inom avancerad programmering, men väcker också frågor om tillförlitlighet och säkerhet. När processorkärnorna konkurrerar om minnet…

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

  • Ubuntu 26.10 tar sina första steg – men det här är bara början

    Ubuntu 26.10 ”Stonking Stingray” har nu dykt upp i sin första tidiga testversion. Det är långt ifrån ett färdigt operativsystem, men för utvecklare, testare och Linuxintresserade ger den första snapshot-versionen en tydlig försmak av vad nästa Ubuntu-utgåva kan komma att bjuda på när den släpps hösten 2026. En första titt på nästa Ubuntu Ubuntu 26.10,…

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

  • Stöd för AMD Zen 6, Arm v9.7 och mer RISC-V

    När nästa generations processorer från AMD, Arm och RISC-V står för dörren måste även mjukvarans grundverktyg ligga steget före. Med GNU Binutils 2.46 tar utvecklarvärlden ett viktigt kliv mot framtiden genom att lägga till stöd för kommande CPU-arkitekturer, förbättrad felsökning och en moderniserad verktygskedja som gör fria operativsystem redo för hårdvara som ännu inte nått…

  • QNX tar steget mot skrivbordet – ett realtids-OS blir självbärande för utvecklare

    QNX tar ett ovanligt kliv från det dolda till det synliga. Med lanseringen av en självhostad Developer Desktop för QNX 8.0 kan utvecklare för första gången arbeta i en fullständig skrivbordsmiljö och bygga sina program direkt på operativsystemet. Satsningen markerar ett tydligt skifte för QNX – från strikt inbyggt realtids-OS till en mer öppen och…