A summary of all of the bad Linux advice in the CentOS thread earlier this month

[Jay Ashworth]

----- Original Message -----
> From: "Tyler Morgan" <tyler at xmission.com>

> The complete discounting of *BSD really irked me. Okay, sure, Filepro
> mailing list -- it doesn't work on BSD. Great to know! But let's not
> completely discount something like OpenBSD -- by far the most secure and
> best documented, full-featured Unix distribution in existence, or the
> amount of *BSD code under your Linux distro's hood.
> 
> So much code that so many people could not live without was written by
> the BSD folks. You know that free IPSec stack you're using for your
> OpenVPN sessions you couldn't live without? Or uh, SSH? Written by
> OpenBSD in the 90s. OSX on your Macbook? Based on FreeBSD.

Here, you're speaking to me.  And I was quite careful, I thought, to
characterize my distaste for BSD as being specific to the audience on
whose behalf assistance was being requested: IE: untechnical Filepro
users.

I didn't say BSD was bad.

I said it was "bad for running Filepro on if you weren't a damned *guru*".

Brian and Mark are such gurus.  I'm not. 

> And don't even get me started on how awesome at networking BSD is
> (OpenBSD in particular). Don't feel like spending $5 grand on a pair of
> HSRP capable Cisco routers for your border? OpenBSD was nice enough to
> reverse engineer it and then rewrite it as CARP in such a way where they
> couldn't be sued for violating Cisco's patents on HSRP. Now you can
> spend about $650 on a pair of commodity-hardware 1U rackmount servers
> and make a nearly equally capable border router. Never, ever use Linux
> as a router. iptables literally pales, falls over dead, and then
> decomposes before your eyes when compared to pf.

I'll make a note of it.  (My 2 Slackware 12 based firewalls handled my
10Mbps L3 fiber quite nicely, thanks.  With homemade IP failover.)

> I'm not saying you should look to any BSD to host your application --
> especially if it's Filepro! Linux is just as good in almost every way
> and much easier to manage in my opinion, except when it comes to
> networking. However, discounting it so quickly with remarks like "less
> than 1% of the community uses it" is really going to rub long-time
> Unix nerds the wrong way.

My first Unix was Tandy Xenix 1.2 on a Model 16; my first Linux, SLS 
0.99pl12f installed from 3.5" floppies.  Your move.  :-)

> I may be misreading slightly, but it was implied that LVM suffers from a
> similar issue as RAID0 -- if you lose 1 physical chunk of it, the whole
> array is gone. That is sort of true, but definitely not the whole story.
> If you lose any physical volume in a volume group, all of your logical
> volumes that belong to that volume group are gone -- no argument here.
> This is why you have to plan your (redundant) physical volumes
> carefully before putting LVM on top of them.

Yup.  I believe you're talking to me here, as well.  I still have the 
driveset in a bag, if you want to help me recover it.  :-)

> It's actually a very similar situation to picking what level of RAID you
> want. LVM can be configured as a "JBOD" which suffers the same risks as
> any other JBOD. This is hardly anything to hold against it. The totally
> reliable, sort of magical, well supported, well documented, and easy
> to use virtual "partitioning" system LVM provides can make your life
> really easy when you're moving stuff around or need to rethink your disk
> situation.

Well, no.  If you are in a position where you *can* have separate 
filesystems, then you *specifically* add more failure exposure by using
LVM if you don't need to.  Older MythTV installs (like the one I had
to deal with at the time) had that problem; newer ones don't, due to
storage groups.

> And that leads me into answering a question someone asked that never got
> a reply: RAID5 is still significantly slower for writing than RAID10 (or
> RAID0+1, your preference). For reading you can probably make RAID5
> faster but honestly I use RAID10 for anything that has to be fast. RAID1
> plus the occasional hot spare for anything that can be averagely fast
> and is important. RAID5 for large amounts of storage that is expected
> to be sort of slow to write to (but pretty speedy to read from!).

Whether your RAID5 is slower to write depends on how much RAM's on your
controller, and your write duty cycle.  If you don't have a hardware
RAID *card* controller with a battery and its own memory, you're playing,
and not covered by the conversation we were having as I understood it.

> Oh Bill. I respect your oldschool ways but /u, really? Don't use /u and
> the word competent in the same sentence. This is 100% preference and has
> nothing to do with skill level. And I 100% prefer to not make a mess of
> my filesystem by unnecessarily rearranging things. As far as installing
> to /usr/local/* always... well... I can't say I disagree in general,
> but at the end of the day: install to where ever makes it easy.

Personally, having grown up with filepro, I tend to put *everything* that
LHS wants under /opt into /appl.

> Again, unless there is a really good reason, I am not a fan of making
> it hard on myself. Defaults, defaults, defaults -- they are what get
> QA'ed most often! Unnecessary complication based solely on preference can
> lead to nightmare webs of pain after a decade of doing it and not cleaning
> up after yourself. Or, frankly, not accepting times change.

Following the Principle of Least Astonishment in systems administration
procedure design is an excellent plan, certainly.  But if you don't 
understand all the rules, then you don't know when to break them.

Nobody who's *left* on the planet, now that it's past 6pm local nearly
everywhere, is perfect (:-), but I've read all of the top administration
reference books, multiple times, usually -- including Limoncelli -- and
when I break the rules, I have a pretty good reason. Usually. :-)

> Speaking of which: "If it's not tape, it's not a backup" -- heh, well,
> no. Sure, tape has its uses, but again, there is absolutely no reason
> to think enterprise-level magnetic drives are not equally reliable and
> come with a whole slew of benefits over tape.

25 years of systems administration experience says you're wrong.  I have 
tapes easily that old, and they're still readable.  Good luck with your 
HDDs.  :-)  Sure spinning magnetic storage has advantages.  But if you 
believe that those outweigh its disadvantages, and the advantages of tape,
then you and I are playing in different card games.

>                                            Instead of worrying so badly
> about what media you're backing up to, why not make sure you're
> backing up to multiple locations. And monitor them daily. And test restores
> often. And break stuff on purpose occasionally. These are the things
> that are important when you're talking about backups -- not the media.

Sure.  But we weren't *talking* about those aspects.
 
> Lot's of /good/ advice on not touching SCO and using real RAID
> controllers! They are worth every penny.

Glad to hear we agree on *something* at least.  ;-)
 
> Anyway, I know this isn't a Linux or BSD mailing list, but it's always
> a best practice to have different perspectives on questionable
> statements or advice. I sincerely mean no disrespect and wish everyone well!

I always like to hear competitive opinions.  Every once in a while,
I learn something new from them.  :-)

Cheers,
-- jra
-- 
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates     http://baylink.pitas.com         2000 Land Rover DII
St Petersburg FL USA      http://photo.imageinc.us             +1 727 647 1274