Fiasco Microkernel Version 1.0 Released

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

Obligatory 'talking out of arse' comment

[twilight30]

... Wasn't the L4 microkernel meant to be an alternative, future base for the HURD (currently based on a GNU implementation of Mach, IIRC)? Has Marcus or anyone else had the chance to look at this yet? If so, what do they think?

Re:Obligatory 'talking out of arse' comment

[KayEyeDoubleDee]

There are already a bunch of L4 implementations [tu-dresden.de] out there with varying degrees of availibility and licensing and some using version 4 of L4 ABI are due out soon...

Re:Obligatory 'talking out of arse' comment

[paladin_tom]

Neal H. Walfield is in charge of porting the Hurd to L4. He's waiting for the Pistachio implementation to be released (which is promised to be soon [l4ka.org]).

L4 is independent of the Hurd. It's a research-project started by Prof. Jochen Lietdke. It's performance seems to be good (unlike Mach's), and its structure is very different from that of Mach, so the Hurd developers want to port the Hurd to L4.

I can't believe it!

[felipeal]

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

Hooray for C++!

[Anonymous Coward]

Finally, a kernel written in a high-level language. This is going to make the nontrivial subsystems like VM and buffer cache MUCH cleanier, easier to debug, and ultimately, easier to improve.

Re:Hooray for C++!

[Pseudonym]

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

Re:Hooray for C++!

[Pseudonym]

I disagree. Common Lisp is a good choice for some kinds of OS. C++ is a good choice for others.

One issue with Common Lisp, for example, is that in a loaded OS, resources must be freed as quickly as possible. This means that you have to use a real-time garbage collector. This means extra accounting associated with each object and worse cache performance. This may not be a "problem" in general, but it's an issue to take into account.

BTW, I'm a functional programmer by design, but I like C++. It's not

Re:Hooray for C++!

[Anonymous Brave Guy]

Sorry, I can't resist destroying this post point by point.

[C++] 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.

You don't know much about how to write C++, do you? Sure, for really low level code, a lot of it will be the sa

Re:Hooray for C++!

[Pseudonym]

This isn't entirely true, of course, as there will always be some people who don't like or feel the need for things like OO, and who value the simplicity of C. For everyone else, the only remaining credible reason to stick with C over C++ is that its compilers optimize better, so it still has a slight performance edge, and even that gap is closing fast as C++ compiler technology evolves.

I think this is overstating it just a tad.

Off the top of my head:

• Generated code is generally smaller, I believe due to

Re:Hooray for C++!

[Anonymous Brave Guy]

c will have a long life in the embeddedspace. Little chips like the PICs, AVRs, 68H11s, and even the 8051s are programed in c or asm.

But mainstream microprocessors are being used more and more often. Economies of scale mean they often cost a comparable amount these days, and clearly they are easier targets for development.

C++ is just too big for 8k devices.

That's obviously not true, of course. If you can write for it in C, you can write for it in C++. Just don't use the extra features unless you r

Re:Hooray for C++!

[Pseudonym]

Fiasco is an L4 microkernel. It doesn't have buffer cache, and it only barely has VM, too.

One of the good things about L4, though, is that it provides the bare necessities (threads, IPC and address spaces) and the rest is up to you. You can your file system code in whatever language you like.

huh?

[GigsVT]

How can you call it Linux, if it doesn't use the Linux kernel? Wouldn't it just be Another GNUish System?

Re:huh?

[Anonymous Coward]

It does use the Linux kernel, silly. It's running in user space on top of L4, alongside other L4 apps. So Linux apps run in user-user-space. Hey, maybe if L4 was ported to L4, apps would run in user-user-user-...-space.

How metacircularity is useful in practice

[yerricde]

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 [sourceforge.net] and the new Plex86 [sourceforge.net] for more info.

Re:huh?

[Bob The Cowboy]

MMMMMmmmmm..... ganoush [google.com].

This is lovely

[0x0d0a]

As far as I can tell, the only practical impact of this is a slap in the face to the HURD developers, who have just been bypassed by yet *another* kernel project...

Re:This is lovely

[Ben Escoto]

As far as I can tell, the only practical impact of this is a slap in the face to the HURD developers, who have just been bypassed by yet *another* kernel project...

This project isn't a competitor to the hurd. The HURD is a bunch of services that need a microkernel to run on top of. So if anything, HURD developers should be happy, because they now have the option of porting their kernel from Mach to the theoretically speedier L4.

Where's the innovation?

[Wesley Felter]

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.

Re:Where's the innovation?

[Hard_Code]

nothing interesting [apple.com]?

Re:Where's the innovation?

[Wesley Felter]

OS X uses some Mach code, but it doesn't use a microkernel. And OS X is architecturally not very interesting; it's basically yet another Unix.

Good idea, questionable implementation

[Anonymous Coward]

Ever try to hack linux? It is cryptic, convoluted, bloated, pretty much awful code. No good docs for it, and even if there were good docs for it they are quickly out of date because the core linux contributors all get together and change everything every few months. There is only one way to figure out how to do stuff and that is to study the awful, cryptic code. The newsgroups + mailing lists don't work, people don't answer the deep technical question you ask.

So here's the idea: Have a tiny micro kernel, a