That seems like a great reason to run a virtual machine and sandbox a more modern linux to run those specific apps.
On Thu, Mar 20, 2014 at 8:58 PM, Keith Lofstrom <[email protected]>wrote: > On Tue, Mar 18, 2014 at 04:43:53PM -0700, Tim wrote: > > Your software distribution does you a grand service by managing this > > for you. Use a distro that does it right, buy into it and use their > > framework, and many of the headaches you describe become minor. > > On Wed, Mar 19, 2014 at 08:31:38AM -0700, Paul Heinlein wrote: > > For example, if there were a vulnerability in libcrypt, roughly 300 > > binaries on one of my CentOS 6 servers would have to be rebuilt, > > repackaged, and reinstalled. > > Wise words, thanks for that. I suppose what I should want is > a "multilibrary" wrapper and package updater for new packages. > > I run a Red Hat Enterprise clone, Scientific Linux 6.5 . It is > stodgy (equivalent to Fedora 12, a 4 year old base kernel) - but > it will get security updates until 2023, supported by Fermilabs > even if Red Hat goes away (or worse, gets bought by Larry > Ellison). The problem is, almost all recent third party not-in- > the-standard-distro packages want later major revs of libraries > with new features; I can't compile or run those because the > dependencies collide. > > So what if I could run different families of programs with > different runtime loaders, which looks at the program's requests > for libraries and other runtime requirements and pulls them from > someplace besides the mainline /usr/lib ? This would require > more disk space, more backup time and storage, and many nightly > update processes, but it would mean that old stuff that is > difficult to migrate wouldn't have to, and I would never see > dependency conflicts when loading a new package. > > So, I might be running SL6.5, Fedora 20, and Ubuntu 14.04 > packages all on the same machine, and migrating binaries from > older to newer distros gradually, as new very long term support > versions become available. New machines could be installed with > the latest SL6.5 (or SL7.1 or 8.1 when those become available) > with similar linker/wrappers backwards to older libraries. > > Yes, this might leave some security holes in some of the obscure > web-facing components, but for those of us with a gigantic > /usr/local/bin and ~/bin , not being able to easily keep old > capabilities represents a larger threat to productivity. > > Keith > > -- > Keith Lofstrom [email protected] > _______________________________________________ > PLUG mailing list > [email protected] > http://lists.pdxlinux.org/mailman/listinfo/plug > -- Darren R. Couch [email protected] _______________________________________________ PLUG mailing list [email protected] http://lists.pdxlinux.org/mailman/listinfo/plug
