101–110 of 380 posts
Earlier quoted context omitted.
>We must have a GPU hardware programming "standard" first. Isn't that what WebGPU has become?
The WebGPU API is very far removed from the hardware. It's the common subset of Vulkan, D3D12 and Metal, each of those APIs also being fairly high level abstractions over different GPU architectures.
This sounds more than great. Unrelated but at same time related, feel your self absolutelly free to ignore this message, Linux needs a HISP with firewall. I comment it here because this need to be supported by a/the kernel, its needed to limit the functions that allow process injections, and also a way for to canalize all the process executions in a supervised mode. As an [put operative system name here] user, I need…
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…
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.
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…
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 timing as well as mixed criticality support. No other system can currently make such claims.
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.
It seems highly irrelevant what you or I need. The author explicitly made the project as a learning experience, not for others. The "Why" is described in the opening paragraph, and makes the goal very clear.
And it seems like the author was highly successful, so congratulations author! Great to see people diving headfirst into very complicated parts of the stack.
Earlier quoted context omitted.
> 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 If you don't run docker as root, it's fairly ok for normal software. Kernel memory safety is not the main issue with container escapes. Even with memory safety, you can have logical bugs that result in privilege escalation scenar…
If I remember correctly, Ada was much slower compared to C. Stuff like boundary checks on arrays has a cost.
Compatible means "syscall compatible" (I get that from the article). I wonder if it also means kernel module compatible (I dont think so, as the API touch point surface is much larger), but if it strives to be that'd be great (use all hardware that works on Linux).
Not even Linux itself is kernel module compatible from version to version, so it would be exceedingly difficult to try to be compatible with it.
On one end device drivers in Rust are now possible, OTOH the Meastro kernel. I wonder if there come be a day in my life that I run a non-C-kernel in prod/ on dev laptop.
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.
> Personally, I find yet another monolithic kernel unix clone is not what we need It seems highly irrelevant what you or I need. The author explicitly made the project as a learning experience, not for others. The "Why" is described in the opening paragraph, and makes the goal very clear. And it seems like the author was highly successful, so congratulations author! Great to see people diving headfirst into very comp…
There is no need to twist my words into sounding negative.
As already explained in the parent, congratulations to them for getting it done, and I believe it does provide value through testing one thing (Rust) while sticking to the very mature and well understood UNIX design.
Earlier quoted context omitted.
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…
What you are proposing is so terrible in practice that people have invented hundreds of programming languages to escape it. Millions of person-hours have been spent on getting away from what you say is desirable.
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).