Slashdot Mirror
MINIX 3.2 Released With Some Major Changes
An anonymous reader writes "MINIX 3.2.0 was released today (alternative announcement). Lots of code has been pulled in from NetBSD, replacing libc, much of the userspace and the bootloader. This should allow much more software to be ported easily (using the pkgsrc infrastructure which was previously adopted) while retaining the microkernel architecture. Also Clang is now used as a default compiler and ELF as the default binary format, which should allow MINIX to be ported to other architectures in the near future (in fact, they are currently looking to hire someone with embedded systems experience to port MINIX to ARM). A live CD is available."
The big highlight is the new NetBSD based userland — it replaces the incredibly old fashioned and limited Minix userland. There's even experimental SMP support. Topping it all off, the project switched over to git which would make getting involved in development a bit easier for the casual hacker.
Git? Seriously? So the system developed by the primary "enemy" (or so it's portrayed) of the designer of MINIX (and most vocal opponent of the way MINIX operates) is used to develop MINIX itself now, presumably because "it works" even if it's not architecturally perfect?
I can't decide if that's incredibly ironic, or a wonderfully beautiful illustration of Open Source.
I see an interesting convergence of some technologies happening. clang is on the roadmap for several BSDs and now is default on Minix. NetBSD tools were pulled in which are also used in part on several other systems. The Minix folks will probably upstream fixes to NetBSD as well as make improvements to llvm.
It's great to see alternatives to GNU tools gaining ground. It's the only logical choice for embedded systems due to licensing. We're going to need to step up our game and make our own tools with threats like Wayland coming.
MidnightBSD: The BSD for Everyone
Just because MINIX is not popular in public-facing production systems doesn't necessarily make it any less valuable as a training tool to teach of operating system design.
Seconded. Aside from a purely nostalgic standpoint, not sure how relevant MINIX is in this day and age, given the hardware and OS choices available. Still, I guess people have the right to work on whatever the hell they want to.
Remember it for what it was originally made for... an operating system to learn from while coding.
You might not remember those days, but when you have a working operating system that is minimal in code size, it's easier to grasp.
I'm just a little disoriented by the need to advance it, unless it's a minimal codebase of the NetBSD variety. Then again, they did say it was "pulled" from NetBSD, so that'd mean in my mind it's not minimal... which nullifies that. ... and we're back to square one.
-- This space for lease, low setup fee, inquire within!
Perhaps it's being used for educational purposes. Linux is a bit huge to use as a learning tool for various aspects of how operating systems work. I speculate that pulling in code from NetBSD seems to make sense to provide more up-to-date examples of modern OS architecture issues.
MINIX on ARM will be very interesting if it happens. As I gather the footprint will be much smaller compared to Linux!
Will it? You are probably comparing Minix to the bloated x86 Linux distributions. ARM Linux is much smaller
I wonder, how is real-world useability state of microkernels? As i know of only 3 serious open source projects developing an actual useable microkernel for pc-ish hardware (namely: minix, hurd and -shoot me- reactos), how does minix compare to hurd. Which of those 2 projects would be likely to be a serious (`production`-ready) alternative for linux?
On first sight, it seems Hurd is a few steps further - debian delivers an experimental distro around a Hurd kernel (comparable to the debian/freebsd project) for a few years now, whereas minix just implemented netBSD's userland with this release. On the other hand, news on Hurd has been steadily stale for a decade or 2.
If our future would be easy selectable kernels (linux/hurd/minix) and userland (gnu/*bsd), in any combination of our liking and/or most suited for the goals, then i'd welcome it, but i'm quite sure this is an oversimplification of current reality, and probably future, especially seen current *bsd vs linux development (partly caused by licensing issues). Maybe some expert on the matter could enlighten us with enduser-understandable technical details, and a comparison on those projects, please.
A glitch a day keeps the bugs away.
ARM Linux is much smaller
The Linux kernel itself usually isn't. The C libraries that come with the distributions ARM board vendors often bundle with their hardware are typically smaller as they don't usually use glibc (or a derivative of it).
A full featured kernel and userland that allows you to tinker with a micro-kernel based system. Linux and the BSD's are all monolithic kernels, even where they offer modules support (Darwin, the core of OS X, isn't a true micro-kernel based system either).
Embedded dists tend to use uClibc + BusyBox. Android uses a BSD user-land with a C runtime implementing a subset of Posix called BIONIC. The kernel would be compiled down to strip out superfluous drivers, filesystems, subsystems and so on.
I think it's evolving the userspace side - while the Minix is the kernel side. The userspace of Minix suffered and gets crufty as people can't use what they already know since the Minix userspace starts looking a little barren.
There are lots of teaching operating systems out there. Most are just applications that run on another OS to teach basic concepts like multithreading, locking and such. Minix appears to be the end goal - an OS that can be taught running on real hardware. A userspace revamp to make it feel modern and not a toy. And being able to go and compile some program you wrote on an OS you're tinkering with can trigger excitement among students.
And there's probably a ton of OS research going on with Minix as well, and not having to put up with limitations on tools because the userspace can't run them is helpful.
I wouldn't call Bionic a real BSD user-land. Bits and piece of the libc were copied from BSD, but a lot of it was written from scratch by Google.
OS X is a real BSD user-land, even if there are a fair amount of change (or as I would call them, compatibility issues)
“Common sense is not so common.” — Voltaire
So you could use them on a desktop but the question is why in most cases since you would have the CPU and memory to support the fullblown libs. I doubt uClibc would compile against desktop style applications and most dists would expect full blown GNU tools to function. You'd probably have to roll your own dist for that.
I respect Minix for its attempt at doing something different from the monolithic OSs we almost invariably use.
Linux and its ilk are very powerful, but they're not the only way to solve problems. Keep up the good work!
...laura
Of the various microkernels that ever existed @ different times, Mach 3 was less than satisfactory, Chorus ended up digested by Sun, and Amoeba itself today stands discontinued. L4 is a 2nd generation microkernel that has been tried out in some projects, including a Linux project called L4Linux as well as an OS/2 successor called OSfree. There are some other microkernels, such as Coyotos & Viengoos that have in the past been tried by the Hurd project.
I'd think that something like Minix 3.0 (not 3.2) would be a good microkernel to base Hurd on. Given the licensing differences, the Hurd guys may need to fork Minix anyway in order to get a microkernel that has everything that Hurd needs. If they get that, they can then continue on the rest of the project, and finally have the GNU's own kernel (which ain't Linux).
On another note, I wonder why the Minix guys chose the NetBSD userland, since NetBSD is the least used BSD among the big 3. They could have simply gone w/ FreeBSD, which would have given them a range of targeting options, allowing them to borrow from PC-BSD for netbooks, pFSense for routers/firewalls, FreeNAS for storage, and so on.
And finally, I do hope they get an arm version sometime. Another suggestion - they might want to get a Raspberry Pi and port the ARM Minix to that platform, making it the target platform for this initially.
Oh, I remember that all right. What I remember is that circa 1989, the vi editor Minix had could not handle text files larger than 32k! Our first assignment was to hack on some source that was, of course, in a file larger than 32k, so we had to use split to break it into pieces, then cat to join everything together. Compiling might fail because you ran out of hard drive space, or memory, or file handles, process table entries, or who knows what. Over and over, Minix told its users that their cheesy consumer PCs just weren't big and good enough for a real OS. Lame!
In short, in those days Minix was a horrible OS. Made DOS + Windows 3.1 look like a model of usability by comparison. And now, Minix is the hotness in microkernels and embedded devices? Disorienting indeed.
That was a long time ago. I'd like to see Minix improve and succeed. And that because I feel nearly everything about computing has become seriously bloated. How did libc get so gigantic? Despite the bloat, computers are still so inflexibly, unthinkingly literal they make the most severe autism patients look like they gush with empathy and understanding.
Intellectual Property is a monopolistic, selfish, and defective concept. It is "tyranny over the mind of man"
Linux can be configured to run in 2MB of RAM and 2MB of flash or less. It can run in 4MB RAM with a full network stack, busybox, and several hundred K remaining for apps.
There is no other full featured free unix like kernel which can do that. Certainly none of the free BSDs.
I'll take the bait. Care to show a reference to running a modern Linux kernel w/ 2 MB RAM, or 4 MB RAM with busybox, on i386 or ARM? Busybox can do wonders for storage requirements (e.g. for NAND FLASH), but it doesn't help with RAM at all! I found 8 MB to be difficult enough (!), last I tried ulibc and busybox on i386.
Just as a point of discussion, generic NetBSD is smaller than generic Linux (e.g. Debian) on the ARM platforms I've been using. A line from top shows the latest (NetBSD 5.1.2) kernel RAM footprint on ARM9: about 1.2 MB, with numerous filesystems, NFS, networking, USB support, etc. built in. This includes all kernel modules.
PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND
0 root 125 0 0K 1240K schedule 0:00 0.00% 0.00% [system]
Running 1 instance of httpd, sshd, and two user processes, minus 1.5 MB of buffers/cache, it's using 5.5 MB of RAM right now. Tightened up, it might boot in 4 MB but I haven't tried. Do note that this is with the standard (Net)BSD libc, all completely generic, 'out-of-the-box'.
Amazing work has been done to cram Linux into small places, but I think it's somewhat disingenuous to say that no BSD is close. I'd say NetBSD provides a rather interesting starting point.