My home server has been running FreeBSD for ten years now, and it has never let me down. Except for one time I got fresh with /dev/speaker and triggered a spontaneous reboot (I don't know if it's FreeBSD's fault or the hardware, though).
I delayed upgrading to 15.0 after it was released, but last weekend I finally did it, and it left me wondering why I hadn't done it sooner, because it went quickly and smoothly.
Is there anything FreeBSD can do that, say, Debian cannot? Probably not (at least I cannot think of anything). When I set up the server, ZFS was a huge selling point, but I heard that it works quite well on Linux, these days. But I appreciate the reliability, the good documentation, the community (when I need help).
There are various niche applications where Debian or any Linux are worse than FreeBSD.
For example the support for magnetic tapes and for a few other SCSI peripherals is better in FreeBSD. The Linux utility for controlling a LTO tape drive lacks some important options that the corresponding FreeBSD utility has.
I have a tape drive, and to be able to use it like I want I had to move it to a FreeBSD server.
Some years ago I was using a surveillance camera that was much easier to use in FreeBSD than in Linux, if you wanted to record good quality video and audio. I have not tried more recently to use such cameras in Linux, to see if now the recording quality is better.
So while there are more hardware devices that have better support in Linux than in FreeBSD, there are also devices with better support in FreeBSD than in Linux.
However the main reason why I use FreeBSD on many of my servers is that I need much less time for their administration than for Linux servers. In my experience, Linux servers need much less time for administration than Windows servers, and FreeBSD compares to Linux like Linux to Windows.
I have FreeBSD servers that I have not touched for years, and they have worked 24/7 with no downtime and no rebooting, and this includes servers connected directly to the Internet, which implement firewalls, routers and various services, like NTP, DNS servers and proxies, e-mail servers, web servers and proxies etc.
> I have FreeBSD servers that I have not touched for years, and they have worked 24/7 with no downtime and no rebooting, and this includes servers connected directly to the Internet, which implement firewalls, routers and various services, like NTP, DNS servers and proxies, e-mail servers, web servers and proxies etc.
Same. We've got qmail config files with 2006 as the mtime
Well, my experience on the stable release branches is that there aren't all that many kernel updates, so if you keep your services patched then you really only need to reboot about every 6 months.
The longest without rebooting two prod FreeBSD servers I was once responsible for, including applying userland patches, was roughly 3000 days (just over 8 years).
Fair, but to my point none of those security patches for 14.2 or 14.3 that required a reboot were critical for our use case. I'm more worried about people's crappy Wordpress blogs getting hacked.
My approach to IT security starts from: There is very little security. That stands regardless of OS.
I patch everything I can think of, as regularly as I can think of. It is rare that a patch is delivered along with a changelog along the lines of "meh, lol, soz" I'm old enough to remember when the notion of a patch was the only term in play, well before "service packs".
I'm jolly boring and run host based firewalls and router, switch, edge etc firewalls, mostly with point to point rules. Its a bit of a faff and so is completely random and different passwords and targeted MFA on each host. I'm fairly sure it is quite hard to pivot across my land.
The best approach to security is to start with: "Mine is a bit shite" and "I'm probably already compromised" and work from there. In the real world: start with a threat model and work on out. For most people that is avoiding scams and becoming part of a bitcoin farm.
Cameras? I suppose the world still has some weird cameras that need proprietary/weird drivers, but for all intents and purposes: USB cameras are UVC and work with a generic driver, and IP cameras are OnVIF and work with ffmpeg. I can't imagine the latter having any OS dependencies as far as Linux/BSD/Mac/Windows is concerned. Quality is fine - I have a bunch recording 24/7 with high quality audio and video.
> Some years ago I was using a surveillance camera that was much easier to use in FreeBSD than in Linux, if you wanted to record good quality video and audio. I have not tried more recently to use such cameras in Linux, to see if now the recording quality is better.
A Logitech FullHD camera on USB, but I doubt that the problem was camera-specific. I believe that I would have seen the same behavior on any high-resolution USB camera.
In FreeBSD, the command required for recording was very simple and it worked flawlessly. In Linux, it was more complex and there were various stuttering problems at maximum resolution. I am still using those cameras, but I have not tried them again in Linux. In Linux they worked worse than in FreeBSD around 5 years ago, perhaps nowadays there is no longer any problem in Linux.
This was intended to be an example that you cannot know a priori whether a given device will work better on FreeBSD or on Linux. In general, there is a greater probability for Linux to have good support than for FreeBSD, but there are also counterexamples, so you cannot be certain which is better until you try both.
I am sorry, I have a hard time accepting this level of detail, acknowledging it was half a decade ago.
In a nutshell, you content that FreeBSD running on the same hardware as "a linux" performed better with camera operations. However, you did not specify even a specific camera model, or the interface(s) used to interact with the camera.
I have zero issue accepting that a BSD is better than a linux at things, pretending otherwise is foolish. However, this specific example isn't tracking.
I have already said that it was an USB camera, using the UVC protocol, and that it had FullHD resolution. Nothing else really matters about the interface.
FreeBSD has a dedicated service for USB cameras, webcamd, and it worked very well for capturing video and audio at maximum resolution, and without interference from any other programs that were running concurrently on the server. As I have said, in Linux not only the required configuration was more complex, but I tried several programs and all had stutter problems at FullHD resolution (while other programs were also running on the computer). That was the status at that time. Now, many kernel versions later, I assume that such problems no longer exist, at least not with old cameras.
I do not see what is not tracking for you in this example. It is not an isolated example, for many years FreeBSD was known to have less problems than Linux in handling video streams and audio streams with low latency and constant throughput. More recently, Linux has also improved, but in the past unreliable performance with certain video/audio devices was not unusual (i.e. where other programs running concurrently caused video/audio drops or delays).
That’s fair. I’m struggling to understand how Linux had a harder time interfacing with a USB byte stream than a bsd would. A model for the camera would be great!
I think that it was the Logitech C920, which is still available.
But like I have said, I do not think that the model mattered much. IIRC the camera had an internal video encoder, because otherwise uncompressed FullHD video would not pass through USB 2.0.
The differences between FreeBSD and Linux at that time were at 2 levels. Regarding the user interface, FreeBSD happened to include in the base system programs dedicated for using such a camera, so their use was very simple. On Linux I had to search and install a suitable package, and those that were available were more general video applications and because of that their configuration to do the specific thing that I needed was more complex.
Besides the simpler interface, there was the stuttering problem on Linux, which was caused by the scheduling policies of the kernel. Perhaps it would have been possible on Linux to find a way to ensure a higher priority for the video and audio handling, to not be preempted by the concurrent programs running on the server, but since on FreeBSD everything worked fine out of the box there was no reason for me to investigate how that could be done on Linux.
Standardization [1] for backups. A tape with 2.5 TB (uncompressed) goes for 30 EUR. The LTO-6 (affordable current iteration) drive itself goes for 300-500 EUR if you buy it second hand. Cheaper if you grab one without casing and FC, but you'd need a FC switch and a FC HBA. I went for a SAS HBA instead, although since I already for fiber through the whole house, FC would've been suffice.
> Is there anything FreeBSD can do that, say, Debian cannot?
If you asked the opposite (what can Debian do that FreeBSD cannot) I would have more to say and it would mostly be preceded by "I know FreeBSD is not Linux but ...". Whenever I need to do any sort of maintenance or inspection I have to look up the equivalent commands for things like lsblk and something nested in /usr/etc/... when I'm used to finding it in /etc/ over every other system.
This is a consequence of both FreeBSD's reliability in needing very infrequent attention and my limited use-cases to use it. As a NAS it is great but I can't touch it without full-text search of all my notes on the side! Either way, no regrets about learning and relying on it after ~18 months so far.
Lack of good NFS support? When we benchmarked it last it was 10x+ slower than running on linux (ubuntu).
Also lack of collective mindshare. I use FreeBSD at work every since day and while I don't hate it, I do wish we just used Linux. There are more guides, tools, etc for Linux than for FreeBSD. Yes, as a comment in this sub-thread stated, jails exist but everyone knows docker, not jails. So even with jails apparently being better than containers, it doesn't really matter, there isn't the ecosystem there.
FreeBSD might be as good as this blog author makes it out to be, and maybe I'm "holding it wrong" (always a strong possibility) but I can't help but feel it causes more friction than I'd like, it's just "slightly" harder to do anything. In the age of LLMs I have to tell it (or put it in my system prompt) "I'm using FreeBSD" or it will be give me Linux advice. It just feels like death by a thousand papercuts.
I would not be surprised if FreeBSD NFS is slower than Linux NFS, but 10x slower is too weird to be correct. Have you used the same NFS version, e.g. NFSv4, on both FreeBSD and Linux?
I have used for many years file servers on FreeBSD, servicing a great number of users and they certainly were not slower than Linux and they had perfect reliability. It is true however, that I have used Samba, not NFS.
I have also used NFS in a few cases, but I have not run benchmarks. I mean that I have not tested intensive random accesses, but I have just copied entire disks through NFS and that worked at the speed limit imposed by a 1 Gb/s Ethernet link, so at least for sequential transfers NFS did not seem to have any speed problems.
The speed of NFS also depends on the speed of the file system used on the server. If you have tested a FreeBSD with ZFS versus a Linux with XFS or EXT4, than your benchmark might not reflect anything about FreeBSD vs. Linux, but only about ZFS. ZFS is significantly slower than XFS or EXT4, regardless if it is used by FreeBSD or by Linux.
Nobody uses ZFS for speed, but only when the extra features provided by ZFS are desired. ZFS is still faster than BTRFS, but not by so much as XFS/EXT4 are faster than ZFS.
On FreeBSD, its older file system, UFS, is faster than ZFS, though not as fast as XFS/EXT4. But if you use NVMe SSDs on the file server, the speed of NFS should be mostly limited by Ethernet, not by the file system of the server.
It is though. Had the same experience, dog slow transfers in FreeBSD on brandnew servers with 10/25G+ cards, hovering at 1-2G speeds. Only switching to Linux helped, and now easily saturates the links.
> speed limit imposed by a 1 Gb/s Ethernet link
FreeBSD might be slow, but its not that slow that it cant saturate a 1G link ;)
All this would be true if Linux and FreeBSD had similar exposition. But there's obviously less users and less hardware in the BSD world, so we must expect a higher variance.
For instance, searching in recent FreeBSD issues, some hardware is compatible but 3× slower, as in "NFS is much too slow at 10GbaseT"[^1].
Or a FreeBSD upgrade to v14 could sink the NFS performance, as in "Write performance to NFS share is ~4x slower than on 13.2".
Of course, these bugs happen with Linux, but there are vastly more resources to detect and fix these problems in the Linux world.
> I use FreeBSD at work every since day and while I don't hate it, I do wish we just used Linux. There are more guides, tools, etc for Linux than for FreeBSD.
Regarding guides specifically, FreeBSD has exceptional resources:
FreeBSD Handbook[0]
FreeBSD Porter's Handbook[1]
FreeBSD Developers' Handbook[2]
The Design and Implementation of the FreeBSD Operating System[3]
Not to mention that the FreeBSD man pages are quite complete. Granted, I am biased as I have used FreeBSD in various efforts for quite some time and am a fan of it. Still and all, the project's documentation is a gold standard IMHO.
> Documentation certainly is not gold standard. I'm a former doc tree committer, familiar with many of the bugs …
As "a former doc tree committer", I am sure you are aware that no set of documentation artifacts are without error of some sort. To be exact, you provided two examples of your identifying what you believe to be same.
I stand by my statement that the cited FreeBSD resources are "a gold standard" while acknowledging they are not perfect. What they are, again in my humble opinion, is vastly superior to what I have found to exist in the Linux world. Perhaps your experience contradicts this position; if so, I respect that.
Arch Wiki can't never cover a userland+kernel documentation by design. FreeBSD does. Arch it's utterly lacking in tons of areas. Forget proper sysctl documentation. Say goodbye to tons of device settings' documentation. Forget iptables/NFT's documentatiton on par of PF.
I don't agree about that ZFS issue. Using whole disk isn't inheritantly wrong. When you have data pool separated from boot disks, using whole disks is better. No need to create partition table, when replacing disk. No worring over block alignment.
Docker is a concept resembling FreeBSD's jails that were introduced in year 2000, having much better isolation, much better security than Docker has had for a long time (perhaps even now jails are still superior to Docker).
Better isolation, better security, but far fewer gists and shared config-files shared ok the Internet for common tasks. Docker comprehensively wkn thr popularity contest, and is often the more convenient solution because of it, in a worse is better way.
People comparing Docker and Jails don't really understand that Docker is 99% about packaging and composing software. From that perspective Jails are nothing like Docker containers. No versioning, no standard, no registry, no compose, no healthchcks, no tree of containers, etc. etc. etc.
If you want to compare Jails to something on Linux then I think LXD is probably much closer to what Jails are.
ZFS on FreeBSD is first class. I had an old FreeNAS raid z5 array on 5x 500GB disks that I wanted to check 4 years after decommissioning the system. I put together a temporary machine with all the disks plugged in and without doing anything the live FreeBSD image found and configured the array. I was instantly able to look through the file system and even dump it to my current FreeBSD server with almost 0 effort. I was sold after that. These days I prefer to run small systems and basic services. I don't want webguis or docker images anymore.
Just so you know: the zfs in freebsd and in linux are the same codebase. Literally. It’s OpenZFS.
Also, a few years ago the FreeBSD people decided to throw away their own ZFS implementation and import the linux one (OpenZFS) because they couldn’t keep up with the development pace.
Nowadays ZFS development is collaborative but in each major freebsd release it’s clearly marked which OpenZFS releases they imported in the FreeBSD codebase.
Right. On my development workstation I use Arch and I'm always worried a kernel upgrade is going to break the ZFS module. For those that aren't familiar, ZFS isn't part of mainline Linux because of licensing incompatibility (and general distrust of Oracle).
>Is there anything FreeBSD can do that, say, Debian cannot?
ZFS boot environments.
One could install Debian's root on ZFS by following the OpenZFS documentation guide, combine it with ZFSBootMenu (or similar), but there won't be any upstream support from the Debian project itself.
The Nitrux Linux distribution is based on Debian and provides an immutable feature similar to boot environments, but you can't treat your immutable boot images the same way you can treat your mutable data like how you can with ZFS datasets on FreeBSD.
FreeBSD is an amazing beast. I'm currently using it as my workstation, and because I need to use Linux, bhyve came to the rescue and is easy to use it through the vm wrapper tool. It works like a charm and it is built in.
Being that said, on FreeBSD 15, I believe I've found a serious bug: when I disconnect a USB optical mouse on the "Lenovo 16 G7 ARP" the system completes freezes and reboots, I guess it reaches a kernel panic. It took me a few disconnections of the power, ethernet and finally the mouse to detect this condition.
Surprinsingly this does not happen if the device is wireless (I tried to remove the receiver of a Trackball and the system keeps working just fine). I find this really weird and don't know if actually report it in the FreeBSD forums, maybe is just a glitch on this particular laptop or it has something to do with the touchpad, just guessing here.
Putting this particular issue aside, I'm extremely happy that almost everything works with little or no effort on a recent/modern laptop.
> But I appreciate the reliability, the good documentation, the community
These were big reasons for me. Cannot overstate the documentation angle.
> Ports. Packages. > DEB/APT/RPM (particularily for a C programmer.
> Licensing more friendly to integrating into your appliances (I did this) or code
Before ZFS it was still better for the afformentioned reasons but ZFS was a game changer.
I started Linux with Slackware and writing my own ppp up/down scripts while dual booting from windows, which took 2 weeks to get online the first time, then I went to redhat/debian/mandrake for a few years... then I found FreeBSD at it was like a breath of 'clear' air.
Started using it for my daily desktop in 2002 and I still use it on several converted Macs at home and my main 'office' server which is a VPS these days.
Production wise I would always have to reboot my fbsd servers for EOL never any issues and many uptimes north of 1000 days over the years. That builds trust.
I trust FreeBSD project to be conservative and consistent for the most part -- THE PRINCIPLE OF LEAST SURPRISE -- another thing I have not seen enough of with Linux distros.
There are narrow things for which FreeBSD is just lovely but it hasn’t been as powerful as Linux for decades. It was one of the best server OS back in the 1990s though. Just a very clean implementation. I used it a lot back in the day and am very fond of it. But I can no longer recommend it.
I started out running FreeBSD on my home servers, then moved to Alpine Linux because all server software that I wanted to run was provided in Docker docker containers and with docker compose examples, so it was just easier. Moving the ZFS pools over to Linux was effortlessly.
And now I am looking at moving over to k3s (still on Alpine) because everyone is providing Helm charts, so it seems easier.
I really like FreeBSD, but it's just easier to go with the flow.
> I delayed upgrading to 15.0 after it was released, but last weekend I finally did it, and it left me wondering why I hadn't done it sooner, because it went quickly and smoothly.
I haven't done that yet because I think I'd want to switch to pkgbase but that makes me nervous. Did you go with that option or continued to use the sets?
Early in my Unix-ish at home journey (26-ish years ago) I tried FreeBSD. It was so Unix because, well, it is. An operating system, not a collection of parts. I found at the time in Linux land Debian felt similar.
But there is always pressure for more features, more bloat. In Linux, on the plus side, I can plug in some random gadget and in most cases it just works. And any laptop that's a few years old, you can just install Fedora from its bootable live image, and it will work. Secure boot, suspend, Wifi, the special buttons on the keyboard, and so on. But the downside is enormous bloat and yes, often the kind of tinkering you really don't want to do any more, such as the Brother laser printer drivers still being shipped as 32-bit binaries and the installer silently failing because one particular 32-bit dependency wasn't autoinstalled. Or having to get an Ubuntu-dedicated installer (Displaylink!) to run on Fedora.
But here you have the "mainstream" Unix-ish OS absorbing all the bleeding edge stuff, all the bloat. Allowing FreeBSD free reign to be pure, with a higher average quality of user, which sets the tone of the whole scene. An echo of the old days, like Usenet before "Eternal September" and before Canter & Siegel - for those old enough to remember how it all felt back then.
I think I finally know what to do with my second NUC: FreeBSD.
I'm in the process of converting and consolidating all my home infra into a mono-compose, for the simple reason I don't want to fiddle with shit, I just want to set-and-forget. The joy of technology was in communications and experiences, not having to dive through abstraction layers to figure out why something was being fiddly. Containers promised to remove the fiddliness (as every virtualization advancement inevitably promises), and now I'm forced to either fiddle with Docker and its root security issues, fiddle with Podman and reconfiguring the OS for lower security so containers don't stop (or worse, converting compose to systemd files to make them services), or fiddle with Kubernetes to make things work with a myriad of ancillary services and CRDs for enterprises, not homelabs.
For two years now, there's been a pretty consistent campaign of love-letters for the BSDs that keep tugging at what I love about technology: that the whole point was to enable you to spend more time living, rather than wrangling what a computer does and how it does it. The concept of jails where I can just run software again, no abstractions needed, and trust it to not misbehave? Amazing, I want to learn more.
So yeah, in lieu of setting up the second NUC as a Debian HA node for Docker/QEMU failover, I think I'm going to slap FreeBSD on it and try porting my workloads to it via Jails. Worst case scenario, I learn something new; best case scenario, I finally get what I want and can finally catch up on my books, movies, shows, and music instead of constantly fiddling with why Plex or Jellyfin or my RSS Aggregator stopped functioning, again.
Ran a FreeBSD colocated server for about a decade that went through generations of hardware. I really want to like the OS, except it's most touted feature, the network stack, was consistently unreliable for me using Intel NICs on Supermicro servers. They would go offline usually after some load due to mbuf resource exhaustion. I never got to the bottom of it even though I posted to the bugs database and would diligently follow up and perform experiments. This also happened on different incarnations of server hardware, so it wasn't the same physical NIC having the issue, but different varieties.
Anyways had enough of the random downtime, I just switched to Linux which didn't have these issues.
I'd say the best part of FreeBSD though is freebsd-update which was a game changer from the previous make world shenanigans.
A week ago, I decided to set up my home server with FreeBSD, after the HDD failed, just to try it out. The setup was quick and easy and everything works fine so far.
I am just not sure it is worth leaving the Linux ecosystem. What if I want to run a Docker container? Do I have to trust random people for ports of software that runs natively on Linux, or port it myself?
FreeBSD seems good so far, but community and ecosystem are important.
> Over the years, FreeBSD has served me well. At a certain point it stepped down as my primary desktop - partly because I switched to Mac, partly because of unsupported hardware - but it never stopped being one of my first choices for servers and any serious workload.
Not my idea of love. Maybe that hardware was supported on Linux. Switch from Linux to FreeBSD so that you can later switch to Mac when you get frustrated with unsupported hardware is not a good pitch.
I was using FreeBSD (after NetBSD) as my primary system for a while in school (no, i can't watch this youtube video, flash doesn't run on FreeBSD). i still use it for my home server, it's just cozy.
When I tried FreeBSD, I was also blown away by the manual, so simple, such high-quality documentation. I think what I liked the most is that it felt coherent, unlike modern OS like Linux and Windows. I think macOS might be the most cohesive of the popular OS's.
I recently put it on an OVH VPS and was very surprised how easy it is to do anything. Firewall. A few ipfw rules/script (pf I think is even easier). Caddy. Just install it and then it very clearly tells you the commands to run as not root. Follow the instructions. Easy. Everything is meant to be simple. I like that. And it seems so much more memory efficient than Linux. Do processes just run better on bsd? Anyway it's been a pleasure. It's my only bsd VPS but I'm glad I've got one.
Around 10 years ago, I picked up an old Thinkpad T42, put FreeBSD on it, and had an amazing experience. Actually used it as a daily driver for a while, which seems crazy in retrospect, but I enjoy trying to work within that kind of constraint sometimes. I miss it! This post rekindles the flame...
I love OpenBSD for similar reasons, except, I still run it as my primary desktop and on an old Chromebook. It just works. No drama with updates. Upgrade every six months. I'd be lost without it.
For someone who has multiple years of experience using Linux for desktop and servers, what's the best way to get into FreeBSD? Any specific recommendations for desktop, like is Wayland ready on FreeBSD?
I use it as a daily driver. I have tried to use it in some shape or form for the past 20 years.
I made a career in Linux and Windows, but always have had a heart for FreeBSD. A person I consider by technical mentor, loved FreeBSD. My first "Admin" job was at a small ISP where he worked. That was where I got my first taste of FreeBSD which I believe was version 5.3? He made sure that all consoles were set to show beastie and I really learned a ton which set up the rest of my tech career.
Later on, he committed suicide, and I use it as a daily driver in honor of him.
I have Linux vms in bhyve. I use jails, etc. I find it pleasant and I prefer it over Linux, if I do not mind its paper cuts (for Desktop use).
I had to previously use wifi dongles since it did not support AX200 at decent speeds. Since version 14 though, it has jumped leaps and bounds. I no longer need it.
What I still have to do is use a custom xorg.conf, because I have dual amd and intel video cards. If I start without it, it says I must specify Bus Ids. I can use pure wayland, but if anything requires X, I still need a working xorg.conf.
If you are willing to deal with paper cuts, and workarounds, it rocks. If you do not have time for that, it may not be for you (desktop wise).
What a delightful letter of appreciation for a project. Reminds us all to appreciate what FOSS gives the world every day and to not take it for granted!
I am a long time Debian Netinst (terminal) user, and Mint Cinnamon for Desktop.
OPNSense run on FreeBSD and it just works.
My personal issue is that I do not believe FreeBSD will give me a smooth experience to get my GPU and what not running. On Mint Cinnamon, I only had to install the latest supported kernel to get my RTX and WiFi6 card recognised.
Debian, the reason why I run Debian as a server everywhere, even in my 3D printer is because it just work, and not just that.
I only run Debian Netinst version, that means to only install standard system and SSH, text mode is the way.
We are talking about 300MB of memory being used by Pihole + Unbound Recursive DNS of 512MB running on a Debian 13.
Disk space?? 1GB or so I guess.
These are my blockers to even try raw FreeBSD, lack of proper hardware support and as a server even if I remove everything I can, I do not imagine FreeBSD running with 300MB/1G of resources.
Not to mention if you work in IT in any way, the last thing you wanna is fighting the system you use to solve another problem, that is why I left Ubuntu after 13years or so, it is a Windows within the Linux world now.
A distro Linux must just run, no dramas, no issues, major system release goes like nothing happened. That matters!!!
FreeBSD and OpenBSD docs are great, but let's not say they're the pinnacle of docs. I like them a lot more than docs for the average Linux distribution. They're even more polished than Arch Linux wiki. But they still have room for improvement. And improving the Arch wiki is easier in my experience.
I ran a TrueNAS server that was based on BSD, loved jails. Then TrueNAS started using debian so more application can run on it. Selfishly I like getting more utility from my server so this was a welcomed change. What industry is BSD used in now a days?
Serious FreeBSD question: I like a lot of what FreeBSD promises, but have been hesitant to make the leap for my home server as I enjoy hosting game servers via steamcmd. I know FreeBSD has Linux binary compatibility, but I am unsure how this would play out for all of my hosting needs. Also, I have some old Nvidia GPUs in this machine, which I might get rid of as they are no longer supported by the latest releases of ML packages, but I also might keep them around for self-teaching CUDA.
How do FreeBSD users get around the inconveniences associated with the "the rest of the world" running on Linux?
What is the roadmap to ML on FreeBSD? From what I could find, apparently neither CUDA nor ROCm is supported? And there are no short-term plans to address the lack of hardware support for ML?
I just installed FreeBSD 15 on a T480 that also runs Debian13. Do other people notice that FreeBSD has longer battery life? I'm still looking into this.
I just hope FreeBSD dosen't get bit by the Rust in the kernel initative. Maybe it'll have to deal with it eventually, when, for example, expanding the compatiblity layer to support interoperability with Linux. But, maybe by then, at least Rust will have gone through its hype test gauntlet and we can see it for what it is instead of being tainted by a polticial power grab.
As an amateur my need is to use the same OS in all the devices from the GUI desktop, to servers, down to Raspberry Pi, having simultaneously very good documentation. And the only one that fulfills this is Arch Linux. Being excellent in device drivers, package maintenance and simplicity is also deal breaker.
I've never used FreeBSD and I appreciate the appeal, but to me the most exciting ideas in OS space are being developed within Nix/Guix projects. I am putting up a NixOS-based homelab server right now. Does FreeBSD have anything remotely similar?
One of my favorite FreeBSD features is first-class support for ZFS boot environments. These have been working in FreeBSD/Solaris since 2008[0]. Having each boot environment available as a ZFS snapshot capable of being managed the same way as any other dataset, capable of being sent and received, is such a powerful feature. I dilligently watch the immutable/atomic Linux space to see when something implements this in the same fashion.
Ubuntu could have been the one, but they reversed course after dropping support for Zsys in 2022[1].
If there are others, then please let me know, but as far as I can tell, the closest approximations in Linux are:
- Btrfs with Snapper in OpenSuse Tumbleweed/MicroOS
- Snapshot Manager/Boom in RHEL
- OStree in Fedora Atomic, CarbonOS, EndlessOS
- Bootable container implementations in Fedora CoreOS, RHEL10, CarbonOS, Bazzite, BlendOS, etc.
- Snaps in Ubuntu Core
- Generations in NixOS and Guix
- A/B update mechanism in ChromeOS, IncusOS
- OverlayFS in Nitrux Linux
- Ad-hoc implementations with Arch, Alpine, etc.
Excluding the ad-hoc implementations, only OpenSuse and Red Hat approaches allow you to treat your system image and system data the same way. They're great, but fundamentally incompatible, and neither has caught on with other distributions. Capabilities of both approaches are limited compared to ZFS.
The strangest part of the Linux situation IMHO is, every time ZFS on Linux is discussed, someone will invariably bring up XFS. For the past decade, XFS on Linux contains support for Copy-on-Write (CoW) and snapshots via relinking. If this is the preferred path on Linux (for users who don't want checksumming of ZFS/Btrfs/Bcachefs), then how come no major distros besides Red Hat have embraced it[2] to provide an update rollback functionality?
I concede that most of the other approaches do provide a higher level level of determinism for what your root system looks like after an upgrade. It's powerful when you can test that system as an OCI container (or as a VM with Nix/Guix). FWIW, FreeBSD can approximate this with the ability to use it's boot environments as a jail[3].
I am not too familiar with the FreeBSD community, so I have a question for the experts: has it ever been for FreeBSD something similar to Ubuntu for Linux? Meaning: a successful billionaire that decides to put money and effort to create a valid, popular alternative to Windows for end users? (not saying that Ubuntu is perfect; just stating the intention).
> had trained me to hunt for documentation in fragments: often incomplete, often outdated, sometimes already stale after barely a year.
This is indeed a problem now that google search is next to useless. And AI further
degrading the quality.
I work around it to some extent by keeping my local knowledge base up to
date, as much as that is possible; and using a ton of scripts that help me do
things. That works. I am also efficient. But some projects are simply underdocumented. A random example is, in the ruby ecosystem, rack. Have a look
here:
Yes, you can jump to the individual documentation of the classes, but does that really explain anything? It next to tells you nothing at all about anything about rack.
If you are new to ruby, would you waste any time with such a project? Yes, rack is useful; yes, many people don't use it directly but may use sinatra, rails and so forth, I get it. But this is not the point. The point is whether the documentation is good or bad. And that is not the only example. See ruby-webassembly. Ruby-opal. Numerous more projects (I won't even mention the abandoned gems, but this is of course a problem every language faces, some code will become outdated as maintainers disappear.)
So this is really nothing unique to Linux. I bet on BSD you will also find ... a lack of documentation. Probably even more as so few blog about BSD. OpenBSD claims it has great documentation. Well, if I look at what they have, and look at Arch or Gentoo wiki, then sorry but the BSDs don't understand the problem domain.
It really is a general problem. Documentation is simply too crap in general, with a few exceptions.
> if the team behind this OS puts this much care into its documentation, imagine how solid the system itself must be.
Meh. FreeBSD documentation can barely called the stand-out role model here either. Not sure what the BSD folks think about that.
> I realized almost immediately that GNU/Linux and FreeBSD were so similar they were completely different.
Not really.
There are some differences but I found they are very similar in their respective niche.
Unfortunately my finding convinced me that Linux is the better choice for my use cases. This ranges from e. g. LFS/BLFS to 500 out of top 500 supercomputers running Linux. Sure, I am not in that use case of having a supercomputer, but the point is about quality. Linux is like chaotic quality. Messy. But it works. New Jersey model versus [insert any high quality here]. https://www.jwz.org/doc/worse-is-better.html
> Not only that: Linux would overheat and produce unpredictable results - errors, sudden shutdowns, fans screaming even after compilation finished.
Well, hardware plays a big factor, I get it. I have issues with some nvidia cards, but other cards worked fine on the same computer. But this apocalypse scenario he writes about ... that's rubbish nonsense. Linux works. For the most part - depending on the hardware. But mostly it really works.
> I could read my email in mutt while compiling, something that was practically impossible on Linux
Ok sorry, I stopped reading there. My current computer was fairly cheap; I deliberately put in 64GB RAM (before the insane AI-driven cost increases) and that
computer works super-fast. I compile almost everything from source. I have no real issue with anything being too slow; admittedly a few things take quite a bit of compile-power, e. g. LLVM, or qt - compiling that from source takes a while, yes, even on a fast computer. But nah, the attempt to claim how FreeBSD is so much faster than Linux is, that's simply not factual. It is rubbish nonsense. Note that OpenBSD and NetBSD folks never write such strangeness. What's wrong with the FreeBSD guys?
262 comments
I delayed upgrading to 15.0 after it was released, but last weekend I finally did it, and it left me wondering why I hadn't done it sooner, because it went quickly and smoothly.
Is there anything FreeBSD can do that, say, Debian cannot? Probably not (at least I cannot think of anything). When I set up the server, ZFS was a huge selling point, but I heard that it works quite well on Linux, these days. But I appreciate the reliability, the good documentation, the community (when I need help).
For example the support for magnetic tapes and for a few other SCSI peripherals is better in FreeBSD. The Linux utility for controlling a LTO tape drive lacks some important options that the corresponding FreeBSD utility has.
I have a tape drive, and to be able to use it like I want I had to move it to a FreeBSD server.
Some years ago I was using a surveillance camera that was much easier to use in FreeBSD than in Linux, if you wanted to record good quality video and audio. I have not tried more recently to use such cameras in Linux, to see if now the recording quality is better.
So while there are more hardware devices that have better support in Linux than in FreeBSD, there are also devices with better support in FreeBSD than in Linux.
However the main reason why I use FreeBSD on many of my servers is that I need much less time for their administration than for Linux servers. In my experience, Linux servers need much less time for administration than Windows servers, and FreeBSD compares to Linux like Linux to Windows.
I have FreeBSD servers that I have not touched for years, and they have worked 24/7 with no downtime and no rebooting, and this includes servers connected directly to the Internet, which implement firewalls, routers and various services, like NTP, DNS servers and proxies, e-mail servers, web servers and proxies etc.
> I have FreeBSD servers that I have not touched for years, and they have worked 24/7 with no downtime and no rebooting, and this includes servers connected directly to the Internet, which implement firewalls, routers and various services, like NTP, DNS servers and proxies, e-mail servers, web servers and proxies etc.
Same. We've got qmail config files with 2006 as the mtime
So, no patching. I used to boast about my NetWare server uptimes but that is so noughties 8)
> … stable … about every 6 months.
Maybe slightly optimistic.
https://bokut.in/freebsd-patch-level-table/#stable/13
https://bokut.in/freebsd-patch-level-table/#stable/14
https://bokut.in/freebsd-patch-level-table/#stable/15
>> … stable … about every 6 months.
> Maybe slightly optimistic.
The longest without rebooting two prod FreeBSD servers I was once responsible for, including applying userland patches, was roughly 3000 days (just over 8 years).
Too bad they dropped support for it.
I patch everything I can think of, as regularly as I can think of. It is rare that a patch is delivered along with a changelog along the lines of "meh, lol, soz" I'm old enough to remember when the notion of a patch was the only term in play, well before "service packs".
I'm jolly boring and run host based firewalls and router, switch, edge etc firewalls, mostly with point to point rules. Its a bit of a faff and so is completely random and different passwords and targeted MFA on each host. I'm fairly sure it is quite hard to pivot across my land.
The best approach to security is to start with: "Mine is a bit shite" and "I'm probably already compromised" and work from there. In the real world: start with a threat model and work on out. For most people that is avoiding scams and becoming part of a bitcoin farm.
> For example the support for magnetic tapes and for a few other SCSI peripherals is better in FreeBSD.
Could you give us another hint?
> The Linux utility for controlling a LTO tape drive lacks some important options that the corresponding FreeBSD utility has.
That should be easy to list, no? It's been a while since I used a LTO drive, but I don't know what I missed.
> I have FreeBSD servers that I have not touched for years
Are you sure, they are still "yours"?
> Some years ago I was using a surveillance camera that was much easier to use in FreeBSD than in Linux, if you wanted to record good quality video and audio. I have not tried more recently to use such cameras in Linux, to see if now the recording quality is better.
This example seems very hand-wavy. What camera?
In FreeBSD, the command required for recording was very simple and it worked flawlessly. In Linux, it was more complex and there were various stuttering problems at maximum resolution. I am still using those cameras, but I have not tried them again in Linux. In Linux they worked worse than in FreeBSD around 5 years ago, perhaps nowadays there is no longer any problem in Linux.
This was intended to be an example that you cannot know a priori whether a given device will work better on FreeBSD or on Linux. In general, there is a greater probability for Linux to have good support than for FreeBSD, but there are also counterexamples, so you cannot be certain which is better until you try both.
In a nutshell, you content that FreeBSD running on the same hardware as "a linux" performed better with camera operations. However, you did not specify even a specific camera model, or the interface(s) used to interact with the camera.
I have zero issue accepting that a BSD is better than a linux at things, pretending otherwise is foolish. However, this specific example isn't tracking.
FreeBSD has a dedicated service for USB cameras, webcamd, and it worked very well for capturing video and audio at maximum resolution, and without interference from any other programs that were running concurrently on the server. As I have said, in Linux not only the required configuration was more complex, but I tried several programs and all had stutter problems at FullHD resolution (while other programs were also running on the computer). That was the status at that time. Now, many kernel versions later, I assume that such problems no longer exist, at least not with old cameras.
I do not see what is not tracking for you in this example. It is not an isolated example, for many years FreeBSD was known to have less problems than Linux in handling video streams and audio streams with low latency and constant throughput. More recently, Linux has also improved, but in the past unreliable performance with certain video/audio devices was not unusual (i.e. where other programs running concurrently caused video/audio drops or delays).
But like I have said, I do not think that the model mattered much. IIRC the camera had an internal video encoder, because otherwise uncompressed FullHD video would not pass through USB 2.0.
The differences between FreeBSD and Linux at that time were at 2 levels. Regarding the user interface, FreeBSD happened to include in the base system programs dedicated for using such a camera, so their use was very simple. On Linux I had to search and install a suitable package, and those that were available were more general video applications and because of that their configuration to do the specific thing that I needed was more complex.
Besides the simpler interface, there was the stuttering problem on Linux, which was caused by the scheduling policies of the kernel. Perhaps it would have been possible on Linux to find a way to ensure a higher priority for the video and audio handling, to not be preempted by the concurrent programs running on the server, but since on FreeBSD everything worked fine out of the box there was no reason for me to investigate how that could be done on Linux.
[1] https://github.com/LinearTapeFileSystem/ltfs
> Is there anything FreeBSD can do that, say, Debian cannot?
If you asked the opposite (what can Debian do that FreeBSD cannot) I would have more to say and it would mostly be preceded by "I know FreeBSD is not Linux but ...". Whenever I need to do any sort of maintenance or inspection I have to look up the equivalent commands for things like
lsblkand something nested in/usr/etc/...when I'm used to finding it in/etc/over every other system.This is a consequence of both FreeBSD's reliability in needing very infrequent attention and my limited use-cases to use it. As a NAS it is great but I can't touch it without full-text search of all my notes on the side! Either way, no regrets about learning and relying on it after ~18 months so far.
Also lack of collective mindshare. I use FreeBSD at work every since day and while I don't hate it, I do wish we just used Linux. There are more guides, tools, etc for Linux than for FreeBSD. Yes, as a comment in this sub-thread stated, jails exist but everyone knows docker, not jails. So even with jails apparently being better than containers, it doesn't really matter, there isn't the ecosystem there.
FreeBSD might be as good as this blog author makes it out to be, and maybe I'm "holding it wrong" (always a strong possibility) but I can't help but feel it causes more friction than I'd like, it's just "slightly" harder to do anything. In the age of LLMs I have to tell it (or put it in my system prompt) "I'm using FreeBSD" or it will be give me Linux advice. It just feels like death by a thousand papercuts.
I have used for many years file servers on FreeBSD, servicing a great number of users and they certainly were not slower than Linux and they had perfect reliability. It is true however, that I have used Samba, not NFS.
I have also used NFS in a few cases, but I have not run benchmarks. I mean that I have not tested intensive random accesses, but I have just copied entire disks through NFS and that worked at the speed limit imposed by a 1 Gb/s Ethernet link, so at least for sequential transfers NFS did not seem to have any speed problems.
The speed of NFS also depends on the speed of the file system used on the server. If you have tested a FreeBSD with ZFS versus a Linux with XFS or EXT4, than your benchmark might not reflect anything about FreeBSD vs. Linux, but only about ZFS. ZFS is significantly slower than XFS or EXT4, regardless if it is used by FreeBSD or by Linux.
Nobody uses ZFS for speed, but only when the extra features provided by ZFS are desired. ZFS is still faster than BTRFS, but not by so much as XFS/EXT4 are faster than ZFS.
On FreeBSD, its older file system, UFS, is faster than ZFS, though not as fast as XFS/EXT4. But if you use NVMe SSDs on the file server, the speed of NFS should be mostly limited by Ethernet, not by the file system of the server.
> but 10x slower is too weird to be correct.
It is though. Had the same experience, dog slow transfers in FreeBSD on brandnew servers with 10/25G+ cards, hovering at 1-2G speeds. Only switching to Linux helped, and now easily saturates the links.
> speed limit imposed by a 1 Gb/s Ethernet link
FreeBSD might be slow, but its not that slow that it cant saturate a 1G link ;)
For instance, searching in recent FreeBSD issues, some hardware is compatible but 3× slower, as in "NFS is much too slow at 10GbaseT"[^1]. Or a FreeBSD upgrade to v14 could sink the NFS performance, as in "Write performance to NFS share is ~4x slower than on 13.2". Of course, these bugs happen with Linux, but there are vastly more resources to detect and fix these problems in the Linux world.
[^1]: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277197
[^2]: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276299
> I use FreeBSD at work every since day and while I don't hate it, I do wish we just used Linux. There are more guides, tools, etc for Linux than for FreeBSD.
Regarding guides specifically, FreeBSD has exceptional resources:
Not to mention that the FreeBSD man pages are quite complete. Granted, I am biased as I have used FreeBSD in various efforts for quite some time and am a fan of it. Still and all, the project's documentation is a gold standard IMHO.0 - https://docs.freebsd.org/en/books/handbook/
1 - https://docs.freebsd.org/en/books/porters-handbook/
2 - https://docs.freebsd.org/en/books/developers-handbook/
3 - https://books.google.com/books/about/The_Design_and_Implemen...
> Regarding guides specifically, FreeBSD has exceptional resources: FreeBSD Handbook …
Ahem.
<https://www.reddit.com/r/freebsd/comments/1rpnd05/comment/o9...> for the ZFS chapter "… telling people to do the WRONG thing, …"
<https://www.reddit.com/r/freebsd/comments/1ru0k9u/comment/oa...> for the ports chapter "… misleading, it was wrongly updated: …"
– and so on.
> … the project's documentation is a gold standard IMHO.
Documentation certainly is not gold standard. I'm a former doc tree committer, familiar with many of the bugs …
> Documentation certainly is not gold standard. I'm a former doc tree committer, familiar with many of the bugs …
As "a former doc tree committer", I am sure you are aware that no set of documentation artifacts are without error of some sort. To be exact, you provided two examples of your identifying what you believe to be same.
I stand by my statement that the cited FreeBSD resources are "a gold standard" while acknowledging they are not perfect. What they are, again in my humble opinion, is vastly superior to what I have found to exist in the Linux world. Perhaps your experience contradicts this position; if so, I respect that.
> … Yes, as a comment in this sub-thread stated, jails exist …
https://mastodon.bsd.cafe/@grahamperrin/116168374700889783
> Would anyone like to say something? > > …
>>maybe I'm "holding it wrong" (always a strong possibility)
Yes. You are holding it wrong. And it's obvious from your comment.
If you want to compare Jails to something on Linux then I think LXD is probably much closer to what Jails are.
Also, a few years ago the FreeBSD people decided to throw away their own ZFS implementation and import the linux one (OpenZFS) because they couldn’t keep up with the development pace.
Nowadays ZFS development is collaborative but in each major freebsd release it’s clearly marked which OpenZFS releases they imported in the FreeBSD codebase.
On FreeBSD I know its always going to work.
>Is there anything FreeBSD can do that, say, Debian cannot?
ZFS boot environments.
One could install Debian's root on ZFS by following the OpenZFS documentation guide, combine it with ZFSBootMenu (or similar), but there won't be any upstream support from the Debian project itself.
The Nitrux Linux distribution is based on Debian and provides an immutable feature similar to boot environments, but you can't treat your immutable boot images the same way you can treat your mutable data like how you can with ZFS datasets on FreeBSD.
vmwrapper tool. It works like a charm and it is built in.Being that said, on FreeBSD 15, I believe I've found a serious bug: when I disconnect a USB optical mouse on the "Lenovo 16 G7 ARP" the system completes freezes and reboots, I guess it reaches a kernel panic. It took me a few disconnections of the power, ethernet and finally the mouse to detect this condition.
Surprinsingly this does not happen if the device is wireless (I tried to remove the receiver of a Trackball and the system keeps working just fine). I find this really weird and don't know if actually report it in the FreeBSD forums, maybe is just a glitch on this particular laptop or it has something to do with the touchpad, just guessing here.
Putting this particular issue aside, I'm extremely happy that almost everything works with little or no effort on a recent/modern laptop.
BSDs in general are fantastic OSes.
> Is there anything FreeBSD can do that, say, Debian cannot? Probably not (at least I cannot think of anything).
Stability of user interface and documentation.
> … ZFS was a huge selling point, but I heard that it works quite well on Linux, these days. …
True.
I have OpenZFS-native encrypted root-on-ZFS for Kubuntu 25.10, made ultra-simple by the installer for Ubuntu (25.04 at the time).
FreeBSD can not yet do this. Please see, for example, https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=263171
> 263171 – add loader(8) and boot loader menu support for boot with OpenZFS-encrypted ROOT
The main gripe is probably Docker and/or software depending on Linux-isms that can't be run natively without resorting to bhyve or smth alike that.
> But I appreciate the reliability, the good documentation, the community
These were big reasons for me. Cannot overstate the documentation angle.
> Ports. Packages. > DEB/APT/RPM (particularily for a C programmer.
> Licensing more friendly to integrating into your appliances (I did this) or code
Before ZFS it was still better for the afformentioned reasons but ZFS was a game changer.
I started Linux with Slackware and writing my own ppp up/down scripts while dual booting from windows, which took 2 weeks to get online the first time, then I went to redhat/debian/mandrake for a few years... then I found FreeBSD at it was like a breath of 'clear' air.
Started using it for my daily desktop in 2002 and I still use it on several converted Macs at home and my main 'office' server which is a VPS these days.
Production wise I would always have to reboot my fbsd servers for EOL never any issues and many uptimes north of 1000 days over the years. That builds trust.
I trust FreeBSD project to be conservative and consistent for the most part -- THE PRINCIPLE OF LEAST SURPRISE -- another thing I have not seen enough of with Linux distros.
> Is there anything FreeBSD can do that, say, Debian cannot?
Yes. Emulate traffic latency using IPFW and dummynet[^1]. There is no Linux (or OpenBSD, NetBSD) counterpart.
The ZFS implementation is less buggy.
[^1]: https://man.freebsd.org/cgi/man.cgi?dummynet
And now I am looking at moving over to k3s (still on Alpine) because everyone is providing Helm charts, so it seems easier.
I really like FreeBSD, but it's just easier to go with the flow.
> I delayed upgrading to 15.0 after it was released, but last weekend I finally did it, and it left me wondering why I hadn't done it sooner, because it went quickly and smoothly.
I haven't done that yet because I think I'd want to switch to pkgbase but that makes me nervous. Did you go with that option or continued to use the sets?
But there is always pressure for more features, more bloat. In Linux, on the plus side, I can plug in some random gadget and in most cases it just works. And any laptop that's a few years old, you can just install Fedora from its bootable live image, and it will work. Secure boot, suspend, Wifi, the special buttons on the keyboard, and so on. But the downside is enormous bloat and yes, often the kind of tinkering you really don't want to do any more, such as the Brother laser printer drivers still being shipped as 32-bit binaries and the installer silently failing because one particular 32-bit dependency wasn't autoinstalled. Or having to get an Ubuntu-dedicated installer (Displaylink!) to run on Fedora.
But here you have the "mainstream" Unix-ish OS absorbing all the bleeding edge stuff, all the bloat. Allowing FreeBSD free reign to be pure, with a higher average quality of user, which sets the tone of the whole scene. An echo of the old days, like Usenet before "Eternal September" and before Canter & Siegel - for those old enough to remember how it all felt back then.
I'm in the process of converting and consolidating all my home infra into a mono-compose, for the simple reason I don't want to fiddle with shit, I just want to set-and-forget. The joy of technology was in communications and experiences, not having to dive through abstraction layers to figure out why something was being fiddly. Containers promised to remove the fiddliness (as every virtualization advancement inevitably promises), and now I'm forced to either fiddle with Docker and its root security issues, fiddle with Podman and reconfiguring the OS for lower security so containers don't stop (or worse, converting compose to systemd files to make them services), or fiddle with Kubernetes to make things work with a myriad of ancillary services and CRDs for enterprises, not homelabs.
For two years now, there's been a pretty consistent campaign of love-letters for the BSDs that keep tugging at what I love about technology: that the whole point was to enable you to spend more time living, rather than wrangling what a computer does and how it does it. The concept of jails where I can just run software again, no abstractions needed, and trust it to not misbehave? Amazing, I want to learn more.
So yeah, in lieu of setting up the second NUC as a Debian HA node for Docker/QEMU failover, I think I'm going to slap FreeBSD on it and try porting my workloads to it via Jails. Worst case scenario, I learn something new; best case scenario, I finally get what I want and can finally catch up on my books, movies, shows, and music instead of constantly fiddling with why Plex or Jellyfin or my RSS Aggregator stopped functioning, again.
Anyways had enough of the random downtime, I just switched to Linux which didn't have these issues.
I'd say the best part of FreeBSD though is freebsd-update which was a game changer from the previous make world shenanigans.
I am just not sure it is worth leaving the Linux ecosystem. What if I want to run a Docker container? Do I have to trust random people for ports of software that runs natively on Linux, or port it myself?
FreeBSD seems good so far, but community and ecosystem are important.
> Over the years, FreeBSD has served me well. At a certain point it stepped down as my primary desktop - partly because I switched to Mac, partly because of unsupported hardware - but it never stopped being one of my first choices for servers and any serious workload.
Not my idea of love. Maybe that hardware was supported on Linux. Switch from Linux to FreeBSD so that you can later switch to Mac when you get frustrated with unsupported hardware is not a good pitch.
Immich assumes you're running Docker and I can't seem to get Linux running in a bhyve VM with Intel Quick Sync acceleration.
I made a career in Linux and Windows, but always have had a heart for FreeBSD. A person I consider by technical mentor, loved FreeBSD. My first "Admin" job was at a small ISP where he worked. That was where I got my first taste of FreeBSD which I believe was version 5.3? He made sure that all consoles were set to show beastie and I really learned a ton which set up the rest of my tech career.
Later on, he committed suicide, and I use it as a daily driver in honor of him.
I have Linux vms in bhyve. I use jails, etc. I find it pleasant and I prefer it over Linux, if I do not mind its paper cuts (for Desktop use).
I had to previously use wifi dongles since it did not support AX200 at decent speeds. Since version 14 though, it has jumped leaps and bounds. I no longer need it.
What I still have to do is use a custom xorg.conf, because I have dual amd and intel video cards. If I start without it, it says I must specify Bus Ids. I can use pure wayland, but if anything requires X, I still need a working xorg.conf.
If you are willing to deal with paper cuts, and workarounds, it rocks. If you do not have time for that, it may not be for you (desktop wise).
Server wise, I still love it, just like 5.3 days.
I want to have a bunch (5-10) of freebsd cattle-style servers to run a service on.
What’s the preferred infrastructure as code style approach to setting them up?
Some will be bare metal with kvm console access. Some will be VMs. They will be heterogeneous and not in one DC.
I probably don’t need zfs for this application (raw iops matter more than snapshots, etc).
I have previous experience with kubernetes, and am not interested in using it again.
Monitoring, logging, deterministic “zero to working” install and updates are probably the main requirements.
My personal issue is that I do not believe FreeBSD will give me a smooth experience to get my GPU and what not running. On Mint Cinnamon, I only had to install the latest supported kernel to get my RTX and WiFi6 card recognised.
Debian, the reason why I run Debian as a server everywhere, even in my 3D printer is because it just work, and not just that.
I only run Debian Netinst version, that means to only install standard system and SSH, text mode is the way.
We are talking about 300MB of memory being used by Pihole + Unbound Recursive DNS of 512MB running on a Debian 13.
Disk space?? 1GB or so I guess.
These are my blockers to even try raw FreeBSD, lack of proper hardware support and as a server even if I remove everything I can, I do not imagine FreeBSD running with 300MB/1G of resources.
Not to mention if you work in IT in any way, the last thing you wanna is fighting the system you use to solve another problem, that is why I left Ubuntu after 13years or so, it is a Windows within the Linux world now.
A distro Linux must just run, no dramas, no issues, major system release goes like nothing happened. That matters!!!
How do FreeBSD users get around the inconveniences associated with the "the rest of the world" running on Linux?
How do you get hired if you do happen to have proper FreeBSD skills? It's notably absent from all the job listings.
Ubuntu could have been the one, but they reversed course after dropping support for Zsys in 2022[1].
If there are others, then please let me know, but as far as I can tell, the closest approximations in Linux are:
- Btrfs with Snapper in OpenSuse Tumbleweed/MicroOS
- Snapshot Manager/Boom in RHEL
- OStree in Fedora Atomic, CarbonOS, EndlessOS
- Bootable container implementations in Fedora CoreOS, RHEL10, CarbonOS, Bazzite, BlendOS, etc.
- Snaps in Ubuntu Core
- Generations in NixOS and Guix
- A/B update mechanism in ChromeOS, IncusOS
- OverlayFS in Nitrux Linux
- Ad-hoc implementations with Arch, Alpine, etc.
Excluding the ad-hoc implementations, only OpenSuse and Red Hat approaches allow you to treat your system image and system data the same way. They're great, but fundamentally incompatible, and neither has caught on with other distributions. Capabilities of both approaches are limited compared to ZFS.
The strangest part of the Linux situation IMHO is, every time ZFS on Linux is discussed, someone will invariably bring up XFS. For the past decade, XFS on Linux contains support for Copy-on-Write (CoW) and snapshots via relinking. If this is the preferred path on Linux (for users who don't want checksumming of ZFS/Btrfs/Bcachefs), then how come no major distros besides Red Hat have embraced it[2] to provide an update rollback functionality?
I concede that most of the other approaches do provide a higher level level of determinism for what your root system looks like after an upgrade. It's powerful when you can test that system as an OCI container (or as a VM with Nix/Guix). FWIW, FreeBSD can approximate this with the ability to use it's boot environments as a jail[3].
[0] https://daemonforums.org/showthread.php?t=7099
[1] https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1968...
[2] https://docs.redhat.com/en/documentation/red_hat_enterprise_...
[3] https://man.freebsd.org/cgi/man.cgi?query=bectl&sektion=8&ma...
Not clear!
> had trained me to hunt for documentation in fragments: often incomplete, often outdated, sometimes already stale after barely a year.
This is indeed a problem now that google search is next to useless. And AI further degrading the quality.
I work around it to some extent by keeping my local knowledge base up to date, as much as that is possible; and using a ton of scripts that help me do things. That works. I am also efficient. But some projects are simply underdocumented. A random example is, in the ruby ecosystem, rack. Have a look here:
https://github.com/rack/rack
Now find the documentation ... try it.
You may find it:
https://rack.github.io/rack/
Linked from the github page.
Well, have a look at it.
Remain patient.
Now as you have looked at it ... tell me if someone is troll-roflcopter-joking you.
https://rack.github.io/rack/main/index.html
Yes, you can jump to the individual documentation of the classes, but does that really explain anything? It next to tells you nothing at all about anything about rack.
If you are new to ruby, would you waste any time with such a project? Yes, rack is useful; yes, many people don't use it directly but may use sinatra, rails and so forth, I get it. But this is not the point. The point is whether the documentation is good or bad. And that is not the only example. See ruby-webassembly. Ruby-opal. Numerous more projects (I won't even mention the abandoned gems, but this is of course a problem every language faces, some code will become outdated as maintainers disappear.)
So this is really nothing unique to Linux. I bet on BSD you will also find ... a lack of documentation. Probably even more as so few blog about BSD. OpenBSD claims it has great documentation. Well, if I look at what they have, and look at Arch or Gentoo wiki, then sorry but the BSDs don't understand the problem domain.
It really is a general problem. Documentation is simply too crap in general, with a few exceptions.
> if the team behind this OS puts this much care into its documentation, imagine how solid the system itself must be.
Meh. FreeBSD documentation can barely called the stand-out role model here either. Not sure what the BSD folks think about that.
> I realized almost immediately that GNU/Linux and FreeBSD were so similar they were completely different.
Not really.
There are some differences but I found they are very similar in their respective niche.
Unfortunately my finding convinced me that Linux is the better choice for my use cases. This ranges from e. g. LFS/BLFS to 500 out of top 500 supercomputers running Linux. Sure, I am not in that use case of having a supercomputer, but the point is about quality. Linux is like chaotic quality. Messy. But it works. New Jersey model versus [insert any high quality here]. https://www.jwz.org/doc/worse-is-better.html
> Not only that: Linux would overheat and produce unpredictable results - errors, sudden shutdowns, fans screaming even after compilation finished.
Well, hardware plays a big factor, I get it. I have issues with some nvidia cards, but other cards worked fine on the same computer. But this apocalypse scenario he writes about ... that's rubbish nonsense. Linux works. For the most part - depending on the hardware. But mostly it really works.
> I could read my email in mutt while compiling, something that was practically impossible on Linux
Ok sorry, I stopped reading there. My current computer was fairly cheap; I deliberately put in 64GB RAM (before the insane AI-driven cost increases) and that computer works super-fast. I compile almost everything from source. I have no real issue with anything being too slow; admittedly a few things take quite a bit of compile-power, e. g. LLVM, or qt - compiling that from source takes a while, yes, even on a fast computer. But nah, the attempt to claim how FreeBSD is so much faster than Linux is, that's simply not factual. It is rubbish nonsense. Note that OpenBSD and NetBSD folks never write such strangeness. What's wrong with the FreeBSD guys?