GNOME Software With XDG-App Is Working On Live Updates

[phoronix]

Phoronix: GNOME Software With XDG-App Is Working On Live Updates

As a Christmas present for GNOME users, Richard Hughes has shared the work going on with the GNOME Software app center and with the XDG-App sandboxing tech...

http://www.phoronix.com/scan.php?pag...tware-Live-App

[Candy]

Christmas present or Christmas nightmare ? I doubt anyone will be ever using this by intention. It leads to a lot of security issues (by sandboxing older libraries that might still contain security issues). I recently read a few comments from 3rd party Apple programmers (companies), who removed their programs from apple store, because of limitations and because they couldn't do certain things that require *non sandboxing*. Sure you can achieve this under linix because it's not restrictive. But there might be restrictions one day, if you follow the path of sandboxing (e.g. requirements for sandboxing programs). I still go with rpm and deb anytime.

[blackout23]

I like what they are trying to do with xdg-app. I just find that the solution is pretty complex, but maybe there is no easy solution. Can't really wrap my head around OStree. I know that it works bit like git, but that's it. Ideally apps should be just one file like a file system image, you should be able to install any version you want, you should be able to even have multiple versions installed if you wish without any conflicts, it should be nearly guaranteed to work on any distro if it worked on the PC that the app bundle was created, it should be easy to sandbox, space efficient and there should be a package manager that can search and download these apps directly from upstream, all cryptographically signed.

[plonoma]

The name of XDG-App is really unfitting for a sandboxing standard.
Why not call it XDG-SandBox-App/XDG-Sandbox or something else that makes a better name?

[jonnor]

I like what they are trying to do with xdg-app. I just find that the solution is pretty complex, but maybe there is no easy solution. Can't really warp my head around OStree. I know that it works bit like git, but that's it.

OSTree is used to build an xdg-app bundle. It is not something one needs to understand to use such bundles.
And according to the devs, one can build these images with other build/package systems as well (like NiX/rpms/debs etc).

Ideally apps should be just one file like a file system image, you should be able to install any version you want, you should be able to even have multiple versions installed if you wish without any conflicts, it should be nearly guaranteed to work on any distro if it worked on the PC that the app bundle was created, it should be easy to sandbox, space efficient and there should be a package manager that can search and download these apps directly from upstream, all cryptographically signed.

That is basically what xdg-app aims to provide.

[Ximion]

The name of XDG-App is really unfitting for a sandboxing standard.
Why not call it XDG-SandBox-App/XDG-Sandbox or something else that makes a better name?

That's because xdg-app is an application deployment system which happens to implement a sandbox by default. So deployment and sandboxing are glued together, and while you can deploy an app with xdg-app without full sandboxing, you can't use the sandbox without also using xdg-app.
That said, the Limba project will also implement sandboxing (but later), and having a generic API to sandbox arbitrary binaries would be nice, so maybe that will happen at a later stage. But that's all a research project at time, since we need to be on Wayland first and also need something like kdbus to isolate DBus communication.

[justmy2cents]

Christmas present or Christmas nightmare ? I doubt anyone will be ever using this by intention. It leads to a lot of security issues (by sandboxing older libraries that might still contain security issues). I recently read a few comments from 3rd party Apple programmers (companies), who removed their programs from apple store, because of limitations and because they couldn't do certain things that require *non sandboxing*. Sure you can achieve this under linix because it's not restrictive. But there might be restrictions one day, if you follow the path of sandboxing (e.g. requirements for sandboxing programs). I still go with rpm and deb anytime.

you can use it without sandboxing, you know? sandboxing is just one of the options

[[email protected]]

That's very nice to finally hear some progress is being made on these 'LinuxApps'.
Now, I hope every distro or so will standardize on a distribution format with a package manager. Maybe the best solution is to make these distro-agnostic and toolkit-agnostic. (ie, command line tools not tied to gtk, on which existing tools can build up). This is a much needed solution; so please don't fragment the linux desktop even more once again (I hope Microsoft won't get involved).

[ElectricPrism]

Alls I know is if I could run a App from 2015 in 2035 that would be great.

Of course some scenarios are better off with a app not using SandBox - OpenSSL, ProFTPd, etc... which all require security. On the other hand, my Video Game doesn't need to use the latest system SDL library.

In a perfect "ideal" world we could have all Apps ahear to API and implement proper code - but in this world it's more likely that the majority of programmers are less than "top notch", and from the users perspective if the App & Desktop are used on a Consumer / Small Business / Personal level what do they care about it being bulletproof if it doesn't boot because the App was coded bad, they'd rather have a Working App with security holes than a Broken App whose dependencies are bulletproof.

I just imagine a world where QuickBooks, Photoshop, and Microsoft Office all break because X,Y&Z dependencies update before the Publisher has a chance to verify compatibility with their code. Just Imagine if Python 3.x dropped a replacement to Python 2.x without downstream having a chance to update to the newest standards, a total trainwreck would ensue...

Sounds like XDG-App Sandbox could be extremely useful when implemented in the proper scenario.

[Maxjen]

Maybe the best solution is to make these distro-agnostic and toolkit-agnostic. (ie, command line tools not tied to gtk, on which existing tools can build up).

That's exactly how xdg-app works already. You can use it on Arch or Fedora for example and the applications will just work. And there are no ties to gtk.