[Yum] Yum Compatibility

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 11 Mar 2003, Erik Williamson wrote:

> 
> > Who are these people who need to preserve 6.2?
> 
> It's the "But this works for me" posse (a.k.a the
> "My-backspace-key-behaves-differently-now-and-I'll-never-figure-it-out
> -you-made-my-life-a-living-hell" posse.)
> 
> I'm with you on this one.  Hey!  I could use the 'end-of-life' bit that
> RedHat is starting up.  6.2 is/was to expire this month.

In addition you could point out that heterogeneity and maintaining
multiple revisions for years past their bedtime is very expensive, far
more expensive than their resolving backspace key problems (obviously
the humans you deal with have never heard of keymaps or stty, so you
might have to beat them on the head with a manual -- distributions don't
have anything intrinsic to do with key mappings).  Of course, the same
people who won't let you upgrade the base revision want the latest
version of tool XXX to work, because they see it in operation on their
neighbor's 7.3 or 8.0 system.  Silly little problems like incompatible
libc's mean nothing to them.

To make the cost differential explicit, refer them to Aduva (reviewed a
couple of days ago) and let them find out precisely how expensive it
will be for them to continue to run 6.2 on their own.  A bit of
discussion involving "opportunity cost" (the many, many ways you and
they could better spend the time and money that would otherwise be
wasted supporting multiple incompatible revisions) is also in order.

To do more for less money, keep things HOMOGENEOUS, SCALABLE, and
CURRENT.  Homogeneous because that way work can be focussed on doing one
thing well instead of four things very badly.  Scalable so that the work
done well ONE time is useful throughout your organization.  Current so
that your organization isn't vulnerable to productivity-sapping security
exploits, so that workflow isn't interrupted by bugs and crashes, so
that the workforce can take advantage of the newest tools and latest
features designed to >improve< productivity.

To support productivity further, invest a small amount in perpetuity in
training and supporting workers through revision upgrades.  An
organization without upgrade/update mobility soon becomes stagnant, its
workflow becomes static in a dynamic universe, its competitive advantage
declines relative to organizations that are more flexible and up to
date.  What systems administrator isn't familiar with the secretary who
has been using the same (often expensive and immensely powerful) mail or
word processing tool for years and is still using just five or six of
the most basic features of the menu?  

Left alone these individuals totally distort the cost-benefit
decisioning for an entire organization, costing it immense amounts of
money in buying software whose expensive features aren't even being
used, in work being done "the hard way" by hand that should be done
using the unused software features, in complete revisions of the work
flow that might eliminate whole tasks being done by hand that could be
fully automated.

I swear, I should charge for this stuff.  I mean hell, there are jokers
who go around and charge institutions $20K for a one day session in
which they tell top level management "Gentlemen, this is your ass.
These are your hands.  Please place your hands on your ass.  No, sir,
that is not >>your<< ass.  No, madam, that is not your >>ass<<.  That's
it.  Wonderful.  Congratulations, today you have learned to find your
ass with both hands!  Tomorrow, for a mere additional $20,000, I would
be happy to help you learn to chew gum while in actual motion..."

Maybe if you go to your toplevel bosses and offer to bring me in as an
outside expert on scalable, cost effective computer networking and
management?  I'm available at a cost of a mere $20,000 for a one day
session, a real bargain (for me, anyway:-)!  

I'll even see if I can come up with some of those humorous "exercises"
where one blindfolds some hapless employee and throw them out of a
second story window so that they can learn to trust their fellow
employees to catch them without at the same time going through their
wallets or copping a quick feel.  Jolly good fun.

    rgb

-- 
Robert G. Brown	                       http://www.phy.duke.edu/~rgb/
Duke University Dept. of Physics, Box 90305
Durham, N.C. 27708-0305
Phone: 1-919-660-2567  Fax: 919-660-2525     email:rgb@xxxxxxxxxxxx





[Index of Archives]     [Fedora Users]     [Fedora Legacy List]     [Fedora Maintainers]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]

  Powered by Linux