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).