Recently, I was at a conference and I met a young person who wanted to start using free and open source software, but they did not know where to start.

They told me that they were a programmer and even could do simple programs in C, but they wanted an open source IDE (there are a couple) and they were "even willing to learn vim or emacs, but they are really hard."

Now I have been a vim person for a long time, mostly through a series of editors that first started using hardcopy terminals. While these editors were not written by the same people, each was typically compatible enough that I moved from one to the other as the new ones occurred. I was using vi/ex (very usable on a hardcopy terminal) when I migrated to vi/ex on character cell terminals that used termcap to translate strings of cursor-control output for positioning characters on the screen.

I do realize, however, that beginning to use a powerful editor like vim or emacs seems daunting. There are whole books on how to use these editors for what seems to be a relatively simple task: moving and editing text characters.

This is actually true for most of open source (including free) software and is multiplied by the fact that you can learn "below" what the developers actually expose to the end user. It is easy to become overwhelmed.

My advice to my young friend was to concentrate on a small subset of commands for vim (I could have easily substituted emacs, but I chose vim) to open a file, save a file, go into input mode, escape from input mode, move around in the full-screen mode, etc.

Over time you can learn about how to search for strings or move to the end of the line or the beginning with one or two keystrokes, but you can learn those as you go.

Should you try to remember all the commands? No, but you think "I bet that vim has this command, let me find it in the help facility."

Likewise this is true of GNU/Linux itself. While the power of Linux really lies beneath the graphical interface at what most people think of as "the command line" or "shell level," many people can do whatever they need to do without ever learning these levels of usage.

People can create files using the graphical text editor (on my system this is xed,) launched through the menu system, which is very mouse based. You can move through the directory structure using a graphical file manager. You can print on a file by clicking on it and choosing the function of "print" with your mouse. It's totally graphical, and many applications are available that work just that way, no command line needed.

However, to really experience the power of GNU/Linux, you have to be willing to search, experiment, and learn.

In 1977 I became a Unix systems administrator at Bell Laboratories. While I had worked on a variety of operating systems and hardware, I had never worked on a Unix system before. Bell Labs (the creators of Unix) hired me because I had demonstrated the ability to learn on my own and apply it.

Bell Labs sent me to a one-week course in Unix and set me up to have two mentors help me with the administration while I came on board.

One night I was sitting at the (paper) console of the Unix system, and I had hundreds of files that had to be updated by moving one element on each line of each file to another place on the same line of that file. I was patiently (and for people that know me, patience is not my strongest strength) editing one file after the other, doing this on each line. I estimated that it would take eight hours or more.

After about two hours of this, I stopped. I said to myself "I do not know that Unix has a command to do this, but I am willing to bet that it does." So I stopped my editing and started looking through the Unix manual.

After a short time I came across the command cut, which seemed to do what I wanted, but I needed more. At the bottom of the page I saw the words "See also paste." Looking at that page, I formulated a plan to use cut and paste to do what I needed. Twenty minutes later I walked out of the room.

I did not memorize everything that cut could do, or even the rest of the commands, but after that, once a year, I spent an hour or two just refreshing my mind about the different Unix commands.

I knew the rest of the commands would do what I needed when I needed it.