Ubuntu stops shipping Flatpak by default

Post by simon_o » Wed, Mar 29, 2023, 1:00 PM UTC

Kinrany wrote: post #142

dTal wrote: post #121

Earlier quoted context omitted.

I can't make out what you're disagreeing with - you seem to be arguing against something I didn't say? The point is that the contents of an AppImage - "a dynamically linked executable + lots of dynamically linked libraries" - works just as well without all the squashfs backflips. If you can ship an AppImage, you can ship a regular ol' tarball with a binary named "RunMe" inside. The purpose of an AppImage is simply to…

> But I've seen no justification why that should be co-mingled with package management. Building sandboxing on top of package management makes a lot of sense because you want sandboxing to work by default, and for that you need to identify the sandboxable things without making the user point to each one individually.

Post by skeletal88 » Wed, Mar 29, 2023, 1:02 PM UTC

wilonth wrote: post #161

Wow they're still pushing snaps, the project with some the worst engineering I've ever seen. - Extremely slow at doing anything, even the most basic commands. - Ridiculous auto-update mechanism (you can't even disable it wtf). - Random, nonsense limitations (why can't I open dot files and dot directories???). So terrible that for most apps that I installed with snaps I end up installing the deb version later on. What…

Post by esarbe » Wed, Mar 29, 2023, 1:04 PM UTC

necovek wrote: post #50

petepete wrote: post #9

Mir, Unity, now Snap. Ubuntu has a track record of wanting to go it alone. But, I'm all for competition, long may it continue. The only real negative here is that some apps will only release Snaps, others will only release Flatpaks and people will end up having to just revert to copr/AUR like before. Choosing a distro is basically choosing a DE and package manager these days anyway - a single unified packaging format…

To put things into context, snaps were created before flatpak: in a sense, RedHat wanted to go at it "alone" (or at least separately from Canonical) with xdg-app/Flatpak. These ideas were already present even before those times and outside of both RH/Canonical, so it was more of a who's committed first. Basically, Ubuntu phones were using click packages (predecessor to snaps) back in 2011 and 2012, with snapcraft shi…

Post by jovial_cavalier » Wed, Mar 29, 2023, 1:05 PM UTC

mg wrote: post #108

I wish there was a solution like flatpak or snap that does make things simpler, not more complex. To begin with: It would be nice if the data of the containerized applications were stored in one place and one place only. Each application should simply be a single directory in /snaps/ or something. At first I thought snap would be like that. But no. When I did some tests, the data of a snap seems to be splattered acro…

Post by biorach » Wed, Mar 29, 2023, 1:10 PM UTC

Nursie wrote: post #173

veeti wrote: post #157

Earlier quoted context omitted.

Have you ever actually worked on distribution packaging? There is no such thing as a "standard" .deb or .rpm. Unless you're statically linking against distro policy they have dependencies on the particular version of the distribution they are built for. You can't take a "standard" .rpm from the Fedora repositories and install it on CentOS. You can't take a .deb from Debian 11 and install it on Debian 10.

> You can't take a .deb from Debian 11 and install it on Debian 10. I mean, you can, if you also install its dependencies. And you may end up with a weird franken-system, but you can. You can even automate it and set preferred distros with pinning, it's how people run things like hybrid testing-unstable distros.