Slashdot Mirror

← Back to Stories (view on slashdot.org)

Fiasco Microkernel Version 1.0 Released

Posted by timothy on from the freedom-of-choice dept.

'lonzo writes "Version 1.0 Fiasco, a GPL re-implementation of the L4 microkernel has recently been released. This microkernel is designed to be a flexible hardware abstraction layer rather than YetAnotherCloneOfUnix. Its 'mechanism not policy' design allows far more opportunities for *ghasp* innovation than any of the Unix clones. It also provides people with an alternative to the macrokernel design of Linux. Get your copy here. Linux has already been ported to this OS, get it here, and another port."

4 of 29 comments (clear)

  1. I can't believe it! by felipeal · · Score: 3, Funny

    Fiasco Microkernel Version 1.0 Released
    So, Hurd is finally out? WOW!!!

  2. How metacircularity is useful in practice by yerricde · · Score: 4, Informative

    Hey, maybe if L4 was ported to L4, apps would run in user-user-user-...-space.

    Having a metacircular operating system (one that can run as a user process within another instance of itself) is actually useful, as it allows for virtualizing a machine. This can make server configuration and isolation easier (which is why it's common on mainframes), and it makes kernel debugging a lot easier. Look at User Mode Linux and the new Plex86 for more info.

    --
    Will I retire or break 10K?
  3. Where's the innovation? by Wesley+Felter · · Score: 3, Insightful

    Its 'mechanism not policy' design allows far more opportunities for *ghasp* innovation than any of the Unix clones.

    I agree, but where is it? The L4 crowd, like Mach before them, spent so much time building the microkernel that they haven't built anything interesting on top of it.

  4. Re:Hooray for C++! by Pseudonym · · Score: 3, Interesting
    There are two high level languages suitable for writing operating systems: C and Ada.

    A sensible person would stop reading here, but I'm not sensible. The most suitable language for writing a given OS depends highly on internal (e.g. features) and external (e.g. linkability) constraints. We used to have operating systems written in assembler, PL/I and Oberon. Nowadays we have boot PROMs written in Forth. All of these decisions were certainly justifiable at the time.

    Incidentally, I used to say pretty much the same things that you do about C++, until I wrote my first nontrivial application in C++. Nowadays I'm not a C++ zealot, but I'd far rather hack in C++ than in C any day.

    It doesn't offer anything over a well written C program. If you write two identical programs on the same level as an OS in both C and C++, you'll end up with a lot of lines of code being about the same. Going through the extra trouble (and compilation overhead) involved in C++ isn't worth the bother when 99% of the code is the same.

    Pull up your Linux source and have a look at fs/pipe.c. Scroll down to do_pipe. Stare at the code for a moment. All those gotos didn't write themselves.

    Now scroll up to the file_operations structs. What you're looking at is a bunch of virtual function tables.

    This type of code may not be much shorter in the equivalent C++, but it's going to be a lot more than 1% different, and the difference is almost all going to be in maintainability, which is far more precious than number of lines of code.

    Factually, C++ is the most used programming language there is, but to a first approximation, all of this code is for Windows, and I don't count Windows.

    I don't know where you've been. There are lot more job placements for Unix C++ programmers than Unix C programmers.

    --
    sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});