Those waiting for FreeBSD to make a big splash often wait a long time. That’s one of the things I both appreciate and occasionally find frustrating about the system. I appreciate it because you’re not bombarded with marketing hype every other day. But it’s frustrating because you often have to piece together the most interesting developments from mailing lists, release notes, and passing remarks.
Looking back at the past seven days, the core picture is quite typical for FreeBSD: outwardly, it’s relatively quiet, but beneath the surface, discussions are happening in precisely the areas that make operating systems either pleasant or frustrating in daily use—software build performance, ZFS stability and memory behavior, and how to make pkg more practical in a PKGBASE environment.
FreeBSD 14.4 Remains the Dominant Topic
The most important official news in the observed period is still the release of FreeBSD 14.4-RELEASE on March 10. While it falls just outside the seven-day window, it has clearly shaped discussions this week—and for good reason.
Key highlights of 14.4 include:
- OpenSSH 10.0p2
- Hybrid post-quantum algorithm mlkem768x25519-sha256 enabled by default
- OpenZFS 2.2.9
- Improved cloud-init/nuageinit compatibility
- A new p9fs(4) for filesystem sharing between host and bhyve guests
- Enhancements to manpages and their tools
Overall, this is a solid release. No revolution, but exactly the kind of version FreeBSD is known for: evolutionary, pragmatic, and focused on meaningful maintenance rather than spectacle.
Also worth mentioning is the dedication of this release to Ken Smith, who passed away late last year and played a key role in FreeBSD’s release engineering for many years. Such acknowledgments often get lost in technical announcements, but they matter—they remind us that behind all the code, there are people.
Early Feedback on 14.4: Build Times Cause Frustration
More interesting than the release announcement itself were this week’s real-world reports. On the mailing list, a case was described where, after upgrading from 14.3 to 14.4, build times with poudriere had increased—sometimes doubling in duration.
This isn’t a minor detail. For those who build ports, maintain packages, or compile locally, this isn’t just a cosmetic issue—it’s a daily pain. If a full build suddenly takes two days instead of one, that’s no longer a footnote.
The discussion pointed to a known performance issue and noted that a workaround exists to restore the previous behavior. That’s the good news. The less good news is that such problems only surface in practice, and users have to dig through threads and commit messages to find solutions.
This is, unfortunately, not uncommon with FreeBSD: the technology is often solid, but communication about it can be less user-friendly than it could be.
ZFS Remains Excellent—and Sometimes Frustrating
Things got really interesting in a discussion about ZFS deadlocks and memory accounting issues on NFS servers. A scenario was described where machines, despite having plenty of free RAM, came under memory pressure, started swapping, and in the worst cases, hit OOM (out-of-memory) conditions. This is particularly frustrating because large storage and file-serving systems running FreeBSD are often chosen precisely because ZFS is supposed to excel in such environments.
The reported case involved systems with very high RAM capacity, where ARC memory appeared evictable, yet the system still entered a problematic state. There were also reports of blocked processes and wait states around ARC and dbuf mechanisms. Of course, this is just one case from a mailing list—not a universal statement about all 14.x installations. But it’s exactly the kind of signal that should make administrators take notice.
Such issues aren’t problematic because they’re spectacular; they’re problematic because they often disguise themselves as “odd behavior” for a long time. A little swap here, some load there, a few hanging processes—and suddenly, a system that, by superficial metrics, shouldn’t be struggling at all, is in trouble.
FreeBSD still has strong arguments in the storage space. But when reports like this emerge, they should be taken seriously—not hysterically, but seriously.
A Small pkg Discussion, But with Practical Relevance
Less dramatic but still practically relevant was a discussion about pkg and its interaction with PKGBASE. Specifically, the desire to cleanly separate upgrades for third-party packages and the base system.
Proposed additions included aliases like:
pkg upgrade-packagespkg upgrade-base
The idea is simple and reasonable: in daily use, users don’t always want to lump everything together. Instead, they want to consciously decide whether to update only ports packages or only the base system.
This isn’t the kind of news that inspires excitement, but it’s a good example of how FreeBSD evolves: often in small, unassuming, yet practical steps. In the end, such improvements often make more of a difference than some grand, heavily promoted project.
At the same time, the discussion highlights a typical problem: naming and clarity aren’t trivial. If you say “packages” when, technically, everything is a package, confusion is almost built in. It’s not a disaster, but it’s not a detail that should be ignored either.
What Stands Out from This Week?
Summing up the past seven days around FreeBSD, this is the picture that emerges:
FreeBSD often appears quiet—almost too quiet—on the surface. But beneath that calm, the discussions revolve around precisely the issues that matter most to users and administrators:
- How well does a new release perform in real-world use?
- Are there performance regressions?
- Is ZFS as stable under real-world load as expected?
- Are tools like
pkgbecoming more usable in daily operations?
That, in the end, might be what’s most likable about FreeBSD. The most interesting news is rarely just “New! Bigger! Faster!” Instead, it’s often about where practice clashes with theory—and that’s where a system earns long-term trust.
14.4-RELEASE is undoubtedly the most significant recent development. But the subsequent discussions about build performance and ZFS show that a release isn’t finished when it’s published. That’s when the phase begins where it becomes clear how well things actually work outside of release notes and announcements.
And that phase was the truly interesting part of the last seven days.
Sources
- FreeBSD News Flash: https://www.freebsd.org/news/newsflash/
- FreeBSD News RSS Feed: https://www.freebsd.org/news/feed.xml
- FreeBSD 14.4-RELEASE Announcement: https://lists.freebsd.org/archives/freebsd-announce/2026-March/000228.html
- FreeBSD-announce Archiv März 2026: https://lists.freebsd.org/archives/freebsd-announce/2026-March/date.html
- Thread: „Huge build times increase after updating from 14.3 to 14.4“: https://lists.freebsd.org/archives/freebsd-stable/2026-March/003900.html
- Antwort von Olivier Certner zum bekannten Performance-Problem: https://lists.freebsd.org/archives/freebsd-stable/2026-March/003901.html
- Nachfrage von Philip Paeps zu den Package-Buildern: https://lists.freebsd.org/archives/freebsd-stable/2026-March/003907.html
- Thread: „ZFS deadlocks/memory accounting issues“: https://lists.freebsd.org/archives/freebsd-stable/2026-March/003910.html
- Antwort von Alan Somers im ZFS-Thread: https://lists.freebsd.org/archives/freebsd-stable/2026-March/003911.html
- Thread/Proposal zu pkg-Aliases: https://lists.freebsd.org/archives/freebsd-stable/2026-March/003942.html
- Rückfrage zur Benennung der pkg-Aliases: https://lists.freebsd.org/archives/freebsd-stable/2026-March/003944.html
- FreeBSD-stable Archiv März 2026: https://lists.freebsd.org/archives/freebsd-stable/2026-March/date.html