[LUNI] Re: Seen any good distros lately?

[Lawrence Weeks]

Once upon a time (Sun Jan 07), Larry Garfield wrote:
> On Sunday 07 January 2007 4:26 pm, Branko Kotur wrote:

> Avoid CentOS.  We've been trying to run it at work, and it's been very 
> trying. :-)  Its SELinux implementation is b0rked to hell, and kept randomly 
> causing Apache to spit out 403 errors for no reason.  It also has a kernel 
> bug where periodically an apache process will spiral out of control and eat 
> up a crapload of RAM. [ ... ]

Once upon a time (Mon Jan 08), Trev Peterson wrote:

> I have been maintaining a few CentOS 4.4 servers for a client for the
> last 6 months.  In that time we've had the following problems:

> 1. SELinux is broken on CentOS4.4 and it is on by default (very bad
> choice).  There are many reasons I say this and if you are interested in
> a list let me know. 

> 2. As Larry mentioned the Apache package leaks memory (severely in some
> instances).

> 3. Auto-updates break on dependency hell (yes we are using yum and it
> still is unable to reliably update).  This has happened twice in the
> first 3 months I was maintaining the servers.  Both times it left the
> packages in a state that required considerable manual intervention to
> correct (read more than 1 - 2 hours).  Choosing Sendmail and Bind as the
> default mail and DNS servers make it even more important to regularly
> update your system.

I have CentOS installed on at least a dozen servers, both in small
business and an ISP environment running many, many virtual domains. I
have never seen a single one of these problems, save issues with
SELinux, which is now turned off immediately. We use distro Apache,
and BIND, and a combination of distro Postfix and latest-n-greatest
Postfix. I have all machines up to date with yum, and haven't had a
single issue of OS related instability, nor an issue of being unable
to update. I just checked serveral servers to make sure, and the
httpd processes (both init spawned and children) on none are very
large in resident or virtual. The oldest I saw goes back to Sep 28,
process sizes no larger than 20M. I'm not disputing your experiences,
but I haven't seen any of that in production.

> 4. Limited packages and configurations results in much more software
> maintained outside the package management system.  This adds to
> increased support time/cost and even more upgrade headaches.

I will grant you this. It includes only what the base RHEL
includes. However, I don't find this too much of a concern. The base OS
will be stable for years, and RedHat back-ports patches. For packages
for which we want more recent revisions we compile and install,
compile RPMs from the package when they support it (lots do), and
roll our own RPMs when justified.

Larry
-- 
Lawrence Weeks                                    lweeks at anabasis.net
Anabasis Consulting Ltd