Re: Sandboxed Gnome apps

[Alexander Larsson <alexl redhat com>]

On tor, 2014-09-04 at 14:39 -0700, Christian Hergert wrote:
> On 09/04/2014 10:05 AM, Alexander Larsson wrote:
> > I don't necessarily agree to the use of btrfs[1] for the images, but
> > otherwise I think this is generally the right approach for desktop
> > apps. However, in order to actually be useful for desktop apps there
> > is a lot more work required. I've recently started looking at what
> > Gnome needs to do here, and wanted to start a discussion about this.
>
> I rather like it, but we should definitely consider whether or not we
> need to care about *BSD's, and the availability of Btrfs.

Well, in the end the full sandboxing solution will have hard
dependencies like namespaces, kdbus and wayland which may be hard on
BSD. That said, much of the work done here on defining the platform
could easily be reused for a similar system on the BSDs.

> > 3. A SDK and other tooling
> >
> > There needs to be an easy way to build an application against the 
> > gnome runtime. This means we need to ship a SDK with all the
> > development stuff for the runtime (headers, symbols, debug info), as
> > well as tooling to make it easy to use those without risking any
> > contamination from the host. We also want to have tooling to make it
> > easier to bundle libraries, as we don't want every app author to have
> > to package everything from scratch.
>
> I hope to be able to use this from Builder.
>
> Especially if it is available via OSTree. I imagine a dialog in Builder
> to manage your local SDK's, and downloading the updates trivially.
> (Android SDK has this too). This will allow me to get things setup in a
> VM/Simulator so that developers can test against multiple runtime.

I think it will work very similar to how the apps themselves work. So,
we would have some kind of wrapper that you run, specifying a command to
run, except it will be run inside the chrooted tree with the SDK /usr. 
So you'll do something like "gnome-sdk make -j8" and it would compile
your app with /usr coming from the sdk.

> > I've recently started looking at how 1-3 could be done. I've
> > experimented with openembedded which is a very nice way to do cross
> > compilation that also lets you create SDK. However, some of stuff, in
> > particular gobject-introspection is very tricky to do right when cross
> > compiling. I've now changed over to the mixed model that
> > gnome-continuos is using where openembedded is used to build a base
> > containing the build environment, and the rest is built in a chroot.
>
> You've seen Yocto w/ meta-gir?

I saw it, but never tried it. Just reading the explanation of how it
worked was scary enough. We generally don't *need* cross compilation, so
why suffer all this pain to get it?

> > We need to start looking into exactly what the runtime should include
> > though. Obviously it should contain glib, gtk+ and the gnome platform,
> > but we also need to pick the lower level dependencies (glibc, X, etc)
> > as well as some level of standard unix tools.
>
> Is there any sort of "dependency" chain here? Were there is something
> like a reduced LSB for the core utilities so our runtime, and KDE's, and
> others need not all share this effort?

I can definately imaginge a freedesktop runtime that just ships X libs,
mesa, dbus and maybe SDL. That would be a great fit for e.g. games.
Could we reuse that image to base ours on? Perhaps...

> > There are also lots of technical issues. For instance how do we ship
> > mesa and DRI drivers which have dependencies on the kernel part of the
> > driver? How do we support e.g. the nvidia drivers in this? Do we need
> > some kind of overlay for the runtime image for local hardware drivers?
>
> Do we ship those in our Runtime, or is our runtime simply laid over the
> core platform?

I don't know how this would work. It needs more research.