In June 2022, I started work on porting FreeBSD to run on Firecracker. My interest was driven by a few factors. First, I had been doing a lot of work on speeding up the FreeBSD boot process and wanted to know the limits that could be reached with a minimal hypervisor. Second, porting FreeBSD to new platforms always helps to reveal bugs — both in FreeBSD and on those platforms. Third, AWS Lambda only supports Linux at present; I’m always eager to make FreeBSD more available in AWS (although adoption in Lambda is out of my control, Firecracker support would be a necessary precondition). The largest reason, however, was simply because it’s there. Firecracker is an interesting platform, and I wanted to see if I could make it work. Firecracker is Amazon’s virtual machine monitor. This article goes in great detail about the process of porting FreeBSD to run on Firecracker.
FreeBSD developers are looking at using the open-source NVIDIA kernel driver being developed by NVIDIA as an open-source Direct Rendering Manager driver that is out-of-tree, but not to be confused with Nouveau. With that kernel driver they are able to provide this nvidia-drm-kmod driver on their own and within the ports collection for better integration with the kernel and those wanting one less kernel binary blob. Excellent news for FreeBSD users with NVIDIA cards.
FreeBSD is a compelling and cutting-edge operating system that provides a wealth of features and advantages. FreeBSD’s deep OpenZFS integration, completely customizable packaging, and the ability to manage a huge fleet with a small team make it a clear contender for consideration in your next infrastructure build. This one’s written by a company that, among other things, sells FreeBSD and OpenZFS support, so take that into account when reading the article.
One of my old home automation boards running ebusd is still using Raspberry PI 2 B SoC. FreeBSD is still perfectly supporting this hardware, however, due to being a Tier-2 platform, binary updates freebsd-update are not supported. Of course, one can download the new image, but this will mean re-installing and reconfiguring all the software, which is time-consuming and painful. Also, the traditional “build from source” way will probably take forever on this tiny board and also could potentially destroy the SD card. So the obvious alternative was cross-compilation. If you’re in this very specific niche – you’re very happy this guide exists.
FreeBSD is still going strong. Its strength comes from having built a strong base in its code, documentation, and culture. It has managed to evolve with the times, continuing to bring in new committers, and smoothly transition through several leadership groups. It continues to fill an important area of support that is an alternative to Linux. Specifically, companies needing redundancy require more than one operating system, since any single operating system may fall victim to a failure that could take out the entire company’s infrastructure. For all these reasons, FreeBSD has a bright future. In short, FreeBSD is awesome! Having finally delved a bit deeper into FreeBSD this past year, I have to say it’s an incredibly nice operating system to use and maintain. In the end, it’s the lack of polish as a desktop and laptop user that prevents me from using it full-time, but the built-in tools are incredibly nice to use, software installation and updates are a breeze, and the documentation is great. It really makes me wish the desktop and laptop was more of a focus for the developers, but I understand why it isn’t.
The FreeBSD team has released the latest point release for FreeBSD 13.x, version 13.2. It comes with updated versions of OpenSSH and OpenSSL, improvements to bhyve to allow more than 16 virtual processors, an updated version of OpenZFS, the inclusion of the WireGuard kernel driver, and much more.
FreeBSD 12.4 has been released. This is a maintenance release of the older stable branch, and contains the usual package updates, bug fixes, and other relatively minor changes.
It’s been a long journey these past few months trying to find a modern, compatible, FreeBSD laptop, and getting it to work well enough for daily use (everything except for gaming). For the past few months, I’ve been documenting my journey using this laptop, then I left the framework laptop and switched to a Thinkpad X260, and then a Thinkpad X1C7. This gave me perspective on what is considered “FreeBSD compatible”.. After experiencing what that “compatibility” meant, and the work needed to get those machines up and running, I decided to come back to the framework laptop with that perspective, and try to get FreeBSD running on it again in a smoother capacity. I’ve finally succeeded! Everything isn’t perfect, but it’s pretty good, and will hold you until even better support comes to the machine. I can now pretty much say that you can use this laptop in a production capacity for your every day stuff. Getting FreeBSD to fully support a modern laptop for desktop use seems like what it was like to get desktop Linux up and running smoothly on a desktop about twenty years ago. I love the idea of desktop FreeBSD, but I feel like there’s a long way to go, and I wonder if the people actually developing and contributing to FreeBSD are really focused on it (which is, of course, their prerogative).
FreeBSD 13.1 has been released, and as the version number signifies, this is not a major release, so don’t expect any massive changes. Lots of various core packages of the operating system have been updated to their most recent versions, like OpenSSH, OpenSLL, and ZFS, there’s the usual driver updates, and a whole slew of fixes.
FreeBSD 12.3 has been released. As a true point release, there’s no major new features or massive updates in here – there’s updated network drivers, kernel bug fixes, and so on. The full release notes have all the details.
The third quarter of 2021 was quite active in lots of different areas, so the report covers a bunch of interesting work including but not limited to boot performance, compile-time analysis, hole-punching support, various drivers, ZFS raidz expansion, an update to the sound mixer, and many more. FreeBSD’s status reports are a great way to keep up to speed with the project’s progress.
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. It’s always nice to read perspectives like this.
The FreeBSD Release Engineering Team is pleased to announce the availability of FreeBSD 13.0-RELEASE. This is the first release of the stable/13 branch. The announcement and release notes contain more information.
FreeBSD will promote arm64 to a Tier 1 architecture in FreeBSD 13. This means we will provide release images, binary packages, and security and errata updates. While we anticipate there will be minor issues with this first release, we believe the port is mature enough that they can be resolved during the life of FreeBSD 13. Maybe not massively relevant right now, but with Arm making its way into both servers and desktops, this is some good future-proofing for FreeBSD.
Steam is a gaming platform that sells and manages games on Windows and Linux. Since FreeBSD has some pretty good Linux emulation, it is possible – with some footnotes – to run Linux Steam Games on FreeBSD. This was already possible in 2016 but the tooling keeps being updated, so let’s take a look at how things work. This is really interesting. Wine’s and Valve’s efforts are paying off in so many unforeseen ways.
With the release of FreeBSD 13.0 on the horizon, I wanted to see how it shapes up on my Lenovo T450 laptop. Previous major releases on this laptop, using it as a workstation, felt very rough around the edges but with 13, it feels like the developers got it right. It would be good for the desktop Linux world if FreeBSD managed to become even a little bit more mainstream among desktop users. Linux pretty much has the open source desktop world all to itself, and some competition would be very welcome.
This morning, WireGuard founding developer Jason Donenfeld announced a working, in-kernel implementation of his WireGuard VPN protocol for the FreeBSD 13 kernel. This is great news for BSD folks—and users of BSD-based routing appliances and distros such as pfSense and opnSense. Not something I personally use, but good news for those that do.
I normally deal with Linux machines. Linux is what I know and it’s what I’ve been using since I was in college. A friend of mine has been coaxing me into trying out FreeBSD, and I decided to try it out and see what it’s like. Here’s some details about my experience and what I’ve learned. Exactly what it says on the tin – and may I just say that the design and colour scheme of the website in question is extremely pleasant to the eyes.
This quarter had quite a lot of work done, including but certainly not limited to, in areas relating to everything from multiple architectures such as x86, aarch64, riscv, and ppc64 for both base and ports, over kernel changes such as vectored aio, routing lookups and multipathing, an alternative random(4) implementation, zstd integration for kernel dumps, log compression, zfs and preparations for pkg(8), along with wifi changes, changes to the toolchain like the new elfctl utility, and all the way to big changes like the git migration and moving the documentation from DocBook to Hugo/AsciiDoctor, as well as many other things too numerous to mention in an introduction. The best way to keep up with FreeBSD development from an outsider’s perspective. FreeBSD is on my radar for the UltraSPARC server-as-a-workstation project – a reader has donated a SunFire V245 that’s currently in shipping to me – so I’m trying to be a bit more in tune than I usually am with the world of FreeBSD.
On modern Unix-like systems such as FreeBSD, “swapping” refers to the activity of paging out the contents of memory to a disk and then paging it back in on demand. The page-out activity occurs in response to a lack of free memory in the system: the kernel tries to identify pages of memory that probably will not be accessed in the near future, and copies their contents to a disk for safekeeping until they are needed again. When an application attempts to access memory that has been swapped out, it blocks while the kernel fetches that saved memory from the swap disk, and then resumes execution as if nothing had happened. In 2021, cheap SSDs have become commonplace and have performance characteristics much better suited to swapping, so it seems worthwhile to revisit how swapping works in FreeBSD, and try to provide some insight into frequently raised issues. Some light reading for the weekend.