81–90 of 234 posts
Earlier quoted context omitted.
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.
How is that different from Linux with all virtio drivers? (You can just not compile real hardware drivers)
I'm interested in these kind of kernels to run very high performance network/IO specific services on bare metal, with minimal system complexity/overheads and hopefully better (potential) stability and security. The big concern I have however is hardware support, specifically networking hardware. I think a very interesting approach would be to boot the machine with a FreeBSD or Linux kernel, just for the purposes of h…
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
Basically single app directly to network (the world) and as little as possible else in between.
I think this looks incredible. Like how does one create a compatible abi _for all of linux_??? Wow! > utilize the more productive Rust programming language Nitpick: it’s 2024 and these ‘more productive’ comparisons are silly, completely unscientific, And a bit of a red flag for your project: The most productive language for a developer is the one they understand what is happening one layer below the level of abstract…
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.
Earlier quoted context omitted.
How is that different from Linux with all virtio drivers? (You can just not compile real hardware drivers)
I would imagine that virtualized device drivers would have a well-defined api and vastly simplified logic.
I'm interested in these kind of kernels to run very high performance network/IO specific services on bare metal, with minimal system complexity/overheads and hopefully better (potential) stability and security. The big concern I have however is hardware support, specifically networking hardware. I think a very interesting approach would be to boot the machine with a FreeBSD or Linux kernel, just for the purposes of h…
Earlier quoted context omitted.
You're wrong. A lot of Chinese code and hardware is in production in the west. Huawei networking hardware is widespread, for example.
> Huawei networking hardware is widespread That's an interesting example because Huawei equipment is currently being removed by several Western countries (UK, Canada, US, Germany) specifically because it's Chinese. https://www.nytimes.com/2024/07/11/business/huawei-germany-b... https://www.cbc.ca/news/politics/huawei-5g-decision-1.631083... https://www.gov.uk/government/news/huawei-to-be-removed-from... https://www.r…
I personally dislike rust, but I love kernels, and so I'll always check these projects out. This is one of the nicer ones. It looks pretty conservative in it's use of Rust's advanced features. The code looks pretty easy to read and follow. There's actually a decent amount of comments (for rust code). Not bad!
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?
I personally dislike rust, but I love kernels, and so I'll always check these projects out. This is one of the nicer ones. It looks pretty conservative in it's use of Rust's advanced features. The code looks pretty easy to read and follow. There's actually a decent amount of comments (for rust code). Not bad!
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?
Decades ago Linus Torvalds was asked in an interview if he feared Linux to be replaced by something new. His answer was that some day someone young and hungry would come along, but unless they liked writing device drivers Linux would be safe. This is all paraphrased from my memory, so take it with a grain of salt. I think the gist of it is still valid: Projects like Asterinas are interesting and have a place, but the…
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?
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.
The _static_ borrow checker can only check what is _statically_ verifiable, which is but a subset of valid programs. There are few things more frustrating than doing something you know is correct, but that you cannot express in your language.