How I Learned Linux

[Update: A bunch of you are here because Eric S. Raymond is awesome and nice. Thanks, ESR!]

And, by extension, how you can.

I’ll start this off with a disclaimer. I am not a Linux expert by any means–in fact, I’m not even fluent, and don’t use it as my main operating system. However, if I sit down in front of a Linux computer to do some work, I’m perfectly comfortable with using it. I can use the command line comfortably, I know what repositories are for and not to download just whatever interesting-looking tarball off the Internet (unless I’m doing so to tinker with it), I can do a tiny bit of shell scripting, and I can even compile or interpret my own programs (written in less annoying languages) via the command line.

Most people are not there. It took me a long time to get there; I remember being interested in Linux long before I figured out even how to learn how to use it.

The boost that let me get into the Linux world was discovering virtual machines, which are great for letting you play with different distros, screw things up, delete everything if you want/need to, start over–all sort of nonsense. It’s worth noting that Linux systems won’t be as reliable on a VM because of funky stuff with virtual hardware and guest additions and that kind of thing. The tutorial I wrote earlier can help with that. (If you’re used to Windows, you won’t notice anything strange about their reliability.)

You don’t need to take a formal class on Linux. In fact, if you really want to learn Linux, taking a class will feel painfully slow for you and will probably try to teach you silly stuff like how to get X Windows [*] to run on a network, which will be boring and frustrating. You can learn much of what you would in a Linux class by tinkering–although, if you’re focused on computer networking rather than programming, you might like taking a class.

On whether it’s right to write intro posts like this

Hackerdom seems to contain a large contingent which considers that anyone who can’t find the information in the rest of this post for themselves isn’t worth helping, because they won’t have the right spirit or work ethic. I disagree. It’s entirely possible to not even know what to type into Google in order to start solving your problem, and this doesn’t necessarily imply anything about the person who is confused. Whether they’ll admit it or not, many hackers will have been similarly helped by being around other hackers who at least know what program their juniors are looking for but don’t know exists. This is what Linux User Groups are for–but, again, most people don’t know those exist, either.

I can understand not wanting to spoon-feed people all the way, and someone with the true hacker spirit wouldn’t want to be spoon-fed anyway because it’s too much fun to do your own research, since you run into lots of other interesting knowledge along the way. But I don’t consider it a detriment to the Linux world to give people a boost in, so here we go: how to get comfortable with Linux.

No, I’m not going to describe what everything does. This post would become ridiculously long and that IS something you can Google for yourself. I will, however, provide you with good links and descriptions where they’re necessary. 

1. Set up your first virtual machine (VM).

i. Download VirtualBox (opens in new tab)

ii. Download a torrent client–a reader suggested deluge or transmission; I haven’t used them myself. I use uTorrent, but as I don’t know much about P2P systems, I pretty much picked the first one I found. As our commenter pointed out, uTorrent has certain questionable downsides. Perhaps when I have time, I’ll do some research about the different torrent clients and do a post about it.

Also, learn how to set it up. If stuff downloads, but only uploads at a painful snail’s pace, you probably have it set up wrong (although you might just have a less popular distro).

iii. Torrent at least one Linux .iso file. If given the option, choose 32-bit.

Distros (distributions) you might want to play with include Xubuntu (which is pretty easy to use and has a decent interface), Debian with GNOME (which is my favorite), Fedora (which is a little different! but maybe you’ll like it), and Mint (which, depending on which one you get, may be based off of either Ubuntu or Debian–it’s kind of a nice middle ground between them and very popular). I suggest making VMs of any distro you’re interested in, and playing with them, rather than relying on other people’s opinions about which you should use. Those posts can be fun to read, but not very helpful in the long run.

Distros you should save for a point when you know what you’re doing better and want to explore other things Linux can do include, but are not limited to, Puppy Linux and Kali Linux. Puppy is meant for running on tiny systems and can be run on computers which don’t even have a hard drive (it can run on just RAM), and Kali is meant for digital security testing. Please don’t do anything stupid with Kali.

iv. Set up your VM.

There are a lot of how-tos on this subject, including my own, which I just updated; I really suggest that you get into the habit now of checking more than one to see how they’re different and how one might be better than the other. My own included a few weird voodoo/cargo-cult programming things that were in there because they’d made something work for arcane reasons when really it was something else that was wrong–which is why it just got updated, and why you should always look at more than one tutorial. Keep the links of good tutorials; you’ll meet other newbies who need them.

2. Learn the command line.

There are numerous excellent tutorials on this. I don’t need or want to rewrite them, but I will link to them.

Zed A. Shaw’s tutorial at the end of Learn Python the Hard Way. Start with this one. Keep the link; you can learn Python at that web site, the tutorials are really good. Don’t be dissuaded by the name, it’s easier than learning from the dispassionate bureaucrats writing Microsoft programming manuals any day.

How-To Geek (Will teach you how to install things, very important–although if you’re using Fedora or a derivative, you can’t use apt-get. Just replace “apt-get” with “yum” in any of the commands mentioned and you should be fine.)

If you’re still confused about apt-get, look here for Ubuntu’s how-to. — I don’t remember reading this all the way through, but I had it bookmarked, so probably it answered some question or other. Come back to it if you have questions.

3. Don’t break your system (unintentionally).

Sometimes you intentionally pound on stuff to see what breaks it. However, if something breaks and you have no idea what you did, that’s a glaring neon sign that you haven’t learned enough. It helps to know what kind of stuff will break your system and why before you get to that point, though.

Here’s a link I found with good advice. It says Debian, but the points it makes are not Debian-specific.

Don’t Break Debian

4. Know where to go for help.

Your first resource when you don’t know how something works should be this really helpful command that you NEED to know. It’s called “man”. No, there isn’t a “woman” command. “man” is short for “manual.”

Typing “man ls” into the Terminal will show you everything you could ever want to know about the ls command, including different formatting options like -a and -l. The utility of those flags may not seem like much, until you write a shell script that needs to use ls and have the output in a reliable format, so man pages can be your best friend.

Man pages can also be found on the Internet.

Google is your other best friend. Learn how to use it, please; it’ll save everyone’s time, including yours, in the long run.

However, if you’ve spent more than 30 minutes to an hour (depending on the complexity/obscurity of your problem) trying to find answers, it’s probably time to go to a human. Preferably, one who can program.

Your distro will have its own forum. If you’re trying out different distros, make sure you go to the right forum for the distro that has the problem, even if the bug isn’t distro-specific.

There are also more general Linux forums, like this one which even has a newbie section.

5. Learn the secret handshake.

I was going to make a joke about this to finish off the article. Then I realized there actually is kind of a secret handshake, if you want to be a hacker and not just become competent with Linux. Consider this optional but fun; it may help you stick with Linux instead of giving up, so visit these links if you get bored.

The Jargon File

How to Become a Hacker

How to Learn Hacking

This collection of links should set you in good stead to becoming competent with Linux. If, given this boost, you can’t get any further or find anything interesting to do with what you’ve learned… well, that’s the point where we’d be spoon-feeding you. But I think it’d be hard to get through all this without sort of learning the attitude and skills you’d need to keep going, if you wanted. If you weren’t cut out for this sort of hobby, you probably wouldn’t have had the persistence or interest to make it through–you would have given up halfway through this post.

Good luck, and happy hacking!

*X Windows is an older remote access program, and a window system. It used to be a reasonably good program, I’ve heard, but it’s not a good option now. It would allow you to virtualize one computer’s GUI on another computer. But there are inherent security risks in programs that transfer GUIs over a network–at least, so far. If there were a startup that wanted to improve that, I bet there’s a huge market for a secure remote access system.

Our teacher didn’t like it–she’s a firm believer in using SSH and the command line for this sort of thing, and I agree until someone comes up with a better solution–and I don’t think the textbook writer liked it either because he put it at the very end of the chapter, after all the other options.


SSH is faster anyway.