Nacho-BSD

[Fairlight]

On Sun, Jun 25, 2006 at 11:24:03AM -0500, Steve Bergman may or may not have
proven themselves an utter git by pronouncing:
> I don't really miss open server.  I think someone pointed out the Digi 
> drivers are easier under SCO.  (By the way, whoever said that, I think 
> you will find that their drivers actually work with more versions of 
> Linux than those listed in the docs.)  I find that is true of many 
> things serial.  SCO was born into an rs-232 world.  Linux was born into 
> a networking world.  Much of Linux's rs232/422 stuff seems bolted on.  
> Then again, SCO's tcp/ip seems bolted on.

Might I ask how you perceive linux's serial to be "bolted on"?  I started
in '93 at 0.99.9pld.  First release that supported Adaptec's 1522 card
(when FreeBSD didn't--else I'd have been on FreeBSD for 13 years and
counting instead of linux).  However, the serial was already in the kernel
-then-.  We had UUCP going on it, as well as a few other things (I want to
say minicom was already out in an early form, I think it was...uucp
-definitely- was as I used it for sure at that time.

The serial code was a non-modular segment for a LONG time.  You could
enable or disable it, but they didn't make it modular until the time they
started going through and making everything a module (including the
keyboard, if I recall correctly).

Now, Digi got support relatively late.  I'm going to hazard a rememberance
and say about '97-'98-ish.  That's Digi in specific.  Before that there
-was- support for a Stallion card that I'd never heard of before working
with the kernel.  That was more like '94-'95.  That was around quite some
time before Digi's driver.

As for the Digi driver--who wrote it?  Digi?  Or someone else?  If it was
Digi, it was probably the same kind of delay seen in getting Adaptec's i2o
driver stable and rolled into the kernel officially (a process that I seem
to recall taking over 2 years).

At any rate, I fail to see where rs232 was tacked on.  It was there very
early.  If certain multiport cards weren't supported, that doesn't mean
serial in general wasn't, it means specific cards weren't.

As for SCO's TCP, it -is- bolted on.  It has been since Xenix, when you had
to buy a separate TCP/IP stack, and also with their 3.2.4.x unix you had
Enterprise which had it, and the non-enterprise which did not.  I believe
the same held true for OSR, did it not?  But yeah, that definitely was a
tack-on.  Actually, SCO not having a TCP/IP stack is the best security
enhancement ever "designed" into it. :)

> At any rate, and the real reason for this post, is to suggest CentOS to 
> you.  As you probably already know, it is the premier community 
> supported version of RHEL.  It is very well maintained.  Security 
> patches are prompt.  The support mailing list is excellent.  It comes 
> with over 7 years of support from the time of release.  The current 
> release is CentOS 4.3, based on RHEL4, which was in turn based on FC3 
> and was released a year and a half ago.

Support in terms of non-deprication, or support in terms of commercial
support you can call?  If the latter, RH's was -useless-.  I had issues
with perl crashing with a segv (this should -never- happen with perl)
-only- on RHEL3, and they -never- have fixed it, to this day, despite
several reports through my customer's licensed support.  Their support was,
in fact, -worthless- in my opinion, especially considering how much they
ream you for it.

I actually resent RH's 'development' model.  They took away RHL, thus
killing most goodwill in the community, moved to an extravagantly costly
support-license model (whether you need support or not) under which you
have to license it PER YEAR, and to add major insult to injury, they get
the majority of the real product on which they base their "product" (ie.,
their lousy support) off the backs of the hard-working developers in the
Fedora community.  Along the way, they manage to bastardize things to the
point they don't run correctly.  Their own 'setup' tool won't even display
properly from RHEL3 to PuTTY--the screen gets corrupted.  I've lost pretty
much all respect I had for RH; and I really used to actually like them.
They've screwed themselves into the ground as far as I'm concerned.  I'd
take them over Mandrake, but that isn't saying much considering how much I
dislike Mandrake.

Given the above, -why- would I want to base myself on a distribution 2
tiers removed from where the actual meat of the real work is being done?
That seven year promise looks good, but organisations and companies have
historically rewritten such things to their benefit.  Originally some were
five, then three, then two...  I wouldn't trust it.  If that's the only
reason to go for something that far removed from its actual source, I'd
take a pass.  If there are other reasons, do tell.

> Other options would be CentOS 3 based on RHEL3 based on RH9 ( I think).  
> Or CentOS 2, based on RHEL 2.1, based on RH 7.2.  Even with the ancient 
> CentOS 2, 3 years of support are left on the clock.

The only one of those I'd trust is CentOS 2, and that's a bad move.  If it
were based on 7.3, okay, cool.  The differences in nightmaric circular
dependency lists for the rpm's between 7.2 and 7.3 was -HUGELY- pronounced,
and believe me, I had reasons to be intimately familiar with both.  7.3 was
by far a superior distribution compared to 7.2.  And I haven't liked or
trusted a release -after- 7.3.  With the direction RH was taking RHL,
whether it ticked a lot of us off or not, they -did- do us a favour by
getting a lot of us off of their platform, because their platform was
becoming increasingly less well engineered by the release.  8.0 had issues.
9 was a bad joke, and one of the worst cases of misguided-but-intentional
back-porting I've ever witnessed.  They were getting to be a bad joke.
There's a reason I personally never installed or recommended anything past
7.3; the releases that came after it just plain sucked like an Electrolux.

> RHEL/CentOS only makes releases every 18-24 months.  So it's not the 
> ever-moving target that some other distros are.

That's such a two-edged sword, though.  Especially with idio--er, people
basing their stuff on PHP and demanding the latest and "greatest" *cough*
version of it to keep up with the ever-changing API.  I know some of the
hardcore kernel developers--okay, when 7.3 went EOL and there was a
security issue where I had to roll my own PHP for 7.3 -and- keep it
conformant with 7.3's architecture, several of the more involved kernel
developers and developers for other popular packages told me (this is
verbatim from one of them), "If I had to reinstall PHP, I'd rather just
install a new version of the OS.  It's a nightmare."  And that's from a
developer who's obviously not tech-shy, and his sentiments were echoed by
about five other people that night.  Sure, I did it...wasn't pleasant, but
I pulled it off in one sitting.

Thing is, the concept of taking one base version, hacking it up, making
back-ports that it needs but also ones it doesn't, and then tracking it by
rpm revision number...  I mean, RH at one point had 2.4.9-[somehugenumber]
that was really "almost" equivalent to 2.4.18.  They finally did a 2.4.21
based kernel, but the one I remember had an ungodly amount of patches
applied.  They had an apache 1.3.12 that was really a -lot- higher than
that in terms of what it -actually- had going for it.  Eventually they
released 1.3.27--a LONG time later.

You can't tell what you really have unless you track the CSA numbers in
--changelog readouts, and you don't get anything except what they offer
you.  In most cases, you're free to roll whatever you like, but PHP was a
bear, and their perl is so hooked into the dependency list that you pretty
much don't dare -replace- it, no matter how buggy it is; your safest bet is
a parallel installation of a custom roll.

When you get to that point, remind me again -why- you're running a vendor's
distribution when you disagree with their philosophy, they're doing
half-arsed versioning and back-porting, their stuff is unstable, and
rolling your own mods into their dist is less cost-effective than rolling
it on pre-megavendor dists?  Ah, yes, for that superb "support" where
they'll "get back to you" and never actually do.  Apparently with the perl
thing, when I called them 4 months later for something else and happened to
inquire about it, "engineering" had left a ticket asking for my source code
(like they're getting THAT!) so they could replicate the problem.  This,
despite having told them in which 3 functions the crash must be occurring.
But did they call me to ask?  No.  Email?  No.  They never said a word
until I asked again.  Sorry, their "support" sucks, pure and simple.

Personally, when you get to that point, I think you're better off running
something like Slackware and just rolling all your dists yourself.  Which
would be the extreme, and require a lot of maintenence that hardly anyone
has time to do--especially if you maintain dozens of systems or more.  So
Bill's OpenPKG scenario sounds like a good idea after a while.

I'm just failing to see how CentOS would be beneficial when it's based on
something that wasn't theirs, and isn't trustable at the level it was taken
from--and from a certain point in time forward was actually not designed
(largely) by that party at all, but by the community with the exception of
the vendor-specific bits and the lousy back-porting.

Even the 7-yr timeframe doesn't really help.  Maybe you've never had this
discussion with package maintainers, but I have:

"There's a problem with your program on RH 6.2."

"RH 6.2?  That's still GLIBC 2.1.  What are you doing running -that-?"

"I'm stuck with it for the immediate future.  Now, back to why the program
slows to an absolute crawl...?"

"Sorry, we're only developing on glibc 2.2 and higher, on kernel x.x.x and
higher.  You have the source, feel free to fix it."

It was well within a 7hr window, too.  And yes, I've actually had that
discussion.

Promise of 'x' lifetime doesn't do you much good when the applications
running on it (and other developers' decisions) make the platform obsolete
even if the OS vendor themselves will stand by it for a long period of
time.  Hell, they can't even control that half the time.  Most of the major
stumbling blocks have been things like the a.out->ELF conversion,
libc5->glibc, major kernel revisions, etc.  They can stand by an obsolete
configuration.  Red Hat could have stood by 5.2 to this very day for all
the good it would do a MySQL user (mysql won't compile properly on RH 5.2,
I've tried--even back in 3.23 days).  So I'm not seeing the benefits there
unless you happen to be running something -so- static that you can afford
to let your platform go stagnant, save security patches.

And linux isn't alone in this.  You get people -today- that will actually
read you the riot act for running Win2K, when the software in question
(Oblivion, in this case) actually -includes- Win2K in the compatibility
list for sysreqs, -and- MS still supports Win2K.  Nooooo...you should be
running XP SP2, period.  Anything else and you're a slacking loser.  Trust
me, I had this argument 2 weeks ago.  And the linux developers are more or
less apathetic to your problems unless you are on the later releases.  Not
many are willing to guarantee backwards compatibility to what I'd consider
'x' sane degree.

> I've been quite pleased with it.

Okay, tell me -why- you're pleased with it.  My experiences with RH tend to
tell me (as you can tell) that I'm less than pleased with them.  Why would
it be a good idea for me to consider a dist -based- on theirs, from
someplace I've never dealt with, no less?  At its heart, if it's -really-
based on RH's later stuff, I don't think I'd be happy with it.

> As to the BSDs.  Even though I don't happen to use them myself at this 
> time, I'm a big believer in the idea that all the POSIX-like OS users 
> are "family".   If FreeBSD is adjusting its development style, best of 
> luck to them.  We're all still suffering from the damage done by the 
> UNIX Wars.  This is probably gonna come off sounding pretty corny, but 
> open-source OSes could really benefit from more people applying the 
> Vulcan concept of IDIC:  Infinite Diversity in Infinite Combinations.

We've had that for the better part of 13 years.  Then people clamored that
there wasn't enough standardization, which lead to LSB 1 and 2, the
UnitedLinux debacle, and any number of problems.  That wasn't diversity,
that was attempting to homogenize it--but it was at the request of the
enduser community that -didn't- like the level of diversity we had.  Hell,
they still don't like the current level of differences, and you still hear
people griping, "There is no 'linux', they're all different!"  Someone said
that here on this list about three days ago.

Then you get into cross-platform diversity, and it becomes a religious war
all over again--far moreso than the vendor wars within one OS community.

Besides...I don't think the *BSD crowd shares your sentiments.  From what I
gather, they abhor the linux zealots, and they're none too fond of a lot of
the design decisions made in linux.  They have an air of superiority which
may actually be well-founded; they inherited a fully mature OS before linux
was even ready for solid beta release, and it's only gotten better since.

I'm enough of a fatalist to realise that cycle will -never- end.  There's
either going to be one OS and vendor that sweeps everything else away,
or there's going to be an ongoing religious war over whose software
is "better".  If the former happens, some idiot will claim, using the
buzzwords of that era, that innovation is being retarded.  If the latter,
we at least maintain the status quo--which is about the best you can hope
for with human beings in the loop.

Don't get me wrong--I love linux for servers.  It's the -people- making
lousy decisions and questioning sane decisions that I could do without.
Some days moving to FBSD sounds like a good idea.  I'm just reluctant to
virtually throw away 13 years of experience.  I could augment, I suppose,
but I'm not sure I want to spend the -next- 13 years learning FBSD inside
and out.  :)  (I've a lot of catching up to do since 4.3 Tahoe.)  I've
worked with FBSD 4.4 and 4.7.  But I don't know it as intimately.  No way
could I claim that.

mark->