The Future of Flatpak

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.

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

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

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.

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.

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

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

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.