FreeBSD 13.1 | Hacker News Reader

FreeBSD 13.1

freebsd.org

134 pointsSpaceInvader67 comments

Open articleView on HN

My contribution: FreeBSD 13.1 boots significantly faster than FreeBSD 13.0; in EC2 it's over a 2x speedup.

I'll be talking about this at BSDCan in a few weeks. (Virtual conference, so it's not too late to sign up!)

Thank you for what you do.

Awesome, how did you do that?

We use plenty of short-lived FreeBSD agents for our (AWS-hosted) CI builds, so a 2x speed up would be very welcome!

Boot Loader Changes

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)

Also, for IPv6 users:

> 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

Identifying slow pieces of boot: https://github.com/freebsd/freebsd-src/search?q=TSENTER , etc: https://github.com/freebsd/freebsd-src/blob/main/sys/sys/tsl... , and then eliminating low hanging fruit (many, but not all of his recent commits): https://freshbsd.org/freebsd/src/branch/main?merge=false&aut...

As loeg says, profiling and then working my way through the list of places we're spending a lot of time.

I'd love to hear more about how you're using FreeBSD/EC2; can you send me an email?

Nice work, you are a champ. Anything fun and new planned with tarsnap by any chance?

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.

Congrats on the kiddo.

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. :-/

Gotta love those FOMO babies!

Congrats! Crawling at 2 months! My 10 month old is just learning to crawl. I blame his giant head.

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).

Congratulations! I had no idea you had a kid. You have good dad energy! This is great to hear. Don't send her to college at age 9.

Planning on waiting until she's 12. (I did start teaching her differential calculus before we left the hospital though.)

Ahh, good, good, you're going to make her wait until she's finished all the exercises in Spivak's Calculus. I approve.

I think I prompted you to look into this a few years ago:

https://news.ycombinator.com/item?id=26051254#26051847

Anyways, thanks for all of your work :)

As I said in that thread, I started working on this in 2017 (indeed, the tslog profiling I encouraged you to try was my first step).

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.

It's a kludge, but for pulling data off ext* you could run Linux in bhyve, pass in the device/partition, and then NFS mount back to the host.

Oh nono, don't use the fuse-way for ext3/4, freebsd has builtin support for it...and it's muchmuchmuch better:

# Load the kernel module

kldload ext2fs

# mount

mount -t ext2fs -o ro /dev/<device/partition> <mountpoint>

# Exmaples:

mount -t ext2fs -o ro /dev/ad1s1 /mnt/

# Or on a different partition scheme (p vs s):

mount -t ext2fs -o ro /dev/ada0p1 /mnt/

https://forums.freebsd.org/threads/howto-mount-ext4-without-...

Okay I'll check it out nix23. I thought I tried that, but will redouble efforts. Many thanks!

> really crap ext3/4 filesystem support

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.

I don't need much pushing, I'm almost ready to migrate the lot to ZFS. Gonna try loading a kernel module one more time as nix23 prompted.

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.

What do you like most about FreeBSD over Ubuntu?

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.

I should have clarified, proprietary software that needs to be compiled and distributed; GPL compels disclosure of the source code in this case.

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?

Same as last time: implementing it is non-trivial and very few people are working on it.

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)

https://www.freebsd.org/cgi/man.cgi?query=iwlwifi&apropos=0&...

https://www.freebsd.org/cgi/man.cgi?query=iwm&apropos=0&sekt...

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).

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!

Funny how in 2004/05 I had a lot less problems using FreeBSD on a laptop than Linux (as a complete newbie as well), maybe it was a fluke :P

Just run your wifi driver in a Linux vm. https://github.com/pgj/freebsd-wifibox

I'm beginning to think I should've coached my comment with lines acknowledging the basic responses like this.

I'm aware of that project, though I appreciate the response nonetheless.

I like FreeBSD. It makes me happy. Thank you, FreeBSD contributors.

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.

It uses OpenZFS.

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.

https://openzfs.org/wiki/Main_Page

>>The OpenZFS project brings together developers from the Linux, FreeBSD, illumos, MacOS, and Windows platforms. OpenZFS is supported by a wide range of companies.

Congrats to the team! And a special thanks to cperciva for all the work he's done specifically for BSD in EC2.

It's hard to imagine that my FreeBSD journey started with 3.1, and I'm glad to see it's still going strong (and why I keep donating to the project).

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:

https://freebsdfoundation.org/blog/q1-2022-software-developm...

Lots of good stuff in the pipe, not just features like kernel WireGuard or improved WiFi but basic support stuff like improving/updating the Handbook.

Are there any plans for a “minimal” version of FreeBSD?

(similar in concept to what various linux distros release, allowing for super slim servers OS)

That's one of the motivations for pkgbase. Which will land... checks notes... any decade now?

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.

The number of definitions of a minimal install is maximal.

Here you go buddy ;)

https://github.com/michaeldexter/occambsd

But FreeBSD in itself is already as slim as ~possible (because no installed pkg's)

mfsBSD was the minimal version I found (a few years ago) for use in a netboot environment (loads into memory)

https://mfsbsd.vx.sk/

Anyone knows if the pf syncookie made it to 13.1?

https://freebsdfoundation.org/wp-content/uploads/2022/03/Por...

Matching releng/13.1 source to D31138, it did.

Source: https://cgit.freebsd.org/src/tree/sys/modules/pf/Makefile?h=...

D31138: https://reviews.freebsd.org/D31138

Thank you

I love me some FreeBSD.

I wish FreeBSD had something at the OS-level like NixOS.

(yes I’m aware that nix packages exists)

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.

This is Unix I know this.

I have never been as excited in a movie theater as when I heard that quote at 12.

I was hoping 13.1 has wireguard. Cannot find it.

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.

Reply on news.ycombinator.com