Puppy Linux Discussion Forum

nic007 wrote: Wed Aug 05, 2020 5:39 am 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 wrote: Wed Aug 05, 2020 10:01 am

nic007 wrote: Wed Aug 05, 2020 5:39 am 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 wrote: Wed Aug 05, 2020 10:03 am Double post.....sorry!

mikewalsh wrote: Wed Aug 05, 2020 10:01 am

nic007 wrote: Wed Aug 05, 2020 5:39 am 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.

nic007 wrote: Wed Aug 05, 2020 1:39 pm

mikewalsh wrote: Wed Aug 05, 2020 10:03 am Double post.....sorry!

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

nic007 wrote: Wed Aug 05, 2020 5:39 am Maybe one day all software for linux will be made to run on all linux distributions and versions (one fits all)

Shloz wrote: Wed Aug 05, 2020 10:52 amJust 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?

mikewalsh wrote: Thu Aug 06, 2020 12:13 pm

Shloz wrote: Wed Aug 05, 2020 10:52 amJust 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.

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

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

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.

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

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!)

@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

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