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.
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.
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
> 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.
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.
> 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?
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.
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.)
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.
> 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.
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.
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.
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.
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).
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.
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.
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.
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.
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 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).
>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.
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.
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.
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.
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.
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.
> 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.
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.
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.
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.
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.
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.
> 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?
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 !
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.
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.
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.
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.
> 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.
> 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.
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.
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).
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.
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
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.
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.
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.
> 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.
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.
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 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" :)
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 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 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.
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.
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.
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?
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?
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!!!
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.
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
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 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.
> 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.
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?
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.
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.
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'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.
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.
Hendrikto | a day ago
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.
vermaden | a day ago
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
ComputerGuru | 23 hours ago
sidkshatriya | 22 hours ago
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.
c-c-c-c-c | 17 hours ago
elcritch | 18 hours ago
shevy-java | a day ago
> 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.
fridder | a day ago
mghackerlady | 23 hours ago
0x457 | 22 hours ago
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.
Gud | 20 hours ago
cess11 | 19 hours ago
shevy-java | a day ago
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?
4fterd4rk | a day ago
anthk | a day ago
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.
guenthert | 23 hours ago
> Ok sorry, I stopped reading there.
Why? That's a treasured feature. https://xkcd.com/303/
SanjayMehta | a day ago
crdrost | a day ago
Gud | 19 hours ago
I still prefer FreeBSD.
SanjayMehta | 14 hours ago
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.
lproven | 3 hours ago
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...
amadeuspagel | a day ago
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.
nullpoint420 | 23 hours ago
frumplestlatz | 23 hours ago
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.
pjmlp | 23 hours ago
frumplestlatz | 20 hours ago
pjmlp | 19 hours ago
hideout_berlin | 22 hours ago
frumplestlatz | 20 hours ago
freeopinion | 23 hours ago
Imagine quitting MacOS because it doesn't support Realtek RTL8188CUS.
pjmlp | 23 hours ago
bitwize | 20 hours ago
adrian_b | 19 hours ago
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.
imagetic | a day ago
krylon | 23 hours ago
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).
whizzter | 23 hours ago
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.
BirAdam | 22 hours ago
whizzter | 22 hours ago
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.
frumplestlatz | 20 hours ago
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.
akdev1l | an hour ago
Does `podman machine init` not work in FreeBSD? In those other platforms it will spin a small Linux VM to run containers on.
jbverschoor | 20 hours ago
TacticalCoder | 14 hours ago
If people want or need to run Docker on FreeBSD, they can run a Linux VM under bhyve.
toast0 | 23 hours ago
Stability of user interface and documentation.
throwaway27448 | 22 hours ago
toast0 | 21 hours ago
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.
[1] https://www.debian.org/releases/stable/amd64/
gzread | 13 hours ago
grahamjperrin | 11 hours ago
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...
adiabatichottub | 20 hours ago
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.
MisterTea | 22 hours ago
adiabatichottub | 20 hours ago
On FreeBSD I know its always going to work.
grahamjperrin | 11 hours ago
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.
adiabatichottub | 9 hours ago
akimbostrawman | 6 hours ago
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...
znpy | 16 hours ago
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.
evanjrowley | 22 hours ago
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.
sidkshatriya | 22 hours ago
shrubble | 22 hours ago
sidkshatriya | 19 hours ago
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.
HackerThemAll | 17 hours ago
https://www.phoronix.com/review/linux-70-filesystems
GuestFAUniverse | 17 hours ago
And only than those benchmarks would be more interesting to me.
lproven | 3 hours ago
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.
Numerlor | 15 hours ago
sidkshatriya | 8 hours ago
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.
krylon | 19 hours ago
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.
gzread | 13 hours ago
I heard the developer got sidetracked into writing himself an AI girlfriend. (Not sarcasm)
PhilipRoman | 5 hours ago
krylon | 22 hours ago
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.
zenoprax | 21 hours ago
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.
atmosx | 20 hours ago
HackerThemAll | 17 hours ago
overfeed | 17 hours ago
st3fan | 12 hours ago
If you want to compare Jails to something on Linux then I think LXD is probably much closer to what Jails are.
assimpleaspossi | 16 hours ago
burner420042 | 6 hours ago
atmosx | 6 hours ago
joshstrange | 16 hours ago
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.
assimpleaspossi | 16 hours ago
Yes. You are holding it wrong. And it's obvious from your comment.
irishcoffee | 16 hours ago
assimpleaspossi | 12 hours ago
grahamjperrin | 11 hours ago
adrian_b | 14 hours ago
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.
idoubtit | 2 hours ago
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
AdieuToLogic | 13 hours ago
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...
grahamjperrin | 12 hours ago
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 …
AdieuToLogic | 11 hours ago
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.
andxor | 8 hours ago
grahamjperrin | 12 hours ago
https://mastodon.bsd.cafe/@grahamperrin/116168374700889783
> Would anyone like to say something? > > …
jmmv | 20 hours ago
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?
sidkshatriya | 19 hours ago
With such powerful tools I find it fascinating that FreeBSD users are not more willing to experiment !
jmmv | 19 hours ago
krylon | 19 hours ago
grahamjperrin | 11 hours ago
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.
atmosx | 20 hours ago
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
c0balt | 20 hours ago
[0]: https://www.man7.org/linux/man-pages/man8/tc.8.html
atmosx | 17 hours ago
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.
allreduce | 20 hours ago
[0]: https://man.archlinux.org/man/tc-netem.8.en
favorited | 17 hours ago
FreeBSD and Linux have been using the same implementation of ZFS for years.
atmosx | 16 hours ago
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.
grahamjperrin | 11 hours ago
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.
atmosx | 10 hours ago
gsich | 16 hours ago
https://jagt.github.io/clumsy/index.html
adrian_b | 19 hours ago
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.
irishcoffee | 18 hours ago
This example seems very hand-wavy. What camera?
adrian_b | 18 hours ago
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.
irishcoffee | 17 hours 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.
adrian_b | 15 hours ago
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).
irishcoffee | 15 hours ago
adrian_b | 14 hours ago
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.
adiabatichottub | 18 hours ago
Same. We've got qmail config files with 2006 as the mtime
gerdesj | 15 hours ago
So, no patching. I used to boast about my NetWare server uptimes but that is so noughties 8)
adiabatichottub | 13 hours ago
grahamjperrin | 12 hours ago
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
AdieuToLogic | 11 hours ago
> 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).
blackhaz | 7 hours ago
Too bad they dropped support for it.
adiabatichottub | 9 hours ago
MarkusWandel | 17 hours ago
george916a | 12 hours ago
righthand | 18 hours ago
TacticalCoder | 14 hours ago
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).
grahamjperrin | 11 hours ago
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.
liendolucas | 16 hours ago
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.
rootnod3 | 12 hours ago
johng | 15 hours ago
jdefr89 | an hour ago
grahamjperrin | 12 hours ago
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
chillfox | 8 hours ago
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.
jandrewrogers | 8 hours ago
lproven | 3 hours ago
Can you explain what you mean by that? Can you give some examples?
antihero | 6 hours ago
debian3 | 2 hours ago
Docker containers is a big one.
pseudohadamard | an hour ago
endsandmeans | 26 minutes ago
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.
badgersnake | 23 hours ago
CodeCompost | 23 hours ago
Immich assumes you're running Docker and I can't seem to get Linux running in a bhyve VM with Intel Quick Sync acceleration.
messe | 23 hours ago
jaypatelani | 22 hours ago
smm11 | 23 hours ago
ogogmad | 22 hours ago
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.
evanjrowley | 22 hours ago
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...
aforwardslash | 16 hours ago
evanjrowley | 31 minutes ago
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.
seethishat | 22 hours ago
hideout_berlin | 22 hours ago
stego-tech | 22 hours ago
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.
MarkusWandel | 22 hours ago
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.
sidkshatriya | 22 hours ago
If you think Linux can have "enormous bloat" then Windows bloat by the same standards is terrifyingly humongous (and slow!).
Asooka | 22 hours ago
MarkusWandel | 15 hours ago
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.
adiabatichottub | 13 hours ago
throwaway27448 | 13 hours ago
philistine | 21 hours ago
steve1977 | 20 hours ago
massysett | 13 hours ago
kalleboo | 11 hours ago
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.
gosukiwi | 22 hours ago
hedora | 15 hours ago
I could say some nice things about MacOS, but it certainly is not “cohesive” any more.
7F902DDA | 12 hours ago
That sounds like a hilarious story. What was going on?
sgt | 22 hours ago
commandersaki | 21 hours ago
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.
dewarrn1 | 20 hours ago
commandersaki | 17 hours ago
grahamjperrin | 10 hours ago
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.
doublerabbit | 20 hours ago
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
kev009 | 20 hours ago
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.
miguno | 5 hours ago
adrian_b | 19 hours ago
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.
sidkshatriya | 19 hours ago
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.
adrian_b | 19 hours ago
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.
commandersaki | 16 hours ago
[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...
adrian_b | 15 hours ago
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.
kalleboo | 10 hours ago
LeonenTheDK | an hour ago
w4rh4wk5 | 20 hours ago
xenophonf | 20 hours ago
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:
https://www.ghostbsd.org/
adiabatichottub | 19 hours ago
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.
nesarkvechnep | 5 hours ago
myylogic | 19 hours ago
aap_ | 19 hours ago
c-c-c-c-c | 17 hours ago
estebank | 15 hours ago
brcmthrowaway | 18 hours ago
aborsy | 18 hours ago
Not clear!
aforwardslash | 16 hours ago
hedora | 15 hours ago
SystemD has to be in the dozens at this point.
aforwardslash | 6 hours ago
adiabatichottub | 14 hours ago
msla | 11 hours ago
God, it reminds me of Slashdot trolls in the 1990s..
dwrodri | 17 hours ago
How do FreeBSD users get around the inconveniences associated with the "the rest of the world" running on Linux?
hedora | 17 hours ago
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.
ijustlovemath | 17 hours ago
hedora | 17 hours ago
ochoseis | 16 hours ago
QuantumNoodle | 16 hours ago
h4kunamata | 16 hours ago
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!!!
pfp | 15 hours ago
How do you get hired if you do happen to have proper FreeBSD skills? It's notably absent from all the job listings.
adiabatichottub | 15 hours ago
https://freebsdfoundation.org/end-user-stories/netflix-case-...
But it's still a pretty small market share.
andrehacker | 15 hours ago
merpkz | 6 hours ago
olivierestsage | 15 hours ago
waynesonfire | 14 hours ago
grahamjperrin | 11 hours ago
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.
waynesonfire | 10 hours ago
Maybe this,
https://forums.freebsd.org/threads/the-case-for-rust-in-the-...
?
MrResearcher | 9 hours ago
wang_pp8 | 9 hours ago
lproven | 2 hours ago
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.
burner420042 | 6 hours ago
leavenotracks | 6 hours ago
kombine | 5 hours ago
nesarkvechnep | 5 hours ago
Arch-TK | 5 hours ago