aps@decwrl.UUCP (Armando P. Stettner) (12/01/85)
Hi. Regarding the news comment by der Mouse on whether or not Ultrix is 4.2 or not: From mcgill-vision!mouse Sat Nov 30 15:39:41 1985 Path: decwrl!decvax!mcnc!philabs!micomvax!musocs!mcgill-vision!mouse From: mcgill-vision!mouse (der Mouse) Newsgroups: net.unix,net.unix-wizards Subject: Re: 4.2 on 8600 (repeat) Message-Id: <339@mcgill-vision.UUCP> Date: 30 Nov 85 03:30:16 GMT References: <285@mupsy.UUCP>, <128@decvax.UUCP> Organization: McGill University, Montreal Lines: 40 Xref: pepe net.unix:4052 net.unix-wizards:5829 Apparently-To: aps Status: R > Ultrix-32 runs on the 8600. It runs like the > proverbial "bat out of ...". Contact your DEC salesperson for further > information. (do I recall something about advertising being verboten?) > Ricky Palmer > DEC > Ultrix Group > rsp@decvax I wasn't able to find the original article for this, but from the subject line, I assume someone asked whether 4.2 ran on the 8600. ULTRIX IS NOT 4.2. IF THEY ASK FOR 4.2, DON'T ASSUME A CLOSE LOOKALIKE WILL DO!! Functionally, from the user level, it's very close, granted. BUT.... When we had a uVAXII here for evaluation it had Ultrix, and when I wanted to put in the /dev/std{in,out,err} driver and the load average syscall and the other kernel hacks, guess what I found? No kernel source! UNIX source comes with it (for universities). Ultrix source costs an obscene amount (we looked into getting it). And UNIX without source is pretty pointless (for us; for example, we had a grad student here whose thesis work would have been completely impossible without the kernel source). Guess what we'll be doing with our microvaxen! Right, running 4.3 (if they have it by that time) or moving 4.2 (otherwise). With UNIX source, when you find a bug, you fix it. The fix is available within a few hours, or days for the tough ones. With a vendor system like Ultrix, you send in an SPR and hope they deign to pay attention to it. Even when they do, you're lucky if it gets back, with or without a fix, within a month. Sorry for such a long and heated posting, but this sort of attitude "whaddya want 4.2 for when you can have Ultrix for 1000% more" really gets to me. -- der Mouse USA: {ihnp4,decvax,akgua,etc}!utcsri!mcgill-vision!mouse philabs!micomvax!musocs!mcgill-vision!mouse Europe: mcvax!decvax!utcsri!mcgill-vision!mouse mcvax!seismo!cmcl2!philabs!micomvax!musocs!mcgill-vision!mouse Hacker: One who accidentally destroys / Wizard: One who recovers it afterward Ultrix *is* 4.2 with a fair amount of work by DEC UNIX Engineering Group. Ultrix is not a look alike! It is modified 4.2. There is even about to be some of the internal improvements from 4.3BSD. Just because some (re)distribution of UNIX does not include source does not mean that it isn't UNIX (is 4.2 UNIX? as the question goes???). There in fact should be enough stuff distributed with Ultrix so that you can add a driver painlessly (assumming that you require no hacks in other parts of the kernel, because there are no sources!). Further, many of the tables and hard coded constants have been removed from the original source modules and placed in modules that are shipped as sources so that you (the customer) can get at them. Ultrix is not really good for academic environment where students will be doing thesis work on operating systems or other computer science activities that involve modifying existing programs. It is better suited to places that have less experience with UNIX or for places that would prefer not to maintain the staff necessary to keep up an operating system. As for SPR's and service: that is the primary motiviation for some commercial organization to get Ultrix rather than 4.2 from Berkeley. This is not to say that that which comes from Berkeley is substandard or not useful. In fact, DEC would have based its products on System III (and then V) if 4BSD were not up to the tasks at hand. However, Berkeley is not in the business of *supporting* 4BSD for every organization that wants to run (or now runs) their release. DEC *is* in this business (please no flames ...). Realize that there is a seperate group within DEC with a charter to measure how quickly SPR answers are turned around to the customer. I do not believe that the attitude of myself or members of UEG is one of "whaddya [you] want 4.2 when you can have Ultrix". I think that you might not have had a very clear understanding of what Ultrix is and how it would or would not fit *your* situation. I don't feel sorry for people who complain that /bin/ed is not a good full screen editor. Armando Stettner
george@cornell.UUCP (George R. Boyce) (12/06/85)
In article <1554@decwrl.UUCP> aps@decwrl.UUCP (Armando P. Stettner) writes: >Hi. >Regarding the news comment by der Mouse on whether or not Ultrix >is 4.2 or not: > ... > >Ultrix is not really good for academic environment where students will >be doing thesis work on operating systems or other computer science >activities that involve modifying existing programs. It is better >suited to places that have less experience with UNIX or for places that >would prefer not to maintain the staff necessary to keep up an >operating system. > ... > Armando Stettner Ok, I give. Does someone care to support or attack this thesis? Since my job is to support an academic computing environment, The above statement strikes close to home. I can get kernel sources cheaply if I need them so that isn't the basis. Everything I've tried to port from BSD4.2 seems to either run or recompile and run just fine. And that does include all the "missing" BSD4.2 programs; I'll be asking Digital at DECUS to explain just why some of the programs were left out. Like 'finger' and 'man'... Sigh. Anyway, just *why* is it that Ultrix is bad for supporting computing in, say, a computer science department?? I'm not going to touch the line about support staff... George Boyce Academic Computing, Cornell Computing Services george@cornell.arpa, george@gvax.cs.cornell.edu, george@crnlcs.bitnet
avolio@decuac.UUCP (Frederick M. Avolio) (12/07/85)
In article <1441@cornell.UUCP>, george@cornell.UUCP (George R. Boyce) writes: > ... > ... Anyway, just *why* is it that Ultrix is bad for supporting computing > in, say, a computer science department?? It is fine for such an environment. Sometimes a customer will ask me why they should get Ultrix-32 rather than pay less and get 4.2BSD. I tell them that Ultrix-32 is more than just 4.2BSD. It is a commercial product. Some things have been added and some have been fixed. Also, one can get updates, bug fixes, and access to Digital'support force including a 24 hour hotline, an Ultrix Dispatch, automatic reporting and tracking of SPRs, etc. (And if you are having trouble with any of the above-mentioned services *and you have paid for them* you should raise a stink!) But, and this is what I think Armando was getting at, if you have no use for any of that, if you do all your own support, if your goal is to make massive changes to the kernel (essentially voiding the warrantee) then you might do better to go with a non-commercial product. No commercial OS product that I know of is set up to allow the customer to make changes to it and stil be supported by the company. Well, anyway, it's one man's opinion. In other words in no official capacity... -- Fred @ DEC Ultrix Applications Center {decvax,seismo,cbosgd}!decuac!avolio
grr@unirot.UUCP (George Robbins) (12/08/85)
In article <1441@cornell.UUCP> george@cornell.UUCP (George R. Boyce) writes: >In article <1554@decwrl.UUCP> aps@decwrl.UUCP (Armando P. Stettner) writes: >>Regarding the news comment by der Mouse on whether or not Ultrix [discussion of ultrix vs BSD] [conclusion: ultrix not for academe] >Ok, I give. Does someone care to support or attack this thesis? Since >my job is to support an academic computing environment, The above >statement strikes close to home. I can get kernel sources cheaply if >I need them so that isn't the basis. Everything I've tried to port >from BSD4.2 seems to either run or recompile and run just fine. And that >does include all the "missing" BSD4.2 programs. >George Boyce Academic Computing, Cornell Computing Services From the view point of a person trying to use the system, Ultrix is BSD, the major difference is in packaging. Ultrix is packaged for people who want to *use* unix, and provides a single source for machine, software and support. BSD is packaged for people who want to do things *to* unix, and who are capable and/or have the time to put all the pieces together and do their own support. There are some intermediate levels, organizations that offer a prepared release of BSD, or like Mt. Xinu who offer support for a price. The problem with your mix and match solution is that you get stuck in the loop. You have to find the things that don't match up and load up a bunch of sources that don't really correspond to what you are running. With BSD, the stuff is there and you just grant access to appropriate groups. Do you want to be involved every time a person wants to see how, say, egrep works? At 10:00 PM? My feeling is that anyone who can get a source license for the system they are actually running, and doesn't had better crawl under the bit bucket and hide! -- George Robbins uucp: {unirot|tapa}!grr P.O. Box 177 Lincoln U, PA 19352 [The ideas herein are not responsible to themselves!]
campbell@maynard.UUCP (Larry Campbell) (12/08/85)
> ...But, and this is what I think Armando was getting at, if you have no > use for any of that, if you do all your own support, if your goal is > to make massive changes to the kernel (essentially voiding the > warrantee) then you might do better to go with a non-commercial > product. No commercial OS product that I know of is set up to allow > the customer to make changes to it and stil be supported by the > company. > -- > Fred @ DEC Ultrix Applications Center {decvax,seismo,cbosgd}!decuac!avolio Well, maybe this is ancient history, and the product is nearing the end of its life, but TOPS-10, DEC's timesharing system for its largest machines (PDP-10s) was ALWAYS shipped in source form. There was no binary-only distribution. And the stuff was supported too (although if you wanted a bug report taken seriously, you had to be able to reproduce it on a vanilla system). -- Larry Campbell The Boston Software Works, Inc. ARPA: maynard.UUCP:campbell@harvard.ARPA 120 Fulton Street UUCP: {harvard,cbosgd}!wjh12!maynard!campbell Boston MA 02109
mouse@mcgill-vision.UUCP (der Mouse) (12/09/85)
Key: >>> [ Ricky Palmer / DEC / Ultrix Group / rsp@decvax ] >> [ me, see .signature for address ] > [ aps@decwrl.UUCP (Armando P. Stettner) ] > Regarding the news comment by der Mouse on whether or not Ultrix > is 4.2 or not: >>> Ultrix-32 runs on the 8600. It runs like the >>> proverbial "bat out of ...". Contact your DEC salesperson for further >>> information. >> (do I recall something about advertising being verboten?) >> [ my--uh--flame?--to the effect that Ultrix is not 4.2 omitted ] First off: I feel I must apologize to Ricky Palmer (and to the Ultrix group in general I suppose) for the uncalled-for virulence of my posting. He really didn't deserve it (well, maybe *he* did, but his posting certainly didn't). I realized this about a day later, after I'd cooled down and the article had made its way out onto the net. And I didn't know how to cancel an article (still don't, anyone out there want to enlighten me?) > Ultrix *is* 4.2 with a fair amount of work by DEC [ ... ] If you did a fair amount of work on it then it is not 4.2, it is *modified* 4.2 (as you yourself say a sentence or two later). > There > in fact should be enough stuff distributed with Ultrix so that you can > add a driver painlessly (assumming that you require no hacks in other > parts of the kernel, because there are no sources!). My main complaint (read my original). We *do* require other kernel hacks, notably in trap.c (kernel_user traps, so errors in kernel mode can be made to signal a user process instead of panic()ing) and locore.s (so we could grow the cmap struct for memory mapping--no sysV flames please!). > Further, many of > the tables and hard coded constants have been removed from the original > source modules and placed in modules that are shipped as sources so > that you (the customer) can get at them. At least you tried. > [ a paragraph and a half about how Ultrix is for business and BSD for > academia ] Exactly. I forget sometimes there is a real world out there. > Realize that there is a > seperate group within DEC with a charter to measure how quickly SPR > answers are turned around to the customer. Well, we have some outstanding VMS SPRs which are a year or two old (yes we do run VMS on one machine; a historical artifact).... Maybe the rest of the company needs to look at their measurements? (:-) > I do not believe that the attitude of myself or members of UEG is > one of "whaddya [you] want 4.2 when you can have Ultrix". I > think that you might not have had a very clear understanding of > what Ultrix is and how it would or would not fit *your* situation. I didn't say this was your attitude, or even the prevailing attitude at DEC; that was what I saw at the time in Palmer's posting. I think maybe I do have an idea of how Ultrix would or would not [the latter] fit our situation; we had a uVAXII with Ultrix on it here for evaluation, so I have some sort of idea what Ultrix is like. > I don't feel sorry for people who complain that /bin/ed is not > a good full screen editor. Point taken, though I feel it isn't quite that extreme; Ultrix does make some sort of claim to being 4.2bsd [/bin/ed doesn't pretend to be a full screen editor]. I will try to remember to cool down before posting in the future. -- der Mouse USA: {ihnp4,decvax,akgua,etc}!utcsri!mcgill-vision!mouse philabs!micomvax!musocs!mcgill-vision!mouse Europe: mcvax!decvax!utcsri!mcgill-vision!mouse mcvax!seismo!cmcl2!philabs!micomvax!musocs!mcgill-vision!mouse Hacker: One who accidentally destroys / Wizard: One who recovers it afterward
matt@oddjob.UUCP (Matt Crawford) (12/09/85)
In article <722@decuac.UUCP> avolio@decuac.UUCP (Frederick M. Avolio) writes: >But, and this is what I think Armando was getting at, if you have no >use for any of that, if you do all your own support, if your goal is >to make massive changes to the kernel (essentially voiding the >warrantee) then you might do better to go with a non-commercial >product. What operating system ever came with a warranty? Does DEC sell an operating system with any sort of warranty of correct operation? _____________________________________________________ Matt University crawford@anl-mcs.arpa Crawford of Chicago ihnp4!oddjob!matt
wedgingt@udenva.UUCP (Will Edgington/Ejeo) (12/17/85)
I'm not sure I want to get involved in this mess, but I felt I ought to, due
to the fact that we run VMS (4.2), Ultrix 1.0, *and* BSD 4.2 (not to mention
BSD 2.9) here. We have source only for BSD; Ultrix didn't come with source
(at least not at a decent price) when we got it. All three are on VAX
11/750's, though we also have a 780 (VMS). I am one of the two staff people
here that does major work maintaining and upgrading the Unix (& Ultrix)
machines. We have full field support only for VMS, though we do have full
*hardware* support on the Unix/Ultrix machines; software support was felt to
be too expensive (both before I was hired and now; I have little to do with
such decisions).
First, hardware failures are at least as common as 'system crash'-type
software failures are. Nearly all our disks are ra81s and ra80s; they have
been at the root of all hardware failures under BSD *or* Ultrix in the year
I've worked here.
Second, the two major software failures under BSD: one was indirectly due
to the large disks (sign extension); the second was due to an incorrect (at
least, to *our* kernel) bugfix from this network. Other major 4.2 bugs have
either already been fixed, don't apply to our system, or haven't shown up
here yet and we haven't ever seen them. Ultrix won't have these partly because
we don't have source and partly because DEC has learned from 4.2's failures
and fixed them already.
Third, the major device driver changes: we recently installed ethernet
(DEUNAs) between all the VAXes (even VMS, though they don't have TCP/IP yet).
Ultrix already had the driver (of course); I just had to reconfigure the system
and do the make. For the BSD machine, I got a copy of Lou Salkind's driver
(from 'der Mouse', as a matter of fact), reconfigured and did the make.
Again, the major difference was due to the fact that Ultrix could take
advantage of the time difference: it was written later. At about the same
time, we added a System Industries tri-density (800, 1600, and 6250 bpi) tape
drive (dual ported to the BSD machine and the Ultrix machine). Under BSD, I
had to make a few changes to the source to be able to write at 6250, reconfig,
and make. Under Ultrix, no source. So I copied the BSD driver over, reconfig,
slight mods to the makefile to add the driver as a source file, and a make.
NO CHANGES TO SOURCE CODE. If that's not compatibility, I don't know what is.
Only major difference: lack of source on the Ultrix machine.
Fourth, bug fixes to user programs: these are hard to do without source,
so we make the changes to the BSD machine and copy the new program to the Ultrix
machine. Every time, the *executable* from BSD has run under Ultrix without
change. Identical system directory structure and username/UID pairs has helped.
Major programs done in this fashion include tip, rpr (a locally written program
that uses tip to print a file on a printer, possibly on VMS, over our MICOM
dataswitch), and getty (autobaud changes). tip and getty, especially, show
how compatible BSD 4.2 and Ultrix are; they depend rather heavily on system
internals.
Fifth, while we are an educational institution, that has little to do with
our preference for BSD over Ultrix: no students, not even workstudies in my
department (which is *NOT* academic; it is an administrative department) have
access to any system source, VMS nor Unix nor Ultrix nor VOS nor MCP/CANDE nor
etc., etc. (We also have a Burroughs 5920, a Harris 500, and a Harris 1000).
Our preference for BSD lies primarily in the fact that we have source for it
and can therefore modify it more easily into what we require. DEC would never
write half the programs that we *must* have, with such a mix of equipment.
BSD and Ultrix are otherwise equal in our eyes.
--
Will Edgington | Phone: (303) 871-2081 (work), 722-5738 (home)
Computing Services Staff | USnail: BA 469, 2020 S. Race, Denver CO 80210
University of Denver | Home: 2035 S. Josephine #102, Denver CO 80210
Electronic Address (UUCP only): {hplabs, seismo}!hao!udenva!wedgingt
or {boulder, cires, ucbvax!nbires, cisden}!udenva!wedgingtjsdy@hadron.UUCP (Joseph S. D. Yao) (12/19/85)
In article <1441@cornell.UUCP> george@cornell.UUCP (George R. Boyce) writes: >In article <1554@decwrl.UUCP> aps@decwrl.UUCP (Armando P. Stettner) writes: >>Ultrix is not really good for academic environment where students will >>be doing thesis work on operating systems or other computer science >>activities that involve modifying existing programs. It is better >>suited to places that have less experience with UNIX or for places that >>would prefer not to maintain the staff necessary to keep up an >>operating system. >Ok, I give. Does someone care to support or attack this thesis? So far I've spent quite a bit of time fixing Ultrix so that we can use it. This is Ultrix 1.1 on a 750, not the Micro-VAX Boyce seems to have (?). The first fix was to retrofit bug fixes into hp.c so that we could use our disc drives. This was quite a task without source! We got the source, and continue to incorporate bug fixes. The DECvolken over at decuac (in lieu of other software support people -- that's not their real job) have been very willing to help, but overworked. Bottom line: from where I sit, at least, it looks like you still need source and support staff. This is n o t an opinion, it is empirical observation. -- Joe Yao hadron!jsdy@seismo.{CSS.GOV,ARPA,UUCP}
jsdy@hadron.UUCP (Joseph S. D. Yao) (12/26/85)
Even not having read the follow-ups on this, I want to make some quick comments: In article <997@udenva.UUCP> wedgingt@udenva.UUCP (Will Edgington/Ejeo) writes: > ... Nearly all our disks are ra81s and ra80s; they have >been at the root of all hardware failures under BSD *or* Ultrix in the year >I've worked here. RA drives I've worked with: no problems at all w/RA81; a few problems with one RA60; but in general OK. The main problem -- this was under the SysV machine I work with -- was verifying that my driver worked, since two drives started off not working! Once fixed, though, they seem to have stayed fixed (mostly). Admittedly, we haven't thrashed them yet. > ... Ultrix won't have these partly because >we don't have source and partly because DEC has learned from 4.2's failures >and fixed them already. 'Fraid I have to burst your bubble. If you have Ultrix 1.0 or 1.1, the source code compatibility to 4.2 goes as far as not including any of the bug fixes I'd installed, anyway. > ... Under Ultrix, no source. So I copied the BSD driver over, reconfig, >slight mods to the makefile to add the driver as a source file, and a make. >NO CHANGES TO SOURCE CODE. If that's not compatibility, I don't know what is. You're lucky. The driver I had to fix under Ultrix (hp.c) had been modified once in 1.0, then heavily in 1.1. To make it work (before we bit the bullet and got source), I had to do some reverse engineering. I even got a few things wrong: such as which printf's had been changed to mprintf's, and of course a few variable names. (Amazingly few: i and cp are universal.) For that matter, you probably did break error logging, since mprintf() is not in 4.2BSD. > ... Identical system directory structure and username/UID pairs has helped. Yes, for the most part. A major problem was uucp. (Tip doesn't suffer because it only uses the top of the uucp spool directory.) There may have been others. > Fifth, while we are an educational institution, that has little to do with >our preference for BSD over Ultrix: no students, not even workstudies in my >department (which is *NOT* academic; it is an administrative department) have >access to any system source, ... Same here. We just felt that for some things maintenance would be much easier with source. Looks like we were right so far. So with all these complaints, why did this group get Ultrix? Well, I'll tell you. It is a supported product (or will be ...) by the maker of the CPU (at least), and that is valued. Once we get up to equal speed with each other, things should be great. >BSD and Ultrix are otherwise equal in our eyes. And with 1.2, Ultrix may edge ahead. (Ultrix has some of 4.3's speed enhancements; I don't know what-all else.) -- Joe Yao hadron!jsdy@seismo.{CSS.GOV,ARPA,UUCP}