API specification and library hell still not solved.

Two annoyances, and these are actually not specific for Linux. The first is
IMHO a Unix or POSIX problem, the second is even more universal.

_The first:_

The API (headers) of Linux (kernel and *nix userland) is in C, and C is
kind of problematic to convert to an arbitrary format (e.g. a different
language).. 

Besides being in C (which is hard enough already), they are all different,
and use different macros, constructs, defines etc, which pretty much means a
custom parser for each set of headers (package), and even that isn't fully
automatic. (and handconversions are costly from a time perspective, and
therefore will nearly permanently be out of date)

A nice illustration of this problem is the mere existance of "Configure" the
way it exists now. It doesn't process the headers directly to query them,
a very complex compiling/testing/analysis process is done to get some info
about headers. 

The Microsoft angle (since this group will probably do a lot of comparing
with Windows): slightly better. Microsoft provides about a third in IDL, and
the remaining 2/3's are coherent, and as a while much more suitable for
automatic conversion.
Though this is only a gradual difference (still need custom parser, and
still manual postprocessing), it is a factor 10-20 better (in lines/hour
header translations).

Solution: Define the headers at a abstract, higher level, provide generators (and
their skeletons) to generate the plain C headers from that abstract level.

Additional advantages: 

- Useful for C too, not only for other languages.
  Easier to generate headers with directives for non gcc or heavily modified C
  compilers etc. (I've played with gcc for hp48, and that is not fun)
- Easy parsability makes checking for API breakage between versions easier,
  since analysing the interface is easier. 

disadvantages:
- needs mentality change
- quite some work


_the second_ shared lib hell.(=dll hell)

The library system of Linux (*BSD too, I don't know how universal this is)
is different from that of Windows. One can have multiple versions in
paralel, at least _IF_ the binary links to the correct library. (and not to
some symlink),

However, while security wise it might be better to disallow shared libs (not
dynloaded) in app directories, this kills some flexibility compared to
Windows too, since Windows allows libraries to be moved/copied to the
application directory if version conflicts arise.

I'd say the overall situation is about the same.
Both systems (windows and linux) rely too much on properly versioned
libraries. A small error takes down the entire system. (a minor upgrade that
is incompatible etc)

Solution: 
- binaries must _always_ have full version nr of required library.
- I must be able to assign any library version to any binary. 
- there must be a system global db which lists version compabilities. 
     so if binary lists 2.1.76, the db must list that 2.1.40-2.1.80
     are compatible, and automatically assign the newest version of that
	library available in that range to the binary.
    I'm still in dubio if this should be done only for libraries as a whole,
	or on a per symbol basis ( library version X is compatible with
	library version Y as long as you don't use for symbol Z)
- There must be a database to register exceptions (specially for proprietary
	software).  E.g. if Heroes3 links to old versions libc and gtk, I
	must be able to list that heroes3 (as old binary only game) should
	get assigned some old libc/gtk versions only. (if file=heroes3 then
	assignlibc(x<=libc<=y) and assigngtk(z<=libgtk<=a)