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

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

  • KDE får över en miljon euro för att stärka det fria skrivbordet

    KDE får över en miljon euro från Sovereign Tech Fund för att stärka det fria Linux-skrivbordet. Pengarna ska gå till bättre återställning, fabriksåterställning, säkrare infrastruktur och förbättrad e-post- och kalenderhantering. Satsningen visar hur fri och öppen källkod blir allt viktigare när Europas digitala självständighet hamnar högre upp på den politiska och tekniska dagordningen.

    Det fria skrivbordet KDE får en rejäl ekonomisk förstärkning. Genom Sovereign Tech Fund ska KDE-projektet få drygt 1,28 miljoner euro under 2026 och 2027. Pengarna ska användas till att göra KDE Plasma stabilare, säkrare och mer användbart – inte minst för myndigheter, företag och organisationer som vill minska sitt beroende av stora kommersiella teknikplattformar.

    KDE är ett av de mest kända projekten inom fri och öppen källkod. Mest känt är KDE Plasma, skrivbordsmiljön som används i många Linuxdistributioner. För vanliga användare är Plasma det grafiska gränssnittet: panelen, startmenyn, fönstren, inställningarna och allt det som gör att datorn känns som en modern arbetsmiljö.

    Men KDE är mycket mer än bara ett snyggt skrivbord. Projektet utvecklar även program, bibliotek, systemverktyg och infrastruktur som används i hela Linuxvärlden.

    Vad ska pengarna användas till?

    Stödet från Sovereign Tech Fund är öronmärkt för tydliga tekniska förbättringar. KDE ska bland annat arbeta med bättre återställningsfunktioner i KDE Plasma. Det betyder att systemet ska bli enklare att reparera om något går fel, till exempel efter en misslyckad uppdatering eller en trasig inställning.

    En annan viktig del är planerna på en fabriksåterställning för KDE Linux. Det kan jämföras med funktionen i moderna mobiltelefoner, där användaren kan återställa systemet till ett fungerande grundläge utan att behöva installera om allt manuellt. För Linux på skrivbordet kan detta bli ett stort steg mot att göra systemet mer lättskött för vanliga användare.

    Pengarna ska också gå till bättre testning och kvalitetssäkring. Det handlar om att bygga upp infrastruktur som automatiskt kan testa att viktiga funktioner fungerar som de ska. Ju bättre testning, desto mindre risk att nya uppdateringar orsakar fel.

    KDE PIM får också ett lyft

    En del av satsningen går till KDE PIM, alltså KDE:s programsvit för personlig informationshantering. Där ingår bland annat e-post, kalender, kontakter och relaterade funktioner.

    Här vill KDE förbättra stödet för moderna e-post- och kalendersystem. Det handlar bland annat om IMAP4, WebDAV, push-notiser och standardiserad kontokonfiguration. Målet är att e-post, kalender och kontakter ska fungera bättre och mer tillförlitligt i KDE-miljön.

    Detta är viktigt eftersom många organisationer är beroende av just dessa funktioner i vardagen. Ett skrivbordssystem utan stabil e-post, kalender och kontaktbok blir svårt att använda i större skala.

    Digital suveränitet – mer än ett modeord

    Bakom satsningen finns en större idé: digital suveränitet. Det betyder att individer, företag och samhällen ska ha kontroll över sin digitala infrastruktur. Man ska inte vara helt beroende av några få stora teknikbolag, deras molntjänster, licensmodeller eller datainsamling.

    Fri och öppen källkod spelar en central roll i detta. När källkoden är öppen kan den granskas, förbättras och anpassas. En myndighet, ett företag eller en kommun kan låta egna tekniker eller lokala IT-leverantörer kontrollera hur systemet fungerar. Det går också att bygga vidare på programvaran utan att behöva be om tillstånd från en kommersiell leverantör.

    KDE passar väl in i den modellen. Projektet drivs inte för att sälja abonnemang eller samla in användardata, utan för att skapa fri programvara som alla kan använda.

    Varför spelar skrivbordsmiljön fortfarande roll?

    I en tid när mycket handlar om molntjänster, appar och AI kan det vara lätt att tro att skrivbordsmiljön inte längre är så viktig. Men för de flesta människor är skrivbordet fortfarande porten till det digitala samhället.

    Det är där man öppnar sin webbläsare, skriver dokument, hanterar e-post, laddar ner filer, ansluter till nätverk, skriver ut papper och använder myndighetstjänster. Skrivbordet är ofta platsen där personlig information samlas: lösenord, dokument, bilder, meddelanden och arbetsmaterial.

    Därför blir säkerhet, återställning och stabilitet på skrivbordet en viktig samhällsfråga. Om datorn inte fungerar, fungerar inte heller många av de tjänster man är beroende av.

    Ett alternativ till de stora plattformarna

    KDE:s styrka är att det erbjuder ett alternativ till de stora kommersiella systemen. I stället för att vara låst till Microsoft, Apple eller Google kan användare och organisationer bygga sin IT-miljö på öppen programvara.

    Det betyder inte att KDE redan är perfekt för alla. Stora organisationer kräver stabilitet, support, central hantering, säkerhetsrutiner och långsiktig förvaltning. Just därför är den här typen av finansiering viktig. Pengarna går inte främst till synliga effekter som nya teman eller ikoner, utan till det underliggande arbetet som gör systemet mer robust.

    Det är sådant arbete som ofta märks först när det saknas: när uppdateringar går sönder, e-post inte synkas, nätverksdelningar krånglar eller inställningar inte går att återställa.

    KDE fyller 30 år

    KDE fyller 30 år i oktober, och stödet kommer vid en symboliskt viktig tidpunkt. Under tre decennier har projektet utvecklats från ett skrivbordsprojekt till ett omfattande ekosystem av programvara.

    Det som en gång kunde uppfattas som ett hobbyprojekt är i dag en del av den digitala infrastrukturen. KDE används av privatpersoner, utvecklare, företag, skolor och offentliga verksamheter världen över.

    Att Sovereign Tech Fund nu investerar över en miljon euro i KDE visar att fri programvara inte längre bara ses som ett tekniskt alternativ. Den ses allt mer som en strategisk resurs.

    En investering i framtidens öppna datorer

    Satsningen på KDE handlar i grunden om mer än en skrivbordsmiljö. Den handlar om vem som ska ha kontrollen över våra datorer, våra dokument och våra digitala liv.

    När allt fler samhällsfunktioner flyttar in i digitala system blir frågan om programvarans ägande och insyn allt viktigare. Sluten programvara kan vara bekväm, men den gör också användaren beroende av leverantörens villkor. Öppen programvara kräver ibland mer arbete, men ger i gengäld större frihet, bättre insyn och möjlighet till lokal kontroll.

    Med stödet från Sovereign Tech Fund får KDE bättre möjligheter att bli ett ännu starkare alternativ för både privatpersoner och organisationer. Om arbetet lyckas kan KDE Plasma bli enklare att återställa, tryggare att använda och bättre anpassat för professionella miljöer.

    Det är kanske inte lika spektakulärt som en ny app eller en ny dator. Men det är precis den typen av grundläggande förbättringar som gör fri programvara möjlig att använda i större skala. KDE:s nya finansiering är därför inte bara goda nyheter för Linuxanvändare – den är också ett tecken på att digital självständighet börjar tas på allt större allvar.

    Teknisk faktaruta: KDE och Sovereign Tech Fund

    Projekt: KDE

    Organisation: KDE e.V.

    Finansiär: Sovereign Tech Fund / Sovereign Tech Agency

    Stöd: 1 285 200 euro

    Period: 2026–2027

    Huvudområden:

    • Förbättrad återställning i KDE Plasma
    • Fabriksåterställning för KDE Linux
    • Bättre QA- och testinfrastruktur
    • Förbättrad backup och återställning av data
    • Bättre stöd för nätverksdelningar
    • Stärkt säkerhetsinfrastruktur
    • Förbättrad KDE PIM-integration

    KDE PIM: Programsvit för e-post, kalender, kontakter och personlig informationshantering.

    Tekniker som nämns: IMAP4, IMAP4rev2, WebDAV, WebDAV push-notiser, Flatpak och standardiserad kontokonfiguration.

    Mål: Att göra KDE:s fria programvara mer robust, säker och användbar för privatpersoner, företag och offentlig sektor.


  • 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
  • Fedora 44 försenas – varför några få buggar kan stoppa ett helt operativsystem

    Fedora 44 har försenats efter att flera allvarliga fel upptäckts i systemets mest kritiska delar, som installation, grafik och krypterad uppstart. I stället för att hålla det planerade releasedatumet väljer utvecklarna att pausa lanseringen – ett beslut som visar hur avgörande kvalitetssäkring är när modern programvara ska fungera på många olika typer av hårdvara.

    Det låter kanske dramatiskt: en ny version av Fedora Linux var planerad att släppas den 14 april, men lanseringen stoppades i sista stund. Orsaken? Några envisa fel i systemet – så kallade blocker bugs – som bedömdes vara så allvarliga att hela releasen måste skjutas upp, sannolikt till den 21 april.

    Men varför kan några få buggar få ett helt operativsystem att vänta? Och vad säger det om hur modern programvara faktiskt byggs? Det här är en berättelse om kvalitetskontroll, teknikens komplexitet och varför förseningar ibland är ett tecken på att något fungerar precis som det ska.

    Vad är Fedora – och varför spelar en ny release roll?

    Fedora Linux är en av världens mest inflytelserika Linuxdistributioner. Den används både av entusiaster, utvecklare och som teknikplattform för innovationer som senare kan dyka upp i andra system. Fedora fungerar ofta som ett slags laboratorium för ny programvara: här introduceras nya skrivbordsmiljöer, uppdaterade utvecklarverktyg och modern systemteknik tidigt.

    Version 44 skulle bland annat föra med sig GNOME 50 för Workstation, Plasma 6.6 för KDE-användare, Budgie 10.10 med Wayland-stöd, förbättringar i installationsverktyget Anaconda och flera uppdaterade programpaket för utvecklare och servermiljöer.

    Det är alltså inte konstigt att många väntat på släppet.

    När ett planerat datum inte räcker

    I stora mjukvaruprojekt finns nästan alltid en målkalender. Fedora 44 hade en planerad lansering den 14 april. Men i praktiken är ett releasedatum inte en garanti – det är ett mål som bara gäller om systemet anses tillräckligt stabilt.

    När Fedora-projektet kom fram till att flera allvarliga fel fortfarande var öppna, ställdes det planerade Go/No-Go-mötet i praktiken in. Beskedet från kvalitetsarbetet var tydligt: det fanns flera kvarstående blockerare, och inget tydde på att de kunde ignoreras eller ”viftas bort”.

    Det är här begreppet final blocker bug blir centralt.

    Vad är en blocker bug?

    Alla buggar är inte lika viktiga. Vissa är irriterande men går att leva med, till exempel ett mindre grafiskt fel eller en ovanlig krasch i ett specialprogram. En blocker bug är däremot ett fel som anses så allvarligt att produkten inte bör släppas alls förrän det är löst.

    Det handlar ofta om sådant som:

    • att installationen kraschar
    • att användaren inte kan konfigurera viktiga funktioner
    • att systemet inte startar korrekt
    • att grundläggande säkerhets- eller krypteringsfunktioner fallerar

    Med andra ord: fel som förstör själva grundupplevelsen.

    Vad var det som stoppade Fedora 44?

    De accepterade blockerarna i Fedora 44 rör inte smådetaljer, utan just sådant som användaren möter allra först.

    Ett av problemen gäller en Mesa-bugg som kan få den inledande systemkonfigurationen att krascha på datorer med NVIDIA-hårdvara. Mesa är en viktig del av grafikstacken i Linuxvärlden, och grafikproblem tidigt i uppstart eller installation kan göra systemet oanvändbart direkt för vissa användare.

    De övriga accepterade blockerarna är kopplade till Plasma Setup, alltså installations- och förstagångsflödet för KDE-varianten av Fedora. Där påverkas bland annat tangentbordslayout och Wi-Fi-konfiguration – två saker som är avgörande när en användare ska komma igång med systemet.

    Dessutom finns två föreslagna blockerare kopplade till kärnan, alltså Linux-kärnan själv. De handlar om svart skärm i samband med att användaren anger LUKS-lösenord, alltså lösenordet för krypterade diskar. Ett av fallen ska dessutom vara specifikt observerat på en ThinkPad X1 Carbon Gen 13.

    Detta är ett bra exempel på hur svår modern systemutveckling är: problemen finns i gränssnittet mellan grafikdrivrutiner, kärnan, hårdvara, kryptering och installationsflöden. Ett fel i en sådan kedja kan räcka för att hela upplevelsen faller samman.

    Varför just första uppstarten är så känslig

    Ur ett tekniskt perspektiv är första uppstarten en av de mest kritiska faserna för ett operativsystem. Då ska många delar fungera samtidigt:

    • grafiken ska starta korrekt
    • tangentbord och språkval ska fungera
    • nätverk ska kunna konfigureras
    • krypterade system ska låsas upp
    • användaren ska kunna slutföra grundinställningarna utan fel

    Om något går sönder här spelar det nästan ingen roll hur bra resten av systemet är. Användaren kommer aldrig fram till de mer avancerade funktionerna.

    Det är därför det är logiskt att Fedora väljer att vänta. En release är inte bara en teknisk leverans – den är ett första intryck.

    Förseningen som kvalitetsstämpel

    I teknikvärlden uppfattas förseningar ofta negativt. Men i projekt som Fedora kan en uppskjuten release också tolkas som ett sundhetstecken. Det visar att kvalitetsprocessen faktiskt har mandat att säga stopp.

    Det är frestande att hålla ett datum, särskilt när användare, utvecklare och medier väntar. Men att släppa ett system med kända problem i installation, nätverk eller krypterad uppstart hade sannolikt kostat mer i förtroende än vad en veckas försening gör.

    På så sätt fungerar blocker bugs som en sorts säkerhetsventil i utvecklingsprocessen. De påminner om att programvara inte bara är kod – det är också testning, prioritering och ansvar.

    Vad väntar i Fedora 44 när den väl kommer?

    Trots förseningen ser Fedora 44 ut att bli en stor uppdatering. Bland nyheterna märks:

    • GNOME 50 i Workstation-versionen
    • Plasma 6.6 för KDE-användare, med nytt installationsflöde och ny inloggningshantering
    • Budgie 10.10 med stöd för Wayland
    • förbättringar i Anaconda-installationsprogrammet
    • bättre hantering av Live-media och förbättrat stöd för aarch64 på Windows on ARM-laptops
    • uppdaterade utvecklarverktyg och paket, som MariaDB 11.8, Ansible 13, Helm 4 och Golang 1.26
    • Nix i paketrepositorierna för utvecklare

    Det visar hur bred en modern Linuxrelease är. Det handlar inte bara om ett nytt skrivbord eller några nya appar, utan om ett helt ekosystem av verktyg, drivrutiner, pakethantering och plattformsteknik.

    En liten försening, en stor påminnelse

    Fedora 44:s uppskjutna release är i grunden en påminnelse om hur skör och komplex digital infrastruktur kan vara. Det räcker inte att ”det mesta fungerar”. För ett operativsystem måste även de allra första minuterna – installationen, uppstarten, inloggningen, nätverket – vara robusta.

    Därför är en försenad release ibland bättre än en punktlig.

    Och kanske är det just där den populärvetenskapliga lärdomen finns: bakom varje ”uppdatering” vi klickar hem döljer sig ett enormt samspel mellan människor, kod och maskiner. När det samspelet inte riktigt håller ihop, då märks det direkt. Men när utvecklare vågar bromsa i tid, är det också ett tecken på att tekniken tas på allvar.

    https://qa.fedoraproject.org/blockerbugs/milestone/44/final/buglist

    Teknisk ruta: Fedora 44

    Typ: Linuxdistribution med fokus på ny teknik och snabba uppdateringar

    Status: Försenad release på grund av kvarvarande blocker bugs i kritiska systemdelar

    Planerat släpp: Flyttat från 14 april till tidigast 21 april

    Berörda problem: krascher i initial setup på NVIDIA-system, fel i Plasma Setup för tangentbord och Wi-Fi samt svarta skärmar vid LUKS-upplåsning

    Skrivbordsmiljöer: GNOME 50, Plasma 6.6 och Budgie 10.10 med Wayland-stöd

    Övriga nyheter: uppdaterad Anaconda-installation, förbättrad Live-media, bättre stöd för aarch64 på Windows on ARM samt nya paketversioner för utvecklare

    Exempel på uppdaterade verktyg: MariaDB 11.8, Ansible 13, Helm 4 och Golang 1.26

  • 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
  • Forgejo 14.0 – Egen hostad lösning för kodsamarbete

    Forgejo är en fri och community-driven plattform för kodsamarbete som används för att lagra, granska och utveckla programvara tillsammans. Den bygger på Git, ett distribuerat versionshanteringssystem som gör det möjligt för utvecklare att spåra förändringar i källkod, arbeta parallellt och slå samman arbete på ett kontrollerat sätt. Med Forgejo får organisationer och individer ett självhämtat alternativ till kommersiella kodplattformar, där de själva har full kontroll över data, arbetsflöden och säkerhet, samtidigt som de drar nytta av moderna funktioner för ärendehantering, kodgranskning och automatisering.

    Forgejo 14.0 släpptes den 15 januari 2026 och är en tydlig milstolpe för den community-utvecklade, självhämtade Git-plattformen. Versionen fokuserar på att göra det dagliga arbetet smidigare för användare, samtidigt som den stärker tillförlitlighet och säkerhet för administratörer och driftansvariga. Resultatet är en mer robust och långsiktigt hållbar kodplattform, utan att ge avkall på projektets öppna och självständiga filosofi.

    Förbättrad sökning i ärenden och pull requests

    En av de mest märkbara förbättringarna i Forgejo 14.0 är den nya sökfunktionen för ärenden och pull requests. Direkt i sökfältet kan användaren nu använda enkla inline-filter för att begränsa resultat baserat på exempelvis status, vem som skapat ärendet eller hur resultaten ska sorteras. Det gör att man snabbare kan hitta rätt bland stora mängder diskussioner och kodgranskningar, utan att behöva växla mellan olika menyer eller avancerade sökdialoger. En inbyggd hjälptext i gränssnittet förklarar hur filtren används, vilket sänker tröskeln även för mindre erfarna användare.

    Ny webbredigerare för snabbare och mer tillgänglig redigering

    Den webbaserade filredigeraren har fått en genomgripande förändring. Den tidigare lösningen, baserad på Microsofts Monaco-editor, ersätts nu av CodeMirror. Bakgrunden till bytet är att Monaco visade sig vara onödigt tung för Forgejos vanligaste användningsfall, som ofta handlar om snabba ändringar i enstaka filer. Med CodeMirror förbättras laddningstider och prestanda märkbart, samtidigt som tillgänglighet och mobilanvändning fungerar bättre. För många användare innebär detta att webbredigering nu känns mer direkt och pålitlig, snarare än som ett undantag man helst undviker.

    Förfinat gränssnitt och fortsatt arbete utan JavaScript

    Forgejo 14.0 innehåller flera mindre men viktiga förbättringar i användargränssnittet. Förhandsvisning av CITATION-filer har blivit mer flexibel, med möjlighet att växla mellan CFF- och BibTeX-format direkt i vyn. Samtidigt fortsätter arbetet med att göra Forgejo fullt användbart även utan JavaScript. I den nya versionen går det att posta kommentarer och komma åt fler menyer även när JavaScript är avstängt. Detta stärker både tillgänglighet och robusthet, och gör Forgejo mer motståndskraftigt mot framtida förändringar i webbläsare och teknik.

    Kraftigt förbättrade Forgejo Actions

    Automatiseringssystemet Forgejo Actions har utvecklats rejält i version 14.0. Hanteringen av förtroende för workflows som kommer från pull requests har blivit tydligare och mer detaljerad. Projektägare kan nu enkelt välja om ett workflow ska godkännas en gång, alltid tillåtas eller helt nekas, och tidigare beslut kan återkallas. Det ger bättre kontroll över säkerheten i projekt där externa bidrag är vanliga.

    Samtidigt har synligheten i Actions-gränssnittet förbättrats. När ett jobb väntar på en specifik runner visas detta tydligt som ett väntande tillstånd, vilket gör det enklare att förstå varför en pipeline inte startar. Stöd för concurrency-grupper, dynamiska matriser och runs-on-definitioner som bestäms av tidigare jobb gör dessutom att mer avancerade och intelligenta workflows kan byggas, anpassade efter projektets faktiska behov.

    Förbättrad databasdrift och ökad stabilitet

    På driftsidan åtgärdar Forgejo 14.0 flera långvariga problem. Ett känt fel som kunde leda till att commit_status-tabellen fylldes med miljontals redundanta poster har nu rättats till. Ett nytt kommandoradsverktyg gör det möjligt att rensa bort dessa poster efter uppgradering, vilket i praktiken kan minska datamängden med över 97 procent. Databashanteringen har också förbättrats genom att deadlocks i stort sett eliminerats och genom att foreign keys införts för att förhindra inkonsekvent data vid uppgraderingar.

    Skärpt säkerhet och moderniserat CSRF-skydd

    Säkerheten har fått särskild uppmärksamhet i Forgejo 14.0. När Forgejo är konfigurerat att själv hantera SSH-åtkomst kontrolleras nu authorized_keys-filen redan vid uppstart. Om oväntade nycklar upptäcks vägrar tjänsten starta, vilket tvingar administratören att undersöka och åtgärda problemet innan systemet tas i drift. CSRF-skyddet har samtidigt skrivits om till en stateless-lösning baserad på webbläsarens fetch-metadata. Det innebär att användare kan ha flikar öppna under lång tid utan att riskera att formulär slutar fungera när de väl skickas.

    Sammanfattning och framtidsblick

    Forgejo 14.0 är en genomtänkt och mogen uppdatering som kombinerar förbättrad användarupplevelse med tydliga vinster för säkerhet och driftsäkerhet. För både utvecklare och administratörer innebär versionen ett mer pålitligt verktyg i vardagen. Nästa stora steg blir Forgejo 15.0 LTS, planerad till april, som väntas ge långtidssupport och ytterligare stabilitet för organisationer som satsar på Forgejo i produktion.

    https://forgejo.org/download

    Forgejo 14.0 – fakta
    Vad är Forgejo?
    Självhostad kodplattform (Git forge) för repo, ärenden, PR och CI.
    Vad är Git?
    Distribuerad versionshantering som spårar ändringar och möjliggör samarbete.
    Release
    15 januari 2026
    Största UI-nyheterna
    Inline-filter i Issue/PR-sök + webbredigerare byter från Monaco till CodeMirror.
    Bättre utan JavaScript
    Fler menyer och kommentarer fungerar även med JS avstängt.
    Actions
    Tydligare trust-kontroller, “waiting”-status, concurrency-grupper och dynamiska matriser.
    Drift & databas
    Fix för commit_status-bloat + CLI-rensning, färre deadlocks och bättre dataintegritet.
    Säkerhet
    Validerar authorized_keys vid start + stateless CSRF-skydd (fungerar bättre med långöppna flikar).



  • 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: mjukvaruutveckling

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

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

  • KDE får över en miljon euro för att stärka det fria skrivbordet

    KDE får över en miljon euro från Sovereign Tech Fund för att stärka det fria Linux-skrivbordet. Pengarna ska gå till bättre återställning, fabriksåterställning, säkrare infrastruktur och förbättrad e-post- och kalenderhantering. Satsningen visar hur fri och öppen källkod blir allt viktigare när Europas digitala självständighet hamnar högre upp på den politiska och tekniska dagordningen. Det fria…

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

  • Fedora 44 försenas – varför några få buggar kan stoppa ett helt operativsystem

    Fedora 44 har försenats efter att flera allvarliga fel upptäckts i systemets mest kritiska delar, som installation, grafik och krypterad uppstart. I stället för att hålla det planerade releasedatumet väljer utvecklarna att pausa lanseringen – ett beslut som visar hur avgörande kvalitetssäkring är när modern programvara ska fungera på många olika typer av hårdvara. Det…

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

  • Forgejo 14.0 – Egen hostad lösning för kodsamarbete

    Forgejo är en fri och community-driven plattform för kodsamarbete som används för att lagra, granska och utveckla programvara tillsammans. Den bygger på Git, ett distribuerat versionshanteringssystem som gör det möjligt för utvecklare att spåra förändringar i källkod, arbeta parallellt och slå samman arbete på ett kontrollerat sätt. Med Forgejo får organisationer och individer ett självhämtat…

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