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

/cc @neildarlow@fosstodon.org

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

/cc @neildarlow@fosstodon.org


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?

/cc @neildarlow@fosstodon.org

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



@nathand Again, I have to disagree. First of all, the .deb dependency, in worst case, breaks your entire system so it no longer boots. With image based systems with A/B updates, not really.

When it comes to desktop applications true, you can try to re-run your .deb install and hope for the best, but your system is in an unknown state. flatpak on the other hand, uses atomic transitions to update an app. Means it's always in a known-good-state.

/cc @neildarlow@fosstodon.org

Sign in to participate in the conversation
Sheogorath's Microblog

This is my personal microblog. It's filled with my fun, joy and silliness.