[linux-elitists] What to do about cluebatting such companies, that require possibly *YEARS* old Distros
Thu Jan 27 11:30:37 PST 2005
On Wed, 2005-01-26 at 18:41, Rick Moen wrote:
> Quoting Aaron Sherman (firstname.lastname@example.org):
> > 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.
More information about the linux-elitists