I am looking at those as well. One appeal is they allow precise tracking of dependencies and seem to support Mac as well, so could set things up easier on developers machines.

It isn't fine for developers or for the Linux ecosystem.

Sure it works for users for installing what has been a complex development and packaging system.

The problem is exactly that it is hard to distribute applications in Linux.

> Flatpak is the next-generation technology for building and installing desktop applications. It has the power to revolutionize the Linux desktop ecosystem. https://flatpak.org/

> The problem is exactly that it is hard to distribute applications in Linux.

For who? Distributions generally seem to like their own packaging processes. You can distribute a package on the AUR in a few lines of bash and it's filled to the brim with software because of it.

Me and the lack of software on Linux. I am talking about making it so that Linux can finally get some killer apps that we can't get our hands on.

Flatpak is the replacement for applications and not OS specific packages. You would still use a package manager for OS related packages and for flatpak/snap and then flatpak/snap installs and uninstalls applications. Much better system for everyone.

The complexity for deployment and its complexity and diversity is the number one issue with Desktop Linux and applications. This is why we don't have Adobe applications or many others. I use several commercial programs and to them deb = Linux and I use OpenSUSE so I constantly have to go through hoops until they start supporting rpm, which they normally will start doing if they get enough traction in Linux.

Now this is the key difference I feel has been left out of the messaging surrounding flatpak. It's not meant for libraries and OS packages, just end-user applications? That makes more sense now.

Well the achiles heel for Python is also deployment. The reason why we have so few applications is that each system has differences. RPM, DEB to other Distros or forget you just read this but (SystemD and not SystemD). With a flatpak you have a runtime and the runtime makes the hooks for the development.

Linux has a great tool for deploying different packages and it is hardly used. You build the package here and then it will rebuild it for other distros and systems. It could even make Windows and MacOS if they extend it. It is complex to do these things. https://build.opensuse.org/

With a flatpak or snap you just build the one package and it runs everywhere.

If I had a Euro for everytime I heard that, or some variation on that, I would have a lot of Euros

Package manager have nuances, and so have flatpak and snap installations.

Also, add Windows and macOS into the mix. Down the drain it is. It's basically what Docker was trying to get out of the way. Funny thing is that actually Go and Rust might be more the solution to the whole packaging dilemma that and packaging solution.

Even with containers, being able to reproducibly rebuild the containerized application from its sources if desired is still a challenge.

1) flatpak runs on a runtime and the application would than be exactly the same on all systems. Just like a Java program or any other programming language that runs on a runtime.

2. flatpak and snap are not for servers, which containers makes more sense because they are solving a different problem than desktops'. So they are more like a sandbox like what we find on tabs in Chrome.

> Is Flatpak a container technology?

"It can be, but it doesn't have to be. Since a desktop application would require quite extensive changes in order to be usable when run inside a container you will likely see Flatpak mostly deployed as a convenient library bundling technology early on, with the sandboxing or containerization being phased in over time for most applications. In general though we try to avoid using the term container when speaking about Flatpak as it tends to cause comparisons with Docker and rkt, comparisons which quickly stop making technical sense due to the very different problem spaces these technologies try to address. And thus we prefer using the term sandboxing." https://flatpak.org/faq.html

Reproduceable builds are not about software distribution, they are about compilation. The Arch Linux maintainers would like to be able to verify that the Java bytecode that they are sending to their users was indeed built from the Java source files that they were expected to be built from. With reproduceable builds anyone can double check that the Java bytecode that is being distributed is the correct one by recompiling it on their own machine. Without reproduceable builds you need to trust that the person who compiled the file didn't do anything malicious (either intentionally or unintentionally)

Why though? There is no difference in complexity between `package-manager uninstall package-name` and `rm -rf /apps/package-name`. If you implement the latter, it will probably be aliased to the former.

The biggest problem in any case is not the application's assets (which all package managers manage competently), but its state and configuration files. It took Windows about a decade of carrot and stick to get (most) applications to put their files in a few defined locations instead of all over the place.

The issue is reproducible and developer complexity. But in terms of complexity you are confusing user complexity and developer complexity. Developer complexity is still high and is the big barrier to Linux development.

Also we have the crazy apt-get update vs upgrade fiasco that chocolatey has gotten caught up in. They even made choco update be replaced by upgrade.

There's a causal connection between those two things....

ROX has been doing that for like 15 years. http://rox.sourceforge.net/desktop/AppDirs.html