eesrajm@cc.brunel.ac.uk (Andrew J Michael) (03/01/90)
Several people have recently commented that MINIX is a teaching operating system, not a real one. So what makes a real O/S ? Is it the O/S itself, or the utilities which come with it ? Surely no-one in their right minds would buy MSDOS as an operating system; they buy it for the programs they can run on it. The same argument can be applied to MINIX; it is seen as a teaching O/S because the programs which it runs are pretty restricted in their outlook. All that MINIX needs to become a real O/S is application programs. I must also suggest (and I don't want to start a flame war) that one's view of MINIX may be tempered by which machine you are running it on. I have tried both MINIX-PC and MINIX-ST, and I regard the ST as superior because porting public-domain UNIX programs to it is pretty simple. No restrictions on length of variables or memory usage. The only real problem is 16-bit ints, but gcc removes this restriction. When I did my part-time MSc recently, virtually all the project work was done on a MINIX machine at home (admittedly my 68020, not an ST). MINIX supported enough of ACK to develop a backend for the Acorn ARM with very little trouble. MINIX kept my project diary, it sent my mail and did lots of other jobs. Finally, running TeX, it produced my dissertation and printed it. That sounds like a pretty real operating system to me. Andy Michael -- Andy Michael (eesrajm@cc.brunel.ac.uk) " Software cannot be written to 85 Hawthorne Crescent be completely free of errors." West Drayton Middlesex - Acorn Computers Ltd. UB7 9PA
bammi@curie.ces.CWRU.Edu (Jwahar R. Bammi) (03/02/90)
In article <1383@Terra.cc.brunel.ac.uk> eesrajm@cc.brunel.ac.uk (Andrew J Michael) writes:
both MINIX-PC and MINIX-ST, and I regard the ST as superior because porting
public-domain UNIX programs to it is pretty simple. No restrictions on length
of variables or memory usage. The only real problem is 16-bit ints, but gcc
removes this restriction.
i must say i agree 100% with andy. in my opinion, minix-pc is a *toy*
mainly because of the 64k segments. unfortunately, this also also
effects how code gets written for minix in general. witness the
definition of NULL, size_t (this is a worse than NULL) etc in the 1.5
header files. its even deeper than that: using zero for null pointers
all over the place (even if NULL is used), the ACK C compiler for the
St thinks that the typeof( sizeof ) is unsigned 16 bit int. Also, all
the silly segment things all over the design of the kernel (note i am
not complaining about clicks). i hope with the refree system we see
the weeding out such system dependent code.
--
--
bang: {any internet host}!dsrgsun.ces.CWRU.edu!bammi jwahar r. bammi
domain: bammi@dsrgsun.ces.CWRU.edu
GEnie: J.Bammijdudeck@polyslo.CalPoly.EDU (John R. Dudeck) (03/02/90)
In article <1383@Terra.cc.brunel.ac.uk> eesrajm@cc.brunel.ac.uk (Andrew J Michael) writes: >Several people have recently commented that MINIX is a teaching operating >system, not a real one. > >So what makes a real O/S ? Is it the O/S itself, or the utilities which >come with it ? I would say that what makes a real OS is the OS itself, not the utilities. After all, it is possible to set up an entire set of the Unix utilities under MS-DOS, and give a very Unix-like feel to DOS. Of course what is missing when you do this are the multiple processes of Unix. An OS's purpose is to provide a high-level interface to the underlying hardware, at the system-call level. A "standard" operating system provides a standard interface, so that there is portability of software between systems. A "real" OS is one which provides a reasonably complete mapping of the capabilities of the underlying hardware into a higher-level programming interface. In addition, there are a number of other non-hardware related services provided by a real OS, such as multiple processes. >Surely no-one in their right minds would buy MSDOS as an >operating system; they buy it for the programs they can run on it. This is true. MS-DOS lacks many of the elements that are generally considered to be part of a "reasonably complete" OS, such as multiple processes, access to a reasonable amount of memory to run programs in, etc. On the other hand, it does provide better support than Minix for some parts of the hardware, such as the range of floppy and hard disks available, and the range of video adapters. In my opinion, Minix is close to being a "real" OS. Here is what I think it still lacks: - Support for full use of available memory by programs. In the 80x86 world this means support for the large memory model. - Support for the math chip in context switches (has this been added?) - Support for the full range of hard and floppy disk types available on whatever platform it is running on. - Swapping (has this been added?). - Spooled printing. Of course there are a lot of other things that would be nice. But these are the main things that Minix lacks, which keep it from being viable as an OS used in say, a business setting. Without these, the range of applications is limited, and the frustration level is too high. -- John Dudeck "You want to read the code closely..." jdudeck@Polyslo.CalPoly.Edu -- C. Staley, in OS course, teaching ESL: 62013975 Tel: 805-545-9549 Tanenbaum's MINIX operating system.
cagney@chook.ua.oz (Andrew Cagney - aka Noid,285,5585,3362395) (03/02/90)
Oh, no no again.....
peter@ficc.uu.net (Peter da Silva) (03/02/90)
In article <25eda193.62e3@polyslo.CalPoly.EDU> jdudeck@polyslo.CalPoly.EDU (John R. Dudeck) writes: > In my opinion, Minix is close to being a "real" OS. Here is what I think > it still lacks: ... > - Spooled printing. That's a system program level sort of thing, not part of the O/S. I'm sure you could implement spooled printing for a single-system single-printer environment in a day. Hell, the following code would do just fine for many folks: ---lpr--- NEXT=`cat /usr/spool/lp/.next` if [ 0 = $# ] then cat > /usr/spool/lp/D.$NEXT set /usr/spool/lp/D.$NEXT fi echo $* > /usr/spool/lp/C.$NEXT NEXT=`expr $NEXT + 1` echo $NEXT >> /usr/spool/lp/.next ---lpq--- ls /usr/spool/lp | while read X do echo "$X\t`cat /usr/spool/lp/$X`" done ---lpd--- touch /usr/spool/lp/.run while [ -f /usr/spool/lp/.run do ls /usr/spool/lp/C.* | while read X do FILES=`cat /usr/spool/lp/$X` cat > /dev/lp << ! ****************************************************************************** $FILES ****************************************************************************** \f ! for FILE in $FILES do cat $FILE > /dev/lp echo \f >/dev/lp done rm -f $X `echo $X | sed 's/C/D/'` done sleep 1 done -- _--_|\ Peter da Silva. +1 713 274 5180. <peter@ficc.uu.net>. / \ \_.--._/ Xenix Support -- it's not just a job, it's an adventure! v "Have you hugged your wolf today?" `-_-'
overby@plains.UUCP (Glen Overby) (03/03/90)
In article <1383@Terra.cc.brunel.ac.uk> eesrajm@cc.brunel.ac.uk (Andrew J Michael) writes: >Several people have recently commented that MINIX is a teaching operating >system, not a real one. >So what makes a real O/S ? Is it the O/S itself, or the utilities which >come with it ? Both. The kernel alone isn't of much use; you need to surround it with good tools. Some people have faulted Minix for only using 64K segments. I think there are very good reasons for doing this on 8088s: there is much less of a chance of programs running over each other if they do not touch the segment registers. The compilers are easier to write, too. Minix on 80386s will run 32-bit segments, so you can have your GNUisms and other memory-hungry programs. I haven't seen a real Unix that allows huge model programs on an 8088 or 80286. The problems of device compatability we have encountered with Minix are no different than what any other multitasking operating system (i.e. one that does not rely soley on the ROM BIOS for it's I/O) has encountered. I think there are two things left to make Minix an extremely usable system: (1) the ability to swap, thus allowing iddle programs to be shoved out of memory, allowing larger programs to use available memory. (2) the bottleneck in the filesystem and, to a lesser extent, the memory manager will have to be dealt with. The problem right now is that one process can quite effectively take over the system by keeping the filesystem busy. We've already seen one attempted solution to this: a "multitasking" filesystem. It was a bit ugly. I think a nicer solution will be to implement threads (aka lightweight processes, and probably a few other synonyms). Then it will be possible to have multiple threads of execution servicing requests in all of the servers and devices. I doubt Minix will ever become a serious alternative for businesses, but it should make a good a personal (or "hacker", if you will) operating system. -- Glen Overby <overby@plains.nodak.edu> uunet!plains!overby (UUCP) overby@plains (Bitnet)
ast@cs.vu.nl (Andy Tanenbaum) (03/05/90)
In article <3696@plains.UUCP> overby@plains.nodak.edu (Glen Overby) writes: >I think there are two things left to make Minix an extremely usable system: >(1) the ability to swap >(2) the bottleneck in the filesystem ... I think that problem (1) is only really an issue on 8088 systems and very small 80x86 ones. With memory prices dropping all the time, having 1M or more on an 80286 or 80386 is hardly uncommon these days. With 1M of program memory it is very rare to get so many processes active that it fills up and would have to swap. Thus putting in swapping for the benefit of the 8088 only seems like a fairly low priority item. If you have 640K and no RAM disk, with MINIX eating up about 140K, you still have 500K for programs. You have to run a fair amount of stuff in the background to fill that up, and with 2 or 3 background jobs on an 8088, the performance won't be so great. As to (2), the only difference the single-threadedness makes is some loss of performance if you have two or more I/O bound jobs running at once. For a CPU bound job (e.g., the compiler, compress, nroff), you won't gain that much. If the foreground job is an editor, and is mostly idle, I very much doubt whether you would notice the gain, but the change is very complicated and introduces all kinds of possibilities for race conditions deadlocks and the like. I don't think it is worth it. A couple of thoughts on toy-ness. Original, MINIX was clearly a toy. It had the following characteristics: - Was aimed at an 8088 with 2 floppy disks - very few utilities - editor that could only handle files to 40K It has clearly evolved over the years, in no small part due to the collective efforts of the people in Netland. It is fair to currently characterize it as: - Aimed at 80286 or 80386 with lots of memory running in protected mode - Works with most hard disks - Soon to be available on the Atari, Amiga, and Macintosh; SPARC later - About 175 utilities - Editors include ed, ex, vi, and a mini-emacs, in addition to mined - Over 225 library routines - ANSI C compiler now running, will be available within 6 months - POSIX compatibility probably in a year or so - Pascal compiler available from UniPress and Transmediair - RS232 supported, kermit and zmodem available (uucp?) - Up to 3 users can run on the same machine - text processing with a somewhat lobotomized nroff - Distributed computing via Ethernet was in 1.3, hope to get it back in 1.5 While it is clearly nowhere near BSD 4.3 or System V, I think that running MINIX on a 2M PC/AT all by yourself is not that much worse that sharing a PDP-11/45 with 8 other people, and perhaps even a bit better. I think that if you compare MINIX 1.5 and its utilities to what you get if you buy MS-DOS in a box from Microsoft, it is not a toy at all. There is only one real technical limitation, but one that the PDP-11 also had: the 64K + 64K address limit. It is clearly getting to be a nuisance, but I am very hesitant to hack in segments just for the 286. On a 386, with Bruce's code, you can run 32 bits. Thus I prefer to keep the simple architecture of a linear address space. Note that the 64K property is not inherent to MINIX. On the 68000s, programs can be as big as memory. The 64K comes from the brain-damaged 8088 archtitecture, and going to multiple segments seems to be the wrong thing to do now with the future of even low-end machines clearly being the 386(SX) chips. A single, linear address space is so much simpler. I see MINIX-ST as the prototype. The most conspicuous thing lacking is a lot of applications software. There is kind of a vicious circle operating here: with a small user base, companies don't even consider making software for MINIX, and without software, the user base remains small. One thing that the newsgroup could do is look around for public domain software available in source form in C, and try porting it to MINIX. There is a huge amount of PD software around, most of it awful, but even if only 1% is good, that is still a great deal. Perhaps we need a mechanism to allow people who do a lot of work writing or porting some major utility to be able to sell it for a modest price (preferably with source). This might provide some incentive. Would the MINIX Centre in England be a suitable mechanism (Andy Michael-- any comments?)? Andy Tanenbaum (ast@cs.vu.nl)
peter@ficc.uu.net (Peter da Silva) (03/06/90)
I feel compelled to pop this in... In article <5741@star.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes: > While it is clearly nowhere near BSD 4.3 or System V... Thank god! > There is only one real technical limitation, but one that the PDP-11 also > had: the 64K + 64K address limit. It is clearly getting to be a nuisance, > but I am very hesitant to hack in segments just for the 286. Good for you. Make no compromises with terrorist architecture! I might just get a 386SX machine just to run MINIX, even without VM. In the meantime, how about shared libraries? That'd cut the overhead problem down a bunch. Is anyone working on it? -- _--_|\ Peter da Silva. +1 713 274 5180. <peter@ficc.uu.net>. / \ \_.--._/ Xenix Support -- it's not just a job, it's an adventure! v "Have you hugged your wolf today?" `-_-'
stailey@iris613.gsfc.nasa.gov (Ken Stailey) (03/07/90)
In article <3612QZxds13@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: >In the meantime, how about shared libraries? That'd cut the overhead problem What about shared text? How many copies of "sh" are usually being run at once? INET stailey@iris613.gsfc.nasa.gov UUCP {backbone}!dftsrv!iris613!stailey
kjh@pollux.usc.edu (Kenneth J. Hendrickson) (03/12/90)
In article <25eda193.62e3@polyslo.CalPoly.EDU> jdudeck@polyslo.CalPoly.EDU (John R. Dudeck) writes:
%In my opinion, Minix is close to being a "real" OS. Here is what I think
%it still lacks:
% - Support for full use of available memory by programs. In the 80x86 world
% this means support for the large memory model.
% - Support for the math chip in context switches (has this been added?)
% - Support for the full range of hard and floppy disk types available
% on whatever platform it is running on.
% - Swapping (has this been added?).
% - Spooled printing.
How about virtual memory, so a large address space can be supported?
Ken Hendrickson N8DGN kjh@usc.edu ...!uunet!usc!pollux!kjhgert@targon.UUCP (Gert Kanis) (03/16/90)
In article eesrajm@cc.brunel.ac.uk (Andrew J Michael) writes: >I have tried >both MINIX-PC and MINIX-ST, and I regard the ST as superior because porting >public-domain UNIX programs to it is pretty simple. No restrictions on length >of variables or memory usage. The only real problem is 16-bit ints, but gcc >removes this restriction. ^^^^^^^^^^^^^^^^^^^^^^^^^^^ > >Andy Michael Hi there, I for one don't see how 16 bit ints could be a REAL problem..... As you undoubtly know: short = at least 16 bit int = at least 16 bit long = at least 32 bit The real length of an int depends on the architecture (the compiler should know about this :-/). Nevertheless NO portable code should rely on ints being longer than 16 bit (use longs instead). What's the problem? Gert Kanis. +-----------------------------------------------------------------+ | No more jokes they | Gert Kanis, ASW CBS SWP | | take to much space. | Nixdorf Computer BV, Postbus 29 | |----------------------| 4130 EA Vianen, Netherlands. | | I do not represent | E-mail : ... nluug.nl!targon!gert | | anyone elses opinion.| or {..uunet!mcsun!}hp4nl!targon!gert | +-----------------------------------------------------------------+
HBO043%DJUKFA11.BITNET@cunyvm.cuny.edu (Christoph van Wuellen) (03/20/90)
(Concerning 16-bit ints)
Well, the problem simply is that there is much software which makes
illegal assumptions on the size of int's and which you don't want
either to reject or to fix.
C.v.W.