Path: gmdzi!unido!mcsun!ukc!strath-cs!cs.glasgow.ac.uk!bru-cc!eesrajm
From: eesr...@cc.brunel.ac.uk (Andrew J Michael)
Newsgroups: comp.os.minix
Subject: A real operating system ?
Keywords: future 1.5
Message-ID: <1383@Terra.cc.brunel.ac.uk>
Date: 28 Feb 90 20:19:59 GMT
Organization: Brunel University, Uxbridge, UK
Lines: 34
Posted: Wed Feb 28 21:19:59 1990
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 (eesr...@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
Path: gmdzi!unido!mcsun!uunet!ogicse!plains!overby
From: ove...@plains.UUCP (Glen Overby)
Newsgroups: comp.os.minix
Subject: Re: A real operating system ?
Summary: I prefer a virtual operating system.
Keywords: future 1.5
Message-ID: <3696@plains.UUCP>
Date: 2 Mar 90 23:29:29 GMT
References: <1383@Terra.cc.brunel.ac.uk> <25eda193.62e3@polyslo.CalPoly.EDU>
Reply-To: ove...@plains.nodak.edu (Glen Overby)
Organization: North Dakota State University, Fargo
Lines: 42
Posted: Sat Mar 3 00:29:29 1990
In article <1...@Terra.cc.brunel.ac.uk> eesr...@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 <ove...@plains.nodak.edu>
uunet!plains!overby (UUCP) overby@plains (Bitnet)
Path: gmdzi!unido!mcsun!hp4nl!star.cs.vu.nl!ast
From: a...@cs.vu.nl (Andy Tanenbaum)
Newsgroups: comp.os.minix
Subject: Re: A real operating system ?
Keywords: future 1.5
Message-ID: <5741@star.cs.vu.nl>
Date: 4 Mar 90 18:44:27 GMT
References: <1383@Terra.cc.brunel.ac.uk> <25eda193.62e3@polyslo.CalPoly.EDU>
<3696@plains.UUCP>
Sender: n...@cs.vu.nl
Organization: Fac. Wiskunde & Informatica, VU, Amsterdam
Lines: 78
Posted: Sun Mar 4 19:44:27 1990
In article <3...@plains.UUCP> ove...@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 (a...@cs.vu.nl)
Path: gmdzi!unido!mcsun!ukc!strath-cs!cs.glasgow.ac.uk!bru-cc!eesrajm
From: eesr...@cc.brunel.ac.uk (Andrew J Michael)
Newsgroups: comp.os.minix
Subject: A Real Operating System (Part II)
Keywords: MINIX ST PC
Message-ID: <1460@Terra.cc.brunel.ac.uk>
Date: 23 Apr 90 15:51:15 GMT
Organization: Brunel University, Uxbridge, UK
Lines: 57
Posted: Mon Apr 23 16:51:15 1990
Last month I posted my thoughts on how "real" an operating system MINIX was
(or was not). Unfortunately after posting the article I vanished for a few
weeks, and therefore failed to answer some of the replies. Ast also asked
for my comments (as a part-time consultant for The MINIX Centre) on porting
public domain software to MINIX. I have ported several public domain programs
to MINIX, ranging from PLPL (a PAL/JEDEC compiler) to TeX. The following
conclusions my be of interest .........
Firstly I have given up any further attempts on porting software to the PC,
because the PC has two major problems. The 64k limit is well known; I cannot
even get MicroEMACS to link under MINIX-PC, and it isn't really a large program.
Secondly, I did not originally realise that MINIX-PC has problems with
identifiers longer than 8 characters (I think - it might be six, or ten).
Thus MicroEMACS won't even compile without some massaging of procedure names.
I'm not saying that it isn't possible to tweak some software so that it will
compile and link under MINIX-PC, but to my mind the least effort that has to
be expended in re-inventing the wheel, the better.
I have also given up using the ACK C compiler on the ST, but for a different
reason, although this is also well known; sizeof(int) != sizeof(char *).
I fully appreciate the arguments put forward in the MINIX-ST manual as to the
choice of 16-bit ints for the ST, but they are, IMHO, inconsequential in
comparison with the question of compatibility with UNIX software. Like it or
not, the vast majority of the public domain software assumes that an int and
a pointer are the same size. One could argue that this software is broken and
needs fixing (I agree, so don't flame me !), but that isn't the point. I have
spent far too many hours trying to fix such programs, and I really don't have
that much time to waste. The only solution is if-you-can't-beat-em-join-em
and use a 32-bit int compiler; gcc.
However, gcc has problems; for obvious reasons it is hardly likely to ever be
distributed with MINIX, and it is very memory hungry. That said, if you have
enough memory to run it it is the answer to the software porting dream. As
an example, the yacc recently posted to comp.sources.unix compiled and ran
without a single alteration.
So - a wishlist for MINIX to enhance portability of public domain UNIX
programs looks like this:
(1). Removal of the 64k limit on MINIX-PC.
(2). Removal of the identifier limit on MINIX-PC (this will probably come with
the ANSI compiler; ACK V4 already has a MINIX-PC compiler using .o files
and the same linker as the ST).
(3). An ACK C compiler for the ST with both 16 AND 32 bit ints, software
selectable like gcc. Again, ACK already has hooks for this.
And finally, we need the world to start writing POSIX compatible software ...
Andy Michael
--
Andy Michael (eesr...@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