I was spending a lot of my time just doing QA for the rest of the kernel.
You seem to just be painfully misinformed - or you're outright trolling.
2,109 karma · joined July 30, 2012
I was spending a lot of my time just doing QA for the rest of the kernel.
You seem to just be painfully misinformed - or you're outright trolling.
I'm afraid not all opinions are created equal, this isn't design by committee :)
Meanwhile, I no longer have to stress about whether I'll be about to get bugfixes out, actual users seem happy and my life is far better :)
For that you have to dig into the methodology, look at the code, look at user reports, etc.
But you can get a pretty good approximation just from the philosophies and attitudes of the engineers and what they're talking about.
The talk I just gave at the Rust for Linux conference was all about that - how do we make the system debugable, the community aspect of how we respond to bug reports and talk to users, the prep work for the Rust conversion and formal verification and how we're approaching all that.
Reliability doesn't come out of nowhere, "all bugs are shallow with enough eyeballs" really doesn't apply to filesystems. You just have to plan for it, come up with a methodology, and do the work.
I doubt there'd be any real interest in a bastardized fork that only exists so the deep pocketed vendors can get away with code dump and run.
All this has been discussed to death, we don't need people armchair quarterbacking a year later. It's over, it's time to move on.
Actual distro support, and doing it right with people actually communicating with each other, has always been a priority for the project.
At some point I'd like to get our own automated pts runs going, since Michael is not consistent with what hardware he tests on and he hasn't been consistent with getting them out.
Not everyone gets it though, that's for sure.
And, if you want to know if it's mature, I'd trust the user reports over the one liners :)
Sometimes there are ways to make things easier without dumbing them down, but way too many people conflate the two; I get nervous when non engineers say "I've studied this, it should be easy".
And it went in when it did because Redhat was pushing for it and claiming to be supportive - but that never materialized. They wanted to get something for free without investing, or putting in the absolute bare minimum.
A _lot_ of people were saying publicly and privately "dear god yes we need something better than btrfs" - but no one from the existing kernel community was interested in stepping up.
Community's still growing, though. A lot of people have gotten active in making sure bcachefs actually works well for people end to end, and there's a hell of a lot more to shipping a filesystem than just writing kernel code.
A lot of things were tried, people did try to mediate.
The particularly galling thing though was when I finally started looking - post split - comparing bcachefs PRs to other subsystems and especially XFS - I was being more conservative with what I considered a critical bugfix.
There was never a clear statement on what the issue was. What you guys got in public was about as much as I got.
All I can say is - going fast when you're stabilizing and getting bugfixes out the door is what you can and should be doing when you've invested in test coverage, test automation, keeping the codebase clean and asserted, and building up a community that works well together on testing and shaking things out.
I genuinely do not know what they were thinking.
But you might want to check out the bus factor on btrfs too; when a maintainer says "but we've saved Facebook billions and billions of dollars!", calls for the other filesystem maintainer to be ejected from the community, then quits to join Anthropic a month later - that's not a vote of confidence.
I'd be very happy if people could just stop bringing up drama and us factors. We put it behind us a year ago, but it seems not everyone got the memo.
I've been saying it for months, but eventually I'm going to move the automated builds off the 48 core monster and we'll be able to use that for automated perf testing too. The machine we just got has spindles for EC perf testing, but the Hetzner monster has very high end enterprise ssdd.
Also, just got done with the Rust for Linux conference, still not home but here's slides that still need reformatting: https://evilpiepirate.org/~kent/Kangrejos-2026-bcachefs.pdf
I do have a lot more pull requests to merge than I did before. I don't know if you want to count "Kent isn't reviewing PRs fast enough" as drama :)
The community infighting has sucked, but that's a thing that matters primarily for maintainers.
I think most users just want something that works.
And if a threat to the human race does come from AI, it's going to come from OpenAI/Anthropic. Hypercapitalist, secretive, in bed with the government, plus multiple real documented hackings of open source infrastructure already.
We're a hell of a lot safer with China doing the same research out in the open and making it available to anyone. The choice might well be: one or two superintelligent autonomous AIs at OpenAI/Anthropic - or a lot of smaller ones, unable to be controlled but also coming out of a diverse set of environments.
One of those leads to a stable ecosystem where we can all coexist, the other is genuinely terrifying. But make no mistake, from OpenAI/Anthropic this is all motivated by their stock price - when you're in the silicon valley mindset, it distorts your reality. They've convinced themselves that everyone's safer if they stay on top and in control, conveniently ignoring how that benefits them, and I don't believe them for a minute.
They're not proposing anything concrete, and when they do, what do you think the proposal will be? Will OpenAI and Anthropic open themselves for inspection so we can verify they really have stopped developing these "world ending" technologies? Or are their proposals going to be aimed at everyone running open Chinese models?
HAH
No capabilities, or even a sane and useful way of adding capabilities with everything in ring 0, and the flat integer namespacing of users and groups just doesn't work for what userspace needs to do today - hence namespaces, which have introduced their own problems, because (no surprise) trying to graft a tree structure onto a flat integer namespace after the fact is a mess.
Virtualization tried to sidestep all that, but to make it fast the cost has been more driver interfaces to host ring-0 - remember what the original was? - and screwing around a whole bunch with particularly arcane facets of the core ring-0 security boundary, e.g. page tables.
It is a mess.
Lots of companies in the U.S. have fallen victim to that syndrome, but if you used the word "restraint" in that context in Silicon Valley most people would look at you like you're insane.