How do #linux people get their apps today?
What is good or painful about this approach?
What is a missed opportunity for app distribution on linux?
cc @Laser @jb55 @franzap @KernelKind
Login to reply
Replies (81)
too many different "app stores" apt flatpak snap app images debs etc etc
What does your ideal app distribution look like on linux as a linux user/enjoyer? What is the one “killer” thing that obsoletes the status quo?
Also, do you publish apps as a Linux developer?
switched to nixos and just let my .dotfiles agent handle everything
I haven't published, no
if *everything* worked with apt install I would be pretty happy
^ I've been shipping tarballs or self extracting tarballs.
All have their benefits and drawbacks. But I think the direction RedHat is moving in (more immutability) there will be a place for system packages (RPM) and self-contained user-app packages (flatpaks).
Agreed
flatpak, or use brew for cli.
or create a distrobox, put it in there.
Whichever method is recomended by the app maker. Prefered is package manager. Flatpak is acceptable. Sometimes things need to be hacked into the system manually.
Recently needed an older version of a gui app that wasn't available anymore through the distro repos. So I installed it in distrobox in an older version of the distro. Pain in the ass. Then I realized I can copy the package over and install directly without distrobox. That integrates much better with the desktop environmet! Feels nice.
Things can get cumbersome, but everytime I have to solve a problem I learn something, which is a good feeling.
Now with running #omarchy I’m still learning how stuff can work with Arch Linux.
- pacman for and
Official repositories - ArchWiki
AUR (en) - Packages
Tell me more about the pain in the 🌝 one
What’s a thing you absolutely love about your current setup (if anything)?
If you could change one thing only to better suit your needs, what would it be? Why?
Sounds like you are ok with the setup.
If you click snap your fingers, and change one thing instantly what would it be and why?
what about it?
Well, today I was stuck on verifying the signature of the downloaded packages (corrupted files?) trying to install LibreOffice.
From the user standpoint or developer?
tarballs are a horrible option for non-advanced users. And unless signatures are pushed, it's on users to verify package signatures
dev:
- tarballs are the easiest way to bundle an application with it's dependencies and config
- super easy to push to a webserver
- basically universal for all windows, linux, and mac systems since ~2019 I think.
- I don't need permission from package maintainers to ship to users
- I don't have to ask permission from half a dozen or more repo maintainers
- because it's a universal archive format I don't need to create different package types to support a bunch of different distros.
user:
- for advanced users: tarballs are straightforward and standard. Users have the power to see all the application files (binaries, libs etc) and put them wherever they want (if supported)
- It's easy, I just curl https://yoursite.com/path/to/tarball.tgz
- I can more hands-on do things like verify sums and signatures - don't trust verify kind of thing.
- I don't need to rely on repo maintainers and the developer's relationship with them.
Frozen-point OS typically freeze packages so maintainers might ship later versions of an app, and if you're not on the latest rolling OS version you're left behind and the maintainer. The only option is to hope the maintainer ships a tarball I can manually extract onto my system to get up and running.
> If you could change one thing only to better suit your needs, what would it be? Why?
In both cases, user and dev. Make a fairly universal package archive file that fits within a tarball like npm does. Or even better, make a package format around tarballs that supports most of the popular package managers (backward compatability).
Package managers (apt, Synaptic). It's simple, and just works.
pacman + AUR
Super smooth. Never want to have something else.
Dunno. Arch makes it simple. 🤔
Build from source like a psychopath
idk there's so many options that is chaotic imo. I kinda like appimages. I wish there was chocolatey for Linux. one simple package manager that works for all the apps.
Appimages flatpaks nix and dnf
What do you like about this setup?
What do you dislike?
“one simple package manager that works for all the apps.”
Tell me more
Appimages don’t really “install”, you have to use a different program to create start menu shortcuts and such
Flatpaks are fine, i like the sandboxing approach. It can cause some issues in my experience, discord probably being notorious for the IPC being dysfunctional for years.
Nix is good if you’re using NixOS or home manager. It’s also good if there’s a command line utility you only want to use once as you can just run
nix run nixpkgs#<program> or whatever
dnf is fine. No complaints.
closest thing is nixpkgs which has the highest number of packaged software on the planet
I’m somewhat impartial between flatpak and appimage at the moment. I don’t know the two of them in depth enough to really say which one is better.
Appimages are definitely simpler to use. But simpler is not always better
I like chocolatey it has all the main apps, it's simple and I think you can wrap existing apps in a choco package.
sudo apt install
otherwise I like appimages because they are selfcontained and portable. I don't like to have things installed all over the OS. I like standalone or like choco were I can list, it's contained and i say remove this app, and it cleans it all.
If you could change one thing about this flow, what would it be and why?
Angry turk’s opinion
Same
What one thing would you change about this install approach? Why?
Flatpak/appimages fixed the fragmentation pain, but discovery is still a maze. missed opportunity: a curated storefront with builtin Lightning payments so developers get paid instead of doing open source charity forever.
I wouldn’t change anything, I don’t know how to install things any other way
Same
My preference is AppImage if available otherwise I go with the distro default and as last resort 'sudo apt install'.
AppImage works great because I run one main host with numerous VMs serving different functions. I locate the AppImage on one disk shared to all VMs. The one install and execute from any VM instance is the big sell point for me.
I'm using Pop!_OS 24.04 mostly and it defaults to using either Flatpak or 'sudo apt install'. An initial pain point for me with Flatpak is it stores the binaries in a unique location. To execute any flatpak installed binary for automation purpose, one has to execute 'flatpak run <appname>'.
I think the missed opportunity by most developers is not generating an AppImage for their application. It might just be me but I don't like applications pooping all over my hard disk.
I know a lot of people would like apt install.
I personally think the best experience is something like Openclaw.
Just copy paste a 1 line into the terminal.
apt or flatpak...
Or download from whatever source website and verify. Sparrow Wallet has a nice tool for checking downloads.
Haven't had much success with AppImage for some reason. Probably missed a step.
Does that mean blind trust in apt repositories?
homebrew is cool on macs. Sucks on linux.
I run as many things as possible via podman. The things I can't when I am not lazy I put in virtual machines. Very portable and repeatable.
Curl, brew, npm or apt get. 🚬
By default, the repos only contain what the OS maintainers put there, so app updates are no different from OS updates, and both are from the same source.
Flatpak and Flathub have solved the app distribution issue on most distros. People can fight it or come up with something better which I doubt is happening in the near future... maybe Kaiming if Chinese companies invest in it.
Install from source, apt, sometimes snap
Snappy (snap packages), yes it is canonical yes the store is not really open but technically the best solution (from point of security). And it ships possibly to all important Linux Distros.
Trust should never be blind. Always verify sources and understand the code.
I mean most of it is opensource…. You verify the checksum in your terminal and you verify the code if you know how
I get it using the distro's package manager. That's it.
If something is not there, or I need a bleeding edge version, I use flatpak.
Overtime I found that this approach works very well for me.
I just use nixpkgs, all the packages are hash-verified. Cool
Hash-verified means a known hash is compared to a computed hash. What is the source of the known hash?
When does it go wrong, if ever?
I typically go with whatever the app maker recommends. RPM is common. Flatpaks are common. AppImage is less common. Sometimes you get a tarball but that is way less common than it used to be. Flathub (as a flatpak source) has gotten a lot better, but I like to make sure a Dev is the one who actually posted software there or it was done by a trustworthy group. Of course there's some trust there. Can't escape that.
Building from source is probably the safest route but it is more time consuming.
paru btw
Slackware user here and a lot already comes with it.
And those not I'll build from source or search in slackbuilds
You should check out extrepo. Repo management for apt.
Extrepo search
Extrepo add
Apt install
You should check out extrepo.
Extrepo search
Extrepo add
Apt install
The coolest thing in linux package management and it gets very little love.
More people should set up repos and get added to extrepo instead of publishing a .deb and expecting us to dpkg -i
I think apt checks signatures.
You only need to be careful when adding a new repo to verify the pubkey there.
I use apt and dnf. They all do some form of verification. Verifying repo pubkeys UX is bad, and there is no second layer of defence (e.g. malware makes it into a repo, not uncommon)
I learned reprepro and had my own repo (apt get) for a few years. Woowee was upgrading things annoying. Until I got into automation with bash!
I mostly build from source, or sometime grab binaries from git if they build for my architecture.
> What is the source of the known hash?
The known hash is manually entered in the package's Nix file. When adding a new package, you specify its source (e.g., Git or crates.io) and initially leave the hash field empty. Nix will then download the source, compute its hash, and error because it doesn't match the empty value. You simply copy this computed hash from the error message into the file to finalize it.
Check the nixpkgs GitHub repo. Search for a program's package file to see its hash and the PR that updated it.
upgradepkg --install-new
Or sbopkg -i
Or when you're too lazy to throw together a slackbuild script, ./configure && make && make install
I've gotten better about not using that last one so much in my old age though.
Those of us who haven't taken on the mark of the Debian thank you for this sane practice.
The amount of times I have to go digging for actual source distributions because the download page is a deb, a snap, and a flatpak...
I get nobody ships txz's but a tarball should ALWAYS be one option.
A package format around tarballs? You mean like, the way the oldest distribution in existence has always done it which nobody could help themselves but to find a worse way to do things??
I guess I do use dpkg too
I've literally reverted to using discord in a browser.
Probably half my system is built from source, using slackbuilds. The rest either included or from alienbob's repo.
It can be a pain for big stuff. Once in a blue moon it even makes sense to deb2tgz but it can be a little messy.
I assume you've gotta use pip, at least once in awhile? Or is all of that just packaged up as Debs?
Ahhh yeah well I use pip for my host too
the horror
What stops the Nix repo maintainers from changing those hashes?
there is no nixpkgs maintainer, each package have its maintainers.
if you just changed the hash to an incorrect one, nix will show you an error and the package won't be built.
if you mean changing the source to a malicious source code, other maintainers or anyone else saw the incorrect source, they will report it and it will be fixed. You can also check the package source by running `nix-edit` command.
Also not any change on the packages will be chipped to the stable nixpkgs version, it chipped to the unstable first.
When a vendor doesn't release the software using one of these methods. Curl bash is very common for example.
I usually try to find an alternative.
To express my dedication to tarballs
Didn’t know you are a oil and gas maxi. Based