501–510 of 853 posts
Rust in the kernel feels like a red herring. For fault tolerance and security, wouldn’t it be a superior solution to migrate Linux to a microkernel architecture? That way, drivers and various other components could be isolated in sandboxes.
Earlier quoted context omitted.
One perspective is that Rust appears to be forced into the Linux kernel through harassment and pressure. Instead of Rust being pulled, carefully, organically and friendly, and while taking good care of any significant objections. Objections like, getting the relevant features from unstable Rust into stable Rust, or getting a second compiler like gccrs (Linux kernel uses gcc for C) fully up and running, or ensuring th…
Personally, I observe that Rust is forced everywhere in the Linux ecosystem. One of my biggest concerns is uutils, mostly because of the permissive license it bears. The Linux kernel and immediate userspace shall be GPL licensed to protect the OS in my opinion. I have a personal principle of not using LLVM-based languages (equal parts I don't like how LLVM people behave against GCC and I support free software first a…
Earlier quoted context omitted.
Which ones would that be?
In order to figure this out I took the list of platforms supported by Rust from https://doc.rust-lang.org/nightly/rustc/platform-support.htm... and those supported by Linux from https://docs.kernel.org/arch/index.html , cleaned them up so they can be compared like for like and then put them into this python script: linux = { "alpha", "arc", "arm", "aarch64", "csky", "hexagon", "loongarch", "m68k", "microblaze", "mips…
Earlier quoted context omitted.
Some pretext: I'm a Rust skeptic and tired of Rust Evangelism Task Force and Rewrite in Rust movements. --- Yes. I remember that message. Also let's not forget what marcan said [0] [1]. In short, a developer didn't want their C codebase littered with Rust code, which I can understand, then the Rust team said that they can maintain that part, not complicating his life further (Kudos to them), and the developer lashing…
One perspective is that Rust appears to be forced into the Linux kernel through harassment and pressure. Instead of Rust being pulled, carefully, organically and friendly, and while taking good care of any significant objections. Objections like, getting the relevant features from unstable Rust into stable Rust, or getting a second compiler like gccrs (Linux kernel uses gcc for C) fully up and running, or ensuring th…
Rust should have done exactly one thing and do that as good as possible: be a C replacement and do that while sticking as close as possible to the C syntax. Now we have something that is a halfway house between C, C++, JavaScript (Node.js, actually), Java and possibly even Ruby with a syntax that makes perl look good and with a bunch of instability thrown in for good measure.
It's as if the Jehova's witnesses decided to get into tech and to convince the world of the error of its ways.
Earlier quoted context omitted.
So does this mean that the C developers might need to learn Rust or cooperate more with the rust developer team basically?
Depends on the change being made. If they completely replace an API then sure, probably. But for most changes, like adding a param to a function or a struct, they basically have to learn nothing. Rust isn't unlike C either. You can write a lot of it in a pretty C like fashion.
I think that with all of the Rust's borrowing rules the statement is very iffy.
Earlier quoted context omitted.
So does this mean that the C developers might need to learn Rust or cooperate more with the rust developer team basically?
I guess in practice you'd want to have Rust installed as part of your local build and test environment. But I don't think you have to learn Rust any more (or any less) than you have to learn Perl or how the config script works. As long as you can detect if/when you break it, you can then either quickly pick up enough to get by (if it's trivial), or you ask around.
Completely tangential but it would be nice if could 'natively' run wasm.
Earlier quoted context omitted.
No maintainer is obligated to not break any part of Linux other than the user space API, there are no stable in-kernel APIs
There is, I understand, an expectation that if you do make breaking changes to kernel APIs, you fix the callers of such APIs. Which has been a point of contention, that if a maintainer doesn't know Rust, how would they fix Rust users of an API? The Rust for Linux folks have offered that they would fix up such changes, at least during the experimental period. I guess what this arrangement looks like long term will be…
Earlier quoted context omitted.
In order to figure this out I took the list of platforms supported by Rust from https://doc.rust-lang.org/nightly/rustc/platform-support.htm... and those supported by Linux from https://docs.kernel.org/arch/index.html , cleaned them up so they can be compared like for like and then put them into this python script: linux = { "alpha", "arc", "arm", "aarch64", "csky", "hexagon", "loongarch", "m68k", "microblaze", "mips…
It’s an interesting list from the perspective of what kind of project Linux is. Things like PA-RISC and Alpha were dead even in the 90s (thanks to the successful Itanium marketing push convincing executives not to invest in their own architectures), and SuperH was only relevant in the 90s due to the Dreamcast pushing volume. That creates an interesting dynamic where Linux as a hobbyist OS has people who want to suppo…