131–140 of 380 posts
Earlier quoted context omitted.
That's pure FUD.
Disillusionment. I paid my dues with virtiofsd et al. I'm glad the dev is having fun and learning, I just hope it doesn't escalate into an OS schism.
[flagged]
Given his explanation, it seems he switched to writing in Rust largely because it allowed this project to do double duty allowing him to learn Rust while learning to develop an OS. That is an entirely reasonable thing to do. The thing with Linux compatibility isn't explained, but most likely because it makes the process much simpler if you can run at least some existing software as-is and not have to write an entire userspace yourself to be able to actually do anything with your toy kernel. Wholesale new OS projects ultimately intended for real-world use by people other than the developer don't seem to be taking that approach.
[flagged]
If you spend time reading the article, you can agree or disagree with his choices, but he provides several reasons for why he chose to rewrite in Rust over after the initial project was written in C: "At that moment, I decided to switch to Rust (my first project in this language), which represented several advantages: - Restart the project from the beginning, using lessons learned from previous mistakes - Be a bit mo…
I applaud them for getting things done vs just talking about it. Personally, I find yet another monolithic kernel unix clone is not what we need, but the point here is that it's made in Rust, which itself is an experiment; It is best to not do too many experiments at once, thus cannot complain.
Earlier quoted context omitted.
You can get your assembly-written kernel right now for every OS out there: just compile Linux using a RISC-V backend of your favourite compiler.
This is severely wrong: you cannot compare hand written and properly commented assembly with compiler generated one.
Earlier quoted context omitted.
What do you mean a risc-v kernel? One written in RISC v assembly? Because that would be terrible. Risc-v is the instruction set architecture, rust is a programming language. You can port languages to target ISAs. Linux can already run in riscv. The ISA of the hardware and the language the software it runs are completely different issues.
Well, I think you are wrong, and that would actually be the real way forward: an assembly written kernel using a worldwide standard ISA, aka RISC-V. Of course, it would have not to abuse any preprocessor, because moving the issue which is the complexity of the compiler dependency to a preprocessor complexity dependency would nullify everything. Doing that in rust, is just doing the mistake of linux all over again, ac…
....or do you think that because RISC-V is "standard", assembly for RISC-V would run on any hardware?
A memory safe linux kernel would be a fairly incredible thing. If you could snap your fingers and have it, the wins would be huge. Consider that right now a docker container can't be relied upon to contain arbitrary malware, exactly because the Linux kernel has so many security issues and they're exposed to containers. The reason why a VM like Firecracker is so much safer is that it removes the kernel as the primary…
If you find this amazing, perhaps you should take a look at seL4, which has formal proofs of correctness, going all the way down to the generated assembly code still satisfying the requirements. It also has a much better overall architecture, the best currently available: A third generation microkernel multiserver system. It provides a protected (with proof of isolation) RTOS with hard realtime, proof of worst case t…
Earlier quoted context omitted.
You are right in a legacy context where the mess of ISAs required an abstraction of the assembly language. But where you are wrong is, moving forward in a world with a modern worldwide standard ISA (RISC-V) is actually writing a kernel in assembly (without abusing any preprocessing).
People have had the ability to do that for decades, and they have almost always chosen not to when they had the option, because it's terrible. RISC-V is nothing revolutionary on that front, and doesn't magically make it better. Without preprocessing you won't have variable names or jump label names or strings, which is even more terrible. Please give us some actual evidence, instead of just saying "you're wrong", bec…
My opinion is this is wrong, and I did voice my disagrement and gave my own view on the matter. If there is something extreme here is the karma slash upon displeasing the pro rust people and AI bots on HN.
Earlier quoted context omitted.
I don't know about webGPU, but it seems you missed the word "hardware" in "hardware programming interface", like NVMe is for non volatile memory device.
I was replying to the "Isn't that what WebGPU has become?". The WebGPU programming model is already too high level for a "hardware programming interface". WebGPU is designed to sit on top of other 3D APIs, which in turn sit on GPU vendor drivers, and most of the complexity and 'hidden magic' is in those drivers.
A memory safe linux kernel would be a fairly incredible thing. If you could snap your fingers and have it, the wins would be huge. Consider that right now a docker container can't be relied upon to contain arbitrary malware, exactly because the Linux kernel has so many security issues and they're exposed to containers. The reason why a VM like Firecracker is so much safer is that it removes the kernel as the primary…
"gVisor is an application kernel for containers. It limits the host kernel surface accessible to the application while still giving the application access to all the features it expects. Unlike most kernels, gVisor does not assume or require a fixed set of physical resources; instead, it leverages existing host kernel functionality and runs as a normal process. In other words, gVisor implements Linux by way of Linux."