steiny@scc.UUCP (Don Steiny) (06/17/86)
** As a software developer that develops software for UNIX I am a bit ticked off at DEC. They claim that ULTRIX is 4.2BSD, or at least 4.2BSD compatible. They tell their customers that and they tell their sales people that. Now, if I write a program, and it runs on 4.2bsd. What should happen if I compile the source on ULTRIX? It should run right? The only reason it would not run is because my software is no good right? Well, iff it were true that ULTRIX were 4.2bsd compatible that might be true. In sys/acct.h the ac_etime field is float on ULTRIX and and time_t on UNIX (including 4.1bsd, 4.2bsd, version 7, system III, system V). In sys/acct.h the ac_utime and ac_stime fields are float on ULTRIX and comp_t on UNIX. The data types are not even close. Since that adds 4 bytes to the 24 byte accounting record, the /usr/adm/acct file grows 16% faster than on UNIX. To cap off this, DEC wants to CHARGE me to use one of their machines to port my software. HP, Sun, and Pyramid besides having machines that can run circles around DEC machines, were cooperative, polite, and helpful. They gave me accounts on a machine. Zilog was also very helpful, even Intel was helpful. Further, all of the ports, Sun, Pyramid, HP, Microport on Intel, and Zilog took a matter of hours for me to port my software to. I have been fighting with ULTRIX for two days and just keep discovering other bizarre inconsistancies. I have had considerable experience now with various ports and ULTRIX is without a doubt the worst. It is not even close to UNIX. I have never heard anything from any DEC person but how terrible UNIX is. It looks like they are trying to prove their point by passing off a junk operating system as UNIX and then saying "see we told you so." -- scc!steiny Don Steiny @ Don Steiny Software 109 Torrey Pine Terrace Santa Cruz, Calif. 95060 (408) 425-0382
karl@grebyn.UUCP (06/18/86)
I'll probably show my ignorance in a number of places here, but what the heck. > ** > > As a software developer that develops software for UNIX > I am a bit ticked off at DEC. > > They claim that ULTRIX is 4.2BSD, or at least 4.2BSD > compatible. They tell their customers that and they > tell their sales people that. I have moved tons of software over without any changes. A significant amount of which I have brought over in BINARY form. > > Now, if I write a program, and it runs on 4.2bsd. What > should happen if I compile the source on ULTRIX? It should run > right? The only reason it would not run is because my software > is no good right? Well, iff it were true that ULTRIX were 4.2bsd > compatible that might be true. > > In sys/acct.h the ac_etime field is float on ULTRIX and > and time_t on UNIX (including 4.1bsd, 4.2bsd, version 7, system III, > system V). In sys/acct.h the ac_utime and ac_stime fields are > float on ULTRIX and comp_t on UNIX. The data types are not even close. > Since that adds 4 bytes to the 24 byte accounting record, the > /usr/adm/acct file grows 16% faster than on UNIX. And note that the accounting is broken in 4.1bsd, 4.2bsd, and probably some of the other as well (if my memory serves me correctly). Furthermore, if you don't mind, here's my /usr/include/sys/acct.h (from a uVAX II, running 1.1). What version of Ultrix are you running? If you have floats for these things, I might presume you have a copy of Ultrix 1.2, which is based upon BSD4.3, in which I believe the accounting is changed to allow a finer granularity of accounting than seconds (a second of CPU time on a uVAX II is a lot of time, and not being able to bill for the "less than 1 second" of CPU means a lot of lost revenues!) /* acct.h 6.1 83/07/29 */ /* * Accounting structures; * these use a comp_t type which is a 3 bits base 8 * exponent, 13 bit fraction ``floating point'' number. */ typedef u_short comp_t; struct acct { char ac_comm[10]; /* Accounting command name */ comp_t ac_utime; /* Accounting user time */ comp_t ac_stime; /* Accounting system time */ comp_t ac_etime; /* Accounting elapsed time */ time_t ac_btime; /* Beginning time */ short ac_uid; /* Accounting user ID */ short ac_gid; /* Accounting group ID */ short ac_mem; /* average memory usage */ comp_t ac_io; /* number of disk IO blocks */ dev_t ac_tty; /* control typewriter */ char ac_flag; /* Accounting flag */ }; ... > To cap off this, DEC wants to CHARGE me to use one of > their machines to port my software. HP, Sun, and Pyramid > besides having machines that can run circles around DEC machines, > were cooperative, polite, and helpful. They gave me accounts > on a machine. Zilog was also very helpful, even Intel > was helpful. Further, all of the ports, Sun, Pyramid, HP, > Microport on Intel, and Zilog took a matter of hours for me > to port my software to. I have been fighting with ULTRIX > for two days and just keep discovering other bizarre > inconsistancies. When I was employed at Verdix Corp., we regularly went over to the Digital Ultrix Application Center in Landover, MD, and performed validations of our Ada compiler on some of their hardware (785 on down at the time) and Ultrix Operating System AT NO COST. ( We also happened to own half a dozen Vaxen, running 4.2BSD, by the way.) If you can find the right people in the right places who are interested in what you are doing, you can usually get free help. If you can provide them with something that they want, you can play the "I'll scratch your back, you scratch mine" game. Some other companies loaned us hardware, while others even PAID US for the privilege of porting our software to their hardware. It might be dependent upon how interested they are in getting your software running on their machine. > I have had considerable experience now with various ports > and ULTRIX is without a doubt the worst. It is not even close > to UNIX. I have never heard anything from any DEC person but > how terrible UNIX is. It looks like they are trying to prove their > point by passing off a junk operating system as UNIX and then > saying "see we told you so." But for you to take this sort of attitude would make it very hard for them to try and help you, knowing that all they're going to get is bitching. -- -- Karl -- DDN: nyberg@isif.arpa UUCP: ...!{decuac, seismo, vrdxhq}!grebyn!karl I don't need a disclaimer since I own the company.
matt@uwvax.UUCP (Matthew J. Thurmaier) (06/18/86)
In article <661@scc.UUCP>, steiny@scc.UUCP (Don Steiny) writes: > ** > They claim that ULTRIX is 4.2BSD, or at least 4.2BSD > compatible. > > In sys/acct.h the ac_etime field is float on ULTRIX and > and time_t on UNIX (including 4.1bsd, 4.2bsd, version 7, system III, > system V). In sys/acct.h the ac_utime and ac_stime fields are > float on ULTRIX and comp_t on UNIX. > What version of ULTRIX are you running? At the University of Wisconsin, we are running 1.3 on MicroVaxII's and it is VERY compativle with our 4.3Betta and 4.2 releases. I did a "grep ac_utime /usr/include/sys/acct.h" and it showed "comp_t ac_utime; /*...*/". Of course the comment was there. Perhaps you got a bad or out-of-date version of ULTRIX? Don't get me wrong, I don't normally defend corporate giants, but I think you are to quick to judge in this case. At U of W, we keep ALL of our source on 1 750 and compile and distribute it to our (~100+) vaxen with NO problems. > scc!steiny > Don Steiny @ Don Steiny Software > 109 Torrey Pine Terrace > Santa Cruz, Calif. 95060 > (408) 425-0382 Matthew J. Thurmaier U of Wisc - Madison, Computer Systems Lab ...!{allegra,harvard,ihnp4,seismo}!uwvax!matt matt@rsch.wisc.edu "why am I ALWAYS going somewhere?" >>-matt-->
faustus@ucbcad.BERKELEY.EDU (Wayne A. Christopher) (06/18/86)
In article <661@scc.UUCP>, steiny@scc.UUCP (Don Steiny) writes: > As a software developer that develops software for UNIX > I am a bit ticked off at DEC. ... > In sys/acct.h the ac_etime field is float on ULTRIX and > and time_t on UNIX (including 4.1bsd, 4.2bsd, version 7, system III, > system V). In sys/acct.h the ac_utime and ac_stime fields are > float on ULTRIX and comp_t on UNIX. The data types are not even close. > Since that adds 4 bytes to the 24 byte accounting record, the > /usr/adm/acct file grows 16% faster than on UNIX. ... > I have had considerable experience now with various ports > and ULTRIX is without a doubt the worst. It is not even close > to UNIX. I think you're picking a bad example. Just because an accounting program won't run on Ultrix and will on 4.2, it doesn't mean that Ultrix isn't Unix. First, Ultrix is following 4.3 pretty closely, so if there are incompatibilities they are most likely 4.2 / 4.3 differences. Second, I routinely move binaries and source between 4.3 machines and Ultrix machines, and I have yet to find any real incompabilities. I think DEC did a very good job in their port. After dealing with "UNIX" ports like HP-UX I appreciate a sensible approach like that of DEC. The tone of your article makes me seriously doubt that you have had "considerable experience" with anything at all. Try and think a bit before posting ravings like this to the net. Wayne
grr@cbmvax.cbm.UUCP (George Robbins) (06/19/86)
In article <661@scc.UUCP> steiny@scc.UUCP writes: > They claim that ULTRIX is 4.2BSD, or at least 4.2BSD >compatible. [ much confused and emotional ranting follows...] > >scc!steiny Don Steiny @ Don Steiny Software You seem to be confused - Ultrix 32 is BSD4.2 compatible, I'm sitting here using it. Perhaps you were using the pdp11 flavor which is something else altogether. Please do your homework before making a fool of yourself. -- George Robbins - now working with, uucp: {ihnp4|seismo|caip}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@seismo.css.GOV Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)
jso@edison.UUCP (John Owens) (06/23/86)
In article <661@scc.UUCP>, steiny@scc.UUCP (Don Steiny) writes: > They claim that ULTRIX is 4.2BSD, or at least 4.2BSD > compatible. They tell their customers that and they > tell their sales people that. > > [ flames about changes in the accounting structures ] > > I have had considerable experience now with various ports > and ULTRIX is without a doubt the worst. It is not even close > to UNIX. I have never heard anything from any DEC person but > how terrible UNIX is. It looks like they are trying to prove their > point by passing off a junk operating system as UNIX and then > saying "see we told you so." > > scc!steiny You've got to be kidding. (But obviously you're not.) First, you have to understand that the accounting structures have traditionally been very neglected in UNIX. So much so, that they really aren't very useful in 4.2BSD. A second of CPU time is much too granular on a VAX to mean very much. DEC, in adapting 4.2BSD plus various other Berkeley improvements into Ultrix, wanted to make a reliable commercial product. This included such *enhancements* as porting a "good" VMS Fortran compiler, and improving the accounting structure a great deal. (I think some of the accounting work was done for 4.3BSD, but I'm not sure.) I think that's worth breaking one in a thousand programs that use the accounting structure. In any case, I would hardly think an incompatibility like that would make it "not even close to UNIX." What about 4.2 vs. SysV? v7? SysVr1 vs SysVr2 vs SysVr2v2 vs SysVr3? If all those are UNIX, certainly Ultrix is! I hope Fred Avolio responds to all this.... John Owens @ General Electric Company (+1 804 978 5726) edison!jso%virginia@CSNet-Relay.ARPA [old arpa] edison!jso@virginia.EDU [w/ nameservers] jso@edison.UUCP [w/ uucp domains] {cbosgd allegra ncsu xanth}!uvacs!edison!jso [roll your own]