Hallo! Meh, for forwarding (moderated) messages from one mailing list to another by using the Mailman web interface, one apparently needs a Judo black belt or something.
Now adding back Rick to the recipients' list. <bug-hurd@gnu.org> or <help-h...@gnu.org> are suitable lists for such questions. On Wed, 04 May 2011 15:28:46 -0400, hurd-devel-boun...@gnu.org wrote: > I've been a lurker here for some time. I've tried to keep up with the > status of this project, but to me it's confusing. Do these summaries help to stay up-to-date? <http://www.gnu.org/software/hurd/index.html#index1h1>. > Where are we on Hurd development? > > No 64-bit kernel? Correct. > A working 32-bit kernel? Correct. > No VM extensions? What exactly do you mean here? > In theory, provided Linux apps use standard protocols for core function > calls, shouldn't all software work with hurd's kernel (if it's working > well)? Correct, if we're talking about C library, POSIX, or similar programming interfaces, and anything below it, and if the applications use these interfaces exactly as described, and we implement them exactly as described. (As you can easily guess, there is a gray zone involved on all sides.) > Including drivers? At a first approximation, an operating system's device drivers are (typically) implemented in the kernel, thus above the layer quoted just before, so they are specific to the kernel implementation. GNU Mach does have a few device drivers, but they're rather old -- yet they are rather solid for basic stuff like IDE hard disks, or Ethernet network cards. Work has been done (DDE project) to improve this: to move the device drivers out of the kernel, and instead rely on Linux device drivers, but run these as regular user-space tasks, but this is currently stalled due to time constraints. > Where are we on hurd development? Does that help? <http://www.gnu.org/software/hurd/#index5h1>, <http://www.gnu.org/software/hurd/hurd/status.html>. Grüße, Thomas
pgpo8N3e5oLy6.pgp
Description: PGP signature