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.
Thread beginning with comment 551774
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE: Sandboxing
by Soulbender on Thu 7th Feb 2013 09:24 UTC in reply to "Sandboxing"
Soulbender
Member since:
2005-08-18

I wonder what this will do that http://0install.net doesn't?


Yeah, I was thinking the same (actually, I think that every time someone comes up with yet another contained distribution method but I digress..). 0install is rather neat and is by now pretty mature and stable.
NIH maybe?

Reply Parent Score: 3

RE[2]: Sandboxing
by oiaohm on Thu 7th Feb 2013 11:53 in reply to "RE: Sandboxing"
oiaohm Member since:
2009-05-30

"I wonder what this will do that http://0install.net doesn't?


Yeah, I was thinking the same (actually, I think that every time someone comes up with yet another contained distribution method but I digress..). 0install is rather neat and is by now pretty mature and stable.
NIH maybe?
"

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

cgroups the filesystem namespace allows /opt/bundle to contain each individual application files. Yes each application bundle what is in the directory /opt/bundle is different and owns to them. So packages applications can use static paths to their resources and libraries. Oinstall applications are forced to use dynamic paths.

Cgroups also it allows live tracking by default if an application is running and absolute termination of program and every program it started. Also provide resource access limits even hide other running processes on the system from the application. All with quite min overheads.

Yes the fact each running application in this package management cannot see each other. This is again different to 0install.

Oinstall does have higher overhead than using the kernel built in feature of cgroups.

http://people.gnome.org/~alexl/glick2/ yes have a good read Soulbender. It does quite a few things better than 0install in design.

Thing is this gnome option is never going to be portable to other platforms out side something Linux..

The cgroup file system alteration features did not exist when Oinstall was invented.

You might call this a tech updated Oinstall that has the option of integrating better and support building most existing Linux applications without require source code alteration. Again lot of applications with 0install requirement for dynamic prefix require quite major alterations to work with 0install.

In fact the warping that Glick2 is doing in theory could allow you to cgroup a completely different distribution to install there applications.

Reply Parent Score: 4

RE[3]: Sandboxing
by Tom5 on Thu 7th Feb 2013 13:35 in reply to "RE[2]: Sandboxing"
Tom5 Member since:
2005-09-17

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 http://example.com/app.xml --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

RE[3]: Sandboxing
by Soulbender on Fri 8th Feb 2013 02:15 in reply to "RE[2]: Sandboxing"
Soulbender Member since:
2005-08-18

That's pretty neat (for Linux users) but I don't see why this can't be implemented as an optional feature of 0install.

Reply Parent Score: 3