Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!
cs.utexas.edu!uunet!mcvax!hp4nl!botter!star.cs.vu.nl!...@cs.vu.nl
From: a...@cs.vu.nl (Andy Tanenbaum)
Newsgroups: comp.os.minix
Subject: The future of MINIX
Message-ID: <2835@ast.cs.vu.nl>
Date: 7 Jul 89 11:25:20 GMT
Sender: a...@cs.vu.nl
Reply-To: a...@cs.vu.nl (Andy Tanenbaum)
Organization: VU Informatica, Amsterdam
Lines: 58
I have been fairly quiet lately, not out of lack of interest, but waiting
for the dust to settle. It seems that the overwhelming majority opinion
is that Bruce Evan's protected mode code is a big step forward. I tried it
and, of course, it didn't work on my machine. However, after a round of
12,000 mile remote debugging with Bruce, we found the problem (2 lines)
and it works fine now.
I have also looked at his code more closely, and I am impressed. It is not
only very well programmed, but he resisted the temptation that most other
people have succumbed to, namely, changing my layout. If I am to use it in
the book, I certainly don't want two different styles in there, and my
changing everything by hand would undoubtedly lead to errors. There is no
MINIX pretty-printer at present (hint). The UNIX pretty-printer, cb, doesn't
produce my layout style, which I am very much attached to.
Another plus is that Bruce has been very helpful in answering questions etc.
My major fear, that the code would be too complicated for students, is
probably unjustified. It is certainly longer now, but not that much hairier.
The 80286 stuff is fairly well isolated. I took a look at how long the
listing in the book will be if I include only the same files as last time,
plus a few new ones that are essential. It comes to something like 380 pages,
vs. 250 last time. Together with, say, 30 pages of descriptive text about
how the new code works, and 20 pages of man pages in Appendix C, the book
will exceed 900 pages. This is getting kinda large for a 1 semester textbook.
Printing it in 2 volumes makes it more expensive. I might be able to
help a little here and there by not including things like klib88.x and
protect.c, which are very technical and not very conceptual, and perhaps
eliminating the cross reference listing.
Anyway, I have decided to use Bruce's code as the basis for V2.0 (subject to
Prentice-Hall not vetoing a 900 page book).
There are still a number of things that need to be done before I even start
with POSIX. Bruce and I have discussed this by email. The game plan is that
he is going to make some changes during the summer, and then post the new
version of the kernel. I am going to look at fixes etc from the net
concerning utilities etc, and post those cdifs. All this should happen
around September. Let us call that version 1.4b. This will be my base for
starting to work on POSIX. I'll do the kernel/FS/MM myself (looking at
what Simon Poole has already done), but help writing/converting libraries,
utilities etc is very welcome.
When all that is done, we will have a protected mode system that is based
on POSIX and reasonably fast for small machines. MINIX seems to be
evolving in the direction of something more than an academic toy and towards
a more serious system. If I run into Niklaus Wirth at a conference
sometime, I'll have to ask him about that :-).
An additional note. Amiga MINIX is actually up and running. It is now
being tested.
Furthermore, MINIX 1.3 is being ported to the SPARC.
Getting all these versions back together, and then POSIX-based is going to be
a job on the order of cleaning out the Augean Stables, and I don't have a
Hercules card.
Andy Tanenbaum (a...@cs.vu.nl)
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!uw-beaver!
uw-june!phil
From: p...@june.cs.washington.edu (Phil Nelson)
Newsgroups: comp.os.minix
Subject: Re: The future of MINIX
Summary: Minix V2.0, protected mode, and 8088s
Message-ID: <8678@june.cs.washington.edu>
Date: 7 Jul 89 22:02:52 GMT
References: <2835@ast.cs.vu.nl>
Organization: U of Washington, Computer Science, Seattle
Lines: 8
I don't have a 286 and so I didn't get a copy of Bruce's protected
mode kernel. With the announcement that V2.0 will be based on
Bruce's work, I had a question that was not answered by the
announcement. What does this move mean to those of us without a
286? Will the same code run on both 8088s and 80286s?
--Phil Nelson
(aka p...@unicorn.wwu.edu)
Path: utzoo!attcan!uunet!image.soe.clarkson.edu!jk0
From: j...@image.soe.clarkson.edu (Jason Coughlin)
Newsgroups: comp.os.minix
Subject: Re: The future of MINIX
Message-ID: <1989Jul8.171336.27399@sun.soe.clarkson.edu>
Date: 8 Jul 89 17:13:36 GMT
References: <2835@ast.cs.vu.nl>
Sender: j...@sun.soe.clarkson.edu (Jason Coughlin)
Organization: Clarkson University, Potsdam, NY
Lines: 14
From article <2...@ast.cs.vu.nl>, by a...@cs.vu.nl (Andy Tanenbaum):
> ,and perhaps
> eliminating the cross reference listing.
I realize that with 900 pages it is hard to figure out what to cut and
what not to cut. But, the cross reference listing is VERY handy. I
used it ALL of the time when taking our OS course. If it's gotta go
then it's gotta go, but if something else can go instead please leave it.
--
--
Jason Coughlin
( j...@sun.soe.clarkson.edu , jk0@clutx )
Path: utzoo!utgpu!jarvis.csri.toronto.edu!dptcdc!tmsoft!mshiels
From: mshi...@tmsoft.uucp (Michael A. Shiels)
Newsgroups: comp.os.minix
Subject: Re: The future of MINIX
Message-ID: <1989Jul9.023852.21674@tmsoft.uucp>
Date: 9 Jul 89 02:38:52 GMT
References: <2835@ast.cs.vu.nl> <1989Jul8.171336.27399@sun.soe.clarkson.edu>
Reply-To: mshi...@tmsoft.UUCP (Michael A. Shiels)
Organization: MaS Network Software and Consulting
Lines: 2
Will the protected mode version work on a 386 machine? I am not
familiar with the differences for protected mode. Thanx.
Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!usc!cs.utexas.edu!uunet!
mcvax!hp4nl!botter!star.cs.vu.nl!ast
From: a...@cs.vu.nl (Andy Tanenbaum)
Newsgroups: comp.os.minix
Subject: Re: The future of MINIX
Message-ID: <2850@ast.cs.vu.nl>
Date: 10 Jul 89 09:31:24 GMT
References: <2835@ast.cs.vu.nl> <8678@june.cs.washington.edu>
Reply-To: a...@cs.vu.nl (Andy Tanenbaum)
Organization: VU Informatica, Amsterdam
Lines: 19
In article <8...@june.cs.washington.edu> p...@june.cs.washington.edu
(Phil Nelson) writes:
>I don't have a 286.
>What does this move [Bruce Evans' code] mean to those of us without a
>286? Will the same code run on both 8088s and 80286s?
Yes. Definitely. Bruce was extremely careful to distinguish where something
was specific for the 286. In the next release, the test for 8088 vs. other
CPUs will be dynamic.
Conclusion: don't worry. We are not planning to dump the 8088 by any means.
One thing I may do, however, is make the assumption that by the time this
system (V2.0) is released, probably 1991, everybody wanting to recompile
the system will have a hard disk. Making the system boot and run with
floppy only isn't so hard, but as the kernel has grown, it is getting harder
and harder to recompile the whole operating system on floppies. By 1991
hard disks will be so cheap that it is hard to imagine any serious user
not having one.
Andy Tanenbaum
Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!usc!cs.utexas.edu!uunet!
mcvax!hp4nl!botter!star.cs.vu.nl!ast
From: a...@cs.vu.nl (Andy Tanenbaum)
Newsgroups: comp.os.minix
Subject: Re: The future of MINIX
Message-ID: <2851@ast.cs.vu.nl>
Date: 10 Jul 89 09:38:03 GMT
References: <2835@ast.cs.vu.nl> <1989Jul8.171336.27399@sun.soe.clarkson.edu>
Reply-To: a...@cs.vu.nl (Andy Tanenbaum)
Organization: VU Informatica, Amsterdam
Lines: 12
In article <1989Jul8.171336.27...@sun.soe.clarkson.edu>
j...@image.soe.clarkson.edu (Jason Coughlin) writes:
>I realize that with 900 pages it is hard to figure out what to cut and
>what not to cut. But, the cross reference listing is VERY handy.
How about this. I could grep the listing in the book for PRIVATE and PUBLIC
and just give an alphabetical list of those lines, 3 or 4 columns per page.
That way you could find where symbols are defined, which I think is more
useful than the reverse. Conceivably I could also make a full cross
reference list and put in on the disk. Making that list, incidentally, was
a gigantic pain in the rear end. It was surprisingly difficult to automate.
Andy Tanenbaum
Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!apple!sun-barr!
cs.utexas.edu!uunet!mcvax!hp4nl!phigate!prle!prles2!cstw01!meulenbr
From: meule...@cstw01.prl.philips.nl (Frans Meulenbroeks)
Newsgroups: comp.os.minix
Subject: Re: The future of MINIX
Message-ID: <563@prles2.UUCP>
Date: 10 Jul 89 15:07:52 GMT
References: <2835@ast.cs.vu.nl>
Sender: nob...@prles2.UUCP
Reply-To: meule...@cstw01.prl.philips.nl (Frans Meulenbroeks)
Organization: Centre for Software Technology, Philips Eindhoven
Lines: 85
[lots of text discarded]
In article <2...@ast.cs.vu.nl> a...@cs.vu.nl (Andy Tanenbaum) writes:
[...]
>Anyway, I have decided to use Bruce's code as the basis for V2.0 (subject to
>Prentice-Hall not vetoing a 900 page book).
[...]
>starting to work on POSIX. I'll do the kernel/FS/MM myself (looking at
>what Simon Poole has already done), but help writing/converting libraries,
>utilities etc is very welcome.
>
>When all that is done, we will have a protected mode system that is based
>on POSIX and reasonably fast for small machines. MINIX seems to be
>evolving in the direction of something more than an academic toy and towards
>a more serious system. If I run into Niklaus Wirth at a conference
>sometime, I'll have to ask him about that :-).
>
>An additional note. Amiga MINIX is actually up and running. It is now
>being tested.
>
>Furthermore, MINIX 1.3 is being ported to the SPARC.
>
>Getting all these versions back together, and then POSIX-based is going to be
>a job on the order of cleaning out the Augean Stables, and I don't have a
>Hercules card.
>
>Andy Tanenbaum (a...@cs.vu.nl)
Ok. That amounts to 5 different versions:
for 8088, 286/protected, ST, Amiga, SPARC.
As far as getting these together:
This can really become a pain.
However, I would support such an integration very much.
As far as I can see it there are two different problem areas:
- assembly code
Since these must be rewritten completely, IMHO they should be avoided
as much as possible. I know that it is tempting to do a lot of rs232
stuff in assembly for performance purposes. However I would like to
ask to limit this to the bare minimum.
- hardware dependencies
This is another problem, which mainly arises in the tty/rs232/console
area. Please do not rely on the fact that every system has a 8250
chip. In the current tty.c there are a lot of places where the 8250 is
enabled. I would suggest to keep all hardware independent stuff in
tty.c, and either put all hardware stuff in say console.c and rs232.c
or put it in dedicated files like i8250.c and so on, dealing with the
various hardware components.
Doing things this way yields a clear separation of the common part
and the hardware specific part.
If ast decides to isolate the hardware depencies in one way or
another, I could be persuaded to look at the ST part of it.
(By the way, the above does mainly apply to rs232, keyboard and
monitor. I don't know if such an approach is feasible for floppy and
hard disk).
On a related but different topic:
will something be done to get the compiler more ansi conformant?
I'm mainly thinking about function prototypes and floating point
support.
As an aside:
I have a version of 1.4a for the ST, but I really don't know what to do
with it. Since I prefer very much to have an official upgrade
I'm very reluctant to post this.
On the other hand: I've shipped this to Johan Stevenson for
authorisation and posting somewhere in April, but it seems that he does
not have the time to look into it, and approve it.
I'm sitting on this stuff for more than two months now, and I feel in
some kind of catch-22 situation. What is the opinion of the net in
general and ast specifically that I should do with this stuff??
Note: please don't send mail requesting me to mail you a copy.
I want to get the minix community in sync, and I definitely don't want
a lot of different version floating around.
(by the way: this ST version is compatible with 1.4a, except for the
amoeba stuff. It does support rs232 (at least at 1200 baud))
regards,
Frans Meulenbroeks (meule...@cst.prl.philips.nl)
Centre for Software Technology
( or try: ...!mcvax!phigate!prle!cst!meulenbr)
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!wasatch!cs.utexas.edu!
uunet!murtoa.cs.mu.oz.au!munnari.oz.au!otc!metro!extro!natmlab!ditsyda!evans
From: ev...@ditsyda.oz (Bruce Evans)
Newsgroups: comp.os.minix
Subject: Re: The future of MINIX
Message-ID: <2056@ditsyda.oz>
Date: 10 Jul 89 17:11:16 GMT
References: <2835@ast.cs.vu.nl>
<1989Jul8.171336.27399@sun.soe.clarkson.edu> <1989Jul9.023852.21674@tmsoft.uucp>
Reply-To: ev...@ditsyda.mq.oz (Bruce Evans)
Organization: CSIRO DIT Sydney, Australia
Lines: 13
In article <1989Jul9.023852.21...@tmsoft.uucp> mshi...@tmsoft.UUCP
(Michael A. Shiels) writes:
>Will the protected mode version work on a 386 machine? I am not
Yes, assuming the machine is AT-compatible apart from the processor. This
does not use 32-bit mode so still suffers from small segments.
It (the same binary) will also run on an 8088, by avoiding the small parts of
the code specific to protected mode.
I am working on a full 32-bit version. It runs, but there is no practical
compiler for it yet.
--
Bruce Evans ev...@ditsyda.oz.au
Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!gatech!bloom-beacon!
tut.cis.ohio-state.edu!ucbvax!hplabs!hp-pcd!hpcvca!charles
From: char...@hpcvca.CV.HP.COM (Charles Brown)
Newsgroups: comp.os.minix
Subject: Re: The future of MINIX
Message-ID: <5870010@hpcvca.CV.HP.COM>
Date: 10 Jul 89 17:51:50 GMT
References: <2835@ast.cs.vu.nl>
Organization: Hewlett-Packard Co., Corvallis, Oregon
Lines: 12
> This is getting kinda large for a 1 semester textbook.
> Andy Tanenbaum (a...@cs.vu.nl)
Just a nit... Why does the textbook need to be restricted to 1
semester? I have seen several textbooks which, in the introduction,
map out various sizes (how many semesters) and levels (undergrad vs
grad) of courses by suggestions on what chapters to cover and what
chapters to skip. I think that approach works well.
--
Charles Brown char...@cv.hp.com or charles%hpc...@hplabs.hp.com
or hplabs!hpcvca!charles or "Hey you!"
Not representing my employer.
Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!aramis.rutgers.edu!
athos.rutgers.edu!rbthomas
From: rbtho...@athos.rutgers.edu (Rick Thomas)
Newsgroups: comp.os.minix
Subject: Re: The future of MINIX
Message-ID: <Jul.11.01.40.45.1989.26685@athos.rutgers.edu>
Date: 11 Jul 89 05:40:46 GMT
References: <2835@ast.cs.vu.nl>
<1989Jul8.171336.27399@sun.soe.clarkson.edu> <2851@ast.cs.vu.nl>
Organization: Rutgers Univ., New Brunswick, N.J.
Lines: 24
> Conceivably I could also make a full cross
> reference list and put in on the disk.
Now, That's a good idea! Most people aren't interested in the Xref
unless they are into serious code hacking anyway, so they can be
expected to have the disks. Also, I bet it's easier to talk P-H into
adding a disk to the distribution than adding 50-100 pages to the
book. (Or printing a second volume with the code and Xref in it.) As
an added benefit, if the Xref production can be automated (not easy, as
Andy noted, but maybe some of the hackers out there would be willing to
have a go at it. Warning -- you should probably start with the source
code of the CPP and parser pass of the compiler. Anything less is
bound to wind up getting confused by comments that look like code,
etc.) The program that does it can be put on the floppy, instead of
the actual Xref. Then people can have Xrefs of their own local
versions.
Rick
--
Rick Thomas
uucp: {ames, cbosgd, harvard, moss, seismo}!rutgers!jove.rutgers.edu!rbthomas
arpa: rbtho...@JOVE.RUTGERS.EDU
Phone: (201) 932-4301
Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!
mcvax!hp4nl!botter!star.cs.vu.nl!ast
From: a...@cs.vu.nl (Andy Tanenbaum)
Newsgroups: comp.os.minix
Subject: Re: The future of MINIX
Message-ID: <2858@ast.cs.vu.nl>
Date: 11 Jul 89 15:25:29 GMT
References: <2835@ast.cs.vu.nl> <563@prles2.UUCP>
Reply-To: a...@cs.vu.nl (Andy Tanenbaum)
Organization: VU Informatica, Amsterdam
Lines: 15
In article <5...@prles2.UUCP> meule...@cstw01.prl.philips.nl
(Frans Meulenbroeks) writes:
>I have a version of 1.4a for the ST, but I really don't know what to do
>with it. Since I prefer very much to have an official upgrade
>I'm very reluctant to post this.
>On the other hand: I've shipped this to Johan Stevenson for
>authorisation and posting somewhere in April, but it seems that he does
>not have the time to look into it, and approve it.
I don't either. Still, I think it worth trying to get the two versions into
sync. You could post the cdifs and let the net try to work out the bugs
collectively. A far more interesting question is getting the second
release of Bruce Evans' stuff and the Atari in sync, since that will be the
base for V2.0 on the IBM line.
Andy Tanenbaum (a...@cs.vu.nl)
Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!
mcvax!hp4nl!botter!star.cs.vu.nl!ast
From: a...@cs.vu.nl (Andy Tanenbaum)
Newsgroups: comp.os.minix
Subject: Re: The future of MINIX
Message-ID: <2859@ast.cs.vu.nl>
Date: 11 Jul 89 15:34:33 GMT
References: <2835@ast.cs.vu.nl>
<1989Jul8.171336.27399@sun.soe.clarkson.edu> <2851@ast.cs.vu.nl>
<Jul.11.01.40.45.1989.26685@athos.rutgers.edu>
Reply-To: a...@cs.vu.nl (Andy Tanenbaum)
Organization: VU Informatica, Amsterdam
Lines: 20
In article <Jul.11.01.40.45.1989.26...@athos.rutgers.edu>
rbtho...@athos.rutgers.edu (Rick Thomas) writes:
> Also, I bet it's easier to talk P-H into
>adding a disk to the distribution than adding 50-100 pages to the
>book.
That's true, but next time around I will probably only have 360K diskettes.
For V1.x, there was 640K PC and 512K AT. All the people with 512K PCs and
640K ATs got confused. Thus the number of diskettes will invariably be
larger next time, which does not give any technical problems, but does affect
the price.
> The program that does it can be put on the floppy, instead of
>the actual Xref. Then people can have Xrefs of their own local
>versions.
Not a bad idea, assuming I can automate the process. I'll also have to put
the line numbering program on the disk. Not that it is hard to do that,
but I might forget. Somebody please remind me around Dec 1990.
Andy Tanenbaum (a...@cs.vu.nl)
Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!
mcvax!hp4nl!botter!star.cs.vu.nl!ast
From: a...@cs.vu.nl (Andy Tanenbaum)
Newsgroups: comp.os.minix
Subject: Re: The future of MINIX
Message-ID: <2860@ast.cs.vu.nl>
Date: 11 Jul 89 15:36:10 GMT
References: <2835@ast.cs.vu.nl> <5870010@hpcvca.CV.HP.COM>
Reply-To: a...@cs.vu.nl (Andy Tanenbaum)
Organization: VU Informatica, Amsterdam
Lines: 8
In article <5870...@hpcvca.CV.HP.COM> char...@hpcvca.CV.HP.COM
(Charles Brown) writes:
>Just a nit... Why does the textbook need to be restricted to 1 semester?
The standard OS course is 1 semester, so the book ought to at least be
usable for that.
Andy Tanenbaum (a...@cs.vu.nl)
Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!iuvax!bsu-cs!dhesi
From: dh...@bsu-cs.bsu.edu (Rahul Dhesi)
Newsgroups: comp.os.minix
Subject: Re: The future of MINIX
Message-ID: <8176@bsu-cs.bsu.edu>
Date: 11 Jul 89 17:00:27 GMT
References: <2835@ast.cs.vu.nl> <5870010@hpcvca.CV.HP.COM>
Reply-To: dh...@bsu-cs.bsu.edu (Rahul Dhesi)
Organization: CS Dept, Ball St U, Muncie, Indiana
Lines: 9
I think Dr. Tanenbaum should consider finding a different publisher for
the revised Minix book and disks.
What Minix badly needs is a publisher that knows about software and how
to handle upgrades in an organized manner. Prentice Hall definitely is
not it.
--
Rahul Dhesi <dh...@bsu-cs.bsu.edu>
UUCP: ...!{iuvax,pur-ee}!bsu-cs!dhesi
Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!
mcvax!hp4nl!botter!star.cs.vu.nl!ast
From: a...@cs.vu.nl (Andy Tanenbaum)
Newsgroups: comp.os.minix
Subject: Re: The future of MINIX
Message-ID: <2862@ast.cs.vu.nl>
Date: 11 Jul 89 21:34:16 GMT
References: <2835@ast.cs.vu.nl> <5870010@hpcvca.CV.HP.COM>
<8176@bsu-cs.bsu.edu>
Reply-To: a...@cs.vu.nl (Andy Tanenbaum)
Organization: VU Informatica, Amsterdam
Lines: 44
In article <8...@bsu-cs.bsu.edu> dh...@bsu-cs.bsu.edu (Rahul Dhesi) writes:
>I think Dr. Tanenbaum should consider finding a different publisher for
>the revised Minix book and disks.
No. (1) I have a contractual obligation to P-H and would certainly be sued
if I tried to breach it, and (2) although they have screwed up the software
distribution, they have done ok on the book. If I were to find a software
publisher, I bet they would screw up on the book. Nevertheless, P-H is
definitely learning about software. They now have a full-time customer
service software person, for example, and I will try to train him on MINIX
next time.
VISION ON THE FUTURE OF EDUCATION:
I think that in the coming decade, many universities will expect/require
all students to buy a computer. If you take a $2000 computer and write it
off over four years, you get $500 per year. When added to private college
tuition of $10K per year, it only adds 5% and the student gets to keep the
computer afterwards. At state schools it will take a little longer, but not
much.
These machines will need software for physics labs, biology labs, library
access etc. It is my bet that 99% of it will be written by free lancers,
mostly professors, the same way it is with books. There are very few
corporations that churn out textbooks as their main product. Thus I expect
college software to go essentially the same route as college textbooks.
In this case, it makes sense that the distribution is handled by book
publishers. Whether they are selling a book or a box of diskettes hardly
matters--the manufacturing is contracted out to third parties in both
cases. It is just a 7" x 10" x 2" lump with an ISBN number in both cases.
Prentice-Hall is far and away the biggest (and as far as I am concerned)
the best computer science textbook publisher, and I expect them to be the
same in educational software as well. I know plenty of other authors, and
have heard about other people's experiences, and while P-H is certainly not
perfect, I am by-and-large pretty satisfied. If any of you are thinking of
writing textbooks or educational software, they are definitely worth
considering.
I guess it all boils down to what MINIX is. I still see it as primarily
an educational system. I can't imagine any Fortune 500 company choosing it
over UNIX. Correct me if I am wrong, but I think it falls under the
heading Educational/Instructional rather than Operating systems (see page
336 of the July Byte Magazine).
Andy Tanenbaum (a...@cs.vu.nl)
Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!
uunet!mcvax!hp4nl!targon!gert
From: g...@targon.UUCP (Gert Kanis)
Newsgroups: comp.os.minix
Subject: Re: The future of MINIX
Summary: What about MINIX ST (Atari)
Keywords: MINIX , Atari ST , disk compatibility
Message-ID: <575@targon.UUCP>
Date: 12 Jul 89 19:37:05 GMT
References: <2835@ast.cs.vu.nl> <563@prles2.UUCP>
Reply-To: targon!g...@nluug.nl (Gert Kanis)
Followup-To: comp.os.minix
Organization: Nixdorf Computer , P.O. Box 29,Vianen, The Netherlands
Lines: 64
In article <5...@prles2.UUCP> meule...@cstw01.prl.philips.nl
(Frans Meulenbroeks) writes:
>[lots of text discarded]
>In article <2...@ast.cs.vu.nl> a...@cs.vu.nl (Andy Tanenbaum) writes:
>[...]
>>Anyway, I have decided to use Bruce's code as the basis for V2.0 (subject to
>>Prentice-Hall not vetoing a 900 page book).
>>[...]
>>When all that is done, we will have a protected mode system that is based
>>on POSIX and reasonably fast for small machines. MINIX seems to be
>>evolving in the direction of something more than an academic toy ...
>>
Sounds good, I'll bet all those with 80x86's will be most happy about
this decission. But what's the future of those other versions?
>>An additional note. Amiga MINIX is actually up and running. It is now
>>being tested. Furthermore, MINIX 1.3 is being ported to the SPARC.
>>
>>Getting all these versions back together,and then POSIX-based is going to be
>>a job on the order of cleaning out the Augean Stables, and I don't have a
>>Hercules card.
>>Andy Tanenbaum (a...@cs.vu.nl)
>
>Ok. That amounts to 5 different versions:
>for 8088, 286/protected, ST, Amiga, SPARC.
>
>As far as getting these together:
>This can really become a pain.
>However, I would support such an integration very much.
>
>Frans Meulenbroeks (meule...@cst.prl.philips.nl)
> ( or try: ...!mcvax!phigate!prle!cst!meulenbr)
So we see a clear path concerning the devellopment of MINIX in the next few
years. One of the goals was (apart from the teaching aspects) portability.
Looking at already 5 versions one cannot deny this has succeeded. But will
we have 5 different versions soon? I really hope not, that would depart
from the original idea.
OK , I know that everybody can hack around to make his own version,
what I mean is the reference, the thing you can make your diffs to, the
version of The Book. (or Books :-) )
SOME QUESTIONS I'D LIKE TO SHARE.
1)At this moment we have MINIX ST 1.1 that is said to equal MINIX PC 1.3 .
So why isn't it CALLED MINIX ST 1.3 ?
2)Why is it impossible to read disks written on the other version although
the original OS'es of PC and ST can do so easily? (don't know about these
other versions). The (ST) documentation says: The goal is not TOS (Atari)
but UNiX compatibility. What about making MINIX compatible with itself.
(I know someone said this before).
I hope 2.0 will again become available for many computers. There is
more than this PECEE. (You might have guessed I have an Atari :=) )
Don't think I'm unhappy with MINIX but this keeps bothering me.
+-----------------------------------------------------------------+
| The smoker you drink,| Gert Kanis, SWP |
| the W.C. | Nixdorf Computer BV, Postbus 29 |
|----------------------| 4130 EA Vianen, Netherlands. |
| I do not represent | E-mail : targon!g...@nluug.nl |
| anyone elses opinion.| or ..!mcvax!targon!gert |
+-----------------------------------------------------------------+
Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!
uunet!mcvax!hp4nl!botter!star.cs.vu.nl!ast
From: a...@cs.vu.nl (Andy Tanenbaum)
Newsgroups: comp.os.minix
Subject: Re: The future of MINIX
Keywords: MINIX , Atari ST , disk compatibility
Message-ID: <2880@ast.cs.vu.nl>
Date: 15 Jul 89 09:44:34 GMT
References: <2835@ast.cs.vu.nl> <563@prles2.UUCP> <575@targon.UUCP>
Reply-To: a...@cs.vu.nl (Andy Tanenbaum)
Organization: VU Informatica, Amsterdam
Lines: 26
In article <5...@targon.UUCP> targon!g...@nluug.nl (Gert Kanis) writes:
>1)At this moment we have MINIX ST 1.1 that is said to equal MINIX PC 1.3 .
>So why isn't it CALLED MINIX ST 1.3 ?
Johan and I felt it strange to call the first release 1.3. Maybe it isn't.
Also, it is not exactly 1.3.
>2)Why is it impossible to read disks written on the other version although
>the original OS'es of PC and ST can do so easily?
I am not really sure. Probably we slipped up. The Amiga version should be
able to read MINIX-ST disks, so we have tried to avoid that mistake again.
>I hope 2.0 will again become available for many computers. There is
>more than this PECEE. (You might have guessed I have an Atari :=) )
It may be a long road. What I do realistically hope to do is have FS and MM
be absolutely identical on all versions. That is one of the advantages of
splitting them off from the kernel. After V2.0 is done for the PC, I hope
we can find some ambitious volunteer to try to retrofit the ST and Amiga
kernels to the V2.0 kernel, where possible. I don't know if this will work.
The SPARC is yet another story, since the register window business is quite
different than all the other machines.
Andy Tanenbaum (a...@cs.vu.nl)