OSWG logo
Open Source
Writers Group

Project Information
Main Page

OSWG Projects
Man Page Project
Wish List

open source writers group

Non-Condescending Guide to Linux for New Users

    Contact: Aaron Eppert
    Homepage: currently, this is it
    License: TBD


    1. Avoid condescending approach in every way possible. This is a problem common to a large majority of beginner's Unix books ala "Dummies *" and "Idiot's Guide to *."

    2. All topics should be approached clearly, concisely, AND completely. Books that only approach the new topics by "look at this", "type this", etc, are not enough for most people. For someone to truly appreciate the power and flexibility of Linux they must be told the ``how's'', ``why's'', and ``where's''. Granted there must be a very carefully balance met here to insure that enough information is given, but not too much to lose the point of the subject at hand.

    • One solution to this is extensive and _proper_ use of appendices.
      1. Appendix for Command Summaries (ie, ls(1), rm(1), etc)
      2. Appendix for detailed kernel configuration and (if possible!) summary of options present in the most recent/stable kernel. Keep as general as possible as to not out-date the book too quickly.
      3. XFree configuration information.

    3. Large goal of the book should be to teach the person _HOW_ to find help and learn. Extensive footnotes of URLs to web sites with greater detail than presented in the book and where the information from the book was researched. This _should_ be introduced no later than the second chapter of the book. Commands such as the obvious man(1) command, cat(1), ls(1), pwd, cd, ps(1), df(1), free(1), should all be introduced as a means for the person to at the very least be capable of explaining their problem to someone else or know how to search for help.

    4. History behind Linux should be displayed _properly_. Rather important introduction to the Operating System that people obviously want to learn about if they buy this book. Should appear as the first chapter, that way people can skip it if they so desire and not lose the ``solid'' material of the book.

    5. Section dedicated to questions such as "How do I do....", should be present. This allows anyone to search through the questions, which should be categorized in proper order, to find a rough idea of what they want to do. Poll the FAQs to find the most obvious ones to include and perhaps poll Tech Support at RHAT to find further questions that can be answered in the book.

    6. Keep book as abstract as possible. Should not focus on Red Hat in particular, nor Debian, etc. Red Hat, Debian, SuSE, etc, should be approached for specifics via Appendixes. This is where RPM and Debian's package manager should be detailed. Unfortunately it may have to be assumed that the person reading the book already has Linux installed. This can be fixed again by an addition to the appendix. Each distribution Appendix can have a section of ``Notes:'' recommended to the reader for installation of that particular package. So many books spend 70-80% of the content on just _installing_ the OS. Red Hat has a rather fine set of documentation for dealing with 90% of all problems encountered, plus people who buy Red Hat ``shelved'' receive 30 days of tech support for free. This is obviously a rather difficult situation and will require extensive research and question to clarify it one way or another.

    7. GUIs will be a difficult situation to approach. Is it necessary to dedicate an entire chapter to GNOME/KDE and if so _how_ do we spend time in those chapters? With this do we detail Enlightenment/FVWM2/WindowMaker/etc? Or is it sufficient to detail the differences between all of the window managers and GNOME/KDE? Detailing the differences would be easier than showing dedicating to showing individual programs. This is where the ``non-condesending'' approach comes in. It is more difficult to find exact details contrasting the environments listed above than it is for someone to just try them out on their own. If we teach the readers properly they will be able to find out on their own how to select their ``proper'' window manager/environment.

    8. Should keep the book as Unix generic as ``possible.'' Obviously we want this to be a Linux book, but the more details we give about commands and approaches being available elsewhere (ie other Unix environments), the more valuable of a resource this book will become.

    9. Diagrams and pictures should be used as frequently as possible. People gravitate toward detailed and logically explained images. Flowcharts, etc should be used often, but only properly. A bad graphic is far worse than absolutely no graphics.

    (This is not 100% complete but should give a solid idea of what is expected of the final product.)

    TOPIC EXAMPLES: (Perhaps chapters? --- Not remotely complete!)

    1. History behind Linux
      • Go all the way back to Bell Labs
      • How Minix ``contributed''
      • Linus' desire to learn C
      • GNU Project Involvement
    2. Overview of Linux/Unix Usage (``Why Unix/Linux?'')
      • Design philosophy
      • Reasons for usage
      • OSS ideology
    3. How to navigate/find help.
      • Introduce man(1) immediately and why it should be used
      • Basic (navigation) commands
        • ls
        • cd
        • pwd
        • ps
        • free
        • cat
    4. System Layout
      • Explain file-system hierarchy
        • Listing of / and detail what everything means from there
          • /bin - Executables
          • /boot - Linux kernel location ..
          • /etc - Configuration files... etc
            • Include brief history if possible about the naming convention. If you present ideas like this people tend to remember them more.


I (Aaron Eppert) would like to see this as much of a group effort as humanly possible. It is in everyone's best interest that this book should be maintained as much as possible by one main author/editor. This is the capacity that I shall serve. I would like to encourage contributions from outside sources when possible and critiques of the material is very much desired. The goal is to create a book in the spirit of the Linux community, which even has an ``overseer'' in Linus.

Linux is a trademark of Linus Torvalds. All other trademarks are owned by their respective companies.
Everything else, © 1999 Deb Richardson