I have migrated most of my personal stuff (like local fileservers, caldav / carddav and a few others) to FreeBSD jails in 2022 and haven't looked back. When a new release comes along I run `freebsd-update` and recreate my jails from Ansible, and that's that. A lot calmer than the churn that is modern Linux + Docker. And I get an awesome ZFS experience, too. I'm really happy.
That's calmer? You know what I do when a new Fedora release comes out? Nothing. My containers just work.
Sometimes a new network driver comes along, sometimes an old network driver is taken out, rarely affects me.
You rebuild your entire jail with Ansible every single release? You freebsd people are hilarious to me. I used to be one of you, from 2000 to 2009 I used FreeBSD for everything. I also used Perl for all scripting. I look back and am glad I moved on from that. For my mental health I'm glad.
Well, I'm managing a whole fleet of Docker (and, not too long ago, LXD) containers at work. So I definitely know that ecosystem.
Of course you can take any old Docker image and just run it as-is.
Just as I can simply run old FreeBSD releases in jails.
But that's not the whole story, is it? 3rd party dependency updates and whatnot.
And yes, I feel simply deleting my jails and letting my scripts recreate them feels calm to me. I haven't had anything break or require too much attention so far. Can't say that for all the Docker stuff.
And I always have the peace of mind that should my server hardware give up the ghost, I can always take a new computer, run my scripts, and have everything configured and running in no time because the procedures are exercised regularly.
What's the churn with docker? You don't have to update your docker files if you don't want to. I mean it's probably a bad idea to not update long term (security issues, etc), but that's also true for freebsd. Y
Because it's easy, because I like to stay up to date, because it's a good way to exercise the scripts that create them every now and then to make sure they still work as expected :)
I had the fun of briefly checking yesterday that the long-forgotten Vagrant packaging for 13.4-RELEASE still works.
It does! And FreeBSD is a real fun, calm little playground for those of us who spend most of our lives on Linux. I'd recommend people try it out if for no other reason than just to see how things could be done otherwise, and to get a chance to read Michael W. Lucas's stellar books on the topic.
I'm quite interested in putting FreeBSD on one of my dev servers. I had tried it back in July and got as far as installing Podman, but despite Podman for FreeBSD coming with a message that says many containers work with FreeBSD's Linux emulation¹, I couldn't even get the basic "hello world" container to start. I know FreeBSD has something called jails that are akin to containers, but I don't know anything about them and felt too frustrated being unable to get a simple Podman container off the ground.
I want to dedicate some time to trying it again soon.
Jails are not like containers but the technology enabling the containers. There's an ongoing effort to bring OCI container support to FreeBSD, backed by jails and ZFS.
> still; can't shake the image of my in-laws complaining about different desktop icons and "how are we supposed to work with this?"
Haha that's exactly how I feel! I'm not married to Podman/Docker/containers in general, I'd just been hoping to get my server migrated from an old Ubuntu setup over to FreeBSD that weekend. Migrating the sites and apps I had running on that old server from containers to jails, too, wasn't something I had planned for, and the weekend ran out of time before I could start looking into how I'd do it.
Most people have or should have already moved to 14. Some people can't, for example if they have binary kernel modules; we provide stable kernel interfaces within a major version but not between versions.
From my perspective though, the most useful thing about doing legacy branch releases is that it gives us a chance to practice the process. Mike Karels was supposed to be the release engineer for 13.4 -- his first release since BSD 2.x -- before he died on the way home from BSDCan, that is.
A number of people do not care enough for things getting better. The OS they are running is fine, it solves their problems and does not have gaping holes. But they do care a lot about things getting worse: something breaking during the upgrade, something degrading or becoming incompatible, and requiring more work just to get to the previous position. So an upgrade has basically no upside and a significant possible downside.
I'd say that you either live in a rolling mode, when you spread small-scale fixing and adaptation efforts over a long time, or you stick to a particular release and only apply security updates, and never upgrade, but instead build your new iteration from scratch using new versions of everything.
There are some people that like the stability of staying in a single branch for a longer period of time. Same as for example people staying on RHEL 8 vs RHEL 9 or Ubuntu 22.04 vs 24.04
For general purpose systems it doesn't make much sense to lag a release, the amount of breaking change is pretty minimal in FreeBSD these days and it is fairly common to run -CURRENT (main) in production so there aren't a lot of hidden dangers in a .0
Old school appliance vendors appreciate the old stable branches where they carry a lot of local changes.
Not recommended. We have backwards compatibility but not necessarily forwards compatibility within a stable branch; running a 13.4 userland on a 13.3 kernel could break horribly.
(My guess is that it's probably fine, simply because not much has happened on stable/13 in the last 6 months. But it's not uncommon to have e.g. new syscalls MFCed.)
I never said that it's recommended, just that you could do it.
Actually I completely agree with what you say. I've been forced to try at work a few times though, due to stupid reasons, it has worked out every time except once. Exactly due to what you mention.
The one time it didn't work out things exploded beautifully, so the stupid policy that we can't reboot is now scrapped. :-)
There are also security errata which require a reboot. Maybe if your device is not connected to a network you can get away with not updating / rebooting. But in 99% of the cases having a 700+ days of uptime is not a good thing anymore.
That's one nice thing about debian. For home servers I can setup auto updates once and forget about it till the next debian version is released. It will auto install security updates, reboot if necessary.
it's a tradeoff between fear that an update will break it and fear that a adversary will break it.
highly depends on the circumstances if/when auto-updates make sense, but once you have seen uptime in the decades range, most don't want to go back to ephemeral systems.
I have never seen a Debian system break due to auto-updates when they only subscribe to the common main, contrib and even non-free Debian repositories. They are incredibly stable and robust.
However one might want to use apt preferences/version pinning if they also use external non-debian repositories to e.g. install a newer version of PHP. Since some repositories keep different major versions in the same repository, an auto-update might otherwise install a version that causes an application to break.
That being said, most systems can probably get away with auto-updates and a little apt preference configuration and call it a day.
Mails are the correct way to do it. These kind of stops are what make *BSDs/Linux less prone to widespread attack vectors given how heterogeneous their populations are.
Yes, I'm assuming any kind of updates, security related or not, might be unsecure given less eyes looked at them due to their freshness.
Last time I’ve checked FreeBSD didn’t seem to handle mixed core types like the ones you find on recent intel and ARM processors very well. Did it changed?
I believe work is underway on HEAD but I don't think we'll see any of it in 13. Probably not even in 14. That sort of stuff is hard to merge without breaking KBIs.
I’ll get back to FreeBSD when the most popular wifi card by a wide margin (iwlwifi, Intel AX200/AX2xx) will start working. That’s a shame, FreeBSD was long known for quality networking, and now what?
Not even 802.11ac, and of course no 802.11ax or more recent modes. (802.11ac appeared in 2013). This means that you get about 2 MB/s from it, which makes it completely unusable in 2024.
Ah, even 802.11n is not supported! This is a 2009 standard. So we are left with 802.11a/b, which is 2003. The wifi of 21 years ago.
I'm connecting to remote SSH endpoints for 20+ years and the connection quality actually improved over the years. Some of these connections are not just encrypted text-based stuff, but tunnelled VNC and other more throughput-hungry use-cases for using SSH (than logging into remote text-based terminal).
I'm curious - what do you do, or what use-case do you have in mind, that renders 16 Mbit/s throughput "completely unusable"? I never required 16 Mbit/s throughput for... anything related to my work. It's enough even for high-quality video conferencing.
Your comment suggests that FreeBSD is a thing of a past and no longer capable of "quality networking", due to poor WiFi support. I can only agree with the poor WiFi support part. But WiFi is by no means something you can judge networking stack dedicated for servers.
FreeBSD was never designed for consumer hardware networking. There were a few "desktop distros" but all have more or less died, and the few FreeBSD-based "storage distros" moved to Linux after FreeBSD changed its upstream for ZFS. And I'm saying this as someone who made a lot of effort to use FreeBSD on laptop over the years, and a current user of 15.0-CURRENT on ThinkPad.
But FreeBSD was and is THE choice for high-bandwidth wired networking. Netflix is both an early adopter and an active contributor to FreeBSD's networking codebase. They hack FreeBSD[0] to achieve cool numbers over and over[1][2].
Intel's device mentioned by you - AX200 - works "fine" on my ThinkPad, for a few months now. The device was on supported hardware list for more than a year prior, but the actual driver wasn't covering all vendor/device id pairs (different flavors of hardware or behavior all known as "the same" chip; this is a major problem with consumer devies since chip outages started).
That said, by "fine" I mean that I can use the card and finally can connect to 5GHz networks and avoid disruptions related to 2.4GHz congestion. But FreeBSD is still incapable of utilizing speeds offered by modern WiFi specifications. Even with 5GHz connection, only throughput typical for 802.11n can be expected.
At this point, I guess that modern WiFi (as protocol/specification) support will only mature in form of drivers ingested from Linux, and emulated via LinuxKPI[3]. And it's great! I'm using Ryzen's Radeon features and DRM stuff on FreeBSD thanks to the LinuxKPI compatibility layer, for a few years now.
It's great that whenever FreeBSD can suck some non-GPL codebase from Linux via extending its "compatibility layer" - there's no major hostility. FreeBSD failed with evolving WiFi support on it's own. KPI worked great with amdgpu/DRM, and I have high hopes that Linux codebase will allow FreeBSD to evolve its WiFi support most reasonably.
I have migrated most of my personal stuff (like local fileservers, caldav / carddav and a few others) to FreeBSD jails in 2022 and haven't looked back. When a new release comes along I run `freebsd-update` and recreate my jails from Ansible, and that's that. A lot calmer than the churn that is modern Linux + Docker. And I get an awesome ZFS experience, too. I'm really happy.
That's calmer? You know what I do when a new Fedora release comes out? Nothing. My containers just work.
Sometimes a new network driver comes along, sometimes an old network driver is taken out, rarely affects me.
You rebuild your entire jail with Ansible every single release? You freebsd people are hilarious to me. I used to be one of you, from 2000 to 2009 I used FreeBSD for everything. I also used Perl for all scripting. I look back and am glad I moved on from that. For my mental health I'm glad.
“You FreeBSD people”?
This is not standard practice managing jails which you should know if you were a FreeBSD user for 9 years.
Updating FreeBSD and jails is dead simple. https://docs.freebsd.org/en/books/handbook/jails/#jail-upgra...
Well, I'm managing a whole fleet of Docker (and, not too long ago, LXD) containers at work. So I definitely know that ecosystem.
Of course you can take any old Docker image and just run it as-is.
Just as I can simply run old FreeBSD releases in jails.
But that's not the whole story, is it? 3rd party dependency updates and whatnot.
And yes, I feel simply deleting my jails and letting my scripts recreate them feels calm to me. I haven't had anything break or require too much attention so far. Can't say that for all the Docker stuff.
And I always have the peace of mind that should my server hardware give up the ghost, I can always take a new computer, run my scripts, and have everything configured and running in no time because the procedures are exercised regularly.
>For my mental health I'm glad.
And the FreeBSD community too ;)
To me, FreeBSD Jails are by far the best of the breed. If you are running servers, you really should look into jails.
Congratulations on the new release.
What's the churn with docker? You don't have to update your docker files if you don't want to. I mean it's probably a bad idea to not update long term (security issues, etc), but that's also true for freebsd. Y
`freebsd-update` updates only the base systems though. Updating ports is a trainwreck on FreeBSD compared with `dist-upgrade` on Debian.
>Updating ports is a train-wreck on FreeBSD compared with `dist-upgrade` on Debian.
Well if one does not know about packages the ones knowledge is a train-wreck too then? I works perfectly fine...since forever.
>pkg upgrade<
Updating ports is simple, but why aren’t you using pkg?
Why do you recreate your jails? Just upgrade them or leave them on the older version, for example host=14.x jails=13.x
Because it's easy, because I like to stay up to date, because it's a good way to exercise the scripts that create them every now and then to make sure they still work as expected :)
I had the fun of briefly checking yesterday that the long-forgotten Vagrant packaging for 13.4-RELEASE still works.
It does! And FreeBSD is a real fun, calm little playground for those of us who spend most of our lives on Linux. I'd recommend people try it out if for no other reason than just to see how things could be done otherwise, and to get a chance to read Michael W. Lucas's stellar books on the topic.
I'm quite interested in putting FreeBSD on one of my dev servers. I had tried it back in July and got as far as installing Podman, but despite Podman for FreeBSD coming with a message that says many containers work with FreeBSD's Linux emulation¹, I couldn't even get the basic "hello world" container to start. I know FreeBSD has something called jails that are akin to containers, but I don't know anything about them and felt too frustrated being unable to get a simple Podman container off the ground.
I want to dedicate some time to trying it again soon.
[1] https://www.freshports.org/sysutils/podman/
Jails are not like containers but the technology enabling the containers. There's an ongoing effort to bring OCI container support to FreeBSD, backed by jails and ZFS.
we all know that feeling. nbd
podman/docker seem heavily entrenced in linux land, might be worth to check out alternatives. fwiw jails are much simpler to understand and use.
still; can't shake the image of my in-laws complaining about different desktop icons and "how are we supposed to work with this?"
> still; can't shake the image of my in-laws complaining about different desktop icons and "how are we supposed to work with this?"
Haha that's exactly how I feel! I'm not married to Podman/Docker/containers in general, I'd just been hoping to get my server migrated from an old Ubuntu setup over to FreeBSD that weekend. Migrating the sites and apps I had running on that old server from containers to jails, too, wasn't something I had planned for, and the weekend ran out of time before I could start looking into how I'd do it.
I'm going to take another whack at it soon.
With 14 already out for a long time, do many stay on 13 still?
Most people have or should have already moved to 14. Some people can't, for example if they have binary kernel modules; we provide stable kernel interfaces within a major version but not between versions.
From my perspective though, the most useful thing about doing legacy branch releases is that it gives us a chance to practice the process. Mike Karels was supposed to be the release engineer for 13.4 -- his first release since BSD 2.x -- before he died on the way home from BSDCan, that is.
A number of people do not care enough for things getting better. The OS they are running is fine, it solves their problems and does not have gaping holes. But they do care a lot about things getting worse: something breaking during the upgrade, something degrading or becoming incompatible, and requiring more work just to get to the previous position. So an upgrade has basically no upside and a significant possible downside.
I'd say that you either live in a rolling mode, when you spread small-scale fixing and adaptation efforts over a long time, or you stick to a particular release and only apply security updates, and never upgrade, but instead build your new iteration from scratch using new versions of everything.
There are some people that like the stability of staying in a single branch for a longer period of time. Same as for example people staying on RHEL 8 vs RHEL 9 or Ubuntu 22.04 vs 24.04
For general purpose systems it doesn't make much sense to lag a release, the amount of breaking change is pretty minimal in FreeBSD these days and it is fairly common to run -CURRENT (main) in production so there aren't a lot of hidden dangers in a .0
Old school appliance vendors appreciate the old stable branches where they carry a lot of local changes.
Updating to 14 requires a reboot.
Updating to 13.4-RELEASE also requires a reboot.
You are correct, but you can install the new userland without a reboot, you will not get the benefit of an updated kernel though.
With FreeBSD 14 you definitely have to reboot.
Not recommended. We have backwards compatibility but not necessarily forwards compatibility within a stable branch; running a 13.4 userland on a 13.3 kernel could break horribly.
(My guess is that it's probably fine, simply because not much has happened on stable/13 in the last 6 months. But it's not uncommon to have e.g. new syscalls MFCed.)
I never said that it's recommended, just that you could do it.
Actually I completely agree with what you say. I've been forced to try at work a few times though, due to stupid reasons, it has worked out every time except once. Exactly due to what you mention.
The one time it didn't work out things exploded beautifully, so the stupid policy that we can't reboot is now scrapped. :-)
There are also security errata which require a reboot. Maybe if your device is not connected to a network you can get away with not updating / rebooting. But in 99% of the cases having a 700+ days of uptime is not a good thing anymore.
Not really no. I moved my desktop to 14 when 14.1 came out.
But it's really nice that there's always two production releases so you have plenty of time to migrate.
https://www.freebsd.org/releases/13.4R/relnotes/
Does freebsd have the debian equivalent of unattended-upgrades? I want to setup auto security updates and forget about it.
It's not recommended, but you can run freebsd-update and pkg upgrade non-interactively.
This is not recommended. The recommended way is to set the weekly_status_pkg_enable flag and check email often.
https://man.freebsd.org/cgi/man.cgi?periodic.conf
That's one nice thing about debian. For home servers I can setup auto updates once and forget about it till the next debian version is released. It will auto install security updates, reboot if necessary.
it's a tradeoff between fear that an update will break it and fear that a adversary will break it.
highly depends on the circumstances if/when auto-updates make sense, but once you have seen uptime in the decades range, most don't want to go back to ephemeral systems.
I have never seen a Debian system break due to auto-updates when they only subscribe to the common main, contrib and even non-free Debian repositories. They are incredibly stable and robust.
However one might want to use apt preferences/version pinning if they also use external non-debian repositories to e.g. install a newer version of PHP. Since some repositories keep different major versions in the same repository, an auto-update might otherwise install a version that causes an application to break.
That being said, most systems can probably get away with auto-updates and a little apt preference configuration and call it a day.
I never had a debian installation break from automated security updates.
You should never have auto updates on a production server but for home servers and desktops they are vital.
somewhere the line got blurry
Mails are the correct way to do it. These kind of stops are what make *BSDs/Linux less prone to widespread attack vectors given how heterogeneous their populations are.
Yes, I'm assuming any kind of updates, security related or not, might be unsecure given less eyes looked at them due to their freshness.
Last time I’ve checked FreeBSD didn’t seem to handle mixed core types like the ones you find on recent intel and ARM processors very well. Did it changed?
I believe work is underway on HEAD but I don't think we'll see any of it in 13. Probably not even in 14. That sort of stuff is hard to merge without breaking KBIs.
I’ll get back to FreeBSD when the most popular wifi card by a wide margin (iwlwifi, Intel AX200/AX2xx) will start working. That’s a shame, FreeBSD was long known for quality networking, and now what?
According to the "Supported Hardware" list AX200 is supported: https://wiki.freebsd.org/WiFi/Iwlwifi#Supported_Hardware
Not even 802.11ac, and of course no 802.11ax or more recent modes. (802.11ac appeared in 2013). This means that you get about 2 MB/s from it, which makes it completely unusable in 2024.
Ah, even 802.11n is not supported! This is a 2009 standard. So we are left with 802.11a/b, which is 2003. The wifi of 21 years ago.
I'm connecting to remote SSH endpoints for 20+ years and the connection quality actually improved over the years. Some of these connections are not just encrypted text-based stuff, but tunnelled VNC and other more throughput-hungry use-cases for using SSH (than logging into remote text-based terminal).
I'm curious - what do you do, or what use-case do you have in mind, that renders 16 Mbit/s throughput "completely unusable"? I never required 16 Mbit/s throughput for... anything related to my work. It's enough even for high-quality video conferencing.
Well, downloading 1GB of updates, or a 15GB dataset is a pretty common occurrence.
Your comment suggests that FreeBSD is a thing of a past and no longer capable of "quality networking", due to poor WiFi support. I can only agree with the poor WiFi support part. But WiFi is by no means something you can judge networking stack dedicated for servers.
FreeBSD was never designed for consumer hardware networking. There were a few "desktop distros" but all have more or less died, and the few FreeBSD-based "storage distros" moved to Linux after FreeBSD changed its upstream for ZFS. And I'm saying this as someone who made a lot of effort to use FreeBSD on laptop over the years, and a current user of 15.0-CURRENT on ThinkPad.
But FreeBSD was and is THE choice for high-bandwidth wired networking. Netflix is both an early adopter and an active contributor to FreeBSD's networking codebase. They hack FreeBSD[0] to achieve cool numbers over and over[1][2].
Intel's device mentioned by you - AX200 - works "fine" on my ThinkPad, for a few months now. The device was on supported hardware list for more than a year prior, but the actual driver wasn't covering all vendor/device id pairs (different flavors of hardware or behavior all known as "the same" chip; this is a major problem with consumer devies since chip outages started). That said, by "fine" I mean that I can use the card and finally can connect to 5GHz networks and avoid disruptions related to 2.4GHz congestion. But FreeBSD is still incapable of utilizing speeds offered by modern WiFi specifications. Even with 5GHz connection, only throughput typical for 802.11n can be expected.
At this point, I guess that modern WiFi (as protocol/specification) support will only mature in form of drivers ingested from Linux, and emulated via LinuxKPI[3]. And it's great! I'm using Ryzen's Radeon features and DRM stuff on FreeBSD thanks to the LinuxKPI compatibility layer, for a few years now.
It's great that whenever FreeBSD can suck some non-GPL codebase from Linux via extending its "compatibility layer" - there's no major hostility. FreeBSD failed with evolving WiFi support on it's own. KPI worked great with amdgpu/DRM, and I have high hopes that Linux codebase will allow FreeBSD to evolve its WiFi support most reasonably.
[0] https://www.youtube.com/watch?v=q4TZxj-Dq7s
[1] (400Gbps PDF) https://people.freebsd.org/~gallatin/talks/euro2021.pdf
[1] (400Gbps video) https://www.youtube.com/watch?v=_o-HcG8QxPc
[2] (800Gbps PDF) https://people.freebsd.org/~gallatin/talks/euro2022.pdf
[2] (800Gbps video) https://www.youtube.com/watch?v=_o-HcG8QxPc
[3] https://wiki.freebsd.org/LinuxKPI
They were known for their high quality network stack, not driver support
Well, “high-quality network stack” includes wifi, and wifi includes 802.11ax, and there is basically no modern wifi at all on FreeBSD, so…
(I understand that it is mostly a server OS, and usually there is no wifi on servers, but still).
That’s a little sad, because FreeBSD pioneered the wifi stack, it was better than Linux back in the days.
Go shout at the vendor for creating Linux only blobs. Or better yet shout at them to open source.
Drivers are not a BSD problem inherently. More one of that vendors are not contributing to other mainstream OSes.