[net.wanted] Which small UNIX system would YOU buy?

dfh (03/14/83)

  Nearly every week, some new 16/32-bit microcomputer announces a
UNIX or UNIX-like operating system for their hardware.  Many of these
are small (1-4) multiuser systems, and generally cost between 9-15K.
This price range is within reach by many departments at small-medium
size universities, which is my primary concern.
  So, for all of you who have small, relatively inexpensive multiuser
UNIX systems, I have 3 questions:

1)  What system do you have, and why did you pick it?

2)  What system would you buy today?

3)  What is the worst system you have seen, and why?

As always, I will compile the responses, and post to the net.

					sknahT,
					David Hinnant
					N. C. Educational Computing Service
					decvax!duke!mcnc!dfh

dfh (03/31/83)

A few weeks ago, I submitted the following query:


  Nearly every week, some new 16/32-bit microcomputer announces a
UNIX or UNIX-like operating system for their hardware.  Many of these
are small (1-4) multiuser systems, and generally cost between 9-15K.
This price range is within reach by many departments at small-medium
size universities, which is my primary concern.
  So, for all of you who have small, relatively inexpensive multiuser
UNIX systems, I have 3 questions:

1)  What system do you have, and why did you pick it?

2)  What system would you buy today?

3)  What is the worst system you have seen, and why?

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=


To which I received the following responses worthy of posting.  Thanks
to those of you who replied.

					David Hinnant
					N.C. Educational Computing Service
					(919) 549-0671
					ucbvax!decvax!duke!mcnc!tucc!ecs!dfh

=======================================================================
We have a plexsus system which is z8000 based. The biggest complaint I have
with it is that they don't take full advantage of the segmentation of the
chip. The Z8000 supports multiple segments, each of which is accessed thru
a segmentation register. To make things easy, the makers of the plexsus
decieded to use only 2 segment registers, one for data, one for text.
This limits the address space of processes to 128K.

=======================================================================



The system I would most recommend is the Onyx C8002.
Although it has a 128K I+D addressing limitation, it is pretty fast,
and quite reliable. It's been around for about 3 years now, and was
one of, if not the, first small Unix systems. The major drawback is
dealing with Onyx itself for software support. They basically can't tell
a C program from a Basic program, much less a kernal from a hole in the
wall. However, after 3 years of work, their stuff works better than any other
I've seen. By the way, the Unix port that Onyx uses was NOT done by
Microsoft, a big plus in my book. They are running system 3, which ATT
uses on their Onyxes; much cooperative work was done on the port; therefore
the Onyx system 3 stuff is really and truly system 3. The C8002 is a little
more expensive than most, about 17K I think.

As for the worst system I've seen, there is no doubt in my mind that it
is the Zilog system. The major problem is the atrocious C compiler that
they have come up with. Trying to be clever about register usage and
argument passing, they have made it very difficult to move C code that
runs on any other machine I've tried to the Zilog, and have it work.

=======================================================================


	In the $10K range I bought an "old" 16 bitter called an 11/23 and
put Western Electric Unix V on it, plus an additional $2K for VENIX.
After all, for $800 your entire school (!) can get the System V license
and software, so the incremental cost is zilch.  VENIX is an enhancement
which allows me to do data acquisition in real time while servicing normal
multiuser requests in parallel.


=======================================================================


we have tried both the pixel and the fortune.

pixel:
	the unix that is delivered with the computer is a full set.
        ( cc, csh, vi ... through rogue 3.7 )

        the hardware seems quite solid, we had a demmo unit for 2 weeks
        with no problems of any sort, includeing no non power related
        crashes.

        the pixel terminal & its keyboard are the shittyest i have ever
        (in 18 years of computers )  worked with.

        we are recomending this computer to a number of sites here at
        harvard and elsewhere.

        we have found only two problems with the software
             A/ df does not list the root file system

             B/ uucp does not work to our 11/44. ( this seems to be
                a problem with microsoft ports, the fortune has the
                same problem )

fortune:
       the unix delivered was a SMALL subset of what i

guy (03/31/83)

A couple of comments for the respondees:

1) Re: Zilog - another annoyance is their habit of changing things for the
sake of change.  Our (pre-release, admittedly) Zeus 2.2 DOES NOT HAVE A
"UMASK" COMMAND IN THE BOURNE SHELL!  Instead of "umask nnn", you say
"set umask = nnn"; much more user-friendly, no?  Why didn't they do something
like changing "umask" so that you can give "chmod"-like values to it instead
of making useless changes to the syntax - which make existing shell files NOT
WORK?  (They probably would have done it to the C shell, too, except that
"set umask = nnn" already sets the variable "umask" to "nnn".)  They also
borrowed Berkeley's idea of /etc/ttytype - a good idea (who wants to have to
tell UNIX what kind of terminal they're on every time they log in?) - but
they they screw it up by limiting the terminal type to two characters!
Furthermore, their clever calling sequence CAN'T BE DISABLED WITH A COMPILER
OPTION, which makes "adb" next to useless.  Plus, when they added "curses",
they did an excellent port, except they forgot that the "*printw" routines
take a variable number of arguments and have to be changed to work on Zeus...

2) Re: System V on an 11/23 - real live System V kernel, IPC, shared memory,
semaphores and all?  Bell sort of half-heartedly supported System III on
non-separate-I&D machines (it was basically the V7 support with: disk buffers
out of kernel address space, and the U page copied on context switches instead
of map - sure, it saves address space, but I hope it doesn't do very many
context switches), but System V was a good deal bigger and they claimed only
to support 11/45s and 11/70s (not even 11/44s - USG UNIX uses the second
register set, which 11/44s don't have, but you could easily change it not to,
at the cost of making some of the copy routines a bit slower; does anybody know
whether the second register set makes a significant difference?).  The "correct"
solution is probably to use an overlay scheme (for a lot of PDP-11 work, I
think the lack of any overlaying is the biggest problem with UNIX) for the
kernel and user code; the HCR overlaying scheme for V7 will probably work for
USG UNIX as well - it uses a separate stack for the overlay stack, so it
requires no change to the C stack frame. Did you get such a kernel or roll
your own?  (For that matter, I thought RSX-11M+ required split I&D space, too,
but I've heard claims that P/OS is based on M+, not on M, and that M+ runs
on 11/23s.  Does it no longer require split I&D space, or has DEC come out with
a split I&D space mode for the 11/23 or 11/23+?)

						Guy Harris
						RLG Corporation
						{seismo,mcnc,we13}!rlgvax!guy