ast@cs.vu.nl (Andy Tanenbaum) (05/22/89)
Bruce Evans has clearly done a great deal of high quality work in his recent giant posting and I am sure many people are interested in it. Furthermore, I hate to be a party pooper, but... According to P-H's sales figures, the PC version of MINIX is still outselling the AT version by a wide margin. This means that there are a lot of 8088s still out there. Consequently, I am going to base V2.x on 1.4a, not on Bruce's version. I just don't want all that extra complexity on the 8088 (remember, the goal was a teaching system). This means that if you convert to Bruce's system now, you may have trouble converting to 2.x (POSIX-based) later. It is clearly up to you which way you go, but at least you should be aware that there is a fork in the road here. The long term plan for MINIX is to wait until not only the 8088, but the 286 has also vanished, and make MINIX 3.x (probably in 4 or 5 years) entirely a 386/486/585/686/786 based system, assuming these are all architecturally compatible. The 286's dwarf segments are a real nuisance, and hardly compatible with the Atari, Amiga, and other versions of MINIX in progress, whereas on the 386 one can use a single 32-bit segment (Motorola mode) and implement that fairly cleanly. Andy Tanenbaum (ast@cs.vu.nl)
michaelw@microsoft.UUCP (Michael Winser) (05/23/89)
In article <2570@ast.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes: >still out there. Consequently, I am going to base V2.x on 1.4a, not on Bruce's >version. I just don't want all that extra complexity on the 8088 (remember, >the goal was a teaching system). Is this goal still reasonable? I would guess that most of the buyers are using MINIX to learn about UN*X (but not necessarily from an os design point of view). >This means that if you convert to Bruce's system now, you may have trouble >converting to 2.x (POSIX-based) later. It is clearly up to you which way you >go, but at least you should be aware that there is a fork in the road here. ^^^^:-) >The long term plan for MINIX is to wait until not only the 8088, but the 286 >has also vanished, and make MINIX 3.x (probably in 4 or 5 years) entirely >a 386/486/585/686/786 based system, assuming these are all architecturally >compatible. The 286's dwarf segments are a real nuisance, and hardly >compatible with the Atari, Amiga, and other versions of MINIX in progress, >whereas on the 386 one can use a single 32-bit segment (Motorola mode) and >implement that fairly cleanly. Four or five years is a long time to wait for a MINIX that can effectively use the 386. By that time we may all have moved to i860's or i960's! I don't want to start yet another intel vs. motorola discussion here, but to implement MINIX in a single 32-bit segment on the 386 is to ignore much of the parts capabilities. The 386/486 segments and hardware tasks are ideal for MINIX. All the messy fork blitting that the Atari has to do is because there is no mmu. Michael P.S. Isn't it nice to know that the x86 line must stop with the 686. The 786 is/was a specialised graphics part (not very flexible, but pretty cool nonetheless). -- /\ no guts michael winser \/ no glory microsoft corp. (206) 882-8080, michaelw@microsoft.uucp
frank@croton.DEC.COM (Frank Wortner) (05/24/89)
I can see the headlines now:
Open Minix Foundation Formed
Minix International Announced
:-)jds@mimsy.UUCP (James da Silva) (05/27/89)
In article <2570@ast.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes: > According to P-H's sales figures, the PC version of MINIX is still > outselling the AT version by a wide margin. This means that there are a > lot of 8088s still out there. Consequently, I am going to base V2.x on > 1.4a, not on Bruce's version. I just don't want all that extra complexity > on the 8088 (remember, the goal was a teaching system). While I personally plan on running Bruce's version, I agree with Dr. Tanenbaum. `Teaching Minix' as shipped from Prentice Hall doesn't need to have all the bells and whistles. It also doesn't need to be POSIX compatible where such compatibility would complicate Minix. Keep it simple! However, I urge Dr. Tanenbaum to look very closely at Bruce's changes. Many are bug fixes and improvements that have nothing to do with protected mode. It would be silly to ignore so many fixes. Bruce documented every change he made to each source file in the CHANGES file present in every directory; I would say that this is probably the best-documented Minix update I've seen. Much better than the 1.2 and 1.3 updates. > This means that if you convert to Bruce's system now, you may have > trouble converting to 2.x (POSIX-based) later. It is clearly up to you > which way you go, but at least you should be aware that there is a fork > in the road here. I think that the people of the net will help here as they have in the past. I did an upgrade kit for Minix 1.2, Vince Broman did one for 1.2 and one for 1.3d. There's no reason to think that others will not do the same in the future. This should go without saying, but those people serious about keeping track of changes that come over the net while making their own mods should be using a revision control system. I use the SVC system posted here a while back; there has also been a port of RCS to Minix. I've got Minix 1.1, 1.2, 1.3d, 1.4a and Evans' patches all online and easily accessible. Those with 386's or better will most likely borrow more and more from the GNU project; what Prentice Hall does with Minix five years from now just doesn't seem relevent to me, for OS hacking or `learning Unix cheaply'. There will still be a need for a teaching OS, and I trust that Dr. Tanenbaum will provide an excellent one. > Andy Tanenbaum (ast@cs.vu.nl) Jaime ........................................................................... : domain: jds@mimsy.umd.edu James da Silva : path: uunet!mimsy!jds
wbeebe@bilver.UUCP (bill beebe) (05/29/89)
In article <2570@ast.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes: > >Bruce Evans has clearly done a great deal of high quality work in his recent >giant posting and I am sure many people are interested in it. Furthermore, >I hate to be a party pooper, but... > >According to P-H's sales figures, the PC version of MINIX is still outselling >the AT version by a wide margin. This means that there are a lot of 8088s >still out there. Consequently, I am going to base V2.x on 1.4a, not on Bruce's [some stuff deleted] >This means that if you convert to Bruce's system now, you may have trouble >converting to 2.x (POSIX-based) later. It is clearly up to you which way you >go, but at least you should be aware that there is a fork in the road here. > >The long term plan for MINIX is to wait until not only the 8088, but the 286 >has also vanished, and make MINIX 3.x (probably in 4 or 5 years) entirely >a 386/486/585/686/786 based system, assuming these are all architecturally [more stuff deleted] I hate to be a party pooper too, but I find Bruce Evan's postings what PC Minix needs to move into the larger world of the 386. I find it interesting you base your figures on P-H's sales figures, without qualifying who is really buying Minix. It would be interesting to see what systems at major universities are running Minix. I have found that the majority of systems in U.S. universities are donated ATs, with the switch to 386 AT architectured machines. And we can roundly curse the "dwarf segments" on the 80286 under protected mode, but there is something to be said about 80286 PM code; it run's with little or no modification on 80386 machines. One other thing you need to think about, Mr. Tanenbaum, and I'll draw a picture to help illustrate my point. +-------------------+---+---+---+---+----------------+ | BASE 31...24 |23 |22 |21 |20 | LIMIT 19...16 | | |G |X |O |AVL| | +-------------------+---+---+---+---+----------------+ It's a crude picture of the upper 16 bits of the 80386 descriptor quad word. The high 16 bits were zero in the 80286, but in the 80386 we have four more bits in the limit field and eight more in the base. If we lave the base alone, the segment limit is now 1 meg, not 64 K. Using the current AT Minix architecture, that means programs can span 2 megs; 1 meg for code and 1 meg for data. It also means that segments have a one byte granularity. Using the base and setting the granularity bit, we can have segment limits up to 4 gig with a granularity of 4K bytes. I find your reasoning why Bruce Evan's work will cause a split to be flawed and technically imcompetent. I support Evan's work and will do whatever I can to add to the existing body of PM Minix code. As a matter of perspective one of our local Minix group here in Orlando, Florida ,Jim Smith, has stated that he had the least number of problems and glitches patching his version of Minix with Evan's posting. It has been one of the easiest, if not the easiest. And Jim has faithfully installed every major posting that has appeared in the conference. Evan's work was merged with Minix 1.3 purchased from P-H, and is running on a 20 MHz 80386 machine with 4 megs of memory, an Adaptec RLL controller, and an ST277. The 80386 AT bios drive tables were patched so that Minix boots from the RLL drive with the standard AT wini code. The Adaptec is register compatible with the WD standard. I'm sorry for the tone of my message, but Minix is far larger than you apparently realize. I would strongly recommend you do more research and deeper thinking about Minix's future path.
jds@mimsy.UUCP (James da Silva) (05/29/89)
In article <216@bilver.UUCP> wbeebe@bilver.UUCP (bill beebe) writes: > ... One other thing >you need to think about, Mr. Tanenbaum, and I'll draw a picture to help >illustrate my point. > > +-------------------+---+---+---+---+----------------+ > | BASE 31...24 |23 |22 |21 |20 | LIMIT 19...16 | > | |G |X |O |AVL| | > +-------------------+---+---+---+---+----------------+ > >It's a crude picture of the upper 16 bits of the 80386 descriptor quad >word. The high 16 bits were zero in the 80286, but in the 80386 we have >four more bits in the limit field and eight more in the base. If we lave >the base alone, the segment limit is now 1 meg, not 64 K. Using the current >AT Minix architecture, that means programs can span 2 megs; 1 meg for code >and 1 meg for data. It also means that segments have a one byte granularity. >Using the base and setting the granularity bit, we can have segment limits >up to 4 gig with a granularity of 4K bytes. I find your reasoning why >Bruce Evan's work will cause a split to be flawed and technically >imcompetent. Bill, I must be even more imcompetent (sic) than Dr. Tanenbaum, as I don't see your point at all. Could you draw me another picture? Seriously, the fact is that it is tricky for a 32-bit kernel to support 16-bit processes. And out of the question for a 16-bit kernel to support 32-bit processes. So what choice do we have? The 16-bit and 32-bit kernels have to be different binaries, at least. The sources can be largely the same, if you are very careful. But not entirely the same. So, should the PC Minixers have to carry around the extra complexity required to support protected mode, in the base Minix release? I don't think so. I think this was all Dr. Tanenbaum was trying to say. Then, should we cripple the 32-bit kernel to increase compatibility with the PC version of Minix? I hope not! Should Prentice Hall market ANOTHER version of Minix for the protected mode? Maybe, but who cares? How would it help you or me? Now, does this mean that we won't have 32 bit Minix for our 386's until Prentice Hall and AST decide to do it? No, of course not. Nit Pick: Bit 21 of the descriptor is not `O', it is `0', as in Undefined. Jaime ........................................................................... : domain: jds@mimsy.umd.edu James da Silva : path: uunet!mimsy!jds
hedrick@geneva.rutgers.edu (Charles Hedrick) (05/30/89)
This is really a plea directed at ast. Can we please make some kind of compromise here? I'm in a situation that I think is shared by many of the readers here. I'm a hacker. I'd like an OS for my home machine that I have source to. I'd also like an OS that I can recommend for students to put on their PC's. At the moment Minix is really the only alternative. Gnu OS is the major alternative, but it doesn't exist yet. Even when it does, chances are most of the people on this list won't be able to afford machines that run it, since the Gnu project in general seems to like large software that requires large machines. Minix does very well in using limited resources. Just what the home hacker community needs. But it's possible to have too much of a good thing. 64K programs carry "small is beautiful" too far. I've collected a lot of software for my PC (which I currently use under Microport System V). Almost none of this will run in 64K. There's a middle ground between Gnu Emacs and ed. That middle ground is occupied by a large amount of stuff that is posted to the net by hackers for PC's, e.g. various microemacses, KA9Q TCP/IP, sc, kermit. This is all reasonably small-scale stuff. It mostly runs fine under MS-DOS. But almost none of it will run under Minix. I had to remove all the help strings from kermit to bring it up under Minix, which is an abomination. The question is what Minix is supposed to be. OK, originally it was intended as an example for OS courses. I'm sure it still is fine for that. But I'm much more concerned with producing students who know how to use OS's than how to write them. And currently they can't really use Minix. So they end up running MS/DOS, and learning nothing at all about how an OS should really support their programming. Can't we do something to lift the curse of 64K from Minix sooner than 4 years from now? Yes, I agree that the 286 is an abortion. The large model is an obscenity. But I'd much rather see my students using a slightly scatalogical Minix than MS/DOS. Bruce's 286 patches are a useful starting point. But what we need most is a large-model compiler, and the ability to run large-model programs even on the 8088. I might even be willing to work on it if I saw some signs that you'd accept the results.
HELMER%SDNET.BITNET@vm1.nodak.edu (Guy Helmer) (05/30/89)
>In article <2570@ast.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes: >> >>Bruce Evans has clearly done a great deal of high quality work in his recent >>giant posting and I am sure many people are interested in it. Furthermore, >>I hate to be a party pooper, but... >> >>According to P-H's sales figures, the PC version of MINIX is still outselling >>the AT version by a wide margin. This means that there are a lot of 8088s >>still out there. Consequently, I am going to base V2.x on 1.4a, not on >Bruce's >[some stuff deleted] > >I hate to be a party pooper too, but I find Bruce Evan's postings what PC >Minix needs to move into the larger world of the 386. I find it interesting >you base your figures on P-H's sales figures, without qualifying who is >really buying Minix. It would be interesting to see what systems at major >universities are running Minix. I have found that the majority of systems >in U.S. universities are donated ATs, with the switch to 386 AT architectured >machines. As a recent graduate with a B.S., I know for a fact that at least in all the schools I've seen, AT machines are rare. A small Minix based on the 8088 is necessary if undergrad classes are to be taught based on Minix. > I find your reasoning why >Bruce Evan's work will cause a split to be flawed and technically >imcompetent. I support Evan's work and will do whatever I can to add >to the existing body of PM Minix code. As a matter of perspective one >of our local Minix group here in Orlando, Florida ,Jim Smith, has stated >that he had the least number of problems and glitches patching his version >of Minix with Evan's posting. It has been one of the easiest, if not >the easiest. I agree that Bruce's improvements in interrupt handling are useful and should be included in Dr. Tannenbaum's Minix. I do not believe that Dr. Tannenbaum should be asked to include protected mode support in Minix. Real Minix is a teaching operating system. What Bruce's changes do is create a Minix that is not longer the small teaching system but a step towards a Minix that could be used in place of commercially marketed un*x. >I'm sorry for the tone of my message, but Minix is far larger than you >apparently realize. I would strongly recommend you do more research >and deeper thinking about Minix's future path. I believe that Dr. Tannenbaum has Minix on the correct path. The network is presently creating a new version of Minix, one that the network will have to support by itself. -- Guy Helmer Opinions are mine, all mine.
jca@pnet01.cts.com (John C. Archambeau) (05/31/89)
If you want Minix to be more than it already is, you are going to have to put
it in. I commend author the 286 protect mode upgrade kit and its people like
that that make Minix more than what it was originally intended for. I have no
qualms about Dr. Tanenbaum keeping Minix the way it is for educational
purposes, but for those of us that want to make Minix more than an educational
tool and experience with operating systems, we're going to have to pitch in to
make it a reality. Rather than complaining about what Minix lacks, why not
put your head together with people on here on how to make it do what you want?
I have kicked around the idea of how to get beyond the 64K code/64K data
segment problem and have talked to others about how to get around this, and
here's what I have come up with (with help from others). More memory can be
accomplished by the following;
1. Shared libraries
2. swapping code segments
3. full swapping
4. virtual memory
Each of these has its fruits and varying levels of difficulty to implement.
But needless to say that if you want to expand Minix to get beyond its current
limitation of programs, you're going to have to put it in. And putting our
heads together is the whole idea why these Usenet conferences exist in the
first place. I am more than happy to discuss with anybody (as time permits)
on ways to improve Minix. But one thing I must say, don't expect Dr.
Tanenbaum to do it, he's most likely busy enough as an instructor and can't
maintain a wish list of what you want in Minix. If you want something in
Minix (as I've been continually stressing in this article), YOU are going to
have to make an effort to add it yourself or with help from those of us here.
I see the reasoning behind why Minix is designed the way it is and have no
intention of defeating that purpose.
One last thing that I would like to add here, I would like to additionally
commend those who have made contributions to Minix, both Dr. Tanenbaum and
those who have written bug fixes, improvements, and/or ports to other
machines.
JCA
UUCP: {nosc ucsd hplabs!hp-sdd}!crash!pnet01!jca
ARPA: crash!pnet01!jca@nosc.mil
INET: jca@pnet01.cts.comart@felix.UUCP (Art Dederick) (05/31/89)
In article <16497@louie.udel.EDU> HELMER%SDNET.BITNET@vm1.nodak.edu (Guy Helmer) writes: >I believe that Dr. Tannenbaum has Minix on the correct path. The network >is presently creating a new version of Minix, one that the network will >have to support by itself. And I thought we were getting away from multiple versions of the same OS. How naive I was. I see the AT&T/BSD wars beginning all over again. Flames to /dev/null, intelligent comments to felix!art. Art D.
wbeebe@rtmvax.UUCP (Bill Beebe) (06/01/89)
In article <17779@mimsy.UUCP> jds@mimsy.umd.edu (James da Silva) writes: >I must be even more imcompetent (sic) than Dr. Tanenbaum, as I don't see >your point at all. Could you draw me another picture? > >Seriously, the fact is that it is tricky for a 32-bit kernel to support >16-bit processes. And out of the question for a 16-bit kernel to support >32-bit processes. So what choice do we have? The 16-bit and 32-bit [stuff deleted] >Nit Pick: Bit 21 of the descriptor is not `O', it is `0', as in Undefined. > >Jaime No, the incompetent boob is me, the guy who left his brain on idle while his hands went wild on the keyboard. If I had thought about the the 16- vs 32-bit kernel problems I would have killed the comment, or at least put more thought into it. The points I was trying to make are: 1) once you have 80286 protected mode, you can move up to the 80386 and use the code as-is, assuming that you have the same video, serial, and mass storage devices on an AT architecture machine. You will have to remain in 16-bit mode, and migration to 32-bit will be no trivial matter. But it is not impossible, and is in fact (at least to me) an inviting challenge. 2) it would be nice to have a teaching 32-bit Minix. Why can't we have some say-so in the process? Bruce Evan's work is so good, and Dr. Tanenbaum seemed to slam the door on that work and all it promises. I became very angry at the apparent tone of the message. As for '0' vs 'O', I'm suprised I can type at all, considering my coke-bottle bottom glasses. I'll try to keep my typos to a minimum, or at least not make them in overly obvious areas.
paula@bcsaic.UUCP (Paul Allen) (06/01/89)
I've been watching the discussion regarding the fate of Bruce Evans' protected mode diffs and feel I must comment. We seem to be standing at a crossroads. We can choose either to maintain the IBM version of Minix as a toy operating system, or we can evolve it to support current hardware. The Atari version of Minix was apparently 'real' at the outset, judging by the amount of current Unix software that runs on it. The IBM version is a toy that supports current software either with great difficulty or not at all. I fail to see the value in making the current IBM version of Minix POSIX-compliant, when much of the available POSIX- compatible code out there won't even compile. The ideal of a small, simple operating system for teaching purposes is adequately served by the 1.3 version of PC Minix. The real value of POSIX compatibility will come when there is a 386 version of Minix that can take advantage of it. An adequate stop along the way would be a 286 PM version with a large- model compiler. In my view, the next version of PC Minix should be a 'real' operating system, capable of supporting most current software. While there is certainly a place for a small Minix that fits on antiquated hardware, the strength and vitality of an operating system depend upon the efforts of people like Bruce Evans who are pushing the limits. If we set the limits artificially tight, we will choke off future innovation. I sincerely hope that Dr. Tanenbaum will reconsider his decision not to adopt Bruce's version. Paul Allen -- ------------------------------------------------------------------------ Paul L. Allen | pallen@atc.boeing.com Boeing Advanced Technology Center | ...!uw-beaver!bcsaic!pallen
Leisner.Henr@xerox.com (marty) (06/02/89)
I haven't examined Bruce Evan's work too carefully but it seems very neat and well-documented. I feel a protected mode implementation of Minix is a most useful thing for a teaching tool. I regularly use Ms/Dos and Unix machines -- software development on Ms/Dos generally requires constant booting (I wrote a TSR to at least break out of an infinite loop). In college, my OS course dealt with aspects of protection between processes and stressed the importance of "the system shouldn't crash". Minix ignores these protection issues. I kinda get annoyed when computers crash -- I suppose developers trained on Minix may well build the next generation of Ms/Dos machines (god forbid). I think Andy's desire to ignore protection issues may be expedient -- how about advanced Minix? What I would like to see is a graceful way to add more sophisticated features (i.e. memory protection, swapping, etc) in a configurable manner. This way Minix can serve as both a teaching tool and a useful system. One of the problems with Pascal (at least the way I understand it) is it was never intended to accomplish anything in a production environment -- it was a teaching tool. So pascal vendors impelemented various extension to the language (this was the case 8 years ago when I learned C and Pascal). It is not an easy task to develop an operating system to support multiple processors with various hardware features (i.e. how context switching takes place, memory/no memory protection, etc). But I think with some careful redesign Minix can serve as a teaching tool (in the present configuration) and a more useful, more powerful system supporting multiple users with memory protection on 286/386 machines. One of the problems is the copyrighted status of the source -- the idea of 400k of patches doesn't appeal to me, and the multiple levels of patches seem to be a pain. If a group of us want to take a protected mode activity off-line, I'd like to be able to pick up a complete kernel. I've never been good at applying patches. Also since no source control system is used in Minix, it's always been hard for me to know exactly what I got. I'm pretty impressed by Minix. GNUos (if it ever appears) won't have a chance of ever running on PC XT clones. Minix seems like a seems which has a path from 8086/80286/80386 in a reasonable way if changes are made. A few minor extensions would make Minix far more usable to me: 1) support TCP/IP (I'm not going to ask for XNS) -- i.e. ftp/telnet would give it real world usefulness. I'd be happy to discuss how to do this with anyone else interested. 2) support 386 protected mode with 32 bit addresses (mainly to run gnu C). 3) Multiple sessions off the console (I implemented a buggy version of this -- someone else did also I believe. Did it ever make it into the release?) 4) A larger buffer cache (I don't think 40k can be of much use). 5) Shared text and a sticky bit (this would be most useful addition) A few major problems I found with Minix which I think limit its usefulness: 1) The C compiler (sorry, I've never been able to accomplish much with it when I port code). And it's slow. And the benchmarks I've run indicate it's code generation wasn't competive. (does current minix support split I&D?) I've did all my Minix development on Ms/Dos using Aztec C. 2) Lack of a clean way to manage more sophisticated memory models (I had to make major changes to begin to allow this but never got there). I find a memory model with 64k data, 64k text, 64k stack and N 64k malloced segments to be most useful (very few applications need > 64k code). It would be nice if instead of the T, D and S model, a variable number of segments were supported. I think it would be a good idea if Prentice-Hall and ast free'd up the source code to the operating system so people could easily let other people look at new kernels. I would gladly share my 80286 protected mode stuff I could distribute it intact -- at the time I was doing it I had no space on my hard disk to leave a distribution. It seems this would not jeopardize PH sales since booting a system without the source code to the operating system is quite a formidable task. I haven't done a Minix work in a year now. Hopefully I'll have a chance soon to catch up, look at my work, look at Bruce's work, look at Andy's latest release. Now that I finally have a sun386i I should be able to run DOS, Minix and Unix all on the same machine and generate binaries with various compilers. I would like to see a way to release 88 Minix, 286 Minix and 386 Minix off one distribution source (but not necessarily one binary). marty ARPA: leisner.henr@xerox.com GV: leisner.henr NS: martin leisner:wbst139:xerox UUCP: hplabs!arisia!leisner
henry@utzoo.uucp (Henry Spencer) (06/04/89)
In article <11989@bcsaic.UUCP> paula@bcsaic.UUCP (Paul Allen) writes: >... We can choose either to >maintain the IBM version of Minix as a toy operating system, or >we can evolve it to support current hardware. The Atari version >of Minix was apparently 'real' at the outset... Hey, toy operating systems for toy hardware, real ones for real hardware. :-) Anything with a cpu whose number ends in "86" is a toy. :-) :-) -- You *can* understand sendmail, | Henry Spencer at U of Toronto Zoology but it's not worth it. -Collyer| uunet!attcan!utzoo!henry henry@zoo.toronto.edu
muller@munnari.oz (Paul Muller) (06/04/89)
Firstly I apoligise to anyone offended by the summary line....
I think it is rather inconsiderate to talk about Minix as if it was
collectively owned by the netlanders (although much of it would not exist
without them and they all deserve credit), Andrew and PH will differ on
that point no-doubt about it, though as ast so wonderfully put it, there
would appear to be a "fork" in the road after the work of Bruce hit the net.
Minix first and foremost is the poor student's teaching OS. It serves its
purpose above and beyond the call of duty, and that is the point. If you
were a student you wouldn't fancy wading through all those #ifdefs for two
days just to find you made a mistake early on in the code and that's why
none of what the lecturer is saying fits together. I am a student and find
nothing more annoying than conditional compilation, it ruins your day and
often clouds the purpose of the code.
I am not going to propose anything radical in regards as to what should be
done, I will just try and put together some ideas that have floated across
the battle table (and try to foresee new ones).
The first idea is to KISS. Sounds nice huh? ;-) Seriously, the first
thing is to get a standard piece of PC code that will form the kernal (in
the larger sense) of the Minix book. Much as it is now. Students can still
boot up on the two floppy PCs they have at home and happily hand in work
for the teacher with the knowledge that comes from looking at the guts of
an OS. 1.4a contains more or less than what is needed to do this. POSIX
compliance is probably important from the point of view of teaching the
ideas in a real world sense (we can't always patch the C compiler!).
The second is the 'upmarket' Minix that everyone seems to think is so
important, why? Most people who got into Minix for reasons other than formal
education just wanted to 'hack around', you were happy with Minix then, why
not now, the old case of "give an inch take a mile" or more "too much of a]
good thing" :-) The idea then is to produce a bunch of either, patches or
modules (FS,MM,xx_wini,etc) that cater for individual tastes and needs.
People can then make up a Minix system to suit them, you could have a file
in /etc that would list all options loaded or have an internal table hard
coded into Minix that would tell applications if they could use certain
features or not at compile (or patch) time.
If people are so into the idea of 'real life' Unix, then checkout AT&T, SCO,
etc offerings. They produce different BINARIES for each processor they
support, most proabably different sources as well. Xenix (tm) 286 won't
run 386 code, so why all the hoopla about Minix compatibility? What is
needed is some form of arbitration committee to decide what goes in the
upmarket version. This should not just rest on ast's shoulders, I prefer
he gets more time to write his great books! :-)
The whole idea is asking for trouble, but there are sooooo many things that
poeple in the Minix user community want/need/loath/despise in minix that can be
done on paper but fall done trying to fit in with the 'small is beutiful' model
, Virtual memory, windowing, memory model work, swapping and networking just
to name a few.
I like what Bruce and others are doing for Minix, but the seminal idea
of ast's based itself on V7, "because of its simplicity and elegance" and this
is foremost in my mind when I hear talk about changing the listing that will
appear in the back of the second revision of The Book.
What do others feel? The ST was a step in another direction, what do users
of ST AND PC (that is people who have used (are using) both) think about
the differences in the code/machine?
paulstailey@iris613.gsfc.nasa.gov (Ken Stailey) (06/04/89)
In article <1989Jun4.025012.8674@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >In article <11989@bcsaic.UUCP> paula@bcsaic.UUCP (Paul Allen) writes: >>... We can choose either to >>maintain the IBM version of Minix as a toy operating system, or >>we can evolve it to support current hardware. The Atari version >>of Minix was apparently 'real' at the outset... > >Hey, toy operating systems for toy hardware, real ones for real hardware. :-) >Anything with a cpu whose number ends in "86" is a toy. :-) :-) This was true up until the 386. Q: What does the 386 call a 32-bit address space? A: a segment. :-) INET stailey@iris613.gsfc.nasa.gov UUCP {sundc ames}!dftsrv!iris613!stailey
jk0@sun.soe.clarkson.edu (Jason Coughlin) (06/05/89)
From article <11989@bcsaic.UUCP>, by paula@bcsaic.UUCP (Paul Allen): > We seem to be standing at a crossroads. We can choose either to > maintain the IBM version of Minix as a toy operating system, or > we can evolve it to support current hardware. The Atari version Pardon me this is NOT a flame, but "we" seem to be saying "WE" a little too often. I think we should all take a small step back and realize that Minix is Dr. Tanenbaums baby - NOT ours. I realize we've all been "guinea pigs" with Minix and we all love it, but still - it's his creation, not ours. What's your vote Dr. Tanenbaum? > ... The Atari version > of Minix was apparently 'real' at the outset, judging by the > amount of current Unix software that runs on it. The IBM version > is a toy that supports current software either with great difficulty > or not at all. But the Atari ST isn't exactly the ideal hardware either :-). > > I sincerely hope that Dr. Tanenbaum will reconsider his > decision not to adopt Bruce's version. (Me too :-) -- Jason Coughlin ( jk0@sun.soe.clarkson.edu , jk0@clutx.BITNET )
jca@pnet01.cts.com (John C. Archambeau) (06/06/89)
Toy? Not really. The 80x86 are bad (especially x > 2). The 80286 is just
brain damaged, not a toy really, just a labotomized chip. The 8086 isn't bad
with LIM EMS 4.0. You may regard the 80x86 family as a toy, and that is your
opinion, but just remember, there are those of us who can and have worked out
the brain damaged hardware. Even the best Unix boxes have their problems, the
Unisys 7000 is a classic example with its brain damaged floating point
instructions. So before you go harping on our 'toys', take a good look at
your own hardware first. I have yet to see anything that is perfect when it
comes to hardware.
JCA
/*--------------------------------------------------------------------------*
* That's not an operating system, this is an operating system!
*--------------------------------------------------------------------------*
* UUCP: {nosc ucsd hplabs!hp-sdd}!crash!pnet01!jca
* APRA: crash!pnet01!jca@nosc.mil
* INET: jca@pnet01.cts.com
*--------------------------------------------------------------------------*/
#include <disclaimer.h>pcm@iwarpj.intel.com (Phil C. Miller) (06/06/89)
In article <216@bilver.UUCP> wbeebe@bilver.UUCP (bill beebe) writes: >In article <2570@ast.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes: [stuff about protected mode 286 being left out of future releases of MINIX] [response from Bill Beebe about Andy's comments] >One other thing >you need to think about, Mr. Tanenbaum, and I'll draw a picture to help >illustrate my point. I am embarassed for you that you feel you need to patronize a prominent figure in the field of computer science. [more technocratic discussion] >[...] I find your reasoning why >Bruce Evan's work will cause a split to be flawed and technically >imcompetent. I find your manners to be astonishingly crude. >I'm sorry for the tone of my message, but Minix is far larger than you >apparently realize. I would strongly recommend you do more research >and deeper thinking about Minix's future path. Frankly, YOU are much SMALLER than you apparently realize. It is totally unnecessary to be so abrasive in making your point. Grow up. Phil Miller
wbeebe@rtmvax.UUCP (Bill Beebe) (06/07/89)
In article <4523@omepd.UUCP> pcm@iwarpj.UUCP (Phil C. Miller) writes: >In article <216@bilver.UUCP> wbeebe@bilver.UUCP (bill beebe) writes: > >Frankly, YOU are much SMALLER than you apparently realize. >It is totally unnecessary to be so abrasive in making your point. >Grow up. > > >Phil Miller Mr. Miller, I won't argue the point about my crude display of manners. They were and I have since made a (weak?) attempt at an apology. I'll accept dressing downs where necessary, but it would help to follow conversational threads before forming replies. This small rule applies to all of us. This is a public apology to Dr. Tanenbaum and all others whom I offended with my original message.
des@berlioz (Desmond Young) (06/09/89)
In article <16698@louie.udel.EDU>, Leisner.Henr@xerox.com (marty) writes: > I'm pretty impressed by Minix. GNUos (if it ever appears) won't have a > chance of ever running on PC XT clones. Minix seems like a seems which has > a path from 8086/80286/80386 in a reasonable way if changes are made. A > few minor extensions would make Minix far more usable to me: > 1) support TCP/IP (I'm not going to ask for XNS) -- i.e. ftp/telnet would > give it real world usefulness. I'd be happy to discuss how to do this with > anyone else interested. > marty > ARPA: leisner.henr@xerox.com > GV: leisner.henr > NS: martin leisner:wbst139:xerox > UUCP: hplabs!arisia!leisner Well...., I have Phil Karn's TCP-IP (NET) package running under MINIX. But, I have not posted it for the following reasons: 1. Only the original Version 1.000000 software will compile in 64K code, the MINIX compiler is AWFUL. 2. I have written the Ethernet driver for the National Semiconductor DP839EB (Evaluation Board for the DP8390 chipset). 3. The driver, and MINIX is lower performance than I would like. Now, The DP8390 Ethernet Controller is the chip set used in MOST PC cards, that's the good news. For example, the WD Etherplus uses our chipset, later 3com boards do, lots of clones do. In fact the amoeba code with MINIX is written for this set. Now the bad news. Our Eval board uses the two on-board dma channels on the DP8390 to implement remotely-accessed shared memory. The WD board uses dual- ported shared memory. However, it should be even easier to have it talk to our set on the WD card than the EB. I have taken the V1.0 NET package and put it a load of the "BEST" features from some later versions of NET. For example, I have added the rmdir, mkdir, chdir, into FTP. I have also added access permissions, host file address lookup, and so on. So, NET is pretty usefull. I stopped work on it since MINIX was so awful at interrupts it was not possible to write a REALLY high performance driver (I am picky). If anyone is really interested I could give you a copy on a 1.2M floppy. The Ethernet driver could be made to support the 3c500 also. This is the NET packages usual card (but god it is awful). Anyway, many thanks to Phil Karn, KA9q, and other contributors, the package is really great. Almost all the problems I had were MINIX, not NET. Also thanks to Ed Hall, he sent me the V1.0 source he had got working with SLIP under MINIX. One last point, NET effectively polls all servers and clients, so it runs stand-alone on your machine. It does offer multiple sessions, so for example, I run the echo, discard, telnet, mail, and ftp servers, and offer up to four clients when I am running NET. The executable (with debugging) is now about 55+KBytes, so I cannot add much more to it (it really needs the mailer upgrading). Sorry about raving on, Cheers, Des.
des@berlioz (Desmond Young) (06/09/89)
In article <11989@bcsaic.UUCP>, paula@bcsaic.UUCP (Paul Allen) writes: > .... The real > value of POSIX compatibility will come when there is a 386 > version of Minix that can take advantage of it. An adequate > stop along the way would be a 286 PM version with a large- > model compiler. > > I sincerely hope that Dr. Tanenbaum will reconsider his > decision not to adopt Bruce's version. HEAR, HEAR. I do not expect ast to adopt it, but there is no reason why it should not become the defacto standard. Des. -- Reply: des@logic.nsc.com {decwrl,hplabs,sun,pyramid,amdahl}!nsc.com!logic!des Des Young, M/S D3635 National Semiconductor, Santa Clara The light at the end of the tunnel was only a burglar's torch - J.Buffet.