Daniel Berrangé

glibc has really good backward compatibility. But, yeah, few other libraries even bother, let alone make a serious attempt at this. One of the major exceptions is libvirt, which promised 100% backward compatibility from day 1. Here's a great overview (2011) of how they accomplish that: https://www.berrange.com/posts/2011/01/13/versioning-in-the-libvirt-li… Note that it wasn't until GCC 10 (2020) that you could implement ELF symbol versioning without using an ugly inline asm hack in your function definition. From the GCC 10 release notes at https://gcc.gnu.org/gcc-10/changes.html: > The symver attribute can be used to bind symbols to specific version nodes on ELF platforms. This is preferred to using inline assembly with GNU as symver directive because the latter is not compatible with link-time optimizations. In combination with confusion around the differences between file suffix versioning, soname versioning, and symbol versioning, it's not surprising few developers even attempt to get this right. OTOH, most ABI breakages are because of dumb mistakes early on or gratuitous changes to the API. If you commit to API stability from the beginning, then ABI stability can and will come more naturally, at least for C code. Versioning of any sort becomes less complicated and even less important.[1] C++ is different because of how heavily header-defined templates are used these days. [1] In other words, if you think API and ABI stability is principally a question of…

1. "Testing: Termux, vmtest, and QEMU": https://gist.github.com/NoteAfterNote/7614b0137ac6959e3bba35df66eaa75a (gist.github.com/NoteAfterNote/7614b0137ac6959e3bba35df66eaa75a) 2. "The surprisingly complicated world of disk image sizes": https://www.berrange.com/posts/2017/02/10/the-surprisingly-complicated… (www.berrange.com/posts/2017/02/10/the-surprisingly-complicated-world-of-disk-image-sizes/)

Or Fedora: https://www.berrange.com/posts/2012/11/30/installing-fedora-17-arm-on-… Or countless other Linux distros.

Your web browser is designed to sandbox and safely run code. Your shell isn't. (People are working on it though, see for example http://berrange.com/posts/2012/01/17/building-application-sandboxes-wi…

Libvirt is not needed to use KVM but the purpose has been to provide stability (and an abstraction as you mentioned) over the changes QEMU has had in various releases. Update: Here's a blog related to your very question that was written just a few days ago: http://berrange.com/posts/2011/06/07/what-benefits-does-libvirt-offer-…

> I am intimately familiar with eWLM and I think it's quite unfair to call it containers. I feel like you're strawmanning me, here. I specifically avoided calling WLM "containers." I said they're building blocks that, combined with MAC-style service isolation (which also existed on 1980s mainframes), allow containerized isolation of consolidated services on a single OS image. It also wouldn't be fair to directly call cgroups "containers," though they provide similar building blocks for what I'm sure we agree are "containers" once configured by a tool like LXC. I compared WLM to cgroups because both track utilization over a window of time and manage scheduling in a way that avoids starvation while enforcing other priority or fairness goals. The documented resource limitation and contention-sharing configurations for WLM [1] are undeniably similar to cgroups. > I'll give you a simple example. Do dd if=/dev/sda of=foo.img (or even /dev/null) in one container and measure I/O performance in the other. Linux kernel cgroups have supported block I/O limits and weights for fair sharing under contention since 2008. I'll give you the benefit of the doubt here, though, and assume you're actually trying to provide an example of breaking the page cache because you mention that immediately afterward. > The page cache is a global resource and so far there is not way to isolate it within containers. Buffered I/O is pretty fundamental to all workloads. Shared page caching among…

> Workload Manager (WLM) [1] has been a part of IBM z/OS since before it was even called z/OS. WLM implemented something like cgroups scheduling, in that existing utilization samples feed into future scheduling to ensure responsiveness and fair access to resources under contention. I am intimately familiar with eWLM and I think it's quite unfair to call it containers. > It's your turn to provide some citations. You could argue that the Linux kernel has failed to achieve good multi-tenancy support, but saying it hasn't been designed for multi-tenancy just makes you look ignorant of the last five years of development on namespaces, cgroups, and general multiprocess resource scheduling. I'll give you a simple example. Do dd if=/dev/sda of=foo.img (or even /dev/null) in one container and measure I/O performance in the other. The page cache is a global resource and so far there is not way to isolate it within containers. Buffered I/O is pretty fundamental to all workloads. >> I'm quite sure it's not faster than virtualization. > > Citation needed, especially since you're arguing that more layers of abstraction (kernel + hypervisor + kernel) is at or above the same speed of fewer (kernel + cgroups/namespaces). cgroups aren't free. See https://www.berrange.com/posts/2013/05/13/a-new-configurable-cgroups-l… I already cited a widely published benchmark (SpecVIRT). You article cites made up numbers (5-10 minutes to provision a guest). $…