(no title)
woodPurchase | 1 year ago
>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 those changes may break the Rust bindings – and he doesn't want the responsibility of fixing them if that happens.
>"If it isn't obvious, the gentleman yelling in the mic that I won't force them to learn Rust is Ted Ts'o. But there are others. This is just one example that is recorded and readily available."
A lot of the quotes, this in particular, really comes off as petty. Not wanting a maintenance burden on your hands is a perfectly sane response from Ts'o
>But the rules put in place to guide open source communities tend not to constrain behavior as comprehensively as legal requirements. The result is often dissatisfaction when codes of conduct or other project policies deliver less definitive or explainable results than corporate HR intervention or adversarial litigation.
>Citing the Linux kernel community's reputation for undiplomatic behavior, The Reg asked whether kernel maintainers need to learn how to play well with others.
Lol. You need to set firm rules. No, not like that! You need to play nice with others! Upper-management telling you off is bad only when The Register says so
>As an alternative, [Drew DeVault] has proposed starting anew, without trying to wedge Rust into legacy C code. He wrote that "a motivated group of talented Rust OS developers could build a Linux-compatible kernel, from scratch, very quickly, with no need to engage in LKML [Linux kernel mailing list] politics. You would be astonished by how quickly you can make meaningful gains in this kind of environment; 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."
Ah, yes. Drew DeVault. The expert in A) non-divisive/petty community politics, and B) 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?!
aeadio|1 year ago
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-...
mustache_kimono|1 year ago
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
renox|1 year ago
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..