Re: Best suiting OS

On Sun, 4 Oct 2009, Mark Mielke wrote:

> On 10/04/2009 01:55 PM, Devrim GÜNDÜZ wrote:
>> On Sun, 2009-10-04 at 10:05 -0400, Mark Mielke wrote:
>>
>>> So any comparisons between operating system *distributions* should be
>>> fair. Comparing a 2007 release to a 2009 release, for example, is not
>>> fair. RHEL / CentOS are basically out of the running right now,
>>> because
>>> they are so old.
>>>
>> Some people call these "stability" .
>>
>
> Note that if a deployment is running well, and has been running well for
> years, there is probably no reasonable justification to change it. My
> comments are for *new* deployments. If somebody were to come to you with a
> *new* deployment request, what would you recommend? Would you really
> recommend RHEL 5 *today*?
>

I use the following systems:
RHEL4
RHEL5
Fedora 11, latest updates and kernels.

Basically, all systems are stable but all of them have "problems":
RHEL4, RHEL5: Old, but proven systems, missing new features and still
bugs that have already been fixed.
Fedora 11: Bleeding edge system, but with new bugs and systems are
getting even slower with newer kernels:-(

Examples are major bugs in latest kernels in the CFQ scheduler:
http://bugzilla.kernel.org/show_bug.cgi?id=13401#c16

Linux kernel slows down:
http://www.theregister.co.uk/2009/09/22/linus_torvalds_linux_bloated_huge/
http://www.phoronix.com/scan.php?page=article&item=fedora_test_2008&num=4

So software will always have either less features or bugs :-) So it is
always a tradeoff between stability and bleeding edge.

Ciao,
Gerhard
>From pgsql-performance-owner(at)postgresql(dot)org Sun Oct 4 19:23:14 2009
Received: from maia.hub.org (unknown [200.46.204.183])
by mail.postgresql.org (Postfix) with ESMTP id 57E676337CC
for <pgsql-performance-postgresql(dot)org(at)mail(dot)postgresql(dot)org>; Sun, 4 Oct 2009 19:23:14 -0300 (ADT)
Received: from mail.postgresql.org ([200.46.204.86])
by maia.hub.org (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024)
with ESMTP id 59913-08
for <pgsql-performance-postgresql(dot)org(at)mail(dot)postgresql(dot)org>;
Sun, 4 Oct 2009 22:23:06 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from bifrost.lang.hm (mail.lang.hm [64.81.33.126])
by mail.postgresql.org (Postfix) with ESMTP id 2A5BE63249B
for <pgsql-performance(at)postgresql(dot)org>; Sun, 4 Oct 2009 19:23:05 -0300 (ADT)
Received: from asgard.lang.hm (asgard.lang.hm [10.0.0.100])
by bifrost.lang.hm (8.13.4/8.13.4/Debian-3) with ESMTP id n94MMtLZ030883;
Sun, 4 Oct 2009 15:22:55 -0700
Date: Sun, 4 Oct 2009 15:22:55 -0700 (PDT)
From: david(at)lang(dot)hm
X-X-Sender: dlang(at)asgard(dot)lang(dot)hm
To: =?ISO-8859-15?Q?Devrim_G=DCND=DCZ?= <devrim(at)gunduz(dot)org>
cc: Mark Mielke <mark(at)mark(dot)mielke(dot)cc>,
Denis Lussier <denis(dot)lussier(at)enterprisedb(dot)com>,
S Arvind <arvindwill(at)gmail(dot)com>, pgsql-performance(at)postgresql(dot)org
Subject: Re: Best suiting OS
In-Reply-To: <1254678959(dot)25301(dot)0(dot)camel(at)hp-laptop2(dot)gunduz(dot)org>
Message-ID: <alpine(dot)DEB(dot)2(dot)00(dot)0910041459350(dot)9391(at)asgard(dot)lang(dot)hm>
References: <abf9211d0910010246r1f59408bp82d19ae1b3a29407(at)mail(dot)gmail(dot)com> <alpine(dot)DEB(dot)2(dot)00(dot)0910011208450(dot)11706(at)asgard(dot)lang(dot)hm> <ba8cf61c0910011244p677c0a89wabcd31108ac26a08(at)mail(dot)gmail(dot)com> <4AC8AB8E(dot)4080309(at)mark(dot)mielke(dot)cc>
<1254678959(dot)25301(dot)0(dot)camel(at)hp-laptop2(dot)gunduz(dot)org>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Spam-Status: No, hits=-2.599 tagged_above=-10 required=5
tests=BAYES_00=-2.599
X-Spam-Level:
X-Archive-Number: 200910/80
X-Sequence-Number: 35794

On Sun, 4 Oct 2009, Devrim G?ND?Z wrote:

> On Sun, 2009-10-04 at 10:05 -0400, Mark Mielke wrote:
>>
>> RHEL and CentOS are particular bad *right now*. See here:
>> http://en.wikipedia.org/wiki/RHEL
>> http://en.wikipedia.org/wiki/CentOS
>>
>> For RHEL, look down to "Release History" and RHEL 5.3 based on
>> Linux-2.6.18, released March, 2007. On the CentOS page you'll see it
>> is
>> dated April, 2007. CentOS is identical to RHEL on purpose, but always
>> 1
>> to 6 months after the RHEL, since they take the RHEL source, re-build
>> it, and then re-test it.
>>
>> Linux is up to Linux-2.6.31.1 right now:
>> http://www.kernel.org/
>>
>> So any comparisons between operating system *distributions* should be
>> fair. Comparing a 2007 release to a 2009 release, for example, is not
>> fair. RHEL / CentOS are basically out of the running right now,
>> because
>> they are so old.
>
> Some people call these "stability" .

"stability" can mean many things to people

in this case it does _not_ mean 'will it crash' type of stability.

if you do not have a corporate standard distro and your sysadmins are
equally comfortable (or uncomfortable and will get training) with all
distros, then the next question to decide is what your support
requirements are.

some companies insist on having a commercial support contract for anything
that they run. If that is the case then you will run RHEL, SuSE
enterprise, Ubuntu (probably long term support version), or _possibly_
debian with a support contract from a consutant shop.

the next layer (and I believe the more common case) is to not require a
commercial support contract, but do require that any software that you run
be supported by the project/distro with security patches.

In this case you need to look at the support timeframe and the release
cycle.

With Fedora, the support timeframe is 12 months with a release every 6
months. Since you cannot (and should not) upgrade all your production
systems the day a new release comes out, this means that to costantly run
a supported version you must upgrade every 6 months.

With Ubuntu, the support timeframe is 18 months with a release every 6
months. This requires that you upgrade every 12 months to stay supported

With the enterprise/long-term-support versions, the support timeframe is 5
years with a new release every 2-3 years. for these you will need to
upgrade every new release, but can wait a year or two after a release has
been made before doing the upgrade

for Debian stable the support timeframe is 1 year after the next release
(which has historicly had an unpredictable schedule, they are trying to
shift to a 2 year cycle, but they haven't actually done it yet). This
allows you to wait several months after a release before having to do an
upgrade.

another question you have to answer in terms of 'support' is what are the
limitations on replacing software that came with the distro with a new
version yourself. With the commercial support options the answer is
usually 'if you upgrade something you void your support contract'. This
can be a significant problem if the distro cycle is long and you need a
new feature. note that for the kernel a 'new feature' may be support for
new hardware, so this can limit what hardware you can buy. If you insist
on buying your hardware from HP/Dell/IBM/etc this may not be too big a
problem as those hardware vendors also take a significant amount of time
to 'certify' new things. For example, I have been looking for a new
hardware vendor and just discovered that I cannot buy a system from
HP/Dell/IBM that includes a SSD yet.

In my case I run Debian Stable on my servers, but identify 'important'
packages that I will compile myself and keep up to date with the upstream
project rather than running what Debian ships. The kernel is one such
package (I don't necessarily run the latest kernel, but I watch closely
for the vunerabilities discovered and if any are relavent to the
configuration I have, I upgrade). For dedicated database boxes Postgres is
another such package (if a system is primarily used for something else and
that package just needs a SQL database I may stick with the distro default)

David Lang