NetBSD Planet

I got a new MacBook Air for work as part of a fleet refresh, which happened to coincide with Dan Langille getting a new one too. I like to imagine us sitting at a coffee shop setting our kit up together; that’d be fun.

Dan goes into detail explaining what he does with a new machine. I won’t go into as much detail, but these are my high-level steps.

In the past I had Ansible scripts I’d use to stand up new machines. But desktops thesedays change so much, they were rarely usable out of the box without tinkering. So now I configure things the old fashioned way; albeit with a few choice repositories.

Pre-configuration

1. Create a USB key with the latest macOS release, and booting from it

2. Wipe the new machine, configuring APFS with encryption, with some slack space at the end for dual-booting if needed.

3. Boot into macOS for the first time, force a software update, and restart.

Is this paranoid? Probably. Does it do much? Almost certainly not. Will I keep doing it until Apple decides they don’t want to grant us permission to install things on our own computers ourselves? Absolutely yes.

Making the Mac desktop more pleasant

1. Right-click the Dock, and choose Left under Position on Screen. This makes the best use of widescreens. I also click Dock Settings… and disable Show suggested and recent apps in Dock. I also choose Only in Stage Manager for Click wallpaper to reveal desktop. You can’t disable this annoying behavior entirely, but I don’t even know what a “Stage Manager” is, so this is fine.

2. Go to the Finder, and Settings:

   • Under General, I like to uncheck all desktop items to reduce visual clutter.

   • Under Sidebar, I add my home directory and hide things like AirDrop and iCloud that I don’t use.

   • Under Advanced, I enable Show all filename extensions, and I check everything under Keep folders on top. I also choose Search the Current Folder under When performing a search.

Fixing settings

The macOS System Settings is a hot mess now, and the Search bar is functionally useless most of the time. This is as much for me to remember where settings now are, as of Sonoma:

1. Launch System Settings. These next screens are in the order they appear on the sidebar.

2. Under Network, configure the wireless and wired networks, and set the appropriate DNS settings.

3. Under Accessibility, choose Display, and enable Reduce transparency, Reduce Motion, Show window title icons, and Show toolbar button shapes. These are less about accessibility and more about taste.

4. Under Appearance, change the Accent color and Highlight Color to green. I’d choose teal, the world’s best colour, but this isn’t an option. I find green calming. I also enable Show scroll bars always, and set Sidebar icon size to small.

5. Under Apple Intelligence & Siri, verify that all that guff is turned off. Alas, this is something we all need to do every time we do an update. Hey, at least it isn’t Recall.

6. Under Control Centre, enable Show Percentage under Battery. Under Clock options, I enable Show the day of the week and Display the time with seconds.

7. Under Keyboard, drag the Key repeat rate slider to the fastest it will, go and Delay until repeat to the shortest.

8. Under Trackpad, click Tap to click.

9. Under Displays, set the resolution required for 2× HiDPI/Retina, not the hideous 1.5× that Apple now defaults to. Such sharpness!

Configuring package managers

1. Go to brew.sh for the requisite install command for the Terminal. This is what I use for graphical applications and some Mac tools.

   • Install essentials like Firefox, LibreOffice, Microsoft Office, MacVim, Ferdium, Thunderbird, the GNU Image Manipulation Program, Mattermost, KeePassXC, Inkscape, Viscosity for VPN connections, QEMU, and UTM.

2. Go to pkgsrc on SmartOS—thank you MNX!—for the pkgsrc installation tarball. I install this into /opt/pkgsrc.

   • Installing essentials like Perl, Python, LaTeX packages, my preferred shell oksh, and all my tooling.

3. Open the Mac App Store and installing a few tools like Wireguard and other chat software.

Post-install configuration

1. Connect to our home FreeBSD server and git clone my configuration, SSH, VPN, and work repos into ~/repos, then alias my dotfiles from that into my home directory.

2. Generate new keys/keypairs for SSH and Wireguard for this machine.

3. Go to Konachan.net, Wikimedia Commons, and/or our server photos folders for an appropriate wallpaper.

I think that’s it? Now back to work.

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

Hello. I use NetBSD 10.1. The touchpad of my laptop annoys me with click-to-tapping. I would like to disable the click-to-tap function and utilize the physical buttons on my touchpad instead. Using dmesg command I found that my touchpad is Synaptic. Reading through the pms man page I did not find a variable that could disable the annoying click-to-tapping. Is it possible to disable the function?

Hi everyone,

I recently upgraded from NetBSD 10.0 to 10.1 using the sysupgrade auto command. The upgrade went smoothly without any errors, but after rebooting I’ve noticed that some programs are taking longer than usual to start. This wasn’t happening back when I was running 10.0.

The most noticeable delay happens when I open uxterm — as you can see in the screenshot I attached, it can take up to seven seconds to launch, which feels like way too much for a terminal.

Also, as shown in the same image, I don’t have many processes running, and none of them are putting any real load on the CPU.

So my question is: could anyone point me in the right direction to figure out what’s causing this delay?

Thanks in advance for any help!

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)

I don’t watch Apple keynotes or news that often anymore; the company hasn’t done anything worth paying attention to for years. But Ernie Smith caught this nugget at the end of the Platforms State of the Union talk:

macOS Tahoe will be the final release for Intel Macs. So if you’ve not done so already, now is a great time to help your users migrate to the Apple silicon versions of your apps.

I still bristle a bit when I hear desktop software referred to as “apps”. It reads as though they’re trivialising their complexity and importance; though maybe I’m just old fashioned.

But back to this announcement! We knew it was coming—we’ve known for many years at this point—it was just a question of when. Those of us who lived through past transitions knew that our older hardware was living on borrowed time from the moment the new architecture was announced. It’s not all bad though; replacing Mac OS X on my iBook G3 was my gateway into NetBSD! But I digress.

Still though, it’s interesting to look back at Apple’s foray into Intel Macs: what a curiosity they were. It was weird to me at the time that they they leaned so heavily on Intel’s name recognition, rather than saying they were moving to x86. It limited their potential collaboration with AMD for example, though I suppose they were still in the proverbial silicon woods at the time.

I had the first Intel MacBook Pro, as I mentioned in passing in a blog post about Mozilla software in 2006. I used it for years, but boy was it a rough machine. It had a loud, shrill whine when the CPU was idle, to the point where the “fix” was to run a shell script that chewed up just enough battery power to shut it up. I remember being on a call with an Apple rep in Crows Nest at the time, and they were well aware of the issue, and… unconcerned. Maybe they’d been to too many concerts and couldn’t hear it when it was reproduced for them. The cooling system was never great either; I ended up repasting it a few years later and the results were embarrassingly better. The screen inverter died, the MagSave port was flaky, both fans eventually needed replacing. My first, and one of my only YouTube videos, was about this! Very strange for a laptop that was never dropped or manhandled.

Just like the first Intel iMac, this MacBook Pro was also among the only Macs released with Intel’s Core Duo CPU; no, not Core 2 Duo. The Core Duo was 32-bit silicon, meaning we were artificially limited by what we could run almost from the start. I believe it was a year later when Apple released a Core 2 Duo-based machine, and we lost support for Mac OS X a few years later. Even many Apple fans seem oblivious to this oddity in Apple’s lineup, given how people thought Apple moved permanently to 64-bit CPUs starting with the G5.

That said, is a phrase with two words. Mac OS X had its golden era on the Intel platform. The best versions of the OS were released during this time, which perhaps says more about modern macOS than anything else. The last great, serviceable desktop Mac—the original Mac Pro—also sported Intel CPUs.

We’re spoiled in many ways with how good Apple Silicon MacBook hardware is now. No PC laptops that I’m aware of can match their weight, 2× HiDPI screens, battery life, and performance. I had an 11-inch Intel MacBook Air I miss dearly, but it was a slouch compared to my desktops at the time. If only their software and services didn’t continue to slide from okayish, to mediocre, to baffling, to embarrassing.

Anyway! A bit of a shaggy dog story about a retired architecture for your Sunday morning. Just be thankful I didn’t wax lyrical about PowerPC.

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

TLDR; Asking for a hand in learning how to develop and contribute to NetBSD

Hello, I have been trying to learn operating systems development for around five years. I felt comfortable enough in conceptual understanding to reach out for mentoring around a year ago. My goal is to find a small(er) community where the atmosphere might be more welcoming to newcomers than larger projects, and where I can potentially make a larger impact.

I started with illumos. Although I did some minor ports to software in order to try to contribute (and reached out to the community for help), I didn't get much traction. Afterwards, I reached out to the now-abandoned Minix3 project. I have a copy of The Minix Book and found its content to be rewarding. I reached out to some of the Minix3 developers, as well as the larger community, asking about the project and prospects of receiving some type of mentorship. Although I didn't find much in the way of community help as it seems the project has gone dormant, I did manage to do minor updates to the base Minix3 source tree in order to sync some of the outdated NetBSD tooling with new NetBSD tooling, since Minix version 3.2 and above lives in the NetBSD source tree. I applied old Minix3 patches to the new NetBSD tooling, using diffs/grep/find to locate Minix3 patches, and functionality which has changed between NetBSD releases. This also gave me a chance to familiarize myself with NetBSD.

Where I find myself now is at a point of conceptual understanding, lacking clarity and understanding when looking at the NetBSD repository [or any large OS repository for that matter]. I understand the layout and purposes of the source tree at varying levels, comparing what I see in the source tree against the concepts I learned in materials I have read. I find it difficult to modify code -- I feel like seeing someone else doing this would be very beneficial, and can testify to how helpful mentorship in any capacity can be.

I would really appreciate some newcomer-friendly instruction. My courses don't cover this area and I have gaps in understanding that I'm eager to close. I would like to see the methodology, tooling, and steps used by others in order to have a starting point. Ideally, I'd like to arrive at a point where I can bootstrap this knowledge and begin contributing to NetBSD.

Thanks for your consideration. 🙂

A couple of weeks ago I built a NAT router/gateway/firewall with a RockPro64 running NetBSD 10.1 and using NPF. After some frustration I started to better understand NPF and had a lot of fun making this work. So for at least a week, this RockPro64 has been idling along, routing packets galore. Tonight, my wife was streaming a video from some proprietary service, watching a graduation ceremony. There wasn't anything else significant happening on our LAN. Suddenly NAT wasn't forwarding packets anymore. Everything else was working except LAN devices could not see the WAN. All 6 CPUs on the RockPro64 were at idle and RAM usage was low. Restarting NPF didn't solve the problem, as expected. Removing and re-initialising the WAN interface didn't help. The only thing that helped was rebooting the RockPro64.

What could cause this, or how could I have determined what caused it?

Last week I mentioned we’d been off with the flu. Not to get all Malcolm Gladwell on you, but turns out it was also Covid; in particular that new strain that’s sweeping all over the place. Fun! I said in that post that it had taken us out “worse than Covid did”… little did I know at the time.

My brain is finally starting to come back online having been stuck at the human equivalent of an fsck> prompt for a couple of weeks. Alas, my brain does not use OpenZFS, so sometimes it loses data and functions based on external stimuli. If only I could issue a brain scrub and be done with it; instead I have to wait until the UFS in my grey matter is reconstituted. Good thing I keep a… journal!

It got me thinking about some of the tech that helped us through it. It’s easy to be cynical in the current world, but our recovery was made immeasurably better thanks to some basic things—and the people behind it—that I wanted to thank.

In no particular order:

• FreeBSD, NetBSD, OpenZFS, and Alpine Linux. Aside from the first three all being pleasingly-matched names with letters and an initialism, they kept everything going without my input the whole time.

• Plex. Their platform continues to drop free features while ignoring the ones people want, but in a pinch it still worked beautifully delivering stuff to our TV so we could sit there like blobs with little motor control and effort. Their AppleTV application continues to be the best one on the platform.

• YouTube. I both love and hate YouTube. It’s an increasingly enshittified platform with lots of issues, but the people on it are wonderful. We may have watched more than a few retrocomputing, engineering, and cooking videos during that time, even if my mind barely comprehended half of it. One video I watched about the Z80 made me wonder what the CPU in the Commodore 64 was… and I couldn’t remember the number (it’s the 6510, but I was thinking “the 606-something?”)

• Those combined rapid test things. You can now get ones with Covid, the current dominant strain of influenza, and a couple of other diseases I hadn’t even heard of, all in the one test kit.

• The Web. I was able to keep in contact with family, friends, and colleagues; do telehealth appointments; and so much more thanks to the miracle of packet-switched Ethernet that kept our little abode connected to the outside world. Then as we started feeling better, the Web let us continue to isolate so as to not infect anyone else.

• Minecraft. Don’t have the brain capacity to do anything other than resurface train line tunnels for hours at a time? Minecraft has you covered. Honourable mention here goes to all the classic Maxis and Humongous Entertainment games, and those Microsoft simulation games from the late 1990s, all of which can also be as complicated or as simple as you want.

• Modern creature comforts like running hot and cold water, drains, refrigerators, coffee grinders, microwave convection ovens, soap, washing machines, electric toothbrushes, vtubers, thermal shirts, rechargeable batteries, video upscalers, double-glazed windows, toasters, cotton socks, CD changers, and diffused lighting. I remember sitting on our little couch staring at the ceiling with a fever and being grateful that I could sit in such modern comfort while feeling that way. There are people in the world who aren’t as lucky.

• Universal Human Translater. Mine has been stuck on English since I crash landed on Earth in the late 1980s, but it still works decently well. Wait, you didn’t read that.

• Showers. I could have thrown that into the creature comforts point above, but a hot shower when your bones and eyes hurt is absolutely, indescribably wonderful, not to mention how the steam helps with sinuses and sore throats. I would leave the confides of water and steam feeling like a new person, even if only for a short while.

I’m sure I’m ignoring, forgetting, or otherwise failing to mention many more. Those things were also great.

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

NetBSD is an OS that I installed only a couple of times over the years, so I’m not very familiar with its installer, sysinst. This fact was actually what led to this article (or the whole series rather): Talking to a NetBSD developer at EuroBSDcon 2023, I mentioned my impression that NetBSD was harder to install than it needed to be. He was interested in my perspective as a relative newcomer, and so I promised to take a closer look and write about it. While it certainly took me long enough, I finally get to do this. So let’s take a look at NetBSD’s installer, shall we? The version explored here is NetBSD 10.1 on amd64.

↫ Eerie Linux

An excellent deep, deep dive into the NetBSD installer. The two earlier installments cover FreeBSD’s and OpenBSD’s installers.

On NetBSD, the SQLite Backup and Close methods used by renterd and hostd (Sia decentralized data storage) depend on CGO-specific features of the go-sqlite3 driver, which are not fully supported on this platform.
Attempts to substitute go-sqlite3 with CGO-free alternatives such as modernc.org/sqlite or ncruces/go-sqlite3 proved impractical due to required structural changes in the codebase, despite preliminary efforts.
Consequently, Backup and Close functionalities have been disabled in this howto to allow successful compilation and runtime on NetBSD 10.1.
Regular manual backups should be performed using standard SQLite commands, e.g., sqlite3 db.sqlite \".backup 'db.bkp'\".

Prerequisites

• Complete NetBSD version or without X11 (minimal version is insufficient due to missing header files).

Install necessary packages

pkgin update
pkgin -y install go124 git gcc14 tmux

Clone the repository

cd /tmp
git clone https://github.com/SiaFoundation/renterd.git
cd renterd

SQLite Installation (CGO)
go124 install github.com/mattn/go-sqlite3

Required modifications to the source code

• Disable the backupDB function in renterd:

Edit /tmp/renterd/stores/sql/sqlite/backup.go, replace the entire backupDB function (starting from line 36) :

func backupDB(ctx context.Context, src *dsql.DB, destPath string) (err error) {
        // create the destination database
        dest, err := dsql.Open("sqlite3", destPath)
        if err != nil {
                return fmt.Errorf("failed to open destination database: %w", err)
        }
        defer func() {
                // errors are ignored
                dest.Close()
                if err != nil {
                        // remove the destination file if an error occurred during backup
                        os.Remove(destPath)
                }
        }()

        // initialize the source conn
        sc, err := sqlConn(ctx, src)
        if err != nil {
                return fmt.Errorf("failed to create source connection: %w", err)
        }
        defer sc.Close()

        // initialize the destination conn
        dc, err := sqlConn(ctx, dest)
        if err != nil {
                return fmt.Errorf("failed to create destination connection: %w", err)
        }
        defer dc.Close()

        // start the backup
        // NOTE: 'main' referes to the schema of the database
        backup, err := dc.Backup("main", sc, "main")
        if err != nil {
                return fmt.Errorf("failed to create backup: %w", err)
        }
        // ensure the backup is closed
        defer func() {
                if err := backup.Finish(); err != nil {
                        panic(fmt.Errorf("failed to finish backup: %w", err))
                }
        }()

        for step := 1; ; step++ {
                select {
                case <-ctx.Done():
                        return ctx.Err()
                default:
                }

                if done, err := backup.Step(100); err != nil {
                        return fmt.Errorf("backup step %d failed: %w", step, err)
                } else if done {
                        break
                }
        }
        if _, err := dest.Exec("VACUUM"); err != nil {
                return fmt.Errorf("failed to vacuum destination database: %w", err)
        }
        return nil
}

with:

func backupDB(ctx context.Context, src *dsql.DB, destPath string) (err error) {
    // deactivation for NetBSD
    return nil
}

• Apply modifications to hostd:

Enable editing:
chmod +w /root/go/pkg/mod/go.sia.tech/hostd/[email protected]/persist/sqlite/store.go

Edit this file and replace the entire backupDB function :

func backupDB(ctx context.Context, src *sql.DB, destPath string) (err error) {
        // create the destination database
        dest, err := sql.Open("sqlite3", sqliteFilepath(destPath))
        if err != nil {
                return fmt.Errorf("failed to open destination database: %w", err)
        }
        defer func() {
                // errors are ignored
                dest.Close()
                if err != nil {
                        // remove the destination file if an error occurred during backup
                        os.Remove(destPath)
                }
        }()

        // initialize the source conn
        sc, err := sqlConn(ctx, src)
        if err != nil {
                return fmt.Errorf("failed to create source connection: %w", err)
        }
        defer sc.Close()

        // initialize the destination conn
        dc, err := sqlConn(ctx, dest)
        if err != nil {
                return fmt.Errorf("failed to create destination connection: %w", err)
        }
        defer dc.Close()

        // start the backup
        backup, err := dc.Backup("main", sc, "main")
        if err != nil {
                return fmt.Errorf("failed to create backup: %w", err)
        }
        // ensure the backup is closed
        defer func() {
                if err := backup.Finish(); err != nil {
                        panic(fmt.Errorf("failed to finish backup: %w", err))
                }
        }()

        for step := 1; ; step++ {
                select {
                case <-ctx.Done():
                        return ctx.Err()
                default:
                }

                if done, err := backup.Step(100); err != nil {
                        return fmt.Errorf("backup step %d failed: %w", step, err)
                } else if done {
                        break
                }
        }
        if _, err := dest.Exec("VACUUM"); err != nil {
                return fmt.Errorf("failed to vacuum destination database: %w", err)
        }
        return nil
}

with:

func backupDB(ctx context.Context, src *sql.DB, destPath string) (err error) {
    // deactivation for NetBSD
    return nil
}

Also, replace the line:
sqliteVersion, _, _ := sqlite3.Version()
with:
sqliteVersion := "deactivated"

Compilation

cd /tmp/renterd
export CGO_ENABLED=1
go124 mod tidy
go124 build -v ./...
cd cmd/renterd
go124 build

Binary installation

mkdir -p /opt/renterd/bin
mv /tmp/renterd/* /opt/renterd/
cp /opt/renterd/cmd/renterd/renterd /opt/renterd/bin/

Creating a dedicated secure user

groupadd renterd
useradd -g renterd -d /var/empty -s /sbin/nologin -c "renterd Daemon" renterd

Applying strict permissions

chown -R renterd:renterd /opt/renterd
chmod -R 750 /opt/renterd

Starting renterd with tmux (simple example)
tmux new -s renterd

usermod -s /bin/sh renterd
su renterd -c 'cd /opt/renterd && /opt/renterd/bin/renterd'

On first launch, initialize with the corresponding seed phrase and wallet address.

Detach the tmux session: Ctrl+b, then d

Remove the interactive shell from the user:
usermod -s /bin/false renterd

Off course, create a service and a /opt/renterd/renterd.yml configuration file.

In order to access the web console of renterd, just create an SSH tunnel (-L9980 127.0.0.1:9980) between your client and the server, and use your browser (http://127.0.0.1:9980)

Of course you can run Doom on a $10,000+ Apple server running IBM AIX. Of course you can. Well, you can now.

Now, let’s go ahead and get the grumbling out of the way. No, the ANS is not running Linux or NetBSD. No, this is not a backport of NCommander’s AIX Doom, because that runs on AIX 4.3. The Apple Network Server could run no version of AIX later than 4.1.5 and there are substantial technical differences. (As it happens, the very fact it won’t run on an ANS was what prompted me to embark on this port in the first place.) And no, this is not merely an exercise in flogging a geriatric compiler into building Doom Generic, though we’ll necessarily do that as part of the conversion. There’s no AIX sound driver for ANS audio, so this port is mute, but at the end we’ll have a Doom executable that runs well on the ANS console under CDE and has no other system prerequisites. We’ll even test it on one of IBM’s PowerPC AIX laptops as well. Because we should.

↫ Cameron Kaiser

Excellent reading, as always, from Cameron Kaiser.

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

We had presentations from:

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

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

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

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

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

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

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

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

This is happening on X11 under both cygwin and NetBSD.

Excerpt of xev(X11) output:

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

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

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

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

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

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

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

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

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

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

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

Clara and I bought an apartment last year, and it’s been fun—and exhausting!—setting it up with everything we want. Our plan is to eventually get Ethernet wired up to each room, but in the interim our hobby room is a sufficient distance from the router that using cable isn’t feasible. This is a pain, because my retrocomputers don’t have Wi-Fi; and even if they did, they probably wouldn’t support the latest security protocols.

Then I remembered we had a few dusty Raspberry Pis in a box, a Wi-Fi dongle, and a Fast Ethernet hub. Yes, a hub! None of this would be fast, or even tolerable in a modern setting, but I figured it’d be more than sufficient as a temporary hack for these ancient machines.

The Raspberry Pi Model A+ was a no-go, because its lone USB port would need its own powered hub for the Wi-Fi module and Ethernet, and my serial-to-pi console cable is in another box I couldn’t find. But the first-gen Rasberry Pi from 2011 has two USB ports and Ethernet.

I downloaded the latest NetBSD earmv6hf image, and followed the NetBSD Guide to configure wireless and create a bridge. I was going to write a guide here, but everything described just… worked. I have a wireless bridge in this room, which lets these old machines access our network in the other room. And it was cobbled together from stuff we already had.

NetBSD! One day it’ll surprise me when I can’t use it for a random little project. Not today.

I feel like I should have a separate page on the Retro Corner specifically about how to interface old machines with the modern world. Well okay, FTP and gopher aren’t exactly modern world. But they’re hosted in FreeBSD jails, which are.

By Ruben Schade in Sydney, 2025-05-25.

Dumbness or perhaps stupidity, today’s mini theme.

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

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

For those too young to remember, or who wisely chose to forget, Windows Millennium Edition—aka, Windows Me—was notorious. Microsoft removed Real Mode DOS access which peterbed weirdos like me who loved rebooting into MS-DOS to play NFS:SE, but history will remember Windows Me for its instability and performance issues. It was available on the market for about a year in 2000 before Windows XP was released, and few people were sad to see it go… perhaps other than the technicians for whom the OS gave them a guaranteed and regular source of clients.

I had one factory-installed Windows Me machine as a kid, a Sony VAIO PCG-C1VM laptop. This I quickly “upgraded” (cough) to Windows 98 Second Edition like most people, and upon realising how easy it was, made a small fortune for a kid by offering to do it for friends and their parents. Windows 98 was an error-filled mess, but it was still a breath of fresh air compared to Windows Me. Then when Windows XP came out, I jumped to 2000 and lived with the performance drop so I didn’t have to deal with crashes.

But this is where the weirdness starts. I may have inadvertently stumbled upon a specific combination of parts and drivers that result in a stable Windows Me system; one that works faster, and more reliably than Windows 98. HOW!?

Like most of my retrocomputers, I bought this Dell Dimension 4100 on a lark for a bit of nostalgia. I never had one of these beige towers as a kid, but it seemed as though everyone in Singapore did around the late 1990s and early 2000s. My school upgraded all their disparate DIY Pentium 1 machines cobbled together at the likes of Sim Lim Square and Funan Centre for a fleet of these towers, and they imprinted. I saw someone in Canberra selling one for less than $100 in immaculate physical condition, and the rest is history.

My intention was to make it a glorified display piece on our study Museum Shelf of Doom, but when it arrived I was shocked to discover it was the most capable retro PC I own. It sports an absolutely blazing 800 MHz Pentium !!! CPU, 128 MiB of PC-133 memory, and… a dreadful proprietary ATI Rage 128 card which I quickly swapped out for a cheap and cheerful 4× AGP Radeon 9600 XT. This is now my primary Win 9x game machine for the likes of Train Simulator, Flight Simulator 98, Age of Empires II, Golf 95 (shaddup), The Sims, SimCity 3000 Unlimited, and my old Borland IDEs.

Okay, so what does this have to do with Windows Me? Well those of you who’ve tinkered with PCs of this vintage know that SATA was either in its infancy, or not available at all. I’ve had the most success with Transcend IDE SSDs with the internal ATAPI controller, or by using industrial CF Cards. The challenge though has been getting the host machine and OS to detect UDMA support and use it, or your performance will almost make you long for the days of you 7200 RPM hard drive. Hope it’s not a Deathstar.

Windows 98 SE on this machine, despite being the factory standard OS at the time, simply doesn’t like this SSD. It takes forever to boot, copy files, and crashes upon shutdown, no matter how many times I’ve reinstalled it. The authentic Windows experience, in other words! This despite the fact UDMA is shown in Control Panel, and in the BIOS POST screens when the machine starts. The same configuration works on my other old PCs without issues, so I assume its a weird combination of stuff on this specific tower.

I thought I’d try Windows Me for a bit of a joke, but it’s had the last laugh. It’s been one of the two bootable OSs on this machine for more than a year now (I always dual-boot retro computers with NetBSD, partly for fun, but also so I can use it to copy files and so on), and it’s only crashed a handful of times. It boots quickly, all the hardware was detected and installed the first time, games run absolutely flawlessly, and I can even run Netscape Communicator to launch my Retro Corner.

I’m… kinda speechless to be honest. I guess Windows Me was testy about what it ran on, and I’ve somehow stumbled upon the perfect mix of parts to make it work, entirely by accident.

Would I recommend running Windows Me for your retrocomputing adventures? I mean, if Windows 98 SE is performing crap with your IDE SSD, maybe give it a try!? But, is a word with three letters.

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

We’re looking at an article from 2007 here, but I still think it’s valuable and interesting, especially from a historical perspective.

I first started working on the UNIX file system with Bill Joy in the late 1970s. I wrote the Fast File System, now called UFS, in the early 1980s. In this article, I have written a survey of the work that I and others have done to improve the BSD file systems. Much of this research has been incorporated into other file systems.

↫ Marshall Kirk McKusic

Variants of UFS are still the default file system in at least NetBSD and OpenBSD, and it’s one of the two default options in FreeBSD (alongside ZFS). In other words, this article, and the work described therein, is still relevant to this very day.

We are happy to announce that The NetBSD Foundation will participate in Google Summer of Code 2025 with 3 projects!

Here the list of the projects and contributors:

• Enhancing Support for NAT64 Protocol Translation in NetBSD - Dennis O.I
• Asynchronous I/O Framework - Ethan Miller
• Using bubblewrap to add sandboxing to NetBSD - Vasyl Lanko

For the next 3 weeks mentors and contributors will get in touch for the community bonding period. Mentors will help contributors to get started with the project, introduce them to the community and get more familiar with the codebase and adjusting deliverables for the the project.

Welcome Dennis, Ethan and Vasyl!

Some BSD-specific links mixed in.

• Future of Arts, Culture & Technology Symposium videos.  Scroll right.  (via)
• What The Internet Did To Garfield, a video.  (via, via)
• RDAP is replacing WHOIS.  (via)
• The Flywheel Spin Top.
• Netnews: The Origin Story.  USENET, or nntp, if you prefer.  (PDF, via)
• The NetBSD General Meeting is coming up on the 17th.
• A 55-year example of Moore’s Law.
• Hacker Laws.  (via)
• TRMNL, which I might have linked to before, but two different people have told me they got it and love it recently.
• diff-jfk, a use I didn’t expect for diff.  (Thanks, Paul)
• NumFOCUS concerns.  “Linux Foundation: Voltron of Bureaucracy” is a funny section title.  (also thanks, Paul)
• The History of Solaris.  “UNIX is plural.”  (PDF, via)
• The modern OpenBSD home router.  (via)
• tinypod, turning an Apple Watch into an iPod.  (via)

Your unrelated music video of the week: DRASS – Nucleation Point.  Makes me think I need to start making my phone less useful.  (via)

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

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

Prerequisites

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

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

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

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

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

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

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

These packages were already installed:

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

I’ve added these:

• openjdk21
• execline

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

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

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

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

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

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

Step by step: Supervising Minecraft service

1. Create dedicated Unix user with its own process supervisor

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

2. Globally, map hostname to IP

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

3. Locally, map port number to service name

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

4. Allow incoming connections

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

5. Download software

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

6. Accept EULA

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

7. Create control socket

mkfifo -m 0600 data/control

8. Symlink service logs where I usually look

ln -s data/logs logs

9. Create run script

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

10. Enable service

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

11. Send initial configuration

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

Be notified of updates

As the minecraft user:

1. Create service and run script

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

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

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

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

set -e
set -x

exec 2>&1

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

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

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

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

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

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

2. Enable service

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

Further improvements

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

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

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

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

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

On Linux, this command

fstrim -av

I will remove all unused blocks (particularly interesting on VM disks and necessary on SSD to preserve/get a longer duration). NetBSD has a similar command called blkdiscard

This command wipes the entire disk, so it becomes unusable (correct me if I am wrong)

blkdiscard -v /dev/rwd...

I see there is a flag which starts to discard after some bytes (or MB)

blkdiscard -v -f 256m -m 128m /dev/rwd0c

Suppose my partition uses 6GB of data, to make a safe discard (my data still remains), is this the correct command?

blkdiscard -v -f 6000m -m 128m /dev/rwd0c

Done early!

• Other Networks: A Radical Technology Sourcebook.  For pre-order, and excerpts are available.  I think this is a unique book; catch the limited print while you can.  (via)
• Vim Spellcheck Cheat Sheet.
• NetBSD on Raspberry Pi!
• State of virtualizing the BSDs on Apple Silicon.
• From ACS to Altair: The Rise of the Hobby Computer.
• Walter Bright’s Classic Empire, Empire Deluxe, and original author Walter Bright.  (incidentally, original available as a port/pkg/port)
• Standalone Digital Scratch Instrument.
• Debugging aids for pf firewall rules [on FreeBSD].  For reference.
• Free MWL excerpts/books.  (via)
• If you’re going to GDC, there’s a Roguelike Celebration meetup on the 18th.
• UNIX advertisements.  (via)  From that page:

For decades, Linux and BSD have stood as two dominant yet fundamentally different branches of the Unix-like operating system world. While Linux distributions, such as Debian, Ubuntu, and Fedora, have grown to dominate the open-source ecosystem, BSD-based systems like FreeBSD, OpenBSD, and NetBSD have remained the preferred choice for those seeking security, performance, and licensing flexibility. But what if you could combine the best of both worlds—Debian’s vast package ecosystem with FreeBSD’s robust and efficient kernel?

Enter Debian GNU/kFreeBSD, a unique experiment that merges Debian’s familiar userland with the FreeBSD kernel, offering a hybrid system that takes advantage of FreeBSD’s technical prowess while maintaining the ease of use associated with Debian. This article dives into the world of Debian GNU/kFreeBSD, exploring its architecture, installation, benefits, challenges, and real-world applications.

↫ George Whittaker

More of a list of upsides and downsides than an actual in-depth article, but that doesn’t make it any less interesting. There’s a variety of attempts out there to somehow marry the Linux and BSD worlds, and each of them takes a unique approach. I’m not sure the Debian userland with a FreeBSD kernel is the way to go, though, and it seems I’m not alone – Debian GNU/kFreeBSD was officially dropped from Debian in 2015 or so, and after a flurry of unofficial activity in 2019, it was discontinued completely in 2023 due to a lack of activity and developer interest. Odd that the source article doesn’t mention that.

If you’re still interested in a combination of Linux and BSD, I’d keep an eye on Chimera Linux instead. It’s very actively developed, focuses on portable code by supporting many architectures, and its developers are veterans in this space. I have my eye on Chimera Linux as my future distribution of choice.

I stopped developing pkgsrc with CVS.

Quick bit of background: NetBSD is still using CVS as its version control system. The decision to move to something else has been taken long ago, but the switch has not happened as of today.

Working with CVS is painful for many reasons. For instance, there is no way to see your local changes without waiting several minutes for a cvs up -n. A full tree update (cvs up) churns for quite a while before it even starts updating any files.

Back when Java was still a new programming language, Sun had the idea of building a computer specifically designed for Java, unique processor running byte-code as its native machine code and all. This whole endeavour proved to be more complicated than Sun had hoped, and as such, they eventually abandoned the idea of a Java processor in favour of plain SPARC. When the JavaStation shipped, it was a regular SPARC workstation without a hard drive, running something called JavaOS from flash memory.

Since JavaOS is, of course, long gone, what can you do with JavaStation today? Well, you apparently can run NetBSD on it, but it’s quite an ordeal. The JavaStation needs to boot from the network using a combination of RARP, NFS, and more, and surprisingly, this entire setup, including the computer acting as the ‘server’ for the JavaStation, is well-documented and supported by NetBSD. Once you’ve gone through all the steps, you’ll end up with a JavaStation running the latest release of NetBSD, which is pretty cool.

Obviously there is still a lot to do; as you can see postfix isn’t happy, and the swapfile security needs tightening up for a start. But we do now have a functional NetBSD system running on a vintage network computer!

↫ Old Fart’s Almanac

NetBSD’s continued support for the most arcane of hardware will never cease to amaze me.

We are happy to announce that The NetBSD Foundation will participate in Google Summer of Code 2025!

Would you like to contribute to NetBSD and/or pkgsrc in the next months? Google Summer of Code is a great chance for that!

You can find a list of possible projects at Google Summer of Code project page. Of course, you can also propose your own!

Please reach us via #netbsd-code IRC channel on Libera.Chat and/or via mailing lists.

If you are more interested about Google Summer of Code please also check official homepage at g.co/gsoc.

Looking forward to a great Summer!

As you might be aware of, I am working on a minimal BSD/UNIX system called smolBSD. It is based on the NetBSD operating system, and its main target is virtual machines, more specifically microvms. This system is capable of fully booting the OS in less than one second using a specially trimmed kernel along with small, specialized root systems.
I was stunned to learn (but am I wrong?) that this work does not seem to have an equivalent, not even in the Linux world. FreeBSD Firecracker support sure permits to boot a kernel is about the same time my NetBSD hacked kernel does, but there’s no work around s slim and task dedicated root filesystem.

Quirky, just like I want it.

• Why is editing PDFs so prevalent?
• A Suitably Bizarre Start of the Year 2025.
• Naming Quarters.  I think fortnights and sennights are underutilized timeframes, incidentally.
• pkgsrc-2024Q4 is out.
• Tellico, collection management software.  (via)
• Some of the original BeOS icons reimagined in Blender.  (via)
• Cray 1 Supercomputer Performance Comparisons With Home Computers Phones and Tablets. (via)
• The next leap second is at least a year away.
• Copyright-free images.  A vast amount of images available.

Your unrelated music link of the week: Where to Start With Tempa, The Label That Invented Dubstep.

Make, as arcane as a build tool can be, may still be a good first fit for certain scenarios. “Heresy!”, you say, as you hear a so-called “Bazel expert” utter these words.

The specific problem I’m facing is that I need to glue together the NetBSD build system, a quilt patch set, EndBASIC’s Cargo-based Rust build, and a couple of QEMU invocations to produce a Frankenstein disk image for a Raspberry Pi. And the thing is: Make allows doing this sort of stitching with relative ease. Sure, Make is not the best option because the overall build performance is “meh” and because incremental builds are almost-impossible to get right… but adopting Bazel for this project would be an almost-infinite time sink.

Anyway. When using Make in this manner, you often end up with what’s essentially a “command dispatcher” and, over time, the number of commands grows and it’s hard to make sense of which one to use for what. Sure, you can write a README.md with instructions, but I guarantee you that the text will get out of sync faster than you can read this article. There is a better way, though.

This report was written by Diviyam Pat as part of Google Summer of Code 2024.

This summer I worked on NetBSD's kernel test framework to cover root device discovery and root file system selection. This area of the kernel is not very well documented and program flow has to be determined by reading the code.

I would also like to tell you about my early interactions with the project, let me start with project findings.

Why NetBSD?

Google Summer of Code 2024 is not my first time applying to GSoC. My first time was in 2022, in my first year of college. I have been fascinated with newer Windows versions since my Intel Core Duo i3 days as every new Windows version used to bring new changes and features, from Windows XP to Vista to 8.1 and then to 10 (cosmetic only) but was very heavy on my PC's memory usage that was upwards of 60% leaving very little room for applications and games.

My Intel i3 would be enough for it. This experience made me decide I wanted my project to be in the operating system space. I ventured into all OS projects on the Google Summer of Code website. Gentoo, Debian but that didn't turn out well. I then decided to explore BSDs. The community seemed friendlier, more responsive, and active in helping beginners. I started mailing all the mentors about my interests (I realized I should have done a lot more work before mailing them, it shows more dedication towards the project.)

Christoph explained the project in great detail to me, helped me with getting started and guided me through the hard parts of the project.

Project Details

Root device and file-system selection is made during the later stages of the boot process by the kernel. The kernel config file defines candidates for the root device and the kernel selects one after validating those options. If no options are defined, the auto config subroutines handle configuration. Head over to my docs for more details here. This functionality is handled primarily by the function setroot in file kern_subr.c. It also calls specialized functions for a number of cases. Our task was to add ATF tests for this function and some other functions that assist setroot. This part of the kernel works, and it has worked for over 30 years but the code is rather complex to read and there is no documentation. The only way to understand it is to read the code.

At any given stage when any condition fails the fallback option is to ask the user manually for the device. Thus this part of the kernel rarely needs attention. There are some global functions used in conditions inside setroot: rootspec, bootspec, etc. These variables are either set through the config file or through other machine-dependent kernel functions like findroot etc. We need to manually set them in our test cases and also need to stub kernel functions used by setroot and other functions. We wanted to make these test cases use 'vnd' devices, but we ran into bugs, and Christoph was trying to fix them. Therefore we had to resort to stubbing. We validate the global variables. We also test the tftproot_dhcpboot function that loads the contents of a memory disk device from a TFTP server and uses that as root device. Devices are represented by the device_t struct which is populated by the kernel. We mock this behavior through the create_device function and use this in the test programs. User input is handled by stubbing the cngetsn function. Global variables and arguments are set to test values in the body of the test cases and the function being tested is called. The test file is divided into 3 parts: 1) setroot_root, 2) setroot_ask, and 3) tftproot_dhcp. In the file kern_subr.c setroot() calls these functions but here we test them independently

Conclusion

I have worked on enhancing NetBSD's ATF tests to test the root device and file system selection process, testing the setroot function and its dependencies. These tests shall improve coverage of the ATF tests to the setroot function and in general, to root device selection. In the future, contributors can rely on these tests for kern_subr.c's functionality.

I am C++ developer and unfamiliar with script technologies like nodejs etc. I tried to build VS Codium on NetBSD 10.0 from sources 1.96.2 on github, by how-to manual. After running build/build.sh it outputs:

...
+++ ../update_settings.sh
300s/'default': true/'default': false/
sed: -E: No such file or directory
219s/'default': TelemetryConfiguration.ON/'default': TelemetryConfiguration.OFF/
sed: -E: No such file or directory
114s/'default': true/'default': false/
sed: -E: No such file or directory
#

When I look into target directory vscode I am seeing there something like result: vscode/cli/src/bin/code/main.rs How to continue with build to reach binary executable "bin/codium" ? What to do with that main.rs ? I read that it has something with rust ? Can anyone put more light on this to understand what to do ? I don't need to create installation package, it should be sufficient to run VSCodium from target build directory.

I recently picked up an embedded project in which I needed to build a highly customized full system image with minimal boot times. As I explored my options, I came to the conclusion that NetBSD, the often-forgotten BSD variant, was the best viable choice for my project.

One reason for this choice is NetBSD’s build system. Once you look and get past the fact that it feels frozen in time since 2002, you realize it is still one of the most advanced build systems you can find for an OS. And it shows: the NetBSD build system allows you to build the full OS from scratch, on pretty much any host POSIX platform, while targeting any hardware architecture supported by NetBSD. All without root privileges.

Another reason for this choice is that NetBSD was my daily workhorse for many years and I’m quite familiar with its internals, which is useful knowledge to quickly achieve the goals I have in mind. In fact, I was a NetBSD Developer with capital D: I had commit access to the project from about 2002 through 2012 or so, and I have just revived my account in service of this project. jmmv@ is back!

So, strap onto your seats and let’s see how today’s NetBSD build system looks like and what makes it special. I’ll add my own critique at the end, because it ain’t perfect, but overall it continues to deliver on its design goals set in the late 1990s.

The NetBSD project is pleased to announce the first update of the NetBSD 10 release branch NetBSD 10.1! See the release announcement for details.

This release includes 9 months of bug fixes and a few new features after the 10.0 release in March. It also gives those still using older release a good reason to finally update to the NetBSD 10 release branch, even if they avoid dot-zero releases by all means.

If you want to try NetBSD 10.1 please check the installation notes for your architecture and download the preferred install image from the CDN or if you are using an ARM based device from the netbsd-10 builds from the bootable ARM images page.

If you have any issues with installation or run into issues with the system during use, please contact us on one of the mailing lists or file a problem report.