Linux history

From: dmiller@acg.uucp (David Miller) Subject: Linux is Obsolete and follow up postings Date: 3 Feb 92 01:03:46 GMT 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

From: michael@gandalf.informatik.rwth-aachen.de (Michael Haardt) 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   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