But this is supposedly the point of sbin, but (and I haven't looked for ages) it used to be that various entries in sbin were actually dynamically linked. Whatever you do you can't win, I guess with rescue disks being as good as they are now in an ideal world you'd have everything that could be dynamically linked and just use a rescue disk to dig yourself out of the mire when it all goes a bit pear-shaped. -----Original Message----- From: fedora-list-bounces@xxxxxxxxxx [mailto:fedora-list-bounces@xxxxxxxxxx] On Behalf Of Don Levey Sent: 23 February 2007 01:47 To: For users of Fedora Subject: Re: ESR: Goodbye Fedora- big picture On Thu, 2007-02-22 at 17:06 -0500, Steve Friedman wrote: > On Thu, 22 Feb 2007, Tom Horsley wrote: > > > On Thu, 22 Feb 2007 10:59:16 -0800 > > "John P. Fisher" <john.fisher@xxxxxxxx> wrote: > > > >> 3) I guess if I could wave a wand, I'd have a set of common fundamental > >> libraries that get shared and maintain compatibility between distro > >> releases, and everything else would be handled by the applications > >> themselves. Maybe this is plain dumb, but it sure would be easier for me... > > > > I'd just have every single app have its very own versions of every library > > it needs with a reaper that runs around at low priority hard-linking > > the ones that are identical :-). > > > > > > Then you've forgotten the zlib security issues of only 5 years ago. A > security vulernability was found in a compression library common to over > 500 apps. Those that dynamically linked to zlib were patched with a > single upgrade; however, large numbers of apps had to be recompiled > because they statically linked to zlib. This was a *major* security > crisis -- and *many* apps/utilities switched to dynamic linking of zlib > (and other common libraries) to avoid this happening again. As a non-programmer, I'm ignorant of many of the issues involved, but why can't you say: "if you link against an external library, do it dynamically" as a rule of thumb? That way you could replace the library without needing to recompile. Unless you want to state for sure that no-one else will use your library, and not place it in a shared location, that is. -Don -- fedora-list mailing list fedora-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list The information contained in this email is intended for the personal and confidential use of the addressee only. It may also be privileged information. If you are not the intended recipient then you are hereby notified that you have received this document in error and that any review, distribution or copying of this document is strictly prohibited. If you have received this communication in error, please notify Brendata immediately on: +44 (0)1268 466100, or email 'technical@xxxxxxxxxxxxxx' Brendata (UK) Ltd Nevendon Hall, Nevendon Road, Basildon, Essex. SS13 1BX UK Registered Office as above. Registered in England No. 2764339 See our current vacancies at www.brendata.co.uk
