7 ms·

Damn. I was enjoying not having to deal with the fun of ZFS and DKMS, but it seems like now bcachefs will be in the same boat, either dealing with DKMS and occa

Damn. I was enjoying not having to deal with the fun of ZFS and DKMS, but it seems like now bcachefs will be in the same boat, either dealing with DKMS and occasional breakage or sticking with the kernel version that slowly gets more and more out of date.

WD-42 1y ago
The article says that bcachefs is not being removed from the mainline kernel. This looks like mostly a workaround for Linus and other kernel devs to not have to deal with Kent directly.
- ffsm8 1y ago
  The three listed options in the OP thread were * Another kernel Dev takes over management and they tread it as a fork (highly unlikely according to their estimate) * Kent hires someone to upstream the changes for him and Kent stops complaining wrt when it's getting merged * Bcachefs gets no maintenance and will likely be removed in the next major release I do not know him personally, but most interactions I've read online by him sounded grounded and not particularly offensive, so I'm abstaining from making any kind of judgement on it. But while I have no stake in this, Drama really does seem to follow Kent around for one reason or another. And it's never his fault if you take him by his public statements - which I want to repeat: he sounds very grounded and not offensive to me whatsoever.
  - sarlalian 1y ago
    If you look at all the places where Kent has had drama, the common element is him and environments that have pretty rigid workflows. The common thread seems to be him not respecting workflows and processes that those places have, that inconvenience his goals. So, he ignores the workflows and processes of those places, and creates a constant state of friction and papercuts for those who he needs to accomplish his goals. They eventually get fed up, and either say no, not working with you anymore, or no, you’re not welcome to contribute here anymore. He’s not super offensive, but he will tell a Debian package maintainer that their process sucks, and the should change it and they are being stupid by following that process. Overall, he seems a bit entitled, and unwilling to compromise with others. It’s not just Kent though, the areas that seem to be the most problematic for him, are when it’s an unstoppable force (Kent), and an immovable wall (Linux / Debian). Working in the Linux kernel is well known for its frustrations and the personal conflict that it creates, to the point that there are almost no linux kernel devs/maintainers that aren’t paid to do the work. You can see a similar set of events happen with Rust4Linux people, Asahi linux project and their R4L drivers, etc.
  - BoredPositron 1y ago
    Grounded? Not offensive? https://lore.kernel.org/lkml/CAHk-=wiLE9BkSiq8F-mFW5NOtPzYrtrXsXiLrn+qXTx4-Sy6MA@mail.gmail.com/ https://lore.kernel.org/lkml/CAHk-=wiLE9BkSiq8F-mFW5NOtPzYrt... https://lore.kernel.org/all/citv2v6f33hoidq75xd2spaqxf7nl5wbmmzma4wgmrwpoqidhj@k453tmq7vdrk/ https://lore.kernel.org/all/citv2v6f33hoidq75xd2spaqxf7nl5wb...
    - ffsm8 1y ago
      The first one is by Linus? And his replies (at least the ones I read) are - to me- less aggressive then the rest of the mails in that chain The second has one offensive remark: > Get your head examined. And get the fuck out of here with this shit. which I thought he admitted was out of line and - said sorry for. Or do I misremember? I admit once again, I'm still completely uninvolved and merely saw it play out on the internet.
      - yencabulator 1y ago
        If you read his replies downthread from that, Kent seems to be going through a lot of effort to not apologize, in any form, and prefers talking about how other people were mean to him. I had high hopes for bcachefs. sigh
- tux3 1y ago
  It's complicated, no one really knows what "externally maintained" entails at the moment. Linus is not exactly poised to pull directly from Kent, and there is no solution lined-up at the moment. Both Linus and Kent drive a hard bargain, and it's not as simple as finding someone else to blindly forward bcachefs patches. At the first sign of conflict, the poor person in the middle would have no power, no way to make anyone back down, and we'd be back to square one. It's in limbo, and there is still time, but if left to bitrot it will be removed eventually.
  - immibis 1y ago
    That person would be accountable to Linus, but not to Kent.
    - tux3 1y ago
      Unfortunately, there's also nothing they can do if Kent says no. Say there's a disagreement on a patch that touches something outside fs/bcachefs, that person can't exactly write their own patches incorporating the feedback. They're not going to fork and maintain their own patches. They'd be stuck between a rock and a hard place, and that gets us back to a deadlock. The issue is that I have never seen Kent back down a single time. Kent will explain in details why the rules are bullshit and don't apply in this particular case, every single time, without any room for compromise. If the only problem was when to send patches, that would be one thing. But disagreements over patches aren't just a timing problem that can be routed around.
      - koverstreet 1y ago
        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 mission is a rock solid commitment to reliability and robustness, including being responsive to issues users hit, and we've seen repeatedly that the kernel process does not share those priorities.
deleted 1y ago
[deleted]
mustache_kimono 1y ago
> Damn. I was enjoying not having to deal with the fun of ZFS and DKMS, but it seems like now bcachefs will be in the same boat, either dealing with DKMS and occasional breakage or sticking with the kernel version that slowly gets more and more out of date. Your distro could very easily include bcachefs if it wishes? Although I think the ZFS + Linux situation is mostly Linux religiosity gone wild, that very particular problem doesn't exist re: bcachefs? The problem with bcachefs is the problem with btrfs. It mostly still doesn't work to solve the problems ZFS already solves.
- kstrauser 1y ago
  > Although I think the ZFS + Linux situation is mostly Linux religiosity gone wild I can think of non-religious reasons to want to avoid legal fights with Oracle.
  - mustache_kimono 1y ago
    >> I can think of non-religious reasons to want to avoid legal fights with Oracle. Oh, certainly, but that's really not the problem posed right now. Oracle's own lawyers have said they see no problem with the combination, and Ubuntu has shipped the Linux + ZFS combination for years without a lawsuit.[0][1] In the 1990s, Microsoft/SCO, like you, would also fear monger about open source and lawsuits, and we in the OSS community mostly called this "FUD" (fear, uncertainty, and doubt). Whereas now, almost 10 years into this experiment, we know more about the ZFS + Linux combination, and what Oracle will do about it, than most other open questions in OSS, and the answer is that some in OSS community have chosen to instead participate in the same kind of FUD because of a very online, very uninformed internecine licensing debate. [0]: https://www.youtube.com/watch?v=PFMPjt_RgXA&t=2260s https://www.youtube.com/watch?v=PFMPjt_RgXA&t=2260s [1]: https://ubuntu.com/blog/zfs-is-the-fs-for-containers-in-ubuntu-16-04 https://ubuntu.com/blog/zfs-is-the-fs-for-containers-in-ubun...
- jchw 1y ago
  > Although I think the ZFS + Linux situation is mostly Linux religiosity gone wild, I think the Linux Kernel just doesn't want to be potentially in violation of Oracle's copyrights. That really doesn't seem that unreasonable to me, even if it feels pointless to you.
NewJazz 1y ago
FWIW DKMS is not the only way to distribute out of tree modules. https://github.com/chimera-linux/ckms https://github.com/chimera-linux/ckms

WD-42 1y ago

The article says that bcachefs is not being removed from the mainline kernel. This looks like mostly a workaround for Linus and other kernel devs to not have to deal with Kent directly.

ffsm8 1y ago
The three listed options in the OP thread were * Another kernel Dev takes over management and they tread it as a fork (highly unlikely according to their estimate) * Kent hires someone to upstream the changes for him and Kent stops complaining wrt when it's getting merged * Bcachefs gets no maintenance and will likely be removed in the next major release I do not know him personally, but most interactions I've read online by him sounded grounded and not particularly offensive, so I'm abstaining from making any kind of judgement on it. But while I have no stake in this, Drama really does seem to follow Kent around for one reason or another. And it's never his fault if you take him by his public statements - which I want to repeat: he sounds very grounded and not offensive to me whatsoever.
- sarlalian 1y ago
  If you look at all the places where Kent has had drama, the common element is him and environments that have pretty rigid workflows. The common thread seems to be him not respecting workflows and processes that those places have, that inconvenience his goals. So, he ignores the workflows and processes of those places, and creates a constant state of friction and papercuts for those who he needs to accomplish his goals. They eventually get fed up, and either say no, not working with you anymore, or no, you’re not welcome to contribute here anymore. He’s not super offensive, but he will tell a Debian package maintainer that their process sucks, and the should change it and they are being stupid by following that process. Overall, he seems a bit entitled, and unwilling to compromise with others. It’s not just Kent though, the areas that seem to be the most problematic for him, are when it’s an unstoppable force (Kent), and an immovable wall (Linux / Debian). Working in the Linux kernel is well known for its frustrations and the personal conflict that it creates, to the point that there are almost no linux kernel devs/maintainers that aren’t paid to do the work. You can see a similar set of events happen with Rust4Linux people, Asahi linux project and their R4L drivers, etc.
- BoredPositron 1y ago
  Grounded? Not offensive? https://lore.kernel.org/lkml/CAHk-=wiLE9BkSiq8F-mFW5NOtPzYrtrXsXiLrn+qXTx4-Sy6MA@mail.gmail.com/ https://lore.kernel.org/lkml/CAHk-=wiLE9BkSiq8F-mFW5NOtPzYrt... https://lore.kernel.org/all/citv2v6f33hoidq75xd2spaqxf7nl5wbmmzma4wgmrwpoqidhj@k453tmq7vdrk/ https://lore.kernel.org/all/citv2v6f33hoidq75xd2spaqxf7nl5wb...
  - ffsm8 1y ago
    The first one is by Linus? And his replies (at least the ones I read) are - to me- less aggressive then the rest of the mails in that chain The second has one offensive remark: > Get your head examined. And get the fuck out of here with this shit. which I thought he admitted was out of line and - said sorry for. Or do I misremember? I admit once again, I'm still completely uninvolved and merely saw it play out on the internet.
    - yencabulator 1y ago
      If you read his replies downthread from that, Kent seems to be going through a lot of effort to not apologize, in any form, and prefers talking about how other people were mean to him. I had high hopes for bcachefs. sigh
tux3 1y ago
It's complicated, no one really knows what "externally maintained" entails at the moment. Linus is not exactly poised to pull directly from Kent, and there is no solution lined-up at the moment. Both Linus and Kent drive a hard bargain, and it's not as simple as finding someone else to blindly forward bcachefs patches. At the first sign of conflict, the poor person in the middle would have no power, no way to make anyone back down, and we'd be back to square one. It's in limbo, and there is still time, but if left to bitrot it will be removed eventually.
- immibis 1y ago
  That person would be accountable to Linus, but not to Kent.
  - tux3 1y ago
    Unfortunately, there's also nothing they can do if Kent says no. Say there's a disagreement on a patch that touches something outside fs/bcachefs, that person can't exactly write their own patches incorporating the feedback. They're not going to fork and maintain their own patches. They'd be stuck between a rock and a hard place, and that gets us back to a deadlock. The issue is that I have never seen Kent back down a single time. Kent will explain in details why the rules are bullshit and don't apply in this particular case, every single time, without any room for compromise. If the only problem was when to send patches, that would be one thing. But disagreements over patches aren't just a timing problem that can be routed around.
    - koverstreet 1y ago
      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 mission is a rock solid commitment to reliability and robustness, including being responsive to issues users hit, and we've seen repeatedly that the kernel process does not share those priorities.

deleted 1y ago

[deleted]

mustache_kimono 1y ago

> Damn. I was enjoying not having to deal with the fun of ZFS and DKMS, but it seems like now bcachefs will be in the same boat, either dealing with DKMS and occasional breakage or sticking with the kernel version that slowly gets more and more out of date. Your distro could very easily include bcachefs if it wishes? Although I think the ZFS + Linux situation is mostly Linux religiosity gone wild, that very particular problem doesn't exist re: bcachefs? The problem with bcachefs is the problem with btrfs. It mostly still doesn't work to solve the problems ZFS already solves.

kstrauser 1y ago
> Although I think the ZFS + Linux situation is mostly Linux religiosity gone wild I can think of non-religious reasons to want to avoid legal fights with Oracle.
- mustache_kimono 1y ago
  >> I can think of non-religious reasons to want to avoid legal fights with Oracle. Oh, certainly, but that's really not the problem posed right now. Oracle's own lawyers have said they see no problem with the combination, and Ubuntu has shipped the Linux + ZFS combination for years without a lawsuit.[0][1] In the 1990s, Microsoft/SCO, like you, would also fear monger about open source and lawsuits, and we in the OSS community mostly called this "FUD" (fear, uncertainty, and doubt). Whereas now, almost 10 years into this experiment, we know more about the ZFS + Linux combination, and what Oracle will do about it, than most other open questions in OSS, and the answer is that some in OSS community have chosen to instead participate in the same kind of FUD because of a very online, very uninformed internecine licensing debate. [0]: https://www.youtube.com/watch?v=PFMPjt_RgXA&t=2260s https://www.youtube.com/watch?v=PFMPjt_RgXA&t=2260s [1]: https://ubuntu.com/blog/zfs-is-the-fs-for-containers-in-ubuntu-16-04 https://ubuntu.com/blog/zfs-is-the-fs-for-containers-in-ubun...
jchw 1y ago
> Although I think the ZFS + Linux situation is mostly Linux religiosity gone wild, I think the Linux Kernel just doesn't want to be potentially in violation of Oracle's copyrights. That really doesn't seem that unreasonable to me, even if it feels pointless to you.

NewJazz 1y ago

FWIW DKMS is not the only way to distribute out of tree modules. https://github.com/chimera-linux/ckms https://github.com/chimera-linux/ckms