Slashdot Mirror

This week's Slashdot interview subject is Eric S. Raymond. You already know who he is, and may even know that his new book, The Cathedral and the Bazaar, subtitled Musings on Linux and Open Source by an Accidental Revolutionary, will be published by O'Reilly in October. We anticipate lots of questions for Eric. Please try to avoid the obvious ones he's answered thousands of times already, and try to ask only one question per post! We'll forward the selected 10 - 15 questions deemed most interesting by Slashdot moderators and/or editors to him Tuesday afternoon. Answers will appear Friday.

jimmcq writes "A User Friendly book is going to be published by published by O'Reilly & Associates. See the Press Release for more details. " It's been in the works for quite awhile, but it looks like O'Reilly has finally set a date: October, 1999.

Thanks to darrn chamberlain for an excellent review of the Lincoln Stein and Doug MacEachern book Writing Apache Modules with Perl and C. This is an excellent book for those considering working with Apache and mod_perl, and helpful for C programmers. Click below for more details. Writing Apache Modules with Perl and C author Li pages 724 publisher O'Reilly, ISBN: 156592567X rating 9.5/10 reviewer darren chamberlain ISBN summary Absolutely essential for anyone who is considering using Apache and mod_perl. C programmers may need more. The Scenario

If you're like me, your first introduction to Perl ^[?] was in the form of CGI ^[?] scripts. A few years ago, I inherited a few dozen ancient CGI scripts (Perl and otherwise) that required Immediate Attention. CGI led to Perl, and to Apache ^[?] ; Perl and Apache led, naturally enough, to mod_perl ^[?] , once I started hitting the performance bottlenecks inherenent in CGI programming. After researching mod_perl, building a mod_perl-enalbed Apache, and reading all the available online documentation, I got it up and running--and I was suitably impressed.

So, when O'Reilly ^[?] announced a book devoted to programming Apache with Perl, I was extremely excited. The book starts with an introduction and history of web programming, introduces CGI and other types of web programming (server API ^[?] 's, such as ISAPI and NSAPI; embedded processors, such as mod_perl, mod_dtcl, and mod_pyapache; FastCGI; Java ^[?] servlets ^[?] ; ActiveX ^[?] ; and client-side scripting languages, such as VBScript ^[?] and JavaScript ^[?] ), and then describes the Apache module architecture, using some simple examples ("Hello, World" in Perl and in C). Then it gets good, covering dynamically generated content; the hobgoblin of HTTP, state; and all the other stuff that gives CGI programmer nightmares (like authentication and authorization).

What's Bad?

Although the title reads '... with Perl and C', the emphasis is very obviously on Perl. The C API reference chapters (chapters 10 and 11, pages 505 through 631) are very thorough, but almost all the examples are in Perl only. In fact, the authors go so far as to recommend that almost all Apache modules be written in Perl, and not C, except for very small modules or modules that need that extra speed boost or small memory footprint of being compiled into the server (page 13: "Anything you can do with the C API you can do with mod_perl with less fuss and bother."). Their reasoning is sound: mod_perl modules and scripts require a server restart at most, and often not even that, while for C modules, Apache itself must be recompiled; but I was expecting more in this area, perhaps a larger section on using DSO. After the book was published, however, several of the Perl-only examples were ported to the C API, and are available for download.

A few of these examples have already been published, and in these cases the book is mostly redundant. Notably, the Apache::NavBar module (which Lincoln uses on the server in his lab) and the Apache::AdBlocker module (chapters 4 and 7), appeared in The Perl Journal last year (issues 12 and 11). This is not that big a deal, since both of these modules are incredibly useful and probably deserve to be published in a few more places, but two brand new modules would have been most welcome, especially since the book's target audience probably also reads The Perl Journal.

What's Good?

There's a lot to like here. Since I'm a Perl programmer by trade and disposition, I personally liked the fact that 99.9% of the examples were written in Perl. With only a few exceptions, the modules could be copied into the right locations and run immediately; the exceptions were the modules that made use of either other programs (Chapter 5's Hangman program which uses a relational database to store state information) or specialized Apache features (Chapter 7's Apache::AdBlocker module, which requires proxy functionality).

Much of the text and all of the source code is available on the web at www.modperl.com. Chapters 6, 7, 8, and 9 can be found on the web site for the book, as can all the Perl modules and some of the examples in functional form (Apache::Magic and hangman).

Chapter 9 is the key chapter, and the heart of the book. It describes in great detail all the Apache:: modules. If you use mod_perl at all, download and print this chapter. Memorize it. Use your favorite indexing script to make it searchable. Everything you need to know about mod_perl is here in this chapter.

The appendices are also excellent, although, because it is an Apache book, I would have figured that several of the sections would be regular chapters, and not relegated to the end. The appendices are divided pretty evenly between concentrating on Perl and on C, unlike most of the rest of the book.

So What's In It For Me?

Fortunately for people like me, there is a lot of information about mod_perl on the web; The Perl Journal has had several articles on it, WebMonkey has had an article or two, and so on. There is a comprehensive mod_perl developer's guide on the offical Apache/Perl site. Lincoln Stein uses it a lot on his site and in his software. And, of course, we have the man pages and perldocs. So why do we need a book?

A few reasons. First and foremost, few of those sources go into the kind of detail that this book does, while still being approachable. Second, the book focuses on Apache, programming Apache, and (to a lesser extent) programming applications on the web; Perl and C are the means here, not the end. The in-depth technical discussions are about Apache: how it translates URI's to filenames, how it handles subrequests and internal redirects, how it maps files to MIME types. It then presents techniques for usurping these functions, customizing each phase of the reponse process, and explains when and why you would want to do this, instead of letting Apache do it's own thing. Creating checksums on the fly, compressing and decompressing data, creating extremely flexible HTML preprocessors, and modifying outgoing and incoming headers are some just some of the given examples.

The reference chapters are probably the single most valuable thing about the book. If you are a Perl programmer on a budget, you can download chapter 9 from the web site, but the C programmers out there have to buy the book to get the C API refernce. The C reference is 2 chapters (126 pages) long, and covers all the functions in precise detail.

For those among you who are using Microsoft operating systems, the book pays special attention to building, installing, and configuring mod_perl and Apache on Win32 systems, where it is different from Unix and Unix-like systems. Most of the actual modules are very similar (except for the obvious ones, such as scripts that call sendmail and the scripts that access MySQL), but the installation and building of mod_perl (or ApacheModulePerl.dll) are very different. The process is described in enough detail to make it possible, without boring those readers to whom it is irrelevant.

Conclusion

Programming Apache/mod_perl without this book is like writing Perl without the camel book. It can be done, but it is much easier and more enjoyable with the book. The writing is clear, informative, straight-forward, and, at times, amusing. The authors are the definitive sources for information on mod_perl and CGI programming, and this is reflected in every aspect of the book. While not as definitive for C programmers, it is still the best Apache API reference out there, other than the actual source code itself.

Purchase this book at Amazon.

Errata Table of Contents

1. Server-Side Programming with Apache
2. A First Module
3. The Apache Module Architecture and API
4. Content Handlers
5. Maintaining State
6. Authentication and Authorization
7. Other Request Phases
8. Customizing the Apache Configuration Process
9. Perl API Reference Guide
10. C API Reference Guide, Part I
11. API Reference Guide, Part II

1. Standard Noncore Modules
2. Building and Installing mod_perl
3. Building Multifile C API Modules
4. Apache:: Modules Available on CPAN
5. Third-Party C Modules
6. HTML::Embperl--Embedding Perl Code in HTML

Thanks to darrn chamberlain for an excellent review of the Lincoln Stein and Doug MacEachern book Writing Apache Modules with Perl and C. This is an excellent book for those considering working with Apache and mod_perl, and helpful for C programmers. Click below for more details. Writing Apache Modules with Perl and C author Li pages 724 publisher O'Reilly, ISBN: 156592567X rating 9.5/10 reviewer darren chamberlain ISBN summary Absolutely essential for anyone who is considering using Apache and mod_perl. C programmers may need more. The Scenario

If you're like me, your first introduction to Perl ^[?] was in the form of CGI ^[?] scripts. A few years ago, I inherited a few dozen ancient CGI scripts (Perl and otherwise) that required Immediate Attention. CGI led to Perl, and to Apache ^[?] ; Perl and Apache led, naturally enough, to mod_perl ^[?] , once I started hitting the performance bottlenecks inherenent in CGI programming. After researching mod_perl, building a mod_perl-enalbed Apache, and reading all the available online documentation, I got it up and running--and I was suitably impressed.

So, when O'Reilly ^[?] announced a book devoted to programming Apache with Perl, I was extremely excited. The book starts with an introduction and history of web programming, introduces CGI and other types of web programming (server API ^[?] 's, such as ISAPI and NSAPI; embedded processors, such as mod_perl, mod_dtcl, and mod_pyapache; FastCGI; Java ^[?] servlets ^[?] ; ActiveX ^[?] ; and client-side scripting languages, such as VBScript ^[?] and JavaScript ^[?] ), and then describes the Apache module architecture, using some simple examples ("Hello, World" in Perl and in C). Then it gets good, covering dynamically generated content; the hobgoblin of HTTP, state; and all the other stuff that gives CGI programmer nightmares (like authentication and authorization).

What's Bad?

Although the title reads '... with Perl and C', the emphasis is very obviously on Perl. The C API reference chapters (chapters 10 and 11, pages 505 through 631) are very thorough, but almost all the examples are in Perl only. In fact, the authors go so far as to recommend that almost all Apache modules be written in Perl, and not C, except for very small modules or modules that need that extra speed boost or small memory footprint of being compiled into the server (page 13: "Anything you can do with the C API you can do with mod_perl with less fuss and bother."). Their reasoning is sound: mod_perl modules and scripts require a server restart at most, and often not even that, while for C modules, Apache itself must be recompiled; but I was expecting more in this area, perhaps a larger section on using DSO. After the book was published, however, several of the Perl-only examples were ported to the C API, and are available for download.

A few of these examples have already been published, and in these cases the book is mostly redundant. Notably, the Apache::NavBar module (which Lincoln uses on the server in his lab) and the Apache::AdBlocker module (chapters 4 and 7), appeared in The Perl Journal last year (issues 12 and 11). This is not that big a deal, since both of these modules are incredibly useful and probably deserve to be published in a few more places, but two brand new modules would have been most welcome, especially since the book's target audience probably also reads The Perl Journal.

What's Good?

There's a lot to like here. Since I'm a Perl programmer by trade and disposition, I personally liked the fact that 99.9% of the examples were written in Perl. With only a few exceptions, the modules could be copied into the right locations and run immediately; the exceptions were the modules that made use of either other programs (Chapter 5's Hangman program which uses a relational database to store state information) or specialized Apache features (Chapter 7's Apache::AdBlocker module, which requires proxy functionality).

Much of the text and all of the source code is available on the web at www.modperl.com. Chapters 6, 7, 8, and 9 can be found on the web site for the book, as can all the Perl modules and some of the examples in functional form (Apache::Magic and hangman).

Chapter 9 is the key chapter, and the heart of the book. It describes in great detail all the Apache:: modules. If you use mod_perl at all, download and print this chapter. Memorize it. Use your favorite indexing script to make it searchable. Everything you need to know about mod_perl is here in this chapter.

The appendices are also excellent, although, because it is an Apache book, I would have figured that several of the sections would be regular chapters, and not relegated to the end. The appendices are divided pretty evenly between concentrating on Perl and on C, unlike most of the rest of the book.

So What's In It For Me?

Fortunately for people like me, there is a lot of information about mod_perl on the web; The Perl Journal has had several articles on it, WebMonkey has had an article or two, and so on. There is a comprehensive mod_perl developer's guide on the offical Apache/Perl site. Lincoln Stein uses it a lot on his site and in his software. And, of course, we have the man pages and perldocs. So why do we need a book?

A few reasons. First and foremost, few of those sources go into the kind of detail that this book does, while still being approachable. Second, the book focuses on Apache, programming Apache, and (to a lesser extent) programming applications on the web; Perl and C are the means here, not the end. The in-depth technical discussions are about Apache: how it translates URI's to filenames, how it handles subrequests and internal redirects, how it maps files to MIME types. It then presents techniques for usurping these functions, customizing each phase of the reponse process, and explains when and why you would want to do this, instead of letting Apache do it's own thing. Creating checksums on the fly, compressing and decompressing data, creating extremely flexible HTML preprocessors, and modifying outgoing and incoming headers are some just some of the given examples.

The reference chapters are probably the single most valuable thing about the book. If you are a Perl programmer on a budget, you can download chapter 9 from the web site, but the C programmers out there have to buy the book to get the C API refernce. The C reference is 2 chapters (126 pages) long, and covers all the functions in precise detail.

For those among you who are using Microsoft operating systems, the book pays special attention to building, installing, and configuring mod_perl and Apache on Win32 systems, where it is different from Unix and Unix-like systems. Most of the actual modules are very similar (except for the obvious ones, such as scripts that call sendmail and the scripts that access MySQL), but the installation and building of mod_perl (or ApacheModulePerl.dll) are very different. The process is described in enough detail to make it possible, without boring those readers to whom it is irrelevant.

Conclusion

Programming Apache/mod_perl without this book is like writing Perl without the camel book. It can be done, but it is much easier and more enjoyable with the book. The writing is clear, informative, straight-forward, and, at times, amusing. The authors are the definitive sources for information on mod_perl and CGI programming, and this is reflected in every aspect of the book. While not as definitive for C programmers, it is still the best Apache API reference out there, other than the actual source code itself.

Purchase this book at Amazon.

Errata Table of Contents

1. Server-Side Programming with Apache
2. A First Module
3. The Apache Module Architecture and API
4. Content Handlers
5. Maintaining State
6. Authentication and Authorization
7. Other Request Phases
8. Customizing the Apache Configuration Process
9. Perl API Reference Guide
10. C API Reference Guide, Part I
11. API Reference Guide, Part II

1. Standard Noncore Modules
2. Building and Installing mod_perl
3. Building Multifile C API Modules
4. Apache:: Modules Available on CPAN
5. Third-Party C Modules
6. HTML::Embperl--Embedding Perl Code in HTML

Thanks to darrn chamberlain for an excellent review of the Lincoln Stein and Doug MacEachern book Writing Apache Modules with Perl and C. This is an excellent book for those considering working with Apache and mod_perl, and helpful for C programmers. Click below for more details. Writing Apache Modules with Perl and C author Li pages 724 publisher O'Reilly, ISBN: 156592567X rating 9.5/10 reviewer darren chamberlain ISBN summary Absolutely essential for anyone who is considering using Apache and mod_perl. C programmers may need more. The Scenario

If you're like me, your first introduction to Perl ^[?] was in the form of CGI ^[?] scripts. A few years ago, I inherited a few dozen ancient CGI scripts (Perl and otherwise) that required Immediate Attention. CGI led to Perl, and to Apache ^[?] ; Perl and Apache led, naturally enough, to mod_perl ^[?] , once I started hitting the performance bottlenecks inherenent in CGI programming. After researching mod_perl, building a mod_perl-enalbed Apache, and reading all the available online documentation, I got it up and running--and I was suitably impressed.

So, when O'Reilly ^[?] announced a book devoted to programming Apache with Perl, I was extremely excited. The book starts with an introduction and history of web programming, introduces CGI and other types of web programming (server API ^[?] 's, such as ISAPI and NSAPI; embedded processors, such as mod_perl, mod_dtcl, and mod_pyapache; FastCGI; Java ^[?] servlets ^[?] ; ActiveX ^[?] ; and client-side scripting languages, such as VBScript ^[?] and JavaScript ^[?] ), and then describes the Apache module architecture, using some simple examples ("Hello, World" in Perl and in C). Then it gets good, covering dynamically generated content; the hobgoblin of HTTP, state; and all the other stuff that gives CGI programmer nightmares (like authentication and authorization).

What's Bad?

Although the title reads '... with Perl and C', the emphasis is very obviously on Perl. The C API reference chapters (chapters 10 and 11, pages 505 through 631) are very thorough, but almost all the examples are in Perl only. In fact, the authors go so far as to recommend that almost all Apache modules be written in Perl, and not C, except for very small modules or modules that need that extra speed boost or small memory footprint of being compiled into the server (page 13: "Anything you can do with the C API you can do with mod_perl with less fuss and bother."). Their reasoning is sound: mod_perl modules and scripts require a server restart at most, and often not even that, while for C modules, Apache itself must be recompiled; but I was expecting more in this area, perhaps a larger section on using DSO. After the book was published, however, several of the Perl-only examples were ported to the C API, and are available for download.

A few of these examples have already been published, and in these cases the book is mostly redundant. Notably, the Apache::NavBar module (which Lincoln uses on the server in his lab) and the Apache::AdBlocker module (chapters 4 and 7), appeared in The Perl Journal last year (issues 12 and 11). This is not that big a deal, since both of these modules are incredibly useful and probably deserve to be published in a few more places, but two brand new modules would have been most welcome, especially since the book's target audience probably also reads The Perl Journal.

What's Good?

There's a lot to like here. Since I'm a Perl programmer by trade and disposition, I personally liked the fact that 99.9% of the examples were written in Perl. With only a few exceptions, the modules could be copied into the right locations and run immediately; the exceptions were the modules that made use of either other programs (Chapter 5's Hangman program which uses a relational database to store state information) or specialized Apache features (Chapter 7's Apache::AdBlocker module, which requires proxy functionality).

Much of the text and all of the source code is available on the web at www.modperl.com. Chapters 6, 7, 8, and 9 can be found on the web site for the book, as can all the Perl modules and some of the examples in functional form (Apache::Magic and hangman).

Chapter 9 is the key chapter, and the heart of the book. It describes in great detail all the Apache:: modules. If you use mod_perl at all, download and print this chapter. Memorize it. Use your favorite indexing script to make it searchable. Everything you need to know about mod_perl is here in this chapter.

The appendices are also excellent, although, because it is an Apache book, I would have figured that several of the sections would be regular chapters, and not relegated to the end. The appendices are divided pretty evenly between concentrating on Perl and on C, unlike most of the rest of the book.

So What's In It For Me?

Fortunately for people like me, there is a lot of information about mod_perl on the web; The Perl Journal has had several articles on it, WebMonkey has had an article or two, and so on. There is a comprehensive mod_perl developer's guide on the offical Apache/Perl site. Lincoln Stein uses it a lot on his site and in his software. And, of course, we have the man pages and perldocs. So why do we need a book?

A few reasons. First and foremost, few of those sources go into the kind of detail that this book does, while still being approachable. Second, the book focuses on Apache, programming Apache, and (to a lesser extent) programming applications on the web; Perl and C are the means here, not the end. The in-depth technical discussions are about Apache: how it translates URI's to filenames, how it handles subrequests and internal redirects, how it maps files to MIME types. It then presents techniques for usurping these functions, customizing each phase of the reponse process, and explains when and why you would want to do this, instead of letting Apache do it's own thing. Creating checksums on the fly, compressing and decompressing data, creating extremely flexible HTML preprocessors, and modifying outgoing and incoming headers are some just some of the given examples.

The reference chapters are probably the single most valuable thing about the book. If you are a Perl programmer on a budget, you can download chapter 9 from the web site, but the C programmers out there have to buy the book to get the C API refernce. The C reference is 2 chapters (126 pages) long, and covers all the functions in precise detail.

For those among you who are using Microsoft operating systems, the book pays special attention to building, installing, and configuring mod_perl and Apache on Win32 systems, where it is different from Unix and Unix-like systems. Most of the actual modules are very similar (except for the obvious ones, such as scripts that call sendmail and the scripts that access MySQL), but the installation and building of mod_perl (or ApacheModulePerl.dll) are very different. The process is described in enough detail to make it possible, without boring those readers to whom it is irrelevant.

Conclusion

Programming Apache/mod_perl without this book is like writing Perl without the camel book. It can be done, but it is much easier and more enjoyable with the book. The writing is clear, informative, straight-forward, and, at times, amusing. The authors are the definitive sources for information on mod_perl and CGI programming, and this is reflected in every aspect of the book. While not as definitive for C programmers, it is still the best Apache API reference out there, other than the actual source code itself.

Purchase this book at Amazon.

Errata Table of Contents

1. Server-Side Programming with Apache
2. A First Module
3. The Apache Module Architecture and API
4. Content Handlers
5. Maintaining State
6. Authentication and Authorization
7. Other Request Phases
8. Customizing the Apache Configuration Process
9. Perl API Reference Guide
10. C API Reference Guide, Part I
11. API Reference Guide, Part II

1. Standard Noncore Modules
2. Building and Installing mod_perl
3. Building Multifile C API Modules
4. Apache:: Modules Available on CPAN
5. Third-Party C Modules
6. HTML::Embperl--Embedding Perl Code in HTML

The return of Doc Technical is marked by his review of the upcoming O'Reilly book Mastering Algorithms with C. Click below if you wish to learn more about this Kyle Loudon book. Mastering Algorithms with C, 1st Ed. August 1999 author Kyle Loudon pages 560 publisher O'Reilly and Associates, ISBN= rating 6.5/10 reviewer Doc Technical ISBN summary A flawed but wide-ranging book for intermediate toexpert programmers. [Reviewers Disclaimer: This review is based on a pre-publication copy of the book, so some changes may have occurred in the published copy. Most of my comments relate to structure and content, and I expect they'll remain valid.]

There are many books on programming algorithms, and quite a few of them use C for their examples, but even so, I was looking forward to this new book from O'Reilly.

Most of the existing algorithm books were designed as college text books. While they have their place, there is certainly room for a book that approaches the subject matter in the informal, clear writing style and practical focus that is O'Reilly's trademark. Unfortunately, for me at least, Mastering Algorithms in C was not that book.

My Problem with Algorithms One of O'Reilly's strengths has always been their attention to the structure of their books. O'Reilly books are usually well designed, with logical and reader-friendly layouts. But Mastering Algorithms with C has a layout that I found somewhat vexing.

The chapter on linked lists serves to illustrate. An introductory section describes three kinds of lists, then briefly describes several applications for them (mailing lists, memory management, scrolled lists in GUIs, etc.). This is followed by a brief section describing the basic concepts of linked lists.

>From there the chapter moves directly to an implementation of linked lists, starting with a section called "Interface for Linked Lists". This section enumerates each function in a linked list library. For each function we are given its function prototype, followed by its return value, a brief description of the function's purpose, and finally, its algorithmic complexity in O-notation.

The next section is called "Implementation and Analysis of Linked Lists". After a paragraph describing some data structures, we are presented with a listing of the C header file, list.h, followed by a lengthier description of each of the functions described in the previous section. Finally, we are presented with a code listing of list.c.

And this is where I started having a problem.

First, I feel the author plunges much too quickly into implementation before providing a proper context. Let's assume that the reader knows nothing about linked lists (that's why, after all, they bought the book). Before describing a specific implementation, shouldn't the reader be clued in on the basic operations (independent of the implementation language) performed on linked lists: adding a node, deleting a node, etc.? While a little of this is given early on, the author seems in a rush to move on to the implementation.

And when we have the implementation described, the information is spread across (at least) three locations. For example, the function list_ins_next is first introduced in the "Interface" section, its prototype is shown in the list.h file, a more detailed description is provided in the "Implementation" section, and finally the actual code is presented in the list.c code listing. This forces the reader to jump around quite a bit to get all the info about each function.

How Much Should the Reader Know? How much should the writer assume you know about linked lists (or any of the other algorithms described in this book)? If the reader already understands the basic concepts of linked lists, and if they're already a C programmer, they most likely wouldn't need this book. So let's assume the reader is starting at ground zero (or its general vicinity) when it comes to linked lists.

If that's the case, then I would expect the writer to present a relatively "bare bones" implementation, at least for basic algorithms like lists.

Instead, what is presented is an almost object-oriented implementation with init and destroy functions, function pointers, and other details that may provide a clean implementation but may be an impediment to the authors primary duty: teaching the reader the algorithm.

For much the same reasons, I found many of the examples out of sync with what was being taught. While virtual memory paging schemes are a lot of fun, they're a hell of a thing to spring on some poor sucker trying to grasp the concept of linked lists.

Finally, I had some problems with the author's prose style. This may be more my preconception of how an O'Reilly book should read. Luckily, you can (and should) make your own decision. O'Reilly has Chapter 13, Numerical Methods, available at their web site.

But Wait While I have problems with this book, I don't mean to imply the book is bad. It's a fair book, I just don't think it's great book. It covers a lot of territory. For me, its main fault is that it fails to explain concepts clearly and basically enough before diving into the code.

On the plus side, I found the figures that illustrate concepts throughout the book to be clear and helpful. The selection of which algorithms to cover is also quite good, as these are all areas that a wide variety of programmers will face at some point in their work.

If you already have a moderate understanding of the algorithms, and want a text that presents a clear and documented implementation of them, then you may want to consider this book.

Pick this book up at Amazon.

Table of Contents:

Preface

1. Preliminaries
   1. Introduction
   2. Pointer Manipulation
   3. Recursion
   4. Analysis of Algorithms
2. Data Structures
   1. Linked Lists
   2. Stacks and Queues
   3. Sets
   4. Hash Tables
   5. Trees
   6. Heaps and Priority Queues
   7. Graphs
3. Algorithms
   1. Sorting and Searching
   2. Numerical Methods
   3. Data Compression
   4. Data Encryption
   5. Graph Algorithms
   6. Geometric Algorithms

The return of Doc Technical is marked by his review of the upcoming O'Reilly book Mastering Algorithms with C. Click below if you wish to learn more about this Kyle Loudon book. Mastering Algorithms with C, 1st Ed. August 1999 author Kyle Loudon pages 560 publisher O'Reilly and Associates, ISBN= rating 6.5/10 reviewer Doc Technical ISBN summary A flawed but wide-ranging book for intermediate toexpert programmers. [Reviewers Disclaimer: This review is based on a pre-publication copy of the book, so some changes may have occurred in the published copy. Most of my comments relate to structure and content, and I expect they'll remain valid.]

There are many books on programming algorithms, and quite a few of them use C for their examples, but even so, I was looking forward to this new book from O'Reilly.

Most of the existing algorithm books were designed as college text books. While they have their place, there is certainly room for a book that approaches the subject matter in the informal, clear writing style and practical focus that is O'Reilly's trademark. Unfortunately, for me at least, Mastering Algorithms in C was not that book.

My Problem with Algorithms One of O'Reilly's strengths has always been their attention to the structure of their books. O'Reilly books are usually well designed, with logical and reader-friendly layouts. But Mastering Algorithms with C has a layout that I found somewhat vexing.

The chapter on linked lists serves to illustrate. An introductory section describes three kinds of lists, then briefly describes several applications for them (mailing lists, memory management, scrolled lists in GUIs, etc.). This is followed by a brief section describing the basic concepts of linked lists.

>From there the chapter moves directly to an implementation of linked lists, starting with a section called "Interface for Linked Lists". This section enumerates each function in a linked list library. For each function we are given its function prototype, followed by its return value, a brief description of the function's purpose, and finally, its algorithmic complexity in O-notation.

The next section is called "Implementation and Analysis of Linked Lists". After a paragraph describing some data structures, we are presented with a listing of the C header file, list.h, followed by a lengthier description of each of the functions described in the previous section. Finally, we are presented with a code listing of list.c.

And this is where I started having a problem.

First, I feel the author plunges much too quickly into implementation before providing a proper context. Let's assume that the reader knows nothing about linked lists (that's why, after all, they bought the book). Before describing a specific implementation, shouldn't the reader be clued in on the basic operations (independent of the implementation language) performed on linked lists: adding a node, deleting a node, etc.? While a little of this is given early on, the author seems in a rush to move on to the implementation.

And when we have the implementation described, the information is spread across (at least) three locations. For example, the function list_ins_next is first introduced in the "Interface" section, its prototype is shown in the list.h file, a more detailed description is provided in the "Implementation" section, and finally the actual code is presented in the list.c code listing. This forces the reader to jump around quite a bit to get all the info about each function.

How Much Should the Reader Know? How much should the writer assume you know about linked lists (or any of the other algorithms described in this book)? If the reader already understands the basic concepts of linked lists, and if they're already a C programmer, they most likely wouldn't need this book. So let's assume the reader is starting at ground zero (or its general vicinity) when it comes to linked lists.

If that's the case, then I would expect the writer to present a relatively "bare bones" implementation, at least for basic algorithms like lists.

Instead, what is presented is an almost object-oriented implementation with init and destroy functions, function pointers, and other details that may provide a clean implementation but may be an impediment to the authors primary duty: teaching the reader the algorithm.

For much the same reasons, I found many of the examples out of sync with what was being taught. While virtual memory paging schemes are a lot of fun, they're a hell of a thing to spring on some poor sucker trying to grasp the concept of linked lists.

Finally, I had some problems with the author's prose style. This may be more my preconception of how an O'Reilly book should read. Luckily, you can (and should) make your own decision. O'Reilly has Chapter 13, Numerical Methods, available at their web site.

But Wait While I have problems with this book, I don't mean to imply the book is bad. It's a fair book, I just don't think it's great book. It covers a lot of territory. For me, its main fault is that it fails to explain concepts clearly and basically enough before diving into the code.

On the plus side, I found the figures that illustrate concepts throughout the book to be clear and helpful. The selection of which algorithms to cover is also quite good, as these are all areas that a wide variety of programmers will face at some point in their work.

If you already have a moderate understanding of the algorithms, and want a text that presents a clear and documented implementation of them, then you may want to consider this book.

Pick this book up at Amazon.

Table of Contents:

Preface

1. Preliminaries
   1. Introduction
   2. Pointer Manipulation
   3. Recursion
   4. Analysis of Algorithms
2. Data Structures
   1. Linked Lists
   2. Stacks and Queues
   3. Sets
   4. Hash Tables
   5. Trees
   6. Heaps and Priority Queues
   7. Graphs
3. Algorithms
   1. Sorting and Searching
   2. Numerical Methods
   3. Data Compression
   4. Data Encryption
   5. Graph Algorithms
   6. Geometric Algorithms

Monday we requested questions for Tim O'Reilly, of O'Reilly & Associates. Tim obviously put a lot of time into coming up with thoughtful answers, which we have published below. We've also invited Tim to join in the discussion here if he can find time, but please don't get upset if he can't. "Busy" is an understatement for this man!

Dominican asks:
How often are books revised? Open to the author?

Tim responds:
In our early days, we revised our books constantly. For example, I did ten editions of Managing UUCP and Usenet between 1986 and 1991--about one every six months. The book grew in something much like an open source software process, where I was constantly incorporating reader feedback, and rolling it into the next printing. We didn't do a big marketing push about it being a new edition, we just had a change log on the copyright page, much like you do with a piece of software, each time you check it in and out of your source code control system.

Now that we're much larger (and many of our authors no longer work directly for us), it's harder to do that, but we still roll in a lot of small changes each time we go back to print.

The reason why it's harder mainly has to do with the inefficiency of retail distribution. When there are thousands of copies sitting in bookstores waiting to be bought, rolling out a "new edition" is a big deal, since you have to take back and recycle all the old ones. So you have to go through a process of letting the inventory "stored in the channel" thin out. This means that, especially for a very successful book, you can't do updates as often as you otherwise might like. We slipstream in fixes to errors and other small changes, but major changes need to be characterized as a "new edition" with all the attendant hoopla.

There is also the issue you advert to in your question, and that is the availability of the author to do the update. Sometimes an author like David Flanagan has a number of bestselling books, and he updates them in round-robin fashion. Sometimes an author loses interest in a topic, or gets a new job and doesn't have time any more, and we have to find someone else. Sometimes the technology is fairly stable, and so we don't need to do a new edition.

Sometimes we know we need a new edition, but we just get distracted, and don't get around to it as quickly as we should! At least we don't do what a lot of other publishers do, which is issue a "new edition" for marketing reasons only, where the content stays pretty much the same, but it's called a new edition just so they can sell it in freshly to bookstores.

t-money asks:
Fatbrain.com has recently announced that it will offer an electronic publishing service, E-matter. What do you think about offering documents for download for a fee? Is this something that O'Reilly might be undertaking in the future?

Tim responds:
Well, we were part of FatBrain's ematter announcement, and we're going to be working with them. But I have to confess that the part of their project I liked the best wasn't the bit about selling short documents in online-only form, it was the idea of coordinating sale of online and print versions.

I know that there's a lot of talk about putting books up online for free, and we're doing some experiments there, but to be honest, I think that it's really in all of our best interests to "monetize" online information as soon as possible. Money, after all, is just a mutually-agreed ratio of exchange for services. When the price is somewhere between zero and a large number, based on negotiation, the uncertainty often means that the product is not available.

In general, I foresee a large period of experimentation, until someone or other figures out the right way to deliver AND pay for the kinds of things that people want to read online. We've seen it take about five years to develop enough confidence in advertising as a revenue model for the web (starting from our first-ever internet advertising on O'Reilly's prototype GNN portal in early 1993). Similarly, I think that the "pay for content" sites--whether eMatter or ibooks.com, or books24x7, or itknowledge.com--will take some time to shake out. Meanwhile, we're playing with a bunch of these people, and doing some experiments of our own as well.

the_tsi asks:
Not to start a free SQL server war here, but I notice there is a (quite good) book on mSql and MySql, but nothing for PostgreSQL. Are there any plans to cover it in the near future?

Tim responds:
We're looking at this but haven't started any projects yet. We've had a huge number of requests for a book on PostgreSQL, and we're taking them very seriously.

Tet asks:
You've said that the Linux Network Administrator's Guide sold significantly less than would normally be expected as a result of the text of the book being freely available on the net. By what sort of margin? How many copies did it sell, and how many would you have expected to sell under normal circumstances? Would you release another book in a similar manner if the author accepts that they'll make less money from it? Did the book actually make a loss, or just not make as much profit as expected?

Tim responds:
Well, it's always hard to say what something *would* have done if circumstances had been otherwise. But on average, the book sold about a thousand copies a month in a period where Running Linux sold 3-4000 and Linux Device Drivers about 1500. Now the book is badly out of date (though a new edition is in the works), but you'd expect that there are more people doing network admin than there are writing device drivers. (And in fact, reader polls have actually put the NAG at the top of the list of "most useful" of our Linux books.)

Frank Willison, our editor in chief, made the following additional comments about the NAG and its free publication:

"We can demonstrate that we lost money because another publisher (SSC) also published the same material when it became available online. Because the books were identical, word for word (a requirement the author put on anyone else publishing the material), every copy sold of the SSC book was a loss of the sale of one copy of our book.

One interesting side note was that SSC published the book for a lower price than we did. Of course, we had the fixed costs: editing, reviewing, production, design. But those fixed costs didn't make the difference: when you took out the retail markup, the difference in price was equal to the author royalty on the book.

The above may be too much info, and isn't directly related to current Open Source practices, but it still chafes my butt."

If I had to quantify the effect, I'd guess that making a book freely available might cut sales by 30%. But note that this is for O'Reilly--we've got books with a great reputation, which makes people seek them out. And we cover "need to know" technologies where people are already looking for the O'Reilly book on the topic. For J. Random Author out there, open sourcing a book might be a terrible idea, or a great one. An author with some unique material that doesn't fall into an obvious "I already know I need this" category can build a real cult following online, and then turn that into printed book sales to a wider audience. We're hoping to do the same thing in publishing Eric Raymond's The Cathedral and the Bazaar (and other essays) this fall. Most of you guys have probably read them online, but there is a larger population who've probably heard the buzz, and will pick them up in the bookstore. On the other hand, an author who puts a lousy book online will only show this to the world, and sales will be 10% of what they'd been if the reader hadn't been able to see the book first.

Perhaps more compelling is the evidence from the Java world, where sales of the Addison-Wesley books based on the Sun documentation (which is mostly available online) are quite dismal, while our unique standalone books (as those from other publishers) do quite well. More importantly, though, programmers in our focus groups for Java report spending far less overall on books than programmers in other areas, because they say that they get most of the info they need online.

All of this is what tells me we need to tread carefully in this area, since I have to look out for the interests of my employees and my authors as well as my customers. In the end, free books online may look like a great deal, but it won't look so good if it ends up disincetivizing authors from doing work that you guys need.

And frankly, we have conversations all the time that go like this: "I'm making $xxx as a consultant. I'd love to write a book, but it's really not worth my while." At O'Reilly, we try to use authors who really know their stuff. So writing a book is either a labor of love, or it's a competitive situation with all the other things that author could be doing with their time. So money is an issue.

maelstrom asks:
(two out of three submitted) What books would you recommend a budding writer should read and study? and Do you read every book you publish?

Tim responds:
Books about writing that I like are Strunk & White (The Elements of Style) and William Zinsser's On Writing Well. But really, read any books that you like. Reading good technical books, and thinking about what works about them for you, is always great. We learn far more by osmosis than by formal instruction. So read, and then write.

Going back to the recurrent questions about free documentation--a great way to learn to write is to do it. Contribute your efforts to one of the many open source software projects as a documentation writer, get criticism from the user community, and learn by doing.

I would say that the ability to organize your thoughts clearly is the most important skill for a technical writer. Putting things in the right order, and not leaving anything out (or rather, not leaving out anything important, but everything unimportant), is far more important than trying to write deathless prose. The best writing is invisible, not showy. My favorite quote about writing (which came from a magazine interview that I read many years ago) was from Edwin Schlossberg: "The skill of writing is to create a context in which other people can think."

As to your second question: alas, I no longer have time to read everything we publish. We have a number of senior editors whose work I trust completely -- I never read their stuff unless I'm trying to use it myself. For new or more junior editors, I generally do a bit of a "sample" of each book somewhere during the development process. If I like it, I say so, and don't feel I have to look at it again. If I don't like it, I may make terrible trouble, as some of my editors and authors can attest.

howardjp asks:
One of the biggest compaints aong critics of the BSD operating systems is the lack of available books. Since O'Reilly is the leader in Open Source documentation, you are well positioned to enter the BSD market. With that in mind, why hasn't O'Reilly published any BSD books in recent memory?

Tim responds:
Every once in a while we make a stupid editorial decision, as, for instance, when we turned down Greg Lehey's proposed BSD book (now published by Walnut Creek CDROM). This was based on the fact that the BSD documentation, which we'd co-published with Usenix, had done really poorly, and the relative sales of our original BSD UNIX in a Nutshell relative to our System V/Solaris one. That was many years ago now, and BSD has emerged from the shadows of the AT&T lawsuit, and become a real force in the open source community. So I definitely think that there are some books that we might want to do there. Proposals are welcome.

That being said, so many of our books cover BSD (just like they cover Linux, even if they don't say Linux on the cover). After all, BSD is one of the great mothers of the open source movement. What is Bind, what is sendmail, what is vi, what is a lot of the TCP/IP utility suite but the gift of BSD...it's so much part of the air we all breathe that it doesn't always stand out as topic that gets the separate name on it.

chromatic asks:
Would you ever consider making previous editions of certain books free for download when supplanted by newer editions?

For example, when Larry Wall finally gets around to writing the 3rd edition of the Camel (probably about the same time as Perl 6), would you consider making the second edition available in electronic format?

I realize this has the possibility of forking documentation, but it's hard to find anyone more qualified than Larry, Randal, and Tom, for example. It would only work for certain books.

Tim responds:
The previous edition of CGI Programming for the WWW is available online now, while we work on a new edition, as is MH & xmh and Open Sources. You can read these at http://www.oreilly.com/openbooks/. We'd like to put more of our out of print books online, but it's a matter of man hours. Our Web team is organizing a new effort around this now, so look for more books to appear on this page.

And in fact, an awful lot of Programming Perl *is* available for free online, as part of the Perl man page or other perl documentation. It's not available in exactly the same form, but it's available. That's one of the big questions for online documentation: does the online version always look like the print version.

But this is a good question, and it's one we have certainly something we can think about. Might be another interesting experiment in understanding the ecology of online publishing.

Crutcher asks:
Not sure how to phrase this, but, well, what is the status of O'Reilley and marketing books to schools and colleges for use as textbooks. Our textbooks suck, and if there textbook versions of ya'lls books it would rock.

Tim responds:
We actually do quite a bit of marketing to schools and colleges, and they are used as textbooks in a number of places. If you know of a professor who ought to be adopting an O'Reilly book, please send mail to our manager of college and library sales, Kerri Bonasch, at kerri@oreilly.com. We also have a Web site to support this effort at http://www.oreilly.com/sales/edu/.

Are there any specific things that you see as obstacles to use of the books as textbooks? What topics would you especially like to see as textbooks?

zilym asks:
Are there any plans to improve the binding on your future books? Many of us use O'Reilly books to death and the binding is the first to go. I know I certainly wouldn't mind pay slightly more for a stronger version of some of the most heavily used titles.

Tim responds:
Hmmm. We use a special high-cost binding, which allows the books to lay flat. It's quite a bit more expensive than the normal perfect binding used by most publishers, and we think it's worth it. I have heard lots of compliments on how great this binding is. I haven't heard complaints about it breaking down--at least not without use that would break down a normal perfect-bound book as well. I don't know of any way to make it more durable.

Maybe hardcover? It would be great to have a slashdot poll on how many people share your problem and would like to see O'Reilly books in hardcover. (One caveat: We tried an experiment once (for our Phigs Programming Manuals--real behemoths) to offer books in both hardcover and softcover, so people could choose. Despite polls that said people would pay more for a more durable hardcover, everyone bought the softcover to save the difference in price.) So, if there is a poll, how much would you pay for a more durable book?

jzawodn asks:
Given some of the recent discussion surrounding the Linux Documentation Project (LDP), I began to wonder about its long-term direction and viability.

I "grew up" with Linux by reading *many* of the HOWTOs and other documents that were part of the LDP. In many ways, I'd have been lost without the LDP. But with the growth of Linux mind-share and increased demand for texts that help newcomers get acquainted with the various aspects of running their own Linux systems, there seems to have been a stagnation in much of the free documentation. I can't help but to wonder if many of the folks who would be working on LDP-type material have opted to write books for publishers instead.

Where do you see free documentation projects like the LDP going? What advice can you offer to the LDP and those who write documents for inclusion in the project? Might we see electronic versions of O'Reilly books (or parts of them) included in free documentation projects?

Tim responds:
I don't think that the slowdown of the LDP is because of authors deserting it to write commercial books. In fact, I think you're going to see a reinvigoration of free documentation efforts, as publishers try to contribute to these projects. I think that the right answer is for those who are writing books to figure out some useful subset of their work that will be distributed online as part of the free documentation, and for there to be some added value only available in books. I think that this has worked pretty well for the core perl documentation, where an update to the camel and an update to the online docs are really seen as part of the same project.

When O'Reilly is directly involved in an Open Source project, this is fairly typical of what we do. For example, O'Reilly was one of the original drivers behind the development of the docbook DTD, which is now used by the LDP. (We started the Davenport Group, which developed Docbook, back in the late 80's.)

We're releasing a book about Docbook, by Norm Walsh and Len Muellner, called DocBook: the Definitive Guide." It will be out in October. Norm and Len's book will be also available for free online through the Oasis web site as the official documentation of the DocBook DTD. This is our contribution to users of DocBook; without our signing and creating this book, good documentation for DocBook wouldn't exist. (This is in addition to our historical support of the creation of DocBook.)

Our goal here, though, is evangelical. We want more people to use docbook (and xml in general), and we think that making the documentation free will help that goal.

CmdrTaco asks (on behalf of a friend):
I understand from a very reliable source that O'Reilly is moving their website from a single Sun and an inside developed webserver to an NT cluster and some barely functioning proprietary software. Their bread and butter has been Unix. They have been taking a more and more vocal position within the OSS community. Why are they switching to NT?

Tim responds:
Well, your very reliable source has only part of the story right, and that's because it's a long and involved story. It started about 18 months ago, when the people on our web team wanted to replace what had become a fairly obsolete setup whose original developers no longer work for the company.

This system--which was about five years old--involves a lot of convoluted perl scripts that take data in a pseudo-sgml format, and generate a bunch of internal documents (marketing reports, sales sheets, copy for catalogs etc) as well as web pages. We wanted to do something more up to date, and didn't have internal resources to devote to a complete rework.

So we went out to a number of web design firms for bids. The winning firm does work on both NT and UNIX, but they showed us all kinds of nifty things that they said they had already developed on NT that we could use. These were tools for surveys, content management, etc. There was also stuff around integration with the spreadsheets and databases and reports used by our financial and customer service people. To recreate these tools on their UNIX side would cost several hundred thousand dollars.

So I said: "We can either walk the talk, or talk the walk. I don't care which, as long as what we do and what we say line up. If you can do it better and cheaper on NT, go ahead and do it, and I'll go out there and tell the world why the NT solution was better."

I was prepared to have to tell a story about interoperability--after all, despite all our efforts to champion open source, we realize that our customers use many, many different technologies, and we try to use them all ourselves as well. We were looking at doing some things on NT--the stuff our vendor said they already had working--while incorporating other elements on UNIX, Mac, Linux, and Pick (yes, we run a Pick system too!). The whole thing was going to be a demonstration of ways that you can choose from and integrate tools from many different platforms.

Instead, I have to tell the story that is so familiar to Slashdot readers, of promises of easy-to-use tools that, unfortunately, don't work as advertised. As your source suggests, the NT parts of the system haven't been delivered on time or on budget, and what we've seen doesn't appear to work, and we're considering scrapping that project and going back to the safe choice. To put a new spin on an old saw: No one ever got fired for using open source.

I say that tongue-in-cheek of course, because unlike a lot of open source partisans, I don't think that all good things come from the open source community. We like to bash Microsoft with the idea that "no matter how big you are, all the smart people don't work for you" but it's just as true that they don't all work for the open source community either. There are great ideas coming from companies like Sun and Microsoft, and (most of) the people who work there are just like us. They care about doing a good job. They want to solve interesting problems and make the world a better place. And sometimes they do.

I consider it my job to give them a fair shake at convincing me, and if they do, to give you a fair shake at learning what they've done right as well as what they've done wrong. I'll keep you posted.

Monday we requested questions for Tim O'Reilly, of O'Reilly & Associates. Tim obviously put a lot of time into coming up with thoughtful answers, which we have published below. We've also invited Tim to join in the discussion here if he can find time, but please don't get upset if he can't. "Busy" is an understatement for this man!

Dominican asks:
How often are books revised? Open to the author?

Tim responds:
In our early days, we revised our books constantly. For example, I did ten editions of Managing UUCP and Usenet between 1986 and 1991--about one every six months. The book grew in something much like an open source software process, where I was constantly incorporating reader feedback, and rolling it into the next printing. We didn't do a big marketing push about it being a new edition, we just had a change log on the copyright page, much like you do with a piece of software, each time you check it in and out of your source code control system.

Now that we're much larger (and many of our authors no longer work directly for us), it's harder to do that, but we still roll in a lot of small changes each time we go back to print.

The reason why it's harder mainly has to do with the inefficiency of retail distribution. When there are thousands of copies sitting in bookstores waiting to be bought, rolling out a "new edition" is a big deal, since you have to take back and recycle all the old ones. So you have to go through a process of letting the inventory "stored in the channel" thin out. This means that, especially for a very successful book, you can't do updates as often as you otherwise might like. We slipstream in fixes to errors and other small changes, but major changes need to be characterized as a "new edition" with all the attendant hoopla.

There is also the issue you advert to in your question, and that is the availability of the author to do the update. Sometimes an author like David Flanagan has a number of bestselling books, and he updates them in round-robin fashion. Sometimes an author loses interest in a topic, or gets a new job and doesn't have time any more, and we have to find someone else. Sometimes the technology is fairly stable, and so we don't need to do a new edition.

Sometimes we know we need a new edition, but we just get distracted, and don't get around to it as quickly as we should! At least we don't do what a lot of other publishers do, which is issue a "new edition" for marketing reasons only, where the content stays pretty much the same, but it's called a new edition just so they can sell it in freshly to bookstores.

t-money asks:
Fatbrain.com has recently announced that it will offer an electronic publishing service, E-matter. What do you think about offering documents for download for a fee? Is this something that O'Reilly might be undertaking in the future?

Tim responds:
Well, we were part of FatBrain's ematter announcement, and we're going to be working with them. But I have to confess that the part of their project I liked the best wasn't the bit about selling short documents in online-only form, it was the idea of coordinating sale of online and print versions.

I know that there's a lot of talk about putting books up online for free, and we're doing some experiments there, but to be honest, I think that it's really in all of our best interests to "monetize" online information as soon as possible. Money, after all, is just a mutually-agreed ratio of exchange for services. When the price is somewhere between zero and a large number, based on negotiation, the uncertainty often means that the product is not available.

In general, I foresee a large period of experimentation, until someone or other figures out the right way to deliver AND pay for the kinds of things that people want to read online. We've seen it take about five years to develop enough confidence in advertising as a revenue model for the web (starting from our first-ever internet advertising on O'Reilly's prototype GNN portal in early 1993). Similarly, I think that the "pay for content" sites--whether eMatter or ibooks.com, or books24x7, or itknowledge.com--will take some time to shake out. Meanwhile, we're playing with a bunch of these people, and doing some experiments of our own as well.

the_tsi asks:
Not to start a free SQL server war here, but I notice there is a (quite good) book on mSql and MySql, but nothing for PostgreSQL. Are there any plans to cover it in the near future?

Tim responds:
We're looking at this but haven't started any projects yet. We've had a huge number of requests for a book on PostgreSQL, and we're taking them very seriously.

Tet asks:
You've said that the Linux Network Administrator's Guide sold significantly less than would normally be expected as a result of the text of the book being freely available on the net. By what sort of margin? How many copies did it sell, and how many would you have expected to sell under normal circumstances? Would you release another book in a similar manner if the author accepts that they'll make less money from it? Did the book actually make a loss, or just not make as much profit as expected?

Tim responds:
Well, it's always hard to say what something *would* have done if circumstances had been otherwise. But on average, the book sold about a thousand copies a month in a period where Running Linux sold 3-4000 and Linux Device Drivers about 1500. Now the book is badly out of date (though a new edition is in the works), but you'd expect that there are more people doing network admin than there are writing device drivers. (And in fact, reader polls have actually put the NAG at the top of the list of "most useful" of our Linux books.)

Frank Willison, our editor in chief, made the following additional comments about the NAG and its free publication:

"We can demonstrate that we lost money because another publisher (SSC) also published the same material when it became available online. Because the books were identical, word for word (a requirement the author put on anyone else publishing the material), every copy sold of the SSC book was a loss of the sale of one copy of our book.

One interesting side note was that SSC published the book for a lower price than we did. Of course, we had the fixed costs: editing, reviewing, production, design. But those fixed costs didn't make the difference: when you took out the retail markup, the difference in price was equal to the author royalty on the book.

The above may be too much info, and isn't directly related to current Open Source practices, but it still chafes my butt."

If I had to quantify the effect, I'd guess that making a book freely available might cut sales by 30%. But note that this is for O'Reilly--we've got books with a great reputation, which makes people seek them out. And we cover "need to know" technologies where people are already looking for the O'Reilly book on the topic. For J. Random Author out there, open sourcing a book might be a terrible idea, or a great one. An author with some unique material that doesn't fall into an obvious "I already know I need this" category can build a real cult following online, and then turn that into printed book sales to a wider audience. We're hoping to do the same thing in publishing Eric Raymond's The Cathedral and the Bazaar (and other essays) this fall. Most of you guys have probably read them online, but there is a larger population who've probably heard the buzz, and will pick them up in the bookstore. On the other hand, an author who puts a lousy book online will only show this to the world, and sales will be 10% of what they'd been if the reader hadn't been able to see the book first.

Perhaps more compelling is the evidence from the Java world, where sales of the Addison-Wesley books based on the Sun documentation (which is mostly available online) are quite dismal, while our unique standalone books (as those from other publishers) do quite well. More importantly, though, programmers in our focus groups for Java report spending far less overall on books than programmers in other areas, because they say that they get most of the info they need online.

All of this is what tells me we need to tread carefully in this area, since I have to look out for the interests of my employees and my authors as well as my customers. In the end, free books online may look like a great deal, but it won't look so good if it ends up disincetivizing authors from doing work that you guys need.

And frankly, we have conversations all the time that go like this: "I'm making $xxx as a consultant. I'd love to write a book, but it's really not worth my while." At O'Reilly, we try to use authors who really know their stuff. So writing a book is either a labor of love, or it's a competitive situation with all the other things that author could be doing with their time. So money is an issue.

maelstrom asks:
(two out of three submitted) What books would you recommend a budding writer should read and study? and Do you read every book you publish?

Tim responds:
Books about writing that I like are Strunk & White (The Elements of Style) and William Zinsser's On Writing Well. But really, read any books that you like. Reading good technical books, and thinking about what works about them for you, is always great. We learn far more by osmosis than by formal instruction. So read, and then write.

Going back to the recurrent questions about free documentation--a great way to learn to write is to do it. Contribute your efforts to one of the many open source software projects as a documentation writer, get criticism from the user community, and learn by doing.

I would say that the ability to organize your thoughts clearly is the most important skill for a technical writer. Putting things in the right order, and not leaving anything out (or rather, not leaving out anything important, but everything unimportant), is far more important than trying to write deathless prose. The best writing is invisible, not showy. My favorite quote about writing (which came from a magazine interview that I read many years ago) was from Edwin Schlossberg: "The skill of writing is to create a context in which other people can think."

As to your second question: alas, I no longer have time to read everything we publish. We have a number of senior editors whose work I trust completely -- I never read their stuff unless I'm trying to use it myself. For new or more junior editors, I generally do a bit of a "sample" of each book somewhere during the development process. If I like it, I say so, and don't feel I have to look at it again. If I don't like it, I may make terrible trouble, as some of my editors and authors can attest.

howardjp asks:
One of the biggest compaints aong critics of the BSD operating systems is the lack of available books. Since O'Reilly is the leader in Open Source documentation, you are well positioned to enter the BSD market. With that in mind, why hasn't O'Reilly published any BSD books in recent memory?

Tim responds:
Every once in a while we make a stupid editorial decision, as, for instance, when we turned down Greg Lehey's proposed BSD book (now published by Walnut Creek CDROM). This was based on the fact that the BSD documentation, which we'd co-published with Usenix, had done really poorly, and the relative sales of our original BSD UNIX in a Nutshell relative to our System V/Solaris one. That was many years ago now, and BSD has emerged from the shadows of the AT&T lawsuit, and become a real force in the open source community. So I definitely think that there are some books that we might want to do there. Proposals are welcome.

That being said, so many of our books cover BSD (just like they cover Linux, even if they don't say Linux on the cover). After all, BSD is one of the great mothers of the open source movement. What is Bind, what is sendmail, what is vi, what is a lot of the TCP/IP utility suite but the gift of BSD...it's so much part of the air we all breathe that it doesn't always stand out as topic that gets the separate name on it.

chromatic asks:
Would you ever consider making previous editions of certain books free for download when supplanted by newer editions?

For example, when Larry Wall finally gets around to writing the 3rd edition of the Camel (probably about the same time as Perl 6), would you consider making the second edition available in electronic format?

I realize this has the possibility of forking documentation, but it's hard to find anyone more qualified than Larry, Randal, and Tom, for example. It would only work for certain books.

Tim responds:
The previous edition of CGI Programming for the WWW is available online now, while we work on a new edition, as is MH & xmh and Open Sources. You can read these at http://www.oreilly.com/openbooks/. We'd like to put more of our out of print books online, but it's a matter of man hours. Our Web team is organizing a new effort around this now, so look for more books to appear on this page.

And in fact, an awful lot of Programming Perl *is* available for free online, as part of the Perl man page or other perl documentation. It's not available in exactly the same form, but it's available. That's one of the big questions for online documentation: does the online version always look like the print version.

But this is a good question, and it's one we have certainly something we can think about. Might be another interesting experiment in understanding the ecology of online publishing.

Crutcher asks:
Not sure how to phrase this, but, well, what is the status of O'Reilley and marketing books to schools and colleges for use as textbooks. Our textbooks suck, and if there textbook versions of ya'lls books it would rock.

Tim responds:
We actually do quite a bit of marketing to schools and colleges, and they are used as textbooks in a number of places. If you know of a professor who ought to be adopting an O'Reilly book, please send mail to our manager of college and library sales, Kerri Bonasch, at kerri@oreilly.com. We also have a Web site to support this effort at http://www.oreilly.com/sales/edu/.

Are there any specific things that you see as obstacles to use of the books as textbooks? What topics would you especially like to see as textbooks?

zilym asks:
Are there any plans to improve the binding on your future books? Many of us use O'Reilly books to death and the binding is the first to go. I know I certainly wouldn't mind pay slightly more for a stronger version of some of the most heavily used titles.

Tim responds:
Hmmm. We use a special high-cost binding, which allows the books to lay flat. It's quite a bit more expensive than the normal perfect binding used by most publishers, and we think it's worth it. I have heard lots of compliments on how great this binding is. I haven't heard complaints about it breaking down--at least not without use that would break down a normal perfect-bound book as well. I don't know of any way to make it more durable.

Maybe hardcover? It would be great to have a slashdot poll on how many people share your problem and would like to see O'Reilly books in hardcover. (One caveat: We tried an experiment once (for our Phigs Programming Manuals--real behemoths) to offer books in both hardcover and softcover, so people could choose. Despite polls that said people would pay more for a more durable hardcover, everyone bought the softcover to save the difference in price.) So, if there is a poll, how much would you pay for a more durable book?

jzawodn asks:
Given some of the recent discussion surrounding the Linux Documentation Project (LDP), I began to wonder about its long-term direction and viability.

I "grew up" with Linux by reading *many* of the HOWTOs and other documents that were part of the LDP. In many ways, I'd have been lost without the LDP. But with the growth of Linux mind-share and increased demand for texts that help newcomers get acquainted with the various aspects of running their own Linux systems, there seems to have been a stagnation in much of the free documentation. I can't help but to wonder if many of the folks who would be working on LDP-type material have opted to write books for publishers instead.

Where do you see free documentation projects like the LDP going? What advice can you offer to the LDP and those who write documents for inclusion in the project? Might we see electronic versions of O'Reilly books (or parts of them) included in free documentation projects?

Tim responds:
I don't think that the slowdown of the LDP is because of authors deserting it to write commercial books. In fact, I think you're going to see a reinvigoration of free documentation efforts, as publishers try to contribute to these projects. I think that the right answer is for those who are writing books to figure out some useful subset of their work that will be distributed online as part of the free documentation, and for there to be some added value only available in books. I think that this has worked pretty well for the core perl documentation, where an update to the camel and an update to the online docs are really seen as part of the same project.

When O'Reilly is directly involved in an Open Source project, this is fairly typical of what we do. For example, O'Reilly was one of the original drivers behind the development of the docbook DTD, which is now used by the LDP. (We started the Davenport Group, which developed Docbook, back in the late 80's.)

We're releasing a book about Docbook, by Norm Walsh and Len Muellner, called DocBook: the Definitive Guide." It will be out in October. Norm and Len's book will be also available for free online through the Oasis web site as the official documentation of the DocBook DTD. This is our contribution to users of DocBook; without our signing and creating this book, good documentation for DocBook wouldn't exist. (This is in addition to our historical support of the creation of DocBook.)

Our goal here, though, is evangelical. We want more people to use docbook (and xml in general), and we think that making the documentation free will help that goal.

CmdrTaco asks (on behalf of a friend):
I understand from a very reliable source that O'Reilly is moving their website from a single Sun and an inside developed webserver to an NT cluster and some barely functioning proprietary software. Their bread and butter has been Unix. They have been taking a more and more vocal position within the OSS community. Why are they switching to NT?

Tim responds:
Well, your very reliable source has only part of the story right, and that's because it's a long and involved story. It started about 18 months ago, when the people on our web team wanted to replace what had become a fairly obsolete setup whose original developers no longer work for the company.

This system--which was about five years old--involves a lot of convoluted perl scripts that take data in a pseudo-sgml format, and generate a bunch of internal documents (marketing reports, sales sheets, copy for catalogs etc) as well as web pages. We wanted to do something more up to date, and didn't have internal resources to devote to a complete rework.

So we went out to a number of web design firms for bids. The winning firm does work on both NT and UNIX, but they showed us all kinds of nifty things that they said they had already developed on NT that we could use. These were tools for surveys, content management, etc. There was also stuff around integration with the spreadsheets and databases and reports used by our financial and customer service people. To recreate these tools on their UNIX side would cost several hundred thousand dollars.

So I said: "We can either walk the talk, or talk the walk. I don't care which, as long as what we do and what we say line up. If you can do it better and cheaper on NT, go ahead and do it, and I'll go out there and tell the world why the NT solution was better."

I was prepared to have to tell a story about interoperability--after all, despite all our efforts to champion open source, we realize that our customers use many, many different technologies, and we try to use them all ourselves as well. We were looking at doing some things on NT--the stuff our vendor said they already had working--while incorporating other elements on UNIX, Mac, Linux, and Pick (yes, we run a Pick system too!). The whole thing was going to be a demonstration of ways that you can choose from and integrate tools from many different platforms.

Instead, I have to tell the story that is so familiar to Slashdot readers, of promises of easy-to-use tools that, unfortunately, don't work as advertised. As your source suggests, the NT parts of the system haven't been delivered on time or on budget, and what we've seen doesn't appear to work, and we're considering scrapping that project and going back to the safe choice. To put a new spin on an old saw: No one ever got fired for using open source.

I say that tongue-in-cheek of course, because unlike a lot of open source partisans, I don't think that all good things come from the open source community. We like to bash Microsoft with the idea that "no matter how big you are, all the smart people don't work for you" but it's just as true that they don't all work for the open source community either. There are great ideas coming from companies like Sun and Microsoft, and (most of) the people who work there are just like us. They care about doing a good job. They want to solve interesting problems and make the world a better place. And sometimes they do.

I consider it my job to give them a fair shake at convincing me, and if they do, to give you a fair shake at learning what they've done right as well as what they've done wrong. I'll keep you posted.

Monday we requested questions for Tim O'Reilly, of O'Reilly & Associates. Tim obviously put a lot of time into coming up with thoughtful answers, which we have published below. We've also invited Tim to join in the discussion here if he can find time, but please don't get upset if he can't. "Busy" is an understatement for this man!

Dominican asks:
How often are books revised? Open to the author?

Tim responds:
In our early days, we revised our books constantly. For example, I did ten editions of Managing UUCP and Usenet between 1986 and 1991--about one every six months. The book grew in something much like an open source software process, where I was constantly incorporating reader feedback, and rolling it into the next printing. We didn't do a big marketing push about it being a new edition, we just had a change log on the copyright page, much like you do with a piece of software, each time you check it in and out of your source code control system.

Now that we're much larger (and many of our authors no longer work directly for us), it's harder to do that, but we still roll in a lot of small changes each time we go back to print.

The reason why it's harder mainly has to do with the inefficiency of retail distribution. When there are thousands of copies sitting in bookstores waiting to be bought, rolling out a "new edition" is a big deal, since you have to take back and recycle all the old ones. So you have to go through a process of letting the inventory "stored in the channel" thin out. This means that, especially for a very successful book, you can't do updates as often as you otherwise might like. We slipstream in fixes to errors and other small changes, but major changes need to be characterized as a "new edition" with all the attendant hoopla.

There is also the issue you advert to in your question, and that is the availability of the author to do the update. Sometimes an author like David Flanagan has a number of bestselling books, and he updates them in round-robin fashion. Sometimes an author loses interest in a topic, or gets a new job and doesn't have time any more, and we have to find someone else. Sometimes the technology is fairly stable, and so we don't need to do a new edition.

Sometimes we know we need a new edition, but we just get distracted, and don't get around to it as quickly as we should! At least we don't do what a lot of other publishers do, which is issue a "new edition" for marketing reasons only, where the content stays pretty much the same, but it's called a new edition just so they can sell it in freshly to bookstores.

t-money asks:
Fatbrain.com has recently announced that it will offer an electronic publishing service, E-matter. What do you think about offering documents for download for a fee? Is this something that O'Reilly might be undertaking in the future?

Tim responds:
Well, we were part of FatBrain's ematter announcement, and we're going to be working with them. But I have to confess that the part of their project I liked the best wasn't the bit about selling short documents in online-only form, it was the idea of coordinating sale of online and print versions.

I know that there's a lot of talk about putting books up online for free, and we're doing some experiments there, but to be honest, I think that it's really in all of our best interests to "monetize" online information as soon as possible. Money, after all, is just a mutually-agreed ratio of exchange for services. When the price is somewhere between zero and a large number, based on negotiation, the uncertainty often means that the product is not available.

In general, I foresee a large period of experimentation, until someone or other figures out the right way to deliver AND pay for the kinds of things that people want to read online. We've seen it take about five years to develop enough confidence in advertising as a revenue model for the web (starting from our first-ever internet advertising on O'Reilly's prototype GNN portal in early 1993). Similarly, I think that the "pay for content" sites--whether eMatter or ibooks.com, or books24x7, or itknowledge.com--will take some time to shake out. Meanwhile, we're playing with a bunch of these people, and doing some experiments of our own as well.

the_tsi asks:
Not to start a free SQL server war here, but I notice there is a (quite good) book on mSql and MySql, but nothing for PostgreSQL. Are there any plans to cover it in the near future?

Tim responds:
We're looking at this but haven't started any projects yet. We've had a huge number of requests for a book on PostgreSQL, and we're taking them very seriously.

Tet asks:
You've said that the Linux Network Administrator's Guide sold significantly less than would normally be expected as a result of the text of the book being freely available on the net. By what sort of margin? How many copies did it sell, and how many would you have expected to sell under normal circumstances? Would you release another book in a similar manner if the author accepts that they'll make less money from it? Did the book actually make a loss, or just not make as much profit as expected?

Tim responds:
Well, it's always hard to say what something *would* have done if circumstances had been otherwise. But on average, the book sold about a thousand copies a month in a period where Running Linux sold 3-4000 and Linux Device Drivers about 1500. Now the book is badly out of date (though a new edition is in the works), but you'd expect that there are more people doing network admin than there are writing device drivers. (And in fact, reader polls have actually put the NAG at the top of the list of "most useful" of our Linux books.)

Frank Willison, our editor in chief, made the following additional comments about the NAG and its free publication:

"We can demonstrate that we lost money because another publisher (SSC) also published the same material when it became available online. Because the books were identical, word for word (a requirement the author put on anyone else publishing the material), every copy sold of the SSC book was a loss of the sale of one copy of our book.

One interesting side note was that SSC published the book for a lower price than we did. Of course, we had the fixed costs: editing, reviewing, production, design. But those fixed costs didn't make the difference: when you took out the retail markup, the difference in price was equal to the author royalty on the book.

The above may be too much info, and isn't directly related to current Open Source practices, but it still chafes my butt."

If I had to quantify the effect, I'd guess that making a book freely available might cut sales by 30%. But note that this is for O'Reilly--we've got books with a great reputation, which makes people seek them out. And we cover "need to know" technologies where people are already looking for the O'Reilly book on the topic. For J. Random Author out there, open sourcing a book might be a terrible idea, or a great one. An author with some unique material that doesn't fall into an obvious "I already know I need this" category can build a real cult following online, and then turn that into printed book sales to a wider audience. We're hoping to do the same thing in publishing Eric Raymond's The Cathedral and the Bazaar (and other essays) this fall. Most of you guys have probably read them online, but there is a larger population who've probably heard the buzz, and will pick them up in the bookstore. On the other hand, an author who puts a lousy book online will only show this to the world, and sales will be 10% of what they'd been if the reader hadn't been able to see the book first.

Perhaps more compelling is the evidence from the Java world, where sales of the Addison-Wesley books based on the Sun documentation (which is mostly available online) are quite dismal, while our unique standalone books (as those from other publishers) do quite well. More importantly, though, programmers in our focus groups for Java report spending far less overall on books than programmers in other areas, because they say that they get most of the info they need online.

All of this is what tells me we need to tread carefully in this area, since I have to look out for the interests of my employees and my authors as well as my customers. In the end, free books online may look like a great deal, but it won't look so good if it ends up disincetivizing authors from doing work that you guys need.

And frankly, we have conversations all the time that go like this: "I'm making $xxx as a consultant. I'd love to write a book, but it's really not worth my while." At O'Reilly, we try to use authors who really know their stuff. So writing a book is either a labor of love, or it's a competitive situation with all the other things that author could be doing with their time. So money is an issue.

maelstrom asks:
(two out of three submitted) What books would you recommend a budding writer should read and study? and Do you read every book you publish?

Tim responds:
Books about writing that I like are Strunk & White (The Elements of Style) and William Zinsser's On Writing Well. But really, read any books that you like. Reading good technical books, and thinking about what works about them for you, is always great. We learn far more by osmosis than by formal instruction. So read, and then write.

Going back to the recurrent questions about free documentation--a great way to learn to write is to do it. Contribute your efforts to one of the many open source software projects as a documentation writer, get criticism from the user community, and learn by doing.

I would say that the ability to organize your thoughts clearly is the most important skill for a technical writer. Putting things in the right order, and not leaving anything out (or rather, not leaving out anything important, but everything unimportant), is far more important than trying to write deathless prose. The best writing is invisible, not showy. My favorite quote about writing (which came from a magazine interview that I read many years ago) was from Edwin Schlossberg: "The skill of writing is to create a context in which other people can think."

As to your second question: alas, I no longer have time to read everything we publish. We have a number of senior editors whose work I trust completely -- I never read their stuff unless I'm trying to use it myself. For new or more junior editors, I generally do a bit of a "sample" of each book somewhere during the development process. If I like it, I say so, and don't feel I have to look at it again. If I don't like it, I may make terrible trouble, as some of my editors and authors can attest.

howardjp asks:
One of the biggest compaints aong critics of the BSD operating systems is the lack of available books. Since O'Reilly is the leader in Open Source documentation, you are well positioned to enter the BSD market. With that in mind, why hasn't O'Reilly published any BSD books in recent memory?

Tim responds:
Every once in a while we make a stupid editorial decision, as, for instance, when we turned down Greg Lehey's proposed BSD book (now published by Walnut Creek CDROM). This was based on the fact that the BSD documentation, which we'd co-published with Usenix, had done really poorly, and the relative sales of our original BSD UNIX in a Nutshell relative to our System V/Solaris one. That was many years ago now, and BSD has emerged from the shadows of the AT&T lawsuit, and become a real force in the open source community. So I definitely think that there are some books that we might want to do there. Proposals are welcome.

That being said, so many of our books cover BSD (just like they cover Linux, even if they don't say Linux on the cover). After all, BSD is one of the great mothers of the open source movement. What is Bind, what is sendmail, what is vi, what is a lot of the TCP/IP utility suite but the gift of BSD...it's so much part of the air we all breathe that it doesn't always stand out as topic that gets the separate name on it.

chromatic asks:
Would you ever consider making previous editions of certain books free for download when supplanted by newer editions?

For example, when Larry Wall finally gets around to writing the 3rd edition of the Camel (probably about the same time as Perl 6), would you consider making the second edition available in electronic format?

I realize this has the possibility of forking documentation, but it's hard to find anyone more qualified than Larry, Randal, and Tom, for example. It would only work for certain books.

Tim responds:
The previous edition of CGI Programming for the WWW is available online now, while we work on a new edition, as is MH & xmh and Open Sources. You can read these at http://www.oreilly.com/openbooks/. We'd like to put more of our out of print books online, but it's a matter of man hours. Our Web team is organizing a new effort around this now, so look for more books to appear on this page.

And in fact, an awful lot of Programming Perl *is* available for free online, as part of the Perl man page or other perl documentation. It's not available in exactly the same form, but it's available. That's one of the big questions for online documentation: does the online version always look like the print version.

But this is a good question, and it's one we have certainly something we can think about. Might be another interesting experiment in understanding the ecology of online publishing.

Crutcher asks:
Not sure how to phrase this, but, well, what is the status of O'Reilley and marketing books to schools and colleges for use as textbooks. Our textbooks suck, and if there textbook versions of ya'lls books it would rock.

Tim responds:
We actually do quite a bit of marketing to schools and colleges, and they are used as textbooks in a number of places. If you know of a professor who ought to be adopting an O'Reilly book, please send mail to our manager of college and library sales, Kerri Bonasch, at kerri@oreilly.com. We also have a Web site to support this effort at http://www.oreilly.com/sales/edu/.

Are there any specific things that you see as obstacles to use of the books as textbooks? What topics would you especially like to see as textbooks?

zilym asks:
Are there any plans to improve the binding on your future books? Many of us use O'Reilly books to death and the binding is the first to go. I know I certainly wouldn't mind pay slightly more for a stronger version of some of the most heavily used titles.

Tim responds:
Hmmm. We use a special high-cost binding, which allows the books to lay flat. It's quite a bit more expensive than the normal perfect binding used by most publishers, and we think it's worth it. I have heard lots of compliments on how great this binding is. I haven't heard complaints about it breaking down--at least not without use that would break down a normal perfect-bound book as well. I don't know of any way to make it more durable.

Maybe hardcover? It would be great to have a slashdot poll on how many people share your problem and would like to see O'Reilly books in hardcover. (One caveat: We tried an experiment once (for our Phigs Programming Manuals--real behemoths) to offer books in both hardcover and softcover, so people could choose. Despite polls that said people would pay more for a more durable hardcover, everyone bought the softcover to save the difference in price.) So, if there is a poll, how much would you pay for a more durable book?

jzawodn asks:
Given some of the recent discussion surrounding the Linux Documentation Project (LDP), I began to wonder about its long-term direction and viability.

I "grew up" with Linux by reading *many* of the HOWTOs and other documents that were part of the LDP. In many ways, I'd have been lost without the LDP. But with the growth of Linux mind-share and increased demand for texts that help newcomers get acquainted with the various aspects of running their own Linux systems, there seems to have been a stagnation in much of the free documentation. I can't help but to wonder if many of the folks who would be working on LDP-type material have opted to write books for publishers instead.

Where do you see free documentation projects like the LDP going? What advice can you offer to the LDP and those who write documents for inclusion in the project? Might we see electronic versions of O'Reilly books (or parts of them) included in free documentation projects?

Tim responds:
I don't think that the slowdown of the LDP is because of authors deserting it to write commercial books. In fact, I think you're going to see a reinvigoration of free documentation efforts, as publishers try to contribute to these projects. I think that the right answer is for those who are writing books to figure out some useful subset of their work that will be distributed online as part of the free documentation, and for there to be some added value only available in books. I think that this has worked pretty well for the core perl documentation, where an update to the camel and an update to the online docs are really seen as part of the same project.

When O'Reilly is directly involved in an Open Source project, this is fairly typical of what we do. For example, O'Reilly was one of the original drivers behind the development of the docbook DTD, which is now used by the LDP. (We started the Davenport Group, which developed Docbook, back in the late 80's.)

We're releasing a book about Docbook, by Norm Walsh and Len Muellner, called DocBook: the Definitive Guide." It will be out in October. Norm and Len's book will be also available for free online through the Oasis web site as the official documentation of the DocBook DTD. This is our contribution to users of DocBook; without our signing and creating this book, good documentation for DocBook wouldn't exist. (This is in addition to our historical support of the creation of DocBook.)

Our goal here, though, is evangelical. We want more people to use docbook (and xml in general), and we think that making the documentation free will help that goal.

CmdrTaco asks (on behalf of a friend):
I understand from a very reliable source that O'Reilly is moving their website from a single Sun and an inside developed webserver to an NT cluster and some barely functioning proprietary software. Their bread and butter has been Unix. They have been taking a more and more vocal position within the OSS community. Why are they switching to NT?

Tim responds:
Well, your very reliable source has only part of the story right, and that's because it's a long and involved story. It started about 18 months ago, when the people on our web team wanted to replace what had become a fairly obsolete setup whose original developers no longer work for the company.

This system--which was about five years old--involves a lot of convoluted perl scripts that take data in a pseudo-sgml format, and generate a bunch of internal documents (marketing reports, sales sheets, copy for catalogs etc) as well as web pages. We wanted to do something more up to date, and didn't have internal resources to devote to a complete rework.

So we went out to a number of web design firms for bids. The winning firm does work on both NT and UNIX, but they showed us all kinds of nifty things that they said they had already developed on NT that we could use. These were tools for surveys, content management, etc. There was also stuff around integration with the spreadsheets and databases and reports used by our financial and customer service people. To recreate these tools on their UNIX side would cost several hundred thousand dollars.

So I said: "We can either walk the talk, or talk the walk. I don't care which, as long as what we do and what we say line up. If you can do it better and cheaper on NT, go ahead and do it, and I'll go out there and tell the world why the NT solution was better."

I was prepared to have to tell a story about interoperability--after all, despite all our efforts to champion open source, we realize that our customers use many, many different technologies, and we try to use them all ourselves as well. We were looking at doing some things on NT--the stuff our vendor said they already had working--while incorporating other elements on UNIX, Mac, Linux, and Pick (yes, we run a Pick system too!). The whole thing was going to be a demonstration of ways that you can choose from and integrate tools from many different platforms.

Instead, I have to tell the story that is so familiar to Slashdot readers, of promises of easy-to-use tools that, unfortunately, don't work as advertised. As your source suggests, the NT parts of the system haven't been delivered on time or on budget, and what we've seen doesn't appear to work, and we're considering scrapping that project and going back to the safe choice. To put a new spin on an old saw: No one ever got fired for using open source.

I say that tongue-in-cheek of course, because unlike a lot of open source partisans, I don't think that all good things come from the open source community. We like to bash Microsoft with the idea that "no matter how big you are, all the smart people don't work for you" but it's just as true that they don't all work for the open source community either. There are great ideas coming from companies like Sun and Microsoft, and (most of) the people who work there are just like us. They care about doing a good job. They want to solve interesting problems and make the world a better place. And sometimes they do.

I consider it my job to give them a fair shake at convincing me, and if they do, to give you a fair shake at learning what they've done right as well as what they've done wrong. I'll keep you posted.

Monday we requested questions for Tim O'Reilly, of O'Reilly & Associates. Tim obviously put a lot of time into coming up with thoughtful answers, which we have published below. We've also invited Tim to join in the discussion here if he can find time, but please don't get upset if he can't. "Busy" is an understatement for this man!

Dominican asks:
How often are books revised? Open to the author?

Tim responds:
In our early days, we revised our books constantly. For example, I did ten editions of Managing UUCP and Usenet between 1986 and 1991--about one every six months. The book grew in something much like an open source software process, where I was constantly incorporating reader feedback, and rolling it into the next printing. We didn't do a big marketing push about it being a new edition, we just had a change log on the copyright page, much like you do with a piece of software, each time you check it in and out of your source code control system.

Now that we're much larger (and many of our authors no longer work directly for us), it's harder to do that, but we still roll in a lot of small changes each time we go back to print.

The reason why it's harder mainly has to do with the inefficiency of retail distribution. When there are thousands of copies sitting in bookstores waiting to be bought, rolling out a "new edition" is a big deal, since you have to take back and recycle all the old ones. So you have to go through a process of letting the inventory "stored in the channel" thin out. This means that, especially for a very successful book, you can't do updates as often as you otherwise might like. We slipstream in fixes to errors and other small changes, but major changes need to be characterized as a "new edition" with all the attendant hoopla.

There is also the issue you advert to in your question, and that is the availability of the author to do the update. Sometimes an author like David Flanagan has a number of bestselling books, and he updates them in round-robin fashion. Sometimes an author loses interest in a topic, or gets a new job and doesn't have time any more, and we have to find someone else. Sometimes the technology is fairly stable, and so we don't need to do a new edition.

Sometimes we know we need a new edition, but we just get distracted, and don't get around to it as quickly as we should! At least we don't do what a lot of other publishers do, which is issue a "new edition" for marketing reasons only, where the content stays pretty much the same, but it's called a new edition just so they can sell it in freshly to bookstores.

t-money asks:
Fatbrain.com has recently announced that it will offer an electronic publishing service, E-matter. What do you think about offering documents for download for a fee? Is this something that O'Reilly might be undertaking in the future?

Tim responds:
Well, we were part of FatBrain's ematter announcement, and we're going to be working with them. But I have to confess that the part of their project I liked the best wasn't the bit about selling short documents in online-only form, it was the idea of coordinating sale of online and print versions.

I know that there's a lot of talk about putting books up online for free, and we're doing some experiments there, but to be honest, I think that it's really in all of our best interests to "monetize" online information as soon as possible. Money, after all, is just a mutually-agreed ratio of exchange for services. When the price is somewhere between zero and a large number, based on negotiation, the uncertainty often means that the product is not available.

In general, I foresee a large period of experimentation, until someone or other figures out the right way to deliver AND pay for the kinds of things that people want to read online. We've seen it take about five years to develop enough confidence in advertising as a revenue model for the web (starting from our first-ever internet advertising on O'Reilly's prototype GNN portal in early 1993). Similarly, I think that the "pay for content" sites--whether eMatter or ibooks.com, or books24x7, or itknowledge.com--will take some time to shake out. Meanwhile, we're playing with a bunch of these people, and doing some experiments of our own as well.

the_tsi asks:
Not to start a free SQL server war here, but I notice there is a (quite good) book on mSql and MySql, but nothing for PostgreSQL. Are there any plans to cover it in the near future?

Tim responds:
We're looking at this but haven't started any projects yet. We've had a huge number of requests for a book on PostgreSQL, and we're taking them very seriously.

Tet asks:
You've said that the Linux Network Administrator's Guide sold significantly less than would normally be expected as a result of the text of the book being freely available on the net. By what sort of margin? How many copies did it sell, and how many would you have expected to sell under normal circumstances? Would you release another book in a similar manner if the author accepts that they'll make less money from it? Did the book actually make a loss, or just not make as much profit as expected?

Tim responds:
Well, it's always hard to say what something *would* have done if circumstances had been otherwise. But on average, the book sold about a thousand copies a month in a period where Running Linux sold 3-4000 and Linux Device Drivers about 1500. Now the book is badly out of date (though a new edition is in the works), but you'd expect that there are more people doing network admin than there are writing device drivers. (And in fact, reader polls have actually put the NAG at the top of the list of "most useful" of our Linux books.)

Frank Willison, our editor in chief, made the following additional comments about the NAG and its free publication:

"We can demonstrate that we lost money because another publisher (SSC) also published the same material when it became available online. Because the books were identical, word for word (a requirement the author put on anyone else publishing the material), every copy sold of the SSC book was a loss of the sale of one copy of our book.

One interesting side note was that SSC published the book for a lower price than we did. Of course, we had the fixed costs: editing, reviewing, production, design. But those fixed costs didn't make the difference: when you took out the retail markup, the difference in price was equal to the author royalty on the book.

The above may be too much info, and isn't directly related to current Open Source practices, but it still chafes my butt."

If I had to quantify the effect, I'd guess that making a book freely available might cut sales by 30%. But note that this is for O'Reilly--we've got books with a great reputation, which makes people seek them out. And we cover "need to know" technologies where people are already looking for the O'Reilly book on the topic. For J. Random Author out there, open sourcing a book might be a terrible idea, or a great one. An author with some unique material that doesn't fall into an obvious "I already know I need this" category can build a real cult following online, and then turn that into printed book sales to a wider audience. We're hoping to do the same thing in publishing Eric Raymond's The Cathedral and the Bazaar (and other essays) this fall. Most of you guys have probably read them online, but there is a larger population who've probably heard the buzz, and will pick them up in the bookstore. On the other hand, an author who puts a lousy book online will only show this to the world, and sales will be 10% of what they'd been if the reader hadn't been able to see the book first.

Perhaps more compelling is the evidence from the Java world, where sales of the Addison-Wesley books based on the Sun documentation (which is mostly available online) are quite dismal, while our unique standalone books (as those from other publishers) do quite well. More importantly, though, programmers in our focus groups for Java report spending far less overall on books than programmers in other areas, because they say that they get most of the info they need online.

All of this is what tells me we need to tread carefully in this area, since I have to look out for the interests of my employees and my authors as well as my customers. In the end, free books online may look like a great deal, but it won't look so good if it ends up disincetivizing authors from doing work that you guys need.

And frankly, we have conversations all the time that go like this: "I'm making $xxx as a consultant. I'd love to write a book, but it's really not worth my while." At O'Reilly, we try to use authors who really know their stuff. So writing a book is either a labor of love, or it's a competitive situation with all the other things that author could be doing with their time. So money is an issue.

maelstrom asks:
(two out of three submitted) What books would you recommend a budding writer should read and study? and Do you read every book you publish?

Tim responds:
Books about writing that I like are Strunk & White (The Elements of Style) and William Zinsser's On Writing Well. But really, read any books that you like. Reading good technical books, and thinking about what works about them for you, is always great. We learn far more by osmosis than by formal instruction. So read, and then write.

Going back to the recurrent questions about free documentation--a great way to learn to write is to do it. Contribute your efforts to one of the many open source software projects as a documentation writer, get criticism from the user community, and learn by doing.

I would say that the ability to organize your thoughts clearly is the most important skill for a technical writer. Putting things in the right order, and not leaving anything out (or rather, not leaving out anything important, but everything unimportant), is far more important than trying to write deathless prose. The best writing is invisible, not showy. My favorite quote about writing (which came from a magazine interview that I read many years ago) was from Edwin Schlossberg: "The skill of writing is to create a context in which other people can think."

As to your second question: alas, I no longer have time to read everything we publish. We have a number of senior editors whose work I trust completely -- I never read their stuff unless I'm trying to use it myself. For new or more junior editors, I generally do a bit of a "sample" of each book somewhere during the development process. If I like it, I say so, and don't feel I have to look at it again. If I don't like it, I may make terrible trouble, as some of my editors and authors can attest.

howardjp asks:
One of the biggest compaints aong critics of the BSD operating systems is the lack of available books. Since O'Reilly is the leader in Open Source documentation, you are well positioned to enter the BSD market. With that in mind, why hasn't O'Reilly published any BSD books in recent memory?

Tim responds:
Every once in a while we make a stupid editorial decision, as, for instance, when we turned down Greg Lehey's proposed BSD book (now published by Walnut Creek CDROM). This was based on the fact that the BSD documentation, which we'd co-published with Usenix, had done really poorly, and the relative sales of our original BSD UNIX in a Nutshell relative to our System V/Solaris one. That was many years ago now, and BSD has emerged from the shadows of the AT&T lawsuit, and become a real force in the open source community. So I definitely think that there are some books that we might want to do there. Proposals are welcome.

That being said, so many of our books cover BSD (just like they cover Linux, even if they don't say Linux on the cover). After all, BSD is one of the great mothers of the open source movement. What is Bind, what is sendmail, what is vi, what is a lot of the TCP/IP utility suite but the gift of BSD...it's so much part of the air we all breathe that it doesn't always stand out as topic that gets the separate name on it.

chromatic asks:
Would you ever consider making previous editions of certain books free for download when supplanted by newer editions?

For example, when Larry Wall finally gets around to writing the 3rd edition of the Camel (probably about the same time as Perl 6), would you consider making the second edition available in electronic format?

I realize this has the possibility of forking documentation, but it's hard to find anyone more qualified than Larry, Randal, and Tom, for example. It would only work for certain books.

Tim responds:
The previous edition of CGI Programming for the WWW is available online now, while we work on a new edition, as is MH & xmh and Open Sources. You can read these at http://www.oreilly.com/openbooks/. We'd like to put more of our out of print books online, but it's a matter of man hours. Our Web team is organizing a new effort around this now, so look for more books to appear on this page.

And in fact, an awful lot of Programming Perl *is* available for free online, as part of the Perl man page or other perl documentation. It's not available in exactly the same form, but it's available. That's one of the big questions for online documentation: does the online version always look like the print version.

But this is a good question, and it's one we have certainly something we can think about. Might be another interesting experiment in understanding the ecology of online publishing.

Crutcher asks:
Not sure how to phrase this, but, well, what is the status of O'Reilley and marketing books to schools and colleges for use as textbooks. Our textbooks suck, and if there textbook versions of ya'lls books it would rock.

Tim responds:
We actually do quite a bit of marketing to schools and colleges, and they are used as textbooks in a number of places. If you know of a professor who ought to be adopting an O'Reilly book, please send mail to our manager of college and library sales, Kerri Bonasch, at kerri@oreilly.com. We also have a Web site to support this effort at http://www.oreilly.com/sales/edu/.

Are there any specific things that you see as obstacles to use of the books as textbooks? What topics would you especially like to see as textbooks?

zilym asks:
Are there any plans to improve the binding on your future books? Many of us use O'Reilly books to death and the binding is the first to go. I know I certainly wouldn't mind pay slightly more for a stronger version of some of the most heavily used titles.

Tim responds:
Hmmm. We use a special high-cost binding, which allows the books to lay flat. It's quite a bit more expensive than the normal perfect binding used by most publishers, and we think it's worth it. I have heard lots of compliments on how great this binding is. I haven't heard complaints about it breaking down--at least not without use that would break down a normal perfect-bound book as well. I don't know of any way to make it more durable.

Maybe hardcover? It would be great to have a slashdot poll on how many people share your problem and would like to see O'Reilly books in hardcover. (One caveat: We tried an experiment once (for our Phigs Programming Manuals--real behemoths) to offer books in both hardcover and softcover, so people could choose. Despite polls that said people would pay more for a more durable hardcover, everyone bought the softcover to save the difference in price.) So, if there is a poll, how much would you pay for a more durable book?

jzawodn asks:
Given some of the recent discussion surrounding the Linux Documentation Project (LDP), I began to wonder about its long-term direction and viability.

I "grew up" with Linux by reading *many* of the HOWTOs and other documents that were part of the LDP. In many ways, I'd have been lost without the LDP. But with the growth of Linux mind-share and increased demand for texts that help newcomers get acquainted with the various aspects of running their own Linux systems, there seems to have been a stagnation in much of the free documentation. I can't help but to wonder if many of the folks who would be working on LDP-type material have opted to write books for publishers instead.

Where do you see free documentation projects like the LDP going? What advice can you offer to the LDP and those who write documents for inclusion in the project? Might we see electronic versions of O'Reilly books (or parts of them) included in free documentation projects?

Tim responds:
I don't think that the slowdown of the LDP is because of authors deserting it to write commercial books. In fact, I think you're going to see a reinvigoration of free documentation efforts, as publishers try to contribute to these projects. I think that the right answer is for those who are writing books to figure out some useful subset of their work that will be distributed online as part of the free documentation, and for there to be some added value only available in books. I think that this has worked pretty well for the core perl documentation, where an update to the camel and an update to the online docs are really seen as part of the same project.

When O'Reilly is directly involved in an Open Source project, this is fairly typical of what we do. For example, O'Reilly was one of the original drivers behind the development of the docbook DTD, which is now used by the LDP. (We started the Davenport Group, which developed Docbook, back in the late 80's.)

We're releasing a book about Docbook, by Norm Walsh and Len Muellner, called DocBook: the Definitive Guide." It will be out in October. Norm and Len's book will be also available for free online through the Oasis web site as the official documentation of the DocBook DTD. This is our contribution to users of DocBook; without our signing and creating this book, good documentation for DocBook wouldn't exist. (This is in addition to our historical support of the creation of DocBook.)

Our goal here, though, is evangelical. We want more people to use docbook (and xml in general), and we think that making the documentation free will help that goal.

CmdrTaco asks (on behalf of a friend):
I understand from a very reliable source that O'Reilly is moving their website from a single Sun and an inside developed webserver to an NT cluster and some barely functioning proprietary software. Their bread and butter has been Unix. They have been taking a more and more vocal position within the OSS community. Why are they switching to NT?

Tim responds:
Well, your very reliable source has only part of the story right, and that's because it's a long and involved story. It started about 18 months ago, when the people on our web team wanted to replace what had become a fairly obsolete setup whose original developers no longer work for the company.

This system--which was about five years old--involves a lot of convoluted perl scripts that take data in a pseudo-sgml format, and generate a bunch of internal documents (marketing reports, sales sheets, copy for catalogs etc) as well as web pages. We wanted to do something more up to date, and didn't have internal resources to devote to a complete rework.

So we went out to a number of web design firms for bids. The winning firm does work on both NT and UNIX, but they showed us all kinds of nifty things that they said they had already developed on NT that we could use. These were tools for surveys, content management, etc. There was also stuff around integration with the spreadsheets and databases and reports used by our financial and customer service people. To recreate these tools on their UNIX side would cost several hundred thousand dollars.

So I said: "We can either walk the talk, or talk the walk. I don't care which, as long as what we do and what we say line up. If you can do it better and cheaper on NT, go ahead and do it, and I'll go out there and tell the world why the NT solution was better."

I was prepared to have to tell a story about interoperability--after all, despite all our efforts to champion open source, we realize that our customers use many, many different technologies, and we try to use them all ourselves as well. We were looking at doing some things on NT--the stuff our vendor said they already had working--while incorporating other elements on UNIX, Mac, Linux, and Pick (yes, we run a Pick system too!). The whole thing was going to be a demonstration of ways that you can choose from and integrate tools from many different platforms.

Instead, I have to tell the story that is so familiar to Slashdot readers, of promises of easy-to-use tools that, unfortunately, don't work as advertised. As your source suggests, the NT parts of the system haven't been delivered on time or on budget, and what we've seen doesn't appear to work, and we're considering scrapping that project and going back to the safe choice. To put a new spin on an old saw: No one ever got fired for using open source.

I say that tongue-in-cheek of course, because unlike a lot of open source partisans, I don't think that all good things come from the open source community. We like to bash Microsoft with the idea that "no matter how big you are, all the smart people don't work for you" but it's just as true that they don't all work for the open source community either. There are great ideas coming from companies like Sun and Microsoft, and (most of) the people who work there are just like us. They care about doing a good job. They want to solve interesting problems and make the world a better place. And sometimes they do.

I consider it my job to give them a fair shake at convincing me, and if they do, to give you a fair shake at learning what they've done right as well as what they've done wrong. I'll keep you posted.

Tim O'Reilly is, of course, the founder and guiding light of O'Reilly & Associates, which publishes stacks of books about programming in general and Open Source programming in particular, along with authoritative Linux manuals and a whole bunch of other stuff. Want to become an O'Reilly author? Ask Tim how. Or ask him anything else. Moderators will select the 10 - 15 questions we forward on Tuesday. Answers will appear Friday, and we cordially invite Tim to join the discussion Friday (if he has time) and add more comments or respond to any questions he found interesting but weren't moderated high enough to make the "first cut."

Tim O'Reilly is, of course, the founder and guiding light of O'Reilly & Associates, which publishes stacks of books about programming in general and Open Source programming in particular, along with authoritative Linux manuals and a whole bunch of other stuff. Want to become an O'Reilly author? Ask Tim how. Or ask him anything else. Moderators will select the 10 - 15 questions we forward on Tuesday. Answers will appear Friday, and we cordially invite Tim to join the discussion Friday (if he has time) and add more comments or respond to any questions he found interesting but weren't moderated high enough to make the "first cut."

Tim O'Reilly is, of course, the founder and guiding light of O'Reilly & Associates, which publishes stacks of books about programming in general and Open Source programming in particular, along with authoritative Linux manuals and a whole bunch of other stuff. Want to become an O'Reilly author? Ask Tim how. Or ask him anything else. Moderators will select the 10 - 15 questions we forward on Tuesday. Answers will appear Friday, and we cordially invite Tim to join the discussion Friday (if he has time) and add more comments or respond to any questions he found interesting but weren't moderated high enough to make the "first cut."

The first White Camel awards were presented to some well-deserving folks at the Perl Conference 3.0. Tom Christiansen, Kevin Lenzo and Adam Turoff were the three winners. Click below for details.

The awards were sponsered by Perl Mongers, O'Reilly and sourceXchange-so hats off to them for good work.

Tom Christiansen won the Perl Advocacy award for his work on the documentation, while Kevin Lenzo won the Perl Community Award for his work in "Yet Another Perl Conference" creation/design. Adam Turoff won the Perl User Group Award, for his efforts in making the first group, helping in Perl Mongers and encouraging formation of many other user groups.

Keep up the good work, guys.

Thanks to both danimal and Doc Technical for reviews of the latest and greatest O'Reilly book, Randy Jay Yarger, George Reese, and Tim King's MySQL and mSQL. An excellent book for those who are looking to do database development (and MySQL powers Slashdot!), click below for more details. MySQL & mSQL author Randy Jay Yarger, George Reese, and Tim King pages 506 publisher O'Reilly rating 8.5/10 reviewer Dan Weeks & DocTechnical ISBN summary A good introduction to the world of relational databases and an excellent reference for MySQLand mSQL. First Review: Doc Technical

This is certainly one of the more orthogonal books I've read of late. Besides the obvious axis of MySQL and mSQL, the book also covers the implementation of these databases on Unix, Windows 95 and Windows NT. And it covers a wide variety of programming languages, including perl, Python, PHP, Java, C, and C++.

While this is certainly a good book, in fact a very good book, this wide coverage means that the average reader may need to skip around a bit to get to the parts of the book they need. A Linux perl mSQL programmer will necessarily take a different path through the book then, say, a Windows NT mySQL database administrator.

Not that straying down the wrong path is always a bad thing. It was interesting to read about the quirky differences between different OS implementations.

"Windows 95 leaks about 200 bytes of main memory for each thread creation." [page 41]

"...[D]atabase and table names are case-sensitive under Unix and case-insensitive under Win32." [page 43]

The book is divided into three broad sections: "Getting Started with MySQL and mSQL", "Database Programming", and a final "Reference" section which spans fully half the book. O'Reilly's high standards for editing, layout, writing, and clarity are all evident throughout.

What I Liked Best For MySQL users, this book may appear to present a bit of a quandary. MySQL already comes with a 400+ page reference manual, and a quite nice one at that. But actually, the O'Reilly book covers much material the manual doesn't.

Chapter 2 covers relational database design, and serves as an excellent introduction for the uninitiated. Some college texts could learn a lesson on clarity from the authors' explanation of normal forms.

Chapter 6 has an interesting, short history of the development of SQL.

Chapter 7 describes some of the other free SQLs available, and also provides some insight into those features that MySQL/mSQL don't provide: things like stored procedures, triggers, transactions, and subselects. This chapter is useful for people trying to decide which SQL engine they need. If your sitting on the fence, trying to decide on MySQL/mSQL versus a commercial SQL offering, this chapter may help you decide.

The book's cover declares "Databases for Moderate-Sized Organizations & Web Sites", and the book delivers on this promise by including web-oriented sections on general CGI programming, Perl, and PHP.

The second half of the book provides a good reference to the MySQL/mSQL API's for several languages, as well as the MySQL/mSQL utilities, and a good reference for SQL itself. Most of this information is available elsewhere, and in more detail, but it's useful seeing the various language APIs presented side-by-side, particularly if you're not sure what language you might want to use. I've been contemplating Python programming for a while, and the simplicity of its MySQL API is certainly seductive.

What's Missing It's hard to find fault with the material included in the book, but I was surprised by some of the things that were left out.

There really is no ground-zero, simple mySQL/mSQL tutorial. For people beginning with a new SQL engine, it would be helpful to have a chapter that holds their hand, showing them how to create a database, then create a simple table, the insert records into the table, using the mysql utility. Tutorials are available for MySQL on the net (see www.mysql.com) and one is provided in the MySQL Reference Manual.

The book covers programming using a wide range of languages, but arguably one of the most popular languages, C, seems to get comparitively little coverage. There are only about six pages devoted to C programming, and one of those is a list of API functions. I would have welcomed more. [Admittedly, there is more on C in the book's Reference section, but this covers individual API calls, and doesn't provide any longer examples.]

There were a few rare cases in the book where I disagreed with the authors, or at least thought they needed to add a bit of additional amplification. On page 109, they state that:

"If you know that a lot of clients will be asking for the same summary information often... just create a new table containing that information and keep it up to date as the original table changes."

I have a bit of a nit to pick with this, as seven pages later they discuss the lack of a feature called triggers that would greatly simplify keeping a summary table in sync. Without a trigger, you'll have to devise your own method for keeping a summary table in step with the original table, which may be non-trivial depending on how often the original table changes and how often the summary table is accessed.

Summary This book tries to cover a lot of ground, and so it necessarily hits turf that some subset of readers won't care about.

For the seasoned MySQL programmer or database administrator, this book is a fine companion to the Reference Manual. With its clear introduction to SQL and relational database design, it also makes a good introduction to new SQL users in general.

Second Review - Dan Weeks

The Scenario There comes a time in every project when storing and retrieving data from flat files or proprietary formats (i.e., MS Excel) is no longer feasible. A Relational Database Management System (RDBMS) would be great, but Oracle, Sybase, and Informix can't be justified because of the cost. Along comes MySQL and mSQL, two of many freely available Database Management Systems. While neither of these DBMS's are as full featured and robust as their more mature brethren, they can definitely hold their own in the world of databases. For small and medium sized organizations and web sites either of these DBMS's can provide a sufficient level of functionality and flexibility to store and retrieve your data. What's Bad? The only shortfall I could find is the lack of references to other, more advanced books on the subject of database design and normalization (although that probably doesn't fit in with the publishers motives, but it would be nice). The book is well rounded and all of the authors are very knowledgeable and well written. What's Good? The first thing that struck me as absolutely wonderful about this book is the structure. By breaking the book into three sections the authors have allowed for many different database users to find this book valuable. Getting Started with MySQL and mSQL The first section, Getting Started with MySQL and mSQL has everything the novice needs to at least get one of the packages up and running so that they can experiment with a database system. The authors do a great job of making sure that the reader can skip sections if they don't pertain to them. Introductory topics like What is a Database? and History of MySQL are essential in making sure the subject matter is well rounded and accessible to everyone (especially to people like myself that did not take database classes at university). Later chapters explain and detail database design and normalization in a manner that is easy to understand so that the first databases you build won't suffer from repetition and data inconsistencies. The authors also do a good job of explaining SQL and specifically the variants that MySQL and mSQL use.

One of the high notes is the single chapter, Other Mid-Range Database Engines. Not only do the authors recognize that there are other database engines out there, they also point out what features MySQL and mSQL lack.

Making it Go The second section of the book, Database Programming, is a well written set of chapters that start off with the architecture of databases and client-server application and how they relate to data processing. The authors then quickly take you into the guts of interfacing with the database. They cover CGI, Perl, Python, PHP and other embedded HTML styles, C/C++, and Java. While I have only ever used Perl, Python, and C to interface to a database I can say that the chapters on the other API's seem to do just as good a job and at least allowed me to understand (if even in the most simple of terms) how those languages function in relation to your database engine of choice.

We all love our nutshell books, especially the XXX In A Nutshell series because they are great references. The foresight of the authors is incredibly prevalent in the third section, Reference. The authors actually took the time to make a ...In A Nutshell type of reference and then stick it into the book. Reference chapters that i have found invaluable so far are SQL (which includes separate sections for MySQL and mSQL's variations), and MySQL and mSQL System Variables. Other sections include C, PHP and Lite, Python, Perl, JDBC, and programs and utilities associated with MySQL and mSQL.

So What's In It For Me? If you are at all interested in database programming or you run a database at a small- to mid-sized organization or web site then this book is a must have. For those people that are in need of a little instruction on database design and normalization this book would be a good start. If you have been working with either MySQL or mSQL for a while then this book may be a bit basic for you, but the reference chapters will more than make up for the cost of the book.

Purchase this book at Amazon.com

Table of Contents

Preface
I. Getting Started with MySQL and mSQL
   1. Introduction to Relational Databases
   2. Database Design
   3. Installation
   4. MySQL
   5. mSQL
   6. SQL According to MySQL and mSQL
   7. Other Mid-Range Database Engines
II. Database Programming     121
   8. Database Application Architectures   9. CGI Programming
   10. Perl
   11. Python
   12. PHP and Other Support for Database-driven HTML
   13. C and C++
   14. Java and JDBC
III. Reference     229
   15. SQL Reference
   16. MySQL and mSQL System Variables
   17. MySQL and mSQL Programs and Utilities
   18. PHP and Lite Reference
   19. C Reference
   20. Python Reference
   21. Perl Reference
   22. JDBC Reference
Index

jbc writes "In the latest Ask Tim piece at the O'Reilly Web site, Tim O'Reilly gives his views on the likely impact of big money on the Open Source movement. Among other points, he says Red Hat's pre-IPO invitation is a good start, but doesn't do enough to promote future Open Source development. " At this point, I just wanna see how the market responds to RHAT.

Idmat writes "Nominate the Perl community's unsung heroes for the first White Camel awards. Three awards--for outstanding contributions to Perl Advocacy, Perl User Groups, and the Perl Community--will be awarded at O'Reilly's Perl Conference 3.0 on August 24, 1999. Nominate the folks who have made these important non-technical contributions to Perl at perl.com All nominations must be in by August 2. The White Camel awards are sponsored by Perl Mongers, O'Reilly & Associates, and sourceXchange. See the press release for more info " Anyone want to share their ideas?

chrisd writes "The book Open Sources has been opensourced, and is available here. with a mirror available here. (with a tarball) Enjoy! " I haven't had a chance to read this book yet, but I will now.

Geoff Romer writes "Illiad just announced a book deal for his User Friendly comic strip, and the publisher is none other than our good friends O'Reilly and Associates! Three cheers for both of them! Details are here. " Congrats to both of them. It would be awesome to do an animal cover of dust puppy ;)

jbc writes "Here's an opinion piece from O'Reilly's web site titled The Chameleon and the Virus: More Thoughts on Java's Community License. Gist: The viral, coercive GPL has retarded acceptance of open source software. Java's more flexible license can help bring more people into the movement. "

A new monthly column Brave GNU World has started, with the mission to inform everybody about new GNU software. Apparently dd if=/dev/zero of=/dev/hda does not completely delete the contents of you hard-drive. You should use shred instead. Paul Smith wrote in to plug a Free lecture by Richard Stallman which is going to be held tomorrow - Tuesday 23 March at 7pm at the Commonwealth Institute in London. Finally, jbc wrote in with "In his latest 'Ask Tim' piece, Tim O'Reilly talks about the differences between himself and RMS in terms of how they view OSS/FSF licensing issues." null -> zero (*blush*)

Greg Roelofs, author of PNG: The Definitive Guide, has written a feature on the PNG graphic format. The format has many technical advantages, yet it still isn't gaining acceptance. Personally, I just want a real alpha channel on web pages (well, and anti-aliased fonts, but lets cross one bridge at a time), Anyway, read what Greg has to say on the subject of PNG:

I hadn't intended to write anything up so soon, but lately there's been a lot of FUD and some general cluelessness about the Portable Network Graphics (PNG) image format, so here's an update from somebody who knows a tiny bit about it.

First of all, PNG is certainly not dead, although it obviously has not taken the Widely Webbed World completely by storm (which, in the eyes of the esteemed Mr. Veen, amounts to the same thing). For better or for worse, Netscape Navigator and Microsoft Internet Explorer pretty much define what counts as acceptable Web technology, and they only began supporting PNG natively in the autumn of 1997 (versions 4.04 and 4.0, respectively). As various Slashdotters have noted, neither one really supports PNG well yet, at least with respect to alpha transparency and gamma correction, but that's coming; let me return to that issue in a moment.

PNG has been making steady progress, however, particularly in non-Web applications. It has advanced from being a newsworthy ``extra'' to being an expected, standard component of image applications; in other words, a viewer or editor that ships without PNG support is considered deficient by both consumers and the trade press. That's a moderately subtle point--it doesn't necessarily leap right out at you and scream, PNG has arrived, dammit!, but it's nevertheless quite a significant milestone for any new technology. Mundane can be good. (By the way, I maintain the PNG home site and list known PNG-supporting applications of various persuasions on half a dozen pages; stop by if you're in need of something, and please let me know if I've missed any!)

But that's just one data point. Everybody's favorite technical publisher, O'Reilly and Associates, not only includes PNG chapters in a number of its books (including Web Design in a Nutshell and the soon-to-be-released Programming Web Graphics with Perl & GNU Software ), they also agreed to publish an entire 700-page book completely devoted to the Portable Network Graphics format: PNG: The Definitive Guide . It consists of around 300 pages of main text, 100 pages of program listings (both Unix/X and 32-bit Windows, under a BSDish license, freely downloadable soon), 250 pages of specifications, some fairly cool color figures, and assorted odds and ends; I happen to know because I wrote it. :-) (It just went into production on Monday, so it should hit the shelves in a few months, plug plug. I'll be updating the web page with dates and whatnot as soon as I find out myself.)

In addition, PNG has been published as an informational Internet RFC and a a W3C Recommendation (the very first one), and it's now wending its way through the slowly grinding gears of joint ISO/IEC standardization. That will all help ensure its longevity, but it's also fairly boring to most of you, I'm sure.

So getting back to the Web issue, let me briefly summarize PNG's basic capabilities:

• palette-based support (1, 2, 4, 8-bit), like GIF
• grayscale support (1, 2, 4, 8, 16-bit)
• truecolor support (24, 48-bit), like TIFF or (sort of) JPEG
• binary transparency, like GIF (except including grayscale and RGB modes, not just palette-based)
• alpha transparency (256 or 65536 levels of partial transparency), like TIFF
• alpha-palette transparency (that is, palette has RGBA entries, not just RGB), unlike anything else on the planet
• direct support for gamma correction and color correction
• lossless, unpatented compression
• 2D interlacing, somewhat like progressive JPEG
• no animation (but a closely related format called MNG)

The patent issue is largely history, except to shareware and freeware authors, for whom it's still quite real--Unisys lawyers continue their apparent crusade to kill all low-cost GIF-supporting software. What really matters to Web developers, however, is PNG's support for palette images (no, they don't all have to be really fat, 24-bit monsters); its support for alpha transparency even in palette images; its support for gamma and color correction; and the fact that its compression is lossless (which is why 24-bit PNG images are so fat, especially compared to lossy JPEG). In other words, for the same number of bytes as a binary-transparency GIF image, you can have a lovely alpha-palette PNG image that, thanks to gamma correction, will not look too light on Macs or too dark on PCs. The alpha support means it can be anti-aliased or drop-shadowed to look good against any background, not just a single, flat color. Note that MSIE 4.0 already supports gamma correction, and 5.0 is supposed to do full alpha transparency; we'll find out next month, I guess. Mozilla/Netscape 5.0 will also support both alpha and gamma, or else--I'm the nominal ``owner'' of Mozilla's PNG support, and now that the book is done, I intend to do some serious hacking. (Apologies for the 10-month delay!)

Since PNG pushes the envelope on a lot of image-related stuff--alpha transparency (no other Web formats), RGBA-palette images (no other format, period), gamma and color correction (almost no other formats), and even compression/filtering (it has a bunch of free parameters that one can tweak)--many of the current applications are somewhat behind in supporting some of the features. Be patient; things are steadily improving. I won't point fingers at any underperformers here, but I will note that the GIMP is quite strong in compression and 32-bit RGBA and should have fully working gamma code in the next release after 1.0.2; and Fireworks 1.0 is already partway there with RGBA-palette support and should be completely spiffy by version 2.1 or 3.0. (I didn't quite get my feedback in on time for it to affect the 2.0 release. If only they'd had a Linux version to try...)

I'm hopeful the book will help many of the others--it includes a lot of material aimed at helping programmers to improve their code, but also a lot of stuff to help users avoid problems and make the best of what options they've got. And if I have time while I'm working on Mozilla, I plan to release a free, automatic 32-bit to 8-bit (RGBA to RGBA-palette) converter to handle what seems to be the hardest PNG feature to support. Such conversion literally gives you a factor-of-four reduction in file size with essentially no visible loss (no more than normal RGB-to-palette conversion with nice dithering, anyway).

So...that, in a largish nutshell, is the past, present and future status of PNG. As for new competition, well, let's just say that there have been lots and lots and lots of fantastically improved, incredibly stupendous image formats that have come and gone over the years; ``WI'' is merely the latest, and SVG and JPEG2000/JPEG-LS are right around the corner. Anybody remember Johnson-Grace/AOL's ART format? How about Iterated Systems' fractal format (FIF)? Or some of the quadtree-based ones, or SPIHT, or FlashPix, or JPiG, or CMP, or ePIC, or HARC-C? Heck, even JPEG with arithmetic compression is considerably better than standard DCT-Huffman JPEG, but does anybody actually use it? No. Proprietary standards are simply not tolerated very well on the Web. Even free, open standards like PNG (with free, open-source, non-GPL'd reference libraries) have a huge barrier to climb. It took ``standard'' JPEG four years to catch on; it's taken PNG four years to catch on (yes, it's really been that long, and 2.5 years since the W3C Recommendation); and, barring largish miracles--e.g., Netscape and Microsoft cooperating--it will take any other new image format just as long.

There you have it. There's lots more info on the web site, and there are a couple of mailing lists for folks who really want to get gnarly with PNG. Oh, and please buy the book. ;-)

Greg Roelofs, author of PNG: The Definitive Guide, has written a feature on the PNG graphic format. The format has many technical advantages, yet it still isn't gaining acceptance. Personally, I just want a real alpha channel on web pages (well, and anti-aliased fonts, but lets cross one bridge at a time), Anyway, read what Greg has to say on the subject of PNG:

I hadn't intended to write anything up so soon, but lately there's been a lot of FUD and some general cluelessness about the Portable Network Graphics (PNG) image format, so here's an update from somebody who knows a tiny bit about it.

First of all, PNG is certainly not dead, although it obviously has not taken the Widely Webbed World completely by storm (which, in the eyes of the esteemed Mr. Veen, amounts to the same thing). For better or for worse, Netscape Navigator and Microsoft Internet Explorer pretty much define what counts as acceptable Web technology, and they only began supporting PNG natively in the autumn of 1997 (versions 4.04 and 4.0, respectively). As various Slashdotters have noted, neither one really supports PNG well yet, at least with respect to alpha transparency and gamma correction, but that's coming; let me return to that issue in a moment.

PNG has been making steady progress, however, particularly in non-Web applications. It has advanced from being a newsworthy ``extra'' to being an expected, standard component of image applications; in other words, a viewer or editor that ships without PNG support is considered deficient by both consumers and the trade press. That's a moderately subtle point--it doesn't necessarily leap right out at you and scream, PNG has arrived, dammit!, but it's nevertheless quite a significant milestone for any new technology. Mundane can be good. (By the way, I maintain the PNG home site and list known PNG-supporting applications of various persuasions on half a dozen pages; stop by if you're in need of something, and please let me know if I've missed any!)

But that's just one data point. Everybody's favorite technical publisher, O'Reilly and Associates, not only includes PNG chapters in a number of its books (including Web Design in a Nutshell and the soon-to-be-released Programming Web Graphics with Perl & GNU Software ), they also agreed to publish an entire 700-page book completely devoted to the Portable Network Graphics format: PNG: The Definitive Guide . It consists of around 300 pages of main text, 100 pages of program listings (both Unix/X and 32-bit Windows, under a BSDish license, freely downloadable soon), 250 pages of specifications, some fairly cool color figures, and assorted odds and ends; I happen to know because I wrote it. :-) (It just went into production on Monday, so it should hit the shelves in a few months, plug plug. I'll be updating the web page with dates and whatnot as soon as I find out myself.)

In addition, PNG has been published as an informational Internet RFC and a a W3C Recommendation (the very first one), and it's now wending its way through the slowly grinding gears of joint ISO/IEC standardization. That will all help ensure its longevity, but it's also fairly boring to most of you, I'm sure.

So getting back to the Web issue, let me briefly summarize PNG's basic capabilities:

• palette-based support (1, 2, 4, 8-bit), like GIF
• grayscale support (1, 2, 4, 8, 16-bit)
• truecolor support (24, 48-bit), like TIFF or (sort of) JPEG
• binary transparency, like GIF (except including grayscale and RGB modes, not just palette-based)
• alpha transparency (256 or 65536 levels of partial transparency), like TIFF
• alpha-palette transparency (that is, palette has RGBA entries, not just RGB), unlike anything else on the planet
• direct support for gamma correction and color correction
• lossless, unpatented compression
• 2D interlacing, somewhat like progressive JPEG
• no animation (but a closely related format called MNG)

The patent issue is largely history, except to shareware and freeware authors, for whom it's still quite real--Unisys lawyers continue their apparent crusade to kill all low-cost GIF-supporting software. What really matters to Web developers, however, is PNG's support for palette images (no, they don't all have to be really fat, 24-bit monsters); its support for alpha transparency even in palette images; its support for gamma and color correction; and the fact that its compression is lossless (which is why 24-bit PNG images are so fat, especially compared to lossy JPEG). In other words, for the same number of bytes as a binary-transparency GIF image, you can have a lovely alpha-palette PNG image that, thanks to gamma correction, will not look too light on Macs or too dark on PCs. The alpha support means it can be anti-aliased or drop-shadowed to look good against any background, not just a single, flat color. Note that MSIE 4.0 already supports gamma correction, and 5.0 is supposed to do full alpha transparency; we'll find out next month, I guess. Mozilla/Netscape 5.0 will also support both alpha and gamma, or else--I'm the nominal ``owner'' of Mozilla's PNG support, and now that the book is done, I intend to do some serious hacking. (Apologies for the 10-month delay!)

Since PNG pushes the envelope on a lot of image-related stuff--alpha transparency (no other Web formats), RGBA-palette images (no other format, period), gamma and color correction (almost no other formats), and even compression/filtering (it has a bunch of free parameters that one can tweak)--many of the current applications are somewhat behind in supporting some of the features. Be patient; things are steadily improving. I won't point fingers at any underperformers here, but I will note that the GIMP is quite strong in compression and 32-bit RGBA and should have fully working gamma code in the next release after 1.0.2; and Fireworks 1.0 is already partway there with RGBA-palette support and should be completely spiffy by version 2.1 or 3.0. (I didn't quite get my feedback in on time for it to affect the 2.0 release. If only they'd had a Linux version to try...)

I'm hopeful the book will help many of the others--it includes a lot of material aimed at helping programmers to improve their code, but also a lot of stuff to help users avoid problems and make the best of what options they've got. And if I have time while I'm working on Mozilla, I plan to release a free, automatic 32-bit to 8-bit (RGBA to RGBA-palette) converter to handle what seems to be the hardest PNG feature to support. Such conversion literally gives you a factor-of-four reduction in file size with essentially no visible loss (no more than normal RGB-to-palette conversion with nice dithering, anyway).

So...that, in a largish nutshell, is the past, present and future status of PNG. As for new competition, well, let's just say that there have been lots and lots and lots of fantastically improved, incredibly stupendous image formats that have come and gone over the years; ``WI'' is merely the latest, and SVG and JPEG2000/JPEG-LS are right around the corner. Anybody remember Johnson-Grace/AOL's ART format? How about Iterated Systems' fractal format (FIF)? Or some of the quadtree-based ones, or SPIHT, or FlashPix, or JPiG, or CMP, or ePIC, or HARC-C? Heck, even JPEG with arithmetic compression is considerably better than standard DCT-Huffman JPEG, but does anybody actually use it? No. Proprietary standards are simply not tolerated very well on the Web. Even free, open standards like PNG (with free, open-source, non-GPL'd reference libraries) have a huge barrier to climb. It took ``standard'' JPEG four years to catch on; it's taken PNG four years to catch on (yes, it's really been that long, and 2.5 years since the W3C Recommendation); and, barring largish miracles--e.g., Netscape and Microsoft cooperating--it will take any other new image format just as long.

There you have it. There's lots more info on the web site, and there are a couple of mailing lists for folks who really want to get gnarly with PNG. Oh, and please buy the book. ;-)

Steven Borrelli writes "AT&T as the mother of open source software? Here is a nice examination of the positions that the FSF and OSI have taken on O'Reilly's site. Whence the Source: Untangling the Open Source/Free Software Debate "

Pudding Yeti writes "O'Reilly is running an article entitled Whence the Source: Untangling the Open Source/Free Software Debate, which seeks to, well, untangle the free/open debate. It even seems balanced. I liked it. Maybe others will, too. "

An anonymous reader wrote in to say that O'Reilly is going to be shipping a new Perl Algorithms book By Jon Orwant, Jarkko Hietaniemi & John Macdonald. Its not due until August (why does that feel like years?), but I'm already stoked. And I'm cranky that I missed Larry Walls speech at LWCE.

Andrew Crump writes "Here is an interesting article published in Intraware by Thomas Scoville of O'Reilly. Does Europe have an advantage in fostering free software by virtue of its less capital-driven academia, its wariness of Microsoft products, its longer-term philosophies: in general its socialist leanings? There are certainly plenty of examples to cite that point to less US-centric development."

I'm the first to admit that I'm the last person who should write a book review. In fact, this is the first one I've posted on Slashdot. Frankly I don't read books any more- just web pages. I just don't have time- plus that whole paper thing doesn't appeal to me any more. But when "Open Sources:Voices from the Open Source Revolution" got here, I had no option but to read it. Immediately. Edited by Chris DiBona, Sam Ockman and Mark Stone, it's a collection of essays from Open Source glitterati with an impressive roster of names including ESR, RMS, Linus, Larry Wall, Bob Young, Tim O'Reilly, Bruce Perens and more. It's a wonderful read, hit the link below to read the rest. Open Sources

Each of these essays is an interesting read. The book starts off with ESRs 'Brief History of Hackerdom' which is an enjoyable read, although its a history that most of us are already familiar with. Marshall Kirk McKusick's piece follows with an in depth history of UNIX and BSD. Much of this information was new to me- it was one of my favorite sections in the book. And Linus talks about the Linux Kernel.

RMSs piece is, well, an RMS piece. Its interesting, but nothing new if you're familiar with RMS and the FSF. But if you aren't its an excellent little primer on the topic And that is important considering that this books target isn't as much the hacker, as it is the hacker's Boss. This is especially obvious after reading the articles by Bob Young and Michael Tiemann. Each article is an interesting look at the Open Source movement, but told through the eyes of the businessman.

Bruce Perens defines Open Source, A band of folks from Netscape including Tom Paquin talk about Mozilla from Netscape's perspective, and ESR writes a nice bit on the movement from the other side.

But my personal favorite bit is 'Diligence, Patience, and Humility' by Larry Wall. It seems curiously out of place in this book. Most every essay is a good read for "Your Boss" but this one is clearly for the artsy hacker type. Wall talks about communication, programming, philosophy, and pretty much anything else that comes to his mind in this humorous but insightful rambling essay. It alone was worth the price of admission.

So anyway, if your boss asks you what Open Source is, this is the book. If he ask you why it is, this is also the book. If you want to read an interesting collection of essays by the people who made this movement happen, this is the book. It is one of the few books that I'm glad I own- taking its place besides my few other favorite (mostly Dave Barry, Douglas Adams, and various O'Reilly Animal) dead tree editions. Highly recommended. A 9 out of 10.

If you are interested in purchasing this book, click here.

Table of Contents

Acknowledgments

Introduction
Chris DiBona, Sam Ockman, and Mark Stone

A Brief History of Hackerdom
Eric S. Raymond

Twenty Years of Berkeley Unix: From AT&T-Owned to Freely Redistributable
Marshall Kirk McKusick

The Internet Engineering Task Force
Scott Bradner

The GNU Operating System and the Free Software Movement
Richard Stallman

Future of Cygnus Solutions: An Entrepreneur's Account
Michael Tiemann

Software Engineering
Paul Vixie

The Linux Edge
Linus Torvalds

Giving It Away: How Red Hat Software Stumbled Across a New Economic Model and Helped Improve an Industry
Robert Young

Diligence, Patience, and Humility
Larry Wall

Open Source as a Business Strategy
Brian Behlendorf

The Open Source Definition
Bruce Perens

Hardware, Software, and Infoware
Tim O'Reilly

Freeing the Source: The Story of Mozilla
Jim Hamerly and Tom Paquin with Susan Walton

The Revenge of the Hackers
Eric S. Raymond

Appendix A: The Tanenbaum-Torvalds Debate

Appendix B: The Open Source Definition, Version 1.0

Tank writes "Here's a great little article at O'Reilly about the love affair many geeks have for *nix. Very appropriate as we approach Valentine's Day. Ahhh *nix, how do I love thee, let me `wc` the ways. " H:Perhaps I can compare 2.2 to a summer's day.

Paul Crowley writes "The table of contents for "Open Sources" , O'Reilly's book for the lay reader from Slashdot's interesting-ideas department, is now available and the book itself should be coming out later this month; I've just now received mail warning me of a copy coming my way sometime this week. One chapter is already available online: Eric S Raymond's A brief history of Hackerdom . So you can all start flaming his attention-seeking ways again now, especially since on a related note he's also turned up on Slashdot's favourite news source, BBC News." I just got a copy of Open Sources as well- Chris DiBona mentioned both me & Slashdot in his intro. I've read the ESR and RMS sections already- both were great. A full fledged review of the book will be here whenever I have time to finish reading it.

Paul Crowley writes "The table of contents for "Open Sources" , O'Reilly's book for the lay reader from Slashdot's interesting-ideas department, is now available and the book itself should be coming out later this month; I've just now received mail warning me of a copy coming my way sometime this week. One chapter is already available online: Eric S Raymond's A brief history of Hackerdom . So you can all start flaming his attention-seeking ways again now, especially since on a related note he's also turned up on Slashdot's favourite news source, BBC News." I just got a copy of Open Sources as well- Chris DiBona mentioned both me & Slashdot in his intro. I've read the ESR and RMS sections already- both were great. A full fledged review of the book will be here whenever I have time to finish reading it.

Paul Crowley writes "The table of contents for "Open Sources" , O'Reilly's book for the lay reader from Slashdot's interesting-ideas department, is now available and the book itself should be coming out later this month; I've just now received mail warning me of a copy coming my way sometime this week. One chapter is already available online: Eric S Raymond's A brief history of Hackerdom . So you can all start flaming his attention-seeking ways again now, especially since on a related note he's also turned up on Slashdot's favourite news source, BBC News." I just got a copy of Open Sources as well- Chris DiBona mentioned both me & Slashdot in his intro. I've read the ESR and RMS sections already- both were great. A full fledged review of the book will be here whenever I have time to finish reading it.

The critical companion to the Camel/Llama books, the Ram book, published by O'Reilly, Perl Cookbook: Solutions and Examples for Perl Programmers has been reviewed by Reviewed by: Eugene Sotirescu. This piece of art has been written by Tom Christiansen and Nathan Torkington-and if you want the scoop on the book, click below. Perl Cookbook: Solutions and Examples for Perl Programmers author Tom Christiansen and Nathan Torkington pages publisher O'Reilly & Associates rating 10 reviewer Eugenia Sotirescu ISBN summary An indispensable compendium of Perl programming problems with expert solutions and commentary. The ScenarioThe first Perl book, "Programming Perl", (Larry Wall and Randal Schwartz, 1990; aka the Red Camel) included 2 chapters, "Common Tasks with Perl" and "Real Perl Programs", that were left out of the second edition of the book ("Programming Perl", by Wall, Tom Christiansen and Schwartz, 1996; aka the Blue Camel). Many people bemoaned the omission of all these Perl-at-work gems and one of the authors, Tom Christiansen, undertook to expand the 2 orphan chapters into a separate book. Two years later, with the help of fellow Perl programmer and Perl FAQ maintainer, Nathan Torkington, Christiansen gave us the "Perl Cookbook" (aka the Ram book).

While no review can even get close to summarizing the wealth of information in this book, its structure is easily described: the organizing metaphor is the cookbook and therefore the bulk of each chapter contains recipes designed to address specific programming problems.

A Code FeastHere's a brief list of other goodies you can find in this book:

• a juicy regex grabbag, that shows how to match HTML links, IP addresses, all-caps words and key=value pairs among many other patterns.
• A full chapter on Database access that in addition to DBI also includes the most extensive discussion of DBM files in Perl literature.
• 40 pages on UNIX processes from the point of view of Perl.
• Examples on how to write demon and non-forking servers in the chapter on sockets and code to create robots, parsing server logs and automating form submission in the chapter on web automation.
• Numerous tips and examples of safe and efficient CGI programming in the chapter devoted to this.
• How to keep your modules separate from the system-wide ones and how to prepare modules you've written for CPAN distro
• Everything you ever wanted to do to dates/time but didn't quite know how .

At times, though, the authors can't keep themselves to just code snippets and cook a full ready-to-eat meal in the form of a complete program to cap the solutions presented in a chapter.
At the end of the Pattern Matching chapter, for example, you can find 'tcgrep', Tom Christiansen's cross-platform supergrep that "ignores anything not a plain text file, automatically expands compressed or gzipped files, recurses down directories, searches complete paragraphs or user-defined records . . . and adds underlining or highlighting of the matches". A program called 'hopdelta' caps the "Dates and Times" chapter and shows the time an email message took to reach each destination based on an analysis of its header.

Anatomy of a ChapterAfter an introduction that tries to present the history and general outline of the topic of the chapter come the numbered recipes. Each recipe is divided into 4 parts: a brief statement of the Problem, followed by the code of the Solution and a detailed Discussion with further comments, code examples and pitfalls. The recipe ends with a See Also paragraph that sends the reader to the relevant man pages and further references.

Chapter 7, for instance, deals with File Access. It opens with a 4-page discussion of the basic concepts of file handles and I/O. It then quickly moves into the recipes, which range from the basic (opening a file, covered in depth, output flushing) to the often used and asked about (writing a filter, modifying a file) and ends with a longish complete program that implements lock control over a designated region of a file. Changing a file has 3 sections devoted to it: in-place modification using a temp file, doing it from the command line and the less common in-place modification without a temp file.

(Note: if you've been modelling your file locking on the flock() example on pp.166-7 of the Camel book, make sure you check out recipe 7.11, "Locking a File", to see what you may be doing wrong).

What's Bad?I'd say: nothing. A caveat is in order, though.
Good recipes do not a gourmet cook make. A handy compendium of code snippets like the ones in this book will help solve the problem at hand, but won't help you design better programs. I don't mean to detract from the book's value (after all its purpose is not to teach program structure), just to deflate a little the beginning Perl programmer who uses this book to get unstuck: he's solved the problem at hand and that's great, but he's not necessarily a better programmer for it. The authors are probably aware of this, hence the complete programs at the end of the chapters. I only wish there were more of these.

What's Good?Lucid presentation and clear organization make this book not only useful to refer to, but also pleasant to read through. And the code in it comes not only from experienced authors, but has also been polished by the feedback from scores of Perl gurus, which is a pretty good guarantee of its quality.

Do YOU Need the Ram book?To make it short, let's actually ask: "who doesn't need the Ram book?"
If you're Larry Wall, you probably don't need it . That's it. For the rest of the Perl crowd this book is pretty much an essential companion to the Camel, as both resource and learning tool.

(Note: If you use Perl to teach yourself programming, use the Llama ("Learning Perl," by Randal Schwartz) to get going, but keep the Ram in mind: if you get anywhere with Perl you too will want it).

Buy this book here.

Errata

Table of Contents

1. Strings
2. Numbers
3. Dates and Times
4. Arrays
5. Hashes
6. Pattern Matching
7. File Access
8. File Contents
9. Directories
10. Subroutines
11. References and Records
12. Packages, Libraries, and Modules
13. Classes, Objects, and Ties
14. Database Access
15. User Interfaces
16. Process Management and Communication
17. Sockets
18. Internet Services
19. CGI Programming
20. Web Automation

Matt Welsh (who is probably not coincidentally program chair...) wrote in with a call for papers for the upcoming O'Reilly Linux Conference. It looks like a cool conference, almost a Linux Expo of the west (in August): two days of tutorials, followed by two days of a multi-track conference. They also will have evening "breakaway sessions" for special interest groups (sorta like BOFs, it seems). I actually may submit a paper...

Paul Crowley writes "Back in April, I proposed to Slashdot that there should be a book that shows our "Road Ahead" to lay readers. I just saw that O'Reilly are listing the book that came out of that discussion, now called Open Sources , in their "upcoming books" list, to be out February! Too bad it's too late for Christmas. The star-studded list of contributors includes Linus Torvalds, Eric Raymond, and Richard Stallman. I can't wait to get a copy. " Its by Chris DiBona and Sam Ockman. Pretty sweet- I demand

ensor writes "O'Reilly & Associates are holding a PalmPilot Programming Contest "There is some exciting and innovative work being done in PalmPilot programming" said Tim O'Reilly, president of O'Reilly & Associates. "This contest was one way to reward this spirit of innovation." " H:And the prizes actually look decent.

Nick Towers writes "Interesting response from Tim O'Reilly about releasing books in a similar way to Open Source software" This is getting to be a hot topic these days. This is worth reading.

Eric Wayte wrote in to send us a link to a release about O'Reilly's Open Source Conference which will happen next august and feature Linux, Perl, FreeBSD anr more.

An anonymous reader sent us a link to an Open Letter from Tim O'Reilly (you might have heard of him or his company before. heck, you probably own several of his books) responding to the Halloween Document.

strredwolf writes "If you didn't know already, the first edition of PalmPilot: The Ultimate Guide from O'Reilly has been out, giving some good items on our coolest palm computer. However, there's no Unix/Linux information(only Mac & Win95/NT)! Tim of O'Reilly, however, wants to put some Unix PalmPilot info into the Second Edition of the book, but needs help from the community." Wouldn't mind seeing that one myself.

strredwolf writes "If you didn't know already, the first edition of PalmPilot: The Ultimate Guide from O'Reilly has been out, giving some good items on our coolest palm computer. However, there's no Unix/Linux information(only Mac & Win95/NT)! Tim of O'Reilly, however, wants to put some Unix PalmPilot info into the Second Edition of the book, but needs help from the community." Wouldn't mind seeing that one myself.

davew writes "O'Reilly have brought out a book called Stopping Spam: Stamping Out Unwanted Email and News Postings. It's by Simson Garfinkel (who co-wrote their security book with Gene Spafford) and Alan Schwartz. The animal on the front is a hog. I'm told it's mostly geared toward end users, but with three chapters about what ISPs can do to decrease spam. They've also set up an anti-spam site: stopspam.oreilly.com. "

davew writes "O'Reilly have brought out a book called Stopping Spam: Stamping Out Unwanted Email and News Postings. It's by Simson Garfinkel (who co-wrote their security book with Gene Spafford) and Alan Schwartz. The animal on the front is a hog. I'm told it's mostly geared toward end users, but with three chapters about what ISPs can do to decrease spam. They've also set up an anti-spam site: stopspam.oreilly.com. "

Danny Yee, interpid book reviewer and Slashdot reader has sent us a review of Sendmail. So, if you've always been intrigued by this wonderful util, click below. Sendmail

Bryan Costales + Eric Allman
O'Reilly & Associates 1997

AbookreviewbyDannyYee(danny@cs.usyd.edu.au),Copyright©1998

There is no doubt that sendmail is one of the more complex systems a typical Unix system administrator is likely to have to deal with; my first glance at a sendmail.cf file was certainly off-putting. Leaving aside whether this isn't an argument for using a different MTA entirely, it certainly makes sendmail documentation important. The O'Reilly Sendmail book opens with a slow-paced 190 page tutorial, designed to put the faint-hearted at ease. This goes through the construction of a simple cf file, illustrating the workings of rulesets, macros, and workspaces. Next are sections on installation and configuration - compiling sendmail from source, using M4 to create config files, using checkcompat() - and on administration - covering interaction with the DNS, security, the mail queue, aliases, .forward files and mailing lists, and logging.

This is excellent stuff for people like me, seeking a basic understanding of how sendmail works and a guide to simple administration tasks. There may not be much in it for serious gurus, but they will appreciate the second half of Sendmail, which is a detailed reference manual, containing far more than most people will ever want to know (I have only glanced at it myself). This could, perhaps, have been printed as a separate book: not only are some people likely to want just the reference manual or just the tutorial and administration guide, but bundling them together makes for an awkwardly thick volume. (O'Reilly also publish a pocket-sized Sendmail Desktop Reference, which is basically a summary of and index into the reference manual in Sendmail.)

This second edition of Sendmail covers version 8.8, but most of it (and certainly the tutorial sections) won't date that rapidly. If you actually administer sendmail then it is an obvious O'Reilly title to add to your collection, but it may also interest curious users - after all, almost everyone uses sendmail, even if indirectly.

Browse 430 other book reviews by Danny Yee
Top | Subjects | Titles | Authors | Keywords | Publishers | Latest Get Sendmail over here.

Pater has given us a write up on the famous panther book, Advanced Perl Programming. So, if you just can't get enough Perl, and who can, check it out. Besides, Slashdot is programmed in Perl, and we all love Slashdot, right? Riiigght. REVIEW: Advanced Perl Programming by Sriram Srinivasan (O'Reilly & Associates)

Reviewed by Pater.

Nutshell Review: More in-depth than Programming Perl, this book shows how powerful Perl can be whether designing solutions for the enterprise, or just trying to automate difficult tasks on your own system.

Rating: 7/10

What's Good?

After getting my feet wet programming in Perl (and reading the Camel Book) I wanted more, and a quick paging through this book showed me windows interfaces, networking calls, and more. When reading the book, I found some of the same topics addressed in Programming Perl, but the topics covered in both books are quite possibly the toughest Perl concepts to master. After reading the section on object orientation, I finally felt comfortable enough to due object-oriented programming in Perl. Advanced Perl Programming is, at it's very worst, a quick tour of several modules available for Perl. The book spends a considerable amount of time on Perl/Tk, with an appendix dedicated to Perl/Tk as well.

These sections alone justified the cost of the book to me, but it also contains instructions on embedding Perl into C and using C within Perl. The book also takes time out to compare and contrast Perl with other langauges. This helps those who may be making a transition to Perl from C/C++, Java, or Python. All in all, this book is a good reference for the power Perl programmer.

What's Bad?

One major downside is that many modules upon which Advanced Perl Programming is written are not part of the standard Perl distribution. Granted, most of the CPAN (Comprehensive Perl Archive Network) modules are accepted as "the ones to use," but they are not guaranteed to be on every machine that has Perl. My other biggest irritation is that often an extremely powerful module would recieve little attention, and the book acts as one giant pointer to CPAN. However, this isn't much of a problem to anyone with good internet access.

Why should I buy this book?

If you are a Perl programmer who wants to use Perl to it's fullest, this book is definitely for you. I don't know of a more advanced book on Perl that covers the same material. Advanced Perl Programming is not a book for the Perl hacker (no fancy one-liners here), but more of a guide to help an application developer get the most out of Perl.

So, if you'd like to pick this up, check out Amazon. Also, O'Reilly is doing a Linux survey about their books. Head over there and help them out.

Table of Contents

Preface

1. Data References and Anonymous Storage
2. Implementing Complex Data Structures
3. Typeglobs and Symbol Tables
4. Subroutine References and Closures
5. Eval
6. Modules
7. Object-Oriented Programming
8. Object Orientation: The Next Few Steps
9. Tie
10. Persistence
11. Implementing Object Persistence
12. Networking with Sockets
13. Networking: Implementing RPC
14. User Interfaces with Tk
15. GUI Example: Tetris
16. GUI Example: Man Page Viewer
17. Template-Driven Code Generation
18. Extending Perl: A First Course
19. Embedding Perl: The Easy Way
20. Perl Internals

Appendix A: Tk Widget Reference
Appendix B: Syntax Summary

Per Wigren writes " This article on O'Reilly is from April, but I've not seen it on Slashdot before and it's a really great article about Linux running on so many architectures... "

Ichabod writes "O'Reily made a book about the PalmPilot. Suppossedly it contains all sorts of cool tricks and undocumented tips. This URL is pretty much just an ad for it. " Next semester I'm taking a course in programming small machines where we're gonna take on the Pilot as part of the class. Might just have to snag a copy and warm up for it :)

Keith Brown writes "O'Reilly has an interresting link on their homepage to The Real Grass Roots Movement. It's short and very sweet. "

Infoworld has a report about Tuesday's O'reilly Free software conference. The idea is to come up with some sort of coherent plan to address common issues such as fear of free software, commercial support, and how to develop software within the open source model. Not much appears to have been decided, but it's good to see a recognition of the need for concerted action if free software is to become more mainstream. It would be nice if they stopped calling it freeware, don't you think?