On 4/18/06, Brantley Coile <[EMAIL PROTECTED]> wrote: > System designers have a responsibility to help the rest of the > system's community by providing a useable system. I'll make the > following observations regarding shared libraries as if you and I were > debating putting shared libraries into a system. I have worked both > sides of this issue, so I have an experienced opinion, not just apriori > idea of good system hygiene. > > First, let me deal with your two `advantages.' > > > #1 Maintenance - If you have 50 programs that depend on one library > > and you have a fix for the library how many things do you want to > > "remember to build"? (though people are throwing up straw man > > arguments for this too. I suspect the worst case scenario is not > > always the common case though.) > > This has an ugly other side. If I have 50 programs that depend on one > library and fix a bug in the library, I now have 50 live programs in > production that haven't been tested. I don't know if my change has > broken something else and won't know until I re-test all 50 programs. > I now have to do all that testing at once. With static libraries I > have the luxury of going thru the 50 programs one at a time and > relinking them with the new library or reverting to an old library if > there's a problem.
This is definitely a point of view I've not heard before, regarding suddenly changed but now untested binaries. However let me say that I have experienced this problem before. Mac OS X Tiger betas shipped with new software that broke old software that relied on glib, which relied on some old software behavior. Lots of stuff just stopped working as a result. There goes my maintenance claim :)... and it's not just theory, it happend. > > > > #2 Supposed physical memory savings - libSystem on Mac OS X only > > exists in memory 1 time for all the programs that use it... sorta. > > Read Only pages are shared, writable pages are COW and yes, this adds > > a good deal of complexity to the VM of the OS to have this. > > Before X windows, 10% of programs were from the library. With X > windows that number ballooned to 90%, so there is an apparent (see > below) space savings with X windows. This is because when to touch > anything you get everything. That, I would argue, is bad design. (I > added shared library to a custom embedded Unix I did 15 years ago > because the application was also mis-designed.) The X library is > really a sub-system that should be somewhere other than the user's > program. > > > Also on the down side, shared libraries make it hard to distrubute > binaries without also sending out the library. The binary, or even > the files in the same directory, are no longer all that is required to > run the program. You also have to have the correct version of the > library. Since you get different binaries that need different > versions of the library, you now wind up with three or six or more > slight variations of the same library, all get loaded into core. Now, > where's my space saving? Remove one and now you have a bunch of > programs that don't work, but you don't know it yet. > > To load a binary that is linked to a library takes longer to load. > > > I have seen code sharing done right, such as Oberon, but every version > of shared libraries in Unix I've seen cost more than they were worth. > Including my own. > > Hope the above arguments at least seem rational. They are off the top > of my head. I'm sure others on 9fans have other, better data points > that do the engineering calculation on the cost/benefits of shared > libraries. > > Sure these are good arguments. For the record, I know people outside the Plan 9 camp who stick to the "shared libraries are bad argument" and I've always liked to think of myself as pretty open minded to unpopular ideas. I know from experience that popular doesn't mean it's correct. Dave > bc > >
