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?

Rust code is usually well commented in my experience.

Couldn't you just boot the Linux kernel directly and launch a generic app as pid 1 instead of a full blown init system with a bunch of daemons?

That's basically what you're getting with Docker containers and a shared kernel. AWS Lambda is doing something similar with dedicated kernels with Firecracker VMs

If you want truly high-performance networking, you can bypass the kernel altogether with DPDK. So you don't have to worry about alternative kernels for other tasks at all. On the downside, DPDK takes over the NIC entirely, removing the kernel from the equation, so if you need the kernel to see network traffic for some reason, it won't work for you.

You can check out hardware support here: https://core.dpdk.org/supported/nics/

i might be wrong but if it's ABI compatible the same drivers will work?

p.s.: i was wrong

>While we prioritize compatibility, it is important to note that Asterinas does not, nor will it in the future, support the loading of Linux kernel modules.

https://asterinas.github.io/book/kernel/linux-compatibility....

Why don’t you just use a SmartNIC and P4? It won’t get faster than running on the NIC itself

I love Redox as a project because while it still has a massive ways to go, it's the closest to being a new OS/Kernel that has the potential to make it to a viable daily driver. Windows/MacOS/Unix/Linux are all incredibly old by software standards and Redox is bringing some cool design decisions.

This is fascinating! Couldn't really find the kernel code but would love to know more about the applicability. I'm curious since seeing the Unikraft release that promised millisecond container boot times

Redox has a proper architecture, aka microkernel multiserver.

Thus it is a much more interesting project.

> I think this looks incredible. Like how does one create a compatible abi _for all of linux_??? Wow!

FWIW that’s what the Linux compatibility layer in the BSDs does and also what WSL 1 did (https://jmmv.dev/2020/11/wsl-lost-potential.html).

It’s hard to get _everything_ perfectly right but not that difficult to get most of it working.

Idk. Asahi Linux GPU driver breaks all "common sense" of "how fast a reliable usable feature rich driver" was produced by a small 3rd party team.

The company I work for has both rust and python projects (through partially pre "reasonable python type linting" using mypy and co.) and the general consensus there is "overall" rust is noticeable more productive (and stable in usage/reliable), especially if you have code which changes a lot.

A company I worked previous for had used rust in the very early days (around 1.0 days) and had one of this "let's throw up a huge prototype code base in a matter of days and then rewrite it later" (basically 90% of code had huge tech dept). But that code base stuck around way longer then intended, caused way less issues then expected. I had to maintain it a bit and in my experience with similar code in Python and Js (and a bit Jave) I expected it to be very painful but surprisingly it wasn't, like at all.

Similar comparing my experience massive time wastes due to having to debug soundness/UB issues in Rust, with experiences in C/C++ it's again way more productive.

So as long as you don't do bad stuff like over obsessing with the type system everything in my experience tells me using Rust is more productive (for many tasks, definitely not all task, there are some really grate frameworks doing a ton of work for you in some languages against which the rust ecosystem atm. can't compete).

---

> Most productive language for a developer is the one they understand what is happening one layer below the level of abstraction they are working with.

I strongly disagree, the most productive language is the one where the developer doesn't have to care much about what happens in a layer below in most cases. At least as long as you don't want obsess over micro optimizations not being worth the time and opportunity cost they come with for most companies/use cases.

> Like how does one create a compatible abi _for all of linux_???

You look at Linux's syscall table[0], read through the documentation to figure out the arguments, data types, flags, return values, etc., and then implement that in your kernel. The Linux ABI is just its "library" interface to userspace.

It's probably not that difficult; writing the rest of the kernel itself is more challenging, and, frankly, more interesting. Certainly matching behavior and semantics can be tricky sometimes, I'm sure. And I wouldn't be surprised if the initial implementation of some things (like io_uring, for example, if it's even supported yet) might be primitive and poorly optimized, or might even use other syscalls to do their work.

But it's doable. While Linux's internal ABI is unstable, the syscall interface is sacred. One of Torvalds' golden rules is you don't break userspace.

[0] https://filippo.io/linux-syscall-table/

Everyone says what they are used to is better or more productive. Even in assembly vs ruby, some stuff are much easier in assembly and maybe impossible in ruby afaik

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.

And I'll mention another one that a friend of mine is working on: uxrt

https://gitlab.com/uxrt

I think it's not so much intended as a "you can allow arbitrary untrusted code to run as an unprivileged service" and more "a buggy unprivileged service won't compromise the whole system".

> Recently people argued that instead of focusing on Rust-for-Linux it would be easier to create a drop-in replacement like these two

I guess it depends on what they mean by "easy". Certainly it's easier in the sense that you can just write code all day long, and not have to deal with the politics about Rust inside Linux, or deal with all the existing C interfaces, finding ways to wrap them in Rust in good, useful ways that leverage Rust's strengths but don't make it harder to evolve those C interfaces without trouble on the Rust side.

But the bulk of Linux is device drivers. You can build a kernel in Rust (like Asterinas) that can run all of a regular Linux userland without recompilation, and I imagine it's maybe not even that difficult to do so. But Asterinas only runs on x86_64 VMs right now, and won't run on real hardware. Getting to the point where it could -- especially on modern hardware -- might take years. Supporting all the architectures and various bits of hardware that Linux supports could take decades. I suppose limiting themselves to three or four architectures, and only supporting hardware made more recently could cut that down. But still, it's a daunting project.

I think it’s “Currently, Asterinas only supports x86-64 VMs. However, [rather than working on additional architectures this year,] our aim for 2024 is to make Asterinas production-ready on x86-64 VMs.”

Sounds like their goal is to improve their x86-64 support before implementing other ISAs.

It's clearer from the book roadmap:

> By 2024, we aim to achieve production-ready status for VM environments on x86-64. > In 2025 and beyond, we will expand our support for CPU architectures and hardware devices.

https://asterinas.github.io/book/kernel/roadmap.html

They lack essential things for a kernel that could be used in production, viz. not kernel panicing during out-of-memory conditions, not an easy thing to retrofit when you have designed without consideration of it. It will probably take a bit more than 2 and a half months to rectify that.

https://github.com/asterinas/asterinas/issues/669

Distinction here is between "supports" and "production-ready on", not "x86-64" and "x86-64"

it would be nice to know how much userspace it supports. supporting the dynamic loader, reasonable futexes, epoll, signals, uring are all big milestones

Yeah, I had to read that a few times... I think they just mean it isn't production ready yet, but that's what they are aiming for.

While developing the lx brand on illumos/SmartOS, ltp was helpful. It may not be complete, but it is a pretty good start.

https://linux-test-project.readthedocs.io/en/latest/

Here is a list of implemented syscalls, but of course each checked one could still be slightly incompatible:

https://asterinas.github.io/book/kernel/linux-compatibility....

Makes a lot of sense for virtual machine containers. Inside a container inside a VM, you need far less operating system.

Linux kernel as much as possible tries not to parse or read external data (besides stuff like acpi tables, device trees, hardware registers). For networking, you might look at the iproute codebase to see how they do things like bring a network device up, or create a bridge device, add a route, et cetera.

Edit: looks like iproute2 uses NETLINK, but non-networking tools might use syscalls or device ioctls.

https://en.m.wikipedia.org/wiki/Netlink

It's just what we used to call a "layered architecture".

No. The drivers in Linux are kernel modules, most often in-tree - meaning that the source for the drivers is built along the rest of the kernel source code. Most hardware drivers depend on various common kernel structures that change often - when they do, the source for drivers is fixed practically in the same git branch. There is no driver ABI to speak of.

No. There is no stable ABI nor API for in-kernel device drivers.

Shame about the lack of a stable kernel driver ABI/API in Linux otherwise this kernel could inherent a lot of drivers.

Its not the Chinese words that scare me. It the English "safety" and "security" referring to specific properties and concepts... but wildly different ones between sentences. Like its all 2009 again and we are hoping we avoided XSS when we picked the appropriate quote/encode/escape method.

Supposing it caught on... which do you think is riskier? Running an OS written in mostly memory safe code that somewhat might have tried to slip a backdoor in, or running an OS written in mostly memory unsafe code that has a long history of vulnerabilities and the Chinese almost certainly know about a vulnerability in.

If this catches on and has generally been subject to significant third party code review with positive results, I'm not sure any backdoor is lower cost to use than an equivalent linux vulnerability. To be fair, I'm not sure it isn't either.

You're wrong. A lot of Chinese code and hardware is in production in the west. Huawei networking hardware is widespread, for example.

When someone writes one

More recently, in a similar vein:

> Torvalds seemed optimistic that "some clueless young person will decide 'how hard can it be?'" and start their own operating system in Rust or some other language. If they keep at it "for many, many decades", they may get somewhere; "I am looking forward to seeing that". Hohndel clarified that by "clueless", Torvalds was referring to his younger self; "Oh, absolutely, yeah, you have to be all kinds of stupid to say 'I can do this'", he said to more laughter. He could not have done it without the "literally tens of thousands of other people"; the "only reason I ever started was that I didn't know how hard it would be, but that's what makes it fun".

https://lwn.net/Articles/990534/

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 feel like there's a potentially large audience for a kernel that targets running in a VM. For a lot of workloads, a simple VM kernel could be a win.

Just ask an AI to riir linux drivers. Anybody tried it?

I'm curious about the practical aspect: Are they going to freeze a stable driver ABI, or are they going to break proprietary drivers from time to time?

Hardly different from downloading random binary installers and executing them. Or random source distributions and (sudo) make install. Or npm/pip/cargo/etc. install random packages. Before anyone mentions distros and package managers, as a former team member of a major package manager I can assure you we don’t vet shit beyond project notability, and new versions are accepted semi-automatically. We’ll yank something after the fact if you report a malicious update, sure.

curl | bash has an actual problem: potential execution of an incomplete script (which can be mitigated with function calling). And there’s the mostly theoretical problem of the server being pwned / sending malicious code just to you (which of course also applies to any other unsigned channel). Arbitrary code execution is never a problem unique to it, but people dunk on it all the time because they saw another person dunking on it in the past.

Is the "--privileged" option ironic here? The project is very interesting, but it feels a bit pedantic, especially when emphasizing Rust's safety features while downplaying Linux. At the same time, it seems they're not fully applying those principles themselves, which makes it feel like they're not quite 'eating their own lunch'.

Huh? What is this nonsense?? Are you suggesting that you like to write practical-oriented, simple and working solutions instead of yak shaving half a day at perfecting ridiculous type signatures, removing „unsafe“ code and satisfying borrow checker? Proposterous! /s