Hacker News

Heterogeneity is bffs with security though. Maybe option z isn't so bad after all.

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

> 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.

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.

I wonder if this can grow into a capability-based security tool.

The project says:

> That research phase is complete.

So not sure what part of it now constitutes "research and exploration".

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.

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".

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.

Can you link to an AI contribution to the mainline kernel that qualifies as slop?