OT: Linux flavors...

Fairlight fairlite at fairlite.com
Wed Jul 7 11:33:17 PDT 2004


Four score and seven years--eh, screw that!
At about Wed, Jul 07, 2004 at 11:23:25AM -0500,
Chad McWilliams blabbed on about:
> I am in the process of trying to determine what flavor of Linux to use
> to replace my Red Hat servers.  I've tested several (White Hat, Debian,
> LFS, etc.) but have not had a chance to test Suse (seeing as I can't
> download a copy to try out, unless I've missed it).  It seems that many
> of you think highly of it, which has peeked my interest.  The question I
> have is which version are you all running?  From the website I see:
> 
> Personal 9.1
> Professional 9.1
> Linux Server 8
> Linux Enterprise Server 8

I suggest Professional 9.0.

And I did a full ftp install.  Just get the initial floppy images and use
them to start it up.

Actually -I- didn't have a working cdrom -or- floppy drive, so I took a
tiny partition on a spare HD, combined all the module disks into one
coherent filesystem (basically copy them to the same place, but you have to
merge the modules.conf files into one), and then used loadlin from Windows
to actually start the boot floppy.  After that, ftp over ethernet worked
just fine for my home test system.

> I am looking for "real world" input on these versions, as opposed to the
> glossy details on the website.  I have 10 servers that I will be loading
> the os on when I decide what to go with, and 4 of them will eventually
> host filePro applications.  One of the things that is important to me is
> the update facility for security patches.  I don't always have the
> opportunity to manually recompile a program the minute the patch comes
> out and install it at all locations.  That was one thing I liked about
> Red Hat's errata/update system.

The update system -is- nice.  I never liked up2date.  I still don't
automate my updates.  I prefer to pick and choose exactly what I'm getting.
And they nicely classify patches based on a multi-level system (security fix,
recommended, bugfix, new version, etc.).  Usually I know exactly which
patches I'm waiting on from any vendor anyway.

As for adding software, yast has one of the coolest resolvers for
dependancies, bringing up a list of exactly which packages you need to
install for anything with unsatisfied dependancies.  It's pretty slick.

Under the hood, pretty much everything (I can't think of any real
exceptions) is also editable by hand.  You can configure things by hand if
you wish, and the config tools still work.  Ah, one exception is apache.
I remember reading in the comments that you -can- edit it by hand, but as
soon as yast's apache config module detects the checksum difference, it
will no longer edit with that tool.  But that's no big deal.  I much prefer
to deal with the config file, so I just do that.  The core system is
configurable either way though.

I like SuSE 9.0 better than any RH I used, from 4.1 all the way through
7.3.  (They never sat still long enough to be worth adopting after that,
and then went away.)  And I've had a chance to look at RHEL3 on someone's
system.  I can't say much about a system whose perl is broken.  It
literally segfaults on a very simple program that has worked on Solaris,
SCO, RH 7.x, SuSE, FreeBSD, and a few others, reliably.  I got to talk to
RH's tech support about it and they claimed to know about the issue (they
"think" they know what it is, but their explanation shows they know nothing
about how perl -should- work), and though they said they were escalating
it, it's since been at least two weeks with no word.  Meanwhile, I manually
compiled 5.8.4 and all the modules I needed and it works fine on the same
system.  So if RH screws up something as ubiquitous as perl, what's next,
the kernel?  I find it ironic that now that it's an entirely commercial
product, their bugs are more grievous and less likely to be fixed than when
they had a far more sizable user base on the 'free' product.

I'm still quite prejudiced against Mandrake from back in the 6.x days.  I
won't even look at it again.  No way.  Debian is supposed to be okay, if
you don't care too much about a next to nonexistant lack of current updates
for security, or if you like to roll your own.  And I haven't bothered with
any of the upstarts or smaller players because I frankly don't feel like
wasting the effort on something more likely to go away than not.  We used
to have over 120 distributions to choose from, and now it's down to about
40 or so.  Bill Vermillion probably has the actual number somewhere.  It's
far more reasonable, and there were way too many for a long time.  My point
is, dists flop and fall out of favour and vanish.  So I stick with the
bigger players to avoid wasting effort.

If you've worked on one, you can work on just about any of them anyway--IF
you know the underlying system.  If one absolutely depends on the
vendor-specific tools, this probably does not apply, but then one likely
shouldn't be administering a system anyway, IMHO.  

Two thumbs up to SuSE 9.0.  But as Jay pointed out, avoid 9.1 for now.
It's a fresh dist, which status will iron itself out in about 4.5 more
months.  However, it's also based on the 2.6 kernel, which I'm far less
enthusiastic about based on everything I've heard and seen.  I'm thinking
it'll be a long while before I trust that one.  They're only up to 2.6.7
right now, and releasing at a rate of about one patchlevel a month.  I
don't trust kernels until they hit at least .18.  That's almost a year away
from being trustworthy.  For anyone that thinks I'm exaggerating, 2.4.15
was entirely blowing away whole filesystems, even if you did everything
right--assuming you got it to boot at all.  I know at least five people
-personally- who got hit wit that release, and it was far more widespread
than that.  And that was in a stable tree.  2.2 took through .16-.18 to get
right as well.  I think 1.0 took until .18ish too.  It's just historically
pretty predictable.  So it's going to be a while before I would ever
recommend a 2.6 kernel in production.  I've seen some recent pasting of
very disconcerting disk subsystem errors to IRC as well.  That inspires no
confidence.

Hence, I say wait on 9.1 for a while.  I'd say at least 4.5 months just so
it's been worked out for at least six months as a dist, nevermind the
kernel.  But the kernel will give -me- pause for longer than that, likely.

mark->
-- 
Bring the web-enabling power of OneGate to -your- filePro applications today!

Try the live filePro-based, OneGate-enabled demo at the following URL:
               http://www2.onnik.com/~fairlite/flfssindex.html


More information about the Filepro-list mailing list