There was a period in the early 2000s where installing Linux on your main machine felt less like software installation and more like a controlled act of vandalism.

Not because Linux itself was inherently unstable — although sometimes it absolutely was — but because every step carried the possibility that you were about to destroy the only working operating system you had.

This was before cheap virtual machines, before WSL, before disposable cloud servers, and before most people had spare hardware lying around specifically for experimentation. If you wanted to learn Linux properly, there was a good chance you were going to repartition your main hard drive and hope for the best.

Which, in hindsight, was an astonishingly optimistic approach to systems administration.

Fedora Core 2 vs Windows XP

At the time I was experimenting heavily with Fedora Core 2. I had already broken enough installations to understand one important fact:

if Windows was involved, install Windows first.

Linux boot loaders like GRUB and LILO were surprisingly capable. Windows installers, meanwhile, tended to arrive like a territorial animal marking ownership of the hard drive. I described this in one of my original posts as:

“Microsoft being Microsoft”

Which was probably unfair. Well, slightly unfair.

The process itself now sounds absurdly manual.

I had a 30GB laptop hard drive. Roughly half went to Windows XP, the rest to Linux. Partitioning tools existed, but I did not own any of the good ones, so I handled most of it through installation media and crossed fingers.

Actual crossed fingers, according to my notes. At one point I wrote:

“I start by trying to get FC2 CD1 into the laptops CD drive, but I keep dropping it…”

followed shortly by:

“it’s because I was trying to do it with my fingers crossed.”

Which honestly captures the entire experience fairly accurately.

Before experimentation became safe

Modern development environments are wonderfully forgiving. If you break something:

  • rebuild the container
  • recreate the VM
  • redeploy the environment
  • pull a fresh image
  • reset the workspace

Back then, if you broke something badly enough, you were reinstalling an operating system from physical CDs while silently questioning your life choices. The fear was not theoretical either.

I remember sitting through Fedora installations genuinely unsure whether the machine would reboot successfully afterwards. GRUB configuration screens felt important in the way that only things you barely understand can feel important.

The dual-boot setup process itself was strangely tense:

  • partition the drive
  • preserve the NTFS partition
  • install Fedora into remaining space
  • configure GRUB correctly
  • do not accidentally wipe Windows
  • reboot and hope both operating systems still exist

This was considered normal enthusiast behaviour.

Linux support culture in the mid-2000s

Something else stands out reading these old posts back: how much community knowledge mattered. There was no Stack Overflow yet.

Most troubleshooting involved:

  • obscure forum posts
  • distribution-specific community sites
  • HOWTO documents
  • random blog pages
  • tutorials written by someone with significantly more Linux experience than you

The quality varied dramatically. A lot of documentation had a tone that suggested rebuilding a kernel was a perfectly reasonable thing for a beginner to do on a Tuesday evening.

At the time I was trying to document everything I learned through a small website called LinuxJourney.com.

Originally it was just static HTML files uploaded to ISP web space because I was tired of solving the same problems repeatedly every time I returned to Linux after a break. That gradually evolved into:

  • articles
  • forums
  • comments
  • troubleshooting posts
  • installation walkthroughs
  • increasingly over-explained guides written by someone learning in real time

I did not think of it as “learning in public” because I do not think that phrase existed yet. I just did not want to forget things again.

The hardware lottery

One thing modern Linux users may never fully experience is the hardware lottery. You did not assume hardware would work. You hoped hardware would work.

Wireless networking was especially entertaining. My laptop used a BENQ AWL100 PCMCIA wireless card, which required:

  • driver hunting
  • kernel modules
  • configuration files
  • command-line tools
  • several hours of increasingly creative frustration

A successful install was not:

“everything works”

It was:

“enough things work that I can continue.”

That distinction mattered. Even simple tasks occasionally became adventures. Playing MP3s on Fedora was awkward because of patent restrictions. DVD playback was inconsistent. CD writing sometimes broke after kernel updates. Monitor detection could best be described as speculative.

And yet, despite all of this, Linux was fascinating. Not polished. Not smooth. Not particularly beginner-friendly. But fascinating.

The accidental homelab years

Looking back now, I can see I was accidentally teaching myself infrastructure and systems administration long before I understood those terms properly. I was:

  • editing configuration files
  • managing boot loaders
  • troubleshooting networking
  • configuring package repositories
  • manually compiling software
  • running forums
  • managing hosting limits
  • backing up databases
  • reinstalling operating systems repeatedly for “testing”

Which is a very generous word for what was mostly curiosity combined with poor impulse control. The hosting itself feels historically interesting now. LinuxJourney eventually moved onto rented Linux hosting from a regional hosting company. Not a VPS — those were still relatively uncommon and expensive for hobby projects — but a shared Linux platform with:

  • PHP
  • MySQL
  • FTP access
  • limited database space
  • enough control to learn things
  • enough restrictions to become annoyed regularly

In hindsight it was essentially proto-PaaS hosting before anyone would have called it that. At the time it felt incredibly advanced.

Reading the old posts now

The writing is chaotic. Everything is over-explained. Every thought becomes three paragraphs. Half the tutorials are written like someone narrating events in real time while mildly panicking. But I can also recognise something consistent underneath all of it:

  • curiosity
  • persistence
  • documenting problems
  • learning by experimentation
  • trying to understand systems instead of just using them

And honestly, that part still feels familiar. The technology has changed enormously since then.

The habit of turning small technical problems into unnecessarily large side projects appears to have survived completely intact.

Tags