For those not familiar, xdg-app is a Linux virtualization system targeted at desktop apps, it's been under pretty heavy development and is available for use in Gnome 3.20.

Mathias Clausen recently wrote a blog entry about creating his first xdg-app and the application he chose to play with was Terminix, a terminal emulator, which is written in D. He had some D specific challenges to deal with which may be interesting to others looking to support xdg-app.

You can read his blog entry here:

https://blogs.gnome.org/mclasen/2016/04/15/my-first-xdg-app.

On Thursday, 21 April 2016 at 18:55:23 UTC, Gerald wrote:
> For those not familiar, xdg-app is a Linux virtualization system targeted at desktop apps, it's been under pretty heavy development and is available for use in Gnome 3.20.
>
> Mathias Clausen recently wrote a blog entry about creating his first xdg-app and the application he chose to play with was Terminix, a terminal emulator, which is written in D. He had some D specific challenges to deal with which may be interesting to others looking to support xdg-app.
>
> You can read his blog entry here:
>
> https://blogs.gnome.org/mclasen/2016/04/15/my-first-xdg-app.


This whole sandbox apps seem interesting. Canonical also talking about snaps :)

On Thursday, 21 April 2016 at 18:55:23 UTC, Gerald wrote:
> For those not familiar, xdg-app is a Linux virtualization system targeted at desktop apps, it's been under pretty heavy development and is available for use in Gnome 3.20.
>
> Mathias Clausen recently wrote a blog entry about creating his first xdg-app and the application he chose to play with was Terminix, a terminal emulator, which is written in D. He had some D specific challenges to deal with which may be interesting to others looking to support xdg-app.
>
> You can read his blog entry here:
>
> https://blogs.gnome.org/mclasen/2016/04/15/my-first-xdg-app.

How did he get build that weighs less than megabyte? When building with dub -b release and after stripping binary terminix still weighs 9 MB on my debian. And it's just a single binary, without resources and dynamic dependencies.

On 04/21/2016 11:30 PM, Karabuta wrote:
> This whole sandbox apps seem interesting. Canonical also talking about snaps :)

Meh, I can see why this concept is tempting for desktop systems but it makes me feel that 5 years from now I'll have to build my own Linux-From-Scratch distro to preserve kind of user experience I initially loved Linux for (minimal overhead, running same system on both your tiny media server and power desktop). "A runtime can be thought of as a /usr filesystem with fixed contents. When a bundled app gets run, the runtime it needs gets mounted at /usr." :(

On Friday, 22 April 2016 at 10:24:08 UTC, Dicebot wrote:
> On 04/21/2016 11:30 PM, Karabuta wrote:
>> This whole sandbox apps seem interesting. Canonical also talking about snaps :)
>
> Meh, I can see why this concept is tempting for desktop systems but it makes me feel that 5 years from now I'll have to build my own Linux-From-Scratch distro to preserve kind of user experience I initially loved Linux for (minimal overhead, running same system on both your tiny media server and power desktop). "A runtime can be thought of as a /usr filesystem with fixed contents. When a bundled app gets run, the runtime it needs gets mounted at /usr." :(

I don't know at what point dynamic libraries came to be considered harmful, but it certainly seems to be the case now. And even if they are dynamic inside the container, every program shipping an individual copy of the libs means they might as well be statically compiled into it.

On Thursday, 21 April 2016 at 18:55:23 UTC, Gerald wrote:
> For those not familiar, xdg-app is a Linux virtualization system targeted at desktop apps, it's been under pretty heavy development and is available for use in Gnome 3.20.
>
> Mathias Clausen recently wrote a blog entry about creating his first xdg-app and the application he chose to play with was Terminix, a terminal emulator, which is written in D. He had some D specific challenges to deal with which may be interesting to others looking to support xdg-app.
>
> You can read his blog entry here:
>
> https://blogs.gnome.org/mclasen/2016/04/15/my-first-xdg-app.

Can someone explain to me how xdg-app provides a significantly different experience to static linking (in a language like C or D)? I guess there's the old "what about libc?".

On 04/22/2016 02:57 PM, John Colvin wrote:
> On Thursday, 21 April 2016 at 18:55:23 UTC, Gerald wrote:
>> For those not familiar, xdg-app is a Linux virtualization system targeted at desktop apps, it's been under pretty heavy development and is available for use in Gnome 3.20.
>>
>> Mathias Clausen recently wrote a blog entry about creating his first xdg-app and the application he chose to play with was Terminix, a terminal emulator, which is written in D. He had some D specific challenges to deal with which may be interesting to others looking to support xdg-app.
>>
>> You can read his blog entry here:
>>
>> https://blogs.gnome.org/mclasen/2016/04/15/my-first-xdg-app.
> 
> Can someone explain to me how xdg-app provides a significantly different experience to static linking (in a language like C or D)? I guess there's the old "what about libc?".

https://wiki.gnome.org/Projects/SandboxedApps explains it pretty well. Think of it as immutable filesystem snapshot that gets used for sandboxed app instead of real host filesystem. Not only all dependency code is included but all file resources too,:

"A runtime provides a well-defined environment that an app can run in. Examples would be "GNOME 3.14" or "KDE 5.6". A runtime can be thought of as a /usr filesystem with fixed contents. When a bundled app gets run, the runtime it needs gets mounted at /usr." (c) that link

It also includes facilities for limiting sandboxes app access to host:

"The xdg-app run command sets up an isolated environment before exec()ing the application. Among other things, it

- mounts the files/ directory of the application under /app (readonly)
- mounts the files/ directory of the runtime under /usr (readonly)
- mounts the data/ directory of the application under /var (writable)
- if access to the host filesystem is required, it gets mounted at /
(writable)
- if access to the home directory is required, it gets mounted at its
usual place (writable)
- if access to neither the home directory or the host filesystem is
required, /var/home gets mounted in its place (writable)
- if the runtime has extension points, and matching runtimes are
installed, mount them (readonly)"

So in the end each app will bundle all its dependency and just work no matter what the host is. Which is cool. But it will also bundle all its dependencies and you'd better accept size of your total system installation (and its RAM consumption).

On Friday, 22 April 2016 at 12:07:36 UTC, Dicebot wrote:
> So in the end each app will bundle all its dependency and just work no matter what the host is. Which is cool. But it will also bundle all its dependencies and you'd better accept size of your total system installation (and its RAM consumption).

I don't think it is quite as bad as it seems though, I believe the runtimes are shared and thus do not count as dependencies so it's not like each application is shipping the complete gnome runtime for example. Hopefully as additional runtimes get created the dependency issue will lessen.

I will just leave it here:

http://www.zdnet.com/article/linux-expert-matthew-garrett-ubuntu-16-04s-new-snap-format-is-a-security-risk/

On Saturday, 23 April 2016 at 11:29:29 UTC, NX wrote:
> I will just leave it here:
>
> http://www.zdnet.com/article/linux-expert-matthew-garrett-ubuntu-16-04s-new-snap-format-is-a-security-risk/

This is FUD.

There are no security risks with snappy packages that there aren't with any other existing Linux packaging systems.

Snappy actually improves things in various ways compared to most packaging formats, while not addressing the longstanding and universal issues with X11 that affect just about all Linux distros.

The solution of those issues lies either in setting up X11 to appropriately isolate applications (which AIUI is possible but not very nice to do), or using an alternative display server that addresses those security concerns (Mir or Wayland).

Ubuntu and Canonical have been completely up-front about the limitations of snappy's security guarantees when used on an X11 system (well before Matthew Garrett wrote his article), so it's difficult to see these stories as anything other than a malicious attempt to undermine a competitor.