[Tfug] The Joy of OSX, and the friction coefficient of goose droppings.

[John Gruenenfelder]

On Wed, Oct 29, 2008 at 06:22:56PM -0700, Bowie J. Poag wrote:
>   The rate at which libraries change in Linux circles justifies building
>   static binaries, imho. The annoyance of playing "hunt the library" with
>   every new thing you download gets very old, very fast.
>   The rate at which *new* libraries appear which have functional overlap
>   with existing libs is also obscene. Rather than building off existing
>   libs, kids these days (dammit! get off my lawn!) wan't their libs to do
>   everything for them, rather than having to think for themselves.. It's
>   lame.  I'd say that a good 75% of open source stuff I get through
>   apt-get or yum comes with unmet dependencies, new libraries that need
>   to be downloaded to do things my system already knows how to do.  Sure,
>   from the coder's perspective, you have plenty to choose from. But to
>   the end user, the whole point, target, and audience of the programmer's
>   efforts, it's maddening to continually have multiple versions of
>   multiple libraries to constantly chase after.
>   Do it once, do it right > Do it 15 different ways, and write "a little
>   bit of this, a little bit of that" chinese buffet style code.
>   Yes, apt-get and yum have gone a long way toward at least easing the
>   misery.. But they only do so at the expense of added bloat. Here's a
>   good example, on a base install of Fedora 9:

I see where you're coming from, but I don't entirely agree.  There's a number
of issues here, all jumbled together, some of which are good and some which
aren't.

You're right that there was probably no reason at all to re-invent the wheel
here.  Address books have been around a long time and somebody has no doubt
written the backend code before.  But, given that they *have* done this...

The approach seems more or less sane.  If you *are* going to build an
everyting + kitchen sink adress book, you should split the library into
pieces.  That way only the needed pieces actually get loaded.  You can code
for this specifically by using runtime loadable modules or you can rely on
good support from the OS in the form of lazy linking where the linker won't
load a library (even if the ELF header says it is a dependency) until code
actually tries to use an unknown function.

There's tradeoffs, of course.  Your app could pause briefly while a library is
loaded at use-time and, if not programmed properly could crash when the linker
can't find what it needs (as opposed to failing to start because of an unmet
dependency).  But, it's generally a good idea.  Less memory use most of the
time and since most libs are small(ish) you probably won't even notice the
load pause.

This particular program might not be the best example, though, as those sizes
are rather on the large side... no surprise from KDE, right?  :)  Maybe
they're not stripped, but even if they aren't they still seem too large.

Even if you don't write the libraries yourself, there can still be many
dependencies for users to sort out if they do things manually.  For a program
I'm writing now, I'm using CFITSIO to handle FITS images instead of my
previous custom library.  I'm also using several Boost libraries, ANTLR for
the parser/lexer (needs Java), and Scons for the build system (needs Python).
Makes *my* life easier at the expense of time spent by users to build the
thing.

Contrast with the previous version.  All it needed was a C compiler, lex,
yacc, and optionally libfftw.  Much easier for users and almost no
dependencies, but it takes more of my time and results in more custom
libraries created by my program.


-- 
--John Gruenenfelder    Systems Manager, MKS Imaging Technology, LLC.
Try Weasel Reader for PalmOS  --  http://weaselreader.org
"This is the most fun I've had without being drenched in the blood
of my enemies!"
        --Sam of Sam & Max