Tech Insider					     Technology and Trends

			      USENET Archives

Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!mcvax!botter!ast
From: (Andy Tanenbaum)
Newsgroups: comp.sys.amiga,,,comp.sys.mac
Subject: MINIX - From the mouth of the horse
Message-ID: <>
Date: Thu, 8-Jan-87 18:11:03 EST
Article-I.D.: botter.1026
Posted: Thu Jan  8 18:11:03 1987
Date-Received: Fri, 9-Jan-87 02:45:09 EST
Reply-To: (Andy Tanenbaum)
Distribution: world
Organization: VU Informatica, Amsterdam
Lines: 255

I have just learned of quite a discussion going on in comp.sys.atari about
porting MINIX to the Atari.  For all I know a similar discussion is going on
in comp.sys.amiga and elsewhere.  I am cross posting this to several groups
in case there are people there who are interested in porting MINIX to their
machine.  If you missed the original note in mod.os.unix, I have just written
a UNIX clone that is available now with all the SOURCE CODE for $79.95 from
Prentice-Hall.  There is also a book telling how it works inside.
I suggest that subsequent discussion go on in to avoid 
scattering it all over the place.  At the very least, crosspost comments to under the subject MINIX. Later, we can set up comp.os.minix
if there is enough interest.

Read the comp.sys.atari group under the heading Forwarded for the last 2 weeks
to get the background for this note.

Although MINIX is copyright (not licensed), Prentice-Hall has agreed to permit
people to make a LIMITED number of copies for educational use, home study etc.
Posting the source code on the network (54K lines of C, kernel+utilities) is a
no no, but if each purchased copy doesn't generated more than say, 2 or 3 
copies it is ok. While this is not public domain it is a lot better than Lotus,
Microsoft, Borland, and every other software company in the world's policy.

About the pricing.  It is clearly not shareware, but by publishing the
source code on diskette, we are clearly not acting like AT&T either.
I had some discussion with people like Brian Kernighan (author of
the Software Tools package) and Doug Comer (author of Xinu, a little
embedded operating system for the LSI-11, although not really UNIX
like) and came to the following conclusion.  I would like to see MINIX become
widespread, so the distribution mechanism is crucial.  Having a major
publisher like Prentice-Hall advertise it, bring it to shows, send out
junk mail, etc. will get it a lot more attention than a note on the
net.  Getting a commercial publisher like Prentice-Hall interested means
charging something.  I think in the long run, this funny, copyrighted
but not real aggressive position we are taking will cause MINIX to become
widespread, new software to be made for it, etc.  The GNU people are
upset because deep in their hearts they, too, know that people would rather
pay a reasonable price for good stuff than get empty promises for free.
Does anyone know how much GNU charges for its "free" software for the tape,
postage, handling etc?    Berkeley generally charges something like $125
for its tapes, as I recall.  If GNU also charges $125 for its "free" software
it seems to me that their moral indignation at Prentice-Hall's outrageous
$79.95 price is somewhat weakened.  I mentioned MINIX in netnews last year
and I got quite a few reactions.  I have also contacted lots of people for
various reasons.  With two exceptions, everybody congratulated me and wished
me good luck.  Some people, especially Martin Atkins, Charles Forsyth, and
Richard Gregg gave me a lot of help, for which I am grateful.  Only two
people were really negative, almost bitter--both from the Free Software
Foundation (names withheld because I don't believe in character assassination
on a world-wide network).  I am tempted to comment further, but I won't.

As to the port to the Atari/Amiga/etc as far as I see, there are no technical
problems with the MMU.  The trouble is as follows.  When you fork, the
child has to go somewhere else in memory than where the parent was.
Unfortunately, the child's stack contains absolute addresses, such as
the return from the fork routine.  If the child runs somewhere other
than where the parent was, it will crash.

There are a couple of solutions, the simplest of which is this.  When the
child is created, record in the process table where the parent was.
When it is time to run the child, just swap the parent and the child,
and actually run the child where it belongs.  When the parent wants to
run, swap them again.  Although this sounds horrendous,  it is not at all
so bad.  Swapping two 10K programs in memory might take 30 millisec.
MINIX programs are small.  I am a strong believer in Small is Beautiful.
At the end of this note you will find the sizes of the MINIX utilities.
The only big ones are the compiler passes, cpp, cem, opt, cg, and asld.

Furthermore, 99.9% of the time, the child does an EXEC, at which point the
operating system can put the parent back where it belongs, and put the
new core image anywhere in memory.  In practice, all this trick will
cost is about two copies of the forked core image, and it doesn't require
modifying the compiler. My experience with fragmentation is that it is not bad.
MINIX doesn't swap because one of the design goals was to have it run on CHEAP
hardware (meaning a 256K PC with 1 floppy disk) and floppies are not ideal as
swapping devices.

The MINIX memory management scheme is very simple, because the PC's hardware
is primitive.  A core image consists of the text, the data, a gap, and then the
stack, growing downward.  The stack and the data segments grow into the
gap.  If they meet, BOOM!  In practice, very few programs have wildly
growing stacks or data segments.  I ran some statistics once, and for 90%
of the MINIX utilities, 2K stack is plenty.  On the PC, the text is limited to
64K, and the data + stack is also limited to 64K.  On a 68000, there would
be no need for such a limit.  It comes from the 8088 architecture.
All you have to do is change a couple of constants in the memory manager.

The book is already out.  You should be able to order it at any book store.
The title is Operating Systems: Design and Implementation.  The software 
will be out in three weeks.  It went into production about three weeks ago,
and it takes about six weeks.  Don't ask me why.  Probably the same reason
as why it takes Prentice-Hall 18 months to produce a book from the finished
manuscript (unless you give them camera ready copy, as I do).  If you want to
get the software (either on PC diskettes or 9 track tape), first order the book
and then send back the business reply card (software order form) in the book.

I would like to see a MINIX version for the Atari/Amiga/etc.  The 68000 is
clearly much better than the 8088, but the PC has a lot of software going for
it.  Maybe a tolerable UNIX clone might help the Atari/Amiga/etc in its fight
against the monster from 8088-land.  A colleague of mine at Philips has
already started to port MINIX to the Atari.  He is an absolutely top rate
programmer, but he is VERY busy, so he doesn't have much time.  I think he
has already rewritten the MINIX assembly code (low level interrupt
handlers, etc) for the 68000.  I will check with him one of these days; he
seems to be away right now.  What I would like to find is someone who:

(1) knows the Atari (Amiga, Macintosh, etc) hardware well 
(2) knows UNIX well on the outside and moderately on the inside
(3) has a substantial amount of free time
(4) has access to an IBM PC for testing things etc.  (not essential, but helps)

Perhaps such a person could do the port with a little assistance from me.
Unfortunately I don't have much time either, as Prentice-Hall is bugging me to
revise a book on networks I wrote a million years ago.

The main things to do, other than the 68000 assembly code, are the device
drivers, all of which are in C, but of course are totally different for
the PC and Atari etc.  The PC version doesn't use the BIOS at all, because the
stupid thing doesn't use interrupts.  When you start a background job up
and then start up the editor in the foreground, calling the BIOS to read
a character would put the whole computer in a tiny loop sitting and waiting
for the keyboard to produce a character.  MINIX supports the full UNIX
multiprogramming, so I had to write all the drivers from scratch (in C).  I 
suspect that the Atari BIOS isn't any better, although maybe we could use the
screen output BIOS.

And here we come back to the $79 again. If the person doing the port does a
good job, Prentice-Hall could sell the other version on diskettes, source code
and all, for the same $79 as the PC version.  I have enough clout with P-H
that I think I could arrange that.  Needless to say, the person doing the
port would be remunerated for his efforts, probably in the form of a royalty
on each disk set sold.  The royalty is typically only a couple of dollars,
but that small amount is why capitalism works and socialism doesn't.

If anyone is interested, let me know.  I don't think it will be that difficult,
but you have to plow through much of a very tightly written 719 page book and
understand a 12,000 line program before you can even start, so it will no doubt
be months of work.  Also, debugging operating system code on a bare machine
even a relatively nice one like the 68000, will be a fair amount of work.

One other point is the compiler.  The compiler is based on ACK, which is 
described in Communications of the ACM, Sept. 1983, pp. 654-660.  ACK is a big
system for writing compilers.  It is being distributed by UniPress in Edison
NJ and Transmediair in Utrecht, Holland.  It uses the old UNCOL idea of having
front ends that generate a common intermediate code and then back ends that
compile from that code to the target machine.  At present we have front ends
for C, Pascal, Modula 2, Basic, Occam, and even a subset of Ada. There are back
ends for virtually every micro around, from the 6502 to the 68020.  The ACK
software is owned by the university I teach at. UniPress pays them a royalty on
each copy they sell (academic price is $995 for a source tape containing 6
megabytes, although Modula 2 and Occam aren't on the tape yet).  Our department
doesn't have much money, and we use the royalties to allow grad students to go
to conferences and the like.  For these reasons the compiler kit is not part
of MINIX.    Furthermore even the 8088 C compiler source by itself fills 4
diskettes.  If the compiler source were in the MINIX distribution, that would
have meant raising the basic price to over $100, very much against my idea of
keeping the price low. I personally wrote MINIX in my spare time, which is why 
it doesn't have to follow the same rules as ACK.

Nevertheless, the source of the 8088 MINIX C compiler is available
as a separate package from UniPress.  I suspect that the easiest way to get
a 68000 C compiler is for someone at a university to have their university buy
the ACK tape and use that to develop the 68000 compiler.  When it is done, it
will be necessary to negotiate a deal with UniPress to allow it to be sold,
but I know Mark Krieger, the president of UniPress, and he is a reasonable guy,
so I am sure some deal can be worked out that won't raise the price too much.
He is on the net (m...@unipress.uucp) if you have questions about all this.

The reason that I think this route is the easiest, is that ACK already has a
backend for the 68000, so there isn't much work to be done, but you really
need a VAX or a SUN or something like that to bring up the full ACK development
system.  The compilers that are produced aren't so big, but the compiler-
compilers, and backend generators and the other meta-software doesn't really
fit easily on a PC.  In addition to the 6 megabytes of source code on the
tape, you have to count on at least 20 megabytes of object files and working
space to compile everything.  The 68000 compiler has been running for years
and it is pretty good.  We recently rewrote the backend table for the
68000, 68010, and 68020 and the code quality seems very good (about 15% better
than the C compiler Motorola sells).  I haven't even thought about using the
Pascal, Modula 2, Basic etc. front ends because I wanted the system to fit on,
and be able to recompile itself on a system without, a hard disk.  This
succeeded.  Technically there shouldn't be any big problem with the other
front ends.  Note that UniPress has TWO packages: 8088 MINIX C compiler, and
full ACK.  The former is 4 diskettes; the latter is 6 megabytes on a mag tape.

Andy Tanenbaum (, or in emergencies, m...@vu44.uucp)

Sizes of the MINIX commands

  Program  Text  Data   Bss  Total   (all sizes in decimal bytes)
    sync:   424    20    26    470
     clr:   714    28   156    898
  update:   836    42    58    936
   sleep:   848    58    58    964
      ln:  1070    86    74   1230
   chmod:   984    98   156   1238
basename:  1060    66   156   1282
     tee:  1228    82    94   1404
    kill:  1240    78   156   1474
  umount:   782   758    26   1566
   touch:  1348    76   156   1580
     sum:  1438    84   156   1678
   mknod:   930   738    26   1694
   mount:   890   782    26   1698
     pwd:  1546    84   172   1802
   mkdir:  1656   158    58   1872
   split:  1656   132   130   1918
     rev:   886    42  1052   1980
   rmdir:  1802   196   188   2186
     cat:  1212   722   540   2474
      mv:  2444   244    58   2746
    echo:   648    24  2076   2748
    stty:  2336   260   170   2766
      rm:  2468   276    30   2774
      df:  2030   948   156   3134
    time:  2584   666   266   3516
     lpr:  1314   126  2114   3554
    comm:  1822   104  2400   4326
      tr:  1470    82  2852   4404
   login:  3376  1436    28   4840
   chmem:  3178   278  2074   5530
    size:  3102   232  2208   5542
     tar:  4010   456  1774   6240
    head:  2762   168  3484   6414
      wc:  4460   208  2104   6772
      su:  3548  1498  2076   7122
      dd:  4966   532  2148   7646
   chown:  3522  2148  2074   7744
    date:  5338   412  2104   7854
      od:  5388   288  3654   9330
  passwd:  4976  1764  2620   9360
      pr:  5776   514  3110   9400
    sort:  6404   694  2490   9588
    grep:  6740   694  2208   9642
    uniq:  4956   850  5150  10956
      cc:  4404   826  5986  11216  4404   834  5986  11224
    gres:  8496   768  2076  11340
    tail:  4550   184  7200  11934
      ar:  4900   488 11350  16738
    mkfs:  8708   906  7376  16990
    roff: 12742   820  4710  18272
      cp:  1914   876 16412  19202
    make: 15216  1976  3614  20806
    shar:   980    82 20506  21568
     cmp:  3372   224 18468  22064
 dosread:  7440  3688 11992  23120
   mined: 15680  2198  5308  23186
      sh: 21536  1668  1310  24514
      ls:  7164   584 17994  25742
     cpp: 16896  3764  8580  29240 (Pass 1 of the C compiler)
    asld: 14048  7882  7412  29342 (Pass 5 of the C compiler)
     opt: 16400  9368  9494  35262 (Pass 3 of the C compiler)
      cg: 24816 22968 10520  58304 (Pass 4 of the C compiler)
     cem: 59856 10656  3164  73676 (Pass 2 of the C compiler)

Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!mcvax!botter!ast
From: (Andy Tanenbaum)
Subject: MINIX
Message-ID: <>
Date: Sat, 10-Jan-87 17:33:17 EST
Article-I.D.: botter.1028
Posted: Sat Jan 10 17:33:17 1987
Date-Received: Sun, 11-Jan-87 02:41:40 EST
Reply-To: (Andy Tanenbaum)
Distribution: world
Organization: VU Informatica, Amsterdam
Lines: 70

First, I would like to apologize if I over-crossposted.  I haven't posted much
to the net before, so I may have done things wrong.  I was under the impression
that if one sends to multiple groups it cross posts them in such a way that
each reader only gets the message once, even if the reader subscribes to all 
of them.  If I am wrong will somebody please tell me how to do it (by mail).
It is also possible that I messed up.  Furthermore, we were having news and
mail problems at the time, which may have contributed.    It was my intention
that a lot of people see it once, not that a few people see it many times.

As to being commercial, that's true I guess, but since I am supplying 50,000
lines of source code without copy protection  for $79, and I don't mind a 
limited amount of copying of the binary and source code, it is not in the same 
league as normal PC software in terms of the owners zealously guarding both 
binaries and sources.  In fact, it is probably somewhat closer to the Free 
Software Foundation's way of doing things (also copyrighted) than to Lotus.  
I assumed (and judging by the response, probably correctly) that there would be
a fair amount of interest.  Sorry if I offended people.  

Maybe it would be best to set up comp.os.minix now.  Will everyone who would
want to subscribe to it send me mail.  If there is a sufficient number, I
will ask the local guru how one sets up a new group and try to avoid messing 
that up too.  I will cross post this to various groups, but just stick to or comp.os.minix (depending on the reaction) in the future.

Several people have asked me questions whose answers may be of general interest,
so I will post them here.

Q1: Can you have multiple users on a PC?
A1: In theory yes.  The terminal driver has an array indexed by terminal
    number from 0 to some maximum.  At present that maximum is 1, so you
    have to change a constant and recompile the tty driver.  Also, there
    is no RS232 driver (the deadline had a race with RS232 and the deadline
    won).  Therefore such a driver has to be made, but it is quite simple.
    Most of the hooks and handles you need are already there, for example,
    when it is time to output a character on tty n, the driver calls a
    function pointed to by tty_struct[n].tty_devstart, so each terminal
    can have a different routine to actually output the character. In this
    way you can mix various device types.

Q2: How compatible does a machine have to be to run MINIX?
A2: It needs a NEC uD765 chip as floppy disk controller, a Motorola 6845 as
    video controller, etc.  If the hard disk controller is nonstandard, the
    hard disk won't work, but the rest will.  Machines with different I/O
    chips but try to hide this by presenting the same BIOS interface won't
    work.  About a dozen different clones have been tested.  MINIX worked
    without problems on 80% and failed on 20%.

Q3: Can you call assembler routines from the MINIX C compiler in order to
    write drivers for new devices?
A3: Yes.  The C compiler uses the standard UNIX calling convention of pushing
    the parameters onto the stack in reverse order, so there is no problem
    writing bits of a program in assembler.  The assembly language accepted
    by the MINIX assembler is identical to that of PC-IX, the "official" IBM
    UNIX system for the PC.  Assembly routines for reading and writing I/O
    ports are present in the file kernel/klib88.s (port_in and port_out).

Q4: What do you mean it will sort of run on a 512K machine?
A4: It will boot fine and run ok with 512K, but since it doesn't swap, it
    won't be possible to run a lot of background jobs without running out
    of memory.  Also, if you use make, you may discover that make + cc +
    the various passes that get forked off may not fit in core at once, which
    causes EXECs to fail and make to get an error return.  This can be solved
    by changing the amount of stack space allocated to the compiler passes
    using the chmem utility.  (chmem is functionally the same as in PC-IX,
    which works the same way.)  Reducing the stack allocated to compiler
    passes means that some very large programs may not compile.  With a 640K
    system, files > 50K characters have compiled.  With 512K, that limit may
    be lower.

Andy Tanenbaum (

Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!ames!ucbcad!ucbvax!hplabs!hpcea!hpfcdc!hpfclp!
From: diam...@hpfclp.HP.COM (John Diamant)
Subject: Re: MINIX - From the mouth of the horse
Message-ID: <6640001@hpfclp.HP.COM>
Date: Fri, 9-Jan-87 03:21:21 EST
Article-I.D.: hpfclp.6640001
Posted: Fri Jan  9 03:21:21 1987
Date-Received: Sun, 11-Jan-87 22:52:39 EST
References: <485@uvm-gen.UUCP>
Organization: HP, Fort Collins
Lines: 41


I read your note with much interest.  This sounds like a fantastic
system which I am strongly considering buying for my IBM PC.  However,
your note left a few questions in my mind.  Someone else here has already
placed an order for your book and we will try to get a copy in Washington.

What confused me (and others who already read your note and are interested)
is that we could not figure out what the difference between the 4 software
packages was.  Personally, I am most interested in the 2 PC versions at
the moment.  You mentioned that the smaller version didn't have the C compiler.
If that were the only difference, I would assume you could simply ship the
larger one and tell people the compiler will not run on the smaller systems.
So I presume that there is some sort of kernel tuning such that the smaller
system will run with limited memory.  Since you supply source, and I didn't
see any mention of a kernel tuning utility, I assume that it requires
recompiling the kernel to tune it.  This means that the larger system (since
it can compile itself) is tunable, whereas the smaller one isn't.  Is this
correct?  Is it possible to create the smaller system by setting a few
parameters and recompiling the system on a larger machine?  Is this documented
in your book?  The reason I ask is that I am trying to decide which
configuration I would need to order (I have 384K and 2 floppies).  If it
is worth it, I would upgrade my PC to 640K.  What sort of performance
difference is there between a 256K version and a 640K version?

You also mention a different version for the PC-AT.  If I upgrade my PC to
an AT will I then have the wrong version?  Or would I simply need to recompile
the system with a different ifdef active?

Which binaries are on the tar format?

I also have one question on a completely different topic.  I noticed one
significant area not mentioned in your feature list -- uucp.  Does MINIX
not have uucp?


John Diamant
Systems Software Operation	UUCP:  {hplabs,hpfcla}!hpfclp!diamant
Hewlett Packard Co.		ARPA/CSNET: diamant%hpf...@hplabs.HP.COM
Fort Collins, CO

Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!mcvax!botter!ast
From: (Andy Tanenbaum)
Subject: Re: MINIX
Message-ID: <>
Date: Mon, 12-Jan-87 07:00:41 EST
Article-I.D.: botter.1029
Posted: Mon Jan 12 07:00:41 1987
Date-Received: Tue, 13-Jan-87 00:37:49 EST
Reply-To: (Andy Tanenbaum)
Distribution: world
Organization: VU Informatica, Amsterdam
Lines: 73

John Diamant has asked what the difference between the various MINIX packages
is.  Here is a brief rundown.  The binary of the operating system is identical
on the 256K and 640K PC version.  The only difference is that the binary of
the C compiler has been deleted from the 256K version because some of the
passes are normally kept on the RAM disk, and with only 256K, the RAM disk is
too small to hold them. I just deleted the whole compiler, thus freeing up a
little extra space on the /usr diskette.

There are 3 differences between the 640K PC version and the 512K AT version:
1. The binary for the PC version has a hard disk driver for the XT type disk
   embedded in it.  The binary for the AT version has the AT type disk driver.
   Both versions contain the source code for both the XT and AT drivers, so
   if you upgrade your XT to an AT, you just have to recompile with the other

2. The AT version comes on five 1.2M diskettes instead of eight 360K diskettes.
   The source programs present on both are identical.

3. The initial configuration of what is on the /usr diskette and what is on
   the RAM disk is different.  The compiler passes won't fit on the RAM disk
   here either with only 512K, but there is plenty of room on the 1.2M floppies.

If you have a 256K or 384K machine and a friend has a 640K machine, get the
640K system and make a new root file system (for the RAM disk) yourself using
mkfs.  About 55K is the right size, and it should contain the same /etc and
/dev as the 640K system; /bin should have only: getlf, sh, and sync.
If you have 256K and two floppy disks or a hard disk, you can also copy the
C compiler to a second file system, but you have to fix and recompile the little
driving program cc.c because the paths of the compiler passes are built into
it.  If you are going to put the compiler passes in /user/lib or somewhere
else, you have to change cc.c so it knows which files to EXEC.  When moving
the 640K PC system to a 512K AT you have to make the same change. 
As distributed, cc.c won't compile because I have intentionally included a
line saying: !!!!_SEE_BELOW_!!!   on line 30 to attract your attention to the
comment explaining all this.

In summary, you can use the 640K system to reconstruct a RAM disk (root device)
for 256K or 384K or any other size using mkfs.  You don't have to recompile
the operating system.  The reason for two different sets is that the RAM disk
image (diskette #2) is different for 256K and 640K as described above.  The
only kernel tuning utility is chmem, which changes the amount of stack space
allocated to a program.

The mag tape has all the sources but no binaries at all.  It was intended for
university courses on operating systems that have to use a VAX for the student
projects.  The tape contains a simulator for the IBM PC (8088 interpreter plus
some I/O device simulation) so students can modify MINIX on the VAX and run
it on the PC simulator.  I would be less than honest to suggest that 
interpreting a PC on a VAX is blindingly fast, but if you compile the C to
assembly code and then patch up the main decode loop by hand and hack away at
the condition code routine, you can help somewhat.  The tape also contains
software to run the file-system-only via a pipe to a test program.  This
runs at normal speed, but only allows the students to test the file system.
Neither of these directories are available on diskette.  The complete PC
simulator is not a real small program :-)  I have found the simulator very
useful for debugging however, as it has a wealth of options for tracing,
breakpoints, and other debugging.

I have had a lot of mail asking about uucp.  I don't have one.  If anyone has
a version that runs on V7 and isn't huge and works (a tall order), let me
know or post it.

There was also some discussion about whether or not B. Dalton deals in 
textbooks.  They certainly do.  I have bought many textbooks at some of their
stores.  The problem is this.  Prentice-Hall, Addison-Wesley, and similar
publishers mostly sell to college book stores.  The discount off list price is
based on the way college book stores work.  B. Dalton simply says "We are big
and we want a bigger discount."  This causes friction.  Sometimes B. Dalton
gives in, sometimes the publisher gives in, and sometimes nobody gives in.
If your local B. Dalton refuses to order the book, try a college book store,
or Prentice-Hall's mail order dept.

Andy Tanenbaum 

Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!mcvax!botter!ast
From: (Andy Tanenbaum)
Subject: MINIX
Message-ID: <>
Date: Thu, 15-Jan-87 07:01:29 EST
Article-I.D.: botter.1033
Posted: Thu Jan 15 07:01:29 1987
Date-Received: Sat, 17-Jan-87 00:37:51 EST
Reply-To: (Andy Tanenbaum)
Distribution: world
Organization: VU Informatica, Amsterdam
Lines: 60

lauren@vortex writes:

> I mention this in response to Andy's comment to a uucp query where he said
> (more or less): "if you have one that runs under V7 let me know or post it."
> I assume that he meant to add, "IF and only IF it is PUBLIC-DOMAIN AND NOT

Yes of course that is what I meant.  While developing MINIX I was offered
some software from people who shall here remain nameless.  This software
consisted of utilities taken from AT&T UNIX with the identifiers all
changed, the layout modified, and a few changes here and there.  Needless
to say I sent it all back, warning the authors that making cosmetic
changes to AT&T code does not suddenly void their copyright.  If you ever
get taken to court for copyright violation the judge can easily find an
impartial expert witness and ask him if in his opinion the copy was based
on the original.  If he says "yes" there will be trouble.

The MINIX utilities and libraries were all genuinely written from scratch,
without even peeking at the UNIX code.  The only place you may find some
resemblance is in very small subroutines like strcmp.  There are not really
a large number of fundamentally different algorithms for strcmp, so there
will be some similarity.  For larger programs like ls or even cp, there
is no similarity at all.  

The policy on posting MINIX source code is this.  Although it is copyright,
if you have modified some file and think people might be interested in it,
it is ok to mail or post it.  The only thing to keep in mind is that a
large amount of the network traffic goes over dial up phone lines, even if
your site happens to be on the ARPANET.  When you post something, remember
that other people are paying the phone bills.  If you want to post a large
file, it might be a good idea to first announce it and ask people to send
you mail if they are interested.  If there isn't much response, mailing
it to a few people is much cheaper than posting it to the whole world.

On another subject, as you can imagine, I have gotten LOTS of mail, all
of it very encouraging.  However, one person who works for a major defense
contractor said that his employer was planning to aquire MINIX to run on
some PCs.  Perhaps a word of caution is in order.  MINIX was designed with
the goal of being an educational tool, for teaching in university or
corporate classes, or studying yourself.  It was also designed for hackers
to play with at home on their PCs, and things like that.   I don't think I
would like to trust the defense of the entire Western World to it.

If you sort of have the vague notion that putting MINIX on your PC will 
suddenly turn the PC into something like the VAX running 4.3 that you use at 
work, you will be disappointed.  What it does do, is turn the PC into something 
roughly comparable to a low-end PDP-11 running V7.

Mark Harris posted a question concerning MINIX and the EGA board.  I honestly
don't know if MINIX will work with the EGA board.  I don't have access to
one.  Since the terminal driver is very straightforward, if the EGA board
makes a reasonable attempt to emulate the 6845, patching the driver shouldn't
be too hard even if it doesn't work initially.

Andy Tanenbaum

Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!rutgers!mit-eddie!tower
From: t...@mit-eddie.UUCP
Newsgroups: comp.sys.amiga,,,comp.sys.mac,
Subject: Re: MINIX - From the mouth of the horse
Message-ID: <4564@mit-eddie.MIT.EDU>
Date: Sat, 17-Jan-87 16:53:46 EST
Article-I.D.: mit-eddi.4564
Posted: Sat Jan 17 16:53:46 1987
Date-Received: Sat, 17-Jan-87 23:55:57 EST
References: <>
Reply-To: (Leonard H. Tower Jr.)
Followup-To: comp.os.minix
Distribution: world
Organization: Project GNU, Free Software Foundation, 1000 Mass. Ave.,
Cambridge, MA  02138, USA +1 (617) 876-3296
Lines: 67
Keywords: MINIX FSF GNU freedom Unix
Summary: diffs between FSF/GNU, MINIX, AT&T Unix

In article <> (Andy Tanenbaum) writes:

> ...  The GNU people are
>upset because deep in their hearts they, too, know that people would rather
>pay a reasonable price for good stuff than get empty promises for free.

First, I would like to commend ast for doing MINIX, and going a large part of
the way towards giving MINIX its freedom.

Second, GNU isn't an empty promise.  GNU Emacs is out there.  GDB (GNU's
Debugger) is out there.  Bison, a YACC compatible Parser Generator, is out
there.  The GNU C compiler (highly optimizing with VAX, 68000, and 68020 code
generators) will be released soon.  Etc.

The remaining large undone piece is the kernel.  Work has started on that,
and its being leveraged off of existing code for a Unix style kernel, Trix,
written at MIT a while back.

GNU is a more ambitious project than MINIX, and rms hasn't had much more help
than ast.  Most of rms' help has been volunteer.  rms has also been working on
it for a shorter period of time.

Third, none of the GNU people I know of are upset.  We are just sad that yet
more software has been chained up.

>Does anyone know how much GNU charges for its "free" software for the tape,
>postage, handling etc?    Berkeley generally charges something like $125
>for its tapes, as I recall.  If GNU also charges $125 for its "free" software
>it seems to me that their moral indignation at Prentice-Hall's outrageous
>$79.95 price is somewhat weakened.

First, "free" doesn't refer to cost, but to the freedom of the software.

Second, I would like to present some comparisons between GNU, MINIX, and
Unix.  I know the facts are straight for GNU, correct me on the others.

					GNU	MINIX	Unix
					---	-----	----

Is source code distributed?		Yes	Yes	For many more $$

How many copies of the source can
   you give away, legally?	     Unlimited	3-4	None

Can one legally restrict use by others? No	YES	YES

Can one legally post it on USENET?	Yes	NO	NO

Can one legally ARPA ftp it, freely?	Yes	NO	NO

Cost of non-ARPA distribution from
   home organization:		      $ 150.  $ 80.	Many times more.

People are referred to:
	- the GNU Public License
	- the GNU Manifesto
	- Minix's Licensing arrangements (I have yet to see these)
	- AT&T and susbsidiary vendor Unix Licenses
for further details.

happy hacking, len tower
Len Tower, Project GNU of the Free Software Foundation
	   1000 Mass. Ave., Cambridge, MA  02138, USA +1 (617) 876-3296
HOME: 36 Porter Street, Somerville, MA  02143, USA +1 (617) 623-7739
UUCP: {}!mit-eddie!mit-prep!tower	INTERNET:

Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!ames!aurora!jaw
From: j...@aurora.UUCP (James A. Woods)
Newsgroups: comp.os.minix
Subject: Re: MINIX - From the mouth of the horse
Message-ID: <599@aurora.UUCP>
Date: Mon, 19-Jan-87 21:40:31 EST
Article-I.D.: aurora.599
Posted: Mon Jan 19 21:40:31 1987
Date-Received: Tue, 20-Jan-87 18:57:51 EST
References: <> <4564@mit-eddie.MIT.EDU>
Organization: NASA Ames Research Center, Mt. View, Ca.
Lines: 30
Keywords: MINIX FSF GNU freedom Unix
Summary: free software needs no law

# ``there's only one "two"`` -- local tv station slogan.

just wondering why purveyors of "totally free" unix-like software
seem overly concerned with the law, as the gnu project appears to be.
re-control through new age license agreements is not really much
different from the mentality of an armada of at&t attorneys.

i doubt it'd be worth it to gnu to really enforce re-distribution provisos,
especially if, as has been said in this forum, they can't even get enough
volunteers to completely re-invent the unix wheel.

the reality of software around here is that once it hits usenet, people do
what they want with it.  the u. s. government, for whom i work, has always
taken this enlightened attitude.  if we (this applies to universities as well)
develop something, give it away, and someone makes a buck off it, goody for
them if they add value and support it.  if private industry doesn't add value
and still manages to sell it, the condition never remains for long, since
the code, having been publicized as free, informs public-minded whistleblowers
who then re-publicize the free code.

as for what's available under gnu/minix, there's an obvious merger
with combining the nice and free optimizing gnu c compiler and sophisticated
public domain utilities not in minix (yacc, lex, compress, egrep, diff, etc.)
with the minix kernel.  since each package is cheaper than dinner for two
(at least in some parts of the world), this is easy enough to do.

long live the sean byrne usenet logo
(n years of usenet freedom and anarchy),


Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!rutgers!sri-unix!husc6!mit-eddie!tower
From: t...@mit-eddie.UUCP
Newsgroups: comp.os.minix,comp.sys.amiga,,,
Subject: Re: MINIX - From the mouth of the horse
Message-ID: <4654@mit-eddie.MIT.EDU>
Date: Sun, 25-Jan-87 22:40:12 EST
Article-I.D.: mit-eddi.4654
Posted: Sun Jan 25 22:40:12 1987
Date-Received: Mon, 26-Jan-87 06:38:24 EST
References: <> <4564@mit-eddie.MIT.EDU>
Reply-To: (Leonard H. Tower Jr.)
Followup-To: comp.os.minix
Distribution: world
Organization: Project GNU, Free Software Foundation, 1000 Mass. Ave.,
Cambridge, MA  02138, USA +1 (617) 876-3296
Lines: 73
Keywords: GNU MINIX FSF freedom
Summary: rms' reply
Posting-Front-End: GNU Emacs 18.36.1 of Wed Jan 21 1987 on eddie (berkeley-unix)

rms asked me to post this followup to article <>
of (Andy Tanenbaum).  I apologize for the delay (I was
keyboard-less at USENIX for the last week  ;-} ).

   When Andy Tanenbaum announced his plans for MINIX, I told him that he
   could certainly use any of GNU in MINIX, as long as he followed the
   terms, which say that everyone must be able to redistribute it in any
   quantity to anyone.  Also, I said that if he produced something that
   fit the GNU system and was suitably available, I would use it.
   I don't think this was an antagonistic response.
   But I wasn't interested in more than passive cooperation, for two
   One was that the technical goals were very different and I doubted
   that any code written for one system would really be suitable for the
   other.  He planned a small system to fit the machines now common.  I
   am aiming for a more powerful system that people will prefer to 4.2 or
   system V, to run on the next generation of machine.  Each of these
   paths has its advantages and disadvantages which I'm sure the reader
   can see.
   The other is that I doubted that MINIX would ultimately be available
   on terms that would allow GNU to use it.  I wasn't interested in
   investing any effort on it until this doubt was resolved.  Now
   it appears the resolution is that GNU can't use it.
   Meanwhile, Tanenbaum hasn't used any GNU software, perhaps because
   some is too big for today's IBM PC's or perhaps because GNU copylefts
   would not permit their distribution on Prentice Hall's terms.
   I do not understand why Tanenbaum calls the GNU project "empty
   promises".  Several pieces of GNU software are already in
   distribution, complete with fanatical admirers and detractors.
   I think we have demonstrated that we can deliver what we promise.
   There is no charge whatever for using GNU software for any purpose.
   The Free Software Foundation charges for mailing tapes, but this is
   not the same as a charge for the software on the tape.  That is free,
   and you can make as many copies as you like for anyone at all.  The
   Free Software Foundation is a tax-exempt charitable organization and
   the money that tape distribution brings in is spent on the creation of
   more free software.  (None of it goes to me personally.)
   The GNU C compiler will be released for testing soon.  It compiles
   itself, GNU Emacs and Monardo's free TeX-in-C successfully, so it is
   not far from ready.  And it will be free, with sources.  (TeX-in-C is
   still being tested; the Free Software Foundation and probably others
   will distribute it by and by.  There will be announcements.)
   Further questions on GNU, GNU mailing lists, and the availability
   of GNU software can be directed to or
   mit-eddie!prep!gnu or seismo!!gnu.

rms (Richard M. Stallman) is directly reachable at
<>.  Please realise that any time you spend
communicating with him will delay the delivery of GNU software, by the
time it takes him to read and reply.

happy hacking, -len tower
Len Tower, Project GNU of the Free Software Foundation
	   1000 Mass. Ave., Cambridge, MA  02138, USA +1 (617) 876-3296
HOME: 36 Porter Street, Somerville, MA  02143, USA +1 (617) 623-7739
UUCP: {}!mit-eddie!mit-prep!tower	INTERNET:

Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!rutgers!brl-adm!seismo!mcvax!botter!ast
From: a...@botter.UUCP
Newsgroups: comp.os.minix
Subject: More from the mouth of the horse
Message-ID: <>
Date: Mon, 9-Feb-87 17:41:19 EST
Article-I.D.: botter.1056
Posted: Mon Feb  9 17:41:19 1987
Date-Received: Wed, 11-Feb-87 06:48:48 EST
Reply-To: (Andy Tanenbaum)
Distribution: world
Organization: VU Informatica, Amsterdam
Lines: 67

Here are some questions and answers from recent news and mail.

Q1: Does the PC simulator on the tape have parts in assembler?
A1: No.  It is 100% C.  It should be easy to port anywhere with a C compiler
    and enough memory (about 1.5M).  Only caution is big vs. little endian.

Q2: Why did you have the C compiler produce packed assembly code?
A2: I didn't have a separate assembler and loader.  All I had was a single
    program, asld, that assembled and loaded all at once.  Given this program,
    packed assembly code was better than ASCII assembly code.  MINIX has
    programs libupack and libpack to go both ways.  I admit it is a kludge,
    but time constraints prohibited me from writing an assembler and a loader,
    and asld was available and well-debugged.

Q3: Why wasn't the code produced as a separate volume, like John Lions' book?
A3: I discussed this with P-H at great length.  Given the way book publishing
    works, a two volume set would have greatly increased the price of the
    book, and neither P-H nor I wanted that.

Q4: Any news on new clones that MINIX works on or doesn't work on?
A4: Our dept. has just gotten a large shipment of Zenith Z-248 AT clones for
    student use.  It works fine, provided the machine has a standard graphics
    board that works the way the IBM mono or color board works.  It doesn't
    work quite right with the EGA board.  I don't know why EGA board manuals
    are scarcer than hen's teeth around here.  Even Zenith doesn't have the
    manual for their own board.  I also discovered a class of hard disks that
    the MINIX disk driver can't handle.  The default block size is 1K, which
    means two sectors on most drives.  On a drive with an odd number of 512-
    byte sectors per cylinder, the last logical block will be split over two
    cylinders.  On drives that can't handle the implied seek, the driver gives
    up and reports an unrecoverable error.  The driver is being modified to
    handle this situation by simple reading each sector one at a time. The
    AT driver on the MINIX distribution worked fine with the Zenith 20 MB hard
    disk, but not with the 30 MB disk, which has 85 sectors per cylinder.

Q5: Why didn't you use the BIOS?
A5: Because it doesn't support interrupts.  If a foreground job, like a
    shell or editor read from the terminal by calling the BIOS, all the
    background jobs would be stopped instantly.  The BIOS simply does not
    support multiprogramming at all.  On the AT it has some crude hooks,
    but I wanted the PC and AT versions to be the same.  I don't think that
    will last long, but at least no one can blame me for the divergence.

Q6: Where is get_tot_mem?  I can't find it in the cross reference map.
A6: It is in lib/getutil.s, which is on the disks but not in the book.
    All the kernel library routines are in kernel/klib88.s and are in the
    book.  There are a couple of very short assembler routines that were
    needed in MM and/or FS, and they got put in the lib directory with
    the other library routines.  Note that the library source routines
    are in a MINIX archive lib lib/libsrc.a (to save disk space) so you
    have to unpack the archive to get them.

There has been a lot of discussion about how to post source code.  It seems
to me that the advantage of readable archives (i.e. shar) is so great that
tar just can't compare at all.  Since MINIX includes a shar, it would seem
that the format produced by this shar should be the standard, since everyone
will have it.  Of course one can create a "guest" uid and log in as guest
to limit the damage when unsharing.  Someone made a comment about gres.
The MINIX shar format expects a gres, but thanks to Martin Atkins of York
MINIX has a gres, so there is no problem.

There was a program uuslave.c posted to comp.sources.unix a couple of days
ago.  Does anyone know anything about this program?  Might it be useful as
a first step toward uucp?  If anyone has the time and knowledge, please take
a look at it and post your findings.

Andy Tanenbaum

			        About USENET

USENET (Users’ Network) was a bulletin board shared among many computer
systems around the world. USENET was a logical network, sitting on top
of several physical networks, among them UUCP, BLICN, BERKNET, X.25, and
the ARPANET. Sites on USENET included many universities, private companies
and research organizations. See USENET Archives.

		       SCO Files Lawsuit Against IBM

March 7, 2003 - The SCO Group filed legal action against IBM in the State 
Court of Utah for trade secrets misappropriation, tortious interference, 
unfair competition and breach of contract. The complaint alleges that IBM 
made concentrated efforts to improperly destroy the economic value of 
UNIX, particularly UNIX on Intel, to benefit IBM's Linux services 
business. See SCO v IBM.

The materials and information included in this website may only be used
for purposes such as criticism, review, private study, scholarship, or

Electronic mail:			       WorldWideWeb: