Bcachefs Goes to "Externally Maintained" • Hacker News Board

Re: Bcachefs Goes to "Externally Maintained"

#251

Post by nirava » Sun, Aug 31, 2025, 2:16 PM UTC

quotemstr wrote: post #168

nirava wrote: post #104

Earlier quoted context omitted.

To list down the current state of things: 1. Regardless of whether correct or not, it's Linus that decides what's a feature and what's not in Linux. Like he has for the last however many decades. Repair code is a feature if Linus says it is a feature. 2. Being correct comes second to being agreeable in human-human interactions. For example, dunking on x file system does not work as a defense when the person opposite…

> Being correct comes second to being agreeable in human-human interactions Prioritizing agreeableness above correctness is the reason the space shuttle Challenger blew up. The bcachefs fracas is interesting and important because it's like a stain making some damn germ's organelles visible: it highlights a psychological division in tech and humanity in general between people who prioritize 1) deferring to authority,…

Ugh, this is a lot of words for nothing.

1. I laid down what I perceived as the state of things. The generalizations I drew from observing the system that is Linux development. Nowhere have I prescribed that kent "follow" my ideas. Simply that he can use these to try to understand the unfairness he feels.

2. Your anarcho-individualistic development ideas sound good in theory, but if they ever worked in practice we might have seen it be more widespread than it is today in team sizes > 3.

You should also note that if the oring is labelled experimental and there's an expectation of failure, it's development and testing will not stop the launch. The shuttle leaves when it leaves, it won't wait for the experimental oring to be done to your liking.

Re: Bcachefs Goes to "Externally Maintained"

#252

Post by aaronmdjones » Sun, Aug 31, 2025, 2:17 PM UTC

evanjrowley wrote: post #129

tw04 wrote: post #127

Earlier quoted context omitted.

There's literally ZFS-on-linux and it works great. And yes, I will once again say Linus is completely wrong about ZFS and the multiple times he's spoken about it, it's abundantly clear he's never used it or bothered to spend any time researching its features and functionality. https://zfsonlinux.org/

Sometimes I wonder how someone so talented could be so wrong about ZFS, and it makes me wonder if his negative responses to ZFS discussions could be a way of creating plausible deniability in case Oracle's lawyers ever learn how to spell ZFS.

As far as I know, the license incompatibility is on the GPL side of the equation. As in, shipping a kernel with the ZoL functionality is a violation of the GPL, not the CDDL. Thus, Oracle would not be able to sue Canonical (Edit: or, rather, have any reasonable expectation of winning this battle), as they have no standing. A copyright holder of some materially significant portion of the GPL code of the kernel would have to sue Canonical for breaching the GPL by including CDDL code.

I am not a lawyer.

Re: Bcachefs Goes to "Externally Maintained"

#253

Post by rastignack » Sun, Aug 31, 2025, 2:18 PM UTC

koverstreet wrote: post #246

mort96 wrote: post #224

Earlier quoted context omitted.

It's so sad to see an excellent engineer such as yourself, building what seems like an excellent filesystem that has the potential to be better than everything else available for Linux for many use cases, completely fail to achieve your goals because you lack the people skills to navigate working as a part of a team under a technical leader. Every comment and e-mail I've seen from you has demonstrated an impressive l…

I get a ton of comments like this. Pointing the finger at the skills I lack and my inability, while ignoring the wider picture, of the kernel burning out maintainers and not doing well on filesystems. It's wearying.

How about acknowledging you’ve been too sharp with words, apologizing, and attempting to move forward ?

I know other people in the kernel do the same mistake as you frequently do on mailing lists. But two wrongs do not make a right.

Re: Bcachefs Goes to "Externally Maintained"

#254

Post by chao- » Sun, Aug 31, 2025, 2:18 PM UTC

p_l wrote: post #212

chao- wrote: post #204

Earlier quoted context omitted.

How many years has it been since Ubuntu started shipping ZFS, purportedly in violation of whatever legal fears the kernel team has? Four years? Five years? I obviously have nothing like inside knowledge, but I assume the reason there have not been lawsuits over this, is that whoever could bring one (would it be only Oracle?) expects there are even-odds that they would lose? Thus the risk of setting an adverse precede…

The legal issues between Linux kernel and ZFS are that Linux license does not allow incorporating licenses with more restrictions - including anything that puts protections against being sued for patented code contributed by license giver.

I am aware of that. I did a bad job phrasing my post, and it came off sounding more confident than I actually intended. I have two questions: (1) What are the expected consequences of a violation? (2) Why haven't any consequences occurred yet?

My understanding is that Canonical is shipping ZFS with Ubuntu. Or do I misunderstand? Has Canonical not actually done the big, bad thing of distributing the Linux kernel with ZFS? Did they find some clever just-so workaround so as to technically not be violation of the Linux kernel's license terms?

Otherwise, if Canonical has actually done the big, bad thing, who has standing to bring suit? Would the Linux Foundation sue Canonical, or would Oracle?

I ask this in all humility, and I suspect there is a chance that my questions are nonsense and I don't know enough to know why.

Re: Bcachefs Goes to "Externally Maintained"

#255

Post by mort96 » Sun, Aug 31, 2025, 2:20 PM UTC

koverstreet wrote: post #246

mort96 wrote: post #224

Earlier quoted context omitted.

It's so sad to see an excellent engineer such as yourself, building what seems like an excellent filesystem that has the potential to be better than everything else available for Linux for many use cases, completely fail to achieve your goals because you lack the people skills to navigate working as a part of a team under a technical leader. Every comment and e-mail I've seen from you has demonstrated an impressive l…

I get a ton of comments like this. Pointing the finger at the skills I lack and my inability, while ignoring the wider picture, of the kernel burning out maintainers and not doing well on filesystems. It's wearying.

You get a ton of comments like this because it's true. There are real problems in the kernel, I've seen how hostile it can be to people who are just trying to do the right thing and upstream their changes etc. But your case isn't that. Your behavior would get you in trouble at any job where you have to follow rules set by other people. Your refusal to treat your part of the kernel as anything other than your personal pet project has destroyed your project's potential.

If this was a month or two ago, I would've written something vaguely optimistic here about how you could still turn this around somehow, about what lessons you could learn and move forward with. But that ship has sailed. Your project is no longer the promising next generation filesystem which could replace ext4 as the default choice. Your role is now that of the developer of some small out-of-tree filesystem for a small group of especially interested users. Nobody wanted this for you, including myself. But you have refused to listen to anyone's advice, so now you're here.

Re: Bcachefs Goes to "Externally Maintained"

#256

Post by nullc » Sun, Aug 31, 2025, 2:23 PM UTC

koverstreet wrote: post #250

quotemstr wrote: post #168

Earlier quoted context omitted.

> Being correct comes second to being agreeable in human-human interactions Prioritizing agreeableness above correctness is the reason the space shuttle Challenger blew up. The bcachefs fracas is interesting and important because it's like a stain making some damn germ's organelles visible: it highlights a psychological division in tech and humanity in general between people who prioritize 1) deferring to authority,…

Thanks, I've been struggling to put this into words. When you're working on the core technology we all depend on, correctness is not optional.

Linux is not correct. Linux has never been correct. Linux will never be correct. An incorrect belief that it is correct can only make it less correct.

You must know this when it comes to your own work. Why isn't bcachefs written in augmented rust with dependent types and formal correctness proofs for every line of code? How could there ever be a data losing bug if you had a formal proof that the file system could never lose data? Wouldn't that be more correct?

Turns out when some strong/broad notion of correctness isn't (practically) possible it is, in fact, very optional.

Good project management is all about managing resources and balancing tradeoffs. Sometimes this means making or allowing some things to be worse for the benefit of something else or in adherence to a process with a proven track record. Almost every choice makes something less correct than it could be-- with a goal of slowly inching towards a more perfect state overall in the long run.

It's also beneficial to rock the boat a bit at times, people can be wrong, processes can need improvement-- but there is a correct level, timing, and approach to achieve the best benefit. I expect that the kind of absolute approach you seem to have adopted in comments is unlikely to be successful at effective beneficial change.

Re: Bcachefs Goes to "Externally Maintained"

#257

Post by koverstreet » Sun, Aug 31, 2025, 2:23 PM UTC

abenga wrote: post #196

nextaccountic wrote: post #171

Earlier quoted context omitted.

> But there are also reasons why things are the way they are, and that is also not unreasonable. It is unreasonable if it leads to users losing data. At this point, the only reasonable thing is to either completely remove support for bcachefs or give timely fixes for critical bugs, there's no middle position that won't willfully lead to users losing their data. This used to be the default for distributions like Debia…

> It is unreasonable if it leads to users losing data. Changing the kernel development process to allow adding new features willy-nilly late in the RC cycle will lead to much worse things than a few people using an experimental file system losing their data in the long term. The process exists for a reason, and the kernel is a massive project that includes more than just one file system, no matter how special its dev…

There's no need for kernel development process to change. New features go in during RCs all the time, it's always just a risk vs. reward calculation, and I'm more conservative with what I send outside the merge window that a lot of subsystems.

This blowup was entirely unnecessary.

Re: Bcachefs Goes to "Externally Maintained"

#258

Post by motorest » Sun, Aug 31, 2025, 2:24 PM UTC

koverstreet wrote: post #248

motorest wrote: post #234

Earlier quoted context omitted.

> Too solve a bug with the filesystem that people in the wild were hitting. So you acknowledge that this last episode involved trying to push new features into a RC. As it was made abundantly clear, not only is the point of RC branches to only get tiny bugfixes after testing, the feature work that was presented was also untested and risked introducing major regressions. All these red flags were repeatedly raised in t…

No, I'm sorry but you're simply wrong. bcachefs has a ton of QA, both automated testing and a lot of testers that run my latest and I work with on a daily basis. The patch was well tested; it was for codepaths that we have good regression tests for, it was algorithmically simple, and it worked perfectly to recover a filesystem from the original bug report, and it performed flawlessly again not long after. I've explai…

> No, I'm sorry but you're simply wrong.

It sounds like you have a hard time coping with reality.

https://www.phoronix.com/news/Linux-616-Bcachefs-Late-Featur...

I repeat: it sounds an awful lot like you are trying to gaslight this thread. Not cool.

When this fact was again explicitly pointed out to you by Linus himself, you even tried to bullshit Linus and try to move the goalpost with absurd claims about how somehow it was ok to force untested and unreviewed features into a RC because somehow you know better about what users want or need as if it was some kind of justification for you to skip testing and proper release processes.

You need to set aside some time for introspection because you sound like you are your own worst enemy. And those you interact with seem to be fed up and had enough of these stunts.

Re: Bcachefs Goes to "Externally Maintained"

#259

Post by koverstreet » Sun, Aug 31, 2025, 2:28 PM UTC

tuna74 wrote: post #220

koverstreet wrote: post #103

Earlier quoted context omitted.

The key thing here is I've never challenged Linus's authority on patches outside fs/bcachefs/; I've quietly respun pull requests for that, on more than one occasion. The point of contention here was a patch within fs/bcachefs/, which was repair code to make sure users didn't lose data. If we can't have clear boundaries and delineations of responsibility, there really is no future for bcachefs in the kernel; my core m…

Linus T is responsible for everything in Linux, it is his project and he is the maintainer. He can do everything he wants in his branch and people just have to accept it. If you want to be responsible you have to fork Linux.

Let's examine this, shall we?

Has he ever even been involved with a bcachefs bug? No, aside from arguing against shipping bugfixes.

Has he contributed in any way, besides merging code? No...

Has he set rules or guidelines that benefited bcachefs reliability? No, but he has shouted down talk about automated testing.

I think you're confusing power with responsibility.

Re: Bcachefs Goes to "Externally Maintained"

#260

Post by toast0 » Sun, Aug 31, 2025, 2:30 PM UTC

petre wrote: post #205

toast0 wrote: post #98

Earlier quoted context omitted.

I apprechiate the argument. I do have backups. Zfs makes it easy to send snapshots and so I do. But I don't usually verify the backups, so there's that. And everything is in the same zip code for the most part, so one big disaster and I'll lose everything. C'est la vie.

What good is a backup if you can't restore it?

Well, I expect that I can restore it, and that expectation has been good enough thus far. :p