Linux desktop leaders unite behind Flathub app store. Here's why • Hacker News Board

Re: Linux desktop leaders unite behind Flathub app store. Here's why

#81

Post by Infernal » Wed, Mar 15, 2023, 5:58 PM UTC

badsectoracula wrote: post #61

gnulinux wrote: post #52

What are people's opinions on Flatpak vs AppImage? I use both (AppImage a lot more so than Flatpak) and I'm not well educated in their differences. I shall research it, but I'm wondering if anyone has some insight to share. Some apps I use (MuseScore) publish their own official .AppImage linux executables which work flawlessly for me, so I cannot abandon AppImage completely. Is it worth it to use both? Is it better t…

AppImage is a more localized approach to Flatpak's "bundle everything" in that instead of trying to have shared libraries across different applications (Flatpak tries to share runtimes), every set of dependencies is local to the application itself. In a way it is kinda like trying to static link everything, though of course it doesn't technically use static linking - and it is really up to the developer what "everyth…

I've looked at your other comments here but I can't find elaboration on the bad parts of AppImage. I tend to agree that AppImage is the best of the available options - do you mean that the best solution would be rich system libraries that never break backwards compatibility ala Windows? And since we don't have that, AppImage is the best we can do?

Re: Linux desktop leaders unite behind Flathub app store. Here's why

#82

Post by [deleted] » Wed, Mar 15, 2023, 6:11 PM UTC

wiseowise wrote: post #13

smoldesu wrote: post #3

Part of my issue with Flatpak is that it takes these systems that really ought to be managed separately (process isolation, package management, runtime configuration, security, etc.) and makes them one monolith. It's an ok stopgap for people frustrated with software distribution, but it tangles itself up in so much mess that it's hard to promote over it's competitors (even Snap). It's not great. Sometimes it works we…

> but when the wiccan magic inside Flatpak breaks now you have to debug two runtimes for the price of one! As a user I couldn’t care less.

[deleted]

Re: Linux desktop leaders unite behind Flathub app store. Here's why

#83

Post by AnIdiotOnTheNet » Wed, Mar 15, 2023, 6:19 PM UTC

kitsunesoba wrote: post #72

Potentially stupid question, is there any reason a "simple" .app bundle like has been used on NeXTStep/macOS for decades wouldn't work on Linux? That doesn't take care of sandboxing, but that seems like it'd be better handled by the OS itself rather than the package management system, and it avoids the problems with overhead and integration that come with things like Flatpak and Snap.

> is there any reason a "simple" .app bundle like has been used on NeXTStep/macOS for decades wouldn't work on Linux?

Conceptually no, and both GNUStep and RoxFiler/RoxOS did just that.

The practical reality though was that Linux Desktop has never had a conception of which pieces are 'add-on' and which are 'base-system', and to the extent there was any collection of components that could be part of the latter they were frequently making breaking changes. Combined with no coherent standard for properly versioning libraries and every fiefdom package repo doing its own thing, and what you're left with is decidedly not a platform.

The modern version of Rox AppDirs is AppImage, and it mostly kinda works on most distros. This is sad, but there's just no way out of it as long as the Linux Desktop community continues to reject the very concept of being a platform.

Steam initially tried to solve this for games by just dragging along its own Runtime for developers to target, but there were still issues. They've since regrouped and basically just declared Win32 the one true stable runtime ABI for games on Linux.

FlatPak just decided that yet-another-package-manager was the way to go and manages a collection of explicitly defined runtimes instead. It works well enough for most use cases.

Re: Linux desktop leaders unite behind Flathub app store. Here's why

#84

Post by AnIdiotOnTheNet » Wed, Mar 15, 2023, 6:23 PM UTC

sirius87 wrote: post #38

brucethemoose2 wrote: post #22

Flatpak is great for self contained apps, but it seems problematic when it has to reach outside the sandbox. I ran into this in VSCode and with CUDA video processing filters, but I'm sure there are more examples. And thats what distro packages are for, I guess.

Try using Flatseal [1] which is a Flatpak app that helps manage permissions for other Flatpak apps. You can see exactly what permissions are enabled in each app's sandbox and expand/override everything from env vars to filesystem locations you want to enable access to. [1] https://github.com/tchx84/Flatseal

There are still things Flatseal cannot make work though. For instance, the Wireshark FlatPak is incapable of actually capturing packets.

Re: Linux desktop leaders unite behind Flathub app store. Here's why

#85

Post by hotpotamus » Wed, Mar 15, 2023, 6:27 PM UTC

2OEH8eoCRo0 wrote: post #45

blendergeek wrote: post #33

I owned a Librem 5 phone and used it as my daily driver for a few months. During this time I exclusively used Flatpaks for my apps that I installed. After installing about 15-20 apps, the 32 GB of internal storage were completely full and my phone stopped working. I had no clue how huge Flatpak apps are. Even worse, I could not find out which apps to delete. All the space was taken up by excess "runtimes" I don't kno…

Could this be solved by smarter layering? I've read that Flatpaks are just container images under the hood and I'm sure many of those share the same base layers.

And thus we re-invent shared libraries? Like that's not even really a snarky question; isn't that sort of restarting the cycle?

Re: Linux desktop leaders unite behind Flathub app store. Here's why

#86

Post by 2OEH8eoCRo0 » Wed, Mar 15, 2023, 6:33 PM UTC

hotpotamus wrote: post #85

2OEH8eoCRo0 wrote: post #45

Earlier quoted context omitted.

Could this be solved by smarter layering? I've read that Flatpaks are just container images under the hood and I'm sure many of those share the same base layers.

And thus we re-invent shared libraries? Like that's not even really a snarky question; isn't that sort of restarting the cycle?

Good point. Yes. But there are too many versions and varieties. In the same vein there is a lot of variety of image layers. What problem does Flatpak solve? I assume it's because it's tough to create Linux desktop applications when you have no idea what shared libraries, compiler, or version expect.

Re: Linux desktop leaders unite behind Flathub app store. Here's why

#87

Post by MayeulC » Wed, Mar 15, 2023, 6:39 PM UTC

blendergeek wrote: post #73

kirbyfan64sos wrote: post #55

Earlier quoted context omitted.

There should certainly be more tooling around finding these things out, but one thing worth noting is that you can `flatpak uninstall --unused` to remove old, unused runtimes (the runtime environments for apps).

Wait ... they don't get removed automatically? Is my system is guaranteed to fill up completely if I don't run that command regularly?

Unused End-of-Life runtimes get removed automatically now (as of 1.9.1), but the answer is a bit more nuanced than that, especially if there are multiple users on the same system (that could have user-specific flatpaks that use system runtimes).

It could also benefit users that have more disk space than bandwidth (I was in that situation for a while, though a mechanism for sharing runtimes with LAN peers would be nice).

Discussion: https://github.com/flatpak/flatpak/issues/2639

Remove EOL automatically: https://github.com/flatpak/flatpak/pull/3871

Re: Linux desktop leaders unite behind Flathub app store. Here's why

#88

Post by badsectoracula » Wed, Mar 15, 2023, 6:44 PM UTC

Infernal wrote: post #81

badsectoracula wrote: post #61

Earlier quoted context omitted.

AppImage is a more localized approach to Flatpak's "bundle everything" in that instead of trying to have shared libraries across different applications (Flatpak tries to share runtimes), every set of dependencies is local to the application itself. In a way it is kinda like trying to static link everything, though of course it doesn't technically use static linking - and it is really up to the developer what "everyth…

I've looked at your other comments here but I can't find elaboration on the bad parts of AppImage. I tend to agree that AppImage is the best of the available options - do you mean that the best solution would be rich system libraries that never break backwards compatibility ala Windows? And since we don't have that, AppImage is the best we can do?

Yes, i meant for the "how things should be", the comments i meant were those backwards compatibility which is the root of the problem and AppImage is just a workaround for it.

Re: Linux desktop leaders unite behind Flathub app store. Here's why

#89

Post by Tanoc » Wed, Mar 15, 2023, 6:45 PM UTC

gnulinux wrote: post #47

lenkite wrote: post #29

Earlier quoted context omitted.

Once the linux world moves completely to Flatpak, that would truly help languages like C++ - whose evolution and cleanliness has been tremendously crippled by being unable to have a clean ABI break.

I know this is a controversial opinion, some would strongly disagree with me, maybe most would consider me downright wrong . But as a system designer I always thoughts (by always, I mean last ~5 years since I've been thinking about this) the misery we experience with C/C++ package management is an OS problem, not a language problem. The fact that some languages roll their own package manager like pip, npm, cargo etc…

I know this is going to sound like a stupid question, but does MuseScore run versioning control? Like can you use $sudo apt-get install musescore=4_0_2 as you can with other packages like Tenacity or Dolphin?

Re: Linux desktop leaders unite behind Flathub app store. Here's why

#90

Post by hotpotamus » Wed, Mar 15, 2023, 6:46 PM UTC

2OEH8eoCRo0 wrote: post #86

hotpotamus wrote: post #85

Earlier quoted context omitted.

And thus we re-invent shared libraries? Like that's not even really a snarky question; isn't that sort of restarting the cycle?

Good point. Yes. But there are too many versions and varieties. In the same vein there is a lot of variety of image layers. What problem does Flatpak solve? I assume it's because it's tough to create Linux desktop applications when you have no idea what shared libraries, compiler, or version expect.

I always thought of containers as essentially a universal linux package manager. If you ever yum install something and see it pull in dependencies, it's not like there's an elegant software solution that makes that happen; it's work done by people who maintain lists of what each package requires and compatible versions. Red Hat puts considerable effort into that, and it's work duplicated by other distros, each with their own packaging idiosyncrasies.