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

On Tue, 2015-07-21 at 12:22 +0100, Simon McVittie wrote:
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, 

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.

This only works, of course, if your *builds* are also inside the
virtual machine, or are effectively sandboxed.

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 think we're pretty good with LD_LIBRARY_PATH these days. The main
advantage of a container over a separate UID is that it potentially
allows testing new versions system-level services. But you have to make
the services work inside a container, which is non-trivial.

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).

Hmm, I have some strong doubts about packagers as a reliable line of
defense against malicious code - especially since malicious code could
be very subtle. But yes, there is an advantage not having everything
that is committed to git immediately having full access to developer's
user accounts. A goal to shoot for.

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 

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 

Do you build in the VM or outside the VM?

- Owen

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]