<br><br><div class="gmail_quote">On Mon, May 17, 2010 at 11:42 AM, Jeff Hubbs <span dir="ltr"><<a href="mailto:jhubbslist@att.net">jhubbslist@att.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
This way of operating is infecting IT like a disease.<br></blockquote><div><br>I _almost_ agree except I understand the why and how of this happening. <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
Whether it's on account of client demands, vendor "certification" of one<br>
of their products, PHB-ism, or what have you, the assembly of<br>
tightly-locked dependency stacks was one of the reasons why I *thought*<br>
we fled the closed-source proprietary software world. I don't consider<br>
myself "Stallman-complete" but whenever this sort of situation appears,<br>
no good ever seems to come of it. Even this property of RHEL and<br>
RHEL-alikes where the packages are version-ceilinged often seems to take<br>
what should be basic stewardship and turns it into administration<br>
crises, i.e., CUPS has a bug, can't upgrade it, must upgrade distro<br>
version first, but X app doesn't run under the new version, etc., etc.,<br>
etc.<br>
<br>
But the RHEL situation is just one example of a larger issue: trade<br>
away one aspect of your computing freedom and other aspects follow.<br>
Trading away freedom only works if your trading partner is benevolent.<br>
<div><div></div><div class="h5"><br><br></div></div></blockquote><div>Because Linux systems in particular are such a fast moving code base, and because the business crowd is such dufuses about things changing, the existence of release versions must exist. It really is not a bad thing. It is just a classification system that allows instant knowledge of system capabilities and limitations. Just as kernel version have different capabilities, the overall distro version has certain capabilities. It would be very hard to provide package support for a complicated web app if the database portion changed every few weeks.<br>
<br>The issue is not the distro (RHEL in this case) but the needs of the management structure. Because they understand that version 1.2.3 is earlier than 1.2.4 AND that 1.2.3-7 has the patches applied that made 1.2.4 exist but it's compiled for the same glibc and other libs as the original 1.2.3, they have to stick with distro version. OK. That's not so bad, really. Except they _insist_ on sticking with the same version for 5+ years. Not for sane reasons but for reasons of not wanting to spend the devel time to upgrade their workflow or custom code. <br>
<br>It would mean _they_ have to work and that might impede their martini sucking time time :-)<br><br><br>The version-ceiling is a sneaky way to work around the bozo-manager factor. RHEL keeps the same leading prefixs and adds patch revisions to keep the security issues current and adds that data after the "-". They keep "new features" out of the lib chain until the next distro version release (it's a total PIA to upgrade core libs piecemeal so all at once new distro actually works better in most cases).<br>
<br>The dependancy stacks are not the same as those in the non-open world. In the bad lands, the dependancies are chosen to force the user to replace licenced software with a new license purchase. In happyland, those stacks are only for tewchnical reasons. <br>
<br>For those that want a faster turnaround on technology, they can use faster moving environments like Fedora and the Ubuntu non-LTS releases. Otherwise, it's fork out the bucks to keep backporting security fixes to aging codebases just to keep the PHB happy.<br>
</div></div><br>-- <br>-- <br>James P. Kinney III<br>Actively in pursuit of Life, Liberty and Happiness <br>Doing pretty well on all 3 pursuits <br><br>