From: ajayshah@almaak.usc.edu (Ajay Shah)
Newsgroups: comp.unix.sysv386
Subject: Here it is: (Was: Re: Looking for Posting on "Which 386 *nix do I buy")
Date: 26 Sep 1992 15:18:24 -0700
Organization: University of Southern California, Los Angeles, CA
NNTP-Posting-Host: almaak.usc.edu

bill@ricker.gwinnett.com (William L. Ricker) writes:

>steveh@zentronics.ca (Steve Haller) writes:
>> Would someone be kind enough to email me or let me know of a source
>> for obtaining the article describing the features/benefits, advantages/
>> disadvantages, etc of the various 386 *nix packages.

I don't know if this is the article you are thinking of, but
here is one anyway.  It was first posted a week ago, and we've got
LOTs of feedback, corrections etc.  None of that has been integrated
into this article yet.



This file is a attempt at a quick summary of the Unix options for
386 boxes.  It is not monolithic or complete; it's supposed to be
a quick first look at the field.  It is not a objective, factual
summary; instead it reflects our biases and experiences.

        - Ajay Shah (ajayshah@usc.edu)
          Shuvam Misra (shuvam@jogin.cse.iitb.ernet.in)

Commercial
----------

Unixes:
        BSD386 (by BSDI)
        Coherent
        Destiny (RSN)
        Minix
        Nextstep 486 (RSN)
        SCO Unix
        Solaris 2.0 (RSN)
        a few dozen SVR4 implementations
        a few (commercial) Mach-BSD implementations

Compatibility products:
        Desqview/X
        many X display servers running on 386
        many TCP/IP and NFS products

Free
----

Unixes:
        386-BSD
        Hurd
        Linux
        Mach-BSD

Compatibility products:
        PC-TCP
        SOSS (NFS server which takes over a PC)
        Clarkson packet drivers
        NCSA telnet/ftp



Now for a little more info for some of the above.

BSD-386 (by BSDI)
-----------------

This is a finished, commercial BSD 4.3.  It's $1000 including The
Source.  There are no conditions attached for the source.  The NFS
implementation is from an earlier PD project, don't remember which.

Coherent
--------

This is a 32-bit Unixy OS.  It runs COFF binaries which run on other
386 Unixes.  The distribution set is 6 floppies and takes <10M disk.
Kernel is 100k.  There exists a C compiler, linker, lex, yacc, awk,
make, termcap, terminfo, curses, assembler.  nroff, troff, uucp,
ckermit, ksh, sh, cron, virtual consoles, man pages.  

gcc, emacs, etc. are available by ftp (from where?)
Networking is in the works.

$100.  Mark Williams Co, 60 Revere Drive, Northbrook, IL 60062
708-291-6700

Destiny
-------

This is a SVR4.2 implementation by Univel, a company born of USL and
Novell.  It's very slick -- e.g., it boots into a GUI.

It runs DOS/Windoze binaries.  You can readily ignore the fact that
it's a Unix, and merely use it as a DOS/Windows "multitasker", a job
which it does rather well (obviously better than Windoze).

It's unbundled; there is a base package, then you can buy networking
and/or software development. You can configure it to be either Open
Look or Motif.  It knows Novell protocols.

It's parsimonious on disk/RAM -- like 60M and 4M.

Not shipping yet.  Pricing is unknown, but it's likely to be cheap.
Many clone vendors will offer to ship PCs with Destiny preinstalled.
Needs a newsgroup real soon.

Minix
-----

A small Unixalike by Andy Tanenbaum.  $150 or so buys you The Source.
There is a newsgroup comp.os.minix.

This is _NOT_ Unix. It has Unix-like commands. Its file system is not
Unix-like, its kernel is different. Its main attraction is that its
source is available in Tanenbaum's book, it is study-able in class,
and it is small enough to run on a plain-vanilla PC or XT (yes, no
virtual memory).  It has no TCP/IP, and is too small for serious large
applications, primarily because it supports no virtual memory.

Nextstep 486
------------

The NeXT OS for a 486.  It is BSD on top of Mach, with a pretty
(nonstandard) GUI to boot.  The GUI uses display postscript.
Presumably the entire software base for NeXT will quickly recompile
for NS486.

Not yet shipping. Probably needs a special graphics card.  Probably
expensive.

SCO Unix
--------

!@#$%^&~

It is a peculiar hash of brain-damaged Xenix, MS-DOG and Unix.  For
example, for a debugger, it stoops to Microsoft Codeview.  Too many of
its sysadm features and system daemons have been "customised", or
"optimised" for it to really feel comfortable for old-time Unix users.
It is neither very close to BSD, nor to AT&T (of the two, it's closer
to V.2).  Compiling PD software, even well-written GNU software, to it
often becomes a porting nightmare.  A special problem area is
networking.  It doesn't even have long filenames. It has a nonstandard
GUI, called ODT (Open Desktop) which is not X, though it must have
borrowed things from X.  A plus point: It runs some popular software,
e.g. Foxpro. (dunno how well that will work out now).

It is fast. A simple program on SCO runs faster than on Interactive
i386 (don't recall versions here).  In return, it does not scale well
to large numbers of users. Its performance for one user is very good,
but falls below the competition if say, 20 users are running.

If the above didn't convince you to keep away, consider this: the
Prince of Darkness owns a major stake in SCO.  :-)

Solaris 2.0
-----------

A 100% clone of Solaris 2.0 for the 386.  Needs CD-ROM, SCSI disks,
200M and 8M.  Does MP on compliant hardware.  A SVR4.  100% source
compatible with SPARC Solaris 2.0.  Presumably the entire applications
software base for SPARC hardware will quickly recompile for it, giving
it a unique position among 386 Unix options.

Many clone vendors will offer to ship PCs with Solaris 2.0 preinstalled.

Will it allow the concept of tftp diskless floppy-booting clients?

Not shipping yet.

Many SVR4 implementations
-------------------------

There are a dozen other companies doing SVR4s for the 386.
See Eric Raymond's book-length posting to get the dope.

(Commercial) Mach-BSD
---------------------

This has got to exist :-)  Could you write a paragraph on this?

Desqview-X
----------

This package runs on the PC.  It is a X display server.  It runs all
DOS and Windows programs by virtue of device drivers which convert
Windows calls into X calls.  Hence you can (e.g.) run a Windows binary
on a 386 controlled by dv/X and do display on any X terminal on the
network.

For the rest it's a great DOS/Windows "multi-tasker", far better than
Windows for sure.  This is a great option if you must have strong
DOS/Windows roots.

How well does it mix with a NFS?
Price?
Phone numbers?

X display servers for the PC
----------------------------

There are more than a dozen companies offering these.
Some run under Windoze (and are hence slow), others take over the
PC completely.

Could you contribute a paragraph here?

TCP/IP and NFS products
-----------------------

These products make a PC a good citizen of a Unix network.
You need a TCP/IP to do the low-level shipping.  A NFS product
will let your PC see Unix disks as G:, H:, etc.

Sun ships PC-NFS.  Beame and Whiteside (1-416-648-6556) has a good
product too, as does FTP software.  There are many others.

Typically the NFS product comes with TCP/IP and utilities like telnet
and ftp.  

But it is possible that standalone non-NFS packages i.e those which give
you only telnet and ftp, but no NFS, give you much better telnet and ftp
than those which come with the NFS packages. NCSA Telnet 2.3 is very neat,
comes with source, and is in the public domain. And it is many _times_ as
fast as the telnet program which comes with BWNFS, which costs money.

The problem is that you can't use, say, BWNFS and NCSA Telnet together from
the same PC easily. This is because BWNFS implements the TCP/IP protocol
stack using memory-resident programs which don't let NCSA Telnet function.
So you remove BWNFS first, typically by rebooting the PC. This also means
that using NCSA FTP to transfer files from a Unix system to a PC's NFS disk
is not possible, because BWNFS and NCSA FTP don't run together. So, if you
need BWNFS, you are stuck with their atrociously slow utilities.

Free 386-BSD
------------

This is a free BSD for the 386.  It does NFS and X.
Grab it from agate.berkeley.edu.  Bill Jolitz is writing a book on it.

It has a neat, small kernel, and is stable enough to run for a week or
more without crashing/hanging. It works fine with 4MB RAM and 80MB
disk.  Running X however needs 8MB RAM, and supports only vanilla VGA.
The TCP/IP implementation in this is functional, but not optimised.
This means that FTP throughput is about 5KB/sec on Ethernet, when
almost anything else gives you about 70KB to 100KB per second.

Read comp.unix.bsd. That is almost entirely Jolitz's 386BSD now.

Hurd
----

Someday, this will be the operating system produced by the free
software foundation.  It may be BSD-compatible.  It is being built on
top of Mach 3.0 as supplied by CMU.  Refer Mach-BSD below.

Linux
-----

This is a complete Unix (with X, but no networking).  Grab it from
tsx-11.mit.edu.  Read comp.os.linux. It is characterised by a very
high level of interest, hacker participation and lots of non-hacker
users.  Minimum system is 2M,10M and it will coexist with DOS on a
hard disk.

It has short filenames, virtual consoles, atmost 64M/partition, a
pretty logo.  Virtually all important PD software is available as
binaries up for ftp, including emacs, gcc, TeX, kermit, etc.

It is one of the best options if you want to quickly get a working
free Unix system right now.  Some prefer 386-BSD, and if you have
a AT&T source license, then check Mach 3.0 from CMU.

Hats off to Linus Torvalds!

Mach-BSD
--------

CMU supplies you source and binaries of Mach 2.5 and Mach 3.0 (the
current version). This is a fast, clean OS which has an API and
shell-level interface which is exactly compatible, 100%, with BSD4.3.
(CMU had started with BSD4.3 source). A lot of users in the univ world
have been using Mach 3.0 on PCs. Read comp.os.mach.  It gives you a
CThread API which allows you to write programs whose parts execute in
parallel, somewhat like what OS/2 tried to provide. CThreads in Mach
are kernel-supported, schedulable entities. Other features include
user-level code to implement network- transparent shared memory.

Catch: you must have source licenses for AT&T and BSD.

Note about licensing: CMU demands that you have AT&T and BSD source
license because they have themselves derived their code from BSD
source. But in Mach 3.0, they have separated Mach into a micro-kernel
with no Unix-specific functionality. The Unix services are now
provided as a user-state server task. This server has BSD-derived
code. So now, CMU can give you the Mach 3.0 micro-kernel source
without any licenses. But to get a full Unix-like environment, you
still need an OS server.

FSF's HURD effort is based on the Mach 3.0 micro-kernel. They are writing
their own OS servers on top, from scratch. HURD is not attempting to do
anything inside the micro-kernel; they'll pick it up as it is from CMU.

PC-TCP
------

A basic implementation of TCP/IP on PCs, is MIT/CMU's PC-TCP. This is
public domain, and implements the standard applications (telnet, ftp,
r*) but no NFS. Many other later implementations are modelled after
PC-TCP.

SOSS
----

This is a program which completely takes over a DOS PC and shows
that file system to the world via NFS.  Great for taking backups
at night, e.g.

The PC becomes an NFS server. But it has shortcomings if you want the DOS
disk to be used for Unix applications. The filenames must follow DOS
format, and the SOSS implementation crashes about about 7500 files have
been opened (not simultaneously, but at all, since SOSS bootup).

Clarkson packet drivers
-----------------------

These are drivers for a zillion ethernet cards.  I believe you can get
a TCP/IP which works with these. NCSA, FTP Soft, and most others work
on top of packet drivers. These packet drivers are low-level enough to
just hide the hardware-specific differences. The rest of the protocol
stack is outside.

NCSA telnet/ftp
---------------

This is free telnet and ftp for the PC.  It comes with it's own TCP/IP
protocol stack.

-- 
Ajay Shah, (213)749-8133, ajayshah@usc.edu