Linux-kernel 6.18 zonder bcachefs-bestandssysteem is uit

Versie 6.18 van de Linux-kernel is uit. Daarin is voor het eerst bcachefs als bestandssysteem verwijderd. Wel zijn er verbeteringen aan andere bestandssystemen, zoals 32bit-ondersteuning voor Ext4-groepen. Ook wordt Linux compatibel voor Apples M2-socs.

Linux-hoofdontwikkelaar Linus Torvalds heeft versie 6.18 van de kernel gepusht. De kernel is de laatste kernelversie die dit jaar nog uitkomt en mogelijk wordt het daarmee een lts-release, maar die status heeft de kernel op dit moment nog niet gekregen.

Linux-kernel 6.18 is de eerste release waaruit bestandssysteem bcachefs is verwijderd. Dat gebeurt na veel ophef en ruzie over het bestandssysteem dat Torvalds aanvankelijk wel en later weer niet in het OS wilde hebben. Tweakers schreef daar eerder dit jaar nog een achtergrondartikel over. In september werd al definitief besloten bcachefs uit de kernel te verwijderen. Dat is nu voor het eerst definitief gebeurd.

Een andere opvallende wijziging is dat de kernel nu officieel ondersteuning heeft voor meer van Apples M2-socs, namelijk de M2 Pro, M2 Max en M2 Ultra. De kernel krijgt verder een nieuwe SPI-driver waarmee aangesloten apparaten werken op virtuele machines en die ondersteuning heeft voor de audioaansluiting in de DualSense-controller.

De volledige releasenotes van de kernel zijn te vinden op kernel.org, maar ook in Tweakers' Downloadssectie.

Reacties (21)

[Uruk-Hai]

Wil die kernel ondersteuning voor M2 socs zeggen dat je voor Apple M2 niet langer vastzit aan alleen Asahi Linux, maar ook een willekeurige andere distro met die kernel kunt gebruiken? Of stel ik het me dan te simpel voor?

[ahwx]

Asahi is eigenlijk een soort collectie software, waaronder een kernel build. Zij leveren nu een Fedora versie, maar alle software en drivers etc kun je bijvoorbeeld ook op Gentoo draaien, zie: https://github.com/chadmed/asahi-gentoosupport


Ze zijn dus niet hun eigen distributie, waar je op doelde (denk ik) is de eerder genoemde Asahi versie van Fedora, zie: https://asahilinux.org/fedora/

[GertMenkel]

in principe was er al weinig dat je aande distro van Asahi vasthield. Iedere distro met een aarch64-build had je aan de Asahi-kernel kunnen lijmen. Er zijn alleen maar weinig mensen die daar de tijd en moeite in steken. Plus, je moet ook de configuraties voor dingen als de speakers meenemen en de bootloader goed instellen, allemaal werk dat de meeste Linuxgebruikers liever aan een distro overlaten.

Veel distros kiezen ervoor om (uitbreidingen op) mainline-gebaseerde kernels te gebruiken. Zodra de distromolen een skag gedraaid heeft en de eerste Linux 6.18-builds uit zijn, ben je op M2 in elk geval van het gedoe af om je eigen kernels te compileren. Dat maakt de kans weer groter dat iemand de andere M2-specifieke configuraties ergens in een pakket online gooit groter, en zo stijgt langzaam het gebruiksgemak.

Over minder dan een half jaar komt Ubuntu 26.04 uit, die zal deze wijzigingen en meer waarschijnlijk meenemen. Voor vandaag is er weinig nieuws mogelijk dat je als tweaker vorige week niet ook al kon doen.

[Reactie gewijzigd door GertMenkel op 1 december 2025 19:08]

[milos]

In priciepe zou dat kunnen werken. Maar je zult eerst zelfs die kernel moeten toevoegen.

Het zal even duren voordat de verschillende grotere distro's deze overnemen.

[NielsFL]

Er zijn al wat andere distro's voor M2. Zelf heb ik Ubuntu Asahi gebruikt en volgens mij is er ook een Fedora versie.

Het werkt ook gewoon prima. Totdat ik de gebruike Mac Mini wilde verkopen en bij het wissen van Ubuntu Asahi dat ding heb gebrickt. Daarmee oppassen dus ;-)

[arjankoole]

Het werkt ook gewoon prima. Totdat ik de gebruike Mac Mini wilde verkopen en bij het wissen van Ubuntu Asahi dat ding heb gebrickt. Daarmee oppassen dus ;-)

werkte zelfs een apple USB recovery stick niet meer? auch! :(

[jbijnens]

Zoals ik het begrijp wil een kernel die M2 processoren ondersteunt nog niet zeggen dat alle apps dan automatisch M2 ondersteunen. Zoals ik het begrijp moeten die wel nog gecompileerd worden voor M2. Een Linux distributie zoals Asahi zorgt ervoor dat het hele ecosysteem van applicaties binnen die distributie op Apple hardware gericht is en alles dus werkt. Als je naar een andere distributie gaat, kan je wel de kernel vervangen, maar wat dan met je Window systeem, je applicaties, ... ?

[i-chat]

Wat je zegt klopt maar half

Dat de Linux kernel ondersteuning heeft voor de m2 wil vooral zeggen dat er drivers en configuratis beschikbaar zijn

Het is niet zo dat Apple een functionele andere architectuur heeft dan bijvoorbeeld x86-64 of arm of mipsel


Daarmee komt je verhaal over hercomoileren grotendeels te vervallen


Dat wil niet zeggen dat een herxomcompile helemaal geen zin heeft of kan hebben maar het is ook niet strikt noodzakelijk

[MacGyverNL]

Het is niet zo dat Apple een functionele andere architectuur heeft dan bijvoorbeeld x86-64 of arm of mipsel

Dat is wel degelijk zo; dat zijn verschillende instructiesets en software gecompileerd voor x86-64 draait gewoon níet op AArch64/ARMv8.6-A. Al die software moet dus wél gecompileerd zijn voor AArch64, en anders gehercompileerd worden. Als bijvoorbeeld een distributie z'n gecompileerde software alleen beschikbaar heeft voor x86-64, zoals (vooralsnog) Arch Linux (Arch Linux Arm is een afgeleide, net als Ubuntu een afgeleide is van Debian), dan kun je die distributie echt niet draaien op een AArch64 chip. En bij Debian moet je de ARM-versies van de software binnenhengelen. Tuurlijk, dat gaat allemaal automatisch daar want Debian is opgezet om meerdere instructiesets te ondersteunen, maar de software is apart gecompileerd voor elke instructieset. Je opties zijn hercompilatie of on-the-fly-emulatie via iets als qemu-user-binfmt, dat is wat Apple zélf doet op Mac OS met Rosetta 2 (met alle nadelen die dát dan weer heeft).

[Nelis123]

Dit is precies wat @i-chat zei. Apple M2 gebruikt een ARM instructieset. Hercompileren is dus niet per se nodig maar kan zinvol zijn: https://simplifycpp.org/?id=a0882

[i-chat]

offtopic:
update: naar aanleiding van het mismod topic.

Het is niet zo dat Apple een functionele andere architectuur heeft dan bijvoorbeeld x86-64 of arm of mipsel

of eigenlijk had ik hier moeten zeggen, in tegenstelling tot ARM, x68(-64) en mipsel zijn de chips van Apple geen eigen architectuur maar gewoon een implementatie daarvan met enkele specifieke (non-breaking add-ons)

je kunt zelfs niet eens zeggen dat apple M1 zich op de zefde manier tot arm verhoudt wat amd64 (of x86-64) is tot x86* want amd64 resulteert wel echt in breaking changes. en zelfs dat wordt door veel puristen nog als 64bit extention aangeduid in plaats van als volwaardige architectuur.

in grote mate kun je verwachten dat: op wat configuratie-geneuzel na het overgrote deel van programmatuur dat voor een raspbery pi gecompileerd is ook zou werken op een M1 iets wat tussen x86 en arm, of tussen mips en itanium nooit zou kunnen wanneer je virtualisatie/translatie-lagen als rosetta even buiten beschouwing laat.

[Reactie gewijzigd door i-chat op 4 december 2025 13:25]

[Hans1990]

Veel applicaties en complete distributies hebben al vele jaren arm64 builds. Die worden ook gebruikt voor Android telefoons, Raspberry Pi's, enzovoort.

Of alles werkt is natuurlijk de vraag. Apple heeft hun emulatie layer Rosetta 2 die x86 naar ARM live binary translation doet. Dat werkt verrassend transparant. Er zijn ook wel tools op Linux beschikbaar, maar of dit even transparant en performant werkt weet ik niet. Als je dan dus bvb een exotische tool of spel wilt spelen kan je daar mogelijk tegenaan lopen..

Maar goed ik zie dat soort bewegingen ook als EOL rek begrippen, bijvoorbeeld ten tijde dat Apple M2 uit hun support cycle gooit en je toch (beveilings)updates wilt blijven ontvangen voor bvb je OS.

[Reactie gewijzigd door Hans1990 op 1 december 2025 18:24]

[PrimusIP]

Ik denk dat dit probleem nog wel jaren weg blijft overigens. M1 doet nog steeds mee in de nieuwste versie en ik verwacht ook nog wel de komende paar jaar. Eerst zullen ze de Intel processor ondersteuning droppen. Daarna zal die Mac nog een paar jaar een verouderde macOS hebben die nog wel gewoon beveiligingsupdates krijgt. En als het zo gaat als nu met de Intel Macs, zul je met open legacy patcher vervolgens gewoon nieuwe macOS versies kunnen installeren op hardware dat officieel niet ondersteund wordt.

[Jerie]

Ik denk dat M1 in 2028 vervalt. Dan is deze namelijk 7 jaar oud, en 7 jaar is duur van hun ondersteuning tegenwoordig. In 2027 stopt Apple met ondersteuning van x86-64. Homebrew volgt deze. Of Open Legacy Patcher gaat werken op M1 dat is onderzoekswaardig. Je hebt in ieder geval Asahi Linux. Wat je mist is firmware updates.

[fenrirs]

Als apple geen x86 builds van MacOS meer uitgeeft dan houdt OCLP gewoon op, er valt niets meer te patchen.
(tot mijn spijt, want mijn 2014 Macbook Pro met 16GB geheugen, 1TB ssd en dual core i7 draait gewoon Sonoma en is voor dagelijks kantoor gebruik prima te doen, vooral het toetsenbord is erg fijn)

[Jerie]

Volgens mij is 2026 het laatste jaar dat de huidige macOS (uit september) nog uitkomt, en dan jaar erna dan krijgt die nog updates, waarna dat ook komt te vervallen. Ik kan er een jaar naast zitten.

Wij hebben hier ook nog twee MBPs uit 2015 liggen. Prima machines. Wel is het zo dat de toetsenbord issues op een gegeven moment zijn opgelost (al in de laatste iteraties van MBPs met x86-64). Nadeel van o.a. MBP 2014 is, hoe zit het met de Bluetooth en WiFi stack. Hier zijn op een gegeven moment grote kwetsbaarheden in gevonden.

[GertMenkel]

Alle normale Linux-programma's worden al jaren lang voor ARM gecompileerd. Heel Debian en Ubuntu doen het prima op ARM. Ik heb zelf in de tijden van Android 4 voor de lol nog een Debian chroot gedraaid op armhf, inclusief volledige xfce en Firefox, gecombineerd met een X11 server voor Android. Je gaat aan de kant van open source maar weinig applicaties missen op aarch64, dit probleem is tien jaar terug eigenlijk al wel opgelost.

In principe kun je met QEMU-static en een kopie van de nodige binaries gewoon amd64-applicaties op ARM draaien. Andersom werkt ook. Het is niet heel snel, vooral omdat je GPU-versnelling en andere hardware-acceleratie en dergelijke mist, maar het draait in principe wel. Heel handig om bijvoorbeeld een chroot voor een raspberry pi mee op te zetten vanaf een PC.

Wil je gamen dan heb je iets als FEX nodig.

Of je distro wel of niet aarch64 ondersteunt ligt er een beetje aan, maar alle grote distros hebben daar gewoon images voor, al zijn er maar weinig die ook mainline Linux aanbieden. Voor Ubuntu en Debian zul je even moeten wachten voor je Linux 6.18 zomaar kunt installeren.

[henk717]

Persoonlijk zat ik op deze kernel te wachten en ben blij dat de LTS minimaal 6.18 wordt dit jaar. Ik volg graag de open source nvidia driver ontwikkeling en ik kreeg daar oorspronkelijk zeer slechte resultaten op. Mijn videokaart (3090) was niet standaard ondersteund via de nieuwe GSP methode, daar moest je een boot parameter voor meegeven en ik wist nooit zeker of die dat wel pakte. Vanaf 6.18 is die instelling eindelijk standaard zodat je kunt gamen zonder gebruik te maken van de propriatary driver mocht je dat willen.

Hier lever je wel veel performance voor in.

Combineer je dit met bijvoorbeeld de kisak fresh ppa op ubuntu of een rolling distro krijg je vanzelf nu performance improvements binnen via het mesa project en hoef je niet meer je bootloader aan te passen.

Voor nu is het leuk speelgoed, maar zodra de performance dichter bij komt wordt het op deze manier een stuk gebruiksvriendelijker en makkelijker te implementeren in bijvoorbeeld SteamOS.

Ik kijk er in ieder geval naar uit naar de dag dat het installeren van nvidia's driver een keuze is en niet langer verplicht.

[The Zep Man]

Ik kijk er in ieder geval naar uit naar de dag dat het installeren van nvidia's driver een keuze is en niet langer verplicht.

Dat zal waarschijnlijk enkel voor nieuwere hardware gelden. Er is veel oudere (maar nog wel ondersteunde) hardware met quirks. Zo krijg je een Turing (mobiele) GPU niet in deep sleep zonder de gesloten kernel driver. Dat komt omdat de GSP firmware dat niet ondersteunt op deze generatie. Nvidia heeft aangegeven dat het onwaarschijnlijk is dat dat ooit ondersteund gaat worden.

[Reactie gewijzigd door The Zep Man op 1 december 2025 19:44]

[henk717]

Klopt maar ze moeten ook ergens een grens trekken. Hun driver maakt gebruik van de mogelijkheden die de GSP biedt en dan moet je die natuurlijk wel hebben. Er zijn helaas kaarten die signed firmware willen hebben en waar de gsp niet bestaat en daar zit je dus voor goed klem op de nvidia release. Dat is een probleem die nvidia zelf heeft veroorzaakt. Maar in ieder geval is dit een mooie ontwikkelingen voor kaarten die in de afgelopen 7 jaar zijn gekocht.

[RoestVrijStaal]

Wat betreft bcachefs hoop ik dat er lessen voor de toekomst uit getrokken zijn.

Zomaar vanwege wat-dan-ook vanuit de kernel een experimenteel bestandssysteem ondersteunen waarbij één persoon het grootste deel van het werk voor zijn rekening neemt, is onhandig en onverstandig zo blijkt.

FUSE en DKMS zijn prima voor ondersteuning van dat soort experimentele bestandssystemen.