Minix 3 hits the net
Posted Oct 24, 2005 14:57 UTC (Mon)
by thomask (guest, #17985)
[Link] (19 responses)
Posted Oct 24, 2005 15:02 UTC (Mon)
by hawk (subscriber, #3195)
[Link] (5 responses)
Posted Oct 25, 2005 0:37 UTC (Tue)
by ncm (guest, #165)
[Link] (4 responses)
Posted Oct 25, 2005 1:40 UTC (Tue)
by corbet (editor, #1)
[Link] (3 responses)
Posted Oct 25, 2005 21:12 UTC (Tue)
by ncm (guest, #165)
[Link] (2 responses)
Posted Oct 30, 2005 17:13 UTC (Sun)
by Los__D (guest, #15263)
[Link] (1 responses)
Under the "Source code" tab:
"MINIX 3 Source availability
Dennis
Posted Oct 30, 2005 17:22 UTC (Sun)
by Los__D (guest, #15263)
[Link]
Posted Oct 24, 2005 15:03 UTC (Mon)
by rmini (subscriber, #4991)
[Link]
Posted Oct 24, 2005 15:26 UTC (Mon)
by dowdle (subscriber, #659)
[Link] (10 responses)
Yes, minix was totally closed (as in AST would not accept patches for it) in the beginning because AST said he wanted to keep it simple for his OS book/class. He wanted to keep it multi-platform and wasn't interested at that time in arch independent optimizations. People could not distributed modified binaries and all changes to minix, as I understand it, were issued as patches against the pristine source... and the source was not freely distributable... without owning a copy of the book it came with. That was really a part put in there by the book publisher.
Of course fancy stuff was added to minix (like optimizations for the i386 and more advanced memory management) but it was harder to distribute them than on a truely free system... and thus Linux was born. If minix had been free, chances are Linux would NOT have been born... as Linus probably would have continued to use minix for the underlying system and just forked it at some point. Of course that is a lot of speculation on my part.
Thanks AST!
Posted Oct 24, 2005 16:06 UTC (Mon)
by man_ls (guest, #15091)
[Link] (9 responses)
Posted Oct 24, 2005 16:11 UTC (Mon)
by halla (subscriber, #14185)
[Link] (4 responses)
Posted Oct 24, 2005 17:23 UTC (Mon)
by man_ls (guest, #15091)
[Link] (2 responses)
Posted Oct 25, 2005 18:41 UTC (Tue)
by arcticwolf (guest, #8341)
[Link] (1 responses)
To the extent that Linus can be counted as my student, I'm proud of him, too. That is, not at all? I'm not sure what Tanenbaum actually wants to say here, but I think that Linus cannot be counted as one of his students to any extent at all, unless you want to conjecture that in some way, *all* CS students are students of *all* CS teachers. Is this a hidden side blow against Linus, or a sign of Tanenbaum's hubris (in that now that Linus is famous and Linux is *the* single most successful/important FOSS OS, he's trying to claim Linus as his student)?
Posted Oct 25, 2005 21:16 UTC (Tue)
by man_ls (guest, #15091)
[Link]
Posted Oct 25, 2005 3:15 UTC (Tue)
by landley (guest, #6789)
[Link]
Posted Oct 24, 2005 16:21 UTC (Mon)
by jedidiah (guest, #20319)
[Link] (3 responses)
Only if you ignored the fact that Linus was a Minux user and that Hurd didn't exist then.
Although, for all practical purposes Linus did infact "work on the Hurd".
Posted Oct 24, 2005 17:44 UTC (Mon)
by man_ls (guest, #15091)
[Link] (2 responses)
Posted Oct 24, 2005 20:09 UTC (Mon)
by larryr (guest, #4030)
[Link]
It think its fair to say that for all practical purposes Linux performs the role of the kernel for the "GNU System", the role the Hurd was to perform.
Larry
Posted Oct 25, 2005 7:48 UTC (Tue)
by xoddam (subscriber, #2322)
[Link]
Posted Oct 24, 2005 15:56 UTC (Mon)
by AnswerGuy (guest, #1256)
[Link]
As such it was expected that readers and users would liberally comment on it and one would naturally expect their code to reflect lessons they've learned from their studies. (In other words if my code as a professional programmer bore a notable resemblance to the methods and concepts, even to some idioms in AST's code; that would be expected of any students in any field of endeavor).
So, it's been technically non-free. On a practical level it was clear that AST wasn't looking for a fight with anyone over it.
JimD
Posted Oct 24, 2005 15:35 UTC (Mon)
by tjc (guest, #137)
[Link] (8 responses)
Posted Oct 24, 2005 16:16 UTC (Mon)
by eludias (guest, #4058)
[Link] (6 responses)
Expect that this won't work when f.e.:
While the device driver can be contained, the hardware it drives cannot be contained. And if the device driver is faulty, nothing can be guaranteed about what the hardware will or won't do. This is the same problem the kernel-crash-dump-guys are trying to solve: how to boot a new kernel reliably while the hardware is in an unknown state doing unknown writes to and from memory, and doing unknown things to the bus.
Still, could be useful for a common case of faults (mainly the ones not involving hardware ;), but it is by no means a solution for every device driver problem, just like rmmod/insmod is not the solution for every device driver problem for Linux now.
And don't forget that a Linux kernel Oops is also a kind of fault containment: the kernel tries to keep running (ok, more some kind of limping in some cases...).
Posted Oct 24, 2005 17:41 UTC (Mon)
by lutchann (subscriber, #8872)
[Link] (1 responses)
So this feature isn't a sure-fire guard against bad drivers, but I imagine the technique is quite a bit more helpful in a microkernel operating system than it would be in Linux.
Posted Oct 24, 2005 21:39 UTC (Mon)
by eludias (guest, #4058)
[Link]
It might help developing drivers, but cases like '(a) access a bad location in memory' are already gracefully handled to some extend by Linux with a non-fatal kernel OOPS; and '(b) internal state out of sync' can be remidied (again, to some extend) by using rmmod/lsmod. And indeed, the Minix safeguard is better and catches more errors, but does not solve it all.
Another way to debug drivers which do not drive hardware are using things like virtualisation (Qemu, User Mode Linux).
Posted Oct 25, 2005 20:47 UTC (Tue)
by tyhik (guest, #14747)
[Link]
Posted Oct 27, 2005 19:50 UTC (Thu)
by Max.Hyre (subscriber, #1054)
[Link] (2 responses)
tyhik points
out above:
The same would apply to the PCI and other vital drivers in the
micro-kernel, as well as applying to the last two points (needed
for reincarnation, can't reset). The smaller fish would cause
much less pain, though their problems could indeed degrade performance.
Posted Oct 27, 2005 20:43 UTC (Thu)
by corbet (editor, #1)
[Link] (1 responses)
Posted Oct 27, 2005 23:21 UTC (Thu)
by Max.Hyre (subscriber, #1054)
[Link]
Posted Oct 28, 2005 22:14 UTC (Fri)
by StolenNomenclature (guest, #33445)
[Link]
Posted Oct 24, 2005 17:41 UTC (Mon)
by drag (guest, #31333)
[Link] (6 responses)
Microkernels may not be perfect, but I think that they may win out when it comes to long term management/improvement and ultimately stability. Hell, I bet it doesn't have to replace linux altogether.. I wouldn't be suprised if much of the Linux kernel couldn't end up being stripped out and used in something else. Something like the SCSI subsystem, maybe. Or alsa drivers.
I thought maybe HURD would possibly replace it.. if it ever gets into gear. (have a working enterprise-class kernel alternative aviable for Free/free kinda puts a damper on kernel developement when you have other stuff to work on)
But maybe a minix derivative...
Some of the ideas are very cool. For instance with clustering it would be much easier to impliment a network-wide memory management system I beleive, then with Linux. You can upgrade, and test componates of the system that would require a recompile and reboot with linux, and test out code that would crash linux with code of similar functionality. Drivers wouldn't have to be specific to a kernel version or even kernel. All of that seems pretty attractive.
Posted Oct 24, 2005 22:14 UTC (Mon)
by jd (guest, #26381)
[Link] (5 responses)
The ideal OS is something you can plunk down on a system, where you don't have to care if it's one node or a million, where you don't have to care if memory is uniform or NUMA, and where you don't need to care if you're using multiple cores, SMP or cheesecake. The OS is supposed to hide the underlying physical architecture, so the ideal OS is one that can do this optimally over a distributed, dynamically-shifting topology.
Posted Oct 25, 2005 6:00 UTC (Tue)
by drag (guest, #31333)
[Link] (4 responses)
I am trying to not sound like a dick, but is there actually real Exokernel system's out there? Isn't a Exokernel sort of a Microkernel++?
Now with 'monolythic' kernels-based operating system, we have plenty of those. Many Linux distros, the BSD's, and even OS X and Windows NT-based OSes (w2k, wXP, Vista, NT) are all monolythic systems. (irregardless of what MS and Apple claim in their advertising literature at various times)
These are proven systems and relatively stable and secure when done properly. Everybody uses them.
Then there are actual swear-to-god usefull, very real, and full fledged, Microkernel-based systems outside acadamia and labs. Now I can understand that maybe they aren't the way to go (obviously monolythic systems are much more successful), but they do exist. Namely HURD, and apparently Minix are two that I know of. These are under current development, unlike things like Mach, which died in the mid-1990's. Debian even has a port to HURD, which is suppose to be usefull.
Maybe something like Xen, then? I've used it, I like it. It's very cool and handy. When Xen 3.0 comes out and AMD/Intel releases their systems with extra virtualizing features I am definately going to jump on one of those computers and play around with stuff I didn't previously have resources/machines for. Dragonfly BSD, React OS, NetBSD, Debian GNU/Hurd, Minix, among others.
Would that be considured a 'exokernel' maybe? It's certainly possible to give a hundred users their own 'root' account on a 'DomU' system client on one of those systems, and yet maintain security and stability. Then you'd have one Dom0 system for core services and hardware access. It's possible to migrate DomU (don't know exactly how practical) from Xen host machine to Xen host machine.
Who knows. Maybe it's the future to have simple single user systems hosted on Xen-like hypervisor. A system partitioning/management similar to what IBM has been using on mainframes for years.
Posted Oct 25, 2005 11:44 UTC (Tue)
by job (guest, #670)
[Link] (1 responses)
I don't think virtualization can be regarded as a microkernel. Virtualizing hardware is quite different from providing an API to it the way a (micro)kernel does.
Posted Oct 25, 2005 15:19 UTC (Tue)
by drag (guest, #31333)
[Link]
It uses code from MACH, but it's not realy based on MACH. It's a sort of conglomeration of MACH and BSD code. It's a monolithic kernel by the classic denifitions and MACH isn't realy used for it's microkernel aspects.
The whole microkernel thing is kinda of a advertising thing. As you can understand the concept of the microkernel and advantages in terms of security and stability is very attractive. If somebody was able to create a fast microkernel-based general purpose operating system they would pretty much acheive the holy grail of computer science. Well, maybe not THE holy grail.. but maybe a very special grail. :)
Here is some good technical information on the the XNU kernel:
It's pretty interesting.
Microsoft did the same thing NT. They called 'kernel' a microkernel, but it's about as much as a microkernel as Linux is. There is some message passing aspects with regard to HAL and such, but that's about it, from what I understand. I am no expert on NT though. (and I am no expert as far as OS X goes either).
The current working implimentation of GNU/HURD uses the MACH kernel for the actual microkernel. The 'HURD' part is the unix-replicating services that use the message passing capabilities of the MACH kernel to create a posix-like enviroment to run GNU (and other) software.
However they've found that performance of MACH is lacking with no real way to fix it. It's a kernel that pretty much had the majority of the development end in 1994 and it shows. It's designed for a different sort of computer then we have now.
The L4 kernel is what they are porting Hurd to now. They recently finished very rudementary memory management sceme for it. (from jan of this year)
L4 is a ongoing research project in a few universities with constant progress.
Kinda interesting though that the majority of hardware support for the Hurd/Mach comes from old Linux drivers running in userspace with 'glue' to talk to the other services. Funny stuff.
Posted Oct 25, 2005 20:29 UTC (Tue)
by oak (guest, #2786)
[Link]
Posted Oct 25, 2005 21:47 UTC (Tue)
by ericdujardin (guest, #25277)
[Link]
Eric
Posted Oct 24, 2005 21:11 UTC (Mon)
by litosteel (guest, #33304)
[Link]
Posted Oct 28, 2005 22:36 UTC (Fri)
by StolenNomenclature (guest, #33445)
[Link]
What's un-free about Minix 3, apart from the fact it uses a BSD license?Minix 3 hits the net
I believe it was the old minix license which was non-free...Minix 3 hits the net
A quick search suggests that he switched to the BSD license around 2000.
The license doesn't matter much if you can't find the source code. As it happens, the source is all cleverly hidden away in the Live CD image file, so that the easiest way to get to it is to boot Minix. Sneaky. Presumably somebody will mirror it eventually.Minix 3 hits the net
In fact, they did make finding the source a challenge. You can't even get at it by mounting the CD image. Why make it so hard for potential contributors to dig into the code?
Minix 3 source
Yes, you have to boot from the disc. Probably it's a deliberate way to cut down the noise level: only those willing actually to boot Minix get to see the code (at first). Anybody likely to contribute usefully must already have Qemu (or something).Minix 3 source
Not entirely correct:Minix 3 source
The MINIX 3 source code is included on the CD-ROM image file, but if you want to inspect it while running a different operating system, please click here for a bzip2 compressed tar file."
Ok, it seems that was added from "popular demand" :)Minix 3 source
It wasn't Free at the time Linus started Linux.Minix 3 hits the net
My memory is a little foggy on this but...Minix 3 hits the net
You might as well say that Torvalds would have started to work on the T^wHURD instead of writing Linux. It is evident that the goals, architecture and underlying philosophy of Minix and Linux are different; so maybe Torvalds would have started Linux even if Minix was free (GPL or BSD). After all he had studied with Tanenbaum, and even so he wrote his own kernel disregarding Tanenbaum's principles. So it is not so clear.
Linux was not similar to Minix
Linus has studied with Tanenbaum? With Tanenbaum in Amsterdam and Linus in Helsinki? I think
you're led astray by Tanenbaum saying he'd have given Linus an F if he'd had Linus in
his class -- but he never had, so never gave him his F.
Linux was not similar to Minix
You are right, sorry. Actually I was led astray by this badly remembered quote:
Linux was not similar to Minix
The most important thing I have done is produce a number of incredibly good students, especially Ph.D. students. [...] They have done great things. To the extent that Linus can be counted as my student, I'm proud of him, too.
Linux was not similar to Minix
Linux was not similar to Minix
Is this a hidden side blow against Linus, or a sign of Tanenbaum's hubris [...]?
Well, who knows; surely not the first option, probably none of them. As Landley says below, Torvalds studied Tanenbaum's book. Also, there is this famous exchange. I don't know; someone might consider herself a disciple of Stallman after having read his works, so why not.
Tanenbaum wrote the textbook Linus used to learn about Unix in his first Linux was not similar to Minix
class on the subject. (That's why Linus installed Minix in the first
place.) So Tanenbaum was one of Linus's primary sources, but not directly
one of his professors.
It's detailed at length in Just for Fun...
You might. Linux was not similar to Minix
Linux was not similar to Minix
Only if you ignored the fact that Linus was a Minux user and that Hurd didn't exist then.
Linus was a Minix user, not "Minux". It is confusing enough as it is with all the Unix, Linus, Linux, Minix. And the Hurd did more or less exist at the time, at least officially.
Although, for all practical purposes Linus did infact "work on the Hurd".
What do you mean? The Hurd is not even similar in principle, operation or license to Linux.
Linux was not similar to Minix
Although, for all practical purposes Linus did infact "work on the Hurd".
What do you mean? The Hurd is not even similar in principle, operation or license to Linux.
> And the Hurd did more or less exist at the time, at least officially. Linux was not similar to the Hurd
Your link has a timeline with the Hurd *announced* in May 1991 ("the FSF
is beginning work...") and could run gcc in September 1994. Linus began
work on Linux around exactly the same time (first recorded mention,
definitely not an announcement, was in July 1991) and already had gcc
running on it by the time it was announced on the 25th of August. By
version 0.11 (19th December) Linux was 'self-hosting' in the sense that
you didn't need another OS running to be able to install the system
and build and boot a kernel.
But read those first announcements and 'calls for volunteers' on the
Hurd. A keen-but-clueless newbie like Linus offerering his work would
have been slapped away like a flea! "You need to have an iron-clad grasp
of Unix semantics ... It's not enough that you've programmed Unix before;
you need to understand all the nits." ... bah humbug.
It used to be licensed only to people who purchased the printed text book and there were no rights granted to create derivatives or redistribute. It was clear that the author intended it primarily for its pedagogic value.Non-Free
This is interesting:
Minix 3 hits the net
A reincarnation server automatically kills and replaces faulty device drivers on the fly
http://www.minix3.org/improvements.html
Interesting, indeed.Minix 3 hits the net
- the faulty driver totally locks up the PCI bus
- the faulty driver DMAs over kernel memory
- the faulty driver is in some way needed to let the reincarnation server function
- the faulty driver is too faulty to be able to reset the device enough to make it function again
- ...
Most of those failure modes are usually more indicative of faulty hardware than a faulty driver. In all the drivers I've worked with, accidentally building a bad scatter/gather list for DMA, for example, is pretty unlikely. Usually fatal driver bugs either (a) access a bad location in memory (buffer overflow, dereferencing NULL, etc) or (b) get their internal state out-of-sync with the state of the hardware. I believe damage caused by (a) is contained because Minix runs drivers in their own address space, and (b) can almost always be fixed by resetting the device and reloading the driver.Minix 3 hits the net
I'm not talking about faulty hardware here: I think a larger proportion of the errors in device drivers are because of the mismatch between the specification (if any) and the actual way the hardware works. For example, brand new machines nearly always fail booting a default distro because of some new ACPI incompatibility ; Minix containments is not going to help in this common (for me, at least) case.Minix 3 hits the net
Faulty drivers bring monolithic kernels more easily down than microkernels, of course. But I think this results in overall better quality of the (used) monolithic kernel's drivers. That's because for the driver to be useful, its severe bugs have to be fixed and the bugs just expose themselves in a more severe ways in monolithic kernels. I can easily imagine a buggy driver used in microkernel, which just degrades the performance due to driver's restarts every now and then while the same driver would just be fixed in monolithic kernel.Minix 3 hits the net
No can do.
- the faulty driver DMAs over kernel memory
I believe that's impossible, by design. From the Minix 3
front page:
For example, each device driver runs as a separate user-mode
process so a bug in a driver [...] cannot bring down the entire OS.
Thus, the driver can't get to kernel memory, by virtue of
the MMU.
I would hope that, similarly, the PCI driver is insulated,
validating its input thoroughly. Of course, the PCI driver is
quite capable of hosing the PCI bus, but there's not much you can
do about that. :-)
Faulty drivers bring monolithic kernels more easily down [....]
But I think this results in overall better quality
[because] its severe bugs have to be fixed and the bugs
just expose themselves in a more severe ways [....]
The problem is that there is no way, on x86-style hardware, to prevent a driver from DMAing anywhere it pleases. There is no I/O MMU on the planet's most popular computing platform. If you let the driver DMA, it will have the run of the system's memory.
Yes can do, unfortunately
I hadn't looked at the x86 architecture closely enough to realize that. Thanks.
OUCH!
This is interesting:
A reincarnation server automatically kills and replaces faulty device drivers on the fly
In what sense replace? Is the driver memory image meant to have been corrupted and must be refreshed?
What about the state information? If for example a disk driver had queued commands to a device, then crashes, restoring the actual driver does what? The previous partially completed requests are now lost. This also applies to any state info stored in the client of the driver, which is now out of sync with the newly refreshed driver.
To fully recover (e.g. complete transparency to the user) would surely require a very sophisticated and/or time consuming process (regular snapshots of local variables)?
Any comments?
Minix 3 hits the net
Personally I'd love to see a replacement, a improvement in something over the Linux kernel. I mean it can't go on forever.Minix 3 hits the net
http://www.gnu.org/software/hurd/hurd.html
Microkernels split things too much between kernel-space and user-space, leading to massive communications overheads. An "exokernel" (where the bulk of the work is done in userspace and only things absolutely needing kernel authority are in kernel space) would seem to make more sense. Better yet, these days where clusters are becoming more common, it would make sense to borrow ideas from Plan9 on distributing resources and various clustering technologies on distributing code and data.
Minix 3 hits the net
I suppose so.Minix 3 hits the net
I think Mac OS X is based on a microkernel since it is a BSD-like UNIX running on Mach, which apparently isn't quite dead after all. There is also L4 which is quite alive in the research community and a promising target for the HURD.Minix 3 hits the net
The kernel that OS X uses is called XNU.Minix 3 hits the net
http://www.kernelthread.com/mac/osx/arch_xnu.html
http://kerneltrap.org/node/4580/print
http://os.inf.tu-dresden.de/L4/
The nanokernels like Adeos sound quite interesting too. Minix 3 hits the net
Btw. I think embedded devices have used microkernels for quite a long
time, because there were no resources to run something like Linux. These
kernels were hard real-time and I guess many of them lacked POSIX support
(it was available e.g. for QNX though).
Another classical example of a microkernel-based OS is Chorus. You can Minix 3 hits the net
actually download it from sf.net/jaluna.
It experienced the same as others: message passing between subsystems and
the microkernel kills performance. In the end, ChorusOS became a huge
subsystem on top of the microkernel. Par of the reason relies in the
Posix semantics which require close ties between subsystems (e.g., process
management and I/Os).
Very good information... Minix 3 hits the net
But minix.org is "Service Temporarily Unavailable" down...
Do you know something about it??
Bye.. everyone... My First post ever he he...
I still wonder how useful this very course grained protection mechanism actually is. Due to IPC between processes in separate memory spaces being very slow, there is a limit to how fine grained the protection can be - it would be impracticable for example to have individual C functions of a driver to be in separate memory spaces.Minix 3 hits the net
This protection is also confined to the overwriting of adjacent memory spaces fo other tasks/processes, but many bugs do not fall into this category. A faulty disk driver may not directly effect the kernel memory space (DMA not withstanding), but if a disk driver becomes unuseable for any other reason, the operating system is essentially disabled anyhow.
There is no real susbstitute for elimination of bugs, especially in low level drivers. The Microkernel approach may help in that it is supposed to help the debugging process, but I am still not convinced that the advantages are real rather than imagined.
Has anyone looked at the BRIX op sys? This depends on using a safe language with fine grained memory protection built in. This will of course add a substantial performance hit, but the memory protection is optional and can be omitted from proven software such as drivers that have demonstrated their reliability. This might be the best combination, although the protection mechanism is present only in the Lisp like language supplied.