Slashdot Mirror

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

SEGV, the old faithful of reviews, has sent in one of his latest reviews, this one of Edward Yourdon's latest book Rise and Resurrection of the American Programmer. For those of you who remember, several years ago, Yourdon wrote a book about how the American programmer/developer was doomed. Recent years have changed his opinion, and in this book he talks about the change that he says across the landscape. Fascinating idea-click below for the review. Rise and Resurrection of the American Programmer author Edward Yourdon pages publisher Prentice-Hall, Inc. rating 8.5 reviewer SEGV ISBN 0-13-121831-X summary A few years later, this industry autopsy remains an interesting and insightful read.

Decline and Fall

In the beginning of this decade, Edward Yourdon wrote Decline and Fall of the American Programmer, a pessimistic assessment of the American software industry in the global marketplace. I haven't read that book, but Ed conveniently summarizes it in the first chapter of this book.

His premise was simple: North American programmers are more expensive, less productive, and produce lower quality software than programmers elsewhere in the world. Therefore, he argued, competitive forces will drive them into extinction. He backed this up with a battery of data, figures, case studies, and anecdotal evidence.

This was apparently a wake-up call. After all, Ed wasn't merely an ignorant consultant. Rather, with 35 years in the industry, he had programmed mainframes and helped to invent structure design methodology. People listened to him.

Rise and Resurrection

But something happened during the first half of this decade. Not all of Ed's predictions came true; not all software development migrated to Bangalore, India; not all American programmers fell off the evolutionary ladder.

This book, Rise and Resurrection of the American Programmer, was written mid-decade to reexamine the situation then. Remember 1995? The web was just taking off, Microsoft Windows 95 was just released, Java was just beta, and Linux was just a hacker's toy.

Now the decade is closing, Ed is focusing on Y2K issues, and I've just finished reading this book. Some of Ed's views have dated, and some remain relevant. I'll try to enumerate a few of them here.

Java and the Internet

Ed stressed the importance of corporations embracing the internet. After all, he argued, competitors will. This has turned out to be correct. He also was extremely enthusiastic about Java, which wasn't even shipping when he wrote the book. Although most of the chapter explains the language and environment, and ends up sounding like a Sun white paper, one interesting nugget is Ed's suggestion that Microsoft may simply "embrace and assimilate" Java for themselves.

The Microsoft Paradigm

Let's be frank; Microsoft is quite successful, and does some things right. Ed dissects the corporation and comes to several conclusions. With section headings such as "The Dark Side of the Force" and "Into the Belly of the Beast," this chapter acknowledges public sentiment and should interest most Slashdot readers. But Ed concludes that Microsoft's hackers are growing up, and the corporation's powerful position will be difficult to assault.

Linux and Open Source Software

Ed pretty much missed this one. I didn't see any mention of Linux, hardly a blip on the radar when this book was written. Curiously, I also didn't see any mention of open source software, a wider concept that has been around for decades.

The closest hint I saw of the rising phenomenon was regarding Java's ability to change the economics of paying for software. Ed suggested that downloadable applets and web interaction make it possible to sell a "one-time usage" of software components, which could threaten existing software vendors with monolithic products.

An Enjoyable Read

At just over 300 pages, this book covers quite a few topics. I thought the chapters on peopleware and good-enough software were quite well done. Other chapters spurred me to learn more about the Capability Maturity Model and Personal Software Practices.

Ed is a frank and readable writer, and the book is quite digestible. It's fun to read recent predictions and analyze where they went wrong, and right (remember, hindsight's 20/20!). The book is almost a time capsule of the mid-nineties, which coincidentally being when I started working with computers in earnest was a refreshing read for myself. I think it will be for you as well.

Ed's web site is at www.yourdon.com.

Buy this book here.

TABLE OF CONTENTS

Preface
Trademark Acknowledgements
Part One: Decline & Fall Reexamined
1. The Original Premise
2. Peopleware
3. The Other Silver Bullets
Part Two: Repaving Cowpaths
4. System Dynamics
5. Personal Software Practices
6. Best Practices
7. Good-Enough Software
Part Three: The Brave New World
8. Service Systems
9. The Internet
10. Java and the New Programming Paradigm
11. The Microsoft Paradigm
12. Embedded Systems and Brave New Worlds
13. Past, Present, and Future
Appendix: An Updated Programmer's Bookshelf
Index

Remember Hal in Stanley Kubrick's "2001"? He was a wuss compared to the deep thinking digital machines Ray Kurzweil suggests are heading our way over the next century. Forget the debate over human versus artificial intelligence. "The Age of Spiritual Machines" suggests that we and our computers are about to become one, evolving together in a whole new bio-digital species. By 2020, computers will be as smart as we are. By 2099, there will no longer be any clear distinction between humans and computers. Is this techno-hype or prescient futurism?

In l990, inventor Ray Kurzweil predicted in "The Age of Intelligent Machines," that the Internet would proliferate rapidly and that the defeat of a human chess champion by a computer was imminent.

He was right on both counts, so it's worth paying attention to his new book, "The Age of Spiritual Machines," (Viking, $25.95). This round, Kurzweil is making even more radical predictions - namely, that computing will develop so rapidly over the next century that technology and human beings will literally merge in socially, educationally, biological, even spiritual ways.

Kurzweil has ratcheted up the human-versus-artificial intelligence debate a few notches. There will, he makes clear, be no human intelligence versus artificial intelligence. We and our computers will become one.

This theory picks up where Moore's Law leaves off. Gordon Moore, one of the inventors of the integrated circuit and former chairman of Intel, announced in l965 that the surface area of a transistor - as etched on an integrated circuit - was being reduced by approximately 50 per cent every twelve months. In l975, he revised the rate to 24 months. Still, the result is that every two years, you can pack twice as many transistors on an integrated circuit, doubling the number of components on a chip as well as its speed.

Since the cost of an integrated circuit has stayed relatively constant, the implication is that every other year brings twice as much circuitry running at twice the speed for the same price. This observation, known as Moore's Law on Integrated Circuits, has been driving the acceleration of computing for decades.

The most advanced computers are still much simpler than the human brain, currently about a million times simpler. But computers are now doubling in speed every twelve months. This trend will continue , Kurzweil predicts, with computers achieving the memory capacity and computing speed of the human brain by approximately the year 2020.

This is a stunning idea. Human evolution is seen by scientists as a billion-year drama that led to its greatest creation: human intelligence. Computers will get to the same point in less than a hundred years. It's time - past time, actually - to start asking where they will go from here.

Kurzweil doesn't argue that next year's computers will automatically match the flexibility and subtlety of human intelligence. What he predicts is the rapid rise of what he calls the software of intelligence. Scanning a human brain will be achievable early in the next century, and one future approach to computing will be to copy the brain's neural circuitry in a "neural" computer designed to simulate a massive number of human neurons.

"There is a plethora of credible scenarios for achieving human-level intelligence in a machine," writes Kurzweil. "We will be able to evolve and train a system combining massively parallel neural nets with other paradigms to understand language and model knowledge, including the ability to read and understand written documents."

Kurzweil's own law of accelerating growth and return is centered on the idea that this new bio-digital species becomes increasingly learned and sophisticated, life will become more orderly and efficient, while technological development continues to accelerate.

Kurzweil's premise - that computers will become as smart as we are and then merge their intelligence with ours -- is not only challenging and provocative; it also makes sense. But he isn't as clear or coherent when it comes to divining just what kind of intelligence computers will have - how intuitive they can be, how individualistic or ethical.

By the second decade of the next century, there will be reports of computers passing the Turing Intelligence test, says Kurzweil. The rights of machine intelligence will become a public policy issue. But machine intelligence will still largely be the product of collaborations between humans and machines, computers still programmed to maintain a subservient relationship to the species that created them. But not for long.

Where his book and his vision stumble is in grasping what will happen to us when computers become smarter than we are, then sensual, social or spiritual. Will we better off? Will the computer be moral? Will it have a social or other consciousness? Do we wish to merge with computers into one species? Will we have any choice? We could be heading for a sci-fi nightmare or, alternatively, for another of those utopian visions that used to pepper Wired magazine before it became the property of Conde Nast.

While futurists can measure or plot the computational skills of tomorrow's computers, can anyone really know the precise nature of that intelligence, and whether or not it can replicate the functions of the human brain?

The idea of our being outsmarted, thus dominated and endangered by computers, has been portrayed as a nightmare in Stanley Kurbrick's "2001" (Kubrick apparently greatly underestimated the virtual person Hal would become). It's also surfaced in various rosy intergalactic Disney-like visions in which machines perform labor, clean the air, heal humans, teach kids. Kurzweil doesn't say which notion, if either, sounds more plausible.

The latter half of the book becomes essentially a time-line: Kurzweil somberly walks us through the evolution of computing intelligence, and the eventual merging of digital technology and human beings into a new species.

By 2009, Kurzweil predicts, human musicians will routinely jam with cybernet musicians. Bioengineered treatments will have greatly reduced the mortality from cancer and heart disease. But human opposition to advancing technology will also be growing, an expanding neo-Luddite movement.

By 2019, nonetheless, Kurzweil predicts that computers will be largely invisible, embedded in walls, furniture, clothing and bodies - sort of like the artwork in Bill Gates' massive new mansion. People will use three-dimensional displays built into their glasses, "direct eye" displays that create highly realistic, virtual visual environments that overlay real environments. Paraplegics will routinely walk and climb stairs through a combination of computer-controlled nerve stimulation and exoskeletal robotic devices. This display technology projects images directly onto the human retina, exceeds the resolution of human vision, and will be widely used regardless of visual impairment.

In 2009, human opposition to advancing technology will be growing - as in the spread of the Neo-Luddite movement.

By 2019, there will be almost no human employment in production, agriculture, or transportation, yet basic life needs will be met for the vast majority of the human race. A $1,000 computing device will approximate the computational ability of the human brain that year, and a year later, the same amount of money will buy the computing capacity of about 1,000 human brains.

By the year 2099, a strong trend towards the merger of human thinking with the world of machine intelligence that humans created will be underway. There will no longer by any clear distinction between humans and computers. Most conscious entities will not have a permanent physical presence. Life expectancy will no longer be a viable term in relation to intelligent beings.

Small wonder Kurzweill expects a growing discussion about the legal rights of computers and what constitutes being "human." Direct neural pathways will have been perfected for high-bandwidth connection to the human brain. A range of neural implants will be available to enhance visual and auditory perception, machine-generated literature and multi-media material.

"The Age of Spiritual machines" surpasses most futuristic predictions of sci-fi writers and technologists. Scientists and programmers may not be the best judge of the nature of artificial digital intelligence. Some input from biologists and neurologists might have been useful. Sometimes, Kurzweil's predictions read like the numbingly familiar, gee-whiz techno-hype that infect mass media discussions of the Internet.

Yet Kurzweil is someone to be taken seriously. No nutty academic or cyber-guru, MIT named him inventor of the year in 1988; and he received the Dickson Price, Carnegie Mellon top science award, in 1994.

Caution is still in order. Kurzweil's earlier predictions about the Net and chess were short term, thus much more cautious and feasible. Only the new bio-digital species will know if these visions turned out to be right.

Predictions about the future of technology have a checkered history, itself a cautionary tale for futurists. Walt Disney was convinced we'd be whizzing back and forth to Saturn on weekends by now. We were surely supposed to be controlling the earth's climate rather than worrying about holes in the ozone layer. And whatever happened to cancer cures and hover cars?

But it's hard to find any parallel with the history of computing. The growth of digital machines suggests the future of computers be taken more, not less, seriously. "The Age of Spiritual Machines" is a wake-up call. It reminds us that the relation between human beings and the remarkable machines they've invented is almost sure to change radically. Perhaps it's time to start thinking seriously about how.

Buy this book here.

You can e-mail me at jonkatz@slashdot.org.

LizardKing has sent us a review of John Perry's Advanced C Programming by Example. Covering topics such as pointer trickery, string manipulation and dynamic data structures, this book is designed for those of you who are looking to fine-tune your C skills. Click below for more information. Advanced C Programming by Example author John W. Perry pages publisher PWS rating 9/10 reviewer LizardKing ISBN summary An unusualy well written C textbook, that picks up where most other programming guides finish off. The Scenario

Having been given a book voucher for Christmas, I duly trotted off to Blackwell's bookshop in Oxford to see what I could spend it on. I did the obligatory check for new O'Reilly titles, before turning to the C books. A hardback copy of Kamp II to replace my dog-eared paperback would've been nice, but first I decided to flick through Advanced C Programming by Example. The contents page promised examples of pointer trickery, string manipulation and dynamic data structures. I consequently bought it.

What's Bad?

There is very little to fault this book on. It is written in a clear and enjoyable manner, which is about the best you can hope for from a programming guide. My only real criticism is the lack of a bibliography. For instance, cryptography is mentioned in the chapter on bit manipulation, but no references to further reading are given.

What's Good?

The introduction explains the rationale behind producing another C book by pointing to the dearth of intermediate level texts. The author also criticises the current emphasis on OO languages with their larger vocabulary and more abstract concepts.

The first chapter highlights the importance of coding style to aid maintainability, and the valid use of features like the ternary and comma operators. This is followed by an excellent review of pointer theory. I always judge a C book by how clearly it describes the purpose of pointers - and this one does it superbly.

Subsequent chapters contain in depth analysis of key data structures like singly and doubly linked lists, binary trees, etc. While most C books include examples of these, they are particularily well described and illustrated. Other important techniques like hashing (both to memory and disk) are introduced, with common pitfalls highlighted.

The bit manipulation chapter is comparable with those in other C texts, but is unusually clear and consistent. The same can be said of the advanced I/O chapter.

The chapter on string manipulation uses dynamic memory allocation, arrays of pointers and the more obscure ANSI C string functions for 'real world' examples. This is another area where many C books fall down, ignoring the fact that the strings many programmers deal with cannot be expected to fit into fixed length arrays.

The final "Pot-Pourri" chapters include a discussion of complex function declarations that both expect and return function pointers. A number of other rarely described but expressive features are also covered.

So What's In It For Me?

If you consider yourself a C expert, then this book may be superfluous, as it covers ideas and principles you should know intimately. But if like me you're spending more time with scripting languages like Perl, you may need a handy reference for those forays back into C.

Buy this book here.

Table of Contents

1. Optimal C Coding Style
2. Review of Standard Pointer and Array Operations
3. The Linear Dynamic Data Structures: Stacks, Queues and Linked Lists
4. Advanced String Handling
5. Advanced Input and Output
6. Bit Manipulation
7. Recursion and Binary Trees
8. Multidimensional Arrays and Arrays of (Non-Char) Pointers
9. Potpourri: Part One
10. Potpourri: Part Two
11. Answers to Selected Exercises

I've put the proverbial pen to paper and taken a look at Alan Schwartz and Simson Garfinkel's book Stopping Spam, the (of course) pig book from our friends at O'Rielly. Short, and to the point, this is a good book for those who want to stop some of that spam that seems to flow through. At least I don't get anything from Bull's Eye anymore. (grin) Stopping Spam author Alan Schwartz & Simson Garfinkel pages publisher O'Reilly & Associates rating 8.5 reviewer hemos ISBN summary Quick & dirty ways to stop spam. The Scenario Schwartz and Garfinkel (of HotWired fame) have got together to write a book basically high-lighting ways to stop spam, why spam needs to be stopped, implications of spam for the Internet, and what you can do. Well writte, they also rely on some of their experiences with it, which adds a personal touch to things. The book also talks about some of the history of spam-Spam King, what people are doing, and how Spam works. The book itself is relatively short, but packs good information into it.

What's Bad? I would preferred something longer. The book itself does a good job of covering the basics of stopping spam, but something that's more definitive for the sysamdins in the crowd would have been appreciated. This is truly a nutshell review of things-it doesn't go into a huge amount of detail, but provides more of a general overview.

What's Good? The book does a good job of covering how spam works, and how to stop spam. Some of the advice is basic-things like avoiding putting your e-mail address on web pages. It also talks about spoofing in newsgroups, how cancel messages work, why they work. To people who like context, the history and comments they give are well recieved, and well written. I particularly enjoyed some of the history of UDPs. Filters are covered, in a variety of different e-mail programs, which is useful for many people.

So What's In It For Me? Basically, if you are looking to slow/stop spam this is good. It's a good introduction for moderators of newgroups, small-time syadmins and such. I wouldn't say that this book is the definitive source, but for 80% of us, this book will more then do the job. Things like filtering mail and Usenet, safeguarding addresses, and also spam stopping for administrators. That's good stuff.

Buy this over here.

Table of Contents

1. Preface
2. What's Spam and What's the Problem?
   • Slapped in the Face
   • What's Wrong with Spam
   • A Taxonomy of Spam
3. The History of Spam
   • Prehistory
   • Early Bulk Email
   • Usenet and the Spam Cancelers
   • In Their Own Words
4. Spamming Today
   • The Players
   • The Technology
   • Spamming in the Future
5. Internet Basics
   • Addresses
   • Protocols
   • Email
   • Usenet News
   • Instant Messages
6. A User's Guide to Email Spam
   • Safeguarding your email Address
   • Filtering Junk Mail
   • Responding to Junk Mail
7. A User's Guide to Usenet Spam
   • Filtering News
   • Responding to Spam
8. Spam Stopping for Administrators and ISPS
   • Policy Choice
   • Blocking Incoming Spam
   • Stopping Outgoing Spam
9. Community Action
   • Sharing Information
   • Group Action
   • Legal and Legislative Action
   • Informing the Public
10. A: Tools and Information
11. B: Cyber Promotions Timeline
12. Index

CowboyNeal has, after a long and careful review, sent us a review of Peter van der Linden's Just Java and Beyond. This is a great book for people learning Java-so click below if you are just learning, or are curious. Just Java and Beyond author Peter van der Linden pages publisher Sun Microsystems rating 9 reviewer CowboyNeal ISBN 0-13-784174-4 summary ow! I wish I had this book when I first learned Java. Well-organized and easy-to-read for beginners, this book is perfect for anyone who wants get his/her feet wet in Java. What's Good? Everything. Seriously, the examples are in-depth and well explained, while each chapter has a brief section at the end entitled "Light Relief" which shows how that chapter is relevant to the big picture and/or gives a small anecdote from the author's past. The sections on the Java event-handling model (one of more difficult parts of Java) are well done and even take the time to compare and contrast the Java 1.0 event model and the Java 1.1 event model. I also found the section of Java threads to be particularly outstanding. Not having much background in parallelism myself, I was able to understand the entire concept better, as well as how Java implements it. What's Bad? Almost nothing. When I first read this book, I had a difficult time doing so because many of my friends and coworkers would hoarde it for their own use. The one downside I found is that there are no place where I can find a list of classes, function calls, etc. Although this is not a reference/nutshell book, that is a feature I always like to see. Those looking for a quick reference may be disappointed by Just Java and Beyond. Who should buy this book? If you have no previous experience with Java and want to start learning it, this book is one of the best. I've read countless Java books and this one is both enjoyable and informative. If you are looking for a Java reference, this book may fit the bill, but it's still geared for first-time learners.

Buy this book here.

Table of Contents

Introduction

Using the Just Java CD-ROM

Acknowledgements

1. What Is Java?
2. The Story of O: Object-Oriented Programming
3. The Java Programming Language
4. Java Building Blocks
5. More Sophisticated Techniques
6. Practical Examples Explained
7. All About Applets
8. Utilities And Libraries
9. The Abstract Window Toolkit
10. Graphics Programming
11. Java Foundation Classes (JFC) Preview (Swingset)
12. File I/O
13. Networking in Java
14. Future Developments

Appendix A: The Obsolete JDK 1.0 Event Model

Appendix B: Powers of 2 and ISO 8859

Index

A.M. Kuchling has sent a review of Jeffrey D. Ullman's book Elements of ML Programming. The book is fairly technical in nature, so if you are interested in learning more-well, you know the drill. Elements of ML Programming author Jeffrey D. Ullman pages publisher Prentice Hall rating 8 reviewer A.M. Kuchling ISBN summary A quite technical (but not boring) book that covers functional programming in ML.

This slim book is a fine introduction to the ML programming language, and is worth reading by anyone interested in learning about functional programming. It starts off by teaching you about simple expressions and ML's basic data types, covers writing recursive functions to perform common tasks, and by the end is discussing data structures and information hiding. There are lots of examples and exercises, which you can try out by downloading the SML/NJ implementation. Ullman's writing style is simple and clear, so it's not difficult to understand, and I really enjoyed reading it (sadly a rarity with technical books these days).

ML is mostly a functional language, though it supports some degree of imperative programming, and is an elegant system worth attention. The language has some novel features; my favorite is its automatic type inference. A friend of mine once observed that many programming bugs stem from type mismatches, and points out that because of ML's strict type inference and checking, once you get an ML program to compile successfully it often produces correct results. (Getting to the point of compiling correctly, however...) For example, look at the following interaction with the SML/NJ interpreter:

- fun sumlist( nil ) = 0
= | sumlist( x::xs ) = x + sumlist(xs);
val sumlist = fn : int list -> int

ML is smart enough to figure out that the resulting sumlistfunction takes a list of integers as input ('int list') and returns an integer ('-> int'). It can therefore report an error if you attempt to pass it a list of real numbers:

- sumlist( [1,2,3] );
val it = 6 : int
- sumlist( [1.0,4.0,2.0] );
stdIn:31.1-31.25 Error: operator and operand don't agree [tycon mismatch]
operator domain: int list
operand: real list
in expression:
sumlist (1.0 :: 4.0 :: 2.0 :: nil)

Even though it may be unlikely that you'll write a large program in ML or get a job through your ML knowledge, that should matter to market-driven drones. Hackers should read this book because it demonstrates a style of programming which will twist your thinking around, and benefit your programming in more conventional languages.

But this book over here.

Table of Contents

1. A Perspective on ML and SML/NJ
2. Getting Started in ML
3. Defining Functions
4. Input and Output
5. More About Functions
6. Defining Your Own Types
7. More About ML Data Structures
8. Encapsulation and the ML Module System
9. Summary of the ML Standard Basis

My own literary-review Santa Claus A.M. Kuchling has sent in a review of Sean McGarth's book XML by Example. A book designed not for technical specifications, but for covering the issues arising in XML-like it's applicability in e-commerce, for example. For more information, and if you want to learn more, click below. XML By Example author Sean McGrath pages publisher Prentice Hall rating 6 reviewer A.M. Kuchling ISBN summary A good overview of XML and the surrounding landscape of Document Type The Scenario

Subtitled "Building E-commerce Applications", this is a fairly high-level look at XML, concentrating on financial and commercial application areas. The first chapter explains the basic ideas and history underlying XML, followed by three chapters about potential XML applications and their benefits, and some quick looks at emerging standards such as XSL (XML Style Language) and XLL (eXtensible Link Language). The middle sections have the most technical content: chapter 5 describes the basic syntax of XML, and chapter 11 revisits the syntax in more detail. Chapters 6 through 9 implement some simple applications using different languages such as JavaScript, Java, and Python, and chapter 10 discusses writing little scripts to make one-time searches and modifications to XML files. This is followed by chapters on the then-current drafts of XLL, XSL, and DOM. The final section returns to the high-level overview of the first section, and rounds out the book with a brief chapter on mixing SGML and XML, and 3 more chapters on various E-commerce initiatives.

What's Bad?

I suspect this book may not be low-level enough for some (most?) Slashdot readers -- it spends relatively little space on technical details. Most of the pages are devoted to general descriptions of different DTDs; for complete information about the topics covered, you'll still have to read the relevant recommendations or working drafts. Time is also cruel to XML books; the XSL coverage has been made outdated by massive changes to the current XSL working draft. The book is also marred by poor copy-editing and typography, a fault disappointingly common in Prentice Hall's XML series; I would expect better from the publisher.

What's Good?

The technical explanations that are given, particularly the two chapters on XML syntax, are as good as any I've seen. McGrath definitely has the qualifications you want from a computer book author; he founded Digitome, an SGML/XML consulting company, and has written other articles and books about SGML and XML.

For a long time, if someone asked me "What should I read to learn about the potential applications for XML?", I would recommend the XML issue of O'Reilly's W3 Journal, even though it was quite outdated. I will now begin recommending XML By Example as a more recent overview, slanted toward financial and commercial applications.

So What's In It For Me?

XML by Example would be a good book to give to a boss, or for anyone who want a wide overview of the ongoing activities and standards related to XML. But be aware that XML By Example doesn't dive into low-level details much; programmers might be happier just sitting down and reading the various W3C specifications and working drafts.

Buy this book over here.

Table of Contents

1. XML - An Executive Summary
2. XML in Action
3. The Commercial Benefits of XML
4. Gaining Competitive Advantage with XML
5. Just Enough Details
6. Using XML with Internet Explorer 4
7. Database Publishing with XML
8. Web Automation with WIDL (Web Interface Definition Language)
9. Push Publishing with CDF (Channel Definition Format)
10. Developing XML Utility Programs
11. The XML Standard
12. XML Hypertext Linking with XLL
13. XML Formatting with XSL
14. The Unicode Standard
15. The Document Object Model
16. Raiding the SGML Larder
17. OFX - Open Financial Exchange
18. XML/EDI - XML and Electronic Data Interchange
19. Open Trading Protocol

Yes, it's a milestone many of you thought would never happen: a Slashdot book review on ActiveX. Jon Veal wrote this review up and sent it our way. For those of you who haven't seen this little treasure, think the words "comic novella". Click below for more. Mr. Bunny's Guide to ActiveX author Carlton Egremont III pages publisher rating 10 reviewer Jon Veal ISBN summary A very short and funny book explaining the basics of ActiveX. The Scenario A book about Active X in less than 100 pages ? Well as you might guess from the title this is not an ordinary computing book. It is a humourous look at Active X. Starting with the concept of the pixel, Mr Bunny explains topics such as the Windows registry, Visual Basic 5 and the Internet to Farmer Jake. (Farmer Jake represents a Computer Professional.)

This is not a serious book. Very little useful technical information can be gained from it, however it is very funny. It could be considered to be anti-microsoft. There are lots of digs about the registry and the stability (or lack of) of Visual Basic.

What's Bad? The sense of humour of the writer might not be to everyones taste. It is certainly not a good guide to activeX for that you should look else where.

What's Good? It makes a refreshing change from other computing books. Useful tips include: 'Do not use matches near the windows registry'.

The technical content of the book is correct so it is possible that someone might actually learn something from the book.

So What's In It For Me? I wouldn't have believed that a book with 'Active X' in the title could make me laugh out loud. Check out the web-site for quotes from the book (http://www.mrbunny.com) Overall a very entertaining read but don't expect to gain anything useful from it.

Buy this book over here.

Table of Contents Chapter 0: The Adventure Begins

Chapter 1: The Case for Component Based Software

Chapter 2: The underpinnings of ActiveX

Chapter 3: Inside the Registry

Chapter 4: Visual Basics

Chapter 5: ActiveX Controls

Chapter 6: Delivering the Goods

andrew cooke sent us one of our rare fiction reviews. This book, The Aardvark is Ready for War (No, I don't think it's a Cerebus reference) was the work of James W. Blinn, with Michael Pietsch as Editor. An interesting alternative to history, with the slant of technology. Click below to read more. The Aardvark is Ready for War author James W. Blinn pages publisher rating 8 reviewer Andrew Cooke ISBN summary Geek 22

Andrew (grinning broadly and downloading Erlang!)

The Scenario

The Gulf War was the first Geek War: an armada of high-tech computerised killing machines from the world's greatest military power, sent to destroy the towel-heads. Action at a distance. Remote control. Technical superiority. Overwhelming firepower. Smart weapons. Surgical precision carpet bombing. Primetime TV. CNN. We HAVE the technology...

What's it about?

This book is about technical alienation.

This angry book is about an alienated technician - a SENSO - trying to separate the real from the virtual. It explores the problems technology (and the unequal distribution of technology) has created. Consider, for an example, the information content of today's media information.

If that sounds too intellectual don't worry: there's plenty of violence, drugs, drink, death, and laughs.

At the start of the book the "hero" has placed a woman in the opposite building under surveillance. As he watches her it's soon clear that he is obsessed less with sex than with technology, mortality, and his video camera. He uses hardware, particularly his handicam, as a shield to separate himself from reality.

On the aircraft carrier, heading to the Gulf, his job is to listen for submarines. Faced with a difficult situation - he loses the signal - he hacks a false detection. But as the war grows closer he begins to find himself in situations he is less able to control, or understand. Situations where technology offers no protection.

By the final chapter he is terrified, his life depending on technology that he no longer trusts...

What's Good?

At times, this book is very funny.

The humour sharpens some serious criticism of war (the details describe the Gulf war, but the conclusions are general), America (of which Britain - I am british - is a small, unmentioned colony), technology, surveillance, simulation, and information.

The Aardvark is Ready for War also raises questions that aren't often addressed on Slashdot. It suggests you step back from the excitement and ask - if only for a moment - what we are losing as we rush to embrace more technology.

Aside from the vicious moral comedy, there are some fascinating technical details. Is that really how they detect submarines? The author was in the US Navy for nine years (it says here) so either it's true, or he knows his bullshit (and if this picture of navy life is accurate, then I guess it might be the latter).

What's Bad?

There's not much to criticise: you could ask for better characterisation (some convincing female characters?); perhaps the laughs could be a bit thicker on the ground, especially near the start; more continuity in the plot, maybe. But there's only going to be one Catch-22 this century, and it's already been written.

Maybe here, near the end of my review, I should also point out that reading the book will place any offensive language - "towel heads" for example - in context.

So What's In It For Me?

An alternative to reading Heller again. A history book for technophiles. A wake-up call for the digital generation?

Footnote

Maybe I'm showing my age by assuming that everyone has read Joseph Heller's book Catch-22. If not, well, now you know what I'm referring to above (and read it!).

Pick this book up at here.

Andrew G. Feinberg sent in a review of Richard Petersen's endeavor Linux Programmer's Reference. The book itself is a guide to scripting and other mini-languages, so if brushing up on that looms in your future, click below to read more about it. Linux Programmer's Reference author Richard Petersen pages publisher Osborne/McGraw-Hill rating 9 reviewer Andrew G. Feinberg ISBN summary A reasonable, small book to mini-languages. The Scenario I was looking for a good book to read that had nothing to do with computers, when this little (and it is little) book caught my eye. It looked like it was going to be a huge book, but all it is is a little guide to scripting and other mini-languages.

What's Bad? The title is a bit misleading, but otherwise that is the only bad thing about the book.

What's Good? Everything else! It's not a heavy read, but it's a quick tutorial and reference on shell scripting (bash, tcsh, and my favorite, zsh). It also touches on make, rcs, creating man pages, and tcl/tk. The book also sports a section on LaTeX (a quickie). It's no camel book, but it's cool. Oh, yeah. It also rounds out the mix with a section on gcc and g++. Fun for the whole family.

So What's In It For Me? If you do alot of shell scripting for quick-and-dirty tasks, this book lets you look up more advanced stuff, as well as the cool trick you forgot. It also teaches you how to package a program, and write documentation. I keep it on my desk where I can see it, so if I need to look up a function, it's there.

Pick this book up over here.

Table of Contents

1. Chapter 1: BASH Shell Programming

1. Chapter 2: TCSH Shell Programming

1. Chapter 3: ZSH Shell Programming

1. Chapter 4: Compilers and Libraries

1. Chapter 5: Development Tools

1. Appendix A: PERL - Quick Reference

1. Appendix B: Tcl and Tk

1. Appendix C: TeX and LaTeX

When I put out my call for Geek Christmas Gift ideas, I had no idea what I was in for. But after the storm of email that followed was washed away, I was left with a list of toys that any geek would be excited to give or get this year for whatever holiday it is you celebrate this time of year. Hit the link below and read the list if you're curious. Random Stuff There were a few things that were suggested, that, well, I bet Santa won't come through for them. Hemos asks for Nanites. Thats all he wants. Nanites. Somebody smack him. Nima Negahban says "I would like the beowolf cluster avalon for christmas, dont worry about it fitting it under the tree. " david yates wrote in and simply said "Half naked Princess Leia ,as Jabba's prisoner, action figure." I'm sure his mother is proud. He can have the Action Figure, I want 1976 Carrie Fisher. Games Everyone and their brother wrote in to say that Nintendo 64's and Playstations are great. And the game of choice is definitely Zelda 64. I second that motion. I suggested it to my dad as a Christmas Present. Terrible idea- now I gotta wait until xmas to find out if he got it, and if he *didn't* I gotta buy in on Dec 26. Hard as hell to find. Folks suggested other things like the original Kings Quest or Leisure Suit Larry. Prince of Persia. Commander Keen. Ultima. All those games that aren't around any more, but with their original packaging. Finding a 5.25" drive to play them with might be a tad tricky tho. Clothing It's a well known fact that its better to be clothed at least part of the time. And no self respecting geek should be without a vast array of appropriately political t-shirts to pad out your closet full of suits, jackets, and ties (cough). Daniel suggested checking out the Free BSD Mall for BSD clothing. Jonathan Moore suggested the ever popular KMFMS t-shirts for your local microsoft hater. If thats a bit to exotic for you, how about the classic that Doug Boettcher sent us: the Hack Naked shirt. Since we're mentioning all these t-shirts, we ought to mention that CopyLeft has several shirts including my Don't Fear the Penguins ones, and Slashdot ones too. Software Several folks wrote in to say that they were buying Linux CDs from any of the various places that sell them, and giving them away to the needy. I tend towards Linux Central, and in addition to them Cheap Bytes OpenBsd.org and The Linux Mall were all suggested as places where you can buy the stuff we like. Hardware By far the largest catagory for gift ideas was of course Hardware:The Gift that Costs to much. Of course, anyone would want a a Palm III- it's hard to think of a better stocking stuffer. And besides, they're practically money in the bank now that you can use them to collect automobiles of the rich and famous. But if you've already got a Pilot, James A. Hillyerd suggests a GoType keyboard as the perfect accessory. If the pilot isn't your bag, but you want to read on the road, Mahlen Morris suggested A Rocket E-Book which is basically a tablet computer that is designed to replace books You can get them here. And apparently they have some sort of deal with Barnes & Nobles so you can get content to read on it. They're pretty sweet looking- someday we'll have a wireless version with net access, then we can forget paper. But for now, this'll do.

Have trouble remembering passwords? Digital Persona sells sweet hardware that that you can use to do finger print identification. Suggested by Andrew Lepisto. The pdQ was suggested by Adam D. McKenna. Its a cel phone with an integrated Pilot. Another fairly common suggestion for geek gifts was cel service from your local provider, and a cel modem for the laptop equipped gift getter. Sean McPherson suggested a Kodak DC210+ digital camera. Saves big bucks on film, and is supposed to be supported by SANE. I'm actually planning on getting a Digital Camera before the upcoming string of conferences, and I'll probably look at this one (unless Santa already has one in his bag for me, although at $400 a pop, I highly doubt it) Steven McDonald suggests that we look at DVD RAM Drives as a new huge backup device for storing your MP3s and Porn. Oh, and legit data too.

Mike Miller sent us several suggestions including the Happy Hacking Keyboard. I played with one at ALS- they're not bad. Just as cool are the new Color Gamesboys. I suppose tetris wouldn't be vastly improved by color, but its still pretty sweet. For those with a hugeass budget, How about your very own Alpha Cluster? Obviously Jakob is a lot more hopeful for Saint Nick than I am this year *grin*. How about a vt320 Terminal? Daniel Morrison suggested it, and I think it sounds pretty cool. I had a terminal attached to one of my Linux boxes for awhile. I Let it tail log files and stuff. Kinda fun for reading documentation and stuff too. Can't afford a Multi-Head X-Server, video card, and spare monitor anyway. Plus you can run them into another room and check your email from your kitchen/dining room/bathroom.

Matthew J. Allen sent us a pricey one, but its oh so sweet: Remember those Huge Flat LCD Screens from SGI? I sure do. I wake up after erotic dreams about them. (SUBLIMINAL MESSAGE:Hey SGI: Give Rob one of those things for banner ads. You've got a spare one just sitting around, right?). Matthew also suggested an Iomega Clik Drive if you're on a more reasonable budget. Those things do look pretty sweet. Do cables piss you off? How about the gift of a tangle free workspace? Scott Donovan sent us a link to Cordless Mice and Keyboards from Logitech that will free you up for spinning on your swivel chair really fast until you fall over from getting dizzy instead of getting tangled up in your keyboard cable.

Toys By far the single most suggested toy of all was the Lego Mindstorms. The robotic legos are quite possibly the coolest toy in the history of toys. They aren't cheap, but they are oh so sweet. Else you could consider X-Files Action Figures suggested by E. Waugh. Home Entertainment and Audio Gear The Panasonic Portable DVD Theater was sent in by Joel Telling. Its a tiny portable DVD player obviously designed to make me froth at the mouth like a rabid dog. Several folks wrote in to suggest something I would like, but I wouldn't want to froth on. The Empeg Car CD Player. We've mentioned this before, and although they won't be ready for christmas, they are pretty amazing. 2.1 gigs of MP3s in a car stereo. They need a 9 gig version mounted in a home stereo component too.

Jon Jones (is that a real name? *grin*) wrote in to send a link to ADB I/O which you can use to automate your home for the ultimate in comfort and/or laziness. For the true audio junkie, how about the THX Speakers sent in by Chad R. Henry. Sure, they cost more than my car, but I bet they sound amazing. If you're on a more modest budget Cambridge SoundWorks has some slightly more reasonably priced speakers that I'm told sound awesome. Andrew Hobgood suggests checking out Panasonic SJ-MJ70 MiniDisc Player (portable). Pretty sweet if you aren't willing to chance it on the Diamond Rio (which was also one of the most common suggestions). Frankly any geek should be excited to get either. Rob Sheehy pointed out that Philips has 42 inch widescreen flat TVs that you could hang on your wall if you happen to be rich and wanna watch letterbox movies. This one has a VGA input too.

Random Terry A. Braun suggests that geeks need to get into making our own beer. Sounds like a great idea to me, although I tend to screw up toast. But if you're man enough to try it, you can get Your Own Grain Mill. Alan Mathews wrote in to suggest a A dilbert M&M dispensor McPhee's has some strange stuff, including a Punching Nun suggested by Glen Lipka Tom Berger suggested A VI Command Set Mug STriker RedWolf sent us a link to a chocolate bar shaped like a Pentuim II Chip.

Jason Grundy suggests the $6 card game Kill Dr. Lucky and a Card both from the aptly titled Cheapass.com. Rob Pelkey sent in a pair of gift ideas that are a world apart. The first is An Authentic Moon Rock and the second is a Jesse Ventura T-Shirt or Bumper Sticker. One is probably worth a little more than the other. The concept kitchen has this wierd Finger Stylus Thingee that you can use instead of a pen for some pen machines. Kinda wacky. Sent to us by Wyatt Earp.

Justin Higgins suggests that geeks should all own a copy of the Star Wars Radio Drama. Sure, it costs almost a hundred bucks, but at 15 CDs, it balances out to almost be a bargain. They ought to package it on 1 CD full of MP3s, throw a copy of the script on the disc and sell it for $20. I'd never heard of the Leatherman Wave before, but several folks emailed me to say they are cool. And then I noticed that they were actually advertising here. Shows how much attention I pay to who advertises on my own site I guess. But still several people raved about them, claiming that they're ideal for mucking around inside computer cases with. And Traci Earl sent a link to a site that makes nice Leather Cases for them.

Do you think stuffed animals are stupid? Well how about a Stuffed Plush Space Shuttle? Dave Brunberg sent us that gem. Stirling Westrup sent in a link to something called the Hoberman Sphere which basically is a crazily designed sphere thingee that expands from 9.5" to 30". Crazy looking. If you're looking for something caffienated that you can put in your mouth, several folks reminded us about caffienated penguin mints.

Wrap Up Well this was fun guys. Spending hours looking at crazy things that I can't afford has convinced me to take up cracking banks as an evening hobby. But what is quite obvious is that 1998 is a good year to be a geek. And maybe in 1999 Hemos can have his nanites. Nah.

And lastly, with all the commercial hub bub that tends to go on during this season, don't forget the true meaning of Christmas: Ham.

Arjen Laarhoven has taken some time to send in a review of W. Richard Stevens' book Unix Network Programming, Vol. 1. Obviously the first in a series, this is an updated version of the original, introduced in 1990. This book covers new concepts from the original, from multi-threading to IPv6, in addition to the rest of knowledge this tome contains. Click below to read more. UNIX Network Programming, 2nd Ed, Volume 1; Networking APIs: Sockets and XTI author W. Richard Stevens pages publisher Prentice-Hall, Inc. rating 10 reviewer Arjen Laarhoven ISBN 0-13-490012-X summary This new edition of UNIX Network Programming explains almost every detail of network programming on the UNIX platform thoroughly and clearly. New concepts which have become mainstream since the first edition of 1990, like multithreaded programs are explained, as are the mechanics of IPv4 and IPv6 interoperability which will become important in a few years.

When you start with UNIX programming, and have mastered the basics, the first thing most people want to try out is network programming (at least, I wanted to :-). A lot of people who work with UNIX or Linux have access to a networked environment, and work with networked applications and tools on daily basis. There are a lot of papers and tutorials on socket programming floating around on the Net, but these mostly describe the basic mechanics. In a very short time, you can create small client-server programs which work quite nice. But there is a lot more to UNIX network programming than just being able to open sockets and send data back and forth.

At this point, this new edition of UNIX Network Programming enters the scene. The material from the first edition (almost 9 years old now) is greatly expanded to describe todays standards and new additions to the UNIX environment, like multithreading and IPv4/IPv6 interoperability.

This new edition of UNIX Network Programming is split into 3 volumes, of which 2 are published (Volume 2 is "Interprocess Communications", and 3 will describe important networking applications which). The main reason for this split is that the topic of network programming has expanded much since 1990. Also, the individual topics are much more elaborately described than the first edition.

An important addition to this new edition is the use of multithreaded programs in addition to the fork and select implementation models. Multithreaded programs are a hot topic these days, as they make network programming easier in a lot of situations, and perform better on platforms with multiple processors.

Another important topic is the use of IPv6 and its interoperability with the current IPv4 standard. A great deal of information is provided about making programs protocol-independent. This will be an important part of network programming, when IPv6 becomes more mainstream.

The first edition of this book described more protocols than just TCP/IP. Now, almost 9 years later, TCP/IP is the clear winner of the battle with protocols like OSI and XNS. Also, the socket API for network programming has become the "de facto" standard. But the socket API is not the only one which is described. The last part of the book describes the XTI (the X/Open Transport Interface) networking API, which originated at SysV and is part of the X/Open Unix 98 specification. Some parts of the interface has provisions to accommodate these other protocols, and are mentioned where applicable, but the focus is on TCP/IP

Other nice things are the coverage of the low-level networking APIs, like the BPF (BSD Packet Layer Filter), the DLPI (Data Link Provider Interface) and the Linux (!) SOCK_PACKET interface. These 3 interfaces are mostly platform and/or OS dependent, so there is also information about the libpcap library (used in tcpdump, for example), which provides portable access to these low-level networking capabilities.

Not all the things described in UNP2V1 are available on all UNIX platforms, so some things will not work on the platform on which you are developing your network applications. But most UNIX vendors are hard at work to implement all the standards. Sun Solaris and DEC UNIX 4 are currently the most capable platforms in this respect. There is good information on the networking capabilities of Linux, and the Linux community is hard at work to let it adhere to the standards decribed in this book.

What's in it for me? If you are looking for more in-depth information about creating networking applications on the UNIX platform, UNP2V1 is for you. Not only descriptions of the various functions are provided, but things are explained thoroughly and often accompanied by example programs, which you can run and tinker with. Every chapter is ended by a section of exercises, with which you can test your understanding of the material covered in the chapter. Not only theoretical questions are asked, but a lot of exercises require you to compile, run and change the example programs and figure out what is happening because of the changes.

Instead of just describing the interfaces, there is also information provided on how the TCP/IP protocol works. Stevens has found it very enlightening to know some of the mechanics of the protocol, because you know what is going on "under the hood" and can track down problems very quickly. In some discussions, Stevens refers to his TCP/IP Illustrated series, which provide much more details on the complete TCP/IP protocol suite.

Debugging is a large part of the programming process, and network programming requires some additional tools to diagnose and solve problems in network applications. Stevens explains how to use tools like netstat, tcpdump, ifconfig and his own sock programs to help you debug your network applications.

Designing a network application (and especially servers) can be done in various ways. The most important concepts are the forking model, the select model and the use of multithreading. In a separate chapter, Stevens describes the pros and cons of the different models, illustrated by examples and performance measurements. This way, you can make an informed decision on how to design your network application.

What's Good? The first printing did not provide enough information in the captions of the example programs. Stevens goes through a number of revisions of a program, to include the information just covered. The problem was that you did not know if a program was not optimal or even buggy, unless you read the text. This has been changed in the new printings. Also, the first printing has a lot of typos, and some errors but these bugs have been fixed in the new printings. Stevens maintains a very detailed errata list, so you can debug your copy of UNP2V1 if necessary.

I think that you have to read through this book at least once to use it as a reference. This way, you know what is possible, and can look up the parts you want when you need it. This is not a bad thing IMHO, because you have to understand the basic concepts before you can do anything useful.

The information in the front and back of the cover help you to find important functions, macro's and datastructures quickly. Also, the index is very good.

I have heard people complaining there is no information provided on network programming using the Win32 platform. These people seem unable to read titles of books. Also, the standards described in this book are standards which are created by POSIX and X/Open, and the UNIX community itself. Therefore, it is highly unlikely that they will change radically in the future. Microsoft controls the Win32 API completely, and can do with it what they want.

What's bad? IMHO, nothing. I am aware that the book is not cheap, and that the split into multiple volumes also does not help to cut the price. But to find out this kind of information in a depth comparable with what is described in UNP2V1 yourself will cost huge amount of time (and in the case of a professional programmer, a lot of money). This review is about the contents of the books and the quality of information, and not about price.

Stevens keeps up-to-date errata on his home page, so when bugs or inconsistencies are discovered, you can find them quickly there. You can buy this book at Amazon.

Table of Contents (abbreviated) Part 1. Introduction and TCP/IP

• Chapter 1. Introduction
• Chapter 2. The Transport Layer: TCP and UDP

Part 2. Elementary Sockets

• Chapter 3. Sockets Introduction
• Chapter 4. Elementary Sockets
• Chapter 5. TCP Client-Server Example
• Chapter 6. I/O Multiplexing: The select and poll functions
• Chapter 7. Socket Options
• Chapter 8. Elementary UDP Sockets
• Chapter 9. Elementary Name and Address Conversions

Part 3. Advanced Sockets

• Chapter 10. IPv4 and IPv6 Interoperability
• Chapter 11. Advanced Name and Address Conversions
• Chapter 12. Daemon Processes and inetd Superserver
• Chapter 13. Advanced I/O Functions
• Chapter 14. Unix Domain Protocols
• Chapter 15. Nonblocking I/O
• Chapter 16. ioctl Operations
• Chapter 17. Routing Sockets
• Chapter 18. Broadcasting
• Chapter 19. Multicasting
• Chapter 20. Advanced UDP Sockets
• Chapter 21. Out-of-Band Data
• Chapter 22. Signal-Driven I/O
• Chapter 23. Threads
• Chapter 24. IP Options
• Chapter 25. Raw Sockets
• Chapter 26. Datalink Access
• Chapter 27. Client-Server Design Alternatives

Part 4. XTI: X/Open Transport Interface

• Chapter 28. XTI: TCP Clients
• Chapter 29. XTI: Name and Address Functions
• Chapter 30. XTI: TCP Servers
• Chapter 31. XTI: UDP Clients and Servers
• Chapter 32. XTI Options
• Chapter 33. Streams
• Chapter 34. XTI: Additional Functions

Appendix A. IPv4, IPv4, ICMPv4, and ICMPv6

Appendix B. Virtual Networks

Appendix C. Debugging Techniques

Appendix D. Miscellaneous Source Code

Appendix E. Solutions to Selected Exercises

Bibliography

Index

Links to Web pages related to UNIX Network Programming, Vol. 1

• W. Richard Stevens' home page
• Prentice-Hall's page on UNP2V1

Arjen Laarhoven has taken some time to send in a review of W. Richard Stevens' book Unix Network Programming, Vol. 1. Obviously the first in a series, this is an updated version of the original, introduced in 1990. This book covers new concepts from the original, from multi-threading to IPv6, in addition to the rest of knowledge this tome contains. Click below to read more. UNIX Network Programming, 2nd Ed, Volume 1; Networking APIs: Sockets and XTI author W. Richard Stevens pages publisher Prentice-Hall, Inc. rating 10 reviewer Arjen Laarhoven ISBN 0-13-490012-X summary This new edition of UNIX Network Programming explains almost every detail of network programming on the UNIX platform thoroughly and clearly. New concepts which have become mainstream since the first edition of 1990, like multithreaded programs are explained, as are the mechanics of IPv4 and IPv6 interoperability which will become important in a few years.

When you start with UNIX programming, and have mastered the basics, the first thing most people want to try out is network programming (at least, I wanted to :-). A lot of people who work with UNIX or Linux have access to a networked environment, and work with networked applications and tools on daily basis. There are a lot of papers and tutorials on socket programming floating around on the Net, but these mostly describe the basic mechanics. In a very short time, you can create small client-server programs which work quite nice. But there is a lot more to UNIX network programming than just being able to open sockets and send data back and forth.

At this point, this new edition of UNIX Network Programming enters the scene. The material from the first edition (almost 9 years old now) is greatly expanded to describe todays standards and new additions to the UNIX environment, like multithreading and IPv4/IPv6 interoperability.

This new edition of UNIX Network Programming is split into 3 volumes, of which 2 are published (Volume 2 is "Interprocess Communications", and 3 will describe important networking applications which). The main reason for this split is that the topic of network programming has expanded much since 1990. Also, the individual topics are much more elaborately described than the first edition.

An important addition to this new edition is the use of multithreaded programs in addition to the fork and select implementation models. Multithreaded programs are a hot topic these days, as they make network programming easier in a lot of situations, and perform better on platforms with multiple processors.

Another important topic is the use of IPv6 and its interoperability with the current IPv4 standard. A great deal of information is provided about making programs protocol-independent. This will be an important part of network programming, when IPv6 becomes more mainstream.

The first edition of this book described more protocols than just TCP/IP. Now, almost 9 years later, TCP/IP is the clear winner of the battle with protocols like OSI and XNS. Also, the socket API for network programming has become the "de facto" standard. But the socket API is not the only one which is described. The last part of the book describes the XTI (the X/Open Transport Interface) networking API, which originated at SysV and is part of the X/Open Unix 98 specification. Some parts of the interface has provisions to accommodate these other protocols, and are mentioned where applicable, but the focus is on TCP/IP

Other nice things are the coverage of the low-level networking APIs, like the BPF (BSD Packet Layer Filter), the DLPI (Data Link Provider Interface) and the Linux (!) SOCK_PACKET interface. These 3 interfaces are mostly platform and/or OS dependent, so there is also information about the libpcap library (used in tcpdump, for example), which provides portable access to these low-level networking capabilities.

Not all the things described in UNP2V1 are available on all UNIX platforms, so some things will not work on the platform on which you are developing your network applications. But most UNIX vendors are hard at work to implement all the standards. Sun Solaris and DEC UNIX 4 are currently the most capable platforms in this respect. There is good information on the networking capabilities of Linux, and the Linux community is hard at work to let it adhere to the standards decribed in this book.

What's in it for me? If you are looking for more in-depth information about creating networking applications on the UNIX platform, UNP2V1 is for you. Not only descriptions of the various functions are provided, but things are explained thoroughly and often accompanied by example programs, which you can run and tinker with. Every chapter is ended by a section of exercises, with which you can test your understanding of the material covered in the chapter. Not only theoretical questions are asked, but a lot of exercises require you to compile, run and change the example programs and figure out what is happening because of the changes.

Instead of just describing the interfaces, there is also information provided on how the TCP/IP protocol works. Stevens has found it very enlightening to know some of the mechanics of the protocol, because you know what is going on "under the hood" and can track down problems very quickly. In some discussions, Stevens refers to his TCP/IP Illustrated series, which provide much more details on the complete TCP/IP protocol suite.

Debugging is a large part of the programming process, and network programming requires some additional tools to diagnose and solve problems in network applications. Stevens explains how to use tools like netstat, tcpdump, ifconfig and his own sock programs to help you debug your network applications.

Designing a network application (and especially servers) can be done in various ways. The most important concepts are the forking model, the select model and the use of multithreading. In a separate chapter, Stevens describes the pros and cons of the different models, illustrated by examples and performance measurements. This way, you can make an informed decision on how to design your network application.

What's Good? The first printing did not provide enough information in the captions of the example programs. Stevens goes through a number of revisions of a program, to include the information just covered. The problem was that you did not know if a program was not optimal or even buggy, unless you read the text. This has been changed in the new printings. Also, the first printing has a lot of typos, and some errors but these bugs have been fixed in the new printings. Stevens maintains a very detailed errata list, so you can debug your copy of UNP2V1 if necessary.

I think that you have to read through this book at least once to use it as a reference. This way, you know what is possible, and can look up the parts you want when you need it. This is not a bad thing IMHO, because you have to understand the basic concepts before you can do anything useful.

The information in the front and back of the cover help you to find important functions, macro's and datastructures quickly. Also, the index is very good.

I have heard people complaining there is no information provided on network programming using the Win32 platform. These people seem unable to read titles of books. Also, the standards described in this book are standards which are created by POSIX and X/Open, and the UNIX community itself. Therefore, it is highly unlikely that they will change radically in the future. Microsoft controls the Win32 API completely, and can do with it what they want.

What's bad? IMHO, nothing. I am aware that the book is not cheap, and that the split into multiple volumes also does not help to cut the price. But to find out this kind of information in a depth comparable with what is described in UNP2V1 yourself will cost huge amount of time (and in the case of a professional programmer, a lot of money). This review is about the contents of the books and the quality of information, and not about price.

Stevens keeps up-to-date errata on his home page, so when bugs or inconsistencies are discovered, you can find them quickly there. You can buy this book at Amazon.

Table of Contents (abbreviated) Part 1. Introduction and TCP/IP

• Chapter 1. Introduction
• Chapter 2. The Transport Layer: TCP and UDP

Part 2. Elementary Sockets

• Chapter 3. Sockets Introduction
• Chapter 4. Elementary Sockets
• Chapter 5. TCP Client-Server Example
• Chapter 6. I/O Multiplexing: The select and poll functions
• Chapter 7. Socket Options
• Chapter 8. Elementary UDP Sockets
• Chapter 9. Elementary Name and Address Conversions

Part 3. Advanced Sockets

• Chapter 10. IPv4 and IPv6 Interoperability
• Chapter 11. Advanced Name and Address Conversions
• Chapter 12. Daemon Processes and inetd Superserver
• Chapter 13. Advanced I/O Functions
• Chapter 14. Unix Domain Protocols
• Chapter 15. Nonblocking I/O
• Chapter 16. ioctl Operations
• Chapter 17. Routing Sockets
• Chapter 18. Broadcasting
• Chapter 19. Multicasting
• Chapter 20. Advanced UDP Sockets
• Chapter 21. Out-of-Band Data
• Chapter 22. Signal-Driven I/O
• Chapter 23. Threads
• Chapter 24. IP Options
• Chapter 25. Raw Sockets
• Chapter 26. Datalink Access
• Chapter 27. Client-Server Design Alternatives

Part 4. XTI: X/Open Transport Interface

• Chapter 28. XTI: TCP Clients
• Chapter 29. XTI: Name and Address Functions
• Chapter 30. XTI: TCP Servers
• Chapter 31. XTI: UDP Clients and Servers
• Chapter 32. XTI Options
• Chapter 33. Streams
• Chapter 34. XTI: Additional Functions

Appendix A. IPv4, IPv4, ICMPv4, and ICMPv6

Appendix B. Virtual Networks

Appendix C. Debugging Techniques

Appendix D. Miscellaneous Source Code

Appendix E. Solutions to Selected Exercises

Bibliography

Index

Links to Web pages related to UNIX Network Programming, Vol. 1

• W. Richard Stevens' home page
• Prentice-Hall's page on UNP2V1

Veteran reviewer SEGV has sent in his latest literary exploit, a review of Doug Lea's book Concurrent Programming in Java: Design Principles and Patterns. Not exactly a book for the beginning, this is design for those of you who know their way around Java, and are looking to firm up your theory base. Given the recent lawsuit end, it appears that a lot more attention is being focused on Java again. Let's trya nd get some real programming done for it. Concurrent Programming in Java: Design Principles and Patterns author Doug Lea pages publisher Addison-Wesley rating 8/10 reviewer SEGV ISBN 0-201-69581-2 summary Not for beginners, this advanced book is perhaps somewhat hard to follow in places but rewarding to those who persevere

Concurrent Programming in Java: Design Principles and Patterns,
by Doug Lea
[Addison-Wesley, ISBN 0-201-69581-2]

reviewed by SEGV[home]

Nutshell
Review:

Not for beginners, this advanced book is perhaps somewhat hard to follow in places but rewarding to those who persevere.

Rating: 8/10

A Book on Concurrent Programming

Concurrent Programming in Java is not just a book on Java threads. Rather, this 339 page book from JavaSoft's Java Series delves into the unique problems and solutions of concurrent programming. It just happens to use Java as its example language. Sure, you'll learn how to use Java constructs such as synchronized, volatile, wait, notify, and notifyAll. But you'll also learn how to put them together properly in an architecture that works.

The book has an online site with an excellent overview and supplement (containing errata, code, applets, and more).

Impressions

This was the first book dedicated to concurrent programming that I read. I absorbed it over the course of a month while dealing with serious threading issues in a major shipping product. Since then I've read half of Butenhof's Programming with POSIX Threads (which cites Lea's book), so I have a bit of perspective.

This is definitely not a book for the casual reader. If that's what you need or want, check out the aforementioned Butenhof book. They each deal with concurrent programming in general, but Butenhof's is easier to read (even has cartoons), explains things more accessibly, and overall is a better introduction.

However, if you want a book with no holds barred content, without frivolous diagrams and overblown examples, then this is it. It's a tough read. You have to work to understand how the examples illustrate the text. But we are better off that Lea does not spoon feed us. I came away from this book with a greater understanding of concurrent programming, and to that end it succeeded.

Content

From the table of contents you can see that Lea begins with an introduction. Not only does it frame subsequent chapters, it contains an 8 page further readings section containing references on everything from threads in particular to related topics in general. Subsequent chapters also have a further readings section, though not as overwhelming as the first.

Chapters two and three cover safety and liveness issues, the Scylla and Charybdes of concurrent programming. The former ensures that your program works correctly (eg, no race conditions or deadlocks), and the latter ensures that it does so effectively (ie, not reduced to a single thread). Lea doesn't just explain the pitfalls, but demonstrates the designs and techniques to get around them.

The next chapter covers controlling a thread's action based on its state. I found the discussion of policies of how to proceed when in the wrong state particularly useful. And of course guarded suspension is pivotal in concurrent programming.

The final four chapters take us from raw building blocks to higher level constructs. Lea introduces patterns which serve to control concurrency, allow for services, organize flow, and coordinate everything. Need to solve the readers and writers problem? Want to join a few threads? Perhaps you need to use an assembly line? Or maybe you're interested in transactions? These chapters have all that, and then some.

Summary

I find this book useful, even when I'm not doing Java. The only thing that stops me from purchasing my own copy is that another is readily accessible, and I hope that a second edition will come out that I can get instead!

It's a good book on concurrent programming. I just think it is only worth tackling if you have a strong backing in computer programming, and perhaps design patterns. Then, the text will make more sense and will serve as a good reference.

If you're more of a beginner or intermediate, I'd look elsewhere for a more appropriate book. You'll be better served than by struggling through this one. But certainly come back to it when you can!

Pick this book up at Amazon.

TABLE OF CONTENTS

Preface
Introduction
Applications of Concurrency, Overview, Java Concurrency Support, Further Readings
Safety
Safe Objects, Immutable Objects, Fully Synchronized Objects, Contained Objects, Further Readings
Liveness
Liveness Failures, Instance Variable Analysis, Splitting Synchronization, Further Readings
State-Dependent Action
Policies, Representing State, Guarded Suspension, Balking, Further Readings
Concurrency Control
Subclassing, Adapters and Delegation, Acceptors, Models and Mappings, Further Readings
Services in Threads
Styles and Policies, Commands, Completion, Group Services, Coexistence, Further Readings
Flow
Applications, Flow Policies, Resource Management, Assembly Line, Further Readings
Coordinated Action
Transactions, Notification, Scheduling, Further Readings
Index

Well, Jon Katz has sent in his first book review, The Man Who Loved Only Numbers, written by Paul Hoffman. This is literary tribute to the life and work of Paul Erdos, the eminent mathematician that died last year. Click below to read more about a true geek. When they build the Geek Hall of Fame, in some musty corner of MIT or in a dingey loft in San Francisco's Mission District, there surely will be a corner reserved to honor the mythic mathematician Paul Erdos, whose odd and poignant life is vividly captured in the "The Man Who Loved Only Numbers," by Paul Hoffman (Hyperion, US $22.95).

Erdos, who died in l996, was one of the greatest mathematicians of the century, as well as a profound eccentric. Almost pure geek, he lived for decades out of two battered suitcases, frenetically criss-crossing the world, giving lectures, attacking problems, furiously publishing papers, and unnerving the friends he dropped in on unexpectedly.

If geeks are reputed to have few social skills, Erdos had none. He took the obsessive pursuit of knowledge to breathaking levels. He was allergic to amassing wealth, giving what little money he had to strangers, beggars and promising young students. He had no job, hobbies or home to tie him down. He was also unmarried, celibate and childless.

According to Hoffman, Erdos thought about more problems than any other mathematician in history. He wrote or co-authored 1,475 academic papers, many of them monumentally significant.

His life was the pure pursuit of the beauty, truth and knowledge he found in numbers. Mathematicians have long argued that numbers are about the only thing that can't lie or dissassemble. Erdos saw math as nothing less than the search for ultimate truth.

So he spent his life seeking out fresh problems to solve, hop-scotching continents, popping up on the doorsteps of fellow mathematicians to announce, "My brain is open," then staying to work with his hosts for a few days or until he got bored, meanwhile littering their homes with the potions and powders he used for his many skin ailments. Erdos' motto was "another roof, another proof."

He chafed at being pushed around by an omnipotent being he called the Supreme Fascist, says Hoffman, "the Number-One Guy Up There, God, who was always tormenting Erdos by hiding his glasses, stealing his Hungarian passport, or, worse yet, keeping to Himself the elegant solutions to all sorts of intriguing mathematical problems."

Erdos would frequently tell his friends that the SF "created us to enjoy our suffering. The sooner we die, the sooner we defy his plans."

Until then, though, Erdos worked on groundbreaking problems like Fermat's Last Theorem, and uniquely American ones like the "Monty Hall dilemma."

The Monty Hall dilemma is one of the many surprising, often hilarious glimpses of the odd nature of genius that Hoffman offers in this unexpectedly poignant book. Some of Erdos' prodigious gifts intersected with the popular culture in a distinctly American way.

"My only advice"-Monty Hall, host of the popular TV game show called "Let's Make A Deal," once told a guest, -- "is, if you can get me to offer you $5,000 not to open the door, take the money and run."

In a l990, Parade Magazine columnist Marilyn vos Savant, author of "The World's Most Famous Math Problem," shared with her readers a brain teaser submitted by a reader:

"You're on a game show and you're given the choce of three doors. Behind one door is a car, behind the other two are goats. You choose, say, door 1, and the host, who knows where the car is, opens another door, behind which is a goat. He now gives you the choice of sticking with door 1 or switching to the other door? What should you do?"

Vos Savant advised her correspondent to switch doors. Sticking with the first choice gives a one-third chance of winning, she said, but switching doubles the odds to two-thirds.

The resulting furor and controversy (imagine if the Internet had been in full bloom) over her mathematical reasoning obsessed geeks, TV viewers, contestants and math geniuses alike-eventually ensnaring even the great Erdos, who came across it at a friend's house.

To me, Erdos embodied the touching heart of pure geekness. An outsider, he never found a place to light. An obsessive, he foreswore wealth and creature comforts in favor of the pursuit of the beauty of information and truth. A grumpy rebel, he resisted and bristled at authority and any other entity that might come between him and the solutions he worked on day and night.

Generous with his genius, he transcended boundares, sharing everything he knew with everyone he met, with a special eye towards lifting up and encouraging the young. Before he'd consent to go under the knife during an eye operation, the doctors had to find a mathematician who'd talk numbers with him during the proceedure. If he was often impossible to be around, ill-tempered, self-absorbed and narcissistic, he enriched the world in immense and measurable ways. Erdos was suspicious of technology, and had little love for computers, but was awash with one of the geek's hallmark traits-an addiction for attacking puzzles, breaking intellectual barriers and gathering information.

A life as lonely and disconnected as Erdos's might strike us as a sad one. But as lovingly and engagingly recounted by Hoffman, Erdos's life is anything but. Adopted and embraced by a global community of scholars, friends and colleagues who took him in, clothed and fed him, drove him to the next aiport, and welcomed him into their lives.

That there might be other people like Erdos out there, willing and eager to forego most human warmth and material comfort in the pursuit of truth and wisdom is, as told here, and inspiring, even hopeful story. Buy this at Amazon and help Slashdot out.

Dan Zahn(Stumpy) has sent a review of Mark G. Sobell's A Practical Guide to Linux. This is not a book for the power-users amongst us, but is perfect for introducing people to Linux, or taking your casual relationship with Linux to the next level. So, if you want to advance, or you want to get someone on the bus, click below to read more. A Practical Guide to Linux author Mark G. Sobell pages publisher Addison Wesley rating 9/10 reviewer Dan Zahn(Stumpy) ISBN 0-201-89549-8 summary Excellent beginner and casual user guide REVIEW: A Practical Guide to Linux Mark G. Sobell (Addison Wesley ISBN 0-201-89549-8)

Nutshell
Review: Excellent beginner and casual user guide
Rating: 9/10 Dan Zahn(Stumpy) The Scenario New Linux user? Casual user who wants to learn more? Want to learn more about vi? Emacs? Shell programming in Bash, Tcsh AND Zsh? A quick introduciton to programmers tools on Linux?

What's Bad? This book is actually quite good for most of what it talks about. The only area I can really critisize is in their chapter on GUIs.

They discuss some very basic concepts. What is a mouse? (includes a picture) Bitmaped display devices. This chapter alone is like something for someone who hasn't seen a computer for about 10 years and who's only previous experience was a text terminal on a unix server. Also, they spent an inordinate amount of time on the Andrew User Interface system. Their example includes a short introduction to the ez editor. Odd how their pictures even show a XV window showing a screenshot of what must be an ez window. I've not been able to find this editor anywhere and all ever heard about it is it might be commercial. Can someone enlighten me on this?

What's Good? Everything else. The first 5 chapters walk you through Linux and how to use it. One of the features I really liked about this book is how they get into the history of alot of things and they don't skimp on the Linux history. They have a brief overview of Linux's capabilities. Getting into standard introductory programs and utilities. Ending up on the File system and the shell.

This is followed by two chapters on GUIs and Networking. These could probably have been placed a little later. The networking chapter covers an introduction to many networking utilities and some information about the internet.

Then some of the best chapters follow. These 6 chapters alone are reason enough to buy the book. The first two cover the two most used editors on Linux. There is the chapter giving a quite thorough introduction to the VI editor. It covers quite alot of it's commands and capabilites, teaching me alot of things I didn't know before. Then there is the chapter on Emacs. Those these are entirly different text editors, one of the nice parts of this chapter is how it discusses the same types of commands in roughly the same order as the Vi chapter. Then it gets a little deeper into Emacs, even going as far as to show a quick Emacs LISP language mode module. It gets pretty deep into Emacs for the 56 pages devoted to it. Enough for anyone to get started, only needing to dig into the help manual for obscure or unique commands or configuration.

The last 4 chapters of the reasons to buy this book give a very good explination of shells and shell programming. The first two are dedicated to Bash shell and Bash shell programming. The first chapter is more of an introduction of the concepts you will need in the next 3 chapters with just a little of Bash specifics, mostly to have to do with Bash configuration and simple shell programs. The next chapter those gets into the Control structures of Bash shell programming and explains some of the more advanced concepts of it. The next chapter covers the TC shell getting into how to use and and how to program for it covering the areas where it does not match the Bash shell. Finally ending up on the Zsh shell and the advanced programming capable with it. They cover it's relation to the Korn shell and how it differs and what it borrowed from other shells.

The last two chapters of Section 1 covering programming tools under linux, including Gcc, Make, gdb, RCS, and CVS and System administration. This information here on most of these programmers tools is very quick and just something to get you started. There are many better books to get you really programming in Linux. The RCS and CVS information is useful though and somewhat thorough. The System administration chapter covers backups and general practives that the home Linux user would want to do on their system periodically to clean it up.

Section 2 is a list of about 60-100 linux utility programs. Some or most of which already mentioned and possibly discussed in this book are giving alot better description and are dicsussed a little deeper.

The 4 appendices are quite useful as well. The first is a 10 page introduction to Regular Expressions, something everyone eventually should or is going to have to learn. The next is about 15 pages of quick troubleshooting questions and answers. This is followed by a very brief introduction to some emulator programs for linux.(A fullfillment of an earlier statement about how Linux can run other OS's software) Finally there is a section on the POSIX standards. This section seems out of place with most of the rest of the book. This is something even most diehards wouldn't bother reading. The history given is one of the few reasons to like this part.

Pick this book up at Amazon and help Slashdot out.

So What's In It For Me? If you want to know more about Linux, what you can do with it, how to do what you want to do, and how to make your life easier using it, this is the book for you. The forward written by Linus is definitly a nice touch. The information on text editors allows you to quickly take advantage of both editor's features. The Shell and Shell Programming information make it so you can write off your complex shell commands into a script. Also enough to let you write large utility shell programs that could do just about anything.

Table of Contents

1. Part 1: The Linux Operating System
2. Linux: A Prodcut of the Internet
3. Getting Started
4. An introduciton to the Utilities
5. The Linux Filesystem
6. The Shell
7. Graphicl User Interfaces(GUIs)
8. Networking and the Internet
9. The vi Editor
10. The emacs editor
11. The Bourne Again Shell
12. Shell Programming
13. The TC Shell
14. The Z shell and Advanced Shell Programming
15. Programming Tools
16. System Adminsitration

• Part 2: The Linux Utility Programs
• Regular Expressions
• Help
• Emulators
• The POSIX Standards
• glossary
• Index

Ranjit Mathew has sent a review of the second edition of The Essential Client/Server Survial Guide. This book, written by Robert Orfali, Dan Harkey and Jeri Edwards, has a pretty obvious point to it: trying to make sense of this gradiose world of "client/server programming". It's apparent that this is where much of programming work is heading, so click below, and read more. The Essential Client/Server Survival Guide, Second Edition author Robert Orfali, Dan Harkey and Jeri Edwards pages publisher John Wiley & Sons rating 8/10 reviewer Ranjit Mathew ISBN 0-471-15325-7 summary A somewhat dated yet comprehensive overview of REVIEW: The Essential Client/Server Survival Guide, Second Edition by Robert Orfali, Dan Harkey and Jeri Edwards [John Wiley & Sons; ISBN: 0-471-15325-7]

Nutshell
Review: A somewhat dated yet comprehensive overview of the bunch of technologies collectively known as "client/server programming". A most helpful survival guide for this new, exciting and rapidly expanding field.

Rating: 8/10

Review by: Ranjit Mathew The Scenario

The term "Client/Server" has been used in recent times to refer to a range of diverse technologies including, but not limited to, remote SQL, Transaction Processing, Groupware, Distributed Objects, etc. If you have ever found yourself wondering what any of the above terms mean, then this book is just for you. According to the publishers, this is "...the best source for anyone looking to understand and make informed decisions about client/server technology". I agree. The book is written in way that makes it accessible to a wide range of readers. The language is simple enough and witty cartoons, numerous quotes and opinionated soapboxes combine to make for easy reading.

What's Good?

The book is unmatched in the range of client/server technologies that it covers. The coverage is deep enough to let one feel relatively at ease with the topics and is sufficiently up to date to cover the state of the art at the time of publication (around late 1996). The whole book is divided into parts, each covering a particular client/server technology in depth, which can be read and assimilated almost independently. The authors also include helpful advice for designing, building and deploying client/server applications. The presentation style allows for easy reading yet manages to teach a lot. Quite well written.

What's Bad?

The very nature of the subject covered makes for a very short shelf life for this book. Books of this kind get outdated even before they reach the bookstores. For example, OpenDoc hasn't quite made it the way the authors had predicted it would. Important new technologies like e-Commerce, EJB, etc. look promising yet are not there in the book. Linux has emerged as a major player in the OS market (the authors haven't even acknowledged the existence of Linux in this edition) and has made high performance client/server programming quite affordable. It is high time the authors came up with a new updated and totally revised edition of the book.

The entire book is presented as a survival guide for visiting Martians who wish to make sense of the client/server brouhaha on Earth. (The foreword has been written by a certain "Zog the Martian".) The utility of this device in making this book more approachable by the layman is doubtful and is, at times, an unnecessary distraction (there is frequent talk of intergalactic(!) networks here).

So What's In It For Me?

If you wish to keep yourself up to date with the latest in client/server technologies, this book is for you. If you wish to know where the industry in general is headed to, these guys will tell you. If you find yourself bowled over by terms like SQL, TP-Monitor, CORBA, Groupware, OLE, DCOM, MOM, BLOB, etc. this book is definitely for you. Even if you do not have any immediate use for it give it a read anyway, it doesn't hurt to know about some of the new and emerging technologies. Remember, ignorance is not bliss, not in the IT industry anyway.

Buy the book from amazon.com.

Table of Contents

1. The Big Picture
2. Clients, Servers, and Operating Systems
3. Base Middleware: Stacks and NOSs
4. SQL Database Servers
5. Client/Server Transaction Processing
6. Client/Server Groupware
7. Client/Server With Distributed Objects
8. Client/Server and the Internet
9. Distributed System Management
10. Bringing It All Together

Andrew Cooke has sent us a review of Harold Abelson, Gerald Jay Sussman with Julie Sussman's book Structure and Interpretation of Computer Programs. This is not a book for those who are getting into coding for the first time-this is a nice, big MIT press book that assumes you're smart, and that you want to learn. So, if you want to check out what they think you need to do, click below. Structure and Interpretation of Computer Programs author Harold Abelson and Gerald Jay Sussman with Julie Sussman pages publisher The MIT Press rating 9/10 reviewer Andrew Cooke ISBN summary A huge range of practical computing knowledge, but more tutorial than REVIEW: Structure and Interpretation of Computer Programs Harold Abelson and Gerald Jay Sussman with Julie Sussman The MIT Press

Nutshell
Review: A huge range of practical computing knowledge, but more tutorial than bottled wisdom. With Scheme.
Rating: 9/10 Reviewed by: Andrew Cooke The Scenario

I am a software engineer: it is my responsibility to produce code that works, and that continues to work. I am also someone with no formal education in computing who wants to learn more about the science. My attention was caught by several reviews on the web about this book - it seemed to be one of the recognised classics of computing science - so I decided to educate myself.

What's in it?

By the end of the first chapter (of only five) I had a grounding in Scheme. I guess the book could be used by someone who has never programmed before, but they would have to be pretty sharp - there is little repetition.

The second chapter covers data structures and associated algorithms. Again, a lot of ground is covered very quickly.

After syntax and data comes a chapter on programming paradigms.

The final two chapters look at implementing new languages. Curiously (it makes sense in the context of the book, but how many readers will never have hacked assembler before reading this?), the book finishes with a discussion of register machines.

What's Good?

The range. No other programming book I have read covers so many topics. If I had to pick my three personal favourite Good Ideas, I would choose:

• Functional programming (no state - no assignment to variables - and yes, it does seem strange at first!).
• Closure in data structures (so a subtree looks the same as a tree - how does this conflict with careful typing?).
• (Infinite) streams (using lazy evaluation to generate sequences).

These are not all new to me (although I have always used imperative languages), but in every case this book let me see a lot more than before. No doubt someone else would take away a completely different set of ideas - have a look at the Contents to get an idea of what might interest you.

What's A Necessary Evil?

It is impossible to resist the temptation to review Scheme when reviewing this book. After reading the first few pages I was stunned: what kind of person would enjoy using a language like this?

Imagine waking up knowing you have to go to work fixing the bugs in code written by your colleague down the hall - and you are using a language that does not have static types, objects, or even loops!

After the first chapter I could live without loops and by the end of the book I understood why Scheme had been - and had to be - used. Nothing else I have seen is as flexible and compact (if we rule out J for its illegibility :-)

But I would still hate to use this language at work.

What's Bad?

Ultimately, this is a book written for students. If you have experience in software development then you have to be prepared to skim sections. Maybe I was naive, but the reviews I had read suggested this was pure distilled wisdom - it is not.

If the authors had been able to aim a little higher (already this book could easily be intimidating to a newbie programmer, so why not drop the very basic stuff completely?) then maybe they could have used a less compact, more easily read language, with type safety and multi-threading (I do not have a recommendation, but have a peek at ML).

So What's In It For Me?

An introduction to new good ideas. A reminder of old good ideas. Much thought.

Pick this book up over at Amazon.

Table of Contents

1. Building Abstractions with Procedures
   1. The Elements of Programming
   2. Procedures and the Processes They Generate
   3. Formulating Abstractions with Higher-Order Procedures
2. Building Abstractions with Data
   1. Introduction to Data Abstraction
   2. Hierarchical Data and the Closure Property
   3. Symbolic Data
   4. Multiple Representations for Abstract Data
   5. Systems with Generic Operations
3. Modularity, Objects, and State
   1. Assignment and Local State
   2. The Environment Mode of Evaluation
   3. Modelling with Mutable Data
   4. Concurrency: Time Is of the Essence
   5. Streams
4. Metalinguistic Abstraction
   1. The Metacircular Evaluator
   2. Variations on a Scheme - Lazy Evaluation
   3. Variations on a Scheme - Nondeterministic Computing
   4. Logic Programming
5. Computing with Register Machines
   1. Designing Register Machines
   2. A Register-Machine Simulator
   3. Storage Allocation and Garbage Collection
   4. The Explicit-Control Evaluator
   5. Compilation

Andrew Cooke has sent us a review of Harold Abelson, Gerald Jay Sussman with Julie Sussman's book Structure and Interpretation of Computer Programs. This is not a book for those who are getting into coding for the first time-this is a nice, big MIT press book that assumes you're smart, and that you want to learn. So, if you want to check out what they think you need to do, click below. Structure and Interpretation of Computer Programs author Harold Abelson and Gerald Jay Sussman with Julie Sussman pages publisher The MIT Press rating 9/10 reviewer Andrew Cooke ISBN summary A huge range of practical computing knowledge, but more tutorial than REVIEW: Structure and Interpretation of Computer Programs Harold Abelson and Gerald Jay Sussman with Julie Sussman The MIT Press

Nutshell
Review: A huge range of practical computing knowledge, but more tutorial than bottled wisdom. With Scheme.
Rating: 9/10 Reviewed by: Andrew Cooke The Scenario

I am a software engineer: it is my responsibility to produce code that works, and that continues to work. I am also someone with no formal education in computing who wants to learn more about the science. My attention was caught by several reviews on the web about this book - it seemed to be one of the recognised classics of computing science - so I decided to educate myself.

What's in it?

By the end of the first chapter (of only five) I had a grounding in Scheme. I guess the book could be used by someone who has never programmed before, but they would have to be pretty sharp - there is little repetition.

The second chapter covers data structures and associated algorithms. Again, a lot of ground is covered very quickly.

After syntax and data comes a chapter on programming paradigms.

The final two chapters look at implementing new languages. Curiously (it makes sense in the context of the book, but how many readers will never have hacked assembler before reading this?), the book finishes with a discussion of register machines.

What's Good?

The range. No other programming book I have read covers so many topics. If I had to pick my three personal favourite Good Ideas, I would choose:

• Functional programming (no state - no assignment to variables - and yes, it does seem strange at first!).
• Closure in data structures (so a subtree looks the same as a tree - how does this conflict with careful typing?).
• (Infinite) streams (using lazy evaluation to generate sequences).

These are not all new to me (although I have always used imperative languages), but in every case this book let me see a lot more than before. No doubt someone else would take away a completely different set of ideas - have a look at the Contents to get an idea of what might interest you.

What's A Necessary Evil?

It is impossible to resist the temptation to review Scheme when reviewing this book. After reading the first few pages I was stunned: what kind of person would enjoy using a language like this?

Imagine waking up knowing you have to go to work fixing the bugs in code written by your colleague down the hall - and you are using a language that does not have static types, objects, or even loops!

After the first chapter I could live without loops and by the end of the book I understood why Scheme had been - and had to be - used. Nothing else I have seen is as flexible and compact (if we rule out J for its illegibility :-)

But I would still hate to use this language at work.

What's Bad?

Ultimately, this is a book written for students. If you have experience in software development then you have to be prepared to skim sections. Maybe I was naive, but the reviews I had read suggested this was pure distilled wisdom - it is not.

If the authors had been able to aim a little higher (already this book could easily be intimidating to a newbie programmer, so why not drop the very basic stuff completely?) then maybe they could have used a less compact, more easily read language, with type safety and multi-threading (I do not have a recommendation, but have a peek at ML).

So What's In It For Me?

An introduction to new good ideas. A reminder of old good ideas. Much thought.

Pick this book up over at Amazon.

Table of Contents

1. Building Abstractions with Procedures
   1. The Elements of Programming
   2. Procedures and the Processes They Generate
   3. Formulating Abstractions with Higher-Order Procedures
2. Building Abstractions with Data
   1. Introduction to Data Abstraction
   2. Hierarchical Data and the Closure Property
   3. Symbolic Data
   4. Multiple Representations for Abstract Data
   5. Systems with Generic Operations
3. Modularity, Objects, and State
   1. Assignment and Local State
   2. The Environment Mode of Evaluation
   3. Modelling with Mutable Data
   4. Concurrency: Time Is of the Essence
   5. Streams
4. Metalinguistic Abstraction
   1. The Metacircular Evaluator
   2. Variations on a Scheme - Lazy Evaluation
   3. Variations on a Scheme - Nondeterministic Computing
   4. Logic Programming
5. Computing with Register Machines
   1. Designing Register Machines
   2. A Register-Machine Simulator
   3. Storage Allocation and Garbage Collection
   4. The Explicit-Control Evaluator
   5. Compilation

Giving some actual theory to the whole cryptography discussion, Ian S. Nelson's review of Handbook of Applied Cryptography takes a look at this veritable tome of information. This isn't a book for those of you trying to figure out exactly what the NSA actually does; this is for the real meat and numbers behind it all. Click below for more info. Handbook of Applied Cryptography author Alfred J. Menezes, Paul C. van Oorschot, Scott A. Vanstone pages publisher CRC Press rating 9/10 reviewer Ian S. Nelson ISBN 0-8493-8523-7 summary Required reading for any cryptography freak. REVIEW: Handbook of Applied Cryptography Alfred J. Menezes, Paul C. van Oorschot, Scott A. Vanstone CRC Press (ISBN 0-8493-8523-7) Nutshell
Review: Required reading for any cryptography freak.
Rating: 9/10 The Scenario CRC Press has been building a series of books on discrete mathematics and its applications. Doug Stinson wrote the theory book on cryptography (Cryptography: Theory and Practice (ISBN: 0-8493-8521-0, if you don't like this book you'll vomit when you see the Stinson book) and this is the application book on cryptography. It's close to 800 pages chocked full of information.

I must confess that I'm a cryptography freak and I'm a little sick of the constant political discussions and lack of tech talk, this book is all tech and might even be a little much if you're not into math. It's a wonderful companion to the Schneier books (Applied Cryptography 1st or 2nd Edition A.K.A. "the crypto bible") if you're into the nitty gritty details of cryptography.

What's Bad? I really like this book and I can't find a lot that I don't like about it... but I think in places the math gets a little thick. I have a degree in math and I find myself returning to the math overview section more often than I'd like to admit. If you're not familiar with discrete math and combinatorics then this book probably isn't for you. If you enjoy that stuff, then this will be a piece of cake. If you're looking to build your crypto book library up I'd highly recommend this book before you get some of the more hard-core books.

Something else I feel is lacking is cryptanalysis on ciphers. They discuss attacks on various protocols and hashes but actual attacks on ciphers are glossed over. As a companion to Cryptography: Theory and Practice, which covers cryptanalysis in more detail, it is understandable to leave that material out of this book but I think they could discuss it a little more than they do without going into specifics.

The no-nonsense style can be a little dry at times, there aren't a lot of jokes or anecdotes to lighten things up in this book.

What's Good? Cipher isn't spelled with a 'y' anywhere in this book. It's not filled with a lot of opinion or rumor. It doesn't hardly bring up ITAR, key escrow, or the NSA's mystical superpowers. This book is about cryptographic techniques and a listing of patents is about as political or opinionated as it gets.

It is kind of like a textbook without the problems at the end of each chapter. It is written in an outline format with subitems of "Definition", "Fact", "Notes", "Example", and "Algorithm." Each subitem is followed by a few short but concise paragraphs of explanation.

Plenty of charts and figures fill the pages and everything is explained well. While it lacks source code, there is certainly enough information for you to implement any of the ciphers, hashes, or protocols covered. It even includes some test vectors for a lot of the algorithms.

So What's In It For Me? If you want to learn about cryptography, not the politics but the actual technology, then this is a great book to get before you get over your head. It's very readable and while the math can be a little heavy in places it is accessible and useful. It gives you a good flavor of how more advanced papers and books on the subject are and it avoids the nonacademic discussions surrounding cryptography.

To pick this book up, head over to Amazon and help Slashdot out.

Table of Contents

1. Overview of Cryptography
2. 1. Introduction
   2. Information Security and Cryptography
   3. Background on Functions
   4. Basic Terminology and Concepts
   5. Symmetric-key Encryption
   6. Digital Signatures
   7. Authentication and Identification
   8. Public-key Cryptography
   9. Hash Functions
   10. Protocols and mechanisms
   11. Key establishment, management, and certification
   12. Pseudorandom numbers and sequences
   13. Classes of attacks and security models
   14. Notes and further references
3. Mathematical Background
4. 1. Probability theory
   2. Information theory
   3. Complexity theory
   4. Number theory
   5. Abstract algebra
   6. Finite fields
   7. Notes and further references
5. Number-Theoretic Reference Problems
6. 1. Introduction and overview
   2. The integer factorization problem
   3. The RSA problem
   4. The quadratic residuosity problem
   5. Computing Square roots in Z _n
   6. The Discrete logarithm problem
   7. The Diffie-Hellman problem
   8. Composite moduli
   9. Computing individual bits
   10. The subset sum problem
   11. Factoring polynomials over finite fields
   12. Notes and further references
7. Public-Key Parameters
8. 1. Introduction
   2. Probabilistic primality tests
   3. (True)Primality tests
   4. Prime number generation
   5. Irreducible polynomials over Z _p
   6. Generators and elements of high order
   7. Notes and further references
9. Pseudorandom Bits and Sequences
10. 1. Introduction
    2. Random bit generation
    3. Pseudorandom bit generation
    4. Statistical tests
    5. Cryptographically secure pseudorandom bit generation
    6. Notes and further references
11. Stream Ciphers
12. 1. Introduction
    2. Feedback shift registers
    3. Stream ciphers based on LFSRs
    4. Other stream ciphers
    5. Notes and further references
13. Block Ciphers
14. 1. Introduction
    2. Background and general concepts
    3. Classical ciphers and historical development
    4. DES
    5. FEAL
    6. IDEA
    7. SAFER, RC5, and other block ciphers
    8. Notes and further references
15. Public-Key Encryption
16. 1. Introduction
    2. RSA public-key encryption
    3. Rabin public-key encryption
    4. ElGamal public-key encryption
    5. McElliece public-key encryption
    6. Knapsack public-key encryption
    7. Probabilistic public-key encryption
    8. Notes and further references
17. Hash Functions and Data Integrity
18. 1. Introduction
    2. Classification and framework
    3. Basic constructions and general results
    4. Unkeyed hash functions (MDCs)
    5. Keyed hash functions (MACs)
    6. Data integrity and message authentication
    7. Advanced attacks on hash functions
    8. Notes and further references
19. Identification and Entity Authentication
20. 1. Introduction
    2. Passwords (weak authentication)
    3. Challenge-response identification (strong authentication)
    4. Customized zero-knowledge identification protocols
    5. Attacks on identification protocols
    6. Notes and further references
21. Digital Signatures
22. 1. Introduction
    2. A framework for digital signature mechanisms
    3. RSA and related signature schemes
    4. Fiat-Shamir signature schemes
    5. The DSA and related signature schemes
    6. One-time digital signatures
    7. Other signatures schemes
    8. Signatures with additional functionality
    9. Notes and further references
23. Key Establishment Protocols
24. 1. Introduction
    2. Classification and framework
    3. Key transport based on symmetric encryption
    4. Key agreement based on symmetric techniques
    5. Key transport based on public-key encryption
    6. Key agreement based on asymmetric techniques
    7. Secret Sharing
    8. Conference Keying
    9. Analysis of key establishment protocols
    10. Notes and further references
25. Key Management Techniques
26. 1. Introduction
    2. Background and basic concepts
    3. Techniques for distributing confidential keys
    4. Techniques for distributing public keys
    5. Techniques for controlling key usage
    6. Key management involving multiple domains
    7. Key life cycle issues
    8. Advanced trusted third party services
    9. Notes and further references
27. Efficient Implementation
28. 1. Introduction
    2. Multiple-precision integer arithmetic
    3. Multiple-precision modular arithmetic
    4. Greatest common divisor algorithms
    5. Chinese remainder theorem for integers
    6. Exponentiation
    7. Exponent recoding
    8. Notes and further references
29. Patents and Standards
30. 1. Introduction
    2. Patents on cryptographic techniques
    3. Cryptographic standards
    4. Notes and further references
31. Appendix A: Bibligraphy of Papers from Selected Cryptographic Forums
32. 1. Asiacrypt/Auscrypt Proceedings
    2. Crypto Proceedings
    3. Eurocrypt Proceedings
    4. Fast Software Encryption Proceedings
    5. Journal of Cryptology papers

Giving some actual theory to the whole cryptography discussion, Ian S. Nelson's review of Handbook of Applied Cryptography takes a look at this veritable tome of information. This isn't a book for those of you trying to figure out exactly what the NSA actually does; this is for the real meat and numbers behind it all. Click below for more info. Handbook of Applied Cryptography author Alfred J. Menezes, Paul C. van Oorschot, Scott A. Vanstone pages publisher CRC Press rating 9/10 reviewer Ian S. Nelson ISBN 0-8493-8523-7 summary Required reading for any cryptography freak. REVIEW: Handbook of Applied Cryptography Alfred J. Menezes, Paul C. van Oorschot, Scott A. Vanstone CRC Press (ISBN 0-8493-8523-7) Nutshell
Review: Required reading for any cryptography freak.
Rating: 9/10 The Scenario CRC Press has been building a series of books on discrete mathematics and its applications. Doug Stinson wrote the theory book on cryptography (Cryptography: Theory and Practice (ISBN: 0-8493-8521-0, if you don't like this book you'll vomit when you see the Stinson book) and this is the application book on cryptography. It's close to 800 pages chocked full of information.

I must confess that I'm a cryptography freak and I'm a little sick of the constant political discussions and lack of tech talk, this book is all tech and might even be a little much if you're not into math. It's a wonderful companion to the Schneier books (Applied Cryptography 1st or 2nd Edition A.K.A. "the crypto bible") if you're into the nitty gritty details of cryptography.

What's Bad? I really like this book and I can't find a lot that I don't like about it... but I think in places the math gets a little thick. I have a degree in math and I find myself returning to the math overview section more often than I'd like to admit. If you're not familiar with discrete math and combinatorics then this book probably isn't for you. If you enjoy that stuff, then this will be a piece of cake. If you're looking to build your crypto book library up I'd highly recommend this book before you get some of the more hard-core books.

Something else I feel is lacking is cryptanalysis on ciphers. They discuss attacks on various protocols and hashes but actual attacks on ciphers are glossed over. As a companion to Cryptography: Theory and Practice, which covers cryptanalysis in more detail, it is understandable to leave that material out of this book but I think they could discuss it a little more than they do without going into specifics.

The no-nonsense style can be a little dry at times, there aren't a lot of jokes or anecdotes to lighten things up in this book.

What's Good? Cipher isn't spelled with a 'y' anywhere in this book. It's not filled with a lot of opinion or rumor. It doesn't hardly bring up ITAR, key escrow, or the NSA's mystical superpowers. This book is about cryptographic techniques and a listing of patents is about as political or opinionated as it gets.

It is kind of like a textbook without the problems at the end of each chapter. It is written in an outline format with subitems of "Definition", "Fact", "Notes", "Example", and "Algorithm." Each subitem is followed by a few short but concise paragraphs of explanation.

Plenty of charts and figures fill the pages and everything is explained well. While it lacks source code, there is certainly enough information for you to implement any of the ciphers, hashes, or protocols covered. It even includes some test vectors for a lot of the algorithms.

So What's In It For Me? If you want to learn about cryptography, not the politics but the actual technology, then this is a great book to get before you get over your head. It's very readable and while the math can be a little heavy in places it is accessible and useful. It gives you a good flavor of how more advanced papers and books on the subject are and it avoids the nonacademic discussions surrounding cryptography.

To pick this book up, head over to Amazon and help Slashdot out.

Table of Contents

1. Overview of Cryptography
2. 1. Introduction
   2. Information Security and Cryptography
   3. Background on Functions
   4. Basic Terminology and Concepts
   5. Symmetric-key Encryption
   6. Digital Signatures
   7. Authentication and Identification
   8. Public-key Cryptography
   9. Hash Functions
   10. Protocols and mechanisms
   11. Key establishment, management, and certification
   12. Pseudorandom numbers and sequences
   13. Classes of attacks and security models
   14. Notes and further references
3. Mathematical Background
4. 1. Probability theory
   2. Information theory
   3. Complexity theory
   4. Number theory
   5. Abstract algebra
   6. Finite fields
   7. Notes and further references
5. Number-Theoretic Reference Problems
6. 1. Introduction and overview
   2. The integer factorization problem
   3. The RSA problem
   4. The quadratic residuosity problem
   5. Computing Square roots in Z _n
   6. The Discrete logarithm problem
   7. The Diffie-Hellman problem
   8. Composite moduli
   9. Computing individual bits
   10. The subset sum problem
   11. Factoring polynomials over finite fields
   12. Notes and further references
7. Public-Key Parameters
8. 1. Introduction
   2. Probabilistic primality tests
   3. (True)Primality tests
   4. Prime number generation
   5. Irreducible polynomials over Z _p
   6. Generators and elements of high order
   7. Notes and further references
9. Pseudorandom Bits and Sequences
10. 1. Introduction
    2. Random bit generation
    3. Pseudorandom bit generation
    4. Statistical tests
    5. Cryptographically secure pseudorandom bit generation
    6. Notes and further references
11. Stream Ciphers
12. 1. Introduction
    2. Feedback shift registers
    3. Stream ciphers based on LFSRs
    4. Other stream ciphers
    5. Notes and further references
13. Block Ciphers
14. 1. Introduction
    2. Background and general concepts
    3. Classical ciphers and historical development
    4. DES
    5. FEAL
    6. IDEA
    7. SAFER, RC5, and other block ciphers
    8. Notes and further references
15. Public-Key Encryption
16. 1. Introduction
    2. RSA public-key encryption
    3. Rabin public-key encryption
    4. ElGamal public-key encryption
    5. McElliece public-key encryption
    6. Knapsack public-key encryption
    7. Probabilistic public-key encryption
    8. Notes and further references
17. Hash Functions and Data Integrity
18. 1. Introduction
    2. Classification and framework
    3. Basic constructions and general results
    4. Unkeyed hash functions (MDCs)
    5. Keyed hash functions (MACs)
    6. Data integrity and message authentication
    7. Advanced attacks on hash functions
    8. Notes and further references
19. Identification and Entity Authentication
20. 1. Introduction
    2. Passwords (weak authentication)
    3. Challenge-response identification (strong authentication)
    4. Customized zero-knowledge identification protocols
    5. Attacks on identification protocols
    6. Notes and further references
21. Digital Signatures
22. 1. Introduction
    2. A framework for digital signature mechanisms
    3. RSA and related signature schemes
    4. Fiat-Shamir signature schemes
    5. The DSA and related signature schemes
    6. One-time digital signatures
    7. Other signatures schemes
    8. Signatures with additional functionality
    9. Notes and further references
23. Key Establishment Protocols
24. 1. Introduction
    2. Classification and framework
    3. Key transport based on symmetric encryption
    4. Key agreement based on symmetric techniques
    5. Key transport based on public-key encryption
    6. Key agreement based on asymmetric techniques
    7. Secret Sharing
    8. Conference Keying
    9. Analysis of key establishment protocols
    10. Notes and further references
25. Key Management Techniques
26. 1. Introduction
    2. Background and basic concepts
    3. Techniques for distributing confidential keys
    4. Techniques for distributing public keys
    5. Techniques for controlling key usage
    6. Key management involving multiple domains
    7. Key life cycle issues
    8. Advanced trusted third party services
    9. Notes and further references
27. Efficient Implementation
28. 1. Introduction
    2. Multiple-precision integer arithmetic
    3. Multiple-precision modular arithmetic
    4. Greatest common divisor algorithms
    5. Chinese remainder theorem for integers
    6. Exponentiation
    7. Exponent recoding
    8. Notes and further references
29. Patents and Standards
30. 1. Introduction
    2. Patents on cryptographic techniques
    3. Cryptographic standards
    4. Notes and further references
31. Appendix A: Bibligraphy of Papers from Selected Cryptographic Forums
32. 1. Asiacrypt/Auscrypt Proceedings
    2. Crypto Proceedings
    3. Eurocrypt Proceedings
    4. Fast Software Encryption Proceedings
    5. Journal of Cryptology papers

Giving some actual theory to the whole cryptography discussion, Ian S. Nelson's review of Handbook of Applied Cryptography takes a look at this veritable tome of information. This isn't a book for those of you trying to figure out exactly what the NSA actually does; this is for the real meat and numbers behind it all. Click below for more info. Handbook of Applied Cryptography author Alfred J. Menezes, Paul C. van Oorschot, Scott A. Vanstone pages publisher CRC Press rating 9/10 reviewer Ian S. Nelson ISBN 0-8493-8523-7 summary Required reading for any cryptography freak. REVIEW: Handbook of Applied Cryptography Alfred J. Menezes, Paul C. van Oorschot, Scott A. Vanstone CRC Press (ISBN 0-8493-8523-7) Nutshell
Review: Required reading for any cryptography freak.
Rating: 9/10 The Scenario CRC Press has been building a series of books on discrete mathematics and its applications. Doug Stinson wrote the theory book on cryptography (Cryptography: Theory and Practice (ISBN: 0-8493-8521-0, if you don't like this book you'll vomit when you see the Stinson book) and this is the application book on cryptography. It's close to 800 pages chocked full of information.

I must confess that I'm a cryptography freak and I'm a little sick of the constant political discussions and lack of tech talk, this book is all tech and might even be a little much if you're not into math. It's a wonderful companion to the Schneier books (Applied Cryptography 1st or 2nd Edition A.K.A. "the crypto bible") if you're into the nitty gritty details of cryptography.

What's Bad? I really like this book and I can't find a lot that I don't like about it... but I think in places the math gets a little thick. I have a degree in math and I find myself returning to the math overview section more often than I'd like to admit. If you're not familiar with discrete math and combinatorics then this book probably isn't for you. If you enjoy that stuff, then this will be a piece of cake. If you're looking to build your crypto book library up I'd highly recommend this book before you get some of the more hard-core books.

Something else I feel is lacking is cryptanalysis on ciphers. They discuss attacks on various protocols and hashes but actual attacks on ciphers are glossed over. As a companion to Cryptography: Theory and Practice, which covers cryptanalysis in more detail, it is understandable to leave that material out of this book but I think they could discuss it a little more than they do without going into specifics.

The no-nonsense style can be a little dry at times, there aren't a lot of jokes or anecdotes to lighten things up in this book.

What's Good? Cipher isn't spelled with a 'y' anywhere in this book. It's not filled with a lot of opinion or rumor. It doesn't hardly bring up ITAR, key escrow, or the NSA's mystical superpowers. This book is about cryptographic techniques and a listing of patents is about as political or opinionated as it gets.

It is kind of like a textbook without the problems at the end of each chapter. It is written in an outline format with subitems of "Definition", "Fact", "Notes", "Example", and "Algorithm." Each subitem is followed by a few short but concise paragraphs of explanation.

Plenty of charts and figures fill the pages and everything is explained well. While it lacks source code, there is certainly enough information for you to implement any of the ciphers, hashes, or protocols covered. It even includes some test vectors for a lot of the algorithms.

So What's In It For Me? If you want to learn about cryptography, not the politics but the actual technology, then this is a great book to get before you get over your head. It's very readable and while the math can be a little heavy in places it is accessible and useful. It gives you a good flavor of how more advanced papers and books on the subject are and it avoids the nonacademic discussions surrounding cryptography.

To pick this book up, head over to Amazon and help Slashdot out.

Table of Contents

1. Overview of Cryptography
2. 1. Introduction
   2. Information Security and Cryptography
   3. Background on Functions
   4. Basic Terminology and Concepts
   5. Symmetric-key Encryption
   6. Digital Signatures
   7. Authentication and Identification
   8. Public-key Cryptography
   9. Hash Functions
   10. Protocols and mechanisms
   11. Key establishment, management, and certification
   12. Pseudorandom numbers and sequences
   13. Classes of attacks and security models
   14. Notes and further references
3. Mathematical Background
4. 1. Probability theory
   2. Information theory
   3. Complexity theory
   4. Number theory
   5. Abstract algebra
   6. Finite fields
   7. Notes and further references
5. Number-Theoretic Reference Problems
6. 1. Introduction and overview
   2. The integer factorization problem
   3. The RSA problem
   4. The quadratic residuosity problem
   5. Computing Square roots in Z _n
   6. The Discrete logarithm problem
   7. The Diffie-Hellman problem
   8. Composite moduli
   9. Computing individual bits
   10. The subset sum problem
   11. Factoring polynomials over finite fields
   12. Notes and further references
7. Public-Key Parameters
8. 1. Introduction
   2. Probabilistic primality tests
   3. (True)Primality tests
   4. Prime number generation
   5. Irreducible polynomials over Z _p
   6. Generators and elements of high order
   7. Notes and further references
9. Pseudorandom Bits and Sequences
10. 1. Introduction
    2. Random bit generation
    3. Pseudorandom bit generation
    4. Statistical tests
    5. Cryptographically secure pseudorandom bit generation
    6. Notes and further references
11. Stream Ciphers
12. 1. Introduction
    2. Feedback shift registers
    3. Stream ciphers based on LFSRs
    4. Other stream ciphers
    5. Notes and further references
13. Block Ciphers
14. 1. Introduction
    2. Background and general concepts
    3. Classical ciphers and historical development
    4. DES
    5. FEAL
    6. IDEA
    7. SAFER, RC5, and other block ciphers
    8. Notes and further references
15. Public-Key Encryption
16. 1. Introduction
    2. RSA public-key encryption
    3. Rabin public-key encryption
    4. ElGamal public-key encryption
    5. McElliece public-key encryption
    6. Knapsack public-key encryption
    7. Probabilistic public-key encryption
    8. Notes and further references
17. Hash Functions and Data Integrity
18. 1. Introduction
    2. Classification and framework
    3. Basic constructions and general results
    4. Unkeyed hash functions (MDCs)
    5. Keyed hash functions (MACs)
    6. Data integrity and message authentication
    7. Advanced attacks on hash functions
    8. Notes and further references
19. Identification and Entity Authentication
20. 1. Introduction
    2. Passwords (weak authentication)
    3. Challenge-response identification (strong authentication)
    4. Customized zero-knowledge identification protocols
    5. Attacks on identification protocols
    6. Notes and further references
21. Digital Signatures
22. 1. Introduction
    2. A framework for digital signature mechanisms
    3. RSA and related signature schemes
    4. Fiat-Shamir signature schemes
    5. The DSA and related signature schemes
    6. One-time digital signatures
    7. Other signatures schemes
    8. Signatures with additional functionality
    9. Notes and further references
23. Key Establishment Protocols
24. 1. Introduction
    2. Classification and framework
    3. Key transport based on symmetric encryption
    4. Key agreement based on symmetric techniques
    5. Key transport based on public-key encryption
    6. Key agreement based on asymmetric techniques
    7. Secret Sharing
    8. Conference Keying
    9. Analysis of key establishment protocols
    10. Notes and further references
25. Key Management Techniques
26. 1. Introduction
    2. Background and basic concepts
    3. Techniques for distributing confidential keys
    4. Techniques for distributing public keys
    5. Techniques for controlling key usage
    6. Key management involving multiple domains
    7. Key life cycle issues
    8. Advanced trusted third party services
    9. Notes and further references
27. Efficient Implementation
28. 1. Introduction
    2. Multiple-precision integer arithmetic
    3. Multiple-precision modular arithmetic
    4. Greatest common divisor algorithms
    5. Chinese remainder theorem for integers
    6. Exponentiation
    7. Exponent recoding
    8. Notes and further references
29. Patents and Standards
30. 1. Introduction
    2. Patents on cryptographic techniques
    3. Cryptographic standards
    4. Notes and further references
31. Appendix A: Bibligraphy of Papers from Selected Cryptographic Forums
32. 1. Asiacrypt/Auscrypt Proceedings
    2. Crypto Proceedings
    3. Eurocrypt Proceedings
    4. Fast Software Encryption Proceedings
    5. Journal of Cryptology papers

Mike Hostetler has sent in a review of the "red book" Unix System Administration. Not so much a book for the home user, this book is for all of you out there with a network to contend with. If the armadillo book was one you enjoyed, then click below for more info. Unix System Administration Handbook author Evi Nemeth, Garth Snyder, Scott Seebass & Trent R. Hein pages publisher Prentice Hall PTR rating 9/10 reviewer Mike Hostetler ISBN ISBN 0-14-151051-7 summary Must have book for UNIX system administration REVIEW: Unix System Administration Handbook
(a.k.a. The Red Book) Evi Nemeth, Garth Snyder, Scott Seebass & Trent R. Hein (Prentice Hall PTR, ISBN 0-14-151051-7)

Nutshell
Review: Must have book for UNIX system administration
Rating: 9/10
Mike Hostetler (home)

NOTE: I'm not going to compare this book to ORA's Armadillo Book. I haven't used it, but have glanced through it. They are very much alike. I'll let the readers compare the two in the comments section.

The Scenario

Need a guide to help set up sendmail? Want some assistance in troubleshooting your DNS config? In essence, if you want a go-to book for administrating your UNIX-like machine, then this is the book for you.

What's Bad?

I can only see two things wrong with this book, both of which are small. First of all, I have the second edition (I'm sure the first one is way out of print) which is copyrighted 1995. Needless to say, things have changed a bit. Like there is no discussion about Linux-specific things, unlike their discussions when Solaris, SunOS, HP-UX, etc., are different then the norm. Also, some of the way things are done are different now. Like the book says that OSPF is a "new" TCP/IP protocal, though they do accurately predict that OSPF will become wide-spread, especially in large networks.

The second thing is even smaller. This book is written for people who administrate a large UNIX server or servers on networks. People who have their UNIX box at home will get less use out of this book then people who administrate a server in the work place. But, then again, people who aren't on a dedicated network doesn't have as many problems, or they don't have to be as careful about as many things.

What's Good?

As a quote on the back of the book says, "This is not a nice, neat book for a nice, clean world. It's a nasty book for a nasty world." The Red Book is complicated at times but it has to be - the problems it is trying to solve are complicated. This book is alway extremely practical, and no where else is practicality needed more then in system administration. They never say, "this should work" but "if that doesn't work, try this".

The authors definitely know their material, they know how to present it, and they know how to write about complex problems so Joe Admin knows how to fix them. The OS-specific sections, like, for example, when Solaris acts differently then the rest of the world, are especially good. And example config files are present when needed. And, as an added bonus, the cartoons at the beginning of each chapter are quite humorous.

So What's In It For Me?

If you want help administrating your UNIX computer, then don't hesitate - get this book.

Buy this book at Amazon and help Slashdot out.

Table of Contents

1. Basic Administration
2. Booting and Shutting Down
3. Rootly Powers
4. The Filesystem
5. Controlling Processes
6. Adding New Users
7. Devices and Drivers
8. Serial Devices
9. Adding A Disk
10. Periodic Processes
11. Backups
12. Syslog and Log Files
13. Configuring the Kernel
14. TCP/IP and Routing
15. Network Hardware
16. The Domain Name System
17. The Network File System
18. Sharing System Files
19. SLIP and PPP
20. The Internet
21. Electronic Mail
22. Network Management
23. Security
24. Usenet News
25. Printing and Imaging
26. Disk Space Management
27. Hardware Maintenance
28. Accounting
29. Performance Analysis
30. UUCP
31. Daemons
32. Policy and Politics

Mike Hostetler has sent in a review of the "red book" Unix System Administration. Not so much a book for the home user, this book is for all of you out there with a network to contend with. If the armadillo book was one you enjoyed, then click below for more info. Unix System Administration Handbook author Evi Nemeth, Garth Snyder, Scott Seebass & Trent R. Hein pages publisher Prentice Hall PTR rating 9/10 reviewer Mike Hostetler ISBN ISBN 0-14-151051-7 summary Must have book for UNIX system administration REVIEW: Unix System Administration Handbook
(a.k.a. The Red Book) Evi Nemeth, Garth Snyder, Scott Seebass & Trent R. Hein (Prentice Hall PTR, ISBN 0-14-151051-7)

Nutshell
Review: Must have book for UNIX system administration
Rating: 9/10
Mike Hostetler (home)

NOTE: I'm not going to compare this book to ORA's Armadillo Book. I haven't used it, but have glanced through it. They are very much alike. I'll let the readers compare the two in the comments section.

The Scenario

Need a guide to help set up sendmail? Want some assistance in troubleshooting your DNS config? In essence, if you want a go-to book for administrating your UNIX-like machine, then this is the book for you.

What's Bad?

I can only see two things wrong with this book, both of which are small. First of all, I have the second edition (I'm sure the first one is way out of print) which is copyrighted 1995. Needless to say, things have changed a bit. Like there is no discussion about Linux-specific things, unlike their discussions when Solaris, SunOS, HP-UX, etc., are different then the norm. Also, some of the way things are done are different now. Like the book says that OSPF is a "new" TCP/IP protocal, though they do accurately predict that OSPF will become wide-spread, especially in large networks.

The second thing is even smaller. This book is written for people who administrate a large UNIX server or servers on networks. People who have their UNIX box at home will get less use out of this book then people who administrate a server in the work place. But, then again, people who aren't on a dedicated network doesn't have as many problems, or they don't have to be as careful about as many things.

What's Good?

As a quote on the back of the book says, "This is not a nice, neat book for a nice, clean world. It's a nasty book for a nasty world." The Red Book is complicated at times but it has to be - the problems it is trying to solve are complicated. This book is alway extremely practical, and no where else is practicality needed more then in system administration. They never say, "this should work" but "if that doesn't work, try this".

The authors definitely know their material, they know how to present it, and they know how to write about complex problems so Joe Admin knows how to fix them. The OS-specific sections, like, for example, when Solaris acts differently then the rest of the world, are especially good. And example config files are present when needed. And, as an added bonus, the cartoons at the beginning of each chapter are quite humorous.

So What's In It For Me?

If you want help administrating your UNIX computer, then don't hesitate - get this book.

Buy this book at Amazon and help Slashdot out.

Table of Contents

1. Basic Administration
2. Booting and Shutting Down
3. Rootly Powers
4. The Filesystem
5. Controlling Processes
6. Adding New Users
7. Devices and Drivers
8. Serial Devices
9. Adding A Disk
10. Periodic Processes
11. Backups
12. Syslog and Log Files
13. Configuring the Kernel
14. TCP/IP and Routing
15. Network Hardware
16. The Domain Name System
17. The Network File System
18. Sharing System Files
19. SLIP and PPP
20. The Internet
21. Electronic Mail
22. Network Management
23. Security
24. Usenet News
25. Printing and Imaging
26. Disk Space Management
27. Hardware Maintenance
28. Accounting
29. Performance Analysis
30. UUCP
31. Daemons
32. Policy and Politics

Mike Hostetler has graciously taken the time and energy to send a review of Neil Matthew and Richard Stones' Beginning Linux Programming. The title isn't quite what it would seem, so if you want more info, click below. Beginning Linux Programming author Neil Matthew and Richard Stones pages publisher Wrox Press rating 6.5/10 reviewer Mike Hostetler ISBN 1-874416-68-0 summary A good sharpen-your-skills-book REVIEW: Beginning Linux Programming Neil Matthew and Richard Stones (Wrox Press, ISBN 1-874416-68-0)

Nutshell
Review: A good sharpen-your-skills-book
Rating: 6.5/10
reviewed by Mike Hostetler (home) The Scenario

I bought Beginning Linux Programming in an effort to sharpen my pathetic C skills. The book touchs all sorts of subjects like TCL, CGI, and HTML, but mainly is introducing C programming in the UNIX environment - exec, pipes, redirects, threads, sockets, and, yes, even semaphores.

What's Bad?

Beginning Linux Programming was an ambitous effort from the beginning - the point was to touch on each subject but not get too bogged down on details. That, I think, is it's biggest downfall. The book gives a simple example of each idea and then goes on to the next concept. Naturally, the focus of the book is not to give you a deep understanding of each and every concept, but it definitely made me hungry for more.

Also, the word "beginning" in the title is misleading. In most people's thinking, "beginning" would mean "just learning how to program." However, this books already assumes you have some (but not great) knowledge of C. You will not learn how to program in C from this book. However, you will learn how to program different UNIX concepts in C.

What's Good?

This is one of the most readable Linux/UNIX books I have ever read. Matthew and Stone are good writers and good explainers. And they know their subject matter - no doubt about that. Also, there is a plethora of code in this book - lots of examples to go by. And, for the lazy ones, all the code is downloadable from the Wrox web site.

So What's In It For Me?

If you are like me and have pathetic C programming skills and want to improve them, then this is a must. If you know C well but just want to learn how to program in the UNIX environment, then this book probably isn't for you. If you already know C and UNIX programming, then don't bother - you won't get anything out of it.

If you are interested in purchasing this book, and supporting Slashdot, head over to this Amazon page and pick it up.

Summary of Contents

• Development Tools
• Shell
• Files
• Terminals
• Curses
• Unix Environment
• Databases
• Processes and Signals
• Pipes
• IPC Shared Memory/Semaphors/Messages
• Sockets
• UNIX Development Tools
• Debugging and Optimizing
• X Windows Programming
• Tcl/Tk Programming
• Programming the Internet - HTML
• Programming the Internet - CGI
• The FSF and GNU Project
• Getting Started with Linux
• Internet Resources

Nate, resident Everything developer and consumate chef-and book reviewer has written a review of Gary William Flake's The Computational Beauty of Nature : Computer Explorations of Fractals, Chaos, Complex Systems, and Adaptation . This is an excellent book for those interested in more of the theory and philosphy behind nature, and is recommended for all geeks out there. The Computational Beauty of Nature author Gary William Flake pages publisher Mit Press rating 10+/10 reviewer Nate ISBN 0-262-06200-3 summary A remarkable and fascinating tour through aspects of Fractals, Chaos, Complex Systems, and Adaption. The Computational Beauty of Nature is a major work, spanning and relating subjects as diverse as fractals, neural networks, genetic algorithms, infinite sets, and the game of life. Geek/Hacker Gary Flake introduces and explains these concepts in an informal tone, which makes reading it enjoyable and understandable.

A Labor of Love

The author refers to this work as a "labor of love," and it's plain to see that it is exactly that: the expression of a Computer Scientist's love for his work. If you've ever known the exhilaration of realizing a new computer science concept, this book will take you on a whirlwind tour of some of the most fascinating concepts in the field.

Difficulty

This book was engineered so that it can be approached at different levels. Anybody with a solid high school math background, or even a logical mind will be able to comprehend the concepts introduced. Reading this book from page one all the way through would be an ambitious project for a college-level course, but many of the sections are easily read independantly. As a senior Comp Sci major, the book was very enjoyable and easy to read -- though I had to stop reading it before bed because I never wanted to go to sleep. Readers who have not taken a Comp Sci Theory course will probably want to read the first chapter, which covers many of the fundamental ideas that are extrapolated on in later sections.

The author explains that if you hit a concept that you can't easily understand, you should skip and move on. The book is well written to give a good general view of a concept, but also provide specific details for the extremely CS literate. In addition, most sections have references to "further reading" in case you are completely smitten... The diagrams are also extremely helpful for visual learners, since many of the topics have basic graphic representations.

The Format

The book is in a standard textbook format, but this works well because it allows for a plethora of interesting digressions. Much of the time, a digression will reference another section of the book dealing with a completely different, yet strongly related topic. (Of course, in my ideal universe, this whole book would be browsable and hyperlinked, so I could stream-of-consciousness my way to my masters degree.) In addition, many of the examples have corresponding code examples are to play with. (I was impressed, there's even windows binaries...)

Summary

I enjoyed this book immensely, and would definitely recommend it to anyone with a lust for the science behind these ridiculous boxes. But you can't borrow my copy. It's staying in the basement next to my poof chair and my gun...

To buy this book head over to Amazon.

Visit the CBN Web Page which has more info...

--nate

Nate, resident Everything developer and consumate chef-and book reviewer has written a review of Gary William Flake's The Computational Beauty of Nature : Computer Explorations of Fractals, Chaos, Complex Systems, and Adaptation . This is an excellent book for those interested in more of the theory and philosphy behind nature, and is recommended for all geeks out there. The Computational Beauty of Nature author Gary William Flake pages publisher Mit Press rating 10+/10 reviewer Nate ISBN 0-262-06200-3 summary A remarkable and fascinating tour through aspects of Fractals, Chaos, Complex Systems, and Adaption. The Computational Beauty of Nature is a major work, spanning and relating subjects as diverse as fractals, neural networks, genetic algorithms, infinite sets, and the game of life. Geek/Hacker Gary Flake introduces and explains these concepts in an informal tone, which makes reading it enjoyable and understandable.

A Labor of Love

The author refers to this work as a "labor of love," and it's plain to see that it is exactly that: the expression of a Computer Scientist's love for his work. If you've ever known the exhilaration of realizing a new computer science concept, this book will take you on a whirlwind tour of some of the most fascinating concepts in the field.

Difficulty

This book was engineered so that it can be approached at different levels. Anybody with a solid high school math background, or even a logical mind will be able to comprehend the concepts introduced. Reading this book from page one all the way through would be an ambitious project for a college-level course, but many of the sections are easily read independantly. As a senior Comp Sci major, the book was very enjoyable and easy to read -- though I had to stop reading it before bed because I never wanted to go to sleep. Readers who have not taken a Comp Sci Theory course will probably want to read the first chapter, which covers many of the fundamental ideas that are extrapolated on in later sections.

The author explains that if you hit a concept that you can't easily understand, you should skip and move on. The book is well written to give a good general view of a concept, but also provide specific details for the extremely CS literate. In addition, most sections have references to "further reading" in case you are completely smitten... The diagrams are also extremely helpful for visual learners, since many of the topics have basic graphic representations.

The Format

The book is in a standard textbook format, but this works well because it allows for a plethora of interesting digressions. Much of the time, a digression will reference another section of the book dealing with a completely different, yet strongly related topic. (Of course, in my ideal universe, this whole book would be browsable and hyperlinked, so I could stream-of-consciousness my way to my masters degree.) In addition, many of the examples have corresponding code examples are to play with. (I was impressed, there's even windows binaries...)

Summary

I enjoyed this book immensely, and would definitely recommend it to anyone with a lust for the science behind these ridiculous boxes. But you can't borrow my copy. It's staying in the basement next to my poof chair and my gun...

To buy this book head over to Amazon.

Visit the CBN Web Page which has more info...

--nate

SEGV, another of our resident book reviewers has written a review of the new Scott Meyer's book More Effective C++: 35 New Ways to Improve Your Programs and Designs. This is a follow-up to his previous book, and is designed for people familiar with the language.
On a different note, if you are interested in reviewing, drop me a line. We need more reviews, and I even have some books to send out as tank oos. More Effective C++: 35 New Ways to Improve Your Programs and Designs author Scott Meyers pages publisher Addison-Wesley rating 8/10 reviewer SEGV ISBN 0-201-63371-X summary A fitting follow-up to a practical classic.

More Effective C++: 35 New Ways to Improve Your Programs and Designs,
by Scott Meyers
[Addison-Wesley, ISBN 0-201-63371-X]

reviewed by SEGV [home]

Nutshell
Review:

A fitting follow-up to a practical classic.

Rating: 8/10

Episode VI: Return of the Guru

Scott Meyers has penned a worthy sequel to his original classic (now in its second edition, reviewed here). More Effecive C++ [online site] continues with the same style and quality, allowing the aspiring C++ student to further her skills with this powerful language.

Scope

This book pretty much assumes that you're familiar with the foundation laid in its predecessor. Because of that, it is able to skip the "basics" (like "use delete on pointer members") and get into more advanced topics.

Although it covers fewer Items, it is a larger book by quite a bit. Some Items are full (20+ pages) treatments of complex subjects, such as implementing smart pointers. Meyers takes you through all the nitty-gritty details of the topic at hand; by the time you're finished an Item, you not only know one or two Right Ways to do something, but also half a dozen Wrong Ways!

Content

After a brief treatment of a few more "basic" Items, Meyers leaps into a discussion of operators. Here he covers some points not present in the first book.

If you are using exceptions at all, the next Items will go far towards justifying the cost of this book. We hear about thread-safety, but often forget about exception-safety. Typically, the latter causes resource leaks, which are not as visible as the crashes caused by the former. Meyers not only explains the finer details of using exceptions properly, he also demonstrates idioms to make cleaning up after your code's mess easy and automatic.

Next Meyers discusses ways to help your code perform better and faster. Some are specific, lower level techniques, such as organizing your functions to facilitate the return value optimization. Others are generic, higher level techniques such as lazy evaluation, but it's valuable to see them illustrated in C++. All give you a deeper understanding of how C++ goes about its business.

The next Items are a set of techniques that you can apply in C++. These idioms may help you solve particular problems: for example, making functions virtual with respect to more than one object is how the Visitor pattern is implemented in C++. Even if you use existing code, such as auto_ptr, it's enlightening and instructive to see exactly what's going on under the hood, as with smart pointers.

Finally, Meyers wraps up his treatise with some more general Items. I particularly like his idea of programming in the future tense. What he really means, is write code as it should be, not just as the compiler allows. If your design calls for constraints, enforce them in the code. Don't break encapsulation just for convenience. Build in flexibility. And so on.

Summary

I recommend this book. It's not as reference-worthy as its predecessor, but it has its own place on your bookshelf. It bears reading even if you borrow a copy.

Buy this book over this way.

TABLE OF CONTENTS

Acknowledgements

Introduction

Basics

Item 1: Distinguish between pointers and references
Item 2: Prefer C++-style casts
Item 3: Never treat arrays polymorphically
Item 4: Avoid gratuitous default constructors

Operators

Item 5: Be wary of user-defined conversion functions
Item 6: Distinguish between prefix and postfix forms of increment and decrement operators
Item 7: Never overload &&, ||, or ,
Item 8: Understand the different meanings of new and delete

Exceptions

Item 9: Use destructors to prevent resource leaks
Item 10: Prevent resource leaks in constructors
Item 11: Prevent exceptions from leaving destructors
Item 12: Understand how throwing an exception differs from passing a parameter or calling a virtual function
Item 13: Catch exceptions by reference
Item 14: Use exception specifications judiciously
Item 15: Understand the costs of exception handling

Efficiency

Item 16: Remember the 80-20 rule
Item 17: Consider using lazy evaluation
Item 18: Amortize the cost of expected computations
Item 19: Understand the origin of temporary objects
Item 20: Facilitate the return value optimization
Item 21: Overload to avoid implicit type conversions
Item 22: Consider using op= instead of stand-alone op
Item 23: Consider alternative libraries
Item 24: Understand the costs of virtual functions, multiple inheritance, virtual base classes, and RTTI

Techniques

Item 25: Virtualizing constructors and non-member functions
Item 26: Limiting the number of objects of a class
Item 27: Requiring or prohibiting heap-based objects
Item 28: Smart pointers
Item 29: Reference counting
Item 30: Proxy classes
Item 31: Making functions virtual with respect to more than one object

Miscellany

Item 32: Program in the future tense
Item 33: Make non-leaf classes abstract
Item 34: Understand how to combine C++ and C in the same program
Item 35: Familiarize yourself with the language standard

Recommended Reading

An auto_ptr Implementation

General Index

Index of Example Classes, Functions, and Templates

Starting the week off in our customary fashion Jason Bennett sent in his latest book review. This time around, we're looking at The Deadline, written by Tom DeMarco. This book takes on a might-as-well-be-true story about some of the problems with software development management. Click below to read more. The Deadline author Tom DeMarco pages publisher Dorset House rating 9/10 reviewer Jason Bennett ISBN 0-932633-39-0 summary DeMarco has extended his writing from Peopleware in an interesting form: allegorical novel. Tom Clancy isn't shaking in his boots, but as a pedagogical tool, the fiction works quite well. Some excellent points are made regarding project management and dealing with evil managers. Background

Greetings once again, all. This week we're taking a trek back toward project work with DeMarco's latest work. The allegory has been done before elsewhere (I personally enjoyed Alice in Quantumland ), but I don't believe it's been used in this realm before. I've got another book or two under my belt before I'll need to pause for a reload. For now, though, The Deadline....

What's the book about?

Technically, it's a fictional story about Webster Tompkins, a "downsized" project manager from BT&T (yeah, figure that out). He's hired to work in Moravia for NNL (the Nation's Noble Leader) to turn the country into a software powerhouse. DeMarco then concocts a scenario where Tompkins endures most of the typical problems of a software project manager. He has quite a nice brain trust working with him to help him along and bring out new solutions. The kicker is, since most every software engineer in the country is involved, they have tons more people than they need. Thus, they set up multiple teams for each product in a software engineering laboratory, to test out different ideas. Sprinkled throughout are bad bosses, bad subordinates, staffing issues, metrics, interesting new techniques, various complications, and plenty of DeMarco's own ideas.

What's Good?

The conceit is an interesting idea, and the narrative tends to flow well. There are plenty of scenarios included in the book, and lots of new ideas that you likely haven't tried are mentioned as well. Also, DeMarco summarizes the points he's made in each chapter with a "journal entry" of Mr. Tompkins, in case the reader misses the point of the story. The references to various famous people are also nice, if only because DeMarco tends to summarize what that person believes about a certain issue (yes, even our favorite nemesis makes an appearance). Overall, the story flows quite well, and if you are a project manager, or are on a project team, you can learn from this book. In general, remember the essentials of good management: "get the right people, match them to the right jobs, keep them motivated, and help the team jell and stay that way. Everything else is administrivia."

What's Bad?

Unfortunately, at times the conceit breaks down. DeMarco isn't exactly a great fiction writer (the romantic parts aren't well staged), although admittedly that isn't the point of the book. Also, at times the book's plot is somewhat staged in order to accommodate all of the lessons that DeMarco wants to put in. I also happen to disagree with a few points that DeMarco makes (especially as relates to CMM), but he always has a point, at the very least.

What's In It For Us?

This book is an excellent companion to two previous books that I've reviewed, DeMarco's Peopleware and McConnell's Software Project Survival Guide This book takes a somewhat different tact, of course, and end sup synthesizing the two books. While McConnell deals with process, and Peopleware deals more with employees, Deadline deals with the people issues from the manager's standpoint. Anyone who manages (or participates in!) a software project, whether commercial or open source, will run into the problems detailed in The Deadline. It's always better to be prepared beforehand!

Purchase the book over at Amazon.

1. Preface
2. Opportunity Knocking
3. Standing Up to Kalbfuss
4. Silikon Valejit
5. The CD-ROM Plant
6. NNL
7. The World's Greatest Project Manager
8. Taking On Staff
9. The Eminent Dr. Rizzoli
10. Ex-General Markov
11. Abdul Jamid
12. The Sinister Minster Belok
13. The Numbers Man
14. QuickerStill
15. Moravia's First Programmer
16. Think Fast!
17. Planning for the Summer Games
18. The Guru of Conflict Resolution
19. Maestro Diyeniar
    Interlude
20. Part and Whole
21. Standing on Ceremony
22. Endgame Begins
23. The Year's Hottest IPO
24. Passing Through Riga on the Way Home

Starting the week off in our customary fashion Jason Bennett sent in his latest book review. This time around, we're looking at The Deadline, written by Tom DeMarco. This book takes on a might-as-well-be-true story about some of the problems with software development management. Click below to read more. The Deadline author Tom DeMarco pages publisher Dorset House rating 9/10 reviewer Jason Bennett ISBN 0-932633-39-0 summary DeMarco has extended his writing from Peopleware in an interesting form: allegorical novel. Tom Clancy isn't shaking in his boots, but as a pedagogical tool, the fiction works quite well. Some excellent points are made regarding project management and dealing with evil managers. Background

Greetings once again, all. This week we're taking a trek back toward project work with DeMarco's latest work. The allegory has been done before elsewhere (I personally enjoyed Alice in Quantumland ), but I don't believe it's been used in this realm before. I've got another book or two under my belt before I'll need to pause for a reload. For now, though, The Deadline....

What's the book about?

Technically, it's a fictional story about Webster Tompkins, a "downsized" project manager from BT&T (yeah, figure that out). He's hired to work in Moravia for NNL (the Nation's Noble Leader) to turn the country into a software powerhouse. DeMarco then concocts a scenario where Tompkins endures most of the typical problems of a software project manager. He has quite a nice brain trust working with him to help him along and bring out new solutions. The kicker is, since most every software engineer in the country is involved, they have tons more people than they need. Thus, they set up multiple teams for each product in a software engineering laboratory, to test out different ideas. Sprinkled throughout are bad bosses, bad subordinates, staffing issues, metrics, interesting new techniques, various complications, and plenty of DeMarco's own ideas.

What's Good?

The conceit is an interesting idea, and the narrative tends to flow well. There are plenty of scenarios included in the book, and lots of new ideas that you likely haven't tried are mentioned as well. Also, DeMarco summarizes the points he's made in each chapter with a "journal entry" of Mr. Tompkins, in case the reader misses the point of the story. The references to various famous people are also nice, if only because DeMarco tends to summarize what that person believes about a certain issue (yes, even our favorite nemesis makes an appearance). Overall, the story flows quite well, and if you are a project manager, or are on a project team, you can learn from this book. In general, remember the essentials of good management: "get the right people, match them to the right jobs, keep them motivated, and help the team jell and stay that way. Everything else is administrivia."

What's Bad?

Unfortunately, at times the conceit breaks down. DeMarco isn't exactly a great fiction writer (the romantic parts aren't well staged), although admittedly that isn't the point of the book. Also, at times the book's plot is somewhat staged in order to accommodate all of the lessons that DeMarco wants to put in. I also happen to disagree with a few points that DeMarco makes (especially as relates to CMM), but he always has a point, at the very least.

What's In It For Us?

This book is an excellent companion to two previous books that I've reviewed, DeMarco's Peopleware and McConnell's Software Project Survival Guide This book takes a somewhat different tact, of course, and end sup synthesizing the two books. While McConnell deals with process, and Peopleware deals more with employees, Deadline deals with the people issues from the manager's standpoint. Anyone who manages (or participates in!) a software project, whether commercial or open source, will run into the problems detailed in The Deadline. It's always better to be prepared beforehand!

Purchase the book over at Amazon.

1. Preface
2. Opportunity Knocking
3. Standing Up to Kalbfuss
4. Silikon Valejit
5. The CD-ROM Plant
6. NNL
7. The World's Greatest Project Manager
8. Taking On Staff
9. The Eminent Dr. Rizzoli
10. Ex-General Markov
11. Abdul Jamid
12. The Sinister Minster Belok
13. The Numbers Man
14. QuickerStill
15. Moravia's First Programmer
16. Think Fast!
17. Planning for the Summer Games
18. The Guru of Conflict Resolution
19. Maestro Diyeniar
    Interlude
20. Part and Whole
21. Standing on Ceremony
22. Endgame Begins
23. The Year's Hottest IPO
24. Passing Through Riga on the Way Home

Well, I finished reading Kim Stanley Robinson's new fiction book Antarctica, and had a few comments to make on it. The nutshell is that as is usually the case with Robinson, he has his facts straight and weaves a good tale. Let me know what what you thought, if you've read it. Kim Stanley Robinson is a name well known to any follower of modern science fiction-or rather, science fact. His Hugo and Nebula winning Mars series was seen by many as the heir apparent to Ray Bradbury and Heinlein. I would go so far to argue that Robinson's treatment of the planet, both in terms of the story and the factual nature advanced the cause for the colonization of Mars further then any recent phenomena.

The Mars series, starting with Red Planet and continuing through Blue and Green takes the reader through an incredible planetscape, showing through word pictures and scientific numbers the beauty of the Red Planet. One of the interesting aspects of doing the research for the Mars novels, Robinson has noted, was how often he heard about Antarctica in the same way. People testing for Mars with prototypes down there, comparasions in past history, temperature-the gamut of similaraties. Through a grant from the National Science Foundation Robinson was able to spend time in the Ice Planet, as a "Woo" (Read the book-that'll make sense). His time down there was an example of well-spent government money.

The story that comes out of his time down there is a detailed, well-told story. Set in the not-so-distant future, he addresses many of the issues that we are starting to grapple with today. From the problems of capitolism, to the degradation of the enivronment, and the relationship between men and women, the book takes on a lot. Yes, of course there is the gee-whiz element of technology, but Robinson knows his technology and his facts of science well enough to make that believable, and not turn it into an action-adventure movie.

So why should you read this book? Well, Robinson is an author who knows how to tell a story, for one. The story alone makes the book worth reading. But what he does with the story, and the issues that he addresses through here are what make the book a compelling read. Look at the book as a symposium paper masked as a fiction story. Should you get it? Well, if you like science fact, and like a good story, yes. If you like non-fiction, then probably not.

Some of the stuff he addresses in here is things that I have been doing some thinking about lately. So, if you have thoughts about this, talk below, or drop me a line.

Buy this book at Amazon.

Well, I finished reading Kim Stanley Robinson's new fiction book Antarctica, and had a few comments to make on it. The nutshell is that as is usually the case with Robinson, he has his facts straight and weaves a good tale. Let me know what what you thought, if you've read it. Kim Stanley Robinson is a name well known to any follower of modern science fiction-or rather, science fact. His Hugo and Nebula winning Mars series was seen by many as the heir apparent to Ray Bradbury and Heinlein. I would go so far to argue that Robinson's treatment of the planet, both in terms of the story and the factual nature advanced the cause for the colonization of Mars further then any recent phenomena.

The Mars series, starting with Red Planet and continuing through Blue and Green takes the reader through an incredible planetscape, showing through word pictures and scientific numbers the beauty of the Red Planet. One of the interesting aspects of doing the research for the Mars novels, Robinson has noted, was how often he heard about Antarctica in the same way. People testing for Mars with prototypes down there, comparasions in past history, temperature-the gamut of similaraties. Through a grant from the National Science Foundation Robinson was able to spend time in the Ice Planet, as a "Woo" (Read the book-that'll make sense). His time down there was an example of well-spent government money.

The story that comes out of his time down there is a detailed, well-told story. Set in the not-so-distant future, he addresses many of the issues that we are starting to grapple with today. From the problems of capitolism, to the degradation of the enivronment, and the relationship between men and women, the book takes on a lot. Yes, of course there is the gee-whiz element of technology, but Robinson knows his technology and his facts of science well enough to make that believable, and not turn it into an action-adventure movie.

So why should you read this book? Well, Robinson is an author who knows how to tell a story, for one. The story alone makes the book worth reading. But what he does with the story, and the issues that he addresses through here are what make the book a compelling read. Look at the book as a symposium paper masked as a fiction story. Should you get it? Well, if you like science fact, and like a good story, yes. If you like non-fiction, then probably not.

Some of the stuff he addresses in here is things that I have been doing some thinking about lately. So, if you have thoughts about this, talk below, or drop me a line.

Buy this book at Amazon.

Well, I finished reading Kim Stanley Robinson's new fiction book Antarctica, and had a few comments to make on it. The nutshell is that as is usually the case with Robinson, he has his facts straight and weaves a good tale. Let me know what what you thought, if you've read it. Kim Stanley Robinson is a name well known to any follower of modern science fiction-or rather, science fact. His Hugo and Nebula winning Mars series was seen by many as the heir apparent to Ray Bradbury and Heinlein. I would go so far to argue that Robinson's treatment of the planet, both in terms of the story and the factual nature advanced the cause for the colonization of Mars further then any recent phenomena.

The Mars series, starting with Red Planet and continuing through Blue and Green takes the reader through an incredible planetscape, showing through word pictures and scientific numbers the beauty of the Red Planet. One of the interesting aspects of doing the research for the Mars novels, Robinson has noted, was how often he heard about Antarctica in the same way. People testing for Mars with prototypes down there, comparasions in past history, temperature-the gamut of similaraties. Through a grant from the National Science Foundation Robinson was able to spend time in the Ice Planet, as a "Woo" (Read the book-that'll make sense). His time down there was an example of well-spent government money.

The story that comes out of his time down there is a detailed, well-told story. Set in the not-so-distant future, he addresses many of the issues that we are starting to grapple with today. From the problems of capitolism, to the degradation of the enivronment, and the relationship between men and women, the book takes on a lot. Yes, of course there is the gee-whiz element of technology, but Robinson knows his technology and his facts of science well enough to make that believable, and not turn it into an action-adventure movie.

So why should you read this book? Well, Robinson is an author who knows how to tell a story, for one. The story alone makes the book worth reading. But what he does with the story, and the issues that he addresses through here are what make the book a compelling read. Look at the book as a symposium paper masked as a fiction story. Should you get it? Well, if you like science fact, and like a good story, yes. If you like non-fiction, then probably not.

Some of the stuff he addresses in here is things that I have been doing some thinking about lately. So, if you have thoughts about this, talk below, or drop me a line.

Buy this book at Amazon.

Perenial contributor Jason Bennett has sent in a review of Built to Last, by James C. Collins and Jerry I. Porras. This is part of Jason's continuing series of review about books that are not directly code related, but about how you run a programming/information shop. Check out the full review below. Built to Last author James C. Collins and Jerry I. Porras pages publisher HarperBusiness rating 9/10 reviewer Jason Bennett ISBN 0-88730-739-6 summary This is the first book I've ever read the confirmed what I've always believed: that the best companies are the ones that put people above profits. Background

Welp, it's been a couple of weeks of slackfest over here, but I finally got my butt in gear. Unfortunately, I had to loan out the book I was going to review at the last minute, so I thought I'd substitute this one. I also just finished The Deadline by Tom DeMarco, and have had a nice email conversation with him. Great book, with a neat story and lots of excellent points. I'll get to it in a few weeks. For now, a book that relates to computers the least of all the ones I've done, yet I think gets to the heart of something that the Linux community embodies: that our beliefs are more important than going along with the group. Check it out!

What's the book about?

Built to Last is the collected knowledge of a study that began in 1989 to discover what makes visionary companies. Visionary companies are "premier institutions -- the crown jewels -- in their industries, widely admired by their peer and having a long track record [at least 50 years in this study] of making a significant impact on the world around them." This was done by surveying CEOs and finding out which companies they admired, then studying them in comparison to similarly long-lived companies that were not as admired or successful. The visionary companies are the truly special ones, while the comparison companies are just good enough. But what makes a company visionary? In short, the visionary companies are not the ones with the great ideas of charismatic leaders, but the ones which build the company instead of building thing. Visionary companies are the ones which believe in something (anything!) above profits. Visionary companies are the ones which preserve a set of core beliefs which stimulating progress into the future. Visionary companies set BHAGs (Big Hairy Audacious Goals), goals which are almost impossible, and believe that those goals can be met. Visionary companies have a culture that is almost a religion, where the employees share a set of beliefs (the core values) and live them out every day. Visionary companies are not afraid to try new things, as long as those new things do not violate the core beliefs. Visionary companies grow their own management who preserve the beliefs, instead of bringing in random outsiders. Visionary companies always strive to be better, and are not complacent. Visionary companies are not perfect, and they do stumble, but they are much better equipped to pick themselves up than their regular counterparts.

In short, we are all part of a visionary company: the Linux community. We believe in the freedom of software. We believe in choice of operating system. We believe that no one person of company should dictate what the rest of us do. In order to achieve this, we should be willing to change anything. The kernel. The UI. Heck, we should we willing to change to another operating system entirely, because whether we run Linux or FreeBSD is irrelevant. What is important is the fulfillment of our beliefs. Linus has sent a BHAG for us: World Domination. As long as we continue to build the community, and not just focus on the current OS, the Free Software movement will continue to be strong.

What's Good?

Ok, that was some good preaching. As I said, this book does not mention computer programming at all (save for having IBM as a visionary company), but it does describe us. This book details what is important: not money, but ideology. Money will flow from a strong ideology, but not the other way around. Those who take this book to heart will be part of a community, a company, that will flourish well into the next century.

What's Bad?

Heh, have I built this up enough? Seriously, though, the book isn't perfect. The structure can be a little haphazard at times, and there isn't a good listing of what the books conclusions are (they're a little scattered). The paperback does add a nice summary chapter that appeared in the Harvard Business Review, which covers this problem somewhat.

What's In It For Us?

I think I covered this. :-) Seriously, I think the Linux community would be well served to develop a set of core beliefs and core purposes and write them down. In this way, we could have an artifact of what we hold dear, a credo, that we can show to those who will be flocking to our gates. Obviously, not everyone who runs Linux (or a free OS) must hold these beliefs, just as not every IBM customer holds to their beliefs. Those who are "employees," however, should be thoroughly indoctrinated.

Purchase the book over at Amazon.

• Acknowledgements
• Introduction to the Paperback Edition
• Preface

1. The Best of the Best
2. Clock Building, Not Time Telling
3. No "Tyranny of the OR"
4. More Than Profits
5. Preserve the Core/Stimulate Progress
6. Big Hairy Audacious Goals
7. Cult-Like Cultures
8. Try a Lot of Stuff and Keep What Works
9. Home-Grown Management
10. Good Enough Never Is
11. The End of the Beginning
12. Building the Vision

• Epilogue: Frequently Asked Questions
• Appendix 1: Research Issues
• Appendix 2: Founding Roots of Visionary Companies and Comparison Companies
• Appendix 3: Tables
• Appendix 4: Chapter Notes
• Index

SEGV has submitted a review of UML Distilled: Applying the Standard Object Modeling Language, the first book by Addison-Wesley that is UML Specific in their Object Technology Series. If you're interested in knowing more about the Uniform Modeling Language, click below. UML Distilled: Applying the Standard Object Modeling Language author Martin Fowler with Kendall Scott pages publisher Addison-Wesley rating 9/10 reviewer SEGV ISBN 0-201-32563-2 summary A short and to the point introduction to the standard object modeling language.

UML Distilled: Applying the Standard Object Modeling Language,
by Martin Fowler with Kendall Scott
[Addison-Wesley, ISBN 0-201-32563-2]

reviewed by SEGV

Nutshell
Review:

A short and to the point introduction to the standard object modeling language.

Rating: 9/10

What is the UML?

A modeling language is a (mainly graphical) notation for expressing software designs. Over the last decade, many object-oriented analysis and design gurus developed their own modeling languages and techniques for using them. The two most successful were the Booch method and OMT (Object Modeling Technique). Over the last few years, three of the top gurus (Grady Booch, Jim Rumbaugh, and Ivar Jacobson, now known as the "three amigos") joined forces and unified their methods; hence, the Unified Modeling Language.

The result of that union was the company Rational Software, which developed UML versions 1.0 and 1.1. Now, the OMG (Object Management Group, purveyors of CORBA) is in the process of adopting the UML as standard. Be warned: the OMG adopted version 1.1 as their version 1.0, so there is a lamentable discrepancy in the version numbers.

About the Book

UML Distilled is the first UML-specific book in Addison-Wesley's Object Technology Series (the three amigos are the series editors). The book's online site contains some sample chapters and supplementary information. Martin Fowler's home page also contains useful information.

I have the sixth printing, which is updated to cover UML version 1.0 (per OMG). If you get this book, be sure to get this printing or later.

100% Distilled

UML Distilled is one of the shortest computer books I own: the chapters themselves comprise only 166 pages. It is really only an introduction and overview of the UML and its application; three forthcoming books by the three amigos will go into greater depth. However, the book's brevity is its strength: it is very easily read, and can be consumed in a good afternoon.

Applying the UML

Fowler cuts straight to the chase. In the second chapter he outlines a bare bones development process suitable for use with the UML. In subsequent chapters he covers different parts of the UML, explaining notation, semantics, tips, and techniques. The final chapter is the piece de resistance: an extended example taking the reader from a UML design to Java code.

Throughout UML Distilled, Fowler is not afraid to tell you how he uses the modeling language himself. He will tell you which parts of it he finds extremely useful, and which parts he doesn't bother with. He'll even tell you where he is inclined to bend the rules slightly and do something that strictly speaking doesn't conform to the standard. That's okay, since the desired result is to have the modeling language be of use to you.

Diagrams

As the table of contents shows, most of the chapters cover a particular type of diagram in the UML. If you've never object modeling diagrams, you should check out the book's inside covers, which give a feel for their various elements (and serve as an excellent reference).

I find the class diagrams, interaction diagrams, and activity diagrams to be of most use to me. The first kind is absolutely essential for documenting the structure of your classes. The second kind is useful for documenting how the various classes interact with each other. The third kind is useful for documenting the steps in a task. The latter two kinds even allow for concurrency! And of course, they are all meant to be used during the design phase, and not merely for documentation after the implementation phase (often a sad reality).

Software

I typically do object modeling with a stack of large sheets of blank paper, or a whiteboard. But software tools do exist, whether they are more of a drawing tool or actually generate code. Rational Rose is one of the better known and most advanced tools. However, the software is typically quite expensive. I'm not aware of any freely available alternatives.

Design Patterns

It is worth noting that Fowler is also the author of Analysis Patterns (online site), a book of design patterns for business domain modeling. If you're a patterns fan, you'll be happy to note that there are several examples of their usage in UML Distilled.

Summary

UML Distilled is suitable for all levels. It is short and to the point, and offers an excellent introduction to the field of object modeling. Fowler offers good advice where he is qualified, and points the reader elsewhere (other books or web sites) where his knowledge or experience is lacking, or where further information is available. I recommend this book, at least until the "canon" UML books are available!

Buy this book over at Amazon.

TABLE OF CONTENTS

1. Introduction
2. An Outline Development Process
3. Use Cases
4. Class Diagrams: The Essentials
5. Class Diagrams: Advanced Concepts
6. Interaction Diagrams
7. Package Diagrams
8. State Diagrams
9. Activity Diagrams
10. Deployment Diagrams
11. UML and Programming

• Techniques and Their Uses
• Changes From UML 1.0 to 1.1
• Bibliography
• Index

SEGV has submitted a review of UML Distilled: Applying the Standard Object Modeling Language, the first book by Addison-Wesley that is UML Specific in their Object Technology Series. If you're interested in knowing more about the Uniform Modeling Language, click below. UML Distilled: Applying the Standard Object Modeling Language author Martin Fowler with Kendall Scott pages publisher Addison-Wesley rating 9/10 reviewer SEGV ISBN 0-201-32563-2 summary A short and to the point introduction to the standard object modeling language.

UML Distilled: Applying the Standard Object Modeling Language,
by Martin Fowler with Kendall Scott
[Addison-Wesley, ISBN 0-201-32563-2]

reviewed by SEGV

Nutshell
Review:

A short and to the point introduction to the standard object modeling language.

Rating: 9/10

What is the UML?

A modeling language is a (mainly graphical) notation for expressing software designs. Over the last decade, many object-oriented analysis and design gurus developed their own modeling languages and techniques for using them. The two most successful were the Booch method and OMT (Object Modeling Technique). Over the last few years, three of the top gurus (Grady Booch, Jim Rumbaugh, and Ivar Jacobson, now known as the "three amigos") joined forces and unified their methods; hence, the Unified Modeling Language.

The result of that union was the company Rational Software, which developed UML versions 1.0 and 1.1. Now, the OMG (Object Management Group, purveyors of CORBA) is in the process of adopting the UML as standard. Be warned: the OMG adopted version 1.1 as their version 1.0, so there is a lamentable discrepancy in the version numbers.

About the Book

UML Distilled is the first UML-specific book in Addison-Wesley's Object Technology Series (the three amigos are the series editors). The book's online site contains some sample chapters and supplementary information. Martin Fowler's home page also contains useful information.

I have the sixth printing, which is updated to cover UML version 1.0 (per OMG). If you get this book, be sure to get this printing or later.

100% Distilled

UML Distilled is one of the shortest computer books I own: the chapters themselves comprise only 166 pages. It is really only an introduction and overview of the UML and its application; three forthcoming books by the three amigos will go into greater depth. However, the book's brevity is its strength: it is very easily read, and can be consumed in a good afternoon.

Applying the UML

Fowler cuts straight to the chase. In the second chapter he outlines a bare bones development process suitable for use with the UML. In subsequent chapters he covers different parts of the UML, explaining notation, semantics, tips, and techniques. The final chapter is the piece de resistance: an extended example taking the reader from a UML design to Java code.

Throughout UML Distilled, Fowler is not afraid to tell you how he uses the modeling language himself. He will tell you which parts of it he finds extremely useful, and which parts he doesn't bother with. He'll even tell you where he is inclined to bend the rules slightly and do something that strictly speaking doesn't conform to the standard. That's okay, since the desired result is to have the modeling language be of use to you.

Diagrams

As the table of contents shows, most of the chapters cover a particular type of diagram in the UML. If you've never object modeling diagrams, you should check out the book's inside covers, which give a feel for their various elements (and serve as an excellent reference).

I find the class diagrams, interaction diagrams, and activity diagrams to be of most use to me. The first kind is absolutely essential for documenting the structure of your classes. The second kind is useful for documenting how the various classes interact with each other. The third kind is useful for documenting the steps in a task. The latter two kinds even allow for concurrency! And of course, they are all meant to be used during the design phase, and not merely for documentation after the implementation phase (often a sad reality).

Software

I typically do object modeling with a stack of large sheets of blank paper, or a whiteboard. But software tools do exist, whether they are more of a drawing tool or actually generate code. Rational Rose is one of the better known and most advanced tools. However, the software is typically quite expensive. I'm not aware of any freely available alternatives.

Design Patterns

It is worth noting that Fowler is also the author of Analysis Patterns (online site), a book of design patterns for business domain modeling. If you're a patterns fan, you'll be happy to note that there are several examples of their usage in UML Distilled.

Summary

UML Distilled is suitable for all levels. It is short and to the point, and offers an excellent introduction to the field of object modeling. Fowler offers good advice where he is qualified, and points the reader elsewhere (other books or web sites) where his knowledge or experience is lacking, or where further information is available. I recommend this book, at least until the "canon" UML books are available!

Buy this book over at Amazon.

TABLE OF CONTENTS

1. Introduction
2. An Outline Development Process
3. Use Cases
4. Class Diagrams: The Essentials
5. Class Diagrams: Advanced Concepts
6. Interaction Diagrams
7. Package Diagrams
8. State Diagrams
9. Activity Diagrams
10. Deployment Diagrams
11. UML and Programming

• Techniques and Their Uses
• Changes From UML 1.0 to 1.1
• Bibliography
• Index

Actually titled Darwin Among the Machines: The Evolution of Global Intelligence, this review of the George Dyson book was sent to us by Tal Cohen. To give a good idea about what the book is exploring, I believe that this quote from Dyson, the author is well suited: "In the game of life and evolution, there are three players at the table: human beings, nature, and machine. I am firmly on the side of nature, but nature, I suspect, is on the side of machines." Touted in intellectual circles, this book examines the convergence of man, nature and machine, and the ramifications as well as examining aspects of it within a well developed historical context. For more, click below. Darwin Among the Machines: The Evolution of Global Intelligence author George B. Dyson pages publisher Helix Books / Addison Wesley rating 4/5 reviewer Tal Cohen ISBN 0-201-40649-7 summary

Could it possibly be that modern communication networks lead us to one of those rare crossroads between really far-fetched science-fiction and reality? In Darwin Among the Machines, George B. Dyson speculates that huge-scale non-human intelligence will inevitably evolve around us. In addition, the book is a refreshing history of both computing and evolution science.

Most scientist today believe that the human mind was never designed; it had evolved, slowly, over millions of generations. The main idea suggested by George Dyson in this book is simple: In the digital universe, too, a conscious mind will evolve naturally, rather than as the result of some design. Artificial Intelligence researches might as well spend their time searching for signs of intelligence on the net rather than try to develop it.

The book begins with a refreshing overview of the history of computing, as well as a brief history of the science of evolution -- with a glance towards the evolution of machines. The history of computing presented in the book is naturally biased towards issues that are relevant to the topic at hand, which is in fact an advantage, since it makes the history seem so much more refreshing.

It is a misconception, based on the stereotype of a Turing machine as executing a prearranged program one step at a time, to assume that Turing believed that any single, explicitly programmed serial process would ever capture human intelligence in mechanical form. Turing knew how many interconnected neurons it took to make a brain, and he knew how many brains it took to form a society that could kindle the spark of language and intelligence into flame.

Surprisingly for a book that deals with artificial life and intelligence, and in which Alan Turing is an important part of the cast, the infamous Turing Test for machine intelligence is hardly mentioned. Turing is not dealt with in the cliched way commonly found in other books on the subject. Rather, we are given a view of Turing as a serious researcher -- and as the first hacker-at-heart:

The IAS memory was based on the Williams tube -- an ordinary cathode-ray tube (CRT) modified to allow data to be read, written, and continuously refreshed as a pattern of charged spots on the phosphor coating inside the tube. [...] You could watch the bits of information dancing on the screen as a computation proceeded, and Turing, who soon joined the Manchester group, was noted for his ability to read numbers directly off the screen, just as he had been able to read binary code directly from teletypewriter tapes as intercepted messages were being sorted out.

Dyson quotes from sources, some surprisingly old, about the implications of the theory of evolution on the world of machines. Newer sources, of course, speak mainly about computers in this context; some of the older quotes in the book, however, date long before the computer was even conceived. In fact, even the book's title is a quote -- it was originally the title of an article published in 1863 by Samuel Butler. Such a substantial amount of text in the book is presented as direct quotes, that at times it creates the illusion that the book is nothing but a very-well done library research job. But do not be fooled: Dyson certainly presents bold new ideas.

Dyson's main claim is that the evolution of a conscious mind from today's technology is inevitable. It is not clear whether this will be a single mind or multiple minds, how smart that mind would be, and even if we will be able to communicate with it. He also clearly suggests that there are forms of intelligence on Earth that we are currently unable to understand.

What mind, if any, will become apprehensive of the great coiling of ideas now under way is not a meaningless question, but it is still too early in the game to expect an answer that is meaningful to us.

While Douglas Hofstadter, in Godel, Escher, Bach, had jokingly suggested an ant colony as a model of a mind, Dyson boldly states that insects have "socially distributed intelligence" (p. 174). He also suggests that human societies might actually form higher-level minds, in which humans take the part of neurons. And just as a neuron cannot possibly comprehend its role in the brain, so we can hardly expect a human the grasp his role in the greater mind that he is part of.

[It] is presumptuous to assume that artificial intelligence will operate on a level, or a time scale, that we are able to comprehend. As we merge toward collective intelligence, our own language and intelligence may be related to a subsidiary role or left behind. When the brass head speaks, there is no guarantee that it will speak in a language that we can understand.

With all the ideas Dyson relates regarding the inevitable appearance of intelligence over modern information networks, one might wonder if this hasn't already occurred. In his book Speaker for the Dead, science-fiction author Orson Scott Card suggested that when such an intelligence will emerge, it will be scared to let us know of its existence, knowing that some people, fearing anything nonhuman, will do their best to terminate it.

To buy this book head over to Amazon.

For more information about the book, please visit http://www.forum2.org/tal/books/darwin.html.

For additional book reviews, please visit http://www.forum2.org/tal/books.

Actually titled Darwin Among the Machines: The Evolution of Global Intelligence, this review of the George Dyson book was sent to us by Tal Cohen. To give a good idea about what the book is exploring, I believe that this quote from Dyson, the author is well suited: "In the game of life and evolution, there are three players at the table: human beings, nature, and machine. I am firmly on the side of nature, but nature, I suspect, is on the side of machines." Touted in intellectual circles, this book examines the convergence of man, nature and machine, and the ramifications as well as examining aspects of it within a well developed historical context. For more, click below. Darwin Among the Machines: The Evolution of Global Intelligence author George B. Dyson pages publisher Helix Books / Addison Wesley rating 4/5 reviewer Tal Cohen ISBN 0-201-40649-7 summary

Could it possibly be that modern communication networks lead us to one of those rare crossroads between really far-fetched science-fiction and reality? In Darwin Among the Machines, George B. Dyson speculates that huge-scale non-human intelligence will inevitably evolve around us. In addition, the book is a refreshing history of both computing and evolution science.

Most scientist today believe that the human mind was never designed; it had evolved, slowly, over millions of generations. The main idea suggested by George Dyson in this book is simple: In the digital universe, too, a conscious mind will evolve naturally, rather than as the result of some design. Artificial Intelligence researches might as well spend their time searching for signs of intelligence on the net rather than try to develop it.

The book begins with a refreshing overview of the history of computing, as well as a brief history of the science of evolution -- with a glance towards the evolution of machines. The history of computing presented in the book is naturally biased towards issues that are relevant to the topic at hand, which is in fact an advantage, since it makes the history seem so much more refreshing.

It is a misconception, based on the stereotype of a Turing machine as executing a prearranged program one step at a time, to assume that Turing believed that any single, explicitly programmed serial process would ever capture human intelligence in mechanical form. Turing knew how many interconnected neurons it took to make a brain, and he knew how many brains it took to form a society that could kindle the spark of language and intelligence into flame.

Surprisingly for a book that deals with artificial life and intelligence, and in which Alan Turing is an important part of the cast, the infamous Turing Test for machine intelligence is hardly mentioned. Turing is not dealt with in the cliched way commonly found in other books on the subject. Rather, we are given a view of Turing as a serious researcher -- and as the first hacker-at-heart:

The IAS memory was based on the Williams tube -- an ordinary cathode-ray tube (CRT) modified to allow data to be read, written, and continuously refreshed as a pattern of charged spots on the phosphor coating inside the tube. [...] You could watch the bits of information dancing on the screen as a computation proceeded, and Turing, who soon joined the Manchester group, was noted for his ability to read numbers directly off the screen, just as he had been able to read binary code directly from teletypewriter tapes as intercepted messages were being sorted out.

Dyson quotes from sources, some surprisingly old, about the implications of the theory of evolution on the world of machines. Newer sources, of course, speak mainly about computers in this context; some of the older quotes in the book, however, date long before the computer was even conceived. In fact, even the book's title is a quote -- it was originally the title of an article published in 1863 by Samuel Butler. Such a substantial amount of text in the book is presented as direct quotes, that at times it creates the illusion that the book is nothing but a very-well done library research job. But do not be fooled: Dyson certainly presents bold new ideas.

Dyson's main claim is that the evolution of a conscious mind from today's technology is inevitable. It is not clear whether this will be a single mind or multiple minds, how smart that mind would be, and even if we will be able to communicate with it. He also clearly suggests that there are forms of intelligence on Earth that we are currently unable to understand.

What mind, if any, will become apprehensive of the great coiling of ideas now under way is not a meaningless question, but it is still too early in the game to expect an answer that is meaningful to us.

While Douglas Hofstadter, in Godel, Escher, Bach, had jokingly suggested an ant colony as a model of a mind, Dyson boldly states that insects have "socially distributed intelligence" (p. 174). He also suggests that human societies might actually form higher-level minds, in which humans take the part of neurons. And just as a neuron cannot possibly comprehend its role in the brain, so we can hardly expect a human the grasp his role in the greater mind that he is part of.

[It] is presumptuous to assume that artificial intelligence will operate on a level, or a time scale, that we are able to comprehend. As we merge toward collective intelligence, our own language and intelligence may be related to a subsidiary role or left behind. When the brass head speaks, there is no guarantee that it will speak in a language that we can understand.

With all the ideas Dyson relates regarding the inevitable appearance of intelligence over modern information networks, one might wonder if this hasn't already occurred. In his book Speaker for the Dead, science-fiction author Orson Scott Card suggested that when such an intelligence will emerge, it will be scared to let us know of its existence, knowing that some people, fearing anything nonhuman, will do their best to terminate it.

To buy this book head over to Amazon.

For more information about the book, please visit http://www.forum2.org/tal/books/darwin.html.

For additional book reviews, please visit http://www.forum2.org/tal/books.

Trevor has written up a review of ORA's Linux Device Drivers. Like Linux Application Development this is a pretty important book. We all know about getting drivers written, and getting the hardware to work-now learn about how to be better at doing that. Read below for more. Linux Device Drivers author Alessandro Rubini pages publisher O'Reilly & Associates rating 8/10 reviewer trevor@mindspring.com ISBN summary REVIEW: Linux Device Drivers Alessandro Rubini O'Reilly & Associates, Inc.

Nutshell
Review:
Rating: 8/10 trevor@mindspring.com The Scenario

Though written for linux programmers working on device drivers, Linux Device Drivers by Alessandro Rubini also serves as a tour of the kernel for C programmers interested in the design decisions that give us modern linux. For anyone who is undertaking the process of creating a linux driver from scratch, Mr. Rubini has taken the disparate source files involved and created a coherent mosaic of reference which eases the path from idea to implementation. As a result of Mr. Rubini's well structured book, first time driver programmers will save hours of hand tracing code. The code examples are clearly explained and each chapter ends with a reference section to be quickly accessed while programming. This book is current through 2.1.43 and it clearly notes where code changes are necessary in moving from 2.0.x to 2.1.x.

What's Bad?

As with any traditional book on linux, Linux Device Drivers will eventually be out of date for programmers working with the most current linux source.

What's Good?

Chapters 1 through 8 cover the basics of how the kernel loads and unloads modules. It begins with a simple "hello world, I'm a module" example and moves on to more complex examples. This section does not require the use of any special hardware as it implements a memory "software device" which turns out to be handy for other programming tasks. The book's FTP site has each code sample available so no retyping is necessary. For programmers who can do snazzy tricks with data structures, but are new (or rusty) with lower level hardware programming, chapter 8 is a clear and quick (re)introduction to the issues. Chapter 9 introduces the hairy art of interrupt handling and steps through the pitfalls of race conditions and other such monsters.

The second section, Chapters 10 through 15, can be treated as stand alone works on the topics of kerneld, block drivers, mmap and DMA, network devices, and a short overview of peripheral buses. Depending on your programming goals, these chapters may or may not be immediately useful. However, the reference sections at the end of each chapter can help identify where driver problems originate. Each chapter is recommended reading, but covering them all in one sitting is a sure way to overflow your buffer.

The final two chapters are on the topics of the physical layout of the kernel source and recent developments in the experimental line of kernels. The first chapter in this section serves as a boot to shutdown guide to which source handles different kernel operations. For those who need to know (or are simply interested) in the how linux handles the differences in various architectures, this chapter is a good spring board for the necessary code diving. The last chapter of the book, Recent Developments, details where the linux community of kernel programmers seems to be headed. Though there is no replacement for subscribing to the relevant lists and reading the newsgroups, this chapter can bring those new to open source development up to speed.

So What's In It For Me?

Linux Device Drivers maintains the high standard set by other linux related books published by O'Reilly & Associates. Alessandro Rubini has created a solid guide to the tasks and ideas of the linux kernel. It is a fine addition to the bookshelves of linux users and driver writers alike.

Pick this book up at Amazon.

Table of Contents

1. An Introduction to the Linux Kernel
2. Building and Running Modules
3. Char Drivers
4. Debugging Techniques
5. Enhanced Char Driver Operations
6. Flow of Time
7. Getting Hold of Memory
8. Hardware Management
9. Interrupt Handling
10. Judicious Use of Data Types
11. Kerneld and Advanced Modularization
12. Loading Block Drivers
13. MMAP and DMA
14. Network Drivers
15. Overview of Peripheral Buses
16. Physical Layout of the Kernel Source
17. Recent Developments

Trevor has written up a review of ORA's Linux Device Drivers. Like Linux Application Development this is a pretty important book. We all know about getting drivers written, and getting the hardware to work-now learn about how to be better at doing that. Read below for more. Linux Device Drivers author Alessandro Rubini pages publisher O'Reilly & Associates rating 8/10 reviewer trevor@mindspring.com ISBN summary REVIEW: Linux Device Drivers Alessandro Rubini O'Reilly & Associates, Inc.

Nutshell
Review:
Rating: 8/10 trevor@mindspring.com The Scenario

Though written for linux programmers working on device drivers, Linux Device Drivers by Alessandro Rubini also serves as a tour of the kernel for C programmers interested in the design decisions that give us modern linux. For anyone who is undertaking the process of creating a linux driver from scratch, Mr. Rubini has taken the disparate source files involved and created a coherent mosaic of reference which eases the path from idea to implementation. As a result of Mr. Rubini's well structured book, first time driver programmers will save hours of hand tracing code. The code examples are clearly explained and each chapter ends with a reference section to be quickly accessed while programming. This book is current through 2.1.43 and it clearly notes where code changes are necessary in moving from 2.0.x to 2.1.x.

What's Bad?

As with any traditional book on linux, Linux Device Drivers will eventually be out of date for programmers working with the most current linux source.

What's Good?

Chapters 1 through 8 cover the basics of how the kernel loads and unloads modules. It begins with a simple "hello world, I'm a module" example and moves on to more complex examples. This section does not require the use of any special hardware as it implements a memory "software device" which turns out to be handy for other programming tasks. The book's FTP site has each code sample available so no retyping is necessary. For programmers who can do snazzy tricks with data structures, but are new (or rusty) with lower level hardware programming, chapter 8 is a clear and quick (re)introduction to the issues. Chapter 9 introduces the hairy art of interrupt handling and steps through the pitfalls of race conditions and other such monsters.

The second section, Chapters 10 through 15, can be treated as stand alone works on the topics of kerneld, block drivers, mmap and DMA, network devices, and a short overview of peripheral buses. Depending on your programming goals, these chapters may or may not be immediately useful. However, the reference sections at the end of each chapter can help identify where driver problems originate. Each chapter is recommended reading, but covering them all in one sitting is a sure way to overflow your buffer.

The final two chapters are on the topics of the physical layout of the kernel source and recent developments in the experimental line of kernels. The first chapter in this section serves as a boot to shutdown guide to which source handles different kernel operations. For those who need to know (or are simply interested) in the how linux handles the differences in various architectures, this chapter is a good spring board for the necessary code diving. The last chapter of the book, Recent Developments, details where the linux community of kernel programmers seems to be headed. Though there is no replacement for subscribing to the relevant lists and reading the newsgroups, this chapter can bring those new to open source development up to speed.

So What's In It For Me?

Linux Device Drivers maintains the high standard set by other linux related books published by O'Reilly & Associates. Alessandro Rubini has created a solid guide to the tasks and ideas of the linux kernel. It is a fine addition to the bookshelves of linux users and driver writers alike.

Pick this book up at Amazon.

Table of Contents

1. An Introduction to the Linux Kernel
2. Building and Running Modules
3. Char Drivers
4. Debugging Techniques
5. Enhanced Char Driver Operations
6. Flow of Time
7. Getting Hold of Memory
8. Hardware Management
9. Interrupt Handling
10. Judicious Use of Data Types
11. Kerneld and Advanced Modularization
12. Loading Block Drivers
13. MMAP and DMA
14. Network Drivers
15. Overview of Peripheral Buses
16. Physical Layout of the Kernel Source
17. Recent Developments

Trevor has written up a review of ORA's Linux Device Drivers. Like Linux Application Development this is a pretty important book. We all know about getting drivers written, and getting the hardware to work-now learn about how to be better at doing that. Read below for more. Linux Device Drivers author Alessandro Rubini pages publisher O'Reilly & Associates rating 8/10 reviewer trevor@mindspring.com ISBN summary REVIEW: Linux Device Drivers Alessandro Rubini O'Reilly & Associates, Inc.

Nutshell
Review:
Rating: 8/10 trevor@mindspring.com The Scenario

Though written for linux programmers working on device drivers, Linux Device Drivers by Alessandro Rubini also serves as a tour of the kernel for C programmers interested in the design decisions that give us modern linux. For anyone who is undertaking the process of creating a linux driver from scratch, Mr. Rubini has taken the disparate source files involved and created a coherent mosaic of reference which eases the path from idea to implementation. As a result of Mr. Rubini's well structured book, first time driver programmers will save hours of hand tracing code. The code examples are clearly explained and each chapter ends with a reference section to be quickly accessed while programming. This book is current through 2.1.43 and it clearly notes where code changes are necessary in moving from 2.0.x to 2.1.x.

What's Bad?

As with any traditional book on linux, Linux Device Drivers will eventually be out of date for programmers working with the most current linux source.

What's Good?

Chapters 1 through 8 cover the basics of how the kernel loads and unloads modules. It begins with a simple "hello world, I'm a module" example and moves on to more complex examples. This section does not require the use of any special hardware as it implements a memory "software device" which turns out to be handy for other programming tasks. The book's FTP site has each code sample available so no retyping is necessary. For programmers who can do snazzy tricks with data structures, but are new (or rusty) with lower level hardware programming, chapter 8 is a clear and quick (re)introduction to the issues. Chapter 9 introduces the hairy art of interrupt handling and steps through the pitfalls of race conditions and other such monsters.

The second section, Chapters 10 through 15, can be treated as stand alone works on the topics of kerneld, block drivers, mmap and DMA, network devices, and a short overview of peripheral buses. Depending on your programming goals, these chapters may or may not be immediately useful. However, the reference sections at the end of each chapter can help identify where driver problems originate. Each chapter is recommended reading, but covering them all in one sitting is a sure way to overflow your buffer.

The final two chapters are on the topics of the physical layout of the kernel source and recent developments in the experimental line of kernels. The first chapter in this section serves as a boot to shutdown guide to which source handles different kernel operations. For those who need to know (or are simply interested) in the how linux handles the differences in various architectures, this chapter is a good spring board for the necessary code diving. The last chapter of the book, Recent Developments, details where the linux community of kernel programmers seems to be headed. Though there is no replacement for subscribing to the relevant lists and reading the newsgroups, this chapter can bring those new to open source development up to speed.

So What's In It For Me?

Linux Device Drivers maintains the high standard set by other linux related books published by O'Reilly & Associates. Alessandro Rubini has created a solid guide to the tasks and ideas of the linux kernel. It is a fine addition to the bookshelves of linux users and driver writers alike.

Pick this book up at Amazon.

Table of Contents

1. An Introduction to the Linux Kernel
2. Building and Running Modules
3. Char Drivers
4. Debugging Techniques
5. Enhanced Char Driver Operations
6. Flow of Time
7. Getting Hold of Memory
8. Hardware Management
9. Interrupt Handling
10. Judicious Use of Data Types
11. Kerneld and Advanced Modularization
12. Loading Block Drivers
13. MMAP and DMA
14. Network Drivers
15. Overview of Peripheral Buses
16. Physical Layout of the Kernel Source
17. Recent Developments

Continuing his voyage, Jason Bennett has submitted his review of Peopleware. This is a book about how to run an office in the age of the "information worker". Not about coding, but about creating environments in which the work we are all used can be done. So, if you are interested (or have a manager who should read this), click below. Peopleware author Tom DeMarco and Timothy Lister pages publisher Dorset House rating 10/10 reviewer Jason Bennett ISBN 0-932633-05-6 summary An excellent book about how an office should be run. If you consider yourself an "intellect worker," read this book and apply its principles. Background

I apologize for the missed week. I was finishing up my report for work on this book, and didn't get around to my Slashdot review. I've also ended up changing the schedule, since this review was available, and Creating a Software Engineering Culture would have required duplicating a lot of work. Anyway, we'll get to it next week. I'm also currently reading Built to Last, an excellent book about what makes the difference between a decent company and a great ("visionary") company. I'm not sure that review belongs on Slashdot, but reader demand will help to influence that. :-)

What's the book about?

Peopleware is the collected knowledge of two long-time project managers. Specifically, they deal with what is wrong with how managers treat their people, and what is wrong with the work environment itself. The book talks in terms of software projects, but is useful to anyone who falls in to the category of "intellect worker"; in other words, those people who need to concentrate to work, as opposed to those who work in "interrupt mode."

Peopleware is organized into many separate, but related, essays. Once again, I'll be dealing with the book in chunks:

1. Managing the Human Resource (ch. 1-6)
2. The Office Environment (ch. 10-13)
3. The Right People (ch. 14-17)
4. Growing Productive Teams (ch. 18-23)
5. It's Supposed to Be Fun to Work Here (ch. 24-26)

"Managing the Human Resource" deals with how intellect workers should be treated. The main theme of the book is summed up on page 4: "The major problems of our work are not so much technological as sociological in nature." Ultimately, projects do not fail because people cannot understand the technology, but because the team itself breaks (or is broken). Workers must be treated as people, not as parts of a machine. So much of managerial theory assumes some sort of non-intellectual, "assembly line" development (be it a car plant or burger joint). Using these kinds of adversarial, non-thinking tactics will ruin an environment of people who are paid to think. Because those workers think, each one is unique and irreplaceable. You can't mine your "human resources" from the ground.

"The Office Environment" is one of the most focused, devastatingly effective parts I've read in a while. D&L systematically demolish the theory of cheap, open space, the notion that the environment does not effect people, and the notion that workspace is the place to save money. Consider that the cost of a worker's space is 1/20th of his salary over the average time he stays at one company (2 years). If a poor environment hampers that worker's productivity, the money saved in building that environment will be more than overshadowed by the extra time required for the worker to complete tasks. In fact, there are 11:1 differences in productivity between the best and worst organization. Should you be working 10 times more than you should?

The thesis behind "The Right People" is that it is critical to hire the best people in the first place, as a manager is not likely to mold a worker himself. Therefore, managers should strive to hire the people who will do the best job and complement the team the most, not the people who will most conform to some arbitrary standard. Allowing teammates to assist in the process, and keeping a long-term focus to reduce turnover, will help the situation.

"Growing Productive Teams" focuses on the concept of "jelled teams." These teams, where the members are highly focused on the goal, are much more productive than the individual members could ever be. These teams are difficult to make, but easy to destroy. Managers who give their people freedom and trust are most likely to produce excellent teams. Excellent organizations, the ones that focus on quality, eliteness, and protecting teams, are also likely to produce jelled teams.

"It's Supposed to Be Fun to Work Here" proposes just that: work should be fun. That doesn't mean that the ideal job would be fun, it means that a good manager can and should make work enjoyable for his charges. Doing different things, such as war games and pilot projects, along with giving people as much freedom to define their own jobs as possible, are good ways to make work fun again. The time to act is now.

What's Good?

As I read this book, I felt that every paragraph had something to say. D&L are constantly throwing out important points, backed by data or their own experience. Everyone who works as an "intellect worker" can likely relate to some of the problems in this book, and the points presented can improve any workplace. Pick this book up, read it, and find something to improve. Your coworkers will thank you for it.

What's Bad?

While I can't say there's anything bad about this book, the audience is a little more focused than some books I've reviewed here. Independent contractors, or others who tend to work on their own, and people who don't live at a desk probably won't relate to a lot of this book.

What's In It For Us?

Redhat had better conform to this book, or else.... No, just kidding. Seriously, in terms of "open source" relevance, I'm sure you can configure your virtual office any way you like. However, given that a jelled team is much more productive than random groups of people, it would seem that team-directed efforts should try to strengthen the committee as much as possible.

Purchase the book over at Amazon.

• Acknowledgements
• Preface

1. Managing the Human Resource
   1. Somewhere Today, a Project Is Failing
   2. Make a Cheeseburger, Sell a Cheeseburger
   3. Vienna Waits for You
   4. Quality -- If Time Permits
   5. Parkinson's Law Revisited
   6. Laetrile
2. The Office Environment
   1. The Furniture Police
   2. "You Never Get Anything Done Around Here Between 9 and 5"
   3. Saving Money on Space
   • Intermezzo: Productivity Measurement and Unidentified Flying Objects
   1. Brain Time Versus Body Time
   2. The Telephone
   3. Bring Back the Door
   4. Taking Umbrella Steps
3. The Right People
   1. The Hornblower Factor
   2. Hiring a Juggler
   3. Happy to Be Here
   4. The Self-Healing System
4. Growing Productive Teams
   1. The Whole Is Greater Than the Sum of the Parts
   2. The Black Team
   3. Teamicide
   4. A Spaghetti Dinner
   5. Open Kimono
   6. Chemistry for Team Formation
5. It's Supposed to Be Fun to Work Here
   1. Chaos and Order
   2. Free Electrons
   3. Holgar Dansk

• Notes
• Bibliography
• Index

Back from his vacation, Jason Bennett has written a review of Code Complete. Written by Steve McConnell, this takes a good overview of coding constructs, style and technique. Click below if you want to read more, and if anyone is interested in doing reviews, drop me a line. Code Complete author Steve McConnell pages publisher Microsoft Press rating 9/10 reviewer Jason Bennett ISBN 1-55615-484-4 summary

Everything you should have learned in school, but didn't. Steve gives a complete overview of coding techniques and methods suitable for anyone who writes code.

> Background

Greetings, all. Good to be back on Slashdot after a few weeks away for vacation (in Costa Rica!) and general rest. This week, my McConnell butt-kissing spree continues with his first book, Code Complete. I'll be continuing my reviews next week with a somewhat more focused book, Creating a Software Engineering Culture by Karl Wiegers, followed by two of Tom DeMarco's books, PeopleWare and The Deadline. By that time, who knows, I might have read some more!

What's the book about?

As I said above, this book is everything you should have learned in school, but were too busy hacking to hear. It is a very complete discussion of coding constructs, style, and technique. It's helpful when using any language, on any platform, for whatever goal. In short, if you write code, you can learn from this book.

This book is massive, so for simplicity's sake, I'll deal with it in the following chunks:

1. Laying the Foundation (ch. 1-3)
2. Design (ch. 4-7)
3. Data (ch. 8-12)
4. Control (ch. 13-17)
5. Constant Considerations (ch. 18-22)
6. Quality Improvement (ch. 23-26)
7. Final Steps (ch. 27-30)
8. Software Craftsmanship (ch. 31-33)

"Laying the Foundation" sets up the mental constructs and prerequisite work for software construction. Specifically, he describes the metaphors common to software development and the requirements needed before solid construction can begin. These prerequisites foreshadow Steve's future works, Rapid Development and Software Project Survival Guide, and give a solid, short list of preliminary project needs. Steve's approach here shows that he understands that good development is more than a tight loop or a slick language. That loop is only meaningful to the extent that it fulfills the goal of the project, a goal which must be clear and correct in order to guide the course of the project. Remember that the next time you spend three hours on a nasty module, only to discover that your module isn't needed. Neglecting the preliminaries will only waste your time.

"Design" describes what is needed to set up high-quality routines, including steps for building routines, what a good routine needs and doesn't need, modularity and various design methodologies. Remember, your code's overall structure will largely dictate its maintainability, as well as its debuggability and testability. The better you do here, the easier things will go toward the end.

"Data" drills down one level further, and moves us into the actual code. Although constructing data types is de-emphasized in a true OO environment (such as Smalltalk or Java), those C(++) addicts out there will be dealing with this issue until time immortal. Steve spends plenty of time on data naming, including Hungarian Notation. Scourge to some, savior to others, I don't personally like HN itself, but love the idea of a solid naming convention. However you choose to name your types, calling them mwindsgty won't help you, or anyone else. Steve also discussing variables, including those evil global ones, along with fundamental types and complex types. Mostly an overview of CS101, but there are plenty of useful tips thrown in to boot (especially if you never HAD CS101).

"Control" deals with those most important structures, the decision constructs. If and case statements are addressed here, along with loop controls, gotos (everyone boo here), and my favorite of all, recursion (pointers just aren't the same without it). Again, much of this is basic, but if you never learned it, need a refresher, or need to do it properly, reading it will teach you plenty.

"Constant Considerations" moves out of the actual statements and into other considerations, such as style, self-documenting code, and useful tools. If you are dealing with an external layout standard (such as the GNU standards), you can't apply your own technique, but at least use TAB in Xemacs if nothing else! And comment, dangit! If you saw the evil DOS code I have to maintain, you'd understand why I feel that way....

"Quality Improvement" gives a good overview of Quality Assurance/Quality Control issues, as well as unit testing/debugging techniques. Steve also trumpets peer reviews as an excellent way to remove defects from code. In fact, code reviews can improve code in multiple ways at once. The code itself is checked for accuracy, new techniques are discussed among programmers, and the team is enhanced for having done something well together. Software quality is something we all want, but don't always know how to achieve. This can help.

"Final Steps" takes us through the end-game of development: system integration, tuning and maintenance/evolution. Steve gives some excellent tips on when and when not to tune software. Generally, wait until the last minute before turning your code into a morass of tricks. Document heavily. Above all, make sure you really need it. Usually, the compiler will do better than you, anyway.

"Software Craftsmanship" is a more personally oriented chapter, dealing with character and crafting issues. I'm glad Steve took the time to address these important topics, which sometimes are shoved away by ego-centered considerations. Remember, you code for people, not machines, and you code with people, not machines.

What's Good?

As I said last week, Steve knows what he's doing. This book won some awards for its excellence, and is truely a thorough overview of the coding, and generally the development, process. This is the sort of book you read through once, to make sure you see everything, and then refer to consistently. Make sure you pay attention to those sections on testing and naming, so that your next OSS project will be better for everyone involved.

What's Bad?

It's hard to say anything is bad about CC, although its length is probably its largest detriment. The book is so comprehensive, you'll likely need to pare down the parts you don't need from what's important to you (just like an encyclopaedia). Fortunately, there are good summaries at the end of each chapter that can be copied and referred to at will. It would probably also be a good idea to highlight/copy the relevant parts for easy reference. Also, remember that this book focuses on coding. The other sections are nice, but companion books on testing and requirements/design will be needed.

What's In It For Us?

I don't have to stand on by soapbox quite so shrilly this time. :-) Clearly, good, clean coding is a necessity to any large, long lived project (not that you'd realize that from seeing some code...). These techniques will make anyone a better coder, even if you've seen it all before. We all need review, and we all learn things even when we did think we could. Solid, stable, reviewable, readable, open-source code is our greatest tangible asset. This book will only strengthen that asset.

Purchase the book over at Amazon.

• Checklists

• Reference Tables
• Preface

• Laying the Foundation
  1. Welcome to Software Construction
  2. Metaphors for a Richer Understanding of Programming
  3. Prerequisites to Construction
• Design
  1. Steps in Building a Routine
  2. Characteristics of High-Quality Routines
  3. Three out of Four Programmers Surveyed Prefer Modules
  4. High-Level Design in Construction
• Data
  1. Creating Data
  2. The Power of Data Names
  3. General Issues in Using Variables
  4. Fundamental Data Types
  5. Complex Data Types
• Control
  1. Organizing Straight-Line Code
  2. Using Conditionals
  3. Controlling Loops
  4. Unusual Control Structures
  5. General Control Issues
• Constant Considerations
  1. Layout and Style
  2. Self-Documenting Code
  3. Programming Tools
  4. How Program Size Affects Construction
  5. Managing Construction
• Quality Improvement
  1. The Software-Quality Landscape
  2. Reviews
  3. Unit Testing
  4. Debugging
• Final Steps
  1. System Integration
  2. Code-Tuning Strategies
  3. Code-Tuning Techniques
  4. Software Evolution
• Software Craftsmanship
  1. Personal Character
  2. Themes in Software Craftsmanship
  3. Where to Go for More Information
• Bibliography
• Index

Greg Perkins has written in with a nice paper on Open Source and Capitalism. A lot of people say that these ideas are oil and water, but click the link below and read what Greg has to say about it. Update Greg sent in response to the many comments. It's appended to the end of his original piece. The following was written by Slashdot reader Greg Perkins Open Source and Capitalism

Greg Perkins

Many people associate the idea of Open Source software with collectivism (socialism, communitarianism, or communism). This is understandable given the language and ideas of some of the movement's founders and prominent participants, and given the average political tendencies of college students (at least here in the US), who seem to form the core of the Open Source movement. That is of course no cause for concern. What troubles me is that I keep noticing an undercurrent of mistrust and even open hostility toward capitalism among Open Source fans. There is really no good reason for this, and I worry that it may grow into something truly dangerous to the movement.

I have seen it asked: how can capitalists enjoy and even embrace the Open Source ideal? Hidden in this question is the notion that capitalism is fundamentally incompatible with Open Source, and that collectivism is not. While this is sure to be a touchy subject, I would like to try sharing the principled perspective of the Other Side.

In contrast to the above, I think that it is capitalism which is harmonious with Open Source, and that collectivism is incompatible; principled and thoughtful Open Source advocates should want to fully embrace capitalism for exactly the same reasons they love the idea of Open Source.

The (Societal) Elements of Open Source

I know that most people here have studied the meaning and mechanism of Open Source pretty carefully (consider the popularity of Raymond's The Cathedral and the Bazaar, for example). Let's focus briefly on the crucial societal elements which Open Source depends on for its success:

First, Open Source depends on the idea that cooperation is the preferred mode for dealing with one another, that cooperation and voluntary association to mutual benefit is the most effective, most productive, and, well, simply the Right Way for people to live in society, as contrasted against the use of fraud or physical force. Individual Open Source authors have the right to choose what code they will write and with whom they might like to work -- nobody is allowed to make them do it. When someone else makes that choice for you it is called slavery, and Open Source couldn't be as successful as it is on those terms; peoples' active, willing participation is required.

Second, Open Source depends on the idea of the individual human right to private property. Code wouldn't exist except by the effort of the people who build it -- it is by their choice and their sweat that their code even exists, and so they naturally have the right to decide how they will deploy their creation (otherwise, why should they bother to create it in the first place?). Linus himself expressed this spirit perfectly when he said, "he who writes the code gets to choose the license, and nobody else gets to complain." Open Source authors generously choose to apply licenses like the GPL to their code, thereby exercising their right to dictate how their effort may be used (and how it may not be used).

And finally, Open Source requires the protection of private property rights by a government. People need more than to merely feel justified in saying how they wish their code to be used (and not used) -- they must have confidence that their wishes will not be violated and the product of their best efforts taken and used at just anybody's whim. People can be secure in their cooperation with one another toward whatever ends each may choose when their right to private property is protected. Doing so essentially means barring the initiation of physical force and fraud from peoples' legitimate dealings, leaving them with nothing but cooperation and trade to mutual benefit. We can see this confidence manifest as authors willingly write Open Source code, or help someone write Open Source code: they do so because they trust that the license will be enforced, that someone else cannot take advantage of them and direct their efforts to ends they do not wish.

Another Look at Capitalism

Here's the point that might surprise some Open Source advocates: the above three crucial factors are precisely the same foundation that is required for true, unadulterated, laissez-faire capitalism.

Capitalism is a social system which respects and defends peoples' individual human rights, including the right to property. Further, capitalism is epitomized by cooperation, not by competition -- competition arises in the context of several participants trying to out-cooperate each other in a division-of-labor economy. As a tiny example, consider the handful of pencil companies competing in "cutthroat, dog-eat-dog" manner with each other for the chance to cooperate with you. Now think about how many other economic partners each of them works with in trying to bring you that pencil, from the people mining the graphite and harvesting the wood and rubber, to the transport systems which take them to the factories full of people, the manufacturing and chemical engineers who design the processes, the marketing and distribution channels, and the retailer who makes it easy for you to have that pencil with little or no effort. Thousands and thousands of people all peacefully work in concert to bring you a pencil (not to mention all those who cooperate with them, and those who cooperate with them, and so on). Multiply that by all the other economic values in your life that aren't as insignificant as a humble pencil, and you can see that fundamentally, capitalism means cooperation.

Full-blown capitalism is actually the separation of market and state. In particular, it is not the current American- or European-style mixed economy, with some people and businesses having the ability to use government to secure special advantage over others by lobbying for taxes, regulations, etc. To the extent that people and companies can use government to indirectly compel others in economic matters, capitalism and everything that makes it great is undercut. In the same way that we react to proposals to control the press or the church, in a true capitalist system everybody would simply laugh at someone trying to use the heavy hand of government to some economic advantage. We would just point to the constitutional clause banning any such interference, telling them, "Tough beans -- why don't you try to persuade the people in the marketplace that you are worth doing business with?"

Common Grounds

So if you cheer for the idea of Open Source, then please cheer for what makes Open Source work. If you do that, then you are also cheering for exactly what makes capitalism work, and everything that makes it such a powerful force for improving the human lot in the world.

As a libertarian and staunch capitalist, I get a true charge out of seeing an innovative entrepreneur or inventor serving himself by serving his fellow man in some new, clever, or powerful way. As a software engineer and rabid Open Source advocate, I get a true charge out of seeing the genius behind Stallman's GPL and the meteoric rise of Open Source and GNU/Linux. What makes these great to me is the same in both cases: people are able to be productive and peacefully reap the rewards of their hard work as they see fit.

Banning fraud and the initiation of force in our dealings with one another, and respecting people and their choices as individuals by protecting their property rights... These form a kind of systemic encouragement which brings out the very best within us -- and that is precisely what drives the raging success of both Open Source and capitalism.

Recommended Reading

Economics in One Lesson by Henry Hazlitt is a classic, widely regarded as a wonderful (perhaps the best) first introduction to economics.

Capitalism: a Treatise on Economics by Dr. George Reisman is a lucid and encyclopedic account of capitalism and all things economic.

Also see the works of scholars from the Austrian school of economics, like Ludwig Von Mises and Friedrich A. Von Hayek (1974 Nobel in economics), or scholars from the Chicago school of economics, such as Milton Friedman (1976 Nobel in economics) or James Buchanan (1986 Nobel in economics).

A Followup from Greg Perkins

250 comments in a day -- what a wonderful firestorm of discussion!

Now, surely the more harsh commentators understand that in a short piece like my editorial, no author could even try to cover every anticipated objection or outright mistake in reading and reasoning that a minority of the audience might bring. That would simply bore or distract the majority of readers, perhaps to the point of missing the original thesis! I needed to leave such issues for the ensuing discussion.

And boy, I was pleasantly surprised by what happened! A horde of nimble-fing ered Slashdotters quickly jumped in after the first wave of commentary, answering and dissecting almost all of the incoming criticism quite nicely, relieving me of a lot of work -- thanks much, guys! :^)

However, there remain a couple of important themes that my quick-response comrades didn't address, and so I'll try to cover those here -- starting with the most important and surprising one.

What the Hay??

This trend really did surprise me. Here are a handful of examples where it happened -- notice what they have in common when I put them side-by-si de?

• People, it amazes me that some one can equate Linux, a shining example of sharing and cooperation, with capitalism, a system based on hoarding and selfishness. [Rodion Raskolnikov (), "POLL!! POLL!! POLL!!"]
  
  [The] only thing i can assume is that the author had only 1 thing in mind and that was to get people to join his movement. "Well if i can show that capitalism==GNU then fellow GNUers will join my organization or whatever". [Paul (paul@waterw.com), "Propaganda" ;]

  Open source functions on a gift economy. Sure, some of the behavior could be explained with free market principles ... but it is fundamentally different than the sort of role that the original essayist is trying to force it into. When I write code and I give it away, I get nothing but the satisfaction of writing interesting code, and the satisfaction that someone else is using it. That's not capitalism. [Anonymous Coward (), "Re: Back-asswards!"]

  It's always amusing to me to see some ultra captial weenies taking an idea like Open Source, which is effectively as socialistic as you can get in today's society falling all over themselves to cry out that it isn't, that capitalism and open source are exactly the same thing, yammer yammer yammer. [adr (jbfink@nospammy.entropy.muc .muohio.edu), "amusing"]

  Sheesh. Grow up. "Open Source" ... only superficially shares some ideas with economic theory. There's more to living than just money, and there are many more models of economy than just two. [Markus Fleck (!spam-fleck@informatik.uni-bonn.de), "Bla bla bla..."]

What these and so many other lines of criticism share is a clear misundersta nding of my thesis: they somehow latched onto the idea that I am identifying capitalist free markets and the Open Source movement as being the same thing, and then they went running down the rhetorical road on that false premise. Maybe I was not quite clear enough in the original piece, but I trust that if you look back up at my editorial with a little care, you will find that I never make such a claim. I was not even hoping for such an inference. Indeed, the summary in my conclusion seems quite clear about my hopes:

• So if you cheer for the idea of Open Source, then please cheer for what makes Open Source work. If you do that, then you are also cheering for exactly what makes capitalism work... These [common underpinnings] form a kind of systemic encouragement which brings out the very best within us -- and that is precisely what drives the raging success of both Open Source and capitalism.

Of course the Open Source movement and capitalist free markets are not one and the same, and I wouldn't want anyone to think so. My point is that they share a common foundation which fuels their tremendous effectiveness; these common underpinnings are themselves neither Open Source, nor capitalism -- but they foster both, and identifying them allows us to see and better understand the strengths of both Open Source and capitalism. This point leads naturally into my argument that capitalism is not fundamentally at odds with Open Source, a system which shares the same foundational underpinnings -- and so the mistrust and hostility I have been seeing directed at capitalism by some Open Source fans seems misplaced.

Open Source in the Here and Now

An interesting complaint surfaced regarding those underpinnings: some seem to think that it isn't legitimate that I rely on the fact that licenses like the GPL use the ideas of private property and the defense of individual rights, since by some interpretations of the Open Source Founders, its current form of is only accommodating our current circumstances and is not yet the Ideal Deal:

• The GPL exists (in this form) just because we live in a more or less capitalist world. Therefore it is adopted to the needs of this capitalist world. To conclude that because the GPL shows capitalistic elements, Open Source is capitalistic is IMHO an infinite loop. [Sebastian Schaffert (wastl@woanders.de), "Re: amusing", my underline]

  Open source matches the Marxist notion far better that the libertarian-ca pitalist notion, although it matches it only imperfectly. The GPL is very much a legal means of enforcing the kind of relationship that many believe ought to be natural law. It's a loophole, not the core of the philosophy. [vlax (vlax@yahoo.com) , "Sometimes, you just have to laugh", my underline]

But my observation is resting on the actual, stunning success of Open Source in today's world, on today's GPL terms, and in today's political systems -- not in some dreamt-of, hoped-for future place that may be talked about in recommended readings at the FSF. If someone wishes to argue that some other prospective Open Source system might do as well as (or better than) what we have today, then I welcome their giving it a try. But even if someone somehow makes that argument work, it wouldn't itself do anything to disturb my thesis that the powerful and successful Open Source movement we have before us right now shares the very same foundation as capitalism.

There's Cooperation -- and then there's Cooperation

Several people expressed trouble with my saying that "fundamentally, capitalism means cooperation":

• This is one of those motherhood statements that means nothing when you think about it carefully. Consider some alternatives:

  • "fundamentally, communism means cooperation"
  • "fundamentally, anarchism means cooperation"
  • "fundamentally, fascism means cooperation"
  • "acephalous band-level hunter-gatherer groups are fundamentally dependent on cooperation"

  The truth is, human existence pretty much "means cooperation". [Danny Yee (danny@anatomy.usyd.edu.au), "capitalism means cooperation?"]

  I agree entirely with [the] gripe on the assertion "capitalism means cooperation". It is a null statement. What societal system could exist at all without some degree of cooperation. [The Famous Brett Watson (famous@nutters.org), 'Null statement: "capitalism means cooperation"' ]

Certainly there is a lot of cooperation among people in most any societal system. But capitalism, with its explicit ban on fraud and the initiation of force between people for the express purpose of leaving people with nothing but persuasion and freedom of association in their dealings with one another, is quite different. Communism, fascism, socialism, and even our mixed economy, etc., do not consistently demand that we behave as traders, acting to mutual benefit, persuading our neighbor to work with us. Non-capitalist systems legitimatimize the initiation of (often quite naked) force as a common and convenient means of dealing with one another: all you need is to get the political pull or the popular votes to have your way, and others must "cooperate&quo t; -- whether they ultimately benefit or not, and whether they want to or not.

The Slavery of Wages

Okay, one final, tiny point.

• • When someone else makes that choice for you it is called slavery,

• Interesting comment coming from a capitalist.. So when my boss says "do that" I am a slave, eh? You're basically defining capitalism as wage slavery.. not a very good start on an essay that is supposed to defend capitalism. [ir (mattc@nospam.pob ox.com), "Free Software"]

Notice that I said "someone else makes that choice", not just that "something forces your choice". Despite appearances , I was actually being pretty careful about it. When your boss says "do that", you clearly have a choice where a slave does not: you can quit. But you would starve, you say? Not to be too flip about it (well, maybe just a little :^), but it sounds as if your primary complaint of "injustice" is with reality -- not with your boss. He should have freedom of association just as you should, and you have no right to do business with him unless he wants to do business with you (othewise you are not being a trader, and he would be a slave).

I know of no capitalist who would argue that you have a right to be exempt from the laws of reality.

Greg Perkins has written in with a nice paper on Open Source and Capitalism. A lot of people say that these ideas are oil and water, but click the link below and read what Greg has to say about it. Update Greg sent in response to the many comments. It's appended to the end of his original piece. The following was written by Slashdot reader Greg Perkins Open Source and Capitalism

Greg Perkins

Many people associate the idea of Open Source software with collectivism (socialism, communitarianism, or communism). This is understandable given the language and ideas of some of the movement's founders and prominent participants, and given the average political tendencies of college students (at least here in the US), who seem to form the core of the Open Source movement. That is of course no cause for concern. What troubles me is that I keep noticing an undercurrent of mistrust and even open hostility toward capitalism among Open Source fans. There is really no good reason for this, and I worry that it may grow into something truly dangerous to the movement.

I have seen it asked: how can capitalists enjoy and even embrace the Open Source ideal? Hidden in this question is the notion that capitalism is fundamentally incompatible with Open Source, and that collectivism is not. While this is sure to be a touchy subject, I would like to try sharing the principled perspective of the Other Side.

In contrast to the above, I think that it is capitalism which is harmonious with Open Source, and that collectivism is incompatible; principled and thoughtful Open Source advocates should want to fully embrace capitalism for exactly the same reasons they love the idea of Open Source.

The (Societal) Elements of Open Source

I know that most people here have studied the meaning and mechanism of Open Source pretty carefully (consider the popularity of Raymond's The Cathedral and the Bazaar, for example). Let's focus briefly on the crucial societal elements which Open Source depends on for its success:

First, Open Source depends on the idea that cooperation is the preferred mode for dealing with one another, that cooperation and voluntary association to mutual benefit is the most effective, most productive, and, well, simply the Right Way for people to live in society, as contrasted against the use of fraud or physical force. Individual Open Source authors have the right to choose what code they will write and with whom they might like to work -- nobody is allowed to make them do it. When someone else makes that choice for you it is called slavery, and Open Source couldn't be as successful as it is on those terms; peoples' active, willing participation is required.

Second, Open Source depends on the idea of the individual human right to private property. Code wouldn't exist except by the effort of the people who build it -- it is by their choice and their sweat that their code even exists, and so they naturally have the right to decide how they will deploy their creation (otherwise, why should they bother to create it in the first place?). Linus himself expressed this spirit perfectly when he said, "he who writes the code gets to choose the license, and nobody else gets to complain." Open Source authors generously choose to apply licenses like the GPL to their code, thereby exercising their right to dictate how their effort may be used (and how it may not be used).

And finally, Open Source requires the protection of private property rights by a government. People need more than to merely feel justified in saying how they wish their code to be used (and not used) -- they must have confidence that their wishes will not be violated and the product of their best efforts taken and used at just anybody's whim. People can be secure in their cooperation with one another toward whatever ends each may choose when their right to private property is protected. Doing so essentially means barring the initiation of physical force and fraud from peoples' legitimate dealings, leaving them with nothing but cooperation and trade to mutual benefit. We can see this confidence manifest as authors willingly write Open Source code, or help someone write Open Source code: they do so because they trust that the license will be enforced, that someone else cannot take advantage of them and direct their efforts to ends they do not wish.

Another Look at Capitalism

Here's the point that might surprise some Open Source advocates: the above three crucial factors are precisely the same foundation that is required for true, unadulterated, laissez-faire capitalism.

Capitalism is a social system which respects and defends peoples' individual human rights, including the right to property. Further, capitalism is epitomized by cooperation, not by competition -- competition arises in the context of several participants trying to out-cooperate each other in a division-of-labor economy. As a tiny example, consider the handful of pencil companies competing in "cutthroat, dog-eat-dog" manner with each other for the chance to cooperate with you. Now think about how many other economic partners each of them works with in trying to bring you that pencil, from the people mining the graphite and harvesting the wood and rubber, to the transport systems which take them to the factories full of people, the manufacturing and chemical engineers who design the processes, the marketing and distribution channels, and the retailer who makes it easy for you to have that pencil with little or no effort. Thousands and thousands of people all peacefully work in concert to bring you a pencil (not to mention all those who cooperate with them, and those who cooperate with them, and so on). Multiply that by all the other economic values in your life that aren't as insignificant as a humble pencil, and you can see that fundamentally, capitalism means cooperation.

Full-blown capitalism is actually the separation of market and state. In particular, it is not the current American- or European-style mixed economy, with some people and businesses having the ability to use government to secure special advantage over others by lobbying for taxes, regulations, etc. To the extent that people and companies can use government to indirectly compel others in economic matters, capitalism and everything that makes it great is undercut. In the same way that we react to proposals to control the press or the church, in a true capitalist system everybody would simply laugh at someone trying to use the heavy hand of government to some economic advantage. We would just point to the constitutional clause banning any such interference, telling them, "Tough beans -- why don't you try to persuade the people in the marketplace that you are worth doing business with?"

Common Grounds

So if you cheer for the idea of Open Source, then please cheer for what makes Open Source work. If you do that, then you are also cheering for exactly what makes capitalism work, and everything that makes it such a powerful force for improving the human lot in the world.

As a libertarian and staunch capitalist, I get a true charge out of seeing an innovative entrepreneur or inventor serving himself by serving his fellow man in some new, clever, or powerful way. As a software engineer and rabid Open Source advocate, I get a true charge out of seeing the genius behind Stallman's GPL and the meteoric rise of Open Source and GNU/Linux. What makes these great to me is the same in both cases: people are able to be productive and peacefully reap the rewards of their hard work as they see fit.

Banning fraud and the initiation of force in our dealings with one another, and respecting people and their choices as individuals by protecting their property rights... These form a kind of systemic encouragement which brings out the very best within us -- and that is precisely what drives the raging success of both Open Source and capitalism.

Recommended Reading

Economics in One Lesson by Henry Hazlitt is a classic, widely regarded as a wonderful (perhaps the best) first introduction to economics.

Capitalism: a Treatise on Economics by Dr. George Reisman is a lucid and encyclopedic account of capitalism and all things economic.

Also see the works of scholars from the Austrian school of economics, like Ludwig Von Mises and Friedrich A. Von Hayek (1974 Nobel in economics), or scholars from the Chicago school of economics, such as Milton Friedman (1976 Nobel in economics) or James Buchanan (1986 Nobel in economics).

A Followup from Greg Perkins

250 comments in a day -- what a wonderful firestorm of discussion!

Now, surely the more harsh commentators understand that in a short piece like my editorial, no author could even try to cover every anticipated objection or outright mistake in reading and reasoning that a minority of the audience might bring. That would simply bore or distract the majority of readers, perhaps to the point of missing the original thesis! I needed to leave such issues for the ensuing discussion.

And boy, I was pleasantly surprised by what happened! A horde of nimble-fing ered Slashdotters quickly jumped in after the first wave of commentary, answering and dissecting almost all of the incoming criticism quite nicely, relieving me of a lot of work -- thanks much, guys! :^)

However, there remain a couple of important themes that my quick-response comrades didn't address, and so I'll try to cover those here -- starting with the most important and surprising one.

What the Hay??

This trend really did surprise me. Here are a handful of examples where it happened -- notice what they have in common when I put them side-by-si de?

• People, it amazes me that some one can equate Linux, a shining example of sharing and cooperation, with capitalism, a system based on hoarding and selfishness. [Rodion Raskolnikov (), "POLL!! POLL!! POLL!!"]
  
  [The] only thing i can assume is that the author had only 1 thing in mind and that was to get people to join his movement. "Well if i can show that capitalism==GNU then fellow GNUers will join my organization or whatever". [Paul (paul@waterw.com), "Propaganda" ;]

  Open source functions on a gift economy. Sure, some of the behavior could be explained with free market principles ... but it is fundamentally different than the sort of role that the original essayist is trying to force it into. When I write code and I give it away, I get nothing but the satisfaction of writing interesting code, and the satisfaction that someone else is using it. That's not capitalism. [Anonymous Coward (), "Re: Back-asswards!"]

  It's always amusing to me to see some ultra captial weenies taking an idea like Open Source, which is effectively as socialistic as you can get in today's society falling all over themselves to cry out that it isn't, that capitalism and open source are exactly the same thing, yammer yammer yammer. [adr (jbfink@nospammy.entropy.muc .muohio.edu), "amusing"]

  Sheesh. Grow up. "Open Source" ... only superficially shares some ideas with economic theory. There's more to living than just money, and there are many more models of economy than just two. [Markus Fleck (!spam-fleck@informatik.uni-bonn.de), "Bla bla bla..."]

What these and so many other lines of criticism share is a clear misundersta nding of my thesis: they somehow latched onto the idea that I am identifying capitalist free markets and the Open Source movement as being the same thing, and then they went running down the rhetorical road on that false premise. Maybe I was not quite clear enough in the original piece, but I trust that if you look back up at my editorial with a little care, you will find that I never make such a claim. I was not even hoping for such an inference. Indeed, the summary in my conclusion seems quite clear about my hopes:

• So if you cheer for the idea of Open Source, then please cheer for what makes Open Source work. If you do that, then you are also cheering for exactly what makes capitalism work... These [common underpinnings] form a kind of systemic encouragement which brings out the very best within us -- and that is precisely what drives the raging success of both Open Source and capitalism.

Of course the Open Source movement and capitalist free markets are not one and the same, and I wouldn't want anyone to think so. My point is that they share a common foundation which fuels their tremendous effectiveness; these common underpinnings are themselves neither Open Source, nor capitalism -- but they foster both, and identifying them allows us to see and better understand the strengths of both Open Source and capitalism. This point leads naturally into my argument that capitalism is not fundamentally at odds with Open Source, a system which shares the same foundational underpinnings -- and so the mistrust and hostility I have been seeing directed at capitalism by some Open Source fans seems misplaced.

Open Source in the Here and Now

An interesting complaint surfaced regarding those underpinnings: some seem to think that it isn't legitimate that I rely on the fact that licenses like the GPL use the ideas of private property and the defense of individual rights, since by some interpretations of the Open Source Founders, its current form of is only accommodating our current circumstances and is not yet the Ideal Deal:

• The GPL exists (in this form) just because we live in a more or less capitalist world. Therefore it is adopted to the needs of this capitalist world. To conclude that because the GPL shows capitalistic elements, Open Source is capitalistic is IMHO an infinite loop. [Sebastian Schaffert (wastl@woanders.de), "Re: amusing", my underline]

  Open source matches the Marxist notion far better that the libertarian-ca pitalist notion, although it matches it only imperfectly. The GPL is very much a legal means of enforcing the kind of relationship that many believe ought to be natural law. It's a loophole, not the core of the philosophy. [vlax (vlax@yahoo.com) , "Sometimes, you just have to laugh", my underline]

But my observation is resting on the actual, stunning success of Open Source in today's world, on today's GPL terms, and in today's political systems -- not in some dreamt-of, hoped-for future place that may be talked about in recommended readings at the FSF. If someone wishes to argue that some other prospective Open Source system might do as well as (or better than) what we have today, then I welcome their giving it a try. But even if someone somehow makes that argument work, it wouldn't itself do anything to disturb my thesis that the powerful and successful Open Source movement we have before us right now shares the very same foundation as capitalism.

There's Cooperation -- and then there's Cooperation

Several people expressed trouble with my saying that "fundamentally, capitalism means cooperation":

• This is one of those motherhood statements that means nothing when you think about it carefully. Consider some alternatives:

  • "fundamentally, communism means cooperation"
  • "fundamentally, anarchism means cooperation"
  • "fundamentally, fascism means cooperation"
  • "acephalous band-level hunter-gatherer groups are fundamentally dependent on cooperation"

  The truth is, human existence pretty much "means cooperation". [Danny Yee (danny@anatomy.usyd.edu.au), "capitalism means cooperation?"]

  I agree entirely with [the] gripe on the assertion "capitalism means cooperation". It is a null statement. What societal system could exist at all without some degree of cooperation. [The Famous Brett Watson (famous@nutters.org), 'Null statement: "capitalism means cooperation"' ]

Certainly there is a lot of cooperation among people in most any societal system. But capitalism, with its explicit ban on fraud and the initiation of force between people for the express purpose of leaving people with nothing but persuasion and freedom of association in their dealings with one another, is quite different. Communism, fascism, socialism, and even our mixed economy, etc., do not consistently demand that we behave as traders, acting to mutual benefit, persuading our neighbor to work with us. Non-capitalist systems legitimatimize the initiation of (often quite naked) force as a common and convenient means of dealing with one another: all you need is to get the political pull or the popular votes to have your way, and others must "cooperate&quo t; -- whether they ultimately benefit or not, and whether they want to or not.

The Slavery of Wages

Okay, one final, tiny point.

• • When someone else makes that choice for you it is called slavery,

• Interesting comment coming from a capitalist.. So when my boss says "do that" I am a slave, eh? You're basically defining capitalism as wage slavery.. not a very good start on an essay that is supposed to defend capitalism. [ir (mattc@nospam.pob ox.com), "Free Software"]

Notice that I said "someone else makes that choice", not just that "something forces your choice". Despite appearances , I was actually being pretty careful about it. When your boss says "do that", you clearly have a choice where a slave does not: you can quit. But you would starve, you say? Not to be too flip about it (well, maybe just a little :^), but it sounds as if your primary complaint of "injustice" is with reality -- not with your boss. He should have freedom of association just as you should, and you have no right to do business with him unless he wants to do business with you (othewise you are not being a trader, and he would be a slave).

I know of no capitalist who would argue that you have a right to be exempt from the laws of reality.

Greg Perkins has written in with a nice paper on Open Source and Capitalism. A lot of people say that these ideas are oil and water, but click the link below and read what Greg has to say about it. Update Greg sent in response to the many comments. It's appended to the end of his original piece. The following was written by Slashdot reader Greg Perkins Open Source and Capitalism

Greg Perkins

Many people associate the idea of Open Source software with collectivism (socialism, communitarianism, or communism). This is understandable given the language and ideas of some of the movement's founders and prominent participants, and given the average political tendencies of college students (at least here in the US), who seem to form the core of the Open Source movement. That is of course no cause for concern. What troubles me is that I keep noticing an undercurrent of mistrust and even open hostility toward capitalism among Open Source fans. There is really no good reason for this, and I worry that it may grow into something truly dangerous to the movement.

I have seen it asked: how can capitalists enjoy and even embrace the Open Source ideal? Hidden in this question is the notion that capitalism is fundamentally incompatible with Open Source, and that collectivism is not. While this is sure to be a touchy subject, I would like to try sharing the principled perspective of the Other Side.

In contrast to the above, I think that it is capitalism which is harmonious with Open Source, and that collectivism is incompatible; principled and thoughtful Open Source advocates should want to fully embrace capitalism for exactly the same reasons they love the idea of Open Source.

The (Societal) Elements of Open Source

I know that most people here have studied the meaning and mechanism of Open Source pretty carefully (consider the popularity of Raymond's The Cathedral and the Bazaar, for example). Let's focus briefly on the crucial societal elements which Open Source depends on for its success:

First, Open Source depends on the idea that cooperation is the preferred mode for dealing with one another, that cooperation and voluntary association to mutual benefit is the most effective, most productive, and, well, simply the Right Way for people to live in society, as contrasted against the use of fraud or physical force. Individual Open Source authors have the right to choose what code they will write and with whom they might like to work -- nobody is allowed to make them do it. When someone else makes that choice for you it is called slavery, and Open Source couldn't be as successful as it is on those terms; peoples' active, willing participation is required.

Second, Open Source depends on the idea of the individual human right to private property. Code wouldn't exist except by the effort of the people who build it -- it is by their choice and their sweat that their code even exists, and so they naturally have the right to decide how they will deploy their creation (otherwise, why should they bother to create it in the first place?). Linus himself expressed this spirit perfectly when he said, "he who writes the code gets to choose the license, and nobody else gets to complain." Open Source authors generously choose to apply licenses like the GPL to their code, thereby exercising their right to dictate how their effort may be used (and how it may not be used).

And finally, Open Source requires the protection of private property rights by a government. People need more than to merely feel justified in saying how they wish their code to be used (and not used) -- they must have confidence that their wishes will not be violated and the product of their best efforts taken and used at just anybody's whim. People can be secure in their cooperation with one another toward whatever ends each may choose when their right to private property is protected. Doing so essentially means barring the initiation of physical force and fraud from peoples' legitimate dealings, leaving them with nothing but cooperation and trade to mutual benefit. We can see this confidence manifest as authors willingly write Open Source code, or help someone write Open Source code: they do so because they trust that the license will be enforced, that someone else cannot take advantage of them and direct their efforts to ends they do not wish.

Another Look at Capitalism

Here's the point that might surprise some Open Source advocates: the above three crucial factors are precisely the same foundation that is required for true, unadulterated, laissez-faire capitalism.

Capitalism is a social system which respects and defends peoples' individual human rights, including the right to property. Further, capitalism is epitomized by cooperation, not by competition -- competition arises in the context of several participants trying to out-cooperate each other in a division-of-labor economy. As a tiny example, consider the handful of pencil companies competing in "cutthroat, dog-eat-dog" manner with each other for the chance to cooperate with you. Now think about how many other economic partners each of them works with in trying to bring you that pencil, from the people mining the graphite and harvesting the wood and rubber, to the transport systems which take them to the factories full of people, the manufacturing and chemical engineers who design the processes, the marketing and distribution channels, and the retailer who makes it easy for you to have that pencil with little or no effort. Thousands and thousands of people all peacefully work in concert to bring you a pencil (not to mention all those who cooperate with them, and those who cooperate with them, and so on). Multiply that by all the other economic values in your life that aren't as insignificant as a humble pencil, and you can see that fundamentally, capitalism means cooperation.

Full-blown capitalism is actually the separation of market and state. In particular, it is not the current American- or European-style mixed economy, with some people and businesses having the ability to use government to secure special advantage over others by lobbying for taxes, regulations, etc. To the extent that people and companies can use government to indirectly compel others in economic matters, capitalism and everything that makes it great is undercut. In the same way that we react to proposals to control the press or the church, in a true capitalist system everybody would simply laugh at someone trying to use the heavy hand of government to some economic advantage. We would just point to the constitutional clause banning any such interference, telling them, "Tough beans -- why don't you try to persuade the people in the marketplace that you are worth doing business with?"

Common Grounds

So if you cheer for the idea of Open Source, then please cheer for what makes Open Source work. If you do that, then you are also cheering for exactly what makes capitalism work, and everything that makes it such a powerful force for improving the human lot in the world.

As a libertarian and staunch capitalist, I get a true charge out of seeing an innovative entrepreneur or inventor serving himself by serving his fellow man in some new, clever, or powerful way. As a software engineer and rabid Open Source advocate, I get a true charge out of seeing the genius behind Stallman's GPL and the meteoric rise of Open Source and GNU/Linux. What makes these great to me is the same in both cases: people are able to be productive and peacefully reap the rewards of their hard work as they see fit.

Banning fraud and the initiation of force in our dealings with one another, and respecting people and their choices as individuals by protecting their property rights... These form a kind of systemic encouragement which brings out the very best within us -- and that is precisely what drives the raging success of both Open Source and capitalism.

Recommended Reading

Economics in One Lesson by Henry Hazlitt is a classic, widely regarded as a wonderful (perhaps the best) first introduction to economics.

Capitalism: a Treatise on Economics by Dr. George Reisman is a lucid and encyclopedic account of capitalism and all things economic.

Also see the works of scholars from the Austrian school of economics, like Ludwig Von Mises and Friedrich A. Von Hayek (1974 Nobel in economics), or scholars from the Chicago school of economics, such as Milton Friedman (1976 Nobel in economics) or James Buchanan (1986 Nobel in economics).

A Followup from Greg Perkins

250 comments in a day -- what a wonderful firestorm of discussion!

Now, surely the more harsh commentators understand that in a short piece like my editorial, no author could even try to cover every anticipated objection or outright mistake in reading and reasoning that a minority of the audience might bring. That would simply bore or distract the majority of readers, perhaps to the point of missing the original thesis! I needed to leave such issues for the ensuing discussion.

And boy, I was pleasantly surprised by what happened! A horde of nimble-fing ered Slashdotters quickly jumped in after the first wave of commentary, answering and dissecting almost all of the incoming criticism quite nicely, relieving me of a lot of work -- thanks much, guys! :^)

However, there remain a couple of important themes that my quick-response comrades didn't address, and so I'll try to cover those here -- starting with the most important and surprising one.

What the Hay??

This trend really did surprise me. Here are a handful of examples where it happened -- notice what they have in common when I put them side-by-si de?

• People, it amazes me that some one can equate Linux, a shining example of sharing and cooperation, with capitalism, a system based on hoarding and selfishness. [Rodion Raskolnikov (), "POLL!! POLL!! POLL!!"]
  
  [The] only thing i can assume is that the author had only 1 thing in mind and that was to get people to join his movement. "Well if i can show that capitalism==GNU then fellow GNUers will join my organization or whatever". [Paul (paul@waterw.com), "Propaganda" ;]

  Open source functions on a gift economy. Sure, some of the behavior could be explained with free market principles ... but it is fundamentally different than the sort of role that the original essayist is trying to force it into. When I write code and I give it away, I get nothing but the satisfaction of writing interesting code, and the satisfaction that someone else is using it. That's not capitalism. [Anonymous Coward (), "Re: Back-asswards!"]

  It's always amusing to me to see some ultra captial weenies taking an idea like Open Source, which is effectively as socialistic as you can get in today's society falling all over themselves to cry out that it isn't, that capitalism and open source are exactly the same thing, yammer yammer yammer. [adr (jbfink@nospammy.entropy.muc .muohio.edu), "amusing"]

  Sheesh. Grow up. "Open Source" ... only superficially shares some ideas with economic theory. There's more to living than just money, and there are many more models of economy than just two. [Markus Fleck (!spam-fleck@informatik.uni-bonn.de), "Bla bla bla..."]

What these and so many other lines of criticism share is a clear misundersta nding of my thesis: they somehow latched onto the idea that I am identifying capitalist free markets and the Open Source movement as being the same thing, and then they went running down the rhetorical road on that false premise. Maybe I was not quite clear enough in the original piece, but I trust that if you look back up at my editorial with a little care, you will find that I never make such a claim. I was not even hoping for such an inference. Indeed, the summary in my conclusion seems quite clear about my hopes:

• So if you cheer for the idea of Open Source, then please cheer for what makes Open Source work. If you do that, then you are also cheering for exactly what makes capitalism work... These [common underpinnings] form a kind of systemic encouragement which brings out the very best within us -- and that is precisely what drives the raging success of both Open Source and capitalism.

Of course the Open Source movement and capitalist free markets are not one and the same, and I wouldn't want anyone to think so. My point is that they share a common foundation which fuels their tremendous effectiveness; these common underpinnings are themselves neither Open Source, nor capitalism -- but they foster both, and identifying them allows us to see and better understand the strengths of both Open Source and capitalism. This point leads naturally into my argument that capitalism is not fundamentally at odds with Open Source, a system which shares the same foundational underpinnings -- and so the mistrust and hostility I have been seeing directed at capitalism by some Open Source fans seems misplaced.

Open Source in the Here and Now

An interesting complaint surfaced regarding those underpinnings: some seem to think that it isn't legitimate that I rely on the fact that licenses like the GPL use the ideas of private property and the defense of individual rights, since by some interpretations of the Open Source Founders, its current form of is only accommodating our current circumstances and is not yet the Ideal Deal:

• The GPL exists (in this form) just because we live in a more or less capitalist world. Therefore it is adopted to the needs of this capitalist world. To conclude that because the GPL shows capitalistic elements, Open Source is capitalistic is IMHO an infinite loop. [Sebastian Schaffert (wastl@woanders.de), "Re: amusing", my underline]

  Open source matches the Marxist notion far better that the libertarian-ca pitalist notion, although it matches it only imperfectly. The GPL is very much a legal means of enforcing the kind of relationship that many believe ought to be natural law. It's a loophole, not the core of the philosophy. [vlax (vlax@yahoo.com) , "Sometimes, you just have to laugh", my underline]

But my observation is resting on the actual, stunning success of Open Source in today's world, on today's GPL terms, and in today's political systems -- not in some dreamt-of, hoped-for future place that may be talked about in recommended readings at the FSF. If someone wishes to argue that some other prospective Open Source system might do as well as (or better than) what we have today, then I welcome their giving it a try. But even if someone somehow makes that argument work, it wouldn't itself do anything to disturb my thesis that the powerful and successful Open Source movement we have before us right now shares the very same foundation as capitalism.

There's Cooperation -- and then there's Cooperation

Several people expressed trouble with my saying that "fundamentally, capitalism means cooperation":

• This is one of those motherhood statements that means nothing when you think about it carefully. Consider some alternatives:

  • "fundamentally, communism means cooperation"
  • "fundamentally, anarchism means cooperation"
  • "fundamentally, fascism means cooperation"
  • "acephalous band-level hunter-gatherer groups are fundamentally dependent on cooperation"

  The truth is, human existence pretty much "means cooperation". [Danny Yee (danny@anatomy.usyd.edu.au), "capitalism means cooperation?"]

  I agree entirely with [the] gripe on the assertion "capitalism means cooperation". It is a null statement. What societal system could exist at all without some degree of cooperation. [The Famous Brett Watson (famous@nutters.org), 'Null statement: "capitalism means cooperation"' ]

Certainly there is a lot of cooperation among people in most any societal system. But capitalism, with its explicit ban on fraud and the initiation of force between people for the express purpose of leaving people with nothing but persuasion and freedom of association in their dealings with one another, is quite different. Communism, fascism, socialism, and even our mixed economy, etc., do not consistently demand that we behave as traders, acting to mutual benefit, persuading our neighbor to work with us. Non-capitalist systems legitimatimize the initiation of (often quite naked) force as a common and convenient means of dealing with one another: all you need is to get the political pull or the popular votes to have your way, and others must "cooperate&quo t; -- whether they ultimately benefit or not, and whether they want to or not.

The Slavery of Wages

Okay, one final, tiny point.

• • When someone else makes that choice for you it is called slavery,

• Interesting comment coming from a capitalist.. So when my boss says "do that" I am a slave, eh? You're basically defining capitalism as wage slavery.. not a very good start on an essay that is supposed to defend capitalism. [ir (mattc@nospam.pob ox.com), "Free Software"]

Notice that I said "someone else makes that choice", not just that "something forces your choice". Despite appearances , I was actually being pretty careful about it. When your boss says "do that", you clearly have a choice where a slave does not: you can quit. But you would starve, you say? Not to be too flip about it (well, maybe just a little :^), but it sounds as if your primary complaint of "injustice" is with reality -- not with your boss. He should have freedom of association just as you should, and you have no right to do business with him unless he wants to do business with you (othewise you are not being a trader, and he would be a slave).

I know of no capitalist who would argue that you have a right to be exempt from the laws of reality.

Greg Perkins has written in with a nice paper on Open Source and Capitalism. A lot of people say that these ideas are oil and water, but click the link below and read what Greg has to say about it. Update Greg sent in response to the many comments. It's appended to the end of his original piece. The following was written by Slashdot reader Greg Perkins Open Source and Capitalism

Greg Perkins

Many people associate the idea of Open Source software with collectivism (socialism, communitarianism, or communism). This is understandable given the language and ideas of some of the movement's founders and prominent participants, and given the average political tendencies of college students (at least here in the US), who seem to form the core of the Open Source movement. That is of course no cause for concern. What troubles me is that I keep noticing an undercurrent of mistrust and even open hostility toward capitalism among Open Source fans. There is really no good reason for this, and I worry that it may grow into something truly dangerous to the movement.

I have seen it asked: how can capitalists enjoy and even embrace the Open Source ideal? Hidden in this question is the notion that capitalism is fundamentally incompatible with Open Source, and that collectivism is not. While this is sure to be a touchy subject, I would like to try sharing the principled perspective of the Other Side.

In contrast to the above, I think that it is capitalism which is harmonious with Open Source, and that collectivism is incompatible; principled and thoughtful Open Source advocates should want to fully embrace capitalism for exactly the same reasons they love the idea of Open Source.

The (Societal) Elements of Open Source

I know that most people here have studied the meaning and mechanism of Open Source pretty carefully (consider the popularity of Raymond's The Cathedral and the Bazaar, for example). Let's focus briefly on the crucial societal elements which Open Source depends on for its success:

First, Open Source depends on the idea that cooperation is the preferred mode for dealing with one another, that cooperation and voluntary association to mutual benefit is the most effective, most productive, and, well, simply the Right Way for people to live in society, as contrasted against the use of fraud or physical force. Individual Open Source authors have the right to choose what code they will write and with whom they might like to work -- nobody is allowed to make them do it. When someone else makes that choice for you it is called slavery, and Open Source couldn't be as successful as it is on those terms; peoples' active, willing participation is required.

Second, Open Source depends on the idea of the individual human right to private property. Code wouldn't exist except by the effort of the people who build it -- it is by their choice and their sweat that their code even exists, and so they naturally have the right to decide how they will deploy their creation (otherwise, why should they bother to create it in the first place?). Linus himself expressed this spirit perfectly when he said, "he who writes the code gets to choose the license, and nobody else gets to complain." Open Source authors generously choose to apply licenses like the GPL to their code, thereby exercising their right to dictate how their effort may be used (and how it may not be used).

And finally, Open Source requires the protection of private property rights by a government. People need more than to merely feel justified in saying how they wish their code to be used (and not used) -- they must have confidence that their wishes will not be violated and the product of their best efforts taken and used at just anybody's whim. People can be secure in their cooperation with one another toward whatever ends each may choose when their right to private property is protected. Doing so essentially means barring the initiation of physical force and fraud from peoples' legitimate dealings, leaving them with nothing but cooperation and trade to mutual benefit. We can see this confidence manifest as authors willingly write Open Source code, or help someone write Open Source code: they do so because they trust that the license will be enforced, that someone else cannot take advantage of them and direct their efforts to ends they do not wish.

Another Look at Capitalism

Here's the point that might surprise some Open Source advocates: the above three crucial factors are precisely the same foundation that is required for true, unadulterated, laissez-faire capitalism.

Capitalism is a social system which respects and defends peoples' individual human rights, including the right to property. Further, capitalism is epitomized by cooperation, not by competition -- competition arises in the context of several participants trying to out-cooperate each other in a division-of-labor economy. As a tiny example, consider the handful of pencil companies competing in "cutthroat, dog-eat-dog" manner with each other for the chance to cooperate with you. Now think about how many other economic partners each of them works with in trying to bring you that pencil, from the people mining the graphite and harvesting the wood and rubber, to the transport systems which take them to the factories full of people, the manufacturing and chemical engineers who design the processes, the marketing and distribution channels, and the retailer who makes it easy for you to have that pencil with little or no effort. Thousands and thousands of people all peacefully work in concert to bring you a pencil (not to mention all those who cooperate with them, and those who cooperate with them, and so on). Multiply that by all the other economic values in your life that aren't as insignificant as a humble pencil, and you can see that fundamentally, capitalism means cooperation.

Full-blown capitalism is actually the separation of market and state. In particular, it is not the current American- or European-style mixed economy, with some people and businesses having the ability to use government to secure special advantage over others by lobbying for taxes, regulations, etc. To the extent that people and companies can use government to indirectly compel others in economic matters, capitalism and everything that makes it great is undercut. In the same way that we react to proposals to control the press or the church, in a true capitalist system everybody would simply laugh at someone trying to use the heavy hand of government to some economic advantage. We would just point to the constitutional clause banning any such interference, telling them, "Tough beans -- why don't you try to persuade the people in the marketplace that you are worth doing business with?"

Common Grounds

So if you cheer for the idea of Open Source, then please cheer for what makes Open Source work. If you do that, then you are also cheering for exactly what makes capitalism work, and everything that makes it such a powerful force for improving the human lot in the world.

As a libertarian and staunch capitalist, I get a true charge out of seeing an innovative entrepreneur or inventor serving himself by serving his fellow man in some new, clever, or powerful way. As a software engineer and rabid Open Source advocate, I get a true charge out of seeing the genius behind Stallman's GPL and the meteoric rise of Open Source and GNU/Linux. What makes these great to me is the same in both cases: people are able to be productive and peacefully reap the rewards of their hard work as they see fit.

Banning fraud and the initiation of force in our dealings with one another, and respecting people and their choices as individuals by protecting their property rights... These form a kind of systemic encouragement which brings out the very best within us -- and that is precisely what drives the raging success of both Open Source and capitalism.

Recommended Reading

Economics in One Lesson by Henry Hazlitt is a classic, widely regarded as a wonderful (perhaps the best) first introduction to economics.

Capitalism: a Treatise on Economics by Dr. George Reisman is a lucid and encyclopedic account of capitalism and all things economic.

Also see the works of scholars from the Austrian school of economics, like Ludwig Von Mises and Friedrich A. Von Hayek (1974 Nobel in economics), or scholars from the Chicago school of economics, such as Milton Friedman (1976 Nobel in economics) or James Buchanan (1986 Nobel in economics).

A Followup from Greg Perkins

250 comments in a day -- what a wonderful firestorm of discussion!

Now, surely the more harsh commentators understand that in a short piece like my editorial, no author could even try to cover every anticipated objection or outright mistake in reading and reasoning that a minority of the audience might bring. That would simply bore or distract the majority of readers, perhaps to the point of missing the original thesis! I needed to leave such issues for the ensuing discussion.

And boy, I was pleasantly surprised by what happened! A horde of nimble-fing ered Slashdotters quickly jumped in after the first wave of commentary, answering and dissecting almost all of the incoming criticism quite nicely, relieving me of a lot of work -- thanks much, guys! :^)

However, there remain a couple of important themes that my quick-response comrades didn't address, and so I'll try to cover those here -- starting with the most important and surprising one.

What the Hay??

This trend really did surprise me. Here are a handful of examples where it happened -- notice what they have in common when I put them side-by-si de?

• People, it amazes me that some one can equate Linux, a shining example of sharing and cooperation, with capitalism, a system based on hoarding and selfishness. [Rodion Raskolnikov (), "POLL!! POLL!! POLL!!"]
  
  [The] only thing i can assume is that the author had only 1 thing in mind and that was to get people to join his movement. "Well if i can show that capitalism==GNU then fellow GNUers will join my organization or whatever". [Paul (paul@waterw.com), "Propaganda" ;]

  Open source functions on a gift economy. Sure, some of the behavior could be explained with free market principles ... but it is fundamentally different than the sort of role that the original essayist is trying to force it into. When I write code and I give it away, I get nothing but the satisfaction of writing interesting code, and the satisfaction that someone else is using it. That's not capitalism. [Anonymous Coward (), "Re: Back-asswards!"]

  It's always amusing to me to see some ultra captial weenies taking an idea like Open Source, which is effectively as socialistic as you can get in today's society falling all over themselves to cry out that it isn't, that capitalism and open source are exactly the same thing, yammer yammer yammer. [adr (jbfink@nospammy.entropy.muc .muohio.edu), "amusing"]

  Sheesh. Grow up. "Open Source" ... only superficially shares some ideas with economic theory. There's more to living than just money, and there are many more models of economy than just two. [Markus Fleck (!spam-fleck@informatik.uni-bonn.de), "Bla bla bla..."]

What these and so many other lines of criticism share is a clear misundersta nding of my thesis: they somehow latched onto the idea that I am identifying capitalist free markets and the Open Source movement as being the same thing, and then they went running down the rhetorical road on that false premise. Maybe I was not quite clear enough in the original piece, but I trust that if you look back up at my editorial with a little care, you will find that I never make such a claim. I was not even hoping for such an inference. Indeed, the summary in my conclusion seems quite clear about my hopes:

• So if you cheer for the idea of Open Source, then please cheer for what makes Open Source work. If you do that, then you are also cheering for exactly what makes capitalism work... These [common underpinnings] form a kind of systemic encouragement which brings out the very best within us -- and that is precisely what drives the raging success of both Open Source and capitalism.

Of course the Open Source movement and capitalist free markets are not one and the same, and I wouldn't want anyone to think so. My point is that they share a common foundation which fuels their tremendous effectiveness; these common underpinnings are themselves neither Open Source, nor capitalism -- but they foster both, and identifying them allows us to see and better understand the strengths of both Open Source and capitalism. This point leads naturally into my argument that capitalism is not fundamentally at odds with Open Source, a system which shares the same foundational underpinnings -- and so the mistrust and hostility I have been seeing directed at capitalism by some Open Source fans seems misplaced.

Open Source in the Here and Now

An interesting complaint surfaced regarding those underpinnings: some seem to think that it isn't legitimate that I rely on the fact that licenses like the GPL use the ideas of private property and the defense of individual rights, since by some interpretations of the Open Source Founders, its current form of is only accommodating our current circumstances and is not yet the Ideal Deal:

• The GPL exists (in this form) just because we live in a more or less capitalist world. Therefore it is adopted to the needs of this capitalist world. To conclude that because the GPL shows capitalistic elements, Open Source is capitalistic is IMHO an infinite loop. [Sebastian Schaffert (wastl@woanders.de), "Re: amusing", my underline]

  Open source matches the Marxist notion far better that the libertarian-ca pitalist notion, although it matches it only imperfectly. The GPL is very much a legal means of enforcing the kind of relationship that many believe ought to be natural law. It's a loophole, not the core of the philosophy. [vlax (vlax@yahoo.com) , "Sometimes, you just have to laugh", my underline]

But my observation is resting on the actual, stunning success of Open Source in today's world, on today's GPL terms, and in today's political systems -- not in some dreamt-of, hoped-for future place that may be talked about in recommended readings at the FSF. If someone wishes to argue that some other prospective Open Source system might do as well as (or better than) what we have today, then I welcome their giving it a try. But even if someone somehow makes that argument work, it wouldn't itself do anything to disturb my thesis that the powerful and successful Open Source movement we have before us right now shares the very same foundation as capitalism.

There's Cooperation -- and then there's Cooperation

Several people expressed trouble with my saying that "fundamentally, capitalism means cooperation":

• This is one of those motherhood statements that means nothing when you think about it carefully. Consider some alternatives:

  • "fundamentally, communism means cooperation"
  • "fundamentally, anarchism means cooperation"
  • "fundamentally, fascism means cooperation"
  • "acephalous band-level hunter-gatherer groups are fundamentally dependent on cooperation"

  The truth is, human existence pretty much "means cooperation". [Danny Yee (danny@anatomy.usyd.edu.au), "capitalism means cooperation?"]

  I agree entirely with [the] gripe on the assertion "capitalism means cooperation". It is a null statement. What societal system could exist at all without some degree of cooperation. [The Famous Brett Watson (famous@nutters.org), 'Null statement: "capitalism means cooperation"' ]

Certainly there is a lot of cooperation among people in most any societal system. But capitalism, with its explicit ban on fraud and the initiation of force between people for the express purpose of leaving people with nothing but persuasion and freedom of association in their dealings with one another, is quite different. Communism, fascism, socialism, and even our mixed economy, etc., do not consistently demand that we behave as traders, acting to mutual benefit, persuading our neighbor to work with us. Non-capitalist systems legitimatimize the initiation of (often quite naked) force as a common and convenient means of dealing with one another: all you need is to get the political pull or the popular votes to have your way, and others must "cooperate&quo t; -- whether they ultimately benefit or not, and whether they want to or not.

The Slavery of Wages

Okay, one final, tiny point.

• • When someone else makes that choice for you it is called slavery,

• Interesting comment coming from a capitalist.. So when my boss says "do that" I am a slave, eh? You're basically defining capitalism as wage slavery.. not a very good start on an essay that is supposed to defend capitalism. [ir (mattc@nospam.pob ox.com), "Free Software"]

Notice that I said "someone else makes that choice", not just that "something forces your choice". Despite appearances , I was actually being pretty careful about it. When your boss says "do that", you clearly have a choice where a slave does not: you can quit. But you would starve, you say? Not to be too flip about it (well, maybe just a little :^), but it sounds as if your primary complaint of "injustice" is with reality -- not with your boss. He should have freedom of association just as you should, and you have no right to do business with him unless he wants to do business with you (othewise you are not being a trader, and he would be a slave).

I know of no capitalist who would argue that you have a right to be exempt from the laws of reality.

Greg Perkins has written in with a nice paper on Open Source and Capitalism. A lot of people say that these ideas are oil and water, but click the link below and read what Greg has to say about it. Update Greg sent in response to the many comments. It's appended to the end of his original piece. The following was written by Slashdot reader Greg Perkins Open Source and Capitalism

Greg Perkins

Many people associate the idea of Open Source software with collectivism (socialism, communitarianism, or communism). This is understandable given the language and ideas of some of the movement's founders and prominent participants, and given the average political tendencies of college students (at least here in the US), who seem to form the core of the Open Source movement. That is of course no cause for concern. What troubles me is that I keep noticing an undercurrent of mistrust and even open hostility toward capitalism among Open Source fans. There is really no good reason for this, and I worry that it may grow into something truly dangerous to the movement.

I have seen it asked: how can capitalists enjoy and even embrace the Open Source ideal? Hidden in this question is the notion that capitalism is fundamentally incompatible with Open Source, and that collectivism is not. While this is sure to be a touchy subject, I would like to try sharing the principled perspective of the Other Side.

In contrast to the above, I think that it is capitalism which is harmonious with Open Source, and that collectivism is incompatible; principled and thoughtful Open Source advocates should want to fully embrace capitalism for exactly the same reasons they love the idea of Open Source.

The (Societal) Elements of Open Source

I know that most people here have studied the meaning and mechanism of Open Source pretty carefully (consider the popularity of Raymond's The Cathedral and the Bazaar, for example). Let's focus briefly on the crucial societal elements which Open Source depends on for its success:

First, Open Source depends on the idea that cooperation is the preferred mode for dealing with one another, that cooperation and voluntary association to mutual benefit is the most effective, most productive, and, well, simply the Right Way for people to live in society, as contrasted against the use of fraud or physical force. Individual Open Source authors have the right to choose what code they will write and with whom they might like to work -- nobody is allowed to make them do it. When someone else makes that choice for you it is called slavery, and Open Source couldn't be as successful as it is on those terms; peoples' active, willing participation is required.

Second, Open Source depends on the idea of the individual human right to private property. Code wouldn't exist except by the effort of the people who build it -- it is by their choice and their sweat that their code even exists, and so they naturally have the right to decide how they will deploy their creation (otherwise, why should they bother to create it in the first place?). Linus himself expressed this spirit perfectly when he said, "he who writes the code gets to choose the license, and nobody else gets to complain." Open Source authors generously choose to apply licenses like the GPL to their code, thereby exercising their right to dictate how their effort may be used (and how it may not be used).

And finally, Open Source requires the protection of private property rights by a government. People need more than to merely feel justified in saying how they wish their code to be used (and not used) -- they must have confidence that their wishes will not be violated and the product of their best efforts taken and used at just anybody's whim. People can be secure in their cooperation with one another toward whatever ends each may choose when their right to private property is protected. Doing so essentially means barring the initiation of physical force and fraud from peoples' legitimate dealings, leaving them with nothing but cooperation and trade to mutual benefit. We can see this confidence manifest as authors willingly write Open Source code, or help someone write Open Source code: they do so because they trust that the license will be enforced, that someone else cannot take advantage of them and direct their efforts to ends they do not wish.

Another Look at Capitalism

Here's the point that might surprise some Open Source advocates: the above three crucial factors are precisely the same foundation that is required for true, unadulterated, laissez-faire capitalism.

Capitalism is a social system which respects and defends peoples' individual human rights, including the right to property. Further, capitalism is epitomized by cooperation, not by competition -- competition arises in the context of several participants trying to out-cooperate each other in a division-of-labor economy. As a tiny example, consider the handful of pencil companies competing in "cutthroat, dog-eat-dog" manner with each other for the chance to cooperate with you. Now think about how many other economic partners each of them works with in trying to bring you that pencil, from the people mining the graphite and harvesting the wood and rubber, to the transport systems which take them to the factories full of people, the manufacturing and chemical engineers who design the processes, the marketing and distribution channels, and the retailer who makes it easy for you to have that pencil with little or no effort. Thousands and thousands of people all peacefully work in concert to bring you a pencil (not to mention all those who cooperate with them, and those who cooperate with them, and so on). Multiply that by all the other economic values in your life that aren't as insignificant as a humble pencil, and you can see that fundamentally, capitalism means cooperation.

Full-blown capitalism is actually the separation of market and state. In particular, it is not the current American- or European-style mixed economy, with some people and businesses having the ability to use government to secure special advantage over others by lobbying for taxes, regulations, etc. To the extent that people and companies can use government to indirectly compel others in economic matters, capitalism and everything that makes it great is undercut. In the same way that we react to proposals to control the press or the church, in a true capitalist system everybody would simply laugh at someone trying to use the heavy hand of government to some economic advantage. We would just point to the constitutional clause banning any such interference, telling them, "Tough beans -- why don't you try to persuade the people in the marketplace that you are worth doing business with?"

Common Grounds

So if you cheer for the idea of Open Source, then please cheer for what makes Open Source work. If you do that, then you are also cheering for exactly what makes capitalism work, and everything that makes it such a powerful force for improving the human lot in the world.

As a libertarian and staunch capitalist, I get a true charge out of seeing an innovative entrepreneur or inventor serving himself by serving his fellow man in some new, clever, or powerful way. As a software engineer and rabid Open Source advocate, I get a true charge out of seeing the genius behind Stallman's GPL and the meteoric rise of Open Source and GNU/Linux. What makes these great to me is the same in both cases: people are able to be productive and peacefully reap the rewards of their hard work as they see fit.

Banning fraud and the initiation of force in our dealings with one another, and respecting people and their choices as individuals by protecting their property rights... These form a kind of systemic encouragement which brings out the very best within us -- and that is precisely what drives the raging success of both Open Source and capitalism.

Recommended Reading

Economics in One Lesson by Henry Hazlitt is a classic, widely regarded as a wonderful (perhaps the best) first introduction to economics.

Capitalism: a Treatise on Economics by Dr. George Reisman is a lucid and encyclopedic account of capitalism and all things economic.

Also see the works of scholars from the Austrian school of economics, like Ludwig Von Mises and Friedrich A. Von Hayek (1974 Nobel in economics), or scholars from the Chicago school of economics, such as Milton Friedman (1976 Nobel in economics) or James Buchanan (1986 Nobel in economics).

A Followup from Greg Perkins

250 comments in a day -- what a wonderful firestorm of discussion!

Now, surely the more harsh commentators understand that in a short piece like my editorial, no author could even try to cover every anticipated objection or outright mistake in reading and reasoning that a minority of the audience might bring. That would simply bore or distract the majority of readers, perhaps to the point of missing the original thesis! I needed to leave such issues for the ensuing discussion.

And boy, I was pleasantly surprised by what happened! A horde of nimble-fing ered Slashdotters quickly jumped in after the first wave of commentary, answering and dissecting almost all of the incoming criticism quite nicely, relieving me of a lot of work -- thanks much, guys! :^)

However, there remain a couple of important themes that my quick-response comrades didn't address, and so I'll try to cover those here -- starting with the most important and surprising one.

What the Hay??

This trend really did surprise me. Here are a handful of examples where it happened -- notice what they have in common when I put them side-by-si de?

• People, it amazes me that some one can equate Linux, a shining example of sharing and cooperation, with capitalism, a system based on hoarding and selfishness. [Rodion Raskolnikov (), "POLL!! POLL!! POLL!!"]
  
  [The] only thing i can assume is that the author had only 1 thing in mind and that was to get people to join his movement. "Well if i can show that capitalism==GNU then fellow GNUers will join my organization or whatever". [Paul (paul@waterw.com), "Propaganda" ;]

  Open source functions on a gift economy. Sure, some of the behavior could be explained with free market principles ... but it is fundamentally different than the sort of role that the original essayist is trying to force it into. When I write code and I give it away, I get nothing but the satisfaction of writing interesting code, and the satisfaction that someone else is using it. That's not capitalism. [Anonymous Coward (), "Re: Back-asswards!"]

  It's always amusing to me to see some ultra captial weenies taking an idea like Open Source, which is effectively as socialistic as you can get in today's society falling all over themselves to cry out that it isn't, that capitalism and open source are exactly the same thing, yammer yammer yammer. [adr (jbfink@nospammy.entropy.muc .muohio.edu), "amusing"]

  Sheesh. Grow up. "Open Source" ... only superficially shares some ideas with economic theory. There's more to living than just money, and there are many more models of economy than just two. [Markus Fleck (!spam-fleck@informatik.uni-bonn.de), "Bla bla bla..."]

What these and so many other lines of criticism share is a clear misundersta nding of my thesis: they somehow latched onto the idea that I am identifying capitalist free markets and the Open Source movement as being the same thing, and then they went running down the rhetorical road on that false premise. Maybe I was not quite clear enough in the original piece, but I trust that if you look back up at my editorial with a little care, you will find that I never make such a claim. I was not even hoping for such an inference. Indeed, the summary in my conclusion seems quite clear about my hopes:

• So if you cheer for the idea of Open Source, then please cheer for what makes Open Source work. If you do that, then you are also cheering for exactly what makes capitalism work... These [common underpinnings] form a kind of systemic encouragement which brings out the very best within us -- and that is precisely what drives the raging success of both Open Source and capitalism.

Of course the Open Source movement and capitalist free markets are not one and the same, and I wouldn't want anyone to think so. My point is that they share a common foundation which fuels their tremendous effectiveness; these common underpinnings are themselves neither Open Source, nor capitalism -- but they foster both, and identifying them allows us to see and better understand the strengths of both Open Source and capitalism. This point leads naturally into my argument that capitalism is not fundamentally at odds with Open Source, a system which shares the same foundational underpinnings -- and so the mistrust and hostility I have been seeing directed at capitalism by some Open Source fans seems misplaced.

Open Source in the Here and Now

An interesting complaint surfaced regarding those underpinnings: some seem to think that it isn't legitimate that I rely on the fact that licenses like the GPL use the ideas of private property and the defense of individual rights, since by some interpretations of the Open Source Founders, its current form of is only accommodating our current circumstances and is not yet the Ideal Deal:

• The GPL exists (in this form) just because we live in a more or less capitalist world. Therefore it is adopted to the needs of this capitalist world. To conclude that because the GPL shows capitalistic elements, Open Source is capitalistic is IMHO an infinite loop. [Sebastian Schaffert (wastl@woanders.de), "Re: amusing", my underline]

  Open source matches the Marxist notion far better that the libertarian-ca pitalist notion, although it matches it only imperfectly. The GPL is very much a legal means of enforcing the kind of relationship that many believe ought to be natural law. It's a loophole, not the core of the philosophy. [vlax (vlax@yahoo.com) , "Sometimes, you just have to laugh", my underline]

But my observation is resting on the actual, stunning success of Open Source in today's world, on today's GPL terms, and in today's political systems -- not in some dreamt-of, hoped-for future place that may be talked about in recommended readings at the FSF. If someone wishes to argue that some other prospective Open Source system might do as well as (or better than) what we have today, then I welcome their giving it a try. But even if someone somehow makes that argument work, it wouldn't itself do anything to disturb my thesis that the powerful and successful Open Source movement we have before us right now shares the very same foundation as capitalism.

There's Cooperation -- and then there's Cooperation

Several people expressed trouble with my saying that "fundamentally, capitalism means cooperation":

• This is one of those motherhood statements that means nothing when you think about it carefully. Consider some alternatives:

  • "fundamentally, communism means cooperation"
  • "fundamentally, anarchism means cooperation"
  • "fundamentally, fascism means cooperation"
  • "acephalous band-level hunter-gatherer groups are fundamentally dependent on cooperation"

  The truth is, human existence pretty much "means cooperation". [Danny Yee (danny@anatomy.usyd.edu.au), "capitalism means cooperation?"]

  I agree entirely with [the] gripe on the assertion "capitalism means cooperation". It is a null statement. What societal system could exist at all without some degree of cooperation. [The Famous Brett Watson (famous@nutters.org), 'Null statement: "capitalism means cooperation"' ]

Certainly there is a lot of cooperation among people in most any societal system. But capitalism, with its explicit ban on fraud and the initiation of force between people for the express purpose of leaving people with nothing but persuasion and freedom of association in their dealings with one another, is quite different. Communism, fascism, socialism, and even our mixed economy, etc., do not consistently demand that we behave as traders, acting to mutual benefit, persuading our neighbor to work with us. Non-capitalist systems legitimatimize the initiation of (often quite naked) force as a common and convenient means of dealing with one another: all you need is to get the political pull or the popular votes to have your way, and others must "cooperate&quo t; -- whether they ultimately benefit or not, and whether they want to or not.

The Slavery of Wages

Okay, one final, tiny point.

• • When someone else makes that choice for you it is called slavery,

• Interesting comment coming from a capitalist.. So when my boss says "do that" I am a slave, eh? You're basically defining capitalism as wage slavery.. not a very good start on an essay that is supposed to defend capitalism. [ir (mattc@nospam.pob ox.com), "Free Software"]

Notice that I said "someone else makes that choice", not just that "something forces your choice". Despite appearances , I was actually being pretty careful about it. When your boss says "do that", you clearly have a choice where a slave does not: you can quit. But you would starve, you say? Not to be too flip about it (well, maybe just a little :^), but it sounds as if your primary complaint of "injustice" is with reality -- not with your boss. He should have freedom of association just as you should, and you have no right to do business with him unless he wants to do business with you (othewise you are not being a trader, and he would be a slave).

I know of no capitalist who would argue that you have a right to be exempt from the laws of reality.

Slashdot reader (and now reviewer) Mark Pruett sent us a book that has pretty critical importance, Linux Application Development . If we are really to win the world over, we must have more and more applications. That, and write them well. If you want to do that, read below. Linux Application Development author Michael K. Johnson and Eric W. Troan pages publisher Addison-Wesley rating 9/10 reviewer Mark Pruett ISBN 0-201-30821-5 summary

A clear, concise, practical book for C programmers trying to grasp the nuances of the Linux operating system.

Linux Application Development is one of the few 500+ page computer books published today that deserves its length. It was written by Michael K. Johnson and Eric W. Troan, two names that some SlashDot readers may recognize. These guys are developers for Red Hat Software.

This book fills the need for a concise, clear, no-nonsense book on how to write C programs that run well in the Linux environment. It is short on history and devoid of political diatribe.

Who Needs This Book?

This book is aimed at experienced programmers. It most definitely won't teach you how to program. But programmers moving from another operating system (other Unix variants or any Microsoft platform) will get a big boost up the learning curve.

Having come to Linux almost four years ago after a decade or so as a DOS/Windows programmer, I know this book can be invaluable. Linux (and Unix in general) is a different mindset than Microsoft Windows, and while this book spends no time directly comparing the two operating systems, it does provide the map a Windows programmer needs to make the transition.

The book is broken into four sections. Getting Started provides a brief history of Linux, an overview of the different free software licenses, an explanation of Linux documentation, and pointers to Linux information on the internet.

The second section covers Development Tools and Environment. Make no mistake: this is a book for C programmers. There's information here on the GNU gcc compiler, on vi and Emacs, on Make, on the GNU Debugger, and on memory debugging tools like Checker and Electric Fence. A highlight of this section is the chapter Creating and Using Libraries; this contains information especially useful to programmers new to the Linux OS.

Most of the information in this second section is not in-depth. Rather, it lets you know these tools exist. You'll need to find other references in order to master them.

Systems Programming in Linux

The third section, System Programming, provides the real meat of the book. It features chapters on the Process Model, Simple and Advanced File Handling, Directory Operations, Signal Processing, Job Control, Sockets, and a lot more.

You can tell these guys write code for a living. Their example programs are practical, and serve as good illustrations the topic they're covering. Their explanations are clear and precise; they don't waste your time.

For example, here's their explanation of the getservbyname() function:

Linux systems include the file /etc/services, which maps protocols to port numbers. The most common way to access this file is through the getservbyname() function, which returns information on a particular service.

#include <netdb.h>

struct servent * getservbyname(const char * name,
const char * protocol);

The first parameter, name, is the service name about which the application needs information. The protocol parameter specifies the protocol that will be used. The services database contains information on other protocols (especially UDP); specifying the protocol allows the function to ignore information on other protocols. The protocol is usually the string "tcp", though other protocol names, such as "udp", may be used.

I read arguments in the discussion that followed Arjen Laarhoven's review of Stevens' Advanced Programming in the Unix environment to the effect that the unix man pages are all that a programmer might want or need. I'll leave it as an exercise for the reader to compare the passage above with "man getservbyname". The latter tells you the how, the former tells you the why and the what.

This third section alone is, in my opinion, worth the price of the book.

The final section of the book covers Development Libraries. This section covers a collection of useful libraries, covering topics such as string matching with regular expressions, parsing command line options, and the db database library.

What They Left Out

The authors left out virtually any talk of graphics or X programming. In some ways, this is a good thing, and may extend the shelf-life of the book. The world of X windows and Linux is a bit fractured at the moment, with competing libraries jockeying for position. The authors could have avoided this by discussing X at a lower level (Xlib and the X Intrinsics), but there are other books that do this well enough. [A very good book for programmers interested in learning X is The X Toolkit Cookbook by Paul Kimball, ISBN 0-13-973132-6.]

The authors didn't discuss other languages popular in the Linux environment, such as Perl and Python. Again, I think this would have diluted the book. As it is, Johnson and Troan maintain a sharp focus on what's important to C programmers using Linux.

Compares Favorably

In style and in utility, this book reminds me of Richard Stevens' Unix books, particularly his great Advanced Programming in the Unix Environment (they even share the same publisher). There is some overlap between material in the Stevens' books and material in Linux Application Development. My inclination would be to read the section in LAD first, and then, if the subject was still unclear, look to the Stevens' books for more depth.

If you're a Linux developer, or if you're a C programmer thinking of diving into Linux, I can recommend this book without reservation.

Mark Pruett

To get this book, check out this spot brought by Amazon.