6 files changed, 40 insertions, 40 deletions
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_inside_glibc.mdwn b/faq/debugging_inside_glibc.mdwn
index 2a75a1a7..8577dce3 100644
--- a/faq/debugging_inside_glibc.mdwn
+++ b/faq/debugging_inside_glibc.mdwn
@@ -13,9 +13,7 @@ License|/fdl]]."]]"""]]
 
 In Debian, to get [[debugging]] information for glibc, you need to install the
 `libc0.3-dbg` package.  At the place [[debugging/GDB]] looks for debugging
-symbols by default (`/usr/lib/debug/lib/`), Debian's `libc0.3-dbg` stores only
-the frame unwind information used for backtracing.  If you want to step into
-glibc while debugging, you need to add `LD_LIBRARY_PATH=/usr/lib/debug` to
-debugged program's environment (`set env VAR value` from the GDB command line).
-If that still does not work, try `LD_PRELOAD=/usr/lib/debug/libc.so.0.3`
-instead.
+symbols by default (`/usr/lib/debug/.build-id`), Debian's `libc0.3-dbg` stores only
+the frame unwind information used for backtracing.
+
+You also need to download the source code with `apt source glibc` and `cd` into it for `gdb` to be able to find and show it, or use `set directories` inside gdb, or put it in your `.gdbinit`
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/drivers.mdwn b/faq/drivers.mdwn
index 923e3b38..16d60a9a 100644
--- a/faq/drivers.mdwn
+++ b/faq/drivers.mdwn
@@ -19,14 +19,18 @@ 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.
+CrossInstall|hurd/running/debian/CrossInstall]] or 
+[[mmdebstrap|https://lists.debian.org/debian-hurd/2024/12/msg00003.html]].  
+
+_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 14015b9b..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,16 +35,17 @@ 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 acually checking against overflows. `PATH_MAX` being 4096 is
+that is not actually checking against overflows. `PATH_MAX` being 4096 is
 actually "wrong" on Linux:
 
     $ printf '#include <limits.h>\nPATH_MAX' | cpp -P