The First Fully-Sandboxed Linux Desktop App Is...

[phoronix]

Phoronix: The First Fully-Sandboxed Linux Desktop App Is...

The GNOME-aligned open-source crew working on sandboxing Linux applications has made progress and they do have their first application sandboxed...

http://www.phoronix.com/scan.php?page=news_item&px=Sandboxed-Linux-Apps-First

[skriticos]

His sound system seems to have been broken in the sandbox, the video was totally mute and he had to type the whole time! \s

Anyway, nice to see sandboxing on desktop progress. Does anyone know how portable/inter-operable this is with other desktops like KDE or Unity?

[justmy2cents]

wasn't gnome builder available for a while now? as sandbox preview i mean

and it needs to be said... AWESOME! hopefully we'll see one standard sandbox system instead of NIH

[justmy2cents]

His sound system seems to have been broken in the sandbox, the video was totally mute and he had to type the whole time! \s

Anyway, nice to see sandboxing on desktop progress. Does anyone know how portable/inter-operable this is with other desktops like KDE or Unity?

based that what was run was not Gnome app, it was run completely out of terminal and based that shell more or less provides standard desktop files. i'd say big chance for KDE, not so much for Unity since Wayland is one of requirements

i'd even go to say that terminal show was all about showing innards and interoperability with others

i might be wrong though (and sound worked in video for me)

[brk0_0]

Sorry to ask such a dumb question, but to what extent does this model (Runtimes + Apps) help with our problems on Linux desktop?

AFAIK, what we need is:

1. When we update Apps, they update their dependencies as they need, but without messing with other app's dependencies.
2. We need to make sure Apps only use dependencies they know about, so, if other machines have all listed dependencies installed, the app should work.
3. When a critical bug is found on the dependencies, old software shouldn't need to upgrade also (reducing the mantainence effort of developers, lowering the costs of app development).
4. We should be able to write an app once for various distros (various runtimes at once).

As far as I understand (and that's not much), item (1) is solved by the proposed model, since apps rely on runtimes (and we can have multiple runtime installed at the same time) or have bundled dependencies (which the devs are willing to update together with the app). Item (2) is, I believe, solved by the runtime model also, since apps are sandboxed and cannot access other libs that are not on the runtime.

But what about (3)?

Suppose we have a library called lib with versions v1.0 and v2.0. My app depends on v1.0 and I don't want to update my software anymore. Therefore, if users also have apps using lib v2.0, they must have v1.0 installed alongside v2.0). Now suppose we find a critical bug on all versions of lib. Then, lib's developers launch v1.1 and v2.1 with the fix.

How can I make sure my app upgrades to v1.1 (ABI/API stable, etc.) and not to v2.0-v2.1 (not ABI/API stable)? Notice that's not always that the devs use this kind of versioning scheme: v1.1 may be not be ABI stable and v1.0.1 may be the version with critical fixes.

Furthermore, how can we solve this problem without enforcing strict versioning scheme? Can we use hashes of some kind to ensure ABI stability (something as Nix does, but for ABIs)?

Also, how can we take care of (4)?

My app may be compatible with both KDE 5.123 runtime and with GNOME 3.456 runtimes, but what runtime is installed when I install my app? My app can depend on various runtime? I must install the runtime before install the app, or is it installed as a dependency? Runtimes with no associated app would be still available on my machine?

[RahulSundaram]

His sound system seems to have been broken in the sandbox, the video was totally mute and he had to type the whole time! \s

Anyway, nice to see sandboxing on desktop progress. Does anyone know how portable/inter-operable this is with other desktops like KDE or Unity?

There is nothing DE specific about any of the underlying components. It works best with Wayland. So I don't know about Unity. KDE should be fine.

[dragorth]

Sorry to ask such a dumb question, but to what extent does this model (Runtimes + Apps) help with our problems on Linux desktop?

AFAIK, what we need is:

1. When we update Apps, they update their dependencies as they need, but without messing with other app's dependencies.
2. We need to make sure Apps only use dependencies they know about, so, if other machines have all listed dependencies installed, the app should work.
3. When a critical bug is found on the dependencies, old software shouldn't need to upgrade also (reducing the mantainence effort of developers, lowering the costs of app development).
4. We should be able to write an app once for various distros (various runtimes at once).

As far as I understand (and that's not much), item (1) is solved by the proposed model, since apps rely on runtimes (and we can have multiple runtime installed at the same time) or have bundled dependencies (which the devs are willing to update together with the app). Item (2) is, I believe, solved by the runtime model also, since apps are sandboxed and cannot access other libs that are not on the runtime.

But what about (3)?

Suppose we have a library called lib with versions v1.0 and v2.0. My app depends on v1.0 and I don't want to update my software anymore. Therefore, if users also have apps using lib v2.0, they must have v1.0 installed alongside v2.0). Now suppose we find a critical bug on all versions of lib. Then, lib's developers launch v1.1 and v2.1 with the fix.

How can I make sure my app upgrades to v1.1 (ABI/API stable, etc.) and not to v2.0-v2.1 (not ABI/API stable)? Notice that's not always that the devs use this kind of versioning scheme: v1.1 may be not be ABI stable and v1.0.1 may be the version with critical fixes.

Furthermore, how can we solve this problem without enforcing strict versioning scheme? Can we use hashes of some kind to ensure ABI stability (something as Nix does, but for ABIs)?

Also, how can we take care of (4)?

My app may be compatible with both KDE 5.123 runtime and with GNOME 3.456 runtimes, but what runtime is installed when I install my app? My app can depend on various runtime? I must install the runtime before install the app, or is it installed as a dependency? Runtimes with no associated app would be still available on my machine?

Ok, if you don't want to update your software anymore, then your user is screwed regardless on any other system, right? However, you should be able to create a mechanism that says "This app depends on $lib.so v1" and it should only upgrade ABI/API compatible versions. (Many systems allow you to pin versions of libraries when you are creating your app, so that you are always working with the known good version for your app. This has been solved plenty of times, so this is a non-starter.

Also, the second issue can be solved by creating a build-bot service that simply builds for each dependency set. Or, create a standard set and version it. Like DX11 does. if you have this functionality you are 1.0, if this you are 1.1 or 2.0 and so on.

But, you an have multiple runtimes installed on the same system, so you would just install the one needed for that app, and it becomes available for all apps.

[chrisb]

Sorry to ask such a dumb question, but to what extent does this model (Runtimes + Apps) help with our problems on Linux desktop?

...

My app may be compatible with both KDE 5.123 runtime and with GNOME 3.456 runtimes, but what runtime is installed when I install my app? My app can depend on various runtime? I must install the runtime before install the app, or is it installed as a dependency? Runtimes with no associated app would be still available on my machine?

The developer is always going to have to care enough about the app to upgrade dependencies, test out the new build, and then upload it to an app store for further distribution. It is mutually exclusive that the code will always be exactly the same and that updated libraries would be used automatically. Which means that a developer will always have to "approve" their app for any new releases. The libraries can't just be updated because your app might rely on some buggy behaviour and get broken by updated libraries.

I'm going to guess that if you have different builds of your app for KDE and Gnome, then you will have to release two different apps.

Running some graphical app in a container was already done a while ago - see unpriviledged LXC containers with Google Chrome, Skype and Steam. You can also run Xorg inside an LXC container, which is quite cool - you can have Fedora, Ubuntu etc. desktops all happily coexisting on the same computer.

[brk0_0]

Ok, if you don't want to update your software anymore, then your user is screwed regardless on any other system, right? However, you should be able to create a mechanism that says "This app depends on $lib.so v1" and it should only upgrade ABI/API compatible versions. (Many systems allow you to pin versions of libraries when you are creating your app, so that you are always working with the known good version for your app. This has been solved plenty of times, so this is a non-starter.

Also, the second issue can be solved by creating a build-bot service that simply builds for each dependency set. Or, create a standard set and version it. Like DX11 does. if you have this functionality you are 1.0, if this you are 1.1 or 2.0 and so on.

But, you an have multiple runtimes installed on the same system, so you would just install the one needed for that app, and it becomes available for all apps.

So the runtime developer would care about ABI/API compatibility between versions? I mean, suppose GNOME launch GNOME runtime 3.14, 3.16, 3.18, etc. They would be responsible to update each of these, so we would have 3.14-1 that is ABI/API compatible with 3.14-0?

[brk0_0]

The developer is always going to have to care enough about the app to upgrade dependencies, test out the new build, and then upload it to an app store for further distribution. It is mutually exclusive that the code will always be exactly the same and that updated libraries would be used automatically. Which means that a developer will always have to "approve" their app for any new releases. The libraries can't just be updated because your app might rely on some buggy behaviour and get broken by updated libraries.

I'm going to guess that if you have different builds of your app for KDE and Gnome, then you will have to release two different apps.

Running some graphical app in a container was already done a while ago - see unpriviledged LXC containers with Google Chrome, Skype and Steam. You can also run Xorg inside an LXC container, which is quite cool - you can have Fedora, Ubuntu etc. desktops all happily coexisting on the same computer.

I understand that the apps may rely on library's bugs. Solving these bugs may change the ABI/API but that's not the case always. However, when this is NOT the case, it is convenient that old apps should continue running with the fixed library. In my example, if the ABI/API is changed to solve a critical bug (security, privacy, etc), we would still update from v1.0 to v1.1.

So, this is not a case where developers can forget their apps. But they should only care if their versions becomes incompatible after a critical bug fix. This would mean less maintenance effort.

And if we have two different apps, one for GNOME runtime and other for KDE runtime, what would be available on, say, GNOME Software? Both? Don't you think it would confuse users about their differences?