Hacker News Reader

Comment by MindSpunk | Hacker News Reader

I have almost never had a good experience with Flatpaks as a user, outside of ease of installation. They almost never integrate with the system properly. Wrong theme, wrong cursors, wrong file picker, permission issues, drag-and-drop issues. You often need extra tools that broaden the permissions of apps post-install because some feature won't work (global push-to-talk in Discord is always fun, especially with Wayland).

I couldn't care less about sandboxing if the UX sucks as a result.

If binary portability wasn't such a complete joke on Linux we wouldn't need Flatpak, but here we are.

View on HN

I find Appimage to be better alternative to Flatpak: no install, persistent through linux installations, no issues with themes, icons, Xorg config; in practice - take fraction of flatpak storage size, optional sandboxing with external tools like firejail, easier to run from terminal / dmenu / rofi, very easy to tinker with and fix.

There's just one problem: they don't integrate with desktop without an additional application. We need a feature where dropping an AppImage into "~/.local/share/applications" would automatically detect it as a ".desktop" file and make it appear in the DE menus.

For desktop integration you can use Gear Lever https://github.com/mijorus/gearlever. It can also update AppImages with some configuration changes.

on Ubuntu you can integrate Appimages with AppImageLauncher.

https://www.omgubuntu.co.uk/2022/10/appimagelauncher-install...

Yes! It's very helpful, if you can get it on your distro.

GitHub link: https://github.com/TheAssassin/AppImageLauncher

I disagree. Flatpak pros:

- installing: easy to locate, install and has centralized management for updates.

- flatpaks are also persistent. User-installs are in the home dir.

- sandboxing built-in.

Can't comment on other stuff. Haven't had issues.

sandboxing built-in

This is both a pro and a con. For example, one big downside of this approach is that it can make installing third party plugins and scripts much harder than it should be.

> There's just one problem: they don't integrate with desktop without an additional application

Their biggest problem is that they're not actually truly portable between distributions. They're a gamble of what they're compiled and bundled against, and it's possible for two distributions to not have binary compatibility with each other due to user space differences (different versions, compile flags etc). The kernel developers may not break userspace between updates, but userspace developers certainly have no qualms about breaking userspace.

When you head out of Ubuntu/Debian where developers often build AppImages on (because Linux is a neglected platform and when they think Linux they think Ubuntu), they often fail to run or have errors (e.g. on Fedora). There's more problems such as the terrible practice of encouraging people to set the execute flag on binaries they download off the web.

Flatpak avoids the dependency problem entirely because it's uses runtimes and namespace to ensure reproducible and stable runtime environments.

> I find Appimage to be better alternative to Flatpak

Me too.

But there is a "bigger picture" view of this which I think is important and relevant:

• AppImage encapsulates apps' requirements using the app bundle format from the ROX desktop: https://rox.sourceforge.net/desktop/

• ROX borrowed the idea of app bundles from Acorn's RISC OS, which is still around and is FOSS now: https://www.riscosopen.org/content/

• The RISC OS desktop treats folders whose names begin with a pling (`!`, an exclamation mark) specially. It expects a structure inside with an icon, a launcher script, etc.

• RISC OS also had an "icon bar", a forerunner of the Windows taskbar

• One of the Acorn engineers who worked on RISC OS was head-hunted to NeXT Computer in California. He took his Archimedes with him.

Source: an interview I arranged: https://www.theregister.com/2022/06/23/how_risc_os_happened/

• About a year later, Steve Jobs demonstrated NeXTstep 0.8 with a Dock

• NeXTstep also has app bundles, demarked by a folder called $NAME.app instead of !$NAME

This is a pervasive and influential idea. It's how macOS apps work and that can be traced to RISC OS.

NeXT style bundles are available and work on Linux if you have GNUstep. There are 2 extant GNUstep desktops:

https://onflapp.github.io/gs-desktop/index.html

https://github.com/trunkmaster/nextspace

But there is a distro which takes this idea much further and packages the _entire Linux OS_ in app-bundle directories:

https://gobolinux.org/

I think the makers of Flatpak, Nix, Guix, and Spack -- https://spack.io/ -- all really ought to take a deep look at ROX, AppImage, and GoboLinux.

What all of these do can be done better, in a more human-readable way, if you throw away ancient UNIX assumptions about filesystem directory hierarchies.

This was mostly not designed and was in historical fact accidental anyway:

https://lists.busybox.net/pipermail/busybox/2010-December/07...

I've found AppImages less universally functioning, though. Some segfault on start or have some other weird problems later, while presumably they work great on the author's system.

They seem to work on my current systems, though, and I use a few, but flatpak has always worked on any system, and I expect it has higher chance of working as it delivers more of the system.

Flatpak does have answers for this stuff but it's more the programs inside them aren't utilizing the right APIs, they are meant to use the portals api for filepickers which would use the system filepicker and securely portal stuff through the sandboxing. But many apps just don't.

Theme is also an odd one. GUI design in general has shifted away from an OS theme and more towards an app/product theme which stays consistent between the product on different platforms. Discord for example looks largely the same on Linux, Windows, iOS, and web.

Even for apps that don't use one of the native toolkits like GTK or Qt, where this has been a solved problem for decades, they should at least respond to a dark/light mode flag if they can. Flatpaks mostly don't.

They don't even have the same cursor as the system a lot of the time. It's especially cool when running display scaling when some apps shrink the cursor to a minuscule size too because of poor system integration.

I don't think there was ever a standardised way to publish whether the system was in light or dark mode until the last few years.

If the apps inside need to be specifically coded for it, then why is it "marketed" as a way to sandbox currently existing apps?

I’m not sure flatpak is marketed at all. Users might describe it like that.

From my understanding if you use GTK or QT it just works but many programs have their own custom file pickers which don’t work when filesystem access has been restricted.

I believe it doesn't work for me to open a directory of HTML files in Firefox: it just opens one file, and that's it, so style sheets and links are missed.

I've worked around by running a local web server for that content, but I'd rather if it just worked. The problem is also in some apps that open web browser for their documentation by invoking them directly.

To make the best out of flatpak, it's best to think of it as a new sandboxed distribution that lives on your host system. E.g You could check if a specific theme is installable as a flatpak application.

Flatpaks are not perfect and I have my gripes with flatpak but the only alternative is Ubuntu's snaps.

Ubuntu's Snaps depend heavily on AppArmor which is not present in many of the other top-tier distros which use SELinux, so it's not an alternative.

Semantics. Ubuntu is an alternative to those other "top-tier" distros.

Many of the problems you mentioned are already resolved though.

For example "global push-to-talk in Discord is always fun, especially with Wayland" was solved by using the [Global Shortcuts Portal](https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.fr...).

Most desktop environments / window managers support that portal and stuff like Electron does too, so for example with Slack (installed over Flatpak) in can now toggle mute even If i dont focus Slack.

STEAM on Fedora requires a bunch of incantations on the CLI to get controller support working after Flatpak installation. This pretty much solidifies its flaws as a format. "Table stakes" apps should just work.

Why do these things not work properly when apps are flatpaks? e.g. if an app tries to query the environment and ask "what's the theme", how would it get a different answer when run from a flatpak?

Different answers for different problems, but basically two reasons.

First, library/software/data versions inside the flatpak can and will be different from the ones outside. So a flatpak might as "what is the current Qt5 theme", and get the answer "don't know about Qt5, but the Qt6 theme is cute-cats-qt6" which it cannot interpret. Things like themes might not even be available inside the flatpak, so even if the answer were parseable, cute-cats-qt6 might just not be available on the inside.

Second, flatpaks are sandboxed, so things will be filtered. This means that a query might not get through, an answer might not get through, both might be altered. Or maybe an answer might be useless because "you can get the theme at /usr/share/themes/cute-cats-qt6" points to a path that the flatpak is not allowed to access.

Maybe a contrived example but shouldn't Qt6 be answering with a compatible answer if a Qt5 app asks it what the theme is? And shouldn't the app be asking what the "theme" is, rather than what the Qt5-theme is? It seems like a fundamental issue with compat between apps built for different versions of Qt more than a problem with flatpak?

And is the sandboxing perhaps going a step too far if apps can't access the things they need from the environment?

If Linux libraries had that much respect for backward compatibility, there would never had been any demand for Flatpak. Flatpak (and snap) is merely a workaround for the lack of a common "Linux platform" with comprehensive, versioned APIs analogous to the Windows API or Android API. After all, Flatpak essentially provides a way to run a distribution (provided by Flatpak runtimes) inside the host distribution.

I think that was the role of the distro to integrate a common theme for the various versions of gtk and qt. Yes, it’s often duct taped. But apart from freedesktop, we don’t have an org dictating a common API for stuff like how a graphical app interacts with the DE.

I don't actually know but I guess the issue is that the theme/gui libraries are sandboxed too

You don't need Flatpak at all to have these kind of usability issues, it is deeper than that: For example, if you mount a samba share in the Linux Mint Cinnamon file explorer it is just good to use it from there. Accessing files from the mounted share from "external" apps is a pita (shares are mounted to some obscure path(permission issues), the apps filepickers never have the information that a share was mounted, etc.). If you want usesful access to a samba share you have to mount it via terminal; This way at least the path to the share is short.

I think that because a lot of gtk apps use gvfs[0]. And most kde apps use kio[1]. But if you want files access through the standard syscall. You have to use the standard mount program or fuse.

0: https://en.wikipedia.org/wiki/GVfs

1: https://en.wikipedia.org/wiki/KIO

That's not UX though, it's more theming. If themes affect your UX then there is no pleasing you.

True enough I'm happy with flatpak but I never stray from the default GTK themes.

I was unhappy with flatpak until I found Flatseal, now I include it on all my workstation setups.

But I can't help you with the theming unfortunately, I think that's a sore point for a lot of users that like customizing their Linux DE.

Reply on news.ycombinator.com