The tone here is surprisingly negative. Personally I’m happy with the efforts of the Flathub team 🤷
As a newer Linux user I really like flatpaks.
I don’t use them for most things I install but proprietary apps I want sandboxed or programs that have weird issues with dependencies I grab the flatpak.
Agreed, flatpaks are great for desktop apps. I use Nix for the majority of my packages, but I use flatpak for proprietary for the sandboxing.
Lemmy (and phoronix) people are generally extremely repelled by new stuff in the Linux world
Lemmy people are generally extremely repulsive.
To everyone saying you can’t mirror a flatpak repo… you’re absolutely right. There should be a far easier way to set up your own mirror without needing to build everything from scratch. That being said, if you wanted to try to make your own repo with every one of flathub’s apps, here you go:
https://docs.flatpak.org/en/latest/hosting-a-repository.html
Edit: Some did get a flathub mirror working. The issue is that a. Fastly works good enough and b. There is no concept of “packages” on the server side. It’s just one big addressed content store because of ostree, and syncing is apparently difficult? Idk, not being able to sync the state of content is like the entire point of ostree…
I’d prefer to see downloads per country per capita.
Sorry to ask, I’m not really familiar with Linux desktop nowadays: I’ve seen Flatpak and Flathub talked about a lot lately and it seems to be kinda a controversial topic. Anyone wanna fill me in what’s all the noice about? It’s some kind of cross-distro “app store” thingy?
Flatpak is a universal application packaging standard for Linux. It allows devs to create a single application that gets bundled with all necessary dependencies including versioning.
These apps run in their own semi-isolated “container” which makes immutable distros possible. (Distros like Fedora Silverblue that are effectively impossible to break by installing or removing critical system files.)
This means that a Linux app doesn’t have to have a .deb version, an .rpm version, or be pre-compiled for any other distros. A user can simply go to Flathub, (the main repository for Flatpak apps), download the flatpak, and install it on their distro of choice.
It’s quickly becoming the most popular way for users to install apps on Linux because it’s so easy and quick. But there are a few downsides like size on disk, first party verification, per-distro optimizations, and the centralization of application sources. That’s why some users aren’t fully endorsing or embracing how popular they are becoming.
Cool, thanks for the explanation.
a single application that gets bundled with all necessary dependencies including versioning
Does that mean that if I were to install Application A and Application B that both have dependency to package C version 1.2.3 I then would have package C (and all of its possible sub dependencies) twice on my disk? I don’t know how much external dependencies applications on Linux usually have but doesn’t that have the potential to waste huge amounts of disk space?
Essentially yes, if you start using lots if older applications or mixing applications that use many different dependency versions, you will start to use lots of extra disk space because the different apps have to use their own separate dependency trees and so forth.
This doesn’t mean it will be like 2x-3x the size as traditional packages, but from what I’ve seen, it could definitely be 10-20% larger on disk. Not a huge deal for most people, but if you have limited disk space for one reason or another, it could be a problem.
It CAN get pretty wild sometimes, though. For example, Flameshot (screenshotting utility) is only ~560KB as a system package, while its flatpak version is ~1.4GB (almost 2.5k times as big)
Flameshot is 3.6MB on disk according to
flatpak info org.flameshot.Flameshot
Weird, the software manager (using LM 21.3) reports 1.1GB dl, 2.4GB installed (which is different from when i checked yesterday for some reason?).
flatpak install
reports around 2.1GB of dependencies and the package itself at just 1.3MBEDIT: nvm im stupid, the other reply explains the discrepancy
no, that number don’t reflect the shared runtimes and deduplication
Most dependencies are bundled in the “runtime” images, and it uses file deduplication to reduce the size of the dependencies, but it’s still a little more than a normal package manager.
Not necessarily. GNOME and KDE dependencies and “base system” for flatpaks to run in are flatpaks themselves so apps that depend on them will not use duplicated dependencies. Storage usage may not be as efficient as using a traditional package manager but you don’t install a new OS per app either.
What about those apps using out of date libraries? Wouldn’t that become a security issue - since containers usually aren’t that secure, right? And all app developers would have to update their container libraries separately, instead of just updating the system libraries?
Interesting breakdown, thank you.
Do you happen to know if the containerization is similar to docker containers? Or more like android apps?
It’s more like android apps from early versions of Android before the permissions became user-managable.
It won’t prompt you to give the application access to certain permissions, all the permissions are predefined in the manifest by whoever published the application to flathub. When you run the application you just hope it won’t cause too much havoc (you can of course verify the permissions before running it, but I guarantee most people won’t)
Flatpak supports sandboxing but due to how most desktop applications want access to your home folder, network etc many apps simply disable it.
Regardless of the level of sandboxing applied to the app, Flatpak is a great way for a developer to package once run anywhere. Prior to Flatpak, if you wanted to support multiple distros, you had to build a package for each distro or hope somebody working on that distro would do it for you.
Inb4 AppImage was here first. And if you mention Snap then GTFO
Appimage is probably the most similar to a naked .exe in Windows. They are useful for small apps or simple indie games, but I prefer Flatpaks for my everyday big applications.
Agreed, Snaps are like Flatpaks but worse because locked down back end and Canonical’s sketchy nature. Imagine a really delicious pastry that anybody can make and sell, then imagine the same pastry but only one bakery in the world can make and sell it. Which would you prefer? Lol
I’m not an expert, but from my understanding, more like android apps.
They aren’t totally isolated like a docker or LXC container would be, but they are generally self-contained.
The Linux Experiment has a really great vid that goes into detail on all common packaging formats in Linux including Flatpaks:
Most of the issue is that they’re unreliable. Sometimes the app will work. Sometimes it doesn’t. Sometimes you have to fiddle blindly with flatseal settings, which ones? Who knows? Guessing is part of the fun.
It’d be a great thing if it just worked.
In over 3 years of daily flatpak use (of multiple apps) I’ve never had a single reliability issue with flatpak, the only ones being caused by me because I was trying out settings in flatseal that the app didn’t like. On the flip side I’ve found native packages to be broken more often than not, with .Deb files sometimes just not working and throwing an error or something. Package managers are better for sure but I’ve had dependency issues that I have never experienced with flatpak.
Good for you for not having any problems mate! I’m sure this invalidates the parent poster’s problems.
I don’t hate flatpaks, but flatpaks require more disk space than the same apps from traditional repositories, and they only support a handful of the most common default themes. Since I only ever use older and slower computers, my disk space is limited, and I like to rice my desktop, I personally avoid them. But your use-case may differ.
yes it’s cross distro, it’s controversial becaune some people don’t want to install apps with their own libraries or dependecies, and some apps are not oficial so they break with the flatpak sandbox
As a professor I have to say… the site admin skipped the class that taught them to include always the color bar.
I’m gonna be honest I’ve never had a flatpak version of something ever work properly.
There was even one popular media player that only came in flatpak form or otherwise build from source.
So obviously, for no reason at all, it barely functioned compared to other applications I had already tried.
Congrats to you people put there somehow running things like Steam with no problems lmao.
I have like 20 flatpak software products running without any problem for 2 years now.
Your system might be messed up
Here only the core OS and the basic part of the DE is from the Linux repository. The rest are all flatpaks.
I’m gonna be honest I’ve never had a flatpak version of something ever work properly.
As someone once involved with OS Security, I beg you not to use FlatPaks.
You can’t just make a statement like this without giving a hint of evidence or justification
Why?
Flatpak is not perfect security-wise but is a step in the right direction
Does that count for when an OS is wiped and reinstalled or a nerd has like 3 computers and keeps OS flipping?
In that case you should use user-install flatpaks and separating and reusing your /home partition
I went a step further and have user-installed flatpaks with a custom flatpak directory so everything installs on a separate small hard drive. If the whole system goes down (usually due to my testing things!), I can reinstall set up the custom flatpak and everything works again. In theory. But it borks inter-flatpak communication (flatseal cannot find any other flatpaks and is thus unusable). I moved over to distrobox (which has its own issues, but works better for the OS wiped/reinstall scenario).
I’m sorry
Still no proper way to mirror the thing and have it working offline / on internal networks. Great job self-hosters and sovereign citizens ;)
Offline/internal network installs can be handled with
flatpak create-usb
- https://docs.flatpak.org/en/latest/usb-drives.htmlOne can distribute flatpaks along with their dependencies on USB drives (or network shares, etc.) which is especially helpful in situations where Internet access is limited or non-existent.
Cache/mirroring would be great for those who need it.
Edit:
Thinking about it, I wonder if there’s enough “core features” with ‘create-usb’ that its just matter of scripting something together to intercept requests, auto-create-usb what’s being requested and then serve the package locally? If a whole mirror is required, it may be possible to iterate over all flathub packages and ‘create-usb’ the entire repo to have a local cache/mirror? Just thinking “out loud”.
Thinking about it, I wonder if there’s enough “core features” with ‘create-usb’ that its just matter of scripting something together to intercept requests, auto-create-usb what’s being requested and then serve the package locally?
The issue is that… there aren’t enough “core features”. It doesn’t even handle different architectures and their dependencies correctly. It wasn’t made to be mirrored, nor decentralized.
Apt for instance was designed in a much better way, it becomes trivial to mirror the entire thing or parts and for the end tool it doesn’t even matter if the source is a server on the internet, a local machine, a flash drive or a local folder, all work the same.
Flatpaks are not centralized, Flathub is. You can have your own repo.
Yeah sure, just try to mirror Flathub into your repo.
I don’t get it. Why would you store all of it? I mean, you can but… why?
Because…
- Universities might want to locally host a mirror in order to waste less bandwidth and provide faster downloads;
- Large companies usually like to host internal mirrors for the same reasons as above and also so they can audit and pick what packages will be available for their end users;
- Flathub is slow af for some people;
- Local country-specific mirrors are always faster;
- In some countries not everyone can access the official flathub;
- One might be dealing with airgapped networks and systems for sensitive work and you want to have ways for your end users to install flatpaks;
- Fastly, their CDN might go down at any point (like Cloudflare sometimes does) and you’ll end up with nothing;
- Flathub itself may be subject to a cyberattack and their service might get crippled for a days or weeks and you’ll have nothing as well;
For what’s worth Debian archive repositories are about 5 TB and people actively mirror then in universities, companies, cloud providers etc.
The question here isn’t “why would you” but rather “why would I be unable to do it”. Their actively gatekeeping their repository in a futile attempt to be the single and central point of flatpak distribution - much like what Apple does with the App Store.
Awesome! Love it!
What’s the issue? I installed mint because I know fuckall about Linux, and tbh it’s a dice toss if I have used the Flatpak option not knowing what the actual difference between them are
Flatpak “containerizes” the program, which makes it more secure and less able to accidentally mess up other programs. Fuck if I know how it works.
Also you don’t have to type in your password every time you want to update the program, so that’s nice.
Honestly, you don’t have to worry about what others say, you should use what works best for you. Personally I find them to be nice and comfortable to use, myself 😅
Thing is, if your flatpak software needs something not in its container, it gets a little complicated, because first you have to realise what exactly the problem is and secondly you have to use something like flatseal to give it access to wathever it needs to work (no real help there)
So this was what took me back to pacman (or better said yay)
i hope it does 20 billion
Brazil has so many downloads
nice
MVP
Crazy, how our “free world” is centralized
Flathub is not the entirety of Free World, just a little small slice of the pie. You can say Flathub is quite centralized. But our Free World have so much more. Every country will have a certain focus of what is freely available. It’s an optional server and package format. You are free to install it or use another free package. Nothing crazy here.
Touche. Centralized and un-mirrorable.
Unmirrorable? The whole thing, including the configs are open source?
Unmirrorable
Yes, unlike apt repositories, it wasn’t designed to be mirrored around, run isolated servers etc.
Flatpak was designed to be decentralised, Flathub is just the main repository offering flatpaks and yes, probably 99% of all Flatpak applications are downloaded via the main repo but it is technically possible to just launch your own if you are unhappy with the main repo. The Flatpak team literally has this info page for hosting a repository
I for example, am taking AAGL from their own flatpak repo because they are not offering their launcher via the main one (even tho they also tell you to link the main repo - I guess for dependency reasons - but theoretically you could open your own repo and throw all dependency related packages in there or am I getting something wrong here)
I agree with everything you said, however there are a few details.
it is technically possible to just launch your own [repo]
The ability to create repositories ≠ from mirror existing ones.
Unlike apt repositories Flatpak ones aren’t simply a directory tree with a bunch of files that can get mirrored using rysnc or other efficient means, it’s a clusterfuck of HTTP-only requests that need to be backed by specific metadata and there aren’t tools to manage those.
flatpak create-usb
may be promising but the name says its all - the priority wasn’t to create a way to mirror repositories but a quick and dirty hack for some situation.theoretically you could open your own repo and throw all dependency related packages in there or am I getting something wrong here
Theoretically yes, in practice things are bit more nuanced. That tools only considers your current architecture, it’s a pain to get dependencies in an automated way and most of the time you’ll end up with broken archives. You’ll also need to hack things a lot.
Ah, thx for the explanation :)