Comparing LibreOffice Versions: AppImage, Flatpak, and Snap
ubuntubuzz.com
ubuntubuzz.com
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...
... 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.
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.
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.
P.S. launched from a terminal, gjs start instantly tho
LibreOffice/OpenOffice instead, from what I can remember, I've always found it slow on startup. ^__^
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.
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.
As an aside, I've been trying out Ubuntu for the last 6 months, and this is one example of the lack of polish I'm seeing. I don't remember installing gnome-characters explicitly (it's possible I just forgot doing so), but there are two versions on my machine, one of which happens to have this crazy startup lag. Another annoyance is that firefox came installed as a snap, which meant that all of my downloads went to something like ~/snap/firefox/Downloads instead of the expected ~/Downloads. I don't remember these kind of things happening when I ran Fedora...
It's high on my "hope it fails" list of Linux software. Sorry everyone who works on it :-(. General idea's good, but back to the drawing board, please. Or not and I'll just be less happy with any distros that push it on me, I guess.
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).
Of course, you need to work a bit in creating the snapcraft.yaml configuration file in the first place.
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
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.
Unfortunately Redhat is officially supporting flatpak and Ubuntu is officially supporting snap.
There are there these huge mailing threads where they talked about why they wouldn't adopt one of the existing ones (zeroinstall, appimage, etc)
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?
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)
Here is their initial announcement, 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 You can see the usage stats and also the list of other JetBrains packages.
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.
Apart from that Flatpak is largely, but not exclusively, a Gnome effort while Snap is backed by Canonical and Ubuntu, though again not exclusively.
That's a statement of fact but usually in these discussions it's uttered as a value judgement. The ensuing discussion creates much more heat than light.
Both snaps and flatpaks require a core image (a rootfs), and each package sits on top of that rootfs.
For snaps, there is the core16 (and core18) images, which have quite a lot of shared libraries. Your snap package simply contains your program and any other extra libraries that are missing from the core image.
These cover the case for daemons quite extensively.
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.
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 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.
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.
uApp Explorer is not affiliated with Canonical and does not host any apps. uApp Explorer only displays publicly available information about the official Ubuntu Touch appstore.
Welcome to Linux.
That said, they're both still package managers as far as I'm concerned and don't really offer any significant advantages over those over-engineered abominations.
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.
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.
https://blogs.gnome.org/alexl/2017/02/10/maintaining-a-flatp...
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.
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.
When apt updates libxyz.so and fix some vulnerability (think of exploits for JPEG decoding libraries) you have to wait for the authors of the appimage, flatpack and snap to distribute a new version with the update. That's likely to happen after apt did its job. You'll be vulnerable for a longer time.
I confess that I don't know if those other formats autoupdate like apt does or it's a manual user operation. In the latter case, you might be vulnerable for a long time. So, which one you can trust most? The one that autoupdates, if any.
When looking at this aspect, I think it's important to remember that users can often conflate apt-from-the-distribution with apt-from-a-third-party-repository.
What you've said is true if a user is using a distribution-provided package using apt.
If the user has installed from a third party repository using apt, and that repository has bumped the version of a library because it needs a newer version (this is quite common), then the user is dependent on the third party author to fix the library for security, just the same as a flatpak or snap.
However, in the case of the snap (not sure about the flatpak), at least the impact of an insecure library is limited to within the sandbox. Third party apt repositories do not benefit from any sandbox.
This is perhaps obvious to you, but I think it is misleading to users in general to not separate the two cases. "apt is great for security because you don't have to wait for the upstream author" is not true for third party repositories.
For Flatpak the updates are automatic, at least on the version I'm using with Debian Buster.
In my opinion they care enough about vulnerabilities (but I would say it depends on the packager), currently the Flatpak Evince doesn't have support for PS files (so for now only PDF) for security reasons (I don't recall the details, it's about the Ghostscript interpreter, there's an open issue on the BTS).
Edit: the issue https://gitlab.gnome.org/GNOME/evince/issues/1058