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 <[email protected]>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 [email protected] 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
_______________________________________________ Linux-il mailing list [email protected] http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
