On 21/07/15 00:11, Owen Taylor wrote: > We could theoretically address 2 by having our standard test setup > to run in a VM, but a lot of aspects of the system don't test well > in a VM - touchscreen input, multimonitor, networking UI, sound, etc.
VMs do have the advantage that they are definitely a trust boundary: running a branch of some component in a VM does not require you to trust that branch with all your data, credentials and so on. Test uids and VT-switching have the same advantages, but only work for the user session, not for system components like NetworkManager. Containers are not (in general) an answer to this, because my understanding of the state of the art is that containers don't really contain: root in a container can usually escape. So they're OK for the same use-cases where test uids work, and additionally they can virtualize system-level libraries like a chroot would (e.g. to have a newer GLib in your container without playing with LD_LIBRARY_PATH), but they don't help for the NetworkManager use-case. I personally try to stick to VMs or test uids for anything that isn't either something I can reasonably audit myself, or a supported release of my preferred OS distribution (in my case Debian, where the responsibilities of a package maintainer are meant to include checking new versions for malicious changes). Throwaway virtual machines (qemu with kvm, running from an image on a tmpfs), on a laptop with all the RAM, are a wonderful thing. Accidentally broke the whole system with an ill-considered packaging change? Delete it, copy your clean vmdebootstrap image back into the tmpfs, try again... using an emulated serial console for developer access and a shared directory for file transfer is particularly powerful. I recognise that this approach has limitations that make it unsuitable for many GNOME developers, though: I'm lucky in that I mostly work on plumbing and OS-building rather than hardware integration. -- Simon McVittie Collabora Ltd. <http://www.collabora.com/> _______________________________________________ desktop-devel-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/desktop-devel-list
