This article will walk you through what it means to be technical, and why it is so worth it on the Unix and Linux platform.
So what does it really mean to be technical? It’s the ability to diagnose and troubleshoot components, whether it’s a car, a computer, or a city’s electrical grid. Components can be isolated, and their interaction with other components observed. When there appear to be inconsistencies, you may have a flaky component needing to be swapped out—or if you have the right tools and knowledge, broken down into yet smaller components for diagnosis.
And that’s pretty much it.
You can keep drilling down this way, but eventually you reach a limit of your tools and know-how. So even techs, no matter how much they think they know, are still limited, and from my observations, most are glorified Lego tinkerers and copy & pasters. If you make brand-new Lego pieces, then you are an inventor, and one better than a mere tech. If you observe things that nobody else has before, and can record your findings in a way that others can reproduce your results, then you are a scientist.
But most techs are just techs.
A tech assumes things can be broken down and understood, and by extension, controlled, fixed and hacked. It hardly matters the subject-matter. If there’s objective evidence involved, the smoking gun as it were, it’s the realm of the tech. If not, it’s probably liberal arts or a soft-science like psychology. So it turns out that a tech is a lot like a scientist applying the scientific method on mundane, well understood everyday things, and everyone can do it!
There’s nothing special about the technical mind that can’t be acquired through practice. I frankly feel the same way about creativity, but that’s another story. Who wouldn’t want a little more control over their world? And when you someday are facing a crisis if career or identity, great many more choices of paths in life will be open to you—and here’s the best bit: you will be perceived as more valuable, because you will be able to do things others can’t.
Everyone can and should be at least a little technical—but if you are ONLY A LITTLE technical, keep it to yourself. You never want to be the low man becoming obliged to fix everyone’s printer problems just because you can. Being just a little technical puts you at the mercy of non-techs who still exercise power over you. This site isn’t for people who want to become just a little bit technical. It’s for people who want to get over that hump and ascend to becoming like a force of nature.
This website deals with becoming technical in the realm of computers, and Unix / Linux in particular, which are a haven for techs, due to its somewhat complicated nature (versus point-and-click operating systems), and due to its open source heritage.
Why does open source help a tech?
Remember that discussion on components? Well, a component can either be a “black box” like Windows in which case you can’t look inside it’s inner workings without great effort or legal implications—or you can. With open source, if something goes wrong, you can either diagnose in the modern auto mechanic fashion and swap out whole components—or you can deeply understand the inner workings of the computer, getting into the mind of the inventor, and perchance find a way to do it better!
So unlike on Windows, being a Tech on Unix / Linux leads eventually to nearly total control over the system.
I obviously feel this later approach is better, but it’s something you work your way towards over time. You have to start out diagnosing and swapping black box components as the hack magician sorcerers apprentice. Things are just too complicated starting out to “zoom in” too far. Just follow the boot process from the boot-loader to the kernel to the system-privileged software to things running in userspace. It’s all laid out in text files. Over time, you drill in deeper.
At first, you simply cast your spells without knowing precisely how they work, but you can take take confidence in their reliability, and your ability to restore the system to a predictable state if things get out of control.
And even as you get down the inner workings and purge the mystery, the truth is you’ll never go “all the way down” and truly understand why things work. Even when you cross over into scientist, you’re still just hacking much smaller components, not knowing precisely why things work—it just gets labelled with words like quantum mechanics to make ourselves believe we know what’s going on.
Happily, computers, as a direct human creation, are much more understandable than nature. The big problem is that they assembled in so many different ways that no one could be proficient on all these hardware variations if there was not some extreme commonality. In fact, they are built in so many different ways, that it would take a lifetime simply to be proficient on more than a few. No matter how technical you are, you are nearly powerless if you must spend all day deciphering things just to perform everyday tasks. And becoming technical on computers would hardly be worth it if you were pigeonholed onto a particular piece of hardware.
Enter the good old US Government.
Back around 1979, the Defense Advanced Research Projects Agency (DARPA) was having the same problems of hodgepodge hardware. They saw that, you couldn’t solve it by standardizing hardware, or else you are handing someone hardware company a monopoly, need expensive upgrades for everyone, and might not even end up with the right hardware for the job. But, you could try to reduce the hodgepodge at the software level, giving everything generally the same set of underlying commands and resources, a.k.a., the operating system, a.k.a., Unix. Applications written for different hardware could even now be somewhat easily “ported” to different hardware.
Well, suddenly there was a standardized plumbing for computers, and the general diagnostic principles that anyone could apply became useful on a wide assortment of hardware—anything that ran some flavor of Unix. And correspondingly, a new brand of techs sprang into existence who in actual fact are not necessarily more skilled than an auto mechanic, but they became virtual gods in this new realm—the holders of the keys to the kingdom—the system administrator, sysadmin, or simply admin.
Finally, there was a place where techs not clever enough to be inventors or scientists had a realm where they could lord over the popular kids… and boy did they use it!
The reason this era of draconian god-complex sysadmins lasted so long was that Unix systems were usually large and expensive, and very few people had the time, resources or inclination to train themselves on these types of computers. You needed the equipment to work on, plus someone trusting you enough to give you privileged access. This was a big deal because Unix computers were multi-user, and computing time was valuable, so if you screwed up, you could screw it up for a lot of people.
Meanwhile, graphical user interfaces sprung onto the scene, thanks to the Macintosh, and soon after, Windows. This was all based on proprietary software running underneath the windows and isolated from the user. The computers were also “personal”, really meaning single-user, and subsequently not really needing many of the benefits Unix brought.
Resultantly, few people saw the value in developing Unix skills, and most of the common public who decided to become computer savvy were not learning the standardized plumbing of computers, but rather how to navigate extremely vendor-specific systems having a very short shelf-life—that is, when you think of careers in terms of decades. Windows systems come and go, and the very fundamental underpinnings need to be re-learned, full of ziggurat layers of complexity under the guise of “easier” and “more powerful”, but which are really about vendor lock-in.
But the common Unix commands have remained fundamentally unchanged. Learn how to build a Unix or Linux system from scratch, and you know a great deal about a great deal more technology than just personal computers.
And Unix / Linux are incredibly accessible these days, if you are interested.
A few key things changed since the days of draconian system administrators. First, during the early ’90s, two versions of Unix were brought to the masses as a result of porting it to personal-computer hardware. Those were Linux and BSD, and this let geeks without privileged access in universities and companies get to know the *nix platforms, along with all the computer science majors around the planet who could now work on the business and government sanctioned standard. However, what they were working with was remarkably unsexy looked at next to Mac & Windows, so the revolution didn’t really occur.
The next things to change were product manufacturers who needed to put “brains” into their consumer electronic devices who were getting tired of developing their own proprietary operating systems, looked towards tiny versions of Linux, such as QNX. Devices that needed smarts and to be cheap, such as WiFi routers, actually ran tiny versions of Linux. Soon, the tiny processors got big enough to run somewhat mainstream versions of *nix to the point today where every Android phone has a Linux derivative and every iPhone has a BSD derivative. And on a related note, you probably can’t overstate the importance of Apple choosing Unix to underlay their OS X operating system, greatly in part from acquiring
And finally, virtualized computers and “Live CDs” made experimenting with new operating systems much easier—to the point where you can just download and double-click to get Linux running in a window on a Mac or PC. And if you want a real deployed server, it’s like a 5 minute process to get a $11/mo server at Rackspace.
And so now, Unix and Linux are in the hands of the average Joe, and if you wish to become technically proficient, you can. Nothing is stopping you except for how easily momentum somehow manages to get lost in the attempt. There are a thousand little obstacles to overcome in learning *nix systems, from picking a distribution to getting it running, to getting past the login screen, to knowing what to do next. Worst of all, you might get distracted with graphical user interfaces like Gnome or KDE.
But the path is clear to actually becoming a Unix / Linux tech.