Before the beginning
I first heard of Linux in 1996. I'd been long tired of Windows by then — years of increasingly elaborate window managers bolted on top of DOS, eventually forcing Windows 95 onto a 486 SX33 that had no business running it. I'd become interested in Unix, but living in a regional town made it genuinely difficult to come across. A friend with an internet connection mentioned he'd heard about this Linux thing. I was interested.
Fast forward to 1998. In an otherwise unremarkable University lecture on using Unix, the lecturer mentioned having Linux installers in his office — first come, first served. I walked back with him.
In the pre-Google era, my relatively new PC didn't stand a chance. Dual booting was a challenge, but my only real memory of the early days is killing Windows and needing to make a new boot disk — I was living away from home and hadn't quite brought all the essentials with me. There were a few trips back to the University computer labs to sort out such details.
I also distinctly remember ringing around ISPs trying to find someone who could tell me how to configure a dial-up connection on Linux. I failed at that. What I did get out of it was a job doing on-site installs for one of the ISPs I'd called, plus a free internet connection. At the time, that was a genuinely big deal.
In 1998, getting Linux running was a genuine technical undertaking. There was no Stack Overflow, no YouTube tutorials, no friendly package manager. If something didn't work, you were hunting through mailing list archives, photocopied manual pages, or asking someone in person. The fact that people persisted with it anyway tells you something about how unsatisfying the alternatives were.
A 386 in a cupboard
I returned home mid-1998 and installed Slackware on a 386 connected to a CGA monitor, housed in one of my old converted XT cases. I turned it on, sat it in a cupboard, and proceeded to largely forget about it for a few months while other things took priority.
A few months later I noticed it was running perfectly. Still up. Still working. Windows certainly wasn't capable of that kind of uptime — particularly not on hardware that old. That observation stuck with me more than any feature list ever could. It was just quietly doing its job in a dark cupboard, unattended, on antique hardware, without complaint.
I started getting more interested again. I moved to Red Hat Linux and set up my first file server — and from memory I'd even started sharing my dial-up connection across a home network. Something that sounds unremarkable now was quite an achievement at a time when a lot of people still didn't have a computer at home, let alone a network.
FreeBSD arrives — and changes everything
Working as an IT consultant through 1999, we were quietly using Linux to run servers for clients while showing the friendlier distributions to the public. By early 2000 I'd gone out on my own as a self-employed consultant, and I had a server that I'd recently tried to install the latest Red Hat Linux on. It was too bloated, and it wouldn't detect my modem.
I ordered a burned copy of FreeBSD 4.0 online — yes, this was an actual service at the time, because downloading something that large over dial-up wasn't remotely feasible — and when it arrived a couple of days later, I installed it.
I was immediately in love with it.
Fast installer. Clean finish. Upon completion it saw my modem and the rest of my hardware without any persuasion. The thing I noticed most was what wasn't there: if I hadn't told it to install something, it simply hadn't installed it. I had a genuinely bare-bones operating system. On a 486 with 8MB of RAM, a trim OS wasn't a luxury — it was a necessity.
FreeBSD is a complete, free Unix-like operating system descended from BSD (Berkeley Software Distribution) Unix. Unlike Linux — which is technically just the kernel, with different distributions bundling it with different tools and software — FreeBSD is developed as a complete, cohesive system by a single project. The kernel, base utilities, and documentation are all developed together. This has practical consequences: the system is highly consistent, documentation is excellent, and the base install is genuinely minimal.
FreeBSD also ships with the Ports Collection — a framework of build scripts for thousands of third-party applications, letting you compile exactly what you want with exactly the options you want, rather than accepting whatever a distribution packager decided.
The kernel was easy to recompile, which made it easy to trim down significantly — meaningful when you're trying to coax performance out of a machine that was nearly a decade old when you were installing the OS. Very soon my old 486 SX33 — which at least had a whopping 10MB of RAM and an upgraded 500MB hard disk — became a dial-up gateway, mail server, and web server. With a static IP. On a 486. It worked surprisingly well.
Growing the infrastructure
When DSL became available I was on an SDSL business plan — 512/512Kbps. The recommended DSL-to-Ethernet bridge was a $300 DLink device with a power supply that ran so hot I bonded a CPU heatsink and fan to the metal plate on the casing to keep it alive. The 486 eventually gave way to a Pentium 100 that came bundled with some used monitors I'd ordered from a tech refurbishment company. FreeBSD ran happily on that hardware without any adjustments. Everything just ran.
That machine was in turn replaced with a Compaq ProLiant 5000R — an 8U monstrosity of a server that sounded like a jet taking off, dimmed the lights when it spun up, and was no doubt audible to my neighbours at all hours. Dual Pentium Pro 200 with a stack of SCSI drives and, eventually, a tape drive.
At the time, FreeBSD's kernel didn't include SMP (symmetric multiprocessing) support by default — using multiple CPUs required recompiling the kernel with SMP enabled. This sounds cumbersome, but it was a deliberate philosophical choice: you only compile in what you actually need. On a single-CPU machine, the SMP code just adds overhead. On a dual-CPU machine, you compile it in and it works. The Ports Collection and kernel customisation were both expressions of the same underlying principle: you're in control of exactly what runs on your system.
I'd started hosting customer websites by this point — a number of local motels and a handful of other clients. That ProLiant running FreeBSD became the hosting platform. It was loud enough to be a genuine nuisance in a home environment, but it was rock solid.
The philosophy gap
By this period I found Linux servers increasingly tedious to manage. Each new distribution release seemed to bring more bloat — more stuff installed by default that I hadn't asked for and didn't want, more tuning required to get back to a clean baseline. The "start with everything, remove what you don't want" approach was the opposite of how I liked to work.
FreeBSD's approach — start with nothing, add exactly what you need — suited server work well. The Ports Collection was excellent, and I rarely experienced the dependency conflicts that made managing third-party software on Linux frustrating in that era. Install something, it works, move on.
"Dependency hell" was a genuine problem on Linux through much of the early-to-mid 2000s. Installing a package often required specific versions of other packages, which conflicted with versions already installed for other software, which then required downgrades that broke something else. Modern package managers (apt, dnf, pacman) have largely solved this problem, but at the time it was a common frustration — particularly on distributions that prioritised a large software library over carefully managed version compatibility. FreeBSD's Ports Collection largely avoided this by building everything from source with consistent version constraints.
My desktops were a different story. FreeBSD was an excellent server OS and a frustrating desktop OS. The BSDs have always had narrower hardware support than Linux simply due to the smaller development community, and desktop-oriented software tended to lag behind. I kept Windows around out of necessity — I had to support it for clients, and the accounting software requirements of running a business weren't going away. But I went through a succession of Linux distributions on secondary machines over the years: Mandrake, Mandriva, and various others, trying to find something that worked for general use. If you needed a web browser, email client, and an office suite, Linux desktops were serviceable. Beyond that you were often compromising on something.
Virtualisation and the slow drift
By late 2010 I'd started virtualising. I'd moved interstate and was dealing with varying quality DSL connections across a succession of rentals, which made running on-premises infrastructure impractical. Services bounced back and forth between local hardware and what we'd now call the cloud depending on what connectivity was available and what hardware I had at hand.
I did attempt to manually compile X on FreeBSD on a desktop PC around 2010-2011. That took a few days. The result lasted minutes before I concluded that I didn't like it. The process was interesting enough to be worth doing once. It wasn't worth doing again.
This continued until around 2018 when I finally had decent connectivity, no prospect of moving again, and modern server hardware. By this point I was comfortable with hypervisors, and FreeBSD featured throughout my own infrastructure. But over time, single-service VMs were gradually replaced by Docker containers, and in my other role as a systems administrator at a University, I was working almost exclusively with Linux.
As I started thinking in Linux more naturally, FreeBSD started to feel slightly foreign. I'd been told this by Linux-focused colleagues over the years — that FreeBSD felt obscure to them. I'd never understood what they meant. After nearly two decades, I was starting to.
FreeBSD didn't decline because it got worse — it remained an excellent, stable operating system. What changed was the ecosystem around it. Linux received massive investment from enterprise vendors (Red Hat, SUSE, Canonical), which meant better hardware support, more documentation, more third-party software compatibility, and more professionals whose daily work involved Linux. FreeBSD is still widely used in specific contexts where its strengths matter most — network appliances (pfSense is built on it), storage systems (TrueNAS), and performance-critical infrastructure (Netflix's CDN runs on FreeBSD). But for general server work, the argument for choosing it over Linux narrowed as Linux distributions became leaner and better managed.
The last VM
Eventually I was down to just my mail server — running Matt Simerson's Mail Toaster 6 build. I'd been running Matt's builds for years. When they worked, they were rock solid. My experience in getting to that point was more variable — a fresh build might work perfectly, or something would break partway through and the whole thing would misbehave. Do it again and it might be fine. Or it might not. Updates were similar: usually fine, occasionally not.
Overall it was good, but it had started to feel like a lot of work compared to the options now available. I tested iRedMail on Ubuntu. Light, everything managed from repositories, no real ongoing maintenance overhead. That last quality has become increasingly important to me — a mail server that just keeps running without requiring quarterly effort to keep it healthy is worth a lot.
And just like that, my last full FreeBSD VM was gone. After a quarter of a century, it was no longer the operating system I needed.
There are still a few appliances floating around that use its kernel, but nothing I interact with directly as a running FreeBSD server. I still think of it fondly.
The honest comparison
Having run both for as long as I have, I find the "FreeBSD vs Linux" framing slightly misleading. They were solving different problems, and the relative merits changed substantially over the time I was using them.
| FreeBSD | Linux | |
|---|---|---|
| Server use | Excellent, particularly on constrained hardware. Minimal base, precise control. | Excellent now. More variable in earlier years depending on distribution choices. |
| Desktop use | Never really comfortable. Hardware support gaps, fewer desktop-oriented contributors. | Variable historically, considerably better now. Still not a complete substitute for everyone. |
| Package management | Ports Collection was outstanding — build from source, full control. pkg for binary packages. Dependency issues rare. | Highly distribution-dependent. Modern distributions (apt, dnf) are largely excellent. Earlier era was painful. |
| Documentation | The FreeBSD Handbook is one of the best pieces of technical documentation in open source. Authoritative, thorough, maintained. | Scattered across distribution wikis, man pages, community sites. Quality varies widely. |
| Ecosystem / community | Smaller. Narrower hardware support. Fewer third-party software ports over time. | Large and growing. Enterprise backing. Most software targets Linux first. |
| Stability | Extremely stable. The 486 SX33 running as a mail and web server on a static IP — that was genuinely impressive for the hardware. | Also extremely stable at the server level. The 386 running Slackware unattended in a cupboard for months was an early demonstration of that. |
| Learning value | High. The complete-OS model forces genuine understanding of what each component does. | Also high, though the abstraction layers vary by distribution. |
If I were advising someone setting up a server today, I'd point them at Linux — not because FreeBSD is worse, but because the practical ecosystem advantages of Linux are now significant. More documentation, more compatible software, more colleagues who can help when something breaks at 2am.
If someone told me they were using FreeBSD for a network appliance, a NAS, or a high-performance infrastructure component — I'd tell them they'd made a considered and defensible choice, and that they probably know exactly why they made it.
The 386 in the cupboard running Slackware was interesting. The 486 SX33 serving mail and websites to the internet on a static IP — that was genuinely impressive, and still makes me smile thinking about it. The ProLiant running FreeBSD was the right tool for a growing hosting business. The iRedMail instance that replaced the last FreeBSD mail server just runs, quietly, without bothering me. At this point in a career, that's not a downgrade — it's the point.