Almudena Garcia, le dim. 29 mars 2026 23:51:43 +0200, a ecrit:
> +Joshua Branson tweaked the hurd wiki.  The most helpful addition is [this
> +page]([1]https://lists.gnu.org/archive/html/bug-hurd/2026-02/msg00087.html),
> +which documents how to flash a working qemu hurd image directly to an
> +HDD or SSD.  This is a *really easy* way to install the Hurd on real
> +hardware! 
> 
> This link must point to the article ([2]https://darnassus.sceen.net/~hurd-web/
> hurd/running/flash_qemu_img/) instead the patch. 

Indeed, done so!

Samuel

> 
> El dom, 29 mar 2026 a las 19:02, Samuel Thibault 
> (<[3][email protected]>)
> escribió:
> 
>     Applied with some fixes, thanks!
> 
>     Joshua Branson, le dim. 29 mars 2026 12:37:06 -0400, a ecrit:
>     > news/2026-q1.mdwn: new file.
>     > ---
>     >  news/2026-q1.mdwn | 243 ++++++++++++++++++++++++++++++++++++++++++++++
>     >  1 file changed, 243 insertions(+)
>     >  create mode 100644 news/2026-q1.mdwn
>     >
>     > diff --git a/news/2026-q1.mdwn b/news/2026-q1.mdwn
>     > new file mode 100644
>     > index 00000000..f80ff1e5
>     > --- /dev/null
>     > +++ b/news/2026-q1.mdwn
>     > @@ -0,0 +1,250 @@
>     > +[[!meta copyright="Copyright © 2026 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]]."]]"""]]
>     > +
>     > +[[!meta date="2026-03-02 06:07 UTC"]]
>     > +
>     > +Hello!  Welcome to a new qoth.  This qoth covers new and interesting 
> GNU
>     /Hurd
>     > +developments in Q1 of 2026!
>     > +[[!if test="included()" then="""[[!toggle id=full_news
>     > +text="Details."]][[!toggleable id=full_news text="[[!paste id=
>     full_news]]"]]"""
>     > +else="
>     > +[[!paste id=full_news]]"]]
>     > +
>     > +[[!cut id="full_news" text="""
>     > +
>     > +Brent W. Baccala debugged some `x86_64` SMP issues with a Claude AI
>     > +bot.  The bot did not contribute any code.  It just found some
>     > +incorrect code that Damien then fixed.  It did get [some things
>     > +wrong]([4]https://lists.gnu.org/archive/html/bug-hurd/2026-02/
>     msg00134.html),
>     > +but it was incredibly helpful pointing out several problems.  You can
>     > +read its report
>     > +[here]([5]https://lists.gnu.org:443/archive/html/bug-hurd/2026-03/
>     msg00045.html).
>     > +
>     > +Joshua Branson tweaked the hurd wiki.  The most helpful addition is
>     [this
>     > +page]([6]https://lists.gnu.org/archive/html/bug-hurd/2026-02/
>     msg00087.html),
>     > +which documents how to flash a working qemu hurd image directly to an
>     > +HDD or SSD.  This is a *really easy* way to install the Hurd on real
>     > +hardware!  Buy a supported machine from [[this page|faq/drivers]] and
>     > +give it a shot!  Consider this another reminder that the Hurd project
>     > +could use more documentation writers.  It's an easy way to
>     > +[[contribute|contributing#index3h1]].  As a fun fact, I wrote this qoth
>     on
>     > +the Hurd running on a T420 with 12 GB of RAM!  Running Debian GNU/Hurd
>     on
>     > +bare metal these days is largely fairly stable.  Emacs, i3, netsurf,
>     > +and luakit all work just fine and most of the Debian package archive
>     > +compiles without issue on the Hurd.
>     > +
>     > +Etienne Brateau fixed a [compilation
>     > +error]([7]https://lists.gnu.org/archive/html/bug-hurd/2026-01/
>     msg00194.html).
>     > +He also provided a [simple test
>     > +program]([8]https://lists.gnu.org:443/archive/html/bug-hurd/2026-03/
>     msg00010.html)
>     > +that exposed a [rather serious threading
>     > +bug]([9]https://lists.gnu.org:443/archive/html/bug-hurd/2026-03/
>     msg00012.html),
>     > +which [Samuel promptly
>     > +fixed]([10]https://lists.gnu.org:443/archive/html/bug-hurd/2026-03/
>     msg00038.html).
>     > +This is a good reminder that writing simple C test programs that
>     > +successfully run on Linux, but fail on the Hurd can have a large
>     > +impact.
>     > +
>     > +Gianluca Cannata worked on our [httpfs translator]([11]https://
>     lists.gnu.org/archive/html/bug-hurd/2026-01/msg00138.html).
>     > +
>     > +Diego Nieto Cid added a `daemon-wait` [option for
>     > +console-client]([12]https://lists.gnu.org:443/archive/html/bug-hurd/
>     2026-03/msg00229.html).
>     > +This can help users with slow machines avoid a broken Hurd console.
>     > +He also fixed a [rumpdisk compilation issue]([13]https://
>     lists.gnu.org:443/archive/html/bug-hurd/2026-03/msg00195.html).
>     > +
>     > +Mike Kelley fixed a deadlock in [SMP enabled GNU Mach
>     > +kernels]([14]https://lists.gnu.org/archive/html/bug-hurd/2026-01/
>     msg00165.html).
>     > +He also fixed a [page fault in amd64 SMP
>     > +kernels]([15]https://lists.gnu.org:443/archive/html/bug-hurd/2026-03/
>     msg00197.html).
>     > +He fixed another deadlock in the [alarm ()
>     > +function]([16]https://lists.gnu.org/archive/html/bug-hurd/2026-02/
>     msg00059.html).
>     > +He fixed a [panic when running large
>     > +builds]([17]https://lists.gnu.org:443/archive/html/bug-hurd/2026-03/
>     msg00122.html)
>     > +without the `mach-defpager`.  He also fixed some of our [signal
>     > +related
>     > +code]([18]https://lists.gnu.org/archive/html/bug-hurd/2026-02/
>     msg00003.html).
>     > +He worked with Samuel to investigate an odd
>     > +[bug]([19]https://lists.gnu.org:443/archive/html/bug-hurd/2026-03/
>     msg00135.html).
>     > +Their detailed investigation uncovered and lead to a fix in the [Hurd's
>     ext2's
>     > +xattr 
> code]([20]https://lists.gnu.org:443/archive/html/bug-hurd/2026-03/
>     msg00072.html).
>     > +
>     > +Joan Lledó updated some patches for the [dhcpcd
>     > +port]([21]https://lists.gnu.org/archive/html/bug-hurd/2026-01/
>     msg00062.html)
>     > +as well as some patches for [upstream
>     > +liblwip]([22]https://lists.gnu.org/archive/html/bug-hurd/2026-01/
>     msg00054.html).
>     > +He also tweaked our [lwip
>     > +translator]([23]https://lists.gnu.org/archive/html/bug-hurd/2026-01/
>     msg00049.html).
>     > +He also added a [glibc
>     > +patch]([24]https://lists.gnu.org/archive/html/bug-hurd/2026-01/
>     msg00041.html)
>     > +for `IP_PKTINFO`.
>     > +
>     > +Milos Nikic
>     > +[added]([25]https://lists.gnu.org/archive/html/bug-hurd/2026-02/
>     msg00048.html)
>     > +[some]([26]https://lists.gnu.org/archive/html/bug-hurd/2026-01/
>     msg00244.html)
>     > +[various]([27]https://lists.gnu.org/archive/html/bug-hurd/2026-01/
>     msg00245.html)
>     > +[fixes]([28]https://lists.gnu.org/archive/html/bug-hurd/2026-02/
>     msg00113.html).
>     > +He also made
>     > +[many]([29]https://lists.gnu.org/archive/html/bug-hurd/2026-02/
>     msg00060.html)
>     > +[considerable]([30]https://lists.gnu.org/archive/html/bug-hurd/2026-01/
>     msg00235.html)
>     > 
> +[contributions]([31]https://lists.gnu.org/archive/html/bug-hurd/2026-01/
>     msg00221.html)
>     > +[on]([32]https://lists.gnu.org/archive/html/bug-hurd/2026-01/
>     msg00220.html)
>     > +[filesystem]([33]https://lists.gnu.org/archive/html/bug-hurd/2026-01/
>     msg00219.html)
>     > +[related]([34]https://lists.gnu.org/archive/html/bug-hurd/2026-01/
>     msg00142.html)
>     > +things including [adding ext2fs support for 64 bit
>     > +time]([35]https://lists.gnu.org/archive/html/bug-hurd/2026-01/
>     msg00230.html),
>     > +He also fixed a [rumpdisk
>     > +deadlock]([36]https://lists.gnu.org/archive/html/bug-hurd/2026-01/
>     msg00233.html).
>     > +He also fixed a potential lock in [GNU
>     > +Mach]([37]https://lists.gnu.org/archive/html/bug-hurd/2026-02/
>     msg00039.html).
>     > +He fixed some [IPC issues in
>     > +glibc]([38]https://lists.gnu.org/archive/html/bug-hurd/2026-02/
>     msg00040.html).
>     > +He [contributed
>     > +some]([39]https://lists.gnu.org:443/archive/html/bug-hurd/2026-03/
>     msg00043.html)
>     > +[tiny
>     > +fixes]([40]https://lists.gnu.org:443/archive/html/bug-hurd/2026-03/
>     msg00028.html)
>     > +to speed up GNU Mach's IPC.  His most exciting work is a [JDB2 binary
>     > +compliant
>     > +journal]([41]https://lists.gnu.org/archive/html/bug-hurd/2026-01/
>     msg00186.html),
>     > +which is an ext3/ext4 compatible journal.  The Hurd may soon be running
>     on
>     > +`ext3fs` or `ext4fs` instead of `ext2fs`!  He writes:
>     > +
>     > +    I have been working on creating a prototype for a journal inside
>     > +    ext2fs which is fully Linux compatible (binary JBD2 compatible).
>     This
>     > +    enables standard Linux tools (e2fsck, tune2fs, debugfs, etc.) to
>     work
>     > +    seamlessly with Hurd partitions.
>     > +
>     > +    This means one can mount a Hurd image from Linux and fix any issues
>     > +    with the drive using standard journaling tools if the need
>     > +    arises. While this is currently a prototype with polish still
>     > +    required, it is functional.
>     > +
>     > +    Key Features:
>     > +    * Log Replay: The driver writes JBD2-compliant transactions. I have
>     > +      verified that after a hard crash of the Hurd guest, a Linux host
>     > +      running e2fsck correctly replays the journal and restores
>     filesystem
>     > +      metadata consistency.
>     > +    * Continuous Operation: The driver handles ring-buffer wrap-around
>     and
>     > +      checkpoints correctly. I have tested it with sustained loads
>     > +      (50,000+ transaction loops) without deadlocks or corruption.
>     > +    * Crash Safety: I have verified via "sabotage tests" (modifying the
>     > +      disk offline after a crash) that the journal accurately restores
>     the
>     > +      correct metadata state.
>     > +    * Lightweight: The implementation consists of only a few new files
>     and
>     > +      ~800 lines of code.
>     > +
>     > +You can read the complete email 
> [here]([42]https://lists.gnu.org/archive
>     /html/bug-hurd/2026-01/msg00186.html).
>     > +
>     > +He then tweaked the code a few times and summed up the current status.
>     > +He 
> [writes:]([43]https://lists.gnu.org:443/archive/html/bug-hurd/2026-03
>     /msg00166.html)
>     > +
>     > +    This is it. I have applied numerous fixes, performance tweaks, and
>     > +    cleanups. I am happy to report that this (the journal) now performs
>     on
>     > +    par with unjournaled ext2 on normal workloads, such as
>     > +    configuring/compiling the Hurd, installing and reinstalling 
> packages
>     > +    via APT, and untarring large archives (like the Linux kernel). I
>     have
>     > +    also heavily tested it against artificial stress conditions (which 
> I
>     > +    am happy to share if there is interest), and it handles highly
>     > +    concurrent loads beautifully without deadlocks or memory leaks.
>     > +
>     > +    Progressive checkpointing ensures the filesystem runs smoothly, and
>     > +    the feature remains strictly opt-in (until a partition is tuned 
> with
>     > +    tune2fs -j, the journal is completely inactive).
>     > +
>     > +    The new API in libdiskfs is minimal but expressive enough to wrap
>     all
>     > +    filesystem operations in transactions and handle strict POSIX sync
>     > +    barriers.
>     > +
>     > +
>     > +Manolo de Medici fixed a [bug allowing unprivileged users to modify
>     > +the system
>     > +time]([44]https://lists.gnu.org:443/archive/html/bug-hurd/2026-03/
>     msg00235.html).
>     > +He also worked on [partially opening up the processor set API to
>     > +unprivileged
>     > +processes]([45]https://lists.gnu.org:443/archive/html/bug-hurd/2026-03/
>     msg00169.html).
>     > +
>     > +
>     > +Samuel Thibault gave an update on the [GNU Hurd
>     > +project]([46]https://fosdem.org/2026/schedule/event/
>     
> 7FZXHF-updates_on_gnuhurd_progress_rump_drivers_64bit_smp_software_bootstrapping
>     /).
>     > +His talk dived into [[hurd/rump/rumpnet]], [[hurd/rump/rumpdisk]],
>     > +[[open_issues/smp]], etc.  It was quite an interesting talk.
>     > +Essentially the Hurd is becoming a fairly stable option for daily
>     > +computing.  Check out our [[hurd/status]] page for more information.
>     > +He provided numerous fixes for packages that were failing to build,
>     > +like
>     > +[xserver-xorg-input-keyboard]([47]https://lists.debian.org/debian-hurd/
>     2026/01/msg00020.html).
>     > +He also reported on a [rumpnet
>     > +bug]([48]https://lists.gnu.org/archive/html/bug-hurd/2026-02/
>     msg00075.html),
>     > +which highlighted an interesting feature of the Hurd's design.  When
>     > +Hurd's new or experimental device drivers crash, it does not bring
>     > +down the system.  One can just restart the driver.  If a device driver
>     > +crashes in Linux or BSD land, you may be in trouble.
>     > +
>     > +He also discovered why the Hurd's crash translator [hanged when
>     > +generating core files on
>     > +amd64]([49]https://lists.gnu.org/archive/html/bug-hurd/2026-02/
>     msg00074.html).
>     > +Thanks to a lot of code from Damien, Samuel was able to upload an
>     > +[amd64 SMP kernel to Debian
>     > +Hurd]([50]https://lists.debian.org/debian-hurd/2026/02/msg00103.html)!
>     > +This kernel still restricts processes to `cpu0`, but with the
>     > +`/sbin/smp` utility, one can experimentally run applications on
>     > +multiple cores.  Once we fix the various race conditions, we can run
>     > +more of the Hurd via SMP.  Please be aware that testing programs via
>     > +`/sbin/smp` can lead to crashes.
>     > +
>     > +Mesa was also ported to the Hurd.  The patches are not quite [merged
>     > +upstream]([51]https://gitlab.freedesktop.org/mesa/libdrm/-/
>     merge_requests/443).
>     > +The Hurd does not have a DRM yet, so the performance
>     > +is quite poor.  `nexussfan` on irc ported
>     > +[ClassiCube]([52]https://github.com/ClassiCube/ClassiCube/pull/1517).
>     > +It runs quite slowly.  We are hoping to eventually add a proper DRM
>     > +to the Hurd. Please reach out if you'd like to help us achieve this.
>     > +
>     > +Florian Weimer worked on fixing [some signal processing 
> bugs]([53]https:
>     //lists.gnu.org/archive/html/bug-hurd/2026-01/msg00056.html).
>     > +
>     > +Damien Zammit [ported qemu to the
>     > +Hurd]([54]https://lists.gnu.org/archive/html/bug-hurd/2026-01/
>     msg00266.html).
>     > +He is currently using it for his [continuous
>     > +integration]([55]https://mail.gnu.org/archive/html/bug-hurd/2026-01/
>     msg00199.html).
>     > +It uses a Hurd host to launch qemu to test GNU Mach.  He made many
>     > +contributions to the Hurd's
>     > +[CI]([56]https://lists.gnu.org/archive/html/bug-hurd/2026-01/
>     msg00183.html)
>     > +including [testing the Hurd's xen
>     > +support]([57]https://lists.gnu.org/archive/html/bug-hurd/2026-02/
>     msg00021.html). He
>     > +[fixed GNU Mach compilation on GCC
>     > +10]([58]https://lists.gnu.org/archive/html/bug-hurd/2026-01/
>     msg00182.html).
>     > +He also contributed
>     > +[a]([59]https://lists.gnu.org/archive/html/bug-hurd/2026-02/
>     msg00111.html)
>     > +[lot]([60]https://lists.gnu.org/archive/html/bug-hurd/2026-02/
>     msg00127.html)
>     > +[of]([61]https://lists.gnu.org/archive/html/bug-hurd/2026-01/
>     msg00148.html)
>     > +[fixes]([62]https://lists.gnu.org/archive/html/bug-hurd/2026-01/
>     msg00181.html)
>     > +[for]([63]https://lists.gnu.org/archive/html/bug-hurd/2026-01/
>     msg00098.html)
>     > +[the Hurd's]([64]https://lists.gnu.org/archive/html/bug-hurd/2026-01/
>     msg00083.html)
>     > +[x86_64]([65]https://lists.gnu.org/archive/html/bug-hurd/2026-01/
>     msg00007.html)
>     > +[support]([66]https://lists.gnu.org/archive/html/bug-hurd/2026-01/
>     msg00185.html).
>     > +Thanks to Damien's numerous contributions, the Hurd's SMP support is
>     > +becoming far more useful!
>     > +
>     > +If you did not see the recent Guix Hurd news, then please check out
>     > +their [most recent blog
>     > +post]([67]https://guix.gnu.org/en/blog/2026/the-64-bit-hurd)!  There 
> are
>     > +currently two active GNU Hurd distributions: Debian GNU/Hurd and GNU
>     > +Guix Hurd.  These two distributions run on real hardware!  If you have
>     > +been closely reading the `#hurd` irc channel, then you may have heard
>     > +about some work on adding another Hurd distribution.  Perhaps we will
>     > +have more to report on this exciting news in the next Qoth!
>     > +
>     > +The **GNU Hurd** is the GNU project's replacement for the Unix kernel. 
>     It is a
>     > +collection of servers that run on the Mach microkernel to implement 
> file
>     > +systems, network protocols, file access control, and other features 
> that
>     are
>     > +implemented by the Unix kernel or similar kernels (such as Linux). 
>     [[More
>     > +detailed|hurd/documentation]].
>     > +
>     > +**GNU Mach** is the microkernel upon which a GNU Hurd system is based. 
>     It
>     > +provides an Inter Process Communication (IPC) mechanism that the Hurd
>     uses to
>     > +define interfaces for implementing in a distributed multi-server 
> fashion
>     the
>     > +services a traditional operating system kernel provides.  [[More
>     > +detailed|microkernel/mach/gnumach]].
>     > +
>     > +"""]]
>     > --
>     > 2.53.0
>     >
>     >
> 
>     --
>     Samuel
>     Q:      How do you play religious roulette?
>     A:      You stand around in a circle and blaspheme and see who gets struck
>     by lightning first.
> 
> 
> 
> References:
> 
> [1] https://lists.gnu.org/archive/html/bug-hurd/2026-02/msg00087.html
> [2] https://darnassus.sceen.net/~hurd-web/hurd/running/flash_qemu_img/
> [3] mailto:[email protected]
> [4] https://lists.gnu.org/archive/html/bug-hurd/2026-02/msg00134.html
> [5] https://lists.gnu.org/archive/html/bug-hurd/2026-03/msg00045.html
> [6] https://lists.gnu.org/archive/html/bug-hurd/2026-02/msg00087.html
> [7] https://lists.gnu.org/archive/html/bug-hurd/2026-01/msg00194.html
> [8] https://lists.gnu.org/archive/html/bug-hurd/2026-03/msg00010.html
> [9] https://lists.gnu.org/archive/html/bug-hurd/2026-03/msg00012.html
> [10] https://lists.gnu.org/archive/html/bug-hurd/2026-03/msg00038.html
> [11] https://lists.gnu.org/archive/html/bug-hurd/2026-01/msg00138.html
> [12] https://lists.gnu.org/archive/html/bug-hurd/2026-03/msg00229.html
> [13] https://lists.gnu.org/archive/html/bug-hurd/2026-03/msg00195.html
> [14] https://lists.gnu.org/archive/html/bug-hurd/2026-01/msg00165.html
> [15] https://lists.gnu.org/archive/html/bug-hurd/2026-03/msg00197.html
> [16] https://lists.gnu.org/archive/html/bug-hurd/2026-02/msg00059.html
> [17] https://lists.gnu.org/archive/html/bug-hurd/2026-03/msg00122.html
> [18] https://lists.gnu.org/archive/html/bug-hurd/2026-02/msg00003.html
> [19] https://lists.gnu.org/archive/html/bug-hurd/2026-03/msg00135.html
> [20] https://lists.gnu.org/archive/html/bug-hurd/2026-03/msg00072.html
> [21] https://lists.gnu.org/archive/html/bug-hurd/2026-01/msg00062.html
> [22] https://lists.gnu.org/archive/html/bug-hurd/2026-01/msg00054.html
> [23] https://lists.gnu.org/archive/html/bug-hurd/2026-01/msg00049.html
> [24] https://lists.gnu.org/archive/html/bug-hurd/2026-01/msg00041.html
> [25] https://lists.gnu.org/archive/html/bug-hurd/2026-02/msg00048.html
> [26] https://lists.gnu.org/archive/html/bug-hurd/2026-01/msg00244.html
> [27] https://lists.gnu.org/archive/html/bug-hurd/2026-01/msg00245.html
> [28] https://lists.gnu.org/archive/html/bug-hurd/2026-02/msg00113.html
> [29] https://lists.gnu.org/archive/html/bug-hurd/2026-02/msg00060.html
> [30] https://lists.gnu.org/archive/html/bug-hurd/2026-01/msg00235.html
> [31] https://lists.gnu.org/archive/html/bug-hurd/2026-01/msg00221.html
> [32] https://lists.gnu.org/archive/html/bug-hurd/2026-01/msg00220.html
> [33] https://lists.gnu.org/archive/html/bug-hurd/2026-01/msg00219.html
> [34] https://lists.gnu.org/archive/html/bug-hurd/2026-01/msg00142.html
> [35] https://lists.gnu.org/archive/html/bug-hurd/2026-01/msg00230.html
> [36] https://lists.gnu.org/archive/html/bug-hurd/2026-01/msg00233.html
> [37] https://lists.gnu.org/archive/html/bug-hurd/2026-02/msg00039.html
> [38] https://lists.gnu.org/archive/html/bug-hurd/2026-02/msg00040.html
> [39] https://lists.gnu.org/archive/html/bug-hurd/2026-03/msg00043.html
> [40] https://lists.gnu.org/archive/html/bug-hurd/2026-03/msg00028.html
> [41] https://lists.gnu.org/archive/html/bug-hurd/2026-01/msg00186.html
> [42] https://lists.gnu.org/archive/html/bug-hurd/2026-01/msg00186.html
> [43] https://lists.gnu.org/archive/html/bug-hurd/2026-03/msg00166.html
> [44] https://lists.gnu.org/archive/html/bug-hurd/2026-03/msg00235.html
> [45] https://lists.gnu.org/archive/html/bug-hurd/2026-03/msg00169.html
> [46] 
> https://fosdem.org/2026/schedule/event/7FZXHF-updates_on_gnuhurd_progress_rump_drivers_64bit_smp_software_bootstrapping/
> [47] https://lists.debian.org/debian-hurd/2026/01/msg00020.html
> [48] https://lists.gnu.org/archive/html/bug-hurd/2026-02/msg00075.html
> [49] https://lists.gnu.org/archive/html/bug-hurd/2026-02/msg00074.html
> [50] https://lists.debian.org/debian-hurd/2026/02/msg00103.html
> [51] https://gitlab.freedesktop.org/mesa/libdrm/-/merge_requests/443
> [52] https://github.com/ClassiCube/ClassiCube/pull/1517
> [53] https://lists.gnu.org/archive/html/bug-hurd/2026-01/msg00056.html
> [54] https://lists.gnu.org/archive/html/bug-hurd/2026-01/msg00266.html
> [55] https://mail.gnu.org/archive/html/bug-hurd/2026-01/msg00199.html
> [56] https://lists.gnu.org/archive/html/bug-hurd/2026-01/msg00183.html
> [57] https://lists.gnu.org/archive/html/bug-hurd/2026-02/msg00021.html
> [58] https://lists.gnu.org/archive/html/bug-hurd/2026-01/msg00182.html
> [59] https://lists.gnu.org/archive/html/bug-hurd/2026-02/msg00111.html
> [60] https://lists.gnu.org/archive/html/bug-hurd/2026-02/msg00127.html
> [61] https://lists.gnu.org/archive/html/bug-hurd/2026-01/msg00148.html
> [62] https://lists.gnu.org/archive/html/bug-hurd/2026-01/msg00181.html
> [63] https://lists.gnu.org/archive/html/bug-hurd/2026-01/msg00098.html
> [64] https://lists.gnu.org/archive/html/bug-hurd/2026-01/msg00083.html
> [65] https://lists.gnu.org/archive/html/bug-hurd/2026-01/msg00007.html
> [66] https://lists.gnu.org/archive/html/bug-hurd/2026-01/msg00185.html
> [67] https://guix.gnu.org/en/blog/2026/the-64-bit-hurd

-- 
Samuel
<N>  sl  -  display animations aimed to correct users who accidentally enter
<N>        sl instead of ls.

Reply via email to