BABYL OPTIONS: Version: 5 Labels: Note: This is the header of an rmail file. Note: If you are seeing it in rmail, Note: it means the file has no messages in it.  0, unseen,, *** EOOH *** From: ast@cs.vu.nl (Andy Tanenbaum) Newsgroups: comp.os.minix Subject: LINUX is obsolete Date: 29 Jan 92 12:12:50 GMT Organization: Fac. Wiskunde & Informatica, Vrije Universiteit, Amsterdam I was in the U.S. for a couple of weeks, so I haven't commented much on LINUX (not that I would have said much had I been around), but for what it is worth, I have a couple of comments now. As most of you know, for me MINIX is a hobby, something that I do in the evening when I get bored writing books and there are no major wars, revolutions, or senate hearings being televised live on CNN. My real job is a professor and researcher in the area of operating systems. As a result of my occupation, I think I know a bit about where operating are going in the next decade or so. Two aspects stand out: 1. MICROKERNEL VS MONOLITHIC SYSTEM Most older operating systems are monolithic, that is, the whole operating system is a single a.out file that runs in 'kernel mode.' This binary contains the process management, memory management, file system and the rest. Examples of such systems are UNIX, MS-DOS, VMS, MVS, OS/360, MULTICS, and many more. The alternative is a microkernel-based system, in which most of the OS runs as separate processes, mostly outside the kernel. They communicate by message passing. The kernel's job is to handle the message passing, interrupt handling, low-level process management, and possibly the I/O. Examples of this design are the RC4000, Amoeba, Chorus, Mach, and the not-yet-released Windows/NT. While I could go into a long story here about the relative merits of the two designs, suffice it to say that among the people who actually design operating systems, the debate is essentially over. Microkernels have won. The only real argument for monolithic systems was performance, and there is now enough evidence showing that microkernel systems can be just as fast as monolithic systems (e.g., Rick Rashid has published papers comparing Mach 3.0 to monolithic systems) that it is now all over but the shoutin`. MINIX is a microkernel-based system. The file system and memory management are separate processes, running outside the kernel. The I/O drivers are also separate processes (in the kernel, but only because the brain-dead nature of the Intel CPUs makes that difficult to do otherwise). LINUX is a monolithic style system. This is a giant step back into the 1970s. That is like taking an existing, working C program and rewriting it in BASIC. To me, writing a monolithic system in 1991 is a truly poor idea. 2. PORTABILITY Once upon a time there was the 4004 CPU. When it grew up it became an 8008. Then it underwent plastic surgery and became the 8080. It begat the 8086, which begat the 8088, which begat the 80286, which begat the 80386, which begat the 80486, and so on unto the N-th generation. In the meantime, RISC chips happened, and some of them are running at over 100 MIPS. Speeds of 200 MIPS and more are likely in the coming years. These things are not going to suddenly vanish. What is going to happen is that they will gradually take over from the 80x86 line. They will run old MS-DOS programs by interpreting the 80386 in software. (I even wrote my own IBM PC simulator in C, which you can get by FTP from ftp.cs.vu.nl = 192.31.231.42 in dir minix/simulator.) I think it is a gross error to design an OS for any specific architecture, since that is not going to be around all that long. MINIX was designed to be reasonably portable, and has been ported from the Intel line to the 680x0 (Atari, Amiga, Macintosh), SPARC, and NS32016. LINUX is tied fairly closely to the 80x86. Not the way to go. Don`t get me wrong, I am not unhappy with LINUX. It will get all the people who want to turn MINIX in BSD UNIX off my back. But in all honesty, I would suggest that people who want a **MODERN** "free" OS look around for a microkernel-based, portable OS, like maybe GNU or something like that. Andy Tanenbaum (ast@cs.vu.nl) P.S. Just as a random aside, Amoeba has a UNIX emulator (running in user space), but it is far from complete. If there are any people who would like to work on that, please let me know. To run Amoeba you need a few 386s, one of which needs 16M, and all of which need the WD Ethernet card.  0, unseen,, *** EOOH *** From: meggin@epas.utoronto.ca (David Megginson) Newsgroups: comp.os.minix Subject: Re: LINUX is obsolete Date: 29 Jan 92 14:12:12 GMT Organization: University of Toronto - EPAS Nntp-Posting-Host: epas.utoronto.ca I would like to at least look at LINUX, but I cannot, since I run a 68000-based machine. In any case, it is nice having the kernel independent, since patches like the multi-threaded FS patch don't have to exist in a different version for each CPU. I second everything AST said, except that I would like to see the kernel _more_ independent from everything else. Why does the Intel architecture _not_ allow drivers to be independent programs? I also don't like the fact that the kernel, mm and fs share the same configuration files. Since they _are_ independent, they should have more of a sense of independence. David ################################################################# David Megginson meggin@epas.utoronto.ca Centre for Medieval Studies david@doe.utoronto.ca University of Toronto 39 Queen's Park Cr. E. #################################################################  0, unseen,, *** EOOH *** From: ast@cs.vu.nl (Andy Tanenbaum) Newsgroups: comp.os.minix Subject: Re: LINUX is obsolete Date: 29 Jan 92 18:03:01 GMT Organization: Fac. Wiskunde & Informatica, Vrije Universiteit, Amsterdam In article <1992Jan29.141212.29636@epas.toronto.edu> meggin@epas.utoronto.ca (David Megginson) writes: > >Why does the >Intel architecture _not_ allow drivers to be independent programs? The drivers have to read and write the device registers in I/O space, and this cannot be done in user mode on the 286 and 386. If it were possible to do I/O in a protected way in user space, all the I/O tasks could have been user programs, like FS and MM. Andy Tanenbaum (ast@cs.vu.nl)  0, unseen,, *** EOOH *** From: gt0178a@prism.gatech.EDU (Jim Burns) Newsgroups: comp.os.minix Subject: Re: LINUX is obsolete Date: 30 Jan 92 03:39:48 GMT Organization: Georgia Institute of Technology in article <12605@star.cs.vu.nl>, ast@cs.vu.nl (Andy Tanenbaum) says: > The drivers have to read and write the device registers in I/O space, and > this cannot be done in user mode on the 286 and 386. If it were possible > to do I/O in a protected way in user space, all the I/O tasks could have > been user programs, like FS and MM. The standard way of doing that is to trap on i/o space protection violations, and emulate the i/o for the user. -- BURNS,JIM (returned student) Georgia Institute of Technology, 30178 Georgia Tech Station, Atlanta Georgia, 30332 | Internet: gt0178a@prism.gatech.edu uucp: ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!gt0178a  0, unseen,, *** EOOH *** From: joe@jshark.rn.com Newsgroups: comp.os.minix Subject: Re: LINUX is obsolete Summary: Is this for real? Date: 31 Jan 92 12:55:21 GMT Organization: a blip in entropy In article <12605@star.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes: >In article <1992Jan29.141212.29636@epas.toronto.edu> meggin@epas.utoronto.ca (David Megginson) writes: >> >>Why does the >>Intel architecture _not_ allow drivers to be independent programs? > >The drivers have to read and write the device registers in I/O space, and >this cannot be done in user mode on the 286 and 386. If it were possible >to do I/O in a protected way in user space, [[We must be talking about protected mode]] *THIS IS UNTRUE* The Intel architecture supports independent tasks, each of which can be given a "i/o privilege level". The convenient approach, used by iRMX(?), is to "build" a load image ("root" device driver, kernel, MM and FS). Once booted, these could be replaced by loadable tasks from disc (or network...) and given a suitable privilege level. The '386 additionally allows each task to have an "i/o permissions bitmap" which specifies exactly which ports can be used. (See "80386 Programmers Reference Manual", chapter 8) > all the I/O tasks could have >been user programs, like FS and MM. Do you really mean "user programs" and not "separate tasks" ?? Separate tasks, possibly privileged, I'll agree with. User level programs may be ok for teaching operating system principles, or on toy computers :-) But a "production" system? Not on my machines! >Andy Tanenbaum (ast@cs.vu.nl) joe. -- joe@jshark.rn.com uunet!nstar!jshark!joe  0, unseen,, *** EOOH *** From: drew@anchor.cs.colorado.edu (Drew Eckhardt) Newsgroups: comp.os.minix Subject: Re: LINUX is obsolete Date: 2 Feb 92 12:17:44 GMT Organization: University of Colorado, Boulder Nntp-Posting-Host: anchor.cs.colorado.edu In article <12605@star.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes: >In article <1992Jan29.141212.29636@epas.toronto.edu> meggin@epas.utoronto.ca (David Megginson) writes: >> >>Why does the >>Intel architecture _not_ allow drivers to be independent programs? > >The drivers have to read and write the device registers in I/O space, and >this cannot be done in user mode on the 286 and 386. If it were possible >to do I/O in a protected way in user space, all the I/O tasks could have >been user programs, like FS and MM. > >Andy Tanenbaum (ast@cs.vu.nl) Every 386 TSS has an iopermission bitmap. If the CPL is of a lower priveledge level than IOPL, the io permissions bitmap is consulted, allowing protection on a port by port basis.  0, unseen,, *** EOOH *** From: jonathan@ukmug.uk.mugnet.org (Jonathan Allen) Newsgroups: comp.os.minix Subject: Re: LINUX is obsolete Date: 3 Feb 92 07:43:00 GMT Organization: MUGNET UK Backbone (UKMUG) In article <12605@star.cs.vu.nl>, ast@cs.vu.nl (Andy Tanenbaum) wrote: > In article <1992Jan29.141212.29636@epas.toronto.edu> meggin@epas.utoronto.ca (David Megginson) writes: >> >>Why does the >>Intel architecture _not_ allow drivers to be independent programs? > > The drivers have to read and write the device registers in I/O space, and > this cannot be done in user mode on the 286 and 386. If it were possible > to do I/O in a protected way in user space, all the I/O tasks could have > been user programs, like FS and MM. Surely this could have been done by a minute task just to read/write a given port address in one message ? The security could have been checked like everything else using the process table ... Sure it would not have been at all efficient, but would have given the independance at a price. Jonathan  0, unseen,, *** EOOH *** From: ts@cup.portal.com (Tim W Smith) Newsgroups: comp.os.minix Subject: Re: LINUX is obsolete Date: 7 Feb 92 01:30:59 GMT Organization: The Portal System (TM) Andy Tanenbaum (ast@cs.vu.nl) writes: > The drivers have to read and write the device registers in I/O space, and > this cannot be done in user mode on the 286 and 386. If it were possible > to do I/O in a protected way in user space, all the I/O tasks could have > been user programs, like FS and MM. On the 386, you could run the drivers in V86 mode, which sort of counts as user mode and allows access to I/O registers if the kernel sets things up to allow this. Tim Smith  0, unseen,, *** EOOH *** From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.minix Subject: Re: LINUX is obsolete Date: 29 Jan 92 23:14:26 GMT Organization: University of Helsinki Well, with a subject like this, I'm afraid I'll have to reply. Apologies to minix-users who have heard enough about linux anyway. I'd like to be able to just "ignore the bait", but ... Time for some serious flamefesting! In article <12595@star.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes: > >I was in the U.S. for a couple of weeks, so I haven't commented much on >LINUX (not that I would have said much had I been around), but for what >it is worth, I have a couple of comments now. > >As most of you know, for me MINIX is a hobby, something that I do in the >evening when I get bored writing books and there are no major wars, >revolutions, or senate hearings being televised live on CNN. My real >job is a professor and researcher in the area of operating systems. You use this as an excuse for the limitations of minix? Sorry, but you loose: I've got more excuses than you have, and linux still beats the pants of minix in almost all areas. Not to mention the fact that most of the good code for PC minix seems to have been written by Bruce Evans. Re 1: you doing minix as a hobby - look at who makes money off minix, and who gives linux out for free. Then talk about hobbies. Make minix freely available, and one of my biggest gripes with it will disappear. Linux has very much been a hobby (but a serious one: the best type) for me: I get no money for it, and it's not even part of any of my studies in the university. I've done it all on my own time, and on my own machine. Re 2: your job is being a professor and researcher: That's one hell of a good excuse for some of the brain-damages of minix. I can only hope (and assume) that Amoeba doesn't suck like minix does. >1. MICROKERNEL VS MONOLITHIC SYSTEM True, linux is monolithic, and I agree that microkernels are nicer. With a less argumentative subject, I'd probably have agreed with most of what you said. From a theoretical (and aesthetical) standpoint linux looses. If the GNU kernel had been ready last spring, I'd not have bothered to even start my project: the fact is that it wasn't and still isn't. Linux wins heavily on points of being available now. > MINIX is a microkernel-based system. [deleted, but not so that you > miss the point ] LINUX is a monolithic style system. If this was the only criterion for the "goodness" of a kernel, you'd be right. What you don't mention is that minix doesn't do the micro-kernel thing very well, and has problems with real multitasking (in the kernel). If I had made an OS that had problems with a multithreading filesystem, I wouldn't be so fast to condemn others: in fact, I'd do my damndest to make others forget about the fiasco. [ yes, I know there are multithreading hacks for minix, but they are hacks, and bruce evans tells me there are lots of race conditions ] >2. PORTABILITY "Portability is for people who cannot write new programs" -me, right now (with tongue in cheek) The fact is that linux is more portable than minix. What? I hear you say. It's true - but not in the sense that ast means: I made linux as conformant to standards as I knew how (without having any POSIX standard in front of me). Porting things to linux is generally /much/ easier than porting them to minix. I agree that portability is a good thing: but only where it actually has some meaning. There is no idea in trying to make an operating system overly portable: adhering to a portable API is good enough. The very /idea/ of an operating system is to use the hardware features, and hide them behind a layer of high-level calls. That is exactly what linux does: it just uses a bigger subset of the 386 features than other kernels seem to do. Of course this makes the kernel proper unportable, but it also makes for a /much/ simpler design. An acceptable trade-off, and one that made linux possible in the first place. I also agree that linux takes the non-portability to an extreme: I got my 386 last January, and linux was partly a project to teach me about it. Many things should have been done more portably if it would have been a real project. I'm not making overly many excuses about it though: it was a design decision, and last april when I started the thing, I didn't think anybody would actually want to use it. I'm happy to report I was wrong, and as my source is freely available, anybody is free to try to port it, even though it won't be easy. Linus PS. I apologise for sometimes sounding too harsh: minix is nice enough if you have nothing else. Amoeba might be nice if you have 5-10 spare 386's lying around, but I certainly don't. I don't usually get into flames, but I'm touchy when it comes to linux :)  0, unseen,, *** EOOH *** From: ast@cs.vu.nl (Andy Tanenbaum) Newsgroups: comp.os.minix Subject: Re: LINUX is obsolete Date: 30 Jan 92 13:44:34 GMT Organization: Fac. Wiskunde & Informatica, Vrije Universiteit, Amsterdam In article <1992Jan29.231426.20469@klaava.Helsinki.FI> torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) writes: >You use this [being a professor] as an excuse for the limitations of minix? The limitations of MINIX relate at least partly to my being a professor: An explicit design goal was to make it run on cheap hardware so students could afford it. In particular, for years it ran on a regular 4.77 MHZ PC with no hard disk. You could do everything here including modify and recompile the system. Just for the record, as of about 1 year ago, there were two versions, one for the PC (360K diskettes) and one for the 286/386 (1.2M). The PC version was outselling the 286/386 version by 2 to 1. I don't have figures, but my guess is that the fraction of the 60 million existing PCs that are 386/486 machines as opposed to 8088/286/680x0 etc is small. Among students it is even smaller. Making software free, but only for folks with enough money to buy first class hardware is an interesting concept. Of course 5 years from now that will be different, but 5 years from now everyone will be running free GNU on their 200 MIPS, 64M SPARCstation-5. >Re 2: your job is being a professor and researcher: That's one hell of a >good excuse for some of the brain-damages of minix. I can only hope (and >assume) that Amoeba doesn't suck like minix does. Amoeba was not designed to run on an 8088 with no hard disk. >If this was the only criterion for the "goodness" of a kernel, you'd be >right. What you don't mention is that minix doesn't do the micro-kernel >thing very well, and has problems with real multitasking (in the >kernel). If I had made an OS that had problems with a multithreading >filesystem, I wouldn't be so fast to condemn others: in fact, I'd do my >damndest to make others forget about the fiasco. A multithreaded file system is only a performance hack. When there is only one job active, the normal case on a small PC, it buys you nothing and adds complexity to the code. On machines fast enough to support multiple users, you probably have enough buffer cache to insure a hit cache hit rate, in which case multithreading also buys you nothing. It is only a win when there are multiple processes actually doing real disk I/O. Whether it is worth making the system more complicated for this case is at least debatable. I still maintain the point that designing a monolithic kernel in 1991 is a fundamental error. Be thankful you are not my student. You would not get a high grade for such a design :-) >The fact is that linux is more portable than minix. What? I hear you >say. It's true - but not in the sense that ast means: I made linux as >conformant to standards as I knew how (without having any POSIX standard >in front of me). Porting things to linux is generally /much/ easier >than porting them to minix. MINIX was designed before POSIX, and is now being (slowly) POSIXized as everyone who follows this newsgroup knows. Everyone agrees that user-level standards are a good idea. As an aside, I congratulate you for being able to write a POSIX-conformant system without having the POSIX standard in front of you. I find it difficult enough after studying the standard at great length. My point is that writing a new operating system that is closely tied to any particular piece of hardware, especially a weird one like the Intel line, is basically wrong. An OS itself should be easily portable to new hardware platforms. When OS/360 was written in assembler for the IBM 360 25 years ago, they probably could be excused. When MS-DOS was written specifically for the 8088 ten years ago, this was less than brilliant, as IBM and Microsoft now only too painfully realize. Writing a new OS only for the 386 in 1991 gets you your second 'F' for this term. But if you do real well on the final exam, you can still pass the course. Prof. Andrew S. Tanenbaum (ast@cs.vu.nl)  0, unseen,, *** EOOH *** From: feustel@netcom.COM (David Feustel) Newsgroups: comp.os.minix Subject: Re: LINUX is obsolete Date: 30 Jan 92 18:57:28 GMT Organization: DAFCO - An OS/2 Oasis ast@cs.vu.nl (Andy Tanenbaum) writes: >I still maintain the point that designing a monolithic kernel in 1991 is >a fundamental error. Be thankful you are not my student. You would not >get a high grade for such a design :-) That's ok. Einstein got lousy grades in math and physics. -- David Feustel N9MYI, 1930 Curdes Ave, Fort Wayne, IN 46805. (219)482-9631 feustel@netcom.com === NBC News: GE's Advertising And Public Relations Agency ===  0, unseen,, *** EOOH *** From: meggin@epas.utoronto.ca (David Megginson) Newsgroups: comp.os.minix Subject: Re: LINUX is obsolete Date: 30 Jan 92 19:58:50 GMT Organization: University of Toronto - EPAS Nntp-Posting-Host: epas.utoronto.ca In article <1992Jan30.185728.26477feustel@netcom.COM> feustel@netcom.COM (David Feustel) writes: >ast@cs.vu.nl (Andy Tanenbaum) writes: > > >>I still maintain the point that designing a monolithic kernel in 1991 is >>a fundamental error. Be thankful you are not my student. You would not >>get a high grade for such a design :-) > >That's ok. Einstein got lousy grades in math and physics. And Dan Quayle got low grades in political science. I think that there are more Dan Quayles than Einsteins out there... ;-) David ################################################################# David Megginson meggin@epas.utoronto.ca Centre for Medieval Studies david@doe.utoronto.ca University of Toronto 39 Queen's Park Cr. E. #################################################################  0, unseen,, *** EOOH *** From: feustel@netcom.COM (David Feustel) Newsgroups: comp.os.minix Subject: Re: LINUX is obsolete Date: 30 Jan 92 23:15:05 GMT Organization: DAFCO - An OS/2 Oasis meggin@epas.utoronto.ca (David Megginson) writes: >In article <1992Jan30.185728.26477feustel@netcom.COM> feustel@netcom.COM (David Feustel) writes: >>ast@cs.vu.nl (Andy Tanenbaum) writes: >> >> >>>I still maintain the point that designing a monolithic kernel in 1991 is >>>a fundamental error. Be thankful you are not my student. You would not >>>get a high grade for such a design :-) >> >>That's ok. Einstein got lousy grades in math and physics. >And Dan Quayle got low grades in political science. I think that there >are more Dan Quayles than Einsteins out there... ;-) But the Existence of Linux suggests that we may have more of an Einstein than a Quail here. -- David Feustel N9MYI, 1930 Curdes Ave, Fort Wayne, IN 46805. (219)482-9631 feustel@netcom.com === NBC News: GE's Advertising And Public Relations Agency ===  0, unseen,, *** EOOH *** From: pete@ohm.york.ac.uk (-Pete French.) Newsgroups: comp.os.minix Subject: Re: LINUX is obsolete Date: 31 Jan 92 09:49:37 GMT Organization: Electronics Department, University of York, UK in article <1992Jan30.195850.7023@epas.toronto.edu>, meggin@epas.utoronto.ca (David Megginson) says: > Nntp-Posting-Host: epas.utoronto.ca > > In article <1992Jan30.185728.26477feustel@netcom.COM> feustel@netcom.COM (David Feustel) writes: >> >>That's ok. Einstein got lousy grades in math and physics. > > And Dan Quayle got low grades in political science. I think that there > are more Dan Quayles than Einsteins out there... ;-) What a horrible thought ! But on the points about microkernel v monolithic, isnt this partly an artifact of the language being used ? MINIX may well be designed as a microkernel system, but in the end you still end up with a large monolithic chunk of binary data that gets loaded in as "the OS". Isnt it written as separate programs simply because C does not support the idea of multiple processes within a single piece of monolithic code. Is there any real difference between a microkernel written as several pieces of C and a monolithic kernel written in something like OCCAM ? I would have thought that in this case the monolithic design would be a better one than the micorkernel style since with the advantage of inbuilt language concurrency the kernel could be made even more modular than the MINIX one is. Anyone for MINOX :-) -bat. -- -Pete French. (the -bat. ) / Adaptive Systems Engineering /  0, unseen,, *** EOOH *** From: peter@ferranti.com (peter da silva) Newsgroups: comp.os.minix Subject: Re: LINUX is obsolete Date: 3 Feb 92 16:22:32 GMT Organization: Xenix Support, FICC In article <1992Jan31.094937.3726@ohm.york.ac.uk> pete@ohm.york.ac.uk (-Pete French.) writes: > But on the points about microkernel v monolithic, isnt this partly an > artifact of the language being used ? I doubt it. [isn't MINIX] > written as separate programs simply because C does not support the idea > of multiple processes within a single piece of monolithic code. C doesn't support formatted I/O either, but it can be implemented quite effectively in C. So can concurrent processes. I've done it, in fact. The resulting code is 90% portable (the 10% being the code that handles the context switch). -- -- Peter da Silva, Ferranti International Controls Corporation -- Sugar Land, TX 77487-5012; +1 713 274 5180 -- "Have you hugged your wolf today?"  0, unseen,, *** EOOH *** From: kt4@prism.gatech.EDU (Ken Thompson) Newsgroups: comp.os.minix Subject: Re: LINUX is obsolete Date: 3 Feb 92 23:07:54 GMT Organization: Georgia Institute of Technology viewpoint may be largely unrelated to its usefulness. Many if not most of the software we use is probably obsolete according to the latest design criteria. Most users could probably care less if the internals of the operating system they use is obsolete. They are rightly more interested in its performance and capabilities at the user level. I would generally agree that microkernels are probably the wave of the future. However, it is in my opinion easier to implement a monolithic kernel. It is also easier for it to turn into a mess in a hurry as it is modified. Regards, Ken -- Ken Thompson GTRI, Ga. Tech, Atlanta Ga. 30332 Internet:!kt4@prism.gatech.edu uucp:...!{allegra,amd,hplabs,ut-ngp}!gatech!prism!kt4 "Rowe's Rule: The odds are five to six that the light at the end of the tunnel is the headlight of an oncoming train." -- Paul Dickson  0, unseen,, *** EOOH *** From: kevin@taronga.taronga.com (Kevin Brown) Newsgroups: comp.os.minix Subject: Re: LINUX is obsolete Date: 4 Feb 92 08:08:42 GMT Organization: University of Houston In article <47607@hydra.gatech.EDU> kt4@prism.gatech.EDU (Ken Thompson) writes: >viewpoint may be largely unrelated to its usefulness. Many if not >most of the software we use is probably obsolete according to the >latest design criteria. Most users could probably care less if the >internals of the operating system they use is obsolete. They are >rightly more interested in its performance and capabilities at the >user level. > >I would generally agree that microkernels are probably the wave of >the future. However, it is in my opinion easier to implement a >monolithic kernel. It is also easier for it to turn into a mess in >a hurry as it is modified. How difficult is it to structure the source tree of a monolithic kernel such that most modifications don't have a large negative impact on the source? What sorts of pitfalls do you run into in this sort of endeavor, and what suggestions do you have for dealing with them? I guess what I'm asking is: how difficult is it to organize the source such that most changes to the kernel remain localized in scope, even though the kernel itself is monolithic? I figure you've got years of experience with monolithic kernels :-), so I'd think you'd have the best shot at answering questions like these. >Ken Thompson GTRI, Ga. Tech, Atlanta Ga. 30332 Internet:!kt4@prism.gatech.edu >uucp:...!{allegra,amd,hplabs,ut-ngp}!gatech!prism!kt4 >"Rowe's Rule: The odds are five to six that the light at the end of the >tunnel is the headlight of an oncoming train." -- Paul Dickson Kevin Brown  0, unseen,, *** EOOH *** From: rburns@finess.Corp.Sun.COM (Randy Burns) Newsgroups: comp.os.minix Subject: Re: LINUX is obsolete Date: 30 Jan 92 20:33:07 GMT Organization: Sun Microsystems, Mt. View, Ca. NNTP-Posting-Host: finess.corp.sun.com In article <12615@star.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes: >In article <1992Jan29.231426.20469@klaava.Helsinki.FI> torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) writes: >Of course 5 years from now that will be different, but 5 years from now >everyone will be running free GNU on their 200 MIPS, 64M SPARCstation-5. Well, I for one would _love_ to see this happen. >>The fact is that linux is more portable than minix. What? I hear you >>say. It's true - but not in the sense that ast means: I made linux as >>conformant to standards as I knew how (without having any POSIX standard >>in front of me). Porting things to linux is generally /much/ easier >>than porting them to minix. ......... >My point is that writing a new operating system that is closely tied to any >particular piece of hardware, especially a weird one like the Intel line, >is basically wrong. First off, the parts of Linux tuned most finely to the 80x86 are the Kernel and the devices. My own sense is that even if Linux is simply a stopgap measure to let us all run GNU software, it is still worthwhile to have a a finely tuned kernel for the most numerous architecture presently in existance. > An OS itself should be easily portable to new hardware >platforms. Well, the only part of Linux that isn't portable is the kernel and drivers. Compare to the compilers, utilities, windowing system etc. this is really a small part of the effort. Since Linux has a large degree of call compatibility with portable OS's I wouldn't complain. I'm personally very grateful to have an OS that makes it more likely that some of us will be able to take advantage of the software that has come out of Berkeley, FSF, CMU etc. It may well be that in 2-3 years when ultra cheap BSD variants and Hurd proliferate, that Linux will be obsolete. Still, right now Linux greatly reduces the cost of using tools like gcc, bison, bash which are useful in the development of such an OS.  0, unseen,, *** EOOH *** From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.minix Subject: Re: LINUX is obsolete Date: 31 Jan 92 10:33:23 GMT Organization: University of Helsinki In article <12615@star.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes: >The limitations of MINIX relate at least partly to my being a professor: >An explicit design goal was to make it run on cheap hardware so students >could afford it. All right: a real technical point, and one that made some of my comments inexcusable. But at the same time you shoot yourself in the foot a bit: now you admit that some of the errors of minix were that it was too portable: including machines that weren't really designed to run unix. That assumption lead to the fact that minix now cannot easily be extended to have things like paging, even for machines that would support it. Yes, minix is portable, but you can rewrite that as "doesn't use any features", and still be right. >A multithreaded file system is only a performance hack. Not true. It's a performance hack /on a microkernel/, but it's an automatic feature when you write a monolithic kernel - one area where microkernels don't work too well (as I pointed out in my personal mail to ast). When writing a unix the "obsolete" way, you automatically get a multithreaded kernel: every process does it's own job, and you don't have to make ugly things like message queues to make it work efficiently. Besides, there are people who would consider "only a performance hack" vital: unless you have a cray-3, I'd guess everybody gets tired of waiting on the computer all the time. I know I did with minix (and yes, I do with linux too, but it's /much/ better). >I still maintain the point that designing a monolithic kernel in 1991 is >a fundamental error. Be thankful you are not my student. You would not >get a high grade for such a design :-) Well, I probably won't get too good grades even without you: I had an argument (completely unrelated - not even pertaining to OS's) with the person here at the university that teaches OS design. I wonder when I'll learn :) >My point is that writing a new operating system that is closely tied to any >particular piece of hardware, especially a weird one like the Intel line, >is basically wrong. But /my/ point is that the operating system /isn't/ tied to any processor line: UNIX runs on most real processors in existence. Yes, the /implementation/ is hardware-specific, but there's a HUGE difference. You mention OS/360 and MS-DOG as examples of bad designs as they were hardware-dependent, and I agree. But there's a big difference between these and linux: linux API is portable (not due to my clever design, but due to the fact that I decided to go for a fairly- well-thought-out and tested OS: unix.) If you write programs for linux today, you shouldn't have too many surprises when you just recompile them for Hurd in the 21st century. As has been noted (not only by me), the linux kernel is a miniscule part of a complete system: Full sources for linux currently runs to about 200kB compressed - full sources to a somewhat complete developement system is at least 10MB compressed (and easily much, much more). And all of that source is portable, except for this tiny kernel that you can (provably: I did it) re-write totally from scratch in less than a year without having /any/ prior knowledge. In fact the /whole/ linux kernel is much smaller than the 386-dependent things in mach: i386.tar.Z for the current version of mach is well over 800kB compressed (823391 bytes according to nic.funet.fi). Admittedly, mach is "somewhat" bigger and has more features, but that should still tell you something. Linus  0, unseen,, *** EOOH *** Newsgroups: comp.os.minix From: kevin@nuchat.sccsi.com (Kevin Brown) Subject: Re: LINUX is obsolete Organization: Where??? Date: Fri, 31 Jan 1992 07:43:47 GMT Sorry, but I just can't resist this thread...:-) In article <12615@star.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes: >In article <1992Jan29.231426.20469@klaava.Helsinki.FI> torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) writes: >>You use this [being a professor] as an excuse for the limitations of minix? >The limitations of MINIX relate at least partly to my being a professor: >An explicit design goal was to make it run on cheap hardware so students >could afford it. In particular, for years it ran on a regular 4.77 MHZ PC >with no hard disk. And an explicit design goal of Linux was to take advantage of the special features of the 386 architecture. So what exactly is your point? Different design goals get you different designs. You ought to know that. >You could do everything here including modify and recompile >the system. Just for the record, as of about 1 year ago, there were two >versions, one for the PC (360K diskettes) and one for the 286/386 (1.2M). >The PC version was outselling the 286/386 version by 2 to 1. I don't have >figures, but my guess is that the fraction of the 60 million existing PCs that >are 386/486 machines as opposed to 8088/286/680x0 etc is small. Among students >it is even smaller. I find it very interesting that you claim here that Minix was designed primarily for cheap hardware (in particular, the IBM PC/XT with no hard disk) and yet elsewhere have also mentioned the virtues of being portable across hardware platforms. Well, if you insist on designing the thing with the lowest common denominator as your basis, that's fine, but of course the end result will be less than pretty unless designed *very* carefully. >Making software free, but only for folks with enough money >to buy first class hardware is an interesting concept. Except that Linux was designed more for the purposes of the designer than anything else. If I were writing an OS, I'd design it to suit myself, too. It's just that Linus was nice enough to share his code with the rest of us. >Of course 5 years from now that will be different, but 5 years from now >everyone will be running free GNU on their 200 MIPS, 64M SPARCstation-5. Maybe. But by then, the 386/486 will probably be where the PC is now: everyone will have one and they'll be dirt cheap. The timing will be about right. In which case Linux will fit right in, wouldn't you say? >>Re 2: your job is being a professor and researcher: That's one hell of a >>good excuse for some of the brain-damages of minix. I can only hope (and >>assume) that Amoeba doesn't suck like minix does. >Amoeba was not designed to run on an 8088 with no hard disk. Here's a question for you: as a general rule, when you go to design an operating system, do you design it for specific capabilities and then run it on whatever hardware will do the job, or do you design it with the hardware as a target and fit the capabilities to the hardware? With respect to Minix, it seems you did the latter, but I don't know whether or not you did that with Amoeba. >>If this was the only criterion for the "goodness" of a kernel, you'd be >>right. What you don't mention is that minix doesn't do the micro-kernel >>thing very well, and has problems with real multitasking (in the >>kernel). If I had made an OS that had problems with a multithreading >>filesystem, I wouldn't be so fast to condemn others: in fact, I'd do my >>damndest to make others forget about the fiasco. >A multithreaded file system is only a performance hack. Bull. A multithreaded file system has a completely different design than a single-threaded file system and has different design criteria than a single-threaded file system. >When there is only one job active, the normal case on a small PC, it buys >you nothing and adds complexity to the code. If there is only going to be one job active anyway then *why bother with multitasking at all*???? If you're going to implement multitasking, then don't do a halfway job of it. On the other hand, if you're going to assume that there will be only one job active anyway, then don't bother with multitasking (after all, it *does* complicate things :-). >On machines fast enough to >support multiple users, you probably have enough buffer cache to insure a >hit cache hit rate, in which case multithreading also buys you nothing. Maybe. Multiple users means multiple things being done simultaneously. I wouldn't bet on the buffer cache buying you so much that multithreading makes no difference. It's one thing if the users are doing something simple, like editing a file. It's another thing if they're compiling, reading news, or other things that touch lots of different files. >It is only a win when there are multiple processes actually doing real disk >I/O. Which happens a *lot* when you're running multiple users. Or when you're a machine hooked up to the net and handling news traffic. >Whether it is worth making the system more complicated for this case is >at least debatable. Oh, come on. How tough is it to implement a multi-threaded file system? All you need is a decent *buffered* (preferably infinitely so) message-passing system and a way to save your current state when you send out a request to the device driver(s) to perform some work (and obviously some way to restore that state). Minix has the second via the setjmp()/ longjmp() mechanism, but lacks the former in a serious way. >I still maintain the point that designing a monolithic kernel in 1991 is >a fundamental error. Not if you're trying to implement the system call semantics of Unix in a reasonably simple and elegant way. >Be thankful you are not my student. You would not >get a high grade for such a design :-) Why not? What's this big thing against monolithic kernels? There are certain classes of problems for which a monolithic kernel is a more appropriate design than a microkernel architecture. I think implementing Unix semantics with a minimum of fuss is one such problem. Unless you can suggest an elegant way to terminate a system call upon receipt of a signal from within a microkernel OS? >>The fact is that linux is more portable than minix. What? I hear you >>say. It's true - but not in the sense that ast means: I made linux as >>conformant to standards as I knew how (without having any POSIX standard >>in front of me). Porting things to linux is generally /much/ easier >>than porting them to minix. >MINIX was designed before POSIX, and is now being (slowly) POSIXized as >everyone who follows this newsgroup knows. Everyone agrees that user-level >standards are a good idea. As an aside, I congratulate you for being able >to write a POSIX-conformant system without having the POSIX standard in front >of you. I find it difficult enough after studying the standard at great length. > >My point is that writing a new operating system that is closely tied to any >particular piece of hardware, especially a weird one like the Intel line, >is basically wrong. Weird as the Intel line may be, it's *the* most popular line, by several times. So it's not like it's *that* big a loss. And Intel hardware is at least relatively cheap to come by, regardless of what your students might tell you (why do you think they all own PCs?)... >An OS itself should be easily portable to new hardware >platforms. As long as you don't sacrifice too much in the way of performance or architectural elegance in order to gain this. Unfortunately, that's *exactly* what happened with Minix: in attempting to implement it on hardware of the lowest caliber, you ended up having to make design decisions with respect to the architecture and implementation that have made vintage Minix unusable as anything more than a personal toy operating system. For example: why didn't you implement a system call server as a layer between the file system and user programs? My guess: you didn't have enough memory on the target machine to do it. Put another way: you hit your original goal right on target, and are to be applauded for that. But in doing so, you missed a lot of other targets that wouldn't have been hard to hit as well, with some consideration of them. I think. But I wasn't there when you were making the decisions, so it's real hard for me to say for sure. I'm speaking from hindsight, but you had the tough problem of figuring out what to do without such benefit. Now, *modified* Minix is usable. Add a bigger buffer cache. Modify it so that it can take advantage of 386 protected mode. Fix the tty driver so that it will give you multiple consoles. Fix the rs232 driver to deal with DCD/DTR and do the right thing when carrier goes away. Fix the pipes so that read and write requests don't fail just because they happen to be bigger than the size of a physical pipe. Add shared text segments so you maximize the use of your RAM. Fix the scheduler so that it deals with character I/O bound processes in a reasonable way. >When OS/360 was written in assembler for the IBM 360 >25 years ago, they probably could be excused. When MS-DOS was written >specifically for the 8088 ten years ago, this was less than brilliant, as >IBM and Microsoft now only too painfully realize. Yeah, right. Just what hardware do you think they'd like to port DOS to, anyway? I can't think of any. I don't think IBM or Microsoft are regretting *that* particular aspect of DOS. Rather, they're probably regretting the fact that it was written for the address space provided by the 8088. MS-DOS isn't less than brilliant because it was written for one machine architecture. It's less than brilliant because it doesn't do anything well, *regardless* of its portability or lack thereof. >Writing a new OS only for the >386 in 1991 gets you your second 'F' for this term. But if you do real well >on the final exam, you can still pass the course. He made his code freely redistributable. *You* didn't even do that. Just for that move alone, he scores points in my book. Of course, the distribution technology available to him is much better than what was available when you did Minix, so it's hard to fault you for that... But I must admit, Minix is still one hell of a bargain, and I would never hesitate to recommend it to anyone who wants to learn something about Unix and operating systems in general. As a working operating system (i.e., one intended for a multi-user environment), however, I'd hesitate to recommend it, except that there really aren't any good alternatives (except Linux, of course, at least tentatively. I can't say for sure, since I haven't checked out Linux yet), since it doesn't have the performance capabilities that a working operating system needs. >Prof. Andrew S. Tanenbaum (ast@cs.vu.nl) Kevin Brown  0, unseen,, *** EOOH *** Newsgroups: comp.os.minix From: kevin@taronga.taronga.com (Kevin Brown) Subject: Re: LINUX is obsolete Organization: Sorely lacking. Date: Mon, 3 Feb 1992 05:12:58 GMT It has been brought to my attention that my last posting was exceedingly harsh. Having reread it, I'm inclined to agree. Dr. Tanenbaum claims that the microkernel architecture is the way to go. He has a great deal more experience with operating systems than I have. It's an understatement that it's likely that there's some substance to his statement. :-) Many of the things I said in my previous posting were more a result of my philosophical viewpoint on operating systems and programming in general than experience. And the particular viewpoint I hold that's relevent to the discussion says that the method of implementation chosen depends on the design goals, and that there is no "wrong" or "right" way to do things that is independent of such goals. Thus, my statement that a monolithic kernel follows from some design goals, e.g. ease of implementation of the semantics of the Unix API. In particular, the ease of implementing things like signal handling, premature system call termination, etc. At least, that's the conclusion I come to when I think about the problem. My experience with Minix says that there are a number of things that should not go in a user process, things that are better left in the kernel. Things like memory allocation (which requires global knowledge of the hardware, something that a user process should, IMHO, not have) and signal handling (which requires building stack frames). ÷³So from my point of view, the architecture of Minix is not ideal. While it may win in that it's a "microkernel" architecture, the division of functionality is not entirely to my liking. As is undoubtedly plainly obvious by now. :-) Despite that, Minix is quite usable in many ways as a personal operating system, i.e. one where there is usually only one person logged into the system. If I gave the impression that I thought it was unusable in general, then I apologize for that. However, as a *multiuser* operating system, þòi.e. an operating system designed to efficiently meet the needs of multiple users simultaneously while also performing batch operations, Minix is lacking, as far as I'm concerned. The main reason, of course, is the single-threaded file system (hereafter, STFS). Now, Dr. Tanenbaum may feel that a multi-threaded file system (hereafter, MTFS) is merely a performance hack. Perhaps he's right. Perhaps the architecture of a MTFS is sufficiently similar to that of a STFS that his assessment is correct. My vision of a MTFS may differ significantly from his, and this would explain why he and I seem to have a difference of opinion on this matter. Regardless of whether or not a MTFS is a "performance hack", for a *multiuser* operating system, I think there are a lot of good arguments that say that a MTFS is a *necessary* "performance hack". Provided, of course, that one does not have infinite buffer cache resources. :-) There are other things I feel Minix lacks as well. The ability to allocate memory in the kernel is one (such an ability would allow any user process, e.g. device drivers and the file system, to allocate memory dynamically. This is useful for doing things like resizing the buffer cache on the fly, etc. The ability to pass arbitrarily sized messages, optionally via shared memory, is another (such an ability might be limited by constraints like page size and such). However much Minix may be lacking from my standpoint, it is nevertheless a very useful and welcome enhancement to my system. In spite of the impression that I may have given everyone in my last posting, there will always be a soft spot in my heart for it, if only because it's the first decent operating system I've had on my system that I've had source to. I don't have to tell you people how incredibly useful it is to have source. You already know. It is very important to me to have source code to the things I run. It bothers me a great deal to run things that I don't have source to. Even the C compiler. And the less expensive the source is, the better. This is why Dr. Tanenbaum's statements about Linux touched a raw nerve with me: Linux comes with source *and* it's free. And it's available right now. Someone, either here on this newsgroup or over on alt.os.linux, made a very valid observation: the cost of a 16 MHz 386SX system is about $140 more than a comparably equipped (in terms of RAM size, display technology, hard drive space, etc.) 8088 system. Minix is $169. In economic terms, Linux wins if you have to buy Minix. Where Minix wins (or is at least even :-) is when you can get it for free via the educational distribution clause of the license agreement. However, Minix will run even better on a 16 MHz 386SX than on an 8088. If I were a student, I'd get the 386SX unless I simply didn't have a choice. Then I'd get whichever operating system I could get for the least cost. If I could get both for free, then I'd get both. :-) Given the reasons Linus wrote Linux, I think it's hard for anyone to fault him for writing it the way he did. And he was extremely nice in making his code freely available to the rest of the world. It's not something he had to do. In my book, that makes him almost beyond reproach. Dr. Tanenbaum didn't make Minix free. His goals were different. Minix is a teaching aid above all else (unless Dr. Tanenbaum has changed his views about Minix :-). That means that he must be concerned with the most efficient way to get Minix to the student population. At the time Minix was released, Prentice-Hall was a good solution, and has been for some time. However, I must wonder whether or not this is still the case. Dr. Tanenbaum: do you still feel that free distribution of Minix via the net is not the best way to distribute Minix? Which wins? Minix or Linux? Depends on how you measure them... Kevin Brown  0, unseen,, *** EOOH *** From: kaufman@eecs.nwu.edu (Michael L. Kaufman) Newsgroups: comp.os.minix Subject: Re: LINUX is obsolete Date: 3 Feb 92 22:27:48 GMT Organization: EECS Department, Northwestern University I tried to send these two posts from work, but I think they got eaten. If you have seen them already, sorry. ------------------------------------------------------------------------------- Andy Tanenbaum writes an interesting article (also interesting was finding out that he actually reads this group) but I think he is missing an important point. He Wrote: >As most of you know, for me MINIX is a hobby, ... Which is also probably true of most, if not all, of the people who are involved in Linux. We are not developing a system to take over the OS market, we are just having a good time. > What is going to happen > is that they will gradually take over from the 80x86 line. They will > run old MS-DOS programs by interpreting the 80386 in software. Well when this happens, if I still want to play with Linux, I can just run it on my 386 simulator. > MINIX was designed to be reasonably portable, and has been ported from the > Intel line to the 680x0 (Atari, Amiga, Macintosh), SPARC, and NS32016. > LINUX is tied fairly closely to the 80x86. Not the way to go. That's fine for the people who have those machines, but it wasn't a free lunch. That portibility was gained at the cost of some performance and some features on the 386. Before you decide that LINUX is not the way to go, you should think about what it is going to be used for. I am going to use it for running memory and computation intensive graphics programs on my 486. For me, speed and memory were more important then future state-of-the-artness and portability. >But in all honesty, I would >suggest that people who want a **MODERN** "free" OS look around for a >microkernel-based, portable OS, like maybe GNU or something like that. I don't know of any free microkernel-based, portable OSes. GNU is still vaporware, and likely to remain that way for the forseeable future. Do you actually have one to recomend, or are you just toying with me? ;-) ------------------------------------------------------------------------------ In article <12615@star.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes: >My point is that writing a new operating system that is closely tied to any >particular piece of hardware, especially a weird one like the Intel line, >is basically wrong. An OS itself should be easily portable to new hardware >platforms. I think I see where I disagree with you now. You are looking at OS design as an end in itself. Minix is good because it is portable/Micro-Kernal/etc. Linux is not good because it is monolithic/tightly tied to Intel/etc. That is not a strange attitude for someone in the acedemic world, but it is not something you should expect to be universally shared. Linux is not being written as a teaching tool, or as an abstract exercise. It is being written to allow people to run GNU-type software _today_. The fact that it may not be in use in five years is less important then the fact that today (well, by April probably) I can run all sorts of software on it that I want to run. You keep saying that Minix is better, but if it will not run the software that I want to run, it really isn't that good (for me) at all. > When OS/360 was written in assembler for the IBM 360 >25 years ago, they probably could be excused. When MS-DOS was written >specifically for the 8088 ten years ago, this was less than brilliant, as >IBM and Microsoft now only too painfully realize. Same point. MSoft did not come out with Dos to "explore the frontiers of os research". They did it to make a buck. And considering the fact that MS-DOS probably still outsells everyone else put together, I don't think that you say that they have failed _in their goals_. Not that MS-Dos is the best OS in terms of anything else, only that it has served their needs. Michael -- Michael Kaufman | I've seen things you people wouldn't believe. Attack ships on kaufman | fire off the shoulder of Orion. I watched C-beams glitter in @eecs.nwu.edu | the dark near the Tannhauser gate. All those moments will be | lost in time - like tears in rain. Time to die. Roy Batty  0, unseen,, *** EOOH *** From: entropy@wintermute.WPI.EDU (Lawrence C. Foard) Newsgroups: comp.os.minix Subject: Re: LINUX is obsolete Date: 6 Feb 92 09:22:40 GMT Organization: Worcester Polytechnic Institute Nntp-Posting-Host: wintermute.wpi.edu In article <1992Feb3.051258.4153@menudo.uh.edu> kevin@taronga.taronga.com (Kevin Brown) writes: >Dr. Tanenbaum claims that the microkernel architecture is the way to go. >He has a great deal more experience with operating systems than I have. >It's an understatement that it's likely that there's some substance to >his statement. :-) I tend to prefer seeing for myself rather than accepting "expert" opinion. Microkernels are nice asthetically, but there are times when practical issues must also be considered :) >w3So from my point of view, the architecture of Minix is not ideal. While >it may win in that it's a "microkernel" architecture, the division of >functionality is not entirely to my liking. As is undoubtedly plainly >obvious by now. :-) I've been told by people who have used both that Linux is significantly faster. There are certainly several factors involved (certainly using 32 bits helps alot), but the multithreading also makes for much lower overhead. >However, as a *multiuser* operating system, ~ri.e. an operating system designed >to efficiently meet the needs of multiple users simultaneously while also >performing batch operations, Minix is lacking, as far as I'm concerned. >The main reason, of course, is the single-threaded file system (hereafter, >STFS). Now, Dr. Tanenbaum may feel that a multi-threaded file system >(hereafter, MTFS) is merely a performance hack. I think this is a very valid problem. There are two ways a single threaded FS could work and both have substantial problems. If the FS blocks while waiting for I/O it would be completely unusable for "real" work. Imagine several users accessing a database, if the FS blocks for I/O they will have to wait eventhough the data they are looking for is already in the cache. If it is designed to be non blocking then it is even more complicated than a multithreaded FS and will have more overhead. I hope it is atleast the second >However much Minix may be lacking from my standpoint, it is nevertheless >a very useful and welcome enhancement to my system. In spite of the >impression that I may have given everyone in my last posting, there will >always be a soft spot in my heart for it, if only because it's the first >decent operating system I've had on my system that I've had source to. >I don't have to tell you people how incredibly useful it is to have source. >You already know. I will agree here, Minix is infinitly better than Messy-Loss :) >Given the reasons Linus wrote Linux, I think it's hard for anyone to fault >him for writing it the way he did. And he was extremely nice in making >his code freely available to the rest of the world. It's not something he >had to do. In my book, that makes him almost beyond reproach. I think more effort has been put into making practical use of Linux possible. An educational OS is nice, but there is a world outside of colleges that is suffering from the lack of cheap and useful OS's, I've been stuck doing most consulting work in Messy Loss because customers don't want to fork out $1000 for UNIX. >Dr. Tanenbaum didn't make Minix free. His goals were different. Minix >is a teaching aid above all else (unless Dr. Tanenbaum has changed his >views about Minix :-). That means that he must be concerned with the >most efficient way to get Minix to the student population. At the time >Minix was released, Prentice-Hall was a good solution, and has been for >some time. However, I must wonder whether or not this is still the case. >Dr. Tanenbaum: do you still feel that free distribution of Minix via the >net is not the best way to distribute Minix? I would guess that Prentice-Hall would have some objections :) -- Disclaimer: Opinions are based on logic rather than biblical "fact". ------ This is your friendly | First they came for the drug users, I said \ / neighborhood signature virus | nothing, then they came for hackers, \ / please add me to your signature! | I said nothing... STOP W.O.D. \/  0, unseen,, *** EOOH *** From: kevin@taronga.com (Kevin Brown) Newsgroups: comp.os.minix Subject: Re: LINUX is obsolete Date: 9 Feb 92 09:02:24 GMT Organization: What's that? In article <1992Feb6.092240.16377@wpi.WPI.EDU> entropy@wintermute.WPI.EDU (Lawrence C. Foard) writes: >In article <1992Feb3.051258.4153@menudo.uh.edu> kevin@taronga.taronga.com (Kevin Brown) writes: >>Dr. Tanenbaum claims that the microkernel architecture is the way to go. >>He has a great deal more experience with operating systems than I have. >>It's an understatement that it's likely that there's some substance to >>his statement. :-) > >I tend to prefer seeing for myself rather than accepting "expert" opinion. >Microkernels are nice asthetically, but there are times when practical issues >must also be considered :) I agree. This is why I qualified my statement the way I did. :-) Having seen both monolithic and microkernel architectures running, though, I tend to agree that microkernels are generally the way to go, all other things being equal. But as you say, all things are not always equal. That's when it becomes a judgement call. Which is better? Depends on what you're trying to do. >I've been told by people who have used both that Linux is significantly >faster. There are certainly several factors involved (certainly using 32 bits >helps alot), but the multithreading also makes for much lower overhead. Yup. I think that if Minix were arranged so that it had message queueing and a true multithreaded filesystem, it might be comparable to a monolithic kernel in terms of speed. It's hard for me to say, though. I haven't played around much with multithreaded filesystems, so I don't know how hard it is to make them work efficiently. I'd think, though, that it would depend enormously on how efficient your device drivers were, and how much data copying you'd have to do (ideally, you'd pass references to the data buffers around and do your actual data transfers directly to the user's buffer). >>However, as a *multiuser* operating system, i.e. an operating system designed >>to efficiently meet the needs of multiple users simultaneously while also >>performing batch operations, Minix is lacking, as far as I'm concerned. >>The main reason, of course, is the single-threaded file system (hereafter, >>STFS). Now, Dr. Tanenbaum may feel that a multi-threaded file system >>(hereafter, MTFS) is merely a performance hack. > >I think this is a very valid problem. There are two ways a single threaded FS >could work and both have substantial problems. If the FS blocks while waiting >for I/O it would be completely unusable for "real" work. Imagine several users >accessing a database, if the FS blocks for I/O they will have to wait >eventhough the data they are looking for is already in the cache. If it is >designed to be non blocking then it is even more complicated than a >multithreaded FS and will have more overhead. I hope it is atleast the second I haven't gone deeply into the source code of the Minix file system, but the impression I get from my perusing of it is that it blocks on disk I/O but not on terminal I/O, the idea being that disk I/O requests will almost always be satisfied relatively soon after they are made, whereas terminal I/O requests can take an indefinite amount of time to satisfy. But it seems to me that if you're going to implement the mechanism to handle I/O where the file system doesn't block waiting for it, why not use that mechanism universally??? >>However much Minix may be lacking from my standpoint, it is nevertheless >>a very useful and welcome enhancement to my system. In spite of the >>impression that I may have given everyone in my last posting, there will >>always be a soft spot in my heart for it, if only because it's the first >>decent operating system I've had on my system that I've had source to. >>I don't have to tell you people how incredibly useful it is to have source. >>You already know. > >I will agree here, Minix is infinitly better than Messy-Loss :) Which is why I try to avoid using MS-DOS whenever possible. I'll bet a lot of us Minixers do the same. :-) >>Given the reasons Linus wrote Linux, I think it's hard for anyone to fault >>him for writing it the way he did. And he was extremely nice in making >>his code freely available to the rest of the world. It's not something he >>had to do. In my book, that makes him almost beyond reproach. > >I think more effort has been put into making practical use of Linux possible. >An educational OS is nice, but there is a world outside of colleges that >is suffering from the lack of cheap and useful OS's, I've been stuck doing >most consulting work in Messy Loss because customers don't want to fork out >$1000 for UNIX. Even students can make good use of something like Linux. I have 8 megabytes of RAM on my machine, and 410 meg of harddrive space. Yet I can barely run SBProlog on my system, even though my system is considerably more macho than most. If I had demand paging on my system, this wouldn't be a problem, but the only patches I have for demand paging seem not to work very well. Once Linux becomes more stable (and gets support for Seagate ST-02 SCSI), I'll snag the sources and check it out. Since I already own Minix, I can legally transport *everything* over to it, and since both share the same filesystem layout, I can do the transporting with a minimum of hassle. >>Dr. Tanenbaum didn't make Minix free. His goals were different. Minix >>is a teaching aid above all else (unless Dr. Tanenbaum has changed his >>views about Minix :-). That means that he must be concerned with the >>most efficient way to get Minix to the student population. At the time >>Minix was released, Prentice-Hall was a good solution, and has been for >>some time. However, I must wonder whether or not this is still the case. >>Dr. Tanenbaum: do you still feel that free distribution of Minix via the >>net is not the best way to distribute Minix? > >I would guess that Prentice-Hall would have some objections :) No doubt. :-( -- Kevin Brown Disclaimer: huh? kevin@taronga.com kevin@nuchat.sccsi.com  0, unseen,, *** EOOH *** From: julien@incal.inria.fr (Julien Maisonneuve) Newsgroups: comp.os.minix Subject: Re: LINUX is obsolete Date: 3 Feb 92 17:10:14 GMT I would like to second Kevin brown in most of his remarks. I'll add a few user points : - When ast states that FS multithreading is useless, it reminds me of the many times I tried to let a job run in the background (like when reading an archive on a floppy), it is just unusable, the & shell operator could even have been left out. - Most interesting utilities are not even compilable under Minix because of the ATK compiler's incredible limits. Those were hardly understandable on a basic PC, but become absurd on a 386. Every stupid DOS compiler has a large model (more expensive, OK). I hate the 13 bit compress ! - The lack of Virtual Memory support prevents people studying this area to experiment, and prevents users to use large programs. The strange design of the MM also makes it hard to modify. The problem is that even doing exploratory work under minix is painful. If you want to get any work done (or even fun), even DOS is becoming a better alternative (with things like DJ GPP). In its basic form, it is really no more than OS course example, a good toy, but a toy. Obtaining and applying patches is a pain, and precludes further upgrades. Too bad when not so much is missing to make it really good. Thanks for the work andy, but Linux didn't deserve your answer. For the common people, it does many things better than Minix. Julien Maisonneuve. This is not a flame, just my experience.  0, unseen,, *** EOOH *** From: richard@aiai.ed.ac.uk (Richard Tobin) Newsgroups: comp.os.minix Subject: Re: LINUX is obsolete Date: 4 Feb 92 14:46:49 GMT Reply-To: richard@aiai.UUCP (Richard Tobin) Organization: AIAI, University of Edinburgh, Scotland In article <12615@star.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes: >A multithreaded file system is only a performance hack. When there is only >one job active, the normal case on a small PC, it buys you nothing I find the single-threaded file system a serious pain when using Minix. I often want to do something else while reading files from the (excruciatingly slow) floppy disk. I rather like to play rogue while waiting for large C or Lisp compilations. I look to look at files in one editor buffer while compiling in another. (The problem would be somewhat less if the file system stuck to serving files and didn't interact with terminal i/o.) Of course, in basic Minix with no virtual consoles and no chance of running emacs, this isn't much of a problem. But to most people that's a failure, not an advantage. It just isn't the case that on single-user machines there's no use for more than one active process; the idea only has any plausibility because so many people are used to poor machines with poor operating systems. As to portability, Minix only wins because of its limited ambitions. If you wanted a full-featured Unix with paging, job-control, a window system and so on, would it be quicker to start from basic Minix and add the features, or to start from Linux and fix the 386-specific bits? I don't think it's fair to criticise Linux when its aims are so different from Minix's. If you want a system for pedagogical use, Minix is the answer. But if what you want is an environment as much like (say) a Sun as possible on your home computer, it has some deficiencies. -- Richard -- Richard Tobin, AI Applications Institute, R.Tobin@ed.ac.uk Edinburgh University.  0, unseen,, *** EOOH *** From: ast@cs.vu.nl (Andy Tanenbaum) Newsgroups: comp.os.minix Subject: Re: LINUX is obsolete Date: 5 Feb 92 14:48:48 GMT Organization: Fac. Wiskunde & Informatica, Vrije Universiteit, Amsterdam In article <6121@skye.ed.ac.uk> richard@aiai.UUCP (Richard Tobin) writes: >If you wanted a full-featured Unix with paging, job-control, a window >system and so on, would it be quicker to start from basic Minix and >add the features, or to start from Linux and fix the 386-specific >bits? Another option that seems to be totally forgotten here is buy UNIX or a clone. If you just want to USE the system, instead of hacking on its internals, you don't need source code. Coherent is only $99, and there are various true UNIX systems with more features for more money. For the true hacker, not having source code is fatal, but for people who just want a UNIX system, there are many alternatives (albeit not free). Andy Tanenbaum (ast@cs.vul.nl)  0, unseen,, *** EOOH *** From: linville@garfield.catt.ncsu.edu (John W. Linville) Newsgroups: comp.os.minix Subject: Re: LINUX is obsolete Summary: Small model compiler limits Coherent as an alternative Date: 5 Feb 92 17:56:35 GMT Organization: NCSU CATT Prog In article <12696@star.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes: >In article <6121@skye.ed.ac.uk> richard@aiai.UUCP (Richard Tobin) writes: >>If you wanted a full-featured Unix with paging, job-control, a window >>system and so on, would it be quicker to start from basic Minix and >>add the features, or to start from Linux and fix the 386-specific >>bits? > >Another option that seems to be totally forgotten here is buy UNIX or a >clone. If you just want to USE the system, instead of hacking on its >internals, you don't need source code. Coherent is only $99, and there >are various true UNIX systems with more features for more money. For the >true hacker, not having source code is fatal, but for people who just >want a UNIX system, there are many alternatives (albeit not free). > >Andy Tanenbaum (ast@cs.vul.nl) Coherent is limited by a compiler that only supports the small memory model, making it just as difficult (perhaps more in some instances) to port 'standard' Unix programs to Coherent as it can be under Minix. Also, Coherent is not portable (or at least, to the best of my knowledge, has not been ported), so this advocacy contradicts one of your arguments against Linux. Since a true Unix system often costs as much as the machine it runs on (even more since many Unix providers un-bundle networking and development packages), buying a true Unix system is more than beyond the budget of many people. John W. Linville  0, unseen,, *** EOOH *** From: jerry@connection.prospect.com (Jerry Shekhel) Newsgroups: comp.os.minix Subject: Re: LINUX is obsolete Date: 6 Feb 92 21:28:05 GMT Organization: Polygen Corporation, Waltham, MA linville@garfield.catt.ncsu.edu (John W. Linville) writes: > >Since a true Unix system often costs as much as the machine it runs on (even >more since many Unix providers un-bundle networking and development packages), >buying a true Unix system is more than beyond the budget of many people. > For those who may be interested, MST sells System V Release 4.0.3 for the 386/486 for $399 including development system, $499 if you need networking. X11R5 binaries may be obtained via FTP (networking is not required for X11R5). I have just such a setup, and it works great. MST's version of UNIX doesn't have too much in the way of bug fixes relative to the AT&T code, but the only thing I've really had problems with was a couple of bugs in csh. Now that I have tcsh working (built without so much as a warning!) I'll never go back :-) Micro Station Technology 1140 Kentwood Avenue Cupertine, CA 95014 Tel: 408-253-3898 Fax: 408-253-7853 I am not affiliated with MST except as a customer. > >John W. Linville > -- +-------------------+----------------------+---------------------------------+ | JERRY J. SHEKHEL | POLYGEN CORPORATION | When I was young, I had to walk | | Drummers do it... | Waltham, MA USA | to school and back every day -- | | ... In rhythm! | (617) 890-2175 | 20 miles, uphill both ways. | +-------------------+----------------------+---------------------------------+ | ...! [ princeton mit-eddie bu sunne ] !polygen!jerry | | jerry@polygen.com | +----------------------------------------------------------------------------+  0, unseen,, *** EOOH *** From: meggin@epas.utoronto.ca (David Megginson) Newsgroups: comp.os.minix Subject: Re: LINUX is obsolete Date: 5 Feb 92 20:50:55 GMT Organization: University of Toronto - EPAS Nntp-Posting-Host: epas.utoronto.ca In article <12696@star.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes: >Another option that seems to be totally forgotten here is buy UNIX or a >clone. If you just want to USE the system, instead of hacking on its >internals, you don't need source code. Coherent is only $99, and there >are various true UNIX systems with more features for more money. For the >true hacker, not having source code is fatal, but for people who just >want a UNIX system, there are many alternatives (albeit not free). What Unix's _are_ available for a simple, M68000-based ST, with _or_ without source? These are the only options I know of: 1) OS 9. 2) The Beckmeyer MT C-Shell. 3) MiNT. 4) Minix. I have used all of these except for OS 9, and Minix is clearly the closest thing to Unix that I can run (though it is easier to port BSD programs to MiNT using the MiNT gcc library). I could shell out CAN $3000 for a TT, but then I may as well buy a 386 box anyway. Besides, I _like_ having the source. The extra advantage of Minix is that the user base is a lot wider than the ST market, so I can get decent system enhancements from Amiga, Mac, Sparc, XT, AT, '386 and '486 users as well as from fellow ST owners. David ################################################################# David Megginson meggin@epas.utoronto.ca Centre for Medieval Studies david@doe.utoronto.ca University of Toronto 39 Queen's Park Cr. E. #################################################################  0, unseen,, *** EOOH *** From: ajt@doc.ic.ac.uk (Tony Travis) Newsgroups: comp.os.minix Subject: Re: LINUX is obsolete Date: 6 Feb 92 02:17:13 GMT Organization: Department of Computing, Imperial College, University of London, UK. ast@cs.vu.nl (Andy Tanenbaum) writes: > Another option that seems to be totally forgotten here is buy UNIX or a > clone. If you just want to USE the system, instead of hacking on its > internals, you don't need source code. Coherent is only $99, and there > are various true UNIX systems with more features for more money. For the > true hacker, not having source code is fatal, but for people who just > want a UNIX system, there are many alternatives (albeit not free). Andy, I have followed the development of Minix since the first messages were posted to this group and I am now running 1.5.10 with Bruce Evans's patches for the 386. I 'just' want a Unix on my PC and I am not interested in hacking on its internals, but I *do* want the source code! An important principle underlying the success and popularity of Unix is the philosophy of building on the work of others. This philosophy relies upon the availability of the source code in order that it can be examined, modified and re-used in new software. Many years ago, I was in the happy position of being an AT&T Seventh Edition Unix source licencee but, even then, I saw your decision to make the source of Minix available as liberation from the shackles of AT&T copyright!! I think you may sometimes forget that your 'hobby' has had a profound effect on the availability of 'personal' Unix (ie. affordable Unix) and that the 8086 PC I ran Minix 1.2 on actually cost me considerably more than my present 386/SX clone. Clearly, Minix _cannot_ be all things to all men, but I see the progress to 386 versions in much the same way that I see 68000 or other linear address space architectures: it is a good thing for people like me who use Minix and feel constrained by the segmented architecture of the PC version for applications. NOTHING you can say would convince me that I should use Coherent ... Tony -- ------------------------------------------------------------------------------- Dr. A.J.Travis | Rowett Research Institute, | Greenburn Road, Bucksburn, Aberdeen, | AB2 9SB. UK. tel 0224-712751  0, unseen,, *** EOOH *** From: richard@aiai.ed.ac.uk (Richard Tobin) Newsgroups: comp.os.minix Subject: Re: LINUX is obsolete Date: 7 Feb 92 14:58:22 GMT Organization: AIAI, University of Edinburgh, Scotland In article <12696@star.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes: >If you just want to USE the system, instead of hacking on its >internals, you don't need source code. Unfortunately hacking on the internals is just what many of us want the system for... You'll be rid of most of us when BSD-detox or GNU comes out, which should happen in the next few months (yeah, right). -- Richard -- Richard Tobin, AI Applications Institute, R.Tobin@ed.ac.uk Edinburgh University.  0, unseen,, *** EOOH *** From: comm121@unixg.ubc.ca (Louie) Newsgroups: comp.os.minix Subject: Re: LINUX is obsolete Date: 30 Jan 92 02:55:22 GMT Organization: University of British Columbia, Vancouver, B.C., Canada Nntp-Posting-Host: chilko.ucs.ubc.ca In <12595@star.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes: >But in all honesty, I would >suggest that people who want a **MODERN** "free" OS look around for a >microkernel-based, portable OS, like maybe GNU or something like that. There are really no other alternatives other than Linux for people like me who want a "free" OS. Considering that the majority of people who would use a "free" OS use the 386, portability is really not all that big of a concern. If I had a Sparc I would use Solaris. As it stands, I installed Linux with gcc, emacs 18.57, kermit and all of the GNU utilities without any trouble at all. No need to apply patches. I just followed the installation instructions. I can't get an OS like this *anywhere* for the price to do my Computer Science homework. And it seems like network support and then X-Windows will be ported to Linux well before Minix. This is something that would be really useful. In my opinion, portability of standard Unix software is important also. I know that the design using a monolithic system is not as good as the microkernel. But for the short term future (And I know I won't/can't be uprading from my 386), Linux suits me perfectly. Philip Wu pwu@unixg.ubc.ca  0, unseen,, *** EOOH *** Newsgroups: comp.os.minix From: kevin@nuchat.sccsi.com (Kevin Brown) Subject: Re: LINUX is obsolete Organization: Hierarchical Date: Thu, 30 Jan 1992 01:36:43 GMT In article <12595@star.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes: > >I was in the U.S. for a couple of weeks, so I haven't commented much on >LINUX (not that I would have said much had I been around), but for what >it is worth, I have a couple of comments now. > >As most of you know, for me MINIX is a hobby, something that I do in the >evening when I get bored writing books and there are no major wars, >revolutions, or senate hearings being televised live on CNN. My real >job is a professor and researcher in the area of operating systems. > >As a result of my occupation, I think I know a bit about where operating >are going in the next decade or so. Two aspects stand out: > >1. MICROKERNEL VS MONOLITHIC SYSTEM > Most older operating systems are monolithic, that is, the whole operating > system is a single a.out file that runs in 'kernel mode.' This binary > contains the process management, memory management, file system and the > rest. Examples of such systems are UNIX, MS-DOS, VMS, MVS, OS/360, > MULTICS, and many more. > > The alternative is a microkernel-based system, in which most of the OS > runs as separate processes, mostly outside the kernel. They communicate > by message passing. The kernel's job is to handle the message passing, > interrupt handling, low-level process management, and possibly the I/O. > Examples of this design are the RC4000, Amoeba, Chorus, Mach, and the > not-yet-released Windows/NT. > > While I could go into a long story here about the relative merits of the > two designs, suffice it to say that among the people who actually design > operating systems, the debate is essentially over. Microkernels have won. > The only real argument for monolithic systems was performance, and there > is now enough evidence showing that microkernel systems can be just as > fast as monolithic systems (e.g., Rick Rashid has published papers comparing > Mach 3.0 to monolithic systems) that it is now all over but the shoutin`. Of course, there are some things that are best left to the kernel, be it micro or monolithic. Like things that require playing with the process' stack, e.g. signal handling. Like memory allocation. Things like that. The microkernel design is probably a win, all in all, over a monolithic design, but it depends on what you put in the kernel and what you leave out. > MINIX is a microkernel-based system. The file system and memory management > are separate processes, running outside the kernel. The I/O drivers are > also separate processes (in the kernel, but only because the brain-dead > nature of the Intel CPUs makes that difficult to do otherwise). Minix is a microkernel design, of sorts. The problem is that it gives special priveleges to mm and fs, when there shouldn't be any (at least for fs). It also fails to integrate most of the functionality of mm in the kernel itself, and this makes things like signal handling and memory allocation *really* ugly. If you did these things in the kernel itself, then signal handling would be as simple as setting a virtual interrupt vector and causing the signalled process to receive that interrupt (with the complication that system calls might have to be terminated. Which means that a message would have to be sent to every process that is servicing the process' system call, if any. It's considerations like these that make the monolithic kernel design appealing). The *entire* system call interface in Minix needs to be rethought. As it stands right now, the file system is not just a file system, it's also a system-call server. That functionality needs to be separated out in order to facilitate a multiple file system architecture. Message passing is probably the right way to go about making the call and waiting for it, but the message should go to a system call server, not the file system itself. In order to handle all the special caveats of the Unix API, you end up writing a monolithic "kernel" even if you're using a microkernel base. You end up with something called a "server", and an example is the BSD server that runs under Mach. And, in any case, the message-passing in Minix needs to be completely redone. As it is, it's a kludge. I've been giving this some thought, but I haven't had time to do anything with what I've thought of so far. Suffice it to say that the proper way to do message-passing is probably with message ports (both public and private), with the various visible parts of the operating system having public message ports. Chances are, that ends up being the system call server only, though this will, of course, depend on the goals of the design. > LINUX is > a monolithic style system. This is a giant step back into the 1970s. > That is like taking an existing, working C program and rewriting it in > BASIC. To me, writing a monolithic system in 1991 is a truly poor idea. Depends on the design criteria, as you should know. If your goal is to design a Unix workalike that is relatively simple and relatively small, then a monolithic design is probably the right approach for the job, because unless you're designing for really backwards hardware, the problems of things like interrupted system calls, memory allocation within the kernel (so you don't have to statically allocate *everything* in your OS), signal handling, etc. all go away (or are at least minimized) if you use a monolithic design. If you want the ability to bring up and take down file systems, add and remove device drivers, etc., all at runtime, then a microkernel approach is the right solution. Frankly, I happen to like the idea of removable device drivers and such, so I tend to favor the microkernel approach as a general rule. >2. PORTABILITY > Once upon a time there was the 4004 CPU. When it grew up it became an > 8008. Then it underwent plastic surgery and became the 8080. It begat > the 8086, which begat the 8088, which begat the 80286, which begat the > 80386, which begat the 80486, and so on unto the N-th generation. In > the meantime, RISC chips happened, and some of them are running at over > 100 MIPS. Speeds of 200 MIPS and more are likely in the coming years. > These things are not going to suddenly vanish. What is going to happen > is that they will gradually take over from the 80x86 line. They will > run old MS-DOS programs by interpreting the 80386 in software. (I even > wrote my own IBM PC simulator in C, which you can get by FTP from > ftp.cs.vu.nl = 192.31.231.42 in dir minix/simulator.) I think it is a > gross error to design an OS for any specific architecture, since that is > not going to be around all that long. Again, look at the design criteria. If portability isn't an issue, then why worry about it? While LINUX suffers from lack of portability, portability was obviously never much of a consideration for its author, who explicitly stated that it was written as an exercise in learning about the 386 architecture. And, in any case, while MINIX is portable in the sense that most of the code can be ported to other platforms, it *still* suffers from the limitations of the original target machine that drove the walk down the design decision tree. The message passing is a kludge because the 8088 is slow. The kernel doesn't do memory allocation (thus not allowing FS and the drivers to get away with using a malloc library or some such, and thus causing everyone to have to statically allocate everything), probably due to some other limitation of the 8088. The very idea of using "clicks" is obviously the result of the segmented architecture of the 8088. The file system size is too limited (theoretically fixed in 1.6, but now you have *two* file system formats to contend with. If having the file system as a separate process is such a big win, then why don't we have two file system servers, eh? Why simply extend the existing Minix file system instead of implementing BSD's FFS or some other high-performance file system? It's not that I'm greedy or anything... :-). > MINIX was designed to be reasonably portable, and has been ported from the > Intel line to the 680x0 (Atari, Amiga, Macintosh), SPARC, and NS32016. > LINUX is tied fairly closely to the 80x86. Not the way to go. All in all, I tend to agree. >Don`t get me wrong, I am not unhappy with LINUX. It will get all the people >who want to turn MINIX in BSD UNIX off my back. But in all honesty, I would >suggest that people who want a **MODERN** "free" OS look around for a >microkernel-based, portable OS, like maybe GNU or something like that. Yeah, right. Point me someplace where I can get a free "modern" OS and I'll gladly investigate. But the GNU OS is currently vaporware, and as far as I'm concerned it will be for a LOOOOONG time to come. Any other players? BSD 4.4 is a monolithic architecture, so by your definition it's out. Mach is free, but the BSD server isn't (AT&T code, you know), and in any case, isn't the BSD server something you'd consider to be a monolithic design??? Really. Why do you think LINUX is as popular as it is? The answer is simple, of course: because it's the *only* free Unix workalike OS in existence. BSD doesn't qualify (yet). Minix doesn't qualify. XINU isn't even in the running. GNU's OS is vaporware, and probably will be for a long time, so *by definition* it's not in the running. Any other players? I haven't heard of any... >Andy Tanenbaum (ast@cs.vu.nl) Minix is an excellent piece of work. A good starting point for anyone who wants to learn about operating systems. But it needs rewriting to make it truly elegant and functional. As it is, there are too many kludges and hacks (e.g., the message passing). Kevin Brown  0, unseen,, *** EOOH *** From: aduncan@rhea.trl.OZ.AU (Allan Duncan) Newsgroups: comp.os.minix Subject: Re: LINUX is obsolete Date: 2 Feb 92 22:06:26 GMT Organization: Telecom Research Labs, Melbourne, Australia From article <1992Jan30.013643.3248@menudo.uh.edu>, by kevin@nuchat.sccsi.com (Kevin Brown): > The *entire* system call interface in Minix needs to be rethought. As it > stands right now, the file system is not just a file system, it's also a > system-call server. That functionality needs to be separated out in order > to facilitate a multiple file system architecture. Message passing is > probably the right way to go about making the call and waiting for it, but > the message should go to a system call server, not the file system itself. > > In order to handle all the special caveats of the Unix API, you end up writing > a monolithic "kernel" even if you're using a microkernel base. You end up > with something called a "server", and an example is the BSD server that runs > under Mach. > > And, in any case, the message-passing in Minix needs to be completely redone. > As it is, it's a kludge. I've been giving this some thought, but I haven't > had time to do anything with what I've thought of so far. Suffice it to say > that the proper way to do message-passing is probably with message ports > (both public and private), with the various visible parts of the operating > system having public message ports. Chances are, that ends up being the > system call server only, though this will, of course, depend on the goals > of the design. It gets to sound more and more like Tripos and the Amiga :-) Allan Duncan ACSnet aduncan@trl.oz (+613) 541 6708 Internet aduncan@trl.oz.au UUCP {uunet,hplabs,ukc}!munnari!trl.oz.au!aduncan Telecom Research Labs, PO Box 249, Clayton, Victoria, 3168, Australia.  0, unseen,, *** EOOH *** From: kevin@taronga.taronga.com (Kevin Brown) Newsgroups: comp.os.minix Subject: Re: LINUX is obsolete Date: 4 Feb 92 08:28:08 GMT Organization: University of Houston In article <1992Feb2.220626.25197@trl.oz.au> aduncan@rhea.trl.OZ.AU (Allan Duncan) writes: >From article <1992Jan30.013643.3248@menudo.uh.edu>, by kevin@nuchat.sccsi.com (Kevin Brown): > >> The *entire* system call interface in Minix needs to be rethought. As it >> stands right now, the file system is not just a file system, it's also a >> system-call server. That functionality needs to be separated out in order >> to facilitate a multiple file system architecture. Message passing is >> probably the right way to go about making the call and waiting for it, but >> the message should go to a system call server, not the file system itself. >> >> In order to handle all the special caveats of the Unix API, you end up writing >> a monolithic "kernel" even if you're using a microkernel base. You end up >> with something called a "server", and an example is the BSD server that runs >> under Mach. >> >> And, in any case, the message-passing in Minix needs to be completely redone. >> As it is, it's a kludge. I've been giving this some thought, but I haven't >> had time to do anything with what I've thought of so far. Suffice it to say >> that the proper way to do message-passing is probably with message ports >> (both public and private), with the various visible parts of the operating >> system having public message ports. Chances are, that ends up being the >> system call server only, though this will, of course, depend on the goals >> of the design. > >It gets to sound more and more like Tripos and the Amiga :-) There's no question that many of my ideas spring from the architecture of the Amiga's operating system. It's pretty impressive to see a message-passing, multitasking operating system that operates as fast as the Amiga's OS does on hardware that slow. They did a lot of things right. There are some ideas that, I think, are my own. Or, at least, that I've developed independently. For example, if you have a message-passing system that includes the option to transfer message memory ownership to the target process, then it naturally follows that you can globally optimize the use of your block cache by making your block cache global with respect to *all* filesystems. The filesystem code requests blocks from the block cache manager and tells the block cache manager what device driver to call and what parameters to send it when flushing the block. The block cache manager replies with a message that is the size of a block (or, if you wish to allocate several at a time, several blocks). Since ownership is transferred as a result of passing the message, the block cache manager can allocate the memory itself, optionally flushing as many blocks as it needs in order to free up enough to send to the caller. The block cache manager is, of course, a user process. If the filesystem code is written right, you can kill the block cache manager in order to disable the block cache. The filesystem will simply do its thing unbuffered. Makes for a slow system, but at least you can do it. You can also change the behavior of the buffer cache by sending control messages to the cache manager. Can you say "tunable parameters"? :-) You could also accomplish this with some sort of shared memory, but this would require semaphore control of the allocation list. You'd also have to figure out a way to flush bits of the cache when needed (easy to do if you're a monolithic kernel, but I'm referring to a microkernel) without colliding with another process writing into the block. Semaphore control of the individual blocks as well? >Allan Duncan ACSnet aduncan@trl.oz >(+613) 541 6708 Internet aduncan@trl.oz.au > UUCP {uunet,hplabs,ukc}!munnari!trl.oz.au!aduncan >Telecom Research Labs, PO Box 249, Clayton, Victoria, 3168, Australia. Kevin Brown  0, unseen,, *** EOOH *** From: dgraham@bmers30.bnr.ca (Douglas Graham) Newsgroups: comp.os.minix Subject: Re: LINUX is obsolete Date: 1 Feb 92 00:26:30 GMT Organization: Bell-Northern Research, Ottawa, Canada In article <12595@star.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes: > While I could go into a long story here about the relative merits of the > two designs, suffice it to say that among the people who actually design > operating systems, the debate is essentially over. Microkernels have won. Can you recommend any (unbiased) literature that points out the strengths and weaknesses of the two approaches? I'm sure that there is something to be said for the microkernel approach, but I wonder how closely Minix resembles the other systems that use it. Sure, Minix uses lots of tasks and messages, but there must be more to a microkernel architecture than that. I suspect that the Minix code is not split optimally into tasks. > The only real argument for monolithic systems was performance, and there > is now enough evidence showing that microkernel systems can be just as > fast as monolithic systems (e.g., Rick Rashid has published papers comparing > Mach 3.0 to monolithic systems) that it is now all over but the shoutin`. My main complaint with Minix is not it's performance. It is that adding features is a royal pain -- something that I presume a microkernel architecure is supposed to alleviate. > MINIX is a microkernel-based system. Is there a consensus on this? > LINUX is > a monolithic style system. This is a giant step back into the 1970s. > That is like taking an existing, working C program and rewriting it in > BASIC. To me, writing a monolithic system in 1991 is a truly poor idea. This is a fine assertion, but I've yet to see any rationale for it. Linux is only about 12000 lines of code I think. I don't see how splitting that into tasks and blasting messages around would improve it. >Don`t get me wrong, I am not unhappy with LINUX. It will get all the people >who want to turn MINIX in BSD UNIX off my back. But in all honesty, I would >suggest that people who want a **MODERN** "free" OS look around for a >microkernel-based, portable OS, like maybe GNU or something like that. Well, there are no other choices that I'm aware of at the moment. But when GNU OS comes out, I'll very likely jump ship again. I sense that you *are* somewhat unhappy about Linux (and that surprises me somewhat). I would guess that the reason so many people embraced it, is because it offers more features. Your approach to people requesting features in Minix, has generally been to tell them that they didn't really want that feature anyway. I submit that the exodus in the direction of Linux proves you wrong. Disclaimer: I had nothing to do with Linux development. I just find it an easier system to understand than Minix. -- Doug Graham dgraham@bnr.ca My opinions are my own.  0, unseen,, *** EOOH *** From: peter@ferranti.com (peter da silva) Newsgroups: comp.os.minix Subject: Re: LINUX is obsolete Date: 3 Feb 92 17:40:06 GMT Organization: Xenix Support, FICC In article <1992Feb01.002630.14861@bmerh2.bnr.ca> dgraham@bmers30.bnr.ca (Douglas Graham) writes: > Minix resembles the other systems that use it. Sure, Minix uses lots > of tasks and messages, but there must be more to a microkernel architecture > than that. I suspect that the Minix code is not split optimally into tasks. Definitely. Minix shows you how a microkernel works, but it sure doesn't show you why you would use one. A couple of years ago I brought this up with Andy, and his response indicated that he was himself not convinced of the superiority of the microkernel design at the time. He said (as near as I can recall... this is a paraphrase) that a message passing design was inherently slower than a monolithic one... which was news to me: I had (and still have) a PC that was MUCH more responsive than any UNIX box I ever touched using a message-passing design. > > MINIX is a microkernel-based system. > Is there a consensus on this? Yes, it's not a well-factored one, and there's no API to the microkernel interface, but it's a microkernel design. -- -- Peter da Silva, Ferranti International Controls Corporation -- Sugar Land, TX 77487-5012; +1 713 274 5180 -- "Have you hugged your wolf today?"  0, unseen,, *** EOOH *** From: hedrick@klinzhai.rutgers.edu (Charles Hedrick) Newsgroups: comp.os.minix Subject: Re: LINUX is obsolete Date: 1 Feb 92 00:27:04 GMT Organization: Rutgers Univ., New Brunswick, N.J. The history of software shows that availability wins out over technical quality every time. That's Linux' major advantage. It's a small 386-based system that's fairly compatible with generic Unix, and is freely available. I dropped out of the Minix community a couple of years ago when it became clear that (1) Minix was not going to take advantage of anything beyond the 8086 anytime in the near future, and (2) the licensing -- while amazingly friendly -- still made it hard for people who were interested in producing a 386 version. Several people apparently did nice work for the 386. But all they could distribute were diffs. This made bringing up a 386 system a job that isn't practical for a new user, and in fact I wasn't sure I wanted to do it. I apologize if things have changed in the last couple of years. If it's now possible to get a 386 version in a form that's ready to run, the community has developed a way to share Minix source, and bringing up normal Unix programs has become easier in the interim, then I'm willing to reconsider Minix. I do like its design. It's possible that Linux will be overtaken by Gnu or a free BSD. However, if the Gnu OS follows the example of all other Gnu software, it will require a system with 128MB of memory and a 1GB disk to use. There will still be room for a small system. My ideal OS would be 4.4 BSD. But 4.4's release date has a history of extreme slippage. With most of their staff moving to BSDI, it's hard to believe that this situation is going to be improved. For my own personal use, the BSDI system will probably be great. But even their very attractive pricing is likely to be too much for most of our students, and even though users can get source from them, the fact that some of it is proprietary will again mean that you can't just put altered code out for public FTP. At any rate, Linux exists, and the rest of these alternatives are vapor.  0, unseen,, *** EOOH *** From: nhc@cbnewsj.cb.att.com (n.h.chandler) Newsgroups: comp.os.minix Subject: Re: LINUX is obsolete Summary: How can I get a copy of Linux? Date: 2 Feb 92 01:38:51 GMT Organization: AT&T Bell Laboratories I have been following the Minix/Linux discussion. How can I get a copy of Linux? Neville H. Chandler cbnewsj!nhc@att.com  0, unseen,, *** EOOH *** From: tytso@athena.mit.edu (Theodore Y. Ts'o) Newsgroups: comp.os.minix Subject: Re: LINUX is obsolete Date: 31 Jan 92 21:40:23 GMT Organization: Massachusetts Institute of Technology In-Reply-To: ast@cs.vu.nl's message of 29 Jan 92 12: 12:50 GMT Nntp-Posting-Host: sos.mit.edu >From: ast@cs.vu.nl (Andy Tanenbaum) >ftp.cs.vu.nl = 192.31.231.42 in dir minix/simulator.) I think it is a >gross error to design an OS for any specific architecture, since that is >not going to be around all that long. It's not your fault for believing that Linux is tied to the 80386 architecture, since many Linux supporters (including Linus himself) have made the this statement. However, the amount of 80386-specific code is probably not much more than what is in a Minix implementation, and there is certainly a lot less 80386 specific code in Linux than here is Vax-specific code in BSD 4.3. Granted, the port to other architectures hasn't been done yet. But if I were going to bring up a Unix-like system on a new architecture, I'd probably start with Linux rather than Minix, simply because I want to have some control over what I can do with the resulting system when I'm done with it. Yes, I'd have to rewrite large portions of the VM and device driver layers --- but I'd have to do that with any other OS. Maybe it would be a little bit harder than it would to port Minix to the new architecture; but this would probably be only true for the first architecture that we ported Linux to. >While I could go into a long story here about the relative merits of the >two designs, suffice it to say that among the people who actually design >operating systems, the debate is essentially over. Microkernels have won. >The only real argument for monolithic systems was performance, and there >is now enough evidence showing that microkernel systems can be just as >fast as monolithic systems (e.g., Rick Rashid has published papers comparing >Mach 3.0 to monolithic systems) that it is now all over but the shoutin`. This is not necessarily the case; I think you're painting a much more black and white view of the universe than necessarily exists. I refer you to such papers as Brent Welsh's (welch@parc.xerox.com) "The Filsystem Belongs in the Kernel" paper, where in he argues that the filesystem is a mature enough abstraction that it should live in the kernel, not outside of it as it would in a strict microkernel design. There also several people who have been concerned about the speed of OSF/1 Mach when compared with monolithic systems; in particular, the nubmer of context switches required to handle network traffic, and networked filesystems in particular. I am aware of the benefits of a micro kernel approach. However, the fact remains that Linux is here, and GNU isn't --- and people have been working on Hurd for a lot longer than Linus has been working on Linux. Minix doesn't count because it's not free. :-) I suspect that the balance of micro kernels versus monolithic kernels depend on what you're doing. If you're interested in doing research, it is obviously much easier to rip out and replace modules in a micro kernel, and since only researchers write papers about operating systems, ipso facto micro kernels must be the right approach. However, I do know a lot of people who are not researchers, but who are rather practical kernel programmers, who have a lot of concerns over the cost of copying and the cost of context switches which are incurred in a micro kernel. By the way, I don't buy your arguments that you don't need a multi-threaded filesystem on a single user system. Once you bring up a windowing system, and have a compile going in one window, a news reader in another window, and UUCP/C News going in the background, you want good filesystem performance, even on a single-user system. Maybe to a theorist it's an unnecessary optimization and a (to use your words) "performance hack", but I'm interested in a Real operating system --- not a research toy. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Theodore Ts'o bloom-beacon!mit-athena!tytso 308 High St., Medford, MA 02155 tytso@athena.mit.edu Everybody's playing the game, but nobody's rules are the same!  0, unseen,, *** EOOH *** From: peter@ferranti.com (peter da silva) Newsgroups: comp.os.minix Subject: Re: LINUX is obsolete Date: 3 Feb 92 17:32:54 GMT Organization: Xenix Support, FICC In article tytso@athena.mit.edu (Theodore Y. Ts'o) writes: > This is not necessarily the case; I think you're painting a much more > black and white view of the universe than necessarily exists. I refer > you to such papers as Brent Welsh's (welch@parc.xerox.com) "The > Filsystem Belongs in the Kernel" paper, where in he argues that the > filesystem is a mature enough abstraction that it should live in the > kernel, not outside of it as it would in a strict microkernel design. What does "a mature enough abstraction" mean, here? Things don't move into the kernel simply because they're now considered safe and stable enough, but because they're too inefficient when they're outside it or they lose functionality by being outside it, and there's no easy fix. The Amiga operating system certainly benefits from having a file system outside the kernel. There are dozens of file systems, many of them written by hobbyists, available. Ideas like "assigned paths" can be played with in the file system without breaking stuff. All these file systems have a common interface and so look to the application as part of the operating system, but just because something is on the other side of the API doesn't mean it is, or belongs, in the kernel. > There also several people who have been concerned about the speed of > OSF/1 Mach when compared with monolithic systems; in particular, the > nubmer of context switches required to handle network traffic, and > networked filesystems in particular. If this is because the networking was moved out of the kernel, I consider it a price well worth paying. Having networking code in the kernel is the source of many subtle bugs in networks. Just for something that bit us, what happens if you need to get to the upper level driver before you can acknowledge a packet, but the process that you need to run is hung up in the tty driver waiting for a ^Q? Something *I* would have expected to find in the kernel before now, yet isn't, is windowing systems. With a microkernel (and the associated lower *cost* of a context switch) you can get much of the advantages of a kernel window system without paying the cost in complexity. -- -- Peter da Silva, Ferranti International Controls Corporation -- Sugar Land, TX 77487-5012; +1 713 274 5180 -- "Have you hugged your wolf today?"  0, unseen,, *** EOOH *** From: joe@jshark.rn.com Newsgroups: comp.os.minix Subject: Re: LINUX is obsolete Date: 31 Jan 92 13:21:44 GMT Organization: a blip of entropy In article <12595@star.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes: > > MINIX was designed to be reasonably portable, and has been ported from the > Intel line to the 680x0 (Atari, Amiga, Macintosh), SPARC, and NS32016. > LINUX is tied fairly closely to the 80x86. Not the way to go. If you looked at the source instead of believing the author, you'd realise this is not true! He's replaced 'fubyte' by a routine which explicitly uses a segment register - but that could be easily changed. Similarly, apart from a couple of places which assume the '386 MMU, a couple of macros to hide the exact page sizes etc would make porting trivial. Using '386 TSS's makes the code simpler, but the VAX and WE32000 have similar structures. As he's already admitted, a bit of planning would have the the system neater, but merely putting '386 assembler around isn't a crime! And with all due respect: - the Book didn't make an issue of portability (apart from a few "#ifdef M8088"s) - by the time it was released, Minix had come to depend on several 8086 "features" that caused uproar from the 68000 users. >Andy Tanenbaum (ast@cs.vu.nl) joe. -- joe@jshark.rn.com  0, unseen,, *** EOOH *** From: joe@jshark.rn.com Newsgroups: comp.os.minix Subject: Re: LINUX is obsolete Date: 2 Feb 92 23:59:12 GMT Organization: Jshark Communications In article <12595@star.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes: > >I was in the U.S. for a couple of weeks, so I haven't commented much on >LINUX (not that I would have said much had I been around), but for what >it is worth, I have a couple of comments now. Maybe keepng quiet would have been best. >1. MICROKERNEL VS MONOLITHIC SYSTEM > > While I could go into a long story here about the relative merits of the > two designs, suffice it to say that among the people who actually design > operating systems, the debate is essentially over. No, MS-DOS won. Sad, but there you are. 60 million: Next It would be churlish to point out that MS-DOS has loadable device drivers and that VMS is now (basically)a set of loadable service modules and drivers. "Microkernel" was the buzz-word of last year, so Minix is a microkernel. "Object-oriented" is this years, so Minix is object-oriented - right? joe. ---- joe@jshark.rn.com uunet!nstar!jshark!joe I'm a mutated .sig virus, I got this from Henry Spencer's: "As a user, I'll take speed over features anyday" - A Tanenbaum  0, unseen,, *** EOOH *** From: entropy@wintermute.WPI.EDU (Lawrence C. Foard) Newsgroups: comp.os.minix Subject: Re: LINUX is obsolete Date: 5 Feb 92 14:56:30 GMT Organization: Worcester Polytechnic Institute Nntp-Posting-Host: wintermute.wpi.edu In article <12595@star.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes: >Don`t get me wrong, I am not unhappy with LINUX. It will get all the people >who want to turn MINIX in BSD UNIX off my back. But in all honesty, I would >suggest that people who want a **MODERN** "free" OS look around for a >microkernel-based, portable OS, like maybe GNU or something like that. I believe you have some valid points, although I am not sure that a microkernel is necessarily better. It might make more sense to allow some combination of the two. As part of the IPC code I'm writting for Linux I am going to include code that will allow device drivers and file systems to run as user processes. These will be significantly slower though, and I believe it would be a mistake to move everything outside the kernel (TCP/IP will be internal). Actually my main problem with OS theorists is that they have never tested there ideas! None of these ideas (with a partial exception for MACH) has ever seen the light of day. 32 bit home computers have been available for almost a decade and Linus was the first person to ever write a working OS for them that can be used without paying AT&T $100,000. A piece of software in hand is worth ten pieces of vaporware, OS theorists are quick to jump all over an OS but they are unwilling to ever provide an alternative. The general consensus that Micro kernels is the way to go means nothing when a real application has never even run on one. The release of Linux is allowing me to try some ideas I've been wanting to experment with for years, but I have never had the opportunity to work with source code for a functioning OS. -- Disclaimer: Opinions are based on logic rather than biblical "fact". ------ Hackers do it for fun. | First they came for the drug users, I said \ / "Profesionals" do it for money. | nothing, then they came for hackers, \ / Managers have others do it for them. | I said nothing... STOP W.O.D. \/  0, unseen,, *** EOOH *** From: ast@cs.vu.nl (Andy Tanenbaum) Newsgroups: comp.os.minix Subject: Re: LINUX is obsolete Date: 5 Feb 92 23:33:23 GMT Organization: Fac. Wiskunde & Informatica, Vrije Universiteit, Amsterdam In article <1992Feb5.145630.759@wpi.WPI.EDU> entropy@wintermute.WPI.EDU (Lawrence C. Foard) writes: >Actually my main problem with OS theorists is that they have never tested >there ideas! I'm mortally insulted. I AM NOT A THEORIST. Ask anybody who was at our department meeting yesterday (in joke). Actually, these ideas have been very well tested in practice. OSF is betting its whole business on a microkernel (Mach 3.0). USL is betting its business on another one (Chorus). Both of these run lots of software, and both have been extensively compared to monolithic systems. Amoeba has been fully implemented and tested for a number of applications. QNX is a microkernel based system, and someone just told me the installed base is 200,000 systems. Microkernels are not a pipe dream. They represent proven technology. The Mach guys wrote a paper called "UNIX as an application program." It was by Golub et al., in the Summer 1990 USENIX conference. The Chorus people also have a technical report on microkernel performance, and I coauthored another paper on the subject, which I mentioned yesterday (Dec. 1991 Computing Systems). Check them out. Andy Tanenbaum (ast@cs.vu.nl)  0, unseen,, *** EOOH *** From: wolff@neuron.et.tudelft.nl (Rogier Wolff) Newsgroups: comp.os.minix Subject: Re: LINUX is obsolete Date: 8 Feb 92 09:13:39 GMT Organization: Delft University of Technology, Dept. of Electrical Engineering Nntp-Posting-Host: neuron.et.tudelft.nl ast@cs.vu.nl (Andy Tanenbaum) writes: >In article <1992Feb5.145630.759@wpi.WPI.EDU> entropy@wintermute.WPI.EDU (Lawrence C. Foard) writes: >>Actually my main problem with OS theorists is that they have never tested >>there ideas! >I'm mortally insulted. I AM NOT A THEORIST. Ask anybody who was at our >department meeting yesterday (in joke). >Actually, these ideas have been very well tested in practice. The problem is that to really do an unbiased test you would need two *identical* teams, and ask them to make two OS's, for the same destination machine, one using a microkernel architecture, and the other using the monolithic approach. This is in practice not feasable and the publications on the subject can only shout: "look: I've got a good performance using a microkernel", "we've got very good performance using a monolithic aproach" or "it only took us X months to implement this OS" If people did benchmark their OS's they wrote the OS for one architecture, and adapted it to test the other. This adaptation will naturally degrade performance, and show that the designers were right in the first place. Anyway, anybody have an opinion about the fact that code for printf is included three times in the Minix OS when it runs (once in the kernel, MM and FS) Roger -- If the opposite of "pro" is "con", what is the opposite of "progress"? (stolen from kadokev@iitvax ==? technews@iitmax.iit.edu) EMail: wolff@duteca.et.tudelft.nl ** Tel +31-15-783644 or +31-15-142371  0, unseen,, *** EOOH *** From: meggin@epas.utoronto.ca (David Megginson) Newsgroups: comp.os.minix Subject: Re: LINUX is obsolete Date: 8 Feb 92 15:04:31 GMT Organization: University of Toronto - EPAS Nntp-Posting-Host: epas.utoronto.ca In article <1992Feb08.091339.16121@donau.et.tudelft.nl> wolff@neuron.et.tudelft.nl (Rogier Wolff) writes: >Anyway, anybody have an opinion about the fact that code for printf >is included three times in the Minix OS when it runs (once in the >kernel, MM and FS) Back in the yore days, this might have been a problem. I remember when every program, even wordprocessors, had to be written in assembler to squeeze them down to the smallest size possible for a 64K system. One of the reasons WordPerfect is such a mess today is that it was written in assembler instead of C. Now, even the small systems which Minix runs have at least 640K, so a few wasted bytes are not so much of a problem. Why not write Linux in 80386 assembler? It would be smaller and even faster. And don't forget to code inline as much as possible, to avoid the crippling overhead of function calls. And leave out comments, because they waste disk space. David ################################################################# David Megginson meggin@epas.utoronto.ca Centre for Medieval Studies david@doe.utoronto.ca University of Toronto 39 Queen's Park Cr. E. #################################################################  0, unseen,, *** EOOH *** From: cs2@doc.ic.ac.uk (Christopher Stuart) Newsgroups: comp.os.minix Subject: Re: LINUX is obsolete Date: 11 Feb 92 13:52:57 GMT Organization: Department of Computing, Imperial College, University of London, UK. Nntp-Posting-Host: oak10.doc.ic.ac.uk Article 18297 of comp.os.minix: Path: icdoc!uknet!mcsun!uunet!cis.ohio-state.edu!rutgers!news-server.csri.toronto.edu!utgpu!news-server.ecf!epas!meggin From: meggin@epas.utoronto.ca (David Megginson) Newsgroups: comp.os.minix Subject: Re: LINUX is obsolete Message-ID: <1992Feb8.150431.11030@epas.toronto.edu> Date: 8 Feb 92 15:04:31 GMT References: <1992Feb5.145630.759@wpi.WPI.EDU> <12747@star.cs.vu.nl> <1992Feb08.091339.16121@donau.et.tudelft.nl> Sender: news@epas.toronto.edu (USENET) Organization: University of Toronto - EPAS Lines: 28 Nntp-Posting-Host: epas.utoronto.ca In article <1992Feb08.091339.16121@donau.et.tudelft.nl> wolff@neuron.et.tudelft.nl (Rogier Wolff) writes: >Anyway, anybody have an opinion about the fact that code for printf >is included three times in the Minix OS when it runs (once in the >kernel, MM and FS) Back in the yore days, this might have been a problem. I remember when every program, even wordprocessors, had to be written in assembler to squeeze them down to the smallest size possible for a 64K system. One of the reasons WordPerfect is such a mess today is that it was written in assembler instead of C. Now, even the small systems which Minix runs have at least 640K, so a few wasted bytes are not so much of a problem. Why not write Linux in 80386 assembler? It would be smaller and even faster. And don't forget to code inline as much as possible, to avoid the crippling overhead of function calls. And leave out comments, because they waste disk space. David ################################################################# David Megginson meggin@epas.utoronto.ca Centre for Medieval Studies david@doe.utoronto.ca University of Toronto 39 Queen's Park Cr. E. ################################################################# -- /*----------------------------------------------------------------------------*/ /* Christopher Stuart: cs2@doc.ic.ac.uk */ /* Dept. Computing, Imperial College, London. */ /*----------------------------------------------------------------------------*/  0, unseen,, *** EOOH *** From: peter@ferranti.com (peter da silva) Newsgroups: comp.os.minix Subject: Re: LINUX is obsolete Date: 10 Feb 92 03:10:00 GMT Organization: Xenix Support, FICC In article <1992Feb08.091339.16121@donau.et.tudelft.nl> wolff@neuron.et.tudelft.nl (Rogier Wolff) writes: > The problem is that to really do an unbiased test you would need two > *identical* teams, and ask them to make two OS's [...] No, you don't. I don't think there's any question that a macrokernel is very easy to get decent performance out of. Where the microkernel design has a major advantage is in flexibility. Adding stuff to a macrokernel is fairly complex and quickly becomes pretty gross. Look at BSD or System V for examples. Adding stuff to a well designed microkernel is VERY easy. Sometimes you don't want to compare oranges and oranges. Sometimes you want to compare concentrated orange juice with fresh-squeezed. Fresh-squeezed takes longer, but it's worth it. Plus, with a microkernel you can get much better context switching between microtasks than macro processes. So you can do stuff in separate processes that would be out of the question in a macrokernel, and avoid nonsense like the myriad inconsistencies in NFS. > anyone have an opinion about why the code for printf > is included three times in the Minix OS when it runs (once in the > kernel, MM and FS) Anyone have an opinion why the code for printf is included only once in AmigaOS (even though the AmigaOS 2.04 "kernel" is actually a dozen or more separate processes)? Minix is a poor technology demonstrator for microkernels. Which is OK, since it wasn't supposed to be one. -- -- Peter da Silva, Ferranti International Controls Corporation -- Sugar Land, TX 77487-5012; +1 713 274 5180 -- "Have you hugged your wolf today?"  0, unseen,, *** EOOH *** Newsgroups: comp.os.minix From: peter@ferranti.com (peter da silva) Subject: Re: LINUX is obsolete Organization: Xenix Support, FICC Date: Thu, 6 Feb 1992 16:02:47 GMT In article <12747@star.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes: > QNX is a microkernel > based system, and someone just told me the installed base is 200,000 systems. Oh yes, while I'm on the subject... there are over 3 million Amigas out there, which means that there are more of them than any UNIX vendor has shipped, and probably more than all UNIX systems combined. -- -- Peter da Silva, Ferranti International Controls Corporation -- Sugar Land, TX 77487-5012; +1 713 274 5180 -- "Have you hugged your wolf today?"  0, unseen,, *** EOOH *** From: tim@maths.tcd.ie (Timothy Murphy) Newsgroups: comp.os.minix Subject: Re: LINUX is obsolete Date: 6 Feb 92 11:14:59 GMT Organization: Dept. of Maths, Trinity College, Dublin, Ireland. Nntp-Posting-Host: salmon In <1992Feb5.145630.759@wpi.WPI.EDU> entropy@wintermute.WPI.EDU (Lawrence C. Foard) writes: >32 bit home computers have been available for almost a >decade and Linus was the first person to ever write a working OS for them >that can be used without paying AT&T $100,000. A piece of software in hand is >worth ten pieces of vaporware, OS theorists are quick to jump all over an OS >but they are unwilling to ever provide an alternative. Surely Bruce Evans' 386-Minix preceded Linux? (Diffs for PC-Minix -> 386-Minix available from archive-server@plains.nodak.edu in the directory Minix/oz) -- Timothy Murphy e-mail: tim@maths.tcd.ie tel: +353-1-2842366 s-mail: School of Mathematics, Trinity College, Dublin 2, Ireland  0, unseen,, *** EOOH *** From: ts@cup.portal.com (Tim W Smith) Newsgroups: comp.os.minix Subject: Re: LINUX is obsolete Date: 7 Feb 92 02:09:23 GMT Organization: The Portal System (TM) > Actually my main problem with OS theorists is that they have never tested > there ideas! None of these ideas (with a partial exception for MACH) has ever > seen the light of day. 32 bit home computers have been available for almost a > decade and Linus was the first person to ever write a working OS for them > that can be used without paying AT&T $100,000. A piece of software in hand is How about Netware 386 from Novell? It seems to work. Tim Smith  0, unseen,, *** EOOH *** Newsgroups: comp.os.minix From: peter@ferranti.com (peter da silva) Subject: Re: LINUX is obsolete Organization: Xenix Support, FICC Date: Thu, 6 Feb 1992 16:00:22 GMT In article <1992Feb5.145630.759@wpi.WPI.EDU> entropy@wintermute.WPI.EDU (Lawrence C. Foard) writes: > Actually my main problem with OS theorists is that they have never tested > there ideas! I beg to differ... there are many microkernel operating systems out there for everything from an 8088 (QNX) up to large research systems. > None of these ideas (with a partial exception for MACH) has ever > seen the light of day. 32 bit home computers have been available for almost a > decade and Linus was the first person to ever write a working OS for them > that can be used without paying AT&T $100,000. I must have been imagining AmigaOS, then. I've been using a figment of my imagination for the past 6 years. AmigaOS is a microkernel message-passing design, with better response time and performance than any other readily available PC operating system: including MINIX, OS/2, Windows, MacOS, Linux, UNIX, and *certainly* MS-DOS. The microkernel design has proven invaluable. Things like new file systems that are normally available only from the vendor are hobbyist products on the Amiga. Device drivers are simply shared libraries and tasks with specific entry points and message ports. So are file systems, the window system, and so on. It's a WONDERFUL design, and validates everything that people have been saying about microkernels. Yes, it takes more work to get them off the ground than a coroutine based macrokernel like UNIX, but the versatility pays you back many times over. I really wish Andy would do a new MINIX based on what has been learned since the first release. The factoring of responsibilities in MINIX is fairly poor, but the basic concept is good. > The general consensus that Micro kernels is the way to go means nothing when > a real application has never even run on one. I'm dreaming again. I sure throught Deluxe Paint, Sculpt 3d, Photon Paint, Manx C, Manx SDB, Perfect Sound, Videoscape 3d, and the other programs I bought for my Amiga were "real". I'll have to send the damn things back now, I guess. The availability of Linux is great. I'm delighted it exists. I'm sure that the macrokernel design is one reason it has been implemented so fast, and this is a valid reason to use macrokernels. BUT... this doesn't mean that microkernels are inherently slow, or simply research toys. -- -- Peter da Silva, Ferranti International Controls Corporation -- Sugar Land, TX 77487-5012; +1 713 274 5180 -- "Have you hugged your wolf today?"  0, unseen,, *** EOOH *** From: dsmythe@netcom.COM (Dave Smythe) Newsgroups: comp.os.minix Subject: Re: LINUX is obsolete Date: 10 Feb 92 07:08:22 GMT Organization: Netcom - Online Communication Services (408 241-9760 guest) In article <1992Feb5.145630.759@wpi.WPI.EDU> entropy@wintermute.WPI.EDU (Lawrence C. Foard) writes: >Actually my main problem with OS theorists is that they have never tested >there ideas! None of these ideas (with a partial exception for MACH) has ever >seen the light of day. David Cheriton (Prof. at Stanford, and author of the V system) said something similar to this in a class in distributed systems. Paraphrased: "There are two kinds of researchers: those that have implemented something and those that have not. The latter will tell you that there are 142 ways of doing things and that there isn't consensus on which is best. The former will simply tell you that 141 of them don't work." He really rips on the OSI-philes as well, for a similar reason. The Internet protocols are adapted only after having been in use for a period of time, preventing things from getting standardized that will never be implementable in a reasonable fashion. OSI adherents, on the other hand, seem intent on standardizing everything possible, including "escapes" from the standard, before a reasonable reference implementation exists. Consequently, you see obsolete ideas immortalized, such as sub-byte-level data field packing, which makes good performance difficult when your computer is drinking from a 10+ Gbs fire-hose :-). Just my $.02 D -- ======================================================================== Dave Smythe N6XLP dsmythe@netcom.com (also dsmythe@cs.stanford.edu)  0, unseen,, *** EOOH *** From: mitchell@mdd.comm.mot.com (Bill Mitchell) Newsgroups: comp.os.minix Subject: Re: LINUX is obsolete Date: 10 Feb 92 15:03:51 GMT Reply-To: mitchell@mdd.comm.mot.com (Bill Mitchell) Organization: Motorola, Mobile Data Division - Seattle, WA Bcc: mitchell in comp.os.minix, dsmythe@netcom.COM (Dave Smythe) said: >In article <1992Feb5.145630.759@wpi.WPI.EDU> entropy@wintermute.WPI.EDU (Lawrence C. Foard) writes: > >David Cheriton (Prof. at Stanford, and author of the V system) said something >similar to this in a class in distributed systems. Paraphrased: > > "There are two kinds of researchers: those that have implemented > something and those that have not. The latter will tell you that > there are 142 ways of doing things and that there isn't consensus > on which is best. The former will simply tell you that 141 of > them don't work." > Yeah, but what's the odds on two who have implemented something differently agreeing on which 141 don't work? -- mitchell@mdd.comm.mot.com (Bill Mitchell)  0, unseen,, *** EOOH *** From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.minix Subject: Apologies (was Re: LINUX is obsolete) Date: 30 Jan 92 15:38:16 GMT Organization: University of Helsinki In article <1992Jan29.231426.20469@klaava.Helsinki.FI> I wrote: >Well, with a subject like this, I'm afraid I'll have to reply. And reply I did, with complete abandon, and no thought for good taste and netiquette. Apologies to ast, and thanks to John Nall for a friendy "that's not how it's done"-letter. I over-reacted, and am now composing a (much less acerbic) personal letter to ast. Hope nobody was turned away from linux due to it being (a) possibly obsolete (I still think that's not the case, although some of the criticisms are valid) and (b) written by a hothead :-) Linus "my first, and hopefully last flamefest" Torvalds  0, unseen,, *** EOOH *** Newsgroups: comp.os.minix From: jkp@cs.HUT.FI (Jyrki Kuoppala) Subject: ast's comments on OS's [was Re: LINUX is obsolete] In-Reply-To: ast@cs.vu.nl (Andy Tanenbaum) Nntp-Posting-Host: sauna.cs.hut.fi Reply-To: jkp@cs.HUT.FI (Jyrki Kuoppala) Organization: Helsinki University of Technology, Finland Date: Fri, 31 Jan 1992 12:07:46 GMT In article <12595@star.cs.vu.nl>, ast@cs (Andy Tanenbaum) writes: >who want to turn MINIX in BSD UNIX off my back. But in all honesty, I would >suggest that people who want a **MODERN** "free" OS look around for a >microkernel-based, portable OS, like maybe GNU or something like that. I hear bsd 4.4 might also become free and appear in the near future for the 386, also someone's supposed to be working on bsd 4.4 on top of the Mach microkernel, and then there's of course GNU. Currently of course for many people Linux is the OS to use because it's here now, is free and works. >P.S. Just as a random aside, Amoeba has a UNIX emulator (running in user >space), but it is far from complete. If there are any people who would >like to work on that, please let me know. To run Amoeba you need a few 386s, >one of which needs 16M, and all of which need the WD Ethernet card. A note here, the sources I've seen seem to imply that Amoeba will not be free as in you won't be able to use it, copy it, enhance it, share it etc. without paying $$ and/or asking permission from someone. //Jyrki  0, unseen,, *** EOOH *** Newsgroups: comp.os.minix From: geoff@world.std.com (Geoff Collyer) Subject: posixiation (was Re: LINUX is obsolete) Organization: The World @ Software Tool & Die Date: Fri, 31 Jan 1992 01:13:00 GMT Andy Tanenbaum: >MINIX was designed before POSIX, and is now being (slowly) POSIXized as >everyone who follows this newsgroup knows. May I recommend the use of the verb "posixiate" (by analogy with asphyxiate) instead of "posixize"? Similarly, I prefer "ansitise" (converse and anagram of "sanitise") to "ansify". -- Geoff Collyer world.std.com!geoff, uunet.uu.net!geoff  0, unseen,, *** EOOH *** From: pmacdona@sanjuan (Peter MacDonald) Newsgroups: comp.os.minix Subject: re: Linux is obsolete Date: 1 Feb 92 02:10:06 GMT Organization: University of Victoria, Victoria, BC, CANADA Nntp-Posting-Host: sanjuan.uvic.ca Since I think I posted one of the earliest messages in all this discussion of Minix vs Linux, I feel compelled to comment on my reasons for switching from Minix to Linux. In order of importance they are: 1) Linux is free 2) Linux is evolving at a satisfactory clip (because new features are accepted into the distribution by Linus). The first requires some explanation, because if I have already purchased Minix, what posssible concern could price have for me? Simple. If the OS is free, many more people will use/support/enhance it. This is also the same reasoning I used when I bought my 386 instead of a sparc (which I could have got for just 30% more). Since PCs are cheap and generally available, more people will buy/use them and thus good, cheap/free software will be abundant. The second should be pretty obvious to anyone who has been using Minix for for any period of time. AST generally does not accept enhancements to Minix. This is not meant as a challenge, but merely a statement of fact. AST has good and legitimate reasons for this, and I do not dispute them. But Minix has some limitations which I just could no longer live with, and due to this policy, the prospect of seeing them resolved in reasonable time was unsatisfactory. These limitations include: no 386 support no virtual consoles no soft links no select call no ptys no demand paging/swapping/shared-text/shared-libs... (efficient mm) chmem (inflexible mm) no X-Windows (advocated for the same reasons as Linux and the 386). no TCP/IP no GNU/SysV integration (portability) Some of these could be fixed by patches (and if you have done this yourself, I don't have to tell you how satisfactory that is), but at least the last 5 items were/are beyond any reasonable expectation. Finally, my comment (crack?) about Minix's segmented kernel, or micro-kernel architecture was more an expression of my frustration/ bewilderment at attempting to use the Minix PTY patches as a guide of how to do it under Linux. That particular instance was one where message passing greatly complicated the implementation of a feature. I do have an opinion about Monlithic vs Message Passing, but won't express it now, and did not mean to expresss it then. My goals are totally short term (maximum functionality in the minimum amount of time/cost/hassle), and so my views on this are irrelevant, and should not be misconstrued. If you are non-plussed by the lack of the above features, then you should consider Minix, as long as you don't mind paying of course :)  0, unseen,, *** EOOH *** From: ts@cup.portal.com (Tim W Smith) Newsgroups: comp.os.minix Subject: re: Linux is obsolete Date: 7 Feb 92 01:52:51 GMT Organization: The Portal System (TM) Someone says: > If the OS is free, many more people will use/support/enhance it. > This is also the same reasoning I used when I bought my 386 instead > of a sparc (which I could have got for just 30% more). Since > PCs are cheap and generally available, more people will buy/use > them and thus good, cheap/free software will be abundant. Good cheap/free software will also become redundant. Who cares if the cheap machine has fifteen versions of everything available and the more expensive machine only has one or two, if the one or two are good? The only real exception to this seems to be games. A lot of games seem to only become available on one system. Tim Smith  0, unseen,, *** EOOH *** From: jmaynard@oac.hsc.uth.tmc.edu (Jay Maynard) Newsgroups: comp.os.minix Subject: Re: Linux is obsolete Date: 7 Feb 92 11:59:55 GMT Organization: UT Health Science Center Houston Nntp-Posting-Host: oac.hsc.uth.tmc.edu In article <54087@cup.portal.com> ts@cup.portal.com (Tim W Smith) writes: >Good cheap/free software will also become redundant. Who cares if the >cheap machine has fifteen versions of everything available and the >more expensive machine only has one or two, if the one or two are >good? I do, if the one or two versions available are implemented in a fashion I have some kind of problem with. -- Jay Maynard, EMT-P, K5ZC, PP-ASEL | Never ascribe to malice that which can jmaynard@oac.hsc.uth.tmc.edu | adequately be explained by a .sig virus. "IMHO, USENET includes printing out articles and sticking them on my fridge with little magnets." -- Charles Geyer  0, unseen,, *** EOOH *** From: olaf@oski.toppoint.de (Olaf Schlueter) Newsgroups: comp.os.minix Subject: Re: Linux is obsolete Date: 7 Feb 92 11:41:44 GMT Organization: Toppoint Mailbox e.V. Just a few comments to the discussion of Linux vs Minix, which evolved partly to a discussion of monolithic vs micro-kernel. I think there will be no aggreement between the two parties advocating either concept, if they forget, that Linux and Minix have been designed for different applications. If you want a cheap, powerful and enhancable Unix system running on a single machine, with the possibility to adapt standard Unix software without pain, then Linux is for you. If you are interested in modern operating system concepts, and want to learn how a microkernel based system works, then Minix is the better choice. It is not an argument against microkernel system, that for the time being monolithic implemenations of Unix on PCs have a better performance. This means only, that Unix is maybe better implemented as a monolithic OS, at least as long as it runs on a single machine. From the users point of view, the internal design of the OS doesn't matter at all. Until it comes to networks. On the monolithic approach, a file server will become a user process based on some hardware facility like ethernet. Programs which want to use this facility will have to use special libraries which offer the calls for communication with this server. In a microkernel system it is possible to incorporate the server into the OS without the need for new "system" calls. From the users point of view this has the advantage, that nothing changes, he just gets better performance (in terms of more disk space for example). From the implementors point of view, the microkernel system is faster adaptable to changes in hardware design. It has been critized, that AST rejects any improvements to Minix. As he is interested in the educational value of Minix, I understand his argument, that he wants to keep the code simple, and don't want to overload it with features. As an educational tool, Minix is written as a microkernel system, although it is running on hardware platforms, who will probably better perform with a monolithic OS. But the area of network applications is growing and modern OS like Amoeba or Plan 9 cannot be written as monolithic systems. So Minix has been written with the intention to give students a practical example of a microkernel OS, to let them play with tasks and messages. It was not the idea to give a lot of people a cheap, powerful OS for a tenth of the price of SYSV or BSD implementations. Resumee: Linux is not better than Minix, or the other way round. They are different for good reasons. -- Olaf Schlueter, Sandkuhle 4-6, | olaf@oski.toppoint.de, 2300 Kiel 1, Germany, Toppoint Mailbox e.V. | olaf@tpki.toppoint.de "When MSDOS was written specifically for the 8088 ..., this was less then brilliant. Writing an OS only for the 386 in 91 gets you the second 'F'..." AST  0, unseen,, *** EOOH *** From: cwr@pnet01.cts.com (Will Rose) Newsgroups: comp.os.minix Subject: Re: LINUX is obsolete Date: 1 Feb 92 12:16:12 GMT Organization: People-Net [pnet01], El Cajon CA I've used Minix quite a bit on a PC XT, from version 1.2 onwards, and a couple of points seem worth making. Firstly that I ordered version 1.1 from Prentice Hall, and am devoutly thankful that they delayed my order until 1.2 was available. The first version of something as complicated as an OS is only for the dedicated, and that goes for Linux too I should think. Secondly Minix has evolved to a reliable OS on its original PC platform, but is still getting there on eg. the Mac; these things do take time. Thirdly even (standard) PC 1.5 Minix won't run a lot of current Unix software. Partly this is a matter of the hardware being too limited, and partly a matter of Minix being too limited in eg: the tty driver. (And even this tty driver took a lot of sorting out in the early days). Fourthly, I bought my XT four years ago - the motherboard was $110, and memory (falling in price) was $7.00 per 256KB chip. Last autumn I bought my wife an XT to replace her CP/M word-processor - the m/b was $50, and memory was $1.50 a chip. This week I replaced a dead 286 board for a friend - the drop-in 16MHz 386SX was $140, and memory was $40 for 9 x 1MB... If I actually wanted an OS to use today, I think I'd go with Linux; but if I wanted to learn about OS's, I think I'd use Minix. It looks as if they both do what they were designed to do. Will cwr@pnet01.cts.com  0, unseen,, *** EOOH *** From: meggin@epas.utoronto.ca (David Megginson) Newsgroups: comp.os.minix Subject: Mach/Minix/Linux/Gnu etc. Date: 1 Feb 92 17:11:03 GMT Organization: University of Toronto - EPAS Nntp-Posting-Host: epas.utoronto.ca Well, this has been a fun discussion. I am absolutely convinced by Prof. Tannenbaum that a micro-kernel _is_ the way to go, but the more I look at the Minix source, the less I believe that it is a micro-kernel. I would probably not bother porting Linux to the M68000, but I want more services than Minix can offer. What about a micro-kernel which is message/syscall compatible with MACH? It doesn't actually have to do everything that MACH does, like virtual memory paging -- it just has to _look_ like MACH from the outside, to fool programs like the future Gnu Unix-emulator, BSD, etc. This would extend the useful lives of our M68000- or 80286-based machines for a little longer. In the meantime, I will probably stay with Minix for my ST rather than switching back to MiNT -- after all, Minix at least looks like Unix, while MiNT looks like TOS trying to look like Unix (it has to, to be TOS compatible). David ################################################################# David Megginson meggin@epas.utoronto.ca Centre for Medieval Studies david@doe.utoronto.ca University of Toronto 39 Queen's Park Cr. E. #################################################################  0, unseen,, *** EOOH *** From: gkm@sys6626.bison.mb.ca (greg moeller) Newsgroups: comp.os.minix Subject: Minix VS Linux Date: 2 Feb 92 04:38:14 GMT Organization: system 6626 BBS, Winnipeg MB Just wanted to throw in one point about getting Minix because it can run on just an 8088. If I were a student with an 8088 and had a choice of buying Minix for $169, or spending about $140 for a 16 Mhz 386sx motherboard and get Linux for free, I think I'd get the new motherboard. Greg P.S. all in all, I think it depends on what you want to do with the OpSys that should determine what you get. --- (greg moeller) a user of sys6626, running waffle 1.64 E-mail: gkm@sys6626.bison.mb.ca system 6626: 63 point west drive, winnipeg manitoba canada R3T 5G8  0, unseen,, *** EOOH *** From: ortmann@plains.NoDak.edu (Daniel Ortmann) Newsgroups: comp.os.minix Subject: Re: Minix VS Linux Date: 2 Feb 92 19:42:13 GMT Organization: North Dakota State University, Fargo, ND What type of kernal is gnu going to have?  0, unseen,, *** EOOH *** Newsgroups: comp.os.minix From: meggin@epas.utoronto.ca (David Megginson) Subject: Re: Minix VS Linux Organization: University of Toronto - EPAS Date: Sun, 2 Feb 1992 20:23:11 GMT Nntp-Posting-Host: epas.utoronto.ca In article <14883@plains.NoDak.edu> ortmann@plains.NoDak.edu (Daniel Ortmann) writes: >What type of kernal is gnu going to have? Gnu will have a Unix emulator running on top of the Mach kernel. The Unix emulator is currently in the early stages. There is an information sheet on the Gnu project at prep.ai.mit.edu. David  0, unseen,, *** EOOH *** From: odiug@cip-s08.informatik.rwth-aachen.de (Guido Muesch) Newsgroups: comp.os.minix Subject: Re: Minix VS Linux Date: 4 Feb 92 13:16:26 GMT Organization: RBI - RWTH Aachen Nntp-Posting-Host: cip-s08 gkm@sys6626.bison.mb.ca (greg moeller) writes: >Just wanted to throw in one point about getting Minix because it can run >on just an 8088. The 8088 is obsolate. And my opinion is that Minix should only support the i386 of all intel architectures in the future. It is to much overhead to support the old 16-bit processors. Minix could be cleaned up easier if the old 16-bit stuff will be removed. >If I were a student with an 8088 and had a choice of buying Minix for >$169, or spending about $140 for a 16 Mhz 386sx motherboard and get Linux >for free, I think I'd get the new motherboard. Thats also my reason for suggesting NOT to support the old 16-bit architectures. People who are willing to pay $169 for Minix-PC can also spend another $140 for a new Motherboard. (If not they still have Linux 8-)) Cheers Guido >Greg >P.S. all in all, I think it depends on what you want to do with the OpSys > that should determine what you get. >--- (greg moeller) a user of sys6626, running waffle 1.64 >E-mail: gkm@sys6626.bison.mb.ca >system 6626: 63 point west drive, winnipeg manitoba canada R3T 5G8 -- /\ bitnet: odiug%messua.informatik.rwth-aachen.de@unido.bitnet / \ email: odiug@messua.informatik.rwth-aachen.de __/ \ ________________________________________________________________ \/ snail: Guido Muesch, Ruetscher Str.165/1413, 5100 Aachen  0, unseen,, *** EOOH *** From: vpaul@nmsu.edu (Vincent J. Paul) Newsgroups: comp.os.minix Subject: Re: Minix VS Linux Summary: rebuttal flame-from-hell Date: 4 Feb 92 18:55:47 GMT Organization: New Mexico State University In article , odiug@cip-s08.informatik.rwth-aachen.de (Guido Muesch) writes: > > > The 8088 is obsolate. And my opinion is that Minix should only support > the i386 of all intel architectures in the future. It is to much overhead > to support the old 16-bit processors. Minix could be cleaned up easier if > the old 16-bit stuff will be removed. > > >If I were a student with an 8088 and had a choice of buying Minix for > >$169, or spending about $140 for a 16 Mhz 386sx motherboard and get Linux > >for free, I think I'd get the new motherboard. > > Thats my reason for suggesting NOT to support the old 16-bit architectures. > People who are willing to pay $169 for Minix-PC can also spend another $140 > for a new Motherboard. (If not they still have Linux 8-)) > You missed the point completely, Guido. I'll be generous, though, and assume it was due to language diffulties. In smaller words, if you already own an 8088 box (and a lot of people still do) then buying a new box for $800 is MUCH more expensive than buying a $169 OS that is compatible. Saying "[spend] $140 on a 386 motherboard and get Linux for free..." is like saying to Ethiopians "Just buy a plane ticket to somewhere where there is a food surplus." AST made a few good points which have been glossed over: with limited budgets (like mine), and a fixed set of hardware, Minix is much more affordable than Linux. IF (and only if) that fixed set of hardware jsut HAPPENS to be 386- based, THEN Linux is a great bargain. Your attitude is much like that attributed to Marie Antoinette\--"Let them eat cake!" Atari and Mac owners have the wrong hardware. Let them get the proper one! (Note: not the proper "ones"--portability, bud, is a GOOD thing.) And as for that statement, "suggesting NOT to support the old 16-bit architectures," are you offering to pay for the upgrades? Somehow I doubt it. Just for your information (and the world at large) I bought Minix 1-1/2 years ago, and my XT-clone 5 years ago for $400. Since then, I've been going to school, not getting rich. I can hardly afford eating regularly, much less keeping up with Intel's CPU-chip fashions. If you want a 32-bit Intel-dedicated OS, go get Linux, and get the hell off this newsgroup. Don't go toasting anyone for providing, as Andy Tanenbaum REALLY has, a public service. Even if he doesn't cater to you. There, I've had my day. Let's call an end to this controversy, shall we? If you prefer Linux, go hang out with the Linux crowd over on (I think) alt.linux. Rag on Minix all you can stand there. Hanging around in comp.os.minix reeks of low to lowest class. And if anyone was going to convert, they already would have by now, don't you think? (Really. DON'T you?) Vince Paul/vpaul@nmsu.edu ------------------------------------------------------------------------------- Vincent J. Paul | vpaul@nmsu.edu New Mexico State University | OPR016%BITNET.NMSUVM1 "I take no resposibility for anyone believing anything I say. Even this."  0, unseen,, *** EOOH *** From: asg@sage.cc.purdue.edu (The Grand Master) Newsgroups: comp.os.minix Subject: Re: Minix VS Linux Date: 6 Feb 92 02:10:58 GMT Organization: Purdue University Computing Center In article <1992Feb4.185547.9585@nmsu.edu> vpaul@nmsu.edu (Vincent J. Paul) writes: }In article , odiug@cip-s08.informatik.rwth-aachen.de (Guido Muesch) writes: }> }> }> }> >If I were a student with an 8088 and had a choice of buying Minix for }> >$169, or spending about $140 for a 16 Mhz 386sx motherboard and get Linux }> >for free, I think I'd get the new motherboard. }> }> Thats my reason for suggesting NOT to support the old 16-bit architectures. }> People who are willing to pay $169 for Minix-PC can also spend another $140 }> for a new Motherboard. (If not they still have Linux 8-)) }> }You missed the point completely, Guido. I'll be generous, though, and }assume it was due to language diffulties. In smaller words, if you This is totally uncalled for - and I think you owe Guido an apology. Geez - and we (Americans) wonder why we have such a bad reputation abroad. }already own an 8088 box (and a lot of people still do) then buying a }new box for $800 is MUCH more expensive than buying a $169 OS that is }compatible. Maybe you are the one who is not understanding. What he is saying is that you do not NEED to spend $800 on a new system, just $140 for a 386sx motherboard. }Saying "[spend] $140 on a 386 motherboard and get Linux }for free..." is like saying to Ethiopians "Just buy a plane ticket to }somewhere where there is a food surplus." Not even close. IF SOMEONE CAN AFFORD TO BUY MINIX, THEN THEY CAN OBVIOUSLY AFFORD TO PUT THAT $169 DOLLARS TOWARDS A 386sx MOTHERBOARD! And *SAVE* $29 in the process if you find a 386sx motherboard for $140. So your analogy does not hold - considering that a starving Ethiopian is not likely to have the money to buy a plane ticket to anywhere. }AST made a few good points }which have been glossed over: with limited budgets (like mine), and }a fixed set of hardware, Minix is much more affordable than Linux. }IF (and only if) that fixed set of hardware jsut HAPPENS to be 386- }based, THEN Linux is a great bargain. Your attitude is much like that }attributed to Marie Antoinette\--"Let them eat cake!" Atari and Mac }owners have the wrong hardware. Let them get the proper one! (Note: }not the proper "ones"--portability, bud, is a GOOD thing.) Portability is both good and bad - the unfortunate thing about portability is that it does not allow you to take advantage of many hardware-specific features. } Just for your information (and the world at large) I bought }Minix 1-1/2 years ago, and my XT-clone 5 years ago for $400. Since }then, I've been going to school, not getting rich. I can hardly }afford eating regularly, much less keeping up with Intel's CPU-chip }fashions. If you want a 32-bit Intel-dedicated OS, go get Linux, }and get the hell off this newsgroup. Don't go toasting anyone for }providing, as Andy Tanenbaum REALLY has, a public service. Even }if he doesn't cater to you. Mr. Tanenbaum, though undoubtedly a gifted professor, and undoubtedly a gifted programmer, is not providing a "PUBLIC SERVICE". MINIX was written for his students, and AST had the fortune that MINIX caught on, and has now sold many copies. AST makes money off the deal I am sure - and if he does not, then I cannot understand why he does not free the code of copyright, so it can be distributed. And you might remember that the person who started this thread was not Guido, nor anyone else in the "Linux camp". } And if anyone was going to convert, they already }would have by now, don't you think? (Really. DON'T you?) } It really has nothing to do with conversion. Don't get me wrong - I think MINIX is a brilliant piece of work, and it is certainly well thought of by some (likely large) segment of the OS-knowledgable population. But AST attacked Linux for no reason whatsoever. Linus has created a brilliant piece of work as well - one that incorperates many of the features that people want which are not readily (or at all in some cases) available for MINIX. The important thing about Linux is that it is here, and it works, and its free. There is NO other OS available (portable or not) that fits the bill that Linux does. AST's comments were absolutely uncalled for - and his feelings for those of us out here who would like some common useful features (like > 64k segments, or job control, or TCP/IP) are readily appearant from his comment about (note: slightly paraphrased) ".....keeping all those people who want to turn MINIX into BSD...." off his back. Clearly he is not in the "Public Service" field. -- -How long must we fight? How long Courtesy of Bruce Varney until we can live in peace. asg@sage.cc.purdue.edu -Until the madmen are dead my son, Or until they realize that they cannot count on us to do nothing  0, unseen,, *** EOOH *** From: stolk@fwi.uva.nl (Bram) Newsgroups: comp.os.minix Subject: 'folks with enough money' (was: LINUX-MINIX) Date: 3 Feb 92 11:43:17 GMT Organization: FWI, University of Amsterdam Nntp-Posting-Host: irwin.fwi.uva.nl Hi, In one of the previous articles, ast wrote: > Just for the record, as of about 1 year ago, there were two >versions, one for the PC (360K diskettes) and one for the 286/386 (1.2M). >The PC version was outselling the 286/386 version by 2 to 1. I don't have >figures, but my guess is that the fraction of the 60 million existing PCs that >are 386/486 machines as opposed to 8088/286/680x0 etc is small. Among students >it is even smaller. Making software free, but only for folks with enough money >to buy first class hardware is an interesting concept. Hmm... can I do a little math here? define: configuration 1: 8088 PC, 2 floppydrives, monitor. configuration 2: 386 AT, 2 floppydrives, monitor. let A be the price of config. 1 at the time of MINIX' conception. Let B be the price of config. 2 at the time of LINUX' conception. Question: What are the chances of 'A >= B' being true? My answer: I would say, better than average. The point I am trying to make is: nowadays, students buy 386s. Not because students are rich, but because 386s from Taiwan come VERY cheap. (Many of my fellow students have 386s) So 'the folks with enough money' bit is kinda naive. IBM's 8088s used to sell at the price of small cars, in the old days. I would favor LINUX, even if it were only for the lack of proper object files in MINIX. Bram Stolk  0, unseen,, *** EOOH *** From: cwr@pnet01.cts.com (Will Rose) Newsgroups: comp.os.minix Subject: Re: Minix VS Linux Date: 3 Feb 92 14:16:11 GMT Organization: People-Net [pnet01], El Cajon CA kevin@taronga.taronga.com (Kevin Brown) writes: >It has been brought to my attention that my last posting was exceedingly >harsh. Having reread it, I'm inclined to agree. Didn't seem so to me - or is everyone else getting much more tactful in the 'kinder, gentler' 1990s? >Despite that, Minix is quite usable in many ways as a personal operating >system, i.e. one where there is usually only one person logged into the >system. .... lines omitted >However, as a *multiuser* operating system, i.e. an operating system designed >to efficiently meet the needs of multiple users simultaneously while also >performing batch operations, Minix is lacking, as far as I'm concerned. >The main reason, of course, is the single-threaded file system (hereafter, >STFS). In fact, Minix has noticeable problems even as a *single-user* system; such a user is likely to be developing code in an 'edit - compile - test' cycle, and on a multitasking machine compilation can conveniently take place in the background using multiple processes. Given the small amount of memory on the early Minix machines, it probably wasn't practical to edit in the foreground during a compile; but a low-end XT such as mine can now put the ram-disk in expanded memory and have 500KB free after the OS is loaded. However, editing during a compile is still totally impractical; the standard 1.5 scheduler can't cope, and keyboard response time is both long (seconds) and variable. The fix is simple, use Kai-Uwe Bloem's (spelling ?) patch. KuB's scheduler algorithm isn't the last word in sophistication, and the code change is a small one, yet it is extremely effective. I don't understand why the original scheduler lasted so long. Broadly speaking, when porting programs to Minix, or writing them from scratch, the main problems are not details of kernel implementation but things that are simply missing, such as non-blocking reads or SIGHUP. If a program is to be used on the majority of Minix systems, then it must be written for the lowest common denominator ie: the standard current release, and this has significant limitations. Only after these are overcome does the lack of memory space, or lack of filesystem performance, become important. (It is quite possible that many of these problems will be fixed in 1.6, but that still lies in the future. By the time it arrives, the goalposts will have moved again... ) >Someone, either here on this newsgroup or over on alt.os.linux, made a >very valid observation: the cost of a 16 MHz 386SX system is about $140 >more than a comparably equipped (in terms of RAM size, display technology, >hard drive space, etc.) 8088 system. Minix is $169. In economic terms, >Linux wins if you have to buy Minix. This may have been drawn from a comment of mine, concerning the recent replacement of a dead 286 motherboard with a 386SX; it was part of an example of just how fast hardware prices are falling. The *board* price was $140, ie: $90 more than an XT board. Memory is about the same price for both boards, but obviously the system price for the 386 will tend to be higher with the use of faster, larger disk drives, more memory, and so on. In the last year PH has started marketing Minix as a small general-purpose/ training Unix, but if Minix 2.0 isn't released for another year, I think it will become strictly an adjunct to a successful textbook. It won't run enough of the then-available PD code to be useful for anything else, since such code will mostly require gcc and megabytes of memory, implying at least a 386. (I'm assuming that the cheapest hardware will still be Intel/ISA bus). Linux seems well-placed to pick up on this wave; whether it will also make inroads into academe via easy FTP availability (a version of 'OS Design and Implementation' without Minix is coincidentally in hand) remains to be seen. Will Rose cwr@pnet01.cts.com  0, unseen,, *** EOOH *** From: kevin@taronga.taronga.com Newsgroups: comp.os.minix Subject: Re: Minix VS Linux Date: 4 Feb 92 07:56:04 GMT Organization: University of Houston In article <1992Feb03.141611.6995@crash.cts.com> cwr@pnet01.cts.com (Will Rose) writes: > >kevin@taronga.taronga.com (Kevin Brown) writes: > >>It has been brought to my attention that my last posting was exceedingly >>harsh. Having reread it, I'm inclined to agree. > >Didn't seem so to me - or is everyone else getting much more tactful in >the 'kinder, gentler' 1990s? Guess it depends on whether or not you agree with what I had to say. ;-) Some people read other people's postings with an implied "IMHO". Others don't. Those that don't will probably think of that posting as exceedingly harsh. Since I try to be as explicit as possible, I would say I didn't put enough "IMHO"s in. >>Despite that, Minix is quite usable in many ways as a personal operating >>system, i.e. one where there is usually only one person logged into the >>system. >... lines omitted >>However, as a *multiuser* operating system, i.e. an operating system designed >>to efficiently meet the needs of multiple users simultaneously while also >>performing batch operations, Minix is lacking, as far as I'm concerned. >>The main reason, of course, is the single-threaded file system (hereafter, >>STFS). > >In fact, Minix has noticeable problems even as a *single-user* system; such >a user is likely to be developing code in an 'edit - compile - test' cycle, >and on a multitasking machine compilation can conveniently take place in >the background using multiple processes. Given the small amount of memory >on the early Minix machines, it probably wasn't practical to edit in the >foreground during a compile; but a low-end XT such as mine can now put the >ram-disk in expanded memory and have 500KB free after the OS is loaded. >However, editing during a compile is still totally impractical; the standard >1.5 scheduler can't cope, and keyboard response time is both long (seconds) >and variable. The fix is simple, use Kai-Uwe Bloem's (spelling ?) patch. >KuB's scheduler algorithm isn't the last word in sophistication, and the code >change is a small one, yet it is extremely effective. I don't understand >why the original scheduler lasted so long. I agree wholeheartedly. In fact, Bruce Evans sent me a very simple patch that gives an I/O bound process like an editor effectively infinite priority: it causes the process that's being readied (in the ready() routine in proc.c) to be added to the beginning of the process queue instead of the end. This fixes the problem for sure, but it causes CPU bound processes to suffer rather badly in the face of I/O bound processes. >Broadly speaking, when porting programs to Minix, or writing them from >scratch, the main problems are not details of kernel implementation but things >that are simply missing, such as non-blocking reads or SIGHUP. I've had the SIGHUP problem solved on my system for some time, but I've got weird problems with the signal handling as relates to process groups and signalling a parent process in a process group before signalling the child. Causes very strange things to happen (like the FS to restart! You get the message "executing in protected mode" as a result of killing a parent process before killing the child process). This is the primary reason I don't have UUCP going on my system already. I don't trust it enough to handle a UUCP connection going away (dropping carrier) in the middle of a transfer. >If a program >is to be used on the majority of Minix systems, then it must be written for >the lowest common denominator ie: the standard current release, and this has >significant limitations. Only after these are overcome does the lack of >memory space, or lack of filesystem performance, become important. (It >is quite possible that many of these problems will be fixed in 1.6, but >that still lies in the future. By the time it arrives, the goalposts will >have moved again... ) What he said. :-) >>Someone, either here on this newsgroup or over on alt.os.linux, made a >>very valid observation: the cost of a 16 MHz 386SX system is about $140 >>more than a comparably equipped (in terms of RAM size, display technology, >>hard drive space, etc.) 8088 system. Minix is $169. In economic terms, >>Linux wins if you have to buy Minix. > >This may have been drawn from a comment of mine, concerning the recent >replacement of a dead 286 motherboard with a 386SX; it was part of an >example of just how fast hardware prices are falling. The *board* price >was $140, ie: $90 more than an XT board. Memory is about the same price >for both boards, but obviously the system price for the 386 will tend to be >higher with the use of faster, larger disk drives, more memory, and so on. Right. The only time the architecture bites you is when your applications are larger as a result of using a 32-bit memory model, though. So while you tend to use faster and larger disk drives, more memory, etc. for the 386, that's because you *can* more than anything else. The architecture supports it. I figure the larger and faster hard drives come as a result of having more memory to stuff programs into. :-) If the price difference is only $90, then the 386SX *definitely* wins. For the $80 I save in buying a 386SX and getting Linux, I can get another 50 meg of hard drive space, or perhaps even more, depending on where on the price/capacity curve I am. >In the last year PH has started marketing Minix as a small general-purpose/ >training Unix, but if Minix 2.0 isn't released for another year, I think it >will become strictly an adjunct to a successful textbook. It won't run >enough of the then-available PD code to be useful for anything else, since >such code will mostly require gcc and megabytes of memory, implying at least >a 386. (I'm assuming that the cheapest hardware will still be Intel/ISA bus). I don't know. While I agree that many of the applications will be too large, there's something to be said for small, efficient programs, and something to be said against large, baroque programs. Having lots of features isn't necessarily a good thing, despite what the marketers might tell you. >Linux seems well-placed to pick up on this wave; whether it will also make >inroads into academe via easy FTP availability (a version of 'OS Design and >Implementation' without Minix is coincidentally in hand) remains to be seen. Maybe we can get Linus to write a book on operating systems. :-) :-) >Will Rose >cwr@pnet01.cts.com Kevin Brown  0, unseen,, *** EOOH *** From: peter@ferranti.com (peter da silva) Newsgroups: comp.os.minix Subject: What good does this war do? (Re: LINUX is obsolete) Date: 3 Feb 92 16:37:24 GMT Organization: Xenix Support, FICC Will you quit flaming each other? I mean, linux is designed to provide a reasonably high performance environment on a hardware platform crippled by years of backwards-compatible kludges. Minix is designed as a teaching tool. Neither is that good at doing the other's job, and why should they? The fact that Minix runs out of steam quickly (and it does) isn't a problem in its chosen mileau. It's sure better than the TOY operating system. The fact that Linux isn't transportable beyond the 386/AT platform isn't a problem when there are millions of them out there (and quite cheap: you can get a 386/SX for well under $1000). A monolithic kernel is easy enough to build that it's worth doing it if it gets a system out the door early. Think of it as a performance hack for programmer time. The API is portable. You can replace the kernel with a microkernel design (and MINIX isn't the be-all and end-all of microkernel designs either: even for low end PCs... look at AmigaOS) without disturbing the applications. That's the whole point of a portable API in the first place. Microkernels are definitely a better design for many tasks. I takes more work to make them efficient, so a simpler design that doesn't take advantage of the microkernel in any real way is worth doing for pedagogical reasons. Think of it as a performance hack for student time. The design is still good and when you can get an API to the microkernel interface you can get VERY impressive performance (thousands of context switches per second on an 8 MHz 68000). -- -- Peter da Silva, Ferranti International Controls Corporation -- Sugar Land, TX 77487-5012; +1 713 274 5180 -- "Have you hugged your wolf today?"  0, unseen,, *** EOOH *** From: ast@cs.vu.nl (Andy Tanenbaum) Newsgroups: comp.os.minix Subject: Unhappy campers Date: 3 Feb 92 22:46:40 GMT Organization: Fac. Wiskunde & Informatica, Vrije Universiteit, Amsterdam I've been getting a bit of mail lately from unhappy campers. (Actually 10 messages from the 43,000 readers may seem like a lot, but it is not really.) There seem to be three sticking points: 1. Monolithic kernels are just as good as microkernels 2. Portability isn't so important 3. Software ought to be free If people want to have a serious discussion of microkernels vs. monolithic kernels, fine. We can do that in comp.os.research. But please don't sound off if you have no idea of what you are talking about. I have helped design and implement 3 operating systems, one monolithic and two micro, and have studied many others in detail. Many of the arguments offered are nonstarters (e.g., microkernels are no good because you can't do paging in user space-- except that Mach DOES do paging in user space). If you don't know much about microkernels vs. monolithic kernels, there is some useful information in a paper I coauthored with Fred Douglis, Frans Kaashoek and John Ousterhout in the Dec. 1991 issue of COMPUTING SYSTEMS, the USENIX journal). If you don't have that journal, you can FTP the paper from ftp.cs.vu.nl (192.31.231.42) in directory amoeba/papers as comp_sys.tex.Z (compressed TeX source) or comp_sys.ps.Z (compressed PostScript). The paper gives actual performance measurements and supports Rick Rashid's conclusion that microkernel based systems are just as efficient as monolithic kernels. As to portability, there is hardly any serious discussion possible any more. UNIX has been ported to everything from PCs to Crays. Writing a portable OS is not much harder than a nonportable one, and all systems should be written with portability in mind these days. Surely Linus' OS professor pointed this out. Making OS code portable is not something I invented in 1987. While most people can talk rationally about kernel design and portability, the issue of free-ness is 100% emotional. You wouldn't believe how much [expletive deleted] I have gotten lately about MINIX not being free. MINIX costs $169, but the license allows making two backup copies, so the effective price can be under $60. Furthermore, professors may make UNLIMITED copies for their students. Coherent is $99. FSF charges >$100 for the tape its "free" software comes on if you don't have Internet access, and I have never heard anyone complain. 4.4 BSD is $800. I don't really believe money is the issue. Besides, probably most of the people reading this group already have it. A point which I don't think everyone appreciates is that making something available by FTP is not necessarily the way to provide the widest distribution. The Internet is still a highly elite group. Most computer users are NOT on it. It is my understanding from PH that the country where MINIX is most widely used is Germany, not the U.S., mostly because one of the (commercial) German computer magazines has been actively pushing it. MINIX is also widely used in Eastern Europe, Japan, Israel, South America, etc. Most of these people would never have gotten it if there hadn't been a company selling it. Getting back to what "free" means, what about free source code? Coherent is binary only, but MINIX has source code, just as LINUX does. You can change it any way you want, and post the changes here. People have been doing that for 5 years without problems. I have been giving free updates for years, too. I think the real issue is something else. I've been repeatedly offered virtual memory, paging, symbolic links, window systems, and all manner of features. I have usually declined because I am still trying to keep the system simple enough for students to understand. You can put all this stuff in your version, but I won't put it in mine. I think it is this point which irks the people who say "MINIX is not free," not the $60. An interesting question is whether Linus is willing to let LINUX become "free" of his control. May people modify it (ruin it?) and sell it? Remember the hundreds of messages with subject "Re: Your software sold for money" when it was discovered the MINIX Centre in England was selling diskettes with news postings, more or less at cost? Suppose Fred van Kempen returns from the dead and wants to take over, creating Fred's LINUX and Linus' LINUX, both useful but different. Is that ok? The test comes when a sizable group of people want to evolve LINUX in a way Linus does not want. Until that actually happens the point is moot, however. If you like Linus' philosophy rather than mine, by all means, follow him, but please don't claim that you're doing this because LINUX is "free." Just say that you want a system with lots of bells and whistles. Fine. Your choice. I have no argument with that. Just tell the truth. As an aside, for those folks who don't read news headers, Linus is in Finland and I am in The Netherlands. Are we reaching a situation where another critical industry, free software, that had been totally dominated by the U.S. is being taken over by the foreign competition? Will we soon see President Bush coming to Europe with Richard Stallman and Rick Rashid in tow, demanding that Europe import more American free software? Andy Tanenbaum (ast@cs.vu.nl)  0, unseen,, *** EOOH *** From: meulenbr@ce.philips.nl (Frans Meulenbroeks) Newsgroups: comp.os.minix Subject: Re: Unhappy campers Date: 4 Feb 92 17:21:31 GMT Organization: Philips Consumer Electronics, Eindhoven First of all I want to say, that I like to support the idea of Andy to keep minix small. If you want something large go for GNU. I'm also against featurism. However, undoubtly my wanted set of features differs from Andy's set. Therefore what I would like to see, is something which allows it to add features easily. If for instance device drivers are loadable, or easier to add as they are now, then the core and some drivers can be the standard PH minix. If people want to add something, then it is nice to have a mechanism with which you can do so, without having to meddle with things like fs/table.c kernel/table.c include/minix/config.h (for NR_TASKS) etc. ast@cs.vu.nl (Andy Tanenbaum) writes: >Suppose Fred van Kempen returns from the dead and wants to take over, creating Just a remark for the readers. As far as I know Fred is not physically dead. If english is not your native language (just like mine) you might conclude otherwise from ast's words. Fred is only electronically dead. -- Frans Meulenbroeks (meulenbr@prl.philips.nl) Philips Research Laboratories  0, unseen,, *** EOOH *** From: jonathan@ukmug.uk.mugnet.org (Jonathan Allen) Newsgroups: comp.os.minix Subject: Re: Unhappy campers Date: 6 Feb 92 11:43:05 GMT Organization: MUGNET UK Backbone (UKMUG) In article <1992Feb4.172131.18145@philce.ce.philips.nl>, meulenbr@ce.philips.nl (Frans Meulenbroeks) wrote: > ast@cs.vu.nl (Andy Tanenbaum) writes: > >>Suppose Fred van Kempen returns from the dead and wants to take over, creating > > Just a remark for the readers. As far as I know Fred is not physically dead. > If english is not your native language (just like mine) you might > conclude otherwise from ast's words. Fred is only electronically dead. Well, just you wait and see :-) !!!  0, unseen,, *** EOOH *** From: meggin@epas.utoronto.ca (David Megginson) Newsgroups: comp.os.minix Subject: Re: Unhappy campers Date: 4 Feb 92 20:17:22 GMT Organization: University of Toronto - EPAS Nntp-Posting-Host: epas.utoronto.ca In article <12667@star.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes: >As an aside, for those folks who don't read news headers, Linus is in Finland >and I am in The Netherlands. Are we reaching a situation where another >critical industry, free software, that had been totally dominated by the U.S. >is being taken over by the foreign competition? Will we soon see >President Bush coming to Europe with Richard Stallman and Rick Rashid >in tow, demanding that Europe import more American free software? Actually, the U.S. is more likely to have you arrested for selling restricted software to unfriendly powers (not that anyone in the C.I.S. can afford software this winter -- they're probably burning their PCs for heat). I remember that they jailed some poor computer vendor in the U.K. a couple of years ago. Seriously, you must have run into this problem with crypt and Minix distribution in and out of the U.S. David ################################################################# David Megginson meggin@epas.utoronto.ca Centre for Medieval Studies david@doe.utoronto.ca University of Toronto 39 Queen's Park Cr. E.  0, unseen,, *** EOOH *** Newsgroups: comp.os.minix From: jkp@cs.HUT.FI (Jyrki Kuoppala) Subject: Re: Unhappy campers In-Reply-To: meggin@epas.utoronto.ca (David Megginson) Nntp-Posting-Host: sauna.cs.hut.fi Reply-To: jkp@cs.HUT.FI (Jyrki Kuoppala) Organization: Helsinki University of Technology, Finland Date: Wed, 5 Feb 1992 15:47:26 GMT In article <1992Feb4.201722.20620@epas.toronto.edu>, meggin@epas (David Megginson) writes: >Actually, the U.S. is more likely to have you arrested for selling >restricted software to unfriendly powers (not that anyone in the >C.I.S. can afford software this winter -- they're probably burning >their PCs for heat). I remember that they jailed some poor computer >vendor in the U.K. a couple of years ago. Around here a few years ago they had a trial against a couple of guys who sold old VAXes to the Soviet Union. They were charged with treason because they were breaking some export rules. They weren't convicted, though, I think it was something about the export rules not being a law in Finland. For some reason the U.S. troups didn't come to Finland to kill a few thousand people and take these guys to USA for a trial like they did with another person in another country. //Jyrki  0, unseen,, *** EOOH *** From: ast@cs.vu.nl (Andy Tanenbaum) Newsgroups: comp.os.minix Subject: Re: Unhappy campers Date: 6 Feb 92 11:03:51 GMT Organization: Fac. Wiskunde & Informatica, Vrije Universiteit, Amsterdam In article <1992Feb5.154726.983@nntp.hut.fi> jkp@cs.HUT.FI (Jyrki Kuoppala) writes: > >Around here a few years ago they had a trial against a couple of guys >who sold old VAXes to the Soviet Union. In their book, Cyberpunk, Katie Hafner and John Markoff report that a group of hackers tried to sell MINIX to the KGB claiming it was the VMS source code. The KGB didn't buy. Andy Tanenbaum (ast@cs.vu.nl)  0, unseen,, *** EOOH *** From: james@fiskville.mc.utexas.edu (James Hammett) Newsgroups: comp.os.minix Subject: Re: Unhappy campers Date: 8 Feb 92 02:18:28 GMT Reply-To: james@fiskville.mc.utexas.edu (James Hammett) Organization: The University of Texas at Austin From what little I understand, the reason Minix needs to use a second class encryptor for its passwd file is because of the export restrictions. You can't export or transmit the algorhthym (sp). James  0, unseen,, *** EOOH *** From: fnf@fishpond.uucp (Fred Fish) Newsgroups: comp.os.minix Subject: Re: Unhappy campers Date: 4 Feb 92 20:57:40 GMT Organization: Amiga Library Distribution Services In article <12667@star.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes: >While most people can talk rationally about kernel design and portability, >the issue of free-ness is 100% emotional. You wouldn't believe how much >[expletive deleted] I have gotten lately about MINIX not being free. MINIX >costs $169, but the license allows making two backup copies, so the effective >price can be under $60. Furthermore, professors may make UNLIMITED copies >for their students. Coherent is $99. FSF charges >$100 for the tape its "free" >software comes on if you don't have Internet access, and I have never heard >anyone complain. 4.4 BSD is $800. I don't really believe money is the issue. >Besides, probably most of the people reading this group already have it. The distribution cost is not the problem. As you've noted, nobody complains about the FSF's distribution fee being too high. The problem, as I see it, is that there is only one legal source for for the software for people that simply want a working release. And from watching the minix group since minix first became available, my impression is that nobody enjoys dealing with PH for a whole host of reasons. >I think the real issue is something else. I've been repeatedly offered virtual >memory, paging, symbolic links, window systems, and all manner of features. I >have usually declined because I am still trying to keep the system simple >enough for students to understand. You can put all this stuff in your version, >but I won't put it in mine. I think it is this point which irks the people who >say "MINIX is not free," not the $60. If PH was not granted a monopoly on distribution, it would have been possible for all of the interested minix hackers to organize and set up a group that was dedicated to producing enhanced-minix. This aim of this group could have been to produce a single, supported version of minix with all of the commonly requested enhancements. This would have allowed minix to evolve in much the same way that gcc has evolved over the last few years. Sure there are variant versions of gcc, but most of the really good enhancements, bug fixes, etc are eventually folded back into a master source base that future distributions derive from. Thus you would have been left in peace to continue your tight control over the educational version of minix, and everyone else that wanted more than an educational tool could put their energies into enhanced-minx. The primary reason I've never gotten into using minix, after the initial excitement of hearing about it's availability way back when, is that I have no interest in trying to apply random patches from all over the place, sort out the problems, and eventually end up with a system that does what I want it to, but which I can't pass on to anyone else. >The >test comes when a sizable group of people want to evolve LINUX in a way Linus >does not want. Until that actually happens the point is moot, however. Where is the sizeable group of people that want to evolve gcc in a way that rms/FSF does not approve of? Where is the sizeable group of people that want to evolve emacs in a way that rms/FSF doesn't approve of? I'd say that if the primary maintainers of a large piece of useful, freely redistributable, software are at all responsive to incorporating useful enhancements and acting as the central repository and clearing house for the software, then these splinter groups simply do not have sufficient motivation to form. Having a single source for the software, and having the primary maintainer(s) be unresponsive to the desires of a large group of users, is the catalyst that causes these sorts of pressures; not the freedom of the software. -Fred -- |\/ o\ Fred Fish, 1835 E. Belmont Drive, Tempe, AZ 85284, USA |/\__/ 1-602-491-0048 {asuvax,mcdphx,cygint,amix}!fishpond!fnf  0, unseen,, *** EOOH *** From: vladimir@Eng.Sun.COM (Vladimir Ivanovic) Newsgroups: comp.os.minix Subject: Re: Unhappy campers Date: 5 Feb 92 04:34:18 GMT Organization: Sun Microsystems, Inc. NNTP-Posting-Host: ronnie In-reply-to: fnf@fishpond.uucp's message of 4 Feb 92 20:57:40 GMT >>>>> On 4 Feb 92 20:57:40 GMT, fnf@fishpond.uucp (Fred Fish) said: fnf> If PH was not granted a monopoly on distribution, it would have been fnf> possible for all of the interested minix hackers to organize and set fnf> up a group that was dedicated to producing enhanced-minix. This aim fnf> of this group could have been to produce a single, supported version fnf> of minix with all of the commonly requested enhancements. This would fnf> have allowed minix to evolve in much the same way that gcc has evolved fnf> over the last few years. Sure there are variant versions of gcc, but fnf> most of the really good enhancements, bug fixes, etc are eventually fnf> folded back into a master source base that future distributions derive fnf> from. Thus you would have been left in peace to continue your tight fnf> control over the educational version of minix, and everyone else that fnf> wanted more than an educational tool could put their energies into fnf> enhanced-minx. I don't get it. What's preventing people from doing this? The quoted paragraph doesn't give any reasons for its assertions. -- Vladimir -- Vladimir G. Ivanovic Sun Microsystems, Inc (415) 336-2315 MTV12-33 vladimir@Eng.Sun.COM 2550 Garcia Ave. {decwrl,hplabs,ucbvax}!sun!Eng!vladimir Mountain View, CA 94043-1100 Disclaimer: I speak for myself.  0, unseen,, *** EOOH *** From: mitchell@mdd.comm.mot.com (Bill Mitchell) Newsgroups: comp.os.minix Subject: Re: Unhappy campers Date: 5 Feb 92 15:09:12 GMT Reply-To: mitchell@mdd.comm.mot.com (Bill Mitchell) Organization: Motorola, Mobile Data Division - Seattle, WA Bcc: mitchell in comp.os.minix, vladimir@Eng.Sun.COM (Vladimir Ivanovic) said: >>>>>> On 4 Feb 92 20:57:40 GMT, fnf@fishpond.uucp (Fred Fish) said: > >fnf> If PH was not granted a monopoly on distribution, it would have been >fnf> possible for all of the interested minix hackers to organize and set >fnf> up a group that was dedicated to producing enhanced-minix. This aim >fnf> of this group could have been to produce a single, supported version >fnf> of minix with all of the commonly requested enhancements. This would >fnf> have allowed minix to evolve in much the same way that gcc has evolved >fnf> over the last few years. Sure there are variant versions of gcc, but >fnf> most of the really good enhancements, bug fixes, etc are eventually >fnf> folded back into a master source base that future distributions derive >fnf> from. Thus you would have been left in peace to continue your tight >fnf> control over the educational version of minix, and everyone else that >fnf> wanted more than an educational tool could put their energies into >fnf> enhanced-minx. > >I don't get it. What's preventing people from doing this? The quoted >paragraph doesn't give any reasons for its assertions. > As I understand it PH takes the position that the copyright must be observed, and that distribution of modified copies of their copyrighted code is in violation of the copyright. I think that they are required to defend the copyright against such violations if they want it to remain legally valid. Diffs against the baseline are allowed. But diffs have to be applied in strict order. This would be difficult to administer in a tight-knit organization with well defined distribution channels. In net.anarchy it's all but unworkable. The fact that the Minix-386 variant of PC Minix 1.5 has managed to remain stable as a set of diffs suprises me. I recall that the NLMUG Minix variant was distributed as modified baseline code instead of as diffs, and that PH copyright lawyers put a stop to that. Or do I have it wrong? -- mitchell@mdd.comm.mot.com (Bill Mitchell)  0, unseen,, *** EOOH *** From: fnf@fishpond.uucp (Fred Fish) Newsgroups: comp.os.minix Subject: Re: Unhappy campers Date: 5 Feb 92 15:33:33 GMT Organization: Amiga Library Distribution Services In article vladimir@Eng.Sun.COM (Vladimir Ivanovic) writes: >>>>>> On 4 Feb 92 20:57:40 GMT, fnf@fishpond.uucp (Fred Fish) said: >fnf> If PH was not granted a monopoly on distribution, it would have been >fnf> possible for all of the interested minix hackers to organize and set > >I don't get it. What's preventing people from doing this? The quoted >paragraph doesn't give any reasons for its assertions. My understanding is that PH is the only one that is allowed to distribute a complete minix distribution. All others are restricted to the "2 copy limit" or by the educational provision for classroom use. There is apparently no place where I can send a check for $50 - $150 and receive a complete, ready to install, copy of an enhanced minix that has most of the common enhancements that are floating around as diff kits, already installed and tested. When I run into a problem, I can't post a message saying that eminix version 15.4 does mumble-foo when it should do mumble-bar, and expect other people to be easily able to reproduce the problem. Except for people that are running strictly vanilla minix as received from PH, I doubt that there are any two minix sites anywhere in the world, that are not directly in touch with each other, that are running the same set of binaries. This is bug heaven, and a maintenance nightmare. If I'm wrong, and there is such a place to get a full 32 bit minix with VM, hardware supported memory protection, and other assorted enhancements such as GNU gcc, g++, emacs, etc, with full sources and binaries for the entire system, preferably for an Amiga 3000, then please tell me. Directions that go "well first order minix X.X from PH, and then apply patch kit xxx from ftp site yyy and patch kit zzz from ftp site kkk, and write to John Doe for his patch kit www, and pick up patch kit ddd from the minix usenet archives" will be cheerfully ignored. -Fred -- |\/ o\ Fred Fish, 1835 E. Belmont Drive, Tempe, AZ 85284, USA |/\__/ 1-602-491-0048 {asuvax,mcdphx,cygint,amix}!fishpond!fnf  0, unseen,, *** EOOH *** From: al@escom.com (Al Donaldson) Newsgroups: comp.os.minix Subject: Re: Unhappy campers Date: 6 Feb 92 14:53:21 GMT Reply-To: al@escom.COM (Al Donaldson) Organization: ESCOM Corp., Oakton VA (USA) In article <207@fishpond.uucp> fnf@fishpond.uucp (Fred Fish) writes: >My understanding is that PH is the only one that is allowed to distribute >a complete minix distribution. Fred, To the best of my knowledge, PH has no such restriction. In fact, as of a year ago, PH had an active program to license MINIX to anyone who wants to use it for whatever purpose. This specifically includes building variants of the MINIX system such as "enhanced" MINIX. >There is apparently no place where I can send a check for $50 - $150 and >receive a complete, ready to install, copy of an enhanced minix that has >most of the common enhancements that are floating around as diff kits, >already installed and tested. Although I didn't explore this specifically, I saw nothing that would preclude someone or some company from signing a license agreement with PH, building an "enhanced" version of MINIX, and then selling as many as the market will bear. The only rule is that this licensee (Company X) would have to behave like a business: report each sale and collect a license fee. The license fees depend upon the quantity Company X believes can be sold, and require some amount of prepayment. License fees appear to be fairly reasonable, for example, perhaps US $50 at quantity 1000. But for this license fee, Company X must duplicate its own diskettes and produce its own release notes. And answer its own phones, and handle customer gripes, and strike its own licensing agreements with the individuals who wrote the various add-on packages that make up eminix. And so on.. >If I'm wrong, and there is such a place to get a full 32 bit minix with >VM, hardware supported memory protection, and other assorted enhancements >such as GNU gcc, g++, emacs, etc, with full sources and binaries for the >entire system, preferably for an Amiga 3000, then please tell me. I don't know of anyone who sells this, but that's not PH's fault.. Al  0, unseen,, *** EOOH *** From: ast@cs.vu.nl (Andy Tanenbaum) Newsgroups: comp.os.minix Subject: Re: Unhappy campers Date: 5 Feb 92 23:23:26 GMT Organization: Fac. Wiskunde & Informatica, Vrije Universiteit, Amsterdam In article <205@fishpond.uucp> fnf@fishpond.uucp (Fred Fish) writes: >If PH was not granted a monopoly on distribution, it would have been possible >for all of the interested minix hackers to organize and set up a group that >was dedicated to producing enhanced-minix. This aim of this group could have >been to produce a single, supported version of minix with all of the commonly >requested enhancements. This would have allowed minix to evolve in much the >same way that gcc has evolved over the last few years. This IS possible. If a group of people wants to do this, that is fine. I think co-ordinating 1000 prima donnas living all over the world will be as easy as herding cats, but there is no legal problem. When a new release is ready, just make a diff listing against 1.5 and post it or make it FTPable. While this will require some work on the part of the users to install it, it isn't that much work. Besides, I have shell scripts to make the diffs and install them. This is what Fred van Kempen was doing. What he did wrong was insist on the right to publish the new version, rather than diffs against the PH baseline. That cuts PH out of the loop, which, not surprisingly, they weren't wild about. If people still want to do this, go ahead. Of course, I am not necessarily going to put any of these changes in my version, so there is some work keeping the official and enhanced ones in sync, but I am willing to co-operate to minimize work. I did this for a long time with Bruce Evans and Frans Meulenbroeks. If Linus wants to keep control of the official version, and a group of eager beavers want to go off in a different direction, the same problem arises. I don't think the copyright issue is really the problem. The problem is co-ordinating things. Projects like GNU, MINIX, or LINUX only hold together if one person is in charge. During the 1970s, when structured programming was introduced, Harlan Mills pointed out that the programming team should be organized like a surgical team--one surgeon and his or her assistants, not like a hog butchering team--give everybody an axe and let them chop away. Anyone who says you can have a lot of widely dispersed people hack away on a complicated piece of code and avoid total anarchy has never managed a software project. >Where is the sizeable group of people that want to evolve gcc in a way that >rms/FSF does not approve of? A compiler is not something people have much emotional attachment to. If the language to be compiled is a given (e.g., an ANSI standard), there isn't much room for people to invent new features. An operating system has unlimited opportunity for people to implement their own favorite features. Andy Tanenbaum (ast@cs.vu.nl)  0, unseen,, *** EOOH *** From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.minix Subject: Re: Unhappy campers Date: 6 Feb 92 10:33:31 GMT Organization: University of Helsinki In article <12746@star.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes: > >If Linus wants to keep control of the official version, and a group of eager >beavers want to go off in a different direction, the same problem arises. This is the second time I've seen this "accusation" from ast, who feels pretty good about commenting on a kernel he probably haven't even seen. Or at least he hasn't asked me, or even read alt.os.linux about this. Just so that nobody takes his guess for the full thruth, here's my standing on "keeping control", in 2 words (three?): I won't. The only control I've effectively been keeping on linux is that I know it better than anybody else, and I've made my changes available to ftp-sites etc. Those have become effectively official releases, and I don't expect this to change for some time: not because I feel I have some moral right to it, but because I haven't heard too many complaints, and it will be a couple of months before I expect to find people who have the same "feel" for what happens in the kernel. (Well, maybe people are getting there: tytso certainly made some heavy changes even to 0.10, and others have hacked it as well) In fact I have sent out feelers about some "linux-kernel" mailing list which would make the decisions about releases, as I expect I cannot fully support all the features that will /have/ to be added: SCSI etc, that I don't have the hardware for. The response has been non-existant: people don't seem to be that eager to change yet. (well, one person felt I should ask around for donations so that I could support it - and if anybody has interesting hardware lying around, I'd be happy to accept it :) The only thing the copyright forbids (and I feel this is eminently reasonable) is that other people start making money off it, and don't make source available etc... This may not be a question of logic, but I'd feel very bad if someone could just sell my work for money, when I made it available expressly so that people could play around with a personal project. I think most people see my point. That aside, if Fred van Kempen wanted to make a super-linux, he's quite wellcome. He won't be able to make much money on it (distribution fee only), and I don't think it's that good an idea to split linux up, but I wouldn't want to stop him even if the copyright let me. >I don't think the copyright issue is really the problem. The problem is >co-ordinating things. Projects like GNU, MINIX, or LINUX only hold together >if one person is in charge. Yes, coordination is a big problem, and I don't think linux will move away from me as "head surgeon" for some time, partly because most people understand about these problems. But copyright /is/ an issue: if people feel I do a bad job, they can do it themselves. Likewise with gcc. The minix copyright, however, means that if someone feels he could make a better minix, he either has to make patches (which aren't that great whatever you say about them) or start off from scratch (and be attacked because you have other ideals). Patches aren't much fun to distribute: I haven't made cdiffs for a single version of linux yet (I expect this to change: soon the patches will be so much smaller than the kernel that making both patches and a complete version available is a good idea - note that I'd still make the whole version available too). Patches upon patches are simply impractical, especially for people that may do changes themselves. >>Where is the sizeable group of people that want to evolve gcc in a way that >>rms/FSF does not approve of? >A compiler is not something people have much emotional attachment to. If >the language to be compiled is a given (e.g., an ANSI standard), there isn't >much room for people to invent new features. An operating system has unlimited >opportunity for people to implement their own favorite features. Well, there's GNU emacs... Don't tell us people haven't got emotional attachment to editors :) Linus  0, unseen,, *** EOOH *** From: laverman@cs.rug.nl (Bert Laverman) Newsgroups: comp.os.minix Subject: Re: Unhappy campers Date: 6 Feb 92 09:41:07 GMT Organization: Dept. of Computing Science, Groningen University Originator: laverman@rug16 Nntp-Posting-Host: rug16 Andy Tanenbaum writes: > >Where is the sizeable group of people that want to evolve gcc in a way that > >rms/FSF does not approve of? > A compiler is not something people have much emotional attachment to. If > the language to be compiled is a given (e.g., an ANSI standard), there isn't > much room for people to invent new features. An operating system has unlimited > opportunity for people to implement their own favorite features. Try posting an announcement in one of the gnu groups about porting FSF software to the Macintosh... ;-) People will be emotional about anything they make, and more so if others try to do unexpected things with it. Software is no exception. If I remeber well, the only real attempt at global coordination of Minix projects has been Glen Overby's Projects directory at plains. Problem is that usually people don't want to announce all of their projects, because they are not sure about whether or when they will finish it. Fred was ready, and he told me he even set up big plans for only sending out his stuff to people who could prove they owned an original. PH was sceptical about his ability to check this, and their ability to check Fred. They were even less enthausiastic about his using the name "Minix" in the name of the final product. sigh. I've seen some of his code. Too bad he only works on PCs. Some of the ideas and comments floating around in the course of the current discussion were fixed by Fred; centralized system call server, dynamically added servers who can then serve new system calls. He ran TCP/IP as an added server. Sure, Fred has an unusual personality, and sometimes an attitude that smells of simply liking to run into a brick wall (not literally, please), but he is one hell of a programmer, and when he was still unemployed he had just the dynamism needed to get a large Minix rework done. I'ld allmost feel sorry for the fact that he has a job now. ;-) Perhaps we can use all this shouting and selfreflecting caused by the Linux wars to some good end. Glen Overby had the right idea in setting up a central site for collecting project info and ideas. What actually is needed is someone to volunteer maintaining such a database. Just saying "dump it here" will only transform anarchy to organized anarchy. Also portability of patches is currently far from ideal. As the recent sighup/init/getty activity shows, we have several packages, some of which are PC only, while others are ST only, and again others have simply never been tested on a wider range of machines. We have for the FS: - symbolic links, multi-threading For mm: - ?? kernel: - virtual consoles (standard on ST, addon on PC), sighup, the kub scheduler tools: - new init, boot packages, shoelace lib: - ?? commands: - zillions of programs I would like to suggest to those that built a patch set, to try and collect as much as possible info on portability, interference with other major patch sets, reliance on other major patch sets, and include this info with their patch sets. It would greatly help if an enthausiastic ST owner, having found a nice feature for his system, would not be (unpleasantly) surprised by the fact that the patch is only for PCs. Or vice versa of course. Greetings, Bert --- #include Bert Laverman, Dept. of Computing Science, Groningen University Friendly mail to: laverman@cs.rug.nl The rest to: /dev/null -- #include Bert Laverman, Dept. of Computing Science, Groningen University Friendly mail to: laverman@cs.rug.nl The rest to: /dev/null  0, unseen,, *** EOOH *** From: kentd@FtCollins.NCR.com (Kent Dalton) Newsgroups: comp.os.minix Subject: Re: Unhappy campers Date: 5 Feb 92 09:23:56 GMT Organization: NCR Microelectronics, Ft. Collins, CO In-reply-to: ast@cs.vu.nl's message of 3 Feb 92 22:46:40 GMT >>>>> On 3 Feb 92 22:46:40 GMT, ast@cs.vu.nl (Andrew "Dice" Tanenbaum) said: Andy> As an aside, for those folks who don't read news headers, Linus is Andy> in Finland and I am in The Netherlands. Are we reaching a Andy> situation where another critical industry, free software, that had Andy> been totally dominated by the U.S. is being taken over by the Andy> foreign competition? I prefer to think of it as indicative of the fact that the U.S. is still the pioneer when it comes to new ideas and technologies. The rest of the world just follows along, trying to refine and capitalize upon our new developments. :^) Andy> Will we soon see President Bush coming to Europe with Richard Andy> Stallman and Rick Rashid in tow, demanding that Europe import more Andy> American free software? Be glad software isn't as important as oil. ;^) -- /**************************************************************************/ /* Kent Dalton * EMail: Kent.Dalton@FtCollinsCO.NCR.COM */ /* NCR Microelectronics * CIS: 72320,3306 */ /* 2001 Danfield Ct. MS470A * */ /* Fort Collins, Colorado 80525 * (303) 223-5100 X-319 */ /**************************************************************************/ I've got an IDEA!! Why don't I STARE at you so HARD, you forget your SOCIAL SECURITY NUMBER!!  0, unseen,, *** EOOH *** From: nao@sala.sony.co.jp (HAMADA Naoki) Newsgroups: comp.os.minix Subject: Re: Unhappy campers Date: 6 Feb 92 12:08:51 GMT Reply-To: nao@sala.sony.co.jp Organization: Science Art Laboratory, Tokyo, Japan. In-Reply-To: ast@cs.vu.nl's message of 3 Feb 92 22:46:40 GMT Nntp-Posting-Host: skyline Greetings! In article <12667@star.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes: (most stuffs omitted) > If you don't have that journal, you can FTP the paper from > ftp.cs.vu.nl (192.31.231.42) in directory amoeba/papers as comp_sys.tex.Z > (compressed TeX source) or comp_sys.ps.Z (compressed PostScript). I am so much interested in this paper, but I cannot get it. The ftp server of ftp.cs.vu.nl rejects my connection because the IP address of machines in my site (and most sites in Japan), from machines outside of Japan, cannot be resolved by ptr. Is there anyone who has fetched it and placed it in annonymous ftp? Archie servers seem to have no idea. Thanks in advance. -HAMADA Naoki Naoki is my first name. nao@sala.sony.co.jp  0, unseen,, *** EOOH *** From: awoodhull@hamp.hampshire.edu Newsgroups: comp.os.minix Subject: Minix for 8088? Yes! Date: 4 Feb 92 15:10:46 GMT Organization: Hampshire College Subject: Minix for 8088? Yes! Some of the correspondence about Minix vs. Linux has argued that the 8088 compatibility of Minix is no longer important, because 80386 machines are not that much more expensive now. That may be true when you talk about new machines, but students are also in the market for used machines. I got a system quite competent to run Minix, a PC clone with two 360K floppy drives, for $75 recently at a yard sale. You aren't going to find second hand '386s for a while yet. Like ast I am also a professor. I expect to be teaching an OS course using Minix in Nicaragua next year. There, as in many other places outside the over-developed world, availability of entry-level or used computer equipment for student use is the best that most students can hope for. For the purpose for which it was created, continued compatibility of Minix with low-end hardware is definitely worth maintaining, and I hope ast will not change his target. Linux also sounds like a nice experiment, for a different purpose. I may decide to play with it, too, after I get Minix working on my new '486. I don't think I will use Linux in my teaching, however. Albert S. Woodhull School of Natural Science, Hampshire College, Amherst, MA 01002 awoodhull@hamp.hampshire.edu, woodhull@dawn.hampshire.edu  0, unseen,, *** EOOH *** From: dmiller@acg.uucp (David Miller) Newsgroups: comp.os.minix Subject: Linux is Obsolete and follow up postings Date: 3 Feb 92 01:03:46 GMT Distribution: all Organization: AppliedComputerGroup As an observer interested in operating system design, I couldn't resist this thread. Please realize that I am not really experienced with minux or linux: I have been into unix for many years. First, a few observations: Minix was written to be an educational tool for ASTs' classes, not a commercial operating system. It was never a design parameter to have it run freely available source code for unix systems. I think it was also a statement of how operating systems should be designed, with a micro kernel and seperate processes covering as much of the required functionality as possible. Linux was written mostly as a learning exercise on Linus part - how to program the 386 family. Designing the ultimate operating system was not an objective. Providing a usable, free platform that would run all sorts of widely available free software was a consideration, and one that appears to have been well met. Criticism from anyone that either of these systems isn't what *they* would like it to be is misplaced. After all, anybody that has a computer that will run either system is free to do what Linus and Andrew did: write your own! I, for one, applaud Linus for his considerable effort in developing Linux and his decision to make it free to everybody. I applaud AST for his effort to make minix affordable - I have real trouble relating to complaints that minix isn't free. If you can afford the time to explore minix, and a basic computer system, $150 is not much more - and you do get a book to go with it. Next, a few questions for the professor: Is minix supposed to be a "real operating system" or an educational tool ? As an educational tool it is an excellent work. As a real operating system it presents some terribly rough edges (why no malloc() ?, just for starters) My feeling from reading The Book and listening to postings here is that you wanted a tool to teach your classes, and a lot of others wanted to play with an affordable operating system. These others have been trying to bolt on enough features to make it a "real operating system", with less than outstanding success. Why split fundemental os functions, such as memory management, into user processes? As all good *nix gurus know, the means to success is to divide and conquer, with the goal being to *simplify* the problem into managable, well defined components. If splitting basic parts of the operating system into user space processes complicates the function by introducing additional mechanisms (message passing, complicated signals), have we met the objective of simplifying the design and implementation? I agree that *nix has suffered a bad case of feature-itis - especially sysVr4. Perhaps the features that people want for either functionality or compatibility could be offered by run-time loadable modules/libraries that offer these features. The micro-kernel would still be a base-level resource manager that also routes function requests to the appropriate module/library. The modules could be threads or user processes. (I think - os hackers please correct me :-) ) Just my $.04 worth - please feel free to post or email responses. I have no formal progressive training in computer science, so I am really asking these questions in ignorance. I suspect a lot of others on the net have similar questions in their own minds, but I've been wrong before. -- -- David David Miller Phone: (207) 873-3317 Applied Computer Group Fax: (207) 872-5018 5 Kimball Street UUCP: uunet!acg!dmiller  0, unseen,, *** EOOH *** From: rdc30@nmrdc1.nmrdc.nnmc.navy.mil (LCDR Michael E. Dobson) Newsgroups: comp.os.minix Subject: Re: Fred returning from the dead Date: 6 Feb 92 13:18:22 GMT Organization: Naval Medical Research & Development Command In article <1992Feb4.172131.18145@philce.ce.philips.nl> meulenbr@ce.philips.nl (Frans Meulenbroeks) writes: > >ast@cs.vu.nl (Andy Tanenbaum) writes: > >>Suppose Fred van Kempen returns from the dead and wants to take over, creating > >Just a remark for the readers. As far as I know Fred is not physically dead. >If english is not your native language (just like mine) you might >conclude otherwise from ast's words. Fred is only electronically dead. > He's not electronicly dead any longer either. I and several others involved with MUGNET have received electronic communications from him, that is unless our hosts are haunted by Fred's electronic spirit. -- Mike Dobson, Sys Admin for | Internet: rdc30@nmrdc1.nmrdc.nnmc.navy.mil nmrdc1.nmrdc.nnmc.navy.mil | UUCP: ...uunet!mimsy!nmrdc1!rdc30 AT&T 3B2/600G Sys V R 3.2.2 | BITNET: dobson@usuhsb or nrd0mxd@vmnmdsc WIN/TCP for 3B2 | MCI-Mail: 377-2719 or 0003772719@mcimail.com  0, unseen,, *** EOOH *** From: michael@gandalf.informatik.rwth-aachen.de (Michael Haardt) Newsgroups: comp.os.minix Subject: 1.6.17 summary and why I think AST is right. Date: 6 Feb 92 20:07:25 GMT Reply-To: u31b3hs@messua.informatik.rwth-aachen.de (Michael Haardt) Organization: Gandalf - a 386-20 machine Nntp-Posting-Host: kaa I will first give a summary of what you can expect from MINIX in *near* future, and then explain why I think AST is right. Some time ago, I asked for details about the next MINIX release (1.6.17). I got some response, but only from people running 1.6.16. The following informations are not official and may be wrong, but they are all I know at the moment. Correct me if something is wrong: - The 1.6.17 patches will be relative to 1.5 as shipped by PH. - The header files are clean. - The two types of filesystems can be used together. - The signal handling is rewritten for POSIX. The old bug is removed. - The ANSI compiler (available from Transmediar, I guess) comes with compiler binaries and new libraries. - There don't seem to be support for the Amoeba network protocol. - times(2) returns a correct value. termios(2) is implemented, but it's more a hack. I don't know if "implemented" means in the kernel, or the current emulation. - There is no documentation about the new filesystem. There is a new fsck and a new mkfs, don't know about de. - With the ANSI compiler, there is better floating point support. - The scheduler is improved, but not as good as written by Kai-Uwe Bloem. I asked these things to get facts for the decision if I should upgrade to MINIX 1.6.17 or to Linux after the examens are over. Well, the decision is made: I will upgrade to Linux at the end of the month and remove MINIX from my winchester, when Linux runs all the software I need and which currently runs under MINIX 1.5 with heavy patches. I guess this may take up to two months. These are the main reasons for my decision: - There is no "current" MINIX release, which can be used as basis for patches and nobody knows, when 1.6.17 will appear. - The library contains several bugs and from what I have heard, there is no work done at them. There will not be a new compiler, and the 16 bit users still have to use buggy ACK. - 1.6.17 should offer more POSIX, but a complete termios is still missing. - I doubt that there is still much development for 16 bit users. I think I will stop maintaining the MINIX software list in a few months. Anyone out there, who would like to continue it? Until Linux runs *perfect* on my machine, each update of Origami will still run on 16-bit MINIX. I will announce when the last of these versions appears. In my opinion, AST is right in his decision about MINIX. I read the flame war and can't resist to say that I like MINIX the way it is, now where there is Linux. MINIX has some advantages: - You can start playing with it without a winchester, you can even compile programs. I did this a few years ago. - It is so small, you don't need to know much to get a small system which runs ok. - There is the book. Ok, only for version 1.3, but most of it is still valid. - MINIX is an example of a non-monolithic kernel. Call it a microkernel or a hack to overcome braindamaged hardware: It demonstrates a concept, with its pros and cons -- a documented concept. In my eyes, it is a nice system for first steps in UNIX and systems programming. I learned most of what I know about UNIX with MINIX, in all areas, from programming in C under UNIX to system administration (and security holes:) MINIX grew with me: 1.5.xx upgrades, virtual consoles, mail & news, text processing, crosscompiling etc. Now it is too small for me. I don't need a teaching system anymore, I would like to get a more complicated and featureful UNIX, and there is one: Linux. Back in the old days, v7 was state of the art. There was MINIX which offered most of it. In one or two years, POSIX is what you are used to see. Hopefully, there will be MINIX, offering most of it, with a new book, for people who want to run a small system to play and experiment with. Stop flaming, MINIX and Linux are two different systems with different purposes. One is a teaching tool (and a good one I think), the other is real UNIX for real hackers. Michael  0, unseen,, *** EOOH *** From: dingbat@diku.dk (Niels Skov Olsen) Newsgroups: comp.os.minix Subject: Re: 1.6.17 summary and why I think AST is right. Date: 10 Feb 92 17:33:39 GMT Organization: Department of Computer Science, U of Copenhagen michael@gandalf.informatik.rwth-aachen.de (Michael Haardt) writes: >Stop flaming, MINIX and Linux are two different systems with different >purposes. One is a teaching tool (and a good one I think), the other is >real UNIX for real hackers. Hear, hear! And now Linux articles in alt.os.linux (or comp.os.misc if your site don't receive alt.*) and Minix articles here. eoff (end of flame fest :-) Niels