[linux-elitists] What to do about cluebatting such companies, that require possibly *YEARS* old Distros

Aaron Sherman ajs@ajs.com
Thu Jan 27 11:30:37 PST 2005


On Wed, 2005-01-26 at 18:41, Rick Moen wrote:
> Quoting Aaron Sherman (ajs@ajs.com):
> 
> > Rick, once again I'll ask the question: show me an example of one
> > company that does better than their competition (not just "is big"),
> > where they do and their competition does not upgrade operating system
> > software more frequently than every 3 years.
> 
> Once more, I'll suggest that you review the risks to exposed,
> unmaintained and EOLed systems, and consequences thereof.  I'm not
> playing "show me a company" games.

The statement has been made, over and over again that there's some
decisive link between the competency/agility of a company that upgrades
OSes frequently vs. one that does not (note that I'm not at all talking
about the CAPACITY to upgrade frequently, but the act). Without examples
and counter-examples, I am left to assume that's simply speculation.

> If you don't get that, then I can't help you.

Believe me, I wasn't looking for help on this topic. Not in the
slightest. I was asking you (and others) why there seems to be such a
strong feeling that upgrades have to happen so frequently. Is it just
that I'm older and 3 years no longer seems like an eternity?

So, security is the concern. Ok fine. In the case of outward facing
systems that is valid, though certainly a company that had the
resources, and decided that it was more cost-effective to maintain
security for the packages on the older (again, we're talking 3 years,
here) OSes could do so. It's not like we haven't been running around for
years saying that OSS frees you from the shackles of vendor-forced
upgrades because, worst-case, you can author the security fixes
yourself. Didn't everyone get torqued off when Microsoft EOLed Win98/ME
specifically because of that closed-source lock-in?

Now, as for internal systems... as others have pointed out, the
cost-benefit analysis probably favors sticking with a longer upgrade
cycle of about 3-5 years. That's about the period of time that I find
software starts to become difficult to manage, along-side of its newer
cousins (e.g. the "why don't those boxes support monitoring feature X
when everything else does" syndrome).

I measure system uptimes in longer units than it seems like many people
here want upgrade cycles to be. I guess these are just different worlds
with different demands on them.

-- 
☎ 781-324-3772
✉ ajs@ajs.comhttp://www.ajs.com/~ajs




More information about the linux-elitists mailing list