|[Home] [Credit Search] [Category Browser] [Staff Roll Call]||The LINUX.COM Article Archive|
|Originally Published: Friday, 31 December 1999||Author: Rob Bos|
|Published to: featured_articles/Featured Articles||Page: 1/1 - [Std View]|
The Value of a Community in Learning Linux
One of the most difficult things about Linux is the learning curve. For people who are accustomed to user interfaces that attempt to do everything for them, an interface that does exactly what you tell it to do with minimal fuss (graphical or command line) can be an invigorating breath of fresh air or a hard slap in the unsuspecting face....
The command line is a good example: the utter proliferation of tiny little tools and software, each with their own distinct purpose, syntax, and idiosyncrasies, can be extremely overwhelming at first. Yet it is also very powerful, allowing you to accomplish tasks easily in the Unix environment that would often be impossible or exceedingly difficult in any other environment. (Say... something like "for i in *mp3; do mv "$i" `echo "$i" | sed s/_/' '/g`;done" to replace the underscores in a whole lot of files with spaces in one big whack; and yes, there are probably easier ways to do this.)
The single most formidable problem with exploiting all these tools to their maximum effectiveness is not their syntax, nor their speed, nor any other of the seemingly large factors, but rather finding out about these tools in the first place. Start up bash and hit "Tab" a couple times at the prompt. A typical Linux distribution has well over a thousand distinct executable programs at your call, and your "vocabulary" at the beginning is limited mostly to "ls," "mv," "cp," and (let's say) "pico." The question quickly arises: with all these programs and no time to poke through them, how is one to find out how to accomplish what they need to do? Unix is goal-oriented, designed first and foremost to produce a result. And without that basic vocabulary of commands, without an essential grammar of how they string together, your linguistic competence in Linux will be limited to a frightening degree.
Some people learn their linguistic competence from books, some by simply interacting with their machines as much as possible, and some through formalised classes. Increasingly, however, it is becoming clear to me that the easiest way to learn the Unix command line, with its rich syntax, complex grammar, and immense vocabulary, is to treat it as you would any literal spoken or written language. The best way to learn Unix is to immerse yourself in a group of people who speak it fluently, who constantly use it, who can teach it to you, and show you how to express ideas in it.
Hence the value of a community in learning Linux. Geeks, like humans in general, are social beasts at heart. They congregate on mailing lists, newsgroups, web sites, IRC, instant messaging forums; everywhere. (On rare occasions they've even been known to meet in person. Fancy that!) These form the nuclei of communities within which Linux catches on, takes fire, and spreads itself. The people in those groups teach each other Unix as a matter of course, growing together in linguistic competence; the people who have learned the most help the people who haven't learned as much, each individual drawing on the experience of their friends. The intermixing of ideas and the exchange of discoveries is what allows any given person to learn how to use Linux to its maximum to the fullest extent of its capabilities. Books, classes, and exploration certainly complement the learning process, in the same way that they complement conventional linguistic development, but they are just that - complementary, not primary.
Simply put, the best and fastest way to learn about what Linux has to offer is to talk to people, interact with them, trade ideas and ask for help when you're stuck.
No one is saying, however, that you should nag everyone around you for trivial instructions on how to do every little thing. Quite the opposite. Linux is maintained by a network of communities, and they have better things to do than help everyone with things that are covered in the documentation. If you ask a question that is covered in plain sight on several Web sites, or in a prominent location on that program's man page, or in "/usr/doc/programname," don't expect people to have patience with you. Read on the subject, make sure you know what you're talking about, ask for points of clarification - but at the very least, put some effort into it. People get annoyed very quickly when bombarded with the same questions over and over again. There's a reason FAQs (frequently asked questions) are maintained.
In time, most Linux users are recruited into helping other people with something or another. It's fun to watch other people grow in their ability to use more and more complex commands, do more and more elaborate things, and know that you helped with that process.
Rob Bos, firstname.lastname@example.org.