I mentioned that hurd-console fails to start, which means that users cannot use X.

1 files changed, 9 insertions, 7 deletions

diff --git a/faq/64-bit.mdwn b/faq/64-bit.mdwn
index a41d215d..ae25b500 100644
--- a/faq/64-bit.mdwn
+++ b/faq/64-bit.mdwn
@@ -19,17 +19,19 @@ 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
+Hurd developers ported GNU Mach 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
+on the x86_64 userland port in Feb 2023.  As of April 2025, 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.
+namely swapping issues with rumpdisk, deadlocking issues with
+libdiskfs/ext2fs, and the hurd-console fails to start, which means that
+you cannot use X.  
+
+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.
 
 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.