OpenBSD 8.0 brings bigger virtual machines, graphics improvements, and another helping of AI mockery. The round version number doesn't signal a radical break with its predecessors. OpenBSD 8.0 is the 61st release of the project. Developer Bryan Steele posted a highlights rundown on Mastodon. Wireless improvements include updates to the qwx driver for Qualcomm Wi-Fi 6 hardware. Its VMM/VMD hypervisor now supports multiprocessor VMs with up to 64 virtual CPUs in each guest. The kernel virtual memory address space on x86-64 is now 512 GB, up from 4 GB, allowing for GPUs with large amounts of VRAM. On Arm64 machines, OpenBSD supports hibernation, and on both x86-64 and Arm64 it can use CPU AES instructions for faster encrypted swap. Component upgrades include OpenSSH 10.6 and LibreSSL 4.4.0, and the DRM graphics driver stack from Linux 6.18. The default C compiler is Clang/LLVM 22, including for the SPARC64 edition – but at the cost of dropping support for the Loongson architecture. The list of errata is short, with just four fixes – but then, version 8.0 is very new. Just days before this release, there was a high-profile OpenBSD issue: Calif's "Big Fish" research describes a decades-old shared-memory bug chained with a separate kernel flaw to gain local root access. Both were fixed in OpenBSD 7.9, through errata 026 and 018 respectively. Project leader Theo de Raadt forked OpenBSD from NetBSD 1.0 in 1995, and the first release of the new OS was OpenBSD 1.2 in July 1996 – so version 8.0 is as close as the project will get to a 30th anniversary release. According to Calif's proof-of-concept code on GitHub, the bug was in the original code that both OpenBSD and NetBSD inherited from the original BSD codebase – which is how come there's a 37-year-old bug in a 30-year-old project. A HackerNews comment says: "Interestingly, looks like this was accidentally fixed in NetBSD during a rewrite of that code in August of 1999." The project has not updated its infamous slogan. The homepage still proclaims: "Only two remote holes in the default install, in a heck of a long time!" As we noted in May when OpenBSD 7.9 appeared, the project rejects code generated by LLMs, although on the basis of licensing concerns rather than its cousin NetBSD's explicit anti-AI stance. As we reported recently, this strict anti-AI stance seems to be serving NetBSD well. OpenBSD is also an anti-AI project, and for this release, the website goes out of its way to make that very clear. OpenBSD's mascot is a pufferfish, and in the banner artwork for the new release, "Puffy" has an extra eye – and the signpost in the image's background also has malformed text, a hallmark of early image-generation bots. The eyes are also constantly blinking – one at a time – to emphasize that this is a reference to Blinky the mutant fish from The Simpsons. In case you missed The Simpsons reference, the version 8.0 release theme song makes it even more explicit: it's titled "The Simps on AI." The lyrics and the vocals parody both Simpsons characters and AI users. Our favorite line sounds like Grampa Simpson, and says: Back in my day we didn't have artificial intelligence, we had real stupidity – and we liked it. We've seen negative reactions online, but then we often find that some people lack much of a sense of humor. For our part, we really enjoyed seeing the OpenBSD team having such fun. We reckon it will appeal to many Butlerian Jihadi types. It certainly did to The Reg FOSS desk. A little Wine with your pufferfish A couple of days before the 8.0 release came an unexpected announcement on the openbsd-ports mailing list: a proposed port of Wine for OpenBSD. This is a new version of the Wine 11 runtime that allows Windows binaries to launch and run on OpenBSD. This is a 64-bit version of Wine for OpenBSD on x86-64, and for now, this means it can only run 64-bit Windows code. (For the technical nitty-gritty: Wine needs to manipulate the CPU's GS register. Windows on x86-64 uses the GS segment base to locate the Thread Environment Block (TEB), as the late great Geoff Chappell explained. This is a very longstanding Windows data structure, going all the way back through Windows 95 to OS/2. The port was particularly tricky because OpenBSD doesn't allow programs to alter that, so the port is emulating instructions that use the %gs segment override. The snags are that this means 32-bit code doesn't work, and secondly, because this is unnecessary on Linux, the code is unlikely to be merged back into upstream Wine.) If you want to see it working, there are a few screenshot galleries on Reddit's openbsd_gaming group, showing a number of recent major titles running: Some samples from WIP wine port, more wine-on-OpenBSD screenshots, and even more wine-on-OpenBSD proof. The port comes hedged with caveats, notable among them that Wine does not do any kind of sandboxing, so using it potentially opens up OpenBSD to Windows malware. However, for some users, this could be a very useful addition. OpenBSD is the simplest and cleanest member of the BSD family, indeed, of the FOSS Unix family. Part of this is because entire subsystems are missing that the other BSDs provide. Bluetooth connections to Apple's wireless keyboards and pointing devices aren't supported. There's no logical volume management – which would massively help with OpenBSD's complex disk partitioning. There's no journaling filesystem either (although a port of the new Gefs is in progress). While small and clean, its priorities favor security and simplicity, though performance will depend on the hardware and workload. Importantly – since you probably will need to ask for help – the OpenBSD community does not have a reputation for friendliness. Saying that, it is quite a lot easier to get OpenBSD installed and running, complete with its 25-year-old version 2.2.5 of the Fvwm window manager, than either NetBSD or FreeBSD. If you're looking for an AI-free, and indeed systemd-free, path away from Linux, OpenBSD 8.0 is very definitely worth a try. ®

Surprisingly few organizations were promoting Linux distros at Open Source Summit Europe. The only dedicated stands we found belonged to two Chinese projects, with openEuler occupying the larger booth. For users accustomed to Western enterprise distros, openEuler may be a less familiar name, but it has an impressive history. It's the modern free community version of Huawei's EulerOS, a version of which achieved official official UNIX™ certification. openEuler is no longer a solely Huawei project, though. Since then, it's been opened up, and it is now run by the OpenAtom Foundation. OpenAtom was co-founded in 2020 by Huawei along with some other big Chinese names, such as Alibaba, Baidu, and Tencent. Another of the co-founders was Inspur, which formerly developed its own distro, K/UX – a version of which also achieved official UNIX™ certification. Inspur K/UX won Unix certification in February 2016, and EulerOS seven months later. K/UX's Unix certification expired in 2019. A few months later, in May 2019, the US placed wider sanctions on Huawei. It is possible that the fresh restrictions on American sales prompted Huawei's interest in closer co-operation with other companies in the Chinese Linux space. As far as we can see, there were no further versions of K/UX after version 3. As additional motivation for cooperation, both EulerOS and K/UX were originally based on CentOS Linux, and of course, in December 2020, the CentOS Project announced it would shift its focus from CentOS Linux to CentOS Stream. The openEuler community has taken the platform in new directions. It has built its own stack of tools for developing, deploying, and running LLMs, called Intelligence BooM. It has a tool for migrating CentOS Linux systems to openEuler, called x2openEuler. As you would expect, it supports Kubernetes, as well as Docker and Podman, but it also has its own container engine called iSula (named after a species of ant). Aware that it's less known outside Asia, at the Open Source Summit, OpenAtom was handing out copies of a special "Focus Guide" from Admin Magazine, which is also available as a free download. Some parts of this are also available online without registration, such as AI and the BooM Stack and Automating Migration to openEuler. openEuler has a dual-strand release cycle, akin to Ubuntu rather than the RHELatives, with LTS versions and more frequent "innovation releases." The current LTS is version 24.03, released in June 2024, while the latest version is 26.09. There is a plethora of versions and editions available on the downloads page: the latest release is for x86-64 and 64-bit Arm. The LTS version adds support for RISC-V and LoongArch, and there are minimal versions for 32-bit Arm as well. The older 22.03 LTS was also available for SW-64, meaning the SunWay RISC processors that Register sister site The Next Platform looked at in 2016. As LWN put it last year, this is a "non-upstream kernel port." There are five types of installation ISO available: Offline Standard, Offline Everything (a hefty 24.9 GB), Network Install (a still significant 1.5 GB), and two variants of the desktop "DevStation" version – a basic one at 3.3 GB and an "everything" edition at 25 GB. We gave the DevStation a very quick whirl in VirtualBox. It boots into its own installation program called Heolleo, which offers the choice of Simplified Chinese or English. Installation took a while, as it automatically fetches updates as it goes. We ended up with a GNOME desktop configured for Chinese, but we opened Settings, typed "language" into the Search box, and picked English. After a reboot, we could read most of the desktop. Program groups and some other elements are still in Chinese, but it's navigable with a bit of guesswork. It's GNOME 49, with the Dash to Panel and Arc Menu extensions preinstalled for a slightly more familiar layout. Opening a terminal, we were greeted with: Welcome to 6.18.48-0.0.0.15.oe2609.x86_64 It also offers the Deepin Desktop Environment, UKUI (as seen in Ubuntu Kylin), MATE, Xfce, and the Kiran Desktop Environment, which is a new one to us. In places, the English-language materials for openEuler mention Chinese CPU makers rather than western ones – which is understandable, in context. Examples include processors from Hygon, a Chinese licensee of AMD designs, as well as Phytium and Kunpeng, which explain the Arm support on offer. In the western world, the Red Hat user community responded to the end of CentOS Linux by building new free distros that stay as close as they can to their progenitor: the Rocky Linux and AlmaLinux projects, rebuilt from Red Hat source code. Then, when the IBM subsidiary restricted access to that source to its customers in 2023, the Rocky and AlmaLinux projects started to diverge. Rocky aims for the closest possible RHEL compatibility, and its most visible innovation is that it's built its own new build service. It also found a clever workaround to get Red Hat's kernel source code. AlmaLinux still targets RHEL compatibility, but differentiates itself by retaining older device support and older CPU architectures after Red Hat drops them. Chinese vendors have responded very differently. Those offering CentOS Linux-based OSes clubbed together, dropped their rival versions and their UNIX compatibility efforts, and instead are working on new tools and subsystems. Much like European interest in digital sovereignty, this is in part due to the Trump administration. Half a decade after it was cut off from its upstream sources, the openEuler platform is thriving and growing, even if few in the western world pay any attention at all. ®

Microsoft has been forced to admit that the Always On VPN glitch – which it said it had fixed in an update on October 13 – was not actually fixed after all. We've all been there. You fix that bug, or tweak the configuration setting, and you're pleased with yourself, but it turns out it didn't take, and you have to send the "er, about that fix" follow-up email of shame. The same has happened to Microsoft. After proudly declaring the problem resolved as part of its last security update, the company had to roll back its triumphant trumpeting to a sad little parp from a clown's horn in the message WI1482218: "This disclosure was mistakenly updated to Resolved status on October 13, 2026. We have returned its status to Mitigated. "We apologize for any inconvenience or confusion." The bug in question concerns the operating system's Always On VPN functionality, a useful bit of code that quietly opens a VPN connection in the background without tiresome prompts for authentication. It dates back to Windows 10, and Microsoft alerted administrators to problems after the September 2026 Windows security update inadvertently broke it. The issue affects Windows 11 versions from 24H2 through 26H2. The problem could occur when the VPN was set to try a different connection method if the initial connection failed (Microsoft gave the example of using automatic protocol selection with IKEv2 and SSTP). According to Microsoft: "Affected VPN connections might remain in a 'Connecting' state or repeatedly attempt to connect without succeeding. Subsequent connection attempts might also display the error: 'The specified port is already in use'." This is not ideal for administrators. The workaround Microsoft highlighted back on October 13 was to change from automatic protocol selection to a single protocol, which would at least get affected users up and running. The workaround remains the same. The bad news is that, because last week's fix did not work, affected administrators will need to apply the workaround for a bit longer. Microsoft claimed, "A resolution for this issue is planned to be included in an update to be released in the coming weeks." ®

In Brno in Czechia, Red Hat’s large local office has been helping the city’s Masaryk University to teach future technical writers. Whenever someone tries to teach, though, they learn as well. At the Open Source Summit in Prague, a senior member of Red Hat’s documentation team in Brno presented a talk called Diagrams & Dragons: Teaching Technical Writing to University Students the Open Source Way. Red Hat has a large site in Brno, which is the second-largest Czech city and is also the home of the respected Masaryk University. Red Hat’s Brno office has a substantial documentation team — this vulture was part of it for a while. For the last four years, Red Hat has been working with the university’s Faculty of Informatics to teach a course unit in technical writing. Jiří Herrman talked about what the course tutors had learned from the students. For FI MUNI, its course PV177 Technical Writing. Red Hat has a page with some of the materials. “RH has been looking into cultivating technical writers in Brno for a while,” he said, but the launch of the course was “delayed due to the 2020 worldwide global… thingy.” The company particularly wants to work on what he described as “that tricky part of technical writing where you actually have to interact with other humans.” Some of the things that struck this former tech-docs writer the most are covered on pages 7 and 9 from Herrman’s short slide deck [PDF], which discuss what didn’t work. Although the course was aimed at students with some technical knowledge, they found that setting classwork with shell-based tools didn’t work: some of the students had never used the command-line, some came with borrowed laptops without admin-level access, and some came with just phones rather than laptops. Some we found less surprising. Getting students to grade one anothers’ work, much as professional tech writers review one another’s contributions, didn’t work well – partly due to the speed required. In the end, the compromise was to give the students a course in grading each other’s work “without pissing each other off.” It didn’t shock us, but we suspect might leave some training vendors taken aback, that interacting with remote teachers who were presenting online didn’t work well – especially when there were multiple tutors, changing with each class. LLM use You may well have already foreseen the biggest “gotcha” for a course that ran for the first time in 2023. It is, naturally, use of LLM. The students were told that they were not allowed to use LLMs during the course, but naturally enough, they did so anyway. Among the problems that Herrman reported were that giving praise to good work that involved LLM use just encouraged more cheating. However, telling students off for it discouraged them, and that encourages cheating. So the team had to come up with some tactics to try to manage this, which involved teaching the students how to use LLMs instead. They did, however, find some things that did work well. Awarding points, even on a semi-arbitrary basis, with occasional secret prizes, as well dispensing feedback via internet-style memes. A final exercise was to role-play a scenario, “Dungeons & Dragons” style. The quest was “I want to be a tech writer, but how to get there?”. This involved navigating a cross-functional team, creating things like release notes, technical notes, and some real documentation for the process. And as the course materials are open source, the graduates ended up with a permanent FOSS record that they can show to prospective employers. There is a project Github, and you can see some of the student’s archived coursework for 2025 and 2026. The issues around LLM use in tech writing were the primary subject of a “Birds of a Feather” session that Herrman moderated earlier: Technical Writing in the Age of AI. He started by asking how many in the audience were using AI in their tech-writing efforts, getting what he called an “overwhelming majority” who were already on-board. What we found interesting is what people said they didn’t use it for. They find even the best models are poor at writing documentation themselves. They’re also poor at drawing diagrams, and at reading them for review purposes. They’re poor at reviewing docs (“AI is too obsequious and so reviews are overly positive,” and “it doesn’t give good feedback on user focus, or structure.”) However, most of the attendees found uses for it all the same. Examples included “Change management” and “Updating to new code” – in other words, identifying which parts of large products had changed and which therefore needed fresh documentation. Others said they used it for “Documenting decisions from meeting notes,” and in other ways, “Collecting information resources for writing,” and worryingly, to “Summarize notes (from conferences, meetings, etc.) and cluster by themes”. Another use was “Reverse engineering code to figure out intent,” or to “Find existing docs to prevent reinvention or duplication.” Tech writing is a demanding job, and pretty much permanently under-resourced. We can’t and don’t blame anyone for grabbing onto anything that might help. Even so, for us, what stood out from this session was the pretty much unanimous agreement among an audience of tech writers that LLMs were poor at doing the job that tech writers themselves did. Reviewing each others’ docs is a core part of the job: tech writers are used to this, and when they review the bots’ efforts, they find the machinese lacking. That fits our impressions, too. What we found alarming is that, although they find the bots poor at doing what the writers know best, even so, they trusted the bots to be competent in other functions, things the writers don’t look at so closely – for example, finding and selecting where docs need updating. The use for summarization is especially alarming: this is something that studies have demonstrated LLMs are bad at. They shorten, not summarize, and that’s no substitute. We find that worrying, but we regularly hear reports of companies pressing staff to use AI more. This is an all-too-human response: “it can’t do my job, but if I must use it, then this stuff isn’t my jurisdiction, and if it messes up, I can blame someone else.” We just worry at whose desk this buck will eventually stop. ®