How does it stack up against traditional package management and others like AUR and Nix?
I use it but I hate how much space it uses and I hate when I update flatpaks I have no idea how much is going to download.
https://gitlab.com/TheEvilSkeleton/flatpak-dedup-checker
And it should only download the diffs, not everything.
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).nix-collect-garbage
to force a clean up of unused packageshttps://search.nixos.org/packages makes searching for packages a lot easier
https://mynixos.com/search?q=home-manager+ same, but for finding options to configure packages through home-manager
Comment if you need help
update: removed nixGL from flake and home, installed it through nix-channel in order to not use
--impure
duringhome-manager switch
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.I haven’t used distrobox, so take this with a grain of salt:
-
reproducibility: if you copy my nix files, the
flake.lock
will ensure you have the exact same results as me -
declarative package management: you make a list of packages and the declarative nature forces you to keep it up to date at all times, that’s how you install/remove them. On arch you need to
-Syu
the package and remember to add it to an installation script (I never did). This also allows for easier maintenance because you don’t need to go through random dependencies to find an unused package you’ve installed (~100 packages on the list == almost 2000 packages installed). If there’s a distrobox version of a Dockerfile, you can do the same but it will most likely have the same disadvantages. -
home-manager allows you to configure packages (usually not worth it though)
-
no need to export packages, when you install them they’re immediately available in your main distro
-
combine these and you have an extremely simple setup to distrohop, or work on multiple devices. You can also for example break off certain packages in a separate module, and only install them on a certain machine.
-
I’m guessing updates are easier, and if it breaks something, you can easily rollback to a previous generation. It will not only revert to the exact same packages you used previously, but it will also revert any package configs it controls. And on top of that it lets you pin a package to a specific version, and upgrade everything else.
-
cross-platform: you can take your list and install the same packages on win/mac natively. They don’t need to run linux in a vm like a container would
-
less storage used?
-
temporary package installs. For example I only needed
arandr
for 30 seconds to set up a new monitor, so I justnix shell nixpkgs#arandr
and it created a shell with that package. When I was done I just closed the terminal, and didn’t need to think about it anymore. The package was completely removed the next time I rannix-collect-garbage
. -
you need a package that’s in no repository, but it has a flake with all of the compilation dependencies? You just
cd
into the repo,nix develop
, and you’ve got a temporary environment with everything you need to start following the compilation instructions
But in case of the repository size, Debian and Arch (+ AUR) are extremely big aswell.
Arch has a lot of packages, but there are some that I had to install through aur which I don’t like. Nixpkgs have so far had everything I needed, except for nixgl (although I couldn’t get a few of them to work). Also, you can chose between “stable” and unstable repos. Arch doesn’t have a frozen version with updates every ~6 weeks, and no other release based distro comes even close in either quantity or freshness.
That’s what I can think of for a casual user. There are a lot more benefits for professionals to be honest, and I wouldn’t suggest nix at all if home-manager didn’t massively simplify the whole process. Getting to those few simple files from above was a massive pain, and it’s made even worse by the official nix guide suggesting outdated methods, and most of the support threads being for nixos. With them, you can get going in like 10 minutes even if you don’t know anything.
Thanks for your great explanation!
How up-to-date are the packages, compared to Flatpaks?IIRC, I used Nix a while ago to install a program, which was supposedly hard to build for Linux and crashed all the time as Flatpak. Sadly, the Nix version was almost a year old and also not great.
But I think I’ll take a look into it again. I began using terminal apps a lot more and also became a huge fan of image based distros, and I think Nix packages have similar benefits as immutable distros.
-
I definitely prefer it over Snaps or appimages. Straight-forward to update, and Flatseal provides a nice GUI to control permissions (if needed). Themes may not work properly, but whatever, not a big deal for me.
The distro’s repo is always my go-to. If it’s not available there, then flatpak, and I’ll use appimage under duress. If that doesn’t work, I’ll figure out a different solution.
Some of the under-the-hood implementation of Flatpak irritates me, like why the hell are we installing software in /var? Using it with the terminal is a pain because of the org.something.SomeThing shit it does, and I think Flatpak gives you all the drawbacks of app sandboxing with none of the benefits. It likes to not see the whole file structure; for instance I found the Flatpak version of Steam to be unusable because it wouldn’t see anywhere I wanted to put my games library. That needs to be fixed.
That said, I think it’s the better of the three all-distro package managers, it’s got a central repository and package manager unlike Appimage so it’s a place to publish and get stuff, and it’s not tied to Canonical so it’s obviously better than Snap.
https://github.com/trytomakeyouprivate/flatalias
Try this script I wrote and help improve it!
if you want to change app permissions, use Flatseal and add the needed directory. This is very easy. If it is something all users generally need, open a bug on their repo.
Installing a separate program to make the first program work the way it should in the first place, and opening bugs in repos, is abolutely 100% things end users are willing to do.
KDE has flatpak settings included, GNOME is doing their thing with unix philosophy and all. Flatseal works fine.
As I said, you should not need to edit those settings, maybe you need to, and if it generally makes sense (for example GNUmeric only has documents access, nothing else) this needs to be fixed.
Will not happen often for common apps
Reminds me of this XKCD.
The state of flatpak permissions currently is like that. They can never read each others storage, much like on Android with
/storage/emulated/0/Android/data
. So it you keep stuff stored inside these apps its safe.Until they can use portals, many have permissions to read/write everything
My totally unscientific opinion (with a double-your-money-back guarantee!):
I’m not crazy about either Flatpak or Snap for that matter as there’s so much backend baggage for both as well as certain hurdles regarding privileges and access to the file system (somebody please correct me if I’m wrong or working with dated information.)
My other completely prejudiced, unfounded bias against Flatpak is that it appears to have been adopted by RedHat as “the one true way,” and what with IBM’s/RedHat’s behaviour anti-FOSS behaviour lately, plus I’ve almost always have been an
apt
user, I find it a pill hard to swallow.Me, say what you will about the security issues and its other flaws, but I like AppImage.
Flatpaks follow the concept “losen the sandbox as much as needed to make apps work”. This sucks, in constrast to android, but its needed.
So you shouldnt need to edit anything via Flatseal/KDEs settings, if you want to make apps work.
Flatpak is default on OpenSuse too, even more as they use Flathub instead of the Fedora Flatpaks repo. RHEL is just trying to get some money and stop people from using their work, as they need to make money.
Honestly it should be normalized that people on FOSS do weird things to make money. Fedora is RHEL upstream, so RHEL is not stealing any code, just take what Fedora does and wait a bit until its stable.
Appimages are completely flawed and as an apt user you should not like to use them, at all. This post of min may give some infos, I will update it soon.
And speaking of completely flawed, your link doesn’t work.
Anyway, thanks for
beratinginforming me about AppImage but it’s the closest thing on Linux to app bundles which IM<HO is the sanest way to package applications.Thats a lemmy problem, copy the link and remove the lemmy part
Thats a lemmy problem
Hmmm…my link in the previous post works. More proof of why Linux has never really taken off with the non-spectrum general public. I guess just following format (
[words](https://your.lousy.link)
) or – god forbid – you select a word, click the link button and paste just isn’t esoteric enough…?In any case, I see that you edited your post to
cover your tracksfix Lemmy’s error.The error is that I dont use https as every browser defaults to that, but lemmy links it internally. I fixed it. Stop annoying me, my comment was constructive and trying to help, so
whatever this isstop it.
Does anyone know how they handle spoofed malware? I can never figure out whether I can trust the packages from flathub. I always have to check the official website of the particular software first.
On the one hand I like the basic idea, on the other hand I think that some fundamental problems aren’t fully solved yet. There big use case are passkeys and direct password manager integration – neither mesh well with the idea of software that isn’t allowed to talk to most of the system.
I’m certain that this will be resolved at some point but for now I don’t think Flatpak and its brethren are quite there yet.
passkeys
Dont know, may already work? Keyword adaption
direct password manager integration
Not sure what that means, but probably native messaging, a biig missing portal.
Flatpak has an Inter-process-communication permission, so software could absolutely be opt-in allowed to talk, while keeping security for the rest. Apps cant see each others
~/.var/app/org.app.name/
storage though, never.
I still prefer traditional packages, but I get why devs of complicated graphical apps with lots of dependencies hate them. As for Flatpak specifically, I’m not super impressed. It’s just going to get more annoying over time having more old versions of all their libraries and more and more apps that aren’t updating to the latest version so they eat up a ton of drive space and give constant notices to harass the devs, but out of all the major distro agnostic options they suck the least and they’re getting better the fastest, which is why I think they’ve pretty much won at this point. I’m not currently using them, but it’s pretty much inevitable that I’ll have to at some point, and overall that’s probably more good than bad. I think AppImages could have been better if the lead dev wasn’t a walking, talking collection of weird hills to die on, but I’m afraid that ship has already sailed.
I mean if the apps are not maintained, they wouldnt work well as distro packages too, would they?
Not really. It’s actually pretty common for simpler, unmaintained apps to get small changes in each distro made by the distro maintainers to stay compatible with their current library versions. There’s nobody doing that on Flathub.
Probably, but I guess thats the lack of “it has to be updated”. Just as distro maintainers do, flatpak maintainers or contributors can do as well, as its often pretty easy.
Sure, they can, and yeah it is pretty easy, but people have lives. They move on. A distro always has someone checking to make sure things aren’t broken. On Flathub it won’t even break. It’ll just waste drive space and start giving users annoying error messages, and there if the maintainer isn’t interested in maintaining it anymore the only option for doing anything about it is to fork the whole project, and who’s going to do that for something that isn’t even really broken?
you dont need to fork a project to update its manifest on github flathub. I think the packaging is very easy and accessible, in comparison to maintaining some Debian repo package etc. Also there are way more officially supported apps on Flathub, so I dont think the lack of pressure to upgrade an app is such a big problem.
But for sure, Onionshare was one of them, and different parts of the community took care of it.
How exactly do you update the github of a flathub package with no one actively maintaining it? Not sarcastic. That is an actual question.
And I’m not worried about big officially supported apps. A better example of the kind of thing I’m talking about is older open source games. Flatpak could be great for games. No distro out there is maintaining a current version of every open source game that has ever been released, but Flathub can, and it could be great. Unfortunately anything that’s not being actively maintained is rapidly going to become a 200MB download that whines about security every time you update your flatpaks, even if it doesn’t connect to the internet at all. Even if it’s possible for any random person to update it, who will?
Of course, this doesn’t just have to be about games. There are lots of open source programs out there that just kind of get completed and abandoned. And that’s not even bringing up all the closed source software on flathub that definitely won’t be updated eventually. These aren’t unsolvable problems, of course, but I don’t even think anybody working on flatpak even cares.
I dont know who manages “who can maintain”, if its only a single person thats bad of course. Good point that should be addressed to the flathub people. There should always be administrative access to some form of elected bunch of people that can then merge PRs or make new people admins.
True about the EOL runtime error messages, I mean they are important but should be possible to mute per app, especially when its offline. This will then just consume more disk space, which is probably fine.
I personally think it is trash…
Just putting “personally” in front of an unfounded statement doesnt make it better
Why it is unfounded?? The sandbox is still a lie (flatseal is impractical security since it makes you become a security researcher overnight), apps are not properly filesystem-unveiled. But a new level of complexity.
Could you explain “filesystem-unveiled”?
Apps are not updated to support portals for “compatibility” or just lack of maintenance. Flatpak needs to follow their approach if they want to have many apps being supported.
Desktop Linux doesnt have the marketshare to dictate that all apps need to adopt portals. In the meantime, flathub.org has a rating system and verified checks, this is simply not well shown in KDE Discover and not sure about GNOME software.
Could you explain “filesystem-unveiled”?
Means its filesystem access is restricted.
For example, chromium on OpenBSD use the unveil(2) system call to restrict itself to /tmp and $HOME/Downloads .
Many popular flatpak applications have filesystem=host. This is equal to restrict all filesystem access and then unveil the whole filesystem.
Apps are not updated to support portals for “compatibility” or just lack of maintenance. Flatpak needs to follow their approach if they want to have many apps being supported.
Desktop Linux doesnt have the marketshare to dictate that all apps need to adopt portals. In the meantime, flathub.org has a rating system and verified checks, this is simply not well shown in KDE Discover and not sure about GNOME software.
If they can’t even enforce portals, flatpak is a new level of complexity.
So I said it is trash.
Good that Chromium does that, but this means if it doesnt use portals many things will be broken.
The host access is not actually everything
These directories are blacklisted: /lib, /lib32, /lib64, /bin, /sbin, /usr, /boot, /root, /tmp, /etc, /app, /run, /proc, /sys, /dev, /var
Exceptions from the blacklist: /run/media These directories are mounted under /var/run/host: /etc, /usr
Portals need a change in the app code that is not huge but differs from other packaging formats on any distro and OS. So it sucks that its so slow but that has a reason.
The host access is not actually everything
Not as restrictive as chromium’s unveil.
For home it even restrict to the downloads folder, not accessing the whole home directory.
Yes that only works for browsers and would completely break image viewers, document editors etc
People need to realize that before Flatpak, distributing a small-time Linux app was a nightmare. Appimages were your best option if you wanted to avoid distro specific builds, PPAs and AUR, etc. Ever since packaging 2009scape on Flathub I haven’t looked back. It auto updates. People can find it from software centers. It works on all distros. It connects straight to upstream’s CICD. It even forced us to adopt XDG compliance so we could sandbox it better.
Yes, Flatpak has downsides like the download size (on disk it doesn’t matter because it gets compressed and the runtimes are shared, same as literally any other package manager). But overall, I hugely welcome it over the options we had before. Much love to the Flatpak and Flathub devs!
Flatpak shooould just download the diffs
They should, actually. Google released a tool for downloading only the diffs on binaries a few years ago
They use ostree afaik, so “they should” as in “I think they do”
I’m a bit “eh” on flatpak. The only benefit I see is that it’s sometimes more up-to-date than what I can get from an LTS package repository. As a heavy CLI user they force me to find and click icons which is irritating (yeah - I know about
flatpak run something.I.always.forget
but that’s even worse somehow).I’ve hit occasional issues with applications being too locked-down. Like with Darktable only being able to see things in $HOME/Pictures. But I keep my photography work in a different location so it can’t see it. I had to jump through some odd hoops to fix that. Not a problem of flatpak itself per se but something you can expect when dealing with package makers.
I fall back on flatpak if the version available through the standard package manager is too out-of-date for my liking. Other than that I can’t be bothered.
EDIT: Okay - for people who think they’re being “helpful” by telling me that “aliases are a thing” just stop. I’m not going to workaround a broken system. I’m going to use another one that isn’t broken (or less broken).
If you’re going to use flatpak from the command line you’re definitely going to need to start aliasing those flatpak run commands. It’s still annoying, but at least that way it’s only annoying once.
No. I’ll use snaps before I start maintaining a bunch of aliases that I shouldn’t have to. It’s a flaw in flatpak.
No snaps are insecure on other distros that Ubuntu, as they are only isolated using apparmor. Also they are nonfree by design, just no.
They’re not insecure. No more so than when I install a package via apt. No more so than when I download some code and compile it. This is propaganda.
They are less secure than flatpaks and there was malware on that store
You think the unverified flatpaks which choose their own permissions are “safe”?
You have the option to add the verified subset only, and you can always check permissions before starting an installed app, and it will not start before.
Try this aliasing script I made
No idea if it still works lol, but should tbh. I think its even pretty well done.
- Lists your installed flatpak apps
- Searches for already added aliases
- Convert the appname to be the last part, remove
-
_
- Alias to bash, fish, zsh
Only thing missing is handling duplicate apps I think.
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.
Yes, also it uses deduplication on the disk, where it is even less space actually used.
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?
Where’s that Chris Pratt meme? –
I don’t know what that is and at this point I’m afraid to ask
Flatpak is a project trying to fix many things at once
- make apps that work on every distro
- thus have apps officially supported by the devs, unlike distro packages mostly
- sandbox apps with an android-like permission system with a rating system
- use modern standards like delta-downloads, deduplication and BTRFS compression to save storage space
- make everything nice and user friendly