16 files changed, 173 insertions, 84 deletions
diff --git a/faq/2_gib_partition_limit.mdwn b/faq/2_gib_partition_limit.mdwn
index fa5105bd..654379a3 100644
--- a/faq/2_gib_partition_limit.mdwn
+++ b/faq/2_gib_partition_limit.mdwn
@@ -15,8 +15,8 @@ License|/fdl]]."]]"""]]
 
 The 2 GiB ext2fs limit has been removed.
 
-IDE disk drivers however currently do not support more than 2^28 sectors, i.e. 128GiB.
+IDE disk drivers (`hd*`) however currently do not support more than 2^28 sectors, i.e. 128GiB.
 
-The gnumach AHCI disk driver supports up to 2^48 sectors, i.e. 128PiB, but the device interface supports only 2^32 sectors, i.e. 2TiB.
+The gnumach AHCI disk driver (`sd*`) and rumpkernel drivers (`wd*`) support up to 2^48 sectors, i.e. 128PiB, but the device interface supports only 2^32 sectors, i.e. 2TiB.
 
 You can have a bigger disk, you just should not put disk partitions beyond these limits for the drivers to be able to read from them.
diff --git a/faq/64-bit.mdwn b/faq/64-bit.mdwn
index a41d215d..d3d6d046 100644
--- a/faq/64-bit.mdwn
+++ b/faq/64-bit.mdwn
@@ -13,23 +13,17 @@ License|/fdl]]."]]"""]]
 
 [[!meta title="Is there a 64-bit version?"]]
 
-There are plans for 64-bit kernelland with 32-bit userland, which will notably
-permit to efficiently make use of more than 2 GiB memory and provide 4 GiB
+64-bit kernelland is supported with 32-bit userland, which notably
+permits to efficiently make use of more than 2 GiB memory and provide 4 GiB
 userland addressing space.
 
-A 64-bit GNU/Hurd is also coming soon,
-progress is tracked on [[open_issues/64-bit_port]]!
-Hurd developers ported GNUMach to
-64-bit some time ago.  Then they started making significant progress
-on the x86_64 userland port in Feb 2023.  As of September 2024, the
-Debian hurd-amd64 port works just like the hurd-i386, except for
-missing packages and more
-[[bugs|https://lists.gnu.org/archive/html/bug-hurd/2024-07/msg00058.html]],
-namely swapping issues with rumpdisk and deadlocking issues with
-libdiskfs/ext2fs.  We are currently building
-64-bit packages.  We plan on supporting both a 32-bit and 64-bit Debian
-GNU/Hurd, only not both at the same time.  However, there is no plan to fix the
-year 2038 concern on a 32-bit system.
+A 64-bit GNU/Hurd is also available, progress is tracked on [[open_issues/64-bit_port]]!
+As of April 2025, the Debian hurd-amd64 port works just like the hurd-i386, except for
+some bugs, namely swapping issues with rumpdisk and dumping core files.
+
+We plan on supporting both a 
+32-bit and 64-bit Debian GNU/Hurd, only not both at the same time.  
+However, there is no plan to fix the year 2038 concern on a 32-bit system.
 
 That being said, you can always run a 32-bit version on a 64-bit machine, it
 just works, processes are just limited to a couple GiB available memory.
diff --git a/faq/context_switch.mdwn b/faq/context_switch.mdwn
index 2d090c4c..55d20429 100644
--- a/faq/context_switch.mdwn
+++ b/faq/context_switch.mdwn
@@ -17,7 +17,13 @@ It is not, there is no real reason why it would be particularly slow, it is just
 about switching virtual addresses and registers, which all OS have to perform
 anyway.
 
-A quick-and-dirty benchmark:
+A quick-and-dirty benchmark.
+
+You can build this file with:
+
+        gcc -pthread -rt -o context-switch context-switch.c
+
+In `context-switch.c` write:
 
         #include <fcntl.h>
         #include <semaphore.h>
diff --git a/faq/debugging_translators.mdwn b/faq/debugging_translators.mdwn
index 1bd0deec..031b5778 100644
--- a/faq/debugging_translators.mdwn
+++ b/faq/debugging_translators.mdwn
@@ -11,12 +11,4 @@ License|/fdl]]."]]"""]]
 
 [[!tag faq/development]]
 
-In order to [[debug|debugging]] translators and being able to step into glibc
-during it, on Debian you need the `hurd-dbgsym` and `libc0.3-dbg` packages installed.
-If you need to debug the initialization of the translator, start the translator
-like
-
-    $ settrans -Pa /foo /usr/bin/env LD_LIBRARY_PATH=/usr/lib/debug /hurd/foofs
-
-The `-P` option will make it
-pause and you will be able to attach [[debugging/GDB]] to the process.
+See [[/hurd/debugging/translator]].
diff --git a/faq/dev-console.mdwn b/faq/dev-console.mdwn
new file mode 100644
index 00000000..743c6f5a
--- /dev/null
+++ b/faq/dev-console.mdwn
@@ -0,0 +1,26 @@
+[[!meta copyright="Copyright © 2025 Free Software Foundation,
+Inc."]]
+
+[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
+id="license" text="Permission is granted to copy, distribute and/or modify this
+document under the terms of the GNU Free Documentation License, Version 1.2 or
+any later version published by the Free Software Foundation; with no Invariant
+Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
+is included in the section entitled [[GNU Free Documentation
+License|/fdl]]."]]"""]]
+
+[[!tag faq/running]]
+
+[[!meta title="Fails to boot with /dev/console: Read-only file system"]]
+
+Somehow your `/dev/console` got hurt. You can mount by hand (e.g. on `/target`)
+your root filesystem from a Hurd installation CD and run
+
+    settrans -c /target/dev/console /hurd/term /dev/console device console
+
+to restore it.
+
+You can also set it from a Linux system (mounting it as ext4) with:
+
+    touch /target/dev/console
+    setfattr -n gnu.translator -v "/hurd/term\0/dev/console\0device\0console\0" /target/dev/console
diff --git a/faq/dev-init.mdwn b/faq/dev-init.mdwn
new file mode 100644
index 00000000..4264c39d
--- /dev/null
+++ b/faq/dev-init.mdwn
@@ -0,0 +1,47 @@
+[[!meta copyright="Copyright © 2025 Free Software Foundation,
+Inc."]]
+
+[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
+id="license" text="Permission is granted to copy, distribute and/or modify this
+document under the terms of the GNU Free Documentation License, Version 1.2 or
+any later version published by the Free Software Foundation; with no Invariant
+Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
+is included in the section entitled [[GNU Free Documentation
+License|/fdl]]."]]"""]]
+
+[[!tag faq/running]]
+
+[[!meta title="Fails to boot, hangs at auth."]]
+
+Perhaps your `/dev/` got hurt. You can mount by hand (e.g. on `/target`)
+your root filesystem from a Hurd installation CD and run
+
+    chroot /target dpkg-reconfigure hurd
+
+or
+
+    chroot /target /usr/lib/hurd/setup-translators -k -p
+
+or even completely by hand:
+
+    settrans -cfg /target/dev/console /hurd/term /dev/console device console
+    settrans -cfg /target/dev/null /hurd/null
+    settrans -cfg /target/servers/socket/1 /hurd/pflocal
+    settrans -cfg /target/dev/urandom /hurd/random --seed-file /var/lib/random-seed --fast
+
+to restore it or at least the basic parts.
+
+You can also try to fix some entries from a Linux system (mounting it as ext4) with:
+
+    rm -f /target/dev/console
+    rm -f /target/dev/null
+    rm -f /target/servers/socket/1
+    rm -f /target/dev/urandom
+    touch /target/dev/console
+    touch /target/dev/null
+    touch /target/servers/socket/1
+    touch /target/dev/urandom
+    setfattr -n gnu.translator -v "/hurd/term\0/dev/console\0device\0console\0" /target/dev/console
+    setfattr -n gnu.translator -v "/hurd/null\0" /target/dev/null
+    setfattr -n gnu.translator -v "/hurd/pflocal\0" /target/servers/socket/1
+    setfattr -n gnu.translator -v "/hurd/random\0--seed-file\0/var/lib/random-seed\0--fast\0" /target/dev/urandom
diff --git a/faq/dev-rebuild.mdwn b/faq/dev-rebuild.mdwn
index 5a4678d1..84c2ece8 100644
--- a/faq/dev-rebuild.mdwn
+++ b/faq/dev-rebuild.mdwn
@@ -11,7 +11,7 @@ License|/fdl]]."]]"""]]
 
 [[!tag faq/running]]
 
-[[!meta title="Some ntries in /dev are bogus"]]
+[[!meta title="Some entries in /dev are bogus"]]
 
 Possibly something broke translators there. You can run
 
diff --git a/faq/drivers.mdwn b/faq/drivers.mdwn
index 923e3b38..0d73f995 100644
--- a/faq/drivers.mdwn
+++ b/faq/drivers.mdwn
@@ -19,14 +19,17 @@ and you can use an [[SSD|hurd/rump/rumpdisk]].  If you have difficulty
 installing the Hurd, then try setting your harddrive mode to "legacy"
 in the BIOS.  A cheaper option is the T43 (2GB max RAM).
 
-Other working Thinkpads include the X200, T400, or T500 Thinkpads,
+Other working Thinkpads include the X200, T400, 
+[[T410|https://logs.guix.gnu.org/hurd/2025-04-25.log#103752]] or T500 Thinkpads,
 which support internet connectivity via the ethernet port.  You can
 use an [[SSD|hurd/rump/rumpdisk]] on these laptops, which support a
 maximum of 8GB of RAM.  The Debian installer images from 2023 fail to
-boot these machines, but you can install the Hurd via [[Debian's
-CrossInstall|hurd/running/debian/CrossInstall]].  Until we fix the
-libdiskfs/ext2fs issues on the [[64 bit port|faq/64-bit]], we
-recommend that you use the 32 bit version of the Hurd.
+boot these machines, but you can install the Hurd from a linux
+installation via [[crossinstall method|hurd/running/debian/CrossInstall]]. 
+
+_While the [[64 bit port|faq/64-bit]] is about as stable as the 32-bit 
+port, the rumpdisk support needed for it is still relatively experimental.
+For this reason we recommend casual Hurd users to use the 32 bit port._
 
 Other hardware that is known to work includes the [[Dell Inspiron
 1750|https://logs.guix.gnu.org/hurd/2024-09-28.log]] on i386
diff --git a/faq/foo_max.mdwn b/faq/foo_max.mdwn
index 5f736680..ccd09904 100644
--- a/faq/foo_max.mdwn
+++ b/faq/foo_max.mdwn
@@ -18,7 +18,12 @@ For porting guidelines, see [[hurd/porting/guidelines#PATH_MAX_tt_MAX_PATH_tt_MA
 
 # Is it really standard not to define them?
 
-These macros are indeed optional in Posix, so not defining them remains standard-compliant.
+These macros are indeed optional in Posix, so not defining them remains
+standard-compliant. Quoting the standard:
+
+    A definition of one of the symbolic constants in the following list shall be
+    omitted from <limits.h> on specific implementations where the corresponding
+    value is equal to or greater than the stated minimum, but is unspecified.
 
 Their definition was actually not completely clear, Posix 1990 was ambiguous
 about it including `\0` or not, it was made clear later on that it does include
@@ -30,13 +35,14 @@ even depend on its revision, so to be rather queried at runtime with `pathconf`.
 # But it's really convenient! Isn't allocating dynamically much more complex?
 
 `FOO_MAX` constants are most often used as “reasonable size to allocate a
-path”. On Linux it is typically 4096, which is not that reasonable (a whole
+path”. On Linux `PATH_MAX` is typically 4096, which is not that reasonable (a whole
 memory page, thus a TLB lookup) when manipulating a lot of paths. Allocating
 dynamically would use much less memory.
 
 Most often interfaces can be made to properly allocate dynamically. Notably,
-since Posix 2008 `realpath(path, NULL)` and `getcwd(NULL, 0)` allocate the path
-dynamically.
+since Posix 2008 `realpath(path, NULL)` allocates the path dynamically.
+Posix 2008 does not say that `getcwd(NULL, 0)` allocates the path dynamically,
+but BSD, Linux, and even windows do.
 
 In general, using `FOO_MAX` in source code (with a large value) leads to code
 that is not actually checking against overflows. `PATH_MAX` being 4096 is
diff --git a/faq/how_rpcs_work.mdwn b/faq/how_rpcs_work.mdwn
new file mode 100644
index 00000000..cda7e2d9
--- /dev/null
+++ b/faq/how_rpcs_work.mdwn
@@ -0,0 +1,18 @@
+[[!meta copyright="Copyright © 2010, 2011, 2013, 2016 Free Software Foundation,
+Inc."]]
+
+[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
+id="license" text="Permission is granted to copy, distribute and/or modify this
+document under the terms of the GNU Free Documentation License, Version 1.2 or
+any later version published by the Free Software Foundation; with no Invariant
+Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
+is included in the section entitled [[GNU Free Documentation
+License|/fdl]]."]]"""]]
+
+[[!tag faq/general faq/_important]]
+
+[[!meta title="How do RPCs work, similarly to system calls?"]]
+
+There is a talk that explains the path of RPCs (i.e. system calls):
+
+<https://archive.fosdem.org/2015/schedule/event/hurd/>
diff --git a/faq/other_repositories.mdwn b/faq/other_repositories.mdwn
index a55ac1e3..ae00e276 100644
--- a/faq/other_repositories.mdwn
+++ b/faq/other_repositories.mdwn
@@ -14,6 +14,4 @@ License|/fdl]]."]]"""]]
 If you want to use the `apt source` facility, make sure that
 `/etc/apt/sources.list` contains a line like
 
-    deb-src http://ftp.de.debian.org/debian unstable main
-
-... replacing _de_ with your homeland's code.
+    deb-src http://deb.debian.org/debian unstable main
diff --git a/faq/ram_limit.mdwn b/faq/ram_limit.mdwn
index 8e13f321..4e7e47b0 100644
--- a/faq/ram_limit.mdwn
+++ b/faq/ram_limit.mdwn
@@ -13,16 +13,12 @@ License|/fdl]]."]]"""]]
 
 [[!meta title="830 MiB RAM Limit"]]
 
-The 830MB RAM limit has been removed, but just like any 32-bit OS without bad tricks,
-GNU Mach can not cope well with lots of memory.  Latest versions of the Debian `gnumach`
-package will limit themselves to 3 GiB of memory. If you want more, you can twiddle
-the `VM_MAX_ADDRESS` limit between kernelland and userland in
-`i386/include/mach/i386/vm_param.h`, but glibc and the hurd servers will not cope
-well with less than 1 GB.
+The 830MB RAM limit has been removed since long. The default version of the
+Debian `gnumach` package will limit themselves to 3 GiB of memory. If you
+want more, you can try the PAE version, but this requires using rumpdisk for
+accessing disks.
 
-There is a [[64-bit port|open_issues/64-bit_port]] in progress.
-
-If you have an older version, or still experience problems with `vmstat` (see
-above) reported much less memory than you have, the best is to limit the memory
-it can see via GRUB's `upppermem` feature.  Add `uppermem 786432` to GRUB's Hurd
-entry in `menu.lst`.
+Note that by architecture design, 32bit systems can only provide at most 4GiB
+addressing space for processes. With a 32bit kernel, part of is is used by the
+kernel. It is also possible you use a 32-on-64 kernel, to provide the full 4GB
+adress space to userland. To give more to userland, use a fully-64b Hurd.
diff --git a/faq/slow.mdwn b/faq/slow.mdwn
index ffa20fe3..02173952 100644
--- a/faq/slow.mdwn
+++ b/faq/slow.mdwn
@@ -18,12 +18,13 @@ completely usable.
 Take care when running the Hurd in fully-virtualized machines: virtualization
 software use ugly heuristics to make Linux run faster, which will not work on
 the Hurd (or BSD, etc.) so comparisons in virtualized environments do not really
-hold. Also take care of not comparing Hurd (which is currently 32bit) with a
+hold. Also take care of not comparing a 32bit Hurd with a
 64bit Linux execution: 64bit has *much* more computational and optimization
 possibilities than 32bit. At least, use -m32 to build a 32bit Linux version of a
-test for comparison.
+test for comparison, or use a 64b Hurd.
 
-The main reason for slowness is *not* because of the overhead of RPCs. It's
+Contrary to common belief that is terribly widespread in webnews comments, the
+main reason for slowness is *not* because of the overhead of RPCs. It's
 mostly simply because less care has been done on implementing what makes Linux
 fast: intelligent read-ahead, carefully-tuned page cache, etc. or even just
 missing DMA support for your disk controller.
diff --git a/faq/smp.mdwn b/faq/smp.mdwn
index ee0bf53f..d6001b3a 100644
--- a/faq/smp.mdwn
+++ b/faq/smp.mdwn
@@ -21,18 +21,18 @@ This needs testing as SMP support has recently been added to Mach.
 Intel_iPSC/860]], so principally has the required infrastructure.  It has
 recently been enhanced to support nowadays' SMP standards like ACPI.
 
-However, [[GNU Mach|microkernel/mach/gnumach]]'s Linux device driver glue
-code isn't SMP-safe so build with --disable-linux-groups to test SMP and use
+However, [[GNU Mach|microkernel/mach/gnumach]]'s Linux device driver glue code
+isn't SMP-safe so the in-kernel drivers will be disabled, and one has to use
 rumpdisk to provide disk access.
 
 To build an SMP supported gnumach with kdb:
-../configure --enable-ncpus=8 --enable-kdb --enable-apic --disable-linux-groups
+../configure --enable-ncpus=8 --enable-kdb
 
 This will by default allow you to boot with one core isolated to the default
 processor set, and all the other detected cpus will be in the slave processor set.
 The slave processors need to be enabled per-task using RPCs to manipulate processor sets.
 
-See https://lists.gnu.org/archive/html/bug-hurd/2024-02/msg00088.html for a test program
+See [Damien's post](https://lists.gnu.org/archive/html/bug-hurd/2024-02/msg00088.html) for a test program
 that can enable a task to use the slave processors by calling ./smp /bin/bash for example.
 
 Unfortunately, there are race conditions causing hangs or crashes in Mach when attempting
diff --git a/faq/software.mdwn b/faq/software.mdwn
index 719e123c..90e7a524 100644
--- a/faq/software.mdwn
+++ b/faq/software.mdwn
@@ -13,7 +13,7 @@ License|/fdl]]."]]"""]]
 
 [[!meta title="What software is available for GNU?"]]
 
-As of March 2014, 79% of all [Debian](http://www.debian.org/)
+As of August 2025, 72% of all [Debian](http://www.debian.org/)
 [packages](http://packages.debian.org/) are available for [[Debian
 GNU/Hurd|hurd/running/debian]].  Of course, testing and bug fixing is welcome,
 as we have obviously not tested all of them.
diff --git a/faq/still_useful.mdwn b/faq/still_useful.mdwn
index 575781a1..b2b1b272 100644
--- a/faq/still_useful.mdwn
+++ b/faq/still_useful.mdwn
@@ -13,10 +13,10 @@ License|/fdl]]."]]"""]]
 
 [[!meta title="What are the advantages with the Hurd over Linux/BSD?"]]
 
-The Hurd will be considerably more flexible and robust
+The Hurd is already considerably more flexible and robust
 than generic Unix.  Wherever possible, Unix kernel features have been
 moved into unprivileged space.  Once there, anyone who desires can
-develop custom replacements for them.  Users will be able to write and
+develop custom replacements for them.  Users are able to write and
 use their own file systems, their own `exec' servers, or their own
 network protocols if they like, all without disturbing other users.
 
@@ -24,8 +24,8 @@ A [[series of interesting examples|hurd/documentation/translator_primer]] is
 available.
 
 The Linux kernel has now been modified to allow user-level file
-systems, so there is proof that people will actually use features such
-as these.  It will be much easier to do under the Hurd, however,
+systems, so there is proof that people actually use features such
+as these.  It is much easier to do under the Hurd, however,
 because the Hurd is almost entirely run in user space and because the
 various servers are designed for this sort of modification.
 
@@ -43,31 +43,33 @@ various servers are designed for this sort of modification.
 >     $ settrans myspace /hurd/ext2fs myspace.img
 >     $ cd myspace
 
->> Just curious, but I keep seeing these (and other similar) concepts being
->> brought up as the amazing selling points of the Hurd, but all of this is
->> entirely doable now in Linux with FUSE or things like it.
+Other variants of the question include:
 
->>> Nowadays, at LAST, yes, partly.
->>> And only on machines where fuse is enabled. Is it enabled on the servers you have an account on?
+> Just curious, but I keep seeing these (and other similar) concepts being
+> brought up as the amazing selling points of the Hurd, but all of this is
+> entirely doable now in Linux with FUSE or things like it.
 
->> I'm not sure if an ftp filesystem has been implemented for FUSE yet, but its
->> definately doable; and loopback filesystems like in your second example have
->> been supported for years.
+>> Nowadays, at LAST, yes, partly.
+>> And only on machines where fuse is enabled. Is it enabled on the servers you have an account on?
 
->>> As a normal user?  And establish a tap interface connected through ppp over
->>> ssh or whatever you could want to imagine?
+> I'm not sure if an ftp filesystem has been implemented for FUSE yet, but its
+> definately doable; and loopback filesystems like in your second example have
+> been supported for years.
 
->>  What, then, are the major selling points or benefits?
+>> As a normal user?  And establish a tap interface connected through ppp over
+>> ssh or whatever you could want to imagine?
 
->>> These were just examples, Linux is trying to catch up in ugly ways indeed
->>> (yes, have a look at the details of fuse, it's deemed to be inefficient).
->>> In the Hurd, it's that way from the _ground_ and there is no limitation
->>> like having to be root or ask for root to add magic lines, etc.
+>  What, then, are the major selling points or benefits?
 
-> It also for instance provides userland drivers, for instance the network
-> drivers are actually Linux drivers running in a separate userland process.
+>> These were just examples, Linux is trying to catch up in ugly ways indeed
+>> (yes, have a look at the details of fuse, it's deemed to be inefficient).
+>> In the Hurd, it's that way from the _ground_ and there is no limitation
+>> like having to be root or ask for root to add magic lines, etc.
 
-> It also for instance provides very fine-grain virtualization support, such as
-> [[VPN for only one process|open_issues/virtualization/networking]], etc.
+The Hurd also for instance provides userland drivers, for instance the network
+drivers are actually Linux drivers running in a separate userland process.
 
-> etc. etc. The implications are really very diverse...
+It also for instance provides very fine-grain virtualization support, such as
+[[VPN for only one process|open_issues/virtualization/networking]], etc.
+
+etc. etc. The implications are really very diverse...