|
|
|
|
|
|
by aeadio
652 days ago
|
|
|
> 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 article references) doesn't downplay the effort involved in developing a kernel. But you're definitely overplaying it. 30M SLOC in the Linux kernel is largely stuff like device drivers, autogenerated headers, etc. While the Linux kernel has a substantial featureset, those features comprise a fraction of that LOC count. Meanwhile, what Drew's suggesting is a kernel that aims for ABI compatibility. That's significantly less work than a full drop-in replacement, since it doesn't imply every feature is supported. Not to mention, some effort could probably be put into developing mechanisms to assist in porting Linux device drivers and features over to such a replacement kernel using a C interface boundary that lets them run the original unsafe code as a stopgap. [1] https://sr.ht/~sircmpwn/helios/ [2] https://harelang.org [3] https://drewdevault.com/2024/08/30/2024-08-30-Rust-in-Linux-... |
|
|
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