The state of UNIX in general and PLD in particular

[Jakub Piotr Cłapa]

<note>
WARNING: Highly flammable content! If you consider replying, read the 
whole e-mail, paying attention to detail. I don't want to start a flame 
war, just a discussion in which I would love my thesis to be proved 
either right or wrong.
</note>

I would like to hear some comments on a paper I came about lately 
discussing some problems with old-UNIX heritage in modern systems.

The paper [1] can be found on arXiv. It's short and you can probably 
omit the part which discusses the micro/monolithic kernel performance 
prejudices.

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.

There is also a project called GoboLinux [2] which seems to move in a 
similar direction as proposed by the paper.

Now back to PLD, I quite like the idea of a distro which:

1. supports only some core libraries and programs and adds several 
optional packages (or package sets --- it doesn't really matter) for 
desktop environments and other big library stuff like Java, Mono, etc,

2. makes use of bundles [3] by means of plain folders (like in OS X), 
tar/zip archives (AFAIK like in Mozilla and Java jar files) or 
filesystem abstraction (think FiST or FUSE, no known implementations),

3. allows program installation by the means of drag and dropping bundles 
containing the program, it's required libraries which are not supplied 
with the base system (no DLL/dependency hell!) and other required files 
(which currently go into /usr/share/*). It works like magic on OS X for 
GUI programs. Unfortunately CLI is not so simple (NeXT/Apple left it 
without solution in NeXTSTEP/OS X) but I think it's doable. [4]

I understand that this is quite contrary to what current PLD philosophy 
is but OTOH I'm not proposing to blindly follow Fedora or Ubuntu so 
maybe this ideas are at least worth some fair discussion.

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

We know why Apple failed to include legacy software in their new UNIX 
vision but we also know that this is solvable (GoboLinux is one try at 
this, isn't Rox also similar?).
What we have (and Apple does not) is the ability to patch large amounts 
of software installation routines to make them work in any new system 
layout we can imagine. Hey, we do it on day to day basis to fix many 
packages with differing views (or simply a lack of education) on the 
whole LHS business.


References:

[1] http://arxiv.org/abs/cs.OS/0701021
[2] http://www.gobolinux.org/

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

[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/
[jpc w ibook-jpc ~/.local] grep pythonpath ~/.zshenv
export -TU PYTHONPATH pythonpath
pythonpath=(~/.local/*/lib/python2.4/site-packages/ 
~/.local/*/lib/python/ $pythonpath)

Similar thing for PATH and PKGCONFIG make it work quite well considering 
home little works it needs (mostly a --prefix to configure and sometimes 
some CFLAGS/LDFLAGS play).

[5] more complicated but still interesting code sharing concept: 
http://www.usenix.org/events/usenix05/tech/general/collberg.html

-- 
regards,
Jakub Piotr Cłapa