The State Of Flatpak vs. Snaps On Various Linux Distributions

[kyrios]

Why use such small distribution as Solus where are very few apps compared to Debian testing Xfce that is a rolling release os too and way more popular, stable, faster (according to distrowatch Solus uses 800MB ram after boot when Debian testing Xfce uses 200MB), easier to use and more compatible with other distributions.

I installed it to try it out and I decided to keep it despite of all the current limitations because it is imho a very promising distribution. The community is small but FRIENDLY and helpful which is not the case anymore on some other bigger distributions (even if it's only caused by a minority of people). I got fed up with the systemd war and the split of Debian-Devuan.
Unlike most small distributions that are juste based on something else and that don't bring any added value, I think Solus do try many things: some I don't really understand (their own packaging system... WHY?), but also some interesting ones : Budgie desktop, implementing some of the aggressive settings of ClearLinux, tools to manage multi-gpu, etc.

This being said, I fully agree that currently this distribution still lacks maturity and I wouldn't advise it to everyone (yet).

[alvez]

I installed it to try it out and I decided to keep it despite of all the current limitations because it is imho a very promising distribution. The community is small but FRIENDLY and helpful which is not the case anymore on some other bigger distributions (even if it's only caused by a minority of people). I got fed up with the systemd war and the split of Debian-Devuan.
Unlike most small distributions that are juste based on something else and that don't bring any added value, I think Solus do try many things: some I don't really understand (their own packaging system... WHY?), but also some interesting ones : Budgie desktop, implementing some of the aggressive settings of ClearLinux, tools to manage multi-gpu, etc.

This being said, I fully agree that currently this distribution still lacks maturity and I wouldn't advise it to everyone (yet).

Don't feed the trolls.

Use the distro that fits you best.

[samuel]

It seems its two commands for snap to search a different server/PPA, and a snap store is just a http server, so its easy

That seems pretty distributed to me!

From here: http://blog.dustinkirkland.com/2016/...store.html?m=1

The only difference seems to be that snap on Ubuntu has chosen their server as default, whereas flatpak currently has no default, and needs one added by the user

With love

[samuel]

It seems its two commands to get snap to search a different server/PPA, and a snap server is just a webserver, so its easy

That seems pretty distributed!

From here: http://blog.dustinkirkland.com/2016/...store.html?m=1

The only difference seems to be that Ubuntu have configured snap to use a default server, whereas flatpak currently needs this to be set by the user

With love

[ArchFanatic]

There is no such a distribution that fits you the best. It is easier to remove/change existing stuff than conjure out of thin air.

Arch Linux? The philosophy is brilliant (https://wiki.archlinux.org/index.php...nux#Principles)... Few times i returned back to Windows because the satisfaction factor on most distros is low for me (too high ram usage by default and tons of shit preinstalled(email and contacts applications... Ubuntu Unity: 900 MiB on fresh install, Fedora Gnome same... i even tried other Ubuntu spins like Kubuntu and it was even worse - full of buggs and crashes, always old half-working software put together by hacking the source code and inserting tons of workarounds...)...

After i found Arch linux im never looking back and will never install any windows $^%$& on my notebook agin... ram usage on fresh KDE Plasma DE is under 350 MiB and its so fast.

[ermo]

Does anybody really care about flatpak and snaps? To me it seems like yet another linux holy war that is reinventing the wheel and not contributing much to the ecosystem. Tell me ONE advatnage over rpm/apt.

With rpm/apt, you approach the entire repo as one dependency graph. With e.g. flatpak, you confine your dependency tree to independent runtimes that can be updated asynchronously from the base OS rpm/apt dependency graphs.

What this means is that you might not need to update the user-facing flatpaks, but only the base OS rpm/apt dependency graphs and the flatpak runtime that links into the base OS (and you can update the flatpak runtime without affecting the base OS dependency graph).

This is a very big deal for ISVs, because it cuts down on their test and support surface, which will potentially lead to more ISVs offering their software for Linux. As an ISV, you could target the hypothetical XYS webdev stack v2.2x or later or the GNOME 3.2x stack or later for you app instead of having to distrubute eleventeen different .rpm/.deb/.ebuild/.tar.xz/.whatever versions for different distros and versions.

At least, that's my current understanding of the benefits of flatpaks.

[bug77]

There is no such a distribution that fits you the best. It is easier to remove/change existing stuff than conjure out of thin air.

That is false from a logic point of view. There may be no distro that fits 100% what you need, but there has to be one that's closer to your needs than the rest. That's the one that fits you best.

[trek]

This is a very big deal for ISVs, because it cuts down on their test and support surface, which will potentially lead to more ISVs offering their software for Linux. As an ISV, you could target the hypothetical XYS webdev stack v2.2x or later or the GNOME 3.2x stack or later for you app instead of having to distrubute eleventeen different .rpm/.deb/.ebuild/.tar.xz/.whatever versions for different distros and versions.

if I understand correctly, flat & snap provides a workaround for software that uses buggy libraries that frequently changes their ABI, like gnome/gtk libraries

not needed if the software is based upon posix standards

[jKicker]

if I understand correctly, flat & snap provides a workaround for software that uses buggy libraries that frequently changes their ABI, like gnome/gtk libraries

not needed if the software is based upon posix standards

Well, you don't understand correctly.

Have you ever wanted to make a release of your application for Linux in general and have it updated? Well that's where they come in. For OSX, Windows, iOS, Android etc you just build and distribute your app. For linux you need to create multiple packages for multiple distributions so you spend more time on building your app than developing. Unless you are popular enough so that distribution packagers do it themselves. And then you still can't update that.

They also have security features that your posix c really doesn't have given what all security issues happened over the last decade that whole new language was designed to mitigate that (rust). So they will also confine your buggy application to some degree.

As for snap vs flatpack it seems we need another "universal" package solution that will create flat/snap from that package...

[TheBlackCat]

Well, you don't understand correctly.

Have you ever wanted to make a release of your application for Linux in general and have it updated? Well that's where they come in. For OSX, Windows, iOS, Android etc you just build and distribute your app. For linux you need to create multiple packages for multiple distributions so you spend more time on building your app than developing. Unless you are popular enough so that distribution packagers do it themselves. And then you still can't update that.

They also have security features that your posix c really doesn't have given what all security issues happened over the last decade that whole new language was designed to mitigate that (rust). So they will also confine your buggy application to some degree.

As for snap vs flatpack it seems we need another "universal" package solution that will create flat/snap from that package...

Based on the summary quoted in the OP anyone who supports snap also supports flatkpack, so we really don't.