Contact: Aaron Eppert
Homepage: currently, this is it
License: TBD
GOALS/IDEAS:
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.
- Appendix for Command Summaries (ie, ls(1), rm(1), etc)
- 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.
- 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!)
- History behind Linux
- Go all the way back to Bell Labs
- How Minix ``contributed''
- Linus' desire to learn C
- GNU Project Involvement
- Overview of Linux/Unix Usage (``Why Unix/Linux?'')
- Design philosophy
- Reasons for usage
- OSS ideology
- How to navigate/find help.
- Introduce man(1) immediately and why it should be used
- Basic (navigation) commands
- 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.