@neildarlow flatpaks are a solution to a non-existent problem. Either statically compile everything in (if you’re one of those dirty hippy companies that don’t like to play nice with OSS) or get help packaging it. A lot of maintainers of existing packaging can either give you hints, point you to automated services, or similar.
Packages, are by and large, a solved problem
Packages themselves are. Desktop software isolation isn't at all. When it comes to application isolation MacOS, Android and even Windows is ahead of the common linux desktop. Obviously technically you can employ SELinux rules and what not on applications, but let's look at the adoption of that in the real world.
And that's actually one of the problems Flatpak and Snap are working on to solve. Are the perfect at that? No. But the path is there.
@sheogorath I won't deny that adoption of SELinux and AppArmor rules is... low under desktop environments. I *would* however posit that it is the *most* appropriate method to provide this kind of security. Flatpak, AppImage and Snap just "throw the baby out with the bathwater".
The technical tools are there, and well developed. These can be better integrated with the distribution, and automatically packaged through the existing channels.
Lets not replace what isn't broken.
@nathand Sadly classic packages are pretty much broken. Not necessarily always and everywhere, but just have a look at issue trackers and how often people complain or need to fix package conflicts. Fully automated updates? No way.
Guess why most firmware is not package based. Because you can't estimate the state of the system due to dynamic code that is executed in unknown order + user interference. That's why things like OSTree exist. Classic packages are fine, but not good.
I don't see how packages are "broken". Yes, things do *break* on occasion. Humans are trying to manage a system, they often do it poorly. Package conflicts can be a part of that, but fully automated updates on Debian stable is pretty much already here.
Firmware is a tricky one. Dell doesn't even automatically push firmware to their own devices through their own software. Apple is the only one I've seen do it, and it does break on occasion. Nothing is perfect.
@nathand On the low level components, like firmware we still have some problems, yes. But That's pretty much solved by A/B updates (which again, are pretty hard when using linux packages, but not impossible, see rpm-ostree).
But for everything on top? Look at Android, iOS, MacOS, Windows "Apps". All of them are self-contained formats. Install, updates, remove. The app itself, might breaks, but the updates process?
Or how about power losses in the middle of your .deb install?
@sheogorath Power loss would be an event that is handled, in part, by journaling. A package can then recover that install by unpacking itself over the existing install.
You don't magically fix these unexpected events with app packages. If you loose power during a package decompression or download or any other process might result in a corrupted state.
Most systems adopt this format because none of them support any sort of novel "dependency" system. Everything is static and fat.
I might want to give a little disclosure here: I did my thesis about the flaws of package-based systems and how to solve them. (The answer is pretty much image-based systems for reproducibility and A/B updates to fail back to a working state). OSTree makes it to employ both of those things in combination with very efficient file-based and delta updates. And given that OSTree is the technology beneath flatpak and, well, rpm-ostree, I'm pretty much in for that.
@sheogorath @nathand @neildarlow In addition, application isolation helps solve:
* Everyone agreeing (instead of having to create separate packages for every distro, I can target one distro and have it work on every distro)
* Unmaintained applications and dependencies (this is one of big sells in the enterprise world where containerization got its start, because you can put unmaintained projects behind a firewall and/or up to date services, and keep running them)
@nathand @sheogorath @neildarlow I don't see the problem here. We aren't just adding one new standard to a pre-existing pile of standards. Containers are different from traditional packaging approaches, which is why trying to use them to replace traditional packaging causes so many problems. It's not like someone would consider vagrant a viable packaging system after all.
Plus, when making a container it's best to have a traditional package to act as a basis for it.
@sheogorath @nathand @neildarlow Really, a major part of why containers took off so much in the enterprise is that small, low support, undocumented, and unmaintained or poorly maintained projects are the norm inside companies. Containers give you an IT solution to the problem, and companies have decades of experience setting up a good security perimeter around their shitty internal software.
This is my personal microblog. It's filled with my fun, joy and silliness.