+Joshua Branson tweaked the hurd wiki. The most helpful addition is [this +page](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 ( https://darnassus.sceen.net/~hurd-web/hurd/running/flash_qemu_img/) instead the patch. El dom, 29 mar 2026 a las 19:02, Samuel Thibault (<[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]( > 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]( > 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](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]( > https://lists.gnu.org/archive/html/bug-hurd/2026-01/msg00194.html). > > +He also provided a [simple test > > +program]( > https://lists.gnu.org:443/archive/html/bug-hurd/2026-03/msg00010.html) > > +that exposed a [rather serious threading > > +bug]( > https://lists.gnu.org:443/archive/html/bug-hurd/2026-03/msg00012.html), > > +which [Samuel promptly > > +fixed]( > 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]( > https://lists.gnu.org/archive/html/bug-hurd/2026-01/msg00138.html). > > + > > +Diego Nieto Cid added a `daemon-wait` [option for > > +console-client]( > 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]( > https://lists.gnu.org:443/archive/html/bug-hurd/2026-03/msg00195.html). > > + > > +Mike Kelley fixed a deadlock in [SMP enabled GNU Mach > > +kernels]( > https://lists.gnu.org/archive/html/bug-hurd/2026-01/msg00165.html). > > +He also fixed a [page fault in amd64 SMP > > +kernels]( > https://lists.gnu.org:443/archive/html/bug-hurd/2026-03/msg00197.html). > > +He fixed another deadlock in the [alarm () > > +function]( > https://lists.gnu.org/archive/html/bug-hurd/2026-02/msg00059.html). > > +He fixed a [panic when running large > > +builds]( > 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](https://lists.gnu.org/archive/html/bug-hurd/2026-02/msg00003.html > ). > > +He worked with Samuel to investigate an odd > > +[bug]( > 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]( > https://lists.gnu.org:443/archive/html/bug-hurd/2026-03/msg00072.html). > > + > > +Joan Lledó updated some patches for the [dhcpcd > > +port](https://lists.gnu.org/archive/html/bug-hurd/2026-01/msg00062.html > ) > > +as well as some patches for [upstream > > +liblwip]( > https://lists.gnu.org/archive/html/bug-hurd/2026-01/msg00054.html). > > +He also tweaked our [lwip > > +translator]( > https://lists.gnu.org/archive/html/bug-hurd/2026-01/msg00049.html). > > +He also added a [glibc > > +patch]( > https://lists.gnu.org/archive/html/bug-hurd/2026-01/msg00041.html) > > +for `IP_PKTINFO`. > > + > > +Milos Nikic > > +[added]( > https://lists.gnu.org/archive/html/bug-hurd/2026-02/msg00048.html) > > +[some]( > https://lists.gnu.org/archive/html/bug-hurd/2026-01/msg00244.html) > > +[various]( > https://lists.gnu.org/archive/html/bug-hurd/2026-01/msg00245.html) > > +[fixes]( > https://lists.gnu.org/archive/html/bug-hurd/2026-02/msg00113.html). > > +He also made > > +[many]( > https://lists.gnu.org/archive/html/bug-hurd/2026-02/msg00060.html) > > +[considerable]( > https://lists.gnu.org/archive/html/bug-hurd/2026-01/msg00235.html) > > +[contributions]( > https://lists.gnu.org/archive/html/bug-hurd/2026-01/msg00221.html) > > +[on](https://lists.gnu.org/archive/html/bug-hurd/2026-01/msg00220.html) > > +[filesystem]( > https://lists.gnu.org/archive/html/bug-hurd/2026-01/msg00219.html) > > +[related]( > https://lists.gnu.org/archive/html/bug-hurd/2026-01/msg00142.html) > > +things including [adding ext2fs support for 64 bit > > +time](https://lists.gnu.org/archive/html/bug-hurd/2026-01/msg00230.html > ), > > +He also fixed a [rumpdisk > > +deadlock]( > https://lists.gnu.org/archive/html/bug-hurd/2026-01/msg00233.html). > > +He also fixed a potential lock in [GNU > > +Mach](https://lists.gnu.org/archive/html/bug-hurd/2026-02/msg00039.html > ). > > +He fixed some [IPC issues in > > +glibc]( > https://lists.gnu.org/archive/html/bug-hurd/2026-02/msg00040.html). > > +He [contributed > > +some]( > https://lists.gnu.org:443/archive/html/bug-hurd/2026-03/msg00043.html) > > +[tiny > > +fixes]( > 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]( > 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]( > 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:]( > 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]( > 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]( > https://lists.gnu.org:443/archive/html/bug-hurd/2026-03/msg00169.html). > > + > > + > > +Samuel Thibault gave an update on the [GNU Hurd > > +project]( > 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]( > https://lists.debian.org/debian-hurd/2026/01/msg00020.html). > > +He also reported on a [rumpnet > > +bug](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]( > 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](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]( > 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](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]( > https://lists.gnu.org/archive/html/bug-hurd/2026-01/msg00056.html). > > + > > +Damien Zammit [ported qemu to the > > +Hurd](https://lists.gnu.org/archive/html/bug-hurd/2026-01/msg00266.html > ). > > +He is currently using it for his [continuous > > +integration]( > 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](https://lists.gnu.org/archive/html/bug-hurd/2026-01/msg00183.html) > > +including [testing the Hurd's xen > > +support]( > https://lists.gnu.org/archive/html/bug-hurd/2026-02/msg00021.html). He > > +[fixed GNU Mach compilation on GCC > > +10](https://lists.gnu.org/archive/html/bug-hurd/2026-01/msg00182.html). > > +He also contributed > > +[a](https://lists.gnu.org/archive/html/bug-hurd/2026-02/msg00111.html) > > +[lot](https://lists.gnu.org/archive/html/bug-hurd/2026-02/msg00127.html > ) > > +[of](https://lists.gnu.org/archive/html/bug-hurd/2026-01/msg00148.html) > > +[fixes]( > https://lists.gnu.org/archive/html/bug-hurd/2026-01/msg00181.html) > > +[for](https://lists.gnu.org/archive/html/bug-hurd/2026-01/msg00098.html > ) > > +[the Hurd's]( > https://lists.gnu.org/archive/html/bug-hurd/2026-01/msg00083.html) > > +[x86_64]( > https://lists.gnu.org/archive/html/bug-hurd/2026-01/msg00007.html) > > +[support]( > 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](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. > >
