A Journey Back in Time: SCO Unix

In the early 1990s, I found myself at a friend’s house, visiting his father-in-law, who had just started a business. He had invested in a multi-user system—a 386 machine running SCO Unix with four serial terminals.

It quickly became clear that Unix was far more complex than MS-DOS, which was the standard at the time. After a rocky start, it was evident to the budding entrepreneur that he needed more expertise to keep the system running. Unfortunately, consultancy was expensive, and resources were scarce for his startup. Ultimately, he handed me the manuals that came with the system, asking if I could make sense of it and lend a hand.

At that point, I had never worked with Unix, but it intrigued me. So, during my daily commute, I began poring over the SCO books—which turned out to be excellent resources. Much of the foundational Unix knowledge I have today came from those texts. Utilities like grep, awk, and vi were explained in detail, along with multi-user concepts (users, groups, permissions) and system performance aspects, such as CPU-bound versus I/O-bound.

After several months (those books were no light reads), I had grasped the basics. However, by that time, the startup had decided to standardize everything on MS-DOS. So, while I didn’t get to use SCO Unix extensively, I carried with me a wealth of foundational knowledge.

My First Experiences with Linux

In 1995, I purchased a second-hand PC with a 20MB hard drive and a 486SX processor—barely enough memory to run anything substantial. Money was tight, as we had just bought our first house.

That year, I attended the NLUUG event and acquired one of the early Linux distributions—likely Slackware, with a kernel version of 0.99.something. The problem was, it was on a CD, and my second-hand computer didn’t have a CD player.

Back then, Linux could also be installed using floppy disk distribution sets. However, this required about 40 floppydisks, which weren’t cheap (a box of ten would cost the current day equivalent of 30-40 Euros).

At work, I had access to a CD-ROM (which was worth about 1000 Euros at the time) and some floppy disks. So I set out to create the distribution disks from the Slackware CD. This may sound straightforward, but there was a catch. The program that wrote the floppies didn’t have error-checking, and floppies are notoriously unreliable. If there was an error, the installer would simply throw up an error message and halt.

Each evening, I would attempt to install the disk set, noting which floppy caused the failure (there was always one). The next day, I’d head back to the office to recreate that floppy disk, bringing it home to try the installation again, hoping it wouldn’t fail due to another faulty disk. I seem to recall that about 20% of the floppies I used were defective, resulting in a lot of back-and-forth trips to my workplace.

After a few weeks, I finally succeeded in installing all the disk sets, and I had a functioning Linux system.

Compatibility Challenges

Or so I thought. The challenge was that every few days—sometimes every few hours—I would encounter a ‘segfault’ error that would bring the system to a halt. With no prior experience, I was puzzled by this. I attempted to recompile things, which was quite difficult under those circumstances. Nevertheless, I worked tirelessly to get the desktop system operational. I still remember it was December 1995 because I recently found the notebook where I tracked everything I did back then.

A few weeks later, my neighbor visited, and I shared my struggles with him. He had just opened a computer shop and offered to sell me a special, low-cost PC he had tested for compatibility; he believed that was the root of my problems. After some consideration, I decided to take the plunge (the price was quite reasonable, and it even had a CD-ROM!).

Needless to say, the new machine ran flawlessly. Installation was a breeze this time around, and I used that system for several years. It marked my first experiences with email, using UUCP to connect to XS4ALL here in the Netherlands. I gradually upgraded with additional hardware (memory) and storage—eventually, the system boasted four IDE disks, three SCSI disks, a CD-ROM player, and a tape streamer. I learned a tremendous amount during this period: compiling software packages, building kernels, and troubleshooting shared library issues. Those were truly formative times in my tech journey.

My First Experiences with BSD

As my career advanced, I transitioned into an IT management role just as the internet revolution began to take shape. Suddenly, every business needed a website, and internet connectivity became essential. Working in Amsterdam, I reached out to a local provider, XS4ALL, which had recently launched and would go on to become one of the major internet providers in the Netherlands. We set up a 64Kb/s full duplex connection, and just like that, we were online—emailing, web browsing, and more! However, as the concept of a corporate website began to materialize, our 64Kb/s connection proved insufficient. We needed a faster connection and enhanced firewall protection. So we turned to XS4ALL for assistance, who pointed us to another startup that helped us secure a 1Mb/s duplex internet link. They also asked if they could set up our route and firewall using FreeBSD. We gladly agreed. Thus in 2002, our journey with BSD began.

Quirks of the Early Days

I soon realized that the service charges from XS4ALL were relatively high compared to the other costs, especially since the line itself—being close to their headquarters—was far cheaper. After some research, I became confident that my team could handle the services that XS4ALL provided. This epiphany led us to become an internet provider ourselves. For years, we occasionally received inquiries from others wanting us to be their internet provider, as we had an official listing as one in the Netherlands. Throughout those years, since we primarily offered services internally, I never encountered issues with our internet-link.

As an internet provider, we were assigned our own set of public IP addresses. When I started, the Dutch internet regulation office naturally inquired about how many addresses we needed. Eventually, we received a subnet range. However, as our internal services continued to grow, I found myself needing an additional subnet and reached out for more. You wouldn’t believe their response: “Oh, just one? I’ll give you eight subnet ranges, so you can keep going without a hitch for a while.”

To accompany our BSD setup, we also needed a test server. We repurposed one of our oldest machines, a genuine 386, and accessed it via SSH, placing it strategically in the server room. It worked like a charm, though compiling software could be slow. Mostly we did not care that much about the delays, we were busy with other projects. Over time, one of my colleagues checked the uptime on the server (running FreeBSD 3.x) and found it had been operational for an impressive 460 days. This is hard to imagine today, where daily or weekly reboots are the norm to install patches and updates.

A continued journey

We used, at my job, FreeBSD version 4 up to 2005. Somewhere around that time I also switched to FreeBSD at home. I’ve skipped FreeBSD 5 and 6, and used all versions since version 7. Today my daily driver is a Thinkpad T450s. And I have a ready to run T410 as well. Both are very much usable although I will upgrade the T450s (it is close to 14 years old by now). And the followup machine will again be Thinkpad, to ensure that BSD will run.