[nycbug-talk] ports systems. . .

[Bob Ippolito]

On Sep 6, 2004, at 11:28 AM, Louis Bertrand wrote:

> On Sat, 4 Sep 2004, G.Rosamond wrote:
>
>> <not an attempt at starting a flame war>
>>
>> Ike and I had a long discussion this evening about ports systems. . .
>>
> Maybe a bit off topic, but I'm getting annoyed at the ports concept 
> because
> of the shared library aspect. If a ports tree gets a bit crufty, you 
> start
> getting problems with shared libraries falling out of sync or, if you 
> want
> to update the shared lib to build a new port you end up having to 
> update all
> the ports that depend on it (woe to you if any are broken at the time).
>
> With faster and faster systems with lots of memory, isn't it time more 
> ports
> got built staticly? Yes, it generates huge binaries, but for big 
> applications
> (e.g. Gimp, Mozilla) the load time is small compared to the time the 
> application
> is in use.

Contrary to popular belief, the reason shared libraries exist are 
because the static components of them (constants and code, basically) 
can be shared amongst processes.  So let's say that a bunch of common 
shared libraries (GTK, X11, whatever) add up to 30mb, and that n 
processes use them (Gimp, Mozilla, GNOME, etc.).  This scenario saves 
30mb * (n -1) megs of RAM, but the tradeoff is of course "dll hell".

There's several ways around this, but the most common is to just keep 
multiple versions of libraries around or to bundle libraries with the 
applications that use them.  There is a way to conserve RAM in the 
latter case that I have read about but never seen implemented - what 
was proposed is that shared libraries should be versioned by hash only, 
so you could bundle all of your applications with all or nearly all of 
their dependencies, and still reap the benefits of shared libraries 
when it is possible.

-bob