A motivated group of Rust developers could build a production ready mostly Linux-compatible kernel from scratch within 5 years without doing any politics on LKML
-
🐧 Jonathan Treffler 🇺🇦🇵🇸replied to 🐧 Jonathan Treffler 🇺🇦🇵🇸 last edited by
Somebody re-implementing ZFS in Rust, which works with existing filesystems and can be read from regular ZFS afterwards ?
All the power to the person that tries to create that, but I am not holding my breath for that to every succeed.The compatibility breaking alternative would be to create a new filesystem with ZFS like capabilities and reliability (!!!) and I just don't see that ever happening.
(2/2)
-
Drew DeVaultreplied to 🐧 Jonathan Treffler 🇺🇦🇵🇸 last edited by
@JonathanTreffler sure, but there are tons of use-cases which don't call for ZFS. Something like ext4 would cover a ton of use-cases and be achievable much more quickly. And with a solid footing it's a great place to start experimenting with more complex or novel filesystems.
-
@martijnbraam @drewdevault Even if 10x or 100x, really irrelevant. The reason to use Rust is memory safety at runtime, not compilation time
-
@raulinbonn @martijnbraam compile time does matter actually
-
:PUA: Shlee fucked around andreplied to Drew DeVault last edited by
@drewdevault You absolutely love to see it.
Rustux is the real tux.
-
@drewdevault especially for something niche starting with basic platform drivers, nvme (or alternative like ahci), and basic framebuffer (uefi based?) support, should be plenty for a lot of interesting projects, and provided it is architectured correctly a pretty good base for further expansion
-
@deetwenty exactly. 100%
If you get a decent filesystem and a few network drivers (even virtio) and good POSIX support you're in the datacenter too
-
@drewdevault if you're only targeting hardware commonly exposed in virtual machines, perhaps. But the real world usage needs real drivers for real hardware and they will be chasing this for years and years
-
@feld not really. I re-iterate my request for everyone to shut up about drivers already
-
@tragicomedy @martijnbraam @drewdevault
Which small program are we talking about?
I found plenty of projects being quicker to build (and rebuild) in rust compared to equivalents.
But the mileage obviously does vary a lot
-
@lu_zero @martijnbraam @drewdevault "like yazi"
-
@tragicomedy @martijnbraam @drewdevault
I looked at the current yazi main branch.
27288 loc in 463 files isn't exactly small.
Yet it builds here in 2 minutes:
Finished `release` profile [optimized] target(s) in 2m 13s
Most of it spent on link time at the very end.
-
@lu_zero @tragicomedy @martijnbraam on what hardware?
-
@lu_zero @martijnbraam @drewdevault 2 minutes? Do you have supercomputer?
-
@tragicomedy @martijnbraam @drewdevault
a last-year laptop.
-
@lu_zero @tragicomedy @martijnbraam one of the most powerful laptops released last year*
-
Boyd Stephen Smith Jr.replied to Drew DeVault last edited by
@drewdevault I hope this is true. I feel like being compatible with userland is "easy" (tho, sysfs and iocntl and fnctl are never truly easy) but actually porting / wrapping all the hacky kernel driver modules could easily swallow person-years of time.
I hope this is true because eventually Linus and/or the Linux foundation is going to fail in some way, so we need to be able to transition to new leadership or consensus building.
-
Drew DeVaultreplied to Boyd Stephen Smith Jr. last edited by
@BoydStephenSmithJr I don't think compatibility with out of tree Linux kernel modules (or even in-tree) is a reasonable goal.
-
Case-study: Tilck
GitHub - vvaltchev/tilck: A Tiny Linux-Compatible Kernel
A Tiny Linux-Compatible Kernel. Contribute to vvaltchev/tilck development by creating an account on GitHub.
GitHub (github.com)
Written by one person mostly over the course of about three years in their spare time and it's ABI compatible enough with Linux to run busybox, vim, tcc, lua, micropython, fbdoom -- from unmodified Linux binaries, not source ports
-
Drew DeVaultreplied to Drew DeVault last edited by [email protected]
Another one: Managarm
GitHub - managarm/managarm: Pragmatic microkernel-based OS with fully asynchronous I/O
Pragmatic microkernel-based OS with fully asynchronous I/O - managarm/managarm
GitHub (github.com)
Does not aim for ABI compatibility with Linux but has implemented a lot of Linux-specific APIs to great success, including DRM (Direct Rendering Manager), epoll, signalfd, etc, and is capable of running software like Sway
Small group of 4-5 principal contributors working slowly but surely since 2016