
Comparing LibreOffice Versions: AppImage, Flatpak, and Snap - app4soft
http://www.ubuntubuzz.com/2019/06/comparing-libreoffice-62-versions-appimage-flatpak-snap.html
======
upofadown
>LibreOffice for GNU/Linux nowadays is available in 3 different universal
formats, as alternative to the native format (DEB and RPM). This is an
advancement that benefits us all greatly.

Not sure I understand the thinking behind this statement. If LibreOffice is
native to a distribution wouldn't you be better off just leaving it as it is?
The three methods are more applicable to third party programs...

~~~
simosx
Some version of LibreOffice is native to a distribution. Those new formats
have benefits, including the ability to automate the processes of updates
(mostly thanks to better tooling as they are newer), the ability for
confinement, etc.

~~~
yjftsjthsd-h
> including the ability to automate the processes of updates

... What exactly will it do that's better than being included in `apt
upgrade`? I do _not_ want to go back to the Windows way where every stupid
application insists on running its own little auto-updater in the background.

------
padraic7a
In the article the author times the startup speed for each installation
method. It's a known issue that Snap installed applications are slower to
execute for the first time than they are subsequently. It's not clear from the
piece if the timed execution was the applications first run or not.

~~~
awelkie
Is that the first time per installation, or the first time per boot?

I just tried starting the gnome-characters app, which I have installed via
snap and via apt. The snap-installed app boots in around 6 seconds after
restarting my machine, and then in about 3 seconds afterwards (I'm just
counting the seconds in my head). By contrast, the apt-installed app boots
well under a second.

~~~
AnIdiotOnTheNet
My god, doesn't that amount of time bother anyone? 3 whole seconds is an
eternity on modern hardware.

~~~
Insanity
It probably bothers some people but it does not bother me. I'm on relatively
slow hardware. I use a (second?) gen i5, but without an SSD and without a GPU.
My laptop is fine for programming, even gaming (CS:GO, CS:S both work! CS:GO
admittedly on 1080p but low graphics).

The thing is that I've never used anything faster than an i7 + HDD (with GPU).
So when my old one died, I just started using my ever so slightly slower
laptop as main device.

I firmly believe that as long as you have not experienced the difference
(which I haven't) it does not bother you. Applications don't start lightning
fast, when I open the terminal I need to wait a second before I can start
typing. So I start Spotify, Firefox alongside my terminal and after ~10
seconds I'm up and running for the rest of the day.

I'm not that bothered about waiting 10 seconds each day.

~~~
AnIdiotOnTheNet
You really should be. I am continually amazed at how, even though computers
have become orders of magnitude faster since the early 90s, everything still
feels pretty much exactly as slow.

Let me put it this way: A 2nd gen i5 can execute about 6 instructions per
cycle per core. At 3Ghz, that's 18 billion instructions every second or 5e-11
seconds per instruction. If each of those instructions is a second to the
processor's subjective experience, then 18 billion of them is about 570 years.
It takes 3 times that to startup an application for typing text into a
document.

I didn't even take multicore into account.

------
robotmay
I find AppImage files quite annoying, I must admit. I understand that it's
annoying packaging for all the different Linux distros, but this doesn't feel
like the solution. Maybe renaming them and dumping them in /usr/local/bin
would make them integrate better with the OS, but I usually just avoid them.

Flatpak has been quite nice when I've used it, if a bit more awkward to figure
out first time.

Snap is fine, but the actual publishing side of it I found quite confusing and
arduous when I tried it, so from a developer point-of-view I would probably
avoid it (unless it improved a lot in the last year).

~~~
loginwithgithub
Why do you find them annoying? I love them. Every application is just one file
that I can freely move and copy around, can't be any simpler than that.

~~~
yjftsjthsd-h
Take a dozen such applications, then have a security vulnerability show up in
a core library. Still simple?

~~~
AnIdiotOnTheNet
Yes, it just isn't "secure" as far as the security-for-the-security-gods types
are concerned.

~~~
loginwithgithub
It depends on how often the stuff in the packages gets updated, not on the
package format.

------
sandGorgon
Redhat and Ubuntu should bury the packaging hatchet and arrive at a single
packaging format. Doesnt matter if it is snap or flatpak. That would have far
reaching ramifications for the adoption of Linux.

~~~
chrisseaton
A Linux distribution’s work _is_ the packaging format and tools - deciding to
use a common one would basically be shutting down the other distro.

~~~
teilo
Eh... it's a _lot_ more than that. It's the specific packages themselves, and
how those packages are built, and how the OS is structured, which versions of
libraries are used, how certain common tools are named (think python vs
python3). The philosophy of different distros can be radically different.
Startup environments can be completely different. Defaults and config in
different places. Packages are patched differently. Libraries named
differently (think dynamic linking to specific library versions). Init vs.
systemd. Wayland vs. XWindows. Some distros even eliminate the distinction
between /bin and /sbin. If RHEL, for example, adopted apt, a RHEL pkg likely
won't work on Debian. That's why Snap, Flatpak and AppImage are what they are:
completely self-contained or statically linked with no dependence on system
libraries or image trees.

------
edent
I still don't get the difference between Flatpak and Snap.

I get that AppImage is a self contained executable. Fine - makes sense to me.
The others... I've got both installed on my Ubuntu 19.04 box and I really have
no idea why I'd choose one over the other, or what the projects are trying to
do that's so different from each other.

Sure, competition is good - but wouldn't pooling resources be better?

~~~
vetinari
Flatpak and Snap have some different approaches, both come with pros and cons.

The first difference is centralization vs. decentralization. Snap is
centralized, there's no way to make your private repos fully under your
control. If you want private snap repo, you must talk to Canonical. From the
user perspective, there's are no competing snap repos, only the Canonical one.
They also support update pushing, so users will get updates whether they want
them or not. This is a huge departure from the way apt/yum repos were managed.

This mirrors in the runtime support: snaps have centralized core16 / core18
runtimes or whatever Canonical comes with. Flatpak runtimes are decentralized
and everyone can make one. You can use org.freedesktop.Platform,
org.gnome.Platform, org.kde.Platform, maybe in future there will be
org.centos.Platform or even something entirely different.

Flatpak focuses on desktop - their main method of app integration are .desktop
files and dbus names. Snap allows arbitrary applications, including services
or cli apps. This impacts the visibility from outside the sandbox: flatpak
uses namespaces, so outside you won't get to see the private bind mounts that
the containers use. With snap, your mount namespace is polluted with the
squashfs mount points.

For sandboxing, Flatpak uses namespaces and secomp, with optional SELinux.
Snap requires AppArmor, but packages with confinement: classic are not
sandboxed at all.

Flatpak uses OSTree to store the app, framework or addon files. OSTree is
often called _git for binaries_ , it is content-addressable repository with
checkouts and pulls. Snaps are squasfs images.

Things they have in common: both are sandboxed (except classic snaps), that's
why the first launch is slower than unsandboxed applications. There are some
things, that are being done, for example font caches are being created, that
the unsandboxed apps do not have to do, because the host environment already
has them. Both allows you to target a specific runtime/SDK, so there's no
surprise for the app at install or runtime. Both have a permission system,
that can control, how the app can interact with other apps or host, though the
permissions currently defined may differ.

~~~
simosx
Snap is not "centralized". It comes with a default Store, and this helps most
users that require modern package management.

If you want to distribute manually your .snap packages, then you can certainly
do so.

For example, the libreoffice snap is easily available for download at
[https://uappexplorer.com/snap/ubuntu/libreoffice](https://uappexplorer.com/snap/ubuntu/libreoffice)
The recipe to create the snap package is shown on the same page. You can
recreate the snap package and then keep it for yourself. Or, upload it to your
website and share with your friends.

After you download the .snap package, just click on it and it will prompt you
to install it.

What you do not get with snaps, is the source code of the Ubuntu Store. Most
likely, if someone is really interested to replicate the store, I believe it
is easy to reverse-engineer, then create a reference implementation.

~~~
vetinari
That's somewhat disingenuous comparison.

Snap, as an ecosystem, includes not only the .snap package, but also the
remote side, equivalent to apt/yum. Even if you do not want the store
equivalent, just plain old repo, you cannot do that with snap. You would have
to replicate all the add repo/check for updates/install/update logic on the
client side too - snap won't allow you to register your repo, _even if you had
your server side solved_ (side note: for apt, yum, flatpak, plain old httpd
server is enough).

Therefore, when comparing with flatpak, which does allow remote-
add/delete/info/ls/update, snap is centralized. The "you can code it yourself"
is not an argument; you can code yourself equivalent to many other proprietary
systems, and that does not make them open or less limited.

------
unixhero
The key here is which of the formats can I trust the most? Which one of these
are likely to betray me?

~~~
simosx
You will most likely get a malicious AppImage from some website because there
is no default central store with such packages.

You could argue that there is a freedom with AppImage that you are not bound
to a Store. But that would not be correct, because you can self-host both
snaps and flatpaks, if you really need to.

With snaps, you have more fine-grained security privileges. For example,
"httpstat" [1] is a network utility to benchmark the access to a website. As a
utility, it only requires access to the network. With snaps, the packager can
only permit access to the network, and no access at all to the user's files or
anything else.

1\.
[https://github.com/davecheney/httpstat](https://github.com/davecheney/httpstat)

~~~
app4soft
> is no default central store with such packages

And this is limitation of Snap and Flatpack - both stored in centralized
stores.

AppImage is fully independent from any centralized stores, so developers could
distribute own apps as AppImage-package _directly_ to users.

~~~
simosx
I said that there is no "default" central store for package in AppImage. Which
means that there is a "default" central store for snaps and flatpaks.

And if you do not like the "default" central store, you are free to distribute
yourself the individual snap or flatpak package. Just like with AppImage.

~~~
AnIdiotOnTheNet
Sure... by making the user setup the equivalent of a PPA. AppImage's advantage
is that you can mail it to them on a CD and they can just run it _from the
CD_.

~~~
simosx
Damned if you do, damned if you don't.

Regarding the reference to "like mounting the CD ISO" for AppImage. All three
of them actually mount one or more filesystems in order to install the
package.

