7 ms·

I am also a Patreon supporter, and I intentionally didn't switch to bcachefs until it was merged into the kernel. After all, Linus would never break userspace r

I am also a Patreon supporter, and I intentionally didn't switch to bcachefs until it was merged into the kernel. After all, Linus would never break userspace right? I am also frustrated by this whole debacle, I'm not going to stop funding him though Bcachefs is a solid alternative to btrfs. It's not at all clear to me what really happened to make all the drama. A PR was made that contained something that was more feature-like than bugfix-like, and that resulted in a whole module being ejected from the kernel? I really wish, though that DKMS was not such a terrible a solution. It _will_ break my boot, because it always breaks my boot. The Linux kernel really needs a stable module API so that out-of-tree modules like bcachefs are not impossible to reliably boot with.

stycznik 1y ago
>It's not at all clear to me what really happened to make all the drama. A PR was made that contained something that was more feature-like than bugfix-like, and that resulted in a whole module being ejected from the kernel? This isn't just a one time thing, speaking as someone who follows the kernel, apparently this has been going on pretty much since bcachefs first tried to get into Linus's tree. Kent even once told another kernel maintainer to "get your head examined" and was rewarded with a temporary ban. Edit: To be fair, the kernel is infamous for being guarded by stubborn maintainers but really I guess the lesson to be learned here is if you want your pet project to stick around in the kernel you really can't afford to be stubborn yourself.
- danw1979 1y ago
  > I guess the lesson to be learned here is if you want your pet project to stick around in the kernel you really can't afford to be stubborn yourself. Amen. And to your point about it being a "pet project" - I'm sure I could go look at the commit history, but is anyone other than Kent actually contributing meaningfully to bcachefs ? If not, this project sorely needs more than one person involved.
- LeFantome 1y ago
  > this project sorely needs more than one person involved. I hold out some hope that somebody else will get involved in bcachefs and that the new person will be able to resubmit bcachefs to the mainline. My impression is that many people respect the technology and would be happy to have it back--they just cannot work with Kent. But that is the reasons this will probably not happen. It does not appear that anybody wants to work with Kent.
ChocolateGod 1y ago
> After all, Linus would never break userspace right? But bcachefs never lived in userspace even before it was merged
- boroboro4 1y ago
  In my opinion any family lives in user space, through a implicit contract of filesystems and data stored on disk?
  - ChocolateGod 1y ago
    Applications do not talk to the filesystem directly, they talk to the generic I/O syscalls on the kernel which handles the internal filesystem calls. Those generic syscalls are (supposed to) don't change, the internal filesystem calls can and do change. This is one reason why ZFS regularly breaks, on top of it can't use GPL exports.
    - cesarb 1y ago
      > Applications do not talk to the filesystem directly, Sometimes, they do. For instance, BTRFS_IOC_CLONE to do a copy-on-write clone of a file's contents (now promoted to other filesystems as FICLONE, but many other ioctl operation codes are still btrfs-specific; and other filesystems have their own filesystem-specific operations).
LeFantome 1y ago
I also waited until bcachefs was in the mainline. And I have been loving it. In fact, I even have multiple systems using it as root. Rock solid. DMKS is not going to work for me though. Some of the distros I use do not even support it. Chimera Linux uses ckms. As for how we got here, It was not just one event. Kent repeatedly ignored the merge window, submitting changes too late. This irked Linux. When Linus complained, Kent attacked him. And Kent constantly ran down the LKML and kernel devs by name (especially the btrfs guys). This burned a lot of bridges. When Linus pushed Kent out, many people rushed to make it permanent instead of rushing to his defense. Kent lost my support in the final weeks by constantly shouting that he was a champion for his users while doing the exact opposite of what I wanted him to do. I want bcachefs in the kernel. Kent worked very hard to get it pushed out. It really is a great file system though.
- webstrand 1y ago
  yeah I'm probably going to have to start building my own kernel
- koverstreet 1y ago
  I need to write up a proper patreon post on all this stuff, because there's a lot of misinformation going around. No, I was not "ignoring the merge window". Linus was trying to make and dictate calls on what is and is not a critical bugfix, and with a filesystem eating bug we needed to respond to, that was an unacceptable situation.
  - 1oooqooq 1y ago
    this crowd is wild. the author answer is voted down :) edit: by the time i commented it was already dark text. guess it recovered.
    - khimaros 1y ago
      if you read the LKML archives closely, you'll find this sort of reply from koverstreet (deflecting all responsibility while taking none) as typical as it is deeply misguided.
yjftsjthsd-h 1y ago
> I intentionally didn't switch to bcachefs until it was merged into the kernel. After all, Linus would never break userspace right? It was explicitly marked experimental.
- webstrand 1y ago
  Experimental, to me, means "it might eat your data, have backups" not "we might decide to remove this module from the kernel for non-technical reasons, good luck users" Reiserfs sat in the kernel for years after he went to prison and didn't get removed on such short notice even though it was equally if not more unmaintained.
  - yjftsjthsd-h 1y ago
    > Experimental, to me, means "it might eat your data, have backups" not "we might decide to remove this module from the kernel for non-technical reasons, good luck users" I don't think the kernel devs share that definition. > Reiserfs sat in the kernel for years after he went to prison and didn't get removed on such short notice even though it was equally if not more unmaintained. Reiserfs wasn't marked experimental.
    - webstrand 1y ago
      Although there are "experimental" labels on features in the kernel, there's no coherent definition for what that means. Historically most distros have enabled CONFIG_EXPERIMENTAL features by default, until the flag was deemed meaningless and removed. Linux has never removed a mainline-merged feature this quickly. Features in staging may be removed quickly, but bcachefs was merged into mainline. The bcachefs removal, not to mention the removal timeline, is unprecedented for a mainline-merged feature. There's never been any expectation that experimental means it may be removed on short notice. Going forward, I'll agree with you: mainline does not care about users of experimental features. But it's disingenuous to suggest that this has always been the expectation.
      - 1y ago
thayne 1y ago
> A PR was made that contained something that was more feature-like than bugfix-like, and that resulted in a whole module being ejected from the kernel? From what I can tell, what happened is that was just a trigger for a clash of personalities between Linus and Kent, both of whom have a bit of a temper, and refused to back down, which escalated to this.
Hendrikto 1y ago
> After all, Linus would never break userspace right? It was marked experimental. No promises were made. > It's not at all clear to me what really happened to make all the drama. A PR was made that contained something that was more feature-like than bugfix-like, and that resulted in a whole module being ejected from the kernel? If you followed the whole saga, Kent had a history of being technically excellent but absolutely impossible to work with. He did not follow the kernel development process over and over again, instead choosing to post long rants and personal attacks to the mailing lists. Instead of accepting that he has to adapt, he always had (still has) the attitude that he knows best, everybody else are idiots and should just accept his better judgement. Of course the rules should apply… to anyone but him, because his work is special. Moreover, this was not a one PR thing. Linus actually had a long history of defending Kent, being patient, bending the rules, and generally putting up with him. This is unambiguously 100% Kent’s fault, which is very sad, because — as mentioned before — Kent’s work is technically excellent. He had a lot of good will that he squandered in spectacular fashion.

stycznik 1y ago

>It's not at all clear to me what really happened to make all the drama. A PR was made that contained something that was more feature-like than bugfix-like, and that resulted in a whole module being ejected from the kernel? This isn't just a one time thing, speaking as someone who follows the kernel, apparently this has been going on pretty much since bcachefs first tried to get into Linus's tree. Kent even once told another kernel maintainer to "get your head examined" and was rewarded with a temporary ban. Edit: To be fair, the kernel is infamous for being guarded by stubborn maintainers but really I guess the lesson to be learned here is if you want your pet project to stick around in the kernel you really can't afford to be stubborn yourself.

danw1979 1y ago
> I guess the lesson to be learned here is if you want your pet project to stick around in the kernel you really can't afford to be stubborn yourself. Amen. And to your point about it being a "pet project" - I'm sure I could go look at the commit history, but is anyone other than Kent actually contributing meaningfully to bcachefs ? If not, this project sorely needs more than one person involved.
LeFantome 1y ago
> this project sorely needs more than one person involved. I hold out some hope that somebody else will get involved in bcachefs and that the new person will be able to resubmit bcachefs to the mainline. My impression is that many people respect the technology and would be happy to have it back--they just cannot work with Kent. But that is the reasons this will probably not happen. It does not appear that anybody wants to work with Kent.

ChocolateGod 1y ago

> After all, Linus would never break userspace right? But bcachefs never lived in userspace even before it was merged

boroboro4 1y ago
In my opinion any family lives in user space, through a implicit contract of filesystems and data stored on disk?
- ChocolateGod 1y ago
  Applications do not talk to the filesystem directly, they talk to the generic I/O syscalls on the kernel which handles the internal filesystem calls. Those generic syscalls are (supposed to) don't change, the internal filesystem calls can and do change. This is one reason why ZFS regularly breaks, on top of it can't use GPL exports.
  - cesarb 1y ago
    > Applications do not talk to the filesystem directly, Sometimes, they do. For instance, BTRFS_IOC_CLONE to do a copy-on-write clone of a file's contents (now promoted to other filesystems as FICLONE, but many other ioctl operation codes are still btrfs-specific; and other filesystems have their own filesystem-specific operations).

LeFantome 1y ago

I also waited until bcachefs was in the mainline. And I have been loving it. In fact, I even have multiple systems using it as root. Rock solid. DMKS is not going to work for me though. Some of the distros I use do not even support it. Chimera Linux uses ckms. As for how we got here, It was not just one event. Kent repeatedly ignored the merge window, submitting changes too late. This irked Linux. When Linus complained, Kent attacked him. And Kent constantly ran down the LKML and kernel devs by name (especially the btrfs guys). This burned a lot of bridges. When Linus pushed Kent out, many people rushed to make it permanent instead of rushing to his defense. Kent lost my support in the final weeks by constantly shouting that he was a champion for his users while doing the exact opposite of what I wanted him to do. I want bcachefs in the kernel. Kent worked very hard to get it pushed out. It really is a great file system though.

webstrand 1y ago
yeah I'm probably going to have to start building my own kernel
koverstreet 1y ago
I need to write up a proper patreon post on all this stuff, because there's a lot of misinformation going around. No, I was not "ignoring the merge window". Linus was trying to make and dictate calls on what is and is not a critical bugfix, and with a filesystem eating bug we needed to respond to, that was an unacceptable situation.
- 1oooqooq 1y ago
  this crowd is wild. the author answer is voted down :) edit: by the time i commented it was already dark text. guess it recovered.
  - khimaros 1y ago
    if you read the LKML archives closely, you'll find this sort of reply from koverstreet (deflecting all responsibility while taking none) as typical as it is deeply misguided.

yjftsjthsd-h 1y ago

> I intentionally didn't switch to bcachefs until it was merged into the kernel. After all, Linus would never break userspace right? It was explicitly marked experimental.

webstrand 1y ago
Experimental, to me, means "it might eat your data, have backups" not "we might decide to remove this module from the kernel for non-technical reasons, good luck users" Reiserfs sat in the kernel for years after he went to prison and didn't get removed on such short notice even though it was equally if not more unmaintained.
- yjftsjthsd-h 1y ago
  > Experimental, to me, means "it might eat your data, have backups" not "we might decide to remove this module from the kernel for non-technical reasons, good luck users" I don't think the kernel devs share that definition. > Reiserfs sat in the kernel for years after he went to prison and didn't get removed on such short notice even though it was equally if not more unmaintained. Reiserfs wasn't marked experimental.
  - webstrand 1y ago
    Although there are "experimental" labels on features in the kernel, there's no coherent definition for what that means. Historically most distros have enabled CONFIG_EXPERIMENTAL features by default, until the flag was deemed meaningless and removed. Linux has never removed a mainline-merged feature this quickly. Features in staging may be removed quickly, but bcachefs was merged into mainline. The bcachefs removal, not to mention the removal timeline, is unprecedented for a mainline-merged feature. There's never been any expectation that experimental means it may be removed on short notice. Going forward, I'll agree with you: mainline does not care about users of experimental features. But it's disingenuous to suggest that this has always been the expectation.
    - 1y ago

thayne 1y ago

> A PR was made that contained something that was more feature-like than bugfix-like, and that resulted in a whole module being ejected from the kernel? From what I can tell, what happened is that was just a trigger for a clash of personalities between Linus and Kent, both of whom have a bit of a temper, and refused to back down, which escalated to this.

Hendrikto 1y ago

> After all, Linus would never break userspace right? It was marked experimental. No promises were made. > It's not at all clear to me what really happened to make all the drama. A PR was made that contained something that was more feature-like than bugfix-like, and that resulted in a whole module being ejected from the kernel? If you followed the whole saga, Kent had a history of being technically excellent but absolutely impossible to work with. He did not follow the kernel development process over and over again, instead choosing to post long rants and personal attacks to the mailing lists. Instead of accepting that he has to adapt, he always had (still has) the attitude that he knows best, everybody else are idiots and should just accept his better judgement. Of course the rules should apply… to anyone but him, because his work is special. Moreover, this was not a one PR thing. Linus actually had a long history of defending Kent, being patient, bending the rules, and generally putting up with him. This is unambiguously 100% Kent’s fault, which is very sad, because — as mentioned before — Kent’s work is technically excellent. He had a lot of good will that he squandered in spectacular fashion.