The state of UNIX in general and PLD in particular

[Jakub Piotr Cłapa]

Daniel Mróz wrote:
> On Sunday 04 of March 2007 02:46:52 Jakub Piotr Cłapa wrote:
>> Two sections, namely 3. Shared libraries and 4. UNIX heritage, are
>> especially interesting in the context of Linux distributions. The author
>>   concludes that the OS X approach to the outlined problems works best
>> allowing for new, useful concepts as well as compatibility with legacy
>> UNIX applications.
> Many legacy applications are bundled with libraries anyway. Those, which are 
> not, are linked statically, linked against recent versions of libraries or 
> you can use -compat packages, or compile much older stuff and run with 
> $LDPRELOAD set.

And this idea would make them first class citizens, without all the 
hacks. The second point is simplifying the administration and removal of 
unused exotic libraries with the last program that uses it (because they 
would be removed with the application bundle).

>> Now back to PLD, I quite like the idea of a distro which:
> [...]
>> The point of the paper was that the dependencies between libraries are
>> not distributed evenly on the dependency graph. It's rather a group of
>> loosely coupled clusters (base libs / GNOME libs / KDE libs / Python
>> libs) with leaves that are (despite being packages in .so shared
>> objects) either not shared or shared by less than 5 programs (think
>> OO.org libs). These could be deployed as big packages holding the
>> clusters and program bundles containing the leaves. We would loose
>> little disk space (and this could be optimized as well by hardlinking
>> the libraries already on the system (see also [6]) upon installation or
>> even poldek retrieval).
> Hardlinks? What with deinstallation? Removing one directory will remove 
> libraries that can by shared among few other applictations.
> What's with upgrades? If application X uses libraries linked (hard or soft) 
> with application Y libraries and we wan't to upgrade application Y to a 
> different SONAME?

AFAIK hardlinks solve the problems you are talking about. With softlinks 
would work as you described and that's why they are not useful here.

> What's if you'll have 10 applications that are using the same libraries, but 
> each of them in different SONAME? What if all of those applications are 
> running (10 versions of the same library lodaded into memory). It's 
> acceptable with legacy products (how many of them you have in your system?), 
> but makes no sense in a distribution.

You are repeating what was suggested in the paper as untrue. Have you 
read it?
If you have 10 apps using 1 or 2 common libraries with many copies in 
the memory you won't notice. Rememeber that libs shared by more that 
10~20 programs go into system library bundles (that's their purpose).

>> [3] A simple example of a bundle may be something like the current
>> tar.gz binary program packages which run without install or the
>> directories inside /opt (but switching from the classical /bin /lib etc
>> names inside the bundles may be a good idea). Shared libraries may also
>> be bundles with all the needed files (think libpython, which needs lots
>> of other files) included inside.
> And soon it will end up with package bundles dependent on library bundles in 
> certain versions. Just like today, but with much more noise in a filesystem 
> and a total lack of control over installed bundles.

No you it will not. The idea (not fully realized on OS X) is to have 
external dependencies only in form of big package groups (KDE/GNOME as a 
whole) which are shared among most of the apps. If you need some other 
library, you put it inside the application bundle. If you need different 
versions you can even put all that are not in the distro in the bundle.

>> [4] I did something similar on my system for simple software
>> installation. (to somehow relieve the pain of lacking PLD packages and
>> poldek on OS X; darwinports/fink are certainly not as comprehensive and
>> up-to-date as our repo)
>>
>> Look for yourself:
>> [jpc w ibook-jpc ~/.local] ls
>> cairo/   geda/    haxe/    hg/      ia636/   macfuse/ openmcl/ pygtk/
>> [jpc w ibook-jpc ~/.local] ls pygtk
>> bin/     include/ lib/     share/
> That's a mess. A bunch of directories with their own bin/lib/share tree...

Yes and no. The bin/lib/share is a mess but OTOH I can remove one 
directory and that's all. Deinstalled. Packages don't mess with the 
system, which is good.

>> Similar thing for PATH and PKGCONFIG make it work quite well considering
> ...and PATH with few thousend paths to executables.
> This can be a good direction of development for MAC OSX, not for PLD with 
> 15000+ packages. Or maybe you wan't to strip repository to... let's say 200 
> packages (boundles)?

Troll? Have you checked what's the performance of having 15000 dirs in PATH?

Maybe having a FUSE filesystem which shows a combined view would solve 
the problem?

>> [5] more complicated but still interesting code sharing concept:
>> http://www.usenix.org/events/usenix05/tech/general/collberg.html
> That concept would be a hell in multiuser enviroment, like terminal servers or 
> shell servers. It's a good concept for legacy applications only.

Could you elaborate?

-- 
regards,
Jakub Piotr Cłapa