Show HN: We Put Chromium on a Unikernel (OSS Apache 2.0)

I just wanna say the Dagger shell syntax is incredibly cool and I look forward to playing with it. I would not complain if you posted such self-promotional comments on any thread where it’s relevant because it goes to show the flexibility of the thing.

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.

How does fast-cold-start help here? What use cases did it enable that were previously not possible with a warm pool of Docker containers?

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

You would have to add support for the peripherals in the kernel, and have some kind of init system. You would also need a filesystem supported to boot the computer.

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.

Yeah, this is mostly just an OSS implementation for self-hosting! I'm not entirely sure what any of those companies use under the hood, in theory they could use this implementation if they wanted to gain the fast boot times, session reuse etc.

Thank you!

Thank you! Yeah, the current implementation basically performs the same as a Docker container (i.e. not much). The interface is the same, so you can use BU/Playwright/Puppeteer's header configs to change as needed.

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.

Why detect "bots" when you can block them using captchas/proof-of-work solutions. Curious to know your use case for detecting bots.

From what we've seen, micro VMs could probably do something very fast too (150ms?) but we thought 20ms was pretty crazy.

It snapshots / pauses the entire unikernel instance after launching chromium, and then resumes the instance in <20ms with exactly the same state.

Yeah, there are some nuances to Unikraft Cloud that their team did to get it running. I'll see if they can chime in and shed some light!

Haven't tried on a Lambda. Would be curious to know the results if you do!

It took us 8gb to get it up - maybe could be slimmed down if you took out the Anthropic Computer Use components, but browsers generally are pretty heavy.

Thank you!