Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- I generally agree Unikernels are cool as I did back in 2010 when I first came across the idea. But the idea that RCE are contained because there is no shell and no interpreter does not hold up. If they can run code on the machine they can run a compiler in your unikernel and device drivers and whatever else they will need. Granted it's much harder to do all these things through the straw of a RCE bug, but the argument that because the tools are not there they can't do damage is wrong their malicious code was not there either but they found a way to bring it in.
- > I think dependent types are the winner for next-generation languages. Anything that lets you codify more into the type system is more back pressure.
This is one reason I'm so bullish on Lean4 as a general programming language
It's now essentially proven that expressive, strong type systems like those of Rust present an advantage for LLM assisted coding
Lean's type system, in which types are first class, fully programmable objects takes it so much further. Particularly when it comes to embracing dependant types
by nylonstrung - As mentioned before on this topic. What about debug ability? An application overflow now corrupts part of the network stack.
In an oxide episode there were some mentions of reading off data lines but I just don’t think that’s practical.
The reduced attack service is cool but not at the expense of my visibility and liveness of the system
by vsgherzi - If you have serious attack surface minimisation goals you need to embrace FOGAs. LLM coded unikernels have way too much bloat.
The Zynq UltraScale+ parts pair a hard ARM CPU with FPGA fabric. You can progressively isolate fast path and high security components in logic. LLMs are getting quite good at using synthesis tools.
https://www.amd.com/en/products/system-on-modules/kria/k26/k...
by angry_octet - It’s good to see this! I’m offering a cloud service to host unikernels based on my BareMetal kernel.
~$0.005 CAD/h for a small network-enabled VM with 4MiB of RAM and no disk.
by ianseyler - General purpose OSses are a tax, one that people pay because it's cheaper than rolling your own.
Has the math changed? Maybe. I remember the days before multitasking and protected memory. Things were faster, but more fragile. But these days there are so many things happening that they are, on some dimensions, just as fragile.
The real cost is going to be hardening, and maybe LLMs can do that as well.
by mannyv - I've had limited adventures in embedded software and as part of that became a fan of Zephyr (http://www.zephyrproject.org) and wonder about its potential application as a unikernel.
On the plus side: it's a unikernel. You compile it and your application together and get a binary. It has support for running on virtual hardware (https://docs.zephyrproject.org/latest/hardware/virtualizatio...) and virtio is the new bios, right?
On the minus side: I think porting "traditional" software - say Nginx - to it will be agonising. And I can't make any guarantees about its performance in the same way that Alpine Linux container images are not necessarily fast.
But there's an entire toolchain, debugging story, drivers etc. for something that compiles to tiny and starts up basically instantaneously. Surely that's got to be useful for something?
by RantyDave - This is the second unikernel article this week I think, and the second that really undersells the benefits of having a full OS. Let's just swap out a couple of words:
> With a unikernel, the [observability] surface is much smaller. If the functionality isn't in the application (the operating system), then the [SRE] is screwed. There's no next hop.
Tools such as `strace`, eBPF, `lsof`, `ss`, etc. have tremendous value. The article mentions some nice things for observability ("structured logging, OTel") but so much gets thrown away.
by scottlamb