Puppy Linux Discussion Forum

[muggins]

I don't know if this has been mentioned on the forum before but, for people having problems getting various apps going with puppy, this is well worth checking out. I've only tried a few of the apps, so I'm not sure 100% will work, but the idea is just download the app you want anywhere, then click & run.

http://portablelinuxapps.org/

[Dingo]

it is a project focused on Ubuntu and derivatives (users reported portablelinuxapps work only on Lucid Puppy)

it seems that app is wrapped, with its dependencies, in a ISO filesystem (like filesystem used by CD)

not very useful, since puppy is worth to use also in builds older than Lucid Puppy, and this project cannot give advantage to Puppy 3.01, 4.3.1 users

so, this portability, is not really universal

[stu90]

Yes i have been using portable linux apps for a while now - some of the applications i have tried on lucid puppy.

Audacity
Avidmux
Boxee
Calibre
Chromium
Deadbeef
Dropbox
FBreader
Firefox
Gimp
Inkscape
Keepas
Opera
Peazip
Qbitorrent
Remobo
Scribus
Seamonkey
Skype
Teamviewer
Terminal
Viewnor
VLC
Wireshark
Xara Extreme

[ICPUG]

and what was the result of your tries? List of what works and what fails would be helpful.

[technosaurus]

I was previously in communication with the author of Magic Ermine (a program that packages up portable linux apps) One of the issues for compatibility is whether the stack smashing protector is enabled. The other was that "statifying" an app that is built with shared libraries produces large files. Eventually I concluded that it would be better to compile them statically and use these tools to pack up the necessary extra files the program needs (the default font, config files, image files, xml etc...)

The biggest difference is resource usage. The portable apps this way _can_ use internal shared libraries that are different than the system libraries, which prevents the kernel internals from being able to share them (causing a HUGE increase in resource usage on otherwise relatively small, low impact programs). If they don't use internal libraries, that's when you get library version mismatches/inconsistencies and stack smashing incompatibilities. The reason this works on windows portable apps is because all the libraries are essentially the same with the same flaws and vulnerabilities and the basic system libs won't need to be packaged (thus the smaller package size).

I am currently building many essential core apps as static uclibc binaries - I may eventually add some uclibc++ apps as well, but the core focus for now is to have a set of fail-safe apps to fall back on in the case that there is a problem with shared libraries. This includes at a minimum: busybox, an Xserver, window manager and a terminal emulator.

As an example:
jwm is <1mb as a static uclibc binary but over 5mb when statified with glibc shared libraries. mcwm is only 71kb compared to ~2MB.

The compromise solution for a linux app to be truly "portable" is to compile the apps statically and use these packaging tools to bundle any extra required files. In my limited testing, the efficiency of uclibc more than overcomes the kernel's memory sharing (due to glibc's issues)

Static uclibc apps actually use less resources than their shared glibc counterparts... at least with current kernels and glibc. Whereas you may see improvement in the kernel, you shouldn't expect any GNU project to _actually_ improve. Look at the number of "won't-fix" glibc bugs if you don't believe me - you can't even compile glibc with -Os anymore (I do have a patch for it though) The uclibc and busybox team on the other hand are very responsive to bug reports

FYI - before anyone asks - yes I have tried it with dietlibc and yes it is more efficient _if_ it works - the number of required patches was just too time consuming. You can get pretty close to the same results as dietlibc with uclibc if you simply compile with -Os -ffunction-sections -fdata-sections and link with --gc-sections. (this is because diet moslty splits out each function to its own file so that it gets its own object - this makes it easier for the linker to eliminate unnecessary functions)

[harii4]