Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!mcvax!botter!ast
From: a...@botter.cs.vu.nl (Andy Tanenbaum)
Newsgroups: comp.sys.amiga,comp.sys.atari.st,comp.sys.ibm.pc,comp.sys.mac
Subject: MINIX - From the mouth of the horse
Message-ID: <1026@botter.cs.vu.nl>
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: a...@cs.vu.nl (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 comp.sys.ibm.pc to avoid
scattering it all over the place. At the very least, crosspost comments to
comp.sys.ibm.pc 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 (m...@cs.vu.nl, 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
cc.at: 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: a...@botter.cs.vu.nl (Andy Tanenbaum)
Newsgroups: comp.sys.ibm.pc,comp.sys.atari.st,comp.unix.wizards,comp.unix.xenix,
comp.sources.d
Subject: MINIX
Message-ID: <1028@botter.cs.vu.nl>
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: a...@cs.vu.nl (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
comp.sys.ibm.pc 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 (mi...@cs.vu.nl)
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!ames!ucbcad!ucbvax!hplabs!hpcea!hpfcdc!hpfclp!
diamant
From: diam...@hpfclp.HP.COM (John Diamant)
Newsgroups: comp.sys.ibm.pc
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
Andy,
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?
Thanks,
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: a...@botter.cs.vu.nl (Andy Tanenbaum)
Newsgroups: comp.sys.ibm.pc
Subject: Re: MINIX
Message-ID: <1029@botter.cs.vu.nl>
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: a...@cs.vu.nl (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
driver.
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: a...@botter.cs.vu.nl (Andy Tanenbaum)
Newsgroups: comp.sys.ibm.pc
Subject: MINIX
Message-ID: <1033@botter.cs.vu.nl>
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: a...@cs.vu.nl (Andy Tanenbaum)
Distribution: world
Organization: VU Informatica, Amsterdam
Lines: 60
lauren@vortex writes:
> DON'T POST AT&T UNIX BINARIES OR SOURCE (OR BINARIES OR SOURCE BASED ON
> AT&T UNIX SOURCES) TO THE NETWORK! FOR THAT MATTER, NEVER POST
> ANY NON-PUBLIC-DOMAIN SOFTWARE UNLESS YOU HAVE EXPLICIT
> PERMISSION TO DO SO FROM THE ENTITY THAT LICENSES SUCH SOFTWARE!
>
> 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
> BASED ON AT&T CODE."
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.atari.st,comp.sys.ibm.pc,comp.sys.mac,
comp.os.minix
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: <1026@botter.cs.vu.nl>
Reply-To: t...@prep.ai.mit.edu (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 <1...@botter.cs.vu.nl> a...@cs.vu.nl (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: t...@prep.ai.mit.edu
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: <1026@botter.cs.vu.nl> <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),
ames!jaw
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,comp.sys.atari.st,comp.sys.ibm.pc,
comp.sys.mac,
comp.os.misc,comp.edu,comp.unix.wizards
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: <1026@botter.cs.vu.nl> <4564@mit-eddie.MIT.EDU>
Reply-To: t...@prep.ai.mit.edu (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 <1...@botter.cs.vu.nl>
of a...@cs.vu.nl (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
reasons.
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 g...@prep.ai.mit.edu or
mit-eddie!prep!gnu or seismo!prep.ai.mit.edu!gnu.
rms (Richard M. Stallman) is directly reachable at
< r...@prep.ai.mit.edu>. 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: t...@prep.ai.mit.edu
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: <1056@botter.cs.vu.nl>
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: a...@cs.vu.nl (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