$ cat post/y2k-echoes-and-red-hat's-promise.md

Y2K Echoes and Red Hat's Promise


November 11, 2002. I woke up to the echo of last year’s Y2K drama, but the day felt more like a cold reminder than an actual event. I was working at a startup, and we had just finished our migration to Linux on the desktop. It was a big shift for us; everyone was still trying to figure out how to make it work in a corporate environment.

The dot-com bust was still a fresh wound, and even though we were a small player, I could feel the tension in the air. Every morning, I would check the status of our Apache servers running on Red Hat Enterprise Linux (RHEL). Apache had become almost as reliable as BIND, which was a relief after dealing with the flakiness of Windows NT at our last job.

In those days, VMWare was still in its early stages, and we were using it to sandbox testing environments. I remember spending countless hours trying to get a dual-boot setup working on my work laptop so I could test software on both Windows and Linux simultaneously. The struggle with the boot order in BIOS was like trying to fit a square peg into a round hole.

Our office was still adorned with Y2K posters, reminding us that we hadn’t completely let our guard down yet. I had just finished fixing an issue where one of our custom-built Java applications was crashing on the first of every month due to a bad date parsing in their configuration file. It felt like a small victory against the lingering threat of calendar rollover issues.

We were also grappling with IPv6 discussions, but they seemed more like academic exercises compared to the immediate problems of IPv4 exhaustion and NAT limitations. The transition was slow, and we weren’t sure if our network equipment supported it yet. But one thing was clear: sooner or later, we would need to think about upgrading.

On this particular day, I was working on a critical deployment that involved migrating our mail server from Sendmail to Postfix. We had been running Sendmail for years, but it seemed like the more things changed, the more they stayed the same. Every time there was an upgrade, we would have to go through a painful process of configuring and testing.

I spent hours debugging a mysterious issue where emails sent between our internal applications were getting stuck in a queue. I retraced my steps, checked configuration files, even recompiled Postfix from source just to rule out any possible bugs. Eventually, it turned out to be a simple misconfiguration—a missing ‘qmgr’ parameter in the main.cf file. Sigh.

Later that day, as I was preparing for our stand-up meeting, I realized that I had been too focused on the technical details and hadn’t spent enough time thinking about the broader implications of what we were doing. We needed to focus more on user experience and communication within the team. So, I added a quick note in my notebook: “Communicate more, code less.”

As the day drew to a close, I sat down with our CTO for a brief chat. We discussed our strategy for the next year, balancing the risk of staying too conservative versus moving too fast into new technologies. He mentioned Napster and other early peer-to-peer file sharing services that were making waves in the industry. It was hard not to feel a bit nostalgic about those days when we were all excited by the promise of new technology.

Leaving work, I walked past the Y2K poster again, feeling a mix of relief and uncertainty. Linux on the desktop was here to stay, but the future was still uncertain. As I made my way home, I thought about how much had changed in just a year and how much more would change before we could truly call this era over.


This reflection is based on common experiences from that time period and touches on the technologies and tools that were relevant during the Y2K aftermath and early 2000s.