helloSystem, a project that gives FreeBSD a user interface reminiscent of macOS, hit the 0.5 landmark with a new build last week.

The 0.5 release is based on FreeBSD 12.2 and is progressing nicely. The release notes show a number of important fixes like “sudo su works now”, “fix wrong font sizes” and “fix menu and desktop on multi-monitor setups”.

There is also a note that “all helloDesktop core components build on Linux now,” raising the possibility of a Linux version in future, and that helloDesktop can be used with an alternative window manager, KWin, instead of OpenBox.

Changes in the core utilities include “spatial mode” in Filer, which means that folders open in a new window. This is on by default but can be configured in Preferences. Filter also has a new Go To menu, a context menu for opening files as root, new keyboard shortcuts, and shows file volumes on the desktop. Windowshading has been introduced, which collapses a window to just its title bar when the title bar is double-clicked.

A side effect of the whole freenode kerfluffle is that I’ve been looking at IRCD again.  IRC, is of course a very weird and interesting place, and the smaller community of people who run IRCDs are largely weirder and even more interesting.

However, in that community of IRCD administrators there happens to be a few incorrect systems programming opinions that have been cargo culted around for years.  This particular blog is about one of these bikesheds, namely the kqueue vs epoll debate.

You’ve probably heard it before.  It goes something like this, “BSD is better for networking, because it has kqueue.  Linux has nothing like kqueue, epoll doesn’t come close.”  While I agree that epoll doesn’t come close, I think that’s actually a feature that has lead to a much more flexible and composable design.

I’ve been a NetBSD developer for three years and it’s been my primary operating system for a long time too - on everything: routers, laptops, Raspberry Pis, PowerPC mac minis, Vortex86 embedded boards, and servers.

I’ve recently been using FreeBSD a lot at work. We have a lot of servers and embedded boards running it, and I was given the option of installing anything I wanted on my workstation. I chose FreeBSD to maintain a separation of BSDs between my work and home life ;)

I thought I’d write a little bit about some differences that stand out to me. Since everyone that knows me well knows that typical use cases like web hosting aren’t really my jam, and I’m more of an embedded, audio, and graphics person, maybe I can offer a more uncommon perspective.

NetBSD’s pkgsrc package manager is the best thing since sliced bread. Like everything the NetBSD maintainers touch, it’s high quality, well documented, predictable, and portable to a fault. I use it everywhere I can, from my macOS and FreeBSD laptops to remote Linux machines. This has lead people on social networks to ask me why, and to give examples.

The biggest reason comes down to what I call digital hygeine, best described by Merlin Mann as “not storing compost in your vegetable crisper”. There’s value in disambiguating personal tools and applications from what is required to run the system, because updating one set shouldn’t impact the other.

Here’s a fun one. I’ve been messing around with an OpenBSD 6.9 image to see just how well my existing code works on a non-Linux environment. Once in a while, I find something unusual and interesting, like a difference in what is supported, and discover a “Linuxism” (or really a “glibcism” in most cases) as a result.

Tonight, however, was not one of those. It was something else brought to us by the folks at Google who put together gtest and gmock, two C++ libraries for testing and mocking libraries, respectively.

The OpenBSD system has this available via their ports system, so you can just “pkg_add gtest” and you’ll get gtest+gmock 1.8.0p3 on your machine, ready to go. Trouble is, it’s not quite right in the head if you do dynamic linking and put both into your binary. Sometimes, it’ll crash with a delightful message about a double-free. If you then only link against gtest (and not also gmock), it won’t crash.

For most of the 2010s, the OpenBSD base system has been stuck with GCC 4.2.1. It was released in July 2007, imported into the OpenBSD source tree in October 2009, and became the default compiler on the amd64, i386, hppa, sparc64, socppc and macppc platforms in OpenBSD 4.8, released in November 2010. As specified in the commit message during import, this is the last version released under the GPLv2 license.

OpenBSD was not the only operating system sticking to GCC 4.2.1 for licensing reasons, FreeBSD did the same, and Mac OS X as well.

It may sometimes seem difficult to believe but FreeBSD has been around for almost 30 years, with its initial release in 1993. It has evolved tremendously over the years, with the involvement of a great community, who have contributed to its continuous development and fine tuning. This great community that puts its shoulder to the development of FreeBSD consists of three groups: committers, contributors, and users.

If users only run FreeBSD systems, contributors are those who submit patches for consideration. Committers are the ones who assess these patches and decide what goes in and what doesn’t. Or, in more simple terms, committers are developers with read and write access to the FreeBSD repositories. In this article, we will take a look of the strengths that make FreeBSD a trustworthy choice of OS.

While FreeBSD and OpenBSD both switched to using LLVM/Clang as their base system compiler, NetBSD picked a different path and remained with GCC and binutils regardless of the license change to GPLv3. However, it doesn’t mean that the NetBSD project endorses this license, and the NetBSD Foundation’s has issued a statement about its position on the subject.

Realistically, NetBSD is more or less tied to GCC, as it supports more architectures than the other BSDs, some of which will likely never be supported in LLVM.

One thing I’ve always wanted to do is support Tor by running a public relay. However, I didn’t have a machine to dedicate to it. All of my normal systems hold data I don’t want to expose to Tor (ssh keys, browser sessions, etc.) Now that FreeBSD has initial support for the Raspberry Pi 3, I can now run an inexpensive Tor relay. At the same time, I could use it to create a special Tor network at home. All data transmitted over the network destined for the public Internet would go through Tor first.

Since I prefer HardenedBSD over normal FreeBSD, that’s what we’ll be setting up in this article. Though this article focuses on using the HardenedBSD on the RPI3, the concepts apply equally to FreeBSD or HardenedBSD on any architecture.

We introduced a kernel-mode version of WireGuard to our most recent pfSense software releases - pfSense® Plus Version 21.02 (which has since been superseded by Version 21.02-p1), and pfSense Community Edition (CE) software version 2.5.0. As noted in a follow-on blog, questions and concerns with the implementation have surfaced that require attention.

Given that kernel-mode WireGuard has been removed from FreeBSD, and out of an abundance of caution, we are removing WireGuard from pfSense software pending a thorough review and audit.

We will follow the FreeBSD developments on kernel-mode WireGuard. Should WireGuard again be accepted into FreeBSD, we will re-evaluate it for inclusion in a future version of pfSense software.