The question I always have when I see these userspace kernels is, Linux in Userspace exists. You can boot Linux with a root in userspace already. Why write a new kernel from scratch instead of fixing/improving usermode Linux instead, which has the benefit of providing the entire Linux API already?
Option A) Everyone shares one OS (container, sandbox, kernel, firewall, whatever). It gets a lot of eyes on it to find bugs. Hacker fuzzes it with a lot of tokens offline. He finds one exploitable vulnerability and he owns everyone.
Option Z) Everyone vibe codes their own custom OS. Each implements and exposes only what they want. Hacker has to beat up on it online to find vulnerabilities. He finds one and he only owns that one machine.
There's probably some middle ground between A and Z, but monocultures are fragile. All eggs in one basket, potato famines, banana fungus, etc...
Option L) Hacker realizes theres more to be gained from joining the builders and shows both sides how to secure their lots against people worse than them
Yes. I'm advocating for consideration of Option Z.
Option A is the best practices status quo for a lot of people. "Don't waste time and money reinventing the wheel", "Given enough eyes, all bugs are shallow", etc...
But Option Z is becoming cheap and fast, and given all the eyes, there still seem to be a lot of bugs in Option A.
Maybe it's better to tolerate a few bugs so long as it's not the same bug on everyone's computer.
Maybe you have fewer bugs if you aren't supporting 50 years of backwards compatibility.
Maybe the economics and risks change for the hacker when he can't find bugs offline.
Maybe we should appreciate people researching how to vibe code containers and kernels.
If we are using only a few LLMs then chances are that they will tend to make same kind if errors when building something. Take LLM prose being annoying - it is so because it is very homogeneous.
So it can very well be worst of bith worlds, worse security on actually homogeneous systems.
If everyone prompts, "reimplement Linux", that's possible or likely.
The dude who says, "Give me a microkernel, use QNX request/receive/respond for syscalls, it only runs WASM blobs, device drivers are isolated user mode processes, it only supports HTTPS on one network interface, and the file system is readonly ExFAT" will probably get something different.
I hate low value LLM prose (slop) too, but if you ask it to write like Herman Melville, you'll get few "it's not this, it's that".
Maybe you do still get the same kinds of errors when you ask for VMS, 64 bit memory safe DOS, or a Unikernel. I dunno, but it seems like something that could be improved when it's identified.
How would it work against vulnerabilities? You still put php inside, and it handles your data. When php is hacked, all your data is stolen, it doesn't matter that your OS is slightly different.
If the host's network driver is hacked, all userland is stolen too.
I'm not sure any software is so valuable that you should never consider replacing it. Vibe coding a PHP substitute probably takes less time and tears than cleaning up a PHP exploit.
Someone more qualified than me can speak to isolating device drivers. I do know that one of the virtues of microkernels was supposed to be that you can run drivers unprivileged.
I sincerely try to avoid sarcasm. Communication is hard enough without it.
Just to clarify: I didn't mean the effort to find and fix a vulnerability in PHP (although that is also difficult). I meant the effort to reformat your system, investigate what else was compromised, and recover from backups after you get hacked through an exploit in PHP.
You probably don't use every last function, and you might be underestimating what became possible this year. You could have a model search for the features you use. You could have it loop until your existing code passes with the substitute. You could have it rewrite your code to use fewer features while still passing your existing tests.
I'm not saying you have to do this, but I think we should question which of our old approaches are based on old constraints.
Php vulnerability depends on the rest of your system. E.g. imagine your system has strict sandboxing for PHP.
Also this is like the worst case where the bug is in one monolithic piece of sw. Something like the alpine ssh bug is more relevant, you can plainly see not all systems are effected.
Not OP but security and ressource usage are often the main motivators.
For security, GVisor is probably the most widely used userspace-kernel. A userspace kernel may also boot faster and use less resources as it can offload a lot of work to the host (FS drivers etc.)
What existed when Linux was started? It had an obvious advantage over proprietary unixen (being gratis and libre, plus running on commodity hardware), and to the best of my knowledge the only real competition was from BSD, which was at the time under some legal dispute.
It’s the same approach as gVisor. Fairly decent isolation if your application can work on it, but your SOL if a scenario comes up that doesn’t work. VMs give you pretty much 100% Linux compatibility at the expense of density, optimal resource allocation and startup time. gVisor gives you excellent startup time, resource allocation and density at the expense of some app compat and performance at the extremes
Edit: at least with gvisor you get close to a decade of work on compat. gVisor can support some rootless containers scenarios and systemd these days.
I’d be very interested in it if it started to approach VM style isolation without needing KVM access (or qemu).
But I’m not sure if that is really possible.
The use case I’m thinking about is a sandbox exec isolation on an HPC cluster without Docker. I know singularity/apptainer exist, but I’m always looking for something that could make that environment more flexible. It is a tight security environment, so we are always limited in what we can do.
It all becomes a religion to some people. hypervisor escapes are a thing. People always point to Vt-x or AMD-V as having stood the test of time, and that might be true, but the software layer on top certainly hasn’t. Yet you will have “security professionals” tell you that you can’t trust anything beyond a hypervisor. Or they might tell you that a user space kernel is just as secure. They might tell you KVM is a no-go because of bad Type1/Type2 hybrid architecture compared to Xen or HyperV Type1. All have had their fair share of vulnerabilities over the years. All less than Linux process isolation, but still.
I really like Virtualization to keep things separate, but I never thought of it as an impenetrable wall. For example, I'd not trust an AI agent even inside a VM in my own system.
OTOH, running a messy environment with rollback support is much easier with a VM than a container.
Containers are fun for packing messy executables into their own environment and run them now and then, though.
I don’t find VMs to be that much easier to manage (in terms of rollback) than containers. The opposite in fact. VMs are these giant blobs that can be stateful or stateless or a mix of both. While containers have clear separation between the state (stored on volumes or in an external store like a db) and the “application” stored in immutable tags or digests.
Rolling back is easy as long as you understand where the state, if any, is which is actually the hard part of any application. At least with containers you have all of them stored in a well defined registry, while with VMs you would be rolling your own VM snapshot storage system. Not super complicated to do in the grand scheme of things, but it’s another thing you need to get right. But VMs/applications that can rollback would be just as easy (if not easier) to rollback with containers.
>I really like Virtualization to keep things separate, but I never thought of it as an impenetrable wall. For example, I'd not trust an AI agent even inside a VM in my own system.
Remember the submission about how Auto Review is safe? Their standard of safe is that it will take a playwright dependency of another project in your home directory and add playwright based tests to your current project that hasn't declared playwright as a dependency. Amazing.
The issue literally isn't even about a hypothetical security argument anymore. Your sandbox is now a policy that tells the agent what it is allowed to do or not.
If it has to go through another layer , hopefully without ring0 privs, which more than likely may filter out a number of exploit vectors, how is this the wrong approach ?
Breaking this layer doesn;t automatically give ring0 privs across the hardware.
The Linux kernel is a gigantic attack surface with a ton of legacy stuff most modern applications will never need. Namespaces do not really help with this, but userspace kernels can. (Haven't looked into Ginux enough to know if it does.)
That is also why I believe the namespace approach, and by extension Docker-like containerization, is a dead end when it comes to isolation. I hope something like gVisor will win.
This is even more important since agents have turned isolation from a datacenter topic into everyone's concern.
> The Linux kernel is a gigantic attack surface with a ton of legacy stuff most modern applications will never need. Namespaces do not really help with this, but userspace kernels can. (Haven't looked into Ginux enough to know if it does.)
This is incorrect. If you can't trust Linux because it is gigantic, you can't trust a whole another new kernel. Userspace is not blackmagic.
Another new kernel might be 1/6000 the size of Linux and therefore have 1/600 times the exploitable bugs—or none, using formal methods. The question is how much a new user-mode kernel can shield Linux from attacks. Usually the new kernel depends on Linux to separate it from the malicious code!
> Another new kernel might be 1/6000 the size of Linux and therefore have 1/600 times the exploitable bugs—or none, using formal methods. The question is how much a new user-mode kernel can shield Linux from attacks. Usually the new kernel depends on Linux to separate it from the malicious code!
Is there any new language close to rust which can help being verified using formal methods or would some other language be more suitable for this job?
Maybe using verus + rust, it seems that atmosphere[0] is an interesting project in this space
Of established languages, Rust, OCaml, F#, and Lean seem to be promising for this kind of thing, but people seem to be vibecoding a lot of new languages right now with this use in mind.
No, I writing that in response to "If you can't trust Linux because it is gigantic, you can't trust a whole another new kernel. Userspace is not blackmagic." The nature of Ginux is irrelevant to that proposition, and, as I think I have clearly shown, it is not well thought out.
This is really awesome and the next rabbit hole I want to check out. I'm on the defensive making software for me running AIs in the most secure way possible, and one main lack was the ability to fully guard against kernel attacks should a jailbreak happen. Its another layer I can add for defense in depth, thanks!
So how exactly can you control multiple isolated address spaces for the leaf user processes and how do you handle syscalls? Does the host kernel have facilities for normal user processes to do so?
> The current implementation includes a security-focused x86-64 interpreter and a balanced native ptrace backend;
ptrace allows you to have the kernel redirect syscalls back to userspace, mostly for debugging purposes. "balanced" here refers to speed, but the overhead is still quite high.
Why should someone spend anytime on this kind of technical piece that is not created by human? Think about what you will get from this, the answer is pretty obvious.
Well, one obvious issue is that this is controlled not by humans,
whereas the linux kernel is. What if the parent company changes
things with regards to the AI here? You may have to pay more
suddenly.
You could probably work around this partially by having contracts
with people, but these in turn also depend on the AI slop then,
so the problem is just shifted.
It is being created by a human, though. Greg Kurtzer is one of the authors of Rocky Linux. He has the respect of his peers. Perhaps you just aren't one.
A userspace kernel is already pretty niche. Not many people will get anything serious out of it.
The slop problem is also a challenge to overcome. The project barely existed and has already pivoted in a completely new direction. Who knows when this direction bores the author and we get yet another pivot. Or the author loses interest and we end up with a dead pile of abandoned code like so many other LLM generated projects.
The previous state of the project could've made for an interesting VM runtime (safety of Rust without the issues that come with the lack of ported drivers). For this new direction, I don't think there's a similar sort of demand.
Stating that nobody will take it seriously is probably an exaggeration, but I consider these projects to be toys for the author to play with, I don't see why you would take more interest than going "huh, neat I guess".
To me, it's that little effort was put into it, so no commitment has been demonstrated. You wouldn't want to build anything serious on top of it because you'd probably just have to throw it away.
A project picked up casually, for a short time, is likely to be dropped casually, in a short time.
More seriously, it is a great use of indirection insofar as replacing the full Linux kernel is a gargantuan task. A userspace kernel per task or task group.. makes a lot of sense. I'd be interested to know how it captures syscalls - eBPF? It wasn't obvious from a skim of the readme.
This kind of give-me-this-interface work seems pretty perfect for LLMs, too.
Which, in turn, makes the word "slop" a joke and a tool that we will soon probably see the pro-AI/AI boosters start to mock them with. Wouldn't even surprise me if I started to see them flipping the tables and calling human-generated content slop, because if there's one thing humans are good at it's writing slop, without the use of AI.
The question I always have when I see these userspace kernels is, Linux in Userspace exists. You can boot Linux with a root in userspace already. Why write a new kernel from scratch instead of fixing/improving usermode Linux instead, which has the benefit of providing the entire Linux API already?
Option A) Everyone shares one OS (container, sandbox, kernel, firewall, whatever). It gets a lot of eyes on it to find bugs. Hacker fuzzes it with a lot of tokens offline. He finds one exploitable vulnerability and he owns everyone.
Option Z) Everyone vibe codes their own custom OS. Each implements and exposes only what they want. Hacker has to beat up on it online to find vulnerabilities. He finds one and he only owns that one machine.
There's probably some middle ground between A and Z, but monocultures are fragile. All eggs in one basket, potato famines, banana fungus, etc...
Option L) Hacker realizes theres more to be gained from joining the builders and shows both sides how to secure their lots against people worse than them
is this before or after we lay off all the builders?
if all the builders are laid off, what is there left to hack?
soon after that, the laid-off hackers become the next builders :)
circles. revolutions. until its learned to see whats ahead, then it can be diverted to something new
Heterogeneity is bffs with security though. Maybe option z isn't so bad after all.
Yes. I'm advocating for consideration of Option Z.
Option A is the best practices status quo for a lot of people. "Don't waste time and money reinventing the wheel", "Given enough eyes, all bugs are shallow", etc...
But Option Z is becoming cheap and fast, and given all the eyes, there still seem to be a lot of bugs in Option A.
Maybe it's better to tolerate a few bugs so long as it's not the same bug on everyone's computer.
Maybe you have fewer bugs if you aren't supporting 50 years of backwards compatibility.
Maybe the economics and risks change for the hacker when he can't find bugs offline.
Maybe we should appreciate people researching how to vibe code containers and kernels.
If we are using only a few LLMs then chances are that they will tend to make same kind if errors when building something. Take LLM prose being annoying - it is so because it is very homogeneous.
So it can very well be worst of bith worlds, worse security on actually homogeneous systems.
If everyone prompts, "reimplement Linux", that's possible or likely.
The dude who says, "Give me a microkernel, use QNX request/receive/respond for syscalls, it only runs WASM blobs, device drivers are isolated user mode processes, it only supports HTTPS on one network interface, and the file system is readonly ExFAT" will probably get something different.
I hate low value LLM prose (slop) too, but if you ask it to write like Herman Melville, you'll get few "it's not this, it's that".
Maybe you do still get the same kinds of errors when you ask for VMS, 64 bit memory safe DOS, or a Unikernel. I dunno, but it seems like something that could be improved when it's identified.
>64 bit memory safe DOS
Ok, you have me intrigued. FreeDOS-64!
One COMMAND64.COM, one CONFIG64.SYS, an optional AUTOEXEC64.BAT, and the rest of the computer is yours. Maybe use forward slashes though. :-)
How would it work against vulnerabilities? You still put php inside, and it handles your data. When php is hacked, all your data is stolen, it doesn't matter that your OS is slightly different.
If the host's network driver is hacked, all userland is stolen too.
But if php is hacked and that's chained with a LPE, we'd like the attacker to get root inside a sandbox where that doesn't mean much.
I'm not sure any software is so valuable that you should never consider replacing it. Vibe coding a PHP substitute probably takes less time and tears than cleaning up a PHP exploit.
Someone more qualified than me can speak to isolating device drivers. I do know that one of the virtues of microkernels was supposed to be that you can run drivers unprivileged.
> Vibe coding a PHP substitute probably takes less time and tears than cleaning up a PHP exploit.
Sarcasm? Definitely not true, by several orders of magnitude. Have you seen how many built-in functions PHP has?
I sincerely try to avoid sarcasm. Communication is hard enough without it.
Just to clarify: I didn't mean the effort to find and fix a vulnerability in PHP (although that is also difficult). I meant the effort to reformat your system, investigate what else was compromised, and recover from backups after you get hacked through an exploit in PHP.
You probably don't use every last function, and you might be underestimating what became possible this year. You could have a model search for the features you use. You could have it loop until your existing code passes with the substitute. You could have it rewrite your code to use fewer features while still passing your existing tests.
I'm not saying you have to do this, but I think we should question which of our old approaches are based on old constraints.
Forget PHP, just vibe code a substitute for the ten lines of WordPress you actually need.
(Better yet, just regular code it!)
Php vulnerability depends on the rest of your system. E.g. imagine your system has strict sandboxing for PHP.
Also this is like the worst case where the bug is in one monolithic piece of sw. Something like the alpine ssh bug is more relevant, you can plainly see not all systems are effected.
Not OP but security and ressource usage are often the main motivators.
For security, GVisor is probably the most widely used userspace-kernel. A userspace kernel may also boot faster and use less resources as it can offload a lot of work to the host (FS drivers etc.)
Ok, but Linux UM exists - why can't it be extended and used instead? It should in theory offer better compatibility, right?
User Mode Linux does work, but it can have significant performance issues and isn't actually very portable.
Yes, I've tried using it before.
Didn't people ask the same question when Linux came out? Why go with X when Y exists?
What existed when Linux was started? It had an obvious advantage over proprietary unixen (being gratis and libre, plus running on commodity hardware), and to the best of my knowledge the only real competition was from BSD, which was at the time under some legal dispute.
How is Ginux different from User mode Linux?
https://en.wikipedia.org/wiki/User-mode_Linux
It is AI slop.
It seems to be more like gVisor than UML, providing a restricted kernel interface as opposed to the full kernel.
This is kind of the wrong approach when linux namespaces exist and rootless namespaces are approach full spectrum.
I’m still fascinated by the approach, though. It seems to me that it sits somewhere between cgroups and virtual machines.
I do wonder what problem it solves, as I don’t think that it provides the same security guarantees that micro-VMs like firecracker do?
It’s the same approach as gVisor. Fairly decent isolation if your application can work on it, but your SOL if a scenario comes up that doesn’t work. VMs give you pretty much 100% Linux compatibility at the expense of density, optimal resource allocation and startup time. gVisor gives you excellent startup time, resource allocation and density at the expense of some app compat and performance at the extremes
Edit: at least with gvisor you get close to a decade of work on compat. gVisor can support some rootless containers scenarios and systemd these days.
I wonder if this can grow into a capability-based security tool.
I’d be very interested in it if it started to approach VM style isolation without needing KVM access (or qemu).
But I’m not sure if that is really possible.
The use case I’m thinking about is a sandbox exec isolation on an HPC cluster without Docker. I know singularity/apptainer exist, but I’m always looking for something that could make that environment more flexible. It is a tight security environment, so we are always limited in what we can do.
It all becomes a religion to some people. hypervisor escapes are a thing. People always point to Vt-x or AMD-V as having stood the test of time, and that might be true, but the software layer on top certainly hasn’t. Yet you will have “security professionals” tell you that you can’t trust anything beyond a hypervisor. Or they might tell you that a user space kernel is just as secure. They might tell you KVM is a no-go because of bad Type1/Type2 hybrid architecture compared to Xen or HyperV Type1. All have had their fair share of vulnerabilities over the years. All less than Linux process isolation, but still.
I really like Virtualization to keep things separate, but I never thought of it as an impenetrable wall. For example, I'd not trust an AI agent even inside a VM in my own system.
OTOH, running a messy environment with rollback support is much easier with a VM than a container.
Containers are fun for packing messy executables into their own environment and run them now and then, though.
I don’t find VMs to be that much easier to manage (in terms of rollback) than containers. The opposite in fact. VMs are these giant blobs that can be stateful or stateless or a mix of both. While containers have clear separation between the state (stored on volumes or in an external store like a db) and the “application” stored in immutable tags or digests.
Rolling back is easy as long as you understand where the state, if any, is which is actually the hard part of any application. At least with containers you have all of them stored in a well defined registry, while with VMs you would be rolling your own VM snapshot storage system. Not super complicated to do in the grand scheme of things, but it’s another thing you need to get right. But VMs/applications that can rollback would be just as easy (if not easier) to rollback with containers.
>I really like Virtualization to keep things separate, but I never thought of it as an impenetrable wall. For example, I'd not trust an AI agent even inside a VM in my own system.
Remember the submission about how Auto Review is safe? Their standard of safe is that it will take a playwright dependency of another project in your home directory and add playwright based tests to your current project that hasn't declared playwright as a dependency. Amazing.
The issue literally isn't even about a hypothetical security argument anymore. Your sandbox is now a policy that tells the agent what it is allowed to do or not.
> All less than Linux process isolation, but still.
.... Right. Exactly. Everything has some vulnerabilities, but if an attacker has to use a relatively rare VM escape, that's a huge win.
> Telling someone's research and exploration is wrong...
Never change, HN, never change :D
The project says:
> That research phase is complete.
So not sure what part of it now constitutes "research and exploration".
Isn't this also adding a capability sort of like OpenBSD's pledge?
If it has to go through another layer , hopefully without ring0 privs, which more than likely may filter out a number of exploit vectors, how is this the wrong approach ?
Breaking this layer doesn;t automatically give ring0 privs across the hardware.
The Linux kernel is a gigantic attack surface with a ton of legacy stuff most modern applications will never need. Namespaces do not really help with this, but userspace kernels can. (Haven't looked into Ginux enough to know if it does.)
That is also why I believe the namespace approach, and by extension Docker-like containerization, is a dead end when it comes to isolation. I hope something like gVisor will win.
This is even more important since agents have turned isolation from a datacenter topic into everyone's concern.
> The Linux kernel is a gigantic attack surface with a ton of legacy stuff most modern applications will never need. Namespaces do not really help with this, but userspace kernels can. (Haven't looked into Ginux enough to know if it does.)
This is incorrect. If you can't trust Linux because it is gigantic, you can't trust a whole another new kernel. Userspace is not blackmagic.
Another new kernel might be 1/6000 the size of Linux and therefore have 1/600 times the exploitable bugs—or none, using formal methods. The question is how much a new user-mode kernel can shield Linux from attacks. Usually the new kernel depends on Linux to separate it from the malicious code!
> Another new kernel might be 1/6000 the size of Linux and therefore have 1/600 times the exploitable bugs—or none, using formal methods. The question is how much a new user-mode kernel can shield Linux from attacks. Usually the new kernel depends on Linux to separate it from the malicious code!
Is there any new language close to rust which can help being verified using formal methods or would some other language be more suitable for this job?
Maybe using verus + rust, it seems that atmosphere[0] is an interesting project in this space
[0]: https://mars-research.github.io/projects/atmo/
Of established languages, Rust, OCaml, F#, and Lean seem to be promising for this kind of thing, but people seem to be vibecoding a lot of new languages right now with this use in mind.
You writing that in response to a vibecoded kernel.
No, I writing that in response to "If you can't trust Linux because it is gigantic, you can't trust a whole another new kernel. Userspace is not blackmagic." The nature of Ginux is irrelevant to that proposition, and, as I think I have clearly shown, it is not well thought out.
In that case, wouldn't it make more sense to build the Linux kernel without those features, or to replace them with sufficient mocks?
You might want to expose more to trusted apps and less to more threatened ones. With kernel shim like gVisor you can have this with little effort.
Ah, good point, thanks!
Rootless namespaces are getting better, but they don't eliminate the host kernel attack surface
You can combine hypervisors, user space kernels and linux namespaces all into one solution. The attacker will have to escape all of them.
This is really awesome and the next rabbit hole I want to check out. I'm on the defensive making software for me running AIs in the most secure way possible, and one main lack was the ability to fully guard against kernel attacks should a jailbreak happen. Its another layer I can add for defense in depth, thanks!
https://github.com/RALaBarge/enclave
Post from yesterday: https://news.ycombinator.com/item?id=50424147
Talk about pivoting. I guess that's what you call lean and agile.
A big concern for me is this: would an AI generated kernel be built with a backdoor or hidden vulnerability by the AI engine generating the code?
So how exactly can you control multiple isolated address spaces for the leaf user processes and how do you handle syscalls? Does the host kernel have facilities for normal user processes to do so?
From the README
> The current implementation includes a security-focused x86-64 interpreter and a balanced native ptrace backend;
ptrace allows you to have the kernel redirect syscalls back to userspace, mostly for debugging purposes. "balanced" here refers to speed, but the overhead is still quite high.
The issue with this kind of thing is nobody will take it seriously.
Why? Because a user space kernel is a bad idea? Or because of the AI use when writing it?
I’m still trying to figure out exactly what it is.
Why should someone spend anytime on this kind of technical piece that is not created by human? Think about what you will get from this, the answer is pretty obvious.
No obvious to me, sorry. What will I get from this?
Well, one obvious issue is that this is controlled not by humans, whereas the linux kernel is. What if the parent company changes things with regards to the AI here? You may have to pay more suddenly.
You could probably work around this partially by having contracts with people, but these in turn also depend on the AI slop then, so the problem is just shifted.
Parent company? It's just this one dude's pet project
It is being created by a human, though. Greg Kurtzer is one of the authors of Rocky Linux. He has the respect of his peers. Perhaps you just aren't one.
A userspace kernel is already pretty niche. Not many people will get anything serious out of it.
The slop problem is also a challenge to overcome. The project barely existed and has already pivoted in a completely new direction. Who knows when this direction bores the author and we get yet another pivot. Or the author loses interest and we end up with a dead pile of abandoned code like so many other LLM generated projects.
The previous state of the project could've made for an interesting VM runtime (safety of Rust without the issues that come with the lack of ported drivers). For this new direction, I don't think there's a similar sort of demand.
Stating that nobody will take it seriously is probably an exaggeration, but I consider these projects to be toys for the author to play with, I don't see why you would take more interest than going "huh, neat I guess".
To me, it's that little effort was put into it, so no commitment has been demonstrated. You wouldn't want to build anything serious on top of it because you'd probably just have to throw it away.
A project picked up casually, for a short time, is likely to be dropped casually, in a short time.
probably you get more isolation with jslinux
My immediate thought was this: https://en.wikipedia.org/wiki/User-mode_Linux
More seriously, it is a great use of indirection insofar as replacing the full Linux kernel is a gargantuan task. A userspace kernel per task or task group.. makes a lot of sense. I'd be interested to know how it captures syscalls - eBPF? It wasn't obvious from a skim of the readme.
This kind of give-me-this-interface work seems pretty perfect for LLMs, too.
Nobody will take him seriously.
Guys - AI slop is winning the war. Soon the Top 500 Supercomputers will run AI-Ginux rather than Linus-Linux.
When something has to be secure and battle-tested, this won’t happen. It can be written with the help AI, but it needs many humans to verify.
Don't worry, Linus-Linux already stands on the AI slop side.
Can you link to an AI contribution to the mainline kernel that qualifies as slop?
The anti-AI crowd uses "slop" as a term for all AI contributions, so yes, trivially.
Which, in turn, makes the word "slop" a joke and a tool that we will soon probably see the pro-AI/AI boosters start to mock them with. Wouldn't even surprise me if I started to see them flipping the tables and calling human-generated content slop, because if there's one thing humans are good at it's writing slop, without the use of AI.