This post is brought to you by Command Line Heroes, an original podcast from Red Hat.
When I was younger
I guess you could call me an “accidental technologist.” Growing up, I never intended to work with computers. When I was younger, I actually only tinkered with PCs at home or at friends’ houses because you had to learn how to edit the config files on DOS to free up enough memory so that games could have 512k memory to run. You had to understand what a device driver was, how to install it, and how to add it to the CONFIG.SYS or AUTOEXEC.BAT files to have a working mouse on the console. I also learned about interrupts, IO addresses, and DMA channels from configuring things like ISA SoundBlaster cards with jumpers and DIP switches. Without meaning to, or even realizing it, I had a pretty decent understanding of personal computers. I was not a programmer, not by a long stretch, but I could get computers working pretty quickly. And I loved automating things in batch files. The power of scripting was clear.
When I was younger, I never wanted to be anything except a police officer. So when I was 16, I became a uniformed volunteer through the Police Explorer program at my local department. When I was 18, I became a jail officer. When I was 21, I graduated #1 from the Travis County Sheriff’s Academy and became a patrolman in a small town in central Texas. When I was 24, after 8 years of non-sworn and sworn law enforcement work, I realized that working nights for so little pay qualified me for welfare—and that continuing to do so was not the smartest idea. I decided to go to college and change careers. Since I had enjoyed tinkering with computers, I figured I’d learn more about them. I settled on getting a degree in computer science.
“You’re going to run the computers from now on”
But I had to have a source of income while I went to school, so I got a job as a technical writer with a small manufacturing company. Because I’d spent so many years writing reports, which enumerated the chronology of events and the elements of an offense, I discovered that I was pretty good at documenting and even improving the processes used to manufacture telecommunications gear. And I got the reputation as the guy to go to when the computers were acting up. We had a sysadmin, but he covered multiple locations, and I only knew him very peripherally until the day he turned in his notice. His three-day notice. His angry, three-day notice. The plant owner looked at me and said, “Thomas, you’re a computer guy. Shadow this guy for three days, learn everything he does, and you’re going to run the computers from now on.” Turns out, the sysadmin was a Certified Novell Engineer with years and years of experience. And very little motivation to actually teach me anything. Did I mention that he was leaving? And angry?
So, after three days of on-the-job training, I was a sysadmin. I knew how to add users to the server, change passwords, clear print queues, and change tapes for the backups. I don’t think I could actually restore anything at that point, though. I read everything I could, and I signed up for training at my local Novell training center. My employer wouldn’t pay for anything but the basic first class, so my beloved grandmother gave me the money to take all the classes to become a Novell Certified Engineer. It took a couple of years, but I did it. The Novell certification was incredibly difficult, since I came from a totally non-technical academic background. Being a police officer didn’t do much to prepare me for a career in IT. But, I was incredibly proud of the certification and that started a lifelong quest to continually learn.
Hiring and training 450 support technicians and getting certified
From the manufacturing plant, I landed a job with Unisys, working for Microsoft during the run up to the launch of Windows 95. It was an incredibly exciting time—Windows 95 was a real game changer in its day. I was hired as one of five technical development engineers. Each of us had different specialties, and we were responsible for hiring and training a staff of 450 support technicians who would do phone support during the beta and launch of Windows 95. I was responsible for teaching all 450 of them how to integrate Windows 95 into networked environments.
At the time, Novell owned the PC server market, but Microsoft was putting serious effort into breaking into the server market with Windows NT, so I went to Microsoft training and finished the 7 classes and exams necessary to become a Microsoft Certified Systems Engineer. This was in the early days of the “OS wars,” and Novell and Microsoft were two behemoths battling. It was a pretty incredible time—very exciting. I worked hard to learn as much as I could about Windows networking, and I got pretty good at it.
I was absolutely convinced that UNIX or any variant was a dead end
There was a kid who worked with me at Unisys in 1995 named Tim Goldenburg, and he kept talking about this thing called “Linux®.” As I understood it, Linux was a free version of UNIX that ran on personal computers. I’d learned NetWare, and I’d learned Windows, and I was absolutely convinced that UNIX or any variant was a dead end. The future was here, and it was obviously Windows NT, baby. But Tim kept going on and on about Linux, so I decided to show him what was what. I told him I was going to set up a Windows NT server on one machine, and Linux on an identical one, and prove that Windows was the future. I installed a whopping 64 megs of memory on each of the machines and installed a massive 340-megabyte hard drive in each.
I went to my local computer bookstore (yeah, those were a thing, once), and I bought one of the “Linux Unleashed” books. It came with a version of Slackware (3.0, I think) on a CD in the back cover, if I recall correctly. So I stood up my NT 4.0 server—I’m pretty sure it was still in beta at the time—and then I tried to install Linux. It was the first time I’d learned an operating system purely through self study, and I don’t mind telling you, it was hard. There was no graphical tool to install, it was a text-based step-by-step process. Partitioning was different from what I was used to, and I had to learn about all the different partition types I could use, and figure out which one I should use. (What the heck is a swap partition? Everyone knew swap was done on files.) Then I had to figure out what the various “package groups” were, and whether I should install them or not. As an example, I didn’t understand what X Window was, so I had to go learn about it to decide if I should install it, and how many of the x-series package groups I needed. Ditto for the development packages, and packages for network services, etc. It was baffling for a Windows guy.
I had butterflies when I completed the Linux installation and rebooted
After a couple of days (yes, days) of false starts and mistakes and starting over, I finally finished the installation. I remember having butterflies when I completed the installation and rebooted. When the system rebooted, I was absolutely thrilled when it came up successfully. But I don’t think I’ve ever felt more like the dog that caught the car when it came up. I got a system banner and a login prompt. I had no idea what to do. I went back to the book, and started reading up on how to log in and what to do to finish configuring the system.
The next several weeks are still sort of a blur. I configured networking, installed the Apache web server, learned to compile it from scratch with SSL support, installed Samba so my Windows machines could use the Linux machine as a file server, and so on. I know now that it was a small thing, but I clearly remember learning that I could configure my Linux machine as a network router by just echoing 1 to /proc/sys/net/ipv4/ip_forward. This completely blew me away—that you could change a kernel setting like routing without having to reboot. On my Windows server, once I dug down into the networking GUI and checked the box to enable routing, I had to reboot! Linux was insanely cool! And you had incredible control.
There were definitely some rough edges… configuring the GUI was stupidly complicated. You had to know refresh rates and resolution settings, and if you got them wrong, you could physically damage your monitor. I found out the hard way that setting too high a refresh rate on a CRT monitor resulted in a weird ascending whine, a small pop, and a slightly smoky smell coming from the now-dead monitor.
I started running my own website and email domains on Linux. I learned to compile the kernel, configure services, secure the system, manage users, and so on. I absolutely fell in love with the elegance and simplicity of the system and how incredibly configurable it was. Eventually, I started consulting on Linux and related technologies. I started two companies focusing on free software. I wrote and delivered training to clients like HP, Compaq, IBM, the U.S. Department of the Treasury, and many others. I worked for companies from startups like my own to massive enterprises like Bank of America, and I’ve have been at Red Hat since 2005. In short, I made a career and supported my family with Linux and free software.
The most important thing I learned was not actually technical
I guess my mission to prove that “Windows is the future” sort of failed, and I will be eternally grateful that it did!
But probably the most important thing I learned from that Linux installation was not actually technical. I learned that there were huge communities of folks out there who were available to help. I learned about Usenet groups like comp.protocols.smb for Samba, and the various comp.os.linux.* groups for core Linux stuff, comp.mail.sendmail for configuring Sendmail, and so on. I found mailing lists. I learned about internet relay chat (IRC) channels. I found that there were people from all around the globe who were watching these groups, lists, and channels, looking for folks who need help—and helping them. For free. Often times, the folks who actually wrote the code were the ones answering!
I also learned about the Free Software Foundation, the Gnu General Public License (GPL), and free software—and about the importance of participation in the various communities whose software I was using. I learned enough to become one of the folks answering questions instead of asking. I learned to contribute to the mailing lists, newsgroups, and so on, instead of just using them.
That participation is what led me to where I am today. I strive to live my life in a service role. I participate in community events, I answer questions, I deliver training sessions, and so on, because I owe a debt of gratitude to those communities. That lesson—that gratitude that I have to the free and open source software communities—carries into everything I do. I love that I contribute in a small way to Red Hat’s contributions to the various communities, as well. I am humbled to think that what I do enabled, in a small way, an engineer here to contribute code that made it possible for a kid to have internet access to learn. I love what I do, and I love that I’m a part of something bigger.
Want to hear more stories about the OS?
Check out @rossturk’s post on the Magic of Linux.