annala@neuro.usc.edu (A J Annala) (12/26/90)
In article <2777E87B.6392@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes: >According to annala@neuro.usc.edu (A J Annala): >>According to DEC's advertisement in Computer Reseller News, the new >>DEC 433MP System (1 to 6 coupled i486 CPU's, 64 MB global shared memory >>64 MB/s system bus, 1.2 GB internal hard disk) will not run any variety >>of VMS (or even ULTRIX) -- INSTEAD IT WILL RUN SCO UNIX!!! >Well, of course it won't run VMS. VMS is coded in VAX assembler. My friends tell me most of VMS is coded in a DEC proprietary language called BLISS. BLISS exists for PDP-11's, PDP-10's, and VAXen -- DEC could have chosen to write a new BLISS compiler for the 80386 -- but that is not what happened -- instead, DEC adopted SCO UNIX for their new machine. Moreover, in the process, DEC abandoned it's own ULTRIX (DEC proprietary version of UNIX) in order to adopt SCO UNIX. >>As far as SCO UNIX being difficult to deal with, you might consider my >>experience with this system. I am a biologist - not a system programmer. >A user who doesn't do anything complicated with system administration, >or who has no history of system administration with other UNIX >systems, will not fully appreciate SCO's "C2" for the botch it is. It >makes things hard that used to be easy, and it makes impossible things >that used to be possible. I have installed the base operating system, development system, and tcp/ip on a completely uninitialized machine with only guidance from a reference manual. I created user accounts - downloaded, compiled, and installed gcc and emacs in the appropriate directories - wrote a device driver for the Data Translation QuickCapture frame grabber - downloaded and am now making appropriate changes to install a SUN UNIX based image processing system. I make periodic backup tapes. I am happy with the system. My users are happy with the system. Living within C2 guidelines is causing us no real grief. What more do you want from SCO UNIX? The fact you have to change some of your habits to fit within the current security framework should not drive so many complaints. Computer systems change -- we have to change with them -- if people didn't accept the need for change we would all still be writing machine code for monolithic IBM 7090's with no operating system, no compilers, and no interactive access. Take a hint from the biological sciences: we must evolve or die.
campbell@redsox.bsw.com (Larry Campbell) (12/26/90)
In article <29029@usc> annala@neuro.usc.edu (A J Annala) writes:
-
-My friends tell me most of VMS is coded in a DEC proprietary language
-called BLISS. BLISS exists for PDP-11's, PDP-10's, and VAXen -- DEC ...
Almost right. The VMS kernel is entirely, or almost entirely, written in
VAX assembler. Many of the user-mode commands, utilities and libraries,
though, are written in BLISS.
--
Larry Campbell The Boston Software Works, Inc., 120 Fulton Street
campbell@redsox.bsw.com Boston, Massachusetts 02109 (USA)
The U.S. Constitution may not be perfect, but it sure beats
whatever we're using right now.eric@egsner.cirr.com (Eric Schnoebelen) (12/27/90)
In article <29029@usc> annala@neuro.usc.edu (A J Annala) writes: - In article <2777E87B.6392@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes: - >According to annala@neuro.usc.edu (A J Annala): - >>According to DEC's advertisement in Computer Reseller News, the new - >>DEC 433MP System (1 to 6 coupled i486 CPU's, 64 MB global shared memory - >>64 MB/s system bus, 1.2 GB internal hard disk) will not run any variety - >>of VMS (or even ULTRIX) -- INSTEAD IT WILL RUN SCO UNIX!!! - >Well, of course it won't run VMS. VMS is coded in VAX assembler. - - My friends tell me most of VMS is coded in a DEC proprietary language - called BLISS. BLISS exists for PDP-11's, PDP-10's, and VAXen -- DEC - could have chosen to write a new BLISS compiler for the 80386 -- but - that is not what happened -- instead, DEC adopted SCO UNIX for their - new machine. Moreover, in the process, DEC abandoned it's own ULTRIX - (DEC proprietary version of UNIX) in order to adopt SCO UNIX. One comment. The reason that DEC most likely went with SCO is that they have had a multi-processor OS (Unix?) for the '386 class chips for at least a year. And DEC certainly could not afford to port Ultrix for the cost that they were able to purchase SCO's multi-processor product. It costs lots of money and time to port an OS, and I can't see DEC perceiving that much return from it's '386/'486 based products. I would suspect they built it to keep customers who wanted low end Unix machines from DEC happy. Remember that DEC also purchases MS-DOS PC's from Tandy to keep those same customers happy. Dollars, not features, and availability, not ability caused DEC to purchase the SCO product over it's own Ultrix product. I will make no comments on the value of the SCO product, since I have not used it. I did watch one gentleman install time and time again in the process of trying to bring up a PICK product recently, but I have no idea how much of that was related to SCO, the PICK product, or the gentleman installing (although my bets are on the third! :-) -- Eric Schnoebelen eric@cirr.com schnoebe@convex.com ... Had this been an actual emergency, we would have fled in terror, and you would not have been informed.
mrm@sceard.Sceard.COM (M.R.Murphy) (12/27/90)
In article <29029@usc> annala@neuro.usc.edu (A J Annala) writes: [...] >I have installed the base operating system, development system, and tcp/ip >on a completely uninitialized machine with only guidance from a reference >manual. I created user accounts - downloaded, compiled, and installed gcc >and emacs in the appropriate directories - wrote a device driver for the >Data Translation QuickCapture frame grabber - downloaded and am now making >appropriate changes to install a SUN UNIX based image processing system. >I make periodic backup tapes. I am happy with the system. My users are >happy with the system. Living within C2 guidelines is causing us no real >grief. What more do you want from SCO UNIX? Real time responsiveness, dynamic rather than static tables, security without gaps, improved resource management, real protection from intentional as well as accidental denial of service...The list could go on, but you'd be bored. For fairness, I want this from more than SCO UNIX. > >The fact you have to change some of your habits to fit within the current >security framework should not drive so many complaints. Computer systems >change -- we have to change with them -- if people didn't accept the need >for change we would all still be writing machine code for monolithic IBM >7090's with no operating system, no compilers, and no interactive access. 7090's had compilers. 7090's had operating systems. WRT "computer systems change -- we have to change with them", it seems that this is cart before the horse. We should change computer systems to meet our requirements; it shouldn't be the other way around. If the current security framework doesn't meet needs, it should be changed to meet needs. If you are happy with SCO's implementation, good. That doesn't mean it meets everyone's needs. > >Take a hint from the biological sciences: we must evolve or die. We all die. Therefore, we all evolve or die :-) -- Mike Murphy mrm@Sceard.COM ucsd!sceard!mrm +1 619 598 5874
jfh@rpp386.cactus.org (John F Haugh II) (12/27/90)
In article <29029@usc> annala@neuro.usc.edu (A J Annala) writes: >My friends tell me most of VMS is coded in a DEC proprietary language >called BLISS. BLISS exists for PDP-11's, PDP-10's, and VAXen -- DEC >could have chosen to write a new BLISS compiler for the 80386 -- but >that is not what happened -- instead, DEC adopted SCO UNIX for their >new machine. Moreover, in the process, DEC abandoned it's own ULTRIX >(DEC proprietary version of UNIX) in order to adopt SCO UNIX. BLISS is not proprietary. If I remember from my languages survey course (the one where I was supposed to write a paper on the origins of BLISS ...), it was originally developed at CMU. BLISS is best known for its use of "." in address notation. Just ask a BLISS-bigot to justify putting that "." in front of a variable name, then stand clear ;-) Furthemore, there is no one "BLISS". My recollection of BLISS is that you get one for each platform - BLISS-36, BLISS-11, etc. I don't know what the difference is as I only played with BLISS on the VAX briefly. As for VMS, it is written, for the most part, in VAX assembler. The utilities are written in a combination of languages, including FORTRAN, BLISS, Pascal, and some are probably still in PDP-11 assembler running in compatibility mode. You can find out the language of your favorite program by getting it to abort somehow and staring at the stack traceback messages. Back when I was abusing VMS machines (about v2.x) you could type a ^Z at almost any program unexpectedly and it would barf for you. You might have better luck dumping the .EXE files and seeing what you can find. It's been quite a few years, so your milage may vary ... I was told several years ago that some people were actually starting to write parts of VMS in C (!). -- John F. Haugh II UUCP: ...!cs.utexas.edu!rpp386!jfh Ma Bell: (512) 832-8832 Domain: jfh@rpp386.cactus.org "While you are here, your wives and girlfriends are dating handsome American movie and TV stars. Stars like Tom Selleck, Bruce Willis, and Bart Simpson."
mju@mudos.ann-arbor.mi.us (Marc Unangst) (12/28/90)
annala@neuro.usc.edu (A J Annala) writes: > The fact you have to change some of your habits to fit within the current > security framework should not drive so many complaints. Computer systems Why not? I'm the boss around here, not my computer. Saying, "We have to do things this way because of the computer," translates to, "We have to do things this way because the programmers were too lazy to get things right." *I'm* not the one that should have to change my habits; the computer is the one that should have to change. -- Marc Unangst | mju@mudos.ann-arbor.mi.us | "Bus error: passengers dumped" ...!umich!leebai!mudos!mju |
shore@mtxinu.COM (Melinda Shore) (12/28/90)
In article <18859@rpp386.cactus.org> jfh@rpp386.cactus.org (John F Haugh II) writes: >BLISS is best >known for its use of "." in address notation. Just ask a BLISS-bigot >to justify putting that "." in front of a variable name, then stand >clear ;-) I hardly qualify as a BLISS bigot, but I really don't see that .FOO is any odder than *foo or foo^, eh? -- Hardware brevis, software longa Melinda Shore shore@mtxinu.com mt Xinu ..!uunet!mtxinu.com!shore
atk@tigger.Colorado.EDU (Alan T. Krantz) (12/29/90)
In article <1990Dec28.022041.20793@mtxinu.COM> shore@mtxinu.com (Melinda Shore) writes: >In article <18859@rpp386.cactus.org> jfh@rpp386.cactus.org (John F Haugh II) writes: >>BLISS is best >>known for its use of "." in address notation. Just ask a BLISS-bigot >>to justify putting that "." in front of a variable name, then stand >>clear ;-) > >I hardly qualify as a BLISS bigot, but I really don't see that >.FOO is any odder than *foo or foo^, eh? I programmed in BLISS-10 for about 4 years (I never took the time to learn BLISS-36 because we never got a BLISS-36 compiler so I don't know how they differ) but anyways, while I liked BLISS-10 a lot one of the problems was that you didn't have data types per sey. Hence for any variable you could put (or forget to put) the . in front of it. So unlike C's *foo or pascal's foo^ .foo (or simply foo) would be legal in any expression (no error (pascal) or warning (C) messages). While one would think that this would create havok, (and sometime it did) it actually wasn't that bad. Anyways, when people say C is an expression language don't listen to them - it ain't. Now BLISS-10 - that's an expression language.... It really is/was a nice language - except that it didn't have any type of standard runtime library... ------------------------------------------------------------------ | Mail: 1830 22nd street Email: atk@boulder.colorado.edu| | Apt 16 Vmail: Home: (303) 939-8256 | | Boulder, Co 80302 Office: (303) 492-8115 | ------------------------------------------------------------------
allbery@NCoast.ORG (Brandon S. Allbery KB8JRR) (12/29/90)
As quoted from <29029@usc> by annala@neuro.usc.edu (A J Annala):
+---------------
| Take a hint from the biological sciences: we must evolve or die.
+---------------
Yes, but I thought the "catastrophe" theory of evolution had been discredited.
++Brandon
--
Me: Brandon S. Allbery VHF/UHF: KB8JRR on 220, 2m, 440
Internet: allbery@NCoast.ORG Packet: KB8JRR @ WA8BXN
America OnLine: KB8JRR AMPR: KB8JRR.AmPR.ORG [44.70.4.88]
uunet!usenet.ins.cwru.edu!ncoast!allbery Delphi: ALLBERYallbery@NCoast.ORG (Brandon S. Allbery KB8JRR) (12/29/90)
As quoted from <1990Dec28.022041.20793@mtxinu.COM> by shore@mtxinu.COM (Melinda Shore): +--------------- | In article <18859@rpp386.cactus.org> jfh@rpp386.cactus.org (John F Haugh II) writes: | >BLISS is best | >known for its use of "." in address notation. Just ask a BLISS-bigot | >to justify putting that "." in front of a variable name, then stand | >clear ;-) | | I hardly qualify as a BLISS bigot, but I really don't see that | .FOO is any odder than *foo or foo^, eh? +--------------- What's odd about it is that it's required by *every* variable. (For those who've never been exposed to BLISS: you don't declare variables, you declare addresses. "." is the dereference operator. So to use a variable, you must *always* use the dot to specify you mean the variable and not its address. This behavior is great for writing OS kernels, device drivers, etc., but is a bit baroque for application programs. I don't remember any other oddities; the extent of my exposure to BLISS was a manual for BLISS-10 that I borrowed for a few days some 9 years ago. It didn't interest me enough to follow up, especially after comparing the horrendous number of JSYSes in TOPS-20 to the number of system calls in Xenix 2.3a, which I had just discovered.) ++Brandon -- Me: Brandon S. Allbery VHF/UHF: KB8JRR on 220, 2m, 440 Internet: allbery@NCoast.ORG Packet: KB8JRR @ WA8BXN America OnLine: KB8JRR AMPR: KB8JRR.AmPR.ORG [44.70.4.88] uunet!usenet.ins.cwru.edu!ncoast!allbery Delphi: ALLBERY
libove@libove.det.dec.com (Jay Vassos-Libove) (01/03/91)
In article <29029@usc> annala@neuro.usc.edu (A J Annala) writes:
My friends tell me most of VMS is coded in a DEC proprietary language
called BLISS. BLISS exists for PDP-11's, PDP-10's, and VAXen -- DEC
could have chosen to write a new BLISS compiler for the 80386 -- but
that is not what happened -- instead, DEC adopted SCO UNIX for their
new machine. Moreover, in the process, DEC abandoned it's own ULTRIX
(DEC proprietary version of UNIX) in order to adopt SCO UNIX.
This is not an official DEC statement, this is just me talking.
DEC did not "abandon" Ultrix in order to "choose" SCO Unix for the PC
line that we sell. DEC chose to fill a market niche that we had not
previously been filling, and our evaluation was that SCO Unix was the
best candidate from among the existing PC Unixes.
Porting VMS to another processor is not just a matter of rewriting
a BLISS compiler, it is a matter of re-engineering the entire operating
system, since the VMS operating system makes use of VAX hardware specific
features to get performance, reliability, and security from the hardware.
Porting any brand of Unix (be it SunOS, Ultrix, etc...) is a MAJOR effort,
and not conducive to getting a product to market in any short time frame,
which I guess was one of the points of choosing existing equipment and
software/OS to repackage as our PC+Unix line - to get it out the door.
No operating systems have been abandoned, and none have any critical
flaws. Everything done here was practical and business oriented.
--
Jay Vassos-Libove libove@libove.det.dec.com
Digital Equipment Corporation decwrl!libove.det.dec.com!libove
Detroit ACT/Ultrix Resource Center Opinions? They're mine, mine, all mine!
Farmington Hills, Michigan and D.E.C. Can't have 'em!