[geeks] Sun vs. SysVr4

Greg A. Woods geeks at sunhelp.org
Wed Aug 22 14:12:37 CDT 2001


[ On Wednesday, August 22, 2001 at 03:06:11 (-0400), Dave McGuire wrote: ]
> Subject: Re: [geeks] Sun vs. SysVr4
>
>   I'm not on geeks.

Oops!  :-)  (The volume is pretty high, even for a list of its nature,
but I'm with Bill -- generic discussions should always move to geeks!)

>   Solaris doesn't run on 3B2s.  We are talking about SOLARIS here...and
> I'm saying that your statement that Solaris replaced SunOS because it
> was more "production quality" is total horseshit.

No that's not what I said.  I said that SysVr4 was one of the best
things that happened to SunOS.

>   ...which is just becoming true about Solaris NOW, but sure wasn't
> seven years ago when Sun was trying to cram it down our throats.
> There was a multi-year gap during which Sun had NO production-quality
> operating system that their salesdroids were pushing.  They were
> busily denying the existence of SunOS4.1.4 while Solaris2.3/2.4
> machines were crashing all over their installed base due to library
> memory leaks and other stupid bugs that should have been caught years
> prior.

I don't disagree with that....  Problem is if they'd tried to get to
where they are now with SunOS-4 they'd have long ago joined the ranks of
Altos or some similarly long dead unix company.

In my view Sun supported SunOS-4 long beyond when they really had to.  I
was stunned that they even produced Y2K patches for it!

>   Oh good lord.  If this isn't a perfect example of pure SysV vs. BSD
> religion, I don't know what is.

Those who have never run large numbers of SysV boxes in highly demanding
production environments (eg. inside phone switches) are doomed to repeat
the learning curve that AT&T went through in the 1970's and early
1980's.

Sure you can baby SunOS-4.1.4 into a production environment if you know
what you're doing, but as an OS vendor you can't expect that to happen
automatically for all your customers.  SunOS-4 always catered far more
to the workstation environment than it ever did to production servers.

>   NOW, of course, yes, it's better.  What do you expect when a company
> abandons development on one operating system and plows forward on
> another.  The thing that I have a problem with, though, is that SunOS4
> was dropped, and its replacement wasn't ready (by any useful measure
> of "ready") for a couple of YEARS afterwards.

Indeed, which is why I say it was Sun's mistake not to have taken the
SysVr4 porting base back from AT&T and start over again with it and do
their vendor-customisation properly.  The likelyhood of that happening
in the political environment of the day was far less than nil of course.

Sun's biggest problem prior to Solaris-2.4 had absolutely nothing
whatsoever to do with their SysVr4 base (that's just the poor excuse
touted by customers such as yourself) -- it was simply that they had far
too many programmers in the code tweaking things and almost NOBODY
testing the results (other than customers, that is).  When they finally
put the hammer down and made, what was it, 1/3 of them(?) into test
engineers, did they finally get a handle on things.

As with any proprietary OS vendor (and even some non-proprietary ones,
as I'm beginning to see with NetBSD), binary compatability is a major
headache too.  Some of Sun's early choices came back to haunt them (and
still do, as figuring out how to migrate user from SunOS-5.[78] to
SunOS-5.9 is taking a major amount of effort).  The migration from
SunOS-4.x to SunOS-5 was major hurdle (and part of the reason why so
many customers stayed with SunOS-4 for so long, demanding (or rather
paying) for support for so long too.

Another part of the problem was they insisted on keeping all the really
broken half-hearted re-implementations of the UCB compatability crap in
front and centre on Solaris.  Anyone using pure SysVr4 stayed as far
away from the UCB compat crap as they could.  Even if they'd taken the
Net-3 tape and used it instead of their own untested re-implementations
they'd have been further ahead.  You could alway be certain of getting a
core dump eventually if you linked something with libucb, and of course
the UCB binaries were built that way and often crashed too.

If you look at any of the big vendors who made a proper switch to
SysVr4.x using the official porting-base code you'll find they built
some very powerful (for the day) and reliable systems.  Pyramid, with
their entirely SysVr4-based DC/OSx comes to mind -- at one time it was
Oracle's favourite platform for really big database systems.  I remember
when having a big DC/OSx system crash was a major earth-shattering event
because it was so rare and unexpected.

Heck I even ran an Amiga-4000 with SysVr4.0 on it for a few years as my
secondary workstation.  I don't think it ever crashed, and it wasn't
like Commodore had much in the way of resources to put into hardening
SysVr4.  They basically only had one real systems guy and a couple of
juniour programmers working on it -- just enough to do the basic porting
and drivers!  SysVr4 from AT&T was very solid if you didn't play around
inside of it and muck things up again!

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods at acm.org>     <woods at robohack.ca>
Planix, Inc. <woods at planix.com>;   Secrets of the Weird <woods at weird.com>



More information about the geeks mailing list