Using AppImages under Puppy Linux.....

[mikewalsh]

Afternoon, guys'n'gals.

Since we have no idea if or when the Murga-Linux database will ever be merged with this Forum, I'm going to re-create this thread about AppImages here.

AppImages are, as many of you know, an easy, 'portable' way to run apps. They're the Linux world's nearest direct equivalent to Windows' PortableApps. A properly-constructed AppImage has absolutely everything required for it to run, and does NOT need to go off hunting around the host OS to find missing dependencies.

Unfortunately, some less-than-scrupulous developers/packagers seem to think you can just do a direct "rip" of an existing .deb/rpm package.....with the effect that your AppImage still bitches about not finding x, y or z. Which kinda defeats the object, n'est-ce pas?

------------------------------------------------

New guy Shloz has posted this morning about the LibreOffice AppImages. I'll post links for these, and am, for now, going to post a few others:-

Okay. Now, these are all guaranteed to run OOTB in Bionic64...

LibreOffice AppImages - https://www.libreoffice.org/download/appimage/

GIMP builds from aferrero @ Github - https://github.com/aferrero2707/gimp-appimage/releases

Shotcut video editor - https://www.shotcut.org/download/

Blender - This isn't an AppImage, per se, so much as a self-contained 'portable' - https://www.blender.org/download/Blende ... 64.tar.xz/. That's a direct link; d/l, unzip, enter the resulting Blender directory, and just click on the executable.

LosslessCut - Best video cutter/trimmer I've ever found, both for functionality, and ease-of-use - https://github.com/mifi/lossless-cut/releases

Webcamoid - Fun webcam app, along the lines of Cheese (only more so!) - https://webcamoid.github.io/

Stellarium - Needs NO introduction - http://stellarium.org/en_GB/

Last but not least (for now), Digikam.....the KDE project's photo-organiser. KDE stuff always wants a bucket-full of extras specific to the Plasma desktop. These ARE big packages, no getting away from it - nearly 400MB - but they run OOTB. These are the older 5.9.0 release, from my Google Drive; newer versions just generate segfault after segfault, even in the newest Puppies. I've even had the 32-bit version running in Slacko 570 with a few tweaks:- https://drive.google.com/drive/folders/ ... sp=sharing Help yourself to the one you want.

These will get the thread off to a start. If any of you find a working AppImage, for whatever application, and you'd like to share, please add details to the end of this thread. Thanks!


Mike.

[nic007]

Maybe one day all software for linux will be made to run on all linux distributions and versions (one fits all). What a day for celebration that will be.

[mikewalsh]

Maybe one day all software for linux will be made to run on all linux distributions and versions (one fits all). What a day for celebration that will be.

Heh. 'Twould be nice, wouldn't it?

Trouble is, most of these things seem to be written for modern hardware, pre-supposing powerful CPUs, large amounts of RAM, etc. I agree with what you've said about these in the past; as they stand, they don't really gel with the Puppy ethos of keeping elderly, low-resource hardware alive.....after all, Puppy has always been about keeping things mean'n'lean, cutting code bloat, streamlining the way stuff works, etc. I DO agree with that.

With this new desktop I now have, the contrast between old & modern - I still have the old P4-powered Dell lappie, and it still runs - just becomes even more apparent! Nevertheless, with 16 GB RAM, you can run half-a-dozen AppImages simultaneously, have two or three browsers open at the same time, and the hardware takes it all in its stride.....it's a real eye-opener to me after the elderly Compaq desktop, I must say. But then, Pup's versatile enough to be able to run on all manner of 'puters, regardless of their abilities...and as time goes by, even the second-hand equipment many of us "make do" with is becoming steadily more capable in what it will let us do with Puppy.

I still wouldn't switch to anything else..!


Mike.

[mikewalsh]

Double post.....sorry!

[Shloz]

Maybe one day all software for linux will be made to run on all linux distributions and versions (one fits all). What a day for celebration that will be.

Heh. 'Twould be nice, wouldn't it?

Trouble is, most of these things seem to be written for modern hardware, pre-supposing powerful CPUs, large amounts of RAM, etc. I agree with what you've said about these in the past; as they stand, they don't really gel with the Puppy ethos of keeping elderly, low-resource hardware alive.....after all, Puppy has always been about keeping things mean'n'lean, cutting code bloat, streamlining the way stuff works, etc. I DO agree with that.

With this new desktop I now have, the contrast between old & modern - I still have the old P4-powered Dell lappie, and it still runs - just becomes even more apparent! Nevertheless, with 16 GB RAM, you can run half-a-dozen AppImages simultaneously, have two or three browsers open at the same time, and the hardware takes it all in its stride.....it's a real eye-opener to me after the elderly Compaq desktop, I must say. But then, Pup's versatile enough to be able to run on all manner of 'puters, regardless of their abilities...and as time goes by, even the second-hand equipment many of us "make do" with is becoming steadily more capable in what it will let us do with Puppy.

I still wouldn't switch to anything else..!


Mike.

Just curious, in the case of LibreOffice how does the appimage compare to the sfs resource-wise assuming the same version in both?
And, is there any other benefit to sfs over appimage I should be aware of?

[nic007]

Double post.....sorry!

Mike, one can delete ones post completely (result as if no post has been posted). Quite handy actually.

[nic007]

Maybe one day all software for linux will be made to run on all linux distributions and versions (one fits all). What a day for celebration that will be.

Heh. 'Twould be nice, wouldn't it?

Trouble is, most of these things seem to be written for modern hardware, pre-supposing powerful CPUs, large amounts of RAM, etc. I agree with what you've said about these in the past; as they stand, they don't really gel with the Puppy ethos of keeping elderly, low-resource hardware alive.....after all, Puppy has always been about keeping things mean'n'lean, cutting code bloat, streamlining the way stuff works, etc. I DO agree with that.

With this new desktop I now have, the contrast between old & modern - I still have the old P4-powered Dell lappie, and it still runs - just becomes even more apparent! Nevertheless, with 16 GB RAM, you can run half-a-dozen AppImages simultaneously, have two or three browsers open at the same time, and the hardware takes it all in its stride.....it's a real eye-opener to me after the elderly Compaq desktop, I must say. But then, Pup's versatile enough to be able to run on all manner of 'puters, regardless of their abilities...and as time goes by, even the second-hand equipment many of us "make do" with is becoming steadily more capable in what it will let us do with Puppy.

I still wouldn't switch to anything else..!


Mike.

Must be completely puzzling to a complete newby from Windows world that every version of Puppy (mostly) and Linux in general requires its own, specifically compiled software just for that specific version of operating system. It's not like in the Windows world where you download say one VLC 32-bit setup file good to run on all Windows 32-bit versions (hardware of machine permitting). I normally use 5 Puppys. Each one has its own compiled version of VLC for example

[mikewalsh]

Double post.....sorry!

Mike, one can delete ones post completely (result as if no post has been posted). Quite handy actually.

Hm. Just tried that.....but it appears it only works IF they haven't been replied to. Still, thanks for the info; I'll remember that in future. So long as you do it at the time of posting, that's one thing we couldn't do on the old Forum.....

(Still haven't quite got used to this one yet. I keep hitting the Quote button instead of the Edit one..!)


Mike.

[01101001b]

Maybe one day all software for linux will be made to run on all linux distributions and versions (one fits all)

Somehow I doubt it
_

xkcd-standards.png (51.18 KiB) Viewed 1608 times

[mikewalsh]

Just curious, in the case of LibreOffice how does the appimage compare to the sfs resource-wise assuming the same version in both?
And, is there any other benefit to sfs over appimage I should be aware of?

@ Shloz:-

Generally speaking, I would say the most noticeable difference is perhaps the size.....even though the SFS packages of LibreOffice tend to be humungously large, they do assume that certain dependencies are installed by default in most distros.

An AppImage will still include these 'standard' dependencies, since the principle is to include absolutely everything - including the kitchen sink! - needed for them to run. As Mikeslr will tell you, an SFS occupies no "Puppy-space" when it's not loaded. An AppImage, on the other hand, always unpacks itself into /tmp, and runs from there while in use; when you close it, the content it placed into /tmp then disappears...

Horses for courses; it's very much personal choice. I like AppImages for their ease of use, and as for size, well.....16 GB RAM tends to allow for an awful lot of 'bloat' without needing to concern yourself as to the consequences...! They're not everybody's cup of tea, though....

What it boils down to is this; use whatever works for YOU. There's no "right" or "wrong" way of doing so many things in Linux; if it works for you, and you're happy with it.....great.


Mike.

[nic007]

Just curious, in the case of LibreOffice how does the appimage compare to the sfs resource-wise assuming the same version in both?
And, is there any other benefit to sfs over appimage I should be aware of?

@ Shloz:-

Generally speaking, I would say the most noticeable difference is perhaps the size.....even though the SFS packages of LibreOffice tend to be humungously large, they do assume that certain dependencies are installed by default in most distros.

An AppImage will still include these 'standard' dependencies, since the principle is to include absolutely everything - including the kitchen sink! - needed for them to run. As Mikeslr will tell you, an SFS occupies no "Puppy-space" when it's not loaded. An AppImage, on the other hand, always unpacks itself into /tmp, and runs from there while in use; when you close it, the content it placed into /tmp then disappears...

Horses for courses; it's very much personal choice. I like AppImages for their ease of use, and as for size, well.....16 GB RAM tends to allow for an awful lot of 'bloat' without needing to concern yourself as to the consequences...! They're not everybody's cup of tea, though....

What it boils down to is this; use whatever works for YOU. There's no "right" or "wrong" way of doing so many things in Linux; if it works for you, and you're happy with it.....great.


Mike.

It seems as if an extra sfs file when loaded only takes about 10MB of space.

[mikewalsh]

Since we now have access once again to the old forum and its treasures.....here's a link to the ORIGINAL thread over at Murga-Linux:-

http://oldforum.puppylinux.com/puppy/vi ... e1642075fd

Enjoy.


Mike.

[666philb]

lots of electron appimages here http://murga-linux.com/puppy/viewtopic.php?t=119151

[Puppyt]

Hiyer Mr mikewalsh,
I have a desktop unit running FossaPup64 (9.5) set up for a video editing project, and installed Kdenlive19.12.3 via the fossa quickpet. Nice, but a bit behind the latest version 21.12.2 - which is available as an AppImage for Linux - and prolly geared up for Ubuntu as it seems to be otherwise available on the Ubuntu ppa. Anyways, after made executable as you indicate earlier, I'm stumped that the latest AppImage doesn't work OOTB in FossaPup64- a title screen flashes up and drops out. Nothing is generated in /tmp either. Is there a method to check for incompatibilities etc to solve this? (The nightly build Olive-76831a2b-Linux-x86_64.AppImage works OOTB, by contrast) I'll revert to trying out the PPA method I guess, and see what dependencies might be otherwise missing. Thanks for your work in the AppImage area

[Phoenix]

You need to run via terminal then instead of 'clicking' on it. @Puppyt

[mikeslr]

There's some kind of incompatibility between KDEnlive and fossapup. I've tried three different versions --AppImages 17, 19 and 21-- including starting them from the terminal. The furthest I get is a disfunctional desktop and a notice to the effect "There's something wrong with your installation; try re-installing it".

As you mentioned, Olive run fine. So do AppImages and MikeWalsh's portables of Openshot and Shotcut. It's not worth my time and effort to try to find out what KDEnlive does wrong.

[Puppyt]

Thanks Phoenix and mikeslr for your comments - relieved to see that it isn't just me, I had those appimage successes with the non-Kdenlive editors too.
Cheers Phoenix I tried (??) to run any app from terminal to see the dependency/incompatibility errors but I couldn't seem to work out how to have FossaPup64's roxfiler identify the .appimage as an executive - to enable the "Run from terminal" leftclick option. I'm a bit rusty - currently beating a hurried retreat from Win10pro on most of my core2duo machines to get back into the Puppy fold - didn't spend time on writing a script that might enable "run from terminal" and show diagnostic verbose errors with installation/operation.
Instead, I was able to workaround with kdenlive 19.12.3 SFS installed via quickpet - I had started a project with that already, but couldn't get the introductory clip effects I was looking for with all the online video tutorials that use the later versions (21.12.2). Always learning...

[Phoenix]

By terminal I mean actually launching one rather than using ROX-Filer's nifty option. So click that icon that looks like this '>_'. Then type in cd /path/to/appimage/directory then issue ./appimage-name.AppImage. If permission is denied then issue chmod +x ./appimage-name.AppImage. (You may ask why not omit the ./? Because bash will interpret it as that it is under the variable PATH, search through the directories listed under PATH, then fail. Sometimes it works, but that depends on where the filepath is placed at in the console. Simarly omitting the / will make cd think 'relative', thereby attempting to change to foobar directory within the current one. Which most likely doesn't exist!)

[mikewalsh]

@Puppyt :-

It doesn't always occur, but I often find with AppImages that are based around Qt5 that, for whatever reason, they're simply not "seeing" their own, included Qt5 libs.

fredx181 did figure out a way of adding the 'LD_LIBRARY_PATH' clause to the active, mounted paths in /tmp (where these things typically unpack themselves for the duration), but that's fraught with peril since they use different paths within /tmp every time you launch them..! Far better, I find, to unpack the things with the

Code: Select all

--appimage-extract

.....argument, which results in what is essentially a RoxApp. Then you can look inside the things, add a re-jigged launcher with a "pointer" to their own libs, followed by doing one of two things:-

• Either run them as they are, essentially as a 'portable' app, or

• Attempt to re-pack them back into an AppImage.....we have several guides to doing this in various locations around the fora nowadays. Sometimes this works, other times it won't.....

YMMV.

Mike.