Path: utzoo!mnetor!uunet!husc6!bloom-beacon!athena.mit.edu!wesommer
From: wesommer@athena.mit.edu (William Sommerfeld)
Newsgroups: comp.unix.wizards
Subject: Re: Help us defend against VMS!
Message-ID: <3610@bloom-beacon.MIT.EDU>
Date: 9 Mar 88 22:40:45 GMT
References: <867@unmvax.unm.edu> <249@lexicon.UUCP>
Sender: daemon@bloom-beacon.MIT.EDU
Reply-To: wesommer@athena.mit.edu (William Sommerfeld)
Organization: Massachusetts Institute of Technology
Lines: 62

In article <249@lexicon.UUCP> rk@lexicon.UUCP (Bob Kukura) writes:
>In article <867@unmvax.unm.edu> mike@turing.UNM.EDU (Michael I.
>Bushnell) writes:
>
>> Now, we all know that Ultrix isn't really UNIX, and that it probably
>> should be thrown out the window, but ...
.
>Why is Ultrix not really UNIX?

Ultrix 1.1 and 1.2 were pretty much vanilla 4.2 and "4.2 1/2" BSD.

Ultrix 2.x contains a large number of really gratuitous changes, and
still doesn't include things from 4.3BSD (such as the use of the
domain name resolver instead of host tables) which are an _absolute
necessity_ for large networked environments.

Source code is difficult to obtain, and (a) doesn't always correspond to
the binaries they ship and (b) doesn't always correspond to a working
version.

The way they implement the "clean" bit in filesystem headers is
incompatible with Berkeley 4.3.  There is an unused "fs_clean" bit
allocated in the Berkeley FFS superblock.  Instead of using this, they
used the "fs_fmod" field.  As a result of this, if you mount an Ultrix
2.0 filesystem read-only on a BSD system, the BSD system will panic in
about 30 seconds with "rofs mod".  

This may not seem to be a major issue to some people, but it was to
us.

There are some really gross modularity violations; in particular, if
you try to mount a "dirty" filesystem before running fsck on it, the
_KERNEL_ prints a message on the controlling terminal of the process
doing the mount system call, telling the user to 'run /etc/fsck'.
What happened to error codes?  C'mon guys, it would have been much
better to just fix the error returns from the mount system call so
that you can figure out the difference between "nonexistant device"
and "file system dirty" and "superblock has bad magic number" and ...

The kernel is _huge_, about twice the size of the 4.3BSD+NFS kernel
which we use.  DEC doesn't care that they added 100KB to the size of
the kernel just to support asymmetric multiprocessing.  And DEC
doesn't care that you need at least 3 MB of memory to run it: they're
in the business of selling memory upgrades, too.

Never mind.  If DEC doesn't throw out the VAX architecture, they're
going to be out of business in a few years, anyway.  

Athena looked at Ultrix 2.x, and ditched it in favor of 4.3+NFS (the
University of Wisconsin port, specifically) because it was too buggy
and too hard to fix.

We haven't had any real trouble with field service, but then we've got
a DEC field service engineer on-site pretty much full time; he has
been "educated" to deal with our systems.  We also have sufficient
clout with DEC to be able to correct some of their misconceptions.
Athena finally got the Ultrix 2.0 source after Paul Grey (president of
MIT), complained to Ken Olsen (president of DEC) that DEC was getting
in the way of Athena by stalling the licensing negotiations.

				Bill Sommerfeld
				MIT Project Athena.