DEC is dishonest - ULTRIX is not UNIX

[karl at grebyn.UUCP]

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 at isif.arpa
UUCP:	...!{decuac, seismo, vrdxhq}!grebyn!karl
I don't need a disclaimer since I own the company.