Live data from Hacker News

Cloud Virtualization: Red Hat, AWS Firecracker, and Ubicloud internals

ubicloud.com

11–17 of 17 posts

Re: Cloud Virtualization: Red Hat, AWS Firecracker, and Ubicloud internals

#11
post #10

Author of "All you need to know about KVM userspace" here! I am happy that you liked it. Some things have changed since then, some have not... Red Hat is now shipping Kata Containers, which does not (much to my dismay) use Libvirt, and also KubeVirt which uses Libvirt but not for sandboxing (only to drive QEMU; Kubernetes takes care of the sandboxing by running one VM per pod). But the original architecture is still…

Thank you Paolo — for what was an excellent post, and also for this helpful update!

Re: Cloud Virtualization: Red Hat, AWS Firecracker, and Ubicloud internals

#12

Earlier quoted context omitted.

May you live in interesting times.

Is there an actual underlying message to this or is this just wordplay? Don't know much about Ruby, but what I do know doesn't suggest it would make our (already all too "interesting") times even more "interesting".

It's an infamous quote: https://en.wikipedia.org/wiki/May_you_live_in_interesting_ti... and likely GP means it due to the yolo attitude of many ruby projects

Re: Cloud Virtualization: Red Hat, AWS Firecracker, and Ubicloud internals

#15
post #10

Author of "All you need to know about KVM userspace" here! I am happy that you liked it. Some things have changed since then, some have not... Red Hat is now shipping Kata Containers, which does not (much to my dismay) use Libvirt, and also KubeVirt which uses Libvirt but not for sandboxing (only to drive QEMU; Kubernetes takes care of the sandboxing by running one VM per pod). But the original architecture is still…

I've become a huge fan of incus as of late. I do wish it had more out of the box support for some of the firecracker/microvm qemu workflows

Re: Cloud Virtualization: Red Hat, AWS Firecracker, and Ubicloud internals

#17
post #4

Ubicloud is built on Ruby, interesting take for 2025.

The Ruby we write is quite strange by the normal reckoning. In particular, it has 100% branch coverage. Being able to do this affordably is one reason I use it.

A fair number of the dependencies we have also have 100% branch coverage, because I copied the practice, starting about ten years ago, from Jeremy Evans, who maintains a huge number of libraries under that principle. That includes "Sequel," the ORM that I've used for many years and originally copied the practice from, around 2015. You can see the libraries he maintains in this way: http://code.jeremyevans.net/ruby.html. He has joined Ubicloud somewhat recently, so I look forward to getting a sense of how he completes the rest of his rather singular & extraordinary maintenance regime.

To have Ubicloud rest at this standard is my objective. My tendentious claim is as follows: this is higher than any other constellation of libraries I have seen in any programming language. If anyone knows of any constellation of libraries that is more capably and rigorously maintained in any language, let me know. The bar as roughly as follows they need to release every month, or something like that (yes really: https://rubygems.org/gems/sequel/versions/), have a wide interface with your program, and break it no more than once every five years.

It's also not a Rails program, and I have never written or maintained a Rails program in any seriousness, which makes me an odd duck among longtime Ruby programmers.

Post reply on HN