Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 1 May 1996 12:40:54 -0400 (EDT)
From:      Bill/Carolyn Pechter <pechter@shell.monmouth.com>
To:        wes@intele.net, freebsd-chat@freebsd.org
Cc:        wpechter@vnet.ibm.com (bill pechter)
Subject:   Re: Unixware
Message-ID:  <199605011640.MAA24010@shell.monmouth.com>
In-Reply-To: <199605011558.JAA08723@obie.softweyr.com> from "wes@intele.net" at May 1, 96 09:58:15 am

next in thread | previous in thread | raw e-mail | index | archive | help
> Which standard set of commands?  V4, V5, or V6?  DEC had a nasty habit
> of breaking everything in VMS each time they did a major version
> upgrade; witness the e-mail incompatibilities between VMS 3.x and 4.x,
> or the backup incompatibilities between 4.x and 5.x, etc.  VMS had its
> good points, but from a system programming standpoint, consistency was
> not one of them.  All of those different layers of operating system,
> each with a completely different API philosophy, could get pretty
> annoying.

Geez, considering I was working at DEC and ran on both alpha and beta 3.x 
and 4.x at DEC I'm surprised about the "email incompatibilities"... Do 
you mean the stupid mailbox pointer problem.  
I dropped off the VMS stuff around 4.2...

> 
>  > The support by rote reading of prior database trouble tickets SUCKS
>  > big time.  "But it's cheaper than hiring engineers to do that..."
> 
> Sounds like you need a better system vendor.  Try Sun or SGI.  Avoid
> IBM like the plague they are.

Actually, I'm working for IBM now and so far it's better than HP or Sun
for support.  I had to really put aside my old DEC views of IBM when
I showed up here.  

It ain't the same company  and it doesn't have the same attitude I saw when 
the IBM techs refused to talk to me when I was a DEC Field Service guy in 
the same computer room. (The DG guy and HP guy talked to me and we even 
loaned each other tools...  The big blue guy wouldn't respond to a hello...back
then.)


> Been there, done that to.  In addition to a wide variety of UNIX (all
> mentioned above, plus SVR2/286, SVR2/68k, {386,Net,Free}BSD, Minix and
> a smattering of Coherent, Concurrent (nee InterPig, er, InterData)
> OS/32, Harris VOS, RT-11, RSX-11, DOS, DG RDOS and AOS, CP/M,
> SuperDOS, and several embedded real-time OSs, including one I've
> pretty much rewritten from scratch in the last few months.
> 

What's SuperDOS?  I know TurboDOS, and the others by reputation...

OS/32 is the OS from hell...  Great OS capabilities with the WORST 
user tools/interface I've ever seen. (I used to work for them after DEC)...
I loved getting them to talk TCP/IP and getting their Corporate Email up
under SMTP after NEM (which looked like IBM Profs done on the cheap).

> Funny, I seem to remember a lot of VMS people saying UNIX would be
> dead by 1990, or 1995, or whenever.  Bought any VMS machines lately?

Almost, last week.  A Vax3100 for my house... but I can't get the OS for it
cheap.

> Remember the predictions from 88/89 when OS/2 was going to kill UNIX?
> Doesn't seem to have happened. 

I never felt that could happen -- or that the Microsoft/IBM mix would hold
together...

> Or from '94, when NT was going to completely replace UNIX within a year?  
> Then the UNIX vendors had record sales in 94 and 95.

Watch and wait...

> 
> There will never be one UNIX standard, because the essence of the UNIX
> marketplace is choice and differentiation.  The UNIX market will not
> coalesce around a single standard because that is not what the UNIX
> market wants.  I agree that most large corporations are looking for a
> single-point solution to their application server woes, which makes
> them steer away from the UNIX market.  Fine -- that doesn't mean we
> have to mold UNIX into the product they want; they can buy that
> elsewhere.
> 

Sure and Unix will be a developer, hacker only OS.

> These people can still buy MPE and OS/400, or NT, or NetWare, they
> just can't get the performance they can from the UNIX market.  When
> they want the performance, they step into the big league, pick a
> vendor who will work with them, and make the relationship work.  Or
> they end up as a UNIX disaster story, because they tried to implement
> UNIX their way, instead of the UNIX way.  Neither is right or wrong,
> they're just different.
> 


Watch.  Pyramid and Sequent and DEC are doing big time multiprocessor 
NT boxes.  It's just getting started.  DEC's doing clusters -- the one
thing they had to differentiate the VMS systems... 


>  > They want DROIDS to run most corporate machines.  A windows interface,
>  > a couple of pull downs, canned applications, a simple backup/restore
>  > application.  They want $35k college kids (hell, they want less than
>  > that -- 2 year tech school wonders) to run the stuff.  They're hiring 
>  > Unix admins that I wouldn't have had as VMS operators...
> 
> Bill, you've made some good points, you've just drawn the wrong
> conclusions.  Just because people want to buy Windows NT is not a
> sufficient argument to make UNIX into Windows NT.  There are
> advantages and disadvantages to doing things the UNIX way; when the
> advantages outweight the disadvantages, customers will buy UNIX.  When
> the disadvantages rule, they will buy something else.  The job of the
> UNIX evangelists (i.e. Harris and Randy, see their monthly column at
> http://www.sun.com/sunworldonline) is to show people that some of the
> perceived disadvantages are simply not true.
> 
> -- 
>    Wes Peters	| Yes I am a pirate, two hundred years too late

Wes -- just wait and see.  Look back to where things were in 1976, then 86
then 96.  Unix HAS peaked... or is just about to.

Bill

-------------------------------------------------------------------------------
 Bill Pechter/Carolyn Pechter  | 17 Meredith Drive, Tinton Falls, NJ 07724, 
 908-389-3592                  | pechter@shell.monmouth.com                
 I'll run Win96 on my box when you pry the keyboard from my cold, dead
 hands.  FreeBSD, OS/2, CP/M, RT11, spoken here.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199605011640.MAA24010>