BSD & Darwin Archive

Remember Darwin? It’s the core of Apple’s macOS, and the company has always – sometimes intermittently – released its source code as open source. Not much ever really happens with Darwin, and any attempts at building a usable operating system on top of Darwin have failed. There was OpenDarwin, which at one point could run a GNOME desktop, but in 2006 it shut itself down, stating: Over the past few years, OpenDarwin has become a mere hosting facility for Mac OS X related projects. The original notions of developing the Mac OS X and Darwin sources has not panned out. Availability of sources, interaction with Apple representatives, difficulty building and tracking sources, and a lack of interest from the community have all contributed to this. Administering a system to host other people’s projects is not what the remaining OpenDarwin contributors had signed up for and have been doing this thankless task far longer than they expected. It is time for OpenDarwin to go dark. ↫ OpenDarwin announcement from 2006 (archived) Any other attempts at making Darwin work as a standalone operating system were further frustrated by the fact that Apple stopped releasing bootable Darwin images, so Darwin never amounted to much more than Apple throwing some code over the fence every now and then for some cheap goodwill among the few people who still believe Apple cares about open source. However, the dream is still alive – the idea that you could use Darwin to build a general purpose operating system, perhaps one with some semblance of compatibility with macOS software, is an attractive one. Enter PureDarwin. This project has been around for a while now, releasing an X11-capable build of Darwin somewhere in 2015, followed long, long after that by a CLI-only build in 2020. A few days ago, the project announced an ambitious change in direction, with a plan and roadmap for turning PureDarwin into a general purpose operating system. The PureDarwin project, originally created to bring Apple’s open-source Darwin OS to more people, is heading in a fresh new direction with some clear short-term and long-term goals. These new plans are all about breathing new life into PureDarwin. In the short term, we’re focused on getting some solid basics in place with graphical interfaces using MATE Desktop and LightDM, so users can get a functional and accessible experience sooner rather than later. Looking further down the line, the long-term goals—shown in some early wireframes—are about creating a fully featured, polished desktop experience that’s easy to use and visually appealing. Plus, a new versioning system will make it clear how PureDarwin is progressing independently from Apple’s Darwin updates, making it easier for everyone to keep track. This refreshed direction sets PureDarwin up to grow from its roots into a user-centered operating system. ↫ PureDarwin announcement These plans and roadmap sound quite well thought-out to me. I especially like that they first focus on getting a solid MATE desktop running before shifting to building a more custom desktop environment, as this makes it much easier – relatively speaking – to get people up and running with Darwin. Once Darwin with MATE is halfway usable, it can serve its job as a development platform for the more custom desktop environment they have planned. It won’t surprise you, by the way, that the sketches for the custom desktop environment are very Apple-y. As part of the goals of creating a usable MATE desktop and then a more custom desktop environment, a whole bunch of low-level things need to be handled. All the kexts (drivers) required for Darwin to boot need to be built, and CoreFoundation needs to be updated, a process that was already under way. On top of that, the project wants to focus on getting Wayland to work, make Darwin buildable under BSD/Linux, and develop an installer. Beyond those goals, the project has an even bigger, tentative ambition: API compatibility with macOS. They make it very clear they’re not at all focused on this right now, and consider it more of a pie-in-the-sky goal for the the distant future. It’s an interesting ambition we’ve seen tried various times before, and it surely won’t be even remotely easy to get it to a level where it could do much more than run some command-line utilities. Darling, a similar project to run macOS binaries on Linux in the style of Wine, has only recently been able to run some small, very basic GUI applications. I like all of these goals, and especially getting it to a state where you can download a Darwin ISO running MATE should be entirely realistic to achieve in a short timeframe. A custom desktop environment is a lot more work of course, all depending on how much they intend to reuse from the Linux graphics and desktop stack. Anything beyond that, and it becomes much murkier, obviously. As always, it’s all going to come down to just how many active and enthusiastic contributors they can attract, and more importantly retain once the initial excitement of this announcement wears off.

I bought a Topton GM1 Industrial Mini PC for my HomeLab. It is aimed at running Slackware Linux but I wanted to have a quick look at how well BSD OSes support it out-of-the-box. ↫ Joel Carnat That’s really all there’s to this story. I just really, really love tiny industrial and office computers and thin clients, and every time I see another one for sale I really have to stop myself from buying one I have absolutely no use for. There’s just something about how these little guys are built that speaks to me – they’re different than regular PCs, but only marginally so, making them fun to play around with, getting drivers for everything, seeing if Linux and BSD have any issues with it, and so on. They’re also often fanless, which is a major boon. The Dell thin client I wrote about last week has been run through a gauntlet of operating systems to see just how capable it is, and I’m surprise by just how much you can do even with a pedestrian Pentium Silver. For now it’s running Fedora GNOME to get an idea how the most default of default Linux environments performs and feels – so I can include it in future articles about it – but I think I’m going to set it up as a retrogaming console using Batocera. Industrial, office, and thin client computers are just fun to play around with, and they’re incredibly cheap when buying used. If things like a Raspberry Pi are hard to get, backordered, or overpriced due to demand outstripping supply, it’s definitely a good idea to see if you can find some cast-off thin client or whatever for your project instead.

DragonFlyBSD lead developer Matthew Dillon has recently been working on further refinements to HAMMER2 for the next DragonFlyBSD operating system release. The latest HAMMER2 activity in the past few days has included improving its CPU performance and adding a new “hammer2 recover” directive. The HAMMER2 recover support allows for recovering/undoing single files as well as preliminary support to recover entire directory structures. DragonFlyBSD always feels like the one nobody talks about or uses, with FreeBSD, OpenBSD and NetBSD taking the spotlight instead. Are any of you folks using it? How has it been?

I encountered yet another discussion about OpenBSD PF versus FreeBSD PF. For those who are new to the discussion: OpenBSD developers created PF in 2001, and it rapidly improved to become the most approachable open source packet filter. FreeBSD ported PF over to its kernel in 2004, with occasional updates since. Today a whole bunch of folks who don’t program echo cultish wisdom that one or the other version of PF has fallen behind, not kept up on improvements, or otherwise betrayed their community. My subtler comments have been misinterpreted, so let’s try this. These claims are garbage. Contrary to what the peanut gallery of open source thinks, in general, the rule is that open source teams work together all the time, more often than not across project lines. Of course the OpenBSD developers are working together and sharing code when it comes to things like PF – they most likely share a lot of features and code, and while one of the two versions of PF might get a certain feature first, it will make its way to the other soon enough. These are professionals – not forum posters.

DragonFly version 6.4 is the next step in the 6.x release series. This version has hardware support for type-2 hypervisors with NVMM, an amdgpu driver, the experimental ability to remote-mount HAMMER2 volumes, and many other changes. The details of all commits between the 6.2 and 6.4 releases are available in the associated commit messages for 6.4.0. The downloads are ready.

Hopefully there’s a new ISO/img on the mirrors for DragonFly 6.2.2 by the time you read this – or you can just update your installation.  The changelog is short, because this is a bugfix-level release.  Also, don’t forget there’s a new set of binary packages out; update that too if you haven’t. Clear as day.

This new ISO contains fixes, improvements, and software updates. Finally, the installer hanging at the cleaning stage for ZFS installation got fixed, and OpenRC and dhcpcd were removed from the base code. Furthermore, automation configuration for HD 7000 series and older GPUs has been added. I also added the support for os-release to show GhostBSD name and GhostBSD version in applications like mate-system-monitor, python distros, pfetch, and neofetch and added a new set of wallpapers for 2022 and removed p7zip from the default selection since it is vulnerable and unmaintained. GhostBSD is a desktop-oriented FreeBSD distribution, mating Mate with the FreeBSD base system.

6.0.1 is tagged and available. The major reason for this update is an expired Let’s Encrypt certificate that would cause problems when downloading dpkg binaries. A list of 6.0.1 commits is available. Not a whole lot going on in this release, but still a major bug fix.

Let’s step away from Windows 11 for a second, and spend some time with DragonFlyBSD. Software running on DragonFlyBSD and making use of pthreads is set to see better performance around low-level locks when heavily contested. This commit has the details on the change by DragonFlyBSD founder Matthew Dillon. But long story short pthreads-using software should benefit from this low-level lock performance improvement.

hello (also known as helloSystem) is a desktop system for creators with focus on simplicity, elegance, and usability. Its design follows the “Less, but better” philosophy. It is intended as a system for “mere mortals”, welcoming to switchers from the Mac. FreeBSD is used as the core operating system. With PC-BSD gone, it’s nice to see others step in to fill the void. This particular project was founded by Simon Peter, who also started AppImage and PureDarwin, so there’s quite a bit of pedigree here. It’s still in development and not yet ready for general use.

Almost all of the BSD releases have been well preserved. If you want to find 1BSD, or 2BSD or 4.3-TAHOE BSD you can find them online with little fuss. However, if you search for 2.11BSD, you’ll find it easily enough, but it won’t be the original. You’ll find either the latest patched version (2.11BSD pl 469), or one of the earlier popular version (pl 430 is popular). You can even find the RetroBSD project which used 2.11BSD as a starting point to create systems for tiny mips-based PIC controllers. You’ll find every single patch that’s been issued for the system. What you will not find, however, is the original 2.11BSD release tapes. You won’t find the original sources. With some digging, you can find is 2.11BSD pl 195. This was released about 30 months after the original was released, and is the oldest one that’s known to exist. And so starts the search for the original code.

DragonFly version 5.8 brings a new dsynth utility for building your own binary dports packages, plus significant support work to speed up that build – up to and including the entire collection. Additional progress has been made on GPU and signal support. This release’s been out for a while, but I haven’t highlighted it yet, so here we go. They’re already up to 5.8.1 by now.

Speaking of using BSD as a general purpose operating system: NomadBSD is a persistent live system for USB flash drives, based on FreeBSD. Together with automatic hardware detection and setup, it is configured to be used as a desktop system that works out of the box, but can also be used for data recovery, for educational purposes, or to test FreeBSD’s hardware compatibility. This seems like quite the polished and minimalist – yet full-featured – FreeBSD distribution to test out your hardware.

NetBSD, the highly portable Unix-like Open Source operating system known for its platform diversity, has gained hardware-accelerated virtualization support via an improved NetBSD Virtual Machine Monitor (NVMM). A virtualization API is provided in libnvmm, that allows to easily create and manage virtual machines via NVMM. It’s always nice to see the major BSD distributions gain expanded hardware and software support. It will come as no surprise to anyone that we believe that competition is always a good thing when it comes to operating systems.