Posted by juecd 3 days ago
- Chrome DevTools Protocol (for Playwright/Puppeteer)
- noVNC (for live view)
We’ve been following the unikernel space for a while, so we decided to see if we could get our image on one. We went with Unikraft Cloud[1]. Here’s how it did:
- Boot-up time: 10–20ms (vs. ~5s for Docker containers)
- Near 0 CPU/memory consumption when idle
- Still ~8GB RAM when active (headful Chromium)
Potential use cases:
- Standby mode during long-running jobs: unikernels can sleep after X sec of inactivity, reducing clock time costs
- Session reuse: auth/session cookies persist for hours/days. Basically as long as the cookies are valid
- Cold start speed: good for low-latency, event-based handling
We open sourced it with Apache 2.0! Feel free to fork or submit an issue / PR. Open to feedback or suggestions. www.github.com/onkernel/kernel-images
==
[0] https://github.com/onkernel/kernel-images
[2] Thanks to the Unikraft Cloud team @fhuici @nderjung @razvandeax for helping us figure this out (we're not affiliated)
[3] (OPs) @rgarcia @juecd
I used this one-liner to run an instance directly from remote source:
dagger -c 'git https://github.com/onkernel/kernel-images | head | tree | docker-build --dockerfile containers/docker/Dockerfile | up --ports 8501:8501,8080:8080,6080:6080,9222:9222'
I look forward to playing with this!
I saw your announcement post / many contentious HN comments, but wanted to chime in here with a supportive take, because I think time will reveal this design to be very compelling.
I actually agonized over whether to include this particular one-liner, because of the risk of perceived self-promotion. In the end I decided to include it, because I actually used it, and I found it actually useful for anyone who wants to try Kernel with a one-liner. I made sure to not include a link to my project, to keep my karma in balance :)
I've been a fan of unikernels for a long time (we acquired the original Unikernel company at Docker), and I have to say applying it to browsers is genius. Now I'm surprised the unikernel community hasn't focused on this application sooner.
> I'm surprised the unikernel community hasn't focused on this application sooner.
There just wasn’t a compelling usecase before agents to need a serverless browser. And Chromium is basically an OS-in-a-box already, and Unikraft has now matured enough to supply the unikernel scaffolding to link it all together (coordinated by Dagger, it seems!)
- Mounting persistent storage for file i/o
- Replacing noVNC with a faster alternative
Would love feedback, especially if you’ve worked on fast-cold-start systems or unikernel-based infra.
How hard would it be to boot a computer to this as an OS?
Unikernels aren't meant to run as a bare metal OS on a standard computer like a PC. Instead they are applications wrapped in thin libraries that allow them to boot in hardware VM's provided by Intel vmx or AMD svm, etc. A hypervisor provides mechanisms for communication with hardware and other resources. They boot fast because the underlying system and hardware is already initialized and running.
The main idea of unikernels is to get rid of costly system calls like brk/sbrk called by malloc, open/read/write, etc. between the OS and application. The system never has to switch protection rings which saves a lot of time. This gives the application full control of its compute and memory resources with the possibility of direct hardware access depending on the host hardware and hypervisor. So you can attach things like NVM storage directly to the VM and let the application handle the disk and fs operations.
So to answer your original question of using such a wrapper to boot chrome on a PC: you will need a much, much bigger wrapper library which adds in all the hardware access which is a LOT of code (The GPU code alone is scary enough). You must also realize the fast boot time will be obliterated by hardware init which usually takes time as you have to jiggle certain hardware registers to wait, then probe again to see if things are working as advertised. This can take several seconds or more. In the end, you save nothing.
If you wanted an OS based on a hypervisor which boots unikernel applications you are at the mercy of the hardware to multiplex access or delegate that to a hypervisor adding more overhead. Again, you saved nothing.
In the end, your OS is really a CPU multiplexer and does a great job of providing all the primitives and resources in a generalized, uniform manner. I highly recommend reading this book: https://pages.cs.wisc.edu/~remzi/OSTEP/
Originally this absolutely was one of the selling points. NetBSD's rumpkernel, for example, clearly was intended to support bare metal. In practice, though, unikernels are typically run within VMs, for the reason you hinted at--you usually still want a regular OS to multiplex your hardware and (unikernel-based) applications.
I was doing something similar for the entire OS a few years ago: cosmopolinux, a distribution of cosmopolitan binaries: https://github.com/csdvrx/cosmopolinux
My idea was to replace the WSL binaries to have a Linux distribution living on C:\, but that could also be booted baremetal if you didn't want to use Windows
I had to put together a multi stage init system for that: if you get the ISO, you can put in on a thumbdrive and boot it: https://gitlab.com/csdvrx/cosmopolinux
The only difference between them is the kernel and the filesystem: the github NTFS has a firecracker linux kernel, the gitlab ISO has a regular kernel with many modules.
I wanted to do a full NTFS solution but I couldn't find a bootloader I liked that would support booting from a NTFS partition.
Booting from an ISO was simpler and faster.
Could you stick the Linux kernel and initramfs on the EFI boot partition as a UKI, and then just tell it about its rootfs being on the NTFS C drive? You don't really need any bootloader except the firmware's UEFI implementation on most modern PCs, and Linux supports NTFS.
I considered that, even if it would go against the idea of having everything inside the Windows partition. I'd rather have had a shim in the EFI, with the UKI in C:\
The difficulty was bitlocker: my approach was a UKI with a small kernel and a few binaries to open the bitlocker volume and kexec the bigger kernel.
I was also exploring how to mark part of the NTFS volume as unusable to stick a different payload there.
The "ISO on a thumbdrive" was done to get baremetal boot working and out of the way, to see if I needed deeper changes to what had started as a 2 stages boot process, or if it was good enough as-as.
> Linux supports NTFS.
The kernel module is great!
I wish there was a linux distribution that could be run from either WSL or baremetal, to get more people familiar with baremetal linux.
Why not do that from the initramfs with the real kernel? I'm pretty sure that's how it works on a normal encrypted root Linux install
With something like a chainloader using a special part of the NTFS partition posing as bad blocks, Windows could "remove" this access easily, without having to touch the EFI partition or the boot variables.
Obviously since this is open source, then I can self host it. What other reasons?
Just curious!
Awesome tech, excited to dig deeper for healthcare
We did notice the unikernel cloud instances don't run into bot detection as often as our hosted docker instances, but I think that's mostly because Cloudflare haven't flagged Unikraft Cloud's IPs yet, hah.
Either way thanks for sharing.