Filesystem in Rust - Kent Overstreet

> A passive-aggressive exit, but not unusual compared to other Rust drama. By Linux kernel drama standards, it was a non-event. You have the video segment in text, it was pretty non-technical. "NO! We don't want to encode what our assumptions are! We don't want to learn Rust. What do you mean write down our assumptions?" [VIDEO]

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: [VIDEO] -- and to reiterate, no one is trying force anyone else to learn Rust nor prevent refactorings of C code. Thanks, -Wedson '''

Also linked in the email in the GP. > Lastly, I'll leave a small, 3min 30s, sample for context here: [VIDEO] -- and to reiterate, no one is trying force anyone else to learn Rust nor prevent refactorings of C code.

Filho's exit message had this point: Lastly, I'll leave a small, 3min 30s, sample for context here: [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.

For those curious, this is the link[0] to the filesystems talk with the relevant timestamp. A bit more was discussed in this[1] article as well about Wedson Almeida Filho leaving. [0]: [VIDEO] [1]: [LINK]

i encourage everyone to watch the linked video [0]. reminds me of the recent non-technical arguments made in the freebsd thread [1]. git mailing lists have such a greybeard IRC vibe to them. i will, from now on, use "only accepts patches per mail" as a proxy for "not worth suggesting new ideas to" for all projects. it's a stupid proxy. correlation and causation and all that. but it's a very useful one for your sanity. [0] [VIDEO] [1] [LINK]

That video snippet which was posted by that former Rust/Linux maintainer has an excellent example: [VIDEO] The return type of that get_or_create_inode() function is: Result<Either<ARef<INode<T>>, inode::New<T>>> I'd say that's a pretty good example for 'hideous'. It looks like some of the worst C++ code I've seen and then quickly tried to forget. If stuff like this ends up in the Linux kernel I would be pissed too as a Linux kernel greybeard.

> 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