My 2018 Mac mini (64G RAM, 2T SSD) has long been a trusty multi-VM pkgsrc and notqmail build machine, mostly via SSH. And during the first couple COVID years when I was still consulting independently but we were out of the country, it was also a trusty low-latency system for collaborative coding sessions with USA-based clients, mostly via screen sharing.

The mini still performs quite well. I still rely on it for keeping my NetBSD VPS running on the latest -current pkgsrc every week or so. But macOS NFS service had a tendency to be a source of annoyance and/or effort on each new major release. NetBSD’s NFS client got fixed, which was enough to get me by, but my Tribblix and Linux VMs had already been basically unusable for a while. And macOS had lately gotten a little unstable after reboot: sometimes misrendering the login screen, freezing after a correctly entered password, or suddenly pegging the fans for no apparent reason and powering abruptly off. So when macOS Tahoe dropped support for nearly all Intel Macs, I was already game to repave mine.

I generally prefer NetBSD when possible, and generally consider my non-NetBSD systems to be only temporarily so (e.g., Small ARMs). Hosting a pile of nvmm-accelerated VMs while also building natively for my primary NetBSD production target would have been a solid use case. But the 2018 mini has a T2 security chip that makes a bunch of basic onboard devices relatively difficult for an OS to attach, and Linux appears to be the only free OS that mostly deals with this. Even then, we’ll need a T2-customized installer and special attention.

1. Prepare installer

$ cd ~/Downloads
$ bash <<<1 <(curl -sL https://github.com/t2linux/T2-Mint/releases/latest/download/iso.sh)
$ sudo dd if=linuxmint-*-cinnamon-*-t2-*.iso of=/dev/$YOUR_USB_STICK
$ rm -f linuxmint-*-cinnamon-*-t2-*.iso

2. Prepare machine

1. Reboot and hold down Command-R.
2. In macOS Recovery, choose Utilities -> Startup Security Utility.
3. Secure Boot: No Security.
4. Allowed Boot Media: Allow booting from external or removable media.
5. Connect USB keyboard/mouse/Ethernet directly (not via Bluetooth or Thunderbolt dock).
6. Quit Startup Security Utility.

3. Install

1. Reboot and hold down Option.
2. Choose your USB stick.
3. In the live environment, open Terminal.
4. Wipe, partition, and format the disk:

   $ for i in \
   "mklabel gpt" \
   "mkpart ESP fat32 1MiB 513MiB" \
   "set 1 esp on" \
   "set 1 boot on" \
   "mkpart Root btrfs 513MiB 100%"; do
   sudo parted $YOUR_DISK_DEVICE $i
   done
   $ sudo mkfs.fat -F32 -n ESP ${YOUR_DISK_DEVICE}p1
   

5. In the live environment, run Install.
6. Instead of “Erase disk and install Linux Mint”, choose “Something else”.
7. Click the btrfs partition -> “Change…”.
8. Use as: btrfs journaling file system.
9. Format the partition: [x].
10. Mount point: /.
11. ”Install Now” and follow the prompts until “Installation Complete”.
12. DO NOT click “Continue Testing” or “Restart Now”. We’re not ready for the new install to be unmounted.

4. Tweak new install

1. Enter newly installed environment:

   $ for i in proc dev dev/pts; do
   sudo mount -B /$i /target/$i
   done
   $ sudo chroot /target
   

2. From now on, track configuration changes in git:

   # echo | apt install etckeeper
   # cd /etc
   # git branch -m pet-power-plant
   # git gc --prune
   

3. Configure grub:

   # echo 'GRUB_RECORDFAIL_TIMEOUT=0' > default/grub.d/60_skip_grub_prompt.cfg
   # etckeeper commit -m 'Skip grub prompt.'
   # update-grub
   

4. Give Mac boot picker a custom icon:

   # apt install libarchive-tools
   # curl -sL https://master.dl.sourceforge.net/project/mac-icns/mac-icns.iso \
   | bsdtar -xOf- iconverticons.com/os_linuxmint.icns \
   > /boot/efi/.VolumeIcon.icns
   

5. Return to the “Installation Complete” dialog (finally!) and click “Restart Now”.

5. Before first boot

1. When prompted, remove USB stick and press Enter.
2. On reboot, hold down Command-R.
3. In macOS Recovery, choose Utilities -> Terminal.
4. Give Mac boot picker a custom label:

   # diskutil list
   # diskutil mount /dev/$YOUR_EFI_SYSTEM_PARTITION_DEVICE
   # bless --folder /Volumes/ESP/EFI/BOOT --label "Linux Mint"
   

5. Reboot and hold down Option.
6. Observe the icon and label. Fancy! Someday you’ll hold down Option again, and this’ll help you disambiguate which volume you’re trying to boot.

6. First boot

1. Go for it!
2. Observe no grub prompt, just straight through the Mint logo to the login screen.
3. Log in.
4. Enable passwordless sudo:

   $ echo '%sudo ALL=(ALL: ALL) NOPASSWD: ALL' \
   | sudo tee /etc/sudoers.d/10sudo_nopasswd >/dev/null
   $ sudo chmod 440 /etc/sudoers.d/10sudo_nopasswd
   $ sudo etckeeper commit -m 'Skip sudo password prompt.'
   

5. Allowlist your Thunderbolt dock, if any:

   $ boltctl list                   # find your device's UUID
   $ sudo boltctl enroll --policy auto $YOUR_THUNDERBOLT_UUID
   

6. Fetch WiFi and Bluetooth firmware:

   $ sudo apt install dmg2img
   $ echo 7 | sudo get-apple-firmware get_from_online
   

7. Connect Ethernet/WiFi/mouse/keyboard as you prefer.
8. Enable T2 fan control and SSH service:

   $ echo | sudo apt install t2fanrd openssh-server
   $ sudo systemctl enable --now ssh
   $ sudo etckeeper commit -m 'Enable sshd.'
   

9. Update device firmware:

   $ echo y | sudo fwupdmgr get-updates
   

   (Note that the Mac’s EFI can’t be updated this way. The only way to update Mac EFI is as a side effect of installing the latest macOS.)
10. Follow the post-install Welcome prompts.
11. In “Account details”, add my photo.
12. Install some basics:

    $ echo | sudo apt install tmux vim myrepos tig silversearcher-ag qemu-system-x86-64 kdeconnect dropbox
    

7. Back to work

1. Mount source trees from NAS. (Oh hey, I finally have a NAS! Similar post forthcoming about that.)
2. Create a NetBSD VM to match my production VPS.
3. Build a fresh batch of packages.
4. Carry on with life.

I’ve got some older Mac minis that may also soon find gainful employment around here.

NetBSD is one of my favourite operating systems. It runs on almost everything, and skills learned on one architecture are largely transferable. Between that and its modest system requirements (at least when compared to a modern Linux distro) mean I’ve only ever run it on older kit, whether it be a ten-year old ThinkPad, or a 486.

My post yesterday about the incredible SilverStone FLP02 retro-inspired case included this throwaway line at the end:

Right now I can’t decide whether to turn this into my primary workstation, or move my FreeBSD jail and bhyve host into it, or my Alpine Xen box, or live out my dream of building a new NetBSD NVMM test host so I can finally retire the HP Microserver.

This lead me to think… what would a new NetBSD machine look like? Well, new by my standards means “second hand, and released within the last few years”, but you get my point.

I’m thinking something like this:

• A new(ish) Ryzen CPU with SVM and a decent core count for running NVMM-accelerated guests, emulated QEMU guests (cough Alpha, cough SPARC), and my various chroot’ed services. Aaah that would be so cool.

• ECC memory would be a plus.

• Integrated graphics, probably. The proprietary (sigh) Nvidia graphics work easier on FreeBSD than Linux, but we don’t have that on the orange flag side of the fence. I wouldn’t be running games on this anyway, except for the important text-based ones.

• NVMe for boot and primary storage with lvm and cgd, and maybe a pair of 2.5-inch SSDs for scratch. I’ve never actually messed with RAIDframe, but I want to give it a try. I’m also not sure what the state of ZFS is on NetBSD, but could be another thing to mess with.

• A nice, supported discrete sound card like an Audigy Fx, for no other reason than I miss having discrete sound cards.

• A supported 10 GbE (or at least a 2.5 GbE) NIC for testing/tuning, though I’d be unlikely to max this out.

My HP Microserver Gen8 box has been a faithful NetBSD tinkering box for almost ten years now, but even that was kinda old when I first got it. I’m intrigued to see what running NetBSD on newer hardware would be like in 2025.

By Ruben Schade in Sydney, 2025-11-12.

In February I talked about boring being a feature, which ruffled more than a few feathers on the usual news aggregator sites; one of whom called me a “fedora-wearing netbsd idiot” which I still intend to print on a business card one day.

Anyway, Linus Torvalds, regarding the latest Linux 6.18 release candidate:

Things remain calm and small, and everything looks pretty normal. […] In other words: it all looks just the way I like it at this point: small and boring."

Turns out this isn’t a difficult concept to grasp after all.

By Ruben Schade in Sydney, 2025-11-10.

This report was written by Vasyl Lanko as part of Google Summer of Code 2025.

Introduction

As of the time of writing, there is no real sandboxing technique available to NetBSD. There is chroot, which can be considered a weak sandbox because it modifies the root directory of the process, effectively restricting the process' view of the file system, but it doesn't isolate anything else, so all networking, IPC, and mounts inside this restricted file system are the same as of the system, and are accessible.

There has already been some research on implementing kernel-level isolation in NetBSD with tools like gaols, mult and netbsd-sandbox, but they haven't been merged to NetBSD. Other operating systems have their own ways to isolate programs, FreeBSD has jails, and Linux has namespaces.

Project Goals

The goal of this project is to bring a new way of sandboxing to NetBSD. More specifically, we want to implement a mechanism like Linux namespaces. These namespaces allow the isolation of parts of the system from a namespace, or, as the user sees it, from an application.

NetBSD has compat_linux to run Linux binaries on NetBSD systems, and the implementation of namespaces can also be utilized to emulate namespace-related functionality of Linux binaries.

A simple example to visualize our intended result is to consider an application running under an isolated UTS namespace that modifies the hostname. From the system's view, the hostname remains the same old hostname, but from the application's view it sees the modified hostname.

Project Implementation

Linux has 8 namespace types, in this project we will focus on only 2 of them:

• UTS namespace, it is the simplest so we can focus on building the general namespace infrastructure with little namespace-specific details
• mount namespace, it is a prerequisite to most other namespace types because UNIX follows the philosophy of "everything is a file", so we need a separate mount namespace to have different configuration files on the same location as the system.

Linux creates namespaces via the unshare or clone system calls, and it will also be our way of calling the namespace creation logic.

We setup the base for implementing Linux namespaces in the NetBSD kernel using kauth, the subsystem managing all authorization requests inside the kernel. It associates credentials with objects, and because the namespace lifecycle management is related to the credential lifecycle it handles all the credential inheritance and reference counting for us. (Thanks kauth devs!)

We separate the implementation of each namespace in a different secmodel, resulting in a similar framework to Linux which allows the isolation of a single namespace type. Our implementation also allows users to pick whether they want to have namespace support, and of what kind, via compilation flags, just like in Linux.

UTS namespace

UTS stands for UNIX Timesharing System, because it allows multiple users to share a single computer system. Isolating the utsname can be useful to give users the illusion that they have control over the system's hostname, and also, for example, to give different hostnames to virtual servers.

The UTS namespace stores the namespace's hostname, domain name, and their lengths. To isolate the utsname we need to first create a copy of the current UTS information, plus we need a variable containing the number of credentials referencing this namespace, or, in simpler terms, the reference count of this namespace.

This namespace specific information needs to be saved somewhere, and for that we use the credential's private_data field, so we can use a UTS_key to save and retrieve UTS related information from the secmodel. The key specifies the type of information we want to retrieve from the private_data, hence using a UTS_key for the UTS namespace. The key for each namespace is a fixed value (we don't create a new key for every credential), but the retrieved value for that key from different credentials may be different.

We had to modify kernel code that was directly accessing the hostname and domainname variables, to instead call get_uts(), which retrieves the UTS struct for the namespace of the calling process. We didn't modify occurrences in kernel drivers because drivers are not part of any namespace, so they should still access the system's resources directly.

MNT namespace

The MNT namespace isolates mounts across namespaces. It is used to have different versions of mounted filesystems across namespaces, meaning a user inside a mount namespace can mount and unmount whatever they want without affecting or even breaking the system.

The mount namespace structure in Linux is fairly complicated. To have something similar in NetBSD we need to be able to control the mounts accessed by each namespace, and for that we need to control what is each namespace's mountlist, this is also enough for unmounting file systems, because in practice we can just hide them.

For the mount_namespace, mountlist structure and the number of credentials using the mount namespace are stored in the credential's private data with the MNT_key. Similarly to the UTS namespace, we had to modify kernel code to not directly access the mountlist, but instead go through a wrapper called get_mountlist() which returns the correct mountlist for the namespace the calling process resides in.

Implementation for the mount namespace is immensely more complex than for the UTS namespace, it involves having a good understanding of both Linux and NetBSD behaviour, and I would frequently find myself wondering how to implement something after reading the Linux man pages, which would lead to me looking for it in the Linux source code, understanding it, then going back to NetBSD source code, trying to implement it, and seeing it's too different to implement in the same way.

Project Status

You can find all code written during this project in GitHub at maksymlanko/netbsd-src gsoc-bubblewrap branch. Because I intend to continue this work outside of GSoC, I want to reinforce that this was the last commit still during GSoC on gsoc-bubblewrap branch and this was the last one for the mnt_ns still WIP branch.

The link includes implementation of general namespace code via secmodels, implementation of the UTS namespace and related ATF-tests, and the work-in-progress implementation of mount namespaces.

The mount namespace functionality is not finished as it would require much more work than the time available for this project. To complete it, it would be required invasive and non-trivial changes to the original source code, and, of course, more time.

Future Work

As previously mentioned, Linux has 8 namespace types, it is important to see which of the missing namespaces are considered useful and feasible to implement.

I believe that after mount namespaces it would be interesting to implement PID namespaces as this in combination with mount namespaces would permit process isolation from this sandbox. Afterwards, implementing user namespaces would allow users to get capabilities similar to root in the namespace, giving them sudo permissions while still restricting system-wide actions like shutting down the machine.

A lower hanging fruit is to implement the namespace management functionality, which in Linux is lsns to list existing namespaces, and setns to move the current process to an already existing namespace.

Challenges

• Semantics. Did you know the unmount system call with MNT_FORCE flag in Linux (usually) returns EBUSY, and in NetBSD it forces the unmounting? One of them makes it easier to implement mount namespaces.
• The behaviour of namespaces is not fully specified in the man pages. If something is not clear from the man pages you need to read the source code.
• Unexpected need to learn a lot of VFS concepts and their differences in NetBSD and Linux.
• There was a much bigger research component than I anticipated.

In the end, Linux and NetBSD are different operating systems, implemented in different ways. Linux is complex and it is not trivial to port namespaces to NetBSD.

Notes

The project is called "Using bubblewrap to add sandboxing to NetBSD" and was initially projected to emulate the unshare system call into compat_linux, but, seeing that having namespaces could be useful for NetBSD, and that it would be easy to add to compat_linux afterwards, we decided to instead implement namespaces directly in the NetBSD kernel. Implementing other system calls necessary to make the bwrap linux binary work correctly also wouldn't be as satisfying as implementing namespaces directly into NetBSD, so this was why the project was initially called "Using bubblewrap to add sandboxing to NetBSD" but nowadays it would be more accurate to call it "Sandboxing in NetBSD with Linux-like namespaces".

Thanks

I am very grateful to Google for Google Summer of Code, because without it I wouldn't have learned so much this summer, wouldn't have met with smart and interesting people, and for sure wouldn't have tried to contribute to a project like NetBSD, even if I always wanted to write operating systems code... But, the biggest thing I will take with me from this project is the confidence to be able to contribute to NetBSD and other open source projects.

I would also like to thank the members of the NetBSD organization for helping me throughout this project, and more specifically:

• Taylor R. Campbell, Harold Gutch and Nia Alarie from IRC, for helping me fix a nasty LD_LIBRARY_PATH bug I had on my system which wouldn't let me finish compiling NetBSD, and general GSoC recomendations.
• Emmanuel Dreyfus from tech-kern, with whom I discussed ideas for projects and proposal suggestions, and in the end inspired the namespaces project.
• Christoph Badura and Leonardo Taccari who volunteered to be my mentors. They took time to research and answer my questions, anticipated possible problems in my approaches, and always pointed me in the right direction, daily, during all of GSoC's period. This project is from the 3 of us.

I love Dan cases for small loungeroom desktops, but SilverStone make my favourite kit for homelab servers and workstations. The manufacturer made massive waves at Computex in Taipei this year with their second retro-inspired case, the FLP02. Tom’s Hardware and GamersNexus had the best reviews I saw of it. Dullards spammed comment boxes decrying they “DON’T SEE THE POINT!!one!1!”, which is always a sign you’re onto something good.

As a hopeless retro tragic, I knew I had little choice but to place a preorder a few months ago. It arrived yesterday, and I’m so excited to blog about it I didn’t get time to clean the study or even move the half-assembled IKEA furniture out of the way!

I still can’t believe this exists. No really, my inner child is bouncing up and down so hard he risks breaking something. This is so shockingly the case of my dreams it’s damned near terrifying. This is the box, for a case, in 2025! Yes I know the puritans pointed out that nobody sported three 5.25-inch disk drives, but shut up that’s why.

Let’s get it out of the box:

Having spend the last few weeks trying to rearrange a real 1980s AT clone desktop that weighs as much as a fully-laden house boat, this case is feather light. Sturdy and solid like all SilverStone kit, but light. I can already see they nailed the beige aesthetic and colour, even with all the protective packaging.

Okay, time for the big reveal:

Wowza! Do people say that anymore? Did they ever? This is, in the most unironic tone I can muster, the single best modern computer case I think I’ve ever seen. I adore my Mini-ITX cases, but this thing is HUGE, and BEIGE, and just so damn well executed! I’m floored by the build quality.

Let’s take the protective tape off and see how this fan grill assembly works:

Pretty nice. There are two 120 mm fans in the front, and one in the rear. The front panel pops off and slides down, with a built in dust filter that would be easy to clean. This is an upgrade from my old (but still beloved) Antec 300 which requires the whole front of the case to be popped off to access this.

Moving up the front we can see the hidden panel at the top which pops down for additional IO, and those amazing front buttons that power on the machine and adjust the fan controller speed. The CPU turbo LEDs even report the controller fan speed, which I can’t wait to try.

The only downgrade from the FLP01 is that the fake drive panels don’t pop down anymore, they’re just covers. That’s fine; I fully intend to populate them with a beige LG Blu-ray burner I bought in Japan, a Zip Drive, and 360 KiB TEAC 5.25-drive for imaging and transferring data to old machines.

Looking inside, we see even the interior surfaces have been powdercoated that glorious beige; something most of us didn’t have at the time. You can see the two included 3.5-inch drive trays, and the space for the three 5.25-inch drives (or four if you remove the fan controller). To the left we have seven full-width ISA slots (see what I did there?) and two vertical. It has modern conveniences like rubber side wall grommets for cable management, and a shroud for the power supply. It also has a bracket for sagging GPUs, which can thankfully be removed:

I’m sure the regular PC case reviewers will eventually upload their reviews with far more detail and better lighting than our messy study at present. But what I can do that might be a bit unique is compare it to a real beige tower from the tail end of the era. Here it is alongside the 1999 Dell Dimension 4100, and the Sanyo MPC-880 off to the side:

As you can see, the FLP02 is significantly taller, wider, and deeper. The side “grills” mask the added width the case extends out from those 5.25-inch drive bays. It would absolutely dwarf my HP Brio BA600, Japanese NEC APEX, or even the IBM Aptiva 2199. I think the trade-off in size is worth it for those modern conveniences like cable management, though it’s something to keep in mind if you intend to stand it alongside the machines upon which it was loosely modelled.

In subsequent posts I’ll compare the FLP02 to the FLP01 in internals and design, and share my ideas for the build that will be going into this machine. Right now I can’t decide whether to turn this into my primary workstation, or move my FreeBSD jail and bhyve host into it, or my Alpine Xen box, or live out my dream of building a new NetBSD NVMM test host so I can finally retire the HP Microserver. We’ll see!

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

I just came back home from Google Summer of Code 2025 Mentor Summit. We were 185 mentors from 133 organizations and it was amazing!

Google Summer of Code (GSoC) is a program organized by Google with the focus to bring new developers to open source projects.

The NetBSD Foundation has been participating in GSoC since 2005.

After nearly a decade being part of GSoC for The NetBSD Foundation, first as student and then as mentor and org admin, I finally attended my first GSoC Mentor Summit! That was a fantastic, very intense and fun experience! I met with a lot of new folks and learned about a lot of other cool open source projects.

Let's share my travel notes!

Wednesday 22, October 2025: arriving in Munich

Going to Munich is relatively doable by train from my hometown. I departed from Urbisaglia-Sforzacosta at 6:59 in the morning. I had around 25 minutes to wait for the change from Ancona to Bologna. I arrived in Bologna at around 11:30 where I met Andrea, my friend and favorite music pusher since childhood. We had lunch together, eating tasty miso veggie ramen, drank some hot sake and then we had coffee. He then accompanied me back to the station where I had the train to Munich Central Station at 13:50.

The scenery from the train was really nice. Near Trento and Bolzano/Bozen, full of vineyards and apple orchards with mountains in the background. It was cloudy for most of the travel but starting from Bressanone/Brixen I began to see «beautiful blue skies and golden sunshine». After Bressanone the scenery was more uncontaminated with light green grazing lands. Unfortunately when reaching Brennero/Brenner (last Italian city before Austria) it started to get dark and I had not enjoyed the rest of the scenery in Austria and Germany. I arrived in Munich at 20:50 and checked in at my hotel which was around 1km from the station.

For this journey I was not alone! Also Christoph Badura (<bad@>) was a delegate for Google Summer of Code and we had been in touch to get dinner and beers together. Christoph had some train delays but at 21:40 we were able to meet and went for a walk a bit to the south-east to find some places to eat and drink. I had done my homework for the beer places (obviously!) but the place in my TODO list to visit on Wednesday did not have a lot of food so we decided to first go to a restaurant and we found Ha Veggie - Vietnamese Cuisine. I had some Edamame and Bò xào sả ớt, a delicious dish with seitan, vegetables, lemongrass and chili pepper.

We then stopped at Frisches Bier, a bit too late, but the publican was kind enough and she permitted us a last round. I had a pint of a refreshing Hoppebräu Wuide Hehna Session IPA.

We then took a walk back to our hotels, talked a bit and went to sleep.

Thursday 23, October 2025: 1st day of Mentor Summit

Thursday was the first day of the Mentor Summit. The summit was in Munich Marriott Hotel, more in the north of the city, around 5km from the central station.

I checked out of my hotel and walked to the city center in Marienplatz and nearby. I also stopped in a couple of shops to grab some souvenirs for my family and friends and then took a long walk in the direction of Munich Marriott Hotel, to hopefully be there at 13:00 sharp for the start of check-in of GSoC Mentor Summit.

Rear of the Siegestor showing its inscription that can be translated to "Dedicated to victory, destroyed by war, urging peace"

I walked through Ludwigstraße and enjoyed the architecture around me, walking near LMU University and Siegestor. I then proceeded through Leopoldstraße and Ungererstraße and then arrived to the Munich Marriott Hotel.

Chris was already in the lobby and he had already checked in. We talked a bit and then I checked in as well. The room was huge and comfy! I quickly went back down to the lobby. We then checked in for Mentor Summit and I finally met Stephanie, Mary and Lucy, the GSoC Program Admins. I also took with me from home some classical and specialty Italian chocolate (Cioccolato di Modica) for the chocolate room (more about that later!) and left the bars in the chocolate room.

The time from 13:00-17:00 was reserved to actually permit mentors to arrive. At 13:00 there were still not a lot of mentors around so with Chris we decided to have lunch. We had lunch in a trattoria where we had an antipasto of grilled vegetables, penne all'arrabbiata with red wine from Montepulciano.

While eating Chris talked about the Tantris but we were already full. We had not tasted the haute cuisine but walked there to just look at the restaurant building. O:)

Tables full of chocolate and sweets from the chocolate room

When we came back to Munich Marriott Hotel, I went to the chocolate room to taste some chocolate/sweets. In GSoC Mentor Summit it is a tradition to bring great quality chocolate - or other sweets for places where chocolate is less usual - so folks can taste sweets from all over the world. That's a very nice initiative! I was curious more about non-chocolate sweets completely new to me so I had some Laddu and Kaju katli, both delicious!

I spent the rest of the afternoon down at the Champions Bar socializing with other mentors.

We had dinner at around 19:00 with good food accompanied by a couple of glasses of Primitivo.

At 20:15 we had the Opening Session. Stephanie, Mary and Robert warmly welcomed us. They shared the schedule and introduced to the unconference format of the sessions. We then had dessert and played the GSoC 2025 Mentor Summit Scavenger Hunt. The Scavenger Hunt is a game where you can meet and find 25 different folks with something that could be common (e.g. «prefers spaces (not tabs)») to something pretty rare (e.g. «has jumped out of a helicopter»). This game was nice because it was also a great conversation starter. I met a lot of mentors both of open source software that I regularly use but also learned about new interesting open source software and organizations while doing that!

We had time until Friday 12:30 and 10 lucky mentors who completed it (at the end around 60 of 185 were able to complete) got randomly selected and they got special prizes.

I stayed up until probably 1am or so, socializing a bit more in the lobby and then went back to my room to have some sleep, knowing that Friday was completely packed with Lightning talks and sessions!

Friday 24, October 2025: 2nd day of Mentor Summit

I had breakfast around 8:20 at the Green's Restaurant. I sat at a table together with other folks and after a minute I saw a known name in front of me: Lourival Pereira Vieira Neto <lneto@>! I was very happy to meet another NetBSD developer and that was a complete surprise. He was there as a mentor of the LabLua organization.

GSoC Program Admins welcomed us for the day and recapped the schedule for Friday and Saturday.

Lightning talks, round 1

The lightning talks consisted of mentors presenting their best GSoC 2025 projects. The format was fast and fun: a maximum of 3 minutes for the talk and a maximum of 4 slides! We had presentations from 18 different mentors and orgs and all of them were able to stay under 3 minutes!

That was a great occasion also to learn about open source projects, new orgs and the experiences shared were interesting too.

GSoC Feedback Session

After the 1st round of Lightning Talks I attended the GSoC Feedback Session. That was a Q&A session with program admins and org admins/mentors.

Hot topics this year were AI usage and spam applications that were not discussed as part of this session because there were two other separate sessions regarding that later.

If I only have one sentence to summarize this session... I should quote Robert sharing that Google Summer of Code is about the journey for the contributors and mentors to get involved in open source. The coding is only the means to an end.

"Hallway track", lunch and group photo

After the first session I decided to take a break and instead stay in the "hallway track" where I met new folks and socialized a bit. Another funny and at the same time a bit embarrassing for me thing of GSoC is that I often met someone and after a couple of minutes of talk I can associate the face with a name and I figured out that I'm an avid user / pkgsrc MAINTAINER of the software they contribute to! :)

At 12:30 we had lunch at Green's Restaurant and then at 13:40 we had a group photo and it was pretty tricky to put around 200 folks (program admins and mentors) on the stage of the Ballroom! :)

Let's talk about improving diversity + inclusion in FOSS!

In the afternoon I joined the session about improving diversity. In open source unfortunately there are a lot of underrepresented groups and we should fix that.

There were a lot of experiences shared from several orgs, food for thought for me! Only to name few topics: Outreachy, how to know and create safe spaces, importance of localization in software and documentation, be sure to make underrepresented folk as part of key people and also try to take the burden of other tasks off them.

GSoC and AI

Artificial Intelligence (AI), in particular Generative AI (GenAI) has been a hot topic since project proposals opened this year!

Some people consider it a speed-up for researching but at the same time it impedes learning.

In NetBSD - according to our Commit Guidelines - code generated by large language model (LLM) or similar technologies is considered tainted code because such models can be trained on copyrighted materials and such resulting code can then violate copyright.

More than 80% of GSoC contributors who filled an anonymous survey used AI, mainly for code generation, code completion, text generation, debugging and error detection.

Most mentors are usually not happy with the outcomes of AI with code often resulting in buggy/vulnerable and poor quality, violating copyright and some mentors also pointed out that as part of mentoring we should also make contributors aware of environmental/ecological impact of such use.

However, both contributors' and mentors' surveys on AI are relatively small dataset (around 90 mentors and 90 contributors).

Lightning talks, round 2

At 16:00 we had the 2nd and last round of Lightning talks. That was another great opportunity to learn more about more projects and organizations!

Asynchronous I/O by Ethan Miller

Christoph Badura (<bad@>) presenting his lightning talk

Christoph Badura (<bad@>) did a lightning talk too and he presented work done by Ethan Miller. Ethan also blogged about his work, please read Google Summer of Code 2025 Reports: Asynchronous I/O Framework if you missed it!

This code was also imported by Christos Zoulas (<christos@>), thanks Christos!, and is now part of -current and it will be in NetBSD 12.0.

GSoC spammy proposals

After the Lightning talks there was a break and then at 17:30 I joined the session about GSoC spammy proposals.

This year most organizations received many more proposals, mostly due contributors starting to massively use GenAI.

A lot of suggestions and tips were shared to make the mentor review job smooth and easy as possible.

The most important suggestion is that mentors must do a 1:1 conversation with potential contributors before accepting them. The weight of the project proposal is like 2/10 and the actual 8/10 weight is on conversations between mentors and contributor.

Dinner and social event

Around 19:00 we had dinner, desserts and socialized. Stephanie also did a final talk recapping GSoC 2025 and thanking all mentors for making that possible.

We then had drinks and it then started the karaoke session (and there were a lot of pro folks doing that, very nice!).

The karaoke session at Ballroom closed with the waiter singing Closing Time (not the one by Tom Waits that is mostly instrumental, but the one by Semisonics!, I did not know it but that's melancholic as well for me, just smells a little bit less of whisky and cigs compared to the Tom Waits one ;)).

We went downstairs to the Champions Bar, had two rounds of some good Higgins Ale Works IPA and socialized a bit more. Time passed pretty quickly and also the barman there at Champions Bar started singing Closing Time!

We went a bit outside and in the lobby talking with other mentors and then I went back to my room to get some sleep for the last day of the summit.

Saturday 25, October 2025: 3rd day of Mentor Summit

I had breakfast around 8:00, a bit earlier, given that on Saturday the first session started at 9:00.

Porting & Packaging

At 9:00 I joined a session about porting and packaging. We had both FreeBSD porters, pkgsrc maintainers and other package systems maintainers on one side. On the other side there were also a lot of upstreams.

We shared do-s and don't-s on packaging.

How to get students to engage with the community

Christoph Badura (<bad@>) proposed a session to share experiences on how to get contributors to engage with the community and a lot of mentors provided a lot of great suggestions.

One thing that most mentors agreed on and worked well was to invite contributors regular (or less regular, to avoid putting too much pressure on contributors) blog posts / status updates.

Some organizations also did that as part of their weekly / bi-weekly updates that are often video meetings. In that case they reserved a slot for the contributor so that they can share their status updates.

These are great opportunities for the contributor to get in touch with the community.

Open source tools for supply chain security

I then joined a session about open source tools for supply chain security.

We discussed about Software Bill of Materials (SBOM) and its importance in the context of regulations like EU Cyber Resilience Act (CRA).

We also discussed Common Platform Enumeration (CPE) and Package URL (PURL) schemas

We talked about vulnerability management and I shared a bit my experience in pkgsrc-security@ and how often the metadata in CVEs (like vendor, product and versions affected) is not that good. Most package systems have their own workflows and usually add extra metadata only for their vulnerability DB.

I also learned about Vulnerability Exploitability eXchange (VEX) that some package systems use.

There were also mentors from AboutCode and SW360, projects that looks very interesting and I should learn more about them!

Vintage computing

Before lunch I joined the Vintage computing session.

Everyone presented themselves and talked about the most vintage computer they had, how running old machines is both fun and productive and we also talked about old Unix-es and The Unix Heritage Society.

Lunch

I had lunch at Green's Restaurant with other mentors and then socialized a bit outside Ballroom.

Waitlisted Lightning talk and funny stories

At 14:00 we had the last sessions. I went to the waitlisted Lightning talk, that can be considered the Lightning talk, round 3! :)

Mentors from different organizations shared interesting projects.

After the lightning talks several of us shared funny stories/hacks. Like learning languages in interesting ways, taking photographs of garbage to train and realize a robot that cleans it, a sort of Tinder for food... And much more! :)

Closing session

At 15:30 we had the closing session.

Some of us stayed for another 1 or 2 hours and talked, socialized a bit more and said see you soon to each other.

Going near Munich East Station and dinner with Chris

Around 17:00 I left the Munich Marriott hotel to check in to my hotel for Saturday night near Munich East Station. It was raining for most of the morning and afternoon but luckily around 17:00 it stopped and the sky seemed fine. I decided to take a walk - a bit more than 6km - to reach the hotel. Also that time I'm happy that I took a long walk because I was able to stay for most of my walk in the Englischer Garten.

Glass of Camba Island (NEIPA) beer and list of draft beers

I checked in at my hotel and then went to Tap-House where with Christoph we planned to have dinner and a couple of beers. Tap-House had a really huge choice of craft beers with 40 drafts! We had a pinsa marinara, a flatbread similar to pizza and I had a couple of small IPAs from Camba Bavaria and Yankee & Kraut Pure HBC 630, a DNEIPA.

We decided to take a walk and went to BrewsLi for some last good night beers. BrewsLi was a very nice brew pub. We sat at a table and near us there were several board games. Chris took one of this board game Mensch ärgere Dich nicht and explained to me the rules. A lot of aleatory is involved but there is also some strategy and it was funny to play and we probably played for 40 minutes or so because most of our game pieces returned to the "out" section. I took a walk with Chris back to the nearest metro station and I came back to my hotel around 2:00.

Mensch ärgere Dich nicht board game

Sunday 26, October 2025: stop in Bolzano/Bozen

On Sunday I took a train from Munich East Station to Bolzano/Bozen because it was unfeasible to go back home by train to Marche region without a stop somewhere in Italy.

View of Bolzano from St. Oswald Promenade

I went for a walk Passeggiata di Sant'Osvaldo (St. Oswald Promenade) uphill to be able to enjoy a view of the city from the top until sunset.

I had a simple but very tasty onion soup and a Gose (really good, one of the best Gose I've drunk!) and Session IPA at Batzen Häusl.

I was not able to visit anything else in the night because I was pretty tired so I went to sleep earlier.

Monday 27, October 2025: back home

In the morning I took a walk to Walther Square and nearby. I got some souvenirs for the family and then I took the trains back home and spent most of my day on the trains.

Conclusion

Google Summer of Code 2025 Mentor Summit was an amazing experience!

I had the chance to participate in very interesting talks, sessions and discussions. I met a lot of mentors from all over the world and learned about new open source projects and organizations. All the folks were also extremely positive, easy to talk to and I had a lot of fun.

Thanks to program admins and all the mentors who made this possible! Thanks a lot also to Google for organizing it and thanks to The NetBSD Foundation that permitted me to go!

NetBSD hand-written logo on the GSoC guest book

If you are new to open source, consider applying for it! If you are a seasoned open source contributor, consider participating as a mentor! You can learn more about GSoC at Google Summer of Code (GSoC) website.

Hi,

My transportable (micropc) homelab has the following specs.

* CPU: AMD Ryzen 7 7730U (8 cores 16 threads)
* RAM: 32GB (Crucial 2x16 LPDDR4 SODIMM)
* SSD: WD BLACK SN850X 1000GB (nvme, made by sandisk)

I'm running Proxmox 9.0.11 with the (Linux) proxmox-kernel-6.17 (soon to be but not yet default).
As people know with proxmox and all Linux KVM virtualisation solution most of the time, for performance, storage is either virtio-blk, or scsi on virtio-scsi single emulated controler.

In my situation the underlying virtual machine storage is on the NVME SSD as LVM volumes.

I have 3 virtual machines as an experimental setup.

• 1)

  AlmaLinux 9.6
  8 GB of memory
  4 vCPU
  64 GB of virtio-blk storage on with an XFS root (default partitioning)

• 2)

  # https://nycdn.netbsd.org/pub/NetBSD-daily/netbsd-11/20251028150036Z/amd64/installation/cdrom/boot.iso
  NetBSD 11_BETA
  8 GB of memory
  4 vCPU
  128 GB of virtio-blk storage with ffs2ea (default partitioning).

• 3)

  # https://nycdn.netbsd.org/pub/NetBSD-daily/netbsd-11/20251028150036Z/amd64/installation/cdrom/boot.iso
  NetBSD 11_BETA
  8 GB of memory
  4 vCPU
  128 GB of scsi (virtio-scsi-single) storage with ffs2ea (default partitioning).

I already precise that the issue is also on NetBSD 10 but I tried to see if the 11_BETA with the few virtio improvements would have it solved.

I tried both the pkgsrc fio (3.19) benchmark version and the same version as the one in almalinux repositories (3.35) compiled from source on the NetBSDs VMs and get the same results.

The goal of trying the same version on Linux and NetBSD as well as using the same exact working fio parameters to have something "comparable".

The following commands was run on all VMs.

mkdir /root/test
export TEST_DIR=/root/test

fio --name=write_throughput --directory=$TEST_DIR --numjobs=4 \
--size=10G --time_based --runtime=5m --ramp_time=2s --ioengine=posixaio \
--direct=1 --verify=0 --bs=1M --iodepth=64 --rw=write \
--group_reporting=1 --iodepth_batch_submit=64 \
--iodepth_batch_complete_max=64 --thread=1

I must precise that I never run the command on two VMs at the same time and that they are the sole VMs/containers/workloads running on the Proxmox system.

The result were:

• 1) Linux virtio-blk

  write_throughput: (g=0): rw=write, bs=(R) 1024KiB-1024KiB, (W) 1024KiB-1024KiB, (T) 1024KiB-1024KiB, ioengine=posixaio, iodepth=64
  ...
  fio-3.35
  Starting 4 threads
  write_throughput: Laying out IO file (1 file / 10240MiB)
  write_throughput: Laying out IO file (1 file / 10240MiB)
  write_throughput: Laying out IO file (1 file / 10240MiB)
  write_throughput: Laying out IO file (1 file / 10240MiB)
  Jobs: 4 (f=4): [W(4)][100.0%][w=3011MiB/s][w=3011 IOPS][eta 00m:00s] 
  write_throughput: (groupid=0, jobs=4): err= 0: pid=17950: Thu Oct 30 20:01:50 2025
    write: IOPS=3130, BW=3131MiB/s (3283MB/s)(918GiB/300058msec); 0 zone resets
      slat (usec): min=3, max=622, avg=31.43, stdev= 8.96
      clat (msec): min=12, max=326, avg=80.93, stdev= 9.06
       lat (msec): min=12, max=326, avg=80.96, stdev= 9.06
      clat percentiles (msec):
       |  1.00th=[   61],  5.00th=[   75], 10.00th=[   78], 20.00th=[   79],
       | 30.00th=[   79], 40.00th=[   80], 50.00th=[   81], 60.00th=[   81],
       | 70.00th=[   82], 80.00th=[   83], 90.00th=[   85], 95.00th=[   87],
       | 99.00th=[  120], 99.50th=[  130], 99.90th=[  171], 99.95th=[  211],
       | 99.99th=[  300]
     bw (  MiB/s): min= 1536, max= 4356, per=100.00%, avg=3133.45, stdev=70.96, samples=2397
     iops        : min= 1536, max= 4356, avg=3133.25, stdev=70.95, samples=2397
    lat (msec)   : 20=0.01%, 50=0.03%, 100=97.12%, 250=2.84%, 500=0.02%
    cpu          : usr=2.59%, sys=0.09%, ctx=104044, majf=0, minf=0
    IO depths    : 1=0.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.1%, >=64=100.0%
       submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
       complete  : 0=0.0%, 4=98.6%, 8=0.1%, 16=0.0%, 32=0.0%, 64=1.4%, >=64=0.0%
       issued rwts: total=0,939328,0,0 short=0,0,0,0 dropped=0,0,0,0
       latency   : target=0, window=0, percentile=100.00%, depth=64
  
  Run status group 0 (all jobs):
    WRITE: bw=3131MiB/s (3283MB/s), 3131MiB/s-3131MiB/s (3283MB/s-3283MB/s), io=918GiB (985GB), run=300058-300058msec
  
  Disk stats (read/write):
    vda: ios=0/955150, merge=0/46, ticks=0/1202556, in_queue=1202602, util=92.54%

• 2) NetBSD scsi with virtio-scsi-single

  write_throughput: (g=0): rw=write, bs=(R) 1024KiB-1024KiB, (W) 1024KiB-1024KiB, (T) 1024KiB-1024KiB, ioengine=posixaio, iodepth=64
  ...
  fio-3.35
  Starting 4 threads
  write_throughput: Laying out IO file (1 file / 10240MiB)
  write_throughput: Laying out IO file (1 file / 10240MiB)
  write_throughput: Laying out IO file (1 file / 10240MiB)
  write_throughput: Laying out IO file (1 file / 10240MiB)
  Jobs: 4 (f=4): [W(4)][100.0%][w=442MiB/s][w=441 IOPS][eta 00m:00s]   
  write_throughput: (groupid=0, jobs=4): err= 0: pid=8190: Thu Oct 30 20:12:30 2025
    write: IOPS=474, BW=476MiB/s (499MB/s)(139GiB/300243msec); 0 zone resets
      slat (usec): min=16, max=7360, avg=54.05, stdev=64.82
      clat (msec): min=363, max=680, avg=536.68, stdev=56.25
       lat (msec): min=364, max=680, avg=536.73, stdev=56.24
      clat percentiles (msec):
       |  1.00th=[  397],  5.00th=[  435], 10.00th=[  447], 20.00th=[  468],
       | 30.00th=[  550], 40.00th=[  550], 50.00th=[  558], 60.00th=[  558],
       | 70.00th=[  567], 80.00th=[  575], 90.00th=[  592], 95.00th=[  600],
       | 99.00th=[  642], 99.50th=[  642], 99.90th=[  659], 99.95th=[  659],
       | 99.99th=[  684]
     bw (  KiB/s): min= 7926, max=1035193, per=100.00%, avg=514464.07, stdev=29885.72, samples=2213
     iops        : min=    4, max= 1009, avg=500.48, stdev=29.19, samples=2213
    lat (msec)   : 500=26.63%, 750=73.38%
    cpu          : usr=1.58%, sys=48.62%, ctx=9107687, majf=0, minf=105676866
    IO depths    : 1=0.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=100.0%
       submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
       complete  : 0=0.0%, 4=98.6%, 8=0.1%, 16=0.0%, 32=0.0%, 64=1.4%, >=64=0.0%
       issued rwts: total=0,142592,0,0 short=0,0,0,0 dropped=0,0,0,0
       latency   : target=0, window=0, percentile=100.00%, depth=64
  
  Run status group 0 (all jobs):
    WRITE: bw=476MiB/s (499MB/s), 476MiB/s-476MiB/s (499MB/s-499MB/s), io=139GiB (150GB), run=300243-300243msec

• 3) NetBSD virtio-blk

  write_throughput: (g=0): rw=write, bs=(R) 1024KiB-1024KiB, (W) 1024KiB-1024KiB, (T) 1024KiB-1024KiB, ioengine=posixaio, iodepth=64
  ...
  fio-3.35
  Starting 4 threads
  write_throughput: Laying out IO file (1 file / 10240MiB)
  write_throughput: Laying out IO file (1 file / 10240MiB)
  write_throughput: Laying out IO file (1 file / 10240MiB)
  write_throughput: Laying out IO file (1 file / 10240MiB)
  Jobs: 4 (f=4): [W(4)][100.0%][w=439MiB/s][w=439 IOPS][eta 00m:00s]   
  write_throughput: (groupid=0, jobs=4): err= 0: pid=6889: Thu Oct 30 20:07:08 2025
    write: IOPS=480, BW=481MiB/s (504MB/s)(141GiB/300537msec); 0 zone resets
      slat (usec): min=18, max=20026, avg=53.78, stdev=97.30
      clat (msec): min=358, max=773, avg=530.61, stdev=55.92
       lat (msec): min=358, max=773, avg=530.66, stdev=55.91
      clat percentiles (msec):
       |  1.00th=[  372],  5.00th=[  439], 10.00th=[  447], 20.00th=[  460],
       | 30.00th=[  535], 40.00th=[  542], 50.00th=[  550], 60.00th=[  558],
       | 70.00th=[  567], 80.00th=[  575], 90.00th=[  584], 95.00th=[  592],
       | 99.00th=[  617], 99.50th=[  634], 99.90th=[  760], 99.95th=[  760],
       | 99.99th=[  768]
     bw (  KiB/s): min= 9925, max=1030032, per=100.00%, avg=516160.58, stdev=29960.85, samples=2232
     iops        : min=    6, max= 1004, avg=502.18, stdev=29.27, samples=2232
    lat (msec)   : 500=25.99%, 750=73.90%, 1000=0.13%
    cpu          : usr=1.70%, sys=47.99%, ctx=9267027, majf=0, minf=107446337
    IO depths    : 1=0.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=100.0%
       submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
       complete  : 0=0.0%, 4=98.6%, 8=0.1%, 16=0.0%, 32=0.0%, 64=1.4%, >=64=0.0%
       issued rwts: total=0,144320,0,0 short=0,0,0,0 dropped=0,0,0,0
       latency   : target=0, window=0, percentile=100.00%, depth=64
  
  Run status group 0 (all jobs):
    WRITE: bw=481MiB/s (504MB/s), 481MiB/s-481MiB/s (504MB/s-504MB/s), io=141GiB (152GB), run=300537-300537msec

I didn't expect NetBSD to be on par with Linux, but I didn't expect a 6x difference (3000MiB/sec for the Linux guest vs 500MiB/sec for NetBSD guest).

I am willing to use NetBSD more in the future, but this kind of massive performance degradation makes it not really a good option for any write heavy workloads and databases.

I am aware this is just a write speed benchmark but I can try read as well if necessary as well as random read writes and so on so forth. You can see that I didn't use io_uring or libaio on Linux to try keeping things safe unless Linux wraps a different system under posixaio in a way I am not aware.

Did I miss something ? Is there some tuning to be done on NetBSD ?

I decided to make the test because I already felt NetBSD sluggish on VPS servers.

I'm not so found of writing to the mailing list because i would have to create yet another throwable email since addresses are made public, but I know there are some NetBSD devs here.

This may also interest @iMil since he works on smolBSD.

Cheers,

PS: I have a similar issue with networking rates/speed but I will create a different post for that.

Please forgive the fluffy nature of this post. If you’re expecting a technical discussion, perhaps look through the archives instead today.

On Mastodon I talked about how I enjoyed being in the BSD, OpenZFS, and illumos communities, even if I only consider myself a lurker most of the time. I don’t know how else to say this, but… I really mean that. More than I could express.

These systems, and the people behind them, are the reason why I can sit here and write this post. Not just in a technical sense, but in a “why I get up in the morning” sense. It’s that stark.

When the broader industry seems hellbent on installing the Torment Nexus, these communities sit on the periphery, quietly designing, developing, documenting, maintaining, patching, porting, upgrading, testing, integrating, and discussing the tools that make my life better, and the tools I can recommend without question. Ditto for all the people who organise events, coordinate projects, manage sponsorships, mediate discussions, and engage with the public. This is all a tremendous amount of work which so often goes unacknowledged, let alone recognised.

I come home after a day of fighting with crappy systems that are ill conceived, badly designed, overpriced, inflexible, and full of hostile dark patterns that would shoot me in the back to make a line go up, and I get to use thoughtfully written, well implemented software that doesn’t chase the shiny. The fact such small teams (relatively speaking) are responsible for software that is better, easier, and more open that companies with orders of magnitude more resources is shocking to me.

I’ve only managed to meet a dozen or so of you at events or over the phone, but you know who you are. You should also know that you’ve had an oversized impact on my life. It’s cool when I read a man(1) page and your name is there, or when I log into a box and I see your handle at the end of a fortune(1).

I guess I wanted to say, in my usual roundabout way, thank you for all you do, and for entertaining my presence too. I’ll continue to work on ways I can contribute back.

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

I’m old enough now to know that some things aren’t targeted at me, and that my distaste of something doesn’t translate into broader artistic merit or usefulness. That said, I watched my first YouTube shorts today, and left more… confused than I thought!

I don’t even know how it started. One minute I was catching up on someone talking about a Sanyo MBC system from the 1980s, and the next I was watching a vertical video about a carved watermelon lamp with single-word subtitles that looped for some reason.

To be clear, is an idiom. Vertical video makes sense, given people are watching this sort of disposable media on their phones. I’m all for the accessibility subtitles provide, though I’d prefer they weren’t baked in and didn’t take up half the screen. The looping I don’t get; whenever I see people watching these sorts of videos they’re swiping as soon the previous video finishes.

Curiously, it was the stilted audio I found most jarring. The Overcast podcast app was made famous for the somewhat grim idea that contemplative silence isn’t a natural part of speech, but wasted time to be cut so you cram even more audible thoughts into your brain hole. But this takes it to a level where the previous word is barely finished before the next begins. I’m trying not to make a broader point about attention spans here, but it’s unavoidable. Are we that time starved? Or will people stop watching if the wholevideoisn’tonelongrunonsentence?

I know, I know, get off my lawn!

But there was one other aspect to this where I think criticism is warranted. I’d say at least half the videos that were regurgitated to me started with the same voiceoveer:

In this video, we can see this person…

Half of these videos aren’t even original. They’re stolen wholesale, and overlaid with text and an AI voiceover that explains in painfully obvious detail what we can already see.

… is building a beautiful desk. The first step involves picking up a hammer, which he uses to hit a nail into the side of…

No, really!? He was using a hammer to drive in a nail? Not a tool to bludgeon himself in the head!? In his DAMNED HEAD!?!?!?!

I’m perhaps showing my ignorance here, but I thought YouTube had famously onerous and overzealous piracy protections? I’m surprised these videos aren’t being flagged almost immediately. Or maybe they are, and the shorts I watched earlier today are already gone.

It makes me wonder what a Short would be for NetBSD.

I’m going to show you how easy it is to install package source! This is the tool that lets you install software on your NetBSD operating system! First, run su and pipe this fetch into ksh which…

Hmm, maybe not.

So how would I summarise my first—and hopefully last—experience with YouTube Shorts? I dunno, that seems like a waste of time given you’ve already read the post. You do you, but I’ll continue to steer well clear of this sort of content (a deliberate word choice).

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

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

This is the 2nd blog post about his work. If you have missed the first blog post please read Google Summer of Code 2025 Reports: Enhancing Support for NAT64 Protocol Translation in NetBSD.

Overview

Typical rules looks like:

map wm0 algo "nat64" 64:ff9b:2a4:: -> 192.0.2.33
map wm0 algo nat64 plen 96 64:ff9b::8c52:7903 <- 140.82.121.3

This tells NPF to translate outgoing IPv6 packets using the prefix 64:ff9b:2a4::/96, rewriting them to use the IPv4 address 192.0.2.33. When the packet returns and hits NPF, it changes source from GitHub's IPv4 to GitHub's IPv6 address and then it rewrites the header.

When an IPv6 packet from a client hits the NPF machine

• The NAT64 translation routine (npf_nat64_rwrheader()) rewrites the IPv6 header to an IPv4 header.
  • The source becomes the host's IPv4 address or any pool of IPv4 addresses.
  • The destination becomes the IPv4 address of github.com extracted from IPv4 embedded IPv6 address defined in the rule configuration. (e.g. 140.82.121.3 from 64:ff9b::8c52:7903).
• TCP/UDP/ICMP checksums are recalculated using in4_cksum() or in6_cksum().
• The packet is then routed out to the IPv4 network.

When a reply packet comes back from the IPv4 server

• NPF performs the reverse translation, embedding the IPv4 address inside the NAT64 prefix to form a valid IPv6 address using npf_embed_ipv4()
• The IPv6 packet is then delivered back to the IPv6 client.

Project Accomplishments

• Core Translation Path: Implemented IPv6 -> IPv4 header and reverse rewriting (npf_nat64_rwrheader() routines).
• Address Mapping: Added functions for embedding and extracting IPv4 addresses within IPv6 prefixes.
• Checksum Recalculation: Integrated checksum updates for IPv4/IPv6 and transport layers.
• Rule Parsing: Extended npf.conf(5) syntax and parser to accept NAT64 configuration parameters.
• Userland and Kernel Integration: Updated kernel headers, userland utilities, and rule constructors.
• Testing: Verified translation with ping, curl and dig, observing packets using tcpdump and Wireshark.

Summary

This project successfully integrates NAT64 along with a separate DNS64 configuration into NPF, enabling IPv6-only clients to reach IPv4-only servers through seamless translation. Although there's a need for additional changes and implementation.

This is indeed the end of my GSoC Program, it was indeed an exciting moment working with system developers and certainly I'd be an active contributor to the NetBSD codebase.

Source code of the Google Summer of Code project can be found at the following branch.

I've just installed virt-manager with pkgin on NetBSD 9.2 just because I want to emulate the virtual machines with qemu + nvmm on NetBSD 9.2. The installation of virt-manager went ok. But,when I ran it,an error came up :

netbsd-marietto# virt-manager

Traceback (most recent call last):

File "/usr/pkg/share/virt-manager/virt-manager.py", line 386, in <module>

main()

File "/usr/pkg/share/virt-manager/virt-manager.py", line 247, in main

from virtManager import cli

File "/usr/pkg/share/virt-manager/virtManager/cli.py", line 29, in <module>

import libvirt

ImportError: No module named libvirt

Googling a little bit maybe I've found the solution here :

https://www.unitedbsd.com/d/285-linux-user-and-netbsd-enthusiast-hoping-to-migrate-some-day

where "kim" said :

Looking at pkgsrc/sysutils/libvirt/PLIST it doesn't look like the package provides any Python bindings -- which is what the "ImportError: No module named libvirt" error message is about. You could try py-libvirt from pkgsrc-wip and see how that works out.

I tried to start the compilation like this :

netbsd-marietto# cd /home/mario/Desktop/pkgsrc-wip/py-libvirt
netbsd-marietto# make

but I've got this error :

make: "/home/mario/Desktop/pkgsrc-wip/py-libvirt/Makefile" line 15: Could not find ../../wip/libvirt/buildlink3.mk
make: "/home/mario/Desktop/pkgsrc-wip/py-libvirt/Makefile" line 16: Could not find ../../lang/python/distutils.mk
make: "/home/mario/Desktop/pkgsrc-wip/py-libvirt/Makefile" line 17: Could not find ../../mk/bsd.pkg.mk
make: Fatal errors encountered -- cannot continue

If u want to see the content of the Makefile, it is :

gedit /home/mario/Desktop/pkgsrc-wip/py-libvirt/Makefile

#$NetBSD: Makefile,v 1.32 2018/11/30 09:59:40 adam Exp $

PKGNAME= ${PYPKGPREFIX}-${DISTNAME:S/-python//}
DISTNAME= libvirt-python-5.8.0
CATEGORIES= sysutils python
MASTER_SITES= https://libvirt.org/sources/python/

MAINTAINER= [email protected]
HOMEPAGE= https://libvirt.org/sources/python/
COMMENT= libvirt python library
LICENSE= gnu-lgpl-v2

USE_TOOLS+= pkg-config

.include "../../wip/libvirt/buildlink3.mk"
.include "../../lang/python/distutils.mk"
.include "../../mk/bsd.pkg.mk"

Can someone help me to fix the error ? very thanks.

Anyone have experience building NetBSD specifically for embedded devices?

I got this Risc-V tablet here, and it has some issues. It came a few weeks ago with Debian Bullseye installed. I am comfortable with Debian, but Bullseye was two releases ago, and even worse it is pinned to a 2021 snapshot. So, software are missing all those vital security patches. Firefox can't even install current extensions, because it is too out of date. I tried upgrading it to Sid three times, but each time the superblocks in the file system become corrupted. So now I am updating it to a 2023 snapshot, but still, that was two years ago, and the superblocks might still get corrupted in the process.

I was thinking about starting fresh with a NetBSD install, but it appears a custom kernel is going to be needed before that can happen. The Manufacturer put's out their own custom Linux kernel, and I imagine it includes some hardware specific modules, so everything is compatible. I also would like to incorporate a file system like F2FS or NilFS, one designed purposefully around embedded devices which operate off of EMMC drives.

It can't be that difficult to accomplish, having built NetBSD and OpenBSD a few times. If it is, I might just throw the tablet on Ebay and start over.

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.

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.

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

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.

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.

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)