This section covers the boot loader, boot menu, and other boot-related changes.
Boot Loader Changes
UEFI boot is improved for amd64. The loader detects whether the loaded kernel can handle the in-place staging area (non-copying mode). The default is copy_staging auto. Auto-detection can be overridden, for example: with copy_staging enable, the loader will unconditionally copy the staging area to 2M, regardless of kernel capabilities. Also, the code to grow the staging area is more robust; for growth to occur, it’s no longer necessary to hand-tune and recompile the loader. (Sponsored by The FreeBSD Foundation)
boot1 and loader have been fixed on powerpc64le. 8a62b07bce7
Other Boot Changes
Performance improvements have been made to loader(8), nvme(4), random(4), rtsold(8), and x86 clock calibration, which collectively yield a significant speedup in system boot time. Configuration changes on the EC2 platform provide additional benefits, resulting in 13.1-RELEASE booting over twice as fast as 13.0-RELEASE. (Sponsored by https://www.patreon.com/cperciva)
EC2 images are now built by default to boot using UEFI instead of legacy BIOS. Note that UEFI is not supported by Xen-based EC2 instances or by "bare metal" EC2 instances. 65f22ccf8247 (Sponsored by https://www.patreon.com/cperciva)
Support was added for recording EC2 AMI Ids in the AWS Systems Manager Parameter Store. FreeBSD will be using the public prefix /aws/service/freebsd, resulting in parameter names which look like /aws/service/freebsd/amd64/base/ufs/13.1/RELEASE. 242d1c32e42c (Sponsored by https://www.patreon.com/cperciva)
> The -i flag is now added to rtsol(8) and rtsold(8) by default in /etc/defaults/rc.conf. a0fc5094bf4c
> ...
> The -i option has been added to rtsol(8) and rtsold(8) to disable the random delay between zero and one seconds, speeding up the boot process. 8056b73ea163
Lots of things planned. Unfortunately my schedule got rather derailed after a very demanding baby arrived last year -- in a sense the FreeBSD work is thanks to her since I couldn't focus enough to do tricky tarsnap coding. Now that she's over a year old and the FreeBSD boot speedup work is mostly wrapping up I'm hoping to get back to more tarsnap coding soon.
Thanks! She's bright and alert and well ahead of her milestones (crawling at 2 months, independently walking at 11 months, and confidently running around at 13 months) -- but along with the energy comes only wanting 10 hours of sleep per day (including her afternoon nap) which sadly makes for two rather sleep deprived parents. :-/
To be fair, that was just commando crawling and it took her five minutes to get a few feet. But she was doing a "traditional crawl" at five months (and charging full speed for the door to the basement stairs if we ever made the mistake of leaving it open).
I switched one of my important boxes to FreeBSD a couple of weeks ago
after chatting with an HN poster here. Foray into new lands for me. So
far a very much simpler and pleasant experience from some of the more
"fuller" (bloated) Linux distros of late. I may become a convert.
One of the nice surprises was spinning up a couple of VMs using bhyve
instead of qemu or vbox. Worked first time.
Only one gripe - apparently really crap ext3/4 filesystem support. I
still haven't managed to mount some important disks despite playing
around with fusefs and all that. I'll crack it with time though.
Sarcastic correction: almost decent support for really crap ext3/4 filesystem
(As compared to either of UFS2 or ZFS)
Fun fact: ~12 years ago I was able to recover 80%+ of data from some failing ext3 drives just by mounting from FreeBSD with ext2fs kld and opportunistic copying — whereas any version of Linux I tried would crash immediately after [ro] mounting.
After dealing with Ubuntu all day at work it's such a breath of fresh air when I finally get to use FreeBSD at home. Thank you FreeBSD community for building and maintaining such a gem of an OS. Sincerely, happy user for 21 years now.
Documentation, elegant simplicity, ports feature flags, POLA, ZFS, observability, instrumentation, integration. Almost every FreeBSD sub-system feels as if it was thought through and built by a passionate expert engineer.
BSD License. Free, as in properly free. It's in the name.
If you're a small business and want to build proprietary system, and don't have the money to shell out millions in licensing fees; FreeBSD is your system. It's the only way to beat mega corps and incumbents. FreeBSD keeps this asymmetry in check. Before someone comments about open source, there are reasons out of your hand to keep source code proprietary. For those applications, FreeBSD is a boon.
> Before someone comments about open source, there are reasons out of your hand to keep source code proprietary
Thing is, usually those reasons don't actually exclude the usage of GPL despite someone saying they do. Google is the biggest offender here, they have outright lied about the terms of GPLv2/3 in order to have quick and easy excuses to avoid it.
Most Linux distributions today are large, fragmented, file systems/config files/apps not as coherent as they once was.
The BSD’s are purists. Strong consistency on the file system/configs, strong design principles on keeping things simple.
I only recently tried BSD’s after being a long term Linux user. I don’t use them on the Desktop, so can’t comment about that. On headless servers, after the initial getting familiar period, I find them a joy to work with taking me back to when I first tried Linux using Slackware.
I know there's effort ongoing, and I'm sure it's a tired question at this point, but I have to ask: what is the deal with (the lack of) 802.11ac wifi in FreeBSD?
FreeBSD isn't really the most suitable choice for a laptop, which should be the only place you need to deal with wi-fi (and I say this as someone that's been using FreeBSD on the desktop and on servers for longer than I care to remember).
Anyway, if you read the release notes this release uses the new/recent linux KPI infrastructure to use the Linux wi-fi drivers and stack via a shim, so presumably this will take care of all your kernel-resident problems (userland support is still a question mark)! See man pages below:
> The iwlwifi(4) driver along with a LinuxKPI 802.11 compatibility layer was added to supplement iwm(4) for newer Intel Wireless chipsets. (Sponsored by The FreeBSD Foundation)
I did read the release notes, but I nonetheless appreciate you re-highlighting that bit.
>FreeBSD isn't really the most suitable choice for a laptop, which should be the only place you need to deal with wi-fi
I don't find this attitude towards the situation productive. It's reasonable to want to have modern wifi speeds in 2022, and being dismissive of this when FreeBSD does in fact have support for running as a desktop OS is just odd to me.
That all said, I'm just gonna take the L and acknowledge that my comment on FreeBSD/802.11ac was badly constructed. If I could go back in time, I'd probably re-word it to be: what needs to happen to speed up 802.11ac support in FreeBSD? Is it simply a money thing to get the right people on it with fewer distractions? Is it testing infrastructure?
I guess I could have phrased that part of my answer in a more directly applicable manner: if the majority of FreeBSD users are on desktop/servers and specifically not on mobile, then the majority of dev attention is also going to be focused in a similar fashion. The shortage for a project of this magnitude and nature isn't going to be lack of hardware, it's going to be lack of time and the opportunity cost for the few that could hack on this to stop hacking away on something else.
Basically, the incentives don't align because you're using FreeBSD in a way that most users/devs aren't. That's not to say that you're in the wrong (not one bit, in fact, you should be commended for your dedication) but just to highlight that there's a fundamental impedance mismatch between the needs of laptop FreeBSD users and the overall priorities of the community. It took an insane amount of time and effort to get Linux KPI going for graphics card support (something that affected both laptop and desktop users), you can infer from that the odds of getting something only for laptop use to become a priority.
That said, you should also look at the current release log as an indication of things to come. The effort to get Linux KPI going is very much a step in the right direction: whatever time/money/effort was going into porting or writing new drivers for wi-fi hardware can now be spent on doing things like improving the crypto and/or protocol support to get things like WPA3 and WiFi 6 going.
But the reason I highlighted the above section of the release notes is strictly because the bulk of the work to get 802.11ac support is purely in writing the drivers since it doesn't fundamentally change the requirements in the rest of the stack (no new crypto required, etc) so I don't see how highlighting that isn't already an answer to your question.
I meant to respond to you yesterday. Though I think we're going to disagree somewhat, I do appreciate the thoughtful responses.
>Basically, the incentives don't align because you're using FreeBSD in a way that most users/devs aren't.
I view this as a chicken/egg issue at this point - there is no reason to use FreeBSD on a laptop (and push/fix the other issues) without modern wifi. This also handicaps more than just laptops - e.g, the Raspberry Pi.
>It took an insane amount of time and effort to get Linux KPI going for graphics card support (something that affected both laptop and desktop users), you can infer from that the odds of getting something only for laptop use to become a priority.
I'm definitely aware of this - the mismatched incentives are why I asked in my last comment if this is just a funding/money issue. I recall that the FreeBSD Foundation has done funding work around wifi updates, but if that's not enough I'd like to know.
e.g
>The shortage for a project of this magnitude and nature isn't going to be lack of hardware, it's going to be lack of time and the opportunity cost for the few that could hack on this to stop hacking away on something else.
When I ask if it's a money issue, I'm not asking if they need money to buy hardware - I'm asking if there's sufficient funding for software engineering time.
Anyway, I've enjoyed the back and forth - here's hoping FreeBSD gets it eventually. I still love the OS to this day, but when it falls behind on stuff like this it can be rough.
I forgot about the RPi train - good point. Fwiw, I hope this gets fixed too, and quickly. Unlike the other commenter, I don't think there's anything wrong with asking for updates all the time and hopefully this will get the attention it needs. Cheers, friend!
I'm not sure that wifi = laptop. FreeBSD is an appealing choice as a firewall for example. I can imagine standardizing on FreeBSD across my networking devices and creating some kind of wifi AP using FreeBSD.
I've been running a FreeBSD-based network at home, at work, and at several other sites - one with hundreds of APs. The software infrastructure isn't (even remotely) there to run the entire WiFi backend off of FreeBSD and lack of 802.11ac or WiFi 6 isn't the biggest problem; the right solution is to deploy separate WiFi infra (sans any dhcp/routing/firewall/etc) hanging off the FreeBSD-powered LAN.
> the right solution is to deploy separate WiFi infra (sans any dhcp/routing/firewall/etc) hanging off the FreeBSD-powered LAN
Just came to say, this is exactly what I do. Firewall/router/dhcp/etc is FreeBSD and it’s great, but for wifi I use purpose built commercial grade hardware at home (Aruba personally, but honestly Ubiquiti, Meraki, Ruckus, etc would all be comparable).
Note that since FreeBSD 13, FreeBSD has been rebased and now uses ZFS on Linux rather than its own, separately developed and maintained ZFS stack. FreeBSD 13.1 upgrades to a newer release of ZoL, which is very important to note since the version that shipped with FreeBSD 13 had some notorious corruption bugs surrounding some of the newer ZoL features when sending/receiving snapshots with unmatched ZFS dataset record sizes or with native ZFS encryption (previously altogether unavailable for FreeBSD ZFS users) in use.
ZoL is still ironing out the remaining corruption bugs in these features, but the snapshot in FreeBSD 13.1 is a much more reliable option than the one that shipped with v13.
Note that users are not locked into the version that FreeBSD shipped with; you can actually installing rolling ZoL releases via ports/pkg and even use them for the system volume but that requires some reconfiguration (installing the port/pkg plus a minor conf file change to load the desired version of the ZFS kernel module) - but since most users don't do that, this should be a welcome upgrade.
FreeBSD used Illumos as upstream, then changed to OpenZFS, OpenZFS is the central project who wants to provide ZFS for Linux,Illumos and BSD and maybe others in the future.
>>The OpenZFS project brings together developers from the Linux, FreeBSD, illumos, MacOS, and Windows platforms. OpenZFS is supported by a wide range of companies.
The very first computer I used was a FreeBSD machine sitting in a small dark closet of my parents' house. Now that I'm all grown up, I run it on a Raspberry Pi and it makes me very very happy.
Such a joy to setup—so simple, so stable. Really happy to see that it keeps getting some love. :)
Anyone interested in FreeBSD and wondering about some of the upcoming stuff getting worked on might also want to keep an eye on the FreeBSD Foundation's updates on active development projects. For Q1 2022:
What do you consider to be minimal? The base installation is slim enough that people have been using an install-per-jail for a long time. There are just a few problematic ports that need to pull in huge dependencies, but if you're not installing a web browser, the dependencies aren't usually a huge issue.
Once nix works well we could just ("just") write nix packages for FreeBSD base, do... something for service management (openrc?), and then we have NixOS/FreeBSD. Not trivial, but doable.
The wireguard kernel module is available from ports and the 13.1 kernel should include the open crypto framework changes required allow if_wg(4) to make use of its fast SIMD-enabled multithreaded ChaCha20+Poly1305. Let's hope the next wireguard (for FreeBSD) release makes use of the new kernel features.
I'll be talking about this at BSDCan in a few weeks. (Virtual conference, so it's not too late to sign up!)