Public developer spats put bcachefs at risk in Linux
- Reference: 1732302193
- News link: https://www.theregister.co.uk/2024/11/22/bcachefs_linux/
- Source link:
The bcachefs team is partly funding the development of their next-gen file system using Patreon, where the project lead Kent Overstreet posted a lengthy article about [1]trouble in the kernel . The current dispute has resulted in Linus Torvalds refusing the latest fixes to this radical new file system, and there's a real risk that the Paramount Penguin may fulfill his [2]threat last month to remove the bcachefs from the kernel. This would be a big loss; it took [3]years of work before it was finally included [4]earlier this year .
At least one of the causes of the current situation is that Overstreet posted an [5]intemperate response in an earlier thread, which ended in swearing.
[6]
Now, to be fair, this is very far from the first time that's happened on the Linux kernel mailing list. Indeed, The Register has been [7]reporting on [8]such incidents at least [9]since 2013 . Even since Linus [10]took a break back in 2018 to "get help on how to behave differently," it still [11]occasionally happens .
[12]
[13]
The thing is, up to a point, Torvalds can get away with it. It's his project and he's still the boss. Overstreet isn't, and can't. Indeed, others in general shouldn't, and to prevent it from happening, the kernel team has adopted a [14]code of conduct , and there's a [15]committee to enforce it . It replaces a smaller, simpler code of conduct instituted nearly a decade ago, as [16]we reported at the time .
In this instance, Shuah Khan of the CoC team has [17]remonstrated with Overstreet . Although the tone of the exchange has calmed somewhat, it has yet to bring resolution.
[18]
Overstreet's post is over 6,000 words long, but in The Reg FOSS desk's opinion, he does in fact make his case fairly well. (We have seen vigorous rejection of this in discussions elsewhere, though.)
There are several aspects to the problem here, but one of the biggest is simple human nature. Whereas corporate products' development is driven solely by commercial imperatives, FOSS development is much more personal. People choose to get involved for all kinds of personal reasons, from wanting something to work a little differently (thanks to Eric Raymond, called [19]scratching an itch ), or having a clever idea and wanting to give it to a project, or some other motivation other than simply money. Although many big companies have made a lot of profit thanks to open source, it's made very few individuals rich.
Codes of conduct alone cannot prevent emotional conflicts in what are, for many of the people involved, passion projects. To make matters worse, the people most closely involved often possess the explosive combination of genius-level intelligence and intense personal investment in their projects.
[20]
Nobody is immune from letting their emotions get involved. Recently, the Rust-in-the-kernel [21]project leader quit . Famously, after presenting a conference talk, he was on the receiving end of what's often termed "a question that's more of a comment" – or in this case, more of a complaint – from celebrated Linux file systems developer Ted Ts'o. As it happens, that talk was co-presented by the very same Kent Overstreet.
[22]Linus Torvalds declares war on the passive voice
[23]Double Debian update: 11.11 and 12.7 arrive at once
[24]Linux updates with an undo function? Some distros have that
[25]Arch-based CachyOS promises speed but trips over its laces
[26]Linux Weekly News has a deep-dive into what the talk covered, but an executive summary might be that the Rust folks are proposing changing how the C parts of the kernel work slightly in pursuit of cleaner, more reliable code. Some of the people who wrote that C code are not at all happy about this.
It seems to us that neither side, strictly speaking, is right or wrong. As best as we can understand them, the suggestions seem practical and reasonable. But from the perspective of the folks who developed the existing file systems, years ago in plain old C, their code is good and works fine, so why change it? The result is that, from their own positions and perspectives, both sides are correct. That makes this a tricky discussion to mediate, and that seems to be at the core of the problem.
These things happen in long-running FOSS projects. For instance, in the Emacs world, Alan Mackenzie, who maintains the pivotal [27]CC mode part of the program, just [28]resigned from his role . (CC-Mode assists in editing code in C and C-like languages, which is arguably the single most important use of Emacs, so this is a big deal.)
It's too soon to call how this will end. The personal suspicion of this vulture is that ruffled feathers will be smoothed down and bcachefs will not be permanently dropped. There are many interested parties here who could really use an all-GPL next-generation file system with copy-on-write snapshots, which is more resilient and repairable than Btrfs. We're not convinced that Red Hat is committed enough to its [29]Stratis storage project for that to be it, and no other vendors seem to be very interested.
As for the larger drama around Rust in the kernel and so on, maybe it will blow over, or maybe it will drive the main development efforts elsewhere. It's still possible that something [30]radically simpler may yet supplant it, and relegate Linux to a compatibility layer that only [31]runs inside VMs . Stranger things have happened. ®
Bootnotes
Just yesterday, Torvalds sent a [32]code commit that finally [33]removes ReiserFS from kernel 6.13. That long and [34]tragic story is finally over.
In case you have difficulties opening Kent Overstreet's blog, Patreon has protective measures in place, which gave us problems on some browsers. When we were using Waterfox, it didn't believe this vulture was a human (we assure you, the FOSS desk is an entirely LLM-free zone). You may have to try a few different browsers or machines.
Get our [35]Tech Resources
[1] https://www.patreon.com/posts/trouble-in-116412665
[2] https://www.theregister.com/2024/10/08/linus_torvalds_grammar_complaint/
[3] https://www.theregister.com/2022/03/18/bcachefs/
[4] https://www.theregister.com/2024/01/10/linux_kernel_67/
[5] https://lore.kernel.org/lkml/citv2v6f33hoidq75xd2spaqxf7nl5wbmmzma4wgmrwpoqidhj@k453tmq7vdrk/
[6] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/oses&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2Z0ENDkx1tDYrMVKhYc4rhgAAARQ&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[7] https://www.theregister.com/2016/07/11/linus_torvalds_in_sweary_rant_about_punctuation_in_kernel_comments/
[8] https://www.theregister.com/2015/11/01/linus_torvalds_fires_off_angry_compilermasturbation_rant/
[9] https://www.theregister.com/2013/01/04/torvalds_kernel_bug_rage/
[10] https://www.theregister.com/2018/09/17/linus_torvalds_linux_apology_break/
[11] https://www.theregister.com/2019/06/21/linus_torvalds_rant/
[12] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/oses&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44Z0ENDkx1tDYrMVKhYc4rhgAAARQ&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[13] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/oses&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33Z0ENDkx1tDYrMVKhYc4rhgAAARQ&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[14] https://docs.kernel.org/process/code-of-conduct.html
[15] https://www.kernel.org/code-of-conduct.html
[16] https://www.theregister.com/2015/03/10/linux_kernel_devs_adopt_bill_and_teds_excellent_code_of_conduct/
[17] https://lore.kernel.org/lkml/71b51954-15ba-4e73-baea-584463d43a5c@linuxfoundation.org/
[18] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/oses&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44Z0ENDkx1tDYrMVKhYc4rhgAAARQ&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[19] http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/
[20] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/oses&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33Z0ENDkx1tDYrMVKhYc4rhgAAARQ&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[21] https://www.theregister.com/2024/09/02/rust_for_linux_maintainer_steps_down/
[22] https://www.theregister.com/2024/10/08/linus_torvalds_grammar_complaint/
[23] https://www.theregister.com/2024/09/04/double_debian_update/
[24] https://www.theregister.com/2024/08/01/linux_rollback_options/
[25] https://www.theregister.com/2024/07/23/cachyos_arch_linux/
[26] https://lwn.net/Articles/978738/
[27] https://www.gnu.org/software/emacs/manual/html_mono/ccmode.html
[28] https://lists.gnu.org/archive/html/emacs-devel/2024-11/msg00534.html
[29] https://stratis-storage.github.io/
[30] https://www.theregister.com/2024/02/21/successor_to_unix_plan_9/
[31] https://www.theregister.com/2024/02/23/linux_built_for_a_vm/
[32] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c01f664e4ca210823b7594b50669bbd9b0a3c3b0
[33] https://www.theregister.com/2022/02/24/linux_kernel_takes_a_step/
[34] https://www.theregister.com/2008/04/29/hans_reiser_found_guilty/
[35] https://whitepapers.theregister.com/
we assure you, the FOSS desk is an entirely LLM-free zone
... and with a name like LLiaM, who could doubt it?
Personal investment
"genius-level intelligence and intense personal investment in their projects."
I guess there's an element of ego involved in this, personally I've never got *that* invested in a project even if I'd staunchly defend it again the inferior alternatives or any criticism. Maybe the trick is having an ego big enough to just not care?
Tying yourself too closely to a project is a trap - you'll spend too much time on it well past the point where it stopped being interesting and worse there'll be a long long tail of people asking for your input after you've moved on.
Plus who wants to be a one trick pony when you have the ability to do other things too?
On another note, it's hardly a great product development route where it's driven by clashing egos and you're all dependent on each other for things to happen. It's 'open' but not really...
Every tree...
has it's natural life span. Once it's fully grown it's just a matter of time before senescence sets in. Hopefully, before that process becomes too advanced the tree will have reproduced, but even if not there is usually another nearby tree for the creatures that live on and/or feed on it to move onto.
OSes are not really that different. It's just a question of time.
Are we reaching a monolithic limit?
There are good reasons for Linux having a monolithic kernel and good reasons why it doesn't have a monolithic development team but that's always going to result in some tension.
The bigger the codebase gets the greater the chance of some apparently innocent change causing some unforeseen consequence. But the older the codebase gets, the more people will want to add new stuff while fewer people will be around who know how the old stuff works. Typically, the way you'd deal with that is to modularise your system in some fashion so that developers only had to be aware of the boundaries of the modules they depended on and the internal implementation of one module wouldn't impinge on another - but that would be a rather different beast.
I think it's amazing that Linux has managed to expand its scope so much while retaining most of its architectural principals, but that's largely down to there being one man at the centre who understands how pretty much all of it works. I'm not sure that's scalable - or even healthy - in the long run, but I have no alternative to suggest - it's still mostly not broke. And in any case, everyone will be far more interested in railing against the iniquities of codes of conduct...