The Register: Rust for Linux maintainer steps down • Hacker News Board

Re: The Register: Rust for Linux maintainer steps down

#21

Post by wolro » Tue, Sep 03, 2024, 8:45 PM UTC

jrpelkonen wrote: post #10

vfclists wrote: post #5

So many comments think that Filho's complaints are about the kernel developers rejection of Rust, but in the video referenced he is asking the kernel developers to explain what the changes are, the semantics not the actual code. There is a real problem if kernel developers cannot take the time to explain the semantics. Trying to explain something to others is how you can be sure you understand it yourself. If the dev…

I wonder how much of it is unwillingness to explain rather than the inability to do so? The vibe I got was that the audience was not interested in changing their ways, after all they've been doing things their way for decades with great success. I have to also credit the presenters, they stayed on the topic and pretty calm despite the heckling. If that presentation encapsulates the state of things, the Rust for Linux…

Exactly. And as far as I understood the talk, nobody even asked the audience to change their ways.

Now, as mentioned by the presenter himself, refactors that change the API semantics will break any consuming code, no matter if written in Rust or C.

So, one option is that the whole issue around breaking Rust bindings is just a strawman and the vocal part of the audience just wants Rust devs to gtfo.

In the other, more charitable setting I can conceive, we are looking at an API that isn't extensively documented in the first place (obviously, otherwhise the Rust for Linux team wouldn't have to ask for clarification) and a small group of kernel devs who are trying to fix everything by themselves rather than documenting changes in a way that so other people can fix their own API-consuming code.

In this setting, also fresh would-be contributors using C will have a hard time getting to grips with the codebase. Now, if I remember correctly, one of the purported reasons for Linux to open up to Rust was to attract fresh developers, but in the outlined scenario, there is a clear reason why people might bounce off, and it is unrelated to the language (at least if this case is representative for other parts of the kernel codebase).

None of the options look good to me. But perhaps I am just missing something.

Re: The Register: Rust for Linux maintainer steps down

#22

Post by mustache_kimono » Tue, Sep 03, 2024, 8:59 PM UTC

aeadio wrote: post #19

woodPurchase wrote: post #7

>That remark is a response to a comment on the video that, according to Filho, came from Linux kernel maintainer Ted Ts'o: "Here's the thing, you're not going to force all of us to learn Rust." >The video depicts resistance to Filho's request to get information to statically encode file system interface semantics in Rust bindings, as a way to reduce errors. Ts'o's objection is that C code will continue to evolve, and…

> Ah, yes. Drew DeVault. The expert in ... developing 30M LOC OS kernels with billions of dollars on R&D investment in a few years with a small team in an experimental language. "Just make Linux 2", it's so simple, why didn't we think of this?! This is an unusual take considering Drew DeVault actually does have experience developing new kernels [1] in experimental languages [2]. Drew's own post [3] (which the linked…

> This is an unusual take considering Drew DeVault actually does have experience developing new kernels in experimental languages.

Not exactly, a new toy kernel is different than reimplementing Linux!

> Meanwhile, what Drew's suggesting is a kernel that aims for ABI compatibility.

Drew and you are missing the point, which is: we don't want to wait years to use a new OS that may or may not come. "Hey, go fork it!" is a fine response to plenty of feature requests, but not this one. The point here explicitly was that in-tree support is/was better, so everyone got watch the development of the thing.[0]

Moreover the actual problem is bad behavior by C kernel devs, to which a leader would say: "This is something we are doing. This project can fail for lots of reasons but it won't fail because kernel C devs are too toxic to work with. You'll apologize to Wedson. You said -- you're not learning Rust. Guess what? Your contributions are paused, while you learn Rust, and assist in building the ext2 reimplementation. Perhaps, as you do, you can make clearer your concerns to the Rust for Linux team, and learn what theirs are as well."

[0]: https://lkml.org/lkml/2020/7/10/1261

Re: The Register: Rust for Linux maintainer steps down

#23

Post by renox » Tue, Sep 03, 2024, 9:09 PM UTC

aeadio wrote: post #19

woodPurchase wrote: post #7

>That remark is a response to a comment on the video that, according to Filho, came from Linux kernel maintainer Ted Ts'o: "Here's the thing, you're not going to force all of us to learn Rust." >The video depicts resistance to Filho's request to get information to statically encode file system interface semantics in Rust bindings, as a way to reduce errors. Ts'o's objection is that C code will continue to evolve, and…

> Ah, yes. Drew DeVault. The expert in ... developing 30M LOC OS kernels with billions of dollars on R&D investment in a few years with a small team in an experimental language. "Just make Linux 2", it's so simple, why didn't we think of this?! This is an unusual take considering Drew DeVault actually does have experience developing new kernels [1] in experimental languages [2]. Drew's own post [3] (which the linked…

> 30M SLOC in the Linux kernel is largely stuff like device drivers, autogenerated headers, etc.

And? These drivers matter otherwise you have Haiku, Redox, etc OSs that seems promised to an "eternal" beta status because they have to reimplement these drivers..

Re: The Register: Rust for Linux maintainer steps down

#24

Post by chem83 » Wed, Sep 04, 2024, 7:22 AM UTC

Y_Y wrote: post #3

> I think if the amount of effort being put into Rust-for-Linux were applied to a new Linux-compatible OS we could have something production-ready for some use cases within a few years. I presume @ddevault knows about Redox, so I'm surprised he didn't mention it in this context. In any case I thought it was an insightful remark. The more I learn about the politics of big projects, the more I believe in flowing around…

Maestro may be closer to what was suggested by the article.

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

Re: The Register: Rust for Linux maintainer steps down

#25

Post by Pet_Ant » Wed, Sep 04, 2024, 8:39 PM UTC

How many patches come into Linux a day? How hard would it be to do parallel development for a while? Just apply the fixes as you slowly evolve your codebase. Not a hard right, but more of a gentle peel away.

Re: The Register: Rust for Linux maintainer steps down

#26

Post by mustache_kimono » Fri, Sep 06, 2024, 3:59 AM UTC

deng wrote: post #9

laymansterms wrote: post #8

Earlier quoted context omitted.

He actually did mention it if you look at the blog post his quote comes from. He's specifically calling for a Linux-ABI-compatible rust kernel that just re-implements things as they were rather than trying to delve into new researchy OS concepts like what Redox does.

Writing a Linux-ABI-compatible kernel in Rust will lead to a kernel no one uses. What would be the advantage of such a kernel? It would be much, much slower for many workloads and only be interesting to Rust hackers. In "Linux the OS", we are stuck with the "Linux the kernel", and Drew knows this very well. You will never catch up with the years of development that went into it. So if you want Rust in the kernel of "…

> It would be much, much slower for many workloads and only be interesting to Rust hackers.

Why exactly?

Re: The Register: Rust for Linux maintainer steps down

#27

Post by deng » Sat, Sep 07, 2024, 6:45 AM UTC

mustache_kimono wrote: post #26

deng wrote: post #9

Earlier quoted context omitted.

Writing a Linux-ABI-compatible kernel in Rust will lead to a kernel no one uses. What would be the advantage of such a kernel? It would be much, much slower for many workloads and only be interesting to Rust hackers. In "Linux the OS", we are stuck with the "Linux the kernel", and Drew knows this very well. You will never catch up with the years of development that went into it. So if you want Rust in the kernel of "…

> It would be much, much slower for many workloads and only be interesting to Rust hackers. Why exactly?

Because if you write a kernel from scratch, things like the scheduler or the networking stack will be much, much less performant than the one from the Linux kernel. As I've written: you'll never catch up with the years and years of development that have poured into these systems.

Now, you could take these stacks from the Linux kernel and rewrite them in Rust, but that's not what Drew has suggested. Besides, that would also take ages: it's a lot of very complicated code, and a lot of it cannot just be transferred to Rust without it becoming unsafe, making the whole point of having a kernel in Rust moot.

Re: The Register: Rust for Linux maintainer steps down

#28

Post by mustache_kimono » Sat, Sep 07, 2024, 8:15 PM UTC

deng wrote: post #27

mustache_kimono wrote: post #26

Earlier quoted context omitted.

> It would be much, much slower for many workloads and only be interesting to Rust hackers. Why exactly?

Because if you write a kernel from scratch, things like the scheduler or the networking stack will be much, much less performant than the one from the Linux kernel. As I've written: you'll never catch up with the years and years of development that have poured into these systems. Now, you could take these stacks from the Linux kernel and rewrite them in Rust, but that's not what Drew has suggested. Besides, that woul…

> Because if you write a kernel from scratch, things like the scheduler or the networking stack will be much, much less performant than the one from the Linux kernel.

Yeah, I don't think you know this.

As I understand it, there have been schedulers written in Rust for Linux already which are faster in specific use cases.

> Now, you could take these stacks from the Linux kernel and rewrite them in Rust, but that's not what Drew has suggested.

As I understand it, Drew that's exactly what he suggested? He didn't say go write a new system. He said go write an ABI compatible system. It's hard for me to imagine he meant "Write an ABI compatible system with wildly different semantics."

> Besides, that would also take ages:

Agreed, and that's what makes his suggestion mostly ridiculous.

> it's a lot of very complicated code, and a lot of it cannot just be transferred to Rust without it becoming unsafe, making the whole point of having a kernel in Rust moot.

I think this passage confuses a few key concepts. First, I'm not really certain how much unsafe a scheduler or a networking stack would have to use. My guess is not that much. Do you have some reason to believe it would have to use an inordinate amount of unsafe? Next, simply using unsafe does not moot the safety argument for using Rust. I've said this about a billion times, but once more: unsafe constrains memory safety to a small enough area that one can reason about it.