Slashdot Mirror

So why did NeXT use Mach in the first place? I'm speculating again. I guess they started out from OSF/1, and the OSF/1 developers had your goals (a) and (b) in mind.

Remember: The Open Software Foundation (OSF, now a merged with the Open Group) was a group of vendors that wanted to develop an Unix platform independent from then-AT&T's UNIX. OSF/1 was to be their kernel. DEC used it to build DEC OSF/1 (now Compaq Tru64 UNIX or whatever it is called this week), and I guess that NeXT took it to build NeXTStep.

The first version of OSF/1 (the one out of which vendors made successful products) was a BSD single server on top of Mach 2.5. At the time it was developed, it was not yet well established that Mach-based systems are slow. In fact, the Mach-2.5-based OSF/1 probably was not that slow: Mach 2.5 had considerably less bloat than Mach 3.0, and it was not really a microkernel-based system as it was closely integrated with a BSD kernel - that is, the microkernel and the BSD server shared the kernel address space (this is sometimes called ``colocation''; the OSF recently rediscovered this technique to speed up MkLinux on top of Mach 3.0). Only with the advent of Mach 3.0, the first ``real'' microkernel, people started to notice that there is something wrong with Mach's original approach.

That said, it does not necessarily follow that microkernel-based system, or even Mach-based systems in particular, need to be slow. I do microkernel-related research myself, and my group has shown with L4Linux that a Unix single server can be implemented with very reasonable overhead on top of a ``real,'' second-generation microkernel - in this case, L4 (macrobenchmarks indicate that L4Linux has an overhead of about 2% to 3% when compared to the original monolithic Linux kernel).

I do not really know MacOS X's architecture well enough to give a well-informed statement, but my guess is that they have enough talent to avoid the most stupid mistakes.

• Pricing.

  It is notoriously difficult to get pricing information for QNX.

  I have heard differing reports on comp.os.qnx, including that it is "very expensive, hundreds of dollars per system," or, on the other hand, the vague answer of "you can license it reasonably economically." (With no definition of what "reasonably economical" means, of course.)

• If people should start thinking of QNX, then they should also start thinking of:
  • VSTa

    A copylefted system that "lifts" ideas from QNX and Plan 9

    It looks like development has not been terribly active lately.

  • MIT Exokernel

    Again, not terribly active, but an interesting OS kernel.

  • EROS

    Eric Raymond thinks it's mindblowing, so the Eric Raymond Personality Cult should all be preparing to drop Linux in favor of EROS. (Of course, it isn't yet capable of self-hosting, which indicates that it's not all that useful at this point. But, to cultists, usefulness is irrelevant...)

  • Possibly even Hurd

    It's different from the other options; certainly not a tiny OS option...

  • eCos
  • RTEMS

    Which, like QNX, appears to be used in some reasonably critical system environments...

  • Fiasco

    Which is a "lighter microkernel than Mach"...

  • On Linux, people interested in QNX should almost certainly look at SRR -- QNX API compatible message passing for Linux

    This is the critical programming abstraction that QNX uses heavily which isn't all that widely used on traditional UNIXes, namely asynchronous messaging.

  These are all interesting alternatives, albeit not all being of identical levels of interest.

It also supports several growing network architectures developed by Bernd Fritzke et al. There's also a Java demo of growing networks, with code available. It's fun to change the input probability distribution and watch the nets adapt on the fly!

J.

There's a real need for an open-source real-time protected-mode operating system, but Linux, or any UNIX variant, isn't it. L4 has real potential, but it's not finished yet. Already you can run Linux on top of L4. If you're into embedded open-source real-time, get behind L4 and push.

What do you think about EROS then?
Unfinished. As the authors put it, it's at the "hello world" stage. The primary author got his degree and graduated.

I was looking seriously at EROS and L4 for some real-time work, but neither is really usable yet. QNX is fast, elegant, reliable, and successful, but it's sold only on terms that make sense if you're building it into something; there's a big up-front cost. There's no clean, usable, secure open-source solution that doesn't have a bloated kernel. (RT/Linux isn't the answer; it's a hack that allows you to add your real-time application to the kernel.)

One very real problem is that very few people know how to write for a message-passing system. You have to divide up your program into isolated communicating processes with different security and timing properties. These processes communicate only by message passing, but the message passing is much faster than UNIX programmers are used to. UNIX and Windows programmers aren't used to designing this way. It's as big a change as going to object-oriented programming.

EROS has the additional problem that the capability crowd tends to be incomprehensible. Norm Hardy, the creator of KeyKos, was known for his impenetrable talks. (He used to have an "explainer", Susan Rajunas) What's needed is something like a well-documented secure web server using a capability-based OS. Then people might pay attention. But EROS isn't finished enough to even start that project.

UNIX/Linux isn't getting more secure. The CERT advisories look about the same as they did ten years ago. Holes in Sendmail. Holes in BIND. Holes in "rsh". Set-UID-to-root problems. No amount of hacking on the UNIX architecture will help. You've got to have a system with far less trusted code. It's possible. Multics did it.

It isn't entirely a Linux version, but "A key component is L4Linux, the Linux server on top of the L4 microkernel; it services standard Linux applications. In addition, separate real time components - designed from scratch - provide deterministic service to real time applications." (They also have their own GPL'ed implementation of the L4 microkernel

It isn't entirely a Linux version, but "A key component is L4Linux, the Linux server on top of the L4 microkernel; it services standard Linux applications. In addition, separate real time components - designed from scratch - provide deterministic service to real time applications." (They also have their own GPL'ed implementation of the L4 microkernel

It isn't entirely a Linux version, but "A key component is L4Linux, the Linux server on top of the L4 microkernel; it services standard Linux applications. In addition, separate real time components - designed from scratch - provide deterministic service to real time applications." (They also have their own GPL'ed implementation of the L4 microkernel

--- Here instead

And it's all open source.

I haven't tried L4, but it's worth a look.

The L3 URL should have read: http://os.inf.tu-dresden.de/L4/l3.html

This conecpt has been implemented before in L3.

Uli Luckas

If your system was powered down in the middle of a database update after reboot the update continued, where it was interrupted. No DB curruption!

L3's persistence implementaiton was based on two 'lazy' copies of the virtual memory. One of a consisten state and the ther one was the working copy. That is the first time you change a memory page, it is copied. The after a fixed interval, an new lazy copy of working memory becomes the new 'consisten' state copy.

My question to the public is wouldn't this be a desirable thing to have in Linux? And the question do the developers does that seem a hard thing to implement?

It seems like a simple concept. But there seems to be a huge pile of implications for the kernel drivers. A process might even be in a system call when the system wakes up again.

I am verry ecited to hear your comments.

Uli Luckas

For people interested in learning about persisence in real life situations, there is a paper entitled A Persistent System in Real Use - Experiences of the First 13 Years.

• RISC or not is about arcitecture, not implementation
• RISC is really about having an architecture whose instructions pipeline cleanly, and which responds to the demands of actual workloads.

If you take the point of view that a P6 is a RISC core running an x86 interpreter, then still the user-visible architecture is not RISC. It would only be RISC if you let me program the core directly with its native micro-ops. "Hannibal" still doesn't understand this distinction between architecture and implementation.

John Mashey of MIPS/SGI has written a good description of the differences between RISC and CISC architectures. It is posted to comp.arch on an irregular basis and is available on the web here.

Some things to check out:


The Anonymizer
Surf the Web anonymously

Replays Anonymous Remailers
Send email anonymously

Onion Routing
Onion Routing allows you to send IP packets anonymously.

SSonet
Multilevel security in computer networks.

• to have lots of registers
• not to have ccomplex addressing modes (to have a "load-store architecture"; by contrast, there is a worst-case indirect-idexed VAX (CISC) instruction which can generate 43 page-faults before it completes executing. That plays hell with pipelining!)
• have fixed-size (often 32-bit) binary instruction format, for easy decoding
• possibly to have alignment restrictions on memory operations.

One view of what Intel is attempting with its forthcoming Merced is to take these RISC ideas, and extend them by demanding that the compiler perform instruction-to-instruction dependency checking, and then format them into "bundles" of instructions that can all be safely issued at the same time.

fwiw

L4 Linux is one of the most interesting technologies under development. Check out their WEBSITE. It really works.

I have used Linux running on top of the L4 microkernel, and it is not crippled.
Check out the web page of the L4/Linux project:
http://os.inf.tu-dresden.de/L4/LinuxOnL4/

It was Dresden University of Technologie. Have a look at http://www.inf.tu-dresden.de/D4D/ for more Information.

Jean