Re: Are we going too fast?

David Ford (david@blue-labs.org)
Tue, 14 Aug 2001 15:54:33 -0400


Per Jessen wrote:

>>On Mon, 13 Aug 2001 14:11:32 +0100 (BST), Alan Cox wrote:
>>
>>If you want maximum stability you want to be running 2.2 or even 2.0. Newer
>>less tested code is always less table. 2.4 wont be as stable as 2.2 for a
>>year yet.
>>
>
>Couldn't have put that any better. On mission-critical systems, this is
>exactly what people do. Personally, my experience is from the big-iron
>world of S390 - if you're a bleeding-edge organisation, you'll be out
>there applying the latest PTFs, you'll be running the latest OS/390 etc.
>If you're conservative, you're at least 2, maybe 3 releases (in todays
>OS390 this means about 18-24 months) behind. If you're ultra-conservative,
>you'll wait for the point where you can no longer avoid an upgrade.
>

Unfortunately, this methodology also introduces another important
factor. You are the most likely target for exploits and
vulnerabilities. As is ever so strongly evidenced by the great numbers
of people being exploited because the version of software they have is
outdated.

It's a gross measure of risks; where does the risk come from, how can it
affect you, and what can you do about it.

Some of the most common questions asked on support areas is (take IIS
for example) "My server is being exploited, how can I stop it?" and the
most common answer to that is "Upgrade and install all necessary patches."

Save for the rare occasion of issue, I run a few different server farms
and they all perform very well and are all rock solid stable. I should
also note that they are all 2.4 kernels. For servers I seem to have
really good success stories, for my workstation I tend to have issues
which is fairly natural, my workstation has numerous accessory cards and
features.

To be honest, save for either power outtage or kernel upgrade, I rarely
have to deal with reboots. I tend to keep my servers within a few
releases of the current code. Due to this policy I rarely have exploit
and vulnerability issues. One particular server (which has a VIA
chipset...is it jinxed? :) has problems now and then but they get fixed.

David

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/