In what is quite a major achievement, Wine has been ported and made to work on OpenBSD.

We have since tested several dozens of 64-bit Windows software, mostly successfully. See screenshots, livestream recordings for example. Even the Remaster of The Witcher 3 which released just last month runs, and runs well (requires adding in vkd3d-proton; see README; livestream which looks less fluent than it is due to the on-system recording with ffmpeg).

↫ Thomas Frohwein

The biggest limitation seems to be the lack of support for WoW64, so 32bit Windows software won’t work. Still, this is a massive milestone for OpenBSD, and makes especially gaming a somewhat viable option on OpenBSD.

What if a regular, normal NetBSD installation is too plebeian for you?

This is a quick overview which attempts to synthesize DW Armstrong’s tutorial on NetBSD encryption with the cgdroot page from the NetBSD wiki in a single MBR partition, divided into multiple disklabel slices to preserve MBR entries.

↫ indigoparadox Web Zone

What if you need this?

The Good Enough File System, originally developed for 9front, is being ported to OpenBSD.

For those who haven’t watched my talk, GEFS is a new, crash-safe, snapshotting, copy on write FS that I wrote for 9front, and which I am in the process of moving to OpenBSD. The file system is described in full here.

↫ Ori Bernstein

One of OpenBSD’s shortcomings is its rather archaic filesystem, so any work on something more modern and especially more performant is quite welcome. While any process of replacing FFS is going to be a long one, even having GEFS as an option could be a great addition to OpenBSD.

The BSD news will continue until morale improves. I missed this two months ago, but Baptiste Daroussin, creator of pkg and poudriere, is working on a service manager for FreeBSD called rcd.

rcd(8) is a service manager daemon called by init(8) (in place of /etc/rc). It reads service definitions from UCL unit files (/etc/rcd.d/*.ucl), builds a dependency DAG, and starts services in parallel. After boot completes, it forks to background and stays running as a supervision daemon (automatically restarting failed services and accepting control commands via a UNIX socket).

↫ Baptiste Daroussin

It’s fully backwards compatible, and works on any existing FreeBSD system without having to make any modifications to rc.d scripts or configuration files. In fact, you can install it on a running system, make zero changes to your files, and reboot to use it, which is quite impressive. The most immediate benefit is, of course, faster boot times, but you’ll also get several other benefits already found on similar systems like Solaris’ smf.

There’s a migration path in place, with a hard promise to maintain compatibility with rc.d scripts for as long as needed. This gives maintainers as much time as they need to convert to rcd‘s own unit files.

Yesterday we had the final maintenance release for the NetBSD 9.x series, and today we have FreeBSD 14.5 entering the scene.

Since this release is occurring late in a legacy stable branch, there are few new features; rather, the focus is primarily on maintenance. As such, changes since 14.4-RELEASE consist mostly of bug fixes, driver updates, and new versions of externally-maintained software.

↫ FreeBSD 14.5 release announcement

The adventurous among us are already on the 15.x branch, but those of us running mission-critical systems are most likely still rocking 14.x, and for you, this is a must.

Speaking of NetBSD, the fifth and final 9x release has been released.

It represents a selected subset of fixes deemed important for security or stability reasons since the release of NetBSD 9.4 in April 2024. It is fully compatible with NetBSD 9.0.

This also marks the end-of-support for all NetBSD-9.x releases and the netbsd-9 branch. All users still on this branch are urgently asked to update to a more recent release like NetBSD 11.0 (with 11.1 upcoming at the end of this month) or NetBSD 10.2 (to be released in a few days).

↫ Martin Husemann at the NetBSD blog

The full release notes have more information.

Why use an installer to install an operating system, when you can just do it yourself, step by step?

In this post I will cover the installation process of the NetBSD operating system, including disk level encryption. Instead of using the standard installation program (sysinst), I decided to install NetBSD “from scratch”, as a way to dive into the internals, and learn more about the nuts and bolts of this great operating system.

↫ Luis Falcon

A fun weekend project for next weekend.

Enlightenment desktop is a low on resources desktop environment without sacrificing on visuals. NetBSD support for this BSD-licensed desktop has been left a few years behind. The aim of this project is to port the newest version of the desktop to pkgsrc and commit upstream portability fixes when necessary to ease future versions updates for NetBSD.

↫ Dimitris Gounaridis on the NetBSD blog

Enlightenment seems like a natural fit for NetBSD, so I’m glad they dedicated a GSoC project to getting the existing, outdated port up to snuff. The project is not complete as there’s a few issues to work out before it can be packaged for easy installation, but this is great progress already.

NetBSD, the operating system specifically designed to run on anything from a supercomputer to a toothpick, just released version 11.0. There’s a ton of changes and improvements here, such as a brand new port to RISC-V, which supports a number of the more popular RISC-V SoCs (sadly, not the one I have just yet). NetBSD 11.0 also adds initial support for the Qualcomm Snapdragon X Elite platform, as well as a port to the virt68k platform, which means the Motorola 68000 port in QEMU using paravirtualized devices.

Speaking of virtualisation, they’re also introducing a new MICROVM kernel for x86:

New MICROVM kernel for x86, supporting both i386 and amd64, NetBSD 11.0 introduces a dedicated MICROVM kernel designed for extremely fast virtual machine boot, leveraging PVH boot, VirtIO MMIO, and multiple kernel optimizations, it can boot in about 10 ms on 2020-era x86 CPUs.

↫ NetBSD 11.0 release notes

There’s also improved support for Linux system calls in compat_linux, the npf firewall, and much more. Of course, the list of other improvements, buigfixes, and smaller changes is long, including many changes for old, outdated, or otherwise odd architectures and platforms, as is the NetBSD way. Which other operating system proudly lists substantial improvements to their PA-RISC, Motorola 68000, and Alpha ports, among others?

Speaking of OpenBSD:

Yes, you read that right. Modern development tools in the form of the LLVM compiler infrastructure is well on its way to supporting OpenBSD/sparc64 along with other more conventional architectures.

The support is now ready for testing, via a patch set presented by Kirill A. Korinsky in a message to the tech@ mailing list, with the subject LLVM toolchain for sparc64.

↫ Peter N. M. Hansteen

On a related note, the the entire LLVM stack (version 19.1.7, including llvm’s binutils, clang, ldd) has also been ported to the SPARC version of Solaris 11 Express (snv_151a). This should make it possible to also port things like Rust and Zig to this same version of Solaris on SPARC, which is good news, because this release supports SPARC hardware long dropped by the current Solaris builds from Oracle.

As I mentioned in my OpenBSD 7.8 highlights post, development of relayd(8) and httpd(8) had stalled. Many diffs appeared on the tech@ mailing list from different contributors, but few were committed into the repository. The main reason was simple: Established OpenBSD developers weren’t interested in these daemons anymore. Call it momentum, or timing.

Around the same time, kirill@ and I started working on these daemons more actively. We both use them regularly and have real-world use cases. I support customers with OpenBSD setups that often involve complex httpd(8) and relayd(8) configurations. This practical need motivated me on many levels.

↫ Rafael Sadowski

They’ve managed to do a ton of work on these two daemons, fixing many long-standing issues and reviewing tons of stalled patch submissions, while also modernising the code and adding new features. It’s great to see people contribute significant time and energy to fixing up the tools they use for everyone else’s benefit.

A rather unusual announcement was made late last night: the FreeBSD project has frozen their ports repository. For more than 48 hours now, no changes have been accepted or made to the tree, and here’s why.

A 150MB binary file was recently committed to the ports tree and, as a result, core@ made the decision to implement a temporary freeze of the ports tree in order to implement some clean up efforts. The commit in question severed our ports tree mirroring to github.com due to their filesize hard limit of 100MB, and introduced a blob of questionable licensing into the repository history.

↫ Kyle Evans in freebsd-announce

While FreeBSD’s ports tree is not hosted by GitHub – it’s merely mirrored there – the FreeBSD team believes the community values the GitHub mirror too much, and as such, steps had to be taken to fix this. Ports has not been compromised and users’ systems do not appear to be at risk in any way due to this occurrence, which is good news.

Curiously, the official announcement makes no mention of which 150MB file, exactly, was committed to ports, but it didn’t take for people long to pinpoint the offending commit (screenshot). It turns out someone committed the entire github-copilot-cli Linux binary to ports, as part of the github-copilot-cli port. This FreeBSD port is effectively a way to easily install and run this tool on FreeBSD using Linuxulator, FreeBSD’s Linux compatibility layer that allows you to run unmodified Linux binaries on FreeBSD.

It’s important to note this FreeBSD port is not actually a port of the Linux version of github-copilot-cli to FreeBSD; the FreeBSD “port” merely acts as a setup script to run the unmodified Linux binary using Linuxulator. It’s not a “real” port because the tool isn’t open source and its license doesn’t allow for modifications. That’s why the announcement specifically mentions “questionable licensing” – github-copilot-cli is licensed under some custom license specifically made for this tool, and is not open source.

Anyway, for whatever reason, the maintainer of this FreeBSD port accidentally made a commit that added the actual, full 150MB Linux binary to FreeBSD ports. I’m assuming that under normal circumstances, building and installing the github-copilot-cli FreeBSD port would merely download the binary off GitHub and set Linuxulator up so that it could run it. Mistakes happen, and since there’s clearly nothing malicious going on, there’s not much to worry about. In fact, this may lead to new checks and balances to prevent this from happening in the future, which would be good news.

The FreeBSD team is working on rolling back, fixing the issue, and investigating how this could have happened. Ports is still frozen at the time of writing, but I’m sure we’ll have a more detailed account soon.

The NLnet Foundation’s NGI0 Commons Fund supported an effort to add WPA3 support to OpenBSD, and the work’s payed off.

All drivers which support PMF can use WPA3, which are: iwm, iwx, and qwx. So far, I have tested this patch on iwx AX200 only. I will roll out this patch to more of my devices now. Help with testing is welcome.

There are both userland and kernel changes involved.

↫ Stefan Sperling

Only the second implementation of WPA3 will be supported, which requires some explanation:

WPA3 has a complicated history. There are two versions of WPA3. The initially standardized version suffered from side-channel leaks found by Mathy Vanhoef and dubbed “Dragonblood“. A revised and fixed version has been standardized and is mandatory in the 6 GHz band as of Wifi 6e (11ax) and mandatory on all bands as of Wifi 7 (11be).

↫ Stefan Sperling

Obviously, WPA3 is a very welcome addition to OpenBSD.

OpenBSD parts ways with an architecture: OpenBSD will no longer be developed for loongson. The reasons are exactly what you’d expect.

The last compiler update unfortunately does not work on mips64el, with clang 22 built with clang 19 being apparently functional, but clang 22 rebuilt with the previous clang 22 hitting deterministic SIGSEGV on various files.

I don’t have the time and energy to try and debug this (which is likely an endianness problem, as octeon appears to run happily with clang 22), especially when it takes 10 days for clang to rebuild itself on these machines; and switching back to gcc 4 won’t help much as modern software in ports will require a working C++>=11 compiler to build anyway.

↫ Miod Vallat

If I got my facts right, this does not affect the newer LoongArch, which is an entirely different architecture that isn’t supported by OpenBSD at all. Similarly, the other MIPS-based architecture OpenBSD supports, Octeon, remains supported and thus isn’t affected either.