Re: How do you hack on GNOME? How can we do better?

[Simon McVittie <simon mcvittie collabora co uk>]

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/>