| |||||||||||||
|
| |||||||||||||
Minix 3 hits the net
Andrew Tanenbaum's Minix system was, among other things, the
source-available (if not entirely free) operating system which got Linus
Torvalds going. Minix has been somewhat overshadowed by Linux, but it is
far from gone. Back in June, Mr. Tanenbaum announced that he was working on a
Minix 3. The results of that work are now available from minix3.org. It is a small, microkernel
system which is aimed simultaneously at education and the embedded systems
market. It is released under the BSD license, and there is, of course, an
associated book in the works. (Thanks to Guillaume
Pierre).
(Log in to post comments)
Minix 3 hits the net Posted Oct 24, 2005 14:57 UTC (Mon) by thomask (guest, #17985) [Link] What's un-free about Minix 3, apart from the fact it uses a BSD license?
Minix 3 hits the net Posted Oct 24, 2005 15:02 UTC (Mon) by hawk (subscriber, #3195) [Link] I believe it was the old minix license which was non-free...A quick search suggests that he switched to the BSD license around 2000.
Minix 3 hits the net Posted Oct 25, 2005 0:37 UTC (Tue) by ncm (subscriber, #165) [Link] 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 source Posted Oct 25, 2005 1:40 UTC (Tue) by corbet (editor, #1) [Link] 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 Posted Oct 25, 2005 21:12 UTC (Tue) by ncm (subscriber, #165) [Link] 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 Posted Oct 30, 2005 17:13 UTC (Sun) by Los__D (subscriber, #15263) [Link] Not entirely correct:
Under the "Source code" tab:
"MINIX 3 Source availability
Dennis
Minix 3 source Posted Oct 30, 2005 17:22 UTC (Sun) by Los__D (subscriber, #15263) [Link] Ok, it seems that was added from "popular demand" :)
Minix 3 hits the net Posted Oct 24, 2005 15:03 UTC (Mon) by rmini (subscriber, #4991) [Link] It wasn't Free at the time Linus started Linux.
Minix 3 hits the net Posted Oct 24, 2005 15:26 UTC (Mon) by dowdle (subscriber, #659) [Link] My memory is a little foggy on this but...
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!
Linux was not similar to Minix Posted Oct 24, 2005 16:06 UTC (Mon) by man_ls (subscriber, #15091) [Link] 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 Posted Oct 24, 2005 16:11 UTC (Mon) by boudewijn (subscriber, #14185) [Link] 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 Posted Oct 24, 2005 17:23 UTC (Mon) by man_ls (subscriber, #15091) [Link] You are right, sorry. Actually I was led astray by this badly remembered quote: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 Posted Oct 25, 2005 18:41 UTC (Tue) by arcticwolf (guest, #8341) [Link]
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)?
Linux was not similar to Minix Posted Oct 25, 2005 21:16 UTC (Tue) by man_ls (subscriber, #15091) [Link] 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.
Linux was not similar to Minix Posted Oct 25, 2005 3:15 UTC (Tue) by landley (guest, #6789) [Link] Tanenbaum wrote the textbook Linus used to learn about Unix in his firstclass 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...
Linux was not similar to Minix Posted Oct 24, 2005 16:21 UTC (Mon) by jedidiah (guest, #20319) [Link] You might.
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".
Linux was not similar to Minix Posted Oct 24, 2005 17:44 UTC (Mon) by man_ls (subscriber, #15091) [Link] 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 Posted Oct 24, 2005 20:09 UTC (Mon) by larryr (guest, #4030) [Link] 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. 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
Linux was not similar to the Hurd Posted Oct 25, 2005 7:48 UTC (Tue) by xoddam (subscriber, #2322) [Link] > And the Hurd did more or less exist at the time, at least officially.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.
Non-Free Posted Oct 24, 2005 15:56 UTC (Mon) by AnswerGuy (guest, #1256) [Link] 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.
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
Minix 3 hits the net Posted Oct 24, 2005 15:35 UTC (Mon) by tjc (guest, #137) [Link] This is interesting:A reincarnation server automatically kills and replaces faulty device drivers on the flyhttp://www.minix3.org/improvements.html
Minix 3 hits the net Posted Oct 24, 2005 16:16 UTC (Mon) by eludias (subscriber, #4058) [Link] Interesting, indeed.
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...).
Minix 3 hits the net Posted Oct 24, 2005 17:41 UTC (Mon) by lutchann (subscriber, #8872) [Link] 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.
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.
Minix 3 hits the net Posted Oct 24, 2005 21:39 UTC (Mon) by eludias (subscriber, #4058) [Link] 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.
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).
Minix 3 hits the net Posted Oct 25, 2005 20:47 UTC (Tue) by tyhik (subscriber, #14747) [Link] 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.
No can do. Posted Oct 27, 2005 19:50 UTC (Thu) by Max.Hyre (subscriber, #1054) [Link] - the faulty driver DMAs over kernel memoryI 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. :-) tyhik points out above: 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 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.
Yes can do, unfortunately Posted Oct 27, 2005 20:43 UTC (Thu) by corbet (editor, #1) [Link] 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.
OUCH! Posted Oct 27, 2005 23:21 UTC (Thu) by Max.Hyre (subscriber, #1054) [Link] I hadn't looked at the x86 architecture closely enough to realize that. Thanks.
Minix 3 hits the net Posted Oct 28, 2005 22:14 UTC (Fri) by StolenNomenclature (guest, #33445) [Link] 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 Posted Oct 24, 2005 17:41 UTC (Mon) by drag (subscriber, #31333) [Link] Personally I'd love to see a replacement, a improvement in something over the Linux kernel. I mean it can't go on forever.
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.
Minix 3 hits the net Posted Oct 24, 2005 22:14 UTC (Mon) by jd (guest, #26381) [Link] 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.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.
Minix 3 hits the net Posted Oct 25, 2005 6:00 UTC (Tue) by drag (subscriber, #31333) [Link] I suppose so.
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.
Minix 3 hits the net Posted Oct 25, 2005 11:44 UTC (Tue) by job (subscriber, #670) [Link] 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.
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.
Minix 3 hits the net Posted Oct 25, 2005 15:19 UTC (Tue) by drag (subscriber, #31333) [Link] The kernel that OS X uses is called XNU.
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.
Minix 3 hits the net Posted Oct 25, 2005 20:29 UTC (Tue) by oak (guest, #2786) [Link] The nanokernels like Adeos sound quite interesting too.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).
Minix 3 hits the net Posted Oct 25, 2005 21:47 UTC (Tue) by ericdujardin (guest, #25277) [Link] Another classical example of a microkernel-based OS is Chorus. You canactually 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).
Eric
Minix 3 hits the net Posted Oct 24, 2005 21:11 UTC (Mon) by litosteel (guest, #33304) [Link] Very good information...But minix.org is "Service Temporarily Unavailable" down... Do you know something about it?? Bye.. everyone... My First post ever he he...
Minix 3 hits the net Posted Oct 28, 2005 22:36 UTC (Fri) by StolenNomenclature (guest, #33445) [Link] 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.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.
|
|
||||||||||||