Not quite; one FreeBSD community member who isn't a developer edited the FreeBSD wiki to suggest this, and that was picked up by a variety of tech press sources.
The comment I left on a Reddit thread four years ago still applies:
> This link gets shared around every now and then, and my response is always the same: there is some useful insight, but there's also information that's so outdated it provides no value, outright misinformation, and self-contradiction. Some of the technical points are fair, and should be and are being addressed. But the commentary is often laughably wrong. The document seems more focused on advancing an agenda than a good-faith effort at improving security in FreeBSD.
If anyone is actually interested in discussing mitigations and improved security posture on FreeBSD I'd suggest starting a thread on one of the mailing lists, but I'll also keep an eye out for feedback here and on the Fediverse.
A lot of Linux kernel drivers are permissively licensed, or dual-licensed with a choice of GPL and a permissive license. This is especially common for vendor-developed drivers. From a hardware vendor’s perspective, broad license compatibility directly supports adoption: the more operating systems, hypervisors, and embedded environments that can incorporate the driver code, the wider the potential market for the hardware itself.
32-bit x86 CPUs haven't been made in years, companies building products based on FreeBSD switched to 64-bit x86 or to other architectures long ago. It's not that work on i386 is being done but kept in private repos and not upstreamed -- work on i386 just isn't being done at all.
Note that the bug that is the topic of discussion here predates OpenZFS. Whether or not there has been a slide in disciplined development in OpenZFS, this bug does not support that assertion.
Since the topic is whether or not the current OZFS developers understand what is going on well enough to reliably fix the bug, I think it still applies.
Linux later had the lawsuit issue with SCO and IBM and tracking where certain things came from (which was not helped by the fact that Linus Torvalds refused to use source code tracking for the longest time (later taking up Bitkeeper, and later developing git)).
I suspect your question is essentially "why is this 14.0, and not 13.3?" And the answer to that question is that this is a new release from our development branch, not an update to an existing branch used for the 13.x releases.
FreeBSD 14.0 represents over two and a half years of feature development, stability and security improvements, and bug fixes. Some of these changes were cherry-picked into the stable/13 branch and were included in the FreeBSD 13.1 and FreeBSD 13.2 minor releases built from there.
A sibling comment notes that APIs or ABIs may change between major versions. This is true, but this is not the reason for a new major version. Rather, ABI and API changes are allowed during the development cycle on the main branch, but are not cherry-picked into the existing stable branches.
I have a proposed change to include in the release notes some significant changes that happened to have been merged into 13.x already, and so far have been excluded from 14.0's notes: https://reviews.freebsd.org/D42546
I'm sure Colin's results can be reproduced, but it will take some effort. Colin has been doing a lot of work so that Firecracker can boot FreeBSD -- see https://www.daemonology.net/blog/2022-10-18-FreeBSD-Firecrac... for an introduction -- and that is not yet all available in Firecracker "out of the box."
