Live data from Hacker News

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

github.com

31–40 of 47 posts

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

#31
post #4

Earlier quoted context omitted.

Thank you!

why is the price bracket so weird? pro/10 gives each user less than half what individual plans would. It's almost like an attempt to dissuade pro purchases. Are there additional tooling you are not mentioning in the comparison?

Are you referring to Unikraft Cloud's pricing? I'm not really sure, since I'm not affiliated. Maybe they'll chime in

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

#32
post #24

What’s the size of the image? Can this run inside a Lambda?

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.

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

#33
post #26

When should I use this versus Browserbase or Browserless or Hyperbrowser? Obviously since this is open source, then I can self host it. What other reasons? Just curious!

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.

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

#34
post #20

Earlier quoted context omitted.

> Could you stick the Linux kernel and initramfs on the EFI boot partition as a UKI 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…

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

I wanted to limit the space needed on the EFI, and keep as much as possible on the Windows partition because there's also the question of where the bitlocker key would go.

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.

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

#35
post #7

This looks excellent, and very fun to play with! 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' Be aware that the initial docker build is quite long... But caching kicks in for subsequent runs. I look forward to pla…

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 ver…

Thank you, I appreciate that!

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.

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

#36
post #35

Earlier quoted context omitted.

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 ver…

Thank you, I appreciate that! 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 t…

Except in this case they are just running a linux payload - that which pretty much any firecracker provider could do.

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

#37

Earlier quoted context omitted.

> 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 hardw…

What about incus? Could incus provide some benefits as the host?

Depends on the application. These unikernel applications are best suited for short lived compute for web applications that need to fire up fast and live for the duration of the users session. Though perhaps it could be beneficial in situations where it could provide determinism with direct hardware access. Security wise I believe you're better off with an OS, better mechanisms and tested security models.

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

#38

This is probably a dumb question from someone who knows almost nothing about system engineering. How hard would it be to boot a computer to this as an OS?

> 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 hardw…

> Unikernels aren't meant to run as a bare metal OS on a standard computer like a PC.

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.

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

#39
post #10

Cool (and congrats on the demo)! Sounds like a promising approach. I work on browser use agents and one of the most difficult problems now is bot detection. Curious if you know how this impacts bot detection/fingerprinting?

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

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

#40
post #2

(OP) Happy to answer any questions! Some things we're still exploring: - 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 does fast-cold-start help here? What use cases did it enable that were previously not possible with a warm pool of Docker containers?
Post reply on HN