AppImages For Linux Distribution. Considered?
System dynamics program with additional features for economics
Brought to you by:
hpcoder,
profstevekeen
Hiya,
Have decided to take this route that does not allow one to author posts
even using web forums as it seems only reasonable format or displays the
expending of purposed energy in hope to pass on something important.
Not a Windows users even with turn of change of attitudes in recent
times however would like to ask if AppImages have been considered as the
package unification for all Linux distributions.
ArchLinux's AUR recent incidents tells us Linux is gaining serious
ground and that the Software Author + Maintainer dynamic is getting
problematic.
Thus enters AppImages which emphasizes Software Authors package their
own software. Fruits from this is you just do it once and it runs
everywhere just like Java with requirement being Runtimes, "JRE".
This even supersedes "JREs", not the Joe Rogan Experience yes haha,
whereby all of dependencies are packaged into the blob you version and
push out thus even with older Linux distribution versions your program
with forever run.
I'll now take my resignation with this piece from AppImage docs as to
why Software Authors should publish their own packages -
https://docs.appimage.org/introduction/upstream.html
--
Regards,
A Wanderi
Hi A Wanderi. I have indeed considered doing an AppImage version of Minsky, ever since I discovered the format about 6 months ago (I am a long-time Linux user of 33 years now, having first installed the SLS (soft-landing system) distribution when Linux was 0.9 something).
I have been aware of Flatpak and Snap formats for some time, but didn't seriously pursue them: partly because they are not as efficient as native packages, in that they require bundling dependent dynamic libs, and partly because again - being annoyed at the Linux ecosystem for having more than one way of doing things.
What has changed? Since late 2022, we have built the front end using the electron framework. Using Electron blew up the footprint of Minsky by at least two orders of magnitude - what was a piddly little 5-7 MB native package, suddenly become 6-700 MBs. But it does support creating Snaps and AppImages out of the box (sadly, no Flatpaks). AppImages look like the easiest. But more work is required. I need to pick a distro, possibly the one I use for development (OpenSUSE), and copy the required dynamic libraries to support the backend node addin. Adding those into the distribution will not bloat the final package size too much, given it is already bloated by the Node.js runtime. But it requires a bit of time to do the necessary work, which I've been sadly deficient on :).
BTW - every time I run into yet another gotcha with Ubuntu or Fedora OBS distributions not building due to stricter package requirements, the AppImage approach starts to have a lot of appeal! Plus, AppImages will allow Minsky to run on a wider ranges of distros than can currently be supported via OBS.
Not a fan of both Flatpaks and Snaps.
The former completely ignores XDG variables and it's always a pain fishing config and storage/databases paths for apps using this packaging format. The security objectives are understandable but I'm not a pentester running programs I want to isolate or give very limited access to my system. If a program is hovering up my data and presenting "adware" leave alone being malicious I am not running it!
The latter is owned by Canonical and with recent popularity or "tailwinds" for GNU/Linux I see no barriers of management + stockholders losing their heads and locking this down to only "Ubuntu" offerings. Polite language is these platforms controlled by them would become "tightened".
Hypothetically R. Standish if a UI rewrite was in the offing today spiriting it away from the Node.js Framework + Chromium Runtime which UI framework do you fancy for this rewrite?
--
Regards,
A Wanderi
On Fri, Jul 24, 2026 at 08:59:56PM -0000, A Wanderi wrote:
Understood. AppImage will probably be the first, and perhaps only way
of doing this distro-independent packaged solution. I would continue
to maintain the OBS packages, but probably reduce the diversity of
platforms supported, as it is an overhead.
Nothing. We moved from TCL/Tk to Electron, and the advantages of huge
ecosystem, and more sane scripting language (as if Javascript could be
called "sane") have far outweighed the disadvantages (such as
bloating). AFAICS, the only other practical alternative is Qt, but
that is a very distant third IMHO. I suppose there's also the
possibility of doing a Java front end, but my impression is this would
have all the disadvantages of the Electron solution without any of the
upside.
--
Dr Russell Standish Phone 0425 253119 (mobile)
Principal, High Performance Coders hpcoder@hpcoders.com.au
http://www.hpcoders.com.au