Steam Link app now available for the Linux desktop

Quoting: Cyba.Cowboy

Quoting: CreakEDIT: looking at Flatpak's wikipedia page, the support out-of-the-box seems as important if not more than for Snap:
https://en.wikipedia.org/wiki/Flatpak#Support

Quoting: slaapliedjeWhere flatpaks and AppImages are open.

Well I have repeatedly stated above that this is the reason I think FlatPak is the superior "next-generation" package manager... I find that Snaps have noticeably better performance and they have certain technical advantages over FlatPak; but at the end of the day, being more "open" is more usually more important in the Grand Scheme of Things (at least in my opinion, anyway).

Which is weird, as everyone I have read says that snaps have terrible performance. The main reason I don't like Flatpaks is that they seem to use a lot more space than normally packaged software. I mean sure, part of that is that they don't use linked libraries, but it's large amounts, to the point where I've had to remove all flatpaks so I had disk space...

Quoting: slaapliedje

Quoting: Cyba.Cowboy

Quoting: CreakEDIT: looking at Flatpak's wikipedia page, the support out-of-the-box seems as important if not more than for Snap:
https://en.wikipedia.org/wiki/Flatpak#Support

Quoting: slaapliedjeWhere flatpaks and AppImages are open.

Well I have repeatedly stated above that this is the reason I think FlatPak is the superior "next-generation" package manager... I find that Snaps have noticeably better performance and they have certain technical advantages over FlatPak; but at the end of the day, being more "open" is more usually more important in the Grand Scheme of Things (at least in my opinion, anyway).

Which is weird, as everyone I have read says that snaps have terrible performance. The main reason I don't like Flatpaks is that they seem to use a lot more space than normally packaged software. I mean sure, part of that is that they don't use linked libraries, but it's large amounts, to the point where I've had to remove all flatpaks so I had disk space...

It does indeed take some disk space (especially the runtimes which are the base for every other packages).

I ran some test using `flatpak info APP_ID`:

Runtimes:
* org.freedesktop.Platform: 736.8 MB
* org.gnome.Platform: 948.8 MB
* org.kde.Platform: 992.1 MB

Applications:
* com.transmissionbt.Transmission: 3.9 MB
* com.obsproject.Studio: 49.3 MB
* org.inkscape.Inkscape: 238.9 MB
* com.valvesoftware.Steam: 40.6 MB
* org.pitivi.Pitivi: 197.3 MB
* org.videolan.VLC: 81.8 MB

But it's the price to pay to have sandboxed applications (I know it's not perfect yet, not completely sandboxed bla bla bla... some pieces of the puzzle need to settle down so that access right will be easier to manage and, overall, the system is rather new, but it has improved drastically in just a couple of years).

And also, I'd rather use Flatpak to run the closed source applications such as Steam, Teams, Slack, Unity Hub, etc..

Quoting: slaapliedje

Quoting: Cyba.Cowboy

Quoting: CreakWell there is at least a huge difference between AppImage and the others (AppImage being merely a huge dump of files that are uncompressed at a specific location and run there).

Meh.

I meant similar in the sense that AppImage loosely has similar goals... There are of course, some obvious differences (such as the fact that it doesn't usually provide libraries, it's not isolated, etc...); but the general idea is the same.

It is quite clearly the "most" different of the three, though...

Quoting: CreakBut overall I don't think the fragmentation is that bad because:
* Snap is basically Ubuntu-only

Not really.

According to Wikipedia, Snaps are supported "out of the box" by at least:
* Ubuntu (plus most of its deviations)
* Gallium OS
* Manjaro
* Zorin OS
* KDE Neon
* Solus
* Li-f-e

I'm not familiar with some of those operating systems, but Manjaro are KDE Neon are certainly big names, and Snaps can be optionally added to a MUCH bigger list of operating systems... In theory, it can run under almost any Linux-based operating system.

So no, not Ubuntu-only.

Quoting: CreakBut overall I don't think the fragmentation is that bad because:
* Flatpak is cross-distributions

Snap is too, so I don't understand your point.

As I wrote above, FlatPak is slightly more "open" - which is the primary reason why I think it is the superior of the two (though I find the performance much better under Snap); but it is certainly not the only one of the two that has cross-distribution support.

Huh, I would be shocked if 'out of the box support' equals 'installed by default'. Especially for Manjaro.

The main issue with snaps is that they are not decentralized, Canonical controls tge store. Where flatpaks and AppImages are open. AppImages are basically the same as the Mac's DMG files, so there is that.

Indeed, snap is not setup out of the box on Manjaro: https://wiki.manjaro.org/index.php/Snap.

The fact that it is "supported" other distos does not say much either. It is supposed to work on Fedora, but it has been broken on Fedora 33 for quite a while before it was fixed as an example (due to a bug which avoided gui snaps from working on gnome 3.38 and wayland). I also had issues with snap + SELinux there when I tried which made spotify insta crash (and never tried again after to be honest, was just intellectual curiosity).
There is a large chance that it would break the same on Manjaro which also used gnome 3.38 and wayland. And from what I saw, bug probably stayed for month, which would tend to say that not many people cared either.

Also, Linux mint is now trying to act against snap after the chromium fake apt drama. PopOS stand agaisnt snap also ... So yeah, I think Snap can be considered a mostly ubuntu/some derivatives stuff. And no, it does not seems to be preinstalled on that many distros.

As for the perf, snap tend to be slow to load because of decompression, and require a root daemon to setup the loops (which is a design flow no matter how you look at it, as it enlarge attack surface).
For perf, I have used flatpak a lot at home, and I did use snap on my ubuntu work laptop, and flatpak - even on ubuntu - seems to be more reactive. At least, flatpak loads instantly even after a reboot, can't say the same for snaps. Flatpak also runs golden on the distros I've used it on (ubuntu,debian, arch and centos).

So yeah, I would say that flatpak is an overall win as a general, non distro specific packet manager. Also, it does not rely on a fully proprietary server, completely controlled by one company which is the last nail in Snap's coffin in my opinion.

Quoting: CreakI didn't know Snap was installed by default on that many distros, I stand corrected.

EDIT: looking at Flatpak's wikipedia page, the support out-of-the-box seems as important if not more than for Snap:
https://en.wikipedia.org/wiki/Flatpak#Support

Quoting: CreakI didn't know Snap was installed by default on that many distros, I stand corrected.

EDIT: looking at Flatpak's wikipedia page, the support out-of-the-box seems as important if not more than for Snap:
https://en.wikipedia.org/wiki/Flatpak#Support

Indeed flatpak is default on all trendy distro I'd say: mint/pop/ elementary and Endless. Not bad, plus the big ones centos/RHEL and Fedora. On ubuntu, it is easy to install, and works golden. So I'd say that it has more effective user adoption than snap. You can also search the endless quantity of users asking how to remove snap from ubuntu... Whereas you don't really see anyone asking to remove flatpak. Simply because it is much less intrusive, no deamon running, and pretty much transparent when running. And especially because no on tries to shove it in our throats ... Flatpak is only there for when you need it: proprietary app you can't trust (slack, zoom etc), maybe browser if the sandbox makes you feel better (it shouldn't but that's another story) or on CentOS/RHEL where it enables you to access recent apps without messing with the base OS.
And if I want to deploy nextcloud, I prefer to use podman and use it to segment and isolate properly than to use a packet which update itself and I can't really control ... So thx for trying to package that, but no thanks.

In the end canonical did what canonical does: they made their own solution, trying to lock in people, tried to shove it to ubuntu users and derivatives, but seems to be slowly failing in front of the "common" alternative which was actually developped by more than one company, is better engineered and is actually focused on solving one problem instead of being a do-it-all/good-for-nothing that snap is (it tries to solve basically all deployement problems - app, server components, low level OS and even kernel ! - which have very different problematic and requirements with a "one size fit it all approach", needless to say that's not usually the best way to tackle engineering issues ...)

Quoting: CreakBut overall I don't think the fragmentation is that bad because:
* AppImage is clearly not the way to go and I think most developers knows that
* Snap is basically Ubuntu-only
* Flatpak is cross-distributions

I'm just curious, what's the problem with appimage? It seems to work fine, some big projects like onlyoffice and emulators like yuzu and rpcs3 have success

Quoting: fagnerln

Quoting: CreakBut overall I don't think the fragmentation is that bad because:
* AppImage is clearly not the way to go and I think most developers knows that
* Snap is basically Ubuntu-only
* Flatpak is cross-distributions

I'm just curious, what's the problem with appimage? It seems to work fine, some big projects like onlyoffice and emulators like yuzu and rpcs3 have success

I think the main issue with Appimage is that it's back to pick up sw randomly off the Internet. Which is not that great. Having only one centralized source sucks. But having a set of sources handled by professionals who check what you will install is quite great. AppImage is a bit like .exe for windows, with all related issues.
A secondary issue is that it is the supreme bloat since you really pack a whole lot of things in your app, and its corrolary: you can't update any part yourself - is it monolithic -, whereas for flatpak, you could force a newer runtime for the basics at least, or overload an installed flatpak with new features/libs if you want.

As you say, it is not a complete blocker either, and it does have some cases where it can be useful for distribution by stores like gog as an example. RPCS3 which does have a flatpak is not the best example though :)

Quoting: 3zekielA secondary issue is that it is the supreme bloat since you really pack a whole lot of things in your app, and its corrolary: you can't update any part yourself - is it monolithic -, whereas for flatpak, you could force a newer runtime for the basics at least, or overload an installed flatpak with new features/libs if you want.

As you say, it is not a complete blocker either, and it does have some cases where it can be useful for distribution by stores like gog as an example. RPCS3 which does have a flatpak is not the best example though :)

I might be misunderstanding your point here, but AppImage currently does allow incremental updates: https://docs.appimage.org/packaging-guide/optional/updates.html

I've been using the zsync method to update the neovim nightly appimage from github; it works just fine — that is the developer (without going through any intermediary) incrementally updates the nightly image on github every day, and the delta is all I have to download.


Last edited by wvstolzing on 18 March 2021 at 7:17 pm UTC

Quoting: wvstolzing

Quoting: 3zekielA secondary issue is that it is the supreme bloat since you really pack a whole lot of things in your app, and its corrolary: you can't update any part yourself - is it monolithic -, whereas for flatpak, you could force a newer runtime for the basics at least, or overload an installed flatpak with new features/libs if you want.

As you say, it is not a complete blocker either, and it does have some cases where it can be useful for distribution by stores like gog as an example. RPCS3 which does have a flatpak is not the best example though :)

I might be misunderstanding your point here, but AppImage currently does allow incremental updates: https://docs.appimage.org/packaging-guide/optional/updates.html

I've been using the zsync method to update the neovim nightly appimage from github; it works just fine — that is the developer (without going through any intermediary) incrementally updates the nightly image on github every day, and the delta is all I have to download.

So for the first point, I was talking about what you can do without the developer, which is override the runtime, or add elements yourself (in flatpak you do that by declaring your own flatpak as prev_flatpak.my_extension). Incremental update is a delta on bin image I guess as implem. Having the update source directly in Appimage is good though.
Also, in term of bloat, two Appimage do not share anything, whereas two flatpaks most likely share their runtime, and probably some "base apps", meaning it will lead to less disk usage overhead.

Second, when I talk about downloading off the internet, I mean as a general habit. The fact that it comes straight from the dev is not necessarily good. And not just for AppImage, the perfect example is: https://www.omgubuntu.co.uk/2018/05/ubuntu-snap-malware where the snap this time came from the dev, but was not carefully checked by intermediary and contained some malware ... If the app had been packaged and tested by a packager, and not just blob submitted and checked only for stuff like sandbox violation, this could have been avoided. But with AppImage, no one even checks whether the program does strange stuff, hence my remark about it being the same as good old .exe days. You can have dishonest devs that get away more easily, or you can have dubious sources for those who are less careful, or if you end up on a repo that looks like that of the original dev as an example. It is much easier to impersonate (imperfectly) a single dev than to take over your distro's repository, or Flathub.

Now, I can see some cases where Appimage has its place, but I don't think it can be THE inter distro platform.


Last edited by 3zekiel on 19 March 2021 at 1:01 pm UTC

Quoting: Creak

Quoting: slaapliedje

Quoting: Cyba.Cowboy

Quoting: CreakEDIT: looking at Flatpak's wikipedia page, the support out-of-the-box seems as important if not more than for Snap:
https://en.wikipedia.org/wiki/Flatpak#Support

Quoting: slaapliedjeWhere flatpaks and AppImages are open.

Well I have repeatedly stated above that this is the reason I think FlatPak is the superior "next-generation" package manager... I find that Snaps have noticeably better performance and they have certain technical advantages over FlatPak; but at the end of the day, being more "open" is more usually more important in the Grand Scheme of Things (at least in my opinion, anyway).

Which is weird, as everyone I have read says that snaps have terrible performance. The main reason I don't like Flatpaks is that they seem to use a lot more space than normally packaged software. I mean sure, part of that is that they don't use linked libraries, but it's large amounts, to the point where I've had to remove all flatpaks so I had disk space...

It does indeed take some disk space (especially the runtimes which are the base for every other packages).

I ran some test using `flatpak info APP_ID`:

Runtimes:
* org.freedesktop.Platform: 736.8 MB
* org.gnome.Platform: 948.8 MB
* org.kde.Platform: 992.1 MB

Applications:
* com.transmissionbt.Transmission: 3.9 MB
* com.obsproject.Studio: 49.3 MB
* org.inkscape.Inkscape: 238.9 MB
* com.valvesoftware.Steam: 40.6 MB
* org.pitivi.Pitivi: 197.3 MB
* org.videolan.VLC: 81.8 MB

But it's the price to pay to have sandboxed applications (I know it's not perfect yet, not completely sandboxed bla bla bla... some pieces of the puzzle need to settle down so that access right will be easier to manage and, overall, the system is rather new, but it has improved drastically in just a couple of years).

And also, I'd rather use Flatpak to run the closed source applications such as Steam, Teams, Slack, Unity Hub, etc..

You may not be checking the true file size correctly there. Flatpak uses OStree and it de-duplicates files. Most runtimes only add a few files ontop of the core freedesktop runtime. To get the correct size you have to do something like:
 
du -sh "org.gnome.Platform/x86_64/3.38" "org.freedesktop.Platform/x86_64/20.08"
You should see then that the first folder is roughly as you said but the next will be much smaller (would be good if flatpak info could do that for you). An app plus its runtime should not use much more space than a native package when you add up all the native system components it depends on. Especially once you have many flatpak apps using the same runtime. Also don't forget to run `flatpak uninstall --unused` from time to time to remove old unused runtimes.

I think I remember reading at some point that SNAPS' developers intend to add similar de-duplication features. No idea where I might have read that though!

Quoting: MagicMyth

Quoting: Creak

Quoting: slaapliedje

Quoting: Cyba.Cowboy

Quoting: CreakEDIT: looking at Flatpak's wikipedia page, the support out-of-the-box seems as important if not more than for Snap:
https://en.wikipedia.org/wiki/Flatpak#Support

Quoting: slaapliedjeWhere flatpaks and AppImages are open.

Well I have repeatedly stated above that this is the reason I think FlatPak is the superior "next-generation" package manager... I find that Snaps have noticeably better performance and they have certain technical advantages over FlatPak; but at the end of the day, being more "open" is more usually more important in the Grand Scheme of Things (at least in my opinion, anyway).

Which is weird, as everyone I have read says that snaps have terrible performance. The main reason I don't like Flatpaks is that they seem to use a lot more space than normally packaged software. I mean sure, part of that is that they don't use linked libraries, but it's large amounts, to the point where I've had to remove all flatpaks so I had disk space...

It does indeed take some disk space (especially the runtimes which are the base for every other packages).

I ran some test using `flatpak info APP_ID`:

Runtimes:
* org.freedesktop.Platform: 736.8 MB
* org.gnome.Platform: 948.8 MB
* org.kde.Platform: 992.1 MB

Applications:
* com.transmissionbt.Transmission: 3.9 MB
* com.obsproject.Studio: 49.3 MB
* org.inkscape.Inkscape: 238.9 MB
* com.valvesoftware.Steam: 40.6 MB
* org.pitivi.Pitivi: 197.3 MB
* org.videolan.VLC: 81.8 MB

But it's the price to pay to have sandboxed applications (I know it's not perfect yet, not completely sandboxed bla bla bla... some pieces of the puzzle need to settle down so that access right will be easier to manage and, overall, the system is rather new, but it has improved drastically in just a couple of years).

And also, I'd rather use Flatpak to run the closed source applications such as Steam, Teams, Slack, Unity Hub, etc..

You may not be checking the true file size correctly there. Flatpak uses OStree and it de-duplicates files. Most runtimes only add a few files ontop of the core freedesktop runtime. To get the correct size you have to do something like:
 
du -sh "org.gnome.Platform/x86_64/3.38" "org.freedesktop.Platform/x86_64/20.08"
You should see then that the first folder is roughly as you said but the next will be much smaller (would be good if flatpak info could do that for you). An app plus its runtime should not use much more space than a native package when you add up all the native system components it depends on. Especially once you have many flatpak apps using the same runtime. Also don't forget to run `flatpak uninstall --unused` from time to time to remove old unused runtimes.

I think I remember reading at some point that SNAPS' developers intend to add similar de-duplication features. No idea where I might have read that though!

Thank you! I also thought at first that de-duplication would give smaller figures, but as I watched the `flatpak info` outputs, I figured it wasn't what I expected, and instead of tweaking the numbers to fit my theory, I preferred to tell my discovery as it is.

I didn't think about using `du -hs` though, but it would makes sense, so I tried it and here are the results:

$ cd /var/lib/flatpak
$ du -hs runtime/org.freedesktop.Platform/x86_64/20.08/ runtime/org.gnome.Platform/x86_64/3.38 runtime/org.kde.Platform/x86_64/5.15/
672M runtime/org.freedesktop.Platform/x86_64/20.08/
265M runtime/org.gnome.Platform/x86_64/3.38
308M runtime/org.kde.Platform/x86_64/5.15/
$ du -hs app/com.transmissionbt.Transmission/ app/com.obsproject.Studio app/org.inkscape.Inkscape app/com.valvesoftware.Steam app/org.pitivi.Pitivi/ app/org.videolan.VLC 
4.4M app/com.transmissionbt.Transmission/
51M app/com.obsproject.Studio
236M app/org.inkscape.Inkscape
40M app/com.valvesoftware.Steam
182M app/org.pitivi.Pitivi/
80M app/org.videolan.VLC

As you can see, except for the GNOME and KDE runtimes where sizes are indeed smaller, the sizes of the Freedesktop runtime and of all the apps are pretty much the same.


Last edited by Creak on 28 March 2021 at 4:33 pm UTC