Cozy video games can quell stress and anxiety (reuters.com)
366 points by vinhnx 7h ago 204 comments
How a yacht works: sailboat physics and design (onemetre.net)
203 points by stass 3d ago 62 comments
Unikernel Linux (UKL) (2023)
100 pabs3 14 4/18/2025, 8:11:45 AM dl.acm.org ↗
https://www.sovereign.tech/
Yes, everything has to be recompiled, because it must be linked to the Linux kernel to create a single vmlinuz containing application + kernel.
One of the aims[1] was requiring minimum source-level modifications to achieve this. For C/C++ programs this was pretty much achieved. As you say for Java or Dotnet you'd have to port the runtime (which we never did) and then the class files ought to run unmodified on top.
Having said that, there's not much benefit to this (perhaps a negligible increase in performance) if you only link your application to Linux. The real benefits come when hotspots within your application are modified so they interact directly with Linux internals (noting that Linux internal APIs are not stable). One example from the paper is shortcutting through the VFS when you know that a read(2) call is always reading from a TCP socket. Another might be to arbitrarily modify page tables to make your garbage collector more efficient. Another one which my student was working on was making Linux epoll handlers direct call into the "userspace" code that handles an event.
A cute part of this is that it's still Linux, just with a "fatter" kernel containing the application. It still has a userspace, and you can still run stuff in that userspace if you want. That's especially useful for debugging (put sshd + a shell in there), or performance analysis (run perf alongside the unikernel program).
There are definitely arguments to be had about whether any of this is a good idea or not, which is why it's a research paper. I think nowadays I'd say that much of the performance benefit can be achieved using io_uring.
[1] Another aim was making minimum changes to Linux itself so it might have some chance to go upstream, which of course it never did.
The tombl Linux-wasm [2] seems like it could be a path to upstream many of the ideas in UKML, but with a new target arch behind it so it's not just a performance boost but also a portability one. The browser demo is pretty impressive: https://linux.tombl.dev
[1] https://anil.recoil.org/notes/wasm-on-exotic-targets [2] https://github.com/tombl/linux
I feel that with the uptake in container technology, kubernetes, serverless approaches, with managed runtimes, running directly on top of type 1 hypervisors, the have kind of achieved unikernel ideas, even if not in an ideal form.
The usual worse is better outcome.
Naturally this doesn't fit the traditional C and C++ execution model, due to the expectations of a POSIX environment instead of the rich runtimes from managed languages, which is where I see the value of this kind of work.
- https://lore.kernel.org/lkml/20221003222133.20948-1-aliraza@...
- https://github.com/unikernelLinux/ukl
However there are some similarities. The trust boundary is between the hardware and the unikernel (kernel + userspace in your case). If the program goes rogue / gets exploited, then networking and firewalls are what protects you. Or in the case where you run the unikernel in a VM, then it's the virtualization boundary that protects you.