Rust in Linux lead retires rather than deal with more "nontechnical nonsense"

https://arstechnica.com/gadgets/2024/09/rust-in-linux-lead-retires-rather-than-deal-with-more-nontechnical-nonsense/

by stalfosknight • 2 years ago

69 84 2 years ago

arstechnica.com

alephnerd• 2 years ago

I wish OSS projects had way less drama.

Rust for Linux had great potential, and would have been a cool alternative to the existing C driven model.

At least eBPF has diverse corporate sponsorship, so drama is somewhat tempered.

Would be great if more companies pitched in to help the FOSS ecosystem, otherwise the only option is an Open Core model.

SoftTalker• 2 years ago

All projects have drama. The bigger the project the more drama. Just how people are.

MayeulC• 2 years ago

It's just the current lead retiring, Rust for Linux is far from dead.

progmetaldev• 2 years ago

I agree on the desire for less drama, but being as OSS has lots of support from people that have made it their passion, I'd expect less drama would mean less caring about the project. Having companies support OSS project more could help, but would also need to be balanced by what is "best" for the project, which could just push drama more towards being monetarily driven. I just hope that this doesn't become an issue that causes a fracture big enough to split the community.

pitched• 2 years ago

As a casual Rust user, I feel it’s a bit ridiculous to think something could outdo Linux only by choice of programming language. Is that the “nontechnical nonsense” here?

3836293648• 2 years ago

No, bullying is

hgaskj• 2 years ago

The quote from T'so in the article is hardly bullying. I found it telling that this was presented as evidence of hostility.

Predictably, the Rust people play the victims while they are the ones who are asking something from all other kernel developers.

AdeptusAquinas4• 2 years ago

I support the c coders. Rewriting linux in rust is an existential threat to the infosec industry where I work

minkles12• 2 years ago

You can still write security software that fucks up the kernel in Rust!

Edit: just in case anyone took this too seriously, it was facetious.

doubled112• 2 years ago

Would a new competitor "cloudstrike-rs" be too blatant a trademark infringement?

antisthenes• 2 years ago

Well, the infosec industry itself is an existential threat to sane, responsive software for power users without the cult of safetyism, so it is potentially still a net win.

The safest software is the one that does nothing.

AdeptusAquinas4• 2 years ago

That's the spirit! People with attitudes like that are why my salary keeps going up.

pdimitar• 2 years ago

Very sad event. People gatekeeping so hard is just flabbergasting to see.

Cieric• 2 years ago

I personally have complaints about bringing rust into the Linux kernel (not a maintainer or contributor so my opinion matters very little), however making changes to the kernel to make it safer or more robust should always be welcome.

I'm curious if this is a case of only getting a single side of the story or not though. I've heard a lot from the rust side, but nothing from the c side of the issue (obviously response is pending.) I'm going to wait on forming an opinion on the limited information currently available.

logicchains• 2 years ago

I'd guess compile time would be a complaint, since Rust generally takes a lot longer to compile than equivalent C. Safety is one thing, but it isn't the be-all and end-all of kernel development; feature development is also important, and reducing productivity impacts that.

Aeolos• 2 years ago

Rust is a significantly more productive language than C. It's not even a comparison.

Proof: Asahi Lina wrote an entire driver for a modern GPU, with zero reported runtime crashes, and explicitly stated this would have been impossible in C.

DSMan1952763• 2 years ago

I've very casually followed this process (lwn articles, read a few emails) and honestly I feel like this was predictable, the problem is the maintenance cost this places on the maintainers. The kernel is developed as one whole thing, the internal C APIs get changed and those changes are applied to all the code contained in the codebase. If there's Rust code calling those APIs then it needs to be fixed as well and they don't know how to do that.

Obviously you can argue over whether the need to maintain the Rust code would end up improving the C code as a result, but ultimately Linus isn't pushing hard for this to happen. Those who want Rust in the kernel need to convince those who will end up maintaining the Rust code why it's worth having, and I don't think that step has been successful.

steveklabnik8• 2 years ago

the problem is the maintenance cost this places on the maintainers. ... If there's Rust code calling those APIs then it needs to be fixed as well and they don't know how to do that.

This is not the case. The C folks are allowed to break the Rust. The Rust folks are committed to fixing it. The existing maintainers do not have any extra work to do, unless you view the Rust folks saying "hey an email when you break stuff would be nice so we can fix it quickly" is extra work.

minkles12• 2 years ago

Gonna write my own kernel, with Rust, blackjack and hookers!

That's how this ends.

And I'm fine with that. May the best solution win.

hindsightbias2• 2 years ago

Prediction: And in 20 years, Rustnix coders will be gatekeeping the next shiny language.

minkles12• 2 years ago

Nah they will be scratching their butts like GNU Herd programmers are. Momentum is a bitch. It's why Windows still exists.

arvigeus• 2 years ago

Welcome to RedoxOS! https://www.redox-os.org/

wongogue• 2 years ago

It is the hobby project of Cosmic DE’s main developer. I don’t think he wants to target the ubiquity of Linux.

minkles12• 2 years ago

starts porting Emacs to it

cmrdporcupine• 2 years ago

I understand some major parts of Fuchsia are Rust-y, and Rust is welcome there.

Maybe that's a project people could pile into. Though as a Google project, it's unlikely to have the open community spirit that Linux has.

vlovich123• 2 years ago

Things like this remind me of Planck's principle:

A new scientific truth does not triumph by convincing its opponents and making them see the light, but rather because its opponents eventually die and a new generation grows up that is familiar with it

It's interesting to hear the complaint is "you can't make me learn another language" from someone like Ted Tso. Learning your 2nd language is very hard but at some point it becomes routine, especially since a good chunk of these languages are all Algol-based in some sense. And the main "new" thing is different concepts like functional ways to write programs and various other ergonomic improvements. But really those things just make your code clearer.

https://en.wikipedia.org/wiki/Planck%27s_principle

bluGill3• 2 years ago

Learning a 2nd programming language isn't a big deal. Learning 2000 is a big deal. All projects should thus carefully limit what languages they allow so that people working in them don't have to learn too many. However you should also be learning new languages once in a while just for personal growth reasons.

If you write code in a memory unsafe language reading about Rust's borrow checker should be very interesting to you. You might conclude it isn't compelling on its own, but you should be very interested and at least thinking about how you can solve the problem in your current code (which might be adopting Rust, might be some other language, or might be change to your current language). If you don't admit that Rust solves a difficult problem I have no discussion for you - but you can say that the downsides to rust are not worth it.

uv-depression• 2 years ago

It really does seem like there's some old-guard who are utterly determined to now allow this to happen. That's not to say that Rust is inevitable in the kernel, but they're refusing to even allow the attempt. The amount of bad-faith argumentation happening is really discouraging about the state of Linux development.

In addition, the changes needed on the C side for RiL are needed anyways! Lifetimes aren't just a Rust thing, it just makes them forefront. You still need to keep track of them in C, and so they need to be documented since the language sure isn't going to help you. Refusing to document them isn't just harming Rust in Linux, it's harming the long-term viability of Linux in general. When the current maintainers quit, who's going to be able to untangle all that? Bug fixes still need to happen if they're only discovered because someone tried to formalize your interface!

fsckboy• 2 years ago

It really does seem like there's some old-guard who are utterly determined to now allow this to happen.

unices and then into the linux project have been a massively successful series of massive C library/API/threading/timing/bittwiddling coordination efforts.

some people now want to turn that Ship of Theseus into catamaran, while it's sailing? Rust people could probably more easily just use the Linux sources and rewrite it into a new better system, clean effort.

Coordinating people is time consuming and difficult, and this "project" clearly makes that issue a lot worse in the interim phases. Seems downright Bayesian, if you know what I mean.

bitexploder4• 2 years ago

Linux is like 27 million lines of code. The core is several million.

I think efforts like gVisor and other sandboxing technologies are the future. gVisor and friends like it can minimize the attack surface of unsafe code down to some minimum.

Rust in Linux as an experiment should go on. Core functionality can likely be re-implemented in Rust and continue to get some meaningful % of the critical path of code safer, but there will always be some level of "unsafe" code in an operating system kernel.

bluGill3• 2 years ago

Anybody can write a good kernel for one single computer (not just CPU) in a couple years. What makes linux useful is the vast amount of different hardware combinations it supports, often with "black magic" because some hardware doesn't work unless you do something weird (commonly you have to wait some amount of time after the power comes on before using it). One computer is easy, adding support for a second that is even slightly different is more work. Linux works correctly on millions of combinations by now (most of those combinations have not been tested but they would work)

znpy• 2 years ago

Indeed, I have a similar feeling.

"Rust people" are annoying because they largely want their stuff upstreamed, and they want it NOW. If you have any form of doubt they'll call you names and mark your word as nonsense. It's just obnoxious.

It's okay to want changes, and I think Rust in Linux is a great thing, but you can't expect people to just drop off everything and give you all the attention you want in the exact specific way you want it, and to give all that attention TODAY.

Otherwise just go ahead, fork Linux and do your thing... If it's any good Linux will pull and merge the changes.

jenadine• 2 years ago

Code is docs. One can just infer lifetime by reading the code.

(That said, having it encoded in the type system makes it many times easier)

p1necone• 2 years ago

One can just infer lifetime by reading the code.

For trivial cases sure, for complex ones though this is akin to saying "you can know if there's any bugs by reading the code" which we all know is not true for any reasonable time investment put into reading the code.

amluto• 2 years ago

Have you actually looked at Linux device model code? Or filesystem code? Or most other code? Most is poorly documented. Most is overcomplicated. Quite a bit is flat-out wrong.

jsheard• 2 years ago

Asahi Lina posted a thread about how difficult this actually is in practice:

https://threadreaderapp.com/thread/1829852697107055047.html

_dain_• 2 years ago

One can just infer lifetime by reading the code.

Enormously load-bearing "just" there. And if there's a subtle lifetime bug ... ?

saagarjha2• 2 years ago

One can just write correct code, of course.

bluGill3• 2 years ago

Sure you can, particularly in simple cases. However some code needs years to understand because something seemingly unrelated happening elsewhere changes things. The kernel often has to run on several different CPUs at the same time, and shouldn't sync the CPU caches if it is possible to avoid it.

Tyrannosaur• 2 years ago

Pretty sure I can get close to mapping that to solving the halting problem

generalizations2• 2 years ago

amount of bad-faith argumentation happening

From my position as an observer, Rust proponents need to deal with their own zealots before they can get annoyed with Linux kernel old-guard for being stubborn.

minkles12• 2 years ago

I think the nature of the problem is the other way around. This is not harming the long-term viability of Linux. It is harming the long-term viability of Rust. As a systems programming language, the promise of which was using it to write secure kernel and system code, not being accepted into a mainstream OS kernel on either technical or political merit is a death sentence.

Both perspectives need to be tested against each other, carefully.

0xcde4c3db• 2 years ago

The amount of bad-faith argumentation happening is really discouraging about the state of Linux development.

I don't think most of it is bad-faith argumentation so much as a failure to assume good faith. This is mostly conjecture on my part (I've only read a small percentage of the LKML and Mastodon threads about this stuff), but I think the idea is pretty straightforward:

Rust trains developers to think about lifetimes, locks, race conditions etc. in pretty specific ways, learn the language of borrow checker errors, and so on. People who haven't written a lot of both Rust and C simply won't have the particular mindset and skill set to look at any given "Rust problem" and understand how it could map to a shortcoming in the C code it's wrapping. So when a Rust developer is trying to wrap a C API and discovers an issue, I think the C-only developer taking the report/patch is primed to see not an indication of a legitimate bug, but rather an attempt to force C code to conform to Rust semantics, for the sake of simplifying the Rust developer's job. The Rust developer tries to explain, but this comes across as an irrelevant appeal to some obscure theoretical concern. At this point, further objections are obviously just the Rust developer being lazy, stubborn, doctrinaire, and otherwise not cut out for kernel development. Something like this probably only needs to happen a handful of times to mutate into a fairly durable meme of "Jesus fucking Christ, these Rust evangelists are exhausting. What the fuck is wrong with them?".

elpocko• 2 years ago

https://news.ycombinator.com/item?id=41386939

https://news.ycombinator.com/item?id=41387924

https://news.ycombinator.com/item?id=41423146

https://news.ycombinator.com/item?id=41424608

https://news.ycombinator.com/item?id=41431856

https://news.ycombinator.com/item?id=41438402

https://news.ycombinator.com/item?id=41443306

the_real_cher2• 2 years ago

I'm hearing word of Zig being an even better language than Rust.

minkles12• 2 years ago

I was considering writing a microkernel OS in Zig that transpiles to Rust and targets WebAssembly on a RISC-V CPU. That would be ultimate security. No one would be able to peel off all the layers!

the_real_cher2• 2 years ago

It's a shame that we don't have React components in the Linux kernel.

saagarjha2• 2 years ago

Not for the reasons the kernel needs.

jmull2• 2 years ago

I think we need to consider the perspective of the linux maintainers.

Learning and mastering a new language and applying it to an existing code base is quite a lot of work. That takes a lot of time away from other things they might be working on.

I think these are mostly (overwhelmingly?) volunteers, so you can't just assign them work. You need to convince them to want to do the work. Doing this shouldn't be dismissed as nontechnical nonsense... it's a very significant hurdle, and one that's directly on the critical path.

BTW, naming and shaming and internet pitchforks are guaranteed to make people not want to do the work, so unless you actually want to kill rust-in-linux, you might want to shut that down.

(Also, I wonder if there isn't a better way to bring memory-safety to the linux kernel. One that is just as effective as rust but less disruptive. The hostile us-vs-them dynamic building up around RiL might torpedo the whole thing, so it might be worth looking for effective alternatives.)

bryanlarsen• 2 years ago

Learning and mastering a new language and applying it to an existing code base is quite a lot of work. That takes a lot of time away from other things they might be working on.

Nobody is asking them to do that. They are being asked to review C patches to enable Rust-in-Linux.

I think these are mostly (overwhelmingly?) volunteers, so you can't just assign them work

The vast majority are professionals. A few work for the Linux Foundation, many work full time on Linux inside of big corps. For example, Ted T'so works for Google.

jorams• 2 years ago

Nobody is asking them to do that. They are being asked to review C patches to enable Rust-in-Linux.

My understanding of their issue is that this can't really be true. Any C code that affects Rust bindings in any way (which will be more and more as long as the integration grows) will become impossible to change without either knowing Rust or hoping/waiting for someone else to pick up that part.

jmull2• 2 years ago

The vast majority are professionals.

That’s good to know. But I guess the money is coming from a bunch of different companies/management structures, so you probably still can’t just tell everyone what to do.

Nobody is asking them to do that.

Perhaps not now, but I don’t think anyone thinks or claims the ambition for rust in linux is for rust to stay on the fringes and out of the way (otherwise, why even bother?). The more rust there is in the kernel, the more likely it is a linux dev will either need to master rust or make way for someone who will.

sazz• 2 years ago

For me, this discussion won't lead anywhere because it covers the wrong topic.

It's not about Rust or C - it's about transparency. The existing maintainers assume that it is not a priority for them whether they break something downstream or not. They therefore work in a space with interfaces that they can change as they see fit, without giving any guarantees as to their continued existence or wanting to subordinate themselves to a defined change process.

Rust is just a symptom of growing pains. Growth would be achieved if they could agree on common rules which would foster independent development linked by the interface contracts.

Instead, the issue is that established maintainers have grown fond of their zoo and are only pursuing their own priorities in a landlord-like manner. On the other hand, they see new technologies appearing and disappearing on the horizon and have consequently realized that a new technology or language cannot improve an existing system.

And yet they are classically talking past each other.

Rust in Linux lead retires rather than deal with more "nontechnical nonsense"

Related Stories