10 ms·
Toro: Deploy Applications as Unikernels
- itsthecourier 10mo agoreminds me of actors, they are sharing messages between kernels with a bus file sharing is complex too it seems would be good to see a benchmark or something showing where it shines
- Imustaskforhelp 10mo agoI think one reason UniKernels can be different are perhaps that they can allow more isolation or run user generated code perhaps inside the Unikernel with proper isolation whereas I don't think actors can do that
- cmrdporcupine 10mo agoIt's written in... Pascal... Neat.
- giancarlostoro 10mo agoMy last name is finally on the front page of HN as a project name, look mah! I was not expecting Pascal, thats an interesting choice. One thing I do like is that Freepascal has one of the better ways of making GUIs meanwhile every other language had decided that just letting Javascript build UIs is the way.
- lacoolj 10mo agoOh holy crap that's actually super cool. One of the first languages I (tried to) learn ... at 13. And failed. Now I write Javascript and SQL. :)
- AceJohnny2 10mo agoyay no C strings!
- gnabgib 10mo ago(2020) Currently, seems to have been around since 2011 (https://news.ycombinator.com/item?id=3288786 https://news.ycombinator.com/item?id=3288786) although at a few different domains (torokernel.org, torokernel.io)
- mvaralar 10mo agoToro started in 2006 more or less. I lost the .org domain so I had to move to the .io.
- spacecadet404 10mo agoWhat's the use case for this rather than containers? Separation from the hypervisor kernel?
- eru 10mo agoIt can be much faster, and much smaller surface area for attacks than using a full Linux kernel.
- Imustaskforhelp 10mo agoContainers (docker/podman) are still not as secure as virtualization (qemu,kvm,proxmox) Plus these might be smaller and might run faster than containers too.
- m00dy 10mo agoyeah it's a fairy tale.
- throwaway894345 10mo agoSmaller than containers seems unlikely since a container doesn't have any kernel at all, while these microvms have to reproduce at least the amount of kernel they would otherwise need (e.g., a networking stack). I'm sure some will be inclined to compare an optimized microvm to an application binary slapped into an Ubuntu container image, but that's obviously apples/oranges. Faster might be possible without the context switching between kernel and app? And maybe additional opportunities for the compiler to optimize the entire thing (e.g., LTO)?
- justatdotin 10mo agocontainer can be smaller at rest, but larger at runtime if you're not sure which you want its probably container
- ahepp 10mo agoPresumably to avoid the cost of context switches or copying between kernel/user address spaces? Looks to be the opposite of userspace networking like DPDK: kernel space application programming.
- richardwhiuk 10mo agoI wonder how it compares to https://mirage.io/ https://mirage.io/
- speed_spread 10mo agoIsn't Mirage OCaml only?
- cmrdporcupine 10mo agoAnd this one is Pascal. Choose your anachronisms. As much as I'm nostalgic about Pascal and my childhood... I'd personally prefer OCaml.
- mvaralar 10mo agoAs far as you provide the bindings, you can compile it with an application built in any language. There are in the repo a few examples with C programs.
- mustache_kimono 10mo agoBryan Cantrill, "Unikernels are unfit for production". [0] [0]: https://www.tritondatacenter.com/blog/unikernels-are-unfit-for-production https://www.tritondatacenter.com/blog/unikernels-are-unfit-f...
- wmf 10mo agoToro provides a GDB stub so there has been a little progress since that time.
- vigilans 10mo agoThere's a man who hasn't tried running qubes-mirage-firewall. Unikernels don't work for him; there are many of us who are very thankful for them.
- mustache_kimono 10mo ago> there are many of us who are very thankful for them. Why? Can you explain, in light of the article, and for those of us who may not be familiar with qubes-mirage-firewall, why?
- vigilans 10mo agoIn Qubes you use VMs to separate your banking environment from the one where you pull npm dependencies and the one where you open untrusted PDFs. Networking also happens in its own VM, and you can have multiple VMs dedicated to networking. Much lower memory footprint running mirage firewall, and an attack surface orders of magnitude smaller (compared to a VM running a Linux distribution purely for networking).
- cmrdporcupine 10mo agoCantrill is far smarter and accomplished than me, but this article feels a bit strawman and hit and run? I think unikernels potentially have their place, but as he points, they remain mostly untried, so that's fair. We should analyze why that is. On performance: I think the kernel makes many general assumptions that some specialized domains may want to short circuit entirely. In particular I am thinking how there's a whole body of research of database buffer pool management basically having elaborate work arounds for kernel virtual memory subsystme page management techniques, and I suspect there's wins there in unikernel world. Same likely goes for inference engines for LLMs. The Linux kernel is a general purpose utility optimizing for the entire range of "normal things" people do with their Linux machines. It naturally has to make compromises that might impact individual domains. That and startup times, big world of difference. Is it going to help people better sling silly old web pages and whatever it is people do with computers conventionally? Yeah, I'd expect not. On security, I don't think it's unreasonable or pure "security theatre" to go removing an attack surface entirely by simply not having it if you don't need it (no users, no passwords, no filesystem, whatever). I feel like he was a bit dismissive here? That is also the principle behind capability-passing security to some degree. I would hate to see people close the door on a whole world of potentials based on this kind of summary dismissal. I think people should be encouraged to explore this domain, at least in terms of research.
- droelf 10mo agoI've been using unikraft (https://unikraft.org/ https://unikraft.org/) unikernels for a while and the startup times are quite impressive (easily sub-second for our Rust application).
- ahepp 10mo agoWhat drove you to choose that over something like containers?
- m00dy 10mo agoshorter cold-boot times.
- ahepp 10mo agoIf we’re talking about cold boot times, wouldn’t the relevant metric for unikernels be the hypervisor’s boot time?
- zozbot234 10mo agoHow would that compare with containers running on Firecracker or other virtio-based μVM's?
- wmf 10mo agoA unikernel on Firecracker is probably going to start faster than a container on Linux on Firecracker.
- ahepp 10mo agoI assume they meant using an OCI image for the rootfs of a firecracker VM, not running a container inside a firecracker VM. Still difficult to see how the unikernel could be slower, but I doubt the difference would be huge? Don't have anything to back that up though.
- droelf 10mo ago
- m132 10mo agoProjects like this and Docker make me seriously wonder where software engineering is going. Don't get me wrong, I don't mean to criticize Docker or Toro in parcicular. It's the increasing dependency on such approaches that bothers me. Docker was conceived to solve the problem of things "working on my machine", and not anywhere else. This was generally caused by the differences in the configuration and versions of dependencies. Its approach was simple: bundle both of these together with the application in unified images, and deploy these images as atomic units. Somewhere along the lines however, the problem has mutated into "works on my container host". How is that possible? Turns out that with larger modular applications, the configuration and dependencies naturally demand separation. This results in them moving up a layer, in this case creating a network of inter-dependent containers that you now have to put together for the whole thing to start... and we're back to square one, with way more bloat in between. Now hardware virtualization. I like how AArch64 generalizes this: there are 4 levels of privilege baked into the architecture. Each has control over the lower and can call up the one immediately above to request a service. Simple. Let's narrow our focus to the lowest three: EL0 (classically the user space), EL1 (the kernel), EL2 (the hypervisor). EL0, in most operating systems, isn't capable of doing much on its own; its sole purpose is to do raw computation and request I/O from EL1. EL1, on the other hand, has the powers to directly talk to the hardware. Everyone is happy, until the complexity of EL1 grows out of control and becomes a huge attack surface, difficult to secure and easy to exploit from EL0. Not good. The naive solution? Go a level above, and create a layer that will constrain EL1, or actually, run multiple, per-application EL1s, and punch some holes through for them to still be able to do the job—create a hypervisor. But then, as those vaguely defined "holes", also called system calls and hyper calls, grow, won't so the attack surface? Or in other words, with the user space shifting to EL1, will our hypervisor become the operating system, just like docker-compose became a dynamic linker?
- kitd 10mo agoThis results in them moving up a layer, in this case creating a network of inter-dependent containers that you now have to put together for the whole thing to start... and we're back to square one, with way more bloat in between. I think you're over-egging the pudding. In reality, you're unlikely to use more than 2 types of container host (local dev and normal deployment maybe), so I think we've moved way beyond square 1. Config is normally very similar, just expressed differently, and being able to encapsulate dependencies removes a ton of headaches.
- m00dy 10mo agoit is using qemu's network stack, would like to know how performant it is.
- raggi 10mo agoI don't want the observability of my applications to be bound by themselves, it's kind of a real pain. I'm all for microvm images without excess dependencies, but coupling the kernel and diagnostic tools to rapidly developing application code can be a real nightmare as soon as the sun stops shining.
- lacoolj 10mo agoI use LXD + LXC, wondering if this is worth trying or if the overhead of accessing (network, etc) would be too much to deal with/care about. Also always a little wary of projects that have bad typos or grammar problems in a README - in particular on one of the headings (thought it's possible these are on purpose?). But that's just me :\
- mvaralar 10mo agoFeel free to submit a PR I will happily accept it.
- agentifysh 10mo agoGreat work. one feedback would be to add Why Toro? to readme. What use cases would Toro fit? pros and cons ?
- mvaralar 10mo agoI can add that. Thanks!
- Alifatisk 10mo agoSo this is like nanos.org ?