what would you pay for good kernel documentation?

[Mike Kallies]

Robert P. J. Day wrote:
>   (i posted a longer form of this on the kernel newbies mailing list
> earlier this morning, so i'll just hit the highlights.)
> 
...
>   i'm mentioning this here since i'm interested in feedback, of
> course.  your thoughts?  how many of you would be a target market for
> that sort of thing?  and if you found the content useful, would you
> consider supporting it?  or, given the vagaries of human nature, do
> you suspect that everyone will simply read, take what they want, and
> leave?
> 
>   and is there anyone out there who's tried something like this?  what
> did you do?  did it work?  etc, etc.  i realize this post is again
> more than a little self-serving but i finally decided that i really
> enjoy writing good tutorials and i'd like to keep writing them, but i
> just need to justify the time invested.

Disclaimer:  I'm not an author :-)

I think that so *few* people will pay, that it probably won't make you
enough money to be worth the effort.  But I do think you'll get
something from it.

There's one alternative out there which I *think* has been successful.
Compile your works into books and include a link to the book in every
article you write.  Even put the books online in html or something.

We still live in a day where most people prefer print copy of long
reading materials.  It's probably going to be like that for at least
another 5-10 years.  That's going to exceed the useful life of most
technical materials, and in the meantime, new strategies might develop.

This was what Bruce Eckel did with "Thinking in C++".  It was years ago
that he did it.  I never bought a copy of his book, but I wasn't
learning C++ at the time, and I had print copies of other books already.
 I printed the one or two chapters I needed and would have certainly
bought the book if I didn't already have primary reference material.

http://www.mindview.net/Books/TICPP/ThinkingInCPP2e.html

On the flipside, others have published annotated print copies of the
Apache source code and I think some similar attempts at the Linux
kernel.  The greatest fault there I think was that the source code, and
the book was out of date as soon as it hit the publisher.  They almost
went straight from the publisher to the discount bin.

So I think the audience needs to be defined carefully... there's no
point in writing a book which is specific to a minor kernel version.

I think there are already books for device driver authors.  I'm not sure
if there are already books for students of operating system design...
Tanenbaum and Minix was king when I was in school, I'm not sure if
that's still the case.

People *thinking about* or curious about how the kernel works, might
benefit from a 200-page guide of how a modern kernel works with maybe a
second 1000 page volume about the details of module loading, virtual
memory, device drivers, virtualization, etc.

The reason I talk about such a small book is becaues there are a lot of
really crappy books out there which are 90% deep-dives into the
technical nitty-gritty and only skim the high level design aspects.  The
nitty-gritty outdates very, very fast.  Most of these books look so
useless that I can only think that they exist to impress people walking
into your office.

I personally could benefit from a kernel guide to help me better
understand things like how performance tools like vmstat, top and /proc
generates numbers for purposes of baseline and tuning systems in system
administration.

... but if the 200 page guide were a monthly posting on a blog, I'm
sorry to say that no, at this point in the history of the Internet, *I*
wouldn't pay for articles online.... and I can't justify to management
donating money to your website as a business expense :-)

again, I'm not an author... just my $.02


-Mike
--
The Toronto Linux Users Group.      Meetings: http://gtalug.org/
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://gtalug.org/wiki/Mailing_lists