Playing Around With Ubuntu's Snaps, On Fedora

[viceversa]

Qaridarium writes: //so in my point of view "snap" solve many problems and it costs us yes harddrive space.//

magnecoeur writes: //So the Linux Snap being around 1GB makes sense since both packages take...//

No, it doesn't make sense. Eric's article needs to be updated. (He must have gone off for a drink at the pub.) As it is, it's wildly and flatly wrong. The massive size of the LO file was due to debug symbols being included. (See above.)

[gururise]

I wonder if Michael will re-evaluate his opinion and/or update the article on Snaps now that it's been revealed that the original 1.1GB Open Office image included full debug symbols and the new "release" build of Open Office 5.2 Beta SNAP package is only 287 MB (including JAVA engine which the other packages don't include).

LibreOffice 5.2 Beta Package Sizes:

• Linux x86_64 (deb) - 229MB
• Linux x86_64 (rpm) - 229MB
• LibreOffice AppImage: 246 MB
• Mac OS X x86_64 - 201MB
• Windows x86_64 - 238 MB
• Linux x86_64 (snap) - 287MB

[Tomin]

I wonder if Michael will re-evaluate his opinion and/or update the article on Snaps now that it's been revealed that the original 1.1GB Open Office image included full debug symbols and the new "release" build of Open Office 5.2 Beta SNAP package is only 287 MB (including JAVA engine which the other packages don't include).

And Base. But it's not Michael that wrote the article.

[gururise]

And Base. But it's not Michael that wrote the article.

Ahh.. you are right. Didn't notice Michael didn't write the article. Anyhow, one of the author's biggest gripes with SNAP packages was the large size of the Libre Office image. I wonder if he would be willing to re-evaluate his opinion and/or update the article now that we know the LibreOffice Snap is only 287MB.

[viceversa]

//Following the announcement, a discussion played out on fedora-devel that made it clear, at least to me, that Fedora is firmly behind Flatpak as the answer to Linux packaging... and frankly I don't blame them.//

Yeah, because Gnome Shell and Fedora are just such an unbeatable combination. Maybe Fedora and Gnome devs should give DELL and SAMSUNG a call to straighten them out? I mean, they would have a say in "Linux Packaging" because why?

To install Libre via flatpak.

wget https://sdk.gnome.org/keys/gnome-sdk.gpg
flatpak remote-add --user --gpg-import=gnome-sdk.gpg gnome https://sdk.gnome.org/repo/
flatpak install --user gnome org.gnome.Platform 3.20
flatpak install --user --bundle LibreOffice.flatpak
flatpak run org.libreoffice.LibreOffice

Via SNAP:

wget http://people.canonical.com/~bjoern/snappy/libreoffice_5.2.0.0.beta2_amd64.snap
sudo snap install libreoffice_5.2.0.0.beta2_amd64.snap

Speaks for itself.

If Fedora thinks flatpak is the future of linux packaging, just leave them to their playground.

flatpak ---> BetaMax
Snap ---> VHS

[starshipeleven]

To install Libre via flatpak.

wget https://sdk.gnome.org/keys/gnome-sdk.gpg
flatpak remote-add --user --gpg-import=gnome-sdk.gpg gnome https://sdk.gnome.org/repo/
flatpak install --user gnome org.gnome.Platform 3.20
flatpak install --user --bundle LibreOffice.flatpak
flatpak run org.libreoffice.LibreOffice

Via SNAP:

wget http://people.canonical.com/~bjoern/snappy/libreoffice_5.2.0.0.beta2_amd64.snap
sudo snap install libreoffice_5.2.0.0.beta2_amd64.snap

Speaks for itself.

If Fedora thinks flatpak is the future of linux packaging, just leave them to their playground.

flatpak ---> BetaMax
Snap ---> VHS

bah, that can be all automated easily.

Besides, if we have to rely on CLI to install supposedly "very user-friendly app packaging", there is something very wrong.

[liam]

Snaps have the concept of interfaces, enabling snaps to provide services to one another securely. This is much richer than the simplistic idea of having a 'base', because it allows you to create a secure interaction between two snaps that exactly reflects the way in which they are supposed to interact. This is how, for example, you would create a shared library snap if you had multiple snaps that needed a common framework.

That sounds similar to Portals except that instead of shared libraries you export specific application functionality. Basically the same as android binder mediated Intents.

https://github.com/flatpak/flatpak/wiki/Portals

[AdamW]

bah, that can be all automated easily.

Besides, if we have to rely on CLI to install supposedly "very user-friendly app packaging", there is something very wrong.

Right. Neither of those is the actual intended user interface. Neither Snappy nor Flatpak is anywhere close to being really 'done' yet, in terms of being a universal desktop app installer. This is why Flatpak's devs aren't going around releasing press releases claiming it is. I don't know why Canonical's PR people are.

[viceversa]

//Right. Neither of those is the actual intended user interface.//

True, my point, really, was that SNAP already appears to be a better thought out and elegant solution.

[pythoneer]

I am a German to and I have 109 mbps download and 42mbps upload on a "VDSL2.0 Vectoring A17" Telekom line. The line capacity right now is 121mbps but Telekom only give 109 away.
So an download of a snap would not be a big problem.

Yeah you are such a cool guy, but what does this proof? Nothing! I hope you are not saying that because you have fast internet every one in Germany has. Do you really missed the "Neuland" discussion recently? ISP "drosseln" their customers or people having "DSL light". I live in Berlin and there are Parts without even DSL. You can have Cable, which is unusable after 6 pm. So please stop presenting your fancy internet connection to prove anything.

we all understand your point but you do not unterstand what snap is for.

What does you make think that? I explicitly said at an example what if you had 15 of those packages ... this implies that not every applications is shipped with these tech.