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?

I have a tinc network, between two LANs on the same subnet.
Both tinc "gateway" machines run NetBSD, and use npf. Both have a tap0 from tinc, bridged to their LANs with bridge0. Both are also dhcp servers for their respective LANs.

I cannot seem to block dhcp requests from going through the tinc network. Both dhcp servers see all machines on both LANs.

tinc is configured "Forwarding = kernel" on both ends. I thought that I could block bootpc and bootps on bridge0 since both bridges have packet filtering enabled. I have it blocked for bridge0 and tap0 on both machines; but dhcp requests still show up on the LAN from the opposite LAN. That is, requests from LAN A show up on awge0 of LAN B's gateway machine, and requests from LAN B show up on re0 of LAN A's gateway machine.

What am I missing?

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.

It’s the next instalment in #SciArtSeptember, a series of prompts for data visualisation artists that I found so interesting that I’m using them for blog posts. Today’s word is growth, spelled “growth”. Thanks Ruben, that was helpful.

Growth is one of those terms that carried deeply negative connotations when my sister and I were growing up, owing to our late mum’s condition. I’m glad we’ve been able to slowly reframe it as a positive in other aspects now that we’re older.

What I’ve found intersting of late is how we prepend qualifiers to growth the same way we do for health. It’s “mental” health and “personal” growth, for example. I can see why these could/would be benign, but I think they also serve to cleave off what are perceived as more legitimate or productive forms of these terms. I’ve come to dismiss this; “mental” health is health, and “personal” growth is growth.

There are two reasons for this for me. Our worth isn’t defined by our economic output and our “business” growth. Though even if it was, we need our own oxygen masks on before we attend to others. A burned out person, or one who hasn’t seen personal growth, won’t be effective in other areas of their lives.

I’ve also struggled for most of my adult life to do things for the sake of personal growth, because I’ve always had to reframe them in terms of what may be useful or productive. Giving up any pretence of these, or not considering them, has lead me in unexpectedly wonderful directions. Turns out, as I’ve been saying about gen-“AI” slop and PR speak, people are engaged and excited to talk with people geniunly interested in something, not merely cosplaying it for engagement.

Is my continuing use of Perl, or learning PyQt, or tinkering with NetBSD the best (or maybe easiest) path to business success? Perhaps not. But I derive significant joy from using these, and they’ve ultimately helped me out in unexpected ways.

Turns out, if you let yourself grow, others take notice too.

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

How well NetBSD supports this ? I didn't see much in the documentation and my knowledge of the code regarding this specifically is sparse.

The search engines didn't give me much in terms of mailing list content.

https://mail-index.netbsd.org/netbsd-users/2023/07/20/msg029876.html
But it was following Xen specific questions and doesn't mention anything about nvme.

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.

The title of this post is a riff on Brent Simmons’ latest post, which I encourage you to read. He contrasted his current experience with Mac and iOS development with that of UserLand Frontier that he helped develop with Dave Winer in the early 1990s.

Balder Bjarnason linked to this on Mastodon, and added a useful additional thought:

This is something I’ve had a hard time convincing young devs of: substantial portions of the field of software in the past used to be better in multiple ways. It wasn’t all good but we’ve clearly regressed in multiple ways.

I made a throwaway comment that the same could apply to modern sysadmin work and system design. I’m not sure what we’ve done in the last decade has rendered how we design, build, or maintain systems any easier. Like Brent and Balter, I’d argue we’ve gone backwards.

Our largest customers at work have fleets of thousands of VMs hosting services you would recognise. You know what the most exotic tooling they use to install, update, and administer them? Ansible. Meanwhile, our smaller customers with a dozen VMs turn to something complicated like K8s and it always, always, results in problems down the line. I would know, because I’m still CC’d on support threads.

The plural of anecdote isn’t data, and I’m sure someone out there has AIX horror stories who is eager to extol the virtues of systemd, or whatever has replaced rkt (is that still a thing?). Merely mentioning these will almost certainly result in this post hitting a news aggregator site, and dozens of people sending me rude email and social media messages taking issue with the trees over the forest. Wait, I’m mangling my idioms again.

But you want to know what the most robust, reliable platforms are built on? Bare metal. Virtual machines. Basic orchestration tools. That’s it.

(I’d also take the opportunity to mention that it’s another reason why I use and love FreeBSD, NetBSD, and Alpine Linux, but I’m likely already in enough trouble posting about the KISS philosophy as it is).

People get so hung up on using the latest and greatest that they never stop to consider (a) what it is they’re hoping to achieve with that approach, and (2) what they’re trading off for that additional complexity. Because it doesn’t need to be that hard.

By Ruben Schade in Sydney, 2025-08-30.

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!

We haven’t had a links post for a while. Not to be confused for a links post, which could be used to read a links post. About lynx.

• Do I need Kubernetes? The answer may surprise you.

• The ODROID-H4 PLUS looks like an amazing little x64 board to use as a home router. I’d be tempted to get one and use it as a NetBSD/npf or FreeBSD/pf box.

• I rediscovered VGMdb, the audio database that has way more anisong than sites like Discogs. The first album I found again was Ryo Takahashi’s music for Classroom of the Elite. I already miss Japanese Tower Records.

• We’ve been helping to price and architect some ELO Digital Office installations at work with earnest this year, and it’s been incredibly interesting. They’re also based out of Germany, which is an asset given our… geopolitical climate.

• These cactus leather wallets from the Vegan Leather Company look gorgeous. I’ve been reducing how much I use my smartphone to make payments, and have even started paying cash again for some transactions.

• Some of you on Mastodon recommended I try OpenSCAD after I talked about wanting to get started in 3D modelling. I like the idea of expressing shapes in a script, rather than 3D modelling.

• A colleague recommended 5D Chess With Multiverse Time Travel, and it looks incredible. Perhaps a bit too much!

• Qt for Python has a tutorial series that has been so much fun. I’ve learned more Python and Qt concepts from this than anything else I’ve tried.

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

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.

This is the forth post in my A-Z Toolbox series, in which I’m listing tools I use down the alphabet for no logical reason. I also definitely didn’t forget I was doing this, which is why it’s been eight months since the last one (cough).

The letter D has some essential gems:

• drill is a better version of dig, the useful DNS network utility. It comes standard on FreeBSD, and carries Gurren Lagann connotations which I appreciate.

• dialog, which lets you create pseudo-graphical shell applications. It can be frustrating to develop against at times, but I love it for wrapping complicated scripts I’ve written for friends and family. It deserves its own post.

• dav1d is a fast av1 encoder/decoder I’ve used to learn about the format and compare it to H264 for new projects.

• Berkley db5 embedded database which, despite now being owned by The Big Database Company, still has its uses which I should write about at some point.

• colordiff which, while technically starting with C, adds colour to the ubiquitous diff utitliy used to compare files. Not everyone finds colour useful, but I do.

But my award for the best D utility goes to dcfldd, an extension to the ubiquiotus dd. It was developed at the American Department of Defence Computer Forensics Lab as a forensic tool, but it has a bunch of useful features including:

• Inline hashing and image verification

• Status/progress output, which is useful if you’re not using the GNU extended dd.

• Multiple, split, and piped outputs

• A more efficient default block size

Use of dcfldd looks similar to dd. For example, here I’m imaging an old Zip disk and logging:

# dcfldd if=/dev/gpt/zip-disk of=/tmp/zip-disk.img \
    conv=sync hash=sha1 sha1log=zip-disk.log

You can then use it to verify images:

# dcfldd if=/dev/gpt/zip-disk.img vf=/tmp/zip-disk.img

dcfldd is one of the first tools I install on any new machine. If you deal a lot with physical media and disk images, especially ones that haven’t been looked after with a proper file system like OpenZFS, I’d consider it essential.

By Ruben Schade in Sydney, 2025-08-23.

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)?

I got great feedback from a bunch of you on Wednesday about which ThinkPad to get as a low-distraction writing tool. I’ll save writing details for when I actually get it, but I found someone in Australia selling a couple of X230 machines for less than AU $100 shipped.

I would have leaned towards getting one with the earlier-style keyboard, but for the purposes of this experiment—and the price!—I couldn’t complain. It also still has that nostalgic ThinkPad design which has imprinted on me from my earlier X61s and X40 which I love and miss dearly.

I’ve found separating mental domains onto their own machines has been helpful for distractions and anxiety. My FreeBSD/Linux tower dual boots into a workstation and games machine, the MacBook Air is for work, and the Panasonic Let’s Note is my on-call laptop for when I leave the house. My hope is this X230 will be the low distraction writing and personal project machine in this arrangement.

It’ll also be the first time in a while that I’ve run NetBSD on real hardware instead of VMs, so that’ll be cool. My plan is to kit it out with as little as feasible to get a text editor going. My favourite is Kate, but Qt software tends to integrate with other desktops pretty well, so hopefully I won’t need all of KDE. Maybe I’ll get away with a basic window manager this time.

Now the only question is whether the age of this machine constitutes “retro” for inclusion on my Retro Corner. I’m leaning towards… not? It’s not a Commodore 64 or an Apple II. Then again, is a phrase with two words.

By Ruben Schade in Sydney, 2025-08-16.

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.

Dumbness or perhaps stupidity, today’s mini theme.

• WebSysctl is Now Live!  I like the idea of this, though it would be nicer to have it accessible on the machine where you need it.  (via)
• The GAFA Stack.  Read section 3.
• 8 Bits & Still Brewin’.
• Mute when Locked.  (via)
• Web Archives and Web Archiving – Introduction for Scholars and Students.  You will need this, or at least wish you knew it better at some point.  (PDF, via)
• At one point, “..” did not exist.
• Setting Up Anubis on FreeBSD via Implement Anubis to give the bots a harder time.
• The amount of bot traffic has increased significantly, I assume to find content for AI, and ignoring robots.txt – and copyright.  I don’t think people realize the scale of this.  It’s causing a denial of service attack in server resources and developer time.
• Related, see comments here for some mod_security blocking alternatives.
• Post-Quantum Cryptography on NetBSD.
• Make Stupid Things.  (via)
• The Wadsworth Constant, learned about in #5 here.
• Dumbware, self-hosted solutions.  I like this except for the dockering.  (via)

Your unrelated audio of the week: Squarepusher’s Ultravisitor, remastered.

One of the few things I know about Minecraft is, some players I know and love could be playing together if someone were to run a server for them. That’s the sort of thing I’d gladly do, provided I could approximately never again pay attention to it.

Here’s what I came up with. Let’s see how it pans out.

Prerequisites

My Virtual Private Server at Panix is NetBSD/amd64 with plenty of RAM, disk, and network headroom. Marginal additional usage is therefore free.

System- and pkgsrc-provided services are controlled by the usual NetBSD-style rc.d scripts.

Site-specific services are supervised, including supervision trees controlled by each user. In the following excerpt from my running system:

• root starts sniproxy
• notqmail runs a web site and its Let’s Encrypt autorenewal,
• schmonz runs a few of each
• all these services were bounced yesterday after a regular package update

/service/sniproxy: up (pid 11133) 81141 seconds

/service/svscan-notqmail: up (pid 325) 846389 seconds
  /home/notqmail/service/renewssl.www.notqmail.org: up (pid 20951) 81141 seconds
  /home/notqmail/service/www.notqmail.org: up (pid 24539) 81141 seconds

/service/svscan-schmonz: up (pid 394) 846389 seconds
  /home/schmonz/service/agilein3minut.es: up (pid 26325) 81141 seconds
  /home/schmonz/service/latentagility.com: up (pid 24554) 81141 seconds
  /home/schmonz/service/renewssl.agilein3minut.es: up (pid 18299) 81141 seconds
  /home/schmonz/service/renewssl.latentagility.com: up (pid 14394) 81141 seconds
  /home/schmonz/service/renewssl.schmonz.com: up (pid 12424) 81140 seconds
  /home/schmonz/service/schmonz.com: up (pid 21449) 81141 seconds

These packages were already installed:

• djbdns-run
• s6-portable-utils
• unzip
• curl
• py-html2text
• jq

I’ve added these:

• openjdk21
• execline

I’m installing Minecraft’s server software manually, so it’ll be my job to notice when to update. Gotta automate the noticing, at least.

Oh, and I need a sensible process-supervision run script for the Minecraft server. The script needs to solve two application-specific system-integration problems:

1. The usual supervision signals cause the server to terminate without saving the state of the world, which seems… rude
2. The usual way to configure a running server is to get on the console and type commands into it, which implies having started it inside a tmux session (which, I love tmux, but not for this)

We solve for (1) by running the server as a child process and translating supervision signals into Minecraft commands.

We solve for (2) by connecting a named pipe to the server’s standard input. Then commands can be sent to the server using nothing but echo and ordinary output redirection.

Without even really being asked, my brain instantly produced the mechanisms for (1) in Perl. Then someone on #s6 shared a run script that additionally solved (2) while being more than twice as short as mine. How? By writing it in execline, a language expressly designed to be this kind of glue.

Step by step: Supervising Minecraft service

1. Create dedicated Unix user with its own process supervisor

useradd -m minecraft
mkdir -p /etc/service/svscan-minecraft/log
cd /etc/service/svscan-minecraft
cat > log/run <<'EOF'
#!/bin/sh
exec setuidgid minecraft logger -t svscan-minecraft -p daemon.info
EOF
chmod +x log/run
cat > run <<'EOF'
#!/bin/sh
exec 2>&1
exec setuidgid minecraft argv0 svscan svscan-minecraft /home/minecraft/service
EOF
chmod +x run
ln -s /etc/service/svscan-minecraft /var/service/

2. Globally, map hostname to IP

echo '+minecraft.schmonz.com:my.server.ip.here' >> /etc/tinydns/data
service tinydns reload

3. Locally, map port number to service name

echo 'minecraft 25565/tcp # minecraft.schmonz.com' >> /etc/services
service sysdb services

4. Allow incoming connections

$EDITOR /etc/npf.conf # add minecraft to $services_tcp
service npf reload

5. Download software

su minecraft
cd
mkdir -p sites/schmonz.com/minecraft/service
cd sites/schmonz.com/minecraft
mkdir bin
curl -o bin/server.jar https://piston-data.mojang.com/v1/objects/e6ec2f64e6080b9b5d9b471b291c33cc7f509733/server.jar

6. Accept EULA

mkdir data
echo 'eula=true' > data/eula.txt

7. Create control socket

mkfifo -m 0600 data/control

8. Symlink service logs where I usually look

ln -s data/logs logs

9. Create run script

cat > service/run <<'EOF'
#!/opt/pkg/bin/execlineb -P
fdmove -c 2 1
cd /home/minecraft/sites/schmonz.com/minecraft/data
redirfd -w -nb 3 control
trap -x
{
    SIGINT  { fdmove 1 3 s6-echo stop }
    SIGHUP  { fdmove 1 3 s6-echo stop }
    SIGTERM { fdmove 1 3 s6-echo stop }
    SIGPIPE { fdmove 1 3 s6-echo stop }
}
fdclose 3
redirfd -r 0 control
java -Xmx1024M -Xms1024M -jar ../bin/server.jar --nogui
EOF
chmod +x service/run

10. Enable service

ln -s /home/minecraft/sites/schmonz.com/minecraft/service ~/service/minecraft.schmonz.com

11. Send initial configuration

cat > data/control <<'EOF'
whitelist on
whitelist add so-and-so
save-on
EOF

Be notified of updates

As the minecraft user:

1. Create service and run script

cd ~/sites/schmonz.com/minecraft
mkdir -p update/service/log
cd update/service

cat > log/run <<'EOF'
#!/bin/sh

exec multilog t ./main
EOF
chmod +x log/run

cat > run <<'EOF'
#!/bin/sh

set -e
set -x

exec 2>&1

MINECRAFT_VERSIONS_ENDPOINT='https://piston-meta.mojang.com/mc/game/version_manifest.json'

running_version() {
   unzip -p ../bin/server.jar version.json \
       | jq -r .name
}

available_version() {
   curl \
       --silent \
       --user-agent "Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/81.0" \
       "${MINECRAFT_VERSIONS_ENDPOINT}" \
   | jq -r .latest.release
}

main() {
   cd /home/minecraft/sites/schmonz.com/minecraft/data

   while true; do
       running="$(running_version)"
       available="$(available_version)"
       if [ "${running}" != "${available}" ]; then
           echo "MINECRAFT SERVER UPDATE NEEDED: ${running} -> ${available}"
           echo "" | mail -s "Please update Minecraft server: ${running} -> ${available}" [email protected]
       fi
       sleep 250000
   done
}

main "$@"
exit $?
EOF
chmod +x run

2. Enable service

ln -s /home/minecraft/sites/schmonz.com/minecraft/update/service ~/service/update.minecraft.schmonz.com

Further improvements

If it’s desirable to have the server periodically auto-save, I’ll add one more service that writes save-all to data/control.

If pkgsrc had a minecraft-server package (FreeBSD Ports does), I could delete my ad hoc update-notification service. Maybe I’ll make it so. I do like packaging things as part of my area-under-the-curve strategy.

My host-specific supervision trees and pkgsrc’s djbware rc.d scripts (qmailsmtpd, for instance) are still using daemontools. I’ve had the intention to switch to s6 for a long time. When it happens, I’ll be happy about it.

I haven’t tried to understand why there are “Java” and “Bedrock” editions of Minecraft, but it seems like they don’t interoperate. I’m sure there are reasons for this product segmentation and that I’ll come to better understand them in the fullness of time. Meanwhile, if and when I need to add Bedrock client interop, Geyser looks like an easy option — once I’m running something other than the vanilla upstream Minecraft Java server. I’ll need to try to understand that whole situation, too.

Are you an experienced Minecraft server administrator? Please share tips and advice!