Choose Linux. Start Using Linux. Get Over Linux Learning Curve.
by Mike Levin SEO & Datamaster, 08/05/2010
NOTE: Since I’ve written this, I’ve come up with a way for you to begin learning Linux on a Mac or PC.
With the MikeLev.in blog, I am gradually writing the book online that I wished had when switching to Linux. There are a bunch of truths I had difficulty realizing and overcoming. This post lays out those truths, and the way I dealt with them to help those who are perhaps thinking of following a similar path.
Foremost is that Linux and Unix are, for my purposes, greatly the same thing. What’s actually worth learning is the fundamental similarities between the two. Call them Unix-like operating systems if you will. They have different heritages, but are both sprung off from circa 1960’s consortium-driven Multics. Unix was made OUT OF frustration, and not to cause frustration, contrary to popular belief.
Forget the Linux graphical user interfaces like Gnome and KDE that provide a Windows/Mac-like point-and-click desktop. Once you put a GUI on Unix/Linux, you might as well not be using it at all–it becomes an “embeded system”, and you’re probably better off just getting a Mac that sits on a great version of Unix anyway. You’ll rarely put Gnome or KDE on a resume, so my interest is actually mastering that embedded system underneath, which has had a good 40-year run in so far, and it’s likely to have 40-years in it still. The things that “sit on top” of Unix/Linux are likely to change, disrupting the hell out of your non-Unix-savvy co-workers, but you will just smile to yourself and forge on uninterrupted. Therefore, it’s all about the type-in interface, called the Unix Shell, and one called BASH in particular.
Philosophically, Unix is just a bunch of commands that are sitting there once the “kernel” gets you booted. The kernel takes care of big issues like making sure your machine can start and users are isolated from each other (security). After that, it’s all about the commands, and each one is ridiculously powerful. You could get lost learning a single command for months, and still there would be more to know. With this collection of commands, and the way they are allowed to “pipe” their information to each other, you could do almost anything you might want to do in a text-based operating system… but it’s not always pretty.
It’s not pretty because the command names are always abbreviated, often to 2-letter combos. The parameter controls are likewise single letters that are often mashed together, for common commands like “ls -la”. You’d never know that this was the way to list the contents of a directory in list format, showing all the contents (invisible or not) without being told. Once you get into the right mindset, you see that “ls” is the shortest possible way of saying “list”, and that the “l” parameter means list format (as opposed to default column format), and “a” means all files (invisible or not). This short-as-possible naming convention pervades all throughout Unix.
Consequently, you have to “just know” certain things right off, which adds to its reputation for being difficult. Unix-like operating systems are not really difficult. They just require a little initiation, in order to get over the hump and get into the right mindset. In a few weeks, you will know where and how to look for information whenever you run up against a wall. And although there is tons of documentation on Unix/Linux (even built into it), it’s not written with someone who knows next to nothing in mind. Unix documentation presumes that you already know Unix, or at least are in the right mindset, and probably even a programmer. Simple examples build on tons of requisite knowledge, and feel like they’re laughing at you for how little you know–just like the draconian sysadmins who usually rule over corporate networks.
Therefore, you can’t approach Unix/Linux as you would like learning Windows, Mac or iPad, in which you can stumble around and gradually learn as you would in the real world. Instead, you have to approach it like Sherlock Holmes picking up the scent and taking off on the trail of his quarry. In fact, it would help you to read a few Sherlock Holmes novels just to put you in the right mindset.
When I took up Linux, I initiated myself, piecing together the clues. I zeroed in on the concept of bootstrapping, and then to the particular tool, debootstrap. So, I essentially bootstrapped myself into the Linux world by bootstrapping Linux. It’s a good formula, and I recommend you do the same. Maybe even follow my steps, and get some history and background as you go. This background and history is great, because it’s “geek currency” and helps you stand toe-to-toe with people who are already in this world, and not particularly happy to have another “newb” so presumptuous as intrude on their turf. They view little pishers like us who actually think we know something as a minor annoyance–who, if they wait long enough, will just go away as we switch our attention to the next wild hair project that gets stuck up our butt.
So, it REALLY helps to know something. Enjoy the reading as great non-fiction. Use Wikipedia. If you’ve got an iPhone, get the Instapaper app, and add lots of articles to Instapaper to read on your down-time. The history of computers is absolutely fascinating, and knowing the REASON for things is sometimes just as important as knowing the thing itself. Steal some time away from sports or video-games, or whatever your time-sink is, and discover how the alternative of advancing yourself professionally is every bit as interesting as time-wasting alternatives. In fact, a lot of the formative players in the industry are still alive and working on interesting things, like Ken Thompson the inventor of Unix, who’s working for Google today on the vastly improved replacement system programming language to C++, called “Go”.
So back to the topic of Unix/Linux itself, again. You have to be prepared to live in this text-based Unix Shell world, and get to it often. You want to base real-life projects on it, and not get stifled or stymied by having to “fire it up” every time. You really want it running like a server for you, 24x7. And that means virtualization is your enemy, and real hardware is your friend. This is a recurring theme you will hear a lot on this site. You want an actual Linux or Unix box running in your house, with services getting through your router, so you can use it from work.
If this sounds like a security risk, well it is. So, learn how to scrutinize security early. Learn about bare-minimum systems that are only running the things you explicitly want to run. Follow in my footsteps, and debootstrap Linux, instead of doing the full install off of a CD-ROM, so that you’re effectively building it up from scratch. Learn the “netstat -tulpn” command, so you can see yourself gradually exposing more risk with each piece of software you install.
Also, starting from a bare-bones debootstrapped Linux system means your comptuer processing requirements go down, which means you can run on much smaller, cheaper and low-power hardware that you feel less bad about leaving turned on at home, 24x7. This means your server footprint is small and efficient, which means you’re setting yourself up for an easy migration to the cloud, where virtualization is actually a good thing, because you have Rackspace, Amazon, or Joyent backing you up.
But didn’t I say virtualization was your enemy? It is–when you’re just getting started and trying to run something like VMWare, VirtualBox or QEMU 24x7 out of your house to get over that Linux/Unix learning curve. Imagine having to restart your virtual machine after every host-Windows system update requiring a restart–not to mention how you deliberately quit out of it for a thousand different reasons. That’s hardly where you want to be running a webserver or mailserver. There’s a whole debate here, but trust me, it’s tough to really keep a virtual instance of a server running out of your house, and that busts your love-momentum. You gotta love it, and to love it, you gotta rely on it being there. And it’s just so easy these days with the hardware being as little as a $100 device that runs invisibly in your home and hardly shows up on your electric bill. So don’t bust your ass trying to turn your main desktop PC at home into a virtual host. Just get some practice in on virtual hardware, then move onto the real stuff.
Hardware is power; and don’t you forget it. Billion-dollar endeavors result from being able to make hardware rise up and do your bidding, like the brooms in Fantasia’s The Sorcerer’s Apprentice. But unlike Mickey who goes awry by only reading only a few pages of the book, we’re going to put in the hard work to become the powerful sorcerer. And even though this will ultimately be expressed by using cloud services (not real hardware), many providers are trying to lock you into yet another vendor dependency–just as surely as happens with software programming platforms. For example, C# relies on .NET relies on Micrsoft Windows relies on x86 Intel-like hardware, and you can never get away from it, without a great deal of pain. It’s ziggurat of dependencies that vendors are trying to reproduce in providing cloud services. They are happy to have you virtualize on their system so long as your virtualization is stuck there.
Avoid that by mastering hardware NOT in the cloud first. Live efficiently on small systems. Experiment on non-Intel platforms, like ARM. Run it out of your house. Buy a domain name and resolve it to that box, optionally using DynDNS overcome dynamic IP issues. Focus on the PROCESS of building your model template Unix/Linux system running on any piece of hardware you sit down at–rather than relying on copying a ready-made virtual appliance image.
Before working on real hardware, get your practice in with virtualization. Installing onto real hardware is almost identical to installing on virtual hardware. So, build yourself a virtual server for practice, getting familiar with installation and security issues. Maybe, follow my approach so that you get deeply exposed to issues along the way, and can amaze your friends with how it requires no install and boots flawlessly on either a Mac or PC host. Make mistakes. Learn debootstrap. Carry around that Linux pendrive. Install some application software.
Prepare yourself mentally for all your “instances” of Linux to be nearly identical, with your programming code flowing freely from one to the next, through the use of a distributed revision control system, like GIT or Mercurial (MUCH more on that later). Prepare to replace your beloved integrated development environment (IDE, such as VisualStudio) with a text editor, vi (or vim) that single-handedly expresses all that is loved and hated about Unix/Linux in one giant mind-numbing moment of brain re-wiring, from which you may never recover, but won’t be sorry.
Purge out all vendor allegiance and dogmatic religion from your technology world-view. Linux sucks. Unix sucks. PCs suck. All technology is imperfect. There was always something better at some specific task, and there will always be something better again. No matter what choice you make, it won’t be the best one in all cases. The world is an imperfect place, and you must pick and learn to love a particular set of imperfect tools, and I’m choosing Unix/Linux.
I make that choice because Unix-like operating systems have already had great deal of longevity, and only promise to have a great deal more. It underlies the Mac and iPhone. Its in cable TV boxes, WiFi routers, and is becoming embedded into more and more devices as the defacto standard information technology plumbing. I also choose Unix/Linux because they satisfies the 80/20 rule, by which you get 80% of the benefit of basing your projects (and career) on it, from the first 20% of your effort–ONCE you’ve gone through the learning curve.
And after tons of false starts in my career, impaling myself on dead technologies, licking my wounds and going dormant into marketing from time to time, I finally feel I have a story to tell. It is actually something you can hold in your hand, and turn into a thousand different endeavors, instances, careers, and perhaps even use it to build an empire. If it works out as I plan, it may even be the first step in what I envision to be my own great work.
I also think that the activity here on MikeLev.in will help you stay in touch with the undercurrents of technology zeitgeist, expressing the heebie jeebies that so many feel relying on proprietary vendor technology for their own careers. But more than just expressing it, it gives you a practical formula and a prescribed method for dealing with it. We all need that open source backup plan–not that open source is a cure-all, but at least someone else can step in to take over heavily relied-upon projects. Unix ain’t going away.
And finally, I believe that my approach to mastering Linux to be one of those great equalizers in technological careers, and indeed life. It has a touch of the underdog story to it that we all love so much. Right as everyone else is saying that the days of the single-handed Webmaster who can and does do everything is over–yielding to specialization in teams, I’m saying NO! Due to the very nature of technology, one person actually can and should still be able to do everything! Let them become rare, but let them become more powerful! And of course let them be us. Take your lesson from Mickey and pick up that sorcerer’s book and give it a try.