Live data from Hacker News

Ubuntu stops shipping Flatpak by default

lwn.net

261–270 of 624 posts

Re: Ubuntu stops shipping Flatpak by default

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

>> 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. If you're using a "Debian based" distribution, the "standard" .deb is the one shipping with Debian. If it doesn't work on the derivative distro, they are doing something wrong. Or like I said, maybe the dependencies are…

Find a deb packaged for an older version of Debian and see if it runs, there's no guarantee, if the software was closed-source you're basically out of luck, unless people statically link all of glibc, ssl etc into their application which is a big no no.

This is the problem that Flapak, Snap etc try and solve. I won't put AppImage onto that list because it actually doesn't solve the problem it just makes it worse.

Re: Ubuntu stops shipping Flatpak by default

#262

Earlier quoted context omitted.

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.

You're shifting more work onto distros and users that shouldn't be work in the first place, and basically preventing non-linux literate people from using their OS.

If I install software on MacOS or Windows, I don't have to care if it was packaged for an older version etc, or that my distro may not package a dependency.

Re: Ubuntu stops shipping Flatpak by default

#263
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

Everyone's done with Ubuntu. It's just not good. Its got a stereotype at this point for being the easy noob distro but that's not even true. Its top to bottom awful and has been for many years.

Re: Ubuntu stops shipping Flatpak by default

#264

Earlier quoted context omitted.

Hot take: package distributors are 'fake jobs' that don't need to exist, or exist only for the make-work of packaging. Tools like flatpak, snap, appimage, containerization, etc. have made the need for adapting software to different distributions unnecessary.

What's the base image for the containers? Do none of your Dockerfiles have apk or apt commands?

It's best practice not to have any shell tools in your app container, including package managers. It bloats the image and can be a security vulnerability if a zero day exploit hits the app. Ideally a container is something like distroless which just has the libc and dependencies you care about and nothing else, not even bash.

Re: Ubuntu stops shipping Flatpak by default

#265
post #239

Earlier quoted context omitted.

Snaps are getting me off Desktop Ubuntu after 12 years of happily using it.

Canonical seems to be trying to push users off of Ubuntu. I switched to Arch from Ubuntu about 6 years ago after seeing how aggressively Ubuntu would auto-update, and because of Zeitgeist. I would never look back. Arch is customizable, simple (in the sense that there are no surprises; things work as expected), and has a great community. Folks here can argue about snaps or flatpaks, and I can happily use AUR to instal…

I also switched to arch for a bit, but then I was left with an unbootable system after the arch devs shipped grub's master branch as stable. The arch devs were completely unapologetic and told me 'well maybe you shouldn't use arch if you can't recover a system who won't boot'

Immediately formatted and switched to pop OS and I've never been happier.

Re: Ubuntu stops shipping Flatpak by default

#266

Like many, I have had my fair share of frustrations with snaps. Already considering moving away from Ubuntu, but not sure where to go next. Is Debian a good option? I use Linux both personally and professionally, so while I do like to tinker with new stuff, I also need some stability. I've used rolling-release distros in the past and its something I'd like to try again. Maybe Manjaro?

I stopped using linux 6 years ago when i realized it had become a glorified desktop cuztomization software for me. Now I use Windows, and on the extremely rare occasions that I need Linux, I use WSL2. But for the most part I do everything on Windows with Powershell

I only use windows for flight simulator, everything else is extremely frustrating for me, it feels like a battle against the OS. May not be the experience of many, but for me Linux stays out of my way or, rather, lets me define what the "way" is. Wouldn't switch for anything :)

Re: Ubuntu stops shipping Flatpak by default

#267

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…

Deleting and pinning snapd is the first thing I do on every fresh Ubuntu install. Next, install ff from mozillateam ppa and chromium from flatpak.

Re: Ubuntu stops shipping Flatpak by default

#268
post #106

Earlier quoted context omitted.

What I would like to see is: 1) a unified database for package names (it's all unnecessarily ad-hoc right now, with different distros having different policies for capital letters, whether libraries are prefixed with "lib", whether python packages have "py" or "python" or "py3" etc... 2) a standard format for declaratively describing how to build a package. Basically, we have FreeBSD ports, Arch PKGBUILDs, Void templ…

Congrats you just invented containers :P

Not sure how you figure that. Containers are completely orthogonal to both of my requirements, which again are 1) a globally canonical package namespace, and 2) tooling to convert some standard recipe file format into distro-specific recipe files (which would require point 1 to work).

Re: Ubuntu stops shipping Flatpak by default

#269

Like many, I have had my fair share of frustrations with snaps. Already considering moving away from Ubuntu, but not sure where to go next. Is Debian a good option? I use Linux both personally and professionally, so while I do like to tinker with new stuff, I also need some stability. I've used rolling-release distros in the past and its something I'd like to try again. Maybe Manjaro?

I've moved from Ubuntu to Fedora and it's been more stable while also being more up-to-date without rolling-release distros headaches. Strongly recommend it.

I gave Fedora a try some years ago (4-5?) and had a couple of issues with nvidia drivers. Whats the status these days? I also have a long history with debs, so going to rpm is a mystery for me :)

Re: Ubuntu stops shipping Flatpak by default

#270
post #121

Earlier quoted context omitted.

No, an Appimage still ships a dynamically linked executable + lots of dynamically linked libraries, that only link against system libraries when strictly needed, e.g glibc and libGL. Those files are bundled in a squashfs and have a script setting a custom LD_LIBRARY_PATH to the squashfs content for the binary. Snap does use this technique, too, but does more, for worse. AppImages are not comparable with statically li…

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…

> Flatpak requires you to run programs with "flatpak run" - yuck

To begin with Flatpak makes .desktop files so no one should be needing to use that command manually.

Secondly, Flatpak has an option folder you can add to your path that lets you run applications by running their FQDN. e.g. org.gnome.Gimp myFile.png rather than gimp myFile.png

Post reply on HN