Now we need this to run without the need to install another Linux / FlatPak runtime beforehand. o) From my perspective, an archiving tool needs to run “bare metal”, because archives are often used to setup a system, extract other tools or personal data. Therefor it should not rely on probably x-hundred of megabytes to be installed / downloaded before it can be used.
An AppImage would be a solution to this, but being able to run this from an existing folder without the need to clutter the system at all, would be even better.
org.gnome.Platform 50 is shared across every GNOME Flatpak, and anyone running GNOME Software or a single Flathub app already has it.
I think that’s a fair assessment. Nobody recovers a machine from a libadwaita GUI. That job belongs to 7zz — a single static binary that Septima bundles unmodified and never links against. Septima’s entire reason to exist is a desktop tuning UI; if you’re in a position to run it, you have a desktop session, which means GTK4 and libadwaita are already on the box.
On personal data specifically: Septima ships with no filesystem permissions. Not --filesystem=home, not a single path. Every file it touches comes through a portal, so you grant access to exactly what you picked and nothing else. 7zz runs as a child inside that same sandbox — it can’t reach anything the GUI can’t. That’s four lines of finish-args total, and it’s in the manifest if you want to check. A bare-metal build is the one thing that can’t give you that.
This is a small install, and anyone with a flatpak install already has all the tools this app needs. No extra runtime downloads required.
No.
For a GTK4/libadwaita app you’d have to bundle GTK4 itself, libadwaita, gdk-pixbuf loaders, GIO modules, the icon theme, fontconfig, and the GL/Vulkan bits GTK4’s renderer needs — built against an ancient glibc, then debugged per-distro against host driver and theme mismatches. You’d land north of 100 MB, larger than Septima.flatpak, and it still unpacks itself into ~/.cache on every run. That’s more clutter !
There are many reasons not to use AppImages at all, mainly the update mechanism, the securities platform, the deprecated dependencies of fuse2- . . .
libfuse.so.2 — FUSE 2. libfuse 3.0 shipped in December 2016. Upstream has treated the 2.x branch as maintenance-only for years, and distros have been steadily dropping it. The format sold as “no install, no clutter, just run the file” asks the user, on a current mainstream distro, to install a deprecated system library with root, before it will run. The Flatpak runtime is bigger, but it installs --user, needs no root, is shared across every app that targets it, and isn’t deprecated by its own upstream.
You could. . . skip FUSE by unpacking the entire squashfs to a temp directory and running from there — every single launch. For a GTK4 bundle carrying GTK, libadwaita, pixbuf loaders and GIO modules, that’s ~100 MB of extraction per start.
FUSE needs /dev/fuse and a working fusermount. Both go missing in exactly the environments a lot of Linux users now live in:
image-based distros — on Silverblue/Kinoite, layering fuse is an rpm-ostree overlay and a reboot, which is a genuinely funny outcome for the low-friction option
hardened setups where the setuid fusermount helper is restricted
AppImage has no proper update mechanism . . . Signatures aren’t enforced. . . You can’t overwrite a running AppImage so you end up AppImageUpdate writing the new version alongside the old one, so ~/Downloads accumulates Septima-0.5.0, Septima-0.6.0, Septima-0.7.0… and the user would have to prune by hand.
We’ve been having these discussions for years, I chose the format looking forward as I always have. Hope you enjoy it and share.
Do you exaggerate AppImage drawbacks a little bit? o) Modern AppImages don’t seem to require FUSE (FUSE v3 is built into modern AppImages) and FUSE v2 does not seem to be problem, even on my “ancient” Debian 12 right now. (I will look closer at the “immutable distro” problem you mentioned! Thx!) You can run AppImages inside of Docker containers by using the “--appimage-extract-and-run” option in case of problems. There also is an update mechanism for AppImages (using these *.zsync files).
But I actually don’t want applications to self-update(!). In a professional / business environment, you don’t want things to auto update, you need to test drive new software excessively before it will be rolled out. New versions often drop features, rearrange UI or introduce new bugs, on a production system, you don’t want any of this. A static, not self-updating AppImage gives me just that.
FlatPaks also don’t run easily in a container, they need a desktop session with DBUS and systemd, that’s what I found out while learning from your very detailed reply. Thanks for that! o)
I am not diving into more “format wars” here, no worries.. o)
I would like FlatPak more, if libraries would actually be shared across the whole system, not just by FlatPak applications. FlatPak solved the “multiple versions of a single component”-problem on Linux, which regular package managers never did, so there is some enhancement in the FlatPak runtime I like, but it is an “island” solution still (to me). I always wonder why there is no “FlatPak” Linux to boot into, so the whole system would benefit from the enhanced version management.
I am mostly a Windows user, I collect applications for 25 years in a “category” folder structure on the network. I can run games and applications from there, they keep their versions, they don’t need to be installed again and again. I setup a new PC by simply copying applications and their folders from that central folder structure onto the new PC. I can also run things easily from USB (or network) when using Windows.. and “AppImages”, well.. They get very close to that freedom and ease of use. Just my two cents of view of course, so you know where I am coming from. o)
Thank you again, I think I got your point:
“Septima” is made for desktop use, after the system is fully setup and “charged” with the FlatPak runtime - fair enough. o)
This is why I provide a bundle that’s outside of OSTree, so you don’t have to ever update. You could also, mask the update using flatpak mask <app> and it will never do so. ( Did this with Gradience before I forked it, and have threads here on how to mask others…)
You kind of mention Fedora Silverblue here a bit. . . It’s kind of that way, but not as intergrated as it should be because of portals development.
If you’ve downloaded it, hope you enjoy ! v0.5 is literally year in the making for me. I had scripts, and a layout years ago to solve batch archiving with passwords + bartch decryption. it’s finally a thing.
