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

Asterinas: A new Linux-compatible kernel project

lwn.net

Post reply on HN
Print view View original

41–50 of 81 posts

Re: Asterinas: A new Linux-compatible kernel project

#41

Post by digdugdirk »

weinzierl wrote: post #24

This is an interesting approach, and I wish it will succeed. I am still skeptical. In the late 90s or early 2000s Linus was interviewed on TV and what he said stuck with me to this day. When asked about competitors he roughly said: No one likes writing device drivers and as long no one young and hungry comes along who is good at writing device drivers I am save. I think he was already well aware at that time that kee…

Hmmm... Would containers + AI enable a scattershot "just let the LLM keep trying stuff until it works" approach to driver development?

Re: Asterinas: A new Linux-compatible kernel project

#42

Post by rcxdude »

reactordev wrote: post #36
tatetian16 wrote: post #29

Earlier quoted context omitted.

> keeping the driver interface unstable is his moat Maybe we will have young and hungry AI-for-system researchers who would like to take on the job of developing AI agents that translate Linux drivers in C to Asterinas ones in (safe) Rust. Another feasible approach is to reuse Linux drivers by running a Linux kernel inside some kind of isolated environments. For example, the HongMeng kernel leverages User-Mode Linux…

This is the future. Hardware has already standardized more towards USB HID than in previous decades, Linus interview included. When AI can develop these device drivers based on just probing the HID info, we’ll be on Cloud9. Because maybe then, we’ll get the year of the Linux desktop.

Such standard interfaces are rarely the problem, though there is often a headache of dealing with the pile of 'quirky' hardware that just so happens to work well enough with exactly what windows happens to do. The pain point is all the things that aren't that. Nonstandard, niche hardware which maybe has a few thousand users, or big and complex interfaces like graphics cards which are basically whole OSs on their own.

Re: Asterinas: A new Linux-compatible kernel project

#43

Post by jitl »

weinzierl wrote: post #24

This is an interesting approach, and I wish it will succeed. I am still skeptical. In the late 90s or early 2000s Linus was interviewed on TV and what he said stuck with me to this day. When asked about competitors he roughly said: No one likes writing device drivers and as long no one young and hungry comes along who is good at writing device drivers I am save. I think he was already well aware at that time that kee…

On the other hand, running on real hardware is less important if none of your hardware is real!

98% of Linux I interact with is running virtualized: on my desktop/laptop systems it’s either Virtualbox full-screened so I can use Windows for drivers, or a headless VM managed by Docker.app on my Mac. All my employer’s production workloads are AWS virtual machines.

My only Linux bare metal hardware is a home server, which I’m planning to retire soon-ish, replaced by a VM on an ebay Mac mini to reduce power bill & fan noise.

If someone can make a Linux compatible kernel that’s more secure and just as performant, it’s much easier these days to imagine a large new user base adopting it despite a dearth of drivers.

Re: Asterinas: A new Linux-compatible kernel project

#44

Post by jitl »

digdugdirk wrote: post #41
weinzierl wrote: post #24

This is an interesting approach, and I wish it will succeed. I am still skeptical. In the late 90s or early 2000s Linus was interviewed on TV and what he said stuck with me to this day. When asked about competitors he roughly said: No one likes writing device drivers and as long no one young and hungry comes along who is good at writing device drivers I am save. I think he was already well aware at that time that kee…

Hmmm... Would containers + AI enable a scattershot "just let the LLM keep trying stuff until it works" approach to driver development?

Maybe in a few years. I find ai most successful when you can provide a very clear spec and solid test suite, when I don’t have that it makes a lot of mistakes without handholding.

Re: Asterinas: A new Linux-compatible kernel project

#45

Post by jitl »

uncircle wrote: post #38
lkjdsklf wrote: post #37

Earlier quoted context omitted.

I’m not sure I would consider fuschia an example that supports your point. It’s design largely failed at being a modern generic operating system and it’s become primarily an os used for embedded devices which is an entirely different set of requirements It’s also not that widely used. There’s only a handful of devices that ship fuschia today. There’s a reason for that.

Did it fail because of its microkernel design? It’s quite disingenuous to use “success” as a metric when discussing the advantages microkernel vs monolithic, as the only kernels you can safely say have succeeded in the past 30+ years are three: Linux, NT and Mach, one of which is a microkernel (of arguably dated design), and the other is considered a “hybrid microkernel.” Did L4 fail? What about QNX? This topic was c…

When I read this thread, I think it’s pretty level headed except your last reply lol.

Re: Asterinas: A new Linux-compatible kernel project

#46

Post by yjftsjthsd-h »

kelnos wrote: post #9
yjftsjthsd-h wrote: post #4

> This IPC often has a performance impact, which is a big part of why microkernels have remained relatively unpopular. I thought newer microkernels... Reduced that? Fixed it? I forget, I just had the impression it wasn't actually that bad except that the industry is still traumatized by Mach. From the project website: > Only the privileged Framework is allowed to use unsafe features of Rust, while the unprivileged Se…

My understanding is they don't mean privileged/unprivileged in the kernel-space/user-space sense. All of it is running at the kernel's privilege level. Just they've logically defined a (smaller) set of core library-like code that is allowed to use Rust unsafe ("privileged"), and then all the code that implements the rest of the kernel (including drivers?) uses that library and is disallowed (by linter rules, I assume…

Oh, okay, so it's "privileged" in that it has the privilege of using unsafe. I got that it was all kernel mode but assumed they were doing something fancy to nonetheless restrict the unprivileged parts (though since they say it's all one memory space, I wasn't sure what)

Re: Asterinas: A new Linux-compatible kernel project

#47

Post by daeken »

digdugdirk wrote: post #41
weinzierl wrote: post #24

This is an interesting approach, and I wish it will succeed. I am still skeptical. In the late 90s or early 2000s Linus was interviewed on TV and what he said stuck with me to this day. When asked about competitors he roughly said: No one likes writing device drivers and as long no one young and hungry comes along who is good at writing device drivers I am save. I think he was already well aware at that time that kee…

Hmmm... Would containers + AI enable a scattershot "just let the LLM keep trying stuff until it works" approach to driver development?

Given the number of times I've bricked hardware during reverse-engineering and driver development, I don't find it super likely, tbh. I'm by no means an expert here, but it's one of those things where if you already have good enough documentation (which in this case could be a known-good implementation) then it's more of a translation task and LLMs could absolutely be helpful there, but the edge cases are sharp and frequent.

Re: Asterinas: A new Linux-compatible kernel project

#48

Post by pjmlp »

yjftsjthsd-h wrote: post #34
pjmlp wrote: post #18

Earlier quoted context omitted.

The problem is that many microkernel haters keep repeating what used to be true like 30 years ago, while running tons of containers for basic tasks.

> while running tons of containers for basic tasks. Those containers run on a monolithic kernel; what's your point?

The supposed performance gains from monolithic kernel being wasted on features that mimic microkernel features.

Re: Asterinas: A new Linux-compatible kernel project

#49

Post by pjmlp »

lkjdsklf wrote: post #37
uncircle wrote: post #31

Earlier quoted context omitted.

You describe microkernels are if there is only one way to implement them. > A different process can just ignore your message > arbitrarily get stuck on something and not act in time This doesn't make sense. An implementation of a microkernel might suffer from these issues, it's not a problem of the design itself. There are many ways of designing message queues. Also: > In a microkernel, there can't be such trust [bet…

I’m not sure I would consider fuschia an example that supports your point. It’s design largely failed at being a modern generic operating system and it’s become primarily an os used for embedded devices which is an entirely different set of requirements It’s also not that widely used. There’s only a handful of devices that ship fuschia today. There’s a reason for that.

Don't mistake Google politics with technical achievements.

Re: Asterinas: A new Linux-compatible kernel project

#50

Post by nickpsecurity »

tatetian16 wrote: post #29
weinzierl wrote: post #24

This is an interesting approach, and I wish it will succeed. I am still skeptical. In the late 90s or early 2000s Linus was interviewed on TV and what he said stuck with me to this day. When asked about competitors he roughly said: No one likes writing device drivers and as long no one young and hungry comes along who is good at writing device drivers I am save. I think he was already well aware at that time that kee…

> keeping the driver interface unstable is his moat Maybe we will have young and hungry AI-for-system researchers who would like to take on the job of developing AI agents that translate Linux drivers in C to Asterinas ones in (safe) Rust. Another feasible approach is to reuse Linux drivers by running a Linux kernel inside some kind of isolated environments. For example, the HongMeng kernel leverages User-Mode Linux…

OKL4, deployed on tons of phones, had the ability to run drivers stand alone or in driver VM's that wrapped them. Other guests could call either. I think Genode uses a similar, L4-based component.

There was also an academic project that combined virtualization with Windows drivers.

Post reply on HN