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

66

Submitter: Master FX

Reacties (66)

Sorteer op:

Weergave:

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.
Ik draaide natuurlijk de laatste versie van Tumbleweed.

openSUSE vernacheld natuurlijk niet moedwillig KDE. Het probleem is dat ze dingen anders doen dan veel andere distro's. Kijk bijvoorbeeld eens wat YaST op de achtergrond allemaal aanpast. Het is ene 'magic' configuratiesysteem wat heel mooi werkt als het werkt, maar in elk ander geval al snel leidt tot problemen.

Voorbeeld: wie is er de baas over je netwerk-instellingen? KDE of YaST? Vaak zie je daar toch problemen ontstaan.

Over een tijdje zal ik het nog eens proberen. Misschien was het een offday.
Hoewel ik geen KDE meer gebruik (the bloated naar mijn beleving, ik houd van simplistisch maar dat is persoonlijk)

Ben ik van Debian naar Ubuntu gegaan. Toen zij met eigen grafisch interface kwamen naar Fedora. (Suse ook nog geprobeerd)

Daar kon ik niet wennen aan het pakket beheer.

En zit nu weer op Ubuntu.

Ik moet daar bij wel zeggen: Ik heb pas bij 2 andere mensen Ubuntu moeten installeren:

Bij mijzelf en 1 iemand geen problemen. Bij 1 iemand anders echt een hel.


Het ligt er dus echt aan.
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.
Snaps vind ik koppijn, flatpaks vind ik ook niet voor alles de oplossing tot nu toe. Dan moet ik wel zeggen dat Flatpaks in Fedora beter geregeld zijn dan in Pop OS wat ik kort gebruikt heb. Voor multiuser is Fedora toch fijner, ook merk ik met mijn Thinkpad dat de integratie beter is dan elk ander platform wat ik hiervoor heb gebruikt.

Ik zit pas vers op Fedora (44) met KDE sinds gisteren om precies te zijn. Tot nu toe bevalt het mij redelijk goed. Moet nog wel even wennen aan DNF gezien ik jaren lang alleen maar apt gebruikt heb en debs.
Ik vind je nogal enthusiast. Ik heb ook tientallen jaren verschillende Linux OS'en gehad, mee gespeeld.

Helaas zie ik naast de package manager versnipperig wat al decennia zo is, toch ook wel gebrekken die al lang en lang geleden toch echt wel moeten zijn opgelost.

Als voorbeeld: De on-board keyboard voor touch capable devices is terug naar de middeleeuwen (KDE), en schijnbaar komt dit door Wayland (Alles moet opnieuw geschreven worden)

Helaas om te zeggen maar de OSK van zelfs Windows XP (jaja, er bestaat een XP Tablet Edition) is nog geavanceerder. Idem dit voor 8/10/11.

Ik vind het zelfs schandalig slecht anno 2026. En ja, KDE ziet er gelikt uit, maar zulke onderdelen zijn OOK van de UI, en de zaakjes zijn zeker niet op orde.

Jammer. Ik had echt gedacht dat dit soort achterstallig onderhoud en quirks anno 2026 niet meer voorkwam op 'Linux'.

Dit weerhoud mij (naast vele andere problemen) nog steeds van om 'definitief' over te stappen.

[Reactie gewijzigd door Marctraider op 30 april 2026 13:33]

Dit weerhoud mij (naast vele andere problemen) nog steeds van om 'definitief' over te stappen.
Ik denk dat je geen enkel OS gaat vinden wat jouw specifieke prioriteit in functionaliteit 100% reflecteert. Want niemand laat Windows liggen om een minder prettig werkend on screen toetsenbord (of duizenden andere bugs of randzaken die daar niet goed geregeld zijn).

Het grote voordeel van open source zou moeten zijn dat iedereen die het kan ook de mogelijkheid heeft functionaliteit te doneren. Dat lijkt in de praktijk helaas vooral te leiden tot honderden IRC clients, terminals en programmeertalen en minder tot specifieke 'saaie' eindgebruikers functionaliteit en nuttige UX analyses. Ook door de fragmentatie van en ruzies over desktops en display servers wordt er een hoop redundant werk gedaan.
U neemt een niche en claimt vervolgens dat het allemaal bagger is. Dat is alsof je een hongerstaking start omdat je spruitjes niet lekker vindt.
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 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.
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. :)
Naar mijn mening is Ubuntu meer voor kleinschalig/hobbymatig gebruik, voor kritische bedrijfsomgevingen zou ik eerder Debian gebruiken (doe ik zelf ook op 4 servers in een DC), rock solid met uptimes van +2 jaar.
Exact dit. Of RHEL. Zeker niet Ubuntu.
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.
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]

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.
Een container is geen VM, niet? Een container gebruikt de kernel van de host. Zie bijvoorbeeld https://www.reddit.com/r/docker/comments/zwty5q/if_docker_is_not_a_lightweight_virtual_machine/.
Je mist hier de kern van het punt. De post gaat niet over of PostgreSQL verplicht is voor Ubuntu of Fedora - dat heb ik beweerd. Het gaat over het feit dat kernel 7.0 aantoonbare regressies introduceert voor een veelgebruikte en kritische workload. Dat is gewoon relevante informatie bij de afweging of je nu upgradet.

En het Docker-argument? Dat maakt het juist erger, niet beter. Docker-containers draaien de kernel van de host - dat is geen isolatie van kernelregressies, dat is precies hetzelfde probleem maar dan één abstractielaag dieper. De syscalls gaan gewoon naar dezelfde kernel. Een PostgreSQL-container op een host met kernel 7.0 heeft exact hetzelfde prestatieprobleem als een bare-metal installatie.

Kortom, ik deel een concreet, gedocumenteerd probleem met een bronvermelding, en het antwoord is een combinatie van een stropopredenering en een technisch onjuist tegenargument.
Maar dan nog begrijp ik niet wat je ermee zeggen wilt, in mijn eerste reactie waar jij op reageert, zeg ik alleen dat Ubuntu 26.04 wel Kernel 7.0 gebruikt, verder niets. Vervolgens schrijf je dat PostgreSQL icm kernel 7.0 performance issues heeft.

Dat is verder allemaal prima (en vervelend voor de PostreSQL gebruikers die zouden willen upgraden), maar niet iedereen gebruikt PostgreSQL, en velen zullen vast ook Ubuntu als hun daily desktop driver gebruiken, niet per se als database server.

Ik heb de kern dus zeker niet gemist (en ik dacht in eerste instantie dat Docker containers eigen kernel hadden, maar wat inderdaad niet zo is, zag ik vandaag zelf ook toen ik het even testte). Ik begrijp alleen de reactie niet op mijn reactie, omdat dus zoals gezegd niet iedereen het gebruikt of nodig heeft.

Ubuntu (en Linux in het algemeen) wordt echt niet meer enkel en alleen voor servers gebruikt (waar PostgreSQL vooral gebruikt wordt).
Er waren toch enorme performance problemen met postgres op de nieuwe 7.0 kernel?
Phoronix is de Telegraaf van Linux nieuws sites. Een hoop opgeklopte verhalen voor de clicks. Er zijn ook echte analyses op dat probleem gedaan en daarbij blijkt dat je een systeem bijna crimineel slecht ingericht moet hebben om last van die issue te hebben (120Gb buffers zonder huge pages te gebruiken).
Er is dus gewoon een oplossing voor en eigenlijk amper een probleem en al zeker niet voor desktop eindgebruikers en/of hobby servers.
'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.
De kernel versie die je noemt (6.9.14) is ook nog maar net een week oud (en EOL omdat het de laatste in de serie is).
Binnen 1 of 2 weken zal Fedora upgraden naar kernel 7.0
"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 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.
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 Verwijderd 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.
Klopt. Bluetooth staat standaard uit om het aanvalsoppervlak te verminderen maar het kan wel gewoon ingeschakeld worden. Het voelt een beetje hetzelfde als de immutable distro Fedora Silverblue, dus niet heel verschillend met de standaard Fedora. Secureblue is erg stabiel en niet zo complex in het gebruik als bijv. Qubes+Whonix, dus ideaal voor mensen die toch een veiliger versie van Linux zoeken maar er niet teveel werk in willen steken, dat is ook de reden dat ik het zelf gebruik. Wel kan de hardware ondersteuning varieren dus is het altijd handig om het even te proberen met de live ISO, maar bij mij werkt alles gewoon. (Ryzen 5 5500, RTX5060) Ook zitten er gesloten drivers in, dus als men een "FSF-approved" distro zoekt is dit misschien niet de beste keuze, ze richten zich voornamelijk meer op veiligheid dan vrijheid. Er is een handig menu op de website voor het selecteren van de juiste ISO voor keuze van de desktop environment en je kunt hier tevems voor de GPU-mogelijkheid kiezen. (zoals de nvidia-open drivers) Hier is een lijst van features die Secureblue zo speciaal maken: https://secureblue.dev/features

[Reactie gewijzigd door Verwijderd op 30 april 2026 08:23]

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.
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 :)
Ik dacht dat de kernel naar 7.0 ging omdat Torvalds geen hogere 6 versie meer wilde uitbrengen.

Om te kunnen reageren moet je ingelogd zijn