[ale] 64bit thunderbird 3.0.4

[Jim Kinney]

On Mon, May 17, 2010 at 11:42 AM, Jeff Hubbs <jhubbslist at att.net> wrote:

> This way of operating is infecting IT like a disease.
>

I _almost_ agree except I understand the why and how of this happening.

>
> Whether it's on account of client demands, vendor "certification" of one
> of their products, PHB-ism, or what have you, the assembly of
> tightly-locked dependency stacks was one of the reasons why I *thought*
> we fled the closed-source proprietary software world.  I don't consider
> myself "Stallman-complete" but whenever this sort of situation appears,
> no good ever seems to come of it.  Even this property of RHEL and
> RHEL-alikes where the packages are version-ceilinged often seems to take
> what should be basic stewardship and turns it into administration
> crises, i.e., CUPS has a bug, can't upgrade it, must upgrade distro
> version first, but X app doesn't run under the new version, etc., etc.,
> etc.
>
> But the RHEL situation is just one example of a larger issue:  trade
> away one aspect of your computing freedom and other aspects follow.
> Trading away freedom only works if your trading partner is benevolent.
>
>
> 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.

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.

It would mean _they_ have to work and that might impede their martini
sucking time time :-)


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).

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.

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.

-- 
-- 
James P. Kinney III
Actively in pursuit of Life, Liberty and Happiness
Doing pretty well on all 3 pursuits
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.ale.org/pipermail/ale/attachments/20100517/51f8dd19/attachment.html