- Joined
- Jan 29, 2024
Civilisation never began. Fire was understandable, the wheel is where we completely lost the plot.Civilisation ended when the walkman was invented.
Follow along with the video below to see how to install our site as a web app on your home screen.
Note: This feature may not be available in some browsers.
Civilisation never began. Fire was understandable, the wheel is where we completely lost the plot.Civilisation ended when the walkman was invented.
It's unclear if this is actually real of not; and - if so - may be exaggerated.
return to monkeyCivilisation ended when walking was invented.
Kent FINALLY put everyone else over the edge. Just from this guy's writing, I wouldn't want him anywhere near a team I am on. He is totally unable to play nicely in the sandbox.LWN: Bcachefs goes to "externally maintained" (a)
Phoronix: Linus Torvalds Marks Bcachefs As Now "Externally Maintained" (a)
So, not completely out of the kernel (yet), but not accepting patches.
bcachefs is now marked "Externally maintained" rather than "Supported" (per the linked stories upthread), except no one seems to understand what that means. Kent himself said he doesn't know. I searched the MAINTAINERS file and do not see this "Externally maintained" phrase anywhere else, so it may be innovated just for Kent. It may be symbolic, and Linus will continue to accept pull requests, just perhaps with more friction. Presumably Linus won't remove it from the kernel any time soon, since people are already using it, but then he won't want to leave fixed bugs in, either.I am skeptical Kent will continue development on bcachefs for an extended period now. It's not like he can easily just take it and convert it to working on some other operating system. In a world where that is easy, Kent's nasty attitude would soon turn whomever ran that project against him.
Sorry for the extended post, but I find Kent so eternally frustrating I was counting down time until him and Linus finally had it with each other, and sure enough, it came. Reading posts by Kent always raises my blood pressure and I'm happy that he's almost certainly permanently sidelined from here on out.
*monkereturn to monkey
what is it with linux filesystem creators being completely batshit insaneKent FINALLY put everyone else over the edge. Just from this guy's writing, I wouldn't want him anywhere near a team I am on. He is totally unable to play nicely in the sandbox.
Yes, it's already too late for me. Just go and leave me*monke
I think it means that the kernel version of bcachefs will have a feature freeze with no new pulls allowed again, and in time it will be removed from the kernel entirely in favour of an external repository like ZFS, where Kent can have full control over the release schedule for his filesystem without putting the kernel schedule at risk. AI summary belowbcachefs is now marked "Externally maintained" rather than "Supported" (per the linked stories upthread), except no one seems to understand what that means. Kent himself said he doesn't know. I searched the MAINTAINERS file and do not see this "Externally maintained" phrase anywhere else, so it may be innovated just for Kent. It may be symbolic, and Linus will continue to accept pull requests, just perhaps with more friction. Presumably Linus won't remove it from the kernel any time soon, since people are already using it, but then he won't want to leave fixed bugs in, either.
Bcachefs Externally Maintained
Linus Torvalds has marked bcachefs as "externally maintained" in the Linux kernel's MAINTAINERS file, which signifies that he will no longer accept new pull requests for the filesystem into the mainline kernel. This change, implemented on August 28, 2025, follows prolonged disagreements over development practices, particularly regarding the timing of feature additions and bug fixes. The status indicates that further development and integration of new changes are unlikely to occur within the main kernel tree in the near future.
Despite this, the bcachefs code remains in the mainline kernel, likely to prevent immediate disruption for users who are already relying on it. This means the filesystem will not be removed immediately, but it will not receive new updates or fixes from the core kernel team. The decision effectively shifts the responsibility for maintaining and developing bcachefs outside the primary kernel development process, allowing the project to continue independently, potentially as an out-of-tree solution.
The move is seen as a response to the primary maintainer, Kent Overstreet, reportedly refusing to adhere to established kernel development guidelines, such as avoiding large feature additions during late stages of a release cycle and prioritizing bug fixes. Some community members view this as a necessary step to protect the kernel's stability and integrity, while others express concern about the future of the filesystem and the potential for bit-rot in the in-tree code. The status "externally maintained" is not a standard category in the MAINTAINERS file, leading to speculation that it functions as an informal designation for out-of-tree projects.
There is a strict hierarchy to Linux Kernel development that flows down from Linus. Kent's opinion is relevant as far as Linus will consider it. Linus has long ago set his standards for the kernel and the relevant ceremony around releases. Kent's biggest problem is that he answers only to himself and makes excuses when he needs to violate other people's rules. Until such time as Kent establishes his own *nix kernel and can run things as he sees, he's going to be watching the game from the bleachers since he can't figure out what it means to be part of a team.Kent's view is that his fixes and features are urgent because he doesn't want bcachefs's users to suffer data loss, and also he wants beta testers to be on the latest so he won't field obsolete bug reports and will quickly learn of any new bugs. Linus's view is that submitted changes must follow the established kernel release schedule. These views are currently unreconcilable.
Well, at least Kent hasn't killed anyone. He probably does have strong opinions about the most efficient way to kill someone, however.what is it with linux filesystem creators being completely batshit insane
this is like the second time
Well, it certainly doesn't mean anything good and I don't think this will increase support for bcachefs. Regarding Kent saying "I don't know", he also "doesn't know" why he's being singled out. I'd love to see him join a project with Kenneth Reitz and Lennart Poettering. It might not release any software, but it would make for amusing drama and a lot of gnashing of teeth.bcachefs is now marked "Externally maintained" rather than "Supported" (per the linked stories upthread), except no one seems to understand what that means. Kent himself said he doesn't know.
i wish for TRD, if only to save the poor debian packagers from a small fraction of their eternal suffering"Upstream insists on exact versioning... and also insists that Debian maintainers go on a war to change Debian's Rust policy to his liking. If it's 'my way or the highway', I guess it's the highway." – Debian packager, Aug 2024
insert a joke about the gnu hurd hereThat's not nothing, but consider how different the Linux kernel would be if Linus was the only one allowed to write code for it.
that we know of...Well, at least Kent hasn't killed anyone.
He probably does have strong opinions about the most efficient way to kill someone, however.
well apparently a lot of people care about it, so as long as the quality is good enough for people to understand, somebody else might become the new bcachefs guyI'd imagine its new status means that bcachefs will more or less get feature frozen in the kernel. It's possible someone talented and more compliant than Kent will contribute, it being open source. I am not sure how feasible that is. Hopefully bcachefs doesn't have a bus factor of one. Filesystems written by one person and filesystems that cannot move forward without that one person is probably a really bad idea.
ok it's plain to see that any sane person would keep this guy very far away from the kernelDon't forget Kent is so sloppy he submitted patches that don't even compile which is an odd scenario for someone claiming to care so much about reliability.
"Move fast and break things" is not the way you want to run a filesystem at all. At least, one that keeps your data safe.
It absolutely has a bus factor of one.Hopefully bcachefs doesn't have a bus factor of one. Filesystems written by one person and filesystems that cannot move forward without that one person is probably a really bad idea.
this would be circumvented if some hypothetical gigachad were to familiarize himself with bcachefs, and then hack on a fork while also following basic instructions from top kernel mailing list brassWhat is a SUPER fucking enormously big deal is how Kent has alienated a very large number of very important people in the VFS and MM space to the point that they refuse to interact with him in any shape or form.
That is a pretty fucking serious issue. Not which repo that code lives in.
That is a big deal and why the filesystem will struggle or just die out long term.
KiwiFSthis would be circumvented if some hypothetical gigachad were to familiarize himself with bcachefs, and then hack on a fork while also following basic instructions from top kernel mailing list brass
Sounds like Hector "Definitely not Lina" Martin, who spent months complaining about kernel procedures and then flounced for very similar reasons.Kent's mode of operation is to join a team project or organization. He says he understands the rules. Then the trouble begins. The only one who knows anything in Kent's world is Kent. He begins to ignore the rules, citing them as being "unfair" and "inefficient". If anyone calls him out, he says they are part of the problem. Kent can never be a subordinate. He thinks his own ways of working are the best. Unfortunately for him, Linux is not his project and he is not king.
So with Asahi, bcachefs, Sway... hold on, we might be slowly gathering the ingredients for a lolcow-sourced system. Call it Loonix, maybe.Sounds like Hector "Definitely not Lina" Martin, who spent months complaining about kernel procedures and then flounced for very similar reasons.
Open Source has a lot of advantages over commerical software development, but handling bad actors is not one of them. If Linux was a company, Kent would have been shot out of a cannon and fired long ago.
what is it with linux filesystem creators being completely batshit insane
this is like the second time
Well, at least Kent hasn't killed anyone. He probably does have strong opinions about the most efficient way to kill someone, however.