So with the recent drama it looks like bcachefs isn’t going to stay in the kernel for too long. What do I do now? I have my root filesystem as bcachefs on multiple devices. Is it possible to migrate to btrfs or ext4?
So with the recent drama it looks like bcachefs isn’t going to stay in the kernel for too long.
That’s way too doomsaying. Even after ReiserFS’ developer was sentenced in 2006, it took till 2022 for it to be deprecated. And it has only recently been left out of of the kernel.
Not the same thing though one was abandoned code they no one is working on and the other is new code where they fuybcant grasp the release schedule. Also doesn’t seem like it has brought in new developers which was one of the reason it was brought in.
Many bcachefs patches are from other contributors. IDK, but I guess the meat is still from Kent. But he claims to be in te process of hiring additionl devs.
There’s no need to jump into conclusions when it’s too early to tell.
If later, it so happens it gets removed, and you don’t want use out of tree stuff, which is still possible through several means, including building your own linux (your own kernel), then you can back all contents of your partitions up, create new partitions with the FS of your preference (ext4, btrfs, whatever), and finally copying over the contents of that last backup. No need to stress out this early, :)
https://news.itsfoss.com/linux-kernel-bcachefs/
For those of us that are out of the loop.
It’s high school level drama. Competent adults will work it out.
I like this response best so far (from the actual mailing list): https://lwn.net/ml/linux-kernel/10576437.nUPlyArG6x@lichtvoll.de/ (from Martin Steigerwald)
Do you really think that power-playing Kent into submission by doing a public apology is doing anything good to resolve the issue at hand?
While it may not really compare to some of the wording Linus has used before having been convinced to change his behavior… I do not agree with the wording Kent has used. I certainly do not condone it.
But this forced public apology approach in my point of view is very likely just to cement the division instead of heal it. While I publicly disagreed with Kent before, I also publicly disagree with this kind of Code of Conduct enforcement. I have seen similar patterns within the Debian community and in my point of view this lead to the loss of several Debian developers who contributed a lot to the project while leaving behind frustration and unresolved conflict.
No amount of power play is going to resolve this. Just exercising authority is not doing any good in here. This needs mediation, not forced public humiliation.
To me, honestly written, this whole interaction feels a bit like I’d imagine children may be fighting over a toy. With a majority of the children grouping together to single out someone who does not appear to fit in at first glance. I mean no offense with that. This is just the impression I got so far. The whole interaction just does not remind me of respectful communication between adult human beings. I have seen it with myself… in situations where it was challenging for me to access what I learned, for whatever reason, I had been acting similarly to a child. So really no offense meant. This is just an impression I got and wanted to mirror back to you for your consideration.
This quote is not the entire response, but most of it. Edit: I totally forgot to include a link. Added now.
power-playing Kent into submission
isn’t the issue that kent thinks the kernel guidelines don’t apply to him because he’s just that good? unless i’m missing something, why should we just let him try to trample the kernel guidelines without even asking for an apology?
this is absolutely the issue… the specific thing he did is irrelevant: you play by the rules, or you gtfo… it doesn’t matter how valuable your contributions are, if you can’t treat people with respect that leads to a toxic culture that eats at the project from the inside
linus was renowned for his insults… he realised (or was told; doesn’t matter at this point) that that behaviour was inappropriate, and his behaviour is now more tempered because it’s important to be able to ensure everyone feels like their work is valued and they’re not just shoveling shit for someone else
and i say this all as someone who is absolutely ecstatic about the prospect of bcachefs and think that his code is among the most important being contributed in the past years and for the next few years: WE NEED A NEW STABLE FILESYSTEM more than almost anything… but if you allow bad behaviour, it erodes the collaborative culture and you just can not allow that in the largest collaborative software project humanity has ever created
When other devs can force a CoC on the actual creator of Linux, that’s when you know they’ve gone to far. It’s his, wtf should anyone else get a say in how it’s governed?
it’s absolutely not his. he is a major and important contributor and person in the community, but linux belongs to humanity and to the community that has now written far more of linux than linus has
While I understand the sentiment, I’d argue that an apology should be made in the same context as what you’re apologizing for. Kent made his statements on the LKML - if his apology is sincere, I don’t think it’s too much to ask to put it there as well
I’m not a fan of forced apology. It’s just there like forcing a billionaire to apology, so some people feel better and to get a false sense. An apology should come from them without asking for one. Otherwise it loses its meaning and is only a formal apology, not a meaningful one. It can even make it worse, because people tend to forget look over the issue as resolved. As said, I do not like the idea at all.
Nobody forced him to apologize. On the other hand, the Linux community isn’t forced to take his patches.
it doesn’t matter if his apology is sincere or not, bc the point is not to make he sincerely repent from his sins. the point is ensuring he will subject himself to the kernel guidelines whether he likes it or not. a public apology means “regardless of how right i think i am, i will now follow the rules of the house”
simple as
You’ll almost never get a forced apology out of an autistic person, anyway. The CoC has no consideration for the neurodivergent.
To me it sounds like Shuah is trying to prove his position has a value while also being on this level of a power trip
Don’t have a knee-jerk reaction to every news post that you see. We have yet to see what will happen and you will have loads of time to decide on what to do when we do know if it will get pulled. You will be able to use your current kernel version with it for as long as you need to even if it does get pulled from the next version. So I would wait and see what actually happens.
Best option is likely a reinstall of your OS to move off it though there are other more involved ways like copying your rootfs off, reformatting and copying it back before reinstalling your bootloader. A reinstall is likely going to be quicker though.
Is bcachefs that good as the dev is saying to justify their bad behavior?
It’s pretty good. No justifying his behaviour tho
How’s the performance compared to other filesystems? Last benchmark I’ve seen it performed pretty poorly compared to btrfs.
It’s a temporary thing and it’s likly Kent will just spend the time too continue development and prepare patches for next cycle instead. The ambition is to take it out of Experimental status sometime in the next year so there’s at least motivation to figure out these things. During the delay testers of this FS can still submit bug reports.
LTS Kernels are not affected, aren’t they? I also wonder if some distributions will patch in bcachefs support for non LTS.
Currently, there’s no serious discussion about removal from mainline. And LTS won’t remove it.
Should it happen, you can still use Kent’s kernel tree as before. Whether distributions ship it - who knows.
If there’s no mainline or dkms support, I’ll move my storage away from it in favor of btrfs that I’ve successfully used the years before instead of switching to LTS. Just because of future maintainability and migration options.