First Program Executed on L4 Port of GNU/HURD

wikinerd writes "The GNU Project was working on a new OS kernel called HURD from 1990, using the GNU Mach microkernel. However, when HURD-Mach was able to run a GUI and a browser, the developers decided to start from scratch and port the project to the high-performance L4 microkernel. As a result development was slowed by years, but now 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. He says: 'We can now easily explore and develop the system in any way we want. The dinner is prepared!'"

Comments

Re:It hurds

[mirko]

The Hurd Project was started in 1983 (it's an instrumental featuring the speech where Stallman explained the origin of the GNU project).
Now, 22 years later, a definitve breakthrough has been performed.
I see this as an excitement :

1. They kept working on it THAT long despite slandering and scepticism such as yours
   
2. The rest of the software library (glib, bash, etc.) is already ready
   
3. With Linux, Hurd and BSD amongst others, we are slowly getting back to the same variety we had 20 years ago, when we had to exchange basic listings and to port these onto various platforms (Sinclair, Commodore, Amstrad, Sharp...)
   

Now, we will see it emerge and, why not, get sufficient audience to become unavoidable. In 20 years from now, it'll be like it's an opportunity as weel as any other so it's not missed, it just took time to emerge, like my favourite whisky.

Re:Mach Microkernel vs L4

[js7a]

L4 has only seven system calls, compared to several dozen in Mach. It fits in about 32KB, too, which is very much smaller than Mach.

But the small size doesn't make most systems faster. Running the same Unix API, L4 adds execution time overhead beyond the default monolithic Linux kernel, about 5%. (Does anyone know the figure for Linux-on-Mach? I know it's much greater than 5%....) However, there are some significant advantages having to do with debugging, maintainability, SMP, real time gaurentees, memory management, configurability, robustness, etc. Detailed discussion here.

From the overview:

Kernels based on the L4 API are second-generation -kernels. They are very lean and feature fast, message-based, synchronous IPC, simple-to-use external paging mechanisms, and a security mechanism based on secure domains (tasks, clans and chiefs). The kernels try to implement only a minimal set of abstractions on which operating systems can be built flexibly.

Other links: L4KA homepage, background info, more info with some historical L3 links.

Frankly, I think L4 is very much the right way to do things. I wish I could say the same for other parts of HURD.

Great

[Pan T. Hose]

When the first programs run, it is just a matter of time before there is a functional L4 port of Debian GNU/Hurd (or just Debian GNU?). I really like the design of the Hurd, but what I'd like to see the most are not the "POSIX capabilities" but the real capabilities as described in the 1975 paper by Jerome Saltzer and Michael Schroeder, The Protection of Information in Computer Systems. (For those who don't know what am I talking about, I recommend starting from the excellent essay What is a Capability, Anyway? by Jonathan Shapiro, and then reading the capability theory essays by Norman Hardy. As a sidenone I might add that I find it amusing that people who say that there are other advantages than only Digital Restrictions Management of using TCPA/Palladium-like platforms usually quote security features, which have already been implemented in the 1970s, only better and with no strings attached. Those TCPA zealots are usually completely ignorant of the existance of such operating systems as KeyKOS or EROS with formal proofs of correctness without all of the silliness.) Are there any plans to have a real capability-based security model available in the Hurd?

Re:Benchmarks?

[Malor]

If the system is able to stay up without further drive access, that could potentially allow you to copy data still in RAM. If the OS simply instantly failed when the HD controller went, then any data in RAM would absolutely be lost.

Software failure is more common than hardware. In many cases, drivers can be restarted. Your specific example is probably the toughest one I can think of offhand... you'd have to have a copy of the HD controller cached somewhere to be able to restart it. (since, obviously, you can't load it from HD :)). But most drivers wouldn't be that hard to restart... video and network are two very good examples. I have seen many 2.4 kernel crashes from what appeared to be network-driver failures. Presumably, a microkernel might have survived whatever the problem was.

You also, of course, have the advantage of each driver/process running in its own address apace, which would probably make very complex code, like the 2.6 Linux kernel, more manageable.

Just as an offhand observation, I kind of wonder if the 2.6 Linux kernel isn't approaching the level of diminishing returns... it's gotten so complex that it's getting pretty tough to cleanly improve without blowing a lot of stuff up. A microkernel design would probably have made maintenance easier, and *probably* would have given us more stable systems now.

But they didn't go that way, and restarting Linux kernel development would be pretty stupid, IMO. :-)

Re:More interested in development

[osierra.com]

This is best illustrated by the parable of the OSs and the gun:

• With Unix you shoot yourself in the foot.
• With DOS you keep running up against the one-bullet barrier.
• With MS-Windows the gun blows up in your hand.
• With MacOS it's easy to shoot yourself in the foot -- just point and shoot.
• With SVR4 the gun isn't compatible with your foot.
• With Linux generous programmers from around the world all join forces to help you shoot yourself in the foot for free.
• With HURD you'll be able to shoot yourself in the foot Real Soon Now.