Multiple software copies (was Re: Die GNU autotools)

[Oron Peled]

Somehow, too many people miss the really big point about
code duplication... So I'll try to put some perspective into this...

On Thursday, 13 בJanuary 2011 13:30:34 Elazar Leibovich wrote:
> On Thu, Jan 13, 2011 at 1:05 AM, Tzafrir Cohen <tzafrir at cohens.org.il>wrote:
> > But it's a system (or user-installed) library. Why would I need to bundle
> > it with my code?
> 
> You just hit the nail on its head!
> Few years ago, you were correct, harddisks were thin, memory was spare, and
> if you could use a preinstalled library it'll be a great benefit.

Disk and memory footprint are important, *BUT* having multiple copies
of the same software suck bigtime for a different reason.

Let's take dynamic libraries as a showcase.
First few facts to set the stage:
 * They exist from the 80's (e.g: Unix systems)
 * They are the dominant form for the last 20 years (the percentage of
    statically linked binaries is very low)
 * BUT -- they cause performance hit (on most architectures) comparing
    to statically linked binaries.

Q: So what's the major reason for their use (bearing in mind that they
     cost us performance)?
A: It's because *dynamic* linking offers crucial key to software
    maintenance -- no need to rebuild every application using the
    library when the library need updates (Tzafrir mentioned this
    on another post)

Let me illustrate with two real life examples from Fedoraproject:

 * Fedora-14 upgraded libjpeg with a new optimized implementation
    that gave a significant performance boost:
    (http://fedoraproject.org/wiki/Features/libjpeg-turbo).

    Q: How many packages I *did not* have to update on my laptop ?
    A:    $ rpmquery --whatrequires libjpeg.so.62 | wc -l
           73                # Yes, I only use "few" graphic apps/utilities

    Q: How many packages *did not* had to be built by the maintainers ?
    A:    $ repoquery --alldeps --whatrequires libjpeg-turbo | wc -l 
           474

    Yes, four hundred seventy four packages.

 * This December a security fix was issued to libsndfile for EPEL
    (https://admin.fedoraproject.org/updates/libsndfile-1.0.17-4.el5)
    to fix several buffer overflows.

    Q: How many packages a RHEL customer or Centos user *did not*
        have to worry about after installing the fix ?
        [OK, I'll cheat and check on my F-14 laptop, since I don't have
         a RHEL / Centos box in front of me]
     A:   $ repoquery --alldeps --whatrequires libsndfile | wc -l 
           108

The two immediate conclusions from these tiny examples:
 * Dynamic library biggest win is software *maintenance* -- static
    libraries maintenance *does not scale*.

 * Using multiple, private copies of dynamic libraries for each application
    is winning the worst of *both* worlds:
    - You get the lousy performace of dynamic libraries (comparing to
      statically linked binaries)
    - And you get unmanageble software mess as well.

Bonus question to clarify the point:
 1. Assume Microsoft issues via their automatic updates a security fix
     to one of their DLL's

 2. What is the chance that the update would fix *all* multiple copies
     of same DLL which is installed/bundled/packaged in 3'rd party
     applications, sometimes in multiple versions (of the application,
     the DLL or both).

     [yes, some of the copies may be installed/upgraded *after* the
      MS-update took place -- we talk about real life, not MS dream
      world]

  3. Now, assuming both Microsoft and the user never miss an update.
      What is the chance of the user to have a secure system ?

Bonus bonus question:
   Answer the previous question, assuming the DLL does not come
  directly from Microsoft but from a 3'rd party (e.g: some popular
  Active-X control or other stupidity)

BTW: This is why Fedora pretty much frowns upon static libraries
         (even special cases requires separate packaging)
[http://fedoraproject.org/wiki/Packaging/Guidelines#Packaging_Static_Libraries]

Cheers,

-- 
Oron Peled                                 Voice: +972-4-8228492
oron at actcom.co.il                  http://users.actcom.co.il/~oron
#define NULL 0           /* silly thing is, we don't even use this */
        --Larry Wall in perl.c from the perl source code
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cs.huji.ac.il/pipermail/linux-il/attachments/20110117/77edd9f7/attachment.html>