I daily drive FreeBSD on my desktop with KDE. It is not as smooth as Linux and requires a little more tinkering compared to Linux. But I love it!
The killer features for me:
- The pf firewall. Rules you actually understand!
- Jails! When you cannot have Zones this will do.
- Native ZFS. Stable, mature, safe and with all the features you can dream of.
- Linuxulator. Binary compatibility with Linux if need be. Can be put in jail as well.
- pkg/ports. I really like it but I might have been indoctrinated.
- Networking stack. Good. Stable. Makes sense to me.
For a nice graphical UI Linux is more smooth but if you are willing to tinker it can work. As Linux gets all the attention you will see stuff such as Chromium lag behind.
I can understand that can scare people off. But FreeBSD feels like a comfortable old glove for me. I will suffer the minor holes. My beard has grayed and my hair line is non-existant.
If waiting for a laptop I would perhaps wait for FreeBSD 15 for much needed improvements in WIFI. If you want fast WIFI today you need weird hacks routing through a Linux VM[1]. It works rather well but it is honestly a bit clunky.
I remember a hack, back in the day, on Linux where a Windows wifi driver was used via a thing called NDISwrapper. Be patient and hopefully you'll soon be looking back on your Linux VM bodge in the rear view mirror.
I feel like I'm seeing a lot about FreeBSD lately. I know they released a new version recently, but is there anything else going on? Is it picking up some steam? Or am I trapped in the algorithm?
I've tinkered with it in the past and I once had a job where we ran in on our servers. It seems pretty nice, but it never gets the attention Linux gets and the hardware support situation is sorta sad. I always chalked it up to the license and assumed people using it just don't contribute anything back. I love Linux and the support it receives from seemingly everyone these days, but it would be nice to have other options too.
> Besides that there is a bigger question that I need to answer for myself: given the quirks of FreeBSD, what actually would the benefit of using it be?
I'd say less maintenance, churn and deprecating knowledge. I've used FreeBSD as a desktop for the whole 5.*-branch (good times) and I am sure that I would still find myself home should I install it. Linux... not so much, though some distributions are better. There was that idea of "stable core and bleeding-edge applications" and freebsd did deliver, at least in those time, because ports and OS were not same, unlike in linux package management.
> and technically you can also use ZFS on Linux, even if it's painful
Maybe on some distros, but on Ubuntu is just an `apt-get install` away, or can be even be added from installation time. I've been using it for many years without any issues and the experience is great.
I actually combine some non-ZFS filesystems with ZFS with encryption and compression for all my setups, including my laptop. I plan to blog shortly about it and how I'm automating it all. Target is also a Framework laptop, too.
I recently looked into the BSDs for a desktop project before going back to Debian. I love the philosophy but they’re for the initiated.
The onboarding rails just aren’t there these days. Everyone says the BSD documentation is superb, but the man pages are more of a reference than an onboarding guide.
One major challenge is LLMs have a hard time with BSD-related prompts. They’re trained on so much more Linux content, and there’s just enough overlap between both systems that hallucination rates are extremely high in my experience.
> Everyone says the BSD documentation is superb, but the man pages are more of a reference than an onboarding guide.
If you try it again, the FreeBSD Handbook is the onboarding guide. [1] It's been a long while since I've set something up going from the Handbook, so I can't personally attest to its quality, but it's supposed to be good.
> One major challenge is LLMs have a hard time with BSD-related prompts. They’re trained on so much more Linux content, and there’s just enough overlap between both systems that hallucination rates are extremely high in my experience
I can't imagine they work well on Linux either, because different distributions have a different selection of tools, especially when you consider older documentation that's still out there and no longer works on mainstream distributions as tools have been replaced. The same is almost certainly true for MacOS and probably Windows as well. All of the OSes I can think of where most of the online documentation should be consistent probably don't have much online documentation. I'm not a LLM user (which is probably obvious), but I can't imagine how you'd get good information from it... at best, maybe you could get pointers to documentation you should read and understand yourself, or you could find the documentation and paste it to be summarized? People that use LLMs that I've tried to help with problems will tell me that the LLM told them X when it doesn't make sense and it actively contributes to their problem, so that doesn't give me confidence; of course, people who use LLMs and it solves their problem don't need my help, do they? :)
I "tested" the handbook recently (I think on FreeBSD 14 when it came out) and I can attest that the experience was flawless. It is even surprising that the right way to use it, is to follow a documentation and apply what it says, versus the Linux way which looks a lot more like "google your way through multiple different ways of doing the thing until you find the one that works".
They do, and they work better on Ubuntu/Debian than on e.g. Alpine, which in turn works better than some wonky Yocto build (ask me how I know). The mere existence of different distributions and tool selections is not the important factor here, but the amount of discourse there is in the training data. Debian and Debian-likes run the table here.
> For a server there's no reason for user A to be able to see processes of user B.
I'm not sure about that. This isn't FreeBSD specific so it's a bit tangential, but I've certainly debugged systems where someone thought it appropriate to run their intensive job on a live box (mind boggling, yes). Seeing it smack dab under their name is kind of important.
This is about unprivileged users - privileged ones can see everything. The idea is to make figuring out what's the surface of the attack harder (for those attackers who are less than skilled) by making it less obvious that 10 years old game server process is running on this OS.
I was really hoping that FreeBSD would support Apple Silicon, particularly the Mini. Hector Martin and friends did the hard and under appreciated work of the m1n1 bootstrap. Indeed, OpenBSD uses m1n1. However, the FreeBSD effort seems to have stalled.
FreeBSD has had a hard time supporting Intel Thinkpads, and they're making progress at getting better. Supporting Apple arm64 is a much heavier lift than that.
ASLR implemented at the mmap level in 32 bits(which was 100% of FreeBSD usage in 2005) is less than 20bits of randomness try 1M times and you've broken it add to that limitations in early implementations where large swaths of the address space were reserved for kernel and shared libraries and you're in a scenario where many of your exploits maybe fail to run the first couple of times and that's ignoring side channels or kernels such as Linux degrading back due to difficulty adapting some other feature to use ASLR.
Depending on what you are doing and what you wanna run you don't really need it.
For most use cases, just `pkg install -j` (-j is for jail) what you want.
Or just put the Linux binary (prefereably the musl/alpine one) in a thin jail it usually works.
I haven't tried podman in FreeBSD yet because from what I understand you can only run it as root right now, so it kind of defeat the purpose.
I have been daily driving FreeBSD for a while now (as a newcomer, coming from Linux) and surprisingly the experience for me was different from what you usually hear.
Pros:
- It is actually in a way easier than Linux. The installation is less complex and more reliable than a Fedora if you are not afraid of the TUI. More important it will soon include a desktop installation script.
- All the software you will ever need is in pkg or ports unless you are a degen
- You will pick up jails for container use cases in 10 minutes and will never want to go back
- VM with vm-bhyve is simpler than libvirt and no XML to deal with.
- Same with networking, you will pick it up quickly and no more confusion between NetworkManager, systemd-networkd, ifup, etc.
- The linux-compat feature will get you very far and there are a lot of Linux apps packaged already
A lot of your points are valid, however... some are taking some liberties. Are you actually running into usecases where FreeBSD is easier or faster to install than current release Fedora Server?
> The wifi thing is no problem with...
You're seriously proposing end users run Linux VMs with PCIe Passthrough to get modern networking cards to work?
A lot of wishful thinking in this thread about FreeBSD on workstations.
> A lot of your points are valid, however... some are taking some liberties. Are you actually running into usecases where FreeBSD is easier or faster to install than current release Fedora Server?
It is just that the Fedora installer is more complex... and also will fail often at partitioning or during install. I've done it hundreds of time and it failed dozens on time.
I would still recommend Fedora to Linux users but the FreeBSD installer much more simple and straightforward.
> You're seriously proposing end users run Linux VMs with PCIe Passthrough to get modern networking cards to work?
It is an Alpine running on the hypervisor you won't even notice it. It consumes less than web browser tab...
Plus it has benefits from a security point of view.
I would rather FreeBSD devs focus on other things than porting all wifi drivers.
I fondly remember working with FreeBSD in my younger days when I would tinker more.
Back in those days I could make any Windows installation unrecoverable. I could severely botch a Linux system. But FreeBSD would always keep chugging, no matter what crazy idea I wanted to try.
It may not be the fastest. It may not be the flashiest. But in my mind, it has this whole "reliability" thing written all over it like no other OS has.
For instance, when I was a student (and thus poor), I had a PC made of (free) scavenged parts. It wouldn't boot Windows. Linux would crash during boot. But FreeBSD just chugged along like there were no issues at all.
I later discovered there were some physical issues with the UDMA mode on the IDE controller, and that's probably what tripped of the other OSes, but FreeBSD would just work. Albeit slowly, but it actually ran fine. For years.
So while I no longer rely on FreeBSD myself, I look back on it with fondness. That's also why I decided to help port .NET to FreeBSD when the first cross-platform version of .NET Core was launched (for Windows, Linux and Mac only). I thought every decent OS deserved to have a working .NET version ;)
A little less than 25 years ago, my then-new day job wanted me to build them a new mail server, using Linux.
I'd put together one or two public-facing mail servers before, but it'd been a few years and the landscape had changed (postfix was the new hotness, sendmail was old news, etc). And I had a FreeBSD machine at home that I'd previously built from garbage that I was using for NAT and a few other things.
So, wanting to appear all slick and stuff at the new job, I built a prototype at home on that FreeBSD box using a freebie dyndns subdomain (which was still practical at that time).
It all worked great. For a couple of years I even used it to host my own email at home. It was less trouble to maintain than the Linux-based thing I'd built at work even though they both started with the same software configs.
But that FreeBSD box was only ever a little forgettable trash-built machine, so there were no backups at all when the hard drive crashed completely (there were grooves worn into the platters) while I was out of town.
Which might normally be the end of the story, but: FreeBSD kept rolling just fine. Whatever data was in RAM (which apparently included at least sshd and bash) remained in RAM and stayed usable, and it kept routing packets like nothing had ever happened at all.
I marveled at this for a few weeks as this very broken machine kept flawlessly doing its NAT duties and providing solid Internet access for my LAN until I scrounged up enough pennies to buy my first "home router": A Linksys WRT54GS. (That little hackable Linux box was a very fun introduction to the rabbit hole of using hardware in unintended ways, but that's a story for a different comment section.)
> For example, ZFS seems interesting but Btrfs is probably close enough for most people.
They are not directly comparable since ZFS is also the volume manager for your ZFS filesystems, enabling features like `zfs send` of snapshots or entire filesystems for easy backups.
> Let's start with the first and probably most important step: setting up the network. […] I don't fully remember how I actually set up the network as it's been a while, but it involved adding the following to `/etc/rc.conf`
All of the modern `rc.conf` examples will also be using `sysrc` instead of telling you to edit the file directly, at first as a first line of defense against fatfingering the file formatting, and later when you get more advanced as a way to transparently descend into Jails' `rc.conf`s without having to think about it: https://man.freebsd.org/cgi/man.cgi?query=sysrc
One thing FreeBSD's installer does not do a good job with that's very relevant for laptop usage is any automatic setup of hardware-specific kernel modules. You will want to enable either `coretemp` or `amdtemp` (depending on your particular Framework model) which will automatically populate all the sensor data, easily queried via `sysctl`:
e: and see my comment here about the quickstart firewall class options that let you avoid writing any of your own rules until you really want to! A laptop would do well with `firewall_type=client`: https://news.ycombinator.com/item?id=45794391
Meanwhile on linux, do I use netplan or NetworkManager or Systemd, maybe /etc/network/interfaces?
On the other hand, the lack of broad HW support means that my FreeBSD server burned 2x more power at low to mid usage levels than the same HW running Proxmox.
> They are not directly comparable since ZFS is also the volume manager for your ZFS filesystems, enabling features like `zfs send` of snapshots or entire filesystems for easy backups.
Btrfs supports both snapshots and sending/receiving them between different hosts. You can also create additional Btrfs subvolumes.
This is mostly what I meant with the differences between zfs and btrfs not being that significant for most: they largely seem to give you the same end result, instead taking a different path to get there. I do know that zfs is better in terms of reliability (or at least people love to bring that up), but it's something I don't have any experience with myself and thus can't comment on.
I daily drive FreeBSD on my desktop with KDE. It is not as smooth as Linux and requires a little more tinkering compared to Linux. But I love it!
The killer features for me:
- The pf firewall. Rules you actually understand!
- Jails! When you cannot have Zones this will do.
- Native ZFS. Stable, mature, safe and with all the features you can dream of.
- Linuxulator. Binary compatibility with Linux if need be. Can be put in jail as well.
- pkg/ports. I really like it but I might have been indoctrinated.
- Networking stack. Good. Stable. Makes sense to me.
For a nice graphical UI Linux is more smooth but if you are willing to tinker it can work. As Linux gets all the attention you will see stuff such as Chromium lag behind.
I can understand that can scare people off. But FreeBSD feels like a comfortable old glove for me. I will suffer the minor holes. My beard has grayed and my hair line is non-existant.
If waiting for a laptop I would perhaps wait for FreeBSD 15 for much needed improvements in WIFI. If you want fast WIFI today you need weird hacks routing through a Linux VM[1]. It works rather well but it is honestly a bit clunky.
[1] https://github.com/pgj/freebsd-wifibox
I remember a hack, back in the day, on Linux where a Windows wifi driver was used via a thing called NDISwrapper. Be patient and hopefully you'll soon be looking back on your Linux VM bodge in the rear view mirror.
I haven't realised Ndiswrapper was deprecated in Linux. I thought I was too lucky with my WiFi cards in the last 10-15 years!
I daily drive FreeBSD with IceWM, four screens 2@4k, 2@1080p running with Xorg on a Sapphire 5600XT, I can't fault any issues.
Exactly. When it works it is great.
I stick with a single 43" 4K@60 but it was a bit of a challenge to get on the happy path:
https://forums.freebsd.org/threads/intermittent-scanline-fli...
All systems can have issues. But the more widely used systems are at an advantage.
Honestly, the problem is always the f!@#ing hardware, isn't it
The reason all this is hard is likely a remnant of what Microsoft did in the 1990s to the point where Non Windows OSes are given the shaft
Nvidia, Broadcom, Wifi generally, whatever
I feel like I'm seeing a lot about FreeBSD lately. I know they released a new version recently, but is there anything else going on? Is it picking up some steam? Or am I trapped in the algorithm?
I've tinkered with it in the past and I once had a job where we ran in on our servers. It seems pretty nice, but it never gets the attention Linux gets and the hardware support situation is sorta sad. I always chalked it up to the license and assumed people using it just don't contribute anything back. I love Linux and the support it receives from seemingly everyone these days, but it would be nice to have other options too.
> Besides that there is a bigger question that I need to answer for myself: given the quirks of FreeBSD, what actually would the benefit of using it be?
I'd say less maintenance, churn and deprecating knowledge. I've used FreeBSD as a desktop for the whole 5.*-branch (good times) and I am sure that I would still find myself home should I install it. Linux... not so much, though some distributions are better. There was that idea of "stable core and bleeding-edge applications" and freebsd did deliver, at least in those time, because ports and OS were not same, unlike in linux package management.
> and technically you can also use ZFS on Linux, even if it's painful
Maybe on some distros, but on Ubuntu is just an `apt-get install` away, or can be even be added from installation time. I've been using it for many years without any issues and the experience is great.
I actually combine some non-ZFS filesystems with ZFS with encryption and compression for all my setups, including my laptop. I plan to blog shortly about it and how I'm automating it all. Target is also a Framework laptop, too.
I recently looked into the BSDs for a desktop project before going back to Debian. I love the philosophy but they’re for the initiated.
The onboarding rails just aren’t there these days. Everyone says the BSD documentation is superb, but the man pages are more of a reference than an onboarding guide.
One major challenge is LLMs have a hard time with BSD-related prompts. They’re trained on so much more Linux content, and there’s just enough overlap between both systems that hallucination rates are extremely high in my experience.
> Everyone says the BSD documentation is superb, but the man pages are more of a reference than an onboarding guide.
If you try it again, the FreeBSD Handbook is the onboarding guide. [1] It's been a long while since I've set something up going from the Handbook, so I can't personally attest to its quality, but it's supposed to be good.
> One major challenge is LLMs have a hard time with BSD-related prompts. They’re trained on so much more Linux content, and there’s just enough overlap between both systems that hallucination rates are extremely high in my experience
I can't imagine they work well on Linux either, because different distributions have a different selection of tools, especially when you consider older documentation that's still out there and no longer works on mainstream distributions as tools have been replaced. The same is almost certainly true for MacOS and probably Windows as well. All of the OSes I can think of where most of the online documentation should be consistent probably don't have much online documentation. I'm not a LLM user (which is probably obvious), but I can't imagine how you'd get good information from it... at best, maybe you could get pointers to documentation you should read and understand yourself, or you could find the documentation and paste it to be summarized? People that use LLMs that I've tried to help with problems will tell me that the LLM told them X when it doesn't make sense and it actively contributes to their problem, so that doesn't give me confidence; of course, people who use LLMs and it solves their problem don't need my help, do they? :)
[1] https://docs.freebsd.org/en/books/handbook/
I "tested" the handbook recently (I think on FreeBSD 14 when it came out) and I can attest that the experience was flawless. It is even surprising that the right way to use it, is to follow a documentation and apply what it says, versus the Linux way which looks a lot more like "google your way through multiple different ways of doing the thing until you find the one that works".
Thank you. I will try again soon. BSD is too compelling from a philosophical standpoint to set aside completely.
>I can't imagine they work well on Linux either
They do, and they work better on Ubuntu/Debian than on e.g. Alpine, which in turn works better than some wonky Yocto build (ask me how I know). The mere existence of different distributions and tool selections is not the important factor here, but the amount of discourse there is in the training data. Debian and Debian-likes run the table here.
> For a server there's no reason for user A to be able to see processes of user B.
I'm not sure about that. This isn't FreeBSD specific so it's a bit tangential, but I've certainly debugged systems where someone thought it appropriate to run their intensive job on a live box (mind boggling, yes). Seeing it smack dab under their name is kind of important.
Am I missing something?
This is about unprivileged users - privileged ones can see everything. The idea is to make figuring out what's the surface of the attack harder (for those attackers who are less than skilled) by making it less obvious that 10 years old game server process is running on this OS.
I was really hoping that FreeBSD would support Apple Silicon, particularly the Mini. Hector Martin and friends did the hard and under appreciated work of the m1n1 bootstrap. Indeed, OpenBSD uses m1n1. However, the FreeBSD effort seems to have stalled.
https://wiki.freebsd.org/AppleSilicon
FreeBSD has had a hard time supporting Intel Thinkpads, and they're making progress at getting better. Supporting Apple arm64 is a much heavier lift than that.
It took FreeBSD almost 20 years to implement ASLR:
https://svnweb.freebsd.org/base?view=revision&revision=34396...
Is security not a priority for their developers?
My impression is that ASLR just hasn't been well regarded and prioritized. See for example this tweet by cperciva: https://x.com/cperciva/status/1528971801983823872
ASLR implemented at the mmap level in 32 bits(which was 100% of FreeBSD usage in 2005) is less than 20bits of randomness try 1M times and you've broken it add to that limitations in early implementations where large swaths of the address space were reserved for kernel and shared libraries and you're in a scenario where many of your exploits maybe fail to run the first couple of times and that's ignoring side channels or kernels such as Linux degrading back due to difficulty adapting some other feature to use ASLR.
It looks like current versions of FreeBSD support Linux containers and podman. Can anyone speak to the experience and performance there?
Depending on what you are doing and what you wanna run you don't really need it. For most use cases, just `pkg install -j` (-j is for jail) what you want. Or just put the Linux binary (prefereably the musl/alpine one) in a thin jail it usually works.
I haven't tried podman in FreeBSD yet because from what I understand you can only run it as root right now, so it kind of defeat the purpose.
I have been daily driving FreeBSD for a while now (as a newcomer, coming from Linux) and surprisingly the experience for me was different from what you usually hear.
Pros:
- It is actually in a way easier than Linux. The installation is less complex and more reliable than a Fedora if you are not afraid of the TUI. More important it will soon include a desktop installation script.
- All the software you will ever need is in pkg or ports unless you are a degen
- You will pick up jails for container use cases in 10 minutes and will never want to go back
- VM with vm-bhyve is simpler than libvirt and no XML to deal with.
- Same with networking, you will pick it up quickly and no more confusion between NetworkManager, systemd-networkd, ifup, etc.
- The linux-compat feature will get you very far and there are a lot of Linux apps packaged already
- Hardware support is ok if you check first on https://bsd-hardware.info/
- The wifi thing is no problem with https://github.com/pgj/freebsd-wifibox
Cons:
- You won't be able to mount/read your LUKS drives from your Linux era.
- Sometime very critical packages like Chromium disappear because they won't build (for example no chromium in pkg on the current FreeBSD 15 BETA)
- Bhyve do not support SPICE so you are stuck with the perf of VNC.
- Bhyve do not have vsock so no blazing fast waypipe
- You basically loose a lot of security feature of web browsers, most of the sandboxing of Firefox and Chrome. This is really bad.
- I haven't really dived into it but it seems there is no Bluetooth LE
- It is fast but doesn't feel as fast as an Alpine
If you are thinking about it and this is ok for you, I would say go for it.
A lot of your points are valid, however... some are taking some liberties. Are you actually running into usecases where FreeBSD is easier or faster to install than current release Fedora Server?
> The wifi thing is no problem with...
You're seriously proposing end users run Linux VMs with PCIe Passthrough to get modern networking cards to work?
A lot of wishful thinking in this thread about FreeBSD on workstations.
> A lot of your points are valid, however... some are taking some liberties. Are you actually running into usecases where FreeBSD is easier or faster to install than current release Fedora Server?
It is just that the Fedora installer is more complex... and also will fail often at partitioning or during install. I've done it hundreds of time and it failed dozens on time.
I would still recommend Fedora to Linux users but the FreeBSD installer much more simple and straightforward.
> You're seriously proposing end users run Linux VMs with PCIe Passthrough to get modern networking cards to work?
It is an Alpine running on the hypervisor you won't even notice it. It consumes less than web browser tab...
Plus it has benefits from a security point of view.
I would rather FreeBSD devs focus on other things than porting all wifi drivers.
I fondly remember working with FreeBSD in my younger days when I would tinker more.
Back in those days I could make any Windows installation unrecoverable. I could severely botch a Linux system. But FreeBSD would always keep chugging, no matter what crazy idea I wanted to try.
It may not be the fastest. It may not be the flashiest. But in my mind, it has this whole "reliability" thing written all over it like no other OS has.
For instance, when I was a student (and thus poor), I had a PC made of (free) scavenged parts. It wouldn't boot Windows. Linux would crash during boot. But FreeBSD just chugged along like there were no issues at all.
I later discovered there were some physical issues with the UDMA mode on the IDE controller, and that's probably what tripped of the other OSes, but FreeBSD would just work. Albeit slowly, but it actually ran fine. For years.
So while I no longer rely on FreeBSD myself, I look back on it with fondness. That's also why I decided to help port .NET to FreeBSD when the first cross-platform version of .NET Core was launched (for Windows, Linux and Mac only). I thought every decent OS deserved to have a working .NET version ;)
A little less than 25 years ago, my then-new day job wanted me to build them a new mail server, using Linux.
I'd put together one or two public-facing mail servers before, but it'd been a few years and the landscape had changed (postfix was the new hotness, sendmail was old news, etc). And I had a FreeBSD machine at home that I'd previously built from garbage that I was using for NAT and a few other things.
So, wanting to appear all slick and stuff at the new job, I built a prototype at home on that FreeBSD box using a freebie dyndns subdomain (which was still practical at that time).
It all worked great. For a couple of years I even used it to host my own email at home. It was less trouble to maintain than the Linux-based thing I'd built at work even though they both started with the same software configs.
But that FreeBSD box was only ever a little forgettable trash-built machine, so there were no backups at all when the hard drive crashed completely (there were grooves worn into the platters) while I was out of town.
Which might normally be the end of the story, but: FreeBSD kept rolling just fine. Whatever data was in RAM (which apparently included at least sshd and bash) remained in RAM and stayed usable, and it kept routing packets like nothing had ever happened at all.
I marveled at this for a few weeks as this very broken machine kept flawlessly doing its NAT duties and providing solid Internet access for my LAN until I scrounged up enough pennies to buy my first "home router": A Linksys WRT54GS. (That little hackable Linux box was a very fun introduction to the rabbit hole of using hardware in unintended ways, but that's a story for a different comment section.)
Nicely done. Curious which VM host you used on the Mac?
FreeBSD has published a youtube video along with a blog post to run FreeBSD VM on Apple Silicon.
- https://www.youtube.com/watch?v=CWuZLJkUBfw
- https://freebsdfoundation.org/blog/three-ways-to-try-freebsd...
I'm using UTM (https://mac.getutm.app/), mostly because it seemed like the easiest thing to set up.
> For example, ZFS seems interesting but Btrfs is probably close enough for most people.
They are not directly comparable since ZFS is also the volume manager for your ZFS filesystems, enabling features like `zfs send` of snapshots or entire filesystems for easy backups.
> Let's start with the first and probably most important step: setting up the network. […] I don't fully remember how I actually set up the network as it's been a while, but it involved adding the following to `/etc/rc.conf`
This would be a great time to show off FreeBSD's documentation. A great “Step 1” would be https://man.freebsd.org/cgi/man.cgi?networking(7)
And then later on when people reasonably wonder what the heck else is going on in `rc.conf`: https://man.freebsd.org/cgi/man.cgi?query=rc.conf
All of the modern `rc.conf` examples will also be using `sysrc` instead of telling you to edit the file directly, at first as a first line of defense against fatfingering the file formatting, and later when you get more advanced as a way to transparently descend into Jails' `rc.conf`s without having to think about it: https://man.freebsd.org/cgi/man.cgi?query=sysrc
One thing FreeBSD's installer does not do a good job with that's very relevant for laptop usage is any automatic setup of hardware-specific kernel modules. You will want to enable either `coretemp` or `amdtemp` (depending on your particular Framework model) which will automatically populate all the sensor data, easily queried via `sysctl`:
- https://man.freebsd.org/cgi/man.cgi?coretemp
- https://man.freebsd.org/cgi/man.cgi?amdtemp
e: and see my comment here about the quickstart firewall class options that let you avoid writing any of your own rules until you really want to! A laptop would do well with `firewall_type=client`: https://news.ycombinator.com/item?id=45794391> https://man.freebsd.org/cgi/man.cgi?networking(7)
That document is a stunning illustration of beautiful simplicity.
Meanwhile on linux, do I use netplan or NetworkManager or Systemd, maybe /etc/network/interfaces?
On the other hand, the lack of broad HW support means that my FreeBSD server burned 2x more power at low to mid usage levels than the same HW running Proxmox.
> They are not directly comparable since ZFS is also the volume manager for your ZFS filesystems, enabling features like `zfs send` of snapshots or entire filesystems for easy backups.
Btrfs supports both snapshots and sending/receiving them between different hosts. You can also create additional Btrfs subvolumes.
This is mostly what I meant with the differences between zfs and btrfs not being that significant for most: they largely seem to give you the same end result, instead taking a different path to get there. I do know that zfs is better in terms of reliability (or at least people love to bring that up), but it's something I don't have any experience with myself and thus can't comment on.