Live data from Hacker News

Bcachefs Goes to "Externally Maintained"

lwn.net

71–80 of 400 posts

Re: Bcachefs Goes to "Externally Maintained"

#71
post #59
post #9

Is it just me or does Kent seem self-destructively glued to his own idea of how kernel development should work? I don’t doubt that people on all sides have made mis-steps, but from the outside it mostly just seems like Kent doesn’t want to play by the rules (despite having been given years of patience).

I think Kent is in the wrong here, but it really doesn't help that the kernel people from Linus on down are seemingly unable to explain the problem, and instead resort to playground insults. Apart from being unprofessional and making for a hostile work environment, it doesn't really communicate why Kent's actions are problematic, so I've some sympathy for his not believing that they are.

I've seen plenty of times where the problems has been explained to Kent. But he just don't give a shit about the problems of people that isn't himself or that doesn't use his file system experiences.

Re: Bcachefs Goes to "Externally Maintained"

#72
post #64
post #59

Earlier quoted context omitted.

I think Kent is in the wrong here, but it really doesn't help that the kernel people from Linus on down are seemingly unable to explain the problem, and instead resort to playground insults. Apart from being unprofessional and making for a hostile work environment, it doesn't really communicate why Kent's actions are problematic, so I've some sympathy for his not believing that they are.

> it doesn't really communicate why Kent's actions are problematic I agree that the kernel community can be a hostile environment. Though I’d argue that people _have_ tried to explain things to Kent, multiple times. At least a few have been calm, respectful attempts. Sadly, Kent responds to everything in an email except the key part that is being pointed out to him (usually his behavior). Or deflects by going on the…

Definitely not saying that the problems are all on one side here. Agreed that going on the attack was bad (as well as dumb).

I just think that while, yes, the kernel folks have tried to explain, they didn't explain well. The "why" of it is a people thing. Linus needs to be able to trust that people he's delegated some authority will respect its limits. The maintainers need to be able to trust that each other maintainer will respect the area that they have been delegated authority over. I think that Kent genuinely doesn't get this.

Re: Bcachefs Goes to "Externally Maintained"

#74
post #59
post #9

Is it just me or does Kent seem self-destructively glued to his own idea of how kernel development should work? I don’t doubt that people on all sides have made mis-steps, but from the outside it mostly just seems like Kent doesn’t want to play by the rules (despite having been given years of patience).

I think Kent is in the wrong here, but it really doesn't help that the kernel people from Linus on down are seemingly unable to explain the problem, and instead resort to playground insults. Apart from being unprofessional and making for a hostile work environment, it doesn't really communicate why Kent's actions are problematic, so I've some sympathy for his not believing that they are.

People have explaining things, at great length, many times. Many of these have been posted to HN before, either as submissions or comments.

Kent just does not listen. Every time the discussion starts from the top. Even if you do agree on some compromise, in a month or two he'll just do the same thing again and all the same arguments start again.

You can't expect people to detail about four or five years of context in every single engagement for the benefit of interested 3rd parties like you or me.

Re: Bcachefs Goes to "Externally Maintained"

#75
post #69

Who would use a file system which essentially seems to be developed by a single person? A bus-factor of one seems unacceptable for a FS. But maybe I am wrong and there are other developers, then why do they not take over upstreaming if the main developer is unable to collaborate with the kernel community.

It's that good.

Re: Bcachefs Goes to "Externally Maintained"

#76
post #9

Is it just me or does Kent seem self-destructively glued to his own idea of how kernel development should work? I don’t doubt that people on all sides have made mis-steps, but from the outside it mostly just seems like Kent doesn’t want to play by the rules (despite having been given years of patience).

Being an outsider to this whole scene, the whole thread reads very differently to me. Kent seems very patient in explaining his position (and frustrations arising from other people introducing bugs to his code) and the kernel & debian folks are performing a smearing campaign instead of replying to what I see are genuine problems in the process. As an example, the quotes that are referenced by user paravoid are, imho,…

it's waaay simpler than that. Some projects have established rules, and kent doesn't want to follow them. It doesn't matter how nice (or not) he is.

Re: Bcachefs Goes to "Externally Maintained"

#77
post #9

Is it just me or does Kent seem self-destructively glued to his own idea of how kernel development should work? I don’t doubt that people on all sides have made mis-steps, but from the outside it mostly just seems like Kent doesn’t want to play by the rules (despite having been given years of patience).

autism is a hell of a social disability sometimes.

Re: Bcachefs Goes to "Externally Maintained"

#78
post #70
post #56

Earlier quoted context omitted.

Backups are great, but don't help much if you backup corrupted data. You can certainly add verification above and below your filesystem, but the filesystem seems like a good layer to have verification. Capturing a checksum while writing and verifying it while reading seems appropriate; zfs scrub is a convenient way to check everything on a regular basis. Personally, my data feels important enough to make that level o…

FWIW, framed the way you do, I'd say the block device layer would be an *even better* place for that validation, no? > Personally, my data feels important enough to make that level of effort, but not important enough to do anything else. OMG. Backups! You need backups! Worry about polishing your geek cred once your data is on physically separate storage. Seriously, this is not a technology choice problem. Go to Amazo…

Ok I think you're making a well-considered and interesting argument about devicemapper vs. feature-ful filesystems but you're also kind of personalizing this a bit. I want to read more technical stuff on this thread and less about geek cred and yelling. :)

I wouldn't comment but I feel like I'm naturally on your side of the argument and want to see it articulated well.

Re: Bcachefs Goes to "Externally Maintained"

#79
post #50
post #25

Earlier quoted context omitted.

Sadly my nonacore phone's soul is too heavy (or light)? to visit that site.

Worked on my OnePlus 8T running LineageOS with no gapps and using Fennec F-Droid for the browser. Could you have a useragent or extension[1] it didn't like? I know that on my PC, GNOME's Gitlab specifically required me to change my UA to get it to load while every other Anubis config I've come across has been fine. I do notice LKML's is using difficulty 4, though, which I think is higher than I usually see. [1] Due t…

The problem is presumably this: https://anubis.techaro.lol/blog/2025/cpu-core-odd/

Re: Bcachefs Goes to "Externally Maintained"

#80
post #34

Earlier quoted context omitted.

This might not be directly about btrfs but bcachefs zfs and btrfs are the only filesystems for Linux that provide modern features like transparent compression, snapshots, and CoW. zfs is out of tree leaving it as an unviable option for many people. This news means that bcachefs is going to be in a very weird state in-kernel, which leaves only btrfs as the only other in-tree ‘modern’ filesystem. This news about bcache…

Meh. This war was stale like nine years ago. At this point the originally-beaten horse has decomposed into soil. My general reply to this is: 1. The dm layer gives you cow/snapshots for any filesystem you want already and has for more than a decade. Some implementations actually use it for clever trickery like updates, even. Anyone who has software requirements in this space (as distinct from "wants to yell on the in…

The other thing dm/lvm gives you is dogshit performance
Post reply on HN