"B. Douglas Hilton" <[EMAIL PROTECTED]> writes: > I am thinking that the Mach uKernel is severely hampering > the Hurd project. As lond as Hurd only relies on mach.h it > would be very effective to rewrite oskit-mach in Ada.
I don't think rewriting any or all pieces in a different language would help much. I think there is some agreement that Mach is suboptimal, in more fundamental ways. Mach is the µ-kernel that works with the Hurd today. If you want to replace it, I would recommend that you try helping the hurd-on-l4 project. To get hurd-on-l4 moving, I think the most urgent tasks (please correct me if I'm wrong) are, in order: x Porting libports to l4, and/or figuring out how to change the Hurd's ports abstraction to be less mach-centric and still fit the Hurd's needs. x Implement a threads library to work around the l4 limitations on the number of threads. The thread implementation on Solaris (which multiplexes n user pthreads on top of m kernel threads, n > m) should provide some ideas. x Implement similar multiplection for user tasks on top of kernel tasks. The debian-hurd list is probably not the right place for discussion about the l4 track, though. As for language wars, I believe C is the language of choice for systems programming on the GNU system, and I don't think that will change anytime soon. Not that I want to stop you from rewriting HURD-related stuff using your language of choice, but I believe there are better ways to help moving the Hurd away from its current µ-kernel, Mach. Best regards, /Niels