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

Asterinas: OS kernel written in Rust and providing Linux-compatible ABI

github.com

Post reply on HN
Print view View original

151–160 of 234 posts

Re: Asterinas: OS kernel written in Rust and providing Linux-compatible ABI

#151

Post by LinXitoW »

GoblinSlayer wrote: post #142
jeroenhd wrote: post #119

Earlier quoted context omitted.

Lifetime tracking and ownership are very difficult. That's why languages like C and C++ don't do it. It's also why those languages needs tons of extra validation steps and analysis tools to prevent bugs. Arc is nothing more than reference counting. C++ can do that too, and I'm sure there are C libraries for it. That's not an admission of anything, it's actually solving the problem rather than ignoring it and hoping i…

Looking at the code, it consists of long chains of get().unwrap().to_mut().unwrap().get() noise. Looks like coping with library design than ownership tacking. Also why Result >? Isn't Result already Option by itself? I guess that's why you need get().unwrap().to_mut() to get a value from Result > from an average function call?

If I ask my repository (backed by an sql db) to get a user, there might be 3 different scenarios I'm interested in:

- Technical problem (like connection problems) means I don't know what's in the db

- No technical problem, but no user entry

- No technical problem, and a user entry

You need the Result for the technical problems, and the Option for whether there's a user entry or not.

Re: Asterinas: OS kernel written in Rust and providing Linux-compatible ABI

#152

Post by tracker1 »

wg0 wrote: post #110
baq wrote: post #93

Earlier quoted context omitted.

If you’re writing C and don’t track ownership of values, you’re in a world of hurt. Rust makes you do from day one what you could do in C but unless you have years of experience you think it isn’t necessary.

Okay, I think it is is more like Typescript. You hate it but one day you just write small JS program and convert it to Typescript to discover that static analysis alone had so many code paths revealed that would have resulted in uncaught errors and then you always feel very uncomfortable writing plain Javascript. But what about tools like valgrind in context of C?

A few years ago I was worrying on a Byzantine mess of a JS project. I converted everything to TS for the sole reason of somewhat safely refactoring the project as a whole.

There was so little trust in the fragility of the original, it took a few months to convince everyone the refactored TS branch was safe.

After that, feature development was a lot faster in terms of productivity again.

Re: Asterinas: OS kernel written in Rust and providing Linux-compatible ABI

#153

Post by ulbu »

metalloid wrote: post #98
baq wrote: post #93

Earlier quoted context omitted.

If you’re writing C and don’t track ownership of values, you’re in a world of hurt. Rust makes you do from day one what you could do in C but unless you have years of experience you think it isn’t necessary.

It was true until LLMs arrive. Feature compilers + IDEs can be integrated with LLMs to help programmers. Rust was a great idea, before LLMs, but I don't see the motivation for Rust when LLMs can be the solution initial for C/C++ 'problems'.

Rust compiler checks things for you. People trust the Rust compiler because it enforces rules they want, so people don’t have to be in its place. Your suggestion is to be that checker to LLM-generated code. Back to square one.

Re: Asterinas: OS kernel written in Rust and providing Linux-compatible ABI

#154

Post by tracker1 »

lmm wrote: post #140
KingOfCoders wrote: post #88

Earlier quoted context omitted.

I always feel Arc is the admission that the borrow checker with different/overlapping lifetimes is too difficult, despite what many Rust developers - who liberally use Arc - claim.

If tracking lifetimes is simple 90% of the time and complex 10% of the time, maybe a tool that lets you have them automatically managed (with some runtime overhead) that 10% of the time is the right way forward.

Then you can use a language and runtime like C# or Java. Or you can use patterns like Go promotes.

There are lots of options if you want.

Re: Asterinas: OS kernel written in Rust and providing Linux-compatible ABI

#155

Post by not_a_dane »

GoblinSlayer wrote: post #126
jauntywundrkind wrote: post #33

Earlier quoted context omitted.

This was true a decade ago, with modern io_uring dpdk is probably an anti-pattern.

If you use io_uring, you're subject to vulnerabilities in kernel network stack which you have no control over.

that's rare.

Re: Asterinas: OS kernel written in Rust and providing Linux-compatible ABI

#156

Post by tracker1 »

ramon156 wrote: post #49
cies wrote: post #35

Earlier quoted context omitted.

Instead of asking "what other languages and project (open/closed, big/small, web/mobile/desktop, game/consumerapp/bizapp) have you experience with as to come to this conclusion?" people down vote you. So lemme ask: what other languages and project (open/closed, big/small, web/mobile/desktop, game/consumerapp/bizapp) have you experience with as to come to this conclusion?

I expect the downvotes to be there because it's talking positively about rust, which is blasphemy! /j

I'm guessing a lot of any perception of a lack of comments or documentation in a rust codebase comes down to how new or green a developer is to rust.

If you're just starting out or doing something relatively simple, your goal is to get something working. This is so true regardless of the language.

Re: Asterinas: OS kernel written in Rust and providing Linux-compatible ABI

#157

Post by thesuperbigfrog »

GoblinSlayer wrote: post #142
jeroenhd wrote: post #119

Earlier quoted context omitted.

Lifetime tracking and ownership are very difficult. That's why languages like C and C++ don't do it. It's also why those languages needs tons of extra validation steps and analysis tools to prevent bugs. Arc is nothing more than reference counting. C++ can do that too, and I'm sure there are C libraries for it. That's not an admission of anything, it's actually solving the problem rather than ignoring it and hoping i…

Looking at the code, it consists of long chains of get().unwrap().to_mut().unwrap().get() noise. Looks like coping with library design than ownership tacking. Also why Result >? Isn't Result already Option by itself? I guess that's why you need get().unwrap().to_mut() to get a value from Result > from an average function call?

>> Also why Result>? Isn't Result already Option by itself?

No. I've written code that returns Result>. It was a wrapper for a server's query web API.

The Result part determines whether the request succeeded and the response is valid.

The Option part is because the parameter being queried might not exist. For example, if I ask the API for the current state of the user session with a given Session ID, but that Session ID does not exist, then the Rust wrapper could return OK(None) meaning that the request succeeded, but that no such session was found.

Re: Asterinas: OS kernel written in Rust and providing Linux-compatible ABI

#158

Post by mcherm »

junon wrote: post #107
wg0 wrote: post #76

Earlier quoted context omitted.

Otherwise is a decent language but what makes it difficult is the borrow semantics and lifetimes. Lifetimes are more complicated to get your head around. But then there's this Arc, Ref, Pinning and what not - how deep is that rabbit hole?

Context: I'm writing a novel kernel in Rust. Lifetimes aren't bad, the learning curve is admittedly a bit high. Post-v1 rust significantly reduced the number of places you need them and a recent update allows you to elide them even more if memory serves. Arc isn't any different than other languages, not sure what you're referring to by ref but a reference is just a pointer with added semantic guarantees, and Pin isn'…

Would you not want to use Pin when sharing memory with a driver or extension written in a different language (eg: C)?

Re: Asterinas: OS kernel written in Rust and providing Linux-compatible ABI

#159

Post by gghh »

treeshateorcs wrote: post #20

https://www.youtube.com/watch?v=3AQ5lpXujGo Asterinas: A safe Rust-based OS kernel for TEE by H. Tian & C. Song (Ant Group & Intel) | OC3 2024

Exactly. I see elsewhere in this page people comparing this project to Linus Torvalds starting an OS in his dorm room while studying CS. Like these were "young and clueless" devs writing an OS for fun.

From the looks of it, this seems like a serious corporate backed project made by employees of the Ant Group, the chinese fintech giant. A more fair comparison would be with Google's Fuchsia OS (defunct) or Huawei's HarmonyOS. It may succeed, it may fail, but it's nothing like a couple of kids doing a passion project to learn Rust.

Re: Asterinas: OS kernel written in Rust and providing Linux-compatible ABI

#160

Post by surajrmal »

vbezhenar wrote: post #108
mdhb wrote: post #89

Earlier quoted context omitted.

Also this mysterious new Fuchsia OS from Google is also shooting for full Linux compatibility and is about to show up in Android, I think this is a much more realistic path of the next generation of operating systems that have a real chance to replace Linux but who knows what their actual plans are here at the moment but I don’t believe for a moment that that project is dead in any way.

I wonder if decision for stable syscalls was genius? Like imagine that Linux syscalls will become what C ABI is now. And there will be multiple compatible kernels, so you can choose any and run the same userspace.

Why would you want to support multiple? New versions should always be backwards compatible with older ones, so you'll always have the largest amount of compatibility by targeting the latest upstream. The real challenge comes with supporting applications that want features only available in forked kernels, which I guess could prompt wanting multiple kernels targeting the distinct ABIs.
Post reply on HN