4 ms·

> 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

by Y_Y 2y ago

> 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 obstacles rather than trying to overcome them directly. If there's significant resistance to Rust in the kernel, then regardless of the technical or other merits, it may just not be worth it to try and win over the objectors. https://redox-os.org/ https://redox-os.org/

chem83 2y ago
Maestro may be closer to what was suggested by the article. https://news.ycombinator.com/item?id=38852360 https://news.ycombinator.com/item?id=38852360
laymansterms 2y ago
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.
- deng 2y ago
  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 "Linux the OS", you need to get Rust into "Linux the kernel" proper. This approach can work, see for instance the history of PREEMPT-RT.
  - mustache_kimono 2y ago
    > It would be much, much slower for many workloads and only be interesting to Rust hackers. Why exactly?
    - deng 2y ago
      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.
      - mustache_kimono 2y ago
        > 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.
pornel 2y ago
To me Drew's article is a "bless your heart" answer that tells Rust users to go away, and keep themselves busy with something that nobody else will care about.

by Y_Y 2y ago

chem83 2y ago

Maestro may be closer to what was suggested by the article. https://news.ycombinator.com/item?id=38852360 https://news.ycombinator.com/item?id=38852360

laymansterms 2y ago

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.

deng 2y ago
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 "Linux the OS", you need to get Rust into "Linux the kernel" proper. This approach can work, see for instance the history of PREEMPT-RT.
- mustache_kimono 2y ago
  > It would be much, much slower for many workloads and only be interesting to Rust hackers. Why exactly?
  - deng 2y ago
    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.
    - mustache_kimono 2y ago
      > 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.

pornel 2y ago

To me Drew's article is a "bless your heart" answer that tells Rust users to go away, and keep themselves busy with something that nobody else will care about.