HURD developer Marcus Brinkmann made a historic step and finished the process initialization code, which enabled him to execute the first software on HURD-L4.
First Program Executed on L4 Port of GNU/HURD
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Now we’re able to run SOFTWARE on HURD.
What a feat!
Dr. Jochen Liedtke’s got some guts, to call his first Kernel EUMEL. I don’t know what part of Germany he’s from but where I’m from that means Boobs…
does this mean that HURD is actually progressing? Aren’t several forks of HURD now? I would love to see HURD completed eventually… just to put an end to the embarrassment that it is. I mean if DragonflyBSD becomes enterprise ready before HURD becomes a viable-desktop-alternative than that would horrendously embarrasing for the HURD team.
Does anyone think this is a majour milestone or an non-event?
Does anyone think this is a majour milestone or an non-event?
programs can launch now.. yeah, i’d call that a major milestone in an OS’s developement.. how could it be a non-event?
GNU should throw their efforts into Darwin, not HURD.
After having said something rather useless, let me explain why this is important.
There aren’t enough HURD developers to develop the HURD and GNU-Mach, so GNU-Mach has bin stagnating. It has old Linux 2.0 drivers only, the OSKit port is more or less dead, so no chance at getting Linux 2.2 and FreeBSD drivers into the GNU-Mach. L4 has a functioning port of Linux 2.4 drivers. Also the L4 community is active and the HURD developers wouldn’t be stuck maintaining an old microkernel like they are with Mach. The HURD developers believe (and this is probably true) that the L4 port will speed up the HURD since the L4 port of Linux is a lot faster then the Mach port. Also the HURD is rather tied to MACH by porting it L4 they hope to gain Microkernel independence, a goal that the HURD always had, but didn’t materialize.
Hope this helps to explain some things to you guys.
Eugenia,
perhaps linking to the original article which was posted on Tuesday on kerneltrap would be more beneficial.
http://kerneltrap.org/node/4658
just because its slashdot, doesnt make it news.
🙂
Darwin is useless for the HURD and GNU didn’t want to support it because of its license. After apple changed some parts of the license GNU accepts it grudgingly but doesn’t recommend it for new projects.
Now tell me why should a project that is out to produce free software get together with a company out to make a profit? And how do you want to force volunteer to work for not for a company that makes millions?
Boy, stop you wishful thinking.
What license is L4 microkernel under? The GPL? If so, then I wouldn’t say its such a big deal to the FSF…
Way to go Markus!
How far off are Network and Desktop Environments? Relatively easy or hard?
I recall reading a while back that there are a number of Debian developer folks interested in applying their specialty skills to complete a Hurd based system.
L4 is not a kernel, it is a kernel specification. There are several implementations under several licensees written in several languages for several platforms. Pistachio, the L4 implementation used by HURD, is licensed under the BSD license and written in C++. For more info go to
http://os.inf.tu-dresden.de/L4/impl.html
According to this there seem to be several implementation of the L4 ‘architecture’, by different groups and under different licences:
http://os.inf.tu-dresden.de/L4/impl.html
If it can run on the L4 microkernel does that mean it can run on any of these implementations?
DOpE (Desktop Operating Environment) on the real-time OS DROPS (Dresden Real-Time Operating System Project) based on the L4 microkernel Fiasco looks nice: http://os.inf.tu-dresden.de/dope/screens.xml
Thats strange, on the implementations page, TU Dresden have a ‘i486 or better’ L4 microkernel Fiasco release under ‘GPL or commercial’, but at http://os.inf.tu-dresden.de/L4/l4down.html it states “the owner of L4/i486, “advised” us (TU Dresden) to stop the redistribution of the L4/i486 micro-kernel”
Is this why they are not using the GPL version? Because otherwise, the details seems to indicate and give the impression that Fiasco is the best implementation.
Fiasco is rather old, and errors where maid. Other L4 implementations learned from those mistakes and tried to avoid them. The other thing is that Fiasco, since it is so old doesn’t support the newer L4 protocol. I don’t think it is developed anymore either.
Nobody is going to use HURD. It is a fanciful waste of effort with the energies best spent elsewhere.
damn, made not maid…
“Now tell me why should a project that is out to produce free software get together with a company out to make a profit?”
I’m sorry this is just too funny for me to pass up. What do you think about IBM or Novell or Red Hat? ^^
Thanks, so the info about Fiasco being the best L4 implementation around must be dated then.
So what is wrong with the GNU Mach microkernel that it was running on before moving over to the L4 microkernel. They’re micro, Ok they take some work to code, but I thought the real hard work came with all the the code that builds on top of the micro-kernel like FSs etc right?
IBM and Novell are riding a train; Red Hat got it’s start in the community, and is still a good member. GNU and IBM and co have something in common, not that GNU wants to help them make money. That would be the case if GNU would throw everything down and start working on Darwin as was suggested. GNU are working on their software because they want to improve said software, not so that others can make money of off their work.
I explained that in my earlier posting, Mach is really old and un-maintained. The drivers are outdated and there is more code overhead then the HURD uses, and Mach is slow when compared to L4. So by porting it over they hope to have a microkernel they don’t have to maintain, have more drivers for, makes it easier to port to non x86 architectures and provides them with a speed up. Also it would make the code more portable between different microkernel’s, that was an original goal that the HURD hasn’t achieved since it is bound rather strongly to Mach.
Hope this helps you understand.
Rock on dudes! Now that is a milestone to be proud of, glad to hear they’re still keeping the faith. A most worthy project, kudos!!
So who doesn’t like german boobs? In the states we call that target marketing.
<<Dr. Jochen Liedtke’s got some guts, to call his first Kernel EUMEL. I don’t know what part of Germany he’s from but where I’m from that means Boobs…>>
Just think of the mascot.
I might even get interested in developing for it now that it isn’t running on Mach. I see HURD being strong on the server. For example, databases run suboptimally on just about every unmodified linux box because the LRU paging strategy is plain wrong for database memory usage. People try to fix this by making a custom Linux build with a different paging strategy, but this means your web server (and the apps that run under it) will run suboptimally because the database specific paging strategy is just plain wrong for them. The correct way to solve this is to put the paging strategy under the control of the userland application. That way the database can override the “default” pager and handle its own virtual memory.
HURD could also be strong on the desktop. The additional security and stability provided by a microkernel makes it possible to implement a more clean seperation of processes (even if they are run by the same user, which is what a desktop environment is all about).
Interesting times ahead.
Is ther someone who could intelligently comment on the way a microkernel architecture and a cell processor might “mesh or perhaps play together?
Seems like an interesting idea.
I don’t know why it would mesh particularly well. There is very little information on Cell’s memory architecture (virtual memory, protection levels, that sort of thing), so it’s very hard to say what sort of OS would be best suited for the architecture. The individual APUs are self-contained, don’t multitask, and do timing control and synchronization in hardware, so they don’t really need any OS support beyond a mechanism for uploading cells to the local storage.
It’s not clear what kind of communication capabilities APUs have. If they are very simple, you might not want to do any sort of system calls from APUs at all. If they are a bit more sophisticated, you might want to use some sort of RPC to invoke system calls from the APUs to a kernel running on the PUs. It probably wouldn’t be a good idea to run a standard shared kernel-space OS on the APUs, since the kernel code would likely reside in main memory, and since the APUs have no cache, instruction fetch would be terribly slow. Also, it’s not clear if the APUs are sophisticated enough to perform well on kernel code. For performance reasons, you might want to run kernel code on the PUs anyway. Rumor has it that Sony and IBM will be running an RTOS on Cell.
“…waste of effort with the energies best spent elsewhere.”
like commenting on osnews? or drinking beer?
come on, these developers have great hobby, show some respect!
Hello,
I understand the whole discussion so far, that Mach is outdated compared with L4. Does it make any sense to replace Mach with L4 on Darwin? What exactly has to be replaced then? I suppose all the drivers, but what about programs in userspace? Will they stay binary compatible? As far as I understand programs in userspace have quite nothing to do with Mach, because they interact with BSD compability layer, right? What about the drivers? Do they rely on Mach or is this BSD compatibility layer enough for them to work?
Thanks
Anton
No, replacing Mach on Darwin with L4 makes no sense whatsoever. Apple spent a lot of money modifying Mach for Darwin, the hole driver infrastructure is really nice and I’m not sure where kernel extension get bound into the system but I guess it is Mach. So unlike GNU with its old and crappy Mach version apple has a nice one. Also the Unix/FreeBSD personality is a single server, so porting it to L4 would still not give you a real Microkernel, just a monolithic single server running on a minimalist microkernel, nothing gained. The only real advantage would be gaining speed, but from what I’ve heard they aren’t really using mach as a real microkernel and just lumped everything into kernel space.
Overall it look as if Apple is heading towards a modular or maybe layered kernel design, not really a microkernel.
<ii>So unlike GNU with its old and crappy Mach version apple has a nice one.[/i]
Wrong. GNU Mach is based on Mach 4.0. The original OS X server was based on Mach 2.5, though with the first release of OS X desktop (10.0), they imported a lot of code from Mach 3.0.
Did you ever look at what the University of Utah did to make Mach 4.0? And did you look at what Gnu changed afterward? Did you ever look at Yamit, or MK++? Fact is Mach sucked, it sucked so much that Yamit rather use 2.5 then 3.0 (because the programmer believed the code to be better) and MK++ rewrote the whole thing from scratch. Apple has had lots of time, 2 mach versions and a tone of OS people from their other operating system projects to work on their version of mach. Just because their kernel was forked from a earlier version number then GNUs doesn’t mean the kernel is better.
The L4 Headquarters:
http://www.l4hq.org/