I’d like to tell you a bit of a story. The year was 2006ish, and I was a fresh-faced university student studying computer science abroad in Adelaide. Being back in the country where I was born, but otherwise didn’t really grow up, felt alien in a way I hear “army brats” and other third-culture kids describe. It’s weird: people think you’re a local based on your accent and appearance, but you’re not. I didn’t know the sports teams let alone the different codes, I was unfamiliar with local customs, and while I could speak some of the vernacular inherited from my parents, more recent lingo made absolutely no sense. But I digress!

A habit I got into when studying in Adelaide, which I’d also carry through to Sydney in the 2010s, was to befriend or at least speak with my favourite lecturers. Originally I’d do it to ask questions, but I also got to know many of them. They were always incredibly generous with their time, and I’d often learn more grabbing a coffee—or beer—with them than I ever did in their lectures. That’s not to say I didn’t find their lectures useful, but obviously the bandwidth and enjoyment are both higher when you’re talking 1:1.

One of my lecturers at the time saw I had an interest in old UNIX, and gave me a teal SGI Indigo2. I was flabbergasted. I held onto it for a solid three weeks before it was stolen out of my dorm, along with my first Panasonic Lumux digital camera, and my 4.0 MiB childhood Palm IIIx. I’ve mentioned it in passing here over the years, but the impact on me was devastating. The financial hit was rough, but I wondered if the thief even knew how special, unique, and precious that SGI box really was. For all I knew, they realised it wasn’t a PC and binned it.

For those unfamiliar, SGI made the workstations people wanted in the 1990s. They were doing consumer-friendly UNIX in coloured boxes targeting high-end creative industries many years before Apple, though they were just as influential in scientific computing. They were, for all intents and purposes, “unobtainium” for mere mortals who’d see ads for them and decide to buy a car instead. Nerds like me knew more about Sun kit, and maybe even DEC Alpha boxes, but the really cool people had MIPS SGI boxes with their discrete 3D graphics hardware that was light-years ahead of what anyone else had.

Long-time readers of my blog and rambling introductions likely know where this is going.

Fast forward to 2025, and a kind reader on the NetBSD developer mailing list got in touch with me to say another NetBSD developer knew someone in Sydney who was looking to part with their SGI Indigo2 machine as part of a home cleanout. We exchanged a few emails back and forth, and I realised their friend lived not that far from where our city office is, and where my parents and family friends spent some time in the 90s. I couldn’t wait, and asked if she was free on Sunday, and before I knew it I was on the morning train down.

Arriving at her home, she had a large box with the Indigo2 and the original Silicon Graphics keyboard! We talked for a bit, and we ended up sharing a coffee she graciously made while we talked about the tech of yore, from her time using an Amiga in broadcast media, to her experience working with developers in Singapore. I could have spent the whole afternoon there!

She gave me a lift to the local station, and I took the Indigo2 home where it now sits on my computer projects desk.

The moral of the story? Be kind to people, and run NetBSD! You never know where doing so will take you. Thank you to everyone who made this possible, and for your generosity. I’m honestly pinching myself, I still can’t quite believe it.

Next step: getting the requisite video hardware converters working, testing that it boots, and doing an inventory of parts for the Retro Corner :).

By Ruben Schade in Sydney, 2025-09-28.

pkgsrc 2025Q3 is now available for NetBSD, this includes binary packages.

I have updated my NetBSD 10.1 packages using 2025Q3 from binary pkgs without any issues.

Today’s #SciArtSeptember prompt I’m using as a writing cue was something else I thought I understood, but there’s more to it than I first realised.

I thought symbiosis was defined as a mutually-beneficial relationship. It’s derived from nature, but the term has also crept into use in other fields, such as disparate IT projects that otherwise complement each other. It implies a sense of balance, or one in which no one party exerts undue influence or benefit. To do so would imply a more parasitic relationship, in which one party benefits at the other’s expense.

The first hint that I misunderstood this came from running dict(1) on this NetBSD laptop (a topic for a future post!), curiously enough:

The living together in more or less imitative association or even close union of two dissimilar organisms. In a broad sense the term includes parasitism

I… huh. As I said, I thought symbiosis was mutually beneficial. Have I been wrong about this the whole time?

My curiousity sufficiently piqued—and because I’m a hopeless retrocomputing tragic—I fired up the 486 to check what Microsoft Bookshelf 94 said. Maybe the definition evolved over time?

E:\BS94>BS94.EXE
==> Cannot read source disk
==> [gibberish]

Well, bother! Either the Sound Blaster 32 (non-AWE) IDE controller has gone kaput on this machine, or the drive itself has failed, or my badly scratched disc has degraded further. I’m sure I’d I’d be able to make a witty analogy here if I had access to Bookshelf’s formal, correct definition of symbiosis. Yes; we’ll go with that.

Anyway, my Bookshelf sufficiently borked, and with my Grolier, Worldbook, and Encarta discs currently in a folder buried under a pile of packing boxes in the other room, it was time to consult the giant Wikipedian in the room, which quoted Angela Dougas in her 2010 book The Symbiotic Habit:

Over time, the definition has varied among scientists. Some have argued that it should refer only to persistent mutualisms, while others have proposed that it should include all long-term biological interactions (i.e., mutualism, commensalism, and parasitism).

Well there you go. I suppose I’m still okay to use “symbiosis” as a metaphor, though I should keep in mind that I may be suggesting more than I intend depending with whom I’m speaking.

By Ruben Schade in Sydney, 2025-09-27.

We’re nearing the end of #SciArtSeptember, and it’s been a lot of fun. I prefer to write what I want to write and on my own terms, which is why I don’t generally do writing challenges like the ill-fated NaNoWriMo. But these prompts designed ostensibly for data scientists and artists were surprisingly fulfilling for writing, even if they weren’t intended as such.

Today’s post is convergence, which is one of my favourite circumstances in life. I love when seeminly unrelated people from around the world converge in ways that would have never happened if you planned for it.

Tonight I had dinner with Clara, her father, and some friends from his university days. The conversation steered towards retrocomputing, and how they’d written Fortran and ALGOL during their studies in Sydney and Hong Kong. I mentioned that I love restoring old machines, which lead down a rabbithole of IBM XTs, 6502 CPUs, Token Ring networks, and punch cards. I talk about this so much with people online, but to have converged with this group of fascinating people in real life who lived through it and had stories… it was something else.

I’ll save this next adventure for a future post, and the details if I get permission to share their names. But a kind reader also put me in touch with someone on the NetBSD developer team who knew someone in Sydney who needed to part with a stunning old machine that had been on my “pie in the sky” wish list for many years. I’ll hopefully be getting their contact details soon, and whether I was first in line to get it. If so, this is utterly unbelievable territory!

Just like news, I think I fall into the trap all too often of thinking converging circumstances conspire against me most of the time. I lead a very comfortable life, but there are aspects of it (family, health, etc) that have been challenging. I often wonder had things not converged in the way they did, I would have been more resilient in tackling them. That may still be true, but I also should be thankful more often for when things converge in positive ways. I’m sure it happens more often than I give it credit.

By Ruben Schade in Sydney, 2025-09-26.

Jesse Smith at Distrowatch reviews NetBSD this week:
https://distrowatch.com/weekly.php?issue=20250922#netbsd

I have a good mix today.

• Open hardware model rocketry.
• vimrc: settings based on terminal background.
• Choose Your Own Adventure, a history.
• MacPaint 1-bit patterns.  (via)
• HTTP headers that tell syndication feed fetchers how soon to come back.
• Voynich Manuscript Structural Analysis.  (via)
• Adventures in porting a Wayland Compositor to NetBSD and OpenBSD by Jeff Frasca.  Video.
• KDE Plasma 6 Wayland on FreeBSD.  Includes install instructions.
• How I felt in love with calendar.txt.  (via)
• Quality-of-life on Tetris games.
• Underworld Amusements.  A niche literary interest.
• Playing the Open Source Game.  (via)
• ++080925.

Your unrelated music video of the week: Return of the Phantom by VOID.  2025 or 1985?  Can’t easily tell.

I grew up using Adaptec SCSI controllers in my PC and Mac towers, but I was always intrigued by BusLogic. I’d see their driver referenced during the bootstrap phase of the Windows NT and 2000 installers, but I had no idea who they were. Turns out they were a prolific SCSI controller vendor from 1988 that were later acquired by Mylex in 1996 and run into the ground. Sounds about right, alas.

I finally got my first BusLogic card earlier this year, thanks to a local seller in Melbourne who had a stack of “new old stock” NICs, VGA cards, and DIMMs going for basically nothing. This is the PCI BusLogic BT-958, which I use on my PCI 486. Note the wonderful 90s-era logo and fonts as well:

Using BusLogic cards on Windows NT and NetBSD is a snap, but DOS and Windows 9x are trickier. As far as I can tell, the legendary Windows 98 SE boot disk everyone uses doesn’t have support for BusLogic cards, so can’t be used to bootstrap a CD-ROM or SCSI hard drive:

Fortunately the process is similar enough to Adaptec on DOS. Get a copy of the BusLogiuc MultiMaster 1.1 drivers from my downloads page or the Internet Archive, and extract them to your boot disk. Then add these lines to your boot disk’s CONFIG.SYS:

;; A:\CONFIG.SYS
DEVICE=A:\BTDOSM.SYS /D
DEVICE=A:\BTCDROM.SYS /D:BANANA

BTDOSM.SYS is the BusLogic SCSI device manager that must be loaded first before the SCSI CD-ROM driver. Then you can load MSCDEX.EXE or an equivalent in your boot disk’s AUTOEXEC.BAT. I wrote about loading DOS CD-ROM drivers back in 2009 (yikes) if you need help.

And yes, it works in my favourite DR DOS 6.0 as well :).

By Ruben Schade in Sydney, 2025-09-20.

I’m a fan of “booby trap” security devices. Infosec is a famously asymmetric struggle, so their inclusion in a security architecture helps level the playing field slightly. The behaviour of booby traps can be difficult to predict, can bog down attackers, and can act as a warning system.

In isolation, sure, they don’t achieve much. There’s also the argument that if someone has breached your permiter defences and are messing with booby traps, you’ve already lost. But as Infosec Shrek reminds us, security is about layers and defence in depth. And if anything else, some booby traps can be a bit of fun too.

So what does this have to do with BSD?

I’ve written thousands of words here about how the FreeBSD and NetBSD operating systems (my favourites) not only make excellent servers, but that Linux admins have more transferable skills than they may realise. I talked with a client who joked that it was easier for her to move from Debian to FreeBSD than it was going from RHEL and SLES to Ubuntu. Read into that what you will.

But what about the commands that don’t work the same? Or may not exist at all? Or that have different names? If you SSH into a BSD and try and run your script kiddie exploit with a bunch of Linux-specific commands or bashisms, they may fail. Oh no! I suppose that’s an unearned security-via-obscurity benefit of BSD, but why not use this to our advantage?

I have a little Go tool we’ll call silly. This is aliased to Linux commands that don’t exist on a vanilla BSD install, such as apt, bash, btrfs, lspci, modprobe, nano, and wget. Think of it like Busybox, only it’s a script that allows Linuxisms to silently fail successfully, while logging connection information and the issued command to an append-only log.

I’ve had this installed in a few honeypot VMs, and it’s been… amusing seeing the commands people issue. I can see them attempting to install packages and run scripts. You’d think these tools would run a uname first to confirm the OS on its which it’s running, but apparently not! I guess its easier to assume you’re hearding penguins than to confirm whether you’re on a BSD, or illumos, or whichever.

By Ruben Schade in Sydney, 2025-09-18.

This report was written by Dennis Onyeka as part of Google Summer of Code 2025.

Introduction & Description

The goal of the NAT64 project is to implement IPv6-to-IPv4 translation inside NPF (NetBSD Packet Filter). NAT64 enables IPv6-only clients to communicate with IPv4-only servers by embedding/extracting IPv4 addresses in IPv6 addresses as per RFC 6052 and RFC 6145. We are using a 1:1 mapping for now, to implement NAT64 translation. Whereby an IPv6 host will use its IPv4 address to communicate with an IPv4 only server. As an example of IPv4, we will use github.com (140.82.121.3) that supports only IPv4. In order to enable NAT64 on NPF we will have a rule like this:

map wm0 algo "nat64" 64:ff9b:2a4:: -> 192.0.2.33

This means we want to use the host IPv4 address associated to wm0 interface 192.0.2.33 to access the public internet in order to communicate with GitHub's IPv4 server. During this process, IPv6 header will be rewritten to IPv4. Part of the IP structure requires source and destination address so our new IPv4 source address will be the Host IPv4 address (which is likely to change during further improvement) and the IPv4 destination address will be gotten from GitHub’s IPv4 embedded IPv6 address i.e. the IPv4 address embedded into IPv6 address (64:ff9b::8c52:7903) gotten from the DNS resolver. Note that NPF is our router so we will have to enable and configure a DNS caching resolver like unbound on the NetBSD machine. The job of the DNS64 is to synthesize AAAA responses from IPv4-only A records using the well-known prefix (64:ff9b::/96), then embed the Github’s IPv4 address (140.82.121.3) into it which will be (64:ff9b::8c52:7903). The hexadecimal values represent Github’s IPv4 address. When the packet is returning from GitHub, it uses the IPv6 interface, so the IPv4 address part will be embedded back into its required position based on the prefix length passed by the user on the configuration. Then it will be sent to the IPv6 interface of the host machine. So far, I’ve been focusing on the core translation path, making sure headers are rewritten correctly and transport checksums are updated. This also requires changes in the userland and kernel.

Current Status

• Address Embedding and Extraction: Implemented functions that are responsible to extract IPv4 from IPv6 and embed IPv4 back into IPv6. Supports prefix lengths 32–96, with 96 as default.
• IP Header Rewrite: Added a functionality that enables headers rewriting by stripping off the old IP header and creating a new header along with structures.
• Rule Parsing: Added keyword support in npf.conf, so users can specify NAT64 prefix length.
• Checksum Handling: Integrated checksum recalculation for IPv4, IPv6, and transport layers (TCP/UDP/ICMP).

More functionalities to be added (In the coming weeks)

• State Integration: Hooked into NPF’s connection tracking so NAT64 works with stateful packet filtering.
• Fine tune the checksum handling

Development Environment & Test Environment

• Running NetBSD in a VM (on Windows host) for test implementation
• Editing and building code on WSL (Windows Subsystem for Linux).

Testing

• Testing traffic with ping, nc (netcat), curl, dig.
• Using tcpdump/tshark/Wireshark on NetBSD to inspect packets before/after translation.

Debugging

• Building kernel and userland via build.sh with kernel debug logs enabled
• Tracing packet flow via ktrace
• Incremental testing/unit: Test functions one by one.

Experience, Observation, Impressions

Experience: Working deep inside NetBSD’s kernel networking stack has been challenging but rewarding. It gave me hands-on experience with mbufs, packet parsing, and kernel-level checksums.

Observation

• Testing NAT64 also requires real network setups, not just unit tests, since correctness depends on seeing the actual wire-format packets.
• Prefix length handling is subtle, user input must be validated and handled gracefully (defaulting to 96).
• The separation between userland rule parser and kernel execution path is strict, everything is serialized into structures properly.

Impressions about NetBSD

• The codebase is clean and modular, but sometimes well-documented to an extent.
• NetBSD’s networking stack is solid and flexible, NPF feels light and extensible.
• The build system is stable.

Hi all,

I'm new here, and to *BSD, but I have an old DEC DS10 that I had my company buy for a project, which we later abandoned. So instead of letting it collect dust in a dank basement, I have a DS10 humming away in my office running NetBSD 9.3.

It took a while to get it installed, but now the setup seems quite content. The only issue I've bumped into, is that when booting, the process stops and asks for a terminal type, hit Enter for VT100, which then dumps me into a root prompt. To continue to boot, I have to "exit", after which it is up and running just fine.

Any idea how to stop this from happening, and have a nice, smooth, boot process?

There's nothing interesting in /var/log/messages, aside from 3 complaints about its pre-DS10-era display card. I don't think it'll help, but here's the complaints:

/netbsd: [ 1.0000000] pm3fb0 at pci0 dev 14 function 0: 3D Labs GLINT Permedia 3 (rev. 0x01)
/netbsd: [ 1.0000000] autoconfiguration error: pm3fb0: no width property
/netbsd: [ 1.0000000] autoconfiguration error: pm3fb0: no height property
/netbsd: [ 1.0000000] autoconfiguration error: pm3fb0: no depth property

Thanks for any/all help!

Spiff

So I'm curious about NetBSD and wondering if it is safe to use for a daily driver desktop. I was doing my research and notice that on the security mailing list there isn't a lot of activity. I already subscribe to the OpenBSD and FreeBSD mailing lists for security vulnerabilities having run both of those BSDs and they have multiple security vulnerabilities every few months. NetBSD hasn't had any this year and only two last year. Is the security really that good or is no one looking for bugs? I mean I work as a system admin and my work's windows server and Red Hat Linux systems get DOZENS of bug fixes / security fixes each and every month!

Thank you for your time and I hope you don't think I am attacking NetBSD, I'm just curious why the "crickets chirping" is found on the security mailing list about any bugs found?

Also, when bugs are found is there any way to patch except for recompiling the entire OS?

Thanks in advance!

Motherboard: Biostar MB-8500TTD (with Jan Steunebrink's patched BIOS ver. J.3)
CPU: AMD K6-2 @ 500MHz
Memory: 256MB PC133 SDRAM, 256MB swap
Storage: Silicon Image Sil3114 SATA controller, 80GB SATA HDD
Network: 3Com 3C595-TX
Graphics: Matrox Millennium G450 (PCI version)
Sound: OPTi 82C931 based ISA card
Misc: Microsoft InPort ISA card and mouse

https://bsd-hardware.info/?probe=7ef8c740df

This is my first time using NetBSD, coming from many years of running Debian Linux.
It's installed alongside Windows 98 in a dual-boot configuration.
I chose NetBSD because I'd wanted to run a modern UNIX-compatible system on my vintage PC, and NetBSD supports old hardware better than Linux does these days.
Since those pictures were taken I've configured the system to my liking. There are three snafus remaining:

• When starting X Windows the display does not immediately switch to the X screen
• I don't know how to set up my InPort mouse
• I don't know how to set up sound

Reguarding X Windows, you can read the X Server logs at the hardware listing linked above.
As for mice and sounds, they're both handled by ISA bus cards. NetBSD already has a driver (mms) for the Microsoft InPort mouse, and the OPTi 82C931 sound chip is Sound Blaster Pro compatible so it can be driven by the sb driver. Unless I'm mistaken it seems I will have to compile a custom kernel and setup these drivers in the configuration file?

This year, 2025, the KDE Community held its yearly conference in Berlin, Germany. On the way I reinstalled FreeBSD on my Frame.work 13 laptop in another attempt to get KDE Plasma 6 Wayland working. Short story: yes, KDE Plasma 6 Wayland on FreeBSD works.

↫ Adriaan de Groot

Adriaan de Groot is a long-time KDE developer and FreeBSD package maintainer, and he’s published a short but detailed guide on setting up a KDE Plasma desktop on FreeBSD using Wayland instead of X11. With the Linux world slowly but finally leaving X11 behind, the BSD world really has little choice but to follow, especially if they want to continue offering the two major desktop environments. Most of KDE and GNOME are focused on Linux, and the BSDs have always kind of tagged along for the ride, and over the coming years that’s going to mean they’ll have to invest more in making Wayland run comfortably on BSD.

Of course, the other option would be the KDE and GNOME experience on the BSDs slowly degrading over time, but I think especially FreeBSD is keen to avoid that fate, while OpenBSD and NetBSD seem a bit more hands-off in the desktop space. FreeBSD is investing heavily in its usability as a desktop operating system, and that’s simply going to mean getting Wayland support up to snuff. Not only will KDE and GNOME slowly depend more and more on Wayland, Xorg itself will also become less maintained than it already is.

Sometimes, the current just takes you where it’s going.

I am a huge fan of my Rock 5 ITX+. It wraps an ATX power connector, a 4-pin Molex, PoE support, 32 GB of eMMC, front-panel USB 2.0, and two Gen 3×2 M.2 slots around a Rockchip 3588 SoC that can slot into any Mini-ITX case. Thing is, I never put it in a case because the microSD slot lives on the side of the board, and pulling the case out and removing the side panel to install a new OS got old with a quickness.

I originally wanted to rackmount the critter, but adding a deracking difficulty multiplier to the microSD slot minigame seemed a bit souls-like for my taste. So what am I going to do? Grab a microSD extender and hang that out the back? Nay! I’m going to neuralyze the SPI flash and install some Kelvin Timeline firmware that will allow me to boot and install generic ARM Linux images from USB.

↫ Interfacing Linux

Using EDK2 to add UEFI to an ARM board is awesome, as it solves some of the most annoying problems of these ARM boards: they require custom images specifically prepared for the board in question. After flashing EDK2 to this board, you can just boot any ARM Linux distribution – or Windows, NetBSD, and so on – from USB and install it from there. There’s still a ton of catches, but it’s a clear improvement.

The funniest detail for sure, at least for this very specific board, is that the SPI flash is exposed as a block device, so you can just use, say the GNOME Disk Utility to flash any new firmware into it. The board in question is a Radxa ROCK 5 ITX+, and they’re not all that expensive, so I’m kind of tempted here. I’m not entirely sure what I’d need yet another computer for, honestly, but it’s not like that’s ever stopped any of us before.

This report was written by Ethan Miller as part of Google Summer of Code 2025.

Introduction

The goal is to improve the capabilities of asynchronous IO within NetBSD. Originally the project espoused a model that pinned a single worker thread to each process. That thread would iterate over pending jobs and complete blocking IO. From this, the logical next step was to support an arbitrary number of worker threads. Each process now has a pool of workers recycled from a freelist, and jobs are grouped per-file so that we do not thrash multiple threads on the same vnode which would inevitably lock. This grouping also opens the door for future optimisations in concurrency. The guiding principle is to keep submission cheap, coalesce work sensibly, and only spawn threads when the kernel would otherwise block.

Project Details and Status

We pin what is referred to as a service pool to each process, with each service pool capable of spawning and managing service threads. When a job is enqueued it is distributed to its respective service thread. For regular files we coalesce jobs that act on the same vnode into one thread. If we fall back to the synchronous IO path within the kernel it would lock anyway, but this approach is prudent because if more advanced concurrency optimisations such as VFS bypass are implemented later this is precisely the model that would be required. At present, since that solution is not yet in place, all IO falls back to the synchronous pipeline. Even so there are performance gains when working with different files, since synchronous IO can still run on separate vnodes at the same time.

Through the traditional VFS read/write path, requests eventually reach bread/bwrite and block upon a cache miss until completion. This kills concurrency. I considered a solution that bypassed the normal vnode read/write path by translating file offsets to device LBAs with VOP_BMAP, constructing block IO at the buffer and device layer, submitting with B_ASYNC, and deferring the wait to the AIO layer with biodone bookkeeping instead of calling biowait at submission. This keeps submission short and releases higher level locks before any device wait. The assumptions are that filesystem metadata is frequently accessed therefore cached so VOP_BMAP usually does not block, that block pointers for an inode mostly remain stable for existing data, and that truncation does not rewrite past data. For the average case this would provide concurrency on the same file. In practice, however, it was exceptionally difficult to implement because the block layer lacks the necessary abstractions.

This is, however, exactly the solution espoused by FreeBSD, and they make it work well because struct bio is an IO token independent of the page and buffer cache. GEOM can split or clone a bio, queue them to devices, collect child completions, and run the parent callback. Record locks are treated as advisory so once a bio is in flight the block layer completes it even if the advisory state changes. NetBSD has no equivalent token. Struct buf is both a cache object and an IO token tied to UBC and drivers through biodone and biowait. For now the implementation of service pools and service threads lays the groundwork for asynchronous IO. Once the BIO layer reaches adequate maturity, integrating a bio-like abstraction will be straightforward and yield immediate improvements for concurrency on the same vnode. The logical next step is to design and port something comparable to FreeBSDs struct bio which would map very cleanly onto the current POSIX AIO framework.

My Development Environment

My development setup is optimised for building and testing quickly. I use scripts to cross-build the kernel and boot it under QEMU with a small FFS root. The kernel boots directly with the QEMU option -kernel without any supporting bootloader. Early on I tested against a custom init dropped onto an FFS image. Now I do the same except init simply launches a shell which allows me to run ATF tests without a full distribution. This makes it possible to compile a new kernel and run tests within seconds.

Lessons

One lesson I have taken away is that progress never happens overnight. It takes enormous effort to get even a few thousand lines of highly multi-threaded race-prone code to behave consistently under all conditions. Precision in implementation is absolutely required. My impression of NetBSD is that it is a fascinating project with an abundance of seemingly low-hanging fruit. In reality none of it is truly low-hanging or simple, but compared to Linux there remains a great deal of work to be done. It is not easy work but the problems are visible and the path forward is clearer.

I also want to note that I intend on providing long term support for this code in the case that any issues may arise.

The code written as part of this project can be found here.

I have a Raspberry Pi 3 with NetBSD 10, running CI jobs. Because SD cards are notoriously unreliable, I attached a USB hard drive to it. The HDD has a swap partition and scratch space for the builds, while root is on the SD. Unfortunately, some writes end up going to the root file system after all, which meant that the SD card was destroyed after only about a year!

Earlier this year, I was trying to get actual daily work done on HP-UX 11.11 (11i v1) running on HP’s last and greatest PA-RISC workstation, the HP c8000. After weeks of frustration caused first by outdated software no longer working properly with the modern web, and then by modern software no longer compiling on HP-UX 11.11, I decided to play the ace up my sleeve: NetBSD’s pkgsrc has support for HP-UX. Sadly, HP-UX is obviously not a main platform or even a point of interest for pkgsrc developers – as it should be, nobody uses this combination – so various incompatibilities and more modern requirements had snuck into pkgsrc, and I couldn’t get it to bootstrap. I made some minor progress here and there with the help of people far smarter than I, but in the end I just lacked the skills to progress any further.

This story will make it to OSNews in a more complete form, I promise.

Anyway, in May of this year, it seems Brian Robert Callahan was working on a very similar problem: getting pkgsrc to work properly on IBM’s AIX.

The state of packages on AIX genuinely surprises me. IBM hosts a repository of open source software for AIX. But it seems pretty sparse compared to what you could get with pkgsrc. Another website offering AIX packages seems quite old. I think pkgsrc would be a great way to bring modern packages to AIX.

I am not the first to think this. There are AIX 7.2 pkgsrc packages available at this repository, however all the packages are compiled as 32-bit RISC System/6000 objects. I would greatly prefer to have everything be 64-bit XCOFF objects, as we could do more with 64-bit programs. There also aren’t too many packages in that repository, so I think starting fresh is in our best interest.

As we shall see, this was not as straightforward as I would have hoped.

↫ Brian Robert Callahan

Reading through his journey getting pkgsrc to work properly on AIX, I can’t help but feel a bit better about myself not being to get it to work on HP-UX 11.11. Callahan was working with AIX 7.2 TL4, which was released in November 2019 and still actively supported by IBM on a maintained architecture, while I was working with HP-UX 11.11 (or 11i v1), which last got some updates in and around 2005, running on an architecture that’s well dead and buried. Looking at what Callahan still had to figure out and do, it’s not surprising someone with my lack of skill in this area couldn’t get it working.

I’m still hoping someone far smarter than I stumbles upon a HP c8000 and dives into getting pkgsrc to work on HP-UX, because I feel pkgsrc could turn an otherwise incredibly powerful HP c8000 from a strictly retro machine into something borderline usable in the modern world. HP-UX is much harder to virtualise – if it’s even possible at all – so real hardware is probably going to be required. The NetBSD people on Mastodon suggested I could possibly give remote access to my machine so someone could dive into this, which is something I’ll keep under consideration.

I have this code:

NSData* data = [[pipe fileHandleForReading] readDataToEndOfFile];
NSString* s = [[NSString alloc] initWithData: data encoding: NSUTF8StringEncoding];

(For context, this is part of a function that executes system commands.)

And this last line produces a warning:

Calling [GSPlaceholderString -initWithData:encoding:] with incorrect signature. Method has @28@0:8@16i24 (@28@0:8@16i24), selector has @28@0:8@16I24

The command works fine, and gives me the output I want, whereby I don't want to see this warning, because I am working on a console application, and these warnings severely disrupt the experience.

Is there any way to disable those warning messages? I tried to "#define NSLog(...)", but it didn't work.

I am using the GCC compiler on a NetBSD 10.0.

I'm trying to set up a VM running NetBSD 6.0 (very unfortunately I have to use this specific version). While I've managed to find the installer ISO very easily, I can't find a single working pkgin / pkgsrc mirror, seems that they've all been removed.

Is anyone aware of any remaining mirrors of that ancient versions, or some other method of installing software packages (mind that they need to be the same versions that shipped with NetBSD 6.0)?

We removed ads from OSNews. Donate to our fundraiser to ensure our future!

The Hurd, the collection of services that run atop the GNU Mach microkernel, has been in development for a very, very long time. The Hurd is intended to serve as the kernel for the GNU Project, but with the advent of Linux and its rapid rise in popularity, it’s the Linux kernel that became the defacto kernel for the GNU Project, a combination we’re supposed to refer to as GNU/Linux. Unless you run Alpine, of course. Or you run any other modern Linux distribution, which probably contains more non-GNU code than it does GNU code, but I digress.

The Hurd is still in development, however, and one of the more common ways to use The Hurd is by installing Debian GNU/Hurd, which combines the Debian package repositories with The Hurd. Debian GNU/Hurd 2025 was released yesterday, and brings quite a few large improvements and additions.

This is a snapshot of Debian “sid” at the time of the stable Debian “Trixie” release (August 2025), so it is mostly based on the same sources. It is not an official Debian release, but it is an official Debian GNU/Hurd port release.

↫ Samuel Thibault

About 72% of the Debian archive is available for Debian GNU/Hurd, for both i386 and amd64. This indeed means 64bit support is now available, which makes use of the userland disk drivers from NetBSD. Support for USB disks and CD-ROM was added, and the console now uses xkb for keyboard layout support. Bigger-ticket items are working SMP support and a port of the Rust programming language. Of course, there’s a ton more changes, fixes, improvements, and additions as well.

You can either install Debian GNU/Hurd using the Debian installer, or download a pre-installed disk image for use with, say, qemu.

The long-planned next meeting of NYCBUG is tomorrow.  If you are going and have a Framework laptop, please bring it for testing HDMI.  I assume it’s related to ongoing support work.

Meeting is canceled cause no presenter available.

If you have been following source-changes, you may have noticed the creation of the netbsd-11 branch! It comes with a lot of changes that we have been working on:

Install changes

Compatibility support code, like 32bit on 64bit machines, has been separated into special sets, to allow easy installation of machines that do not need to be able to run 32bit code.

Install media for some architectures has been split in small ("CD/R") images (w/o debug and compat sets), and full ("DVD-R") sets. This is also useful on hardware that came with a CD drive (instead of a DVD drive) and can not boot from a USB stick.

Manual pages come in two flavors, html and mandoc. Both have now their own sets, so one or the other can easily be left out of an installation.

All mac68k and macppc ISO images are now bootable.

Kernel changes

• x86: PVH boot is now supported on non-XEN platforms (QEMU, Firecracker)
• various new drivers for temperature (and other environmental) sensors and fan control
• the heartbeat watchdog will detect locking errors that prevent softints from running or the timecounters from making progress on one of the CPUs
• lots of enhancements for Linux emulation
• new syscall: semtimedop(2)
• new riscv port primarily targeting StarFive JH71XX-based devices
• various bug fixes

Userland changes

• libc and libm enhancements for C23 and POSIX.1-2024 support
• userland support for manipulating/querying (U)EFI variables has been added
• jemalloc has been updated to version 5.3
• various bug fixes to libpthread and making functions signal safe
• lots of miscelaneous bug fixes
• the in-tree X.org components are all (well, nearly - there are a few minor/unimportant exceptions) up-to-date

3rd party software updates included

• gcc for all architectures is now at version 12.5
• gdb for all architectures is now at version 15.1
• binutils for all architectures is now at version 2.42
• OpenSSL got updated to the latest long term support version available: 3.5.1
• OpenSSH is at version 10.0
• many others updated, including dhcpcd, openresolv, unbound, nsd, ...

And a lot more...

... that we always forget to mention. The list of changes can be found in the beta build, split into changes upto the creation of the branch and changes pulled up to the branch before the 11.0 release.

Things that did not make it in-time for the branch

A few work-in-progress items unfortunately did not make it into this branch and will not be pulled up. The most missed ones are:

• the next round of DRM/KMS updates to enhance x86 and arm graphics support
• the big WiFi renewal project

These will happen in HEAD now carefully and after stabilization might be a good reason to create the next major branch earlier.

Please help us test this BETA!

We try to test NetBSD as best as we can, but your testing can help to make NetBSD 11.0 a great release. Please test it and let us know of any bugs you find.

Binaries are available on NetBSD daily builds and for various ARM based devices (with board dependent boot setup) on arm install images.

Please test NetBSD 11.0_BETA on your hardware and report any bugs you find!

Tentative schedule

No promises, but we will try to make this one of the shortest release cycles ever...

Ideally we will be in release candidate state at EuroBSDCon late in September, and cut the final release early in October.

pkg_admin audit said..

Package sqlite3-3.49.2 has a memory-corruption vulnerability, see https://nvd.nist.gov/vuln/detail/CVE-2025-6965
Package libxml2-2.14.4 has a use-after-free vulnerability, see https://nvd.nist.gov/vuln/detail/CVE-2025-49794
Package libxml2-2.14.4 has a denial-of-service vulnerability, see https://nvd.nist.gov/vuln/detail/CVE-2025-49795
Package libxml2-2.14.4 has a denial-of-service vulnerability, see https://nvd.nist.gov/vuln/detail/CVE-2025-49796
Package libxml2-2.14.4 has a integer-overflow vulnerability, see https://nvd.nist.gov/vuln/detail/CVE-2025-6021
Package libxml2-2.14.4 has a buffer-overflow vulnerability, see https://nvd.nist.gov/vuln/detail/CVE-2025-6170

I usually go to netbsd site, check errata and follow instruction but..

https://www.netbsd.org/support/security/patches-10.1.html

The page result empty. How to fix/patch those vulnerabilities?

I have also run

sysupgrade auto

and reboot, but messages still appear.

Saying goodbye

For several years our autobuild cluster at Columbia University has been providing our CI and produced many official release builds.

Over the years, with new compiler versions and more targets to build, the build times (and space requirements) grew. A lot. A few weeks ago the old cluster needed slightly more then nine and a half hours for a full build of -current.

So it was time to replace the hardware. At the same time we moved to another colocation with better network connectivity.

Preparing for the future

But not only did the hardware age, the CI system we use (a bunch of shell scripts) needed a serious overhaul.

As reported in the last AGM, riastradh@ did most of the work to make the scripts able to deal with mercurial instead of cvs.

This is a necessary step in the preparation of our upcoming move away from cvs, which is now completed. While the build cluster currently (again) runs from cvs, we completed a few full builds from mercurial in the last few weeks.

User visible changes

The cvs runs for builds were purely time driven. To deal with latency between cvs.NetBSD.org and anoncvs.NetBSD.org there was a 10-minute lag built into the system, so all timestamps (the names of the build directories) were exact to the minute only and had a trailing zero.

This does not fit well with modern distributed source control systems. For a hg or git build the cluster fetches the repository state from the master repository and updates the checkout directory to the latest state of a branch (or HEAD). So the repository state dictates the time stamp for the build, not vice versa as we did for cvs.

As a result there is a difference between the time a build is started (wall clock) and the time of the last change of the current branch in the repository (build time or reproducible ID). You can see both times in the status page. Just right now it displays:

Currently building tag HEAD-lint, build 2025-07-22 19:19:02 UTC (started at: 2025-07-22 19:26:40 UTC).
No results yet. 

And, obviously, we can now easily skip builds when nothing has changed - which happens often on old branches, but also may happen when all HEAD builds are done before anything new has been committed. Hurry up, you lazy developers!

While we are still running from cvs, the process of checking if anything has changed is quite slow (in the order of five minutes). So you may notice a status display like:

Currently searching for source changes... 

The new hardware

The new cluster consists of four build machines, each equipped with a dual 16 core EPYC CPU and 256 GB of RAM. As a "brain" we have an additional controller node with 32 GB RAM and a (somewhat weaker) Intel CPU. The controller node creates all source sets, does repository operations, and distributes sources but does not perform any building itself.

On the build machines we run each 8 builds in parallel, and each build with low parallelism (-j 4). This tries to saturate all cpus during most of the time of the overall build. Individual builds have several phases with little/reduced possibility of parallelism, e.g., initially during configure runs, or while linking llvm components, or near the end when compressing artefacts. The goal is not to run a single (individual) build as fast as possible, but the whole set of them in as little time overall.

The build log summary

The head of the result page create for each build now tries to give all the details necessary to recreate this particular build, e.g.:

From source dated Tue Jul 22 04:45:13 UTC 2025
Reproducible builds timestamp: 1753159513
Repository: src@cvs:HEAD:20250722044513-xsrc@cvs:HEAD:20250720221743

The two timestamps are the same, one in seconds since the Unix epoch, the other human readable.

The repository ID is, for cvs, again based on timestamps. But for hg or git you will see the typical commit hash values here.

Why a custom CI system?

We considered using an off-the-shelf CI system and customizing it to our needs instead of moving the fully custom build system forward. We also talked to FreeBSD release engineering about it and asked for their experience. Overall the work for customizing an off-the-shelf solution looked roughly equivalent to the work needed now to modify the existing working solution, and we saw no huge benefit for the future picking either of them.

What does our build infrastructure provide?

First and foremost, we can quickly verify if all of our supported branches indeed compile. While developers are supposed to commit only tested changes, usually they build at most one branch and architecture. But sometimes changes have unforeseen consequences, for example an install image of an exotic architecture growing more in size than expected.

Then, in theory, no NetBSD user has to waste any CPU cycles in order to install (for example) NetBSD-current or the latest NetBSD 9 tree. Instead you can simply download an image and install from that — no matter if your architecture is amd64 or a slightly more exotic one (but you will of course always be able to download the source tree and build that if that suits you better).

Note that a supported architecture is not just supported at one point in time and then as time progresses might start collecting dust and not compile anymore, making it hard to merge all current changes back into that tree. Instead once an architecture is supported, our CI system will without rest build that architecture as one of the many we support. Take the rather new Wii port as an example. Now that it is supported, you can at least for the foreseeable future download the latest and greatest NetBSD release, populate an SD card with the image and boot it. Now, in half a year, and in 10 years (and even further down the line).

Acknowledgements

We are grateful to Two Sigma Investments, LP for providing the space and connectivity for the new build cluster.

I preassembled this list of links over time, so some of them have probably changed.  For the “I’m sorry…” link, that just means more material.

• Precision Clock Mk IV.  Not kidding about the precision part.  (via)
• Calibre News.  An excellent complement to RSS.
• TMG, or Transmogrifier, a compiler for PDP-7.  Not what I first thought.  (via)
• Mark V. Shaney, really an early LLM.  (via)  Plus, this followup.
• Single-function devices in the world of the everything machine.  I was in the same regional blizzard mentioned.
• I’m sorry I’ve written a joke.
• tmux cheat sheet.  (also via)
• The Webcomic List.  This re-acquainted me with some comics I haven’t seen in years.  (via I lost track, sorry)
• Why Some Satellites Use NetBSD?  (indirectly via)
• can an email go 500 miles in 2025?  A nice sequel of sorts to the 500-mile email.
• The A2DVI gives the Apple II DVI and HDMI output.
• Towards a Complete List of Excellent Medieval/Fantasy Combat Scenes.

In this blog post, I have described how I have been using Linux on my Amiga 4000. I hope this information can be of use to anyone who is planning to run Linux on their Amigas. Furthermore, I hope that the existing documentation on the Linux/m68k homepage gets updated at some point. May be the information in this blog post can help with that.

Debian 3.1 works decently for me, but everything is much slower compared to a PC. This is not really surprising if you run an operating system (last updated in 2008) on a CPU from the early 90s that still runs at a 25 MHz clock speed :).

↫ Sander van der Burg

The blog post in question is from January of this year, but as soon as I saw it I knew I had to post it here. It’s an incredibly intricate and detailed guide to running Linux on a 25Mhz Amiga 4000, including X11, networking, internet access, file sharing, and so, so much more – up to running Linux for Amiga inside FS-UAE. There’s so much love and dedication in this detailed guide, and I love it.

In fact, Van den Burg has a similar article about running NetBSD on the Amiga 4000, with the same level of detail, dedication, and information density. A fun note is that while X11 for Linux on the Amiga can’t seem to make use of the Amiga chipset, the X Window System on NetBSD does make us of it. I’m not surprised.

Articles like these are useful only for a very small number of people, but having this amount of knowledge concentrated like this will prove invaluable like five years from now when someone else finds an Amiga 4000 in their attic or at a yard sale, and choose to go down this same path. We need more of these kinds of write-ups.

RPG mini-theme this week.

• You’ll have to scroll a bit, but: Hal Foster images.  (via)
• A modern version of the 1968 game Hammurabi.  (via)
• I feel open source has turned into two worlds.
• Classic Computer Replicas.  (via)
• Deep Fishing, a Sinclair game.  (indirectly via)
• FIST, a paranormal A-Team RPG.  (via)
• XScreenSaver 6.11 out – for the Wayland experimenters.
• listfile: help your scripts process a list of things.
• Blink and you’ll miss it! 4096 colours and flashing text on the console!
• KDE Plasma 6.4 has landed in OpenBSD.
• pkgsrc-2025Q2 has been released.
• The Apple Johnathan, new to me.  (via)
• Microscope RPG, a GMless game for building a world.  (via, via)
• my official list of post-glitch.com hosting options.
• How to install FreeBSD on providers that don’t support it with mfsBSD.  I’ve linked to this sort of method before.
• Ghostty is available for FreeBSD, from a comment last week.

Your unrelated music link of the week: Beanbag metal.

So to set the stage (and it's a strange stage...) this is on NetBSD, using pkgsrc, and on hppa architecture. I build this the same way on sparc without issue.

On hppa, I get:

`_ZL17__gthread_triggerv' referenced in section `.rodata._ZN20cmBasicUVPipeIStreamIcSt11char_traitsIcEED1Ev.cst4' of cmBinUtilsMacOSMachOOToolGetRuntimeDependenciesTool.o: defined in discarded section `.text._ZL17__gthread_triggerv[_ZN20cmBasicUVPipeIStreamIcSt11char_traitsIcEED1Ev]' of cmBinUtilsMacOSMachOOToolGetRuntimeDependenciesTool.o
`_ZL17__gthread_triggerv' referenced in section `.rodata._ZN20cmBasicUVPipeIStreamIcSt11char_traitsIcEED1Ev.cst4' of cmBinUtilsWindowsPEDumpbinGetRuntimeDependenciesTool.o: defined in discarded section `.text._ZL17__gthread_triggerv[_ZN20cmBasicUVPipeIStreamIcSt11char_traitsIcEED1Ev]' of cmBinUtilsWindowsPEDumpbinGetRuntimeDependenciesTool.o
`_ZL17__gthread_triggerv' referenced in section `.rodata._ZN20cmBasicUVPipeIStreamIcSt11char_traitsIcEED1Ev.cst4' of cmBinUtilsWindowsPEObjdumpGetRuntimeDependenciesTool.o: defined in discarded section `.text._ZL17__gthread_triggerv[_ZN20cmBasicUVPipeIStreamIcSt11char_traitsIcEED1Ev]' of cmBinUtilsWindowsPEObjdumpGetRuntimeDependenciesTool.o
`_ZL17__gthread_triggerv' referenced in section `.rodata._ZNSt16_Sp_counted_baseILN9__gnu_cxx12_Lock_policyE1EE10_M_releaseEv.cst4' of cmConditionEvaluator.o: defined in discarded section `.text._ZL17__gthread_triggerv[_ZNSt16_Sp_counted_baseILN9__gnu_cxx12_Lock_policyE1EE10_M_releaseEv]' of cmConditionEvaluator.o
`_ZL17__gthread_triggerv' referenced in section `.rodata._ZNSt16_Sp_counted_baseILN9__gnu_cxx12_Lock_policyE1EE10_M_releaseEv.cst4' of cmExecuteProcessCommand.o: defined in discarded section `.text._ZL17__gthread_triggerv[_ZNSt16_Sp_counted_baseILN9__gnu_cxx12_Lock_policyE1EE10_M_releaseEv]' of cmExecuteProcessCommand.o
`_ZL17__gthread_triggerv' referenced in section `.rodata._ZNSt16_Sp_counted_baseILN9__gnu_cxx12_Lock_policyE1EE10_M_releaseEv.cst4' of cmFindPackageCommand.o: defined in discarded section `.text._ZL17__gthread_triggerv[_ZNSt16_Sp_counted_baseILN9__gnu_cxx12_Lock_policyE1EE10_M_releaseEv]' of cmFindPackageCommand.o
`_ZL17__gthread_triggerv' referenced in section `.rodata._ZN17cmFunctionBlockerD2Ev.cst4' of cmForEachCommand.o: defined in discarded section `.text._ZL17__gthread_triggerv[_ZN17cmFunctionBlockerD5Ev]' of cmForEachCommand.o
`_ZL17__gthread_triggerv' referenced in section `.rodata._ZNSt16_Sp_counted_baseILN9__gnu_cxx12_Lock_policyE1EE10_M_releaseEv.cst4' of cmGeneratorExpressionDAGChecker.o: defined in discarded section `.text._ZL17__gthread_triggerv[_ZNSt16_Sp_counted_baseILN9__gnu_cxx12_Lock_policyE1EE10_M_releaseEv]' of cmGeneratorExpressionDAGChecker.o
`_ZL17__gthread_triggerv' referenced in section `.rodata._ZN20cmBasicUVPipeIStreamIcSt11char_traitsIcEED1Ev.cst4' of cmLDConfigLDConfigTool.o: defined in discarded section `.text._ZL17__gthread_triggerv[_ZN20cmBasicUVPipeIStreamIcSt11char_traitsIcEED1Ev]' of cmLDConfigLDConfigTool.o
`_ZL17__gthread_triggerv' referenced in section `.rodata._ZN20cmBasicUVPipeIStreamIcSt11char_traitsIcEED1Ev.cst4' of cmPlistParser.o: defined in discarded section `.text._ZL17__gthread_triggerv[_ZN20cmBasicUVPipeIStreamIcSt11char_traitsIcEED1Ev]' of cmPlistParser.o
`_ZL17__gthread_triggerv' referenced in section `.rodata._ZNSt16_Sp_counted_baseILN9__gnu_cxx12_Lock_policyE1EE10_M_releaseEv.cst4' of cmake.o: defined in discarded section `.text._ZL17__gthread_triggerv[_ZNSt16_Sp_counted_baseILN9__gnu_cxx12_Lock_policyE1EE10_M_releaseEv]' of cmake.o
`_ZL17__gthread_triggerv' referenced in section `.rodata._ZN20cmBasicUVPipeIStreamIcSt11char_traitsIcEED1Ev.cst4' of cmcmd.o: defined in discarded section `.text._ZL17__gthread_triggerv[_ZN20cmBasicUVPipeIStreamIcSt11char_traitsIcEED1Ev]' of cmcmd.o
make: *** [Makefile:2: cmake] Error 1

It actually compiles everything just fine, it seems like right when it gets to creating "cmake" the binary it fails like this.

I see some other posts on here talking about changing the order in the linker section ?

I've posted to NetBSD mailing lists, as well as the CMake Discourse forum and no replies yet.

Any ideas would be greatly appreciated.

I’m on the road as I type this – though I’ll be back by the time it’s posted – and so the links are without much comment.

• The Best Interfaces We Never Built.
• The 80s were shit.   (via)
• Memory Banks.
• Malleable Software.  (via)
• Lightweight C compilers.
• Exterminate all rational AI scrapers, redux.
• A year of funded FreeBSD.
• Bill Atkinson Dies From Cancer at 74.  Few people realize how much of the modern software world came right from what he did.  (via)
• So you should read Memories of Lisa for the details.  (via)
• Unveiling the EndBOX: A NetBSD-based embedded box for EndBASIC.
• BoxyBSD.  (via)
• Look for the UNIX license plate.

Your unrelated comics link of the week: What’s the best comic I’ve ever read?  Lynda Barry is a master of the form.  (via)

On May 17, 21:00 UTC we had The NetBSD Foundation Annual General Meeting on #netbsd-agm IRC channel on Libera.Chat.

We had presentations from:

• board (billc)
• secteam (billc)
• releng (martin)
• core (riastradh)
• finance-exec (riastradh)
• membership-exec (martin, christos)
• pkgsrc-pmc (wiz)
• pkgsrc-security (tm, leot)
• gnats (dh)

At the end we also had a Q&A session open to anyone.

If you have missed it you can find the IRC logs here.

[I got redirected here from StackOverflow as this is not a programming question (oops).]

For about the last three years or so, under X11, Alt+KP_[n] has yielded a different keycode/keysym (set?) than Alt+[n]. I have been using this difference to change fonts on the fly on urxvt. Checking the version of urxvt shows that the version has not changed since 2021...

rxvt-unicode (urxvt) v9.26 - released: 2021-05-14

...so, what has changed in X11 to cause this, and why has this (been) changed? Or, conversely, is there anything I can do in any of my configurations (xmodmap, etc) to re-enable this behaviour? I can't really switch to having Alt+[n] accomplish this, as I use Alt+[n] as digit-argument in bash (via .inputrc).

I would really like to get the old behaviour of Alt+KP_[n] back. KP_7 shows as a different keystroke under xev than does 7, even though it shows the same output value

This is happening on X11 under both cygwin and NetBSD.

Excerpt of xev(X11) output:

    root 0x36f, subw 0x0, time 2440468, (174,166), root:(2818,273),
    state 0x10, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyPress event, serial 33, synthetic NO, window 0xc00001,
    root 0x36f, subw 0x0, time 2441828, (174,166), root:(2818,273),
    state 0x18, keycode 79 (keysym 0xffb7, KP_7), same_screen YES,
    XLookupString gives 1 bytes: (37) "7"
    XmbLookupString gives 1 bytes: (37) "7"
    XFilterEvent returns: False

KeyRelease event, serial 33, synthetic NO, window 0xc00001,
    root 0x36f, subw 0x0, time 2441906, (174,166), root:(2818,273),
    state 0x18, keycode 79 (keysym 0xffb7, KP_7), same_screen YES,
    XLookupString gives 1 bytes: (37) "7"
    XFilterEvent returns: False

KeyRelease event, serial 33, synthetic NO, window 0xc00001,
    root 0x36f, subw 0x0, time 2442734, (174,166), root:(2818,273),
    state 0x18, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyPress event, serial 33, synthetic NO, window 0xc00001,
    root 0x36f, subw 0x0, time 2445171, (174,166), root:(2818,273),
    state 0x10, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyPress event, serial 33, synthetic NO, window 0xc00001,
    root 0x36f, subw 0x0, time 2445390, (174,166), root:(2818,273),
    state 0x18, keycode 16 (keysym 0x37, 7), same_screen YES,
    XLookupString gives 1 bytes: (37) "7"
    XmbLookupString gives 1 bytes: (37) "7"
    XFilterEvent returns: False

KeyRelease event, serial 33, synthetic NO, window 0xc00001,
    root 0x36f, subw 0x0, time 2445468, (174,166), root:(2818,273),
    state 0x18, keycode 16 (keysym 0x37, 7), same_screen YES,
    XLookupString gives 1 bytes: (37) "7"
    XFilterEvent returns: False

KeyRelease event, serial 33, synthetic NO, window 0xc00001,
    root 0x36f, subw 0x0, time 2445984, (174,166), root:(2818,273),
    state 0x18, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

TRIED: In a urxvt, I pressed Alt+KP_7 (sub any KP_ for 7, it makes no difference).

EXPECTED: I expected, as had happened before, the font to change, by virtue of Alt+KP_7 not being interpreted as the same keystroke as Alt+7.

ACTUAL RESULT: bash prompted (arg: 7), as though I had pressed Alt+7.