12 files changed, 164 insertions, 99 deletions
diff --git a/hurd/bootstrap.mdwn b/hurd/bootstrap.mdwn
index c77682b9..76ad0dc5 100644
--- a/hurd/bootstrap.mdwn
+++ b/hurd/bootstrap.mdwn
@@ -19,101 +19,111 @@ this text.  -->
 
 # State at the beginning of the bootstrap
 
-Please note that as of May 2024 this document is out of date.  It does
-not explain how rumpdisk or the pci-arbitor is started.  Also consider
-reading about [[Serverboot V2|open_issues/serverbootv2]], which
-is a new bootstrap proposal.
+Also consider reading about [[Serverboot V2|open_issues/serverbootv2]], which is
+a new bootstrap proposal.
 
 After initializing itself, GNU Mach sets up tasks for the various bootstrap
 translators (which were loader by the GRUB bootloader). It notably makes
 variables replacement on their command lines and boot script function calls (see
-the details in `gnumach/kern/boot_script.c`). For instance, if the GRUB
-bootloader has the following configuration:
+the details in `gnumach/kern/boot_script.c`). For instance, the GRUB
+bootloader can have the following typical configuration:
 
     multiboot       /boot/gnumach-1.8-486-dbg.gz root=device:hd1 console=com0
-    module          /hurd/ext2fs.static ext2fs --readonly \
-                    --multiboot-command-line='${kernel-command-line}' \
+    module          /hurd/pci-arbiter.static pci-arbiter
                     --host-priv-port='${host-port}' \
                     --device-master-port='${device-port}' \
+                    --next-task='${acpi-task}' \
+                    '$(pci-task=task-create)' '$(task-resume)'
+    module          /hurd/acpi.static acpi \
+                    --next-task='${disk-task}' \
+                    '$(acpi-task=task-create)'
+    module          /hurd/rumpdisk.static rumpdisk \
+                    --next-task='${fs-task}' \
+                    '$(disk-task=task-create)'
+    module          /hurd/ext2fs.static ext2fs --readonly \
+                    --multiboot-command-line='${kernel-command-line}' \
                     --exec-server-task='${exec-task}' -T typed '${root}' \
-                    '$(task-create)' '$(task-resume)'
+                    '$(fs-task=task-create)'
     module          /lib/ld.so.1 exec /hurd/exec '$(exec-task=task-create)'
 
 
-GNU Mach will first make the `$(task-create)` function calls, and thus create a
-task for the ext2fs module and a task for the exec module (and store a port on
-that task in the `exec-task` variable).
+GNU Mach will first make the `$(task-create)` function calls, and thus create
+a series of tasks for the various modules, and assign to the `pci-task`,
+`acpi-task`, `disk-task`, and `fs-task` variables the task ports for each of
+them. None of these tasks is started yet.
 
 It will then replace the variables (`${foo}`), i.e.
 
 * `${kernel-command-line}` with its own command line (`root=device:hd1 console=com0`),
 * `${host-port}` with a reference to the GNU Mach host port,
 * `${device-port}` with a reference to the GNU Mach device port,
-* `${exec-task}` with a reference to the exec task port.
+* `${acpi-task}` with a reference to the acpi task port, and similarly for all other tasks.
 * `${root}` with `device:hd1`
 
 This typically results in:
 
-    task loaded: ext2fs --readonly --multiboot-command-line=root="device:hd1 console=com0" --host-priv-port=1 --device-master-port=2 --exec-server-task=3 -T typed device:hd1
+    task loaded: pci-arbiter --host-priv-port=1 --device-master-port=2 --next-task=3
+    task loaded: acpi --next-task=1
+    task loaded: rumpdisk --next-task=1
+    task loaded: ext2fs --readonly --multiboot-command-line=root="device:sd1 console=com0" --exec-server-task=1 -T typed device:sd1
     task loaded: exec /hurd/exec
 
+
 (You will have noticed that `/hurd/exec` is not run directly, but through
 `ld.so.1`: Mach only knows to run statically-linked ELF binaries, so we could
-either load `/hurd/exec.static`, or load the dynamic loader `ld.so.1` and tell
-it to load `/hurd/exec`)
+either load `/hurd/exec.static` directly, or load the dynamic loader `ld.so.1`
+and tell it to load `/hurd/exec`, which will be readable once `ext2fs.static` is
+started)
 
 GNU Mach will eventually make the `$(task-resume)` function calls, and thus
-resume the ext2fs task only.
-
-This starts a dance between the bootstrap processes: `ext2fs`, `exec`, `startup`,
-`proc`, and `auth`. Indeed, there are a few dependencies between them: `exec` needs
-`ext2fs` working to be able to start `startup`, `proc` and `auth`, and `ext2fs` needs to
-register itself to `startup`, `proc` and `auth` so as to appear as a normal process,
-running under uid 0.
+resume the `pci-arbiter` task only.
 
-The base principle is that `ext2fs` has a nul bootstrap port set to while other
-translators will have a non-nul bootstrap port, with which they will discuss. We
-thus have a hierarchy between the bootstrap processes. `ext2fs` is at the root,
-`exec` and `startup` are its direct children, and `auth` and `port` are direct
-children of `startup`.
-
-Usually the bootstrap port is used when starting a translator, see
+Usually the bootstrap ports of translators is used when starting them, see
 `fshelp_start_translator_long`: the parent translator starts the child and sets
 its bootstrap port. The parent then waits for the child to call `fsys_startup`
 on the bootstrap port, for the child to provide its control port, and for the
 parent to provide the FS node that the child is translator for.
 
-For the bootstrap translators, the story is extended:
+But here when `pci-arbiter` initializes itself, it notices that its bootstrap
+port is nul (it is started by the kernel, not a filesystem) so it knows that it
+is alone and can only rely on the kernel.  It initializes itself and parses the
+arguments, and since it is given a `next-task`, it uses `task_set_special_port`
+to pass a send right to its own control port to that next task (here `acpi`) as
+bootstrap port, and uses `task_resume` to start it.
+
+Similarly, `acpi` initializes itself, gives a send right to `rumpdisk` and
+starts it.
+
+`rumpdisk` does the same, so that eventually `ext2fs` starts, with all of
+`pci-arbiter`, `acpi` and `rumpdisk` ready to reply to `device_open` requests on
+the `pci`, `acpi`, and disks device names.
 
-* Between `ext2fs` and `startup`: `startup` additionally calls `fsys_init`, to
+Now that `ext2fs` starts, a dance begin between the remaining bootstrap
+processes: `ext2fs`, `exec`, `startup`, `proc`, and `auth`. Indeed, there are
+a few dependencies between them: `exec` needs `ext2fs` working to be able to
+start `startup`, `proc` and `auth`, and `ext2fs` needs to register itself to
+`startup`, `proc` and `auth` so as to appear as a normal process, running under
+uid 0.
+
+They will register to each other the following way:
+
+* Between `ext2fs` and `startup`: `startup` calls `fsys_init`, to
 provide `ext2fs` with `proc` and `auth` ports.
 * Between `startup` and `proc`: `proc` just calls `startup_procinit` to hand
 over a `proc` port and get `auth` and `priv` ports.
 * Between `startup` and `auth`: `auth` calls `startup_authinit` to hand over an
 `auth` port and get a `proc` port, then calls `startup_essential_task` to notify
 `startup` that the boot can proceed.
-* For translators before `ext2fs`, the child calls `fsys_startup` to pass over
-the control port of `ext2fs` (instead of its own control port, which is useless
-for its parent). This is typically done in the `S_fsys_startup` stub, simply
-forwarding it. The child also calls `fsys_init` to pass over the `proc` and
-`auth` ports. Again, this is typically done in the `S_fsys_init` stub, simply
-forwarding them.
+* For the series of translators before `ext2fs`, each task calls `fsys_startup`
+to pass over the control port of `ext2fs` to the previous task (instead of
+its own control port, which is useless for it). This is typically done in the
+`S_fsys_startup` stub, simply forwarding it. It also calls `fsys_init` to
+pass over the `proc` and `auth` ports. Again, this is typically done in the
+`S_fsys_init` stub, simply forwarding them.
 
 With that in mind, the dance between the bootstrap translators is happening as
 described in the next sections.
 
-# Initialization of translators before ext2fs
-
-We plan to start pci-arbiter and rumpdisk translators before ext2fs.
-
-pci-arbiter's `main` function parses the arguments, and since it is given a disk
-task port, it knows it is a bootstrap translator and thus initializes the
-machdev library. `machdev_trivfs_init` resumes the disk task.
-
-rumpdisk's `main` function parses the arguments, and since it is given a FS task
-port, it knows it is a bootstrap translator, and thus `machdev_trivfs_init`
-resumes the FS task.
-
 # ext2fs initialization
 
 ext2fs's `main` function starts by calling `diskfs_init_main`.
@@ -127,7 +137,8 @@ ext2fs bootstrap port to `MACH_PORT_NULL`: it is the bootstrap filesystem which
 will be in charge of dancing with the exec and startup translator.
 
 `diskfs_init_main` then initializes the libdiskfs library and spawns a thread to
-manage libdiskfs RPCs.
+manage libdiskfs RPCs. It also notices that the filesystem is given a kernel
+command line, i.e. this is the bootstrap filesystem.
 
 ext2fs continues its initialization: creating a pager, opening the
 hypermetadata, opening the root inode to be set as root by libdiskfs.
@@ -137,7 +148,7 @@ by the libdiskfs library.
 
 # libdiskfs bootstrap
 
-Since the bootstrap port is `MACH_PORT_NULL`, `diskfs_startup_diskfs` calls
+Since this is the bootstrap filesystem, `diskfs_startup_diskfs` calls
 `diskfs_start_bootstrap`.
 
 `diskfs_start_bootstrap` starts by creating a open port on itself for the
@@ -272,13 +283,26 @@ on its bootstrap port, i.e. rumpdisk.
 rumpdisk's `trivfs_S_fsys_init` gets called from the `fsys_init` call from
 ext2fs. It calls `fsys_init` on its bootstrap port.
 
+# acpi getting initialized
+
+acpi's `trivfs_S_fsys_init` gets called from the `fsys_init` call from
+rumpdisk. It calls `fsys_init` on its bootstrap port.
+
 # pci-arbiter getting initialized
 
 pci-arbiter's `trivfs_S_fsys_init` gets called from the `fsys_init` call from
 rumpdisk.
 
 It gets the root node of ext2fs, sets all common ports, and install
-pci-arbiter in the ext2fs FS as translator for `/servers/bus/pci`.
+itself in the ext2fs FS as translator for `/servers/bus/pci`.
+
+It eventually calls `startup_essential_task` to tell startup that it is ready,
+and requests shutdown notifications.
+
+# back to acpi initialization
+
+It gets the root node of ext2fs, sets all common ports, and install
+itself in the ext2fs FS as translator for `/servers/acpi`.
 
 It eventually calls `startup_essential_task` to tell startup that it is ready,
 and requests shutdown notifications.
@@ -286,7 +310,7 @@ and requests shutdown notifications.
 # back to rumpdisk initialization
 
 It gets the root node of ext2fs, sets all common ports, and install
-rumpdisk in the ext2fs FS as translator for `/dev/disk`.
+itself in the ext2fs FS as translator for `/dev/disk`.
 
 It eventually calls `startup_essential_task` to tell startup that it is ready,
 and requests shutdown notifications.
@@ -304,7 +328,7 @@ system is shutting down.
 
 # startup monitoring bootstrap progress
 
-As mentioned above, the different essential tasks (pci-arbiter, rumpdisk, ext2fs, proc, auth, exec)
+As mentioned above, the different essential tasks (pci-arbiter, acpi, rumpdisk, ext2fs, proc, auth, exec)
 call `startup_essential_task` when they are ready. startup's
 `S_startup_essential_task` function thus gets called each time, and startup
 records each of them as essential, monitoring their death to crash the whole
diff --git a/hurd/debugging/translator/gdb.mdwn b/hurd/debugging/translator/gdb.mdwn
index 82a50736..fdf6adff 100644
--- a/hurd/debugging/translator/gdb.mdwn
+++ b/hurd/debugging/translator/gdb.mdwn
@@ -12,6 +12,8 @@ Say you want to try running file system server ([[`ext2fs`|translator/ext2fs]],
 [[`jfs`|translator/jfs]], ...) against a modified version of
 [[`libpager`|libpager]] and debug the latter one using [[debugging/GDB]].
 
+On Debian you need the `hurd-dbgsym` and `libc0.3-dbg` packages installed.
+
 Set the [[hurd/translator]] like this:
 
     $ settrans -fgap ↩
@@ -51,3 +53,11 @@ course):
     [...]
 
 Voilà.
+
+If you need to debug the initialization of the translator, start the translator
+like
+
+    $ settrans -Pa /foo /hurd/foofs
+
+The `-P` option will make it
+pause and you will be able to attach [[debugging/GDB]] to the process.
diff --git a/hurd/glibc.mdwn b/hurd/glibc.mdwn
index 8e330aef..736cc099 100644
--- a/hurd/glibc.mdwn
+++ b/hurd/glibc.mdwn
@@ -49,6 +49,10 @@ One can build libc this way:
     $ make
     $ make check -k
 
+One can run tests individually with:
+
+    $ make test t=wcsmbs/test-wcsnlen
+
 One can run tests with the new libc by hand:
 
     $ ./testrun.sh ~/test
diff --git a/hurd/rump/rumpusbdisk.mdwn b/hurd/rump/rumpusbdisk.mdwn
index 26e1a101..8463e670 100644
--- a/hurd/rump/rumpusbdisk.mdwn
+++ b/hurd/rump/rumpusbdisk.mdwn
@@ -14,7 +14,7 @@ License|/fdl]]."]]"""]]
 # RumpUSBDisk
 
 With RumpUSBDisk, the Hurd can use a usb to SATA dongle to access a
-SATA device.  The StarTech offers a good quality dongle that works
+SATA device.  StarTech offers a good quality dongle that works
 well.  The Hurd could then read/write data from a SATA device with an
 fatfs or ext2 filesystem.  Damien Zammit implemented [[rumpusbdisk
 already|https://lists.gnu.org/archive/html/bug-hurd/2023-07/msg00025.html]].
diff --git a/hurd/running/debian/CrossInstall.mdwn b/hurd/running/debian/CrossInstall.mdwn
index 26cd77af..0f56a3e7 100644
--- a/hurd/running/debian/CrossInstall.mdwn
+++ b/hurd/running/debian/CrossInstall.mdwn
@@ -56,13 +56,6 @@ Ah, reboot and select "GNU (kernel GNUmach 1.3)" from the Grub menu. At the prom
     # export TERM=mach
     # ./native-install
 
-When done the native install requests that you reboot once again and rerun native-install.
-
-    # reboot
-    ...
-    # export TERM=mach
-    # ./native-install
-
 Done, continue setting up your system.
 
 ----
diff --git a/hurd/running/debian/qemu_image.mdwn b/hurd/running/debian/qemu_image.mdwn
index 9984ac33..8409bc8c 100644
--- a/hurd/running/debian/qemu_image.mdwn
+++ b/hurd/running/debian/qemu_image.mdwn
@@ -42,7 +42,7 @@ Optionally you may use `--curses` to keep your keyboard layout. If need be modpr
 
 Note that if you do not have a command named `kvm`, you can try something across the lines of:
 
-	$ qemu-system-i386 --enable-kvm -drive cche=writeback,file=$(echo debian-hurd-*.img) -net user,hostfwd=tcp:127.0.0.1:2222-:22 -net nic,model=e1000
+	$ qemu-system-i386 --enable-kvm -drive cache=writeback,file=$(echo debian-hurd-*.img) -net user,hostfwd=tcp:127.0.0.1:2222-:22 -net nic,model=e1000
 
 Or, if your machine does not allow for KVM acceleration, omit `--enable-kvm` from the command.
 
diff --git a/hurd/running/gnu.mdwn b/hurd/running/gnu.mdwn
index 964e7e8e..b45841df 100644
--- a/hurd/running/gnu.mdwn
+++ b/hurd/running/gnu.mdwn
@@ -2,31 +2,32 @@
 
 # <a name="The_GNU_Operating_System"> </a> The GNU Operating System
 
-The GNU Operating System, Commonly referred to as simply "The GNU System", is a
+The GNU Operating System, commonly referred to as simply "The GNU System", is a
 complete [[Unix]]-like operating system composed entirely of [free
 software](http://www.gnu.org/philosophy/free-sw.html).  The creation of the GNU
 System is one of the goals of the [GNU Project](http://www.gnu.org/), which was
 [launched in 1983](http://www.gnu.org/gnu/initial-announcement.html) by
-[Richard Stallman](http://www.stallman.org/).  It has many ambitious goals that
-the GNU/Hurd intends to address.
-
-These goals include increased security through the [[principle of least
-privilege|https://en.wikipedia.org/wiki/Principle%5Fof%5Fleast%5Fprivilege]], an
-[[extensible system|extensibility]], conformation to open operating standards
-including [[POSIX|https://en.wikipedia.org/wiki/POSIX]], modularity, and
-respecting user freedom.  Many of these goals are things that the GNU/Hurd can
-resolve, however the GNU/Hurd is not the most stable operating system yet.
+[Richard Stallman](http://www.stallman.org/).  The GNU/Hurd intends to 
+increase security through the [[principle of least
+privilege|https://en.wikipedia.org/wiki/Principle%5Fof%5Fleast%5Fprivilege]], provide an
+[[extensible system|extensibility]], conform to open operating standards
+including [[POSIX|https://en.wikipedia.org/wiki/POSIX]], contain a modular code-base, and
+[[respect user freedom|https://www.gnu.org/philosophy/free-sw.html]].  
+Many of these goals are things that the GNU/Hurd can
+resolve, however the GNU/Hurd is not yet the most stable operating system.
 
 If you are looking for a production ready GNU system, then [[hurd/running/Debian]] GNU/Hurd may
-not be the best choice for you.  Debian GNU/Hurd currently lacks 64-bit support,
-many device drivers, sound support, SMP, and a few other essential bits that
-provide a flexible operating system.
+not be the best choice for you.  Debian GNU/Hurd currently lacks many device drivers, sound 
+support, and a few other essential bits that provide a flexible operating system.
+It also has some tricky [[problems|challenges]] to solve.
 
 However, [[gnu.org|https://www.gnu.org/distros/free-distros.html]] maintains a
 list of freedom respecting and production ready GNU/Linux systems.  One of the
-most promising of these is [[GuixSD|https://www.gnu.org/software/guix/]], which
+most promising of these is [[Guix System|https://www.gnu.org/software/guix/]], which
 is the GNU Guix System Distribution, which eventually plans to support the GNU
-Hurd as the kernel! 
+Hurd as the kernel! You can even use a 
+[[childhurd|https://guix.gnu.org/manual/devel/en/html_node/Virtualization-Services.html#The-Hurd-in-a-Virtual-Machine]]
+on Guix System!
 
 ## Resources
 
diff --git a/hurd/running/virtualbox.mdwn b/hurd/running/virtualbox.mdwn
index b48f7ebd..cf9a5870 100644
--- a/hurd/running/virtualbox.mdwn
+++ b/hurd/running/virtualbox.mdwn
@@ -11,8 +11,23 @@ License|/fdl]]."]]"""]]
 
 [[!meta title="VirtualBox"]]
 
-<http://www.virtualbox.org/>
-
+Some people are very familiar with using VirtualBox to run virtual machines of OS
+like GNU/Linux, Windows, etc. Hurd CAN also be run with VirtualBox normally, and
+the way is very similar to running other OS with it. The main problem may be that
+Hurd may not support as many emulated hardware as others, which is also a good
+point to help us.
+
+This also provides a good opportunity for people who want to play with Hurd on
+every other OS which can run VirtualBox. You can absolutely run and develop Hurd
+without switching your current OS or running a nest Hurd in another virtual machine.
+
+If you happen to have experience on developing GNU/Linux on other OS like
+Windows, you can develop Hurd smoothly just like before. We might recommend that
+you use a FSF approved operating system to get better experience of developing
+Hurd, but if for some reason you are stuck using Windows, this won't be an
+unsolvable obstacle.
+
+You can download VirtualBox at <http://www.virtualbox.org/>.
 
 # Installation  
 
diff --git a/hurd/status.mdwn b/hurd/status.mdwn
index bc04d78d..28919995 100644
--- a/hurd/status.mdwn
+++ b/hurd/status.mdwn
@@ -34,6 +34,8 @@ drivers, and experimental support for SATA devices was added in May 2013.
 Robert Millan worked on a port of the Rump kernel, which allowed to run a
 sound driver in userland. This work now needs to be extended. Support for
 character devices and other hardware (USB, multicore) is mostly missing.
+Damien Zammit added [[RumpDisk|hurd/rump/rumpdisk]], which lets the Hurd
+boot and use SSDs with a minimal NetBSD kernel running in userspace.
 
 Although the [[POSIX
 interface|faq/posix_compatibility]] is provided, some additional interfaces
@@ -56,14 +58,28 @@ official Debian release), in April 2015 the [[Debian
 GNU/Hurd|hurd/running/debian]] team released [[Debian GNU/Hurd
 2015|news/2015-04-29-debian_gnu_hurd_2015]]. Similarly, along Debian "stretch",
 in June 2017 [[Debian GNU/Hurd 2017|news/2017-06-18-debian_gnu_hurd_2017]] was released.
+The latest release is from 
+[[2023|https://darnassus.sceen.net/~hurd-web/news/2023-06-11-debian_gnu_hurd_2023/]].
+
+With [[Guix System|hurd/running/guix]] one can trivially run a childhurd or a 
+hurd vm running atop GNU/Linux.  The adventurous can run it on 
+[[real iron|https://guix.gnu.org/blog/2024/hurd-on-thinkpad/]]. 
 
 [[hurd/running/Arch_Hurd]] offers *LiveCDs* for testing and installation.
 
 [[hurd/running/Nix]] provides QEMU images.
 
-
 ## Usability Reports
 
+### Joshua Branson, 2025-04-30
+
+I've had my T43 Thinkpad with 1.5 GB of RAM running Debian GNU/Hurd
+for about a year now.  I use a combination of the i3 window 
+manager, emacs, git, the netsurf web browser, and a terminal to edit 
+this wiki.  The Hurd is fairly stable, but it tends to lock up on me
+about once a month.  While I am fairly certain that I have had some 
+filesystem corruption, I have not noticed any lost files yet.
+
 ### Svante Signell, 2013-05-21
 
 I have been running GNU/Hurd for some years now, with VMs, mainly in the
diff --git a/hurd/translator/ext2fs.mdwn b/hurd/translator/ext2fs.mdwn
index 9be6c885..3baf6b03 100644
--- a/hurd/translator/ext2fs.mdwn
+++ b/hurd/translator/ext2fs.mdwn
@@ -617,18 +617,6 @@ That would be a nice improvement, but only after writeback throttling is impleme
       separate partitions is a way to alleviate them
 
 
-## `ext2fs: ../../libdiskfs/rdwr-internal.c:42: _diskfs_rdwr_internal: Assertion `!diskfs_readonly' failed.`
-
-### IRC, freenode, #hurd, 2014-02-22
-
-    <gg0> login: init: notifying pfinet of shutdown...init: notifying tmpfs
-      none of shutdown...init: notifying tmpfs none of shutdown...init:
-      notifyi.
-    <gg0> ext2fs: ../../libdiskfs/rdwr-internal.c:42: _diskfs_rdwr_internal:
-      Assertion `!diskfs_readonly' failed.
-    <gg0> In tight loop: hit ctl-alt-del to reboot
-
-
 # Documentation
 
   * <http://e2fsprogs.sourceforge.net/ext2.html>
diff --git a/hurd/translator/remap.mdwn b/hurd/translator/remap.mdwn
index a0544c7c..06e3c8c5 100644
--- a/hurd/translator/remap.mdwn
+++ b/hurd/translator/remap.mdwn
@@ -31,9 +31,12 @@ On Debian, `/bin/sh` points to `dash`.  Maybe you would rather it
 point to `bash`.
 
 	$ ls -lha /bin/sh
-	  lrwxr-xr-x 1 root root 4 Jun  5 04:08 /bin/sh -> dash
+	lrwxr-xr-x 1 root root 4 Jun  5 04:08 /bin/sh -> dash
 	$ remap /bin/sh /bin/bash -- ls -lha /bin/sh
-      -rwxr-xr-x 1 root root 1,2M 20 oct.  12:53 /bin/sh
+    -rwxr-xr-x 1 root root 1,2M 20 oct.  12:53 /bin/sh
+    /bin/settrans: fsys_goaway: (ipc/mig) server died
+
+(the warning is expected, it just tells that the exected command has finished)
 
 ## remapping python3
 
diff --git a/hurd/what_is_the_gnu_hurd.mdwn b/hurd/what_is_the_gnu_hurd.mdwn
index 09c26ee7..0ccead52 100644
--- a/hurd/what_is_the_gnu_hurd.mdwn
+++ b/hurd/what_is_the_gnu_hurd.mdwn
@@ -12,6 +12,13 @@ License|/fdl]]."]]"""]]
 [[!meta title="What Is the GNU Hurd?"]]
 
 The Hurd is the GNU project's replacement for the [[UNIX]] system's [[kernel]].
+There are several 
+[[free software operating systems|https://www.gnu.org/distros/free-distros.en.html]]
+using the [[Linux kernel|https://en.wikipedia.org/wiki/Linux_kernel]]. The
+Hurd is an alternate operating system that uses a different kernel.  You can
+read more about the status of the Hurd [[here|hurd/status]].  If you decide
+to use the Hurd, then we would recommend 
+[[the Debian GNU/Hurd distribution|https://www.debian.org/ports/hurd/]].
 
 The Hurd is firstly a collection of protocols formalizing how different
 components may interact.  The protocols are designed to reduce the mutual
@@ -23,7 +30,8 @@ access to its backing store and that the [[principal]] that started it own the
 file system node to which it connects.
 
 The Hurd is also a set of [[servers|translator]] that implement these
-protocols.  They include file systems, network protocols and authentication.
+protocols.  They include [[file systems|hurd/translator/ext2fs]], network 
+protocols and [[authentication|hurd/translator/auth]].
 The servers run on top of the [[microkernel/Mach]] [[microkernel]] and use
 Mach's [[microkernel/mach/IPC]] mechanism to transfer information.
 
@@ -39,8 +47,8 @@ programs and libraries to operate. Let's look at an example.
 
 Firefox invokes glibc's `send ()`, which in turn uses the pfinet (or
 lwip) TCP/IP stack, which talk to our device drivers (rump or netdde),
-which finally talk to GNU Mach.  Only GNU Mach runs in kernel space!
-Everything else is userspace!
+which can actually access the hardware without entering kernel space 
+(GNU Mach).  That's a lot of power for userspace!
 
 The Hurd supplies the last major software component needed for a complete
 [[GNU_operating_system|running/gnu]] as originally conceived by Richard
@@ -51,7 +59,10 @@ organization that is the home of the [GNU project](http://gnu.org/gnu/).
 The Hurd development effort is a somewhat separate project from the
 [[Debian_GNU/Hurd|hurd/running/debian]] port.
 
+Want to know what the Hurd can do?  Read the [[status|hurd/status]] page.
 
 Read about what the GNU Hurd is [[gramatically_speaking]].
 
 Read about the [[origin_of_the_name]].
+
+Want to read more [[Hurd documentation|hurd/documentation]]?