Live data from Hacker News

Ubuntu stops shipping Flatpak by default

lwn.net

191–200 of 624 posts

Re: Ubuntu stops shipping Flatpak by default

#191

Earlier quoted context omitted.

I agree. Maintainers are useless middlemen (at best) who only exist because of Linux userland's particular diseases and a desire for distros to rule over their own little repo fiefdoms. No other desktop OS has done it like Linux and for good reason. People have been citing this as a reason they don't want to use Linux as a desktop for decades to mostly deaf ears, who then turn around and wonder loudly why no one want…

This has to be the dumbest take on this thread. If you want the dystopian hellhole you seemingly long for, just use Android and enjoy the ad-infested crapware? No reason to moan about things you seemingly don't understand.

[deleted]

Re: Ubuntu stops shipping Flatpak by default

#192

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…

I have no idea how to update firefox because of this. I get some notification about not being able to update but it doesn't tell me why.

You have to quit Firefox and then manually update the Snap. I thought restarting Firefox would trigger auto-update, but no.

Re: Ubuntu stops shipping Flatpak by default

#193

Earlier quoted context omitted.

This puts too much unnecessary burden on developers and maintainers. It doesn't make sense to adapt software to tens of distributions (and then to different OS like FreeBSD). Apt should be used only for system software (like init system, system libraries) but not for applications. Also apt allows to run scripts as root during installation and this is not secure.

There's a Pareto effort, of course. If you release Debian and Redhat packages, you cover 80% of the user base. It's not hard to maintain, if you compare to building msi installers. Further, the process of generating packages for derivatives of debian or redhat can be mostly automated, so user coverage is bound to grow if your package is popular. As for root requirements, what you are asking for are (non privileged) u…

I go to cool app website, I click download, I get a '.deb' file, I click .deb file, it opens some installer GUI (instead of Ark because I'm lucky today), I click install, I get error, I google error, I find cryptic commands that modify my system in weird ways just to get the app to install, I install app, I open app, it crashes, I open firefox, I get error "error: libX.so.1.2 not found", I can no longer google the error.

The system package manager is convenient when it works, because it's already there. But that's about it. Using it to install any random apps is a recipe for disaster, it leads to fragmentation since everyone on a different distro uses different commands/workarounds to fuck up their systems in different ways when trying to install poorly packaged software.

If everyone just used Debian, we wouldn't need Flatpak, but obviously that's not the case. Whenever you find a "linux app" that's packaged for distroA, but you're on distroB, there's a chance that it will work. That is 100% luck and coincidence, because most linux distros just so happen to ship the same family of system software/libs, sometimes even with the same versions.

Rather than leave it up to the undefined behavior lottery, a standardized non-system packaging format can guarantee that things will work across any distro. That's better for everyone involved: users, sysadmins, distro maintainers, and developers. Whether Flatpak is that format idk, but IMO it's the best overall out of the three main contenders (Flatpak, Snap, AppImage)

Re: Ubuntu stops shipping Flatpak by default

#194
post #154
post #133

Earlier quoted context omitted.

As someone who does this for a lot of distros (ZeroTier), I can say that it is hell and I understand why devs don't want to do it. Two specific examples: (1) For some reason a lot of Debian distros decided to rename and/or re-version-number OpenSSL for no good reason (pedantry is not a good reason), meaning if you depend on OpenSSL/libcrypto your packages will mysteriously break all over the place because you're not…

> Snap, FlatPak, and Docker are all variations on the same basic conclusion that many developers reached long ago: "fuck it, just distribute software in the form of tarballs of entire Linux installs." ..wait a minute > (2) We use a UPnP library called miniupnp in the current version. We have to statically link it because of issues like (1) and also because some distros were for a time stuck on a version that had secu…

It solves some of the problems, but not all, and it requires a lot of testing and trial and error and setup. Sometimes libraries are hard to statically link. Sometimes you have problems with different glibc versions.

I forgot to say: some distros that people still use are too old for us to build for, so we build fully static binaries for those. But you can't really statically link glibc, so we build them on Alpine statically linked with musl. That usually works okay. It's the best we can do for the old stuff.

We've invested a lot of time in this. For most developers I totally understand "fuck it."

Re: Ubuntu stops shipping Flatpak by default

#195

Earlier quoted context omitted.

Conversely, `pacman -Syyuu` doesn't complete reliably without user intervention, which is far from ideal. I say this as an Arch user - the expectation that I'm going to manually attend to package upgrades in practice leads to me using outdated packages

I'm genuinely curious about this, as I see people say it a lot but it's not my experience at all. I have an Arch Linux desktop (KDE + AMD), I update it every few days, and it's always fine. I also have a shell VM that runs IRC etc that often isn't updated in months, and I run `pacman -Syyu` and everything works fine. I've never had the infamous 'Arch updates are unreliable' issue. Is it certain packages that are more…

I think it depends on when folks were using Arch. I've been using it since 2007, and back then before the "conf.d" configuration file convention became common, it was very frequent that you would need to manually merge your local config files with the upstream one. If you screwed up or forgot, your system would be some variety of hosed. It's become much, much less common in the past ~10 years. I'd hazard a guess I only have to manually attend to an update once or twice a year now, where it used to be almost daily.

Re: Ubuntu stops shipping Flatpak by default

#196
post #173
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.

That's the point though: this sort of thing is not ridiculous on most OSs. I should be able to use old versions of software (or new ones for that matter) without having to worry about causing my system to catch fire and explode.

Re: Ubuntu stops shipping Flatpak by default

#197

Can we go back to just shipping apt packages? They worked fine, and I don't feel like having multiple types of containers and update methods and mounted image file systems really made anyone's life better.

When Let's Encrypt changed the installation instructions to heavily recommend Snaps, I was quite disappointed. I'd been using their apt package for years already, across my fleet, and to have them suddenly change tack and all but disavow their apt repo made me question my choice in them for the first time.

Would their apt repo suddenly disappear? Probably not, but who knows.

Re: Ubuntu stops shipping Flatpak by default

#199
post #173

Earlier quoted context omitted.

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

Yes, but the difficulty and franken-nature of the resulting system means that it's not for the faint of heart.

So upgrade the whole thing. It's open source so in most cases that's possible.

Re: Ubuntu stops shipping Flatpak by default

#200

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…

My father in law has been driven mad by the snap notification that say you have to close an application within the next 30 days in order for it to be updateable.
Post reply on HN