FreeBSD 14.0-Release
freebsd.org
freebsd.org
Open a account at https://bugs.freebsd.org/bugzilla/
Go to https://portscout.freebsd.org/ and find your outdated port (or port without maintainer (ports@freebsd.org))
Update port (makefile) open a bugreport add your diff and that's it...or ask to take additionally maintainership of that port.
I was too young to appreciate it back then, but now in my mid-40s I find myself hankering back to those early days for me. It's a shame that some cloud providers like DigitalOcean and Hetzner have dropped native support for FreeBSD as base operating systems for their VPSes. I think this release will be the turning point for me getting back into FreeBSD after too many years away.
Thanks to the FreeBSD release team!
But you are right, it's sad that hetzner dropped the "webinstall no hands-on" support.
https://github.com/paulc/hcloud-freebsd
(Allows you to provision instances using either the hcloud utility/web uni with ssh key/user-data support)
So, sure, if you've got a stand-alone B2C service that's making money today, enjoy your FreeBSD, SUSE, whatever. But if you're clients include big banks, chunks of governments, etc, think really hard about going off the reservation.
Netflix and Whatsapp can't be too wrong in their choice.
Most companies aren't Netflix, Whatsapp, Google, etc. Netflix can afford to run FreeBSD because they have staff that are intimately familiar with tuning it and hacking on the kernel. That's not most companies. No one said anything about entrenched systems that already use Linux or other systems.
GNU/Linux is entrenched pretty much everywhere at this point. Think about your stack. Does anything you use depend on GNU userland tools? Yeah, you'll get real good at rooting out hardcoded paths and dependencies on GNU extensions. Are your coworkers used to GNU tools? Well, there's a learning curve. Do you use nodejs at your company? The node maintainers actively refused to merge trivial patches to get current versions to build on FreeBSD (and the port itself stagnated).Evaluating something that's not-Linux is neat and cool, I get it. But the reality is switching will incur a heavy up front (and potentially long-term depending on the candidate pool) cost and lots of long-term paper cuts.
The ports tree has been an archaic mess for as long as I've been dicking around with FreeBSD (~2.2.2). Processors and disks have gotten fast enough that relying on make(1) isn't quite as painful as it was, but ok. To ease the pain, FreeBSD started offering binary packages a while ago via pkg(8).
Earlier this year I was evaluating upgrading 12 -> 13, so I fired up VirtualBox and installed 13.whatever. Out of the box pkg did not work. It started its bootstrap song and dance and fell flat on its face. Digging around on the forums came up with a work around to get everything bootstrapped and a working version of pkg installed, but still this was a known problem that made it out the door.
Meanwhile even with a working version of pkg, the FreeBSD mirrors are glacially slow. I've consistently gotten about 2Mbps max from them. Typically I'll get a few hundred kilobytes per second even on an un-throttled 10 Gbps connection with an Intel 825xx NIC.
So on the 12.x machine I set up varnish and pointed the jails at that. And all was well with the world. Until a few weeks ago when pkg again fell flat on its face. Turns out that somewhere along the way pkg went from "use SRV(!) records but fall back on CNAME/A" to "fail if there are no SRV records". Shame on me for not configuring pkg to ignore SRV records in the first place, but what the hell kind of breaking change is that in the middle of a product's lifecycle? That's 100% the kind of thing that should be synced up with the release of new major version of FreeBSD (e.g. 14), but doesn't because pkg straddles and blurs the boundaries between base system and 3rd party tools.
So. Yeah. FreeBSD's great for academic purposes. It's great if you want to push the limits of what's capable and you have staff who are competent kernel hackers. It's great if you can't use GPL licensed products. But for most things? It's a distraction.
What work?
Jails and bHyve has been fantastic for my pipeline. Sure you don't get a fancy GUI like Vmware provides but the hypervisor is solid.
I assume it just downloaded everything straight from FTP servers.
https://learn.microsoft.com/en-us/azure/virtual-machines/lin...
Once I opened a ticket to complain that it is listed under "Linux custom images", however the documentation team decided my complaint was withouth reasoning(!).
“FreeBSD 15.0 is not expected to include support for 32-bit platforms other than armv7. The armv6, i386, and powerpc platforms are deprecated and will be removed. 64-bit systems will still be able to run older 32-bit binaries.“
Also surprised they are cutting Power. That is one of the 4 platforms RHEL supports.
https://www.microchip.com/en-us/product/sam9x60
This was released in the year 2020, for example, the latest Atmel SAM Microprocessor. While ARM9 / ARMv5 is abnormally out-of-date (lol Nintendo DS was ARMv6), its still getting new chips even today.
ARMv7, consisting of Cortex-A5, A7, and similar chips, is also similarly widespread today. I don't know how much FreeBSD support there is but I can think of multiple chips that have been made in the past 5 years that are still 32-bit ARMv7.
In an embedded world that still buys 8-bit computers, 32-bit is a luxury and 64-bit is just too much.
----------
I'm only familiar with these chips from a Linux perspective however. But I have to imagine that some FreeBSD fanboi is hard at work porting FreeBSD to them!
EDIT: Lets see.... https://www.freebsd.org/platforms/arm/
Oh snap, Xilinx Zynq7 family. Yeah, that will do it. That's an extremely common chip (FPGA + ARMv7 / Cortex-A9).
Or developers.
They're cutting 32-bit Powerpc. It looks like powerpc64le support remains in FreeBSD14.
https://lwn.net/Articles/757042/
If anyone has a newer article, feel free to share.
FreeBSD 14.0 Release Information - https://news.ycombinator.com/item?id=38291436 - Nov 2023 (6 comments)
FreeBSD 14.0 has reached – RELEASE - https://news.ycombinator.com/item?id=38219578 - Nov 2023 (93 comments)
FreeBSD 14.0-RC1 Now Available - https://news.ycombinator.com/item?id=37881293 - Oct 2023 (17 comments)
FreeBSD 14.0-BETA2 Now Available - https://news.ycombinator.com/item?id=37532706 - Sept 2023 (7 comments)
Cant wait to see if they are doing 1600Gbps.
https://wiki.freebsd.org/Torrents
EDIT: Looks like they're up now!
Sounds pretty future proofed unless I'm missing a x86 processor out there that does this
Curious where this (rather large, yet still seemingly arbitrary) limit comes from.
It is Good Enough for now, while keeping various pre-allocated, statically created structures with-in reasonable size limits:
> Global and allocated arrays sized by MAXCPU result in excessive bloat on systems with lower core counts. In addition, some code used u_char (8 bits) to hold a CPU index, which is not valid if MAXCPU is greater than 256.
> A number of recent commits addressed these sorts of issues, including at least: […]
* https://cgit.freebsd.org/src/commit/?id=9051987e40c5
See:
> The SMP system now supports up to 1024 cores on amd64 and arm64. Many kernel CPU sets are now dynamically allocated to avoid consuming excessive memory. The kernel cpuset ABI has been updated to support the higher limit. 76887e84be97[1] d1639e43c589[2] 9051987e40c5[3] e0c6e8910898[4] (Sponsored by The FreeBSD Foundation)
* https://www.freebsd.org/releases/14.0R/relnotes/#kernel-gene...
[1] https://ark.intel.com/content/www/us/en/ark/products/231747/...
[2] https://www.supermicro.com/en/products/system/mp/6u/sys-681e...
That supermicro system is 8-way; it's 4 dual-socket motherboards but they're one system, hooked together by backplane boards. You can price supermicro's complete-system-only stuff (all of it now, alas) out on thinkmate or similar sites, but a minimal config (and you'd never buy that for a minimal config) hits around $60k.
The relevant parts of the ABI have been future proofed to allow raising the kernel CPU core count limit without breaking the syscall interface for systems with less cores than the existing limit.
Intel® Xeon® Platinum 8490H Processor
Total Cores 60
Total Threads 120
Max Turbo Frequency 3.50 GHz
Processor Base Frequency 1.90 GHz
Scalability S8S
Up to 60 x 8 = 480 cores or 960 threads AMD EPYC™ 9754
# of CPU Cores 128
# of Threads 256
Max. Boost Clock Up to 3.1GHz
All Core Boost Speed 3.1GHz
Base Clock 2.25GHz
Socket Count
1P / 2P
Up to 128 x 2 = 256 cores or 512 threadsUnfortunately, I need Docker for work on a few different projects -- one for Supabase migrations, and another project that's orchestrated (in development too) via docker-compose.
Highly recommend it otherwise.
NIC pass-through should work though, I already got NVMe pass-through working, so if I had a spare PCIe slot I'd do that with a 10G adapter.
E.g. every single major upgrade in recent memory has shat the bed. There's always a new reason, at one point it's because I rolled past the 3AM deadline and the periodic scripts absolutely fucked freebsd-update. So this time around I thought it'd be nice to script the 13.x install so I'd have a nice repeatable process.
Except the documentation around unattended installs still references sysinstall (which was replaced eons ago) in some parts. After quite a lot of digging I realized the automation story is "roll your own ISO". Nothing that even comes close to kickstart or quickstart in Linux land (geee no wonder AWS adoption is fairly low).
So I dug into some stuff that would've made automated installs from a stock ISO easier, got a proof of concept working and fired off an email to one of the names on the current installer (which is still missing features from sysinstall!). And that's where the story ends. I'm ready to get off of this train, and were it not for ZFS I would've already bailed.
Don't get me started on the ports tree.
I would not run FreeBSD in a production environment without a good reason. If you're already tied to docker that's a great reason to stay with Linux.
FreeBSD was another candidate but just skimming through the docs, what's easy on other systems looks painful there. Want to start a VM ? Here is a set of commands, different for every guest OS, with a bunch of unexplained options...
I'd say the opposite. A great reason to run from Linux.
https://github.com/freebsd/freebsd-src/tree/main/share/examp...
But yeah that pf.conf could be expanded allot, but there are many source to cobble a conf together. My conf is massive but 99.9% commented out so i have my "template" for nearly everything, from mail to web to blacklistd etc.
One of my most popular repos (which isn't saying a lot) is a single config file.
All is mixed from highly reliable and fast connections to dial-up "industry" stuff.
However that would be a good motivation to clean that monster up...hmmm
pfSense 2.7.0 is FreeBSD 14 based already and 2.7.1 was released todayish. You could try tearing their scripts apart to see what's what but bear in mind that pfSense is designed to be a router/firewall not a host based firewall, which sounds like what you really want.
It sounds like you want ufw or firewalld for FreeBSD. No idea if it exists and I am well passed DIY - I had custom scripts for ipfw, ipchains and iptables on Linux and then gave up. I don't use FreeBSD on the desktop but if I did ...
https://www.digitalocean.com/community/tutorials/how-to-conf...
or keep it simple:
https://www.digitalocean.com/community/tutorials/recommended...
You mention a web server. I suggest you keep the host firewall simple, this is in pseudo code:
allow ssh from LAN
allow monitoring_ip to monitoring_ports
drop blocklist_ips to ALL
allow https from ALL to webserver_ip
deny all
Your external router should keep most things out, the host firewall is a last resort. If you have a flat LAN, then this will keep your TV out etc. I have seen a TV port scan my home network, multiple times.If you can, consider deploying multiple VLANs. This does raise the technical bar somewhat! Host firewalls are just as good for small setups. Decide on what your security requirements really are and work on from there. I will grant you that is quite tricky for the uninitiated but keep asking questions and ducking the inevitable "RTFM" style answers from entitled numbskulls and you will get there.
Good luck 8)
I have six WANs at work - four FTTC 80/20Mbs-1, a 1Gbs-1 leased line and a 1000/300Mbs-1 FTTP job. All have IPv6 apart from the FTTP. I only push through the leased line /48 to inside but I do experiments with the IPv6 on the others. I have a /56 IPv6 at home too, for at least 10 years.
I have allowed all ICMPv6 on two out of the four FTTC lines and not noticed much difference. The other two only allow "useful" ICMP, where useful is similar to this: http://firehol.org/guides/icmpv6-recommendations/
Let your external router do the hard work. Your web server on the inside should allow all ICMPv6 in both directions. Just because it has a globally routeable IPv6 address(es) it is not on the outside. Your webserver's firewall is a host one, not an external router one. There is a big difference. Your webserver might be configured to think about itself only and your router's firewalling might consider everything from a high level.
I don't think you need a complicated policy on your webserver but one that stops you accidentally exposing, say, a MariaDB/MySQL to the outside world because you bind it to all interfaces instead of just ::1.
Interesting, so with my VPS on Vultr, there'd be an external firewall that takes care of the messier filtering?
Every single one (including pfSense) has their own variant. From what I can tell FreeBSD's taken bigger steps to sync up with OpenBSD than the rest, certainly bigger than pfSense.
If you use Jails, you have to upgrade them also, there are guides for this.
- Understand `gpart bootcode` (or equivalents), and be really sure that your low-level bootcode gets upgraded.
- If you're running zfs, `zpool checkpoint` can give you a way to rewind the entire state of the pool to a prior point. Used with some care, it can be extremely useful. Or just reassuring, as your "Plan B".
I didn't realize this and went down a rabbit hole of trying to recreate boot partitions which I found interesting.
With that said, I'm curious whether the upgrade procedure updates the bootcode on both drives in the mirror.
---
Slight tangent. The reason for playing around on the VM was that when I installed FreeBSD, I selected the zfs root auto-fs feature. It created a zfs partition that spanned the entire disk which I later decided that I didn't want. My goal was to shrink the zroot, and I was able to accomplish that using zfs send / receive and re-creating the partition withe the desired size. Fun exercise.
I need to revisit the installer to see if I'm able to provide any parameters to tune the size of the zroot. I really didn't want to create the filesystems manually from the installer shell.
If you're talking about a production environment, ideally your machines are more-or-less immutable anyways in which case you wouldn't be upgrading in place anyhow.
"WiFi 6 support has been added to wpa (wpa_supplicant(8) and hostapd(8)). c1d255d3ffdb 3968b47cd974 bd452dcbede6" https://www.freebsd.org/releases/14.0R/relnotes/
>Currently, iwm only supports 802.11b and 802.11g modes. It will not associate to access points that are configured to operate only in 802.11n or 802.11ac modes.
Thankfully, 802.11a seems to work, so I can use my 5 GHz radio. But it's not fast.
* https://www.freebsd.org/releases/14.0R/relnotes/#drivers-dev...
* https://man.freebsd.org/cgi/man.cgi?query=iwlwifi&manpath=Fr...
:(
or is this "old news" and it was rolled into an older release?
* https://lists.freebsd.org/archives/freebsd-current/2023-Nove...
tcp_rack(4) has been available since FreeBSD 13.0, just not the default:
* https://man.freebsd.org/cgi/man.cgi?query=tcp_rack&manpath=F...
An article from 2021:
* https://klarasystems.com/articles/using-the-freebsd-rack-tcp...
* 2021 Discussion: https://news.ycombinator.com/item?id=28549370
- OpenSSH has been updated to version 9.5p1.
- OpenSSL has been updated to version 3.0.12, a major upgrade from OpenSSL 1.1.1t in FreeBSD 13.2-RELEASE.
- The bhyve hypervisor now supports TPM and GPU passthrough.
- FreeBSD supports up to 1024 cores on the amd64 and arm64 platforms.
- ZFS has been upgraded to OpenZFS release 2.2, providing significant performance improvements.
- It is now possible to perform background filesystem checks on UFS file systems running with journaled soft updates.
- Experimental ZFS images are now available for AWS and Azure.
- The default congestion control mechanism for TCP is now CUBIC.
Post-2.2 OpenZFS has RAID-Z expansion committed:
* https://github.com/openzfs/zfs/discussions/15232
Also committed to FreeBSD -HEAD/development:
* https://github.com/freebsd/freebsd-src/commit/e716630d4cf89e...
Supernice.. I'm really looking forward to more separation between OS installs. similar to Qubes.
It's amazing how polished, supported and performant it is for the relative size of the team involved.
B. Please consider donating.
https://freebsdfoundation.org/donate/
C. I have much love for FreeBSD and as such, these are things I hope get address in the next major version (15.0)
- turning all internet facing services (except ssh) off, by default. OpenBSD does this.
- move all non-core things out of the base, like sendmail (now DMA, what a nice import from DFly btw)
- the base should only have one way to do things (don’t have 3 different firewalls in base like today)
- better defaults, https://vez.mrsk.me/freebsd-defaults.html
- something like io-uring, (async-sendfile is similar but that’s only for sendfile)
Thank you again for an amazing OS.
EDIT: I updated the first bullet of C for more clarity.
I think people would be rightfully upset if syslogd, cron, and getty weren't started by default. moused and a mailer daemon I get not wanting to start. What else starts by default that you don't want?
> - the base should only have one way to do things (don’t have 3 different firewalls in base like today)
I dunno about ipf; but ipfw and pf don't have complete overlap --- I need to use both to run my network how I want to (pfsync has no equivalent in ipfw, ipfw pipe/queue/sched doesn't have an equivalent in pf)
I meant internet facing services (e.g. not referring to cron, etc).