Info needed: UNIX for 286/386 machines

[Charles Hedrick]

I'm surprised not to have seen more responses to your question about
PC Unix ports.  (Actually, I'm no longer surprised.  My first attempt
to respond bombed because your list of newsgroups included one
non-existent one.)  I'm not as qualified to comment as some, as I've
had my system only for about a month, and the Microport Unix for only
a couple of weeks, but I've been fairly active at porting software,
and so have at least some basis for commenting on it.  As should be
clear from these comments, I'm really using the system as a
single-user machine.  I could do what I want to do on MS-DOS, but I
already know Unix, I'm disgusted at having a dozen different C
compilers each of which almost but not quite implements the Unix
libraries -- incompatibility with each other, I'm fed up with all the
software being shareware, and I like being able to do something else
while I'm tranferring files with kermit or compiling something.

   o Which unix and why?  How much?

I am using Microport's System V/AT.  I chose it because it was half
the price of Xenix, seemed to have at least as good a reputation, and
was likely to be a somewhat more "pure" Unix.  (The last point may not
be true for the 386, by the way, and I think that even on the 286,
Xenix has been getting closer to System V over time.  You should
depend upon responses from people with Xenix for your evaluation of
that system, not my rumors.)  From any of the standard discount
places, it is something like $169 for the system, and another $209 for
the C and Fortran compilers.  Considering that the MKS toolkit for
MS-DOS is nearly $169, and the high-end compilers are generally
several hundred dollars, this price is no problem.  (Note that the
document preparation software is not included.  It is another $150 or
so.  All three are bundled together some something like $450.  The
document preparation package is nroff, troff, ditroff, eqn, tbl, pic,
and some macro packages.)

   o How do these systems differ from 'real' unix (if there is such a
thing)

As far as I can tell, this is a very straightforward port of System V
release 2.  It is not Berkeley Unix, which in my view means that it is
not "real" Unix.  But as System V goes, it is "real".  Now and then
you'll find a minor utility that wasn't ported, but it is remarkably
complete, including system administration tools that probably don't
make sense on a PC.  In addition to generic system V, some minimal
attempt has been made to support specific features of the PC.  I
particularly like the virtual consoles.  By hitting ALT-F1 through
ALT-F4 (and I think you can raise the number if you need more) the
screen switches among 4 virtual screens.  It's very much like
switching among 4 windows on a Sun, except of course that only one is
visible at a time.  It almost compensates for the fact that System V's
csh doesn't have job control.  It is possible to access video memory
directly using the System V shared memory facilities.  (The man page
for shmcreate says how to do it.)  I've used it for writing text
directly on a monochrome screen.  I haven't tried it for graphics.
Another message in this group suggests that there may be some
difficulties there.  Note that they do not have any other real support
for graphics.  They also don't supply much support for common micro
printers.  The troff they support will print nicely-formatted output
on an Imagen printer, a CAT typesetter, or a Xerox 9700 printer, but
they don't give you much help with an Epson printer.  Of course this
is just what you'd see with "real" Unix on a VAX.

In terms of reliability, I'd compare the system with the first year or
so of our Pyramid.  (We were one of Pyramid's early customers.)  In
porting four moderate-size programs (microEmacs, Kermit [just so I run
from a version I have source to -- they supply kermit], xlisp and sc),
I ran into one or two files where the optimizer blew up.  They work OK
unoptimized.  I ran into one odd problem where microEmacs didn't
restore the terminal modes.  I was able to fix it by initializing some
fields in the terminfo struct.  I'm still not sure whether this was a
bug in uEmacs or some oddity with uport.  I ran into a problelm with
sc where the screen display looked odd, and the console was left in an
unusable state after exit.  It turned out to be a couple of bugs in
the terminfo description of the console (type ansi).  They were easily
fixed.  (I've told uport about the problem and fix.)  This is probably
a bit more trouble than I'd expect to see on a VAX or a Sun, but isn't
bad.  I've had a couple of cases where a job hangs, and only reloading
the system would free it.  (It seemed to be when it ran out of memory
or swap space.  The problem went away when I switched to a decent
malloc.)  Other jobs were usable though.  And I haven't seen any
system crashes yet.  Again, this is a higher level of odd system
behavior than I'd expect to see on a Sun, but there are many systems
in the world that are far worse, and it's well within my expectations.
Almost all, if not all, of the problems I have seen are listed in the
known bugs list that comes with the release notes.

   o Where do you get info on unix system care and feeding? Read the
manuals?

The manuals seem to be an amalgamation of the ATT System V manuals,
with some additional introductory material.  ATT has put in some work
on documentation, so Unix manuals are in general better than they were
back in the good old days of 7th Edition.  If you are an experienced
computer programmer, you can learn Unix from the manuals.  However
it's not clear that you'd want to.  If you're using it as a single
user system, there really isn't a lot of administration to do.  As it
comes out of the box, the startup files are appropriate for that
purpose.  About all you have to do is create yourself an account, set
up the printer spooler for your printer, and modify the appropriate
startup file so that lpsched gets run at startup.  They tell you how
to set up an account.  (You just edit /etc/passwd, create a directory
for yourself, and change its ownership to yourself.)  There is a
chapter on setting up printers, which gives good instructions, though
you do have to look around in a directory and figure out which "model
file" is appropriate for your printer.  That's pretty much it.  There
is a spiffy menu-driven sysadmin tool that will do all of that
automatically, if you like such things.  (I'm a Unix hacker though.
Real programmers don't use menu systems.)  Of course if you want to
run UUCP, things get more interesting.  Again, there is documentation
on what to do, but it can get a bit complex.  (I think the sysadmin
tool may even set up UUCP for you.  But even with automated help there
are going to be choice you have to make that will require some
background.)  If you're using the thing as a single-user machine, you
might prefer just to use kermit (which they supply).  While this is
all straightforward, and they supply instructions, if this was your
first exposure to computers, you might find it a bit much.  Whether it
would be any worse than trying to install and set up MS-DOS on a hard
disk is a bit unclear.  The process is probably no more complex.  Of
course if you really want to run it as a multi-user system, with
news and regular cron jobs, and all that good stuff, then you're
talking a different ball game.  Probably the thing to do is to
set it up as a simple single-user system, get a feel for it, and then
start adding complexities one by one.

   o What is a 'news feed', and how do you get one.  Do I want one?

This is a sort of odd question.  Obviously you know what news is,
since you posted your question.  A news feed is a relationship between
your computer and some other computer that feeds you news.  If you
want to have Usenet news on your PC and read it there, rather than
logging into a machine at your university and reading it there, then
you need a news feed.  If you have easy access to a university
computer, I'd read the news there.  Setting up UUCP and news, and
administering it, is somewhat complex.  Also, if you get a full set of
news, it takes lots of disk space and will use lots of machine
resources.  Finally, Microport's weak point appears to be handling
serial lines.  (This is probably not entirely their fault, but stems
from built-in weaknesses of the hardware.  The PC wasn't really
designed as a multi-user system.)  You can apparently do UUCP at 9600
baud, but not while doing anything else with serial lines at the same
time.  It used to be that exceeding the capabilities of the system
caused crashes.  Microport claims that a lot of these are fixed in
release 2.3.  I don't think the evidence is yet in on whether all of
the crashes have gone away or not, but it is clear that some
performance problems remain.  Of course if you have a single-user
system, you don't have anything else to do with your serial lines, and
this probably won't be an issue for you.  But the administrative and
resource burden is still not something to take on lightly.

   o What are basic system requirements?

Microport says you need at least a 17MB disk partition and 512K of
memory.  I think the 512K of memory is intended as a joke.  Presumably
you can boot the system in it, but I wouldn't try to execute any
commands.  (Note that Microport doesn't seriously advise anybody to
use it on a 512K system.  I asked them over the phone whether their
system would work on a 640K machine.  The answer was "well, yes, but
it will be beastly slow.")  I ran for a week with 1M of memory.  It
swapped a bit more than you'd like, but as a single-user system was
livable.  My main problem was reading big files into microEmacs, but I
later found out that this was because the supplied malloc is
substandard.  I'm now using a tuned malloc, and I think Emacs would
probably work OK in a 1M system now.  Compilations would still be slow
though.  I'm now using 1.5M.  It seems to work fine as long as you
don't try to do lots of memory or disk-intensive things at once.  Most
of the swapping caused by compilations seems to have gone away with
the step up from 1 to 1.5M, though I get the feeling that another .5M
might make some marginal difference.  (Probably relinking the compiler
with a decent malloc would be a better solution, but of course I can't
do that.)  That is, while I'm doing a compile I could be editing a
file or maybe looking around with ls, but I wouldn't want to be doing
much else.  I've heard recommendations as high as 2MB for the system
and 1MB for each user, and 4MB machines are common among people who
like to run Xenix or Unix.  But for my purposes, I don't plan to go
above 1.5M.  Probably 17MB is enough for somebody who isn't going to
have many large files.  I use a 25MB partition, and it looks like it's
going to keep around the sources to a number of public-domain Unix
programs and the smallish things that I'm working on.  Of course if I
were using it for database work, or keeping records of a company, I'd
need more space, but that's obvious.