Domain: minix3.org
Stories and comments across the archive that link to minix3.org.
Comments · 91
-
Android on Minix?
-
Re:Wait a second...
Minix did get an reputation of being unstable some 20 years ago, but of course - much have happened since then.
The one thing that hasn't changed though is that Minix is still just a toy system that's meant to be poked at in schools and that nobody actually uses (yes I know about the 3 rabid Minix users, they probably run AmigaOS too).
Oh, wait, now it finally supports X11 (woohoo !). Wait, has it got a mouse driver too ?However Minix3 *does* feature support for "Over 650 UNIX programs" (such as man, mkdir and ps). *650* ! It's like 130 × 5 ! Think about it !
Granted, starting from a small scale system such as Minix is certainly simpler than with a much more mainstream OS such as one of the BSDs or Linux but even if anything comes out of the project, it won't ever gain even "niche" status. More people must be running Plan9 or Inferno.
The whole idea is utterly futile, except possibly if the code or the concepts can be reused with another system later on. -
Screenshot
http://www.minix3.org/doc/screenies.html Screenshots
-
Even more misleading
...is to call this news. The grant was received in November 2008! (see http://www.minix3.org/news/)
-
Switch to an OS (and CPU) without Virtual Memory?
Well you could always switch to an operating system that doesn't use virtual memory. Check out http://www.minix3.org./ Sure they might add virtual memory eventually but in the meantime you'd have a system without it.
You'd also have to use a processor chip that doesn't use virtual memory look ups. The extra hardware used to look up virtual addresses and map them to either physical or virtual (page file) pages requires a lot of extra clock cycles on each instruction the processor executes that involves loading or storing to or from memory addresses. We're talking a lot of extra cycles even for pages that are in physical memory.
Many micro-controllers don't use virtual memory. They also have the benefit of being dirt cheap compared to Intel's and AMD's behemoths. They also consume much less power. Check out this computer: http://www.makezine/controller.
-
Re:But still...
Minix is open source and has been for a while. Maybe it cost money 17 years ago, but not anymore.
-
Re:In fairness to software engineering
Yeah, minix3 but it's not production status yet
... so you're probably stuck with VXworks. -
Minix 3 is under a BSD-esque license
Minix 3 has a BSD style license so it does not preclude looking and using the source. Versions released prior to 2000 were under a more restrictive license (personal copying only, no redistribution with your changes already merged in, non-commercial use and so on).
I would not consider Singularity to be under an Open Source license myself though. It is more in the vain of pre-2000 Minix (educational/academic use). However the technology in it is interesting and Google's Mike Hearn has a good series of blog entires giving an overview of the ideas within Singularity. -
Re:Infrastructure
Slashdot runs on a 386SX/16 clone with 4 megs of RAM and an 80MB hard drive. It runs under Minix 3.0.
-
Re:Microkernel? WTF?!I know that you are being funny but if you want to work on a FOSS microkernel system take a look at this.
It looks very interesting to me.
-
Re:What is the platform?
we want a lean c one...
Dr Tanenbaum, please come back.. all is forgiven :-) -
Re:That's why microkernels are useful
Mod Parent Up.
Even Microsoft Research is looking into making microkernel operating systems with their Singularity project.
Of course, the Minix 3 Project has been doing this for awhile, supposedly even having a fully POSIX compliant product at this point.
The major design factor of Microkernels is that it's bad practice to have a trusted path from any driver or system service in kernelspace to any other driver or system service in kernelspace. Just because you're "in" doesn't mean that anything else that's "in" should trust you.
The largest hurdle microkernels have to overcome, however, is the problem of DMA. As long as a malicious ATI video card (nevermind the driver) has direct access to all memory locations via DMA, it could easily just patch the driver's memory at runtime every time via hardware. That's why microkernel development is going to have to go hand-in-hand with tools like IOMMU, for controlling access to critical areas of memory.
Of course, critics often complain about Inter-process Communication (IPC) as being another limitation to microkernels, but at this point, it's really just an implementation hurdle as there are several ways to get processes that are in different memory spaces to communicate with high performance, especially as Moore's Law brings CPUs faster and faster. -
Re:Oh please...
How'd you want to create the "perfect" AV product?
Well, for starters, let's limit the attack surface significantly by blocking all executable code that is not on the guestlist (think "whitelist" or "default deny"). We'll certify apps we want on our systems and block everything else. That's the only way we can effectively eliminate all of the grayware and stop today's typical new virus variant (which, although not technically a zero-day, is similar in nature to the sysadmins since the AV signatures have to play catch up). An interesting by-product is increased adherence to strict change control practices. [Does the rate of new application adoption in your org have a curve like this?]
Second, let's have an OS that can separate data objects from executable objects in memory, thus preventing code insertion (buffer overruns). Not an optional kernel memory management function (nX), but a true requirement for all applications compiled to run on the platform.
Third, let's leave users in least privilege mode, so system-level malware is not possible. Again, the interesting by-product is better change control.
Fourth, let's use mandatory integrity levels (or something similar) to ensure that one application does not automatically affect other user-level data. This will prevent the threats that will happen as soon as the other 99% of sysadmins figure out the least privilege concept for their users-- malware will turn to exploiting userland processes and data.
Fifth, let's have applications (i.e. browsers) that follow the same principles the OS does and separate dynamic code objects from data objects as well as not allowing executable code from source A to run as if from source B (think XSS). While we're at it, make sure the applications are designed to not confuse data objects as executable code (think input sanitization).
Sixth, let's make sure the whole process from hardware init to boot up to userland apps is trustworthy. That probably means something along the lines of TPMs, and nixing the possibility of device drivers overwriting memory via DMA (think IOMMU or similar). [Why hasn't it been seen as a bad thing that your USB keyboard driver, regardless of whether it runs in kernel space, can overwrite kernel memory via DMA?]
Where does that leave us? Oh yeah ... that combination does not exist on any platform yet!!! My thought on the religious wars debate (which inevitably pops up whenever the topic of malware comes up): they all suck! Maybe MINIX with IOMMU has a chance (also not available today). -
Re:Let The Flamewars Begin
Andy Tanenbaum was too busy releasing Minix 3.13.a to reply.
-
Not yet for enterprises
I work for a company that has, as I understand it, the single largest install base of Macs at least in North America. And no, it's not Pixar or something similar. It's a greeting card company.
I once competed fruitlessly in the OS religious wars. Now I'm agnostic (except that I think all monolithic kernel OSes are destined for replacement by Microkernels, such as the academic effort: Minix). But there's one thing that tells me this won't fly quite like predicted: There's limited Enterprise support.
In the MS world, we have tools like SMS for automated application deployment. In the Mac word, AFAIK, there are no such tools (or they suck by comparison). We actually wrote our own, using SSH, FTP, and scripts. But that means we have to have the support of our own mass-deployed tool as well. It's such a shame that Apple hasn't built a similar tool (or bought ours from us and then licensed it).
~ -
Java is fine for emulation
[1995] When I was at university on Java 1.0, we were taught operating systems on emulated Minix. It was fine then, no reason x86 won't be fine now.
Just give this project time. Everybody is queuing up to knock it down, but it should be fine. They're not planning to put Vista on it, just emulate some DOS data entry applications. -
Re:VMs
I think id Games used to compile on SGIs. I know MS did some development on Xenix/i286 and Xenix/i386 (somewhere, there's an MS quote about how MS-DOS/Win is not suitable for serious development..hah). In fact, the i286 had a memory management unit, but the only OS (that I know of) which took full advantage of it was Xenix. Minix/i286 may have supported it to some extent, as well.
Some emulator pages....mac&ppc, simos (for SGI/IRIX5), DEC 10 and Big Iron, various DEC emulation, Apple Lisa, Z80 sim&development, yaze Z80, Apricot and Amstrad, bochs x86, ... and there's always emulators that run under DOS that you could run under Bochs or QEMU.
Other possibly helpful links:
emulators on freshmeat
OS kernels on freshmeat
OS's on freshmeat
bunches of old OS disk images
CP/M and MP/M
CP/M disks
Lisa Xenix
LisaOS
tandy xenix
elks and uclinux
freevms
freedos
Apple I (not II) development
reactos - winnt clone
MAME stuff and pinball Mame
info about tandy disk images
solaris minix
minix info and version 3
various free (as in beer and/or speech) OS list
The OS list at tunes.org -
Solution can be found here:
You can find a solution(s) to your problem at one or more
of the following locations:
http://www.centos.org
http://fedoraproject.org/wiki/
http://en.opensuse.org
http://www.opensolaris.org/
http://www.ecomstation.com/
http://www.redhat.com
http://www.reactos.org/en/index.html
http://www.debian.org/ports/hurd/
http://www.openbsd.org/
http://www.freebsd.org/
http://www.netbsd.org/
http://www.dragonflybsd.org/
http://www.osfree.org/doku/en:start
http://www.skyos.org/
http://www.freeos.com/
http://www.minix3.org/
Added to bypass the stupid slashdot lameness filter which apparently doesn't like a post full of links. WTF is wrong with the
stupid lameness filter? Jeez, what does it want, for us to type paragraphs of meaningless drivel just to get past the lameness filter?
Sheeesh. OK, this is really stupid. Why don't ajfajf al;djal a fa fa lkdf jaa fal ja;ljf af af ajf;lajf alfjalf a fjal;fjafl; jaflakjf af;laj
jalkfaj fjf af af fajjjajal jajfa f afjdlakej2233 2235t2352 dsfalkfjal f 222j2 afdkja f23 2 2 2t2352322 233252352 2323232. -
Re:It Never Did
I'm very picky (i.e. a perfectionist), and I've found something wrong with every language I've tried. That's why I'm working on a language of my own (Mana), but progress is slow, as I'd rather take a few extra years and have a better result than rush things out the door.
I get a lot of pleasure out of programming in Ruby. It has a few quirks, but the big problem is that implementations are so slow. Maybe with Ruby 2.0 this will all be better. At any rate, a lot of the software I use on an everyday basis (especially for email) is written in Ruby (by me).
OCaml is a language I could actually write an operating system in. It's closest to ideal of all languages I've found. A friend of mine was actually writing some code to allow drivers for Minix 3 to be written in OCaml. I would have gladly written some drivers afterwards; unfortunately, he abandoned the project.
I'm also a big fan of Common Lisp. People complain about its parentheses, but once you get over that, it's a very powerful language, and, better yet, you can easily extend and adapt it. There actually is an OS being written in Common Lisp: Movitz. -
L4 deserves some attention
-
Re:This debate will never be over......until someone makes a microkernel unix system that's more than just a proof of concept.
you mean like Tanenbaum (slashdotted, try later) did?
FTFA:
So **PLEASE** no more comments like "If Tanenbaum thinks microkernels are so great, why doesn't he write an OS based on one?" He did.
i don't reall know what you mean by proof of concept
again, FTFA:
It is definitely not as complete or mature as Linux or BSD yet, but it clearly demonstrates that implementing a reliable, self-healing, multiserver UNIX clone in user space based on a small, easy-to-understand microkernel is doable. Don't confuse lack of maturity (we've only been at it for a bit over a year with three people) with issues relating to microkernels.
i know this is slashdot, and RTFA is some kind of mortal sin, but please at least try.
-
Re:Minix is already on version 3
Unless Minix finds an easy way to port Linux drivers, it won't go further on the desktop than BSD.
I'm thinking that's a ways down the road. If Minix could at least be viable for embedding into smaller, pre-configured devices, it could garner a lot more support in the device-driver arena.
And it won't even get as far as BSD unless it has a BSD-like license.
Sorry? Minix3 is distributed under the BSD license.
Any word on a Xen compatibility?
Apparently it's up and running. :-) -
Minix 3 screenshots
I almost died of boredom looking for them. Here's the link, for the lazy:
http://www.minix3.org/doc/screenies.html -
Re:Get busy
-
Re:Theory Vs. Practice
-
Re:Eh hem.
No, it's compartmentalization of the applications. Besides, the analogy is really bad because a ship with a blown compartment is quite useful. Computers with a blown network driver will e.g. break any network connections going on, in other words a massive failure. What about a hard disk controller which crashes while data is being written? Drivers should not crash, period. Trying to make a system that could survive driver failure will just lead to kernel bloat with recovery code.
Easy. Minix (the OS that Tanenbaum created) uses a reincarnation server that restarts any drivers that crash. All drivers are run in userspace, so if one crashes then the kernel isn't brought down with it (yes, even the file system driver). Then you can debug all you want.
Yes, it would be nice if drivers never failed. Better yet, why don't we all just agree to make all of our programs fault-free? Not going to happen, at least not when written in C/C++. The best you can hope for is to reload the driver without compromising the rest of the system, which is what Minix's reincarnation accomplishes.
The reason Tanenbaum advocates this stuff is because it can work if designed correctly. Again, see Minix.
-
Re:Oh Dear
-
Re:Oh Dear
Spouting or not, at least he's doing something. Minix3 (the end point he gets to in the article) is a BSD licensed OS that implements the concepts he discussed. I think it's time to get out the ole' performance metrics and see if much has changed in 20 years.
-
Minix3
A paper might show the concept but only a real working sample will provide answers. Just wait until Minix3 (http://www.minix3.org/) is finished and then lets see if it's slower or not and if it's saver or not.
O. Wyss -
If it's too big, try something else
Excerpt from http://www.minix3.org/
MINIX 3 is initially targeted at the following areas:
* Applications where very high reliability is required
* Single-chip, small-RAM, low-power, $100 laptops for Third-World children
* Embedded systems (e.g., cameras, DVD recorders, cell phones)
* Applications where the GPL is too restrictive (MINIX 3 uses a BSD-type license)
* Education (e.g., operating systems courses at universities) -
Re:the "pet rock" of programming languages
>It smells more of an abandonware goodwill gesture than anything.
I have no doubt that you're right; but I have to ask...so what? You make it sound as if this is a bad thing; I'd like to know what you'd have preffered.
By releasing this to the public in this manner, Eiffel has a chance to stay alive and to be adopted by a community which will use and enhance it. Mind you, I can relate to your attitude of "what a kiss off, who cares?". That is exactly how I felt about the open-sourceing of minix years back. I remember Tannenbaum's release, which essentially said "uh, here; have my teaching guide. do stuff with it, I dunno, maybe add it to a watch of something, I don't care". I figured "ok, minix is crap, and now it will go right down the toilet". For a long time, my attidue seemed to be vindicated -minix didn't do much (the compiler was opened, and the newsgroup got a few posts).
Now? I think it was last october that Minix 3 was released. By being opened, Minix found an appreciative audience and had a chance to grow and develop. Obviously had it just been forgotten and kept proprietary this would not have occured.
After what's happened with Minix, and looking at Eiffel; I'd say instead of griping and saying "so what" let's wait and see if something interesting doesn't eventually develop out of this. -
Re:Well DUHYou could make it a microkernel, and put all the device drivers outside of this, with very restricted and controlled functionality:
see: http://www.minix3.org/reliability.htmThere's other stuff out there, like eternal loop-catching etc. I just bounced into this a few days ago, and it looks interesting.
-
Re:When will WGA support Mac OS X?
Are you the real Andrew Tanenbaum, the Minix dude!?!? Checking your replies you seem NOTHING like him, I have read a few of his books, I know his style of writing, and your sir is not his.
Please can you show some respect and don't use the name of a respected person and degrade him, its low lives like you that make good peoples lives hard.
Shame on you. -
Re:44 pages and the main question is still unanswe
http://www.minix3.org/
Surprised it wasn't even mentioned yet. -
Minix 3, microkernels, QNX, VM, and all thatThe most useful observation about microkernels is that the commercial ones work fine, but the academic ones are lousy.
QNX and IBM's VM are the most successful microkernel systems, with tens of thousands of installations and a user base generally happy with their performance.
From the academic world, we have Minix, Mach, EROS, L4, and the Hurd. None of which are very successful. (MacOS X is not based on the microkernel version of Mach; it's based on an earlier version which is basically BSD.)
It's worth reading Jorrit Herder's Minix 3 thesis. This is the guy who wrote the thing. He basically took Minix 2, yanked out all the drivers, and kept adding system calls until they could work outside the kernel. The result is on the ugly side, compared to QNX and VM. He really hasn't thought through the problems of doing device drivers in user space. The supported devices are archaic, like Centronics printers and TTY ports. In particular, no modern I/O (USB, FireWire, etc.) seems to be supported. Those are the ones where a microkernel fits well, because you have a channel driver, which talks to host hardware directly, and device drivers, which need very few privileges. But Minix isn't there yet. Actually, you'd be better off starting with the modern peripherals, especially since the OHCI and UHCI interfaces are well standardized. They also force you to think hard about how startup and shutdown should work, since you have to handle hot plugging. The design works out much better if you treat hot-plugging as the normal case and fixed peripherals as a special case of hot-plugging.
I've written FireWire and USB device drivers for QNX. I've also written UNIX drivers. So I do know what I'm talking about here. It's really much easier under QNX in user space, and the architecture is far cleaner.
The key to microkernel design is getting scheduling and interprocess communication absolutely right. Get scheduling order, scheduling/messaging interaction, scheduling/cache interaction, or interrupt lockout time wrong, and your microkernel will be useless. None of this shows at the API level, yet it's crucial. It's almost impossible to fix this later. It's not clear from the Minix documention how well messaging was done, or how it interacts with scheduling.
Sadly, security seems to have been neglected. Minix 3 still has "root". It doesn't have the security functions of NSA Secure Linux, and it doesn't have an approach to messaging which deals well with security. Retrofitting security is tough and usually fails, Look at the mess in Windows. NT/2000/XP actually have a decent security system, but it's not used, because Windows 3.x/95/98/ME didn't have it, and XP had to be "compatible".
It's a beginning. But probably too late.
-
Re:So what OS are www.minix.org and minix3 running
Well that'll teach me to "save time" by not previewing.
craig@master ~ $ curl -s -I http://www.minix.org/|head -n 3
HTTP/1.1 200 OK
Date: Mon, 24 Oct 2005 23:32:32 GMT
Server: Apache-AdvancedExtranetServer/2.0.47 (Mandrake Linux/4mdk) mod_perl/1.99_09 Perl/v5.8.0 mod_ssl/2.0.47 OpenSSL/0.9.7b PHP/4.3.2
Interesting.
craig@master ~ $ curl -s -I http://www.minix3.org/|head -n 3
HTTP/1.1 200 OK
Date: Mon, 24 Oct 2005 23:33:29 GMT
Server: Apache/1.3.26 (Unix) PHP/4.4.0 mod_ssl/2.8.10 OpenSSL/0.9.6c
Pah!
craig@master ~ $ sudo nmap -P0 -v -v -v -n -TPolite -O www.minix3.org
[wait] ...
Device type: general purpose
Running: Linux 2.4.X|2.5.X|2.6.X
OS details: Linux 2.4.18 - 2.6.11 ...
I guess nobody's ported apache to minix yet... -
So what OS are www.minix.org and minix3 running?
craig@master ~ $ curl -s -I http://www.minix.org/|head -n 3 HTTP/1.1 200 OK Date: Mon, 24 Oct 2005 23:32:32 GMT Server: Apache-AdvancedExtranetServer/2.0.47 (Mandrake Linux/4mdk) mod_perl/1.99_09 Perl/v5.8.0 mod_ssl/2.0.47 OpenSSL/0.9.7b PHP/4.3.2 Interesting. craig@master ~ $ curl -s -I http://www.minix3.org/|head -n 3 HTTP/1.1 200 OK Date: Mon, 24 Oct 2005 23:33:29 GMT Server: Apache/1.3.26 (Unix) PHP/4.4.0 mod_ssl/2.8.10 OpenSSL/0.9.6c Pah! craig@master ~ $ sudo nmap -P0 -v -v -v -n -TPolite -O www.minix3.org [wait]
... Device type: general purpose Running: Linux 2.4.X|2.5.X|2.6.X OS details: Linux 2.4.18 - 2.6.11 ... I guess nobody's ported apache to minix yet... -
407, page currently slashdotted
http://www.minix3.org/index.html seems to be down
:( I think a message like "407" or "403.5 - Page slashdotted" would be better. -
Minix is from the future
Check http://www.minix3.org/license.html:
Copyright (c) 1987,1997, 2006 , Vrije Universiteit, Amsterdam,
indeed the future of OS. -
VMware image. Was :live-CD
Not only that, there is also a VMware image!
-
live-CD
And you can try it out on your current PC - the download is a live-cd!