Man, fuck this article. It’s heavily implying the filesystem was dropped just because Linus and co dislike the creator, or because he’s said something that they disagree with and they want to shut him down in retaliation.
That is not the case. This guy has routinely and flagrantly not followed the established rules towards kernel development, doing things like pushing big feature updates, filled with bugs, just before the release of a new kernel, when only bug fixes are being accepted.
When he’s respectfully told he can’t do things like that, he gets angry and says he’s better than others, his work is more important, he should be an exception to the rules.
You can’t run a project that way, it’d be chaos. Linus was right to kick him. He has been told if he starts complying with the rules then he can start submitting again.
The only children in this story are the BcacheFS dev, and this article author.
It’s not quite as one sided as you put it, either. The most recent last minute feature was pushed for rc3, and wasn’t big filled. It was also a feature that enhanced stability, which is the reason Kent submitted it there. I’m not saying he’s right, but it’s important context here. And he’s far from the only one who has done this. Someone recently added new hardware support in rc7.
Also, he has improved somewhat. Arguably not as much as he should, but things aren’t as bad as they originally were.
And as to the attitude - he’s in good company, honestly. Especially in regard to Linus, them judging Kent is like a group of lepers judging a beauty contest. That’s the point this article makes very well.
None of this excuses his behaviour, but it is important to put it into context.
When Linus gets pissy, it’s to defend the standards and practices that he and the rest of the kernel community have set to advance the project. Yah, he’s direct and probably more unfiltered than he often should be. But it’s resulted in a product that’s given a spectacularly successful platform for FOSS that would have never existed if the companies that controlled everything in the 90s had their way. I guarantee that for all the feelings that he’s hurt over the years, it’s isn’t a patch on the suffering that Microsoft and IBM have laid on their employees. And people still clamor to contribute to the kernel.
Seems like 99% of the contributors manage to work within that framework and get stuff done, even with the threat of being chewed out for submitting bad code at the wrong time hangs over their heads. Kent apparently can’t manage that so maybe he should fade into the background and let someone else interact with the community for him.
I mean, we could say the same thing about Kent - when he’s getting pissy, it’s about ensuring the filesystem is bulletproof and no one loses data.
Thing is, we’re not talking about getting pissy. We’re talking about getting downright insulting and borderline abusive. Linus got suspended from his own goddamn Kernel for his behavior. Let that sink in for a moment.
And I honestly believe that’s where part of the problem comes from. Kent looks up to Linus in a way, and sees himself as entitled to mimicking Linus’s bad behavior, which turns into a clusterfuck. Linux is still a good kernel despite Linus’s behavior, and bcachefs seems to be pretty good from a technical standpoint despite Kent’s behavior (even the kernel maintainers Kent pissed off admit it). They both shouldn’t be behaving that way, period. But both are very talented from a technical standpoint, which makes policing their behavior that much harder.
Ideally, yes, someone else would take over communication with Linus, but my hope isn’t particularly high at the moment. I wish Kent would calm down (further) and play by the rules more (even though he’s far from the only one who has broken those rules), and I wish Linus would learn to take it as much as he dishes it out.
And that makes it such a shame: bcachefs would be great to have in the kernel from a technical standpoint. It’s the personal conflicts that are really messing things up at the moment.
Linus stepped away on his own, he wasn’t “suspended”, or at least that’s the public story. For the most part, he’s been pretty calm since.
[Sarcasm] Yeah sure, a “personality clash.” It’s definitely a “large and unfortunate mistake” to drop a developer just because you don’t like the way they routinely bollocks up established, reasoned software development practices. 🙄
C’mon, Reg, have a nap or something and cool off.
It looks likely that Overstreet has upset too many important, influential people, and hurt too many feelings — and as a result, Linux is not going to get a new next-gen copy-on-write filesystem. It’s a significant technological loss, and it’s all down to people not getting along, rather than the shared desire to create a better OS. ®
I don’t like how this article is framed as if everyone else not tiptoeing around Kent is The Real Problem. He was given clear warnings and way more second chances than he deserved. He was (and still is) unable to follow the rules and control his temper, and everyone decided he’s a lost cause - as is completely logical. Just because you have a cool toy doesn’t mean everyone is forced to be your friend. Go play in your own sandbox until you learn to follow the rules like everyone else. Consider writing a giant apology letter and giving the Linux community the best gift of all: changed behavior.
Frankly, based on what people in this thread are saying, the developer is unable to follow proper procedures to submit code. I personally would not trust someone like this.
It’s been going for a long time, I’m seriously surprised that it took so long. It’s like having to explain over and over the same thing, and even if the person seems to be willing to cooperate in the moment of the discussion, the next time they do the same.
The author of the article doesn’t seem too terribly stable either.
The device working on BcacheFS is unreliable, and kind of a lazy dickhead. It’s not a personality clash, the guy has been given the commit guidelines, just like every day else, and regularly skirts them and commits problematic code. If you did that in your real job, you would be fired.
We still got BTRFS as our next-gen filesystem, we should be fine.
Only if you like “eventual consistency”, in the sense of “eventually, your data is consistently gone”.
What are you people doing with your PCs? I don’t mean it rude, I’m just curious. I admit I’m just regular home PC user, playing games, watching videos, doing some lame audio editing, nothing too serious. I just installed opensuse with btrfs some 4-5 years ago and never had single FS related problem since then. On the other hand it saved my ass multiple times either when I fucked something up or couple times when certain OS update didn’t work well with my PC.
I’m not saying it’s bulletproof, shit happens all the time, it’s just… Maybe I’m lucky? Just a fun fact: My PC at work with windows had way more problems (including filesystem ones) than I’ve had at home during said time.
Yeah I don’t know either. I had a problem once or twice with it because I powered it off randomly when it locked up under load (did this a lot, this machine is 12 years old and needs maintenance). Btrfs check repair fixed it. Snapper rollback is awesome for updates. Under opensuse at least it seems extremely stable.
Sorta related but these “next gen” FSs are pretty overrated on the performance benchmarks lots of groups like Phoronix do every kernel release.
BTRFS lags behind a ton compared to XFS, even though XFS was originally designed for large file throughput on servers.
Even EXT4 beats BcacheFS and BTRFS on several irl load benchmarks.
Only thing I’ve seen actually keep up is F2FS which iirc is the default on Android these days.
The point of COW filesystems isn’t performance. Comparing XFS and EXT4 to BTRFS/ZFS/Bcache is pointless.
The point of these next gen file systems aren’t raw performance, they are reliability, performance for specific cases, and reduced data usage. For example:
-
Copy on Write means it’s very performant to create snapshots
-
incremental backups are much quicker
-
checksumming means the filesystem directly and reliably detects data corruption
-
built-in support for raid means a simplified setup and integration of scrubbing features into the filesystem, which can then take advantage of checksumming etc.
-
deduplication can automatically recognize duplicated data and as such reduce data use
These are things that tend to reduce performance, not increase it. Which is why, when performance on these filesystems stays the same or even increases, that’s a major accomplishment.
-
Linux is about to lose a feature [Bcachefs (ofc)]– over a personality clash (ofc)
FTFY
@kurushimi @cm0002 From what I understand, Kent Overstreet has attempted to circumvent the release cycle by adding #features to an #RC, which was the final straw. #Linus (Torvalds) has warned him repeatedly, but it wasn’t just him. Based on a comment I read from one of the #kernel #developers, his repeated #antics made it considerably more #difficult for them to complete their #work. So while #technically you might be right, it’s not that simple.
Yep the maintainer repeated threw in stuff late in the release cycle . Here’s one instance
The clash stems from a long‑standing debate on kernel rhythm: Linus enforces strict release-cycle discipline, allowing only minimal fixes during release candidates.
At the same time, Kent submitted substantive changes (a patch implementing the new “journal_rewind” feature, which lets the entire filesystem be reset to an earlier point in time) justified by urgent data-recovery needs, though they landed late in the cycle.
For sure. And it wasn’t that simple during the rust shenanigans in February I’d say, but these personalities love to come up and cause trouble 😅. It’s really the nature of open source though; you’ll find similar in major open source projects. Hashicorp GitHub issues come to mind as an easy example.
