I'm writing a book about embedded Linux but I'm not going to compete with traditional technical books.  O'Reilly isn't my competition.  (I personally really like many O'Reilly books and how they're often they're written by open source contributors.)

My competition is often outdated and unfriendly, hard to use technical resources such as the web, mailing lists, wikis, forums, and yes, books.

I want to teach people how to develop embedded Linux systems.  I don't want to provide a step by step here's how you put together an embedded Linux system, although I'm going to do that.  I want to provide the how, but right behind that I'm going to provide the why.

Why does the manual tell me to do this step and then that step?  What's going on under the covers?  What if I (the reader) want to do something similar to this but changing things X, Y, and Z?

I'm going to answer those questions.  You (the reader) are going to help me.

The book's going to be inexpensive (not free).  There's going to be online collaboration (think Google Groups or a forum).  The book's going to take on the mantra of release early, release often.  Trees are going to die, but the book will be available in electronic formats too.

I think it's going to be amazing!  I hope you will, too.



26 October 2010