The Linux Foundation
15 HN mentions · mentioned in 6 months, 2024–2026
35:16 · 124K views · Jul 9, 2024
Kent Overstreet's Linux Foundation talk about writing a filesystem in Rust. Its Q&A segment, where Rust-for-Linux developers ask about interface semantics, became widely cited.
Mostly cited as evidence of the friction between kernel maintainers and Rust developers, notably in Wedson Almeida Filho's resignation.
15 comments from Hacker News
> starting a project out of grudge How many times has this succeeded for fundamental work? I can think of a couple, including Xorg and GCC. I don't know if those cases can be characterized as "grudges" exactly but, in each instance, someone was unsatisfied with the prevailing conditions, forked the work, and then subsumed the legacy. Doubtless there have been far more failures than successes. I also know that computing probabilities based on such ratios is simple minded: other factors exist and the equation is non-linear. > But I think Linux isn't at that position yet. I was disturbed by the irrational behavior I saw in this talk[1]. What the presenter sought was reasonable: communicate the intended semantics so Rust kernel developers can track the evolution. This was somehow understood as: forego C and become a Rust programmer, take responsibility for our work and maintain it going forward. No, I do not believe the former implies the latter. There are endless silos, both formal and informal, for both good reasons and bad reasons, permeating all intellectual work, whether "open" or not. It is entirely reasonable to imagine that this pattern can be employed among reasonable people for the matter at hand, especially for something like file systems, where even parallel implementations can and do exist simultaneously. If this behavior is prevalent enough then drastic steps are justified. Whether they're feasible or not is another matter, and also a many factored, non-linear calcu
It's also not truthful because many of the Rust maintainers are long time C contributors. Marcan also linked to this resignation of a Rust Maintainer: [LINK] which references this fantastic exchange: this video I am not a C person, or a kernel level person, I just watch this from the sideline to learn something every now and then (and for the drama). But this exchange is really stunning to me. It seems so blatantly obvious to me that systematically documenting (in code!) and automatically checking semantic information that is required to correctly use an API is a massive win. But I have encountered this type of resistance (by very smart developers building large systems) in my own much smaller and more trivial context. To some degree, the approach seems to be: "If I never write down what I mean precisely, I won't have to explain why I changed things." A more charitable reading of the resistance is: Adding a new place where the semantics are written down (code, documentation and now type system) gives one more way in which they can be out of sync or subtly inconsistent or overly restrictive. But yeah, my intuitive reaction to the snippet above is just incredulity at the extreme resistance to precisely encoding your assumptions.
yeah, here is the message on lkml [ [LINK] ] ''' Hey folks, This is as short a series as one can be: just removing myself as maintainer of the Rust for Linux project. I am retiring from the project. After almost 4 years, I find myself lacking the energy and enthusiasm I once had to respond to some of the nontechnical nonsense, so it's best to leave it up to those who still have it in them. To the Rust for Linux team: thank you, you are great. It was a pleasure working with you all; the times we spent discussing technical issues, finding ways to address soundness holes, etc. were something I always enjoyed and looked forward to. I count myself lucky to have collaborated with such a talended and friendly group. I wish all the success to the project. I truly believe the future of kernels is with memory-safe languages. I am no visionary but if Linux doesn't internalize this, I'm afraid some other kernel will do to it what it did to Unix. Lastly, I'll leave a small, 3min 30s, sample for context here: this video -- and to reiterate, no one is trying force anyone else to learn Rust nor prevent refactorings of C code. Thanks, -Wedson '''
> And then he can't help himself. After being so reasonable, he throws shade on Rust. Shade that is just unfortunately, just false? Many discussions online (and offline) suffer from a huge-group of people who just can't stop themselves from making their knee-jerk reactions public, and then not thinking about it more. I remember the "Filesystem in Rust" video ( this video ) where there are people who misunderstand what the "plan" is, and argue against being forced to use Rust in the Kernel, while the speaker is literally standing in front of them and saying "no one will be forced to use Rust in the Kernel". You can literally shove facts in someone's face, and they won't admit to being wrong or misunderstand, and instead continue to argue against some points whose premise isn't even true. I personally don't know how to deal with this either, and tend to just leave/stop responding when it becomes clear people aren't looking to collaborate/learn together, but instead just wanna prove their point somehow and that's the most important part for them.
Filho's exit message had this point: Lastly, I'll leave a small, 3min 30s, sample for context here: this video -- and to reiterate, no one is trying force anyone else to learn Rust nor prevent refactorings of C code. First comment to this article is insightful. >The “file system maintainer” had a more legitimate question than most comenters have allowed. Under Linus’s rules for maintainers, when an intrface is changed it is the responsibility of the person requesting the change to submit patches for all other uses of the interface. That requires the “filesystem maintainer” to patch Rust code – which he is unqualified to do. That means he can no longer change any interface, which is a big change in Linux policy that Linus would need to address. It seem that Filho is not correct in his statement. There must be policy change or maintainers must be forced to learn Rust.