Live data from Hacker News

Ubuntu stops shipping Flatpak by default

lwn.net

341–350 of 624 posts

Re: Ubuntu stops shipping Flatpak by default

#341
post #84

Earlier quoted context omitted.

I don't want debian to be like the android app store, where there are thousands apps that work badly and overflow me with ads. I much prefer the f-droid model, of having curated repositories to keep crap outside. Also, I can't understand why people on the internet think that upstream developers are omniscient. They make lots of mistakes and errors. Distribute maintainers fix a lot of things, and send the fixes to the…

There's nothing stopping someone from making a flatpak or other similar tech feed or 'store' that's only the curated apps they deem appropriate for users. Bugs should be fixed upstream, not kept in distro specific silos. There's no reason why only a packager can fix some upstream issues or become a contributor. On the contrary shipping your app as a universal tech like flatpak means Redhat, Debian, Arch or any other…

Bugs should be fixed upstream but unfortunately sometimes upstream does not see them as bugs - for example, telemetry.

Re: Ubuntu stops shipping Flatpak by default

#342

Earlier quoted context omitted.

> Snaps/Flatpacks/other binary-containerised stuff is one of the major reasons why I abandoned Linux distributions after 22-odd years (1999-2022), and am now a happy Apple user (the other one being abandoning X11 in favour of Wayland, and a switch to laptop-first usage, on which Linux still has horrible power-consumption). Flatpaks/Snaps are almost exactly the same, conceptually, as apps on MacOS. Go look inside some…

> This is why "power users" aren't an important user model. Arch, Gentoo, Nix, and others exist if you want to be a "power user". Otherwise, extremely naive assumptions about the amount of effort expended by distro/package maintainers hand-wave the complexity away with "duh, just put it in Jenkins." Surely distros could be based on top of Nix with carefully curated sets of packages with less effort than it takes to p…

And the advantage of doing this over letting application authors maintain their own packages and deptrees with flatpaks/appimage/whatever is...?

They could be based on top of Nix. In practice, it's more likely they'd be based on top of rpm-ostree. But that doesn't do anything to close the gap between the wild west of copr/ppa/aur and "get your application accepted into mainline repos" for someone who wants to distribute their app.

Re: Ubuntu stops shipping Flatpak by default

#344

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.

What you are really saying is you want all software developers to publish Debian packages (no such thing as "apt" packages) compatible with your particular Debian distribution, even though they might be using a different Debian based distribution, a completely different altogether, maybe even a different architecture, even though that compatibility isn't their primary concern.

> What you are really saying is you want all software developers to publish Debian packages

That's exactly what I want. Developers and Linux distribution maintainers should be working more closely with one another instead of reinventing static linking with "snaps" or whatever just to avoid working with the community.

Re: Ubuntu stops shipping Flatpak by default

#345
post #279

Earlier quoted context omitted.

Another way to look at this situation is that canonical comes up with innovative solutions that are reasonably well engineered out of the box but they are rejected just because they are from canonical. I'm struggling to find a way to characterize the difference between Red Hat/IBM and canonical's approach to the community. The most succinct I can come up with is that canonical releases projects and assumes that they…

> they are rejected just because they are from canonical. Or rather because they're proprietary, often closed-source, like Snap server.

Exactly. Canonical's Snap Store service is closed source and the Snap client is designed to only interface with Canonical's proprietary service. It's not "disinformation" to point out that Snap is a locked-down product controlled by Canonical, while most other packaging solutions for Linux are fully free and open source on both the client and server side. Canonical's one-sided approach to interacting with the Linux community will only encourage Linux users to reject Ubuntu and adopt distros with more sensible defaults.

Re: Ubuntu stops shipping Flatpak by default

#346
post #157

Earlier quoted context omitted.

>> The problem with that model is that it puts the burden on the distro maintainers to package every possible application for their distro. That's kinda what the distros ARE. Also, if you're debian based and debian packages are not compatible with your distribution you're actively fucking something up for "reasons" - stop doing that. If an app can't use a standard .deb or .rpm then the distro is doing something wrong…

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.

> Unless you're statically linking against distro policy they have dependencies on the particular version of the distribution they are built for.

The irony here is that we’re discussing flatpak/snap, which take the idea of static linking to the absolute extreme by doing something closer to a container where every dependency is part of the package. Maybe static linking being “against distro policy” is tossing the baby with the bath water by causing maintainers to reach to a much worse packaging method (snap) because the distro policy is just too obnoxious.

There’s no good reason you couldn’t just statically link (or relocatably copy) your dependencies into your .deb except the distro maintainers being purists. It would make the process of building a deb (or RPM or whatever) trivial because you’re using it as a dumb archive format for your build artifacts, similar to how a container works.

Re: Ubuntu stops shipping Flatpak by default

#347

I mean, you could always just do `sudo apt install flatpak`

Not installing software by default doesn't seem that big of a deal to me.

I mean, first thing I do is install Emacs, which should, but doesn't, come pre-packaged with Linux. vim, sure. gedit, ok.

Re: Ubuntu stops shipping Flatpak by default

#348
post #56

Earlier quoted context omitted.

The original model is that software developers don't package their software for distributions at all, at best they provide helper scripts that the distribution maintainers can use to do that. That's why distributions are typically either giant volunteer-run organizations like Debian or companies like RedHat or Canonical.

The problem with that model is that it puts the burden on the distro maintainers to package every possible application for their distro. And application developers have to essentially wait for each distro to repackage their app before it becomes available on that distro. Or start messing with alternate repositories for each distro they want to support. The old model works for established software, but breaks down a l…

> The problem with that model is that it puts the burden on the distro maintainers to package every possible application for their distro.

That's ... kind of the job of a distro maintainer.

Re: Ubuntu stops shipping Flatpak by default

#349

Earlier quoted context omitted.

Happened to me a few months ago (whenever that big SSL 0-day was announced). I use a 3rd party repo for ZFS drivers, which gets checked for compatibility with each new kernel release by the maintainers, so ZFS frequently stops me from upgrading, and crucially it stops me after I've already fetched the new package databases. Running pacman -Sy and then installing an individual package isn't supported and it's understa…

Interesting! How does the ZFS upgrade "stop" the package upgrade process, I wonder? Might be worth reporting a bug, maybe pacman can handle that kind of failure better, or maybe the ZFS package could be changed to fail more gracefully. I think the pacman devs would agree leaving the system in a partial-upgrade state is a bad thing to do.

It's not a bug, it's intended behavior.

The official release of ZFS on Linux I believe only supports kernel 5.x. Since arch is always on the cutting edge, the repo maintainers need to manually test the driver with each new kernel release before pushing it out to the world. They stop you from borking your system in the interim by having a strict version requirement for Linux on the zfs package. Pacman only does that check, though, once the -Sy operation has finished

Re: Ubuntu stops shipping Flatpak by default

#350
post #238

Earlier quoted context omitted.

My favorite experience with snaps is Firefox just closing in the middle of doing something because it wanted to update, and it didn't even bother to check if I was using it first.

This also happened to me. So I decided to uninstall the snap and “apt install firefox” Guess what I got? A freaking snap. Yes, try it. I’m done with Ubuntu

I can't recommend EndeavourOS enough. You get all the good parts of Arch with an easy to use graphical installer, XFCE or another DE + great Nvidia support out of the box.
Post reply on HN