The state of UNIX in general and PLD in particular

[Daniel Mróz]

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.

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

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

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

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

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


Regards
Beorn

-- 
Daniel 'Beorn' Mróz <beorn w alpha.pl>    http://127.0.0.1/beorn
[GIT d s:- a-@ C++++ UL++++$ P+ L++++ E--- W+ N+++ o? K- w---]
[O- M- V!  PS+ PE++ Y+ PGP++ t- 5  X R !tv b+ DI D++ G++ e h*]
[                          r++  y+                           ]