Linux history

From: dgraham@bmers30.bnr.ca (Douglas Graham) 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.

From: hedrick@klinzhai.rutgers.edu (Charles Hedrick) 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.

From: tytso@athena.mit.edu (Theodore Y. Ts'o) 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   >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!