hckrnws
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
"with no downtime and no rebooting"
So, no patching. I used to boast about my NetWare server uptimes but that is so noughties 8)
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.
> … stable … about every 6 months.
Maybe slightly optimistic.
https://bokut.in/freebsd-patch-level-table/#stable/13
>> … 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).
My DigitalOcean FreeBSD droplet chugging along: 7:25AM up 1707 days, 15 hrs, 5 users, load averages: 0.30, 0.21, 0.17
Too bad they dropped support for it.
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.
> 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"?
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.
Magnetic tapes? Super cool! What are you using them for if one may ask? Very curious.
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.
> 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?
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.
[dead]
> 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 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]
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 …
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.
> 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 Linux wiki is the gold standard and better than FreeBSD.
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 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.
> 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 ;)
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.
[^1]: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277197
[^2]: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276299
> … 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.
A tool that is non-obvious in how to use it is a tool problem, not a user problem.
FreeBSD originates from Unix and as one who started in the professional programming world using Unix I find FreeBSD far more obvious than Linux. Don't let your lack of knowledge of Unix tools caused by Linux confuse you or hold you back.
The condescending attitude of a minority of FreeBSD users is never an incentive to engage.
Comment was deleted :(
Lack of docker support? Docker is available on macOS through emulation yes but bhyve is a thing… so why not? :-)
Podman is a viable option. I'm not sure how it works but I was able to run Alpine and Debian containers by setting a few system flags.
That’s very good to know. Thanks!
That's why I don't use Linux. It lacks Jail support.
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.
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).
On FreeBSD I know its always going to work.
> … For those that aren't familiar, ZFS isn't part of mainline Linux because of licensing incompatibility (and general distrust of Oracle). …
It's probably fair to say that trust in Oracle is irrelevant to OpenZFS.
Where Linux does use ZFS: to the best of my knowledge, it's typically OpenZFS – https://news.ycombinator.com/item?id=47407937 is my own use case.
I was mainly referring to statements made by Linus Torvalds that got a lot of press. Canonical seems undeterred by any such arguments.
>I use Arch and I'm always worried a kernel upgrade is going to break the ZFS modulet
That can only happen if you use the unreliable DKMS way of installing it. If you use zfs-linux provided by archzfs it will only allow updating if it's compatible with the kernel, which in linux-lts case is within couple hours of a kernel update.
https://github.com/archzfs/archzfs https://wiki.archlinux.org/title/ZFS#Kernel-specific_package...
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.
>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.
you can use snapper + btrfs and the end result is like `bectl`. However it not as simple/integrated as ZFS Boot environments on FreeBSD
On openSUSE Tumbleweed, it is. Each Upgrade creates two snapshots, one before, one after, and if anything goes wrong, I can boot into a snapshot where the world was still in order.
I have a higher opinion of ZFS than I do of btrfs, but FWIW snapper+btrfs has worked well for me on openSUSE Tumbleweed for ten years now, too.
The btrfs code quality seems less than ZFS, based on the reports I have read.
Last I heard (~8 years ago), the RAID-like functionality in btrfs was very unstable and crash-prone. The impression I got was that there was not a lot of interest in fixing this. Then bcachefs came and ... appears to have gone nowhere AFAICT.
The non-RAID part of btrfs appears to be stable. It's the default filesystem on openSUSE and SLES. But I don't think it's ever going to reach feature parity with ZFS.
> Then bcachefs came and ... appears to have gone nowhere AFAICT.
I heard the developer got sidetracked into writing himself an AI girlfriend. (Not sarcasm)
People love to imagine all sorts of salacious things.
hah, you weren't joking... https://poc.bcachefs.org/ https://www.theregister.com/2026/02/25/bcachefs_creator_ai/
btrfs is suffering from a lot of old bad publicity and some poor design decisions around RAID.
But by now it is a great file system if you don't go near RAID5/6. btrfs has its flaws (ZFS has its own flaws!). However:
- It's used a lot, especially by facebook and Redhat (on fedora)
- Gets a lot of testing
- Sees a lot of bug fixes
- Has a lot of features
I haven't read btrfs code but given that it is a popular file system and Linux code quality tends to be good in popular subsystems I would hesitate to say its code quality is worse than ZFS in any way.
btrfs is pathetic when it comes to performance. So no, thanks.
ZFS is worse than btrfs in performance.
Check out https://www.phoronix.com/review/linux-617-filesystems/5 "Geometric Mean of all test results". You will find that OpenZFS is ~35% slower than btrfs.
I love ZFS but I am aware about the performance it delivers.
Last I tried zfs was far far worse on reads arc couldn't satisfy, and all writes
In real world scenarios, where file based backups fail, one needs to add at least lvm.
And only than those benchmarks would be more interesting to me.
Be specific. Why do you need LVM? What for, what do you do with it?
Secondly: are you aware that ZFS includes what LVM does on Linux, and so you don't need a separate tool for it? This makes the comparison tricky but it's important to consider.
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.
BSDs in general are fantastic OSes.
Instead of the forums, report it also here https://bugs.freebsd.org/bugzilla/
> 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? Probably not (at least I cannot think of anything).
Stability of user interface and documentation.
What documentation does a distro even publish? I only ask because freebsd has the most solid documentation I've used of any OS I've ever encountered. I seriously doubt Debian has documented the linux kernel that well (which, tbf, would be an insane project to even attempt)
Debian has an installation guide[1]. I'd imagine all the major distributions do.
But it probably has to change a lot for every major release, because so many things change. FreeBSD major releases have changes too, but a lot of the user interfaces are very stable and so the documentation can be too. Stable documentation allows time for it to be edited and revised to become better documentation, as well as developing quality translations.
> … Stable documentation allows time for it to be edited and revised to become better documentation,
https://news.ycombinator.com/item?id=47407895
Part of the problem is, too few committers. https://cgit.freebsd.org/doc/log/access?h=refs/internal/admi...
> as well as developing quality translations. …
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=267274
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=284875#c8
For Russian, things are better: https://freshbsd.org/freebsd/doc?committer[]=Vladlen+Popolit... – see https://cgit.freebsd.org/doc/commit/access?h=refs/internal/a...
I wonder if this is a curse of popularity. Presumably the documentation is stable and good because the software is also stable, and well-specified with one way to do each thing rather than five competing projects.
I've been surprised at times by what's missing. There are are some strange omissions, from most recent memory around the Bourne shell builtin commands and make(1). I've had to go hunting in other BSD distribution manuals at times to find what I need. I'd say the GNU core utilities sometimes have better docs for their equivalent commands.
That said, for non-core utilities on Linux it's pretty hit-or-miss. The BSDs are generally pretty consistent in what they do offer, and that's what I love about them. Of course it's a different development model and it shows.
> … 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
Having ZFS baked into the installer and fully supported by the project is a huge motivator for using FreeBSD.
I know that Linux distros can accommodate ZFS, but it's a fair-weather situation due to licensing and most distros' preference for BTRFS.
Licensing is totally irrelevant for the end user. It just means you can't distribute the fully configured system.
My current home server passed 10 years in the autnum, but I've been running FreeBSD on servers since around 2000.
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.
You could just use podman.
Theoretically yes, however still limited by how well the FreeBSD Linux layer handles syscalls. A year or so back I tried running .NET (just binaries, not via a container) since the port wasn't as far along as today and it crashed due to what I suspect was slight differences in signal handling defaults.
And this is part of the situation that's going to get worse, io_uring will become more popular in language runtimes and iirc it's not trivial to emulate via existing FreeBSD mechanisms (kqueue).
Iirc Mac docker uses xhyve (bhyve port/inspired) to run containers via Linux emulation, MS went for pv-Linux for WSL2, while FreeBSD has been "good enough" so far.
But I think that for containers it's either time to shape up Linux emulation well (It's ironic that WSL1 ironed out their worst quirks just as WSL2 was introduced, although that was without io_uring) or just add an option for Podman to have a minimal pv-Linux kernel via bhyve to get better compatibility.
I’m confused because can already do this on MacOS, Windows and Linux
Does `podman machine init` not work in FreeBSD? In those other platforms it will spin a small Linux VM to run containers on.
Indeed, ideally we could get docker on FreeBSD using the same approach as is used on macOS — automatically run (one or more) Linux VMs under bhyve.
I wonder if FreeBSD ought to consider a WSL2-style approach to Linux binary compatibility, too.
Keeping the Linux syscall compatibility layer up-to-date has always been a resource problem, especially when syscalls depend on large, complex Linux kernel subsystems that just don’t map cleanly to FreeBSD kernel facilities.
Exactly the reason why I switched from FreeBSD to Debian, 25 years ago
The difference compared to a quarter of a century ago is that hardware virtualization is an ubiquitous thing now and that machines go so much faster that you don't even realize you're running in a VM anymore: it's pretty much transparent. I run Docker on my Linux servers inside a VM. There's no way I let Docker touch the bare metal, not with a ten foot pole.
If people want or need to run Docker on FreeBSD, they can run a Linux VM under bhyve.
[flagged]
Docker's what lets me spend more time using the software on my server than fiddling with it. I got the fiddling out of my system years ago, I just want shit to work now.
I don't really care about it per se but having a cross-distro unified daemon config & supervisor, package manager, and ability to cram every single important file into a file tree (again, using the same interface to achieve this with every daemon) that has only those files in it (making backups and restores trivial) and then easily verify that I got all the important files (destroy image -> re-create, does it still look good? Then I got everything) makes everything so easy. I no longer put off trying a new service until the weekend because it'll take an unknown amount of time that could end up being hours. Odds are I can have anything available in the official Docker registry (which is approximately everything, these days) up in five minutes flat to try it out, and may not even need any further modifications for it to be ready for (personal) "production".
I use Debian but don't even care, I haven't had to touch systemd once (thank god) and the only Debian-parts I even use are its ZFS, SSH, and Docker, with my ten or so actual user-facing services all just pulled and managed via Docker, ready to transfer to any other distro seamlessly, should I ever care to. Even Samba is under Docker (oh my god it is so much easier to configure for common use-cases this way).
(I would definitely be using FreeBSD on my server if I cared about anything other than Docker, though—I haven't actually liked Linux for about fifteen years now)
I've fixed too many linux-isms in code manually over the years, pkg/ports does what it should but since *nix tradition relies on hardcoded paths I often wanted out-of-tree builds for various software.
And that's the thing, as I grow older I feel more and more that I just want the parts of computing that I don't want to _care_ about to be stupid simple.
If I'm doing a program needing a recent version of some language that doesn't have a FreeBSD port yet and some database behind it, I don't really want to configure it all manually because I don't particularly care for porting the runtime or managing the database (that isn't exposed to the outside world anyhow).
This is stuff where I don't want a large CI pipe or other management (or needing to remember to upgrade the packages if I upgrade the hosting OS).
Stuff like this is why "the clouds are winning", friction should be linear depending on the effort I want to put into managing something.
But going for real HW or even VPS a places an "upgrade tax" on me because I can't just let non-public services like an isolated DB just ride-along over major versions (maybe Jails with isolated userlands could be an option, but that becomes painful instead when needing newer versions of the application behind the veil).
docker and flatpak/snap are _extremely_ different tools with very different purposes.
Sure they're different. They all download blobs and can then execute them. Exactly how, when and why is completely different but they still get you blobs.
In the same way s3 is different to a dropbox, and a car being different to a bike.
Can't tell if you're ragebaiting here, but I'm very confused by this question because they support an entirely different set of features, and if you use both it's painfully obvious how they're different.
Docker is built for running services, distribution is part of that, but it's core is that you can pull an image and run random service on your machine packaged with all the right libraries, network them into your machine in the way you like so it can access the right things, constrain it's resources, and create our own image based on it.
Snap/Flatpak is built to distribute applications, sandboxing being a core part of it, with applications wanting to integrate into distribution mechanics such as audio, URL handling, taking screenshots, ...
Exactly. Yes, I've used them and it was horrible.
For me, the difference is in do I get to compile this from sources myself or do I get someone elses compiler output?
IOW it's not comparing vastly different vehicles, but rather a vehicle with its blueprint.
Also, a long time ago it was commonly accepted that spaghetti code is awful. Docker replaces all that with spaghetti services and debugging gets much worse.
> 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.
That is not really accurate? Linux traffic control (tc, [0]) exists since Kernel 2.2. It can introduce traffic latency and a few other network conditions, like packet loss.
Hmm kind of... I was referring to the fact that dummynet models pipes with a fixed bandwidth and centralized scheduler. Packets are released according to very high precision transmission timing. This means that serialization delay, queue buildup, and link behavior are simulated in a way that resembles real network conditions. Dummynet can provide a highly deterministic timing and queue behavior, which made it popular in networking research and WAN emulation experiments. TC cannot do that with the same accuracy.
I think much like other tools, think SELinux vs OpenBSD (unveil, etc) TC is more flexible (does more things) but there are _some things_ that can't do, and even for things both can do *BSD solutions are much simpler.
> The ZFS implementation is less buggy.
FreeBSD and Linux have been using the same implementation of ZFS for years.
AFAIK the most common is ARC but there are other areas as well.
On Linux, ARC memory is reclaimed using the kernel shrinker API which has historically been a problem. There has been several bugs leading to OOMs or system freeze due to high memory usage on systems that use ARC heavily.
On FreeBSD ARC is integrated directly with the VM subsystem. The stack is simpler, less bug-prone.
Now this is not a ZFS algo/whatever problem. It's an implementation/subsystem issue but it's still something to keep an eye on for the ZFS admin.
ps. I'm using ZFS on Linux for 15 years on a self-hosted, home backup server and only once I've had mem issues leading to crashes when I misconfigured the ARC. So it's fairly _stable_ but still not FreeBSD-level stable.
> … the kernel shrinker API which has historically been a problem. …
Is that still a problem?
A few weeks ago I noted a change in ARC-related documentation for OpenZFS on Linux. I can't remember the details (I can find them, if necessary) but I do remember that it was a significant improvement for Linux users.
Historically yes, is it still today? I am not sure.
You can emulate latency, packet errors, etc using netem tc [0] on Linux.
What I really want is the Windows tool for that. Can't call it equivalent, because clunsy is way superior.
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.
> as powerful as Linux
Can you explain what you mean by that? Can you give some examples?
Linux added differentiated support for high-scale and high-performance systems pretty early on. Good support for very high core counts, kernel bypass mechanisms, XFS, and more recently things like io_uring. This opened Linux up to a class of high-end applications that FreeBSD wasn't designed for.
FreeBSD was excellent for ordinary UNIX-y server things. If you were designing a high-end database engine though, where you mostly just need the OS to get out of the way, it was much easier to target Linux.
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.
> Is there anything FreeBSD can do that, say, Debian cannot?
Docker containers is a big one.
Docker it's a solution for a big Linux problem. FreeBSD would just resort to compatNx libraries (to run older binaries) and/or a jail.
How is it at running something like microk8s? Also do you have to build your own binaries for anything not in the distro?
> 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?
> … I think I'd want to switch to pkgbase but that makes me nervous. …
There has been a disproportionate amount of negative noise from people who know too little about pkgbase.
pkgbase is a good thing. A very good thing. A huge game-changer, in terms of testing STABLE and CURRENT.
Why not create a boot environment and try out FreeBSD 15 with pkgbase ? If the experiment is successful just make the boot environment the default otherwise throw it away...
With such powerful tools I find it fascinating that FreeBSD users are not more willing to experiment !
To be honest I've never tried boot environments. I know they are a thing, and I have my whole setup on ZFS, so maybe that's the perfect use case.
I haven't switched to pkgbase. Yet. I don't intend to for the time being. I set up a VM to test it, but I haven't gotten around to actually testing it.
FreeBSD is actually really nice as an OS, but Linux gets pretty much all of the application support. For example compare XigmaNAS with OMV, I'd really prefer to run my NAS on FreeBSD but Xigma has more or less stalled while OMV is being actively worked on.
I think the main difference is that Linux simply has more hardware support than FreeBSD.
That’s all it came down to with me.. FreeBSD doing WiFi circa 2002 was a remote dream. Shit even Linux you had to use ndiswrapper and it still prob wouldn’t work
FreeBsd is Systemd free.
> FreeBsd is Systemd free.
https://www.reddit.com/r/freebsd/comments/96pm7w/benno_rice_...
> Benno Rice: The Tragedy of systemd – BSDCan 2018 : r/freebsd
Don't be misled by the title. I thoroughly recommend listening to the whole thing.
I'm using Linux since the Slackware-on-a-CDRom days and systemd is a lost cause: it only got worse and worse and only kept meddling more and more into the Linux ecosystem.
The XZ "I only work on systemd distro" backdoor was the final straw (people are going to say it's unrelated but the fact is there: non-systemd Linux distro weren't affected).
I've been gradually switching my workflow to VMs and containers and my idea is to, eventually, run the VMs under FreeBSD's bhyve instead of running them from a systemd Linux distro (Proxmox in my case).
At long last I should soon be, once again, totally free of systemd (last time it was before it existed).
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.
> But the downside is enormous bloat
If you think Linux can have "enormous bloat" then Windows bloat by the same standards is terrifyingly humongous (and slow!).
Well, all those years ago, my testbed for installing and trying out FreeBSD was a 486 with 8MB of memory. That was a heck of a machine compared to the ones BSD grew up on, and it ran great. No GUI on that setup of course, but all the Unixy stuff... vi editor, C toolchain, NFS etc.
I don't know what's the minimum system to run no-GUI mainline Linux on these days. I'm sure BSD has gotten bloated too, but I'll bet not as much.
Stock FreeBSD is about 1.5GB. If you really strip it down to a barebones OS it's about 300MB.
It is.
Ironically windows still ships without basic functionality
FreeBSD is the macOS to Linux's Windows. Or better yet, the iOS to Linux's Android.
I mean, parts of FreeBSD literally are in macOS and iOS...
What kind of Brother laser printer is this? If it’s Postscript or PCL or AirPrint you don’t need drivers.
Brother ship mystery meat linux "drivers" that have a PPD that sends your document through Ghostscript I guess to scrub PostScript that the printer doesn't support.
I tried just using a generic PPD from openprinting.org but that caused the printer to spit out a ream of pages printed with binary junk, so mystery drivers it is.
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.
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.
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.
No one prevents You from installing Linux in a Bhyve VM and running Docker there.
Overhead of FreeBSD Bhyve Hypervisor is about 0.5% (measured in benchmarks) so You loose nothing.
Here You have easy and complete jumpstart into Bhyve in FreeBSD:
- https://vermaden.wordpress.com/2023/08/18/freebsd-bhyve-virt...
Regards, vermaden
Isn't that no longer necessary? Doesn't linuxulator + podman suffice?
> Doesn't linuxulator + podman suffice?
No it is not reliable enough. Some syscalls not implemented, there are edge case issues with procfs etc. Best to execute in a Linux VM.
it’s exceedingly rare that programs dont work with linuxulator, i use vivado daily and you can play games through linux steam and proton that way.
Unfortunately podman on freebsd is pretty early stage. I was only able to get very simple containers to run.
> 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?
You already trust random people in linux, you have to trust even more random and more people when you run docker.
Ports are quite large collection already. If you port yourself it's either up to 20 minutes plus compilation time or major nightmare. More and more software today assumes you run on linux only.
I think FreeBSD is great for setup and forget. If you have to interact with it regularly it's not worth it. Definitely not worth it for desktop.
You can run oci containers via podman.
it isn't anywhere close to the convenience of docker, but if you just need containerised OS-level virtualization FreeBSD has Jails which are really cool
You should avoid Docker, is the obvious answer, and grow to love FreeBSD jails.
I can not answer the other questions; for me Linux worked and works better. But that statement here:
> Do I have to trust random people for ports of software that runs natively on Linux, or port it myself?
This is a bit problematic in my opinion because ultimately we have to trust all who write open source code. This works well for the most part but there are malicious actors too. See the xz backdoor as example. Or various state actors who want to sniff after people. Age verification is the current attempt to sniff for people data, trying to push legislation by claiming "this is only to protect children" (while it has some interesting side effects, e. g. becoming a stepping stone for anyone wanting to sniff user data and relay this).
> FreeBSD seems good so far, but community and ecosystem are important.
Well, there are many more Linux users. Whether that is better or worse ... but it is a fact too.
If you just want to run a Docker container casually, perhaps do it on your personal computer instead of the home server. If there is some service you really can't manage to get running with jails or right on the BSD, bhyve and guest Linux should be easy enough.
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.
Intel has had a somewhat awkward relationship with FreeBSD forever. While they are forced to support it (for $reasons) they never have properly covered it.
I would say as of FreeBSD 12-13 most major issues are addressed from 1gig up to current 100g. There is an odd bug in 2.5g igc where some users have interface stalls whilst others like Netgate are shipping large numbers without issue, waiting to hear if this is firmware or not.
Source: I maintain several of the Intel drivers on a volunteer basis and used to send several Tbit/s to the Internet over them professionally.
Thanks for your contributions!
I do not believe that your problems are typical for FreeBSD servers.
I have been using FreeBSD servers for around 30 years. Most of them had Intel NICs and I have used at least 5 or 6 different kinds of Supermicro motherboards, both with Xeon and with Epyc.
Most servers have worked 24/7, without being rebooted for years and without having any minute of downtime except when I did some hardware upgrade or kernel upgrade.
I do not doubt that you had the problems described, but there must be some very unusual circumstances that have caused this. I would not be surprised if there was some problem with the version of Supermicro BIOS of your motherboards, and not with FreeBSD, because I have seen many bugs in Supermicro firmware. Or perhaps you had some buggy version of Intel NICs.
There is one advantage of Linux over FreeBSD, which is not widely known. Linux has a huge database of known bugs in various peripheral devices, including Ethernet NICs, and when one of those is recognized it applies workarounds for the bugs.
Like any other operating system, FreeBSD also implements workarounds for peripheral interfaces with known bugs, but because it has a much smaller user base also its database of bugs includes much fewer bugs, typically only those that had been reported by FreeBSD users. Because of this, I have seen cases when some hardware devices did not work well in FreeBSD, while they worked well in Linux, and the reason was always because Linux knew that they must not be used in the standard way, but it applied the corresponding workaround for their bugs.
Only Windows is shielded from the problems caused by bugs, because the hardware vendors write themselves the Windows device drivers and include in them any required workarounds for their bugs.
> There is one advantage of Linux over FreeBSD, which is not widely known. Linux has a huge database of known bugs in various peripheral devices, including Ethernet NICs, and when one of those is recognized it applies workarounds for the bugs.
Almost universal hardware support and workarounds for quirks is precisely the reason why everyone uses Linux even if they might want to use FreeBSD or something else. In other words, this advantage is known and is the reason why Linux is dominant in the server space today.
It is widely known that Linux has "better" hardware support for many peripheral devices, but few know what "better" means, i.e. that a lot of devices that you can buy have various bugs and in most cases their vendors do not document the bugs in any way, because they provide Windows drivers that contain workarounds for the bugs, and they do not care about other operating systems.
The users of other operating systems must discover the bugs and how to handle them by reverse engineering, and here Linux has the advantage of a much greater user base than any alternative, so in most cases the bugs will be identified by some Linux user, and then either the user or the maintainers of the corresponding Linux subsystem will implement a workaround for the bug.
If such a workaround exists, an enterprising *BSD user can look at the code and determine what it is and apply a similar workaround in their BSD.
Usually workarounds/quirks need the highest level understanding of the device driver and the device. There are few people in the world with such mastery and fewer people capable of translating this to another operating system. In concept this is simple but in most cases it is difficult.
This looks to be a theme in FreeBSD, specifically tweaking mbuf numbers because of exhaustion [1], [2], [3], [4] (and not to mention any posted on the freebsd bug tracker). The fact that you have options to tweak mbufs and limits in the first place just doesn't seem like a well thought out design -- in Linux you never have to specify skbuff (Linux's mbuf equivalent) numbers for any reason. I don't even know if my issue was hardware specific or just a FreeBSD-ism to do with mbufs, but it is a class of issue that just doesn't exist in Linux.
[1] https://serverfault.com/questions/335461/pfsense-mbuf-full-w...
[2] https://unix.stackexchange.com/questions/394876/how-to-fix-m...
[3] https://redmine.pfsense.org/issues/5553
[4] https://docs.netgate.com/pfsense/en/latest/hardware/tune.htm...
While you are right that it would be better to never need tweaking the number of buffers, all your links show such a problem caused by the same application, the firewall pf.
I assume that for some reason pf consumes more buffers than other applications, so it is likely to cause such problems. So pf users should preemptively change the default configuration.
I have never used pf, because I prefer the native FreeBSD firewall, both to pf and to the Linux firewall.
With the native firewall and with the many other networking applications that I have run, I have never seen buffer exhaustion, and like I have said, the mean time between reboots was well above a year.
FreeBSD and the other *BSDs have always been famous for not needing reboots, even after years of continuous operation. For this goal, avoiding memory fragmentation caused by dynamic allocation is essential. Thus static allocation for various kinds of resources might be necessary.
When my company was briefly running FreeBSD on new (5 years ago) Lenovo servers with Intel NICs, we too had some issues. I don't remember the exact details, but our sysadmin at the time had to do a bunch of work to get it fixed.
I haven't had reliability issues but I could never get decent performance out of the FreeBSD network stack. Across Intel and Mellanox 10 Gbps NIC, it always ended up capping out at around 5 Gbps. Using TrueNAS CORE and OpnSense. Switch to Linux (SCALE and OpenWRT) and I can max out 9 Gbps.
Hail u/cperciva.
Or rather all hail u/cperciva for freebsd-update.
> all hail u/cperciva
Colin Percival (FreeBSD Primary Release Engineering Team Lead) longer uses that ID in Reddit.
Instead: /u/perciva
Most recently, in /r/freebsd https://www.reddit.com/r/freebsd/comments/1rphd7t/freebsd_14...
All hail.
I colocate all my servers that all run FreeBSD.
Myself has been through generational hardware, and had had zero issues with any apart from when the raid card failed.
Network has been solid. ZFS has just worked. Not sure what your issues were however colocating since FreeBSD 8, and now colocating 16-CURRENT on my the server. FreeBSD has been rock stable in my books.
2x Dell R630 and 1x Cisco U220 M5
doublerabbit@cookie:~ $ uname -a && uptime
FreeBSD cookie.server 12.2-BETA1 FreeBSD 12.2-BETA1 r365618 GENERIC amd64
10:39PM up 1752 days, 1:31, 1 user, load averages: 0.64, 1.30, 1.31> 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.
FreeBSD supports a much larger range of hardware than MacOS. It's a bit strange to bemoan hardware support, then switch OS and buy very specific hardware for that OS.
Imagine quitting MacOS because it doesn't support Realtek RTL8188CUS.
Something that a Mac user or developer, those that have been on the ecosystem for decades would never bother to do anyway.
Well it just so happens that the best hardware in the world for desktop use—literally years ahead of any competition—is made by the makers of macOS and is totally supported by macOS.
What you say is true only when you define "desktop use" in a certain way, which corresponds to what an Apple PC is good for.
I define "desktop use" in another way, and for my definition any Apple PC is completely non-competitive, by having a much lower performance and a much higher price than a desktop PC using an AMD Ryzen CPU.
Apple PCs have exceptional single-thread performance, but that is irrelevant for me. I care about multi-threaded performance and especially about floating-point FP64 and big integer computational throughput, for which the Apple CPUs are weak, one could say years behind their competition, except that Apple does not make any attempt to compete in this domain.
An Apple PC may be the optimum PC for your needs and that is fine, but you should not believe that any computer user has the same needs as you.
100%. It reminds me of how a ton of FreeBSD devs moved to Mac during the Darwin days. Then they were abandoned by Apple once they stopped contributing to upstream.
We weren’t abandoned by Apple — Apple never contributed to upstream. Darwin and OpenDarwin were APSL projects and never fed code back into FreeBSD.
Using macOS meant we got laptop hardware that worked reliably, including Wi-Fi, running a more or less BSD-derived userspace.
The lack of graphics and Wi-Fi driver support on the *BSDs is not Apple’s fault. It has always been a resource issue.
Thanks to the AT&T lawsuit, Linux secured momentum at a critical juncture — and here we are. Path dependence and the complexities of real life mean that “winning” is never just a question of technical merit.
A consequence of the license, which allows Apple and Sony to do exactly that.
I and other FreeBSD developers are okay with that — if we weren’t, we’d be using a different license.
Looking to some complaints doesn't feel like everyone is.
do you remember opendarwin? i was also at puredarwin but the project seams death
Yes, and Apple did kill it, unfortunately — but it was never an effort to push code upstream into the BSDs.
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 was inspired to install FreeBSD on my spare minipc after reading this post. After boot the USB mouse didn't work at first.
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.
that makes no sense, youtube hasn’t used flash in ages. If you use any modern browser on freebsd you’d be able to play the video.
I'd infer that the GP is talking about some time back and they are no longer in school.
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!
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'd love to move my home server to FreeBSD but I would like to run Immich on it.
Immich assumes you're running Docker and I can't seem to get Linux running in a bhyve VM with Intel Quick Sync acceleration.
Could be worth checking out: https://github.com/immich-app/immich/discussions/24931
I prefer syncting
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 spent 20 minutes reading forum posts and vague documentation because MacOS couldn’t confirm a .md file wasn’t free of malware.
I could say some nice things about MacOS, but it certainly is not “cohesive” any more.
> MacOS couldn’t confirm a .md file wasn’t free of malware
That sounds like a hilarious story. What was going on?
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.
There's three kinds of documentation:
* Wiki-style "HOWTO"-based that helps you solve a particular problem (Arch and Gentoo wikis showcase this style well)
* Reference documentation that reminds you how you solved a problem (man pages are great examples here)
* Comprehensive documentation that truly documents the system, but can be a bit more obscure if you're not reading it "cover to cover" - textbook style (This is the older "original" software documentation type, which the BSD docs are an example of)
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.
i plan to run netbsd on my chromebook do you have a good manual? or how to?
Hey; Linux refugee here.
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.
Nomad?
how about ansible?
I don’t have any experience with it, but it sounds plausible. What about FreeBSD / Unix native things, like syslog or jails?
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!!!
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've been using both Linux and BSD since 2000. Honestly, I prefer Linux on the desktop. My dev workstation runs Arch, and I keep a FreeBSD VM running to do OS and ports builds.
As a server OS I find FreeBSD really consistent and easy to administrate. I never have trouble finding things: packages always go in /usr/local. The old-school init system works great at what it's designed to do, and all the startup scripts are easy to understand. The whole thing just feels kind of cozy and familiar. If you like working in a shell then FreeBSD just kind of feels like /home.
Coming from modern Linux though, some of the constructs can feel a bit outdated. Usually this gives me a warm fuzzy feeling, but sometimes it's a real pain (looking at you, make(1)). It's like hacking Perl, once you understand the idiom and what it's good at then you can be good friends.
If you want to run a mail server for 20 years and go through multiple hardware and OS upgrades with minimal pain and maximal uptime then you can't beat it.
I'm running Sway on FreeBSD daily and it's way snappier and sharper than on any Linux distro I tried. Go ahead, it doesn't hurt.
I love FreeBSD for its documentation. To answer your question about Wayland specifically:
https://docs.freebsd.org/en/books/handbook/wayland/
If you want something with a graphical environment ready to run, check out GhostBSD, which is based on FreeBSD and features MATE:
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'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?
No. FreeBSD enthusiast will tell you there's no need for something even remotely similar. I love the OS but some of the zealots are the reason for the miniscule size of the community.
Well written and clearly not AI generated. So refreshing these 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?
That's one of the best things I've read this week. Thank you.
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?
firewalls are a common example (many Linux houses have a BSD-based firewall at the edge) but any "single application" setup may run on BSD - Netflix, for example.
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].
[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...
I don't want to be that guy, but zfs on freebsd was kind-of-experimental until around 2012;AFAIK in 2012 (Freebsd 9) root on zfs was a manual process, and not that easy to upgrade. Root on zfs is somewhat "recent"- it took years to get to the installer. My company at the time was basically a bsd shop (openbsd and freebsd), and the opensolaris(12?) version was still quite ahead. Still have my opensolaris tshirt of "first 5000" :)
Would love to know more about your history with BSD.
You're totally right and I appreciate calling this out. I realized the 2008 date was wrong some time after the HN comment became un-editable.
Ok, where are the companies using FreeBSD?
How do you get hired if you do happen to have proper FreeBSD skills? It's notably absent from all the job listings.
> Ok, where are the companies using FreeBSD?
Not quite twenty years ago Yahoo! was using (also, I suspect) FreeBSD.
> How do you get hired if you do happen to have proper FreeBSD skills?
By advertising your other skills?
Playstation is based on FreeBSD, so I would guess that Sony has some serious FreeBSD people working there who created one of the most popular a video game console - that's pretty cool
Well, I mean... Netflix is the example I think most people have heard of:
https://freebsdfoundation.org/end-user-stories/netflix-case-...
But it's still a pretty small market share.
Word is that NetApp and Juniper are using FreeBSD. What these have in common is that they rely heavily on FreeBSD's I/O performannce and capabilities which is said to be head and shoulders above Linux.
I love FreeBSD too, I used to use it on my desktop as a daily driver. I probably still would if it would support my video card (RDNA4).
These days I prefer to run small systems and basic services. I don't want webguis or docker images anymore.
FWIW, agreed.
It is very odd to me that I often read people asking about alternative OSes -- Linux compared to Windows, or FreeBSD compared to Linux, or OpenBSD compared to FreeBSD -- and they say that they want to move except that they desperately need to keep {something arcane}...
And often that arcane thing is why I am interested in getting off the original system under discussion.
The appeal of the BSDs has always been an incredibly stable entire system that means you don't need Docker to run fifteen variations of the various libraries necessary to (Stallman) build a GNU/Linux.
I used to but driver support for wireless devices was so inconsistent I had to move to Linux.
That's unintentionally hilarious -- some of us remember 15-20 years ago when flaky support for wireless devices was the biggest reason people would decide Linux wasn't ready for desktop yet and avoid switching from Windows to Linux. (Well, Windows to dual-boot -- Windows users were never fully willing to let go of the video games angle at the time.)
Linux had better WiFi 20 years ago than FreeBSD has today.
I still prefer FreeBSD.
It is hilarious. When I installed SLS 1.0 I had to assemble the machine to match the drivers available. 92 or 93. I vaguely remember I needed a SCSI hard disk.
Remember that most machines back then were Ethernet, not WiFi.
First wifi device I used was a PCMCIA card from Lucent, claimed 2mbps speeds. Still have it somewhere. I don't think I ever got Linux or BSD to work.
> Remember that most machines back then were Ethernet, not WiFi.
Not "most" -- all.
802.11 networking was standardised in 1997.
The first versions to really see significant mass adoption were 802.11b and then 802.11a in 1999.
https://hewlettpackard.github.io/wireless-tools/Linux.Wirele...
installed it on my n100 last night. it didn't detect my USB mouse.
I could never get sleep to work, and got tired of rebooting 17 times a day.
OpenBSD might have "better" support for sleep and hibernate, but I didn't succeed in installing it on this laptop: I think it required me to connect an Ethernet cable, which I wasn't going to do.
Veering even more off-topic: I've just installed OpenSUSE Kalpa on this laptop. That's not regular OpenSUSE, by the way. Previously, each of the like, 5 problems I've encountered doing it, would've caused me to give up - but ChatGPT helped me fix all of them! I think this is going to become my daily driver for a while now.
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.
https://wiki.freebsd.org/Rust for Rust seems to be stale, but not yet categorised as such – https://wiki.freebsd.org/CategoryStale
In <https://lists.freebsd.org/archives/freebsd-hackers/2025-Augu...> (August 2025), Konstantin Belousov (kib@) write:
> There was a long and hot thread about 'Rust in base' recently. …
Unfortunately, the list archives are not suitably indexed by popular search engines, so, for example, https://www.startpage.com/do/dsearch?query=Rust+base+site%3A... does not find what's required. Sorry.
https://www.phoronix.com/news/FreeBSD-Q4-2025-Status-Report includes Michael Larabel's quote from the final status report of 2025:
> At some point in early 2026 the rust KPIs should be stable enough for interested developers to try writing new code with them. They will not be perfect, but I want to make sure they work roughly like existing drivers expect and also fit the expectations of rust developers before asking for testers. Hopefully the Apple drivers will be back up to parity with the initial WIP in C in the first half of 2026 as well.
>> There was a long and hot thread about 'Rust in base' recently. …
Maybe this,
https://forums.freebsd.org/threads/the-case-for-rust-in-the-...
?
Does FreeBSD support latest PCIe generations and Thunderbolt?
beacuse u are lucky
Can we say FreeBSD is more secure than Linux, because it’s smaller and less of a target?
Not clear!
Rule of thumb, its not. Common stuff like address randomization is a recent default, afaik still doesnt have random process ids, and the base permissions arent stellar. However I would prefer jails any day of the week vs the clusterf** that are namespaces and cgroups.
How many remotely exploitable zero days has FreeBSD had in its init system this decade?
SystemD has to be in the dozens at this point.
Right, because linux security == init system used by some distros. My experience with FreeBSD may be somewhat dated (I've used it since the 4.x days, provided commercial support for it for more than 15 years), an that is not my experience - at all. Obviously, it depends on the threat model you are considering and how far you want to go. The default install does not have (or had) sane security defaults, at least comparing to your random $ystemd linux distro; try installing both and give local shell to a red team and see how fast they get root access.
sysctl kern.randompid=1
Remember: If z/OS were as widely used as Windows 95, it would be just as insecure!
God, it reminds me of Slashdot trolls in the 1990s..
me too
> 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:
Now find the documentation ... try it.
You may find it:
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?
Just one small note: those experiences are from 2002 and I was writing about my first experience when running it on my Sony Vaio. Running on a modern 64Gb Ram hardware is a totally different experience, 24 years later
>> I could read my email in mutt while compiling, something that was practically impossible on Linux
> Ok sorry, I stopped reading there.
Why? That's a treasured feature. https://xkcd.com/303/
The Arch Wiki it's a joke as it gets obsolete with every major upgrade. OpenBSD has the FAQ and all of the base it's throughly documented. GNU/Linux manpages? Info pages? Often either incomplete or missing. Don't let me start on compatibility. On your beloved overengineerd turd, you need to resort to either containers or hacks to run 10 yo software. FreeBSD will just run it through compatNx libraries, where N is the version number, and there's a -32 (bit) suffix for obvious needs. Now, how can you run legacy software under current Arch Linux? Yeah, there's Flatpak, but I've found broken software on it.
Altough on compatibility, under 9front everything it's statically compiled, period. Compile, store, copy back, run.
Docs? man pages, and /sys/doc. Easier to be understood and set.
Current Unixes are too bloated. Yes, FreeBSD too. NetBSD and OpenBSD, a bit less. GNU/Linux it's such a monster that over time I'd guess Guix will just keep Coreutils as a toolbox and everything will be jitted Guile/Scheme, and for the rest of the distros, it will just be Wayland+Gnome+Flatpak OS. Now try hacking that. Try creating a working 32 bit OS with it. Documentation beyond GUIX' info files? Good luck, man will be a legacy tool called from Info from Guix.
SystemD? Over time, Gnome won't be under non SystemD OSes. Forget it under BSD's and shims, KDE will be the only option (and under Guix too). The irony, GNU Networked Object Model Environment outside of the GNU os.
Meanwhile, by default GNU/Linux has more propietary bits in the kernel than GNU bits. Untar it, Radeon depends on nonfree firmware. So does tons of SOCS, audio devices, wireless cards. Linux Libre + Guix? Not with Gnome, maybe with a Guile JIT/AOT'ed desktop environment, a la Cosmic but with AOT'ted Guile instead of Rust. Forget cohesiveness, your Redhatware OS will be as native to the rest as Waydroid inside Fedora Silverblue. Seamless, but not native. And with similar issues on running some software in Waydroid without hacks faking up the existence of some blobs.
And as tons of infra depends on SystemD and blobs, guess what will happen to Arch and the rest of the distros. It will jut be second class, Pacman packaged Fedoras.
> The Arch Wiki it's a joke as it gets obsolete with every major upgrade
I find this claim hilarious because well, arch doesnt have the concept of major upgrades. And rather their documentation is some of the fastest to cover relevant changes with regards to users' needs in software.
Can you find some obsolete bits here or there? Sure, but they're almost always visually flagged as OoD and disputed until consensus is certain rather than immediately yeeted.
>major upgrade
Arch stepped over broken upgrades.
AKSHUALLY...
[dead]
Crafted by Rajat
Source Code