9 ms·

Comparing LibreOffice Versions: AppImage, Flatpak, and Snap

53 points by app4soft 7y ago

robotmay 7y ago
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).
- simosx 7y ago
  For snap packages, you can use the build servers at https://snapcraft.io/build https://snapcraft.io/build Point to your github repository with the snapcraft.yaml file and it will create the snap package for you. I think the publishing is very straightforward, and you can get a new package published very quickly. Of course, you need to work a bit in creating the snapcraft.yaml configuration file in the first place.
- app4soft 7y ago
  For AppImage packages, follow AppImageKit instructions.[0] You can use Travis CI servers (.travis.yml file in your repo on GitHub) with linking linuxdeployqt tool.[1] For deployment built files back to GitHub as assets also use uploadtool Shell-script.[2] [0] https://github.com/appimage/AppImageKit https://github.com/appimage/AppImageKit [1] https://github.com/probonopd/linuxdeployqt https://github.com/probonopd/linuxdeployqt [2] https://github.com/probonopd/uploadtool https://github.com/probonopd/uploadtool
- loginwithgithub 7y ago
  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 7y ago
    Take a dozen such applications, then have a security vulnerability show up in a core library. Still simple?
    - AnIdiotOnTheNet 7y ago
      Yes, it just isn't "secure" as far as the security-for-the-security-gods types are concerned.
      - loginwithgithub 7y ago
        It depends on how often the stuff in the packages gets updated, not on the package format.
edent 7y ago
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?
- simion314 7y ago
  Flatpack was started from a Desktop/GUI/GNOME perspective so you will have a better experience with snap if you want to package non GUI apps. I personally don't care and a .tar.gz is good enough for me if it works (as an example I use Intellij from a tar.gz installer, is simple and it works)
  - simosx 7y ago
    On Intellij, JetBrains are producing themselves snap packages for their whole range of products. It makes it so easy to install on your system, and updates happen automatically. Here is their initial announcement, https://blog.jetbrains.com/idea/2017/11/install-intellij-idea-with-snaps/ https://blog.jetbrains.com/idea/2017/11/install-intellij-ide... Here is the snap package page for Intellij Ultimate, https://snapcraft.io/intellij-idea-ultimate https://snapcraft.io/intellij-idea-ultimate You can see the usage stats and also the list of other JetBrains packages.
    - simion314 7y ago
      Thanks for the information, I don't think that for my use case is is an improvement, though I use snap for skype if I am not mistaken and that use case fits perfect since I don't trust Microsoft in general and Skype especially. A bit off topic, some advice, don't update your IDE during your work week, sometimes something won't work and you will waste time trying to fix it, I learned my lesson and I download the new version .tar.gz and start using it, if something goes wrong I can go back to the previous version and look into finding a fix later.
- 7y ago
padraic7a 7y ago
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 7y ago
  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.
  - simosx 7y ago
    Most likely it is a preload issue. With the apt version, the libraries are already preloaded on your system, because they are shared and in use. With the snap version, the application needs to load up the common core image, then load the set of libraries that are specific to the application. The core image can probably get preloaded, but the set of libraries that are specific to the application probably not. Definitely in the disk cache, but maybe not preloaded.
    - IronBacon 7y ago
      I would say it's slow the application itself (it uses the Gnome Javascript interpreter), I've never noticed before but on my desktop, for example, the flatpaked Gedit is faster to start than non-flatpak gnome-characters version. P.S. launched from a terminal, gjs start instantly tho
      - loginwithgithub 7y ago
        The AppImage is still twice as fast as the Flatpak, and three times as fast as the Snap. So it can't be the application itself, can it?
unixhero 7y ago
The key here is which of the formats can I trust the most? Which one of these are likely to betray me?
- app4soft 7y ago
  IMHO, you should trust AppImage - as it fully portable (if you would not integrate it in your system manually), like mounted ISO-images.
- simosx 7y ago
  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 7y ago
    > 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.
    - the_why_of_y 7y ago
      Snap is centralized; anybody can host their own Flatpak repo, it's just files served over HTTP. https://blogs.gnome.org/alexl/2017/02/10/maintaining-a-flatpak-repository/ https://blogs.gnome.org/alexl/2017/02/10/maintaining-a-flatp...
    - simosx 7y ago
      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.
upofadown 7y ago
>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...
- abrowne 7y ago
  One reason would be to a get a newer version than what your distro offers.
- simosx 7y ago
  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 7y ago
    > 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.
- loginwithgithub 7y ago
  You can run multiple different versions alongside each other, and you are not restricted to the version that your distribution happens to carry which is often outdated. Also, this gives you access to development snapshots
sandGorgon 7y ago
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 7y ago
  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.
  - AnIdiotOnTheNet 7y ago
    Good. There are way too many distros anyway.
  - teilo 7y ago
    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.
  - olau 7y ago
    Actually, the packaging format and tooling is only a very small part of the time spent by the people contributing to the distribution. Go read debian-devel - only a very few people are involved in those things. As far as I can tell, almost all the time is spent polishing and integrating packages and fixing temporary regressions, that sort of thing. RedHat and Debian have different standards for various aspects of the package contents, so you can't just use a package from one and expect it to work on the other, even if the package format and install tool was the same.

53 points by app4soft 7y ago

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).

simosx 7y ago
For snap packages, you can use the build servers at https://snapcraft.io/build https://snapcraft.io/build Point to your github repository with the snapcraft.yaml file and it will create the snap package for you. I think the publishing is very straightforward, and you can get a new package published very quickly. Of course, you need to work a bit in creating the snapcraft.yaml configuration file in the first place.
app4soft 7y ago
For AppImage packages, follow AppImageKit instructions.[0] You can use Travis CI servers (.travis.yml file in your repo on GitHub) with linking linuxdeployqt tool.[1] For deployment built files back to GitHub as assets also use uploadtool Shell-script.[2] [0] https://github.com/appimage/AppImageKit https://github.com/appimage/AppImageKit [1] https://github.com/probonopd/linuxdeployqt https://github.com/probonopd/linuxdeployqt [2] https://github.com/probonopd/uploadtool https://github.com/probonopd/uploadtool
loginwithgithub 7y ago
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 7y ago
  Take a dozen such applications, then have a security vulnerability show up in a core library. Still simple?
  - AnIdiotOnTheNet 7y ago
    Yes, it just isn't "secure" as far as the security-for-the-security-gods types are concerned.
    - loginwithgithub 7y ago
      It depends on how often the stuff in the packages gets updated, not on the package format.

edent 7y ago

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?

simion314 7y ago
Flatpack was started from a Desktop/GUI/GNOME perspective so you will have a better experience with snap if you want to package non GUI apps. I personally don't care and a .tar.gz is good enough for me if it works (as an example I use Intellij from a tar.gz installer, is simple and it works)
- simosx 7y ago
  On Intellij, JetBrains are producing themselves snap packages for their whole range of products. It makes it so easy to install on your system, and updates happen automatically. Here is their initial announcement, https://blog.jetbrains.com/idea/2017/11/install-intellij-idea-with-snaps/ https://blog.jetbrains.com/idea/2017/11/install-intellij-ide... Here is the snap package page for Intellij Ultimate, https://snapcraft.io/intellij-idea-ultimate https://snapcraft.io/intellij-idea-ultimate You can see the usage stats and also the list of other JetBrains packages.
  - simion314 7y ago
    Thanks for the information, I don't think that for my use case is is an improvement, though I use snap for skype if I am not mistaken and that use case fits perfect since I don't trust Microsoft in general and Skype especially. A bit off topic, some advice, don't update your IDE during your work week, sometimes something won't work and you will waste time trying to fix it, I learned my lesson and I download the new version .tar.gz and start using it, if something goes wrong I can go back to the previous version and look into finding a fix later.
7y ago

padraic7a 7y ago

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 7y ago
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.
- simosx 7y ago
  Most likely it is a preload issue. With the apt version, the libraries are already preloaded on your system, because they are shared and in use. With the snap version, the application needs to load up the common core image, then load the set of libraries that are specific to the application. The core image can probably get preloaded, but the set of libraries that are specific to the application probably not. Definitely in the disk cache, but maybe not preloaded.
  - IronBacon 7y ago
    I would say it's slow the application itself (it uses the Gnome Javascript interpreter), I've never noticed before but on my desktop, for example, the flatpaked Gedit is faster to start than non-flatpak gnome-characters version. P.S. launched from a terminal, gjs start instantly tho
    - loginwithgithub 7y ago
      The AppImage is still twice as fast as the Flatpak, and three times as fast as the Snap. So it can't be the application itself, can it?

unixhero 7y ago

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

app4soft 7y ago
IMHO, you should trust AppImage - as it fully portable (if you would not integrate it in your system manually), like mounted ISO-images.
simosx 7y ago
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 7y ago
  > 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.
  - the_why_of_y 7y ago
    Snap is centralized; anybody can host their own Flatpak repo, it's just files served over HTTP. https://blogs.gnome.org/alexl/2017/02/10/maintaining-a-flatpak-repository/ https://blogs.gnome.org/alexl/2017/02/10/maintaining-a-flatp...
  - simosx 7y ago
    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.

upofadown 7y ago

>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...

abrowne 7y ago
One reason would be to a get a newer version than what your distro offers.
simosx 7y ago
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 7y ago
  > 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.
loginwithgithub 7y ago
You can run multiple different versions alongside each other, and you are not restricted to the version that your distribution happens to carry which is often outdated. Also, this gives you access to development snapshots

sandGorgon 7y ago

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 7y ago
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.
- AnIdiotOnTheNet 7y ago
  Good. There are way too many distros anyway.
- teilo 7y ago
  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.
- olau 7y ago
  Actually, the packaging format and tooling is only a very small part of the time spent by the people contributing to the distribution. Go read debian-devel - only a very few people are involved in those things. As far as I can tell, almost all the time is spent polishing and integrating packages and fixing temporary regressions, that sort of thing. RedHat and Debian have different standards for various aspects of the package contents, so you can't just use a package from one and expect it to work on the other, even if the package format and install tool was the same.