• 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

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