From: David Ford <david@blue-labs.org>
To: Per Jessen <per@computer.org>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: Are we going too fast?
Date: Tue, 14 Aug 2001 15:54:33 -0400 [thread overview]
Message-ID: <3B7981F9.3000708@blue-labs.org> (raw)
In-Reply-To: <3B776EA5000338FD@mta3n.bluewin.ch> (added by postmaster@bluewin.ch)
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
next prev parent reply other threads:[~2001-08-14 19:54 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-08-13 18:46 Are we going too fast? Per Jessen
2001-08-14 13:58 ` Andrew Scott
2001-08-14 19:54 ` David Ford [this message]
-- strict thread matches above, loose matches on Subject: below --
2001-08-16 21:42 PinkFreud
2001-08-15 20:13 Roy Murphy
2001-08-14 20:20 Per Jessen
2001-08-14 20:07 Per Jessen
2001-08-14 19:47 Per Jessen
2001-08-14 16:32 PinkFreud
2001-08-14 16:25 PinkFreud
2001-08-13 21:44 PinkFreud
2001-08-14 0:04 ` PinkFreud
2001-08-14 7:24 ` Francois Romieu
2001-08-15 23:24 ` Dr. Kelsey Hudson
2001-08-13 21:36 PinkFreud
2001-08-14 7:57 ` Helge Hafting
2001-08-13 21:07 PinkFreud
2001-08-13 21:20 ` Alan Cox
2001-08-13 21:41 ` Rog�rio Brito
2001-08-14 0:56 ` Ben Ford
2001-08-14 7:34 ` Peter Wächtler
2001-08-14 2:24 ` David Ford
2001-08-14 4:19 ` Nicholas Knight
2001-08-14 12:49 ` Alan Cox
2001-08-14 22:27 ` Paul G. Allen
[not found] <no.id>
2001-08-13 20:24 ` Alan Cox
2001-08-13 21:06 ` Anthony Barbachan
2001-08-14 20:47 ` Alan Cox
2001-08-15 0:07 ` PinkFreud
[not found] <fa.l9dq0tv.7gqnhh@ifi.uio.no>
[not found] ` <fa.g70as7v.1722ipv@ifi.uio.no>
2001-08-13 19:14 ` John Weber
2001-08-13 18:53 Petr Vandrovec
2001-08-13 17:53 PinkFreud
2001-08-13 20:27 ` Gérard Roudier
2001-08-13 7:43 PinkFreud
2001-08-13 8:52 ` Brian
2001-08-13 8:55 ` Francois Romieu
2001-08-13 10:09 ` Chris Wilson
2001-08-13 11:09 ` szonyi calin
2001-08-14 4:21 ` Pete Toscano
2001-08-14 12:48 ` Alan Cox
2001-08-14 22:30 ` Paul G. Allen
2001-08-13 10:03 ` Gérard Roudier
2001-08-13 10:29 ` Justin Guyett
2001-08-13 12:56 ` Andrzej Krzysztofowicz
2001-08-13 16:54 ` Gérard Roudier
2001-08-13 13:11 ` Alan Cox
2001-08-14 18:51 ` Anders Larsen
2001-08-14 20:29 ` Anders Larsen
2001-08-13 13:46 ` hugang
2001-08-13 13:55 ` Anton Altaparmakov
2001-08-13 17:16 ` Stephen Satchell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3B7981F9.3000708@blue-labs.org \
--to=david@blue-labs.org \
--cc=linux-kernel@vger.kernel.org \
--cc=per@computer.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox