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.

Comments

ARM port

[Anonymous Coward]

MINIX on ARM will be very interesting if it happens. As I gather the footprint will be much smaller compared to Linux!

Re:ARM port

[Chrisq]

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

Re:ARM port

[LizardKing]

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).

Re:ARM port

[DrXym]

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.

Re:ARM port

[OrangeTide]

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)

Re:ARM port

[Hatta]

So, is there a reason not to use uClibc and BusyBox on a desktop distro?

Re:ARM port

[DrXym]

Yes. The uClibc C runtime ditches or makes optional a lot of stuff which is superfluous for embedding - locale stuff, math and so on and is optimized to save space, not necessarily performance and doesn't provide a stable ABI. Busybox doesn't offer a full implementation of various tools either, just the basics. Both are also modular so you're meant to pick what features you want or not at compile time. It's fine for embedding because space is usually at a premium, e.g. the rootfs has to sit in a small flash partition.

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.

Re:ARM port

[miknix]

Who called me?

Git?

[ledow]

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.

Re:Git?

[Anonymous Coward]

I don't think it's ironic, I don't judge a hammer by who created it, and git is just a hammer in a different context.

Re:Git?

[j-pimp]

Well Andrew S. Tanenbaum is not predisposed to feel strongly about version control systems. Operating systems on the other hand . . .

Re:Git?

[Noryungi]

That was in 1992. Get a life.

Seriously, though, Torvalds vs Tanenbaum is so 20th century.

Re:Git?

[K. S. Kyosuke]

Not to mention the adoption of BSD userland and Clang compiler. Minix always felt a little bit Oberon-like to me, all tools small and clean. Now it's more like Mini-OS-X than Minix. :-)

Re:Git?

[Anonymous Coward]

Git is overrated for MINIX source. I'm waiting for the station wagon full of tapes to arrive!

Re:Git?

[renoX]

Git is a userspace application, Tanenbaum and Torvalds disagree about the best way to design a kernel, that's a totally different topic..

> I can't decide if that's incredibly ironic, or a wonderfully beautiful illustration of Open Source.

Neither, just a pragmatic decision very similar to MINIX's reuse of NetBSD's userland.

Re:Git?

[gox]

To me, git feels more like minix than linux.

Re:Git?

[sg_oneill]

Since when are Tanenbaum and Linus enemies? Seriously, a lot of folks get riled up by a ridiculous debate nearly 20 years ago between an old professor and a young student over theoretically correct vs practically preferable (do the drivers live in ring zero. yeah, thats pretty much the crux of it)

Re:Git?

[Errtu76]

I don't think Git is used to _develop_ MINIX. If anything, it's used to keep track of code changes.

But I understand your point though. I think it's just using the right tools to get the job done, no matter who developed them.

Re:Git?

[Half-pint HAL]

Git is a userspace application, Tanenbaum and Torvalds disagree about the best way to design a kernel, that's a totally different topic..

That's 20th century thinking, you dinosaur. In the 21st century, you cannot disagree with someone without hating them and everything they stand for. I am now obliged to call you an idiot for disagreeing with me, or in modern parlance: "being wrong". w0t??? U iz a bag of FAIL!!!! I bet you're a communist who votes for pinkos!!!

Welcome to the Century of the Misanthrope.

Re:Git?

[Anonymous Coward]

Not to mention he's switching to using ELF as the binary format!! That stood out like a sore thumb to me. That is a total admit of defeat and surrender to the greatness of Linux.

Re:Git?

[Gilmoure]

Cake?

Or Ring Zero!

Re:Git?

[Anonymous Coward]

Ah, but how different from our beloved raging penguin who switched from KDE to Gnome? I know, old news, he's now using XFce. But still.

Re:Git?

[Anonymous Coward]

You are clearly a terrorist for pointing out the truth.

Re:Git?

[mrmeval]

Is minix open source? I thought it still cost money for any productive use?

That may have been in the 90s...

Re:Git?

[unixisc]

Open source & costing money are by no means mutually exclusive, as OSI will tell you. Even the FSF would argue that 'Free Software' doesn't mean that money can't be charged for it.

Anyway, in the 90s, Minix was something that you got if you purchased Andy Tanenbaum's book 'Operating Systems: Design & Implementation' for whatever the book cost. The CD came in the book. So essentially, it cost one the price of that book. Today, it can be downloaded from the Minix3 website.

As far as the licensing goes, Minix uses a BSD type of license, rather than GPL, and Tanenbaum seems to think that that would make a major difference in whether organizations would want to adopt it or not. In fact, w/ this latest 3.2 release, looks like Minix is replacing GPL3 software, like GCC, w/ Clang/LLVM, so like the BSDs, they too want to get rid of all the GPL3 stuff. On this issue, I think that before too long, Linux too might want to have a non GNU userland - maybe Chrome OS, rather than be tied to GPL3 userland tools.

Re:Git?

[Anonymous Coward]

I am now obliged to call you an idiot for disagreeing with me

Linus? Is that you?

Neat

[laffer1]

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.

Re:Neat

[Sodki]

>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.

What threat does Wayland poses? It's MIT licensed. And X.org isn't going anywhere anytime soon.

Re:Neat

[arkane1234]

For those of us that don't know what Wayland could be, might you freshen our feeble minds with it's definition?

You'll have to forgive us peons.

Re:Neat

[Anonymous Coward]

Oh, sorry, of course. It's just a bit of a leap between discount wargames and embedded systems, but I get it now, the wargames will keep the *n*x guys too busy to do any work.

</sarcasm>

Re:Neat

[Hatta]

clang is on the roadmap for several BSDs and now is default on Minix.

It will be nice if people start to realize that their code needs to compile on things other than GCC. These days you can't even compile a lot of software if you have a different version of GCC than the author did.

Re:Neat

[Chrisq]

What threat does Wayland poses?

Let's put it this way - if you pass Smithers in a dark narrow alleyway keep your back to the wall.

Re:Neat

[laffer1]

Fair question. The problem with Wayland isn't the license, it's the forcefulness of the Linux community to kill off all GUI systems that aren't theirs. The entire point of Wayland (and newer X.org work to a lesser degree) is to kill backward compatibility in the name of progress. The rest of us don't have IBM money to reinvent half the kernel every few years when a new idea crops up.

Re:Neat

[Chrisq]

For not using Google even though it would have taken less time than writing your post?

Are you THAT thick?

Quite. he'll be expecting us to RTFA next

Re:Neat

[laffer1]

http://wayland.freedesktop.org/

Re:Neat

[Anonymous Coward]

Wow, dude. You need to get out of the basement and get some fresh air. Kernel modesetting is the only sane way of doing it. Thank goodness we're finally getting it, even if it's 15 years too late. No?

Re:Neat

[serviscope_minor]

For those of us that don't know what Wayland could be, might you freshen our feeble minds with it's definition?

It's a massive FUD attack designed to replace Xorg with a less featureful but shinier replacement which also makes a number of the same mistakes that were made by OSX and Windows, rather than keeping the better design of parts of Xorg. On the other hand, it's something new which will keep the developers who have got bored with Xorg happy.

Wayland won't feature remote windowing. The best we can hope for is a pixel-scraper which dumps compressed bitmaps over the network.

Wayland seems to feature client side decorations. This has the advantage that every toolkit will give subtly different window decorations, hung applications will have immovable windows and it will be difficult to imlement global policies such as snap-to-window or snap to edge etc.

Wayland also solves a host of completely unrelated problems (apparently). See, one problem with Xorg is tearing in video. I don't have this problem on any of the intel chipsets I have, so it's clearly not an Xorg problm but a problem with drivers for other chipsets. Wayland people claim that wayland will solve this, apparently by magically dealing with the undocumented chips and proprietary blobs from other vendors.

Wayland does reduce the latency for compositing windowmanagers by removing a number of program->xorg->WM->xorg messages. Given that these are coming at a rate of positively 10s per second from your mouse, this is terribly important since Linux can't deal with high data rate, low latency messages.

About the only use-case for wayland is so that you can have a nice graphical transition butween multiple X servers running on a single monitor on a computer. I think that's definitely giving up network transparency for!

Wayland also seems to incite blatantly disengenuous claims from people who should know better like "oh you will be able to run Xorg on top of wayland". This completely ignores the fact that new wayland only programs won't have remote networking and secondly on every other system which does this, X11 is very much a second class citizen and the programs don't integrate properly with the native system.

Oh, apparently the BEST thing about Wayland is that it no longer has the 1980's style graphic primitives. This means that X is old and unfashionable. It also means that the Wayland developers have apparently never heard of software modularity where a bunch of rarely used function calls can sit somewhere on the side in a different source file and not clutter up the main body of code.

Re:Neat

[vlm]

These days you can't even compile a lot of software if you have a different version of GCC than the author did.

These days? For C++, "these days" go back to the 90s, based on personal experience. C++? never again.

Re:Neat

[sardaukar_siet]

Why is Wayland a 'threat'? Open source is evolution. Let Wayland come - if users go for it, they go for it and it becomes the new thing. If not, it was a try and I'm sure some good ideas can be harvested from it still. Where's the love, brah?

Re:Neat

[TeXMaster]

Why is Wayland a 'threat'? Open source is evolution. Let Wayland come - if users go for it, they go for it and it becomes the new thing

The problem is not "if the users go for it". The problem is "if every major distribution tries to cram it down everybody's throat", with no alternatives or making it very hard to choose an alternative.

Re:Neat

[evil_aaronm]

Serious question: if not C++, then what?

Re:Neat

[TheRaven64]

KMS is sensible, as is having the kernel manage memory. The problem is things like GEM that are quite leaky abstractions of the Linux virtual memory subsystem and so are difficult to port to other systems.

Re:Neat

[sardaukar_siet]

If that happens, open-source will route around it - it does that. Something else will come out on the other side that discontent people will like and gravitate towards. Or, Linux will wither away and die. Which outcome do you think is more likely?

Re:Neat

[Flammon]

Excellent post! I would love to see a reply with equal quality so if there's anyone out there with some Wayland answers, please post!

Re:Neat

[canistel]

Wayland won't feature remote windowing. The best we can hope for is a pixel-scraper which dumps compressed bitmaps over the network.

You people need to get over your whole "x11 can run over the network" thing... I don't care what the theory is, nothing beats RDP (windows remote desktop) for running applications. I've used them all: rdp, vnc, ssh -X, nx... nothing comes close to rdp, and if you guys took of the "windows sucks" blinders you would admit that too. Whatever advantages Xorg might have, running appliations remotely is absolutely NOT one of them.

Re:Neat

[Cid Highwind]

Wayland won't feature remote windowing. The best we can hope for is a pixel-scraper which dumps compressed bitmaps over the network.

Which is what we've got now with Xorg + any non-trivial widget set, no?

Re:Neat

[Anonymous Coward]

The first google hit is relevant, and wikipedia has an article.

That said: It's an interface protocol between a display server and the programs - sort of like a clean modern X, though lacking and form of network transparency. It's also the display server itself - which is a deliberately linux-only affair.

Re:Neat

[jdunn14]

I've used them all as well, and I usually prefer ssh -X. Of course, I'm working within a fast internal network and over given more latency other tools may be better suited. On a daily basis I run my email client on my Linux laptop and pipe the display to a rootless X display running under cygwin on my Windows desktop. I commonly forget that the app is not just another windows program.

Can RDP be set to mix remote applications with locally running ones? I like the idea of switching with just an alt-tab and copying between apps without getting stuck in a box where all the remote apps are running. For example, when running RDP if I hit alt-tab to switch applications can I cycle through the other apps on my desktop or just the ones within the remote session?

Re:Neat

[serviscope_minor]

Which is what we've got now with Xorg + any non-trivial widget set, no?

No, not exactly. The x server has been extended with porter duff compositing, and fonts are usually uploaded as pixmaps. Once uploaded, they can be pasted down into a printout of a string by effectively sending a list of pixmap IDs. That's much faster.

Also, GLX is capable of serializing the OpenGL stream and sending that over the network.

Re:Neat

[serviscope_minor]

Meh. The plural of anecdote is not data. Nothing beats X11 over a LAN, and the proper integration bewtween local and remote windows is simply fantastic. IME, nx handily beats RDP over the internet. Perhaps if you took off your X11 sucks blinders, you would see that too.

Whatever advantages Xorg might have, running appliations remotely is absolutely NOT one of them.

For you maybe not. For me it is very much an advantage.

Your attidude seems to typify the whole Wayland debate: "I don't use that feature so you must be wrong about wanting it".

Re:Neat

[serviscope_minor]

These days you can't even compile a lot of software if you have a different version of GCC than the author did.

This is a very disengenuous statement and you should be ashamed of it. You make it sound like GCC is somehow unique in this regard.

If you use experimental vendor extensions, then you will have a hard job getting your code compiled elsewhere. All compilers have nonstandard extensions and GCC is no exception.

Re:Neat

[Myopic]

That depends on your needs. What are you developing? If not an OS, then you have a heck of a lot of options.

Re:Neat

[Bing Tsher E]

Well, GCC started out life as a victim of that stuff, and it claimed for a long time to be the universal solution to that problem. Does GCC still not flag all nonstandard extensions when the -pedantic switch is turned on? It used to have that problem, which made it a code trap. "Write it for GCC but it won't build anywhere else."

Re:Neat

[Flammon]

+1 for mentioning NX and the tone was totally appropriate for the comment that it responded to so I don't know why the Troll moderation.

Re:Neat

[renoX]

> Wayland does reduce the latency for compositing windowmanagers by removing a number of program->xorg->WM->xorg messages

Only with the current implementation: nothing in X protocol prevents from having an X server with a compositor and a window manager in the same process, if the performance cost of X.org's modular design is really an issue..
Also with client-side decoration, I think that Wayland *increases* the number of messages between the client and server when you move a window.

Above all, what's very funny is that, in my understanding, with DRI2 on X11(*) there should very little performance difference locally between X and Wayland: in both cases the application uses a buffer in the GPU's memory to send data to the compositor..

*: on which Kristian Hogsberg the main developer of Wayland worked.

Re:Neat

[mattack2]

Wayland seems to feature client side decorations. This has the advantage that every toolkit will give subtly different window decorations, hung applications will have immovable windows and it will be difficult to imlement global policies such as snap-to-window or snap to edge etc.

So then are you calling Mac OS X more like X windows, even though the 'server' runs on the same machine?

If an app hangs, you can still move the windows. (In the vast majority of cases. Very old legacy apps don't have movable windows, but it's not a Carbon vs. Cocoa thing - Carbon apps can set a single bit to have the windows move via the window server.)

Re:Neat

[macshit]

Note that clang is quite gcc-compatible (by design), so a lot of "gcc only" code works fine with it. Thus it's probably not going to do so much to reduce the popularity of gcc extensions.

Howevery, although it largely implements the same interface as gcc, because it's an entirely separate implementation, it's is very useful as a way to detect inadvertent dependencies on gcc quirks / bugs (compile and test your project with both gcc and clang).

Re:Neat

[Anonymous Coward]

Riiiiiight...

I have this suspicion you've never had to do any real remote admin over a graphical remote desktop because if you had then I doubt you'd be spouting
all that nonsense about Windows RDP being superior. Many times have I had to do some bit of remote admin on a clients' windows server and found myself
grinding my teeth and wishing for a text-based ssh-style method to do things instead. Simply put, RDP sucks for remote admin so much that it makes me want
to cry whenever I have to use it. Give me an ssh connection and screen any day of the week, thanks.

Re:Neat

[DusterBar]

Great post, but there are things that X11 needs to fix. The whole "visuals" bit and the capturing of the mouse? xlib is a mess to program to and the GUI toolkits try to hide that but the overhead still exists.

Now, having said all of that, I would rather have a push to streamline X11 while keeping a strong window manager separation (this is actually important for security in addition to usability) and the remotable constructs. X11 has drawing primitives that are better than bitmaps (wayland) but not really that great. And some of the behavioral requirements makes it really hard on connections that have any level of latency.

Fixing these core items (and bringing in better layer management with composition at the display server side and not client side) is the way to go. Doing so and still being compatible will be very painful. Doing so and having "fun designing new" (or suffering from NIH) does not mix well. Just beware of the draw of "green fields" (starting from scratch) as it rarely works out in the end. (You usually make mistakes that were already address/solved in the prior system since you are more concerned about the "mistakes" in the prior system that you are claiming is the reason for starting fresh)

Re:Neat

[unixisc]

Is there any particular reason why Wayland couldn't be ported to run on the Minix 3.x microkernel? Yeah, it would run in user space, but is there anything that would stop it from running on Minix, when X already runs well? That way, Minix 3.x could also have KDE5 at least running on it, when it's available.

Re:Neat

[peppepz]

It's great to see alternatives to GNU tools gaining ground.

Great for whom? What do users gain with the alternatives to the GNU tools? I like being able to fix bugs in the software running on my routers, or to upgrade my Android phone even after its manufacturer stopped supporting it, and it's only possible because of the GPL.

It's the only logical choice for embedded systems due to licensing.

The vast majority of the embedded systems around me are running GPL code (Linux, busybox) and they seem to be doing fine. I've never seen anything running any *BSD. Am I an outlier?

Re:Neat

[Anonymous Coward]

Yes ... KMS

Re:Neat

[Anonymous Coward]

Looks like you left "kill" off the end of your username.

Some people find it funny, I don't see why you feel the need to point out how sensitive and thoughtful you are, except to be a dick.

Re:Neat

[unencode200x]

Can RDP be set to mix remote applications with locally running ones?

Windows (with either a terminal server or the newer Remote Desktop Services) can do this beautify. I use it all the time for various programs and forget that they're running in a data center far away. Lots of times they run faster if I'm on a slower laptop or working remotely. For example a line-of-business app that needs to hit a data base server that's in the data center. It's pretty nice.

Re:Neat

[Anonymous Coward]

Meh. The plural of anecdote is not data. Nothing beats X11 over a LAN, and the proper integration bewtween local and remote windows is simply fantastic.

Meh. You're trying to argue by anecdote yourself!

How about I give you my anecdote? I find X11 to be abysmal for this purpose. VNC beats it silly, even over a LAN. Modern X applications depend on lots of serial, roundtrip message exchanges with the server. If the pipe between the two has any more latency than a shared memory buffer, performance goes in the crapper so bad that it literally loses to shoving pixels across the very same network.

Worse, X11 doesn't support disconnect/reconnect at all, so if you lose connection, or need to switch computers and migrate the remoted application to the new computer, you're totally screwed. VNC is far better in practice just for that feature alone.

Re:Neat

[sjames]

Inevitably, most of the distros would be promptly forked with an identical distro except that Xorg stays.

Re:Neat

[Anonymous Coward]

C/Go, Ruby/Lua/JS

Just because it isn't in production

[tepples]

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.

Re:Just because it isn't in production

[Maximum Prophet]

Is MINIX singnificantly easier to try new concepts and develop OS prototypes vs. GNU/Linux, FreeBSD, NetBSD, Mach, and others?

Is it easier to instrument? If you learn something from a test, is it applicable to the real world?

Re:Just because it isn't in production

[vlm]

training tool

Its an educational tool not a training tool. Education is learning how stuff works, training is votech. Almost no one in the world will ever be hired because of minix on a resume. It is helpful for learning how OS work. Another way to put it is education gives you something interesting to think about, makes life worth living. Training gives you a way to make money to afford the contemplative life of an educated person. Its an educational tool.

Re:Just because it isn't in production

[LizardKing]

In principle, instrumenting significant parts of micro-kernel such as Minix is much easier than with a monolithic system like Linux. How true that is in practice is not something I can answer - I've only got the second edition of Tanenbaum's "Operating Systems" book, but it describes a much older and less sophisticated version of Minix.

Re:Just because it isn't in production

[Bing Tsher E]

MINIX is a pedagogical tool. It's like the ships that the Navy takes the ensigns out in to learn sailing. It's not a research platform.

Re:Minix

[Anonymous Coward]

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.

Re:Minix

[arkane1234]

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.

Great news!

[heneon]

After this I am sure it is safe to say that the year 2012 will be the year of Minix on the desktop!

Re:Great news!

[Tim4444]

More like Year of Minix on the VM! but.... does it run Linux?

Re:Minix

[jdgeorge]

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.

Real world microkernels?

[xonen]

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.

Re:Real world microkernels?

[anonymov]

Here's one real-world microkernel OS, for example.

Though most real-world is neither pure micro- nor pure macro-kernel, Win NT, OS X and Linux are stuck somewhere inbetween with varying degree of user-space/kernel-space separation.

Re:Real world microkernels?

[Dog-Cow]

Linux is pure macrokernel, in the sense that it isn't even slightly micro-kernelish. Of course, FUSE might confuse the issue a little bit. I am not sure where such facilities fall on the macro/microkernel debate.

Re:Real world microkernels?

[xonen]

commercial Unix-like real-time operating system, aimed primarily at the embedded systems market

That's exactly what i ment.. Commercial, not open-source, and secondly, aimed at embedded systems.

And indeed, most current kernels will be some hybrid between monolithic and micro. That's what makes Hurd and Minix so interesting: pure userland drivers/servers/ or whatever you call it; sshfs and fuse just faints by it. From a programmer stance of view, it narrows the gap between database (in the broad sense) / filesystem / IO, allowing way more efficient approaches of dealing with data and information services.

Re:Real world microkernels?

[anonymov]

They do. Filesystems and device drivers are on the kernel side in monolithic OSes, FUSE/CUPS/SANE/graphics drivers with minimal kernel mode parts/etc. muddy the difference.

It's easy to declare an OS as microkernel or _not_ microkernel, but "monolithic" is pretty much meaningless term, unless you just define anything non-microkernel to be monolithic.

Re:Real world microkernels?

[serviscope_minor]

Linux is pure macrokernel, in the sense that it isn't even slightly micro-kernelish.

As well as FUSE it also has userland USB drivers, userland graphics drivers and much of the sound functionality is in userland. Of couurse it ALSO has in kernel versions of those things too...

Re:Real world microkernels?

[Anonymous Coward]

L4 http://ertos.nicta.com.au/research/l4.verified/

A fully verified kernel for use in critical embedded systems.

Why?

[Maximum Prophet]

Serious answers only. What does Minix offer that GNU/Linux, FreeBSD, NetBSD, et. al. offer?

Re:Why?

[LizardKing]

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).

Re:Why?

[Bing Tsher E]

Minix has a textbook written around it. It's by design a pedagogical learning OS. People can adapt Linux and the BSDs for that purpose but it's not their original and central function.

Re:Why?

[LWATCDR]

Here let me give you the link
http://www.minix3.org/other/read-more.html

Actually Minix is trying to make advancements in a few areas.
1. Embedded. Minix is trying to be smaller, lighters, and more modular than Linux which to be honest is pretty dang good.
2. Security. Being a microkernel and having drivers running in user space it is the goal that a security exploit in a driver will not lead to a global aka root level exploit.
3. Reliability. With the microkernel if a driver crashes then instead of all of Minix crashing that driver can just be restarted. So if a video, network, or some other driver crashes the system stays up. If the driver is written so that the code pages are read only then it could be possible to just restart the driver in memory without having to even reload it.
I swear that people seem to really hate people trying new stuff. I like and use Linux but that is what should be cool about open source. We should be seeing new stuff more. Instead we have Linux, BSD, X and people crabbing about Wayland and Minix. Heck if we only picked what was most popular and worked good enough then we would all be running Windows 7 on desktops and laptops and using iPhones.
Really take a look and read about Minix. It has some interesting ideas. Frankly I could see it making a good firewall and or a NAS or SAN server if the performance gets good enough.
 

With the sound of crickets chirping

[Tarlus]

Topping it all off, the project switched over to git which would make getting involved in development a bit easier for the casual hacker.

...So git involved!

Fast Development

[Anonymous Coward]

That was fast, Linux just reached 3.2 recently as well!

Re:Minix

[TheRaven64]

Minix 3 is a modern, lightweight, BSD-licensed microkernel operating system. Is that interesting or relevant? It is to me...

Re:Minix

[tlhIngan]

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.

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.

Re:Minix

[Gilmoure]

It runs on my toaster (512k Mac) so I'm happy. Boots from one floppy and then can load web server from second. Although I'm running Minix 1.

Re:minix relegated to the dustbin of history?

[Gilmoure]

Exactly! They should post stoopid news like this on a sight just for nerds and geeks.

Question for the MINIX team

[SkOink]

Since I'm assuming somebody on the MINIX team posted this article:

Are there any plans to add real-time extensions to MINIX? I know that ARM support is in the works - with that and hard (or even soft) real-time extensions, it could sweep the embedded world in a big way.

Minix is cool

[spaceyhackerlady]

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

Re:Minix

[eclectro]

Linux is a bit huge

The word is bloated. Which is difficult for embedded solutions to handle, and could well garner an audience for those that need a small footprint (and they're looking for an embedded programmer).

New Rule: OS releases must include .torrent

[Anonymous Coward]

A few days ago, DragonFlyBSD was announced. The download site didn't include a torrent.

Today, MINIX is announced, and again no torrent.

From now on, if you want to post an OS release on slashdot (and in doing so encourage a large number of people to download an .iso), you must include a torrent.

(grumble common grumble effing grumble sense grumble)

Hurd

[unixisc]

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.

Re:Hurd

[manu0601]

On another note, I wonder why the Minix guys chose the NetBSD userland, since NetBSD is the least used BSD among the big 3

This is probably because NetBSD emphasis on portability often makes its code the cleanest one.

EU funds research on lightweight stable opensource

[quantic_oscillation7]

http://www.executivebrief.com/news/eu-funds-research-on-lightweight-stable-open-source-os/

Re:Minix

[bzipitidoo]

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.

Re:Minix

[macshit]

Wait, what? Minix is still what it always was: a historically interesting toy OS. Now it's new and improved, but it's hardly "the new hotness" anywhere.

Debian Archive has been rebuilt with clang

[tick-tock-atona]

http://clang.debian.net/

Re:Minix

[Anonymous Coward]

No, that's not the correct word.

The size and footprint of Linux kernel has been growing slower than density of RAM, so it's actually effectively moving toward lower end devices.

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.

Re:Minix

[CraigParticle]

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.

Re:minix relegated to the dustbin of history?

[iggymanz]

MINIX was and is used in many computer science curriculums. There are millions of people over the last 24+ years who learned about operating systems with the help of Minix. You might even have heard of a guy named Linus who used MINIX as scaffolding and teaching tool to write his own kernel.

Re:Minix

[Anonymous Coward]

Not bait.

http://www.spinics.net/lists/linux-embedded/msg03569.html

There, for example, is alluding to a company with a 3MB RAM project with network, bluetooth, and a web browser.

It's not uncommon to fit such thin under 4MB using XIP.

Linux also has support for CPUs without an MMU, which saves a significant amount of memory (no RAM required for pagetables or virtual memory mapping structures), and run on cheaper CPUs (which are not a general purpose system, but are great for networking and embedded applications). NetBSD is not portable to such systems.

Re:Minix

[CraigParticle]

Thanks, appreciate the link. But it sorta makes my point:
- An allusion to a vapor product with a 3 MB RAM goal is far from showing a dmesg. :)
- The linked "TLK" project reads nicely but has more aspirations than code, AFAICT
- The included 'web browser' was a misstatement, clarified in a subsequent post.

I'm aware of (uc)Linux's lovely support for MMU-less systems. It was a considerable kernel fork; what I'm impressed with is how much of it has been integrated back into mainline. It's a pity that someone long ago didn't do for NetBSD what the ucLinux project did for Linux 2.6.x.

But the context here is Minix3 on vanilla x86, not microcontrollers. So as I said before, I'm looking for configurations of x86 or ARM running a modern Linux kernel (2.6.x or 3.x) w/ 2 MB RAM or 4 MB with busybox. I sound dubious but am genuinely interested if this is possible (and how far you have to go down the rabbit hole to get there).

Re:Minix

[Anonymous Coward]

The Sony folk, who are some of the major contributors to the tiny linux project, also mentioned in other threads that they use XIP extensively to reduce footprint. This is *not* using nommu, mind you.

With nommu, you could go smaller. And it is completely integrated into the kernel -- nommu ports are first class architectures.

Actual systems to demonstrate are hard to find, because embedded vendors typically don't publish that kind of information. Linux is certainly capable of configuring down that small, however. Here, from 2005:

http://tree.celinuxforum.org/CelfPubWiki/TechConference2005Docs?action=AttachFile&do=get&target=linux-tiny.pdf

He actually booted a kernel in 1664KB memory. This had ext2 filesystem, tcp/ip networking, and IDE and NIC drivers. It has 312K free. So it actually booted with 1352KB RAM (and no XIP from ROM). 1.3MB RAM.

Two things have changed in the meantime, firstly, many of these patches and configuration options have been merged into mainline kernel, and secondly the mainline kernel itself has changed significantly. I don't know if you can reproduce exactly these results on the latest kernel, but it demonstrates it certainly can be cut down signficantly. No other free full unix OS comes close, unless you can show me some proof.

Re:Minix

[Anonymous Coward]

BTW, on ARM nommu, using XIP to load the kernel and root filesystem, and without ext2 or block device subsystem, I would expect you could cut it down well below 1MB.

Re:Minix

[CraigParticle]

Thanks for a very thoughtful and informative post!

Where I started in this thread was posting a 1.2 MB kernel RAM footprint in vanilla NetBSD/ARM. This is with UFS/ext2/msdos filesystems, tcp/ip networking, NIC, USB standard devices (bulk storage, audio, etc.) loaded. It doesn't sound terribly far off at all. Outside of the XIP and nommu advantages, which are very significant, I'm actually curious whether it would boot in 2 MB with a minimal userland. The SoC hardware has 32 MB, so I've never bothered editing the memory map. I'll trim it further as your reference did and see what it'll do...

On the Linux side, I'm really impressed at how nommu and many other patches have integrated into mainline. I always expected the bulk of uClinux to be forever a separate patchset. It's great to see.

Re:Minix

[Anonymous Coward]

Well I don't know that it's quite the same thing to boot with 8MB of memory and report a 1.2MB kernel RAM footprint, to booting in 1.3MB of RAM total (2MB - BIOS). Accounting, particularly for early boot fixed allocations and things, is frequently imperfect. You also may need temporarily more memory than is being used when you query the footprint.

Would be interested to see what you come up with.