Submitted by MINIX is a modern, microkernel-based UNIX implementation. The code size of the microkernel is just 129 kB. Servers implement UNIX on top of it. The userland, toolchain, packages etc. are from NetBSD. Release 3.3.0 was just announced:
New features:
- The first release with ARM support, three Beagle targets are supported
- Experimental USB support for the Beaglebones (hubs & mass storage)
- Cross-compiling for both ARM and x86 – the buildsystem is very portable
Improvements
- Big source code cleanup – cleaner C types in messages, improved NetBSD compatibility, all minix-specific code moved to a top-level minix/ folder
- Updated packages overall – a big set is built now; and they are dynamically linked now
- Improved driver modularity
Now that there is an ARM port — and they have gone through the process of porting to another architecture — I would love to see a port to MIPS.
I think Minix would make a great OS for the various MIPS based routers out there that run DD-WRT or OpenWrt right now — mostly with Atheros or MediaTek SoCs in them. Both architectures are MIPS based.
I began and abandoned an attempt to do the port once but that was before the ARM port was done, and I had to try and do too many things for my port.
Now if I can only find enough time, I would love try again at making the port. Sadly time is not what I have an excess of at the moment…
I can’t see myself calling a kernel that doesn’t fit in a PDP11 address space “micro”.
I can’t find a good source but it looks like that number does not include drivers but maybe it does include the NetBSD compatibility “services”?
Surely the alleged 4000 lines of standalone C code don’t compile to a 200kb binary.
Still, evil monolithic UNIXv7 was essentially modern UNIX and included drivers for many devices and only took 40kb of .text 200kb total in memory.
Does anybody know the real breakdown for Minix?
Go back and re-read the summary. The source code is over 100kB, not the resulting binary. Also, the under 4,000 lines of code statistic is for the microkernel, just the microkernel. Not the drivers, services and such on top of it, just the part of MINIX that runs in kernel space.
The summary only says “code size”. It doesn’t say whether this is the size of the source code or the compiled code. Nor does it quote any source for this number.
Looks like it grew to 12,700 lines: http://www.minix3.org/330.html
So not so tiny anymore.
Note that despite the small kernel code size, the minimum required ram is 32MBytes (down from 64MB for the older revision). This is not a replacement for something like Contiki.
The term “micro-kernel” does not, and has never, referred to the actual footprint of the kernel. It’s purely an architectural term. You can have very small monolithic kernels, and very large micro kernels.
With this NetBSD “trick” it starts to get useful in a hurry. So bare X11 isn’t pretty, but every window manager should be portable now.
Boots fine on my box, small and fast.
This NetBSD compatibility is exactly what Haiku should’ve done, but they seem to be increasingly happy with irrelevance (2 years since last release ffs…)
Last nightly was in June, so no. Last formal release was Alpha. Nightly / Alpha, neither is production ready.
No. And the fact that you think so shows that Haiku is not for you.
How does that make sense?
“2 years since last release”
No, 2 years since last “formal” release. If you really cared that much, there have been more recent builds.
As it is now it isn’t for anybody.
Exactly
I used BeOS exclusively back in the day. I owned a BeBox. I ran BeOS on PowerPC hardware (Mac/BeBox.) I ran BeOS on Intel too for a bit. I still have R4.5, R5.0 and most of the Zeta releases (I got a free copy then paid minimum to Mensys for an update at each release.) I cut code. I have the BeBook, Advanced Topics, Be File Sysytem and BeOS Bible in actual physical form, and had a whole slew of older docs, manuals, releases etc till I offloaded my BeBox. I owned a Dt300 and coded for BeIA and actually understood how to build real BeIA Images (rather than the hacked ones that floated around back in the day.) You get me? I know BeOS, I loved it and I still get the urge to use it fleetingly. I say all of this because the context is important.
You’ve made your opinion abundantly clear, and I understand your “pain”. But please stop regurgitating the same rhetoric; I think we understand your position. If you really do feel that badly about Haiku, BeOS is no longer viable, and Haiku isn’t for you. Don’t trip on the way out. Have a happy life – don’t hold on to anger.
Lies. you got busted by your older comments.
Edited 2014-09-17 13:36 UTC
No I didn’t. I threw kernel source at you, and apparently you weren’t clever enough to understand what it was.
So, I did own a BeBox, I do own a Mac with multiprocessors (9500MP/180, if you really care) that runs BeOS if it is installed (drive failure unfortunately killed a lot of “interesting” stuff that was on that box), I don’t have any intel boxes that still run BeOS (I don’t think?!) I do have a lot of old BeOS books/software (GoBE Productive 2.something and Chorum 3 spring to mind) and Zeta from RC 3 up to 1.2.. I don’t really know what you want me to do to prove this. Should I make some pictures? Should I make a picture of a PowerPC machine running BeOS > R5.03? I probably have a screen shot somewhere. I probably even have an ISO of the post R5.03 PowerPC build if you really want to see that running. If that makes you happy, it can happen.
Yes please post photos proving it was your sole system (it wasn’t)
But you’re only clever enough to make a billion comments on OSNews that makes no sense to anyone. So I don’t see it happening.
Edited 2014-09-17 16:20 UTC
Pretty clear he’s trolling. Best leave him to his own devices. Rest assured, to informed readers, everything you’re writing makes sense.
I’ve noticed this pattern since mikeanderson first joined the site; he will spout misinformation about Haiku, especially in threads with people who were actually living and breathing BeOS back in the day.
In my opinion henderson101 is a major authority on the world of BeOS and Haiku among commenters here; I feel I can take him at his word. He’s certainly put me in my place when I’ve misremembered some obscure fact about BeOS.
Edited 2014-09-17 19:58 UTC
Thanks guys! Unfortunately, he is asking for me to go back in time and take photos of my set-up back in the late 90’s/early 2000’s, back before I owned a digital camera or even a film camera. I’m pretty sure my BeBox never ran anything but BeOS, so I’m secure in my self knowledge and have nothing to prove, though he is half right – I had an Amiga 500 too 😉
Why would you say June?
The last Nightly was put out about 2 days ago.
Go to http://download.haiku-os.org/nightly-images/x86_gcc2_hybrid/ to get the lastest downloads.
There is usually new ones posted 3-5 per week.
Okay – good. I was going by the page I found Googling “haiku nightly builds” : https://www.haiku-os.org/aggregator/sources/13
No. What Haiku SHOULD have done is been given a £2.5 million grant by the European Research Council for development of their operating system.
I thought the article was about MINIX, but half the comments are about Haiku …
Anyway, it seems to me that any OS that wants to be taken seriously today, for embedded or other systems, must support wireless networking. Unfortunately, there do not seem to be any plans for supporting WiFi anytime soon in MINIX, which severely limits it’s usefulness in my opinion.
Is anyone out there actually using MINIX for anything other than a toy or just out of curiosity? What if any real advantage is there in the MINIX micro-kernel versus say a stripped down, small, BSD or Linux kernel?
What do you think?
Jeff
Well, this is OS news
MINIX goal was educational in nature. It wasn’t supposed to be directly useful for any particular purpose. In the past Tanenbaum, fought changes that would have made it more useful, to keep the code more readable and understandable.
Is it not possible to use NetBSD wireless drivers?
Probably not, but it should be possible to write a wireless driver server in userspace, which when it crashes, won’t crash your kernel.
I don’t use MINIX in production for anything, but I like the small, clean nature. Since MINIX has a lot fewer features and libararies than Linux or the BSDs I sometimes try to port my code to MINIX. During development MINIX acts as a sort of lowest common point. If my code builds and runs on MINIX it should probably run on any flavour of Linux or BSD with minial tweaking.
Also, since MINIX tends to be very proper and follow strict standards compliance, I am more likely to catch bugs in code that make assumptions. Code running on Linux or FreeBSD may assume certain defaults that won’t fly on MINIX. So in this way MINIX makes for a useful testing tool to make sure my code is cross-platform and standards compliant.
That alone is a good reason for me to look at it.
I will try to download it tonight, and see if I can install it on my development computer.
Hey Jeff, my fault. I fed the Haiku bashing troll.
How does its IPC performance compare to L4’s. In Slashdot I read it is 10 times faster, in another place I read L4 is faster but I havent found a serious analisys. Anyone knows?
L4 is faster and have always been faster. How do I know?
Because L4 was designed to have extremely fast IPC, Minix wasn’t – so the basic design make L4 faster.
For the most common type of IPC, very small messages, the L4 design avoids copying data altogether by keeping data in registers. For somewhat larger messages it allows for single copy. Can’t get any faster without going for user space message passing – something with its own problems using standard processors.
Note that the goals for Minix 3 isn’t performance but reliability so thinking that it will be faster than something designed for speed alone (with the intention the reliability mechanisms or other design choices can be build upon the fast kernel) is simply ignoring real world constraints.
In short: the claims of 10x the speed are ludicrous and should be ignored. The claims in the post show a ignorance of both L4 and Minix performance measurements too.
Are there any processors that have tried solutions to faster message passing or improved sharing/call by reference?
I took it to refer to ARM VS x86 – do the same thing on ARM and you can go 10x faster than x86.