Revolution or evolution: What is the future of cross-distribution software installation?

There is no easy and universally agreed-upon method to install software in the GNU/Linux ecosystem. This has caused many hours of frustration for beginners and enthusiasts alike and is - I believe - one of the primary reasons why Linux distributions are not adopted more widely.

Is it because some Linux enthusiasts have all too willingly come to accept that using GNU/Linux is not for everyone and have found comfort and satisfaction in being part of a dissident minority? Are missionaries (those hoping for wider Linux user adoption) the recent driving force behind the “Linux for Everyone” distros and the new blessings of package formats with universal ambitions such as Snap, Flatpak and AppImage? Are the recent developments of software packaging as revolutionary as they are sometimes advertised or part of an evolutionary process that the less historically conscious tend to overlook? How soon are cross-distribution packages going to be the new default way to install software?

I have been thinking about this a bit and this is where I am up to now:

If snap-type packaging enables packages to be installed easily across different distributions and across different version of individual distributions, that is a good thing.

If snap-type packaging causes some redundancy of data on hard drives due to replicating dependencies this is, in my opinion, a fairly neutral thing since I cannot imagine it is likely going to hit any kind of resource buffer in terms of hard drive space.

If snap-type packaging causes some of the code to be more black-box-like and so be less accessible to users to inspect, this is a bad thing.

Technically speaking, AppImage and xdg-app (now known as FlatPak) has been around long before Snaps ever were a thing by Canonical. And avid users had been using git for updating software via repo syncs and pip for installing software.

These formats and methods alone do not bother me. It’s the standards competing for ubiquity that frustrate me, because each format has strengths and weaknesses associated with them, even though they essentially do the same thing. It’s like everyone trying to patent the same idea without legal authority that drops the hammer for which patent wins.

For cross-platform distribution to succeed, there has to be one format for people to use, but that runs steadfast against the spirit of open-source, where people can make an improvement upon an existing idea by iteration. I am sure if it were up to most old-school Linux users everyone would be on the latest version of Slackware and using tarballs, instead of having to screw around with competing shared library methods that also have their own strengths and weaknesses. Even then, iterative systems that build from that one system would certainly have package incompatibilities, leading to the kind of dependency hell that users shouldn’t ever be burdened with. (It still happens, but it’s easier to deal with it on systems with frontends for package management backends.)

Since I know nothing about Flatpak, let me run through what I know about the others;

  • Snaps
  • Canonical intends for this to be the universal independent package format
  • Developers can build from a variety of locations
  • Most developers may end up using snapcraft.io for hosting
  • May cause duplicate libraries to be installed
  • AppImage
  • Intended for app portability between systems regardless of distribution
  • Has already a large application repository
  • Puts the onus upon users to update, not a software manager
  • Linus Torvalds thinks it’s awesome

So AppImage was created for user convenience, while Snaps (and maybe FlatPak also) appears to be created for developer convenience. None of this is awful. In fact, a lot of it is pretty good, and it isn’t like Windows doesn’t have multiple methods of installing software, from being able to sideload store apps, to using binaries with different installation software, to Microsoft Installer (MSI) files. They generally do the same thing, and they generally act upon the Windows Registey and Windows filesystem in the same way. The difference between what’s in Windows and what’s going on in Linux is there’s no central management utility, or even a way to report to a central management utility.

As for what Steve mentioned, Snaps may be encouraged to developers of non-free software for the exact reason it could be “Black-boxed” and rendered non-open. Contrary to popular belief, I say whether or not this closes off third-party developer accessibility doesn’t matter, because if somebody really wants to keep prying eyes away from their code they’d use a different format anyway which would permit such a thing. Even GitHub sources can be rendered private and inaccessible to the general public should one choose it.

5 Likes

On the other side, this self-contained “boxing” - if I understand it correctly - prevents other apps from recognizing what software is installed on the system and thus increases security?

I’ve just taken a look at some info on Appimage on the Ubuntu main site. Man, it sounds really easy to use, actually.

Okay, I have just been messing around with appimages and snap packages

musescore as an appimage:

Tiny interface such that the menu icons could not be made out nor could they be adjusted. The score document was also a tiny portrait in the top left corner of the interface. Could not be adjusted for size

search for Scribus as a snap package

Did not return Scribus. Returned a significantly inferior alternative instead. Did several other searches of applications I regularly use. Most of them were missing

So, at the moment, these alternative systems are either faulty or inferior in terms of application choice. That is not to say that wont improve. But, for the moment, not good enough to use and rely on, at least for me

Snap development started before xdg-app, now Flatpak. AppImage has been around longest.

Snap and Flatpak are not just focused on cross distro installation, but also tight application confinement. AppImage has no confinement.

Snaps are (being) designed to support any application type, from console, to GUI using any toolkit and servers. Flatpaks are targetted at GUI applications only, specifically GNOME3.

Snaps and Flatpaks can be installed from central repositories and be updated via those repositories, this is very similar to the apt-get or yum/dnf paradigm we are familiar with. Snaps and Flatpaks can also be downloaded from a vendors website and installed locally, with no update mechanism other than manually installing a newer package at some future date. AppImage only supports the manual download and install model.

Snap and Flatpak support runtime or content snaps, meaning Snaps and Flatpaks can share common libraries and other assets without having to duplicate common stuff in multiple packages. AppImage doesn’t support this.

Just my thoughts on whatchas been discussed. And snaps do a whole lot more besides. I think these new packaging paradigms are more evolution than revolution and long overdue.

12 Likes

Hallo

Typical Wimpy, a full of focused facts. Thank you. :slight_smile:

Two things…

Software.
Well it has to be written by someone. Who? People. All the people on this planet share one common asset - each day is 24 hours long. I write a program, its nice, people are going to want to use it, but packaging for linux - not so easy. Doing it for all the different formats? Well for some programmers that might be just too much. So they do one, and publish the source code for the others to compile if they want to. But, today, and in the future, how many linux desktop users can-do-want to compile programs into working binaries? As linux on the desktop becomes more popular this percentage will continue to decrease. So attracting new young programmers to the linux (FOSS) ecosystem in a way that their work has the maximum potential benefit would definitely be supported by a universal packaging system.
But this is a “big change”, yes - but what are systemd and Wayland/Mir?
The young code writers could code for so many platforms, windoze, OS X, Android, IoT devices, embedded devices, large systems… if we want to continue to be able to attract these people to code for the linux ecosystem we don’t need to keep the old barriers doggedly in place. If you don’t evolve you confine yourself to yesterday, therein lies no future.

Views from other distribution leaders
One recent podcast gave some interesting insights…

(http://ubuntupodcast.org/2016/08/11/s09e24-elementary-penguin/)

The discussion of the snapy packaging system begins at 11 minutes and twelve seconds.

If this meant that I’d never again have to use “alien” to install ProjectLibre (https://ubuntu-mate.community/t/how-to-install-projectlibre-a-professional-grade-project-management-tool-on-ubuntu-mate/4650) I would call that “user friendly”, and that is important.

Once again, a simple thank you to all those who wrote, write and will write code for the GNU/Linux ecosystem. :slight_smile: :penguin:

1 Like

Very informative. I only started hearing about Snaps on LUP, hence why I thought xdg-app was first. That and it was rebadged so I thought it was a reactionary rebadge because Snaps came after.

Very welcome to have a thoughtful schooling like that.

It is great to read through this wealth of information and I am learning more about software installation every day. Thank you all for the extensive commentary.

I have another question regarding the installation of snap packages. Why is it required that I sign in with an Ubuntu One account? This reminds me very much of the forced sign-up process with GooglePlay (not so with F-Droid) on Android and the Windows Store in Windows 10.

You don’t need to be signed up to Ubuntu One to install snaps, as far as I am aware

You can go to a terminal and type:

sudo snap install

Also, Ubuntu One has ceased to exist.

http://voices.canonical.com/ubuntuone/2014/04/02/shutting-down-ubuntu-one-file-services/

What have changed in the past 2 years?
What about performance wise, how do all 3 solutions compare?

What about making Flatpak first class citizens in Ubuntu MATE like it is done in Linux Mint (Namely through the Software Manager)?

I’m really liking appimages. They are 100% portable. You just download the appimage as a single file and that’s it. You don’t actually “install” an appimage. Everything, including all dependencies, is all zipped up in this “single” file. You just download, make executable and execute.

Having said that, I don’t know what security issues, if any, there are with appimages. But, they seem, on the face of it, to be about as universal as it gets in Linux.

Here is a list of currently available downloadable apps:

https://appimage.github.io/apps/

3 Likes

Maybe some people benefit from this appimages, flatpack… but me … I don’t have any problem with Linux application, the main problem in Linux is Desktop Distributions and Kernels, witch means poor support on latest hardware, the OS does not run smoothly, because of different video issue, hardware acceleration, power management, and messy code as it gets more complex than an app. Par example on one of my laptop from probably 3 years if I connect an external monitor I just feel on boot when is time to login, so I type the password and after enter and I know it works, because the hassle of just taking out the external monitor before boot is too much just have lightdm display the dialog. If I count all the issues the OS, Distribution has, that some of them will never get fix, so this is why Desktop on Linux can’t get seriously for some people to be adopted, and second missing of proprietary apps that are available only on Windows and under wine run poorly or not at all. One some fault is not Linux community, we can blame NVIDIA, but in the end the user does not care… he wants something running well

Well, one could make the argument that if the freedom (and responsibility) for inclusion of dependencies for applications is handed over to application developers in the form of these portable application methodologies, this leaves the developers of the distributions more time to focus on straightforward hardware compatibility and purely desktop management issues because they are no longer compelled to be all things to all application developers.

In short, all they have to do is provide a stable platform without having to always second guess which dependencies are most likely to be required by application developers.

Thank you for the url.
It shows what I suspected: not many applications. My favorites are missing. Qbittorrent, unetbootin, gkrel, clipit, thunar, nemo, etc.

Similarly when I also check what is available in snap, appimage & flatpak. So much is missing. Looking forward to the years that Linux gets its act together. Very aged in years myself now. So just coping with the remaining months ahead now, in my nursing home lifestyle.

I agree, the list of available apps is currently limited. But, that list is now starting to increase and I expect the rate of increase to rise. Certainly there are many more than this time lat year. But, until it reaches a critical mass, there is still, as you say, the the good old standby of distro repositories. So it’s all good.