Bestandssysteem bcachefs blijft toch niet in de Linux-kernel

Bestandssysteem bcachefs verdwijnt uit de Linux-kernel nadat het eerder was gedegradeerd naar 'extern beheerd'. Linux-hoofdontwikkelaar Linus Torvalds verwijdert de code voor dit filesystem uit versie 6.18 van de Linux-kernel. Die release komt eind november of begin december uit.

De code voor bcachefs in de kernel van Linux is volgens Torvalds muf geworden. Hij stelt dat die code dus verwijderd moet worden om verwarring over versies te voorkomen. Bcachefs is eind augustus gedegradeerd om alleen nog door externe partijen te worden beheerd. Dat betekent dat de makers van de Linux-kernel geen pullrequests meer behandelen voor die code en dat de ontwikkeling van bcachefs in de kernel stilstaat.

Op de achtergrond speelde drama in de opensourcewereld, met eigengereide persoonlijkheden, strikte regels voor softwareontwikkeling, felle discussies en botte aanvaringen. Het plan was eind augustus nog dat het geavanceerde bestandssysteem wél in de kernel zou blijven. Dat blijkt nu niet het geval te zijn.

Bcachefs is inmiddels wel beschikbaar als module om aan te haken op de Linux-kernel. In die vorm van de DKMS-module (Dynamic Kernel Module Support) kan verdere ontwikkeling van het bestandssysteem doorgaan. De verwijdering uit de Linux-kernel komt neer op 117.000 regels code, schrijft opensourcenieuwssite Phoronix.

Reacties (43)

[vanaalten]

De titel van dit nieuwsbericht klinkt alsof er iets onverwachts is gebeurd - maar ik vraag mij af of dat terecht is.

Uit de bron-link: "bcachefs was marked 'externally maintained' in 6.17 but the code remained to make the transition smoother. It's now a DKMS module, making the in-kernel code stale, so remove it to avoid any version confusion."

Voor mij klinkt dit als "in 6.17 is besloten er een DKMS module (externe module) van te maken, we hebben deze code nog even laten zitten voor een soepele overgang maar nu kan 'ie er uit" - dus lijkt mij dat dit altijd al de bedoeling was.

[kodak]

Tweakers heeft er eerder al aandacht aan geschonken en toen bleek uit niets dat er meer bedoeling was dan er een externe module van te maken. De tekst kan op meerdere manieren gelezen worden. Achteraf er alleen in lezen wat uit is gekomen is nmm te makkelijk.

[Consequator]

Dat haantjes gedrag in de Linux wereld zit wel eens vaker wat ontwikkeling in de weg volgens mij.

[RobertMe]

Dat zal vast niet veel anders zijn dan het haantjesgedrag in het bedrijfsleven. Enige verschil is dat het in het bedrijfsleven niet op publieke mailinglists wordt uitgevochten.

[Consequator]

Klopt maar meestal is er dan iemand die dan toch kan zeggen van 'dit gaan we doen' zonder dat het bedrijf dan op eens in tweeën splitst en er een stoelendans plaats vind.

Ik denk dat de meeste 'spinoffs' en forks van Linux software, of zelfs de hele distro, enige vorm van drama als grondslag hebben waarbij iemand kwaad is weggelopen en zijn eigen versie is gestart.

En tot op een bepaald niveau is dat prima voor innovatie en zo, maar als het te ver verwaterd dan merk je toch dat er problemen ontstaan.


En de haantjes in de IT sector zijn meestal 'heilige huisjes' of 'koninkrijkjes' waarbij (meestal een senior) ZIJN stukje helemaal heeft afgebakend en andere oplossingen dan het zijne zijn slecht of bestaan niet.

Dat herken ik wel, maar is net even anders dan met software ontwikkeling :-)

[CAPSLOCK2000]

Klopt maar meestal is er dan iemand die dan toch kan zeggen van 'dit gaan we doen' zonder dat het bedrijf dan op eens in tweeën splitst en er een stoelendans plaats vind.

Ook dat klopt, maar in praktijk hebben de meeste projecten slechts één of enkele beheerders die de grote knopen doorhakken. Anderen kunnen het daar mee eens zijn of niet maar zullen zich moeten schikken, of inderdaad forken. Maar eerlijk gezegd wordt er imho veel te veel gemaakt van forks. In praktijk zijn die behoorlijk zeldzaam. Als het al gebeurt dan sterft een van de twee forks meestal vrij snel uit omdat de community een duidelijke keuze maakt.
(Ik heb het hier uiteraard niet over forken als deel van normaal development zoals feature branches).

Het lijkt misschien groter dan het is omdat er nogal wat schreeuwelijken zijn die geen significante rol spelen maar een bek hebben en veel aandacht krijgen als stampvoetend hun eigen fork aankondigen.

Dat neemt niet weg dat bedrijven een voordeel hebben als het gaat over overkoepelend leiderschap, maar dat heeft weinig te maken met forks en meer met samenwerking tussen mensen/projecten die verder niks met elkaar te maken hebben. Zeg maar dat MS er voor kan zorgen dat de ontwikkelaars van Word, Outlook, Teams en Azure met elkaar samenwerken, ook al zijn dat eigenlijk heel verschillende projecten die functioneel helemaal los van elkaar (zouden kunnen) staan.

Ik denk dat de meeste 'spinoffs' en forks van Linux software, of zelfs de hele distro, enige vorm van drama als grondslag hebben waarbij iemand kwaad is weggelopen en zijn eigen versie is gestart.

Tot op zekere hoogte is Linux zelf zo begonnen. Een deel van de oorspronkelijke code was eigenlijik voor een ander OS geschreven, Minix, maar de beheerder daarvan weigerde die patches. Uiteindelijk werd in het project van Linus de 'missing link' gevonden die nodig was om een heel OS te bouwen uit alle verzamelde code.

Als de beheerder van Minix anders had gehandeld dan was Linux waarschijnlijk nooit ontstaan.
Minix was geschreven als onderwijsmateriaal. De beheerder wilde het simpel houden voor zijn studenten en weigerde dus patches als die het educatieve doel niet hielpen. Dat had dus niks te maken met ruzie, maar er was wel een hoop frustratie onder developers die mooie code hadden geschreven die onmiddellijk werd geweigerd.

En tot op een bepaald niveau is dat prima voor innovatie en zo, maar als het te ver verwaterd dan merk je toch dat er problemen ontstaan.

In theorie klopt dat, maar welke concrete voorbeelden heb je in gedachte? Ook dit is in mijn ogen echt heel zeldzaam.

[rbr320]

Klopt maar meestal is er dan iemand die dan toch kan zeggen van 'dit gaan we doen'

Die persoon is er nu ook, zijn naam is Linus Torvalds.

zonder dat het bedrijf dan op eens in tweeën splitst en er een stoelendans plaats vind.

Ik denk dat de meeste 'spinoffs' en forks van Linux software, of zelfs de hele distro, enige vorm van drama als grondslag hebben waarbij iemand kwaad is weggelopen en zijn eigen versie is gestart.

In het bedrijfsleven kan dit meestal gewoonweg niet. Code is eigendom van het bedrijf, er is een licentie voor nodig en je kan en mag er niet zomaar aan ontwikkelen. In de open source gemeenschap heb je deze vrijheid wel.

[bwerg]

Bovendien heb je bij een bedrijf gewoon een arbeidsovereenkomst en moet je als werknemer kort door de bocht doen wat de baas zegt. Bij OS software op basis van vrijwilligerswerk doet ieder wat hij/zij leuk vindt. Waarbij samenwerken vaak wel praktisch en efficiënt is, maar zo niet, dan niet.

[bzzzt]

Klopt maar meestal is er dan iemand die dan toch kan zeggen van 'dit gaan we doen' zonder dat het bedrijf dan op eens in tweeën splitst en er een stoelendans plaats vind.

Dat komt ook in bedrijven voor. Heb meerdere keren van dichtbij gezien dat er soms behoorlijk gevochten werd over de koers van een bedrijf of product en dat mensen die zich gepasseerd voelden opgestapt zijn.

[nonestpraens]

En de haantjes in de IT sector zijn meestal 'heilige huisjes' of 'koninkrijkjes' waarbij (meestal een senior) ZIJN stukje helemaal heeft afgebakend en andere oplossingen dan het zijne zijn slecht of bestaan niet.

Zijn dit niet meer de Windows sysadmins die hun servers als hun geliefde huisdieren aanschouwen?

[latka]

Intel is het gevolg van haantjesgedrag/afsplitsen van een paar mensen bij Fairchild (die op hun beurt weer afsplitst waren van Shockley). Het gebeurt in het bedrijfsleven ook (en best vaak, althans ik heb het de afgelopen 30+ jaar zeker 4 keer zien gebeuren): mensen zijn het niet eens met het bedrijf, krijgen het niet veranderd en gaan solo door. Soms met extra geld van buitenaf of met mensen die ze nog kenden en starten een nieuw bedrijf. Dus ik denk dat je beeld niet helemaal correct is.

[RobertMe]

Klopt maar meestal is er dan iemand die dan toch kan zeggen van 'dit gaan we doen' zonder dat het bedrijf dan op eens in tweeën splitst en er een stoelendans plaats vind.

Dat is dan ook wat Linus nu gedaan heeft. En de bcachefs ontwikkelaar (het gaat immers maar om 1 iemand, niet een groep) kan voor zichzelf verder. Net zoals je in een bedrijf ontslagen wordt als je niet in het team past.

En ook in het bedrijfsleven zie je "forks". Worden die nieuwe Qualcomm socs niet gemaakt door een team (/overgenomen startup) die daarvoor bij Apple de ARM SoCs maakte? Dat is dus ook een team / paar man geweest die zich van Apple afsplitste naar een eigen startup (en later is opgekocht door Qualcomm).
En bv Ubiquiti is ook opgericht door een voormalig Apple medewerker die daar aan de netwerk hardware werkte (toen Apple op een blauwe maandag wat routers en dergelijke heeft gemaakt).
Of de ontslagen Nokia medewerkers die daar aan MeeGo werrkte die vervolgens hun eigen telefoon en OS zijn gaan maken, Jolla/Sailfish.

Ik denk dat de meeste 'spinoffs' en forks van Linux software, of zelfs de hele distro, enige vorm van drama als grondslag hebben waarbij iemand kwaad is weggelopen en zijn eigen versie is gestart.

Ik denk dat dat echt wel reuze meevalt. Er is maar een Linux kernel, niet vele forks. En de toolchain zijn er ook maar twee van, of GNU of muslc. En is het hebben van een aantal desktop environments nu echt zo erg? KDE en GNOME zijn bv totaal niet vergelijkbaar. Niet in uiterlijk noch in filosofie (KDE geeft veel meer keuze / instellingen, GNOME is "what you see is what you get"). En v.w.b. distro's zijn er toch ook wel verschillen. Alleen al verschil in standaard DE bv (Ubuntu vs Fedora is standaard GNOME vs KDE meen ik bv). Maar ook verschil in release schema's, Ubuntu heeft elke 6 maanden een release, Arch Linux volgt een rolling relesse model en geeft dus nooit nieuwe releases uit. En dan heb je nog verschillen in wanneer software wordt opgenomen, Debian releases hebben een harde freeze maanden voor release, terwijl Ubuntu dat veel korter voor de release doet en dus actuelere software heeft. Of aan de kant van Arch Arch zelf dat helemaal bleeding edge is en als vandaag een nieuwe versie van een softwarepakket uit komt zit het uiterlijk volgende week in de repo (en vaak dezelfde dag of een dag later, uitzonderingen zijn Linux, DEs en dat soort zaken). Terwijl als je Manjaro pakt dat gebaseerd is op Arch ze juist wat langer wachten met updates, bv KDE 6 heeft een maand of 2, 3 geduurd voordat die beschikbaar was.

En dat zijn allemaal prima verklaarbare argumenten om voor de ene of de andere distro te kiezen en dus ook fijn dat er "anders denkende" zijn die hun eigen distro opzetten. En als iemand als hobby zijn eigen distro opzet is dat natuurlijk ook helemaal prima, alleen maar meer keuze (maar ik zal het niet snel gebruiken).

En de haantjes in de IT sector zijn meestal 'heilige huisjes' of 'koninkrijkjes' waarbij (meestal een senior) ZIJN stukje helemaal heeft afgebakend en andere oplossingen dan het zijne zijn slecht of bestaan niet.

Dat herken ik wel, maar is net even anders dan met software ontwikkeling :-)

Hoezo is dat anders dan software ontwikkeling? Het is echt niet zo dat het bij software ontwikkeling anders zal zijn dan op andere vlakken.

[markg85]

Ik denk dat dat echt wel reuze meevalt. Er is maar een Linux kernel, niet vele forks.

Wat jij antwoord op @Consequator:

Ik denk dat de meeste 'spinoffs' en forks van Linux software, of zelfs de hele distro, enige vorm van drama als grondslag hebben waarbij iemand kwaad is weggelopen en zijn eigen versie is gestart.

Denk dat je niet helemaal snapt waarop je quote.

Wat hij zegt klopt helemaal. Forks ontstaan door meningsverschillen en vaak wat onderliggend drama of oplopende spanningen. Denk bijvoorbeeld aan Redis met daarna een fork naar valkey. Of de vele openoffice forks door de jaren. Of in grotere omvang de forks van hele besturingssystemen (Debian -> Ubuntu bijvoorbeeld). Of de verschillende forks die ffmpeg in het verleden heeft gehad. Of de forks van openssl die je nu nog heb. Soms is een fork heel succesvol en wordt het zelfs beter dan de oorspronkelijke software, soms leggen ze het bij en wordt de fork weer opgeheven (dat is bij bijvoorbeeld ffmpeg forks gebeurd) maar vaak eindigt een fork geleidelijk aan in de eeuwige bitrot velden.

[bzuidgeest]

maar is net even anders dan met software ontwikkeling

Dat betwijfel ik ten zeerste als persoon met beheer en software ontwikkeling ervaring. Het is gewoon menselijk gedrag en je ziet het in elk vak en op elk niveau.

Ik zie geen probleem met drama en forks. May the "best" thing win. Veel beter dan closed source waar je geen invloed op hebt en elke dag kan verdwijnen/geen onderhoud meer krijgt. Met open source kan je altijd verder.

[Gwaihir]

meestal is er dan iemand die dan toch kan zeggen van 'dit gaan we doen' zonder dat het bedrijf dan op eens in tweeën splitst en er een stoelendans plaats vind.

Eh.. aan de lopende band. En de breuk is doorgaans lastiger en met een diepere kloof.

Iemand die zoiets binnen een bedrijf heeft ontwikkeld, mag er niet zo maar zelf mee verder gaan. Is het keihard van het bedrijf (en zelfs met patenten dichtgetimmerd) dan kan hij alleen verder als hij het over mag nemen. En anders is het toch een soort van opnieuw beginnen. Opnieuw beginnen inclusief een nieuwe naam en opnieuw klanten winnen.

In vergelijking is deze breuk super vloeiend: de status quo (in de kernel) is even bevroren totdat het alternatief er echt was. De dienstverlening is niet onderbroken. Bestaande gebruikers worden vermoedelijk vloeiend gemigreerd.

[JumpStart]

Als je al jaar-en-dag een cyclus hebt waarbij je features mag aandragen en een periode waarin alleen fixes mogen, moet je dan maar het OK vinden dat een ontwikkelaar ondanks dit volledig ingeburgerde gebruik toch features wil toevoegen terwijl ze in de bugfix-only fase zitten?

Ik ben hierin een complete buitenstaander, want Windows gebruiker en dus niet op de hoogte van wat er speelt in Linux-land, maar zelfs ik snap dat hier toch vooral het vingertje naar de ontwikkelaar van bcachefs mag wijzen. (Met dank aan eerdere berichtgeving op T-net hierover.)

[stuiterveer]

Het kan natuurlijk zijn dat @Consequator hier af is aan het geven op Linux Torvalds, maar dat hoeft niet zo te zijn en is niet op te maken uit de tekst. Het kan ook zijn dat hij het heeft over de maintainer van bcachefs, aangezien daar ook absoluut van haantjesgedrag te spreken is.

[JumpStart]

Het artikel gaat over een besluit van Torvalds. Vervolgens wordt er door OP, zonder verdere specifieke naamsvermelding, over haantjesgedrag gesproken.

Dan is dat in ieder geval impliciet een beschuldiging aan het adres van Torvalds.

[stuiterveer]

Het ligt er echt aan met welke bril je het leest. Vergeet niet dat de maintainer zelf "ook" haantjesgedrag was aan het vertonen, en "ook" dat heeft de ontwikkeling van kernelsupport voor bcachefs in de weg gezeten.

Heeft hij het daadwerkelijk over Linus, dan prima, sta ik 100% achter wat je zegt. Maar het is op dit moment onduidelijk over welke van de twee hij het heeft, of dat hij het misschien zelfs over beide personen heeft.

[GarBaGe]

Dat is niet alleen in de Linux wereld, hoor
Ik kom het overal wel tegen in de IT.
Alleen in de Linux wereld is het voor iedereen te lezen en te volgen....

[stuiterveer]

Wat op zich ook weer een gigantisch voordeel is wanneer je een zoveelste maintainer hebt die begint met "wee mij" en zegt dat ze verkeerd behandeld zijn wanneer ze zelf raar bezig zijn.

[Webgnome]

Waarom haantjes gedrag? Zoals @JumpStart al aangeeft. Als je als bedrijf/organisatie een bepaalde werkwijze hebt die jaren en jaren aantoonbaar goed werkt dan moet je daar als 'nieuweling' niet aankomen met 'ja en nu doe ik het anders'. Het gaat er niet om wat jij wil, het gaat er om hoe het team dat er aan werkt kwaliteit kan blijven leveren.

Als dat betekent dat je met release windows werkt etc dan is dat maar zo

[markg85]

Dit gedrag zit in zo ongeveer alle software ontwikkeling in meer of mindere mate. Bij linux is het alleen open en voor iedereen zichtbaar. Reken maar dat dit gebeurd in elk pakket wat jij dagelijks gebruikt. Een ander voorbeeld van een stukje wat publiekelijk zichtbaar was: Chrome met de introductie van jpegxl. Heeft er helemaal ingezeten en was, achter een vlaggetje, aan te zetten. Enorm veel industrie support maar haantje google heeft eigenhandig het de nek omgedraaid om avif (plaatjes formaat van av1) te ondersteunen. Om jou verder te quoten: "zit wel eens vaker wat ontwikkeling in de weg". En dat is wat we zien dus er is zeker veel meer wat we niet zien.

[SilentDecode]

Dat zit het altijd, echter wordt het minder getolereerd in de Linux wereld.

[NoTechSupport]

Bij opensource is het in ieder geval publiekelijker als het op dit soort aanvaringen aankomt.

Al zijn er ook al prachtige resultaten geboekt. Kijk naar hoeveel zaken waarmee we in contact komen één of andere vorm van Linux draaien.

Maar er zijn ook voorbeelden van dingen die minder goed werken. Er is op vlak van Linux Desktop veel te veel fragmentatie. User friendliness en UI is vaak ook een pijnpuntje. En ook op smartphone is het tot nu toe niet veel geworden.

[The Zep Man]

En ook op smartphone is het tot nu toe niet veel geworden.

De meeste smartphones draaien een Linux kernel. Juist daar lijkt Linux (de kernel) het meest succesvol qua gebruikersapparatuur.

[Reactie gewijzigd door The Zep Man op 30 september 2025 12:54]

[RobertMe]

Dat ligt natuurlijk ook een beetje aan de definitie van Linux. Uiteraard zit er in Android een Linux kernel. Maar vaak wordt er verwezen naar GNU/Linux (heeft Stallman toch mooi geregeld dat GNU eerst komt ) en volgens mij gebruikt Android dat niet. (Maar bv Alpine Linux gebruikt het ook niet terwijl de rest van de userspace daar wel weer ook gewoon op beschikbaar is).

[NoTechSupport]

Klopt, ik drukte me onzorgvuldig uit, ze draaien de kernel. Maar ik doelde op een echte smartphone met Linux waar je alle software op kan draaien die je zelf wilt op de manier die je zelf wilt. Niet wat Google je toelaat.

[The Zep Man]

Niet wat Google je toelaat.

Op welke smartphone met Android met GApps kan je niet sideloaden?

Verder is het de fabrikant die bepaalt of je eigen software mag draaien op je smartphone, niet Google. Google vereist niet een gesloten bootloader. Wel stelt Google eisen aan een bootloader die opengebroken kan worden (clearing smartphone, etc.), maar dat hoeft fabrikanten niet tegen te houden.

[Reactie gewijzigd door The Zep Man op 30 september 2025 13:28]

[arithcoder]

Fragmentatie is een double-edged sword. Net omdat er fragmentatie bestaat is het mogelijk om een distro te kiezen die bij u past, na meerderen uit te proberen. In de Windows wereld waar geen fragmentatie bestaat geldt dat als MS iets doet en hun gebruikers er tegen zijn, kunnen ze niet overstappen op een "ander" Windows sinds er maar één Windows is. Niet mee eens met wat MS doet? Pech! Suck it up and live with it! Geen ander Windows om naar over te stappen!

En Linux is heel successvol in de mobiele wereld. Miljaarden smartphones & tablets draaien op Linux.

[ManIkWeet]

Keuzevrijheid is natuurlijk mooi. Maar het probleem is "veel te veel fragmentatie" - er zijn tenminste 5 verschillende "gangbare" of "grote" desktop omgevingen bijvoorbeeld. Die doen allemaal een hoop van het zelfde, maar dan nèt wat anders. Veel verspilde ontwikkeltijd in al die duplicatie.

En daarbovenop moeten alle software ontwikkelaars (of in ieder geval de UI bibliotheken) daar dan ook weer rekening mee houden, een exponentieel probleem.

[Olympus user]

Helemaal mee eens.
Voor de basis maakt het weinig tot helemaal niets uit. De distro's kiezen daarna hun eigen weg.
Ik gebruik Mint, toevallig omdat het mij beter past dan Ubuntu.

[markg85]

Ik heb "stale" in software terminologie nog nooit in het nederlands als "muf" gezien. Volgens mij is in deze context muf ook niet het goede woord. Het idee is stilstaand terwijl upstream door gaat met de ontwikkeling.

Maar ja, dit zat eraan te komen. Het kan als DKMS ook prima leven, zo doen veel andere bestandssystemen het ook (denk bijvoorbeeld aan ZFS).

[postbus51]

Code is telang in de brooddoos geweest .Oftewel niet regelmatig ververst

[familyman]

Al je gelijk hebt, mag dit woord vanaf vandaag worden geintroduceerd in het Nederlands.

'Deze code is zo muf, daar slaat de spruitjeslucht vanaf'.

[Drumar]

De code is gaan schimmelen.

Die code is zo oud, die is ooit nog op kleitabletten aangeleverd

[familyman]

Idd dekt dus ook 'code smells' goed af.

[Milmoor]

In het Twents zou men “slof” gebruiken.

[locke960]

Ik denk dat het correcte woord hier "achterhaald" is.

Niet meer nodig want er is een DKMS module en verouderd omdat het niet meer wordt onderhouden.

[batumulia]

Ik snap wel dat Linus zo moe werd van het gedrag van Kent (developer bcachefs) dat er nu besloten is uit de kernel te halen. Er is bij Kent al meerdere keren aangegeven dat zijn manier van werken niet thuishoort in de ontwikkeling van de kernel, na iedere berisping ging het dan weer een tijdje goed om vervolgens weer in het oude gedrag terug te vallen. Dan is Linus nog vriendelijk geweest, want vroeger had Linus hier al veel eerder korte metten mee gemaakt.

Kent was daarnaast altijd aan het vechten met andere developers die hem wouden helpen, hoe goed zijn code ook is, en hoe goed zijn filesystem ooit kan zijn, is geen excuus voor het gedrag wat hij vertoonde.

[CH4OS]

Overigens, dat bcachefs dan verder zal moeten als DKMS module, is an sich ook niet iets heel slechts of zo. Volgens mij werkt OpenZFS ook op een dergelijke manier en ook dat wordt desondanks alsnog veelvuldig gebruikt. Het is alleen dat het geen vast onderdeel meer is van de kernel zelf, maar het dus als het ware een soort plug-in wordt. An sich is dat ook geen verkeerd idee, aangezien ook niet iedereen bcachefs of OpenZFS gebruikt, dus wellicht is dit beter ook? Zou me niet verbazen als de discussie mede daar om ging.

[MrMonkE]

Mooi, mijn kernel weer kleiner

[twiet]

Als je 't hebt over de grootte van kernelfiles op disk, ja.

Als je 't hebt over de grootte van de kernel in het geheugen, dan meestal nee. Bij de meerderheid van de distributies zijn dit soort functionaliteiten gestopt in kernelmodules, dus bestanden op disk. Ze worden pas in het geheugen geladen als ze nodig zijn (hier: als je een bcachefs filesysteem mount).