Hacker News Reader

Comment by contrarian1234 | Hacker News Reader

Flatpak is one of those pieces of software that's clearly made by people with nice computers on fast internet

You want to install a calculator app? That'll be multiple gigabytes of download. Mere mortals now have to wait half an hour to get the app.

What's even more insane is at the command line when you Tab to autocomplete the thing makes network requests and hangs! It's the only CLI app I know what requires the internet to autocomplete!

I think the thing has been a complete flop. The multi gig "backends" are all versioned weirdly and I find they're very rarely reused between applications.

Static builds in AppImages are smaller and faster and don't have weird UI issues. AppImages just need maybe an external update mechanism and more standard system integrators. But I'm glad that fundamentally the app format and the updater and system integrator are decoupled. These kitchensink app "systems" seems just big and ugly

View on HN

Flatpak itself is not enforcing this. You can ship a statically linked binary with no dependencies if you want.

The runtime thing that flatpak supports is, ironically, to minimize and deduplicate common dependencies, and to be fair they are only downloaded with the first app that needs it with many apps using the same handful of runtimes. The fetish for shared dependencies within Linux and the pains it causes are a bit frustrating, but that's not new to flatpak.

> What's even more insane is at the command line when you Tab to autocomplete the thing makes network requests and hangs! It's the only CLI app I know what requires the internet to autocomplete!

nit: CLI tools do not implement auto-complete themselves. What you are seeing are auto-complete scripts for your shell that make network connections.

Not sure if flatpak keeps a local repo list. That would be the only way to implement tab-completion of installable items without making network connections.

It does not keep a repo list bc the CLI needs to be constantly directed to the particular repo you want to use/inspect. It doesn't default to flathub and there is no sources.list equivalent. So therefore there is no cache and it needs to constantly ping the server to do anything. This makes the whole interface incredibly sluggish to the point that it's frustrating to navigate and explore. So you end up using the crappy website (as compared to something snappy like aptitude)

Frankly shared dependencies makes sense when they're sort of wide-consensus. Debian-stable or Ubuntu-LTS. Everyone is building to work with the same set of version numbers and they are all rock stable for years. Rolling shared dependencies is just a recipe for broken apps. It's just a combinatorics problem. You can't test against every combination of every version of all your dependencies.

And multiversion shared dependencies .. I don't even understand the point (and why Nix has always confused me)

There is shared consensus: https://docs.flatpak.org/en/latest/available-runtimes.html

> CLI tools do not implement auto-complete themselves. What you are seeing are auto-complete scripts for your shell that make network connections.

nit: This is incorrect. Robust auto-complete scripts call the actual program to provide completions.

That is what Flatpak does. It is Flatpak itself that makes the network connections.

https://github.com/flatpak/flatpak/blob/main/completion/flat...

Not that it would make any differencen if it was implemented in Bash seeing as the Bash script is also provided by Flatpak.

AppImages are also very big. Example: Blender [0] (210MB), OBS [1] (105MB), Ungoogled Chromium [2] (166MB)

The only alternative that does not lead to downloading 100s of MBs of files is .deb/.rpm files and the associated "the prebuilt binary needs libfoo.so.4.0.1 but Debian ships libfoo.so.4.0.0" problems. Which ultimately means you pull even more dependencies than the Flatpak runtime for building (gcc, make, CMake, libfoo-dev, libfoo-dev's *-dev dependencies,...) and spend a long time compiling the application (also suited only for high memory, high core count machines).

[0] https://www.appimagehub.com/p/1169218/

[1] https://www.appimagehub.com/p/1409898

[2] https://ungoogled-software.github.io/ungoogled-chromium-bina...

Right; one way or another a program needs all of its dependencies. The traditional model was that a distribution would include one version of each dependency (most of the time) and share that between all the programs on the machine. Of course, that didn't work if you couldn't use that version, so the alternative is to somehow bundle dependencies in with your program (appimage, Firefox-like tarballs, plain static binaries) or ship them separate (flatpak, maybe docker).

I've been using it as a digital nomad on shaky southern european airbnb and hotel connections for the past year and I have no complaints.

I was skeptical to it, until I realized it uses cgroups for isolation. Now I'm actually quite fond of it, because I've recently converted to using immutable linux distros.

> You want to install a calculator app? That'll be multiple gigabytes of download. Mere mortals now have to wait half an hour to get the app.

The SDKs are shared between applications, just like a traditional package manager. So this is a fixed cost.

Also I think the sum of GNOME and Freedesktop SDKs is closer to 1GB, than multiple gigabytes.

As others have pointed out, in reality the SDKs are very often not really shared and you end up with multiple copies. This doesn't happen (and is basically impossible) with a traditional package manager

Not sure if you've used Flatpak before, I have 108 flatpaks installed with just 3 runtimes, and one of those runtimes is for a deprecated app that won't even update for my distro anyway.

Flatpak means I can continue to use it far into the future.

You end up with just 3 runtimes only when you're either very lucky or very picky.

I have a handful of apps and 3 flatpak runtimes on my phone right now and that's only because I'm the latter (and have to be because of 32GB eMMC).

I have a similar 5.7" 32 GB eMMC device that runs a debian-ish distro with Phosh GUI, where I have been installing flatpaks left and right (without caring which runtimes they use) for a reason ([0]) since early 2022.

I am now at 107 total flatpaks, 18 of which are platform packages (= 89 apps+locales). If I were to remove five outdated apps, that are archived or inactive upstream, I would be able to get rid of four platform packages (I really should, but I don't want to for sentimental reasons).

I have found things to scale similarily across devices: The more flatpak apps you use, the better the ratio gets. If you just use one app, you may end up with 3 Platform packages for it if you are unlucky, making that one app an incredible disk space eating monster. When you have 50 flatpak apps, things will look way better.

Now, would I like to have all these as native deb, rpm, tar.xz (arch), apk? Yes.

But I would also like to use the latest version, making that pretty much a pipedream - and in some cases the distro packages (mostly on Alpine and the AUR) aren't always as functional.

I am really glad flatpak and flathub are a thing.

OT, regarding alternatives discussed in other threads:

AppImages aren't really a thing on aarch64 (also, I use Wayland, which probonopd does not seem to be a fan of [1]).

Snaps: I had 'wrong arch' failures when attempting to run what was promoted as arm64 on Snapcraft.

[0]: https://linuxphoneapps.org

[1]: https://gist.github.com/probonopd/9feb7c20257af5dd915e3a9f2d...

Oh, don't get me wrong - Flatpak is definitely better in a lot of ways than Snap or AppImage. Just let's not pretend that it doesn't eat a lot of space, because it does. It does not scale linearly with number of apps because of deduplication, sure, but you still can easily get the runtimes alone to consume more space than your whole underlying OS with a full set of apps installed natively, and for little benefit - Flatpak makes it unreasonably hard for users to switch the app runtime to a newer one even it it's perfectly compatible and could instantly free gigabytes of disk space.

I don't think app distribution should be dominated by "app store" type solutions; distro repos are an important part of the system too. But there's definitely a use case for "app stores" too and Flatpak fills that niche pretty well, although it still has some really annoying details to sort out before it can actually be as useful as it should be. Thankfully, these issues are mostly about the frontend - the backend seems rather solid already, which is great, so maybe it's just a matter of time until better frontends appear.

> I have a handful of apps and 3 flatpak runtimes on my phone right now and that's only because I'm the latter (and have to be because of 32GB eMMC).

I mean, yes Flatpak will use more disk space than everything being packaged with the distros native package format, although in larger amounts you get a better ratio.

This is the trade off that has to be paid, Linux has no stable userspace ABI like Windows (so, Microsoft doesnt need to ship multiple versions of a dll), it's already the norm in the server space with containers, where it's been extremely successful. Flatpak goes a step further than OCI by having native deduplication due to OSTree (although there is push to get this on servers too)

Do I think the trade off is outweighed by the advantages? Yes, absolutely. I have used Fedora for 10 years (currently using uBlue/Silverblue) and Flatpak makes installing things like Discord, Slack, Steam etc 10x easier on Fedora than it's ever been (partially due to no or outdated rpms).

I certainly would not use it for all apps.

But for things like Steam or Lutris, I happily sacrifice some GB to run a more stable and isolated version.

> Note: This is a community package of Steam gaming plaform not officially supported by Valve. Report bugs through linked issue tracker.

The flatpak is not officially supported by Valve

Is the Arch Linux or Debian package shipped with those distros officially supported by Valve?

I’d still take an unofficial wrapper over that time Steam was wiping home directories.

Ah, that's a very fine point. The rpmfusion RPM isn't officially supported by Valve either.

Edit: Valve releases tarballs and a .deb package. Why would they release a .deb when Arch (which steamos is based on) doesn't use .deb? Releasing a .deb makes me think they test the thing on Ubuntu or Debian

If I recall correctly, Ubuntu has been the only officially supported distro since Steam first came to Linux.

The've moved to arch in recent years, the steam deck itself is running a modified version of arch linux.

> The multi gig "backends" are all versioned weirdly and I find they're very rarely reused between applications.

I find that they're generally rather well shared between apps. I use Tumbleweed and only install apps via Flathub. I have around 40 apps and I don't have this problem. It was a problem when I used 4 Flatpaks and the rest came from system repos.

>You want to install a calculator app? That'll be multiple gigabytes of download. Mere mortals now have to wait half an hour to get the app.

The top 2 calculator apps were under 5mb in size. I'm not sure what point you are making because the hyperbole was too extreme. <2s?

I have every shade of computer and wifi connectivity and waiting <60s-<5min for a download, one time, isn't going to change any experience. We forgive one time downloads. We do not forgive weekly forced reboots and dealing with autosaves M$.

> What's even more insane is at the command line when you Tab to autocomplete the thing makes network requests and hangs! It's the only CLI app I know what requires the internet to autocomplete!

I'm pretty sure that it's a bash-completion feature / "fault".

No command is really executed while your are typing in a terminal until you press "enter".

not entirely true. See: https://news.ycombinator.com/item?id=38302908

Well, technically is still bash who does the tab-completion, flatpak just provides a helper.

Try tab-completion under pure sh or powershell

> It's the only CLI app I know what requires the internet to autocomplete!

Oh that's actually a killer feature of kubectl for me. It's also used by a lot of tools around Kubernetes as well. It makes me not only faster, more certain of results of my commands in advance, but also makes me easier to understand to others when I share what's going on on environments.

Yeah, it does suck if API is far away, but the benefits are too great.

> Flatpak is one of those pieces of software that's clearly made by people with nice computers on fast internet

But like, it's 2023... Having that requirement isn't a hard sell. Especially considering the base of Windows and macOS have fancy requirements as a base.

Also, Flatpak allows for lib dependencies to avoid duplicate libraries from filling up your disk. Not really sure what else you expect.

> Also, Flatpak allows for lib dependencies to avoid duplicate libraries from filling up your disk. Not really sure what else you expect.

Assuming that the app developers play nice and all agree to use the same (latest?) version of the libraries. In which case Flatpack becomes just a clone of Debian/Arch.

If app developers don't play nice (which is most likely), Flatpack becomes more of a bloated version of Nix/Guix.

Part of this "bloat" is sandboxing, which is the main feature I recommend anyone to use flatpak for apps like Discord or Zoom.

> But like, it's 2023... Having that requirement isn't a hard sell.

I know several people who are on a shitty data limited connection. Their internet becomes basically unusable after a windows update tore through it.

Hell the company I work for still hasn't found anyone willing to replace its ancient line with anything remotely modern and the multi connection + mobile network workarounds we have going breaks down the moment there is even a drop of water in the air.

2023 just like the years before it is a year where the network providers don't give a shit about decent service.

There are still plenty of people who do not have access to fiber or even cable. I am one of them. I have a single flatpack app installed, and I rarely apply available updates because each update weighs in at close to 1 GB.

Yeah, I have a friend whose family switched from dial-up internet to DSL only in the mid-2010s.

> But like, it's 2023... Having that requirement isn't a hard sell. Especially considering the base of Windows and macOS have fancy requirements as a base.

I think this is a sad attitude, when software actually has quite a high carbon footprint[1] on par with the aviation industry. There is so much old hardware that would work just fine if we actually cared to make software that works for them.

I think new software should lower the requirement, and better hardware should mean faster software, not that developers can get wasteful.

[1] https://foundation.mozilla.org/en/blog/ai-internet-carbon-fo...

There was a video from Twitter shared on HN a while back of Windows 95 or 98 (I don't remember which) running on a modern computer, and all programs and menus loaded instantly when clicked, not like now where there's often a small delay. It would be great if better hardeware meant the same thing but snappier, rather than the same thing but more inefficient.

However, that speed came at the cost of laborious optimization for the low-end computers of the time and millions of dollars spent by Microsoft debugging defective C and assembly code within Windows.

The only way to force software to be more efficient would be some sort of cap on how inefficient software were allowed to be, which doesn't seem possible. At most, you can have a carbon tax, or increase taxes on electricity use, indirectly incentivizing the use of energy-efficient software.

Another way can be to try to lower the bar to write performant code. For example, the work in languages like Rust, Nim, Hare and Roc might also unlock capabilities to write low-level performant code with the same productivity as high-level languages.

I def. agree though tat a carbon tax to force companies to be more frugal would help too.

I've heard too many times to not think about optimization and just throw more hardware at problems, I think that's a mentality we really need to start questioning.

I agree Rust lowers the bar to write low-level performant code (especially considering that it was always harder to write correct C than, say, correct Ada) but I don't think it's always necessary to write code in non-garbage-collected for decent performance. We just need to use garbage collected programming languages that are statically typed, don't rely on a runtime on the host computer (e.g. the JVM), are memory safe and have predictable performance characteristics. All I can think of are Swift, OCaml, and Standard ML. In Go, your program causes a segmentation violation if it dereferences a null pointer, so I won't call it completely memory-safe, but it's still an improvement in abstraction compared to C while still providing performance.

> It's the only CLI app I know what requires the internet to autocomplete!

Doesn't autocompleting `sudo dnf install ...` do the same?

And what kind of security do AppImages offer you?

You might find this shocking, but in many parts of the world "nice computers on fast internet" is kind of a given now. So for those, even if it is "gigabytes", it is worth it for the various benefits like security or convenience, for example.

You might find this shocking, but in many parts of the world "nice computers on fast internet" is kind of a high-end luxury right now.

Come on it's not. A good midrange machine from 2015-2018 is still running fine today.

Security of my calculator..? Is this a theoretical or actual concern? Are you getting hacked through outdated AppImages? The Snap/Flatpak sandboxing has been widely criticized but I'm not an expert to judge. I'm guessing you can run your AppImage from something like a chroot if that's a real concern

I've never had an AppImage hacked.. (or honestly anything else hacked on a Linux machine) though I'm not running AppImage servers

> in many parts of the world "nice computers on fast internet" is kind of a given now

Well if they want to be an appstore solution for the Linux ecosystem then they need to cater to everyone, not just rich kids in silicon valley

The concern isn't the calculator getting hacked, but the calculator itself being malicious, and there being a desire to safely install programs without opening up your whole system to them.

A calculator should be run as a fully isolated application, with no filesystem access and no ability to damage anything even if it tries.

>Security of my calculator..?

I could upload a "Calculator" application that looks harmless, and even functions as a calculator, but actually steals your GPG keys and logs keyboard input. With a sandbox this would not be possible (in theory).

A "calculator" app isn't really unique here, it can be malicious just as well as anything else could be.

You do not want "apps" to be able to do this at all!

A calculator shouldn't really have access to many things anyways, ideally only access to things it requires to function.

You can enjoy security and convenience without requiring users to download, install and update a dozen different system images just to run some simple apps.

I have a few apps installed via Flatpak there are multi-gigabyte updates several times a week, usually for the base images under the apps themselves. I apparently have 3 different copies of GNOME, more than half a dozen platform images, and several copies of the Freedesktop SDK.

Many Flatpaks aren't sandboxed, either.

It's this kind of comment that makes me worried for the future of computing.

> And what kind of security do AppImages offer you?

None and no one said that it does offer any kind of security. The criticism was entirely unrelated to that.

On the other hand, flatpaks sandboxing is also severly limited by the fact that most packages do not make use of it much. In the past the runtimes offered by flatpak were also lacking behind on critical security updates [0]. Did that change in the meantime?

[0] https://flatkill.org/2020/

Flatkill is full of misinformation or no longer true information. There're many posts debunking most of their points [1]. Some parts were true a few years ago but aren't anymore.

Edit: They removed many of their examples at some point, so it's no longer as bad of an article.

For example if VSCode wouldn't have direct access to the file system, it would be unuseable since it doesn't support portals to ask the user to grant it access to specific folders (by selecting them through the file picker).

In the process of packaging an app for flathub, the packager has to provide some reason for why for example full file system access is necessary. The discussion to add or remove permissions are always open [2].

[1] https://theevilskeleton.gitlab.io/2021/02/11/response-to-fla...

[2] https://github.com/flathub/net.lutris.Lutris/issues/229

It doesn't, it's the whole "do one thing and one thing well", where it's only concerned with having a single executable without any dependencies. You run them with Firejail for security/sandboxing.

> And what kind of security do AppImages offer you?

It shouldn't. Security should be implemented as a separate tool, not tied to any package management system.

Recommended video from Distro maintainer who advocated AppImage and didn't like Flatpak a few years ago:

https://www.youtube.com/watch?v=4WuYGcs0t6I

Its a recommended watch.

Which calculator app is multiple gigabytes in size? How is that even possible!?

When the RPM felt out of time, I switched from SuSe Linux to Kubuntu. Now I use a ubuntu based distro (Bodhi). This flatpak stuff may make me leave ubuntu.

Ubuntu uses Snaps by default. Flatpaks are an option in Ubuntu only if you install the application.

My current version uses mainly DEB. Due to some personal issues I am not up to date with my OS. I install 99% of my software with apt and deb packages. I don't like Snaps and Flatpaks.

Yes, I have to update soon but I will do this when I buy a new Dell XPS

Reply on news.ycombinator.com