Maybe a good halfway point is to still have a unikernel but the libraries for common stuff like networking or fs are already written according to a standard and plug and play and reusable across applications?
The point that makes this different from an OS is that there's no shared service, no syscalls to do that stuff -- just subroutine calls -- and no timesharing (except at the hypervisor level). It's just a single runtime running on hypervisor direct against the virtualized hardware.
Because, yeah, all this work has happened in hardware in the last 30 years to make that possible, but we still treat the operating system as the best unit of resource sharing. When in fact it's kind of a jack of all trades master of none. If you're booting a whole linux kernel -- with its giant framework built to co-tenant a pile of applications and users -- just to run one process, there's definitely something to look at there. Even if the unikernel space itself is relatively immature.
You don't need to emphasize the "vibe coded every time you need them" thing. That's not what anybody was being talked about in the article. The "vibe coding" piece is pointing out that the missing pieces in the ecosystem can be more rapidly filled in now because of agentic tooling.
I used to regard V8 Isolates as a best possible sort of technology, with userlands juggling lots of processes.
Seeing netlify & unikraft switch to microvm's and have such a huge speed up was a bit of an awakening for me. Those are really fast start times! https://www.netlify.com/blog/edge-functions-firecracker-micr... https://unikraft.com/customer-stories/edge-functions-netlify...
Intuitively, I think I have some appreciation for how much silicon has been poured into virtualization. Its always seemed like a "yeah but you could avoid those costs by not doing that" but I'm more receptive to the idea that these might in some cases be really good ways to get some of the isolation workloads demand with the hardware helping us out, these days. There's so much securing for vm's, and maybe it's just easier than trying to secure in userlands: let the hardware help.
Long time interest in microvm's but they felt heavier weight than I wanted. Now it feels like maybe they might actually in some regards in some ways be lighter weight than managing workloads yourself in userland. Maybe. I dunno. Interesting times, i'm open to it.
I'd wager most of the services running on the interwebs are web servers, database servers, inference servers etc that don't change over their lifetime really. They're just doing the same thing all day long every day.
If you're doing stuff like what I'm doing for work right now, which is, yeah, multiplexing potentially oodles of user-submitted jobs, and those jobs are best expressed as distinct images or containers, then yes, managing start times is absolutely imperative in improving utilization/occupancy and therefore reducing costs.
But I'm not convinced that's a typical scenario, not typical enough to drive enough time and money investment in this space maybe?
Also there ain't currently no real "hypervisor" for the (NVIDIA) GPU. Not practically anyways. And that's arguably where we need it the most. Or at least I do, for Day Job(tm).
So unikernels and microvms may have to lean on other arguments for adoption: security and simplicity-to-reason-about might be those...
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
You could make the argument that Rust w/ its memory safety is a candidate, but w/ Rust it's still entirely possible and fairly easy to break out of that. And Rust/Cargo applications have a habit of using a bazillion third party deps that you then need to keep a close eye on.
eyberg•4h ago
That's why I never really liked talking about "reducing attack surface" that much because folk inevitably turn to lines and code, which while reducing is good, just simply doesn't communicate what the biggest problem truly is.
Vuln exploitation is the number one entry point for data breaches and os command injection is the number one CWE in CISA Kev from last year.
System intrusion was repeated something like 64 times in last year's DBIR.
The operating system itself is literally the problem as it's inherently meant to run many different programs whereas unikernels only run one.
fsflover•51m ago
Unless you rely on security through compartmentalization. See: https://qubes-os.org