<- Back
Comments (111)
- m132Projects 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?
- mustache_kimonoBryan Cantrill, "Unikernels are unfit for production". [0][0]: https://www.tritondatacenter.com/blog/unikernels-are-unfit-f...
- droelfI've been using unikraft (https://unikraft.org/) unikernels for a while and the startup times are quite impressive (easily sub-second for our Rust application).
- lacooljI 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 :\
- gnabgib(2020) Currently, seems to have been around since 2011 (https://news.ycombinator.com/item?id=3288786) although at a few different domains (torokernel.org, torokernel.io)
- richardwhiukI wonder how it compares to https://mirage.io/
- cmrdporcupineIt's written in... Pascal...Neat.
- raggiI 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.
- spacecadet404What's the use case for this rather than containers? Separation from the hypervisor kernel?
- AlifatiskSo this is like nanos.org ?
- agentifyshGreat work. one feedback would be to add Why Toro? to readme.What use cases would Toro fit? pros and cons ?
- m00dyit is using qemu's network stack, would like to know how performant it is.
- itsthecourierreminds me of actors, they are sharing messages between kernels with a busfile sharing is complex too it seemswould be good to see a benchmark or something showing where it shines