I delayed upgrading to 15.0 after it was released, but last weekend I finally did it, and it left me wondering why I hadn't done it sooner, because it went quickly and smoothly.
Is there anything FreeBSD can do that, say, Debian cannot? Probably not (at least I cannot think of anything). When I set up the server, ZFS was a huge selling point, but I heard that it works quite well on Linux, these days. But I appreciate the reliability, the good documentation, the community (when I need help).
For example the support for magnetic tapes and for a few other SCSI peripherals is better in FreeBSD. The Linux utility for controlling a LTO tape drive lacks some important options that the corresponding FreeBSD utility has.
I have a tape drive, and to be able to use it like I want I had to move it to a FreeBSD server.
Some years ago I was using a surveillance camera that was much easier to use in FreeBSD than in Linux, if you wanted to record good quality video and audio. I have not tried more recently to use such cameras in Linux, to see if now the recording quality is better.
So while there are more hardware devices that have better support in Linux than in FreeBSD, there are also devices with better support in FreeBSD than in Linux.
However the main reason why I use FreeBSD on many of my servers is that I need much less time for their administration than for Linux servers. In my experience, Linux servers need much less time for administration than Windows servers, and FreeBSD compares to Linux like Linux to Windows.
I have FreeBSD servers that I have not touched for years, and they have worked 24/7 with no downtime and no rebooting, and this includes servers connected directly to the Internet, which implement firewalls, routers and various services, like NTP, DNS servers and proxies, e-mail servers, web servers and proxies etc.
Same. We've got qmail config files with 2006 as the mtime
Could you give us another hint?
> The Linux utility for controlling a LTO tape drive lacks some important options that the corresponding FreeBSD utility has.
That should be easy to list, no? It's been a while since I used a LTO drive, but I don't know what I missed.
> I have FreeBSD servers that I have not touched for years
Are you sure, they are still "yours"?
This example seems very hand-wavy. What camera?
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.
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.
Also, a few years ago the FreeBSD people decided to throw away their own ZFS implementation and import the linux one (OpenZFS) because they couldn’t keep up with the development pace.
Nowadays ZFS development is collaborative but in each major freebsd release it’s clearly marked which OpenZFS releases they imported in the FreeBSD codebase.
On FreeBSD I know its always going to work.
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.
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.
Stability of user interface and documentation.
True.
I have OpenZFS-native encrypted root-on-ZFS for Kubuntu 25.10, made ultra-simple by the installer for Ubuntu (25.04 at the time).
FreeBSD can not yet do this. Please see, for example, https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=263171
> 263171 – add loader(8) and boot loader menu support for boot with OpenZFS-encrypted ROOT
The main gripe is probably Docker and/or software depending on Linux-isms that can't be run natively without resorting to bhyve or smth alike that.
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.
Yes. Emulate traffic latency using IPFW and dummynet[^1]. There is no Linux (or OpenBSD, NetBSD) counterpart.
The ZFS implementation is less buggy.
FreeBSD and Linux have been using the same implementation of ZFS for years.
Can you explain what you mean by that? Can you give some examples?
And now I am looking at moving over to k3s (still on Alpine) because everyone is providing Helm charts, so it seems easier.
I really like FreeBSD, but it's just easier to go with the flow.
I 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?
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.
With such powerful tools I find it fascinating that FreeBSD users are not more willing to experiment !
I know that Linux distros can accommodate ZFS, but it's a fair-weather situation due to licensing and most distros' preference for BTRFS.
Docker containers is a big one.
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).
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.
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.
If you think Linux can have "enormous bloat" then Windows bloat by the same standards is terrifyingly humongous (and slow!).
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.
I tried just using a generic PPD from openprinting.org but that caused the printer to spit out a ream of pages printed with binary junk, so mystery drivers it is.
I'm in the process of converting and consolidating all my home infra into a mono-compose, for the simple reason I don't want to fiddle with shit, I just want to set-and-forget. The joy of technology was in communications and experiences, not having to dive through abstraction layers to figure out why something was being fiddly. Containers promised to remove the fiddliness (as every virtualization advancement inevitably promises), and now I'm forced to either fiddle with Docker and its root security issues, fiddle with Podman and reconfiguring the OS for lower security so containers don't stop (or worse, converting compose to systemd files to make them services), or fiddle with Kubernetes to make things work with a myriad of ancillary services and CRDs for enterprises, not homelabs.
For two years now, there's been a pretty consistent campaign of love-letters for the BSDs that keep tugging at what I love about technology: that the whole point was to enable you to spend more time living, rather than wrangling what a computer does and how it does it. The concept of jails where I can just run software again, no abstractions needed, and trust it to not misbehave? Amazing, I want to learn more.
So yeah, in lieu of setting up the second NUC as a Debian HA node for Docker/QEMU failover, I think I'm going to slap FreeBSD on it and try porting my workloads to it via Jails. Worst case scenario, I learn something new; best case scenario, I finally get what I want and can finally catch up on my books, movies, shows, and music instead of constantly fiddling with why Plex or Jellyfin or my RSS Aggregator stopped functioning, again.
Anyways had enough of the random downtime, I just switched to Linux which didn't have these issues.
I'd say the best part of FreeBSD though is freebsd-update which was a game changer from the previous make world shenanigans.
I 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.
Myself has been through generational hardware, and had had zero issues with any apart from when the raid card failed.
Network has been solid. ZFS has just worked. Not sure what your issues were however colocating since FreeBSD 8, and now colocating 16-CURRENT on my the server. FreeBSD has been rock stable in my books.
2x Dell R630 and 1x Cisco U220 M5
doublerabbit@cookie:~ $ uname -a && uptime
FreeBSD cookie.server 12.2-BETA1 FreeBSD 12.2-BETA1 r365618 GENERIC amd64
10:39PM up 1752 days, 1:31, 1 user, load averages: 0.64, 1.30, 1.31I 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.
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.
[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...
My internet is slow and I can never tell how far along it is or if it's stalled completely for some reason, which happens a lot.
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.
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
> 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.
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.
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.
Imagine quitting MacOS because it doesn't support Realtek RTL8188CUS.
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.
I could say some nice things about MacOS, but it certainly is not “cohesive” any more.
That sounds like a hilarious story. What was going on?
Immich assumes you're running Docker and I can't seem to get Linux running in a bhyve VM with Intel Quick Sync acceleration.
I made a career in Linux and Windows, but always have had a heart for FreeBSD. A person I consider by technical mentor, loved FreeBSD. My first "Admin" job was at a small ISP where he worked. That was where I got my first taste of FreeBSD which I believe was version 5.3? He made sure that all consoles were set to show beastie and I really learned a ton which set up the rest of my tech career.
Later on, he committed suicide, and I use it as a daily driver in honor of him.
I have Linux vms in bhyve. I use jails, etc. I find it pleasant and I prefer it over Linux, if I do not mind its paper cuts (for Desktop use).
I had to previously use wifi dongles since it did not support AX200 at decent speeds. Since version 14 though, it has jumped leaps and bounds. I no longer need it.
What I still have to do is use a custom xorg.conf, because I have dual amd and intel video cards. If I start without it, it says I must specify Bus Ids. I can use pure wayland, but if anything requires X, I still need a working xorg.conf.
If you are willing to deal with paper cuts, and workarounds, it rocks. If you do not have time for that, it may not be for you (desktop wise).
Server wise, I still love it, just like 5.3 days.
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:
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 want to have a bunch (5-10) of freebsd cattle-style servers to run a service on.
What’s the preferred infrastructure as code style approach to setting them up?
Some will be bare metal with kvm console access. Some will be VMs. They will be heterogeneous and not in one DC.
I probably don’t need zfs for this application (raw iops matter more than snapshots, etc).
I have previous experience with kubernetes, and am not interested in using it again.
Monitoring, logging, deterministic “zero to working” install and updates are probably the main requirements.
My personal issue is that I do not believe FreeBSD will give me a smooth experience to get my GPU and what not running. On Mint Cinnamon, I only had to install the latest supported kernel to get my RTX and WiFi6 card recognised.
Debian, the reason why I run Debian as a server everywhere, even in my 3D printer is because it just work, and not just that.
I only run Debian Netinst version, that means to only install standard system and SSH, text mode is the way.
We are talking about 300MB of memory being used by Pihole + Unbound Recursive DNS of 512MB running on a Debian 13.
Disk space?? 1GB or so I guess.
These are my blockers to even try raw FreeBSD, lack of proper hardware support and as a server even if I remove everything I can, I do not imagine FreeBSD running with 300MB/1G of resources.
Not to mention if you work in IT in any way, the last thing you wanna is fighting the system you use to solve another problem, that is why I left Ubuntu after 13years or so, it is a Windows within the Linux world now.
A distro Linux must just run, no dramas, no issues, major system release goes like nothing happened. That matters!!!
* Wiki-style "HOWTO"-based that helps you solve a particular problem (Arch and Gentoo wikis showcase this style well)
* Reference documentation that reminds you how you solved a problem (man pages are great examples here)
* Comprehensive documentation that truly documents the system, but can be a bit more obscure if you're not reading it "cover to cover" - textbook style (This is the older "original" software documentation type, which the BSD docs are an example of)
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.
I still prefer FreeBSD.
How do FreeBSD users get around the inconveniences associated with the "the rest of the world" running on Linux?
How do you get hired if you do happen to have proper FreeBSD skills? It's notably absent from all the job listings.
https://freebsdfoundation.org/end-user-stories/netflix-case-...
But it's still a pretty small market share.
Not quite twenty years ago Yahoo! was using (also, I suspect) FreeBSD.
> How do you get hired if you do happen to have proper FreeBSD skills?
By advertising your other skills?
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.
Maybe this,
https://forums.freebsd.org/threads/the-case-for-rust-in-the-...
?
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...
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.
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.
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.
Not clear!
God, it reminds me of Slashdot trolls in the 1990s..
SystemD has to be in the dozens at this point.
sysctl kern.randompid=1
This is indeed a problem now that google search is next to useless. And AI further degrading the quality.
I work around it to some extent by keeping my local knowledge base up to date, as much as that is possible; and using a ton of scripts that help me do things. That works. I am also efficient. But some projects are simply underdocumented. A random example is, in the ruby ecosystem, rack. Have a look here:
Now find the documentation ... try it.
You may find it:
Linked from the github page.
Well, have a look at it.
Remain patient.
Now as you have looked at it ... tell me if someone is troll-roflcopter-joking you.
https://rack.github.io/rack/main/index.html
Yes, you can jump to the individual documentation of the classes, but does that really explain anything? It next to tells you nothing at all about anything about rack.
If you are new to ruby, would you waste any time with such a project? Yes, rack is useful; yes, many people don't use it directly but may use sinatra, rails and so forth, I get it. But this is not the point. The point is whether the documentation is good or bad. And that is not the only example. See ruby-webassembly. Ruby-opal. Numerous more projects (I won't even mention the abandoned gems, but this is of course a problem every language faces, some code will become outdated as maintainers disappear.)
So this is really nothing unique to Linux. I bet on BSD you will also find ... a lack of documentation. Probably even more as so few blog about BSD. OpenBSD claims it has great documentation. Well, if I look at what they have, and look at Arch or Gentoo wiki, then sorry but the BSDs don't understand the problem domain.
It really is a general problem. Documentation is simply too crap in general, with a few exceptions.
> if the team behind this OS puts this much care into its documentation, imagine how solid the system itself must be.
Meh. FreeBSD documentation can barely called the stand-out role model here either. Not sure what the BSD folks think about that.
> I realized almost immediately that GNU/Linux and FreeBSD were so similar they were completely different.
Not really.
There are some differences but I found they are very similar in their respective niche.
Unfortunately my finding convinced me that Linux is the better choice for my use cases. This ranges from e. g. LFS/BLFS to 500 out of top 500 supercomputers running Linux. Sure, I am not in that use case of having a supercomputer, but the point is about quality. Linux is like chaotic quality. Messy. But it works. New Jersey model versus [insert any high quality here]. https://www.jwz.org/doc/worse-is-better.html
> Not only that: Linux would overheat and produce unpredictable results - errors, sudden shutdowns, fans screaming even after compilation finished.
Well, hardware plays a big factor, I get it. I have issues with some nvidia cards, but other cards worked fine on the same computer. But this apocalypse scenario he writes about ... that's rubbish nonsense. Linux works. For the most part - depending on the hardware. But mostly it really works.
> I could read my email in mutt while compiling, something that was practically impossible on Linux
Ok sorry, I stopped reading there. My current computer was fairly cheap; I deliberately put in 64GB RAM (before the insane AI-driven cost increases) and that computer works super-fast. I compile almost everything from source. I have no real issue with anything being too slow; admittedly a few things take quite a bit of compile-power, e. g. LLVM, or qt - compiling that from source takes a while, yes, even on a fast computer. But nah, the attempt to claim how FreeBSD is so much faster than Linux is, that's simply not factual. It is rubbish nonsense. Note that OpenBSD and NetBSD folks never write such strangeness. What's wrong with the FreeBSD guys?
> Ok sorry, I stopped reading there.
Why? That's a treasured feature. https://xkcd.com/303/