Fedora 44 is officieel uitgebracht met Gnome 50 - update

The Fedora Project heeft Fedora 44 uitgebracht. De Linux-distributie krijgt in deze release nieuwe versies van de Gnome- of KDE-desktopomgevingen, naast andere wijzigingen onder de motorkap. Het OS zou eigenlijk op 14 april al uitkomen, maar werd uitgesteld vanwege onopgeloste bugs.

De grootste wijziging in Fedora Workstation 44 is de upgrade naar Gnome 50, de interface die het OS standaard gebruikt. Versie 50 voegt nieuwe functies voor ouderlijk toezicht toe, naast nieuwe toegankelijkheidsopties, verbeteringen aan de documentenviewer en bestandsbeheerder, betere ondersteuning voor variabele refreshrates en meer.

Ook Fedora KDE maakt gebruik van een nieuwere desktopomgeving: KDE Plasma 6.6. Die krijgt op zijn beurt nieuwe aanpassingsmogelijkheden, zoals het opslaan van globale thema's en meer opties voor het instellen van accentkleuren. Fedora KDE 44 krijgt hiermee ook een nieuwe loginmanager en een simpeler installatieproces.

Verder krijgt Fedora 44 meerdere verbeteringen onder de motorkap. Daarnaast worden OpenSSL-certificaten sneller geladen en is de ntsync-kernelmodule voor Wine standaard ingeschakeld. Dat laatste moet in zeer specifieke gevallen zorgen voor betere prestaties tijdens het gamen.

Fedora 44 is vanaf nu te downloaden via de Fedora-website. Huidige Fedora-gebruikers kunnen hun OS upgraden via de Discover-appstore.

Update, 20.29 uur – In het artikel stond aanvankelijk dat Fedora 44 een nieuwere versie van de Linux-kernel krijgt, maar dit klopt niet. Het OS gebruikt bij release nog steeds Linux 6.19. De voorgaande Fedora 43-release was eerder al geüpgraded naar deze kernelversie. Het artikel is hierop aangepast.

Fedora Workstation

Door Daan van Monsjou

Nieuwsredacteur

29-04-2026 • 16:32

45

Submitter: Master FX

Reacties (45)

Sorteer op:

Weergave:

Nou geupgrade naar fedora 44 en heb nog niks gemerkt van een nieuwere kernel. Zit nog steeds op kernel 6.19.14-300.
Bij Ubuntu 26.04 wordt wel kernel 7.0 gebruikt, die is ook recent uitgebracht, wellicht zit de verwarring daar?

[Reactie gewijzigd door CH4OS op 29 april 2026 17:10]

Dat hebben ze dan snel gedaan bij Ubuntu want de 7.0 versie kwam uit op 12 april 2026: Wikipedia: Linux kernel version history of het ook goed gedaan is, dat weet ik niet.

Maar eigenlijk gaat het nergens over. Je loopt een stable versie achter, maar dat is niets groots. Het verschil tussen 7.0 en 6.19 is klein. Dat is net zoiets als 6.18 vs. 6.19. Het klinkt groot omdat het verschil is tussen 6 en 7 groot lijkt maar het is niet groot, en die grens zal voor altijd blijven bestaan tussen 6 en 7 maar tussen 7.0 en 7.1 enz zal het weer genormaliseerd worden. Zo te lezen is 6.18 de laatste LTS.

Al met al denk ik dat uiteindelijk een versie op basis van datum onvermijdelijk is, en bovendien ook handiger. Dan heeft een versie tenminste nog iets van betekenis.
Het verschil tussen 7.0 en 6.19 is klein.
Bedoel je dat op functioneel of op technisch niveau?

Als ik links en rechts de comments lees krijg ik het idee dat 6.19 vs. 7.0 vaak een béétje gebagatelliseerd wordt. Major version bump zegt bij de kernel inderdaad niks anders dan “het getalletje achter de punt werd te hoog volgens Linus” maar desalniettemin zaten er veel changes in op allerlei fronten. Speur Phoronix maar eens na voor berichten rondom 7.0 :)

Dat wil niet zeggen dat 6.19 geen prima release is, die is voor nu nog wel prima.
Als nieuwe functionaliteit geintroduceerd wordt gebeurd dat met kinderstapjes. Zo werd support voor de rockchip van 6.12 tot 6.15 ineens compleet (eerst een framework, dan in stappen de driver, dan de configuratie, maar alleen in de major releases). Als ik dan verder kijk naar 6.18 (LTS voor Debian), 6.19 (LTS voor Fedora) en 7.0 (LTS voor Ubuntu dan maakt het elkaar niet veel. Maar dat ligt een beetje eraan op welke functionaliteit je wacht.

Groot in 7.1 is "het opruimen van oude zooi" (maar die drivers compileer ik al jaren niet meer). Als je een nieuwe intel of amd gpu hebt kan het nut hebben de laatste stable release te gebruiken. Verschillende rockchip zaken hoop ik dat in 7.2 of 7.3 worden toegevoegd (de rk3588 is al sinds 6.15 functioneel, maar ook de exotischer opties zijn bijna gereed). Voor zaken als de mt7927 ben je nog afhankelijk van dkms-drivers.

Voor mijn (intussen oude) intel i7 ben ik jaren geleden al overgestapt op een 6.12 LTS-kernel en daar mis ik weinig nieuwe functies. Voor de rockchip hangt het een beetje van het gebruik af: stabiel, dan een 6.18-LTS kernel, anders hetzij de laatste stable en af en toe een test met een rc-kernel. HDMI-2.0 lijkt vanaf 7.2 ondersteund te worden voor de rk (4K60), en HDMI-2.1 is daarna aan de beurtj (8K60).
Wat ik bedoel te zeggen is dat het verschil tussen de oren zit. Dat moet je dan weer bagatelliseren door de technische verschillen te noemen. Technisch weet ik niet eens uit mijn hoofd wat er nieuw in 7.0 is t.o.v 6.19, ik weet enkel dat het voor mij niets baanbrekends was (dat je zou kunnen verwachten bij een major version bump). Zo moet ik nog steeds exact dezelfde DKMS installeren.

Het is: een 'gewone' major version bump.

Het is geen: LTS.

Ze hadden het ook 6.20 kunnen noemen. Waarom wel tot 19 gaan en niet tot 29 of tot 9, shrug.

Versioning op basis van datum is gewoon veel informatiever en logischer. Je kunt dan zelfs zien hoe oud een kernel is. De minor revisies kun je uiteraard wel houden, die zijn dan ook informatief. Ik zit nu bijvoorbeeld op die Wikipedia te kijken van wanneer de 6.18 en 6.19 versies zijn. Totaal onnodig als je ze noemt naar de datum. Ubuntu zelf doet dit al heel lang goed (en er is zat gegronde kritiek op Canonical / Ubuntu te bedenken, daar niet van).

Nadeel is dan wel dat je niet weet wanneer de minor uit is gekomen. Dan krijg je weer heel rare dingen, Stel bijvoorbeeld je hebt 7.0 met revisies zoals 2026.04.1 en 2026.04.2 terwijl die .2 uit zou komen in mei. Dan zegt dat alsnog niets over wanneer de minor uitkwam. Enkel wanneer de major uitkwam. Wil je dat wel krijg je bijvoorbeeld 2026.04.1-2026.05.2, of je zou een timestamp in de versie kunnen zetten, maar dat is weer zo omslachtig lang. Punt is: versioning op basis van datum is niet perfect. Maar het is wel beter dan... dit.

[Reactie gewijzigd door Jerie op 29 april 2026 19:20]

Dat is gedaan omdat het een LTS is. De verbeteringen in die net even nieuwere kernel, nemen ze voor jaren mee.
Ja, de Beta Freeze was in februari en de full freeze in maart. Ik volg de dev cycle van Ubuntu niet zo, maar kan me voorstellen dat omdat dat een LTS versie is, er gekozen is om toch de update naar 7 mee te nemen (ookal maakt dat niet zo veel uit idd.)
Het valt me op dat Ubuntu 26.04 LTS standaard is uitgerust met Kernel 7.0. Als je kijkt naar kernel.org, zie je dat 6.18 de officiële LTS-versie is.

Voor een distributie die stabiliteit en "Long Term Support" ademt, vind ik het een aparte keuze om niet de LTS-kernel te volgen. Is de stap naar 7.0 niet te riskant voor bedrijfsomgevingen?
Welk bedrijf gebruikt Ubuntu?
Wij draaien onze servers momenteel met Ubuntu 24.04, straks als er images beschikbaar zijn voor Ubuntu 26.04 zullen we uitgebreid ermee gaan testen vooraleer we dat gebruiken gaan. Er zijn dus wel degelijk bedrijven die dus Ubuntu gebruiken voor hun servers. :)
Bij een overheid waar ik werkte, was 90% Ubuntu.
Ik denk wel een paar. Nu moet je wel een splitsing maken tussen de Desktop versie en de Server versie.

Nu heeft iedere distro voor en nadelen, maar als continuiteit een thema is dan zit je bij Ubuntu LTS redelijk safe. De reden is dat je altijd een LTS versie omhoog kan door te upgraden. Wel moet de .1 release uit zijn maar het kan.

Kijk je naar andere gratis distros met een lange support termijn (Alma, Rocky) dan is het antwoord als je wilt upgraden "kan niet, ondersteunen we niet, formatteer en begin opnieuw". LTS versies krijgen over het algemeen ook alleen security updates, geen nieuwe features.

Dus al met al is het een afweging van wat je wilt. Canonical maakt af en toe gekke beslissingen waar je wat van kan vinden maar zo heeft iedere distro wat. Bij Fedora krijg je bijna wekelijks een kernel update. Die zou ik dan weer niet op een server draaien.
Zat bedrijven. Er zijn niet alleen maar redhat-toko’s. Zeker na dat geneuzel van RH mbt Centos zijn er vele clubs naar Ubuntu gegaan. Daar zit nml de mogelijkheid tot enterprise support bij, is bekend en groot, etc. Vele professionele vendors van applicaties ondersteunen tegenwoordig out of the box maar een paar grote distros.

Bedrijven draaien niet elke floepie-distro met een zwamverhaal over een of andere missie en al helemaal niet in het serverpark.
Wij gebruikten voorheen Ubuntu binnen een overheidsomgeving, maar zijn uiteindelijk gemigreerd richting Red Hat. De belangrijkste redenen waren support, lifecycle management en tooling zoals Red Hat Satellite, wat voor patchmanagement echt sterk is.

Een concreet voorbeeld uit mijn ervaring: we hadden een kwetsbaarheid in Squid. Op RHEL 8 draaide Squid 5.x en de upstream-oplossing leek richting Squid 6.x te gaan. Na een ticket bij Red Hat kregen we vrij snel een backported patch voor de ondersteunde RHEL-versie. Bij Ubuntu 22.04 was diezelfde kwetsbaarheid op dat moment naar mijn ervaring nog niet gepatcht.

Voor enterprise-omgevingen is dat heel belangrijk. Daar betaal je niet alleen voor de software zelf, maar vooral voor support, lifecycle, security backports en goede management tooling.

De kosten vallen in verhouding ook mee, zeker als je veel virtualiseert. Met Red Hat Enterprise Linux for Virtual Datacenters kun je in principe 3x ESXi-hosts afdekken en daarop onbeperkt RHEL VM’s draaien, mits de hosts/sockets en voorwaarden correct gelicenseerd zijn.

Daarom vind ik RHEL in een enterprise-context vaak logischer dan Ubuntu, zeker wanneer support, lifecycle, compliance en centraal patchmanagement zwaar meewegen.
Waarom zou een OS wat een LTS variant heeft, per se ook een LTS kernel moeten gebruiken? Zolang er een supported kernel geleverd wordt, is het prima, toch? :) Het is in elk geval niet zo zwart-wit als je denkt dat het is. Ubuntu gebruikt wat dat betreft de modulaire mogelijkheden prima. Daarnaast geeft LTS natuurlijk ook aan dat Canonical langdurig support biedt op wat zij gemaakt hebben, wat dus niet per se hoeft te betekenen dat de kernel dat vervolgens ook moet zijn.

[Reactie gewijzigd door CH4OS op 29 april 2026 23:27]

Nou meestal loopt fedora wel redelijk voor met de kernel versie's ivm ubuntu. Had wel 7.0 verwacht na de upgrade.
Er waren toch enorme performance problemen met postgres op de nieuwe 7.0 kernel? Ik zal nog maar even wachten de upgrade. Vraag me af of die al zijn opgelost.
https://www.phoronix.com/news/Linux-7.0-AWS-PostgreSQL-Drop
Dus omdat PostgreSQL performance problemen heeft, zou een ander moeten wachten met upgraden of updaten? :? Ik begrijp het niet helemaal, want PostgreSQL is geen verplicht onderdeel van Ubuntu of Fedora of zo.

EDIT: Daarnaast is een boel tegenwoordig ook via Docker ontsloten, waarmee de containers op een eigen OS draaien. Het is dus niet per se noodzakelijk dat PostgreSQL op kernel 7.0 komt te draaien, ook al draait de host dat zelf wellicht wel.

[Reactie gewijzigd door CH4OS op 29 april 2026 23:24]

'Het OS maakt nu bijvoorbeeld gebruik van Linux-kernelversie 6.19'

Geen kernel 7 dus, in de officiele release notes staat ook helemaal niets vermeld over een schijnbaar nieuwere kernel oid.
Lijkt me ook vrij rap aangezien 7 net uit is en fedora 44 al eerder zou uitkomen.

[Reactie gewijzigd door DDX op 29 april 2026 16:50]

Dat is ook de laatste stabiele versie tot nu toe. Kernel 7.0 zal waarschijnlijk binnenkort aangeboden worden. Aan de andere kant is het ook niet zo spannend, want het had net zo goed 6.20 kunnen heten, maar Linus Torvalds heeft een persoonlijke afkeer tegen hoge nummers.
Aan de andere kant heeft Linus Torvalds ook een (heerlijk) apart gevoel voor humor en moet je zijn opmerkingen niet altijd even serieus nemen. Al zal de reden nog steeds "because i wanted to" oid zijn.
Je kan ook.de kernel-ml of.kernel-lt installeren. Dit werrk.ook.o.RHEL/Rocky. De kernel.kan je gewoon wisselen los van welke glibc of andere packages je gebruikt. Er is alleen impact opdrivers en hardware.
Het staat je vrij een andere kernel te installeren natuurlijk.
Vele jaren KDE gebruikt op openSUSE, vervolgens 10 jaar macOS. Na een korte poging om weer openSUSE te gebruiken met KDE (enkele uren) toch maar het mij 'onbekende' Fedora geinstalleerd. Wat een verademing! Ik had serieus het idee dat KDE in 10 jaar niet verder was gekomen en nog een foutenfestijn was geworden. Maar het lag niet aan KDE.

OpenSUSE past KDE zwaar aan, Fedora brengt het (bijna) native. Veel stabieler, veel gebruiksvriendelijker. Ik heb de dozen van openSUSE op mijjn kantoor staan (ja kinders, vroeger kwamen distro's op DVD met boekjes) en kan met recht 'voormalig fanboy' genoemd worden, maar ben totaal verrast door de stabiliteit en gebruiksvriendelijkheid van Fedora.


ps. de partitie-manager in mijn Fedora 44 beta installatie was met dramatisch. Dat is hopenlijk geheel opgelost.

[Reactie gewijzigd door BartOtten op 29 april 2026 17:49]

Dit herken ik (als openSUSE gebruiker) totaal niet. Uit nieuwsgierigheid heb ik wel eens gespeeld met Kubuntu, Fedora, Arch+KDE, in Virtual Machines, en de look verschilt echt niks. OpenSUSE voegt een eigen achtergrond toe, en het startmenu is een SUSE icoontje, maar dit valt vanzelfsprekend in één minuut aan te passen.
De stijl en standaardlayout in bredere zin zijn echt identiek, en de "gebruiksvriendelijkheid" kan onmogelijk verschillen, SUSE steekt natuurlijk geen lading tijd aan het saboteren van de KDE software; de KDE tools en instellingen worden niet aangepast. Wellicht had je nog een oude install van OpenSUSE Leap oid? Het "in 10 jaar niet verder was gekomen" laat het eerder klinken als een oude versie, op een of andere manier?

Ik zou bijna zeggen, probeer nog eens een verse install van OpenSUSE Tumbleweed, gewoon in een VM of oud laptopje o.i.d.
OpenSUSE heeft een betere stabiliteit, vanwege openQA: een SUSE-specific programma dat elke dag de nieuwste build uitgebreid automatisch test. OpenSUSE Tumbleweed is vaak meer up-to-date dan Fedora. SUSE is een Europees bedrijf, tegenover het Amerikaanse Red Hat, mocht je dat relevant vinden.
Fedora is ook verademing omdat OpenSUSE, Ubuntu, etc. inderdaad het denken beter te weten. Ze zien niet dat uniek niet betekent een eigen thema, maar de toolset die je gebruikt. Niemand wilt snaps (de meeste althans), toch gebruikt Canonical het. Hun ideeën daarvoor met Unity waren juist erg goed!

OpenSUSE heb ik ook altijd vreemd gevonden. Hun manieren zijn altijd anders. Zoals op hun KDE immutable variant is dan geen firewall aanwezig: niemand had dat nodig want Flatpaks en containers.. Hoewel dat klopt, lijkt me een firewall (desnoods disabled) een prima iets die je mee kan leveren - vrijwel allemaal doen ze dat.
"Verder krijgt Fedora 44 meerdere verbeteringen onder de motorkap. Het OS maakt nu bijvoorbeeld gebruik van Linux-kernelversie 6.19"

Dit is geen verbetering, Fedora 43 en zelfs Fedora 42 draaien ook kernel 6.19.

Dit is juist deel van de filosofie van Fedora, het is quasi-rolling. De basis van het systeem, voornamelijk de kernel, worden voortdurend upgrade, voor veiligheid en hardware support. Ook GPU drivers worden geupdate voor hardware support, en webbrowsers vanwege hogere risico op web security problemen.
De Desktop Environment en andere packages als glibc en openssl blijven fixed tot de volgende major release.
, en webbrowsers vanwege hogere risico op web security problemen
Deze vat ik zo niet. Bij Debian krijgt de stable niet-bleeding edge netjes security patches (gebackport) die hun rolling-release Sid dan al heeft.

Het niet doen aan een rolling-release hoeft niet te betekenen dat je security meteen gatenkaas is.
Backports kunnen een hell worden uiteindelijk. Je patch op basis van een oudere base, wat prima gaat, maar als je 4.4.1 verwacht, maar die is uiteindelijk 4.4.1 met patches backported van 4.5, dan noem ik dat niet echt stabieler, beter of duidelijker.

Als developer verwacht je iets van een bepaalde versie, die backport kan dus ook weer nieuwe issues met zich meebrengen. Bij Debian/Ubuntu patchen ze erop los. Red Hat ook, maar over het algemeen is het bij hun echt alleen als het nodig is.

[Reactie gewijzigd door HollowGamer op 29 april 2026 22:50]

Ik zou persoonlijk de Fedora-gebaseerde distributie "Secureblue" aanraden voor mensen met een verhoogd dreiginsniveau maar die toch Fedora willen gebruiken:

https://secureblue.dev/

https://discuss.privacyguides.net/t/secureblue-atomic-fedora-hardening/16086

[Reactie gewijzigd door Piraat Hein op 29 april 2026 19:21]

Lees ik nou goed dat Bluetooth standaard uitstaat? Wat zijn je eigen ervaringen t.o.v. andere? Deze lijkt wel interessant.
Ben afgelopen jaarwisseling quasi (*) volledig overgestapt op Fedora KDE en zeer tevreden over deze distro. Morgenavond eens updaten, ben eens benieuwd naar die nieuwe login manager. Of Wine 11 in de praktijk veel zal opleveren voor mij persoonlijk, is nog maar de vraag, gegeven Proton-11 en GE-Proton in Lutris. Maar we gaan eens experimenteren.


(*) dualboot met Windows 11 exclusief voor de Kernel level anticheat games.
Yes ik ben blij met DNF5! Hij is er eindelijk!

PackageKit has been updated to use DNF version 5 for software management. This offers a more uniform and reliable software management experience across the various software management frontends (such as Cockpit, Plasma Discover, and GNOME Software)
En hopelijk is Fedora, GNOME 50, ook te porten ‘bare metal’ op een MacBook M1 M2.
Ik heb Fedora lang geprobeerd, maar ervaarde teveel vervelende dingen die ik met Debian (Pop OS) en Arch (CachyOS) gebaseerde distro's nooit heb ervaren.

Zonder al teveel in detail te gaan:
* nvidia + LUKS encryptie prompt = lastig om goed te krijgen (initramfs, dracut, plymouth...)
* problemen met sleep mode in KDE Plasma (ontwaakt soms niet)
* Steam games starten een pak trager op (mogelijks door SELinux)

Ik heb deze issues bijzonder grondig bekeken, de root causes grotendeels gevonden, en beslist dat deze distro niks voor mij was.

Los daarvan vond ik Fedora echt wel goed, vooral door de dev-focus (zoals ingebouwde dev environments), frequente updates, gebackt door Red Hat dus een blijver en goeie forum support.

[Reactie gewijzigd door TheBlackbird op 29 april 2026 17:51]

NVIDIA is geheel opgelost door de nieuwe first-party nvidia-open drivers te gebruiken van de NVIDIA repo’s zelf (dus niet de onofficiële rpmfusion!). Zelfs een day-one upgrade naar F44 werkt zonder slag of stoot met nvidia-open!

Je sleep problemen lijken overigens ook een oud NVIDIA probleem, wat bij mij direct was opgelost door op nvidia-open over te gaan.


Van trage steam heb ik ook geen last, sneller dan op Windows in elk geval…
Of de ublue images / Bazzite.

Ik vind hun images nog altijd te zwaar, maar dit is de enige basis die ik momenteel zie als bruikbaar en immutable dat werkt.
Gisteravond zag ik dat er in de latest tag aurora (immutable fedora) ook 44 was aangeboden en daardoor brak een van mijn pipelines in een fedora image die ik samen met een collega onderhoud.

Het was daarom weer even old school bugs pletten maar ook citrix en de surface kernel heb ik er weer in kunnen krijgen. Het wordt alleen wel een keertje tijd dat citrix zijn spullenboel op orde gaat krijgen want die oude gtk2 libs kunnen echt niet meer.

https://github.com/L0g0ff/KompassOS/commits/main/

https://github.com/L0g0ff/KompassOS/issues/71

Mooi spul dat open source :)
Oplossing voor een onbestaand probleem? Buiten de bekende OS makers Apple, Microsoft, Google) is er geen die je vraagt om een account aan te maken noch verificaties met leeftijd te doen.
Nog niet.

Ben er mee eens dat het er nog niet is dus dat er niet al volle paniek moet zijn, maar elke keer dat iemand heeft gezegd "dit gaat toch niet gebeuren" .. is het altijd toch gebeurd.

De drang naar verificatieplicht blijft gewoon door gaan en al word iets 100 keer geblokkeerd, de 101ste keer komt ie er toch door.
Dat is afhankelijk van waar je woont. Dat hoeft niet alleen de VS te zijn.
Bang dat je je wietje niet meer ongestoord kan roken? Of zit je aan de Pakistaanse hasj. ;)
Hij heeft toch gewoon een punt? Systemd heeft nu een birthday veld per user. Dat betekent nog niets (het is optioneel), maar voor parental control hoeft iemands leeftijd niet echt uit maken toch? Je kiest het filter niveau, net zoals in Enterprise.

Fedora/Red Hat gaat dit wel gewoon doorvoeren, en vlak ook de EU niet uit. Daarvoor hoef je geen wiet te roken (ik rook niet), kijk gewoon naar voorstellen die er gedaan worden (zoals chat control) en kijk verder dan dat.

Om te kunnen reageren moet je ingelogd zijn