Static programs - isolating library $PATH [SOLVED}

[amigo]

A statically-linked program will require more RAM simply because it is larger. The size difference can be dramatic, depending on just how many libraries it needs. Of course, using a couple may be alright. But some of the things you might most want to have as statically-linked applications may be very large indeed -FF, Seamonkey, Thunderbird, Chrome, etc.

Still, the best way to keep things small is to know exactly what each thing needs. Only very good dependency information can provide this -and dependency info can only be accurately determined *at compile time*. Since even compile-time options can change the requirements of a lib/program, let alone inter-versional differences, the real requirements can only be determined on the build system, at build-time.

[npierce]

[quote="greengeek"]Heres an example: Lets say I want to start with a stripped down Puppy (pupngo) and add only two other programs - a word processor and a browser: Imagine that both of those programs are labelled as being “statically linked

[sunburnt]

And that`s exactly what RoxApp or AppDir or AppPkg does.
They setup a run environment for the app. and then run it.
This is $PATH, $LD_LIBRARY_PATH, and links and dirs. needed.
No union[/n] is needed for these apps., they work with or without one.

If Linux and it`s apps. were setup properly, no need for the links and dirs.
But the original creators of Unix couldn`t have known of this type of use.

amigo has a RoxApp setup that compiles the app. for the distro ( very nice ).
This is the best arrangement for installing odd apps. into odd Linux distros.

As I`ve said, Ubuntu Lucid-Precise are very compatible with the Puppy versions.
I`m sure there`s a few apps. that would have problems, but not many.
So AppPkg or RoxApps made from these should work very well.

AppPkg is compatible with RoxApps, but it allows multiple apps. in one.
It allows app. specific local libs., and AppPkg shared local libs., and it
uses the Linux O.S. shared libs too of course. So no lib. conflicts...

There are other things that keep an app. from working, but libs. are a big one.

[greengeek]

OK, so you are basically trying to prevent the age-old problem of newly installed packages overwriting shared libraries with versions that are incompatible with previously installed programs. You want each program to be able to find a library that is compatible with it without stepping on the toes of other programs' libraries.

Yes you've summarised it nicely.

Still, while the implementation of library versioning is imperfect, it might be worth reviewing here how things are SUPPOSED to work.

Yes, thank you for the indepth info. It is very helpful. It seems to me there will be times when I want to try and do the right thing, and other times when I will want to cut corners, and just get something going the quick and dirty way - but it helps a lot to understand the risks and potential solutions.

Perhaps it was helpful to the understanding of why the problem exists, or perhaps not.

Very much so. Thanks.

I realize that we no longer live in a world where RAM is measured in kilobytes and disk drives are measured in megabytes -- if you've got the space, use it as you like.

Somehow buying a PC that has more than 1 GB of RAM seems morally wrong. And I have heaps of older machines that would benefit from a lean O.S. Apart from that I feel very insecure using software that is bloated and inefficient. Rightly or wrongly it makes me feel that it is potentially full of spyware and other nasties. (ok, it's probably not...)

Either way, I would agree with amigo that your best bet would be to place any needed libraries that do not already exist on the distro, and any that are incompatible with the existing libraries, in a separate directory, and use a wrapper script to set LD_LIBRARY_PATH before launching the program.

Excellent summary. Thanks. On that note I shall mark the topic solved, although I am still very keen to hear of other methods of "sandboxing" apps to avoid conflicts.

And that`s exactly what RoxApp or AppDir or AppPkg does. They setup a run environment for the app. and then run it. This is $PATH, $LD_LIBRARY_PATH, and links and dirs. needed. No union[/n] is needed for these apps., they work with or without one.

Thanks. I will look into this a bit more. Howdo these apps compare with CDE for usability or practicality? Totally different?

[npierce]

You're welcome. I'm glad to hear it was helpful. Good luck with your project.

[sunburnt]

I looked at CDE and I didn`t like how the packages are built ( usage ).
I think it`s messy making them and also messy using them ( try one...).
CDE only shares or includes libs., it doesn`t manage them like AppPkg.
The concept is somewhat similar to RoxApps and AppPkg, but I did not
see that CDE was any better in any regard, and not so good in some.
All of these package types are; No union, and no install or uninstall.

RoxApps and AppPkg are easy to make and work well ( simple is good ).

I`ve designed a small minimal Linux O.S. that only uses AppPkgs.
The O.S. loads into ~ 30 - 40 MB of ram. Apps. run from ram or device.
It only has rxvt, text editor, a few other utilities, and an AppPkg builder.
All other apps. are AppPkgs, so they`re easily added and removed.
Basing it on stable Ubuntu versions means no app. compiling`s needed.

[greengeek]

I'd be keen to have a try of your OS. Any links?

[sunburnt]

The only working setup I made was based on Tiny Core Linux as it`s close.
Puppy`s boot is complex and it uses a union FS, Tiny Core doesn`t.

It`s like John Murga`s version of Puppy, or the Puppy PXE LAN boot setup.
2 files, the kernel and image.gz ( like the old-old Puppy ), the image file
loads to ram and has the root file system and the main Squash file in it.
No save file, it uses a save dir., but uses a save file for non-Linux partitions.
And that`s about it.!!! A very simple setup indeed.

I haven`t made a complete working O.S. of it as I realized the apps. were
the most critical part. So I`ve been working on AppPkg to get it ready.
Then I`ll turn my attention to the O.S. to complete the picture.

[greengeek]

If your OS ends up having a shorter boot time than puppy I think it will be an interesting alternative to trial. Those older puppies are quite intriguing in terms of their ability to do a task or two very quickly and I'd love to see one tailored to run ok on a wide range of hardware (including new gear). I'd probably be looking at having a mix of OS installed - some to handle the normal varied desktop type of environment (like Slacko and Lucid etc), and some cut down OSes to facilitate specific functions that I want to do quickly, without bloat.

What I'm finding interesting with pupngo2012 is that despite it's lack of bulk it runs on even my newest gear (admittedly my netbooks are 3 years old now, so hardly "new"). Maybe that is to do with the zdrive setup. Anyway, the idea of a small, fast puppy core with a statically-linked word processor grafted into it is my first goal. So much to learn and so little time...

[sunburnt]

Having to reboot all the time is a pain. One O.S. should be as good as another.
Why a W.P. O.S. ?

Eventually I intend the device modules to be compiled into the kernel.
So each kernel would be for a specific PC ( motherboard ).
This would speed up the boot, no modules to load. Also no union to setup.

Puppy has lots of boot methods, this makes for varying boot times.
Booting from CD - DVD is slow, the devices were never ment for an O.S.
Boot methods would be; HD, USB, PXE.

[greengeek]

Why a W.P. O.S. ?.

It's just my observation that the more effort goes into grafting multiple programs into a cutdown OS like puppy, the higher the chance of conflicts, and of unnecessary system load. Some of my machines are old and lacking in ram and they run faster with slim OSes. There are many nights where all I am doing is typing up documents and a WP is all I need. The faster the system runs the more productive I am. Plus it is a learning experience for me to build a puppy one step at a time. If I can't successfully remaster a puppy with nothing more than a single WP theres no point me trying a more complex one

[sunburnt]

I see and understand that. I guess my thought is: Load the SFS you want.
Remastering for apps. is kinda silly considering Puppy`s flexibility.

So... Your stripped Puppy and various SFS files that load-on-the-fly.
There`s How-To pages that talk about removing apps. from the main SFS.
What`s needed is an SFS load-on-the-fly GUI ( maybe one`s been made ).

Puppy`s Boot Manager doesn`t offer Profiles ( I always thought it should ).
But it doesn`t matter, just boot with no SFS files, and load / unload them.

I argued for this type of setup years ago. Many have liked the idea.
Then I realized the union was not needed and it has un-fixable problems.
So my simplified O.S. gradually took shape. AppPkg is a critical part of it.

[tallboy]

greengeek, for some info on almost similar ideas, and in case this distro is unfamiliar to you, you may get some inspiration by taking a look at how GoboLinux is made:

An alternative distribution which redefines the file system hierarchy by installing everything belonging to one application in one folder under /Programs, and using symlinks from /System and its subfolders to point to the proper files

.
(my personal view: links suck!)

tallboy