How does it stack up against traditional package management and others like AUR and Nix?
As a non-technical user: fucking love it.
I personally prefer to use Flatpaks over traditional packages because of the added security, sandboxing, and overall convenience of not having to deal with dependency hell. It’s especially nice being able to have proprietary applications sandboxed from the rest of my system without worrying that Steam is snooping on my ‘super-important-tax-documents’.
Flatpaks are also very useful for having up-to-date packages on distros like Debian, and it’s derivatives. People can still use their preferred distro without having to worry about not getting a certain update, feature, bug fix, etc, for their applications.
Being able to restrict what applications have access to is a game-changer for me. A lot of times Flatpaks, by default, have very lenient permissions, and with the use of Flatseal I can restrict it to my liking. Worried about Audacity’s telemetry?? Turn network permissions off. Now, not all applications will work well (or at all) without internet connectivity, but for applications like Audacity, it works great!! Flatpaks can also be very useful for developers.
That’s not to say that Flatpaks are without their fair share of issues. Are they bloated?? Yeah, and although it’s not an issue for me, it may be for some people. Desktop integration is, meh. Themes, and fonts don’t always integrate the best. (A while back there were issues with Flatpak’s sandbox, but I won’t touch on that because I need to refresh my mind on it, and it was actively being developed to fix those issues so it possibly isn’t even an issue anymore.)
Overall I think Flatpaks are absolutely wonderful.
I use them for some things and I think they are fine. Mostly apps that are kinda messy and I want to keep them and their atrocious dependency tree away from my base system. I also like to use them for proprietary apps or apps where I actually want to use the sandbox. Other than that I prefer native packages 99% of the time.
Flatpak is slower to update than pacman, the cli interface just doesn’t feel good to use. There is the weird naming, no real way to get a dependency tree, can’t hide those annoying eol messages even for apps that I specifically don’t want to update. Another thing is that not every app was made to run in a sandbox or it is just more difficult to use sometimes. A lot of people tend to cite ide’s, but in my case I was having issues with the steam flatpak. Running games with steam was fine, but anytime I wanted to hook up something third party eg: mods, cheat engine, etc. Doing so in the flatpak either required some tinkering around the sandbox or straight up didn’t work.
I feel like that last sentence sums up the whole experience. If you just need to point and click and have it work. Flatpak does that amazingly. If you need any kind of integration with other things, expect problems.
Edit: just wanted to add that, the whole point and click and work is fine for 99% of people which is why I and many others choose to use it.
Yeah, I also had apps like Steam native break once or twice due to library updates (such as Mesa) - the downside to rolling distros. However, the Flatpak version continued to work so now I only use that. I don’t use mods though.
I’m now gravitating towards treating my rolling distro a bit like an immutable; more Flatpaks, avoid user repositories.
Best of the three major agnostic package formats. If it brings more focus to Linux development, I don’t see how it can be a bad thing. A bit more space needed but for most setups this is a non-issue
I really like the idea of a universal app format and flatpak seems the best for it. And flathub has been great as a repo.
The idea of separate system layer (with traditional packages) and user app layer with flatpaks seems like the way to go. Perhaps even immutable system layer.
Flatpak is fantastic for end-user GUI applications
Flathub is also great, but the fact that it’s really the only repo that flatpak maintainers are using concerns me. I know I’m dreaming, but I would love to see some sort of federated or P2P hosting
My main problem with Flatpak is that it hands temporary /var/run/1000 file links to programs instead of real filenames. That would almost be bearable, if Flatpak also took responsibility for keeping those links from breaking sometime after your next reboot.
If I say “here is a path that an app is allowed to use”, flatpak should just allow an open() in there to work. It should not lie about the name of files in there. An app should be able to open a file there, remember that name, and count on being able to access it again in the future.
Other than that, Flatpaks are the bees knees. I love finding something I want to do, finding a solution in the flatpak store, and click-click I’m already doing shit. Finding Windows software is absolute garbage next to this.
Thats basically persistent portals. Would be possible if Distro portals had a button to give the app permanent (static) permission to that dir.
Would indeed be useful and not hard to implement. In the portal window just add a button “permanent” which does
flatpak override --filesystem=$PWD org.app.name
Want to open a discussion or Feature request for your desktops portal?
I love the idea and the philosophy behind ! I have no trouble with them for now, one click install perfect.
However I’ll never use it for programming and I don’t understand why people use vs code flatpak or other coding app, because the app is contained and cannot interact with your system.
As a generalist I have to learn many concepts and dont have time to delve into any one that deep. Flatpak works and isnt proprietary like snap so I enjoy that. My recent debian+kde installation works well with if. Open discover and install flatpaks as much as you wish.
deleted by creator
I love flatpak. It makes it easier for Linux to become mainstream.
It’s fantastic, for two reasons:
- There’s so much great software available through it, and I can always get the latest version regardless of my distro - or an older version if it hasn’t kept up with its dependencies.
- It’s part of the tooling that allows me to update my operating system without risk of it breaking (i.e. I can use an atomic distro because of it).
purely as an end user i hate how much it downloads with each update and how much it uses the disk space although that’s much less of an issue. i know it’s solving a real problem and relieving a lot of the headaches of developers maintaing packages for each distro’s specific package standard, but it’s simply not the software distribution solution for people without at least well enough internet.
i wouldn’t use any distro with flatpaks as its main way of delivering software and i would in almost all cases always choose alternatives even if it’s outdated. i don’t necessarily hate flatpak itself but for me i don’t want to spend money on extra data cap and wait 30 minutes for a small update for my game launcher to finish.
the appimage of one of the applications i was interested in was 3 times less than the average flatpak update so redownloading the appimage every time would be better. if i installed more packages yeah the math would be better but it’s still wasted data per update no matter how small it actually is. i found out after a while of using flatpak that i wouldn’t just update and was stuck with outdated software anyway.
Flatpak updates should generally download changed data, it does a poor job of showing how much this will be in advance though.
the actual update size for the application is logical as far as i remember, it’s the other stuff alongside it (i think related to graphics card) which is the real issue. it added around 500MB each update while the actual update itself might’ve been 10 or 20 MB.
Yes, also it uses deduplication on the disk, where it is even less space actually used.
I installed PyCharm via flatpak. I don’t appreciate that I can’t access vim via the IDE’s terminal, and so far that’s all I really have to say about it. I like that things are sandboxed, and I think maybe this wasn’t the kind of thing I ought to have used flatpak for.
How does it stack up against traditional package management and others like AUR and Nix?
I only used AUR for a few packages (<5 at a time). It’s to be avoided and only used if the other options are a massive pain (unless it’s an official package).
Then I left Arch and eventually landed on MX. During that time Nix with home-manager has slowly replaced flatpak, and I don’t even have it installed anymore. Nix is better in every way, except for ease of use.
Flatpak has great gui integration (for gui tools). You can click through everything, and the updates are unified. It usually works perfectly fine if you just need to install a few programs.
With nix, there’s a lot more setup, but there are many benefits. You end up with a list of packages, and that’s really useful because you can take a fresh install, install nix and home manager, and then run a single line to reinstall everything. You can rollback updates, pin specific versions, install packages from a repo (if it has a flake.nix with outputs), and also configure them. I’m using the unstable branch, and it’s giving me bleeding edge packages on Debian. And there’s no risk of outdated system libraries, like with flatpak, because it provides everything.
That all sounds great, thanks!
Do you have any tips for an “easy” start, where everything is already pre-configured?Nope, and that’s the worst part of nix. I’m actually planning on writing a short startup guide, but I need to solve a few more issues first.
But, this should help you out until then:
- installation commands (per user installations, no sudo needed for using nix or home-manager)
- ~/.config/nix/nix.conf ( you might need to add this before installing home-manager, i’m not 100% sure)
- ~/.config/home-manager/flake.nix
- ~/.config/home-manager/home.nix
The home.nix should be automatically generated, and that’s where you put all of your packages. I left a few as an example.
NixGL is needed to use openGL (
nixGL lutris
for example). It works in most cases, but I couldn’t get alacritty or kitty to work. There are some ways to have packages automatically use it, but I still haven’t tried them out.Flake allows you to select the correct nix repo (stable/unstable), appropriate home-manager version, and add outside packages like nixgl. It’s technically not necessary, but I wouldn’t go without it. Here I’m using the unstable repository, check the relevant docs if you want to go with releases instead.
The equivalent of
apt update && apt upgrade
isnix flake update && home-manager switch --impure
. I like cd-ing into the nix dotfile directory (all of the files are in there and symlinked to ~/.config/ locations), but you can also use command line arguments to point to the flake.nix flake update
updates the package definitions to what’s in the repohome-manager switch
install them, and also updates any configs it’s managing. The --impure is only needed if you’re using nixgl (bad build commands depend on system time).Comment if you need help
Thanks! I saved the comment for later.
What advantage do you see in Nix compared to Distrobox?
I personally enjoy DB because of its simplicity.
I just open BoxBuddy, create a new container from the dropdown-list, and then just start using my Debian or Arch container on top of Fedora Atomic for example.The two main benefits I see in Nix are the reproducibility and the big repo. But in case of the repository size, Debian and Arch (+ AUR) are extremely big aswell.
Are there any other big benefits, that I can’t get with Distrobox, but with Nix?
Just as a small side note, I’m no power user and tend to use my PC more like a casual guy.