Linked by Thom Holwerda on Wed 6th Feb 2013 12:29 UTC, submitted by Anonymous
Gnome "Some GNOME developers are planning to implement an app format that allows developers to provide their Linux programs in distribution-independent files that can be installed as easily as smartphone apps. A sandbox model is supposed to isolate the apps from each other, and from the rest of the system, in a way that goes further than the isolation in current Linux distributions. Various developers worked to conceptualise such "Linux apps" at the GNOME Developer Experience Hackfest, which was held in the run-up to FOSDEM 2013 in Brussels. At the hackfest, the GNOME developers also declared JavaScript as the de-facto standard for GNOME programming." Right, because they haven't alienated enough of their users.
Permalink for comment 551794
To read all comments associated with this story, please click here.
RE[3]: Sandboxing
by Tom5 on Thu 7th Feb 2013 13:35 UTC in reply to "RE[2]: Sandboxing"
Member since:

0install is not using cgroups feature of the Linux kernel. The new one is using cgroups. This does make some major differences in implementation.

Thanks for the comments! I think these might fit together quite nicely though...

0install's job is to download the various packages needed to run an application, check digital signatures, handle dependencies, upgrades, roll-back, etc. The output is the set of downloaded packages and how to link them together. Normally, that's by setting environment variables, because that works everywhere. For example, a Python library might ask for its directory to be added to the application's PYTHONPATH.

But 0install can also output other kinds of bindings, such as the "overlay" binding (which says that a package should appear at a particular point in the file-system, such as /opt).

If you have a cgroups-based sandbox that can support this then you can just connect them together something like this:

0install download --xml | cgroups-sandbox

(that selects and downloads all packages needed to run this app, and then outputs the required bindings as XML, ready for use by other tools)

The EBox demo I linked above, for example, does something like this at the level of the programming language, making the required modules appear in the application's namespace.

Of course, a system based on cgroups won't work on the BSDs, on Windows, on OS X, etc. I'd imagine that most GNOME applications would want to support at least one of those. So if hard coded paths are unavoidable, you'd need to implement an alternative to the cgroups thing for each platform (but it GNOME will need to do that anyway).

Reply Parent Score: 3