Alcun Atirutan BBS

Google announces #KataOS: #Rust userland on top of #seL4:
https://opensource.googleblog.com/2022/10/announcing-kataos-and-sparrow.html

It seems to be special-purpose, but there’s a technical vision here that makes more sense to me than the “Rust in Linux” meme. “Rust in Linux” is more of a distraction than anything else.

@bjc To me, the cost/benefit ratio of Rust-in-Linux is very bad: jeopardizing bootstrappability¹ and auditability to get memory safety for a tiny fraction of a huge monolithic kernel. This benefits Rust more than Linux.

I remain convinced that object-capability, μ-kernel-based designs have way more to offer in terms of fault tolerance, security, and user freedom.

¹ https://bootstrappable.org

@civodul @bjc I don't understand the bootstrap argument. The rust parts are afaik only used for some device drivers (and this is planned to stay that way for the forseeable future, isn't it?)

You can just built a kernel without those modules enabled for bootstrapping and rebuild, if you happend to actually need any of those later after you have a rust toolchain available.

Or am I misunderstanding your concern here?

@Bubu @bjc The problem is that Rust doesn’t have a good bootstrapping story, where “bootstrapping” means the ability to build it entirely from source.

Guix is I think the only distro that builds it from source so far, but it’s quite an effort, and one upstream isn’t helping with: https://guix.gnu.org/en/blog/2018/bootstrapping-rust/

@bjc @Bubu I don’t know of any official statement, but IIRC the Rust web site recommends building rustc from the previous version of itself, which it provides as a pre-built binary. That’s yogurt.

@civodul @Bubu @bjc Does the Rust front-end having been merged into GCC resolve this concern, or are there other issues? https://gcc.gnu.org/pipermail/gcc/2022-July/239057.html

@LiberalArtist @bjc @Bubu With GCC, the bootstrap chain can potentially be resolved, and it’s a solution that works on more architectures than with mrustc.

That whole bootstrap chain remains a hack though. What would be more sustainable is a solution à la “debootstrap without archeology”:
https://10years.guix.gnu.org/video/camlboot-debootstrapping-the-ocaml-compiler/

@civodul @Bubu @bjc I of course think bootstrapping is quite important, but I am also sympathetic to the difficulties it can pose for language implementers. From a perspective of trust and security, ultimately I want *both* bootstrappability and safer programming languages. In the mean time, I appreciate people working on both parts of the problem.

@civodul hello Ludovic. To be honest, reading your comments giving me a hunch that either Fuchsia or Golang will eventually be https://killedbygoogle.com.

@civodul I want to say thank you for sharing this website. Now I understand what do you mean with bootstrapping.

PS: I don't know programming.

@bjc