New Release of MINIX 3 For x86 and ARM Is NetBSD Compatible

An anonymous reader writes MINIX 3 is a small POSIX-compliant operating system aimed at high reliability (embedded) applications. A major new version of MINIX 3 (3.3.0) is now available for download at www.minix3.org. In addition to the x86, the ARM Cortex A8 is now supported, with ports to the BeagleBoard and BeagleBones available. Finally, the entire userland has been redone in 3.3.0 to make it NetBSD compatible, with thousands of NetBSD packages available out of the box. MINIX 3 is based on a tiny (13 KLoC) microkernel with the operating system running as a set of protected user-mode processes. Each device driver is also a separate process. If a driver fails, it is automatically and transparently restarted without rebooting and without applications even noticing, making the system self-healing. The full announcement, with links to the release notes and notes on installation, can be found at the Minix Google Groups page.

Comments

A microkernel-based OS that 'just works'

[Anonymous Coward]

with today's HW. Haha, wouldn't that be funny if ten years from now Linux and Minix switched places?

Nah...

Re:A microkernel-based OS that 'just works'

[Anonymous Coward]

Hey, if it becomes production ready, then why not?

Re:A microkernel-based OS that 'just works'

[Obscene_CNN]

Because it will be slow

Re:A microkernel-based OS that 'just works'

[Anonymous Coward]

... or so say the python and Ruby users.

Re:A microkernel-based OS that 'just works'

[flyingfsck]

Finally I have something useful and old fashioned to do with my Beaglebone Black. Running Linux on it was kinda boring.

Re:A microkernel-based OS that 'just works'

[Anonymous Coward]

A 3-year old PC loaded with malware is pretty slow too. Not saying that a microkernel OS is a magic bullet for anything on the security front, but hey, it opens new avenues for invention.

Re:A microkernel-based OS that 'just works'

[Megol]

Magic bullet? There never are any magic bullet for complex systems.
A microkernel is the realization of best practices for security systems and - dare I say it - follows the original Unix philosophy.

Do one thing (IPC) and do it well (ensure security guarantees are kept). Keeping the critical code small makes it easier to verify code in both the practical and mathematical sense.

Re: A microkernel-based OS that 'just works'

[Anonymous Coward]

Thats why Windows NT 3.x was the safest OS on the planet!

Re: A microkernel-based OS that 'just works'

[EmeraldBot]

Thats why Windows NT 3.x was the safest OS on the planet!

Windows NT 3.x was NOT a microkernel. They dropped that claim on NT 4, because they knew it was false.

Re:A microkernel-based OS that 'just works'

[Anonymous Coward]

Well, Plan 9 took it in a slightly different direction. Plan 9 is built around the 9P filesystem, which is the backbone for IPC not just on the same machine, but between machines.

Anyhow, the real Unix philosophy is "Worse is Better". And I say that as somebody who prefers Unix to everything else. Worse is Better is actually a statement about pragmatic engineering, a pragmatism which the microkernel community has been late to adopt.

That said, Minix looks as awesome as ever and I can't wait to give it a spin.

But in the grand scheme of things, the NetBSD and Linux kernels will increasingly look like microkernels when you factor in all the various networked services that will overlay the base operating system. In that sense Plan 9 was much closer to the mark, except instead of 9P we'll live with a mismash of various protocols, which typically include HTTP or an HTTP-like transport (thanks, firewall fanatics!)

High reliability?

[Megol]

Does anybody know what exactly is novel in the Minix 3 approach? Microkernels (or small macrokernels) with restartable drivers are well known and already used in the real world.

Re:High reliability?

[DarkOx]

Its not novel but its simple and clean. Minix is really an education tool more than a production ready OS.

Re:High reliability?

[bluefoxlucid]

The novel approach is that Tanenbaum invented the fucking thing. The specific current advantage is low-latency IPC--on ARM, Minix IPC doesn't even have a measurable cost (the context switch time required is under 20 microseconds), while on x86 IPC is more than 10 times faster than L4.

Monoliths, e.g. Linux, don't have IPC latency because they don't context switch when making calls between major kernel functional units. Of course, if your network driver crashes, your whole system gets fucked up and dies; whereas Minix tries to take a state snapshot, reconstruct something workable, load it into a fresh run of the network driver, and continue without a hickup. This works extremely well with the disk and FS drivers. Ideally, we want this without paying for it.

Re:High reliability?

[MobyDisk]

Minix tries to take a state snapshot, reconstruct something workable,

That's frieking fascinating. I just posted about how I didn't think restarting a driver could really be transparent because state would be lost. Then I read that it actually transfers the state. Do you have any good links with an overview of that? My immediate thought is "well, if the state is transferred, won't the restarted service crash too?" but I'm guessing someone has already thought of that...

Re:High reliability?

[Megol]

10 times faster IPC than L4 on x86?!? That requires user level IPC like done in Barrelfish and ZIMP ("ZIMP: efficient inter-core communication on multi-core machines" ).

Got any proof that the Minix IPC performance is so much better than what is commonly known as one of the most efficient IPC implementations in existance?

Re:High reliability?

[bluefoxlucid]

No idea. I've seen the performance tests where they repeatedly send kill signals to the disk driver to crash it over and over, and measure its impact on performance--large when you have this in a tight loop, yet the system trudges along, and stops being so god damn slow when you stop killing the disk service 1000 times per second.

I can conjecture a lot about how it is and isn't possible--obviously you can't just restart a snapshot from a few ns ago, or tell it to try again, or rerun the service and dump the same exact data back over it; but you can resubmit requests and messages in any number of ways. If you're careful to use a request-acknowledge-free workflow (send a request, wait for an acknowledgement that it's completed, then free the memory for the request when it's acknowledged or when the requested information is returned), you can always replay a request if the server dies. You can even use a mediator to resubmit uncompleted requests or stored state (received frames, journaled file system actions, etc.) to a service if it gets restarted, hiding that process from other services.

Minix documentation and demonstration show that they restart the service and it completes all requests--state is snapshotted and restored. How that state is snapshotted--internal to service, mediated by a message passer, or resubmitted by client services--I don't actually know. I just know it does it and it's technically possible in any number of ways.

Re:High reliability?

[bluefoxlucid]

Last time I looked at this, L4 was some 1-2mS context switch on x86, back in the 1GHz chip era; Minix was 100uS; and it was some 20uS on ARM. ARM is a good architecture--even L4 was ridiculously fast on ARM. Mach was slow as balls all the time.

Re:High reliability?

[LWATCDR]

Are the drivers reneterent? If so you could in theory clear the data pages and restart the code instead of any type of reload.
Over all I am very excited by this news. Minix 3.0 has been very interesting but lacked apps. Being BSD compatible really helps with that issue.

Re:High reliability?

[Megol]

https://www.l4ka.org/126.php

Opteron 1.6GHz - 0.14s context switch

This on a 11 year old CPU...

Re:High reliability?

[flyingfsck]

Minix has been around since the early 1980s, so it is hardly novel anymore. Microkernels are also quite popular, Apple Mac OSX uses one and that is what I am using right now. Slow? Maybe. I never tried to do a proper benchmark, but sometimes it does feel annoyingly sluggish.

Re:High reliability?

[Anonymous Coward]

The novel approach is that Tanenbaum invented the fucking thing. The specific current advantage is low-latency IPC--on ARM, Minix IPC doesn't even have a measurable cost (the context switch time required is under 20 microseconds), while on x86 IPC is more than 10 times faster than L4.

Care to provide a source for that. As far as I'm aware, IPC in modern L4 Kernels is much faster than IPC in Minix 3.

Re:High reliability?

[bluefoxlucid]

Only if the code hasn't deformed (bad RAM, failure to make executable non-writable, etc.).

Re:High reliability?

[bluefoxlucid]

Huh. Last time I looked at this stuff was 2003. Anyway modern IPC doesn't context switch; it mode switches in Minix, transferring in kernel mode on the same context, sort of. It's complex. Linux does the same thing, but with a monolith.

Re:High reliability?

[Anonymous Coward]

OS X uses a modified FreeBSD (old school) kernel, not a microkernel. OS 9 was derived from NextStep, I think, which was in turn based on Mach - but that went away long ago.

Re:High reliability?

[Pseudonym]

Monoliths, e.g. Linux, don't have IPC latency [...]

In the case of non-memory-mapped I/O (e.g. anything that goes through a file descriptor), the major cost isn't context switching, it's copying data. Microkernels have to transfer all this data between address spaces. Macrokernels, on the other hand, have to transfer it between user space and kernel space. It's basically the same operation with basically the same cost, but it falls under a different heading.

Re:High reliability?

[Anonymous Coward]

OS X is based off of NextStep, not OS 9.

OS X i still based off of Mach. Mach was based off a modified BSD kernel, and was never a micro kernel in the sense we mean it today. When we speak of the micro kernel today, L4 is what we think of, a kernel that does the minimum necessary to build a working system.

OS X is heavily based on the FreeBSD user land, and uses some code from the FreeBSD kernel.

OS 9 was a custom built OS that was continued from the original Mac. It was built entirely by Apple.

Re:High reliability?

[Megol]

That doesn't change the fact that L4 _never_ had a 1ms context switch time. Not even on a 486 was it never that slow, the kernel entry cost was 200 clock cycles.

The L4 kernel have always been in the front of pure IPC performance, it is as simple as that.

Also for other people reading this there are a number of features that enable even faster microkernel performance today, the syscall/sysenter instructions makes entry to kernel mode less expensive than the traditional interrupt handler (which due to x86 semantics are often slower than necessary) and address space identifiers makes flushing of L1 cache unnecessary.

Re:High reliability?

[jeremyp]

Err, no.

OS X uses the XNU kernel from NextStep which is a hybrid of the Mach microkernel, some components from BSD (the network stack and the virtual file system) and a device driver architecture which was completely new for OS X. Over the years, a lot of the BSD code has been rewritten with the introduction of more granular locking and better abstractions for the file system and networking APIs.

OS 9 had nothing to do with NextStep.

Re:High reliability?

[bluefoxlucid]

Yes. Minix writes to a memory area shared between contexts, so there's no copying. Messages are also fixed-length packets, so no buffer overruns.

Re:High reliability?

[bluefoxlucid]

But GNU HURD uses L4 and has historically been slow as shit due to in-kernel IPC. When did it get fast?

Re:High reliability?

[LWATCDR]

I wish that they had ported the FreeBSD userland. I am think FreeNAS with ZFS on Minix as a killer NAS solution.

Re:High reliability?

[Pseudonym]

Incidentally, QNX has an interesting design in this respect, in that it maps the the source buffer (a page at a time, IIRC) into the address space of the receiving process, and does the copy directly. Or it might map the destination buffer into the address space of the sending process; not sure about that. This allows messages to be arbitrary-length.

Drivers as processes?

[MobyDisk]

If a driver fails, it is automatically and transparently restarted without rebooting and without applications even noticing, making the system self-healing.

When things are restarted they lose their state. I don't see how applications will not notice that. For example, if an application has an open file handle, it seems unlikely that the file system could be "restarted" without a write failing.

Re:Drivers as processes?

[Chandon Seldon]

Sure. So we've upgraded from the system crashing to one write failing.

Re:Drivers as processes?

[bluefoxlucid]

The file system write or read request doesn't return anything, the driver is detected as dead (heartbeat?), it's killed, resurrected, journals are replayed, and the request is resubmitted to the FS driver.

It'll work. The program might notice a small pause, as if the disk was busy or the kernel yielded schedule to an interrupt handler.

Re:Drivers as processes?

[Megol]

Depends on how it's done. It's possible to have replicated data fully or partially so that things would just work with a little bit longer latency.

Of course there will always be a failure mode in any system however it is possible to push it to very unlikely scenarios (like the data center being the target of a nuclear attack). The cost is in most cases not engineering work IMHO but runtime performance, reliability will cost at least a constant factor for all critical operations. Which is worth it (still IMHO).

Re:Drivers as processes?

[MobyDisk]

So the drivers are stateless?

Re:Drivers as processes?

[MobyDisk]

Certainly that would be a big benefit. But that isn't what the article says happens. The article says it is "transparent" and applications won't even notice. I'm unclear how that is possible and I am looking for input on that. Some other replies are talking about that though, and it sounds interesting...

Re:Drivers as processes?

[bluefoxlucid]

You can reconstruct state. A read request from hard disk will work the same way, repeatedly; a write request to a file system will write to a journal or the same blocks in a file or inode, while a write to a hard drive sector is isometric. Keeping the request buffer, resubmitting the request, and so on lets you reconstruct state. Even a network driver theoretically could read state from the network: it could request DMA from the NIC to a buffered memory area with a control structure of known layout, and the resurrection server could provide the control structure and buffered memory areas back to the driver if it needs to restart.

The remainder of the driver state can be discarded. Bringing in new network frames, new writes to file systems, or the like shouldn't depend on the driver's internal state. Repeated crashing--for example, reloading the network driver as above and having the control structure point to a buffer of unmapped memory--could signal the OS to simply drop state and start fresh. Recovery is possible in many cases: TCP/IP, as a separate driver, would simply experience a dropped frame (lost packet), handling a state-reset network driver the same way as any other faulty media; a failed hard drive write would signal the FS driver to resubmit its write; and a failed file system operation could go so far as to reload the driver and run a journal replay or file system check (non-journaled file systems could use an in-memory journal to facilitate file system driver recovery).

Consider state as a collection of significant and insignificant states. My Web browser right now has a lot of stuff in memory, a lot of things rendered on the screen, a state of how far down I've scrolled, and state describing where in memory all these things are--and where this text I'm typing is stored. If we unload the browser and then re-launch, the only state I need restored to post this message is a copy of this message, dumped anywhere in RAM, with a specific pointer somewhere referencing that buffer as the context of this particular textbox on this Web site. The browser's state may be completely different, yet only that piece of information is important; I can recover the rest by coming to this page and hitting "Reply To This".

From that view, it's not hard to recover discrete processes in an OS. File system separate from disk driver means the FS can handle a disk driver crash and reload; user prorgrams won't notice a file system driver crash if the system just waits for the FS driver to reload and replay a journal or such to return state to sanity. The task entry for the user program tracks all the file handles. All of these things are separate, can communicate between mediators, or can mediate their own communications.

Re:Drivers as processes?

[Anonymous Coward]

So how come this sh*t works then?

Re:Drivers as processes?

[itzly]

How would you resume an open TCP connection after restarting the network driver ?

Re:Drivers as processes?

[ChipMonk]

Because TCP is a separate driver, and tracks the TCP connections on its own. And in ISO-speak, TCP is in the Session layer, not the Network layer.

Talk about News that Don't Matter

[Anonymous Coward]

Now it's Linux.

Well done

[Anonymous Coward]

Making it netbsd compatible is a stroke of genius.

Self-healing drivers

[peppepz]

Don't present userspace drivers as a panacea for all kinds of driver troubles: when a driver fails, it can make the hardware it drives hang your machine solid from the hardware's side, or make said hardware DMA all over your RAM with complete disregard any CPU-imposed protection; there's no safe recovery from such a situation, and in this case applications had better be stopped even if they appear to be still running.

Re: Self-healing drivers

[Anonymous Coward]

Isn't that what iommu/vt-d are for?

Re:Self-healing drivers

[Anonymous Coward]

IOMMUs are increasingly available in modern systems. Perhaps it's time for the operating systems to use them.

Re: Self-healing drivers

[squizzar]

Spoken like someone who has never jammed up a PCIe bus before.... driver mistakes can make systems go down hard. Even if the IOMMU is protecting the memory the underlying hardware might be flooding the bus with junk, or in some other unrecoverable or unmanageable state that requires the hardware to be reset. If the host has a way of driving the reset line to the device then you might get out of your bind but that's a long way from stateless - it would let you restart the hardware device without interfering with the system though. That said I don't think there's that much stuff out there that's robust enough to deal with crazy situations like that

Re: Self-healing drivers

[Anonymous Coward]

You could toggle PCI reset and replay the configuration settings to get the device close to the state prior to the driver class. This wouldn't be hard for most of the hardware being used today. Actually nothing would prevent you to reset the device and simply load a copy of the most recent state saved to it.

Re:Nothing to see here. ANOTHER Linux CLONE!

[halivar]

Uhhh... I think you switched the cart and the horse, there, fella.

http://en.wikipedia.org/wiki/L...

Re: Nothing to see here. ANOTHER Linux CLONE!

[Anonymous Coward]

Uh, no. Minix predates Linux by decades. Check your history, boy.

Re:Nothing to see here. ANOTHER Linux CLONE!

[Hamsterdan]

Please leave your geek card on your way out...

Linux clone

[bluefoxlucid]

Linux currently leads. Minix needs a bunch of drivers implementing kernel event hooks, inotify, dnotify, etc. Essentially, everything for udevd, systemd, and dbus. These wouldn't be integrated in core, and so could only come online when building a distribution to support a Linux-like user space. Could even implement iptables. Would need ext4, xfs, btrfs, zfs, and fuse drivers eventually.

Re:Linux clone

[Anonymous Coward]

Why?

Re:Linux clone

[Obscene_CNN]

Minix will never catch linux. The fact is it is slow. Infact its slower than GNU Hurd (now that is bad). Even worse its run by Andrew Tanenbaum who is notorious for rejecting patches for trivial if not egotistical reasons.

Re:Linux clone

[Anonymous Coward]

> Minix needs a bunch of drivers implementing kernel event hooks, inotify, dnotify, etc. Essentially, everything for udevd,
> systemd, and dbus.

No, please let systemd out of Minix. Lets not contaminate another Unix implementation with it.

Re:Linux clone

[itzly]

And when it's all done, it will be more complex than Linux.

Re:Linux clone

[bluefoxlucid]

From what I've seen, Minix is fast. It's built for speed, avoiding many costs of IPC the same way Linux does.

In Linux, the address space is split. IA-32 4G/4G causes a full TLB and cache flush at syscall entry and return, creating massive slowness. IA-32 normal 3G/1G operation puts 1G at the top for kernel mappings and 3G at the bottom, while x86-64 puts 128TB at the top and 128TB at the bottom. In both cases for split address space, there's no TLB or cache flush when syscalling into the kernel; and returning to user space requires only selective cache and TLB invalidation, removing kernel-private data and leaving userspace data in tact. This greatly improves cache utilization and reduces expensive pagefaults by completely avoiding the kernel/user context switch, replacing it with a simple mode switch.

In Minix, the many kernel contexts make all the same mappings, but lock access to the specific service. It's the same as Linux's split mapping, but with parts of the kernel unable to access other parts; IPC involves a few TLB and cache invalidations in each direction. This strategy lets you run an entire round trip call in under 100nS. It's about as long each way as a CALL and RET, so it's about the overhead of adding a function call along the code path.

Re:Linux clone

[Obscene_CNN]

Although Minix does use some of the same tricks Linux does it still has additional overhead of separate servers and message passing. L4 still has a 2% to 4% penalty vs a monolithic kernel. You can optimize it all you want but the piper must be paid and won't go away.

Re:Linux clone

[bluefoxlucid]

But it will be complex in small, discrete, independently-verifiable pieces, like a cookie with raisins, M&Ms, and a peanut butter cup arranged on top rather than a chocolate-peanut-butter cookie with raisin puree mixed in.

Re:Linux clone

[bluefoxlucid]

It has a 2% to 4% penalty for IPC, specifically. This is like when Theo de Raadt chose to argue with me that position-independent executables were "very expensive" and had "high performance overhead," and I pulled out oprofile and found that 0.2% of the execution time occurred in the main executable--which was 6% slower (when including -fomit-frame-pointer no longer providing a 5% boost), giving a total overhead of 0.012% total system slowdown--a few seconds lost per day.

The difference is I was doing that back then, and not referencing shit I did 10 years ago.

Minix's overhead is small. Minix uses fixed-length buffers, zero-copy strategies, mode switching, and the like to avoid doing any real work for IPC. It's like adding a function call to your code paths--like if you called get_fs_handle() and it called __real_get_fs_handle() without inlining it.

Re:Linux clone

[Obscene_CNN]

Its still going to be slower no matter what you do.

Re:Linux clone

[bluefoxlucid]

Not necessarily.

There is a single, absolutely-optimal way to implement a computer program for a specific task in a specific language on a specific compiler targeting a specific CPU platform for a specific CPU model. In practice, we worry more about code readability, code maintainability, and the general-purpose usefulness of the operating system.

Given what I said--that IPC carries about as much overhead as a function call when calling out to another part of the kernel--we don't even have to consider whether that overhead is so negligible as to be ludicrous to account for or whether it's incredibly large. The only practical impact is the same as using OpenBSD versus NetBSD versus FreeBSD versus DragonFly BSD: different approaches are taken in various kernels to solve the same problem, and they all jump through different numbers of lines of code, different interactions (i.e. DIV takes more cycles than SHR), different call traces (more or fewer function calls passing more or fewer arguments), and so on.

In other words: the overhead is on the level that calling it "slower" is an abuse of terms, the same as claiming that the execl() call shouldn't be a wrapper for execve() because it makes the system slower. The practical impact isn't just small; it's smaller than the practical impact of every other factor in the execution of the code in question, and thus has no real implications for performance as an architectural consideration.

SystemD

[CaptainPinko]

Thousands of packages, but the real question is: does it run SystemD?

Re:SystemD

[Anonymous Coward]

Betcha emacs does.

Re:SystemD

[Anonymous Coward]

I hope not.

Re:SystemD

[Anonymous Coward]

systemd is a reason to consider switching from Linux to Minix.

Re:SystemD

[kthreadd]

Unfortunately Systemd is not available on Minix so that's a downgrade.

Re:SystemD

[Anonymous Coward]

hehehe :)

Re: Nothing to see here. ANOTHER Linux CLONE!

[Anonymous Coward]

Check your history. Minix predates Linux by 4 years (1987 vs. 1991).

Re: Nothing to see here. ANOTHER Linux CLONE!

[Anonymous Coward]

THAT'S DECADES!!!

Does Minix have much real-time capability?

[SkOink]

As an embedded-systems guy, I'd _love_ to have a Unix-like where I could schedule events that were guaranteed-by-design to fire within some deadline of when they were scheduled. Then I could host my once-per-kHz hardware service routines on the same processor that was also running my device's web-server.

Minix's microkernel architecture seems like an ideal fit for that kind of use case. If there are any Minix devs reading this thread, how easy would it be for me to make a system like that using Minix?

Re:Does Minix have much real-time capability?

[johanwanderer]

VxWorks?

Re:Does Minix have much real-time capability?

[SkOink]

VxWorks?

VxWorks is a great product. It's also waaaayyy outside of the price range of a hobbyist developer. Getting up and running with the VxWorks suite of tools can easily cost 20k (USD), and the recurring license fees are pretty significant as well. I would also bet that auditing the VxWorks source code (or trying to get custom patches in) would cost significantly more.

Re:Does Minix have much real-time capability?

[tlhIngan]

As an embedded-systems guy, I'd _love_ to have a Unix-like where I could schedule events that were guaranteed-by-design to fire within some deadline of when they were scheduled. Then I could host my once-per-kHz hardware service routines on the same processor that was also running my device's web-server.

Minix's microkernel architecture seems like an ideal fit for that kind of use case. If there are any Minix devs reading this thread, how easy would it be for me to make a system like that using Minix?

Your requirements mean you want a Real Time operating system - one that guarantees execution of a interrupt or other thing within a fixed deadline.

If your deadline is a do-or-die thing, you have a hard-real-time requirement (i.e., it's a failure if you're late, period). if your deadline is more of a "well, please try not to, but under exceptional cases you can be a bit late" then it's firm real-time, and if it's "well, try not to be late, but it's OK if you are" then it's a soft real-time requirement.

(Note: general purpose OSes often do run tasks that do have hard or soft realtime requirements. E.g., responding to a keyboard is generally a soft-to-firm realtime requirement - the user types something and generally expects a prompt response or the system will seem "slow". A hard realtime requirement would be playing back audio where failure to prepare a new block of audio results in a pop/skip/burp of the audio. Or back in the old days, burning a CD. If you didn't keep the buffers full, you'd be out a disc).

Of course, a RTOS guarantees the deadline regardless of load.

And there are a few that are POSIX compliant - QNX for one. There's also RTLinux which runs Linux as a general task within a realtime framework. I'm not sure if RedHat still maintains it, but eCos was an RTOS as well.

And yes, RTOSes are capable of that - handling a 1kHz process plus a webserver at general processing - the RTOS knows it needs to service that task at 1kHz and will pre-empt the webserver as required.

Re:Does Minix have much real-time capability?

[Anonymous Coward]

"Does Minix have much real-time capability? "
Not so far as I know. But it's open source. You could add it. Minix is *very* modular, so replacing the scheduler is no harder than writing a driver for a new device.

Re:Does Minix have much real-time capability?

[Anonymous Coward]

Or back in the old days, burning a CD. If you didn't keep the buffers full, you'd be out a disc

How has this changed?

Re:Does Minix have much real-time capability?

[n6kuy]

RTEMS, then.

Re:Does Minix have much real-time capability?

[Anonymous Coward]

Nowadays DVD/BD burners all contain internal indexing circuitry to continue interrupted writes on optical disc as if nothing happened. Back in the old CD-R days, this tech was only available in expensive Plextor brand burners, but their patent has expired in the meantime.

Re:Does Minix have much real-time capability?

[BitZtream]

Yes, modern drives don't have a problem waiting and resuming writing once data arrives, and thats been true for god knows how many years.

Re:Nothing to see here. ANOTHER Linux CLONE!

[Obscene_CNN]

you forgot to mention its slow too

Should be 0.14us

[Megol]

Should be 0.14us as per the title

Let's be different

[spaceyhackerlady]

I've followed Minix development with interest. The internal architecture is different from most OSs out there. Not different for the sake of being different, but different to show different solutions to problems. The way we do things in Linux et al is powerful, but it's not the only way.

I haven't come up with a compelling reason to use it in my work (yet... :-), but I install each new release on a virtual machine and play with it.

...laura

Hurd, is that you?

[leandrod]

Will be this the real Hurd?

Re:Hurd, is that you?

[unixisc]

No, this is BSDL, where as Hurd would be GPLv3

So... I tried it...

[Anonymous Coward]

...As a boot CD. "Small" meant 600 Meg on the CD. On one x86 system it didn't recognize the USB keyboard. On another, it went through all sorts of contortions looking for the CD. At boot it said, "Ignore error messages." Maybe it's a good operating system for the next robotic vacuum cleaner, but not anything else.

Good.

[Anonymous Coward]

Linux is finished then, 22 years later.

Re: Nothing to see here. ANOTHER Linux CLONE!

[jeremyp]

It's a decade to an order of magnitude.

Minix underpinnings

[unixisc]

How so? As opposed to making it compatible w/ FreeBSD, which is a lot more popular?

I welcome the addition of Beaglebone support, but would like to see support spread to Arduino and Raspberry Pi platforms. Minix won't be a first choice for any laptops, but it sure can be the first choice of these cards, where the small footprint actually helps.