Re: Sandboxed Gnome apps

[Bastien Nocera <hadess hadess net>]

On Thu, 2014-09-04 at 19:05 +0200, Alexander Larsson wrote:
> I guess by now most people have seen lennarts latest post on how to
> build linux systems:
>
>
> http://0pointer.net/blog/revisiting-how-we-put-together-linux-systems.html
<snip>
> So, what does Gnome need to provide here?
>
> 1. A platform definition
<snip>
> 2. A reference implementation
<snip>
> 3. A SDK and other tooling
<snip>
For 1), 2) and 3), and at the risk of causing a flamewar, couldn't we
rely on packages from a distribution to bundle those?

I could imagine rather trivially creating images from Fedora for
example, so that the GNOME project doesn't have to take care of tracking
NSS, glibc or Mesa (as you mentioned later).

Whichever platform we end up building from, we probably don't want to do
the building of those parts ourselves, with all the security,
trackability and reproducibility that we would need to implement to take
care of this.

> 4. IPC stability guarantees
>
>    In theory we can put any kind of library in the runtime, as we rely
>    on the global version of the runtime itself to keep applications
>    running if API or ABI change. (Although we should of course try to
>    minimize such breaks.) However, any kind of IPC mechanism we include
>    in the runtime must have very strict backwards compatible
>    requirements.
>
>    Historically we have not done very well here. For instance, the GVfs
>    dbus interfaces have generally been tightly coupled with the client
>    libraries, such that you have to update both in lockstep. With an
>    "app" based setup we have to take backwards compatibility much more  
>    seriously, across the board. 
>
>    This is not a code delivery, but rather a change in mentality that
>    we as a project have to accept.

I don't understand the problem with gvfs. gvfs would be at the same
level as GIO or glib, and the clients would only see the public GIO API,
nothing outside it.

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

Why do we care about cross-compiling? For all the platforms we might
want to target (that's the 32-bit and 64-bit variants of x86 and ARM),
there are already machines that are fast enough to build natively.
That's what Fedora does, and that's probably good enough.

> Hopefully I will have some initial cut of a runtime based on
> gnome-continuos some time next week. This will give us a runtime, but
> also a lot of stuff that can be used to make the SDK.

This will give us a runtime that's not easily reproducible or trackable.

> 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.
>
> For instance:
>  * Do we ship a shell interpreter so that shell scripts work?
>  * What standard unix tools do we ship? cp? ps? ship? awk? sed?
>  * What about language runtimes? gjs? pyton2? python3? perl5?
>  * Some of our development stack is of lower quality than the core
>    platform. How much of it do we want to ship? On one hand we
>    can put whatever in the runtime and have the runtime versioning
>    protect against stability issues, on the other hand we'll may be
>    giving application developers false hope wrt the quality and
>    stability of some code, as well as setting us up for long-term
>    maintainance and security fixes for all those libraries.
>  * What about things like plugins like gstreamer? We'll ship some 
>    in the runtime, and if the app needs a particular new one it can
>    bundle it. But it would also be nice if the user can side-load
>    things into a specific runtime. Maybe we need extra local layers on
>    top of the runtime?
>
> 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?

That's also something I mentioned to Lennart and David Airlie. I don't
think there are that many interdependencies between the kernel and Mesa
when it comes to normal usage, but the runtime providers updating Mesa
will be a requirement to having new hardware supported.

> Well, this was a lot of text from my side with nothing practicaly
> useful yet. I think its good to get people started thinking about these
> things though, and I'll keep people updated as I make progress actually
> building something.

My advice is, as for the test ISO images where we scrub Fedora branding
out of the images, to use an established distro to base our reference
image and SDK. I don't particularly mind if it's Fedora, Debian or
something else, those who do the work will get to choose :)

Cheers