Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Maestro: A Linux-compatible kernel in Rust

blog.lenot.re

Post reply on HN
Print view View original

111–120 of 380 posts

Re: Maestro: A Linux-compatible kernel in Rust

#111

Post by zanellato19 »

meltyness wrote: post #50
jvanderbot wrote: post #48

Earlier quoted context omitted.

The culture around memory safe languages is a positive improvement for programmer zeitgeist. Man though the overreach all the way to "always safe forever" needs to be checked.

Just the other day they were full kum ba yah over a holiday-time-released feature that's likely going to greatly increase the likelihood of building race conditions and deadlocks. https://news.ycombinator.com/item?id=38721039

This is such a bizarre take on the stabilization of async that I can't even tell if you are being serious or just hate Rust.

Re: Maestro: A Linux-compatible kernel in Rust

#112

Post by flohofwoe »

sylware wrote: post #101
flohofwoe wrote: post #97

Earlier quoted context omitted.

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.

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.

Re: Maestro: A Linux-compatible kernel in Rust

#113

Post by zanellato19 »

insanitybit wrote: post #75
jvanderbot wrote: post #68

Earlier quoted context omitted.

This is getting a bit defensive. I think people are interpreting your post as saying all safety is guaranteed by using memory safety, but you rightly walk it back in comments to mean it addresses "primary" security problems. That's it.

It's just silly. I wrote an "imagine if we could trust the kernel as a boundary" and I get 100 posts about the same misconceptions. If people read into my post that I think a Rust kernel would solve all problems, perhaps I was overly simplistic with my language.

People here are overly nitpicky, your language was fine.

Re: Maestro: A Linux-compatible kernel in Rust

#117

Post by dabedee »

DaveFlater wrote: post #114

[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 more innovative than just writing a Linux-like kernel in C. After all, just use Linux at that point

- Use the safety of the Rust language to leverage some difficulty of kernel programming. Using Rust’s typing system allows to shift some responsibility over memory safety from the programmer to the compiler."

Unfortunately, your comment doesn't add anything to the conversation and distracts from the interesting project being presented.

Re: Maestro: A Linux-compatible kernel in Rust

#119

Post by Throw839 »

docandrew wrote: post #107
Throw839 wrote: post #83

Earlier quoted context omitted.

If I remember correctly, Ada was much slower compared to C. Stuff like boundary checks on arrays has a cost.

Runtime checks can be disabled in Ada. They’re useful for debug builds though!

But that elimites purpose for Ada. Rust has better type system to deal with this.

Re: Maestro: A Linux-compatible kernel in Rust

#120

Post by plagiarist »

snvzz wrote: post #105
insanitybit wrote: post #6

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…

I wish L4 had taken off for general purpose computing. That and Plan9 are things I'd really like to try out but I don't have space to fit operating systems in amongst the other projects. They both strike me as having the Unix nature, either "everything is messages in userspace processes" or "everything is a file."
Post reply on HN