Slashdot Mirror
Prime Time Freeware Manual: the Dossier Series
You're all of course aware that there's a huge quantity of excellent technical material on-line about the free/open software that you use ... but how much of it have you actually read? Computer's being what they are -- noisy glowing bulky contraptions with awkward physical controls and displays with a resolution a fraction of paper publications -- most of us aren't inclined to read long works on line. So the next step is where you resolve to do printouts of some of the manuals... and then you discover how long they really are. Many a project can fill multiple looseleaf binders with a single-sided printout of its docs. But if you spend about half a day on it you can probably figure out how to get a nice double-sided printout in a smallish typeface and squeeze it all into a single looseleaf binder... which turns out to *still* be too bulky to want to carry around with you. RTFM is easier said ...
The solution to this is of course professionally printed editions of the manuals. These have been easy to get for GNU software for some time -- the GNU Project standardized on documentation in 'texinfo' format which they use to generate both their online documentation and a very good series of books.
But all that is free is not GNU, and filling that gap is one of the goals of the Dossier series, which uses some semi-automated procedures to generate high-quality, up-to-date hardcopy-on-demand publication.
Thus far they've got books out on the following topics (available on-line through the BSD Mall):
- C, etc.: Essential Tools
- Email: Exim 3
- Email: Mail and Sendmail
- File Systems: FreeBSD
- File Systems: RedHat
- Kernel: FreeBSD
- PostgreSQL: Programming
- PostgreSQL: Reference Manual
- PostgreSQL: Use and Administration
- Processes: FreeBSD
- Processes: RedHat
- Python: Library Reference
- Python: Miscellanea
- Security: Local System
- Security: Remote Access
- Text Processing: Essential Tools
- User Commands: FreeBSD
- User Commands: RedHat
Some of the prices might seem a little high for works based on free content (usually $30 to $35 per volume), but on the other hand these are for small press runs without much in the way of economies of scale going for them. And it certainly beats messing with doing print-outs yourself. (Though if you want to go that route, Dossier can help take the sting out of that process: they offer online access to PDF versions of these works, which is much more inexpensive than paying them to ship you bound volumes.)
When I first heard about Prime Time Freeware/Dossier, I immediately ordered the Postgresql documentation, a set which fills three volumes. At that time the only Postgresql book out was Bruce Momjian's which only covered up to version 7.0. At the speed the postgresql development team was working, having docs more than one release behind was definitely a problem (outer joins weren't even supported in 7.0!). I really appreciated having some books I could flip through that discussed the actual state of the software (and man, there are some weird features in there I didn't know about ... graphical data types so that you can try and use postgres as a backend to a CAD system?).
Next I started looking at the volume on "Text" (now renamed "Text Processing" ... which is a shame, in my opinion. I thought it was really funny putting "Text" on the same level as "C" and "Python"). This is a book I would have liked to have some years ago when I needed to understand troff/nroff for man-page hacking (the only time I ever bought one of those 4-inch-wide junk books the 80s were buried under was to get a copy of "UNIX UNLEASHED" because it had a table of *roff commands ... it still bugs me that I had to do that).
One of the things that struck me immediately about this "Text" volume though, was that there were some utilities discussed here that I'd never heard of before, e.g. a2ps which has some decent features for formatting docs for postscript printers. I'd never run across it before, in part because it wasn't installed by default on my RedHat 7.x box. It's a pretty funky command that does a bunch of things automagically that are sometimes hard to predict, but if you need printouts of some docs, I recommend giving a2ps a try for double-column duplex output -- but only if you can't get them from some place like Dossier (yet).
Rich Morin has been working on the problem of making it easier for users of open systems to get information about them for some time, hence The Meta Project, which thus far has resulted in "Meta Demo," aka the FreeBSD Browser. The Dossier series is a spin-off of this research in documenting open systems... check-out the Meta Project sometime. (I'd like to see that system browser extended to cover Linux, myself).
Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
How is this a book review? Saying that there is a series of books available doth not a review make.
Reading a paper medium fior a long time is always best than on screen.
I'm of two minds about printed documentation. On more consumer oriented platforms, such as the Mac OS, and Windows, I've never had need to touch the printed stuff, and the built in help is rarely of use. With *NIX machines, I've always wanted to get full printed documentation, but once I get ahold of if for the stuff I'm using, I never pull it out. Man pages and online documentation are just to convenient.
I feel as though having printed documentation ought to help, but it doesnt. Do people who learned computing through batch systems find things to be different? I know that old DEC junkies typically have a few bookcases of documentation, is that because they learned the systems that way (and find it useful), or just because they are pack rats?
It's more environmentally sound to produce paper than microchips. And paper books dont consume the ~150watts my PC and CRT do.
The paper industry by and large farms the trees they use, and ever larger portions are recycled. It really is time to update the Greenpeace pamphlets.
I don't need no instructions to know how to rock!!!!
Perhaps the test is hpow long you're going to use the book.
Does anyone out there read books on PDA's? How do you find it compared to reading from the computer or reading from a dead-tree book?
It's not wasting time, I'm educating myself.
The problem is that the electronic formats are not always as useful as the paper format. Electronic documentation describing how to fix your computer won't do you much good if your computer is malfunctioning.
Can I order the paperback version of this review?
You can highlight it (a big plug)
You can tag/mark important pages
You can read the paper and the screen (fullscreen) at the same time without switching TTY's
You can have multiple pages open at ones (if looseleaf) and sometimes switching between is easier as well
You can take then with you when not at a PC
If you're in the loo and run out of TP... well...
Most *NIX man pages have a horrible interface and are poorly written. They do not have a tutorial style, and generally show you the commands and a brief definition, but nothing more.
But whether that's online or on paper, it's still going to suck. It's even worse on paper because it's not hyperlinked and has no search capability.
I have read manuals that were completely on the computer and also printed out. I shipped the printed copies back to my parent's home to occupy my old room; I exclusively use the online stuff. It's better, it's faster, and it's exactly the same well-written stuff.
Printing books is a step backwards. It's destructive to the environment. What is really needed? A) Better writers B) a devotion and committment to explaining concepts more thoroughly C) more examples.
I have nearly switched 100% to reading on my Sony Clie, and I prefer my trusty PDA for most reading tasks. For one thing you can fit a pile of books onto a 128M Media Stick. I also like being able to read in the dark, and I really like the fact that as long as I have my PDA I always have a book to read. I am convinced that for casual reading there is no better way to go than a PDA.
Computer documentation, on the other hand, is somewhat more difficult. I have several computer textbooks on my PDA including: "Structure and Interpretation of Computer Programs," "The Emacs Lisp Manual," and "The Zope Book" to name a few. In fact, most everything available at the Linux Documentation Project is available in Plucker format. However, with computer text you generally have to be at least somewhat careful with line wrapping. A lisp function that looks fine formatted at 80 chars a line probably doesn't look so hot when you only have 40 characters per line, and if the book includes pictures then you are even worse off. PDA screens (at least Palm-based PDA screens) are still too narrow and offer too poor of a resolution for books with pictures or source code listings (IMHO).
Go to Baen's web site and download David Drake and Eric Flint's Belisaurius series and read that instead.
For those who haven't followed the article's link to the Meta Project, you really should give it a spin.
/etc/fstab. This points to the man page for fstab, as well as listing commands that read info from fstab (mount, umount, mount_nfs, etc) and their respective man pages.
Here's a sample from the FreeBSD browser, showing a metric arseload of info about the vi command. This page includes pointers to the vi man page, lists of other programs that are really symlinks to vi (and their respective man pages), config files used by vi, and temp files created by vi: all just a click away.
Here's another FreeBSD browser page for
Unix is complex, it is hard to succinctly show the interelations between all of the many pieces. The FreeBSD browser is a really nice step in the right direction!
For some documentation, I prefer to have it on the computer because you can't grep a dead tree. However, for some things, like for instance the Camel Book, I prefer to have it printed because it's something that I read all the way through, like a book. It's also easier to take with you (you don't always have access to a computer for reading). If it's just for reference about one particular part of the subject covered, on the computer is much more handy. But for something I'm going to read all the way through (possibly more than once), printed is the best.
Thank you, doom, for the nice review. Thanks, as well, to timothy, Slashdot,
and the folks who have taken the time and effort to comment. I would like to
respond to a few points that have been raised here; I'll try to be brief (:-).
Printed and online documentation are not mutually-exclusive alternatives. I
use either or both, depending on my needs of the moment. Books have been
around for about two millenia, so it's not surprising that they work well for
certain purposes. It is obvious, however, that electronic access has its own
advantages.
An edited collection (whether printed or PDF) adds significant value over the
"raw" body of source documents. Documents must be located, evaluated, selected,
organized, and formatted. It's not accidental that doom found some novel tools
in our collections; part of our objective is to introduce readers to relevant
tools, whether they are part of a "standard distribution" or not.
Doom is quite correct about the economies of scale for small press runs. Our
books are demand-printed in very small lots. This keeps the investment small,
but the cost per item is about three times (!) that of offset printing. Only
the use of Internet-based sales allows us to offer reasonable pricing.
Like doom, I'd like to see a "Linux Browser", but my resources are limited and
I'm concentrating on other tasks right now. If some Linux-knowledgeable folks
want to help (e.g., by annotating directories and file system relationships),
I encourage them to get in touch.
Aside from DOSSIER, my current efforts are concentrated on creating a browser
that will run on a local system and provide integrated access to documentation
and system metadata. I'm writing a series on this for MacTech Magazine.
A final note on DOSSIER: send topic suggestions! If you'd like to see a volume
on a particular topic, let me know; I may be able to do something about it (:-).
Technical editing and writing, programming, and web development
The physical quality of the books is pretty good: they're roughly comparable to the trade paper backs that you get from O'Reilley or the Free Software Foundation.
I mentioned the pricing of the books, but neglected the pricing of the PDF subscription service: $15/year/volume gets you a subscription to the current PDFs based on the latest versions of the documentation. There are somewhat cheaper deals if you order more, e.g. the three Postgresql volumes I discuss are probably a "topical set", so a subscription to PDFs of all three of them would be $10 * 3 = $30/year.
I didn't talk about the PDF option much because personally I'm not that interested in it: I want pages trimmed and bound like a real book. But it's option you should know about to make your own decisions.
Does the cost of the PDF seem excessive? Well you know, if you think you can do better, no one is stopping you (if you haven't tried it yet: formatting on-line docs in a reasonable way for paper printout is probably harder than you think).
And in defense of my quasi-review here: what kind of review would be *preferable* for these kinds of books? The source material for them is out there on the web, you can go and skim it yourself... though probably you know what it's like, more or less. (However: don't just assume it's all man pages. The postgresql docs are considerably better fleshed out than that.) My take is: does it help to have the information in this form? What do you get out of it that you wouldn't get from having it on your hard drive (or on the web)? And in case it isn't clear, the point is that you tend to do a different kind of browsing with books than with computers, and so you learn about slightly different things.