Applied, thanks! Samuel
[email protected], le ven. 02 janv. 2026 21:04:12 +0000, a ecrit: > I'm having some issues with git send-email at the moment. > > I'm attaching the latest qoth. > > Thanks! > > Joshua > [[!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-01-02 06:07 UTC"]] > > Hello! Welcome to a new qoth. This qoth covers new and interesting GNU/Hurd > developments in Q4 of 2025! > [[!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=""" > > Joan Lledó worked on [porting > dhcpcd](https://lists.gnu.org/archive/html/bug-hurd/2025-10/msg00084.html) > to the hurd. He also made some changes so that > [lwip would work with > dhcpcd](https://lists.gnu.org/archive/html/bug-hurd/2025-10/msg00068.html). In > this > [message](https://lists.gnu.org/archive/html/bug-hurd/2025-10/msg00084.html) > he writes: > > > This is the current state of the port: > > > > - Support only for IPv4. IPv6 not supported yet. > > - It works only over lwip. First, because dhcpcd requires some definitions > > from > > headers and pfinet doesn't provide them AFAIK, but lwip provide the > > headers > > through the liblwip-dev package. > > Second, because both pfinet and lwip need changes in the translator in > > order > > to be fully compatible with dhcpcd, and I made the changes in lwip since I > > know it better. > > - Only Ethernet is supported. This is because the Hurd doesn't define > > `AF_LINK` > > so dhcpcd can't get any data from the interface other thant what is > > returned > > by `getifaddrs()`. > > I'm manually providing the MAC address and hardcoding the interface type > > to > > Ethernet in the `if_init` function. I assume this is correct because the > > Hurd > > only supports ethernet interfaces AFAIK. > > - dhcpcd monitors the interfaces and gets notified when there are changes in > > routes or network configurations. This is not working yet for the Hurd. > > - dhcpcd implements some privilege separation by which the process spawns > > new > > processes that run as a non-privileged user. Or that's what I understood. > > It's not implemented for the Hurd because I've deferred this for now. > > - Access to BPF is provided by libpcap. > > - libpcap and liblwip-dev are dependencies for the Hurd. > > - This has been tested only in a 32-bit Hurd. > > Damien Zammit worked on fixing > [some](https://lists.gnu.org/archive/html/bug-hurd/2025-10/msg00123.html) > [interupt > bugs](https://lists.gnu.org/archive/html/bug-hurd/2025-10/msg00132.html) > in the acpi server. > > He also made some > [fixes](https://lists.gnu.org/archive/html/bug-hurd/2025-10/msg00059.html) > for rumpnet. > > He also worked on adding a > [callwheel to GNU Mach's > clock](https://lists.gnu.org:443/archive/html/bug-hurd/2025-12/msg00015.html). > This would make GNU Mach faster in certain ways. Particularly, Damien > noticed > that his machine boots up one second faster. He writes: > > > Timeouts are now very fast to look up, at the expense of more memory, > > a much shorter list is traversed rather than all of them. See [1]. > > Timeouts that are stopped before expiry are now faster to remove, > > and inserting a timeout is faster. > > [1] [https://doi.org/10.7936/K7VM49H5](https://doi.org/10.7936/K7VM49H5) > > Damien also made some progress on the > [SMP support for > `x86_64`](https://lists.gnu.org/archive/html/bug-hurd/2026-01/msg00007.html). > He writes: > > > This allows gnumach to be compiled with `--enable-ncpus > 1 on x86_64`. > > However, there is still work to be done particularly with SWAPGS > > instruction. Notably, this changeset modifies the AP low boot address > > to be hardcoded to 0x11000 because it is very difficult to implement > > 64 bit AP bringup without knowing the offset in advance of waking up > > the AP via SIPI. > > > > TESTED: > > > > - i386 UP still boots > > - i386 SMP still works with -smp 1 (but freezes during rumpdisk probe) > > - i386 SMP still works with -smp 6 (but freezes during rumpdisk probe) > > - `x86_64 UP` still boots > > - `x86_64 SMP` now compiles, but freezes with -smp 1 during grub module load > > - `x86_64 SMP` now compiles, but freezes with -smp 6 just before AP bringup > > > > We still have work to do, but this definitely makes progress. > > > We had a kind developer submit a tiny patch that kills > [lingering zombie > processes](https://lists.gnu.org:443/archive/html/bug-hurd/2025-12/msg00019.html). > > > > Diego Nieto Cid fixed several compiler warnings throughout our codebase: > [lwip](https://lists.gnu.org/archive/html/bug-hurd/2025-10/msg00052.html), > [nfsd](https://lists.gnu.org/archive/html/bug-hurd/2025-10/msg00050.html), > [nfs](https://lists.gnu.org/archive/html/bug-hurd/2025-10/msg00047.html), etc. > > He also tidied up the glibc `setrlimit ()` call that lets a process limit > its consumption of system resources. When Samuel committed this he > [noticied](https://lists.gnu.org:443/archive/html/bug-hurd/2025-12/msg00052.html) > that it works well. Samuel wrote: > > > Thanks for this! That will stabilize boxes against programs that > > allocate like crazy! > > > > Yes, it works well ; on packages that used to kill buildd boxes, we > > properly get virtual addressing space limitation errors. > > For some time now, Mike Kelly has used `stress-ng` to stress test the hurd, > and he keeps finding bugs to > [fix](https://lists.gnu.org:443/archive/html/bug-hurd/2025-11/msg00038.html). > He > has even started to stress test in > [real > hardware](https://lists.gnu.org:443/archive/html/bug-hurd/2025-12/msg00023.html)! > > Thanks Mike for making the Hurd more stable! > > He also worked on gnumach [fiddling > to](https://lists.gnu.org:443/archive/html/bug-hurd/2025-12/msg00026.html) > [decrease compile > time](https://lists.gnu.org:443/archive/html/bug-hurd/2025-12/msg00047.html). > He writes: > > > This implementation now searches for pages in the order: inactive/external, > > inactive/internal, active/external and active/internal as suggested by > > Samuel > > (https://lists.gnu.org/archive/html/bug-hurd/2025-12/msg00034.html). The > > performance improvement is considerable. A test case involving 3 instances > > of > > g++ compiling C++ template code (MatrixSine.cpp from libeigen-dev) uses > > sufficient memory on a 4GB machine to require around 500MB of swap. This > > test > > takes about 11 minutes with previous gnumach version (using a virtual > > machine) > > but 3 minutes with this alteration. I have not been able to complete this > > test > > on a 64 bit Hurd 'real hardware' installation with previous gnumach but the > > compilation does complete with this patch after about 10 minutes > > João Pedro Malhado updated our > [alternative hurd installation documentation > page](https://lists.gnu.org/archive/html/bug-hurd/2025-10/msg00035.html). > I think it's pretty cool, that using a Debian GNU/Linux computer, one can > install > the Hurd via mmdebstrap. > > We also now have some people running the `x86_64` hurd port on > [real > hardware](https://lists.gnu.org/archive/html/bug-hurd/2025-10/msg00001.html). > > Some time ago, Milos Nikic, implemented a > [metadata journal for > ext2fs](https://lists.gnu.org:443/archive/html/bug-hurd/2025-08/msg00040.html). > It has not been commited to `libdiskfs`, and it is a > [different design from > ext3](https://lists.gnu.org:443/archive/html/bug-hurd/2025-07/msg00048.html). > He writes: > > > This patch introduces a working implementation that captures metadata > > changes, > > writes them to a CRC32-protected journal file, and replays them during early > > boot—before fsck runs—allowing us to correct inconsistencies > > proactively. > > > > I'm now using this system routinely without issues, and I believe it already > > provides value for users. > > Some people are mentioning on other news channels that Debian is considering > requiring rust for apt. We just want to mention that rust was ported to the > Hurd, > so while there might be some challenges in getting a "rusted" apt working on > the Hurd, > we do not forsee any > [unsurmountable > problems](https://lists.gnu.org:443/archive/html/bug-hurd/2025-11/msg00014.html). > > In other rust news, apparently the crate `uzers-rs` has recently been built > with > [Hurd > support](https://lists.gnu.org:443/archive/html/bug-hurd/2025-12/msg00020.html). > Apparently, > this is quite a commonly used crate, which should help more rust code work on > the Hurd. > > > --- > > 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]]. > > """]] -- Samuel <y> ça gaze ? <l> prout -+- #ens-mim - ouvrez les fenêtres ! -+-
