OSNews

Seems to be written mostly by students without a clue.

You do know who Andy Tanenbaum is, right? If you make wild claims like this, you better show some proof.

Just because someone is a recognized computer scientist/professor that has their name splattered all over computer science textbooks that often are specialized on the gory details of how OS's are implemented doesn't say anything about the quality of the product (outside the textbooks) that are associated with him. In other words, he may be mostly overseeing a bunch of students working on this, or perhaps just a bunch of monkeys trained well enough to get C code to compile: the short bug list in the header for this thread alone states that surprisingly little care was put into this release of MINIX, because the errors mentioned are those made by beginners and/or those that didn't bother to properly test things. Let me explain:

"autopart truncase new partitions at 4GB" sounds suspiciously like someone using 32 bit unsigned ints when a larger int should have been used: creating a test case for boundaries of number representation would have been done by someone concerned with the quality of their product, and such 32 bit boundaries are obvious, especially to someone that's attempted to find the amount of free space left on a disk after FAT32 came out, using the old Windows API for that which didn't take that into account.

"a missing check in rename caused moving directories to hang sometimes;": frankly, there aren't that many cases to test for when moving directories in a filesystem. This is an amazingly stupid error to make and not have tested for before shipping.

"mkfs does not check for overflow of firstdatazone field in superblock;" is yet again, another stupid error made most commonly by beginners.

So, I'm guessing Andy Tanenbaum has more of his name than his effort involved in this release: I'd be ashamed to have released something with these noob bugs in it. I also suspect he's had very little personal review time put into it, and at least in the case of the superblock overflow, that may readily be caught by running lint. This release of MINIX has "student hands" written all over it by this thread's posting text alone.

(fixed typo)

Edited 2007-06-09 17:12

"""
You do know who Andy Tanenbaum is, right? If you make wild claims like this, you better show some proof.
"""

Andy Tanenbaum is a long time professor of the ivory tower variety who has written some good books on OS theory and is increasingly known for positions he has taken which have turned out to be wrong.

He is also not above presenting misleading data to support his positions, an example of which, regarding the performance penalty of message passing, I link here.

http://lwn.net/Articles/220255/

"The quality of the source isn't very good, unfortunately."

This is an argument to question the qualities of Minix to be used in education. Good formatted code, identifiers chosen wisely, along with good documentation makes such kinds of material usable from a didactic point of view.

Just have a look at the documentation quality that BSDs offer - and they do not claim to be systems used in education. The source is well documented, and every kernel / system call, library function, OS component (command or file) has an own manual entry.

Reaching good source code quality will make Minix appealing to developers, too, because they usually need to know more than Joe Q. Sixpack or his son in highschool. :-)

Well well, you can always offer your coding skills to the project, if you think you can do better than those lame clueless students.

If you'd ever read one of AST's books, you would never make such claims.

"""
If you'd ever read one of AST's books, you would never make such claims.
"""

I don't think that anyone questions AST's grasp of operating system theory.

It's the "real world" bit that generates the skepticism.

Edited 2007-06-09 23:40

It's pretty shallow to dismiss microkenels as being less capable to alternatives by pointing to one incomplete implementation. The overall model may be more complex than other models but uKs have the potential to be far more secure and flexible than monolithic kernels as theorised by academics. Work needs to be invested to realise this. Minix 3 currently doesn't have many of the memory management techniques found in current operating systems. The official Minix 3 doesn't have dynamic linking support yet. There is only so much work a person with a life outside of software development can do; give these people some time.

I also contend against your assertion that they are . I point to the canonical example of Qnx and I'll also point to Beos and Darwin. Minix is no more difficult to debug than any normal software. You're probably thinking of the GNU Hurd. I remember reading somewhere (I don't remember the source now) that developers of the Hurd platform say that it is more difficult to debug a Hurd server compared to a Minix server because the Hurd servers are agressively multithreaded.

"I point to the canonical example of Qnx "

That canonical example shows that uKernels cannot compete performancewise. Yes, Qnx guarantees timely delivery of services (it's a realtime OS). Somehow, people confuse that with beeing fast. In reality, it means that the scheduler (cpu and I/O) can be as unfair as it wants, as long as timely service delivery is guaranteed.

The truth is, Qnx is very slow and not very scalable, but its goal is *real time*, not speed, nor scalability, so that's fair.

So don't use that as a proof of a fast uKernel. It just isn't. It's an urban legend.

Edited 2007-06-10 09:47

I think you would have to use a loose definition of the term microkernel to be able to say that BeOS is one. It may have been in the very early years. I don't know what to say about Darwin. I don't think it deserves to be mentioned alongside QNX/Neutrino, L4 or GNU/Hurd.

AFAIK the BeOS' GUI responsiveness is primarily due to it's aggressive use of threads and prioritizing the GUI ones. QNX feels quite unresponsive in comparison.

Having written/maintained neither a microkernel nor a monolithic kernel based system I can't say which is the best when all aspects are considered, but I believe that with emerging hardware and languages, purely monolithic kernels seem to go the way of the Dodo.