Linux App Store Flathub Now Has Over One Million Active Flatpak App Users (9to5linux.com) 84
prisoninmate shares a 9to5linux report: Flathub is currently one of the most popular app stores for Linux serving 1.6 billion downloads of over 2,400 apps in the Flatpak format, of which more than 850 apps have been verified by their original authors. And now, Flathub proudly announced today that it surpassed 1 million active users of Flatpak apps. The team believes that the recent growth in users comes from several factors, including the availability of some very popular apps (e.g. Firefox, Thunderbird, VLC, Spotify, OBS Studio, Google Chrome, Telegram), support for new and verified apps, the inclusion of Flathub as the default app source for the Steam Deck's desktop mode, as well as the growing adoption among many popular GNU/Linux distributions like Fedora Linux, Linux Mint, KDE neon, and others.
Re: (Score:2)
Re: (Score:1)
Trashy low-quality software is the Windows feature that Linux has been missing all this time.
Re:Docker images, snaps, flatpaks (Score:5, Insightful)
We could perhaps make all the flatpak that use the same libraries, like share them. You know, to reduce package bloat, disk footprint and RAM requirement. We could call it "shared libraries" for example.
Flatpaks, snap, appimages... are all the same "performances be damned" approach to solving dependency hell. It's convenient, but if you have more than 5 to 10 of those packages running on your system at the same time, get prepared to buy a more powerful machine to get exactly the same performances as with a much leaner machine running regular, properly-packaged software.
Layers, large apps. (Score:4, Informative)
DISCLAIMER: I usually install most of the stuff from the package repository of my distro (Opensuse Tumbleweed, Manjaro ARM, Debian, Raspbian).
But...
We could perhaps make all the flatpak that use the same libraries, like share them. You know, to reduce package bloat, disk footprint and RAM requirement. We could call it "shared libraries" for example.
Jokes aside... that's very close to what Docker and Flatpak are doing. Docker works in a system of layers. (Most of the dockers people use would most likely be extending a ubuntu:latest base)
And Flatpaks are built atop of "runtime" (base system).
These app containers only differ in the main application running and its specific collection of dependencies which are not part of the base system.
are all the same "performances be damned" approach to solving dependency hell
They are not VMs. They are not entirely separate whole-system installs.
They are closer to provide a single specific set of common dependencies that an application can target.
You need to make sure that you application works successfully on top of the latest Flatpak runtime, instead of making sure that it works against a zoo of dozens of distro, each with slightly different set of library versions, some introducing subtle incompatibilities. It is thus closer to, e.g., what Valve' Steam provides for native Linux executables.
Yes, in an ideal world, you would like that the devs of your distro take the time to custom optimize and adapt the application and integrate them nicely with the specific library versions you have. (And hope that other devs similarly replicate this effort on other distros).
(I am lucky, nearly all what I need is available in this way from repos - so that's indeed how I install it).
But these container apps "built against a fixed base layer" is the next best thing before needing to go to "single app VMs".
It's convenient, but if you have more than 5 to 10 of those packages running on your system at the same time,
The prime target are applications which have a very large collections of dependencies (think large office suit like LibreOffice, rather than some lightweight text editor than doesn't depend on much more that the base Qt libraries).
You aren't very likely to run more that a couple at the same time.
And if you check the applications listed as example:
These example all support playing and/or recording media, and thus they all would need ffmpeg/libav or gstreamer and a bunch of codecs. .so (that's currently the case on my opensuse laptop).
Those things are sensitive to versions.
A distro dev would need to make sure that all of them are compatible with the exact version of libraries shipped in my distro (and patching around any bugs).
Or failing that, in practice lots of distros will ship several different versions of the shared libraries, with differing sonames, and you end up with 2-3 version of all multimedia libraries installed, differing only by the number tacked after
(This starts to look very close to how docker and flatpak handle this).
Next use case for docker and flathub (and an extra use for conda environment, for that matter): when you just quickly want to test one specific application that you're probably going to delete afterward, but don't want to install a zillion of specific dependencies for it, and are too lazy to also remove all the not-needed-anymore deps once you remove the app.
(I personally use a couple of containers this way. And use conda a lot for testing data analysis).
SteamDeck is another different use for this containers: it makes it possible to install apps while still keeping the root partition read-only, thus it brings a whole catalog of apps to newbie non-fluent in Linux, who would have otherwise needed to switch the
Re: (Score:2)
This is the case in theory. In practice, most apps ship with different runtimes.
For example, I have 3 flatpak applications (Whatsie, Xnview MP and Vidcutter) installed on my Fedora. flatpak list shows 3 different copies of org.freedesktop.Platform.GL.default, two of org.freedesktop.Platform.GL.nvidia, multiple versions of freedesktop platform.
And yes, I have got rid of unused dependencies using flatpak uninstall --unused
Re: (Score:1)
There are only a few libraries that it makes sense to share in the first place. Containerized apps can use shared libraries if they want. I'd rather have apps isolated and containerized because I don't f-ing trust them not to step all over each other's memory. Most package managers suck entirely due to shared library dependency hell.
Re: (Score:1)
> I don't f-ing trust them not to step all over each other's memory.
Boggle. You *really* don't have the faintest clue, do you?
Re: (Score:2)
Indeed. Somebody just failed OS design 101 and has never heard of process address space encapsulation. Shared libraries share code, not data.
Re: (Score:2)
Ahh yes, because there's NEVER been a security vulnerability in any set of libraries. Ever.
Oh wait, that's your go to "excuse" for hating on all of the containerized applications... "but what if the libraries ( and each copy ) in that application have a security vulnerability, you'd have to update all the containers hurr durr".
At least get your shit straight for fucks sake.
Re:Docker images, snaps, flatpaks (Score:4, Informative)
It's convenient, but if you have more than 5 to 10 of those packages running on your system at the same time, get prepared to buy a more powerful machine to get exactly the same performances as with a much leaner machine running regular, properly-packaged software.
I recently ran out of space on my root file system. Journald logs were the main culprit, but I was surprised to note that /var/lib/snapd dir was nearly 5GB. I also found a bunch of old snaps in there, showing that when you upgrade your system, it doesn't remove old snaps -- thanks Ubuntu. Even after removing old stuff, that dir still takes up about 3GB. Ugh!
Re: (Score:2)
Indeed. The whole idea is pretty stupid. When I want some software in Linux, I get it from my distro. If that is really not possible, I get a version that compiles under my distro and build it myself. It is like the people behind all that stupidity have no Unix real system administration experience at all.
Re: (Score:2)
We could perhaps make all the flatpak that use the same libraries, like share them.
Flatpak could be improved to install shims instead of complete libraries in cases where the installed library on a system is very close to what the app expects. Which would be most cases. The user should also be given the opportunity to install additional native libraries to enable such shims. Probably, in the vast majority of cases, these simple measures would result in being able to directly link to existing libraries.
Not that I'm expecting any sudden outbreak of sanity.
Re: (Score:1)
Slackware + Linux-Libre + Xanmod patches user here, very custom and Slack like, ok, but I use Flatpak for Total Chaos and some stuff not available on pkgs/slackbuilds. On resource usage, flatpak itself deduplicates a lot.
Re: (Score:2)
Note that at least with Flatpak, they are "libified" to a signigicant amount. You may have two applications that don't update at the same cadence, so they have different versions, but if the applications are consistently maintained, they should be similar.
Re:Docker images, snaps, flatpaks (Score:4, Funny)
Hopefully the next big thing for packaging apps is a .tar.gz filled with source code and a moderate amount of documentation.
I still don't get it after all these years... (Score:2)
Maybe I'm just a diehard but why install apps *especially* like Thunderbird, Firefox, etc. from a flatpack/snap/whatever when the distro's package manager has it? Even Debian isn't that far behind in versions for FF. v115-esr vs. v122 currently. I mean, I guess I get it if you need the very latest and don't wanna compile from source, but it just seems like a waste of time. Change my mind?
Re: (Score:2)
I don't get why anybody would want to install something using flatpack. It's going to be a disaster on the scale of systemd in terms of fucking things up.
Re: (Score:3)
Re: (Score:2)
The point of app bundles is that you don't "fuck up your system by mismatching libraries."
They're self-contained so they neither fail to work if the system doesn't have the specific version of a library they're looking for, and they also don't affect other things on the system by changing libraries. It trades convenience and reliability for disk space and maybe some memory use. That's offensive to die hard geeks, but it's pretty necessary if you want non- die hard geeks to use the system.
Re: (Score:2)
> It trades convenience and reliability for disk space and maybe some memory use
Also for security and auditability. ask aptitude which version of openssl is installed, apply critical security fix if available, all programs get it for free.
Except flatpacks/snaps/docker images, those have to be updated by their respective maintainers. There is also no way to ask into those containers whether they're running vulnerable versions of libraries.
https://www.paloaltonetworks.c... [paloaltonetworks.com] comes to mind. terabytes of cont
Re: (Score:2)
Not necessarily. Updates become the responsibility of the app package maintainer rather than the distribution maintainer. Distribution maintainers are usually pretty prompt about some kinds of security updates, but not necessarily others, particularly in the long term support releases. Some packaging systems are also sandboxes so they can improve security, or not, depending on how well they sandbox.
Auditability depends on how the package system is set up. The Mac's app packages are just directories and you
Layered design (Score:2)
Except flatpacks/snaps/docker images, those have to be updated by their respective maintainers.
Not quite.
Docker and flatpak works in layers.
Flatpak in particular has "runtime" - base systems - and is often well integrated into the package manager of the distro (e.g. on the Arch-based SteamOS running on the SteamDeck).
The SSL libraries are part of such base layers.
So if there is a bug fix, most likely you're going to see (either directly from your page manager, or when typing "flatpak updae") an update to "org.freedesktop.Platform.GL.default", "org.gnome.Platform", etc. runtimes, not the individual fl
Re: (Score:2)
So flatpack is basically a separate userspace, not managed by the package manager?
That makes it a bit different, although it kind of negates the binary compatibility advantage (as in not dependent on distro updates). Will a flatpack from today run on flatpack in 10 year's time?
I understand it as "a distro in your distro"
Containers (Score:2)
So flatpack is basically a separate userspace, not managed by the package manager? {...} I understand it as "a distro in your distro"
That more or less sums up how containers work.
The whole idea can be summed up as "chroots, but on steroid" (i.e.: better isolation), and just like chroot, each container is a different userspace.
(With different strategies to manage it.
With LXC, you would need to run that distro's tools (e.g.: pacman if it's Arch) instead of your host's tools (e.g.: aptitude, it it's Ubuntu).
With Flatpak and Docker you play around layers).
Will a flatpack from today run on flatpack in 10 year's time?
In theory, yes.
In practice that 10-years old flatpak will need a specific userland that
Re: (Score:2)
It trades convenience and reliability for disk space and maybe some memory use. That's offensive to die hard geeks, but it's pretty necessary if you want non- die hard geeks to use the system.
I was looking at installing a lightweight GUI editor for LaTeX. The "normal version" takes 1.2 MB. The Flatpack version is 4.6GB because it insists on incorporating the entire texlive-full distribution. That's a ridiculous amount of space for a tiny application, especially when the system already has texlive installed. Even worse, that extra 4.6GB of texlive that came with the package can't be used by anything else. That's not a trivial amount of diskspace... I can only imagine what happens when you ha
Re: (Score:2)
Lazy developers can write bloated apps.
A tex editor, at least one that includes rendering capabilities, isn't a "tiny application." It's a big one, you're just not counting the libraries it uses to do the actual work.
Even so, costs less than twenty five cents. For lots of people, the time they'd spend setting up and maintaining a tex environment is worth quite a bit more. Tex live itself is a project that exists to make setting up a tex environment easier.
Re: (Score:2)
I don't know about Flatpack, but I have started preferring snaps over debs. Ubuntu repositories keep out of date versions, and sometimes they are VERY out of date. To get up to date in those cases, I have to:
1) Find the website that hosts the program.
2) Add the key to apt from the command line.
3) Update apt from the command line.
4) Finally install and run the program.
This usually works, but then sometimes destroys the entire distribution upgrade later.
With the snaps, I launch Discover, search for the progra
Re: (Score:2)
Many useful applications are not packaged for anything but Ubuntu. For some reason certain developers are aggressive Ubuntu supporters and appear to be against producing other packages on principle. And the choice of libraries that will work with the application are so restricted that they will not compile against updated Fedora etc. So no choice but to ship older libraries.
Re: (Score:2)
I wouldn't even worry about Mozilla, who have working CI.
Who is taking responsibility for the minor apps which are shipping vulnerable libraries which the distro has already patched?
Re:I still don't get it after all these years... (Score:5, Interesting)
One of the advantages is that it provides some isolation which is an extra layer for security that is particularly useful for internet facing apps like Thunderbird and Firefox.
its not the only way to do it, but it is the most user friendly way and integrated with GUI package managers.
Re:I still don't get it after all these years... (Score:4, Interesting)
Maybe I'm just a diehard but why install apps *especially* like Thunderbird, Firefox, etc. from a flatpack/snap/whatever when the distro's package manager has it? Even Debian isn't that far behind in versions for FF. v115-esr vs. v122 currently. I mean, I guess I get it if you need the very latest and don't wanna compile from source, but it just seems like a waste of time. Change my mind?
I prefer to use the distros package manager when I can, however some developers have chosen Snap or Flatpak to be their preferred method of distribution so I respect that even if I don't like it. And compiling from source is great, but also the most difficult of them all in terms of keeping everything patched and up to date. Recently went to install Tor Browser. Looks like Flatpak is the maintainers choice, so Flatpak it is.
Re: (Score:2)
I prefer to use the distros package manager when I can, however some developers have chosen Snap or Flatpak to be their preferred method of distribution so I respect that even if I don't like it.
For example, Authy distributes the Linux version of their Desktop app only as a Snap -- until August 2024 anyway, when they're discontinuing all their desktop versions in favor of "focusing on mobile" (though I believe it will still be available for Apple M1/M2 systems).
I'll note that the ability to have my mobile 2FA mirrored/synced on my Windows/Linux desktops was my draw for Authy and now that they're ditching that, I'll probably switch to 2FAS ...
Two use cases (Score:2)
why install apps *especially* like Thunderbird, Firefox, etc. from a flatpack {...} Change my mind?
Use case 1: Steam Deck.
The console is designed with users who aren't seasoned Linux power-users in mind. To avoid the head-aches of support users who managed to utterly break their SteamOS installation, by default the root partition is mounted read-only.
Sure, power users like most of people on /. will simply switch root to read-write and install all they need with pacman from the regular Arch repo. And are probably able to debug why a subsequent SteamOS update has trouble installing and pin-pointing the pac
Re: (Score:2)
Not using your distro repos is just plain stupid. Because if you do not, you have to update that software yourself. Even compiling from sources against dristro shared libraries is better, because then you get at least the library updates from the distro. Sure, containers and the like are nice for experiments. But for stuff that needs maintenance? Utterly stupid.
Re: (Score:2)
Not using your distro repos is just plain stupid. Because if you do not, you have to update that software yourself.
Automatic updates for Snaps and Flatpaks are actually a thing.
Even compiling from sources against dristro shared libraries is better, because then you get at least the library updates from the distro
Until your software of choice built from source has multiple dependencies that also have to be built from source. Then it becomes tedious. No argument I'm fine with my distro repo, but it is one of several tools available to me, each with their own place.
Re: (Score:2)
Maybe I'm just a diehard but why install apps *especially* like Thunderbird, Firefox, etc. from a flatpack/snap/whatever when the distro's package manager has it?
I'm definitely an edge case here. I have an older version of Firefox that I use as a daily driver because I dislike the newest version for various UI reasons. That one was installed via a repo or a .deb - I forget which. But I need a newer version for banking, and obviously I can't run two fully-installed versions at the same time. So for that I'm running an AppImage.
I can see other instances where people might want to run more than one version of, say, a graphics or CAD program. For those, flatpaks and th
Re: (Score:1)
I was asking myself the same thing. The way I see this, creating a FlatPak is kind of like we used to compile with static linking; all the dependencies were there because they were included in the binary. It made for huge binaries but sometimes you didn't have the right to redistribute libraries so it was your only option.
Maybe I'm missing the point of FlatPak...
Re: (Score:2)
https://stackshare.io/stackups... [stackshare.io]
Re: (Score:2)
dumbing it down (Score:5, Insightful)
Re: (Score:2)
We are witnessing the iPhone-ification of Linux. Good thing I still have Gentoo.
+1 to that ... if I had Mod points
Still at stage1... (Score:2)
Good thing I still have Gentoo.
+1 to that ... if I had Mod points
Still waiting the "emerge slashdot/modpoints" to finish building?
Re: (Score:2)
It's just a more secure, more isolated way of installing apps.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Azure was fully compromised in 2023. The only thing that saved MicroShit's sorry ass was that the attackers were trying to not get noticed as they were spying. If they had wanted to do destruction, they could probably have been able to trigger a really bad world economic crisis.
Re: (Score:2)
Yeah, of course. More secure in theory.
Re: dumbing it down (Score:2)
Re: (Score:2)
Right. Flatpak does the opposite of improving security, by dramatically expanding the attack surface.
Re: (Score:2)
It actually is less secure, harder to maintain and entirely driven by cluelessness.
Re: (Score:2)
Re: (Score:3)
Linux needed something way to create 1 install package and that worked. I don't love flatpak, but it's better than snap.
What is needed is say install a game today, and install a game on new box 10 years later and it still works. (or even just works in first place is rare without dinking around with drivers/mesa/vulkan/etc)
i'd still prefer a .rpm or .dep over flat pack but if this just works, and always just works, perfect.
Re: (Score:2)
If security plays no role at all, it will work. In the real-world, not so much.
Re: (Score:2)
What is needed is say install a game today, and install a game on new box 10 years later and it still works. (or even just works in first place is rare without dinking around with drivers/mesa/vulkan/etc)
That doesn't seem to be realistic. It gets to be too hard to build old libraries, apparently. I've tried to do a certain amount of that and gave up. Remember the Loki games for Linux? Familiar with Loki_Compat? Even WITH that, some of those old games don't work any more.
Here's what I think is a better solution: We need more effort put into video drivers for QEMU. This is something I'd actually be willing to chip in for, and I suspect many other users but also more importantly organizations would also be wil
Re: dumbing it down (Score:2)
Linux had a way with AppImage but Red Hat and Canonical were offended by a technology they do not own and control.
I invented Flathub .. (Score:3)
Flathub is a stupid name! (Score:4, Interesting)
When are Linux developers going to understand that you don't name thing based on a technology they may use? Like all these Kdenlive and KOffice like crap? All it does is tie you to that technology, distracts from the purpose of the software, and makes it seem unserious, like the people running it are engaged in a religious war, which you may, but you shouldn't advertise that. "Flathub" doesn't even suggest it's an app store at all, you have to know what the technology "Flat" is referring to!
Anyway, marketing rant aside, Flatpak is the one implemented as Docker images, but with some additional features for desktop integration. This is such an overcomplicated, bloated way of running installing and running apps, and should be shot and put down.
Snaps are the right way to do it, or APPX on Windows. Nice and simple and easy, tailored to the task at hand.
To those asking what the purpose of flatpak and snaps are, it's similar to installation via the Windows Store (APPX), where the installation is not a series of "Install X file here, register this in registry, execute command..." but a simplified packaging where all your files are simply stuffed in an security isolated location with less ability to customize. Shared objects (.o or .dll on Windows) are stored with the app, and only become truly "shared" if they perfectly match a version that exists in the system or another app. That eliminates a lot of DLL hell. Since apps can't install their files anywhere they want, even within the user's profile folder, apps are better isolated.
Re:Flathub is a stupid name! (Score:4, Interesting)
Re: (Score:2)
It's like all the unoriginal fucks who decided *arr was the suffix for all your download crap.
Lidarr
Sonarr
Radarr
Readarr
Prowlarr
Bazarr
Cleanarr
Compressarr
Doplarr
Grabarr
homarr
Notifiarr
recyclarr
tdarr
etc
Re: (Score:2)
Kdenlive is pretty good.
Re: (Score:2)
It is? I have no clue what it is.
Re: (Score:2)
It's a video editor. It's reliable. DaVinci Resolve is a more powerful product by all accounts (and has a free version for Linux) but that reportedly only works properly on mainstream distributions (Debian or Fedora based) and with Nvidia (it has CUDA support.) Works fine on Nvidia/Devuan from what I can tell, I haven't done as much with it as I intended so I can't really speak to what happens when you push it. Kdenlive will work fine on gentoo with AMD graphics or whatever.
Re: (Score:2)
Have you used snaps? They don't even integrate properly with the OS. They write files to weird locations and have trouble accessing the normal ones. And that's in addition to the problem that Ubuntu is the sole source, they saw what Apple did and wanted to be like that. A couple versions of Ubuntu with snaps were enough to drive me away to Debian. Then a couple of problems with systemd almost immediately drove me to Devuan. I had only really been using Ubuntu because it made Nvidia easy, and these days Nvid
Re: (Score:2)
No, I don't use snaps. Or flatpaks when I can avoid it. I didn't know snaps touched the system. Maybe it's only APPX that does it right.
It can be useful (Score:5, Interesting)
It can be useful for apps which are dropped by distributions. For example on Debian zenmap (gui version of nmap) is no more. The easiest way to get it is a flatpak.
A more important app for me was displaycal as I need a colour managed display for photo editing. It had become useless as hadn't made the transition from python2 to python3 and no longer worked. A flatpak version solved that very nicely for the period before a working version again became available in a distro repo.
I agree that it's pretty much pointless using flatpaks for apps easily available in the same versions in distro repos but for me it has been occasionally incredibly useful. It's also quite useful for trying out a different version of an app. For example maybe you run a stable distro and would prefer not to mix in testing or experimental packages.
Re: (Score:2)
A flatpak version of zenmap will give you an aging version of nmap. That may not be what you want.
Re: It can be useful (Score:2)
I have an up to date version of nmap from distro repos. Zenmap from repos? Not available.
Those who do not learn from history... (Score:2)
...are doomed to repeat it.
I'll just leave this 24 year old paper here...
https://www.usenix.org/legacy/... [usenix.org]
But sure, reinvent the wheel, with corners, and off-centre hub and no spokes.
Wasting memory, opening up to security issues (Score:2)
Loading multiple copies of the same library in memory is a waste, and having to rely on individual flatpak maintainers to update every single dependency for each discrete flatpak is a security gamble.
Shared libraries? (Score:2)
Re: (Score:2)
Badly. It will tend to load multiple copies of them.
Re: (Score:3)
That's kind of how shared libraries end up working on Android and macOS. You bundle the libraries you need with your app, and the system essentially has many duplicates of slightly different versions of the same common libraries. Depending on the system providing your needed libraries is not easy to port, and you can also end up in a dependency hell where different applications have different version requirements or bugs. But that last problem is somewhat solvable if the effort is put into it.
It's the Windows method, but worse (Score:2)