>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...
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.
> 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.
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
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.
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.
It's very annoying. Especially since the reason I use gnome-characters is because I'm in the middle of typing something and I need a character that's not easy to type on my keyboard, so it's already a distraction from what I'm trying to do.
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 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.
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.
Snap also pollutes my disk list to the point that, without further effort on my part, regular ol' "df -h" is basically unusable. And it seems to leave old versions of things like VLC hanging around, for some reason, judging from same disk list.
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.
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.
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
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).
For snap packages, you can use the build servers at 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.
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.
AppImage runs on Red Hat and on Ubuntu, and it is independent from both, so much more universal. Also, the smallest and the fastest according to the article.
Have you read the article? AppImage wins by a factor of two to three in terms of speed and size, runs on both Red Hat and Ubuntu. I'd say it is more universal than the distro-made formats.
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.
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.
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?
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.
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
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.
The big difference is that Flatpak is largely an open system while Snap is Canonical's personal playground they've deigned to invite you to if you follow the rules that don't necessarily apply to them.
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.
I don't know lots about the technical differences but if I understand it correctly snaps can be created for servers but flatpaks can't.
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.
The "snap for servers" was an issue so long time ago.
I do not think it is worth repeating.
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.
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.
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.
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.
"You will most likely get a malicious AppImage from some website because there is no default central store with such packages." - No. Just no. If you download the AppImage directly from its original author's website, then you know that no one has tampered with it and it is exactly as the original author intended. In contrast, look at Flathub. Most applications there are not provided by their original authors, but by "random guys". Who do you trust more?
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.
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.
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.
This is probably not the kind of trust you're asking about, but you should also mind about security
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.
> I confess that I don't know if those other formats autoupdate like apt does or it's a manual user operation.
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).
It's a question who you trust, not a question of the format. Personally, I would only run applications from original authors or projects I trust, and only directly from their download page. Not from some random 3rd party download site or app store. AppImage allows me to do that, with no 3rd party in between the author and me.
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...