Universal Linux Apps/Packages (Flatpaks, Snaps, AppImages) seem to get a lot of hate in the Linux community, but why?! In this video, I talk about why this type of technology is not only necessary, but a good thing.
Why Universal Linux Apps are GREAT!
I noticed your cam was adjusting the exposure a lot; I think if you can make it manual and set it at the beginning of your recording session, it would be a lot nicer.
I’m putting this here, because YouTube keeps yeeting my comments.
It’s not fit for the purpose of having any kind of discussion in their comments anymore.
Lots of applications have their own repos that they maintain themselves, as well as tarball installs. For Blender, for example, I only use the tarballs right from blender.org. My dad uses the developers’ own repos for important applications like PostgreSQL that he needs to keep specific versions of. For LibreOffice, we got it from their own repo to keep the latest version (we don’t have to anymore, now that we use Manjaro on our workstations).
We don’t run any flatpacks, appimages, or snaps, but we do run some things, like our GitLab, in Docker containers (on our Synology NAS).
Thanks for making this video @jay and giving us your take on Universal Linux Apps. One point that really has me thinking, is this separation between the base OS and user land apps. My two favorite distros have been playing in this space for a while, and yet have approached in different ways.
MX Linux building on Debian stable, but has maintained a MX Community repo for apps that they keep up to date like the latest Firefox, Featherpad (their default GUI text editor and their MX specific apps). They have also added Flatpak support to give desktop users newer apps on a stable platform. Their package installer can also do some added trickery that allows you to activate testing repo and then shut it off again so that your whole system doesn’t get updated to testing.
Fedora is experimenting with Silverblue, which I currently have zero experience with, but seems to attempt to separate base OS from user land using OStree technologies I believe.
In the server world, we have become comfortable with image repos that we pull down docker images and run on our systems putting all of our server apps into containers which separates the base OS from the apps on a server.
I’m thankful that you pointed out some of the short comings of Universal Apps too. You did a good job of pointing out where universal apps could improve.
One point that former Ubuntu employees (on the Ubuntu Podcast) have pointed out about why the snap store is closed source revolves around the experience Ubuntu had with Launchpad. They went through all of the work to get the code in a state where Launchpad could be released as an open source project. They released it. No one adopted it. They felt the developer time invested in getting Launchpad ready to be open sourced just wasn’t worth the expense. As they look at the landscape of universal apps, and flatpak repos being open sourced, yet only Flathub has emerged as a repo to be used regularly, they probably figure getting the snap store ready to be open sourced just isn’t worth the investment of developer time once again. Why go through the hours of code clean up, documentation, and other tasks if no one would set up a snap store that would help the snap ecosystem. They have probably done the spreadsheet at Canonical and it just doesn’t move the ball forward for snap adoption.
Surely, a bad actor could corrupt a distro’s repo with spyware or crypto miners, but each distro seems to put practices into place to avoid this. How do we know we can trust Flathub, SnapStore, Docker.io, Linuxserver.io, Quay.io … or the random website where you find an Appimage? Random websites have released Windows spyware and viruses. Perhaps with Canonical shepherding the snap store this is perhaps a good thing, and another reason not to open source the snap store. With the developers of Linuxserver.io shepherding their repository that’s a good thing. I would like to play with containers, but at the same time I don’t want to build every container from scratch, but when I find a random container with the web app that I want to self host on Docker.io that isn’t one of the official ones, how do I know that I can trust it? I’m not a developer, I can’t evaluate code easily, I’m just a lowly Linux user and advocate. We are encouraged, trust, but verify. I struggle with the verify when it comes to the sources of the software that I run on my Linux machines.
I think that’s a big issue; when somebody decides to publish a containerized or “universal” app, they’re taking responsibility for all the components they include. That means they need to be following security bulletins and updates for all those components and issuing updates.
There’s also the issue of how do we, as users of those apps, easily know what the components are. I think there should be a utility that works like how “pip freeze” does for Python virtual environments. If it’s built into the container host or universal app installer, it go a long way to helping us properly understand and manage them.
I think there also needs to be gpg/pgp signatures integrated into those repos.
I would take any comparisons with Launchpad with a grain of salt. For how much I like Ubuntu as a distribution and as a base for other distributions. Launchpad was developed during Canonical’s lowest point. They were really struggling with who and what they were as a company.
They were founded with a huge emphasis on community. By the Launchpad era, Shuttleworth was trying to figure out how to get his rather large investment in canonical to turn a profit.
Remember Bazaar, It was a custom-built source control system Canonical tried to create which they then tried to force launchpad users to adopt. They spent hundreds of thousands of dollars trying to reinvent a source control system that was overly complicated and didn’t quite work.
Most, if not all, open-source companies have had their Baazar moments as they navigate the line between open-source ideals and profitability.
Snap is trying to solve a very real problem. Package fragmentation is probably the single largest source of friction within the open-source ecosystem.
On the other hand, the similar but not quite the same nature of the various distros creates a very competitive environment where the various distro are innovating and learning from each other.