Slashdot Mirror

prostoalex writes "How many times, when playing Dungeons and Dragons by yourself, or reading an RFC in the bed alone on a Friday night, have you thought 'Boy, I sure wish there was an easier way to pick up women, like published API with code samples?' What would you say if such documentation was not only available, but succinctly put into 22 design patterns and given formal descriptions just like the ones in your UML book? Dating Design Patterns, with a cover suspiciously similar to Design Patterns by the Gang of Four, is the first attempt to bring verified solutions to common problems in the world of dating." Timothy's review follows prostoalex's, below. Dating Design Patterns author Solveig Haugland pages 150 publisher Solveig Haugland rating 9/10 reviewer Alex Moskalyuk ISBN 0974312002 summary Elements of reusable objective-oriented paired programming

Why design patterns are needed Many will attest that the API to the WOMEN platform is somewhat obscure, contradictory and poorly documented. However, if you talk to any randomly selected groups of men, you will discover that the problems they face (whether in Pickup or Relationship states) are fundamentally the same. If there's a common set of problems, shouldn't there be a common set of solutions? Moreover, doesn't it bother you that programming geeks, who advocate code reusability and open-sourcing have not come up with reusable successful solutions for commonly occurring problems and have not documented them?

This book is the attempt to change that and unite all design patterns in a single documentation project. You can read the conversation that led to writing DDP (caution: those of you in love with Design Patterns' concept might have a hard time reading how it was all a hoax by the Gang of Four). Hopefully you will understand the danger of letting this knowledge out (hint: geeks who talk to attractive girls, date and get laid spend less time writing code, which could jeopardize some projects) and not recommend the book to everyone you know. The table of contents is available online as well (in PDF format), and you can see that the book is subdivided into two large sections - introduction and pattern catalog.

Introduction to dating design patterns In the first part, the authors introduce the concepts of design patterns with several superfluous definitions in an attempt to outdo the academic titles types on Design Patterns in number of formal references and quoted italic text. They also provide the set of anti-patterns, which can be collected by surveying poor implementations of dating patterns. For example, the Iterator anti-pattern is described as "The nag. One of the most taxing on system resources. Also an anti-pattern when used to repeatedly ask the same woman for a date." Many developers fall into fallacy of thinking anti-pattern would do the job when a pattern does not work.

The chapter on refactoring talks about all the issues that must be taken care of before implementing any of the patterns. Each refactoring unit includes sub-sections on Motivation, Mechanics and Example. The motivation part explains how this refactoring unit can help publish an attractive public interface for FEMALE platform. The mechanics part usually includes a bulleted list of what needs to be done for the implementation. The example brings us into more practical world, where we can visualize how the refactoring units "Get a makeover", "Display yourself in a new context through third parties", "Publish a more restricted interface" and "Fake a phone call from an ex-girlfriend" can help interested geek attract female companions.

Pattern Catalog

The second part is nothing more but a collection of 22 existing dating patterns. This part of the book will be even more familiar to those who read the original Design Patterns, as the headings, bulleted lists, sidebar notes and sub-chapter titles are all there. Each pattern is presented in the following format:

1. Pattern name
2. Problem statement (the authors acknowledge that for most of developers the problems reside in attempting to implement getLaid method successfully on FEMALE platform)
3. Forces (why this pattern might lead to successful implementation)
4. Solution (overview of what's required for successful implementation)
5. Strategies (step-by-step guide with copious notes)
6. Benefits and Drawbacks (analysis of when this design pattern makes sense and when it's not appropriate)
7. Related patterns

Anyone who's ever been through UML or Design Patterns class will not have a problem with reading the pattern catalog. The pseudocode sometimes used to describe the pattern is somewhat close to Java and uses Camel notation for method calls, state and interface definitions. Luckily the book is void of any humor that design pattern writers usually try to sneak in, and is just plain formal scientific boring writing with SAT-level vocabulary that we all grew to love while reading the Gang of Four series.

The problem statements use clear language, allowing the reader to figure out whether he has the same problem (and thus should read the pattern to find out the solution) or move on to the next pattern. For example, the Jini Singles Bar pattern describes the following problem:

You're a great catch, of course, and you're looking for someone smart, funny, beautiful, who can talk about rock-climbing, Slashdot, politics and 19th century Serbo-Croatian playrights. It would also be nice if she were 24, between 5'6'' and 5'8'', of French extraction, interested in the songs of Owen Margolis, with dark long brown hair. However, you have not yet found this woman.

Conclusion The point that authors try to emphasize is that Dating Design Patterns is a collection of researched, verified, formalized and proven to work patterns. Of course, there are numerous pages of already available documentation with questionable applicability, as well as HOWTO's from open-source luminaries, but they provide neither the variety of patterns that this book has, nor the exact step-by-step implementations.

As common with design patterns, there are areas where they work perfectly and there are cases, where they are not applicable at all. The collection (full list of patterns with appropriate poster is available from the official Web site) just provides the list of accepted solutions to common problems. Perhaps reading through all 22 patterns is an onerous task and should be left to those in academic world. However, the authors assure that the benefits of successful implementation outweigh the amount of resources that need to be dedicated. Now, if you'll excuse me, that girl from Barnes and Noble with very nice public properties is getting out of the shower and her private members are even more interesting.

Tim's review: Don't buy this book. None of the ideas in it work. Absolute garbage. Haugland's "advice" will not result in flocks of appropriate-sex singles following you out of every coffee bar, bookstore or tango lesson you happen to visit. Repeat: do not buy this book.

You can search for Dating Design Patterns from bn.com, or better yet, straight from the author. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

AlexisKai writes "The Ten-Second Review: Robert Levine's The Power of Persuasion: How We're Bought and Sold is an engaging, highly readable survey of the sophisticated methods of persuasion we encounter in various situations. From television to telemarketing and from self-deception to suicide cults, Levine takes a hard look at all the ways we attempt to persuade each other - and how and why they work (or don't). Robert Levine is a professor of psychology at Cal State Fresno; his previous books include The Geography of Time, about the differences in the perception of time and its passage in various cultures and cities around the world." For those with a longer attention span, AlexisKai's review continues below. The Power of Persuasion: How We're Bought and Sold author Robert Levine pages 278 publisher John Wiley & Sons, Inc. rating 8 reviewer Colin Cannell ISBN 0471266345 summary An engaging, highly readable survey of the sophisticated methods of persuasion we encounter in various situations. From television to telemarketing and from self-deception to suicide cults, Levine takes a hard look at all the ways we attempt to persuade each other - and how and why they work (or don't).

The book is quite balanced in its approach and unusual in that it looks at the art of persuasion through the lens of psychological field research. Levine doesn't merely muse about the vagaries of the mind; he gets out there and investigates it. He takes a job selling knives from a "multi-level marketing" company. He interviews former car salesmen, entrepreneurs, and marketing directors. His students conduct experimental bake sales.

The Power of Persuasion is at its most interesting when it shows how human behavior frequently travels outside the lines of economic theory. Chapter 6, "The Hot Button," details the situations in which we're likely to do something irrational, like buy the most expensive of four very similar-looking toasters, because a decision-making shortcut in our brain has been tripped (in this case, we equate higher price with higher quality despite there being little evidence for that).

The Power of Persuasion covers a certain amount of ground that has already been covered by such books as Robert Steiner's Don't Get Taken and Gerald Zaltman's How Customers Think. What I liked about this particular book's approach is that it takes a position between the two previously mentioned: for the most part it neither condemns the act of persuasion nor celebrates it. Levine is usually content simply to observe how persuasion is done and occasionally marvel at the way, say, a door-to-door salesman often has greater insight into the human brain than a psychologist.

Levine's writing style is fairly consistent throughout the book. In each chapter, he takes a particular theme or area of the art of persuasion and breaks it down to show what psychological and cultural forces are at work. He does this through well-reasoned arguments interspersed with amusing anecdotes, factoids, and citations of interesting studies and statistics.

For example, in the first chapter, "The Illusion of Invulnerability," he uses the metaphor of Garrison Keillor's fictional Lake Wobegon, where all the children are above-average, to describe how people consistently underestimate the extent to which they are personally influenced by advertising and the likelihood that they would fall for deceptive claims and scams. He punctuates this with a story of how he was preparing a university course on the use of mind control in social psychology and became so wrapped up in his thoughts about totalitarian governments and secret police that a man claiming to be a chimney sweep was able to hoodwink him out of $250. After this, he said, he realized that "it's the people we're unprepared for who present the greatest threat. The fast-talking salesman puts us on alert. But the nice guys, the friendly thieves who sell beneath the threshold of our awareness, put us at their mercy."

The following chapters deal with other facets of persuasion, including:

• The illusion of authority, i.e. "I'm not a doctor, but I play one on TV."
• The use of generosity or kindness to create a sense of obligation.
• Contrasting what you're selling with something very similar or very different to create a "false dilemma" in the buyer.
• Moving from "Yes, I'll look at your brochure" to "Yes, I'll sign over my life savings to you" through a series of "gradually escalating commitments."
• One of my favorite chapters, and one that I identified with personally, is "$2 + $2 = $5," which takes a look at "The Ten Rules of Framing." Just like the lottery is "a tax on people who are bad at math," the rules of framing take advantage of the way we perceive numbers emotionally to subtly influence us toward decisions that don't necessarily make logical or financial sense.

Rule #1, for example, is "Separate Gains." Levine cites studies showing that people would prefer to win a $50 prize and a $25 prize rather than a single $75 prize. "This is because we respond less to the cumulative total of the gains than the fact that it is a gain," says Levine. "Every gain brings pleasure." This is why you always see Sports Illustrated offering you a "free" book, video, or football helmet mug, even though most of us would be better off if they would forget the video and just lower their subscription price. "The company wants you to file the gift in your unexpected windfall account," Levine writes, "where its perceived value is psychologically inflated, rather than mentally bunching it together with the other products into one big purchase."

In fact, I found a number of "hey, someone else wonders about that too" topics in The Power of Persuasion, such as the idea of the JND, or Just Noticeable Difference. This is the idea that you can quantify how much something can be changed before people notice that it has done so.If our product costs $5.49, and we raise the price to $5.59, will customers care? What about $5.99? Levine looks at how the JND is different at different price points and in different circumstances.

There are a few problems with the book:

• It includes some minor factual errors, such as the paragraphs in which Levine discusses the ad campaign that introduced "Infinity," which he describes as Toyota's luxury car brand. (I assume he means Infiniti, which is actually Nissan's luxury marque).
• The penultimate chapter is entirely devoted to an analysis of Jim Jones and the cult of Jonestown, whose members committed mass suicide in 1978. The analysis is interesting, and someone who hasn't studied Jonestown will find a good introduction here, but I wasn't convinced it deserved a chapter to itself. Levine's rationale appears to be that Jonestown represents the logical extreme, the "dark end of the dark side of persuasion," and there but for the grace of God go we, etc.
• The last chapter, "The Art of Resistance," turns toward the advocacy that I was so relieved not to find in the rest of the book. It contains advice on "asking disconfirming questions," avoiding groupthink, and being sure to practice "persuasion with integrity." This advice is very intelligent and well-founded, but most Slashdot readers will probably find themselves being told things they already know.

I would strongly recommend The Power of Persuasion to anyone whose job involves selling, who has ever wondered why in the world they bought that sweater/car/time-share, who lives in a capitalist economy, or who is just looking to fill a few hours with a fascinating book. It's an insightful, scientific look at a force that permeates the existence of anyone who has to interact with other people but that we rarely take the time to examine.

Besides being a cracking good read, it's fully footnoted, indexed, and so stuffed with information as to make a worthy addition to anyone's reference library. The next time you wonder what possessed you to pay $50 for a medallion commemorating the series finale of Friends, you'll know where to turn.

You can purchase The Power of Persuasion: How We're Bought and Sold from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

JChris (J. Chris Coppick) writes "Wireless technologies threatening cable monopolies; an underground network of amateurs fighting regulation; legal battles over patent rights; phone owners complaining about telemarketers; car enthusiasts complaining about speed traps ... This may sound like a summary of today's headlines, but these and other familiar conflicts were hot even at the beginning of the 1900s. In Signor Marconi's Magic Box, Gavin Weightman tells the story of the life of Guglielmo Marconi, and of the communications revolution sparked by Marconi and others around the turn of the 20th century." Read on for the rest of Coppick's review. Signor Marconi's Magic Box: The Most Remarkable Invention of the 19th Century & the Amateur Inventor Whose Genius Sparked a Revolution author Gavin Weightman pages 291 publisher Da Capo Press rating 7 reviewer J. Chris Coppick ISBN 0306812754 summary Fascinating science-related historical narrative

This biography of Marconi, published by Da Capo Press in 2003, is just one in a group of science-related historical accounts that I've been working my way through of late, but stands out from the others in sheer deja vu. Before getting into that, though, let us focus first on the author's deftly accomplished goal of fitting the story of Marconi's life and the development of wireless telegraphy (along with a more than adequate treatment of the historical context) into a book of approximately 300 pages (including two small sections of well-annotated photographs).

For those not familiar with Marconi beyond his popular title as the inventor of the radio, one of the first surprises is that much of the story takes place in England and not Italy, due in no small part to the fact that Marconi's mother was Irish. Marconi was born in Bologna, Italy in 1874. He was raised there, and it was in Bologna that he laid the foundation for his future successes in the wireless business. While the existence of "Hertzian" waves was known before Marconi's work, and even though their use as a medium of communication was certainly being considered by others at the time, Marconi can be credited with key innovations that led to the first practical system of wireless telegraphy. In 1896 he traveled to England to popularize his wireless system, with the help of his mother's family connections. Thus it was England where Marconi launched his first wireless enterprise, and England remained his base of operations for the bulk of his career.

For those not familiar with the history of radio, another surprise may be how just many obstacles initially stood in the way of wireless communication. The BBC World News broadcast didn't start the day after Marconi said, "Aha!" Many of the problems stemmed from a general ignorance of the actual physics involved in radio transmission. For example, early wireless sets worked better during the night than the day (like your radio's AM tuner), and early long-distance transmitters required large amounts of power. The advantages of "short waves," much less the theoretical underpinnings, were not recognized until rather late in the story, relative to Marconi. Marconi himself had little understanding of why his "magic boxes" worked. He focused rather on mechanical innovations that increased the convenience and reliability, and therefore the commercial possibilities, of his previous successes. In this respect, Marconi was much more of a craftsman and businessman than a scientist.

By 1900 there were two companies bearing Marconi's name (the Marconi Wireless Telegraph and Signal Company, and the Marconi International Marine Company), though like the true startups they were, neither were making any money. Soon Marconi was almost completely focused on making trans-Atlantic wireless telegraphy a reality. It was near this point in the narrative that I started to see reflections of "modern" legal, political, and cultural themes.

For the curious, let's dispense with these first: Marconi was an "early adopter" of the then-recent advances in automobile technology (he was seriously injured in an automobile accident later in his life). So the book makes mention of the fact that, because of the rapid rise in the popularity of motoring, as early as 1904 the police in England were setting up "speed traps." So the next time you are yelling at the cop who just pulled you over, take a moment to consider your small but vital role in over 100 years of tradition. Also of interest, the book discusses the roots of the "broadcast" concept, some of which involved the telephone system. This leads to the mention of consumer complaints, dating back to the early 1900s, about unsolicited sales calls. I won't ask you to consider, the next time your dinner is interrupted, your small but vital role in that tradition. It's just too depressing.

In December of 1901, Marconi received in Newfoundland the first trans-Atlantic wireless telegraph signal, transmitted from one of his stations in England. At that time, the business of trans-Atlantic communications (i.e. telegraph messages) was monopolized by the small set of companies that owned undersea cables. One cable company even had a legally-defined monopoly on telegraphy in Newfoundland, a fact they quickly pointed out to Marconi, forcing him to take his business to Canada. [ed. note: Newfoundland didn't join Canada until 1949.]

As news of Marconi's accomplishment spread, cable-company stocks began to "wobble." It was assumed by many that once long-distance wireless telegraphy became widespread, the lower cost-per-message for wireless would put the cable companies out of business. Of course, that never really happened. (It's worth noting here that the revolution of radio broadcast came later. Just as no one looking at the ARPANET could see Slashdot, no one looking at the first wireless efforts could see Wolfman Jack, Howard Stern, or Rush Limbaugh.) Soon however, despite the lack of much actual commercial wireless success, "wireless mania" was spreading through parts of the world, especially in the United States. Fraudulent businesses were created, patents (legitimate and otherwise) were being granted, competing standards were leading to international political frictions, patent-infringement suits were being brought, competitors were being bought out, and amateurs were gleefully "hacking" the system. It wasn't long before government regulations were being imposed and bureaucracy was slowing down the adoption of new technologies. Hopefully you can see why all this started to feel more than just vaguely familiar. I do not want to leave anyone with the impression that Signor Marconi's Magic Box is just a depressing litany of the recurring problems of civilization. It's hardly that. Actually the fact that I was able to identify on a modern level with much of the history made an already interesting book even more interesting.

Signor Marconi's Magic Box is pretty much everything you could want in a historical biography, perhaps more. The author touches on enough aspects of the development of wireless telegraphy to keep the story fresh, including most if not all of the personalities involved, and he seems to give credit where it's due. He provides enough detail of Marconi's life to give us a good sense of the man, but not so much as to weigh down the narrative. Likewise, he provides enough technical detail to give us a sense of the technology, but not so much as to detract from the human aspects of the tale. If you are not hooked yet, please allow me brief mention of some other aspects of the story, including: forbidden love, intrigue, war, murder, shipwrecks, practical jokes, heroic deeds, another war, and international espionage. If I had to sum it all up in one sentence it would be this: Any book that contains the phrase "two-ton transformer blew up" can't be all bad.

You can purchase Signor Marconi's Magic Box: The Most Remarkable Invention of the 19th Century & the Amateur Inventor Whose Genius Sparked a Revolution from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

imaginaryNumber writes "Peter Gutmann distinguishes his renowned cryptographic library, cryptlib, from other security toolkits available by claiming it provides a 'coherent security model' that other toolkits omit. His criticism goes further to say that some security toolkits 'lack real security features altogether.' It comes as no surprise, then, that his recent book, Cryptographic Security Architecture: Design and Verification, is a 320-page paean documenting the coherence and the sure-footed construction of his security toolkit. I am a student of electronic privacy, cryptography, security, and mathematics, and I am an admirer of Peter Gutmann's work. He is prolific in the security field, and Gutmann's website at the University of Auckland is a good introduction to his work. I had the pleasure of meeting him recently in New Zealand, after he agreed to field some questions about his book. As you will read in my review, I highly recommend the book even though it has a handful of flaws. And while I have a great deal of respect for the author's work, I'm not ready to accept all of his ideas as gospel." Read on for the rest of imaginaryNumber's review. Cryptographic Security Architecture: Design and Verification author Peter Gutmann pages 320 publisher Springer-Verlag rating 8 reviewer imaginaryNumber ISBN 0387953876 summary A technical book about security architectures, verification techniques, and cryptographic software and hardware

Cryptographic Security Architecture is a technical book that focuses on security architectures, verification techniques, and cryptographic software and hardware. It is an excellent reference source that intricately captures the design process of a security toolkit that has been in use for several years across the globe. The security architecture presented in the book is platform-independent, but the book does touch on platform-specific issues when necessary, especially when cryptlib implementation details are described. The toolkit has been ported to a slew of platforms.

Even though the book and the toolkit benefit from each other's companionship, both can certainly stand alone. The reader doesn't have to be familiar with or even interested in cryptlib to gain from reading Cryptographic Security Architecture . In this review of the book I will keep toolkit discussion to a minimum. The semi-GPL cryptlib security toolkit is OSI-certified open source. The security toolkit includes an excellent user manual which is a formidable 310 pages.

The Passion of the Cryptographic Security Architecture

Cryptographic Security Architecture's first chapter covers the foundational software architecture and is a bit dull. I would hope that the target audience is familiar with basic subjects like object-oriented design and inter-object communications. Too much attention is given to what should have been prerequisite knowledge at the expense of security related matter. For instance, while Gutmann gives a lot of attention to basic object synchronisation (the Kiwi spelling, which is suitably preferred by him) he only alludes to a class of security issues involved with multi-threading. If you can make it through the first chapter, rest assured that Gutmann avoids this flaw in the rest of the book. To be fair, this back-to-basics review does well at underpinning the rest of the security architecture, even though it often reads like a software architecture primer.

The second chapter covers the security architecture, which features such things as permission-based access, least privilege and isolation, mediation, and other expected elements. The design goals include some common goals, like simplicity and efficient implementation. But three of the design goals represent the core philosophy of Gutmann's architecture: The separation of policy definition and enforcement mechanism, a verifiable design (practical vs. theoretical viability), and a flexible security policy.

The separation of the policy definition from the enforcement mechanism solves problems that exist in previous attempts at security architecture (e.g. some Orange Book-based systems hardcode the policy). One claimed benefit of separation is the reduction of complexity in the enforcement mechanism and the improved verifiability that simplicity brings. But I would argue that complexity has been shifted from the toolkit to the toolkit user, who can opt to configure their specialized security policy. What mechanism is going to be used to verify these user-defined policies? It's unlikely the toolkit user's policy will receive the scrutiny that the open source community bestows upon the factory bits.

But I may not fully understand the capabilities of the security policy scheme. Perhaps, when using Gutmann's cryptlib, it is impossible for the toolkit user to configure an incoherent policy. In George Orwell's 1984, the Party worked to deconstruct the English language so that only 'legal' speech could occur. As designed, Newspeak would make illegal statements unspeakable --- and in time, unthinkable. I'm unconvinced that Gutmann's security policy scheme is such a controlled means of expression, where only safe security policies can be spoken. Granted, one could always use the predefined policies, but this path undermines a chief design goal of the architecture: a flexible security policy.

Notwithstanding my nitpicking about the policy, the security architecture chapter is a good example of how the book shines. Gutmann covers in detail his design process and chocks the chapter full of references for the reader's further study. In all, there are almost 700 reference listings, which consume 15% of the book's 320 pages.

The policy definition scheme is followed by a detailed discussion of the security kernel implementation. (The kernel is the policy enforcement mechanism, referred to earlier.) Like most of the book, the writing is as dense as most detailed architectural designs and sometimes sleep-inducing. But Gutmann's writing style is clear, concise, and sometimes funny. Gutmann's writing talent makes even descriptions of "Access Control List for public-key/certificate access" and "Access Control List for an attribute that triggers an object state change" endurable.

Verification techniques for the security architecture are a major theme of the book. Anyone who has attempted to verify that software does what it was specified to do, especially in the security field, will find Gutmann's insights worthwhile reading. This is especially true for anyone who has ever done a Common Criteria-based evaluation, or a verification employing any of its ilk. Gutmann makes an excellent point about the semantic pitfalls of formal methods: "As with ISO 9000, it's possible to produce an arbitrarily bad product but still claim it's correct, since it complies with the paperwork."

Cryptographic Security Architecture also contains the obligatory chapter on random number generation. The chapter includes more of Gutmann's trademark insights. He discusses many software and hardware implementations, including the generators contained in: PGP (Pretty Good Privacy), /dev/random, ssh, Capstone / Fortezza, Intel Pentium III, Microsoft's CryptoAPI, cryptlib, and others. Random number generation flaws abound. For example, he discusses the flaws in the ssh and SSLeay/OpenSSL generators that make it possible to "...suck infinite amounts of state information out of [the random number generators] by repeatedly connecting to the server..."

Towards the end of the book, Gutmann includes a dessert-like discussion of hardware encryption modules. Gutmann's predilection for security hardware is evident as he writes about problems with crypto on end-user systems. This chapter includes all sorts of cryptographic hardware including the designed-for-hostile-environments HiDan embedded PC. One interesting technique to secure modules like the HiDan is to pour a hardening material (e.g. epoxy) into the chamber before sealing it shut.

Regarding the book's construction, while the references are excellent, the glossary and index are poor. Even if you rely on external sources for acronyms, as the author suggests, some of his acronyms are not included in the glossary. For instance, it took me awhile to determine that CMP stood for Certificate Mismanagement Protocol. The index is also oddly incomplete, considering Gutmann's otherwise good documentation habits.

Conclusion I expected Cryptographic Security Architecture to treat the topic of security architecture in a general way, offering many alternatives for designers to ponder while designing their own security architecture. The book does this, but often Gutmann whittles down the prudent design options to one, with most paths arriving at a single destination, namely Gutmann's cryptlib. Don't get me wrong: It's good to be decisive when faced with many architectural tradeoffs, and the ugly alternative is all too often design paralysis. And it's no surprise that cryptlib, according to Gutmann, contains the best architectural elements - he is the author of both the book and the toolkit. Still, the homage to cryptlib often made me unsure that a wide spectrum of design options had been considered: Did the security architecture spawn the cryptlib implementation, or did the implementation spawn the architecture?

To be clear, the strong points of the book (and concepts therein) far outnumber the weak ones, and I highly recommend it to anyone interested in security architectures, verification techniques, and cryptographic software and hardware in general. Simply put, the book is excellent and it should expand most reader's knowledge of cryptographic security.

You can purchase Cryptographic Security Architecture: Design and Verification from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

honestpuck writes with his review of Getting Started with Lego Trains from No Starch Press. "I have a confession to make. There is one small part of my childhood that is constantly returning; every few years it breaks out and I find my apartment covered in small pieces of brightly coloured plastic: Yes, the Lego addiction strikes. One of those recent episodes involved a train set (perhaps I indulged in a few pieces of track and an extra car or two - but that's all, I swear) so I was pleased to see this book." Read on for the rest of his review. Note that the Bricks on the Brain site is down at the moment; you might want to try the google cache instead. Getting Started with Lego Trains author Jacob H. McKee pages 101 publisher No Starch Press rating 7 reviewer Tony Williams ISBN 1593270062 summary Good book on building Lego trains. Not terribly large.

Getting Started with Lego Trains is a fairly good guide to designing and building Lego trains. The writing is a clear, simple style that should be understood by anyone, the layout is clear.

Jacob McKee, the author, is webmaster at Bricks On The Brain, a good site which acts as a portal to build instructions. He also has a section devoted to the book which has three example pages and some links to other sites useful to Lego train builders. Both the book and the site itself promise at least a couple of articles by McKee but these are still "to come." I hope they come soon as McKee promises (in the book and on the site) an article on using decals and I'd like to know his sources and methods.

The book starts with two chapters that are absolutely basic; most of the information here is included in the Lego documentation you get with the train kits, such as how to hook up the electrical power and the different train and carriage sets available. There are still some useful nuggets such as the 'Studs Not On Top' technique for getting bricks pointing away from the vertical and interesting trivia such as a short history of Lego trains. McKee also adds some details that may be hard to glean from the Lego manuals such as how an active passing line can cause a short circuit in your track.

The third chapter is only two pages, which once again detail some fairly obvious information such as the various parts of the train couplings and bogies. From that point on, the book gets interesting. The real core of the book consists of the three chapters that McKee has devoted to three different train models. Instead of just giving you the plans to build the locomotive and two carriages, McKee has shared the design process itself and gives some useful design and building tips before showing you the instructions.

The first model is a glorious model of a GP-38 locomotive (if you want to see the finished models then you can get decent-sized pictures on McKee's site). It might have been better to have had this model last of the three, as it is the most complex and I found it the hardest to make with my Lego collection - there are more specialized parts in this model and I to change the design in a couple of spots. Given the great look of the finished model, this isn't too much of a complaint.

The second example is a refrigerated car (or "reefer car" in train yard slang). I found that I couldn't build this car in the all-green of the book design but had the parts to build it in red. Since, as McKee points out, these sorts of cars are to be found in dozens of different paint jobs I don't feel this was a problem. There are considerably fewer specialized parts in this model.

The third example is a container car (with containers), which is the easiest to build and uses few specialized pieces you are unlikely to have if you own a train set already. Once again my only real problem was one of having exactly the same colour as the book -- one of my containers has red doors instead of white, for example.

I hope from my descriptions of the chapter you can see why I think the model order is wrong -- I'd completely reverse the order of these three chapters.

For an early teen (or older) reader, the strength of this book is the tips and encouragement McKee gives in these three chapters for designing your own locomotives and carriages. There are dozens of little tips and tricks on creating a visually pleasing and playable model design. Younger readers may not appreciate McKee's excellent advice on creating your own designs as much as older readers, but they will enjoy building the models all the same.

There is a final chapter on building track layouts, including some useful tips on building track inclines, and finally two short appendices, one on where to buy Lego and a glossary (McKee labels it "terminology").

Originally (before publication, that is), this book was advertised at $24.95. The actual cover price is $19.95, though, and No Starch have dropped the price again. At the new price of $14.95, it becomes much more attractive and I recommend it to anyone who is interested in designing and building their own Lego train locomotives and carriages. The readable, simple style and clear build instructions make it enjoyable for quite young readers and older, more dedicated builders will appreciate the design tips. Lego have train sets that they advise are for 8 years old or older, and I believe the average seven-year-old would have no problem understanding the build instructions in this book.

You can purchase Getting Started with Lego Trains from bn.com. (They're asking the full cover price for now, but that may change.) Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Peter Wayner writes: "When jury duty called, I was lucky enough to have a copy of Larry Lessig's new book, Free Culture: How Big Media Uses Technology and the Law to Lock Down Culture and Control Creativity, to take along. The Mitchell Courthouse in Baltimore is one of the most beautiful and ambitious marble allegories for how the law can be elegant, ornate, and permanently imposing. It was the perfect place to read a new book devoted to stopping the old guard media czars from using law to keep the couch potatoes down." Read on for the rest of Wayner's review of the book -- which is released today in hardcover, but also available for free online. Free Culture: How Big Media Uses Technology and the Law to Lock Down Culture and Control Creativity author Lawrence Lessig pages 388 publisher Penguin rating 9 reviewer Peter Wayner ISBN 0375505784 summary Lessig takes a serious but accessible look at how law has been subverted by Big Media and proposes workable steps for taking it back.

Lessig is now famous for a number of reasons, including his two previous books, Code and Other Laws of Cyberspace and The Future of Ideas : The Fate of the Commons in a Connected World. In the first, he was one of the first to affirm what many Slashdot readers know almost instinctively: whomever writes the code determines how the world works. Making the right decisions about power and control when designing a computer system is just as important as writing laws for the future. In the second, he writes of the importance of a vast cultural commons which acts as the wellspring for our expression and the grounding plate for our souls.

His new book is his most casual and most accessible. His prose is improving as he drops the footnote-heavy habit of legal writing and adopts a bloggier style driven by anecdotes and personal revelation. And what anecdotes he has -- Lessig's years on the barricades have given a surprisingly large collection of tales that will make any artist or citizen cringe. Time and time again, the powerful warlords of the entertainment conglomerates have banded together to try to stomp out the sharing and cooperation emerging from the Internet. After years of amassing a strangehold on the world's culture, the conglomerates aren't letting this cheap, fast and out-of-control technology sweep it all away.

My favorite anecdote, if one could be said to stand out, comes from a film maker documenting an opera company. When the camera caught a snippet of the stagehands watching the Simpsons with the sound turned down, the director wanted to add a four-second clip to the movie. Matt Groening said "Yes." The lawyers said it was clearly fair use. But Fox's executives responded with the kind of obscenity that doesn't upset the FCC: pay us $10,000. The clip didn't make the film because the director couldn't afford to go head-to-head with the Fox legal department.

This is just one of a number of stories of how interesting, invigorating content and innovation was strangled at birth by old guard. The anecdotes are, I think, an effort to atone for his loss in the Eldred case and reargue it. He presented the Supreme Court with a very logical and legal reading of why it was wrong for Congress to continue extending the length of a copyright monopoly and the court didn't buy it. A friend of his said that this tack was wrong because the court wanted to feel the depths of the injustice. The justices didn't want laws and footnotes, they wanted something human. Lessig blames his loss on not taking this advice. (As an aside, Lessig's personal description of taking a case to the Supreme Court is a good way to understand just how human the game can be.)

This time around, he piles the examples on top of more examples to show just how the conglomerates can hurt the artist and culture in general. After this case failed, Lessig tried another compromise that exposed the true goals of the copyright czars. Lessig describes his efforts to recreate a copyright registration system. If someone wanted to keep a copyright in force after 50 years, Lessig suggested getting them to pay a $1 fee. This would help everyone keep the copyright straight and make it simpler for everyone to understand just who has what rights to an art work. Any art work that goes unregistered flops into the public domain. Anyone who's tried to clear rights to a project will see this as a step in the right direction. The copyright industry, however, rejected this structure in a way that Lessig suggests illustrates how much this is about power and control, not creativity and expression.

Lessig has other tricks up his sleeve. If he can't convince the U.S. government to change the law, he can appeal to the artists themselves who have the ultimate control. He started his Creative Commons project several years ago and now artists can use several boilerplate licenses that reserve some of the rights while releasing others.

This new book itself is also available for free (PDF) under the license, a tactic that has worked well for Cory Doctorow and myself in the past. When I released Free for All under the license several years after the book was published, I watched the asking price on Amazon's used book market rise more than 40%. It wasn't a big jump, but it was still a bit counterintuitive. The freely available text encouraged people to buy the more readable printed version. I think Lessig will see the same effect. The sales driven by the people who read the electronic version will be greater than the sales lost to the people who just read the downloaded copy.

The good news is that the markets and the consumers are already heeding Lessig's advice because they instinctively disdain a monopoly. The power of the old networks is rapidly disappearing and the increasing concentration among the old guard is as much an illustration of the last ditch effort by the executives to cash out by taking large bonuses from the transactions. Some worry about the concentration of power in the radio world by companies like Clear Channel. But who listens to radio for music any longer? One Clear Channel station near my house plays traffic reports every 10 minutes during the day because their audience is dominated by people trapped on aptly named "parkways". The station may play as few as three songs an hour between 6:30am and 9am. The rest of the time, they yak about movies or the weather and their influence upon music continues to drop.

There are surprisingly good alternatives developing to take over the space. Lessig does an excellent job describing how the Internet radio stations were mugged with unfair regulations, but it's important to remember that they continue to exist because they offer something better than endless traffic reports. Furthermore, competition is coming from strange places. Starbucks is just one such company selling commercial- free mix tapes that are, for almost all intents and purposes, just a plastic disk version of a cool DJ. More and more radio-like venues are appearing.

There are other reasons why the concentration is backfiring. Lessig does a good job explaining how the television networks are squeezing out competition from independent producers. He describes how Norman Lear was only able to bring us "All in the Family" because he was free to take his work from ABC to CBS. That freedom disappeared after Congress repealed the laws forbidding the networks from owning stakes in the shows they broadcast. Now, if you want to get on CBS, it helps to sell a part of your show to CBS or, even better, just sell the whole thing.

But is this strategy really working for the networks? Their ratings continue to plummet. There's a reason why there are so many drug commercials for arthritis remedies on network air. That generation is the last one who watches network television almost instinctively. Lessig likes to complain about the "soviet" nature of these networks. It's a wonderful word that reads on many levels. The more they squeeze out competition and aggregate power in the committees, the more they lose the fluid competition that lets cream rise to the top.

So, who really cares if CBS isn't available on the Dish network? There are hundreds of other channels offering good fare. It was a different story in the 1970's when there were only three networks and CBS offered shows like "All in the Family" and "Mary Tyler Moore". Then, they controlled the heart of our popular culture. Today, the network ratings are so low on Saturday night that all of the networks are looking for a way to stop broadcasting on that day. Aside from the NCAA basketball tournament, I've lived without CBS for years without missing a thing. (Even then, I get most sports news from the websites.) The DVD player is a very, very powerful and destructive technology. When you can buy 50 movies for $30, who even needs CBS, the Dish network or HBO?

All of these idea swirled through my mind as I read Lessig's book and waited during jury duty. Are things getting worse or better? Are the 40+ million plus fileswapping pirates winning, or are the draconian laws crushing our creativity like a jackboot? I spent my time thinking of this balance while waiting for the judge and the attorneys to sift through 150 people to find the right 12 folks to render a fair and impartial verdict. On one hand, it was remarkable that society was being so careful before imprisoning someone for attempted murder. On the other, it was clear that the effort can't be sustained for the 40 million+ file sharing pirates who are thumbing their nose at the law.

Lessig understands this. One of his most persuasive arguments is that the current law becomes more marginalized as it becomes increasingly less fair. Prohibition of alcohol corroded the law and now the increasing prohibition of fair use is eroding respect for copyright.You only need to travel a few blocks from the Mitchell court house to end up in dangerous regions of Baltimore where the marble and the pomp can't do much to protect you. Lessig, the lawyer, knows the law can only work when it is fair and equitable. This new book is a strong and passionate argument for how we can restore some sanity to the system and restore our faith in copyright law. Some people think that Lessig is trying to "smash" the copyright system, but I think he's just trying to restore its ability to function.

Peter Wayner is the author of Free for All , a book on the open source movement and Policing Online Games, a book on how to build the Mitchell courthouse in cyberspace. You can purchase Free Culture: How Big Media Uses Technology and the Law to Lock Down Culture and Control Creativity from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page. mpawlo points out you can get the book free and gratis via Bittorrent.

Sarusa writes "eXtreme Programming has been quite the lucrative phenomenon, with a slew of articles and a bookshelf full of 20+ books on the subject, rivaling even UML for fecundity. With all the hype, where's the opposing viewpoint? Well, it's not often as profitable to write a book on the downside of a hot trend, but Matt Stephens and Doug Rosenberg managed to find a publisher for Extreme Programming Refactored: The Case Against XP by Matt Stephens and Doug Rosenberg, henceforth referred to as XP Refactored because I'm eXtremely Lazy. This book is not intended entirely as a hit piece - as the title indicates, they do spend some time examining what works in XP and how it can be used sanely. (Please note that this book has been reviewed on Slashdot once before, but from a slightly different perspective.)" Read on for the rest of Sarusa's review. Extreme Programming Refactored: The Case Against XP author Matt Stephens and Doug Rosenberg pages 432 publisher APress rating 8 of 10 reviewer Sarusa ISBN 1590590961 summary A book you should definitely read along with 'Extreme Programming Explained'. Makes its points quite well, though a bit over the top in places.

Where I'm Coming From I've worked on several large projects (and innumerable small ones) as programmer and/or system designer. I thought long and hard about shelling out my $30 for this book (list price is $39.99, but you can find it for less online), and more importantly, scheduling the time to read it. I pride myself on being a software engineer, concerned with not just cranking out code, but overall system design. On the other hand, after being subjected to various overkill design methodologies, such as full-on UML, I'm wary of things that keep you so busy designing and reading books on the subject that you never get around to doing anything. One of the authors of this book (Rosenberg) is a big UML advocate and has written at least two books on the subject, so I was suspicious.

I want to like XP because I feel strongly about several of XP's source tenets -- such as frequent releases, not bloating the code right now with reusability that will never be needed, refactoring often, and unit testing. And of course it looks sort of 'open-sourcey.' Power to the programmers! I finally decided I had some time to spare, so I lined up Extreme Programming Explained by Kent Beck, Extreme Programming Installed by Ron Jeffries, and XP Refactored.

The Outline XP Refactored starts out by examining eXtreme Programming's basic methodologies and its central claim: In other methodologies, making changes to the project takes exponentially more resources the further along you are in the project. If you make a big change after two years of development, it costs a lot more than a big change after one month of design. XP's basic claim (even if they don't enunciate it this way very often) is to flatten the cost of change by keeping everything in a state of flux all the time. In their words, Embracing Change.

There are 12 canonical XP Practices, and a couple more which weren't part of XP originally but are now gospel, such as collocating -- the entire team needs to fit in one room, or some of the Practices break down. The book goes through the four values, the four activities; basically you get XP in a Nutshell right up front. And the authors do a good job of presenting these in the spirit intended, I think -- after reading this chapter you might feel that XP is a fine thing.

Then we start getting into the juicy bit you bought the book for. They start by examining the infamous C3 project at Chrysler. This was the poster-child XP project that launched XP to stardom and spawned a flood of magazine articles and 20 books on the subject. It was started in 1996 as a payroll system to replace the payroll system running on Chrysler's mainframes, because Chrysler was pretty sure that the Y2K bug would cause all their mainframes to keel over on Jan 1, 2000. Kent Beck was brought in, and he brought in the others. The project was canceled in Feb 2000, when it was apparent that it was still nowhere near done and the mainframes were still working after the drop-dead date.

This chapter really sets the tone for the book. First, we get the too-clever-for-my-taste Beatles filks (song parodies). We get a fairly concise summary of what happened along with references for you to study if you wish. We get lots of satire from the authors. We get copious quotes from XP gurus hanging themselves with their own rope -- and this proves to be one of the most powerful techniques in the book. You are given all the URLs you could ask for to further research the subject yourself, including the XP gurus' own takes on what happened. You will learn that to XP people, 'inexplicable termination' of a horribly late project that has failed in its very reason for existence can be Success. It is at this point that, if you love XP, you will probably fling the book against the wall and walk away. As gleeful as the XP camp was in trumpeting the early successes of the C3 project, the authors of XP Refactored are just as gleeful in dissecting the final outcome and the subsequent confused disarray in the XP camp -- such as TerminationCanBeSuccess.

The next chapter, 'The Case Against XP,' provides the manifesto for the book. It lays out the authors' case in a step-by-step overview. You won't be convinced of anything after reading this chapter, but it summarizes and provides references to later chapters.

'Extremo Culture' examines what kind of people are attracted to XP, how XP plays on the natural inclinations of most programmers who will be attracted by some of the good ideas and not-so-good ideas XP builds on, and the XP culture of fear. XP is obsessed with Fear and Courage -- you must have Courage to do XP, and if you oppose it, it's because you're Afraid of it. You need to be corrected or eliminated (off the team, nothing more violent than that). The only thing that causes project failure is Fear - either you were afraid of XP and weren't doing it right, or someone outside was Afraid of your XP project. I found this chapter quite fascinating, because I could see a lot of myself and the people I've worked with in it.

Having laid out the Practices, and The Case Against XP, the book takes on each of the practices in turn and gives it a thorough going over. This is the largest section of the book, as there are 12 (plus) Practices to cover in detail. The outcome of the analysis is generally negative, though not always -- the authors feel that XP's emphasis on unit tests is a good thing in general and should be expanded to other methodologies. They like frequent releases, just not quite so frequent. The Pair Programming chapter is perhaps the most gleeful, because it's arguably the worst idea in eXtreme Programming when taken to the eXtreme of no programming alone, ever, so there's plenty of fodder for wit and demolishment. But they also examine how Pair Programming is part of the Practices because it's required to compensate for other XP fragilities. This chapter is available as a sample chapter on the authors' website.

After examining the Practices, the book looks at the outcome of another XP research project: what would you expect to happen based on the previous chapters in the book, what did the study report show happened, and what can we learn from this? The predictions of the XP Refactored authors seem to be mostly borne out, and of course they say this proves XP is a bad idea. Though in the end, the study authors said, "But we liked XP anyhow." So you can draw your own conclusions on this one.

And finally, in perhaps the most practical chapter, they take XP and Refactor or 'defang' it. XP makes use of some good ideas, after all. The major failing is taking them all to extremes on the theory that if chocolate tastes good you should eat nothing but chocolate (You think that's silly? Beck reasons exactly this way.) This chapter suggests how to combine XP with real software engineering practices to hopefully achieve manageable, predictable results. Combine flexibility with actual design and risk control. Perhaps not surprisingly, this method resembles a lot what you'll often find small teams of skilled programmers doing on their own. And if you asked them what methodology they were using, they might even say eXtreme Programming, even though they aren't.

What Doesn't Work? Let's start with the bad. The song parodies are unrelenting and painful. If you like filking for the very idea of delicious subversion of media to your own ends, or you are the kind of person who loves any web comic that mentions Star Wars simply because it mentions Star Wars, you may think these are clever. At least they're easy to skip, but severely hamper the utility of handing this book to a manager and saying, "Please read this, it's important." The prose satire sequences and Monty Python skits are less painful, but again often too self-satisfied for their own good. But sometimes nothing makes your point like satire.

If you're a big XP fan coming in, you will almost certainly be turned off by the relentless skewering of XP. Then again, I don't think this book is aimed at you, nor is this review.

XP Refactored does an excellent job of providing all the ammunition you will need to convince anyone who might be thinking of foisting pure XP on you that it's a bad idea, even in manager terms. However, it doesn't provide an 'executive summary' chapter and it could definitely use one - simply because no manager is going to read through this entire book, much of which is in programmer-speak. Chapters 2, 3, 14 and 15 all almost fit the bill, but it needs one chapter with references you can just rip out and hand to your boss to read between holes of golf.

What Works?

Advocates of a position usually fear the other side, and will try to prevent you in some way or another from being subjected to the opposition's best arguments. On the contrary, the authors of XP Refactored seem to feel that the more you read about XP, in the words of Extremos themselves, the better their anti-XP case is made for them. Quotes are used relentlessly, and by the end of the book you will have the eXtreme suspicion that most of the XP authors are making everything up as they go along with no worries about consistency. Which, if you think about it, is pretty XP -- all the contradictory injunctions can be refactored later. Very often the authors' best case against XP is made by a prime quote from an advocate, with reference supplied so you can go verify that it's not out of context, of course.

Secondly, there are frequent Voice of Experience sidebars, which consist of feedback from people who have been involved in XP projects. The authors say they did not solicit these, but when word got out that they were doing the book they started getting submissions anyhow. They delayed the book and added 25 pages in order to fit the VoXP sections. That was very smart, because these notes from the field are quite visceral and provide powerful contrasts between XP in theory and XP in practice -- simply reading the authors' arguments would not be nearly as convincing. For example, the field stories of how XP coaches or managers tend not to do Pair Programming, even while they make everyone else do it, because they hate it too.

XP Refactored is not relentlessly anti-XP, though it sure may seem like it at first blush. The authors do a good job of presenting XP ideas in terms that are not unflattering before they dissect them. They do acknowledge that many XP practices are just good ideas that have been 'turned up to 11' on the theory that more is always better, and will point out the core of a good idea. For instance, rapid releases are a response to the problem of massive unwieldy design methods where everything is supposed to magically all come together at first delivery way down the road, and often doesn't. They also point out that most of XP is a pretty good mode in which to maintain already developed and mature software.

This book makes an important distinction between two levels of XP - the 'official' XP, which is what you'll get in the books (though that's often contradictory) and the 'Extremos' position, which is what you get when the authors argue amongst themselves on Usenet or Wiki and are less guarded and more honest. This is an important distinction as far as theory vs. practice. You'll glean from the various quotes and URLs, if you haven't read the XP books, that Kent Beck is a fairly intelligent guy and knows when it's smart not to go into too much detail on a delicate subject, and when it's time to move on to other causes like Test Directed Development. And then you've got people like Ron Jeffries and Robert Martin who should be thanking their personal gods every day that XP came along and gave people as horribly unqualified to manage or design software a bandwagon to hook onto.

I was a bit harsh earlier on the song parodies and satire sections, but in many cases humor is used quite well to expose the underlying weaknesses or contradictions in XP. That old British humour serves its purpose, and should be well received by the geek audience for the most part. Do you like User Friendly? You should love this.

Finally, the book does an excellent job of clarifying the cultlike nature of XP. How it appeals strongly to coders who think they're being oppressed by The Man and claims to empower them while reducing them to a commodity. Anyone who opposes the culture it is Afraid of you, and needs to be eliminated (non-violently) or ignored. If your XP project fails, it is because you weren't Really Doing XP - any deviation from XP is what lead to disaster. However they'll also tell you it's so flexible you can feel free to change it in any way to fit your way of working. Except you must always Pair Program. Except when you don't. Got that? You may think I am stupidly oversimplifying here, but no, quotes and references are provided. And I'd already gotten a lot of this just by reading two pro-XP books (XP Explained and XP Installed).

Key Points

If you are already pretty sure you want to read XP Refactored, you may want to just skip this section. These are key points I got from reading the book, and of course they're made in far more detail and more cogently in the book itself. This is where you'll find it's pretty clear that I ended up siding with XP Refactored, as well.

The most important argument XP Refactored makes, and uses as a basis through the rest of the book, is that XP is a highly fragile web of high-risk practices which are woven in a tight web to minimize the damage from the other bad practices. These are (mostly) worst-practices that coders engage in because, heck, the most fun part of programming is the coding. So XP attempts to compensate for them and turn them into virtues. For instance, the lack of written documentation is balanced by the code sharing and pair programming, which are supposed to make sure that everyone knows everything about the system. If any one of the practices is not followed religiously, the whole thing comes crashing down. This is referred to as the 'circle of snakes' and is an excellent distillation of what XP books continually hint at but don't tell you outright. XP Refactored goes through each Practice and shows how failing to stick to it causes everything else to collapse, domino-like.

The circle of snakes means that XP (and this is my own analogy, don't blame the authors) is a precariously controlled free-fall, which should get you to where you want to be faster than hiking if you can maintain control. But people don't stick to the practices 100%, because they're very high discipline, the circle unwinds, and the snakes are venomous. As usual in the book, this viewpoint is validated by plenty of quotes from the Extremos themselves, who will tell you that any XP project failed only because you deviated from XP. And XP is such a high discipline methodology that unless you are continuously coerced back onto the true path, you will deviate from it; this is also covered in the C3 chapter, where it happened to even the Poster Child XP team.

XP's indifference to design is pretty astounding to anyone who's gone through any reasonable sized project. The theory is that you don't add anything more than you need at the moment. YAGNI (You Ain't Gonna Need It). And to a certain extent this is a good idea - if you're writing a small memory pool system, there's no need to turn it into a full blown memory manager 'just in case'.

But to use an XP example from the book, if you're working on an program that will need to work with objects on several different systems (local disk, database, web, ftp) but right now you're only got the disk based story card (user stories being broken up into small tasks) you hard code everything in your program to go right to the disk. Even though you know that you will need web support, because the customer insists on it, you are not allowed to plan for that whatsoever by adding a layer of abstraction between your code and the abstracted 'object holder'. Rather, when someone needs to add web support, they will just code it right in, maybe at least out in a separate web class. It will have a slightly different interface than the disk class, since there's almost no design, no planning, and different people coding it. Then later on you will refactor the code and merge these three or four different systems, make them behave the same, and clean up the code.

This is incredibly expensive and error prone for something that could have been avoided with even a little thought up front. You can say that any decent programmer would of course realize this was what was needed to be done, and add the abstraction layer. But you are no longer practicing XP. You made it needlessly complex for the moment, and added a requirement that might be removed.

There is no need for any large scale design in XP because it will naturally 'emerge' from continuous refactoring. As Kent Beck says, "The larger the scale, the more you must rely on emergence." You can treat a 10,000,000 transaction per second system as if it were a 1 transaction per second system. You write the 1 tps system, then the 10,000,000 tps system will just be 'refactored' from the 1 tps system when necessary. You don't need to worry about degenerative interactions between different parts of the system. You don't even need to worry about any error handling or out of bounds cases because that's not simplest possible design, until the customer codes up acceptance tests that trigger these. If you've been on a real project you're probably gasping for air now.

These next few points are points you can bring up with your management if they decide to do XP since they read a neat article about it somewhere. I know arguments that appeal to management aren't necessarily going to be seen as a good thing by coders, but if you've had some project experience they should make you break out in a cold sweat too.

An incredible burden is shifted to the 'customer' in eXtreme Programming. The customer (representative), in the room at all times, is responsible for expressing all the requirements in the form of short use stories (which can be jotted down on a card) and in the form of code, as acceptance tests. The customer is now responsible for everything, and if anything doesn't work, it's the customer's fault for not making their tests stringent enough. Given the extremely low likelihood that anyone is going to dedicate a senior designer/programmer to work with the XP team indefinitely, this tends to fall on someone more 'expendable'. Who is still expected to do a massive amount of work and know how to code and take all the responsibility for the project while having no real authority over the XP team that's implementing it. It should come as no surprise that this is a high stress, high burnout position and that the XP people are trying to 'refactor' this requirement constantly. Now ask your manager who the 'customer' is going to be.

Excellent management ammunition also comes in XP's total inability to deliver your requirements on time - it's quite up front about this. This seems a little strange for something that claims to make your development more rapid, but one set of XP gurus will tell you that XP can deliver by a fixed date, but not a known set of deliverables, and another will tell you that XP can deliver any fixed set of deliverables, but not by a known date. Which works out to be equivalent. Other methodologies often deliver late, but XP doesn't even try, and this is because XP totally punts any real design or scheduling. You can't tell how much emergence or refactoring it's going to take. Let's hear it in their own words:

"One of the most important principles in planning for Extreme Programming is that the dates are hard dates, but scope will vary.'" -- Kent Beck and Martin Fowler.

"There is a difference between 'Schedule' and 'The Schedule'. In XP, 'Schedule' is very important, but 'The Schedule' doesn't exist per se. ... The reality, of course, is that a software project is never done until it has been terminated." -- Robert C Martin

"Once you accept that scope is variable then suddenly the project is no longer about getting 'done'. Rather it's about developing at a certain velocity. And once you establish a velocity then the schedule becomes the customer's problem." -- Robert C Martin

My favorite quote in the whole book also comes from Robert C. Martin:

"If you lose a card, and if the customer does not detect that loss, then the card wasn't very important. If, however, at an interaction planning meeting, the customer says: 'Hay [sic], where's that card about blah, blah, blah,' you'll find it easy to recreate."

Did you get that? It's okay to drop customer requirements in the trash, and unless the customer remembers to code up an acceptance test checking that requirement... the joke's on him! The customer can request you do some documentation, any documentation, monsignor please, only by writing up a story card - how often do you think those get lost? And lest you think this is just a moment of weakness, XP Refactored supplies other quotes from XP gurus encouraging you to dink with the user story cards as it suits you. Summary

XP Refactored largely succeeds in the task to which it set itself: countering the hype of XP, or at least defanging it and making it sane. It won't make any difference to the fanatic adherents and their book empire, but this is an excellent guidebook if anyone tries to foist XP on you, or if you'd been making sideways glances at XP, curiously attracted as it batted its eyes at you. You can tell they had fun writing it, so it's mostly a fun read.

It could sorely use an executive summary chapter consisting of only the most compelling points with references, and please, no humor. For giving an executive to read when you're threatened with XP since he read about it somewhere.

Now I know people are going to read this and indignantly retort that XP is based on some good ideas, and I fully agree. XP's starting assumption, as explicitly stated by Kent Beck, is that if a little of something is good then as much of it as possible is even better. I like chocolate, but I'm not going to eat to exclusion. I further know people are going to respond 'But XP doesn't require you to _x_!', where _x_ is something like lack of design, or not planning ahead. This again is part of the cultlike beauty - you can claim any conflicting interpretation of the Rules you want. The primary advocates often do - Robert Martin says You Must Pair Program, Ron Jeffries says it's an ideal only, except where he says it's absolutely required, but if you fail then it's because you deviated from pure XP. Is that a little breathless? Well, no wonder.

XP Refactored really clarified my uneasiness with XP after reading the two XP books - first it simultaneously devalues real software engineering by providing justifications for ditching it all and treating programmers as commodity items. Secondly the horribly risky practices, combined with the incredible hype, seems to be setting us up for a return to crushingly restrictive, mind numbing waterfall methodologies when it shatters in the field like the fragile flower it is. As already happened at Chrysler, where even Smalltalk and the concept of Object Oriented were tarnished by association with the C3 project.

If you find yourself drawn to XP, as I was, I suggest you read Extreme Programming Explained, by Kent Beck, then this book. Hopefully you can read these and come away with a good idea of what works in XP and what doesn't. Perhaps you might feel the urge to unit test a bit more. Or do rapid release with at least some sane amount of design. Frankly, I got a better feel for the actual strengths of XP from Refactored than I did from any of the pro-XP books, including Explained. Which is pretty good for a book whose stated purpose is to deflate XP.

You can purchase Extreme Programming Refactored: The Case Against XP from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Genady writes "It's about time. Ever since I picked up a copy of Julian Barbour's The End of Time I've been intrigued by time. Everyone understands the concept of time to some degree, yet to explain why time is, is a mental puzzle that has played in the outskirts of my mind for years now. Brian Greene, author of The Elegant Universe has brought us a compelling, easy-to-follow journey through the history of physics and beyond to tackle the very question of 'why is time?' and 'what is space'?" Read on for the rest of Genady's review. The Fabric of the Cosmos author Brian Greene pages 576 publisher Knopf rating 7 reviewer Genady ISBN 0375412883 summary A capsule review of current conceptions of the world of space and time, and enough background for laymen to understand how they came to be.

Now, when I say "easy," this is, like so much of Greene's book, relative. It's taken me three weeks to wade through the concepts and often humorous prose that goes along with them. Being something of a physics geek, I have a basic concept of relativity and quantum mechanics. Greene takes his time laying out classical physics, from Newton to Einstein, exploring the version of the universe presented by the laws of the very large. He then dedicates just as much room enumerating the precepts of the standard model as well as those of quantum mechanics. With these two pillars of modern physics established, we are next whisked on a journey through cosmology, delving further and further back into the history of the universe until both quantum mechanics and relativity break down and we are introduced to strings.

Greene's attention to strings does not overwhelm the book, as in The Elegant Universe, and he doesn't delve deeply into the concepts and math behind any of the theories of physics as in the latter half of his earlier text. What he does present is a very good conceptual overview of modern physics, all the while using the frameworks provided to drive at the central question: What are space and time? (Or "spacetime" as relativity puts it).

This sophomore effort is actually better, I believe, than The Elegant Universe. Greene has a way of explaining things in terms that non-physicists can grasp. His use of pop-culture icons to drive his points home are as masterful as they are funny. It would be my bet that should this book be made into its own television special (and it should) it will have to be a joint work by PBS and Fox. After seeing Greene present his Elegant Universe on PBS, and reading this book, I'm beginning to see him as a new Carl Sagan, or perhaps the illegitimate love child of Sagan and Matt Groening, if such a thing were possible.

In the end, though, the book has left me with more questions than answers. To be sure, Greene and the theories that he covers provide answers, but to conceptualize and understand them is my current difficulty. I'm sure that some of my own problems arise from learning through allegory. Not having the mathematical background to understand these concepts on a more fundamental level is, I'm sure, leading to my own habit of taking an allegory too far. Would the book benefit from a deeper analysis of physics? I don't think so. To take things much deeper would lose those of us without a deep rooting in mathematics. If anything, Greene's work should inspire us to learn more, to grasp the concepts at a deeper level, to understand them in a more fundamental way, if this is indeed possible with the strange world of quantum mechanics.

Greene does delve into what the future of physics could hold. This is, in my opinion, the weakest part of the book. While it is interesting to be exposed to what the 'next big thing' could be, without the grounding that Greene enjoyed in the previous four sections of the book the final chapters prove less fulfilling than the ones that worked towards them. It's not that Greene doesn't explain the concepts expertly, but knowing that we're reading about a theory that hasn't even been fully formed, that is only a step away from speculation, means they don't stand as tall as the previous chapters. People may say this about string theory as well, because it is still very much an evolving theory.

Still, this accounts for no more than the denouement of an otherwise thrilling, work. Having traveled once again with Greene on a journey through physics I can say that I understand what Feynman meant when he spoke of The Pleasure of Finding Things Out; thankfully Greene is a good bit easier to follow than Feynman.

You can purchase The Fabric of the Cosmos from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

charlie writes "Bruce Sterling has been writing on the cutting edge of SF for close to thirty years now. After 2000's Zeitgeist he took some time out to write a non-fiction book, Tomorrow Now -- but it's nice to see he's returning to fiction with a new novel, The Zenith Angle, due out in hardcover on April 27th. While his first novels were set in the far future, his recent novels have approached ever closer to the present moment, so it's not too surprising to see that The Zenith Angle is being marketed as a technothriller." Read on below for the rest of Stross' review. The Zenith Angle author Bruce Sterling pages 320 pages publisher Del Rey rating 10 reviewer Charles Stross ISBN 0345460618 summary High-impact infowar technothriller for the technoliterati

Full disclosure forces me to mention that the publisher sent me an advance copy in the hope that I'd write a cover blurb it -- and I did. I'm really impressed. To sum it up in a single sentence suitable for a dustjacket slot, Bruce has written a Catch-22 for the Slashdot generation: a wry, cynical, informed peek at the paranoid world of the post-9/11 cyberspookerati that shines a bright light on the hidden arsenal of infowar.

So what's it all about?

Meet Derek Vandeveer: your typical shy, retiring, brilliant computer scientist working for an internet startup, married to an equally shy and retiring astronomer. And his former college roommate, Tony Carew: your typical dot-com boardroom monkey, a slick, extroverted hustler with a bizjet and a girlfriend from Bollywood. 9/11 happens, and their worlds are never going to be the same again. One of them is going to betray everything he holds precious, the other is going to dive head-first into the twilight world of internet-era espionage, and when they meet again the consequences will be explosive.

The plot romps along with ironic, discursive energy, from the Rocky Mountain hideaway of an increasingly eccentric billionaire industrialist to the bolt-hole basement where America's guardians wait out the long watch for an act of atomic terrorism -- but we're in safe hands here, because we've got Sterling for a guide. This is the future. This is now.

At this point in a normal review I'd start comparing the product to other novels. In fact, if I was Bruce Sterling reviewing this book and it was written by somebody else, I'd say something like: "this is a book that stands proudly in the tradition of Neal Stephenson's Cryptonomicon [if Cryptonomicon was, like, a normal-length novel instead of a trilogy in a corset] and Bruce Schneier's Secrets and Lies"[but hang on, Secrets and Lies isn't even fiction -- where am I saying, here?] ..."

But I'm not Bruce (and I don't have the chutzpah to put words into his mouth because he's a better reviewer than I am). So let's just say, my take on affairs is that The Zenith Angle doesn't really stand in any kind of tradition at all (even though it does read better if you also dig Schneier and Stephenson). It's one of a kind. What we've got is one of the godfathers of cyberpunk taking a long, hard look at where we've come to. And it's a frightening place indeed. He's been tracking this territory in WIRED for several years now: from the frontiers of hacking (which he documented in 1994's The Hacker Crackdown ) to the weirdly convoluted secret history of the military-industrial complex.

By inclination and occupation Sterling is one-half journalist, one-half futurist, and one-half gonzo cyberpunk novelist -- and he somehow crams it all into this book, a 150% full-on technothriller with science fictional sensibilities, or an SF novel about a future that has imploded into the present. This is good, excellent, stuff. Trust me, you'll like it. Pre-order it from Amazon or buy it next month when it comes out -- but read it anyway. It's seminal and it's scary.

Besides Amazon, you can pre-order The Zenith Angle from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Chris Cowell-Shah writes "If David Foster Wallace can't explain infinity to us, nobody can. At least, that's what I told myself while anxiously waiting for his Everything and More: A Compact History of Infinity. The book promised to be an intellectual history of the mathematical concept of infinity, with heavy doses of history, math, and philosophy. And while it proves heavy going at times, I'm pleased to say that it delivers admirably on this promise." Read on for Cowell-Shah's lengthy review of Everything and More. Everything and More: A Compact History of Infinity author David Foster Wallace pages 319 publisher W. W. Norton & Company rating 8 reviewer Chris Cowell-Shah ISBN 0393003388 summary A mathematical and intellectual history of the concept of infinity.

Wallace may be best known for his footnotes. Virtually everything he has written from his strange but mesmerizing novel Infinite Jest to his hilarious essay about cruise ships (the title work in A Supposedly Fun Thing I'll Never Do Again) to his oddly gripping treatise on the philosophy of dictionaries ("Tense Present" in the April 2001 issue of Harper's)has been liberally sprinkled with footnotes. And what footnotes! Many go on wild tangents. Some contain sub- or sub-sub-footnotes. Others are the length of novellas and could legitimately be reprinted separately from the main work. My point is that Wallace is, at heart, a scholar. He's interested in details. Combine this with an impressive background in math and logic (though he modestly claims a "medium-strong amateur interest in math and formal systems"), and he would seem to make the perfect tour guide for infinity, a concept that seems simple enough on the surface but which we generally suspect is far more complex than we realize.

The Book's Audience and Aims

DFW (an overabundance of abbreviations is one of his most prominent literary tics, and I'll follow his lead) calls Everything and More (henceforth EAM) "a piece of pop technical writing" for "readers who do not have pro-grade technical backgrounds." But the fact of the matter is that to truly follow and understand all (or even most) of his points, one needs to know a lot of math. I'm probably typical of the average reader of EAM: I went through the standard two-year calculus cycle in high school and college, and though most of it made sense at the time, these days I generally double-check my long division. While I've had a fair amount of tertiary-level logic and formal systems coursework while studying computer science and philosophy, even those subjects have grown fuzzy with time. But I am interested in this stuff, and I have the patience and analytical practice to wade through almost any argument or proof, so I would guess that my experience with EAM is pretty close to that of most Slashdot readers.

I should note that this work is really an extended essay rather than a book. Granted, it's a 300-page essay, but that's the term DFW insists on and it seems appropriate given the lack of chapters. The only structure is provided by relatively unhelpful section headers like "4b," and the work sometimes seems to lack convenient breaking points where the reader can pause to catch a breath. This is not a criticism, but the style of the essay does demand that the reader do his best to stay aware of where he is in the overall story of infinity and to be prepared for occasional gaps in the narrative thread. Read this like a math proof with lots of reviewing and re-reading and comparing of earlier and later claims and you should do all right. It's also worth pointing out that the word "history" in the essay's subtitle is important. DFW's goal is mainly to chronicle the ways in which early and not-so-early mathematicians approached the concept of infinity, rather than to explain what infinity is useful for or to give us new ways of thinking about the term. It will probably never have the same mass appeal that more colorful but less difficult books like James Gleick's Chaos or Douglas Hofstadter's Gödel, Escher, Bach have enjoyed, but this is not necessarily a bad thing. DFW has a narrower and more technical aim, and he generally hits his target.

What EAM Covers It's probably better to think of the essay as a series of loosely related arguments and observations rather than a single mathematical story. With this in mind, let's go through some of the essay's sections. DFW opens by discussing what it means to engage in abstract thinking, then investigates the Principle of Induction (a crucial element in the development of infinity) and explains Euclid's proof that there is no largest prime. He (re-)introduces us to a number of high school math concepts, including such things as reductio ad absurdum proofs and the difference between modus ponens and modus tollens. This refresher is very helpful; I consider the book's opening section to be worth the price of admission all by itself.

Once we've got these preliminary concepts under our belt, DFW starts in with ancient Greek philosophers and mathematicians and begins constructing a vast pyramid of mathematical ideas that will eventually support Georg Cantor's notion of infinity at its tip. This nineteenth century German mathematician is the central figure in the book (to the extent that there is one), and DFW makes it clear early on that we're ultimately moving toward his ideas and his vision of infinity. A quick tour through the Greeks covers Pythagoras, Zeno's paradoxes, Aristotle's demolition thereof, and Plato's theory of forms. It's at this point that we are introduced to fascinating questions of mathematical epistemology and ontology, questions that were first mulled over by the Greeks but that remain largely unsettled even today. For example, what do we have to know in order to really know and understand a mathematical concept? And do numbers exist external to people (the Platonist view), or are they purely human constructs (the Intuitionist stance)?

DFW skips ahead to the seventeenth century, where he showcases Galileo's ideas in Two New Sciences and leads us through some of Newton's and Leibniz's independent contributions to the development of calculus. A wonderful discussion of the archetype of the insane mathematician follows (he makes the unsurprising claim that very few world-class mathematicians were terribly well-adjusted). He then chronicles the intellectual shift from math being thought of as empirical (grounded in actual things) to abstract (based on intangibles and relations between them). He does a good job of explaining how this abstraction works surprisingly well when applied to real problems (especially in engineering and physics). It's at this point (in section five of seven) that the mathematical heavy lifting begins. DFW delves deeper into calculus and the notion of limits, and significantly more mental energy is required if the reader wishes to follow carefully. Fortunately, close scrutiny isn't strictly required; even skimming this portion and picking up the thread again in section six yields good results. Now winding down, DFW introduces us to Fourier series and steps through Cantor's delightful diagonalization/denumeration proofs of the mind-warping claims that there are the same number of whole numbers as integers as rationals, and that the cardinality of the reals is larger than the cardinality of any of these other sets. A short excursis into set theory (like most of the rest of the book, it's thrown at us semi-haphazardly rather than being systematically presented), a longish explanation of Cantor's Continuum Hypothesis (a claim about the relations between the various "sizes" of infinity), and we're done. Exhausted and probably more than a little confused, but done.

EAM as a Mathematical History

There are two ways to judge EAM: as a work of mathematical history, and as a piece of English prose. I consider it adequately successful when viewed in the first light, but exemplary when viewed in the second. The math side of the book is probably best assessed by presenting a scattershot collection of my impressions, so let's start with those.

DFW is, in the main, aware of which portions will pose particular trouble for most readers. The prose is peppered with phrases like "Now you can probably feel a headache starting" or "Here's one of those places where it's simply impossible to tell whether what's just been said will make sense to a general reader," which are usually accompanied by extra explanations or illustrations to clarify the point just made. As an amateur mathematician, he may in fact be better at empathizing with his readers' difficulties than many professors are. It's hard to imagine the following passage (with its awestruck tone) appearing in a math textbook or college calculus lecture:

"Let's pause to consider the vertiginous levels of abstraction involved here. If the human CPU cannot apprehend or even really conceive of infinity, it is now apparently being asked to countenance an infinity of infinities, an infinite number of individual members of which are themselves not finitely expressible, all in an interval [0-1] so finite- and innocent-looking we use it in little kids' classrooms. All of which is just resoundingly weird."

As an example of how he leads readers around conceptual landmines, DFW is especially careful to steer us away from thinking that infinity is just a really large number. He invites us instead to consider it and its cousins to be entirely different sorts of objects than finite numbers, with very different properties. This segues into a first-rate explanation of how infinity-related paradoxes (including Zeno's famous arrow paradoxes) often go away, or more properly, cannot be meaningfully stated, once we stop treating infinity as a normal number or (for certain paradoxes) once we are clear on the difference between zero and nothing (or "not applicable"). These are nonobvious points that I had never considered, but which make perfect sense once carefully laid out and illustrated. Resolving these paradoxes turns out to be a crucial propelling force in the history of infinity: "By this point you've almost certainly discerned the Story of Infinity's overall dynamic, whereby certain paradoxes give rise to conceptual advances that can handle those original paradoxes but in turn give rise to new paradoxes, which then generate further conceptual advances, and so on."

Even if you're relatively uninterested in the concept of infinity, DFW's broad and extraordinarily literate survey of concepts like abstractness, limits, and induction make the book worthwhile. He does an especially good job of explaining the nature of abstraction and why abstract thinking is so difficult. The essay is replete with facts not directly relevant to infinity but still interesting to the scientifically inclined. For example, it turns out that 5 x 10^-44 seconds is generally acknowledged to be the smallest interval in which the normal concept of continuous time applies. And Bremermann's Limit (2.56 x 20^92) is the theoretical limit of the number of bits of information that could have been processed by the most powerful computer that could exist on earth (a computer with the mass of the earth that has existed as long as the earth). Problems involving more data than this (such can be found in statistical physics) are considered transcomputable, or not computable in any meaningful sense. These geeky trivia won't improve your life in any way, but it does stave off some of the inevitable monotony of pure math writing.

DFW has lots to say about mathematical pedagogy, including this harsh indictment:

"Rarely do math classes ever tell us whether a certain formula is truly significant, or why, or where it came from, or what was at stake.... And, of course, rarely do students think to ask the formulas alone take so much work to 'understand' (i.e., to be able to solve problems correctly with), we often aren't aware that we don't understand them at all. That we end up not even knowing that we don't know is the really insidious part of most math classes."

Perhaps this concern for how math is taught leads him to focus his efforts strictly on core concepts rather than on the biographical gossip so often found in popular science writing. There are some fun notes about Cantor's personal life, but he's the only one who gets an extended biographical exegesis. This appears to be a conscious and reasoned decision on his part rather than an oversight ("Again, most of this personal stuff we're skipping") and I think it is a wise strategic move in that it keeps the reader's attention focused and undistracted.

As expected, this work does indeed swim in a sea of footnotes. DFW fans would be disappointed in anything less, but I have to confess to lightly skimming most of the footnotes after the first third of the essay. The most difficult or technical notes are marked "IYI" (for "If You're Interested"), but even the non-IYIspasm notes are full of some pretty thorny math; I found that they often proved more confusing than helpful. But readers more familiar with the subject matter might appreciate the additional historical context and suggestions for further exploration provided in the footnotes.

Overall, EAM is more successful at explaining the small problems, paradoxes, and steps in the creation of infinity than it is at stringing them all together into a coherent, easily followed, transparently structured whole. As an example of how well DFW deals with the small-scale issues, consider the following mind-boggling concept. It is of course impossible to fully wrap your mind around this sort of thing, but in the text that follows this quotation he does a sterling job of steering us toward comprehension:

"The Number Line is obviously infinitely long and comprises an infinity of points. Even so, there are just as many points in the interval 0-1 as there are on the whole Number Line. In fact, there are as many points in the interval .00000000001-.00000000002 as there are on the whole N. L. It also turns out that there are as many points in the above micro-interval (or one one-quadrillionth its size, if you like) as there are on a 2D plane, even if that plane is infinitely larger in any 3D shape, or in all of infinite 3D space itself."

On a similar theme, DFW gives a brilliantly simple and utterly convincing explanation of the cortex-withering claim that "the number of points in the closed-interval [0,1] is ultimately equal to the infinity of points on the whole Real Line stretching infinitely in both directions." But (and this is my biggest criticism) this essay really has to be read twice (or more) to get anywhere near full comprehension of the material. In this respect, it's a lot like an extended math proof or a very long philosophy paper. Repeated exposure makes it easier to follow the narrative flow and string the arguments and proofs together into a consistent thread of thought rather than isolated, self-contained concepts.

EAM as a Literary Work

As mentioned above, where EAM really shines is not as a math history, but rather as an example of pure writing. DFW's prose is clear, precise, witty, and creative. His literary idiosyncrasies may be an acquired taste, but once the reader gets used to the aesthetic feel of the essay it becomes hard not to consider it a stylistic tour de force. In many ways this doesn't feel like a math book at all. This is perhaps not surprising given that the author is, after all, mainly a novelist. He loves to make up words, use obscure words, or use common words in strange new ways. Your appreciation for this style will vary depending on your tolerance for neologisms like homodontic (meaning "having only a single type of tooth") or epistoschizoid (meaning, well, your guess is as good as mine), or unusual punctuation (Does he really need parentheses nested inside of other parentheses? As it turns out, yes.). But you also get exposed to real (and entertaining) words like clonic (involving muscle spasms -- nothing to do with clones), cephalalgia (headache), and peruke (the goofy hats worn by Dutch burghers in seventeenth century portraits). Sometimes it doesn't quite work (What does "We are now once again sort of out over our skis, chronologically speaking" mean? Anyone?), but the overall effect is a refreshing and fun change of pace from standard math or science writing.

DFW uses shorthand to an almost pathological degree. This takes some getting used to, but ultimately it makes his text wonderfully compact (OK, his sentences can be almost unparsably long, but he packs a ton of content into each one) and produces virtually no loss of comprehension. The text is sprinkled with abbreviations like "w/r/t" for "with respect to" and useful sentence fragments like "Meaning it doesn't seem logically impossible or anything," and "Goes on forever." This sort of shorthand is pervasive, but really is more of a help than a hindrance. They may not be everyone's cup of tea, but informal parenthetical phrases such as "they're reversed from the axes in the motion-type graphs you're apt to have had in school (long story; good reasons)" are usually very helpful and inject a nicely colloquial tone into a topic that is traditionally treated in the most formal (and dullest) of styles. Descriptions like this are what keep you going when the math gets tough:

"[T]he whole enterprise becom[es] such a towering baklava of abstractions and abstractions of abstractions that you pretty much have to pretend that everything you're manipulating is an actual, tangible thing or else you get so abstracted that you can't even sharpen your pencil, much less do any math."

Everything and More: A Compact History of Infinity is more or less what its title promises. I found it well worth the (not insignificant) effort to plow through, and I recommend it to anyone interested in mathematical and/or intellectual history, or to anyone curious about how difficult mathematical concepts can be discussed in a lively and engaging way. While most readers won't be able to follow all of the subtleties of his arguments with just one pass through the text, a single pass can still be well worthwhile. Those looking for an introduction to David Foster Wallace would be better served by one of his less difficult books (I especially recommend A Supposedly Fun Thing I'll Never Do Again), but for fans of his more technical, scholarly essays, this book is a welcome arrival.

Chris Cowell-Shah is a consultant with Accenture Technology Labs, the R&D branch of Accenture. His website is cowell-shah.com. You can purchase Everything and More: A Compact History of Infinity from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

william_lorenz writes: "With the recent release of KDE 3.2 and KDevelop 3.0, and with the forming of the KDE Quality team as mentioned on Slashdot just days ago, it was an opportune time to read my newest book, C++ GUI Programming with Qt 3. (Qt is of course TrollTech's multi-platform windowing toolkit -- Win32, Linux, UNIX, and the embedded space with Qt/Embedded -- upon which KDE is built. There's a free version licensed under the GPL for non-commercial use and also a commercial version.)" Read on for the rest of Lorenz' review. C++ GUI Programming with Qt 3 author Jasmin Blanchette, Mark Summerfield pages 464 publisher Prentice Hall rating 9 reviewer Bill Lorenz ISBN 0131240722 summary A smooth introduction to best practices for Qt 3 application development.

I didn't have to force myself to read this one: the book grabbed my interest from the beginning. It's filled with just enough technical details to whet my technical curiosity, keep me turning pages, and provide the important information, clearly and concisely. I don't have much Qt development experience (none at all yet), although I am experienced in other windowing toolkits. The book quickly provided me with everything I need to know to get up and developing an application, and now I know where to quickly start.

Who's it for? I am of course a novice Qt developer, yet one with a fair amount of IT experience, specifically with other windowing toolkits. I found this book not only a great introduction for those who want to get started with Qt, but it's also a trove of information for somewhat intermediate Qt developers. It's not for people who work for Trolltech or have already been developing feature-rich KDE applications; however, besides providing a great point of entry for new Qt developers, the book does touch on some more advanced topics. Technical books tend to age quickly, but I should note that the book is written by some of the people who brought us Qt 3 and are working on bringing us Qt 4, so this book should have a degree of forward compatibility. What can I expect to learn?

The book is divided into two sections: "Basic Qt" and "Intermediate Qt" development.

The basic Qt section covers everything that someone new to Qt would probably want to learn, beginning with a simple application and an explanation of signals and slots (signals and slots work much the same way as windowing events in Java, for example, and can help to tell when a button or key is pressed). Signals and slots help make the sample application functional. This section also introduces the Qt reference documentation, available online as a reference during development, and Qt Designer, for those who want to use a graphical user interface to create components such as dialog boxes. A quick overview of some of the available widgets is next (widgets are graphical elements such as dialog boxes and buttons), which helps to give someone brand new to Qt development a feel for some of the components that come ready-to-build-upon. This is all covered in the first 38 pages of the book.

I should point out that I think that knowledge of the C++ programming language is essential if one is to learn good things from this book (I'm a big proponent of learning through experience, and you'll need to play with C++ code), but learning Qt and C++ development at the same time might help one come up with some interesting project ideas for learning!

After a quick introduction to creating custom widgets and double buffering (used in some cases to prevent screen flicker), the intermediate section starts by hopping right into layout managers, intended to make graphical forms and components beautiful (and more usable), just like tables helped to make HTML beautiful before CSS came around; layout managers help do for graphical application components what the font and alignment settings do for a word processor. The managers included are very similar to those used in Java's JFC/Swing stuff, and they work well. Also covered are methods for creating 2D and 3D graphics, drag-and-drop, and event processing. Compared to signals and slots, event processing gives the developer more control, and becomes important when writing custom widgets or changing the way an existing widget behaves.

Following this are sections on internationalization, providing online help within an application, multithreading for responsive applications, and Qt's platform-specific features. Qt works with Microsoft's ActiveX, for example, although this apparently requires the Qt/Windows Enterprise Edition as opposed to the free edition of Qt. It's important to point out that Qt implements its own threading capabilities, and the section on threads covers this in depth.

Conclusion

This is a great book for those interested in Qt and KDE development, cross-platform C++ graphical application development, and just making beautiful, functional applications. The book provides information that can't be had from the Qt API alone, and it does so in a way that kept me turning pages. Blanchette and Summerfield organized their text well, with logical chapters that make finding tips for that first application possible. This book gets twelve thumbs up from me.

Bill Lorenz is Vice-President of the Linux Users Group of Cleveland and is helping to organize the Ohio LinuxFest, 2004 edition (call for submissions now in the wild!). You can purchase C++ GUI Programming with Qt 3 from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Ray Janus contributes this review of Thomas Maufer's Field Guide To Wireless LANs for Administrators, writing "Have you wondered about how the magic of wireless networks for PC's happens? If so, this is a very comprehensive manual on how your bits and bytes move through the ether, and the hazards that they face along the way. Having worked with LANs and WLANs in both personal and business solutions, I was pleased to receive a copy of the Guide at a Sonoran Desert User's Group Meeting, compliments of Addison-Wesley Professional/ Prentice Hall. On first glancing at the title, I expected a 'how to' manual on how to implement and manage a WLAN." While that's not exactly what he found, Janus has mostly good things to say about this book. Read on for his review. A Field Guide To Wireless LANs for Administrators and Power Users author Thomas Maufer pages 333 publisher Prentice Hall/PTR rating 8 reviewer Ray Janus ISBN 0131014064 summary This book takes you under the hood of WLAN technology, providing detailed insights and recommendations along the way.

This book starts out an excellent historical overview of the evolution of local area networks and the migration of TCP/IP technology to a wireless environment. In the process, it provides a definitive reference manual on the 802.11 protocol stack, discussing the evolution and future direction of this standard. The issues associated with reliably transmitting data in the very chaotic wireless world are discussed, but the real meat comes in the book's addressing of the logic behind the radio circuitry in WLANs. Along with these insights that an RF engineer will love, the book is a great guide for anyone with protocol analysis tools looking at wireless traffic, especially given the clear illustrations in the text.

Acknowledging the rapid evolution of 802.11 standards over the last few years, an excellent summary is provided, from the venerable 802.11b standard through the -a and -g standards, and moving into future standards being developed by the 802.11 TGs. Maufer provides some key insights on future directions and capabilities of WLANs, too.

The book covers the principal areas of wireless networking, including security, the hot topic for every LAN administrator. While the book does a great job of addressing the theoretical security issues (and other aspects of wireless LANs operation), it is light on practical recommendations in day-to-day WLAN management. The Guide delves into creating strong passwords for use with WLANs, though, and addresses the strengths and weaknesses of the WEP architecture. It is especially rich in providing insights into the handshake and authentication procedures within WEP. A number of proposed security enhancements are discussed, including the deployment of RADIUS servers to provide authentication in enterprise WLANs. In closing on this section, Thomas provides good insights into WPA, which is becoming the future standard to WLAN security.

For a WLAN component designer, this is probably one of the best reference guides available, and this is also true for power users who really want to get under the hood of today's WLAN systems. However, for a network administrator seeking advice on how to address a herd of WLAN devices, my recommendation would be to seek elsewhere. Maufer offers little information about vendors' product types/models, making the detailed technology discussions independent of real-world products. For the administrator able to glean the technical details of their chosen WLAN products elsewhere, though, this book can be an invaluable guide in deciding the pros and cons of a particular product solution.

Along the way, Maufer provides a series of helpful screenshots, as guides to the technical discussions addressed in the various chapters. He provides a very balanced overview in the use of WLAN technologies for Apple, Linux and Windows platforms.

I recommend this Guide as an excellent text, rich in technical details, and protocol/logic illustrations. A "must read" for understanding WLAN technology in depth. With the rapid advances in WLAN technology, this book represents a excellent benchmark on 802.11 technology, from the perspective of its 2004 timeframe, and a sequel from the author would be an excellent additional resource for WLAN system designers and architects.

You can purchase A Field Guide To Wireless LANs for Administrators and Power Users from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

ijones writes "Andrew Cooke recently reviewed for Slashdot Purely Functional Data Structures, which is on my book shelf next to The Haskell School of Expression: Learning Functional Programming through Multimedia by Paul Hudak from the Yale Haskell Group. In his review, Cooke presented an overview of some available functional programming languages, such as OCaml, SML, and of course Haskell. Havoc Pennington once called Haskell 'the least-broken programming language available today.' Haskell is a purely functional, lazy, statically typed programming language. You can read more about Haskell itself here." Read on for ijones' review of The Haskell School of Expression. The Haskell School of Expression: Learning Functional Programming through Multimedia author Paul Hudak pages 363 publisher Cambridge University Press rating 9 reviewer Isaac Jones ISBN 0521644089 summary Learn to program in a functional style in Haskell by implementing graphics, music, and robots simulations.

As the title implies, The Haskell School of Expression introduces functional programming through the Haskell programming language and through the use of graphics and music. It serves as an effective introduction to both the language and the concepts behind functional programming. This text was published in 2000, but since Haskell 98 is the current standard, this is still a very relevant book.

Haskell's standardization process gives us a window into two different facets of the community: Haskell is designed to be both a stable, standardized language (called Haskell 98), and a platform for experimentation in cutting-edge programming language research. So though we have a standard from 1998, the implementations (both compilers and interpreters) are continually evolving to implement new, experimental features which may or may not make it into the next standard.

For instance, the Glasgow Haskell Compiler has implemented a meta-programming environment called Template Haskell. Haskell is also easy to extend in directions that don't change the language itself, through the use of Embedded Domain-Specific Languages (EDSLs) such as WASH for web authoring, Parsec for parsing, and Dance (more of Paul Hudak's work) for controlling humanoid robots.

Before we get too far, I should offer a disclaimer: The Haskell community is rather small, and if you scour the net, you may find conversations between myself and Paul Hudak or folks in his research group, since I use some of their software. That said, I don't work directly with Hudak or his research group.

In fact, the small size of the Haskell community is a useful feature. It is very easy to get involved, and folks are always willing to help newbies learn, since we love sharing what we know. You may even find that if you post a question about an exercise in The Haskell School of Expression , you'll get a reply from the author himself.

I consider this book to be written in a "tutorial" style. It walks the reader through the building of applications, but doesn't skimp on the concepts (indeed, the chapters are meant to alternate between "concepts" and "applications"). In some ways, the code examples make it a little difficult to jump around, since you are expected to build upon previous code. The web site provides code, however, so you can always grab that and use it to fill in the missing pieces.

For readers who wish to use this book as a tutorial, and to implement all of the examples (which is highly recommended), I suggest that you grab the Hugs interpreter and read the User's Guide while you're reading the first few chapters of The Haskell School of Expression. Hugs is very portable, free, and easy to use. It also has an interface with Emacs. Unfortunately, some of the example code has suffered from bit-rot, and certain things don't work out-of-the-box for X11-based systems. The bit-rot can be solved by using the "November 2002" version of Hugs. This is all explained on SOE's web page.

The Haskell School of Expression should be very effective for programmers who have experience in more traditional languages, and programmers with a Lisp background can probably move quickly through some of the early material. If you've never learned a functional language, I highly recommend Haskell: Since Haskell is purely functional (unlike Lisp), it will more or less prevent you from "cheating" by reverting to a non-functional style. In fact, if you've never really looked at functional programming languages, it may surprise you to learn that Haskell has no looping constructs or destructive assignment (that is, no x = x + 1). All of the tasks that you would accomplish through the use of loops are accomplished instead through recursion, or through higher-level abstractions upon recursion.

Since I was already comfortable with recursion when I started this book, it is hard for me to gauge how a reader who has never encountered recursion would find this book's explanation of the concept. The Haskell School of Expression introduces recursion early on, in section 1.4. It is used in examples throughout the book, and if you follow along with these examples, you will most certainly be using it a lot. The introduction seems natural enough to me, but I note that Hudak does not give the reader any extra insight or tricks to help them along. Not to worry, though; recursion is very natural in Haskell and the reader may not even notice that they are doing something a little tricky.

The use of multimedia was a lot of fun for me, and should quickly dispel the myth that IO is difficult in Haskell. For instance, Hudak has the reader drawing fractals by page 44, and throughout the book, the reader will be drawing shapes, playing music, and controlling animated robots.

Any book on Haskell must be appraised for its explanation of monads in general and IO specifically. Monads are a purely functional way to elegantly carry state across several computations (rather than passing state explicitly as a parameter to each function). They are a common stumbling block in learning Haskell, though in my opinion, their difficulty is over-hyped.

Since input and output cause side-effects, they are not purely functional, and don't fit nicely into a function-call and recursion structure. Haskell has therefore evolved a way to deal safely and logically with IO through the use of monads, which encapsulate mutable state. In order to perform IO in Haskell, one must use monads, but not necessarily understand them.

Some people find monads confusing; I've even heard a joke that you need a Ph.D. in computer science in order to perform IO in Haskell. This is clearly not true, and this book takes an approach which I whole-heartedly agree with. It gets the reader using monads and IO in chapter 3 without explaining them deeply until chapters 16 (IO) and 18 (monads). By the time you get there, if you have heard that monads are confusing, you might be inclined to say "how is this different from what we've been doing all along?" Over all, I was pleased with the explanation of monads, especially state monads in chapter 18, but I felt that the reader is not given enough exercises where they implement their own monads.

If you're worried that drawing shapes and playing music will not appeal to your mathematic side, you will be pleased by the focus on algebraic reasoning for shapes (section 8.3) and music (section 21.2), and a chapter on proof by induction (chapter 11).

After reading this book you will be prepared to take either of the two paths that Haskell is designed for: You can start writing useful and elegant tools, or you can dig into the fascinating programming language research going on. You will be prepared to approach arrows, a newer addition to Haskell which, like monads, have a deep relationship to category theory. Arrows are used extensively in some of the Yale Haskell group's recent work. You will see a lot of shared concepts between the animation in The Haskell School of Expression and Yale's "Functional Reactive Programming" framework, Yampa. If you like little languages, you'll appreciate how useful Haskell is for embedded domain-specific languages. It may be even more useful now that Template Haskell is in the works. Andrew Cooke described Purely Functional Data Structures as a great second book on functional programming. In my opinion, The Haskell School of Expression is the great first book you're looking for.

You can purchase Learning Functional Programming through Multimedia from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

prostoalex writes "Why are networked computing environments so insecure? You've heard the story before - early computers were not designed to work in the network environment, and even most software written later was designed to work on benevolent networks. As Bruce Schneier says in the preface to Building Secure Software: How to Break Code, 'We wouldn't have to spend so much time, money and effort on network security if we didn't have such bad software security.'" Read on for prostoalex's review of Exploiting Software, which aims to balance that situation somewhat. Exploiting Software: How to Break Code author Greg Hoglund, Gary McGraw pages 512 publisher Addison Wesley Professional rating 8 reviewer Alex Moskalyuk ISBN 0201786958 summary Techniques and software used to attack applications.

What kind of secure are you after? There are many published titles on the topic of software security are numerous, but most of them follow certain patterns. Building Secure Software by Viega and McGraw was mainly concerned with proper techniques and general software engineering mindset without going into specifics. Then there was Writing Secure Code , by Howard and LeBlanc, which provided concrete examples and showed the "right way" to do secure coding. I heard the title instantly became a required reading at world's largest software corporation. It's currently in its second edition.

Secure Programming Cookbook for C/C++ by Viega and Messier, was the hands-on title for those developing C/C++ application with security in mind, as the cookbook recipes generally gave examples of good code, with each chapter providing some general background information on the topic discussed (I reviewed it on Slashdot in September last year).

Just in case you were wondering, the list above wasn't just retrieved by a quick search at Amazon. My Master's degree, completed last summer, dealt with the topic of software security, and those are the titles I've read preparing to write the theoretical part.

From the other side With the variety of books on how to write secure software, and what techniques to use to make existing software more secure, there was a niche for a book targeted specifically to those who wanted to break software. Black hat or white hat, the network security experts always had titles like Hacking Exposed to give them an idea of what was available in terms of techniques and methodologies used out there. For software security most of the articles and books generally would tell you something in the terms "do not use strcpy(), as it introduces buffer overruns".

Great, so I won't use strcpy(), did it make my application more secure? Is it more or less hack-proof? What if I am a tester and required to play with this aspect of the application to ensure the application's security before the product ships? Theoretically hanging out at proper IRC rooms and getting lifetime Phrack and 2600 subscriptions should be enough to cover you at the beginning, however, the learning curve here leaves much to be desired, let alone the fact you will probably be kicked out of the IRC rooms for asking n00b questions. Another path would be to take an expensive training course by someone with a name in the industry, but the price tag for those generally leaves out self-learners and those operating on limited budgets, which adds up to about 99% of software engineers and testers out there.

Exploiting Software to the rescue.

Exploiting Software fills the void that existed in this market. Eight chapters take you through the basics and some advanced techniques of attacking software applications with the purpose of executing arbitrary code supplied by an attacker (you).

The book mainly deals with Windows applications for x86 platforms, and some knowledge of C/C++ and Win32 API is required to go through the example applications. To automate some processes and demonstrate possible attacks the authors use Perl, so knowledge of that would help the reader, too. Some chapters, (e.g. the buffer overflow one) show disassembler output, and while you're not expected to read x86 ASM code as if it were English, knowledge of how the registers work and how the subprocedure calls are handled on this Intel architecture are required. After all, if potential attackers know it, you better familiarize yourself with some low-level code, too.

While discussing various possible attacks, the authors post different attack patterns. The patterns themselves usually appear in gray textboxes and talk about the possible exploit in general terms. After that, a series of attack examples follow, with specific descriptions on what can be done, and how. For example, the attack pattern on page 165 is titled "Leverage executable code in non-executable files." The following attack example is "Executable fonts," and it talks how the font files are generally treated by the Windows systems (they are a special form of DLLs). Thus it's possible to embed some executable code into a font library you're creating, for which the authors provide an example in Microsoft Visual Studio.

What's cool is that all the attack patterns are listed in a separate table of contents (alas, not on the Web site table of contents, which just lists the chapters and subchapters), so you can browse to the attack pattern you decide to learn about, read some general info about it and then study specific examples. The examples themselves are not in the table of contents, which I think is a mistake, as it would make searching for possible patterns much easier. After all, how are you supposed to know that "Informix database file system" (p. 189) is under "Relative path traversal" pattern? Well, unless you know specifically that the line http://[Informix database host]/ifx/?LO=../../../etc/ is the one discussed in the example, you would have to either go through the index hoping no omissions were made, or read the chapter in its entirety.

One of the best chapters of the book, Reverse Engineering and Program Understanding, which provides a good introduction into techniques used throughout the book, is available online from Addison Wesley. By having a free chapter you already have 1/8th of the book, but don't think that the low number of chapters makes this 512-page title an introductory book.

Target Audience

Looks like there are two major audiences and reading patterns for this book: those wanting to fix their systems ASAP and thus using Exploiting Software as a reference, and those using it as a text book to learn about security. I've discussed the organization of the book above, and the reference types will probably be more interested in patterns and examples. For a casual reader (although casual readers wouldn't generally pick up a title with C++, Perl, ASM and hex dumps spread around the chapters) this is a book with great educational value, from two authors who have discovered numerous security vulnerabilities themselves.

Exploiting Software is not an easy title to read. Addison-Wesley shipped me the manuscript copy a month before it hit the bookshelves in its final version, and I found myself going through about two pages an hour. The authors bring up sometimes unfamiliar Win32 APIs and occasionally use ready-made tools available on the Web, so generally I found myself visiting MSDN and Google a lot to read through available documentation and download the latest version of the tools used. The book doesn't come with a CD. Some of the stuff, like inserting a malicious BGP packet to exploit a Cisco router (p. 281) is not really testable at home, and I have some reservations about verifying the example with my employer's routers.

The book is probably apt for 2nd or 3rd year computer science students and above. Besides the variety of languages that I mentioned above, you need to be familiar with the basics of Intel architecture, and generally be fluent with terminology like "buffer," "stack," "syscall," "rootkit," etc., as this is not an "Introduction to..." title. From my experience, you probably won't read it from page 1 to page 512 understanding everything perfectly, but for anyone interested in security and those making a career in software development it looks like a bookshelf must-have.

I interviewed Gary McGraw on the current state of software security, the relevance of the topic to the issues beyond C/C++ and improper buffer usage, and future directions in security. Network World magazine also ran an interview with the McGraw in which he talks about the reception of the book at the RSA Conference, whether the economics is right to invest in building secure systems, and whether his book does more harm by providing a compendium of known exploits.

Alex has written numerous reviews of other software and security titles. You can read more of his opinions at his Web site. You can purchase Exploiting Software: How to Break Code from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Raymond Lodato writes "For the past six years, I've been responsible for the installation, configuration, and maintenance of the firewalls at my company. I was surprised and annoyed at the caliber of documentation supplied by Check Point. Six years ago, you really needed a reseller with the appropriate expertise to teach you how to design and implement a firewall. A year or so later, I found Phoneboy's website (phoneboy.com). It was an oasis for someone drowning in the sea of confusing literature and advice. In the time since, I have frequently referred to Phoneboy's site, as well as his fw1-gurus mailing list, as an unsurpassed source of information." Read below for Lodato's review of Phoneboy's recently updated book on the subject. Essential Check Point Firewall-1 NG - An Installation, Configuration, and Troubleshooting Guide author Dameon D. Welch-Abernathy pages 647 publisher Addison-Wesley rating 9/10 reviewer Raymond Lodato (rlodato AT yahoo DOT com) ISBN 0321180615 summary An excellent guide to the ins and outs of configuring Check Point's FireWall-1 NG product, with a guide to the foundations of a good security policy. A 'must read' for any Check Point firewall administrator.

Phoneboy (nee Dameon Welch-Abernathy) has proven himself to be extremely knowledgeable about Check Point's FireWall-1 product. In October of 2001, he produced a book (Essential Check Point FireWall-1, Addison-Wesley, 2001) that helped to clarify the vast amount of information collected over the years through the mailing list and the website. Shortly after the book was published, Check Point saw fit to render it almost obsolete by releasing FireWall-1 NG. The new version of Check Point's flagship product was so different, you almost had to start from scratch to understand it. Dameon has taken the necessary next step and updated his original book. The new book, Essential Check Point FireWall-1 NG, (Addison-Wesley, 2004) now covers all existing versions of NG, up to and including NG with Application Intelligence (NGAI).

When you first open the book and look at the Contents pages, two things will strike you. The first is that the Contents page starts with "Frequently Asked Questions." Anyone who has spent any time on technical websites knows that Frequently Asked Questions (or FAQs) are the first place to look to gather the nugget(s) of wisdom you need. The fact that Dameon has included a large list of FAQs in the book makes it valuable for quickly addressing the typical problems and questions an administrator faces. The second thing you will note is that he does not start describing anything about FireWall-1 itself until late into Chapter 2. He takes the time to lay the foundation of what a firewall is, as well as what a good security policy is, and why it's so important to get one and get it right.

As I read through the book, I was pleased to see that Dameon followed one of the cardinal principles of good presentation: tell them what you're going to say, say it, then tell them what you said. Each chapter outlines what you will know by the end, teaches you what you need to know, then summarizes it. Dameon writes in a style I would call clear but not condescending. It takes someone who not only knows his subject well, but understands his audience well, to walk the fine line between the two. Dameon shows his chops by treading that line like a tightrope walker.

Each chapter contains carefully organized information with numerous figures and screen shots interspersed, to keep the text understandable. Starting in Chapter 4, Dameon also includes selected FAQs culled from the many available on his website. I found this much more valuable than collecting them at the end of the book in one gigantic haystack that you needed to search for that one precious needle. Later chapters include sample configurations to clarify the concepts just described. This makes Essential Check Point FireWall-1 NG useful as a teaching resource, as well as a general reference to the product.

While the chapters in the book follow a logical progression, each building on the prior information, Dameon made sure that most chapters (and even sections within the chapters) could stand alone. This means you can pick and choose what you want to read. For example, if you needed to focus on FireWall-1 on IPSO, you don't necessarily have to worry about what was written about Solaris. The information on IPSO would repeat enough information that you wouldn't have to refer to previous pages. Even so, Dameon provides back references when repeating the information would be too cumbersome.

I did notice that Dameon varied the amount of detail used throughout the book. Sometimes he uses a high-level approach, and sometimes he goes into excruciating detail. Unfortunately there were a number of places I wanted him to provide more detail, only to have him skim over the treetops. While he does explain up front that this book was supposed to cover the essential information, covering some areas in detail just whets your appetite for that same amount of detail in all areas.

One other quibble I have revolves around the figures used in his examples. It becomes obvious that this book evolved over a period of time (I believe he took around a year to get this edition put together). Some figures apparently came from an earlier version of the book, as the text referred to something else. One example occurs in Chapter 8 (User Authentication). Dameon's sample configurations are written in a "follow-me" style. One sample configuration has the text "Next, create the group WebAdmins and add bob and dan to this group." If you followed his directions and then referred to the sample rule base in the figure on the next page, you would see that the group is named DMZAdmins instead of WebAdmins. (And the specs given for the same sample configuration specify that S/Key will be used, yet the figure showing the Authentication tab clearly has S/Key un-checked.) Little inconsistencies like this should have been picked up on the proofreading. Their existence mars an otherwise excellent book.

Overall, Essential Check Point FireWall-1 NG is aptly named: essential. If you are responsible for the care and feeding of Check Point's FireWall-1 software on any platform, you need to get and read this book. It's definitely going to stay within arm's reach on my desk.

You can purchase Essential Check Point Firewall-1 NG from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

honestpuck writes "As titles go "Google, Amazon, and Beyond" sounds to me like Buzz Lightyear's latest slogan, but it's actually quite a good book about writing software to consume and provide web services." Read on for honestpuck's review of the book -- it sounds useful for developers on both sides of a web-service transaction, but honestpuck cautions that its value varies with your attachment to Java. Google, Amazon, and Beyond author Alexander Nakhimovsky and Tom Myers pages 314 publisher Apress rating 6 for most, 8 for Java programmers reviewer Tony Williams ISBN 1590591313 summary Good guide to web services for Java programmers

The first two chapters are introductory material, though the authors quickly introduce some code with JavaScript routines to talk to both Google and Amazon. The second of them does a good job explaining the intricacies of DOM and how you use it to build a web page in Java. Then the authors get down to some serious work at using Java, including stand-alone applications and applets, to access web services.

They move fast throughout the book; this is not one to read quickly or without ready access to a computer. That said, the writing is good; the text is understandable and all the code is well explained.

The book covers a wide gamut of techniques and technologies, including SOAP and REST on the query side, and XSLT and XPath on the output side.

Then the book moves on to instructions for offering your own services. This part of the book starts off with WebDAV using Tomcat, though there is a short digression into Java Server Pages before really getting down to the nitty gritty. Finally the book shows how to use WSDL and Axis to easily create full web applications.

You can see that this volume covers a lot of territory. This breadth may well be the book's largest flaw; its wide reach means no topic gets a really deep coverage and a number of topics do not get the coverage they deserve. Indeed I would have to say that only a much better Java programmer than I would get full value from this volume -- there were parts where the authors lost me entirely and it took an effort to get back my understanding, occasionally resorting to a Java manual.

The publishers have a page for the book that has an example chapter, table of contents, index and source code. The example chapter, 4, details how to build a SOAP server using Java and provides an excellent example for the book. If you're a little unsure of your Java skills, take a look at this chapter and see if you can easily understand the code and explanation. If you can, then this volume should have no surprises for you.

It should be said that nothing about the book's cover tells you how much of it relies on Java, though a good read of the table of contents makes it obvious. I would have personally preferred a book that was more general in the programming language it used, covering more of the tactics and methods rather than examining specific code. If, on the other hand, you are an experienced Java programmer looking for a book on programming web services in that language, then this is an excellent volume.

You can purchase Google, Amazon, and Beyond from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

norburym writes with a review of Wicked Cool Shell Scripts - 101 Scripts for Linux, Mac OS X, and UNIX Systems. "This incredibly fun book (really!), written by Dave Taylor, a veteran UNIX, Solaris and Mac OS X author, is chock full of 101 scripts to customize the UNIX (Bourne) shell." Read on for the rest. Wicked Cool Shell Scripts - 101 Scripts for Linux, Mac OS X, and UNIX Systems author Dave Taylor pages 368 publisher No Starch Press rating 10 reviewer Mary Norbury-Glaser ISBN 1593270127 summary 101 Scripts for Linux, Mac OS X, and UNIX Systems

Chapters are divided into an array of topics sure to catch the attention of any UNIX based system user: The Missing Code Library, Improving on User Commands, Creating Utilities, Tweaking Unix, System Administration: Managing Users, System Administration: System Maintenance, Web and Internet Users, Webmaster Hacks, Web and Internet Administration, Internet Server Administration, Mac OS X Scripts, and Shell Script Fun and Games.

In true "cookbook" fashion, each hack is numbered and divided into The Code, How It Works, Running the Script, The Results and Hacking the Script. Throughout, the author clearly describes the syntax and functionality of each script, often with additional notes in How It Works detailing the syntax process and interesting asides. But Hacking the Script is what gives Wicked Cool Shell Scripts true value; where applicable, the author uses this section to describe script modifications to achieve a variety of alternative real world, practical results. This additional section alone easily triples the total number of scripts the reader is exposed to.

This book enables the reader to get "up close and personal" with their UNIX based system and explore the possibilities afforded by becoming intimate with the command line interface. The reader will find themselves easily propelled into the world of scripting, thanks entirely to Dave Taylor's ability to take what some might describe as a fairly dry topic and translate it into a logical and user friendly construct. Just reading through the table of contents is inspiring and intriguing; did you know you could write a script to retrieve movie info from IMDb? or track the value of your stock portfolio? or that you can use a very simple script to check spelling on your web pages?

Sysadmins and webmasters will find this book fundamentally critical to day-to-day operations; there are dozens of invaluable, customizable scripts highlighted in this book to enable professionals to save time and add simple, elegant solutions to annoying issues in their work environment. User account management, rotating log files, cron scripts, web page tweaks, apache passwords, synchronizing via ftp, etc. are all eminently useful and tweakable.

Geeky home users will discover they can use these scripts to work with files and directories, create spell-checking utilities, calculate loan payments, create summary listings of their iTunes libraries, and of course, play games. Many of the sysadmin scripts would also be of interest to the power user: analyzing disk usage, killing processes by name and backing up directories, to name a few. Both types of users will find this book inspiring and truly fun!

One of the secret pleasures of a technical book reviewer is finding those wonky bits of code that suffer from misplaced or missing punctuation, misspelled words and other basic typographic errors inherent in the book publishing process. I randomly selected many of these scripts to try out in the process of doing this review and...dang, haven't found any errata yet. But be sure to check out the errata page on Dave Taylor's web site for any that more astute readers may find (there were none, as of this writing).

Also be sure to take a closer look at Dave's shell script library, which lists additional scripts that didn't make the cut for the book. As convenient as it is to download the entire script library, I would like to stress the value of buying the book, which will provide you with invaluable instruction and guidance in understanding the syntax of the scripts and it also illustrates how making small but significant tweaks can modify the output to match your specific needs.

(A special nod of appreciation to Dave Taylor's Tintin references!)

You can purchase Wicked Cool Shell Scripts - 101 Scripts for Linux, Mac OS X, and UNIX Systems from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Bombcar writes "Anyone who has used Microsoft products in the last ten years has used the SMB protocol (now known as CIFS). Some have become experts in the usage of Windows file sharing, Samba, and more. We know that there can be a 15 minute delay before new machines appear in 'Network Neighborhood'. We've read the Official Samba 3 book, and follow the Samba mailing list once in a while, perhaps even answering questions. But there is a limit to the knowledge given by these sources." Read on for Bombcar's review of Implementing CIFS from Prentice Hall. Implementing CIFS author Christopher R. Hertel pages 642 publisher Prentice Hall rating 8 of 10 reviewer Tom Dickson ISBN 013047116X summary In-depth (but not too deep) coverage of the CIFS/SMB protocol

It is one thing to be able to use Samba, Windows, and the Common Internet File System (CIFS) protocol. It is another thing entirely to understand CIFS with sufficient depth to begin coding using it. This is where Christopher Hertel's Implementing CIFS begins.

This thick book (over 600 pages) begins with a history of NetBIOS in the DOS era. It quickly progresses to NetBIOS over TCP/IP (which evolved into the current CIFS protocol). Hertel documents the beginnings of quirks that will last throughout the life of the protocol. There is an RFC that was proposed in 1987, but many vendors have added extensions to this. (It might surprise you to learn that Samba has added extensions, which are covered in Chapter 24).

After the basic overview, he quickly dives into real coding of an actual (though simple) implementation. This will be his style for the rest of the book (except for humorous asides now and then). An aspect of the protocol, such as Name Resolution, will be explained in some detail, and then expounded in actual code (and in a few cases pseudocode).

The detail is good but not overwhelming. Some people (with names like Jerry Carter or Andrew Tridgell) will want more depth than this book provides, but for with a protocol as varied as CIFS, choices have to be made. As the Samba website mentions, this book is written in "Geekish." The book covers aspects of older and newer SMB/CIFS implementations, including a description of the NTLM2 challenge/auth system.

One thing that should be noted is that the code examples work, but as the author points out, they usually have little or no error handling. This is common to many books, but it is something to remember.

Now, should you get this book? If you're just a user, you probably don't need it. But if you've ever wished you could understand the Samba technical mailing list, or wanted to know why it takes up to 15 minutes to see a new machine, then you'll enjoy this book. If you want to utilize CIFS in any manner (even if just implementing Samba for clients), I'd highly recommend reading this. It will help you to understand what is going on on your network, even if you're not writing the code yourself. And if you want to be a Samba coder, it is required reading.

What didn't I like? I first read the book in an airport, and found that it relies heavily on having access to a computer. I would have preferred more explanations of code fragments than was given. However, this is a minor issue; most people who are implementing CIFS will be using a computer! I was also left with a desire for more information, but the large Appendix D along with many sources recommended provide for further study.

As a bonus, Appendix A tells you how to make a good cup of Earl Grey tea! That alone to some would be worth the price of admission.

You can purchase Implementing CIFS from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Peter Wayner writes with a review of O'Reilly's Security Warrior: "Close the doors and they come in the windows. Bar the windows and they slip through some cracks in the foundation. Seal those up and the find another way in through the door. Computer security is an odd pursuit because it's just not possible to have a strong, theory of everything when cracks can appear anywhere. Into this field comes Security Warrior, a book on the topic with a wide ranging collection of tidbits and suggestions on sealing as many holes as you can find." Read on for the rest. Security Warrior author Cyrus Peikari and Anton Chuvakin pages 531 publisher O'Reilly rating 7 reviewer Peter Wayner ISBN 0596005458 summary Not a deep approach to security, but a great bag of tricks every sysadmin should have at hand.

The book comes lightly packaged in a metaphor about the training of samurai. A security warrior, it is said, must avoid a "superficial study of the subject" because that leads to a "deterioration of the samurai spirit." To avoid this, the authors plunge deeply into a wide variety of ways that attackers might break into your system. The book is meant to help you "know your enemy" and "see through an attacker's eyes."

This chestbeating fluff disappears pretty quickly because the authors dive into reading assembly code in the first chapter and start talking about the registers of the CPU by page 4. The rest of the first part of the book explores reverse engineering software by reading assembly dumps and using good tools to decipher it.

After poking around in binary code, they turn to the bits floating around the network. Chapters 6 through 10 explore how to sit on one end of the Internet and pry your way into another computer. Chapters 11 through 17 dive deeper into the specific defenses of platforms like UNIX, Windows, SOAP and SQL. The rest of the book, Chapters 18 through 22, explore how to figure out just what the attackers may be doing by setting up honeypots and log analysis tools.

Covering all of these topics in 531 pages is clearly not possible and the book reads more like a survey or a catalog of what can go wrong. If you use PHP, for instance, as a frontend to your database, you might want to be sure that some "script kiddie" won't slip in some extra SQL in the form fields. Each topic isn't built up from some bedrock foundation with perfect mathematical pedagogy, it's just defined as a list of bad things that you should avoid doing.

The authors seem to be aware of how this might be misinterpreted. There are many good tricks in the book and it wouldn't be hard to rename it Al K Da's 1337 Haxor Tips . So the authors stress how learning about the enemy is the only way to defeat the hordes.

I think the problem is deeper and more philosophical. There's no way to prove a negative. There are no good mathematical tools that make it easy to prove statements like P!=NP or big numbers can't be factored quickly. In a larger sense, it's not really possible to prove that someone can't break into a system. A more traditional, ground-up approach to the topic can offer some assurances, but books like this one are always necessary. Anyone doing battle against unknowable and unpredictable adversaries must look between the cracks.

If you look at it this way, the book is a good collection of tips and hints that will help someone keep their network a bit more secure. It doesn't provide a deep, elegant and rigorous explication of the topic, but I don't think that is possible. It's a great collection of tricks that should be part of a good warrior's training.

Peter Wayner is the author of Translucent Databases and Policing Online Games . You can purchase Security Warrior from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

andrew cooke writes "A while ago I read the comments following a Slashdot book review. Someone had posted a request for books that covered a wider range of languages than Java, C, Python, etc. Well, I thought, why not review Okasaki's Purely Functional Data Structures? It's a classic from the underworld of functional programming - recognised as the standard reference, yet clear enough to work as an introduction to the subject for anyone with a basic functional programming background. Of course, some readers won't know what functional programming is, or what is special about pure data structures. So I hope that this review can also serve as something of an introduction to the languages that I (a software engineer paid to work with Java, C, Python, etc) choose to use in my spare time, just for the joy of coding." Read on for the rest; even if you're not planning to give up C or Perl, there are links here worth exploring. Purely Functional Data Structures author Chris Okasaki pages 220 publisher Cambridge University Press rating 8/10 reviewer Andrew Cooke ISBN 0521663504 summary Functional programming for grown-ups.

In Okasaki's introduction he says that the "[...] benefits of functional languages are well known, but still the vast majority of programs are written in imperative languages such as C. This apparent contradiction is easily explained by the fact that functional languages have historically been slower than their more traditional cousins, but this gap is narrowing."

Indeed, OCaml has a reputation for being "as fast as C," yet it contains automatic memory management and supports object-oriented, as well as functional, programming. It's also probably the most widely used functional language outside academia (except perhaps Lisp/Scheme).

I mention OCaml not just because it's fast, free and popular, but because Okasaki uses a related language - ML - in his book. The ML family of languages are the standard strict, functional languages (Standard ML of New Jersey is perhaps the reference implementation but see also standardml.org). Okasaki also includes an appendix with examples in Haskell, which is the standard lazy functional language.

The difference between lazy and strict languages is the order in which code is evaluated. Most languages are strict. Unlike most languages, Haskell only evaluates something when it is absolutely necessary. Each parameter to a function, for example, is passed as a "thunk" of code, not a value. If the value is not required inside the function, the parameter is left unused; if it is required (say as part of a result that needs to be displayed) then the thunk is evaluated. This evaluation may trigger a whole slew of evaluations of functions that "should" have been called earlier (from a Java programmer's point of view).

Laziness is both good and bad. The bad side is obvious: the order in which code is executed my be very different from the order in which the program was written and some serious book-keeping is necessary in the compiler to juggle the thunks of code and their final values. The reordering of code could cause mayhem for IO operations, for example (in practice, of course, Haskell includes a solution to this problem).

The good side is that laziness can help make programs more efficient and, while the definition of ML doesn't include laziness, individual ML implementations -- including OCaml and SML/NJ -- include it as an extra.

Much of Purely Functional Data Structures (the second of three parts) focuses on how to use laziness to make data structures efficient. Lazy evaluation allows book-keeping actions to be postponed, for example, so that the cost of maintaining the data structure in an efficient form can be averaged across several read/write operations (improving worst case limits - avoiding a very slow response if the data happen to be in a "bad" order).

An understanding of how the efficiency of algorithms is rated (the big-O notation) is one piece of knowledge that this book does assume, along with a basic grasp of what Stacks, Queues, Trees, etc, are.

This lazy boost in efficiency is needed because, even though functional languages may be getting faster, it's not always possible for them to implement the efficient algorithms used in imperative (non-functional) programming.

But I'm getting ahead of myself, because I haven't described what a functional language is, or why it is useful. These are the topics of the first part of the book, which explains how functional languages, which make it impossible to change variable values by direct assignment, support persistent data structures. This section is fairly brief, and while it's a good refresher course for someone who's not had to worry about such things since studying at university, it's not sufficient as an initial introduction to functional programming in general.

There's a good explanation of functional programming in the Wikipedia, but, in all honesty, I don't see how anyone can really "get it" without writing functional code (just as I, at least, couldn't understand how OOP worked until I wrote code that used objects).

So forgive me for not telling you why functional programming is good (This paper is one famous attempt), but perhaps a better question to focus on is "Why should you spend the time to investigate this?" The best answer I can give is that it leads to a whole new way of thinking about programming. Describing functional programming as "excluding assignment to variables" doesn't do justice to the consequences of such a profound change (one I found almost unimaginable - how can you program without loop counters, for example?).

There's a practical side to all this too - learning new ways of thinking about programs makes you a better programmer. This ties in closely with the final part of Okasaki's book, which explores a few fairly esoteric approaches to data structures. Who would have thought that you can design data structures that parallel the way in which you represent numbers? Some of this is pretty heavy going - I can't say I understood it all, but I'm taking this book with me on holiday (it's slim - just over 200 pages) and I'll be bending my brain around some of the points in the last few chapters as I lie in the sun (here in the southern hemisphere it's late summer).

So just who would benefit from this book? It seems to me that it's most valuable as a second book on functional programming. There are a bunch of texts (and online guides) that can get you started in functional programming. This one goes further. It shows how to exploit the features of functional languages to solve real problems in applied computing. Admittedly, they are problems that have already been solved in imperative languages, but you might find that you, too, come to enjoy those famous benefits of functional languages. The algorithms in this book let you enjoy those benefits without paying the price of inefficiency.

Andrew Cooke last reviewed for Slashdot The Aardvark is Ready for War . You can purchase Purely Functional Data Structures from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

simoniker writes "Alan Moore is probably best known as the writer of some of the best graphic novels of all time - Watchmen, From Hell, and The League Of Extraordinary Gentlemen, to name but three. But he's also written a prose novel - a sprawling, epoch-spanning paean to his home town of Northampton, England, in the form of Voice Of The Fire, a book originally released in the UK in 1996 in paperback only, and now debuting in the States via a revamped, hardcover version from Top Shelf Productions. So with twelve separate stories and twelve major characters in this 'magical history tour' (as Neil Gaiman describes it in the introduction) spanning six thousand years, how does the book measure up to the seminal comics canon Moore has established?" Read on for the rest of simoniker's review. Voice Of The Fire author Alan Moore pages 336 publisher Top Shelf Productions rating 8/10 reviewer Simoniker ISBN 1891830449 summary In a story full of lust, madness, and ecstasy, we meet twelve distinctive characters that lived in the same region of central England in the span of six thousand years.

There's no question about it - this book is formidable. It is formidable in its complexity, formidable in the connective leaps it expects you to make between stories and eras, and most of all, it can be formidable in its prose. Before I even read Voice Of The Fire, I'd heard that the first chapter of the book is enough to put many casual readers off, and that's not far wrong. The story of a cave-boy called Hob -- confused, immature, possibly mentally deficient, and alone in a world of freedom, love, and, potentially, disaster -- is written in intentionally limited language that the less sharp members of mankind might be imagined to use in 4000 BC. It's not an easy read; this segment is a struggle to decode at times, but the rewards are significant, because the emotions are powerful, and the story strong.

The novel's twelve stories are woven together, but only loosely. Sometimes consecutive stories interact with each other by way of common locations, characters, or themes, as historical figures tell their stories in the first-person, one by one, from the aforementioned Hob to an inevitable conclusion in the present day. But generally, the stories don't actually interact. Some of the most memorable tales, such as the first-person tale of a severed head on a pike circa 1607, or the treacherous dealings of a lecherous court judge from centuries past, have absolutely nothing in common except for the general geographical location. But they share exceptional writing, a self-contained message, and an odd sense of foreboding hovering over the entire proceedings, like someone or something is watching over every single sin committed.

And, let it be said, there are a surfeit of sins -- violence, and senseless murder, and lust, and witchcraft, and plenty left over. But that's how real history is -- bloody. Or, at least, that's how Moore wants us to believe history is, and there's clearly been significant research into many of the real-life historical figures whose lives are embroidered and colorized in Voice of the Fire. There's no doubt that some passages are tricky to digest, particularly those with odd language such as 'The Sun Looks Pale Upon The Wall,' the haunting 1841-set meanderings of another poor citizen who's not quite there. However, if you can wade through the occasional story featuring difficult prose, dense layout and strange language, the rewards can be significant. Plus, the gorgeous new full-page color illustrations/photos, courtesy Jose Villarrubia, add a little visceral flavor to the mix no matter how dense the prose.

Comparisons in terms of genre or content are tricky, though, among the stories that make up this book. What Moore definitely shares with the writer of the introduction to this new version, Neil Gaiman, is a sense of myth, of half-remembered deities and supernatural forces existing in the real world, as Gaiman depicts in American Gods . But Moore's supernatural forces are much more shamanic, much darker, and largely less substantial, except for a truly scary vision unearthed from a medieval burial chamber.

As for Moore's previous work, in as much as Promethea is a set of musings on his faith in the mystical, Voice Of The Fire gives those mystical feelings a more sinister edge and spreads them out over centuries. And it might be said that From Hell contains some similar ideas about the mystical significance of geography. But Voice Of The Fire draws no easy comparison even to Moore's own work -- being in a different medium, and focusing on the place he's lived all his life, it's much more personal than much of his other material, almost as if the dark places of his home town's past are being passed down to him.

Moore spent five years writing this book, and even refers to that torturous stretch in the final chapter, which is written by him in the first-person, in which he ties his experiences of Northampton's history to the stories. A daring move, to be sure, and one that Moore himself admits puts him close to the edge, as he muses:

'There are some weak points on the borderlines of fact and fabrication, crossing where the veil between what is and what is not rends easily. ... Walk through the walls into the landscape of the words, become one more first-person character within the narrative's bizarre procession... Obviously, this is a course of action not without its dangers... always the risk of a surprise ending with the ticket to St. Andrew's Mental Hospital.'

But what is Voice Of The Fire really about? Well, the thirteenth character in the novel, and almost certainly the most important, is the town of Northampton itself, looming large over every single character's experience. This is something that Moore has dealt with before -- there's a moment in the massive, monochrome, mystical From Hell where there's an odd 'flash forward' moment - contemporary office buildings intruding on the goings-on of 19th Century London. The same idea of geography subsuming history is true for Voice Of The Fire -- that the people are not a permanent fixture; the location is the only sure thing. Time layers burial ground on murder site on shiny new office development until there's such an odd mixture of old, new, and indescribable that some kind of sinister magic is created.

[There's plenty more about Moore at the comprehensive Alan Moore Fan Site, and the Alan Moore Yahoo group is both knowledgeable and friendly.]

You can purchase Voice of the Fire from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

honestpuck writes "After many years bashing my head against sendmail in all it's gory details I had amassed a fair amount of knowledge and documentation on handling the Mail Transfer Agent (MTA) in Linux and Mac OS X. This caused a fair amount of teeth gnashing when I discovered it had gone the way of all flesh in OS X Panther to be replaced with Postfix." To un-gnash his teeth, honestpuck used Kyle D. Dent's Postfix: The Definitive Guide (published by O'Reilly); read on for his review of the book. Postfix: The Definitive Guide author Kyle D. Dent pages 260 publisher O'Reilly and Associates rating 8/10 - Excellent book, a little thin on details in a few places reviewer Tony Williams ISBN 0596002122 summary An excellent guide to installing, configuring and running Postfix

Fortunately, my first needs were simple and I came to realise that Postfix was a much easier system to install and maintain. Now that my needs are more complex, I was glad when this book hit my desk at exactly the same time as I started upgrading the corporate servers from Mac OS 9 to OS X Server.

Postfix: The Definitive Guide seems to fit the bill. It is a well-written and well-constructed guide to mail systems in general and Postfix in particular. (Oh, and speaking of definitive, could someone at O'Reilly provide a definitive answer to both reviewers and their own editors as to that colon? This is the second 'Definitive Guide' I've reviewed in as many months, and they are sprinkled with instances of each book's title, sometimes including that colon, sometimes leaving it out.)

The book starts with a good overview of the underlying technology in Chapters 1 and 2. I can't blame Dent for my slight confusion in the section on addresses and headers - having RFC822 superseded by RFC2822 was just a little too much coincidence for this particular "bear of little brain." He then follows it with a chapter discussing Postfix's architecture, important since Postfix uses a much more modular approach than the sendmail monolith, with each part of the mail handling process a different executable and the single queue turned into five.

Once the background is well covered, Dent then gets onto the nitty-gritty of configuring and administering Postfix. He has certainly covered everything I needed, including spam handling, multiple domains, relaying, SASL authentication and using LDAP. Once I'd finished grokking all that, and getting it integrated into my servers, I had a corporate email system up in three sites that replaced and improved upon a couple of thousand dollars worth of proprietary dreck. Happy is an understatement.

Dent's writing is sometimes a little patchy, though never bad. The technical detail does seem overpowering in places, though, and I occasionally found myself reading a section through more than once with a configuration file open in front of me. There are certainly spots where a little more hand holding and care with the writing would have been appreciated. (If you are a little more cognizant of the interstices of mail systems then you may not have the same problem.)

I did, however, appreciate the appendices enormously. The four appendices cover configuration parameters, Postfix commands, installation, and an FAQ. My system came with Postfix compiled and installed just as I required it so I didn't get a chance to thoroughly test out Dent's installation procedure (though it looks good); the other three continue to be useful.

If you want to have a look for yourself, then the usual O'Reilly page is complete with a table of contents and index, but this time no example chapter is provided (how come, O'Reilly?). You can also get an expanded version of the FAQ in Appendix 4 from Dent's website. A better example of Dent's writing style is an excellent article on troubleshooting with Postfix logs at O'Reilly's Onlamp.com.

This is an excellent book, Dent has explained the underlying methodology and use of Postfix well, taken the reader through all aspects of this MTA system and explained both the why and the how. I would recommend this book (and, as a result Postfix) to anyone looking for an MTA and a guide to configuring and running it.

You can purchase Postfix: The Definitive Guide from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

PHPee (Rob Maeder) writes "Scott Fullam's Hardware Hacking Projects for Geeks is an excellent book outlining all you need to know to get started in the wonderful world of hardware hacking. With step-by-step guides to fifteen useful, amusing and off the wall projects, even a novice hacker can be up and running with some basic hacks in a few hours. The book demonstrates various ways consumer electronics can be modified to do things they were never intended to do, and shows you just how much fun voiding your warranty can be." (We mentioned this book yesterday, too.) Read on for PHPee's review. Hardware Hacking Projects for Geeks author Scott Fullam pages 348 publisher O'Reilly rating 8 reviewer PHPee ISBN 0596003145 summary How to get started in exploiting the hidden capabilities in hardware you may already own.

Fullam takes the reader from the very basics of hardware hacking and quickly gets up to speed with some fun and interesting hacks. Projects start out easy and increase in complexity and cost as the book progresses. Hardware Hacking covers many popular hacks we've all seen before, such as the "Macquarium" (Mac Aquarium), a web-enabled coffee machine, and the Blinkenlights building-sized display.

The book is divided into two main parts, the first covering basic hacks, and the second covering more advanced hacks.

Part One:
Starting with the basics, Fullam takes the reader through a crash course in electronics, covering concepts like soldering, using a voltmeter, identifying various electronic components and reading schematics. This section of the book is by no means a replacement for a course in electrical engineering, but it is definitely a solid primer for those of us who weren't born with a soldering iron in our hands. If you've never played with electronics before and don't know the difference between a resistor and a capacitor, this section should get you up to speed fairly quickly.

After the brief basics lesson, the next chapter dives right in to the first project, which is a portable laptop power supply made with a pile of D-cell batteries, a battery holder and some wire. This project is very simple and requires no soldering at all, yet it gives the reader a quick and easy way to make something useful with very little investment in time or money.

Each of the projects is presented in a well-organized manner, starting out with a brief summary and some background information about where the hack originated. A list of necessary tools and materials is also given, followed by a project overview, outlining the major tasks required to get the project completed. Each project outline gives estimates for the cost range, time required and difficulty level for the hack.

After the introductory stuff is out of the way, step-by-step instructions are given on how to assemble, modify or hack the device in question. The instructions are easy to follow and are complete with images or illustrations where appropriate. Many pages contain sidebars that contain additional information related to the project, such as more photos, hints and tips, and links to relevant websites. These sidebars really help to fill in any gaps that may be present in the main text.

At the end of each chapter, Fullam has an "extensions" section, where he suggests ways the hacks can be hacked further, to improve upon the design or alter them to offer more or different functionality. This is one point where the book really shines, advocating the true spirit of hacking and encouraging creativity and experimentation whenever possible throughout the book.

At the end of each chapter is a "Bill of Materials" and schematics for the hack. The bill of materials outlines in great detail all tools and hardware required for the project, including approximate costs as well as sources where they can be purchased.

Some of the highlights in the first section of the book include the "Macquarium," a water-based PC cooling system, and the infamous Furby hack. The Macintosh mod teaches some valuable lessons on using a Dremel tool and working with Plexiglas, which are great skills any budding case modder would want to have. The water-based PC cooling project is one of the more useful hacks presented in the book, showing the reader how to create an inexpensive but effective means to cool down an overclocked CPU. And hacking the Furby to give it a new vocabulary is... well, definitely a great topic for conversation if nothing else. If you have to ask why someone would do such a thing, you wouldn't understand the answer.

Part Two:
Part Two of the book starts off with another more advanced lesson in electronics. It delves into more detail, describing different types of resistors, capacitors and connectors. It also introduces transistors, looking at integrated circuits and surface-mount components as well. One thing I found particularly useful was the section explaining how to read and interpret manufacturers' data sheets for integrated circuits.

The advanced hacks featured in Part Two of Hardware Hacking are a little more exciting than those featured in the first half of the book, but are definitely more involved. The section starts off with a chapter on building a PC-based PVR, using Mandrake Linux. Sample code is included to create shell scripts for a simple, text-based interface, although Fullam does briefly mention some of the more popular GUI-based PVR software available, such as Freevo and MythTV.

Another great hack featured in the advanced section is the "Building-Size Display" hack, reminiscent of Blinkenlights. The chapter starts off with instructions on how to build a display matrix on a much smaller scale, using a series of ultra bright LEDs, but later shows how the project can be expanded to create a 12-story display using an entire building.

Some other mentionable hacks in the advanced chapters include a cubicle intrusion-detection system, an Internet-enabled toaster and coffee maker, and a remote object tracker. These projects provide instructions on how to use more advanced components such as photodiodes, lasers, GPS receivers and microcontrollers (such as the BasicStamp2, in particular).

Two other noteworthy projects in Part Two include a MAME cabinet and a wearable computer.

Plans for the MAME cabinet are very well done, taking the reader through cutting MDF, building the cabinet, installing the software and interfacing the controls to his PC. This chapter goes into great detail, even covering things like creating a monitor bezel and a backlit marquee, and using T-molding for that authentic arcade machine look.

The wearable computer hack is very interesting, covering a wide range of concepts I would never have considered. Fullam gives ideas on what to use for a head-mounted display (HMD), what types of motherboards and CPUs work best, and looks at various power sources, including batteries, solar panels and different generators. The chapter also presents ideas for input devices, such as keyboards and mice, but also speech recognition systems, cameras and GPS receivers. At the end of the chapter, there is an extensive list of websites related to wearable computer projects, offering much more reading to the interested hacker.

The appendixes, while quite brief, do offer more information on topics like creating and editing schematics, using microcontrollers and using different power sources. There is also a list of resources for further reading and a short list of parts suppliers.

Hardware Hacking also has an accompanying website, where readers can download all of the images, illustrations and schematics from the book. The files are available in EPS, PDF and TIFF formats, although they are all gzipped, and are not readily viewable without downloading and extracting first. The website supposedly has code downloads as well, but the links are broken as of this writing, so you'll be stuck typing in code from the book until the site is fixed.

Overall Thoughts
Overall, I was very impressed with this book. Fullam has given the geek community a valuable resource that will provide inspiration for aspiring and veteran hackers alike. It covers many projects that I have personally wanted to build or learn more about, and presents concepts that would be of interest to many fellow Slashdotters.

The only things preventing me from giving this book a 10 are the aforementioned issues with the accompanying website (which I'm sure will be fixed soon) and the quality of some of the photos. Most of the photographs in the book are crisp and clear, but some are rather grainy or pixelated, as if they were enlarged from a website image. Fullam does make mention of the image quality, stating that many photos actually were taken from the original Web sources, and "the clarity of the photograph suffers in print." It's a small point, but definitely noticeable in certain sections of the book. However, as mentioned, the images are available online, and often do look better on a monitor in full color, as opposed to the black and white images in the book.

I highly recommend Hardware Hacking Projects for Geeks to anyone with an interest in those fun projects that only nerds can understand.

You can purchase Hardware Hacking Projects for Geeks from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

dwheeler writes "It's not often you find a classic, but I think I've found a new classic for software and computer hardware developers. It's David J. Agan's Debugging: The 9 Indispensable Rules for Finding Even the Most Elusive Software and Hardware Problems." Read on for the rest. Debugging: The 9 Indispensable Rules for Finding Even the Most Elusive Software and Hardware Problems author David J. Agans pages 192 publisher Amacom rating 9 reviewer David A. Wheeler ISBN 0814471684 summary A classic book on debugging principles

Debugging explains the fundamentals of finding and fixing bugs (once a bug has been detected), rather than any particular technology. It's best for developers who are novices or who are only moderately experienced, but even old pros will find helpful reminders of things they know they should do but forget in the rush of the moment. This book will help you fix those inevitable bugs, particularly if you're not a pro at debugging. It's hard to bottle experience; this book does a good job. This is a book I expect to find useful many, many, years from now.

The entire book revolves around the "nine rules." After the typical introduction and list of the rules, there's one chapter for each rule. Each of these chapters describes the rule, explains why it's a rule, and includes several "sub-rules" that explain how to apply the rule. Most importantly, there are lots of "war stories" that are both fun to read and good illustrations of how to put the rule into practice.

Since the whole book revolves around the nine rules, it might help to understand the book by skimming the rules and their sub-rules:

1. Understand the system: Read the manual, read everything in depth, know the fundamentals, know the road map, understand your tools, and look up the details.
2. Make it fail: Do it again, start at the beginning, stimulate the failure, don't simulate the failure, find the uncontrolled condition that makes it intermittent, record everything and find the signature of intermittent bugs, don't trust statistics too much, know that "that" can happen, and never throw away a debugging tool.
3. Quit thinking and look (get data first, don't just do complicated repairs based on guessing): See the failure, see the details, build instrumentation in, add instrumentation on, don't be afraid to dive in, watch out for Heisenberg, and guess only to focus the search.
4. Divide and conquer: Narrow the search with successive approximation, get the range, determine which side of the bug you're on, use easy-to-spot test patterns, start with the bad, fix the bugs you know about, and fix the noise first.
5. Change one thing at a time: Isolate the key factor, grab the brass bar with both hands (understand what's wrong before fixing), change one test at a time, compare it with a good one, and determine what you changed since the last time it worked.
6. Keep an audit trail: Write down what you did in what order and what happened as a result, understand that any detail could be the important one, correlate events, understand that audit trails for design are also good for testing, and write it down!
7. Check the plug: Question your assumptions, start at the beginning, and test the tool.
8. Get a fresh view: Ask for fresh insights, tap expertise, listen to the voice of experience, know that help is all around you, don't be proud, report symptoms (not theories), and realize that you don't have to be sure.
9. If you didn't fix it, it ain't fixed: Check that it's really fixed, check that it's really your fix that fixed it, know that it never just goes away by itself, fix the cause, and fix the process.

This list by itself looks dry, but the detailed explanations and war stories make the entire book come alive. Many of the war stories jump deeply into technical details; some might find the details overwhelming, but I found that they were excellent in helping the principles come alive in a practical way. Many war stories were about obsolete technology, but since the principle is the point that isn't a problem. Not all the war stories are about computing; there's a funny story involving house wiring, for example. But if you don't know anything about computer hardware and software, you won't be able to follow many of the examples.

After detailed explanations of the rules, the rest of the book has a single story showing all the rules in action, a set of "easy exercises for the reader," tips for help desks, and closing remarks.

There are lots of good points here. One that particularly stands out is "quit thinking and look." Too many try to "fix" things based on a guess instead of gathering and observing data to prove or disprove a hypothesis. Another principle that stands out is "if you didn't fix it, it ain't fixed;" there are several vendors I'd like to give that advice to. The whole "stimulate the failure, don't simulate the failure" discussion is not as clearly explained as most of the book, but it's a valid point worth understanding.

I particularly appreciated Agans' discussions on intermittent problems (particularly in "Make it Fail"). Intermittent problems are usually the hardest to deal with, and the author gives straightforward advice on how to deal with them. One odd thing is that although he mentions Heisenberg, he never mentions the term "Heisenbug," a common jargon term in software development (a Heisenbug is a bug that disappears or alters its behavior when one attempts to probe or isolate it). At least a note would've been appropriate.

The back cover includes a number of endorsements, including one from somebody named Rob Malda. But don't worry, the book's good anyway :-).

It's important to note that this is a book on fundamentals, and different than most other books related to debugging. There are many other books on debugging, such as Richard Stallman et al's Debugging with GDB: The GNU Source-Level Debugger. But these other texts usually concentrate primarily on a specific technology and/or on explaining tool commands. A few (like Norman Matloff's guide to faster, less-frustrating debugging ) have a few more general suggestions on debugging, but are nothing like Agans' book. There are many books on testing, like Boris Beizer's Software Testing Techniques, but they tend to emphasize how to create tests to detect bugs, and less on how to fix a bug once it's been detected. Agans' book concentrates on the big picture on debugging; these other books are complementary to it.

Debugging has an accompanying website at debuggingrules.com, where you can find various little extras and links to related information. In particular, the website has an amusing poster of the nine rules you can download and print.

No book's perfect, so here are my gripes and wishes:

1. The sub-rules are really important for understanding the rules, but there's no "master list" in the book or website that shows all the rules and sub-rules on one page. The end of the chapter about a given rule summarizes the sub-rules for that one rule, but it'd sure be easier to have them all in one place. So, print out the list of sub-rules above after you've read the book.
2. The book left me wishing for more detailed suggestions about specific common technology. This is probably unfair, since the author is trying to give timeless advice rather than a "how to use tool X" tutorial. But it'd be very useful to give good general advice, specific suggestions, and examples of what approaches to take for common types of tools (like symbolic debuggers, digital logic probes, etc.), specific widely-used tools (like ddd on gdb), and common problems. Even after the specific tools are gone, such advice can help you use later ones. A little of this is hinted at in the "know your tools" section, but I'd like to have seen much more of it. Vendors often crow about what their tools can do, but rarely explain their weaknesses or how to apply them in a broader context.
3. There's probably a need for another book that takes the same rules, but broadens them to solving arbitrary problems. Frankly, the rules apply to many situations beyond computing, but the war stories are far too technical for the non-computer person to understand.

But as you can tell, I think this is a great book. In some sense, what it says is "obvious," but it's only obvious as all fundamentals are obvious. Many sports teams know the fundamentals, but fail to consistently apply them - and fail because of it. Novices need to learn the fundamentals, and pros need occasional reminders of them; this book is a good way to learn or be reminded of them. Get this book.

If you like this review, feel free to see Wheeler's home page, including his book on developing secure programs and his paper on quantitative analysis of open source software / Free Software. You can purchase Debugging: The 9 Indispensable Rules for Finding Even the Most Elusive Software and Hardware Problems from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Spencerian writes "Learning Unix for Mac OS X Panther is a good tool for those who are experienced with the original Mac OS or Mac OS X, but not the Unix command line. Most of the content would not interest the traditional programmer, Linux, BSD, or other UNIX jockey, however." For Spencerian's take on why, read on for the rest of his review. Learning Unix for Mac OS X Panther author Dave Taylor and Brian Jepson pages 168 publisher O'Reilly Publishing rating 8 reviewer Kevin Spencer ISBN 0596006179 summary Learning Unix for Mac OS X Panther is a good tool for those who are generally comfortable with the original Mac OS or Mac OS X, but not the Unix command line. Most of the content would not interest the traditional programmer, Linux, BSD, or other UNIX jockey, however. The Finder can't do it all, and it's a good idea to realize that today's Mac OS has more ways to force it to work than its original version. This 3rd edition of the book has a better audience focus than previous editions.

This book focuses on those of us in the Mac OS professional world who have become Unix system admins by default with the introduction of OS X, and could stand to have a handy UNIX reference nearby, particularly if the Finder freezes in Apple's latest version of their BSD/OpenStep blend of a UNIX operating system.

As the authors explain in the book, the best justification for understanding and using the UNIX components present is Mac OS X is the same as in any other UNIX-family operating system: power and control. The Finder (Mac OS X's graphical desktop manager) can't do everything, so this book provides information to help power users and technicians resolve issues, install software, or create an optimized experience, all through the Terminal.

Chapters 1 and 2 provide a very helpful tutorial on the Mac OS X Terminal application, from showing the benefits of customizing the Terminal, the concept of shells, UNIX command syntax, and other obscure but useful settings that strengthen the power of the application when accessing the BSD innards of Mac OS X. Arguably, these two chapters are the strongest guide on Mac OS X's Terminal application (as it relates to its UNIX roots) that I have seen in any Mac OS X book to date.

Chapters 3 and 4 handle understanding of the UNIX filesystem, administration and superuser access, privileges, handling external volumes, file and directory names and the like. Mac OS X, while a BSD at heart, doesn't map out everything in a traditional UNIX-style directory format--at least, not from the Finder's view. Through the Terminal, a user can see the underlying, otherwise-hidden UNIX directories. The authors go through some basic but very helpful situations such as changing file and owner permissions, which can be changed from the Finder with greater ease in Panther, but not with the same finesse as done from a command line.

The file management chapter moves readers through the classic commands for moving, editing, and copying files from the command line, which can be very helpful for administrators of Mac OS X systems who must attempt repairs by SSH, for instance, and don't have access to the usual graphical elements that generally make Mac OS usage so easy. The authors don't pick sides in the vi vs. pico debate, and just offer the basic instructions on how to use either for your editing.

The book continues with the same level of complexity that local system admins or power users require in issues such as printing via CUPS, handling processes that the Finder doesn't show, using the X11 application, using Fink (a Debian-style installation application) installing OpenOffice and GIMP, using FTP and secure shell, using Pine and Lynx, and more.

For a book of just 168 pages, the authors pack quite a bit on making a Mac OS X system work from its Terminal roots. New Mac OS X system administrators will find this book most useful, particularly if their UNIX experience is lacking or radically different from what Mac OS X presents. Experienced *NIX users who bought a new Mac may find the book a good intermediary to demonstrate how Mac OS X Panther differs from the *NIX boxen they've used in the past.

You can purchase Learning Unix for Mac OS X Panther from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Indomitus writes "I used to read tons of science fiction, nothing but for long stretches. Then I grew up and realized that most science fiction sucked. I look back on the time spent reading anything by Piers Anthony and know I'm going to be wishing I had those hours back when I'm older. Writers like Charlie Stross are the reason I know most SF sucks, because he does it so well. He fills this somewhat slim book with more ideas than any 10 other books from the section his work inhabits at the bookstore." Read on for the rest. Singularity Sky author Charles Stross pages 313 publisher Berkley Pub Group rating 9.9 reviewer Matt Grommes ISBN 0441010725 summary A semi-sentient space travelling information gatherer called The Festival comes to a backward planet and instigates 1000 years of technological change in a month. The rulers of the world are not too happy and will use any means they have to stop the Festival, even if it means incurring the wrath of the super-AI that watches over the universe.

The main idea of the story, that a semi-sentient information-gathering alien system called the Festival comes to a backward farming planet and begins granting wishes -- in the form of advanced technology -- in exchange for stories and information, is only the seedbed for the larger exploration of the societally backward planetary system and what happens when the revolution you hoped to lead finally comes and it doesn't need you.

As a lifelong reader of science fiction, I hate that most SF is just as backward-looking as most Fantasy. Part of the problem with recent SF work is that we've come to a point in science where a lot of what made science fiction new has been done and what's coming is almost impossible to imagine, which I'll get to in a second. Space exploration can still be exciting but most new space stuff has been infected with the Star Trek Syndrome, as I call it, where everyone is boring and has no flaws, and the status quo rules. People just don't look to space exploration as exciting in real life so that translates to the SF work that people do. Real life science is changing so fast that it leaves even science fiction people in the dust. The result is the rise of 'Fantasy with robots and aliens' and 'Space Opera,' two facets of SF that seem to be dominating the landscape. Even Neal Stephenson, who was at the forefront of real technological future SF with The Diamond Age and Snow Crash has gone backward with Quicksilver and to a lesser extent Cryptonomicon.

The issue is The Singularity. This is Vernor Vinge's idea that technological progress proceeds at an exponential rate until there is a complete break with what came before. The End Of History, as people call it. This comes with the creation of a human-level AI that quickly proceeds past human-level, the invention of Upload technology that will allow us to live in computer systems and artificial bodies, something of that nature that we can't imagine. The problem with writing futuristic work in the time before a Singularity is that you can't see beyond it. Everything is different, so much so that all we can hope for is the fire up our imaginations to the point where we can begin to think in new ways.

One of the main goals of science fiction as I see it is to prepare us for the future. You can't hope to cope with the future if you've never been innoculated with new ideas. Singularity Sky is one of the first post-Singularity novels I've read that takes the idea seriously and examines it, allowing us to open our minds to the vast possibilities. Stross doesn't shy away from it like so many others. He uses the Festival's coming to show the speed of the change that comes with a technological Singularity and what happens to people in the aftermath. He also shows a culture trying desperately to hang on to old ways and the futility of doing that in the face of such rapid change.

There are problems with the book, mostly in the perennial bugbear of science-fiction, character development, but the rush of ideas glossed over that for me. This is only Mr. Stross's second book, I believe, the first being a collection of short stories called Toast: And Other Rusted Futures, that is high on my Must Read list. Charles Stross is a name that you will hopefully hear a lot more from in the coming years. His imagination is up there with the best and brightest and with his work as an accelerant my mind can't help but burn with new ideas. I hope more science fiction writers see this book and decide to move forward to meet him.

You can purchase Singularity Sky from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

carl67lp writes "With all the hype surrounding Dan Brown's The DaVinci Code, I decided to travel to the bookstore to purchase the novel. However, while looking at the "New in Paperback" section, I happened across Brown's Digital Fortress and read the back cover quickly. It was exactly what I was looking for: a thriller with science (mathematics and cryptography), technology (a 3-million processor supercomputer), and intrigue. I devoured the nearly-400-page book in less than two days. But I left feeling a bit disappointed when looking back on the overall picture." Read on for Anderson's reasoning. Digital Fortress: A Thriller author Dan Brown pages 384 publisher Griffin Trade Paperback rating 7 out of 10 reviewer Carl Anderson ISBN 0312263120 summary An excellent, if slightly flawed, exploration into the world of government cryptography and those who try to defeat it

The premise

The first page ("Prologue") is enough to draw you right in. A Japanese man in Seville, Spain, is dying, and in his last act he attempts to communicate with fellow tourists. We immediately wonder, What is he trying to say? How does this relate to the premise of the book?

Flipping the page literally flips across the Atlantic Ocean, to the National Security Agency (NSA) and to beautiful, intelligent Susan Fletcher, head cryptographer at the NSA. She is involved with a university language professor named David Becker--a man who will figure deeply into the story.

A mysterious phone call sends David to Spain and a phone call from Susan's boss, Commander Strathmore, brings her to NSA headquarters. It's there that she learns of a potentially fatal threat to the NSA's codebreaking supercomputer, TRANSLTR--an unbreakable encryption. Strathmore briefs her that a disgruntled former employee, Ensei Tankado, has threatened to release this encryption scheme to the highest bidder. If Tankado does so, the NSA will be crippled--a fact proven by the revelation that TRANSLTR normally spends minutes decoding a message, but has spent more than half a day trying to break Tankado's algorithm.

Tankado isn't stupid--Strathmore says he has an accomplice who will release the code in the event that something happens to Tankado. Unfortunately, Tankado is the Japanese man who has died in Seville...and thus the NSA is running out of time to locate Tankado's pass key to break the encryption before his accomplice can release it to the world.

Meanwhile, Becker is still in Spain, under orders--from Strathmore, it turns out--to do just that. He realizes that Tankado's ring is the "key" to the mystery, and thus he begins a frantic search that leads him from a French-Canadian writer in the clinic, to a fat German tourist and his red-haired "escort," to a punk rock bar on the outskirts of town. Did I mention he's being followed by a deaf assassin the whole time?

What I liked

As I mentioned, Digital Fortress has all the elements that I was looking for. It had just the right amount of main characters, and everyone had a proper place in the book and in the story. I'm appreciative of the tidbits of technical information here and there--mentions of PGP, NSA history, and other such morsels were well placed.

There was also a smattering of sexual energy (although no real "sex scenes") and humor here and there. Who said computer geeks can't have a good time?!

I'm also a fan of subplots in books, that magically mesh together near the climax. Dan Brown deserves praise in this regard: minor characters who initially make you question their presence are brought nicely into the fold and given purpose.

In any book like this, little puzzles and questions come up as a matter of course. The reader is challenged to solve them just as the characters are. In this book, there are many such puzzles: What does the inscription on the ring mean? Who is Tankado working with, and how? What is the pass-code for the encryption scheme? Why is David Becker being hunted down? I delighted in trying to come up with answers to these questions as I read the book, and was pleasantly surprised to see I was wrong in many respects.

What I didn't like

In any mystery or thriller, the idea is to keep the reader guessing as long as possible, through plot twists, diverging plot lines that reconnect later, and the like. Brown does a fairly good job here, but this is where the book has its weakest points. For example, it is revealed early on that Tankado and the dead Japanese man in Spain are the same person. While this is perhaps unavoidable to push the plot along, I found it strange to have this happen so quickly. Later in the book, the author flips back and forth between who could be Tankado's accomplice, and who has committed a murder in Crypto. This flip-flopping is done poorly and leaves the reader thinking, "I already have my mind made up and you're not doing very well dangling red herrings." I had the bad guy pegged a couple of chapters before it was revealed, although I will admit that I was surprised at a particular turn of events afterwards.

Although this book was published in the late '90s, the technology aspects are still relevant--but this book gets some technical facts incorrect, or at least a bit off. However, they're fairly minor and don't detract from the book too much.

Some plot points are just too far fetched to be believable. For example, Susan's fiance, David Becker, tries to outrun a taxi--driven by the deaf assassin--while on a motorbike. The professional assassin fires several shots at Becker and misses every time, even though the bike is significantly slower than the taxi and the shots hit the bike body itself on several occasions.

Finally, some of the people in the NSA seem too stupid to be working there. In an effort to not give away spoilers, I can't be too much more specific than that, but suffice it to say that the "solution" is something that a high school science student wouldn't have much trouble figuring out.

Final thoughts

I tore into this book with high expectations. I finished the book with mixed feelings. As I look back on it, I can't help but feel that there was a lot of untapped potential and some glaring mistakes that could have been avoided. But I'm also pleased to have read what I consider a fairly good book, one that has served to heighten my interest in the genre, and made me even more ready to read The DaVinci Code.

Of course, it wouldn't be fair to compare this book to any of Dan Brown's later works. An author matures as he or she writes more books, and thus I'm certain that many of my quibbles would have been ironed out in future books. I'll have to find that out when I read DaVinci.

While it might seem that I had more bad to say about the book than good, I'd say that the reverse is actually true--the "good" goes all through the book, but there isn't really a way to quantify it.

I'd wholeheartedly recommend this novel to anyone who has an interest in technological thrillers, spy novels, or thrillers in general. It's a very accessible and enjoyable read, and I'm glad I bought it.

You can purchase Digital Fortress from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

jsight writes with his review of Rob McGregor's Practical C++, published by QUE. He writes "Some books attempt to do one thing really well, and others attempt a little of everything. This book is clearly an example of the latter, in full force. Weighing in at a hefty 900 pages, you would expect this book to be crammed with chapters and details on every aspect of the STL and basic C++. In the following review, I am going to cover where it succeeds in doing this, and where it fails." (This book has been out for a few years; what books would make more sense today for a C++ learner's library?) Practical C++ author Rob McGregor pages 900 publisher QUE rating 7/10 reviewer Jess Sightler ISBN 0789721449 summary Provides a practical guidebook to learning C++ Section I -- Programming 101 At first glance, the book appears to be written for people with experience programming, however reading through this section clearly dispels that myth. Here we have a section which goes over everything from for loops to if conditionals while simultaneously using verbose, duplicitous language at every step. Perhaps this was intended as a means of reinforcement, however, it seems most of the effort here would be wasted.

The technical depth is what you would expect for a novice, but without enough hand-holding and examples to make a novice feel comfortable. Making matters worse, there are numerous typos in this section, including quite a few in the examples (making them uncompilable without corrections). Some of these appear to be type-setting errors, however, there are enough to potentially confuse novice developers.

I believe that the combination of weak examples, and significant typographical errors are strong enough to give a novice much difficulty in learning the C++ language.

Having said that, the section should be provide no difficulty for any programmer with a good knowledge of any vaguely similar language (eg, Perl, Java, PHP, etc).

Section II -- Beyond the Basics

Ah, now we're getting down to Brass Tacks... this section goes over everything from Function overloading to Structure and Unions. The section on function members within structures also does an excellent job of preparing the reader for the upcoming introduction of Object Oriented concepts.

The sections on Memory management, both from an allocation standpoint, and from a bit manipulation standpoint are first-rate. Details are perhaps not as strong as they could have been, however the material is very accessible, and clearly described.

Probably my only complaint with this chapter is the overly general section on compiling and debugging programs. However, as this book does attempt to be somewhat compiler/debugger agnostic, this is forgivable. From here, we dive into the real power of C++, Object Orientation.

Section III

From the beginning, this book treats Objects as an extension of the structure syntax taught previously (with the default of Public switched to Private). This, along with the classic Plans vs. Product description of the difference between a Class and an Object are quite clear and robust.

Again, this is a solid chapter, describing the details of getting a system of classes up and running, as well as some sample data structure implementations.

And then finally, the last section is a slightly less than 200 page description of the STL. This section is probably the book's weakest part, as it is just strong enough to give you a taste of what is available, but often not strong enough to grasp the details. It's a good start, but much more attention should have been made to this subject (potentially even at the cost of some of the wasted words on how a 'for' loop works). It makes a decent introduction for someone with very limited STL background, however, there is not enough depth to reach a strong level of understanding here.

Summary Overall, this is a solid book for an existing programmer to pick up C++ concepts. A programmer with a strong knowledge of an existing procedural language (such as C) would have no trouble digesting the concepts of this book. Having said that, the poor typographical issues, and verbose wording often muddle an otherwise good book.

You can purchase Practical C++ from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

CrankyFool writes "Never having been a huge graphic book fan, I didn't discover Neil Gaiman until my appreciation for Pratchett led me to find Good Omens. Years after Good Omens I discovered urban fantasy as done by Gaiman and hungrily devoured American Gods and Neverwhere. After raving about Neverwhere, someone recommended King Rat by China Mieville (rather than James Clavell, who wrote a very, very different King Rat ) to me. Well, I'll give any author a chance, especially after they'd been reviewed so positively on Slashdot (see an earlier review of Perdido Street Station)." Read on for the rest of CrankyFool's review. King Rat author China Mieville pages 320 publisher Tor Books rating 8 reviewer CrankyFool ISBN 0312890729 summary Saul Garamond is blamed for his father's death, broken out of jail, and finds out his the half-human heir to the rat kingdom and a thousand-year-old conflict. Things go downhill from there.

King Rat is incredibly similar to Gaiman's American Gods and Neverwhere -- I've purposefully not looked into the chronology of publication so I don't want to assert who was influenced by whom, but some significant elements of Neverwhere -- London as a setting, the critical presence of rats, a malevolent, almost-unkillable foe -- and American Gods -- a protagonist who loses someone dear to him very early in the work (Shadow loses his wife in AG, while Saul loses his father), and who struggles through a new understanding of his role in the world, a new appreciation for the fact he was born for a specific destiny, and a rebellion against his father. Hell, one character actually appears in both American Gods and King Rat.

There's probably a very strong correlation between people who liked American Gods and Neverwhere and people who'll like King Rat. At the same time, King Rat's tone is incredibly different -- it's not a derivative of Gaiman's work as much as it is a close family relation. It's almost totally bereft of humor, unlike Neverwhere, and not quite as awash in a palpable sense of loss as American Gods (especially given Shadow's ongoing relationship with his wife). Unlike the other two books, I found this one a little slow to get into, reading five pages here, ten pages there, until it finally hooked me.

King Rat's story revolves around Saul Garamond, who comes home one night to find that someone has killed his estranged father -- and the police think it's him. Garamond is broken out of prison by the title furtive character, who lost his dominion over the rats in the Hamlin catastrophe, and who introduces himself as Saul's uncle. So yes, the protagonist of King Rat is, in fact, Prince Rat (who is half man and half rat).

The rest of the book is the detailing of the conflict between the Rat, Bird, and Spider people and the pied piper of Hamlin who, in fact, turns out to be quite evil and fond of killing things.

Music is at the core of King Rat, from the basic most powerful talent of the nemesis, to the particular defenses of Saul (since he's a halfling, neither human-snaring music nor rat-snaring music alone could get him), to the interweaving of Saul's story with that of Natasha, a friend of his and a jungle-music DJ. Parts of the book, discussing the music arrangement and the role of bass in the actual communication of emotion to an audience, felt like they might be lost a little on a reader who hasn't been awash in that rhythm in a club. Thankfully for the vast majority of slashdotters, that's not a huge part of the book and even if you've never gone clubbing, held a rhythm, or danced your ass off, you're not likely to be alienated by it.

Mieville decided to end the book and the conflict in a way that felt more ambiguous than it could have been. While I applaud any author who doesn't bow and scrape to the convention that if you have a battle between good and evil, evil must be completely vanquished by the end of the work, I couldn't help feel that Mieville ended the book in such a way at least partially so a sequel could be written, featuring largely the same characters. It left me uneasy and on the verge of feeling a little cheated.

So that's the downside. On the upside, I found Saul's characterization engaging, interesting, and real. Saul is not as good of a man as we all would like to be, but he's probably as good as most of us get to be. Especially in the beginning, he's pretty wretchedly whiny. He's not exceedingly brave, or truthful, or kind. He's just ... a guy, with some special powers due to his parentage, thrust into a reality that is wildly different from his own, and he does his best to adapt to it. Saul's friends, Natasha Fabian and Kay, can't be drawn with as fine of a stroke because the book isn't about them, but they're still interesting and nuanced. Pete, the piper of Hamlin, is rather less complex. He's evil. He's strong. He is, in Jules' immortal terms, a bad motherfucker. With a flute.

Darn decent book, I'd say. If you liked Neverwhere (and can stand urban fantasy that isn't funny), or American Gods (and can stand urban fantasy that isn't set in the U.S.), you owe it to yourself to check it out.

China Mieville's official website was down last time I checked -- you may have more luck finding stuff about him at his unofficial home page.

You can purchase King Rat from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

CrankyFool writes "Never having been a huge graphic book fan, I didn't discover Neil Gaiman until my appreciation for Pratchett led me to find Good Omens. Years after Good Omens I discovered urban fantasy as done by Gaiman and hungrily devoured American Gods and Neverwhere. After raving about Neverwhere, someone recommended King Rat by China Mieville (rather than James Clavell, who wrote a very, very different King Rat ) to me. Well, I'll give any author a chance, especially after they'd been reviewed so positively on Slashdot (see an earlier review of Perdido Street Station)." Read on for the rest of CrankyFool's review. King Rat author China Mieville pages 320 publisher Tor Books rating 8 reviewer CrankyFool ISBN 0312890729 summary Saul Garamond is blamed for his father's death, broken out of jail, and finds out his the half-human heir to the rat kingdom and a thousand-year-old conflict. Things go downhill from there.

King Rat is incredibly similar to Gaiman's American Gods and Neverwhere -- I've purposefully not looked into the chronology of publication so I don't want to assert who was influenced by whom, but some significant elements of Neverwhere -- London as a setting, the critical presence of rats, a malevolent, almost-unkillable foe -- and American Gods -- a protagonist who loses someone dear to him very early in the work (Shadow loses his wife in AG, while Saul loses his father), and who struggles through a new understanding of his role in the world, a new appreciation for the fact he was born for a specific destiny, and a rebellion against his father. Hell, one character actually appears in both American Gods and King Rat.

There's probably a very strong correlation between people who liked American Gods and Neverwhere and people who'll like King Rat. At the same time, King Rat's tone is incredibly different -- it's not a derivative of Gaiman's work as much as it is a close family relation. It's almost totally bereft of humor, unlike Neverwhere, and not quite as awash in a palpable sense of loss as American Gods (especially given Shadow's ongoing relationship with his wife). Unlike the other two books, I found this one a little slow to get into, reading five pages here, ten pages there, until it finally hooked me.

King Rat's story revolves around Saul Garamond, who comes home one night to find that someone has killed his estranged father -- and the police think it's him. Garamond is broken out of prison by the title furtive character, who lost his dominion over the rats in the Hamlin catastrophe, and who introduces himself as Saul's uncle. So yes, the protagonist of King Rat is, in fact, Prince Rat (who is half man and half rat).

The rest of the book is the detailing of the conflict between the Rat, Bird, and Spider people and the pied piper of Hamlin who, in fact, turns out to be quite evil and fond of killing things.

Music is at the core of King Rat, from the basic most powerful talent of the nemesis, to the particular defenses of Saul (since he's a halfling, neither human-snaring music nor rat-snaring music alone could get him), to the interweaving of Saul's story with that of Natasha, a friend of his and a jungle-music DJ. Parts of the book, discussing the music arrangement and the role of bass in the actual communication of emotion to an audience, felt like they might be lost a little on a reader who hasn't been awash in that rhythm in a club. Thankfully for the vast majority of slashdotters, that's not a huge part of the book and even if you've never gone clubbing, held a rhythm, or danced your ass off, you're not likely to be alienated by it.

Mieville decided to end the book and the conflict in a way that felt more ambiguous than it could have been. While I applaud any author who doesn't bow and scrape to the convention that if you have a battle between good and evil, evil must be completely vanquished by the end of the work, I couldn't help feel that Mieville ended the book in such a way at least partially so a sequel could be written, featuring largely the same characters. It left me uneasy and on the verge of feeling a little cheated.

So that's the downside. On the upside, I found Saul's characterization engaging, interesting, and real. Saul is not as good of a man as we all would like to be, but he's probably as good as most of us get to be. Especially in the beginning, he's pretty wretchedly whiny. He's not exceedingly brave, or truthful, or kind. He's just ... a guy, with some special powers due to his parentage, thrust into a reality that is wildly different from his own, and he does his best to adapt to it. Saul's friends, Natasha Fabian and Kay, can't be drawn with as fine of a stroke because the book isn't about them, but they're still interesting and nuanced. Pete, the piper of Hamlin, is rather less complex. He's evil. He's strong. He is, in Jules' immortal terms, a bad motherfucker. With a flute.

Darn decent book, I'd say. If you liked Neverwhere (and can stand urban fantasy that isn't funny), or American Gods (and can stand urban fantasy that isn't set in the U.S.), you owe it to yourself to check it out.

China Mieville's official website was down last time I checked -- you may have more luck finding stuff about him at his unofficial home page.

You can purchase King Rat from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

danny writes "How are brain size and intelligence related to social complexity? What are the evolutionary underpinnings of cooperation? How sophisticated are animal communication and social cognition? And do animals have culture? Read on for my review of Animal Social Complexity: Intelligence, Culture, and Individualized Societies." Animal Social Complexity: Intelligence and Culture author Frans de Waal and Peter Tyack pages 616 pages publisher Harvard University Press rating 9 reviewer Danny Yee ISBN 0674009290 summary 18 papers on primates, cetaceans, other mammals and birds

How are brain size and intelligence related to social complexity? What are the evolutionary underpinnings of cooperation? How sophisticated are animal communication and social cognition? And do animals have culture? These are some of the broad questions addressed by the eighteen papers in Animal Social Complexity, which look not only at primates and cetaceans, but also at hyenas, elephants, bats, and birds. The common focus is on societies that are individualized, with members recognising each other as individuals, and stable, with long-lived members and on-going relationships, and in which there are learned survival skills and social behaviours. Some of the papers are overviews of particular species or taxa, some address specific questions in the context of a particular species, and some present cross-species comparisons.

Consisting of the papers from a conference held in 2000, Animal Social Complexity is a professional volume, complete with a hundred pages of references. But the topics covered are of widespread interest, and the multi- and inter-disciplinary nature of the papers makes them mostly accessible to the lay reader.

Carel Van Schaik and Robert Deaner present a life history perspective on cognitive evolution: demonstrating a link between social complexity and intelligence/brain size is complicated because both are correlated with long life spans. Randall Wells presents an outline of dolphin social complexity based on long-term studies on the communities in Sarasota Bay, Florida. And Katy Payne gives an overview of social complexity in the three elephant species.

Christophe Boesch describes examples of complex cooperation among Tai chimpanzees, in group hunts for monkeys and in territorial conflict with other chimpanzee groups. Christine Drea and Laurence Frank describe the social system of spotted hyenas and argue that more attention should be paid to social complexity in carnivores. It has commonly been argued that social stress is a consequence of subordination; Scott Creel and Jennifer Sands present evidence suggesting that it may in fact be a cost of domination, at least in some species.

Three of the papers debate the underlying mechanisms of social cognition. Ronald Schusterman et al. argue for equivalence classifications as a basic structure. In contrast, Robert Seyfarth and Dorothy Cheney argue that "nonhuman primates are innately predisposed to group other individuals into hierarchical classes". And for Frans de Waal the conditionality of behaviour suggests a role for if-then structures in primate "social syntax".

Taking a comparative approach to laughter and smiling in primates, Jan Van Hoof and Signe Preuschoft find that "laughter has evolved in the context of joyful play, and that the broad smile has evolved as an expression of nonhostility and friendliness, taking its origin in the expression of fearful submission". Looking at vocal learning in four parrot species from Costa Rica, Jack Bradbury suggests that in "ecology, social organization, and vocal communication, parrots appear to be more convergent with dolphins than they are with other birds".

Gerald Wilkinson looks to bats for an independent test of the Machiavellian Intelligence hypothesis, probing the relationships between brain size, vocal complexity, and colony size. And Peter Tyack explores bottlenose dolphins' use of signature whistles in communicating social relationships.

Following in the footsteps of Imanishi, pioneer of Japanese primatology, Tetsuro Matsuzawa considers, as examples of "culture", sweet potato washing among Koshima monkeys and nut cracking using stone tools by Bossou chimpanzees. Toshisada Nishida describes the "flexibility and individuality of cultural behavior patterns" among chimpanzees at Mahale. And in "Ten Dispatches from the Chimpanzee Culture Wars" William McGrew gives an overview of the arguments between cultural anthropologists, psychologists, and primatologists (among others) over chimpanzee culture -- and over the definition of culture.

Hal Whitehead looks at sperm whales, the cetacean culture debate more generally, and the possible effects of "cultural hitchhiking" on genetic diversity. And Meredith West et al. find a critical role for social interaction in learning and development in cowbirds and starlings.

In addition to the eighteen papers, there are a dozen shorter "case studies" which tackle narrower questions. Animal Social Complexity is an important contribution to the scientific literature. And it has a wealth of material for anyone fascinated by social animals and not intimidated by scientific methodology, a little bit of statistics, references and scholarly language.

Danny Yee has written over 700 book reviews. You can purchase Animal Social Complexity: Intelligence and Culture from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

roomisigloomis writes "The Maverick and His Machine begins with a paragraph that sounds like the first line of a film noir: 'Thomas John Watson began his life at age 40, after Dayton, Ohio, nearly ruined him.' From there, what one would expect to be a stuffy, boring book about a dead white man turns out to be an interesting and inspiring account of The International Business Machines Company (IBM) and the man who started it. Why would a geek care? Because IBM, its technological breakthroughs and Watson are very much the foundation of commercial technology as we know it today." Read on for the rest. The Maverick and His Machine: Thomas Watson, Sr. and the Making of IBM author Kevin Maney pages 512 publisher Wiley, John & Sons, Incorporated rating 7 reviewer roomisgloomis ISBN 0471414638 summary How IBM came to be, and to succeed.

At age 40, Watson was thrown a curve ball that, like that first sentence says, nearly ruined him. In fact, it sent him so low that this shaped his character more than anything that had happened to him earlier in his lifetime. It sent him to the lower depths and resulted in him being given the reigns of an equally down-in-the dumps loser business just to get rid of him. He was banished to a corporate Siberia. He was considered a loser, and given a loser's position in a loser's business.

It's at this point that he reshaped and remade that company into what is today known as IBM. The blue suits and white shirts that were the uniform of IBM men became so because he wore one every day. There was no written rule that employees had to wear them; they did it because he did it. That says something: he led by example and his employees admired him.

Just as an aside, it seems that Watson's big thing was that things didn't happen (or went wrong) because people didn't think hard enough. To encourage employees to think he had big "THINK" signs put all over the company. This evolved into "Think" buttons, and employees were even allowed and encouraged to kick back and think. Eventually, small notepads were emblazoned with "Think" and they were called "Thinkpads." Hence, the name of the laptop.

THINK, by the way, is the reason that the company created so many technological innovations.

Now, just because Watson started IBM and largely shaped it into one of the most successful companies in the world doesn't mean he was a saint. Some of the most interesting parts of the book have to do with his home life and how he treated his wife and kids. It seems that he was somewhat of a manipulator who knew how to shape people by breaking them and remaking them.

One story about his son (who would later become CEO of the company) shows Watson's mean streak. It seems that, early in the younger Watson's career, after dinner together at home, the elder asked him what his impression was of one of his executives.

The younger Watson dutifully answered, seeking to impress his father with his skill at observing people. The elder paused and then berated the young man for daring to form an opinion about a seasoned executive who had years of experience behind him. Who did the young man think he was to judge someone who had been in the business since before he was born?

While this isn't the stuff of Ward Cleaver, Watson was, all the same, a courageous and enterprising individual who took risks and (most of the time) succeeded. Especially engrossing is the episode during the depression when IBM was in danger of bankruptcy and shutting its doors. Watson, contrary to what most intelligent people would do, gave a rousing talk to his top executives, telling them that instead of cutting back on manufacturing and personnel, they should increase both.

Luckily (for Watson), a few months later, Pearl Harbor happened and, with the sharp increase in troops, materials and logistics, the U.S. government needed "calculating machines" and needed them fast. While major competitors like NCR and Burroughs had to ramp up production to meet demand, IBM, with its ready stockpile of machines won the contract and delivered, saving them from possible bankruptcy.

There is a lot more I could say about the book but because I don't want to spoil anything, I won't go into it here. However, if you're a Big Blue fan (and I am), you might want to follow up this read with Lou Gerstner, Jr.'s book, Who Says Elephants Can't Dance. It's a great read about how, for the second time in its history, the company was saved from becoming history.

You can purchase The Maverick and His Machine: Thomas Watson, Sr. and the Making of IBM from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

honestpuck writes "Harold Davis has started with a marvelous idea, teaching programming using a language available on all platforms, JavaScript, and an interface familiar to everyone, the web browser. Learn How to Program Using Any Web Browser is written for absolute beginners to learn the basic principles of programming -- or at least that's what the cover would have you believe." Read on for honestpuck's evaluation of that claim. Learn How to Program Using Any Web Browser author Harold Davis pages 396 publisher Apress rating 5 reviewer Tony Williams ISBN 1590591135 summary Not much programming, but well written

The language is suitably light and simple, the book well-structured and broken down into easily digested chunks. The order in which concepts are introduced is fairly traditional for a language tutorial: first we get types, variables and statements, before moving on to conditionals, loops, and functions, followed by arrays and objects before finishing with event-driven programming. Davis' decision to leave string handling till last seems a little perverse and personally I would have introduced functions earlier.

My real complaints about this book centre on the abstract nature of the discussion. There are very few real world examples that could be useful to anyone. The best you get is a version of "Rock, Paper, Scissors" in Chapter 3, and an 'auction' application. The book would have been improved dramatically if the end result of your study was a few things you could actually point to.

I also have a complaint about the target audience for this book. The web page for the book at the publishers states that "The target reader is likely a twelve- or thirteen-year-old, who is just starting to get curious about what makes a computer work -- or an office worker who has been using computer applications for years, and would like to spend some time delving deeper into what makes them tick." Most adults and even teenagers don't want to 'learn how to program' as much as they want to learn how to use a tool to perform a task. If your tool is JavaScript, then it's almost certain your task is related to building web pages, but this gets little real attention from Davis. For even younger students, this book totally lacks anything to hold their attention -- the lack of real-world examples hurts here.

I also take issue with the title: this book doesn't really teach 'programming' much at all. It certainly teaches you to write JavaScript, but where are the sections about the real lessons of programming, such as top-down vs. bottom-up design, or breaking a task up into chunks? Even debugging has little coverage -- a single thirty-page chapter, half of which is specific to JavaScript or the throwing and handling of exceptions. Since the work of Papert and others at MIT twenty-five years ago, we've learned a great deal about how to teach programming concepts in a simple manner, but Davis appears to have ignored all this and given us a language tutorial. The publisher's web page for the book says "very emphatically, this is not a book about programming JavaScript." If that's so then I'd argue that it isn't a book about learning the principles of programming either.

It is obvious from this book that Davis is an excellent writer; if he had tried to write a book to teach JavaScript and had focused on the tasks for which it is often used this, volume may have been superb. As it is, he has shot for a higher goal and fallen far too short.

If you would like to check it out for yourself, you can go to the web page for the book where there is sample chapter, the Table of Contents (though they call it a "Detailed TOC" as distinct from the 'Table of Contents,' which is just a list of 11 chapter titles) and index, all in PDF format.

I went looking for a book that I could give to my 11-year-old daughter now that she has become interested in "what Daddy does." I'm still looking, I'm certain that this one isn't it.

You can purchase Learn How to Program Using Any Web Browser from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

raceBannon writes "The book surprised and fascinated me. I thought it was going to be solely about the Golden Ratio. Mario Livio does cover the topic but along the way he throws in some mathematical history and even touches on the idea that math may not be a universal concept spread across the galaxy." Read on for the rest of raceBannon's review. The Golden Ratio author Mario Livio pages 320 publisher Broadway rating 7/10 reviewer raceBannon ISBN 0767908155 summary Through telling the tale of the Golden Ratio, Livio explains how this simple ratio pops up in all kinds of physical phenomenon and debunks the idea that the ratio is present in many famous man-made structures and art work. Along the way, he provides historical tidbits regarding some of the well-known and not so well-known mathematicians throughout the ages and he tells the story of some of the more famous and not so famous mathematical advances. Finally, he discusses the possibility that mathematics may represent some kind of global truth that exists throughout the cosmos.

I have to admit that it is a little spooky to me that this ratio, this irrational number (1.6180339887...), pops up in many varied natural phenomena from how sunflowers grow to the formation of spiral galaxies; not to mention that the Golden Ratio and the Fibonacci Series are related. It makes you want to think that there is a God with a plan.

The Golden Ratio is defined as follows: In a line segment ABC, if the ratio of the length AB to BC is the same as the ratio of AC to AB, then the line has been cut in extreme and mean ratio, or in a Golden Ratio called Phi.

On the flip side, Livio squarely debunks the idea that the Golden Ratio is present in many famous paintings and architecture that has been postulated in previous books. He rightly points out that you can find the Golden Ratio in anything depending on where you decide to place the measuring tape. The idea that the Golden Ratio is such a symbol of universal beauty that it appears by accident in our great man-made buildings and artwork does not carry any weight. I think Livio makes his point.

He also uses the Golden Ratio as a framework to illuminate other historical tidbits about key mathematical figures, guys like Pythagoras and Euclid, who continue to affect the mathematical world to this day. I love this kind of stuff; the historical context of how and why these legends did what they did is very interesting to me. For example, I did not know that Euclid himself did not discover geometry or even make any great new contributions to the field in terms of ways to apply it. What he is famous for is organizing the information into a coherent fashion. He was a teacher of the highest order; so much so that Abraham Lincoln himself used Euclid's texts, unchanged after all those years, to learn the subject back in Lincoln's log cabin days.

The book is not all a philosophical discussion. Livio does use some simple math examples to make his points but it was at a level that I could follow. According to my college professor, I escaped College Calculus by sheer luck. Livio does provide the rigorous math examples in appendices at the end of the book (I did not bother with these).

Finally, Livio takes a shot at the idea that mathematics is a universal concept across the entire universe. To be honest, I have always assumed that it was. After all, I am a Trekkie and this concept goes unstated throughout all four TV series. The idea that mathematics is a human construction and probably holds no water in another civilization that grew up on the other side of the universe makes a lot of sense to me. I have to admit; I need to ponder that one for a while.

I recommend this book. If you like the history of science, your high school algebra class is just a little more than a dark fog in your memory, and you get a charge out of scientific mysteries, you will not be disappointed.

You can purchase The Golden Ratio from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Craig Maloney writes "If you are a Windows programmer looking to create or move your stand-alone database applications away from Microsoft-specific tools such as Visual Basic, Visual C++, Access or SQL Server, MySQL: Building User Interfaces is written just for you." Read on for the rest of Craig's review. MySQL: Building User Interfaces author Matthew Stucky pages 632 publisher New Riders rating 4/10 reviewer Craig Maloney ISBN 073571049X summary MySQL and GTK+ are used to create cross-platform applications, with copious code listings.

What's in the book? The first chapter guides the reader through the basics of MySQL and how it compares to Access 2000 and SQL Server 97. Next, a code listing demonstrates the basics of connecting to MySQL via C using the MySQL C API. the book gives an all-too-brief whirlwind tour to the basics of MySQL. The next four chapters are a tutorial on how to use GTK+ and GLADE, focusing on how these toolkits are similar and different from their Visual Basic counterparts. GTK+ was chosen in this book because of its cross-platform compatibility with both Windows and Linux / UNIX operating environments. The second part of the book takes what was learned about MySQL and GTK+ with GLADE and uses it to create a stand-alone application (a real-world order-entry application). What's Good? Throughout MySQL: Building User Interfaces, Stuckey describes exactly what he is doing and why he is doing it that way. The introduction to GTK+ in the first part of the book describes just about every GTK+ widget available (menus, buttons, sliders, status bars, etc.), and creates a monster busy-box application (not to be confused with the busy-box application by Bruce Perens) demonstrating those widgets by themselves. Later in the book Stuckey uses Glade to put applications together, but not using Glade early on gives the reader a chance to see what is happening under Glade's abstraction. During the building of the order-entry application, Stuckey explains the design decisions behind the widgets. Each window of the application is introduced first with a diagram describing where the widgets will be followed by the code for each widget. The design looks like a Visual Basic application designed by a a programmer, with an eye toward the functional rather than the aesthetics of user interface design, but as an introduction to GTK+ programming it works well. What's Bad? If there was ever a book that required a CD-ROM to accompany it, this book gets my nomination. Authors have to walk a fine line between presenting code snippets that don't make sense by themselves, or risk boring readers with page after page of code that might confuse readers who aren't yet ready to view full code listings. MySQL: Building User Interfaces chose to include the full code listing for everything. This is both a blessing and a curse: readers have the code right in front of them and don't have to worry about being in front of a computer while reading the book, but the flow of the book is interrupted every time something is introduced.

The descriptions also suffer, because those code listings are expected to explain in more detail what is going on. In the GTK+ introduction, widgets are introduced with short paragraph introductions. The real-world application, which should be the focus of the book, reads like an assembly line: A screen is introduced, the widgets are placed, and the code is listed. Worse, files which make little sense without a computer (such as files generated by glade) are presented along with the code listings. This makes reading this book a chore. Thankfully, there is an FTP site with the code ready to use, but future versions of this book would be best served to include it on disc.

Perhaps a balance can be struck in a future edition where important code concepts are highlighted without sacrificing seeing the code in a meaningful context.

So, what's in it for me? Windows programmers who need a hand in getting their applications to Linux or UNIX may find this book helpful (but overwhelming) as they learn. This book stands out as a bridge for Windows programmers to make their transition to Linux and UNIX smoother, but the emphasis and amount of code listings in this book may make Windows programmers choose a different route.

You can purchase MySQL: Building User Interfaces from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

tdrury writes " Embedded Ethernet and Internet Complete , by Jan Axelson, is targeted towards the professional as well as the hobbyist embedded system designer who wants to further extend his communication options from traditional serial (RS-232, RS-455) communications to Ethernet. Axelson had been an author for Circuit Cellar magazine, and I have always enjoyed her articles, which tend to cover embedded communications of one type or another. (Axelson authors a set of Complete books including ones covering serial, parallel, and USB communication.)" Read on for the rest of tdrury's review. Embedded Ethernet and Internet Complete author Jan Axelson pages 482 publisher Lakeview Research LLC rating 9 reviewer Tim Drury ISBN 1931448000 summary Designing with Ethernet in embedded systems.

Axelson's writing style is a little difficult to describe. At times you feel you could be reading a "For Dummies" (TM, Patent Pending, Please Don't Sue Me) book since her writing style is so easy to digest, but simultaneously, she's covering quite a bit of depth and breadth which you expect from a more advanced volume. This seems paradoxical yet the point stands: you will retain what you read from Axelson.

Contents

The networking basics sections describes the network protocol stack (Ethernet, TCP, UDP, and IP frames), collision mediation, and how to use a sniffer (Ethereal in her case). It's of moderate detail suitable for an introduction. Much more detail is provided in later sections. Axelson also uses this section to describe, in good detail, the Ethernet media access control scheme that arbitrates which device talks when and how to handle packet collisions.

These network hardware sections are an in-depth description of cabling (Cat-5, fiber, wireless, etc.) which includes bit rate, max lengths, encoding types, etc. She also includes a small section on building your own Cat-5 for you really cheap Joes. There is a cursory review of hubs, switches, and routers and the network architecture limitations imposed by each for each type of network cabling.

Axelson goes on to describe some common embedded systems including TINI (Java-based) and Rabbit (C-based), which are the two systems she uses and provides examples for. Thankfully, keeping with her Circuit Cellar hobbyist tradition, both of these systems are very affordable to the casual hobbyist. She also provides detailed descriptions of some common Ethernet chipsets down to the registers (at least for the ubiquitous NE2000 registers). Also included are schematics for typical interfaces to these chipsets for the reader who wishes to build his own Ethernet-aware embedded system.

The Internet basics sections describe the various connection solutions such as dial-up, DSL, and satellite and the benefits and limitations of each. Axelson provides a cursory discussion of firewalls, domain naming and DNS, URL dissection, DHCP, NAT, ARP, and ICMP. These sections, I believe, are suitably informational for the embedded system designer, but not exhaustive. She then launches into an in-depth discussion of IP addressing and the IPv4 header which, in my opinion, is required for anyone working at the packet level. Axelson uses some data from Ethereal to support her discussion of IPv4. She also reminds us that Ethernet communications need not use the full TCP or UDP stack but can, if desired, use only IP-wrapped packets or even just Ethernet frames to communicate.

We finally get to some real code in the TCP/UDP socket communication sections. Axelson begins with samples of UDP, then TCP, socket communications. She bounces back and forth between Rabbit C code and TINI Java code. Both sets of examples are properly threaded so as to be more than just academic-example hogwash. Then she delves into the details of UDP and TCP, beginning with descriptions of the frame headers, then concludes with handshaking/flow-control (SYN-ACK and so forth). She includes suggestions for other books that continue even deeper into socket communications which is very nice especially since they aren't gratuitous promotions from the same publisher. (They are, in fact, from two different publishers.) By the way, Lakeview Research is her own company, so Axelson self-publishes. Nice.

Fully half of the book is dedicated to describing the top layer of the protocol stack: applications. Specifically, HTTP client and server, receiving and sending email, and FTP client and server. The HTTP samples leverage the bundled TINI and Rabbit libraries to serve web pages. Axelson also includes examples of running a third-party servlet engine (Tynamo) on the TINI system. Similarly, the sections for sending and receiving email and the FTP client/server leverage the bundled libraries of Rabbit and TINI. I find this appropriate -- why write low-level socket code when there are available libraries that perform all the grunge work for you? If you do need to modify the support libraries, the Rabbit Dynamic C source code is available, but the TINI Java library source code is not.

The last few sections of the book discuss security. Axelson doesn't leave security as a footnote, as she does include sample code for basic authentication, but she also doesn't give security the depth she provided the other topics. Sure, security is a huge topic which would take numerous volumes to cover, but I thought this section could use a little more detail. I would like to have seen example code in the sections on encryption (both symmetric and asymmetric). I would like to have seen what is required to enable SSL in the web server examples. If these were not to be provided, I would have like to have her cite other books which would have completed her discussion as she did in the raw socket communications sections.

What Could Be Improved

I don't really like the large font and spacing used in this book; I prefer a more condensed text which probably would have reduced the book size some 20% or so. But as I think about it, perhaps this is one characteristic that make Axelson's books so easy to read: there is little eye-strain.

In the hardware sections, I would like to have seen even a trivial example of an NE2000 device driver. It wouldn't even have to be an Ethernet-compliant driver, just something that demonstrates sending and receiving with flow and error control. This would be useful if you were building your own device which didn't include a protocol stack.

In the low-level socket communications sections, I would have preferred to see two things. First, I would have liked to see a test program that communicated between the C-based Rabbit and the Java-based TINI to demonstrate a heterogeneous distributed embedded system. Second, I would have like to seen an echo test program. When prototyping communications to any embedded system I always write an echo test program which begins by transmitting a small message with a numeric value, then listens for messages, increments their value, and sends them back out. Validation testing is performed during this process. This program is easy to write and a great diagnostic tool.

Conclusion

Since this is my first book review I can't objectively give it an absolute rating like 4 stars or 8/10 since you have nothing to compare my judgment to. However, I can say that this book is well worth the money spent which, all too often, isn't the case anymore these days. I think Axelson has struck an ideal blend of detail where needed and summary when detail is not required. The book is organized well and should satisfy both the casual bathroom reader and the rigorous, horribly-cracked-binding, lab-bench-reference reader.

I like Axelson's writing style; it's an ideal blend of assume I'm an idiot-style when you need it and in-depth when you want to dig. Another great point: she doesn't stuff the appendices with data sheets, API documentation, or command syntax references. All those can be found on-line and have no place in a book, where they quickly become dated. If you absolutely must have a definite rating, then I'd give it an 8 or 9 out of 10. I would place books like Stevens' Unix Network Programming at a solid 10 and about 99% of the other books out there around a 5.

You can purchase Embedded Ethernet and Internet Complete from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

honestpuck writes "It is refreshing to find a book that is totally honest about the drawbacks of the language it hopes to teach. AppleScript: the Definitive Guide is one such volume. Matt Neuburg delves into all the flaws inherent in this language." Read on for the rest of honestpuck's review. AppleScript - the Definitive Guide author Matt Neuburg pages 476 publisher O'Reilly and Associates rating 8 - Well written, good topic coverage, some flaws reviewer Tony Williams ISBN 0596005571 summary Excellent guide

AppleScript as a language and development environment has some terrible problems, and I applaud Neuburg for not trying to hide them away. Personally I love the power the language can provide, while loathing it for it's "English-like" syntax and the problems inherent in having most of the language defined in differing ways in different applications.

One of Applescript's problems is that it is difficult to teach, as you almost have to understand everything before you can know anything. Unfortunately that problem is reflected in this book. Neuburg constantly finds himself having to resort to the "believe me for now, I'll explain later" strategy throughout the book.

The book is broken up into four sections: "AppleScript Overview," "The AppleScript Language," "AppleScript In Action," and several appendices.

"AppleScript Overview" is a well written look at what AppleScript is, what it is good for and how to use it. Chapter 3, "The AppleScript Experience" is an impressive warts-and-all walk-through of the author developing an AppleScript to solve the problem of renaming files to conform to a particular standard using FrameMaker and the Finder. It is here that the reader will first see the problems inherent with AppleScript as Neuburg battles with incomprehensible dictionaries, unknown object models and uncommunicative error messages to build his script.

Part II, "The Applescript Language," is the 200-page core of this book. Neuburg provides a detailed and comprehensive look at every detail of AppleScript's syntax and semantics. The first chapter of this section, "Introducing AppleScript" contains a marvelous section entitled 'The "English-likeness" Monster' that is a short, sharp (and entirely justified) attack on the problem of AppleScript's attempt to be English-like in syntax.

In the rest of this section Neuburg provides an exceptional survey of the language. I personally appreciated his examination of the intricacies of type coercion and the exotic scoping rules. He has also taken the time to write and elaborate a large number of small pieces of code to demonstrate gotchas and tricks throughout the language.

It is this section that truly separates this book from every other AppleScript book I have previously read -- it is a masterful guide to the language.

Part III is a concrete path towards writing your own scripts. Neuburg starts by examining application dictionaries in depth. The real power of AppleScript lies not in the language itself but in the ability to use language extensions built in to other applications. This also becomes a huge flaw when the only documentation you get is in the application dictionary. As Neuburg puts it "One purpose of the dictionary is to show the human user how to speak AppleScript to a scriptable application in order to drive that application. But a dictionary, by its very nature, is not completely adequate to this task." He then goes on to explain the flaws.

The first appendix is a dump of the AppleScript Suite from AppleScript's 'aeut' resource. This is the core of the language usable everywhere. The second Appendix is a good, useful guide to tools and resources for the AppleScript programmer.

Taken as whole, this is a great book for the AppleScript programmer, both beginner and expert. It has a good writing style, has been well edited and well constructed. Neuburg may be putting in too many forward references, though. Other reviewers, particularly those newer to AppleScript, have called the book frustrating and confusing. I think this may be due to both the high information density in this book and Neuburg's fast introduction to topics that are better explained later in the book. If you are a newcomer to programming and AppleScript then this may be daunting.

If you are new, however, this is still an excellent volume but you may have to force yourself to finish it and then go over at least Part I and II again to truly understand the language. It would probably be a good idea to start trying to build your own scripts after the first read through. I must say, that after taking a good hard look at the way the book has been constructed and ordered I couldn't really come up with a better way that wouldn't have doubled the size of the book.

Visit the O'Reilly web page for the book if you would like to see the Table of Contents or grab an example chapter.

Neuburg has said "My approach is not to rely on documentation, ... but to bang away at the language itself, testing and experimenting, trying to deduce the underlying rules" and this approach has certainly borne fruit in this volume. For all it's minor flaws you cannot say, as may be true of many other tech books, that it is a rewrite of the documentation. He has approached the problem from a different direction and given us a book that offers an excellent guide to the language.

I would recommend it to all Macintosh owners as the perfect way to unleash another powerful aspect of your system. For people who have no AppleScript or programming experience who want to be totally spoon fed this book is probably only a 5, for people with a little AppleScript experience, a fair amount of programming experience and a willingness to stick through to the end this book is probably a 9. It is certainly the best book on AppleScript I have seen.

You can purchase AppleScript - the Definitive Guide from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Alex Moskalyuk writes "Before Sun monopolized the notion of 'write once, run everywhere,' those who enjoy programming in C++ had the choice of using Qt libraries that provide cross-platform GUI support. C++ GUI Programming with Qt3 is written by the employees of TrollTech, the company that created and currently distributes the Qt environment." Read on for the rest of Alex's review. C++ GUI Programming with Qt 3 author Jasmin Blanchette, Mark Summerfield pages 464 publisher Prentice Hall PTR rating 9 reviewer Alex Moskalyuk ISBN 0131240722 summary Practical introduction into GUI programming with Qt

The first question that came to mind when I got this book - is there any need for it? Qt's Documentation is detailed and extensive with how-to's and an API reference available online for free. I have done GUI development in .NET (with C#) and Tk (with Perl) environments, and even though I've never tried Qt, the site with tutorials looked like a sufficiently good resource to start.

However, after getting through the first few chapters, religiously trying out the code, my opinions on whether a separate book is needed have changed. Jasmin Blanchette and Mark Summerfield's book can take a sufficiently clueless newbie with some C++ knowledge and guide him through the intricacies of GUI building, providing practical advice and some bits of experience on the way. You learn about the practicality of this book by turning to page 3 (with page 1 being the title) and seeing a code example as the second paragraph of the first chapter. Writing a basic GUI application in C++/Qt is attractively easy, to win you over and make you read the rest of the chapter, as well as finish the basic introduction by creating a windowed application with SpinBox and Slider widgets.

The table of contents is available on the publisher's Web site and looks fairly simple. Each chapter takes about 20-30 pages, with screenshots and code examples provided as part of the text. Reading the first 5 chapters, which comprise the "Basic Qt" section and take up 110 pages, should be enough for any C++ developer to build a sufficiently complex GUI application if all that's required is some graphical interface slapped on top of the functionality that's already there.

The rest of the book -- "Intermediate Qt" chapters -- take the reader into the common problems of GUI development, providing some insight into more advanced topics as well. Supporting networking, working with graphics and images, internationalization of the software application, interacting with help, reading XML through SAX and DOM APIs, accessing databases and doing inter-process communication are all covered here. The authors tended to avoid inserting huge amounts of reference material into the book, and, for example, in the XML chapter when working with Unicode you will be told to go online and download the numeric values of the Unicode characters instead of dedicating valuable book pages to it.

The language of the book is simple to follow; there are plenty of code examples (with discussion following each), and when the authors make certain choices, they also explain why. The diagrams and screenshots are clear (although not in color), and the code examples can be easily separated from the text. This is the first official TrollTech guide to Qt 3.2 programming, and the authors promise that the techniques will work with Qt 4.

Perhaps part of the positive impression that this book left is the fact that programming in Qt is easy and straightforward. At the early stages of my education, I started learning GUI programming with MFC, which left an indelible image of complexity and will probably increase psychiatrist bills in the future (to be fair to Microsoft, Windows Forms with .NET is a huge step forward). The book and the Qt library made some complex things sound quite simple and enjoyable to program. As Matthias Ettrich notes in the foreword to this book, the most important point in reasoning why Qt is so popular is "because programmers like it."

The book comes with a CD that contains non-commercial version of Qt 3.2 for Windows/Mac/Linux, Borland C++ 5.5 (Non-Commercial) and trial version of Borland C++ 6.0 compilers, SQLite database engine and book source code. The non-commercial version of Qt 3.2 for Windows can be installed for Borland C++ 5.5, Borland C++ 6.0, Microsoft Visual C++ 6 and Microsoft Visual C++.NET environments. The examples are quite conveniently located in folders with chapter numbers, followed by subfolders with example names.

Whether you're looking for general introduction to GUI development with C++ or trying to learn Qt, having worked with other libraries and toolkits before, this book is a good source of practical information and reference. The book is part of Perens' Open Source Series.

Alex Moskalyuk enjoys reading and reviewing books on programming and tech industry in general. You can read his other reviews on his personal site. You can purchase C++ GUI Programming with Qt 3from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

honestpuck writes "Computer magazines come and go at an unrelenting pace. The Perl Journal was one of the better ones before Jon Orwant, the editor and publisher, passed it to CMP. It is therefore pleasing to find he has taken all the articles published over the five year period, removed the chaff and published the rest in three volumes." Read on for honestpuck's lowdown on what you can expect in this set. Computer Science & Perl Programming author Jon Orwant (Editor) pages 710 publisher O'Reilly and Associates rating 8 (7 and 6 for other vols) - Well written, some flaws reviewer Tony Williams ISBN 0596003102 (0596003110 and 0596003129 for other vols) summary Well edited compendium of magazine articles on Perl

All three volumes reveal a good hand at choosing articles and editing the contributions; after spending three years as a magazine editor I know that not all the contributors could have written this well. The writing is consistently good, tight, well edited and readable.

Across them all you will find articles by almost every major contributor to Perl and a great many of the people who have contributed major modules to CPAN. It's good to feel that perhaps a few cents from your book purchase is flowing into each of these pockets and repaying their work.

Viewing the 3 books as a whole my one real concern is that perhaps a little tighter restrictions on the article choice may have been better -- some of the articles are really only of historical interest, discussing methods overtaken by further development in Perl or the modules available. You may also find only one or two of the volumes contain articles of particular interest to you, I discovered that my favourites were spread across all three and bemoaned the semi-arbitrary division of topics as I only closely read about two books worth from the three volumes -- of course your milage may vary.

The first and largest volume, Computer Science & Perl Programming, is the one volume where I read and enjoyed almost every one of the seventy articles (by 41 different authors) included. The topics covered vary widely, from an essential trilogy of articles about regular expressions by Jeffrey Friedl to some esoteric discussion of Perl internals by Chip Salzenburg.

The second volume, Web, Graphics and Perl/Tk, contains 39 articles, around half of which are devoted to topics such as mod_perl, spidering, and other web stuff. Here is where you can find yourself reading an article about topics now made redundant by changes to Perl and its modules. The graphics section is an eclectic mix while the Perl/Tk section adds up to a fairly good tutorial on the topic.

The third volume, Games, Diversions and Perl Culture, collects 47 articles on a broad range of topics: 15 of them are about various sorts of language processing in Perl that I found extremely interesting. It also includes the Obfuscated Perl Contests, the Poetry Contest and a bunch of other "silliness." An article on how the magazine's covers were photographed seemed particularly pointless.

I'd recommend the first volume for almost anyone interested in Perl. The second might be worth purchasing if you wanted the web coverage. The third is worth it if you want the coverage of language processing or have an interest in the culture that surrounds Perl. Check the O'Reilly pages for one, two and three to see the tables of contents, index, grab the code examples and download a sample chapter (the third volume has two example chapters.) I've given the first volume an 8 but the other two get 7 and 6 respectively as the article choices make them less useful, though the quality of writing and editing is as good.

I think all three would be a marvelous addition to any decent tech library - they seem perfect for a library as they have all the benefits of a five year collection of TPJ without the problems of magazine storage, cataloging and conservation. For everyone else, grab the first one and then decide based on the content for the other two.

You can purchase Best of the Perl Journal (Volume 1, Volume 2, Volume 3) from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

honestpuck writes "Computer magazines come and go at an unrelenting pace. The Perl Journal was one of the better ones before Jon Orwant, the editor and publisher, passed it to CMP. It is therefore pleasing to find he has taken all the articles published over the five year period, removed the chaff and published the rest in three volumes." Read on for honestpuck's lowdown on what you can expect in this set. Computer Science & Perl Programming author Jon Orwant (Editor) pages 710 publisher O'Reilly and Associates rating 8 (7 and 6 for other vols) - Well written, some flaws reviewer Tony Williams ISBN 0596003102 (0596003110 and 0596003129 for other vols) summary Well edited compendium of magazine articles on Perl

All three volumes reveal a good hand at choosing articles and editing the contributions; after spending three years as a magazine editor I know that not all the contributors could have written this well. The writing is consistently good, tight, well edited and readable.

Across them all you will find articles by almost every major contributor to Perl and a great many of the people who have contributed major modules to CPAN. It's good to feel that perhaps a few cents from your book purchase is flowing into each of these pockets and repaying their work.

Viewing the 3 books as a whole my one real concern is that perhaps a little tighter restrictions on the article choice may have been better -- some of the articles are really only of historical interest, discussing methods overtaken by further development in Perl or the modules available. You may also find only one or two of the volumes contain articles of particular interest to you, I discovered that my favourites were spread across all three and bemoaned the semi-arbitrary division of topics as I only closely read about two books worth from the three volumes -- of course your milage may vary.

The first and largest volume, Computer Science & Perl Programming, is the one volume where I read and enjoyed almost every one of the seventy articles (by 41 different authors) included. The topics covered vary widely, from an essential trilogy of articles about regular expressions by Jeffrey Friedl to some esoteric discussion of Perl internals by Chip Salzenburg.

The second volume, Web, Graphics and Perl/Tk, contains 39 articles, around half of which are devoted to topics such as mod_perl, spidering, and other web stuff. Here is where you can find yourself reading an article about topics now made redundant by changes to Perl and its modules. The graphics section is an eclectic mix while the Perl/Tk section adds up to a fairly good tutorial on the topic.

The third volume, Games, Diversions and Perl Culture, collects 47 articles on a broad range of topics: 15 of them are about various sorts of language processing in Perl that I found extremely interesting. It also includes the Obfuscated Perl Contests, the Poetry Contest and a bunch of other "silliness." An article on how the magazine's covers were photographed seemed particularly pointless.

I'd recommend the first volume for almost anyone interested in Perl. The second might be worth purchasing if you wanted the web coverage. The third is worth it if you want the coverage of language processing or have an interest in the culture that surrounds Perl. Check the O'Reilly pages for one, two and three to see the tables of contents, index, grab the code examples and download a sample chapter (the third volume has two example chapters.) I've given the first volume an 8 but the other two get 7 and 6 respectively as the article choices make them less useful, though the quality of writing and editing is as good.

I think all three would be a marvelous addition to any decent tech library - they seem perfect for a library as they have all the benefits of a five year collection of TPJ without the problems of magazine storage, cataloging and conservation. For everyone else, grab the first one and then decide based on the content for the other two.

You can purchase Best of the Perl Journal (Volume 1, Volume 2, Volume 3) from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

honestpuck writes "Computer magazines come and go at an unrelenting pace. The Perl Journal was one of the better ones before Jon Orwant, the editor and publisher, passed it to CMP. It is therefore pleasing to find he has taken all the articles published over the five year period, removed the chaff and published the rest in three volumes." Read on for honestpuck's lowdown on what you can expect in this set. Computer Science & Perl Programming author Jon Orwant (Editor) pages 710 publisher O'Reilly and Associates rating 8 (7 and 6 for other vols) - Well written, some flaws reviewer Tony Williams ISBN 0596003102 (0596003110 and 0596003129 for other vols) summary Well edited compendium of magazine articles on Perl

All three volumes reveal a good hand at choosing articles and editing the contributions; after spending three years as a magazine editor I know that not all the contributors could have written this well. The writing is consistently good, tight, well edited and readable.

Across them all you will find articles by almost every major contributor to Perl and a great many of the people who have contributed major modules to CPAN. It's good to feel that perhaps a few cents from your book purchase is flowing into each of these pockets and repaying their work.

Viewing the 3 books as a whole my one real concern is that perhaps a little tighter restrictions on the article choice may have been better -- some of the articles are really only of historical interest, discussing methods overtaken by further development in Perl or the modules available. You may also find only one or two of the volumes contain articles of particular interest to you, I discovered that my favourites were spread across all three and bemoaned the semi-arbitrary division of topics as I only closely read about two books worth from the three volumes -- of course your milage may vary.

The first and largest volume, Computer Science & Perl Programming, is the one volume where I read and enjoyed almost every one of the seventy articles (by 41 different authors) included. The topics covered vary widely, from an essential trilogy of articles about regular expressions by Jeffrey Friedl to some esoteric discussion of Perl internals by Chip Salzenburg.

The second volume, Web, Graphics and Perl/Tk, contains 39 articles, around half of which are devoted to topics such as mod_perl, spidering, and other web stuff. Here is where you can find yourself reading an article about topics now made redundant by changes to Perl and its modules. The graphics section is an eclectic mix while the Perl/Tk section adds up to a fairly good tutorial on the topic.

The third volume, Games, Diversions and Perl Culture, collects 47 articles on a broad range of topics: 15 of them are about various sorts of language processing in Perl that I found extremely interesting. It also includes the Obfuscated Perl Contests, the Poetry Contest and a bunch of other "silliness." An article on how the magazine's covers were photographed seemed particularly pointless.

I'd recommend the first volume for almost anyone interested in Perl. The second might be worth purchasing if you wanted the web coverage. The third is worth it if you want the coverage of language processing or have an interest in the culture that surrounds Perl. Check the O'Reilly pages for one, two and three to see the tables of contents, index, grab the code examples and download a sample chapter (the third volume has two example chapters.) I've given the first volume an 8 but the other two get 7 and 6 respectively as the article choices make them less useful, though the quality of writing and editing is as good.

I think all three would be a marvelous addition to any decent tech library - they seem perfect for a library as they have all the benefits of a five year collection of TPJ without the problems of magazine storage, cataloging and conservation. For everyone else, grab the first one and then decide based on the content for the other two.

You can purchase Best of the Perl Journal (Volume 1, Volume 2, Volume 3) from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Argyle writes "I recently finished reading The Golden Transcendence by John C. Wright. A great novel that serious science fiction readers should pick up. The Golden Transcendence is the third book in The Golden Age trilogy. The first two books were The Golden Age and The Phoenix Exultant." Read on to see if this series might be for you; if so, you're just in time, because author John C. Wright (a retired attorney) is working on the next book, Orphans of Chaos. The Golden Transcendence : Or, The Last of the Masquerade author John C. Wright pages 350 publisher Tor Books rating Excellent reviewer Michael Pusateri ISBN 0765307561 summary Can the determination of an individual change the entire society?

The books are firmly in the space opera genre with a dash of Heinlein libertarianism tossed in for good measure. The story takes place in the far future when artificial intelligences (known as sophotechs) and humans live immortal lives in a libertarian society of near unlimited technology. The experience of real physical interaction is replaced in many cases by remote bodies, recorded experiences of others, and complete control of what a person perceives. Humanity has moved beyond the one body - one brain system and has adopted many different systems of thought and even physical form

Mr. Wright puts forth a brilliant vision of technology and society in the far future where wealth is measured in seconds of computer time and physical labor is non-existent. In this future, there is are still wealthy and poor people but in a different way. In a good interview, Mr. Wright explains:

There would still be rich and poor, even if the poorest of the poor were absurdly well off by our standards. No advancements can eliminate differences in the abilities of men, or the differences in how men value the abilities of their fellow man (which is what causes inequality of prices and hence of incomes). If only by comparison, there will be poverty, even in Arcadia. My characters Ironjoy, Oshenkyo, and the Afloats [...] are meant to represent this idea of future poverty; the Seven Peers represent wealth.

As an example as just one of the concepts presented, we can look at the idea of 'sensefilters.' Perception is no longer what organic senses directly tell the mind. The signals received by the body or remote bodies are processed to be acceptable to the person's particular preferences. If a person doesn't like to see advertising, their mind eliminates the advertising from their vision and fills in the scene with what would be there if the advertisement wasn't there. Consciously, the person isn't aware of this, only that they have requested not to see advertisements. Sensefiltering can be used to remove (or add) objects, people, and even ideas from an individual's perception. The plot devices are interesting stuff that Mr. Wright explores in just enough detail to keep you wanting more throughout the trilogy.

The protagonist, Phaethon, is the son of one of the most important people in the society (known as the Golden Oecumene). In the first two books, Phaethon struggles against first the realization that he is missing parts of his memory, his struggle against society, his fall into exile, and his return to strength.

The third book finds Phaethon poised to fight against the true enemy that has been revealed to him. Without spoiling too much, Phaethon is forced to fight for the very survival of his society (which tossed him out) or allow it to be destroyed.

The author, John C. Wright, obviously has a libertarian heart and embodies the attributes of individuality, resourcefulness, ingenuity and desire for progress in Phaethon, the hero. In the opening novel, we find a society content with things how they are, willing to simply stop progress to prevent anything from changing their utopia in any meaningful way. Phaethon is a man of action in opposition to the statist Golden Oecumene. The underlying theme is that without mankind's strive for exploration and new goals, it is doomed.

Overall, an excellent book and series for the science fiction reader looking for something more than blasters and evil six-legged aliens. Getting used to the terminology and concepts is slow at first but well worth the effort.

Final note: If you enjoy Iain Banks's Culture series, Peter Hamilton's Night's Dawn, or John Varley's Eight Worlds, you will enjoy the The Golden Transcendence and the entire Golden Age Trilogy.

You can purchase The Golden Transcendence from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Michael Bennett Cohn writes "Cisco Press' CCNA Self-Study Certification Library by Wendell Odom consists of two books: the ICND guide and the INTRO guide, corresponding to tests 640-811 and 641-821, respectively. Passing each of those tests will make you a CCNA; so will passing combined exam 640-801. I passed exam 640-801 in one try, with no real networking experience and having taken no classes. The ICND and INTRO books comprised my primary training materials." To sort out a bit of that alphabet soup, CCNA stands for "Cisco Certified Network Associate" and ICND for "Interconnecting Cisco Networking Devices," though if you're in the market for this book you probably already knew that. Read on for the rest of Michael Bennett Cohn's review. Self-Study Certification Library author Wendell Odom pages 1232 (combined) publisher Cisco Press rating 6 reviewer Michael Bennett Cohn ISBN 1587200953 summary Useful but annoying; Decent study materials for Cisco tests 640-811 and 641-821.

Although it is possible to enroll in official ICND and INTRO courses created by Cisco, the books that make up this "library," apparently, are not the books used in those courses. Within the ICND book, Odom refers to "the ICND course, on which the exam is partly based," suggesting that what you have in your hands is a reverse-engineered study guide: a study guide for an exam that is based on a course that does not use said book. Odom occasionally presents tables that he claims come from the ICND course. Clearly, some parts of the course are not fair game for the study guide.

In other words, don't think that just because you are reading the official Cisco press CCNA study guides, you are dealing with a set of information that is as close as possible to the set of information from which the test was drawn.

Studying these books will prepare you for the CCNA in the same way that reading the Encyclopedia Britannica from A to Z will prepare you to identify the capital of Nairobi. It goes without saying that a CCNA candidate should not be studying just to pass a test, she should be studying to qualify herself for a job. But in this case, the difference between the material presented and the material actually making up the test is excessive.

Odom goes to a lot of effort to make the reader feel like he is being spoken to by a friend. "Fun, isn't it?" he writes, after presenting an illustration of function groups and access points that I had to re-draw for myself several times in order to understand. Later, he describes Inverse ARP as "another case of learning by listening, a great lesson for real life!" Gee, thanks. The subtle condescension in the non-humorous asides, the gleeful overuse of exclamation points, and the fable in which Pebbles Flintstone invents networking is compounded by the persistent contextual encapsulation of every single topic in the book. Odom tells you what he's going to tell you, then he tells you, then he tells you what he's told you, much more than necessary.

A better way to put the flustered reader at ease might have been to proofread the books. The ICND guide, especially, is so full of typos that it is often embarrassing to read. In some cases, these are nothing more than obvious misspellings that can be passed over without much more than a little annoyance (e.g. ICND p. 472, "status enquiry messages"). In other cases, the meaning of the sentence is muddled. Worse, the configuration examples have obviously not been proofread either, resulting in, for example, the prompt "R1(config)#" when the appropriate prompt is "R1(config-if)." The difference may seem trivial, but understanding its significance is the kind of stuff the CCNA is all about.

Each book comes with a CD containing a practice test engine and a router simulator (both from Boson). The mistakes in the ICND book pale in comparison to those in the CD test engines. In fact, an argument could be made that studying with those practice tests will hinder more than help the CCNA candidate who has not read the books thoroughly enough to recognize the mistakes. Many multiple-choice questions count correct answers wrong and vice versa (and some of these are taken directly from the books, which usually give the correct answer). A configuration entered into the CLI on a simulator question will be graded as wrong, and the user will then be presented with an identical configuration as an example of the correct way to solve the problem.

None of these problems change the fact that these books will, if used correctly, absolutely help you pass the CCNA. But do it this way: Read the INTRO book. Take the exam right away. If you don't pass, flip through the ICND book and find the areas that you actually need to work on. You'll save months of study time that could be better spent working on your CCNP.

I give the library as a whole 3 out of 5 stars.

You can purchase the CCNA Certification Library from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Ursus Maximus writes "Eagerly awaited by many, this book reached bookstores just after Christmas, and updates the 1999 edition. Learning Python is O'Reilly's introduction to Python programming and at 591 pages, this is a major upgrade to the 366 page original. Furthermore, the Python language has undergone extensive improvements and additions in the last five years, and the new book does a good job of covering these changes." Learning Python 2nd Edition author Mark Lutz & David Ascher pages 591 publisher O'Reilly & Associates, Inc. rating 10 reviewer Ursus Maximus ISBN 0596002815 summary An introduction to Python programming

Python is a dynamic, interpreted, object oriented language used for both scripting and systems programming. Python is known for being easy to learn and use, while also being powerful enough to be used for such projects as Zope and the Chandler project. Its growing popularity is also based on its reputation for fostering programmer productivity and program maintainability. One drawback sometime cited is its relatively slow execution speed compared to compiled languages such as C.

For myself, I have probably read too many books about Python, but that is because I am an amateur hacker who learns programming slowly, and I find that reading several books about the same topic, covering the subject matter from different angles, allows me to better absorb the material. For me, this was a good review of the core language and a welcome refresher course on the newer aspects introduced in versions 2.2 and 2.3. For anyone who is new to Python and wants to learn from the ground up, this book would be a great place to start.

Mark Lutz is an authority on Python and one if its leading teachers, with both Learning and O'Reilly's Programming Python to his credit, as well as the courses and seminars he teaches professionally. In updating the original version, which was already very good, Mark has polished the chapters on the core language to a nearly perfect level, while his co-author David Ascher has done the same on the more advanced aspects of the book. In addition, Mr Lutz has benefited from extensive feedback from students and readers, and his explanations therefore anticipate common misunderstandings. Each chapter is accompanied by a problem and exercise section and answers are included at the back of the book.

A major addition to the new edition is a chapter on "Advanced Function Topics," including list comprehensions, generators and iterators. Python is sometimes used with a functional programing style almost similar to Lisp, although to List purists that may sound like heresy. The recent versions of the language have significantly upgraded Python's support for the functional style. Functions cover three chapters in the 2nd edition instead of just one.

Another major change since the first edition is extended coverage of Modules, which now occupies four chapter instead of just one. Python modules are a high level package structure for code and data, and they help facilitate code reuse. Yet another addition is coverage of Python's "new style classes." Coverage of classes and object oriented programming has been greatly expanded and now includes five whole chapters and almost 100 pages. Coverage of exceptions now is expanded to three chapters.

If you have been considering learning Python, now would be a great time since this new book is the perfect introductory text. If you already know Python and have read the first edition of Learning Python or another introductory text, then this book may not be essential since the new language features are covered pretty well on the web in various places, and you might be better advised to read one of the other fine books on non-introductory aspects of Python. But this book is about as good an introduction to the language as you are likely to find. The book does not cover all of the Python libraries nor many other topics, but it does briefly touch on the major libraries, frameworks, gui toolkits, and community resources.

If you want to learn the core Python language quickly, this may be your best bet. Learning Python only covers the basics, but it is deep in information on what it does cover. Well written, understandable, and in a very logical arrangement, this book is densely packed with info.

I have often found myself returning to the original book, and the new book will now fill this role. It is deep in information, well written, and a joy to read. For an experienced programmer who is just learning Python, it may be possible to thoroughly learn everything about the core language in one reading of this book. For relative newbies, it will be an often-used resource.

To read more reviews of books about Python, visit the Python Learning Foundation. You can purchase the Learning Python, 2nd Ed. from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

emmastory writes "It shouldn't really surprise anyone that David Pogue has once again produced an unqualified success in the third edition of Mac OS X: The Missing Manual. Since OS X came out, I've read and reviewed some dozen Mac books, but when it comes time to pick a single volume to recommend to friends making the switch, I invariably choose Pogue's. It's true that OS X beginners can understand it without any problems, but that shouldn't suggest that it's somehow too simple for veteran users - it's just that the text is exceptionally clear, meaning that even beginners won't find it too scary or confusing. While other books are bigger (Mac OS X Unleashed) and others are written specifically for a more advanced audience (Mac OS X Power Tools), the Missing Manual is the best all-purpose book on the subject, and one that should be in the library of pretty much anyone who runs OS X." That answers the question of "Did she like it?", but read on for the rest of Emma's review, including a mini-interview with David Pogue. Mac OS X: The Missing Manual, Panther Edition author David Pogue pages 763 publisher O'Reilly/Pogue Press rating 10 reviewer Emma Story ISBN 0596006152 summary A must-have manual for Panther users

As I see it, there are really two groups of people who might be wondering whether or not they ought to buy Pogue's new Panther book: Mac users who own a previous edition of the Missing Manual, and those who don't. For the latter folks, the short answer is Yes - you should buy this book. And for the former, the short answer is Probably. Keeping in mind that all the various online retailers offer significant discounts on the book, and that you can also get 30% off if you've registered a previous edition with O'Reilly, it's going to only wind up costing you about twenty bucks, and it's definitely worth it. The text hasn't just been updated to reflect changes and new features in Panther - it's also been updated to reflect reader feedback on previous versions, including things like more information for people migrating from Windows, and mini-manuals on some of the iLife applications. There isn't a single page that hasn't been changed from the Jaguar edition of the book (and there are over seven hundred pages).

Some of my Mac-using friends have told me that they haven't picked up anything from the Missing Manual series because they're under the impression that they're basically novice guides. This is both right and wrong: it's absolutely true that beginners will get their money's worth from a Missing Manual and that they won't get lost in an abundance of overtechnical discussion. The part that isn't true, however, is the implication that these are books only for beginners. I've been using Macs for over ten years now (and various Unix-like systems for five), but my copies of the Missing Manuals get dog-eared and underlined more than any other technical books I own. One of the reasons I'd dispute the claim that this book isn't useful for advanced users is that sprinkled throughout are dozens of little productivity notes -- a keystroke here, a shortcut tip there -- and this is the stuff that I, at least, really get off on, while it seems like novice users tend to be content with straightforward dragging and double clicking. I dive into Part One ("The Mac OS X Desktop") with my Mac in easy reach not because I don't know how to minimize a window, but because I had no idea that (for example) there's now a Finder keystroke to jump immediately to the parent directory. That's not to say topics typically associated with power users aren't given their due, though. Even people who know their Unices (and Unix workalikes) will probably welcome the coverage of NetInfo Manager and other OS X oddities. If you find yourself stuck on some particular topic, chances are it's covered here. It's not by any means an exhaustive guide to BSD, but it's a good way to get started with Darwin. I end up using this book often enough that it has its own place of honor on top of my G4 (my other Mac books are also nearby, of course, but they're not necessarily quite so handy).

Aside from the little-bit-of-everything approach, one of the most refreshing features of the Missing Manuals series remains the writing itself - surprisingly readable, often funny, and rarely confusing. These are some of the few technical books that I'm willing or able to read cover to cover, and some of them I've even read in bed or on the subway. As for specific parts and chapters that stand out from the rest: the new mini-manuals dealing with iLife applications like iTunes and iPhoto are a welcome addition. They'd been more or less ignored in previous editions of the OS X book, since they've got their own books, but the Panther edition introduces a section on each to get you started. Another of my favorite portions of the book is the addition of Appendix F, the Master Mac OS X Secret Keystroke List. It will take a while before I'm able to memorize all of them, and in the meantime it's great to have them all collected in one place.

As for bits I didn't like? Well, I was going to complain that as someone who owned a previous edition of the book and who just upgraded to Panther, it would be nice if the "What's New in Panther" section in the Introduction were a little more fleshed out, so that I would know immediately everything that had changed. But after playing around with the new OS and reading the rest of the book, that wish seems a little impractical - after all, every page in the book had to be changed, so the entire thing is really about what's new in Panther. The section at the beginning covers the biggies (like Expos and the new security features), so that's probably all it really needs to do.

It's probably pretty clear by now that I liked the book, but I still had a few questions about Panther in general and the Missing Manual in particular. Lucky for me, David Pogue was willing to answer them for me - and here they are, in case you're wondering the same things I was:

ES: What are a couple of your favorite new Panther features?

DP: I'm just nuts about the secret buried just-for-fun features: the secret graphing mode of the Calculator; the choice of surface textures for the pieces in Chess (including Marble and Jaguar Fur!); the way you can Option-drag in Preview to copy only one column of text without snagging the adjacent column in the process. These are the kinds of grace notes that really distinguish the Macintosh from the more boring operating systems.

ES: Anything from Jaguar or earlier that you particularly miss?

DP: ALMOST all of the stuff that disappeared from Mac OS 9 has now come back into Mac OS X: labels, the clean install, spring-loaded folders, randomized desktop pictures, and so on.

A few niceties still haven't returned, though. Occasionally I miss the Put Away command, SimpleSound (for quick and dirty sound recordings), and the ability to encrypt a folder on the fly without leaving the desktop.

ES: Do you think that Apple's decision to more or less give up on writing their own manuals is a wise one?

DP: Well, as someone who's making a living filling the gap Apple left behind, obviously I have a vested interest in this point.

But the truth is, a lot of people never crack software manuals--I'm told this over and over again by software makers--and they are expensive and, more to the point, time-consuming to create. (Translation: Once the product is ready, the company wants to SHIP it--not wait around for manuals to be printed and bound.) And Apple certainly isn't alone in eliminating paper manuals.

For myself, yes, I rather wish my software programs came with printed manuals--they're infinitely superior to online help. Whether it's "wise" or not depends on whether you're a shareholder, programmer, customer, product manager...

ES: For those just switching to Mac OS from Windows, should they go for Mac OS X: The Missing Manual or Switching to the Mac? (Or both?)

DP: At this point, Mac OS X: The Missing Manual, Panther Edition. Because I haven't yet updated the Switching book to reflect Panther.

ES: What's another Mac book you'd recommend?

DP: There are many books that pick up in technological depth from where mine leave off. For example, if you're interested in digging deeper into the Unix underpinnings of Mac OS X, I hear great things about Mac OS X Unleashed. And if you want to become a Mac OS X programmer, of course, the whole O'Reilly line of Cocoa, Unix, and Java books await.

The bottom line: if you're a Panther user, you should probably pick up this book. You'll definitely be getting a lot of bang for your buck, even if you think there's nothing you don't know about Mac OS X.

You can purchase the Mac OS X: The Missing Manual from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Peter Wayner writes: "The novel Paranoia begins with one of the most tantalizing premises I've read in some time. Young Adam Cassidy was just sliding by as a junior product line manager in the router division of Wyatt Telecom, when he discovered that the company wasn't doing much for the retirement of his pal down on the loading dock. So he impersonated the VP of corporate events, faked a few invoices, and booked the same caterer who brought in the steaks and lobster for the executive suite. Alas, Nicholas Wyatt, the CEO, wasn't happy with the steep bill and gave Cassidy a choice of 20 years in prison or life as a corporate spy. In no time, Cassidy decides he's quite willing to go undercover and find out just what the heck is going on the skunk works over at their competitor, Trion." Read on for the rest of Wayner's review. Paranoia author Joseph Finder pages 432 publisher St. Martin's rating 9 reviewer Peter Wayner ISBN 0312319142 summary A fast-paced thriller about a young router engineer who is

It may be hard for anyone who's endured the economic downturn in the computer industry and the ascendance of the DRM lawyers to see the romance of tech, but the computer business continues to be one of the most exciting and explosive corners of the zeitgeist. Fortunes are made and lost in days; products depend upon the synergy of the hackers and the marketeers; and everything turns on the information passed along in IMs, emails and whispers. This world is a rich backdrop for the new thriller by Joe Finder, the spy novelist who set his previous books in the world of the three-letter agencies and the military justice system. This time he's plumbing the depths of corporate politics and industrial espionage with his story of a company racing to deliver the next big Palm Pilot replacement.

The thriller is a reminder that electronic gizmos continue to be a tumultuous and exciting domain where creative people with whip-smart minds can change the company's destiny. I suppose it would be possible to set a similar novel in, say, the auto industry, but it just wouldn't have the same resonance. No engineer, designer, or bright employee is going to make much of a difference at Ford or General Motors. Much of their future is dictated by the cost of medical care for the retired workers and the problems are not about cars qua cars. Producing great cars would be nice, but it's not the main challenge for the companies. At least in Silicon Valley, there can be some direct link between action and reaction. Newton's law still holds.

The beginning of the book is an irresistable hook. Who wouldn't want to throw a party on the corporation's dime?

Many of the elements of Silicon Valley's mythology appear here. There's a boss who keeps stable of young, blonde administrative assistants around. There's another boss who works out of the same size cubicle as everyone else. Secret research labs to develop the next generation of gadgets are locked away in a perimeter guarded by other gadgets that scan eyeballs or examine fingerprints. All of the characters drive slick cars and worry about the quality of their real estate.

As the novel unfolds, Cassidy's allegiance and soul is pulled in a tug-of-war. Who deserves the information he's gathering? Is there right and wrong in corporate espionage? Which company deserves to win?

The novel is similar in tone and structure to John Grisham's The Firm or Michael Crichton's Disclosure, two other novels that mused about the nature of the modern workplace. Finder's characters are richer and better drawn, at least than Grisham's earlier works. The search for the next gadget isn't really the point of Cassidy journey in the labyrinth, it's just an excuse to work through the modern world of corporations and the way they organize people and their creations. The book is not filled with the neo-Marxist questioning of the capitalist system that comes from places like the Baffler , but there are similar themes that echo in the cubicle bins.

This is, of course, because it's a thriller, not some postmodern master's degree thesis. The twists are well-handled, the pacing is good, and the ending may open the doors to debates. I spent some time wondering whether it was the best ending on many different levels. That kind of resolution is something that doesn't come from standard thrillers by people like Tom Clancy or James Paterson. In those books, the author's point of view is as solid and fixed as, say, those opinion shows on Fox TV. Someone's always dying or trying to destroy America in those books and stopping the murder or saving the country is the only possible resolution.

Finder's earlier books delved into the mirror world of espionage and the realm of three-letter agencies. Moscow Club focused on a coup and an assassination in Soviet Russia. Extraordinary Powers explored the possibility that various spy agencies could tap clairvoyance and other extra-sensory powers-- a premise that David Moorhouse later confirmed was very real in his book, Psychic Warrior . The world of covert assassination in Latin America took center stage in High Crimes.

The tone is also much lighter than Finder's early books, with their heavy body count. After watching the movie version of High Crimes, I kept wishing someone would write a nice comedy for Ashley Judd. She deserved it, after the blood and betrayal. This time, death isn't part of the stakes, and this leaves Finder a bit more room to maneuver and play people and allegiances off each other. Cutting down on the raw danger gives him the freedom to build suspense with action and character. The book is really a light-hearted romp through a semi-mythical world where fortunes are huge, dreams are made real through engineering, and everyone drives a slick car. I say "semi-mythical," because despite the downturn, there's still plenty of money in some corners of technology. Will it always be there? Well, that's not the point of this book.

It's worth commending Finder for his insight into the technology world. His background is more in Russian literature and spy things, not in programming. Yet, the tech world he creates is as true to life in Silicon Valley as books like Po Bronson's The First 10 Million is the Hardest and Douglas Coupland's Microserfs. Technology is a wonderful domain for a novelist to work within, and we should be glad he came in from the cold to check it out.

Peter Wayner is the author of 13 thrilling technical books on topics like building secure databases ( Translucent Databases ), steganography ( Disappearing Cryptography ), and stopping cheating ( Policing Online Games ). You can purchase Paranoia from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

honestpuck writes "While Apache is possibly the most popular and ubiquitous open source project it is certainly not the most simple. One module alone, mod_rewrite, causes me almost more problems and regex wrestling matches than all other products combined. The 'httpd.conf' file is a long and critical one. In these circumstances the Apache Cookbook from O'Reilly might be a godsend. It is certainly a well-written, well-researched volume. Ken Coar has spent many years working on Apache and Rich Bowen has long laboured on the Apache documentation. They both know their stuff -- and if this is an example, both know how to write." Read on for the rest of honestpuck's review. Apache Cookbook author Ken Coar & Rich Bowen pages 223 publisher O'Reilly rating 8 reviewer Tony Williams ISBN 0596001916 summary A broad range of Apache admin topics covered well

The book has twelve chapters, covering everything from installation and adding modules through to proxies and performance. The chapter on security is the largest, it covers the topics well. By contrast I thought the chapter 'Aliases, Redirection and Rewriting' too short and could have benefited from some more 'recipes', but that may be due to my own bias - mod_rewrite is not an easy topic, and as I've said it causes me a great deal of grief.

It is laid out in a similar way to the Perl Cookbook: each recipe has a 'Problem' section followed by a 'Solution' and then 'Discussion.' In almost all the 'recipes' the 'Discussion' is longer than the 'Solution,' and I often found it far more useful and informative than the problem and its solution.

The Apache Cookbook covers almost all aspects and all parts of the learning curve for Apache. That will either be a strength or a weakness of this volume for you; with such a large and complex piece of software as Apache a single book cannot hope to cover it in a great deal of depth. For me this book was not really a cookbook, more a good source of well documented examples from which to create my own recipes,

My biggest problem reviewing a book like this is that after several years building and configuring Apache (even on an infrequent basis) quite a lot of this volume seems simple. You may also find it the same if you are the sort of person who is not afraid to pore over the documentation, get your hands dirty and make a few mistakes. If you like some hand holding and are just starting with Apache you may benefit from all of it.

That's not to say that I didn't personally find large chunks of this volume useful. Certainly I've gone over several of the recipes and their excellent explanatory text to shed some light on previously dark corners of Apache, particularly as the authors cover both Apache 1.3 and 2.0.

O'Reilly have the usual web page with a Table of Contents and example chapter. The example chapter, on error handling is well chosen as it is typical of the others and useful but not the most useful chapter.

I have recently been thinking that tech books fall into various sorts and there is one sort I'd call 'library books' - books you may not need to own, but will want to read every so often and would be good to have in your local or company library. Apache Cookbook is one of these, a book I'd recommend everyone coming to grips with Apache has close to hand, but it is not going to be constantly on your desk in the same way that Perl Cookbook might be for Perl programmers: to start off with, it's half the size and doesn't cover nearly as many topics. This one falls short of essential due to it's concentration on breadth. rather than depth. So my recommendation for this book is not that all Apache administrators should buy it, but you should have a copy close at hand.

You can purchase the Apache Cookbook from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

honestpuck writes "One of my key concerns when reviewing a good book is the pull between information density and a light, easily read style. I believe that as we get further along the learning curve we can sacrifice some readability for density -- we want more facts and less explanation." Read on for honestpuck's take on the third edition of Core PHP Programming to see how well it achieves that balance. Core PHP Programming (3rd Edition) author Leon Atkinson with Zeev Juraski pages 1041 publisher Prentice Hall PTR rating 9 reviewer Tony Williams ISBN 0130463469 summary Good comprehensive guide for beginner to expert

The authors of Core PHP Programming have found a marvelous middle ground. Toward the beginning of the book they have a great deal of light, explanatory material as they cover the basics of PHP. As they move towards more advanced topics there is less explanation and a tighter packing of information. At the same time the book has a large number of small code examples throughout, making sure that you know how to use the functions under discussion.

This is the third edition and I must admit that I had not come across it in either the first or second editions, so I have no great way of comparing them in this review. It has certainly been revised to take into account the changes for PHP 5 and examining the table of contents for the second edition on Safari I can see the that the basic structure has remained the same while the book has grown about 300 pages. The addition of Zeev Suraski as co-author can only be to the benefit of the quality of the information, particularly regarding PHP 5.

The book starts with the absolute rock bottom of PHP, the basic data types and operators through to efficiency, debugging and design patterns. Along the way it covers almost all aspects of PHP 5 with a readable reference style. The 'Core' in the title of this book is a key to understanding it. If you're looking for a book with all the code required to handle session management, or user logins and security (to mention two possibilities) then this isn't the book for you. If, however, you are after a book that more than adequately explains the power and nuances of PHP and programming in the language then this is a marvelous volume.

It's broken up into 5 sections: "Programming PHP," which covers the basics of data, control flow and I/O; "Functional Reference," which is 600 odd pages broken up into 12 chapters that seems to cover every PHP function (a check of three sub chapters showed every function mentioned on the topic at PHP.net was also in the book) and does it well with good explanation and code examples; "Algorithms," which details a number of methods of performing routine tasks such as sorting, parsing and generating graphics; and "Software Engineering," devoted to design, efficiency and design patterns; and finally, there are a seven excellent appendices.

Taken as a whole it does a good job of covering the whole language and the ways of using it.

I can imagine it would make a good companion volume to my other favourite PHP volume, PHP and MySQL Web Development, which tends more towards recipes and leaves out the encyclopedic coverage of this book.

Leon Atkinson has a good page for the book that includes a link to download all the code and examples, a link to the Prentice Hall page for those wanting an example chapter or a look at the Table of Contents and some other reviews. His site also has a page for the inevitable errata, currently blank. While I did find only one typo (not in example code) I can't claim to have read every page or run all the code examples.

I'd recommend this volume to anyone who wanted a comprehensive guide to PHP 5. It is probably useful at almost all levels.

You can purchase Core PHP Programming, 3rd Ed. from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

cthulu13 writes "Network security can often be a difficult task because there are so many things to consider. This book can help you get a handle on it all by providing a single place to look for advice on policy, design, and implementation. I wish I had the benefit of this book when I was first starting out in my career in security." Read on below for cthulu13's review of the second edition of Merike Kaeo's Designing Network Security. Designing Network Security, 2nd. Ed. author Merike Kaeo pages 745 publisher CiscoPress rating 8 reviewer cthulu13 ISBN 1587051176 summary A good overall resource on network security policy, design, and implementation.

Weighing in at a hefty 745 pages, Designing Network Security is a concise and authoritative guide to the sometimes daunting task of designing secure networks - with a special emphasis placed on Cisco solutions, of course. The book is divided into three major sections:basic theory and essentials; policy design and best practices; and implementation with Cisco hardware. In my opinion this book is best suited as a reference book for those who already have a firm foundation in security and networking, but could also be of value to beginner level techs with a bit of patience. While the topics that are covered have all pertinent information discussed, some might wish that there were a bit more explanation of the Hows and Whys.

The first section, "Security Fundamentals," is an especially valuable part of the book in that it provides a great desk reference to the building blocks of secure networks. The first chapter deals with the basics of encryption technologies - symmetrical/asymmetrical cryptography, digital hashes, public key systems, etc. From there the book moves into what is probably its meatiest chapter, covering the application of encryption to security technologies which range from TACACS+ authorization to TLS encryption. Building on previous chapters, the third chapter deals with the application of these security technologies in protecting real world installations. I was especially impressed with the attention paid to wireless and VoIP technologies in this chapter - this is one of the first discussions of VoIP security I have seen in a general reference book. The first section winds up with a fairly exhaustive discussion on routing protocol security which I also thought was excellent.

The second section, "The Corporate Security Policy," is a good reference to infosec management. Many topics covered in this section are applicable to the CISSP exam - so if that is a career goal for you, this can act as one of your study guides. The section begins with a discussion of threats in the enterprise environment. Types of threats as well as common protocol vulnerabilites are discussed. I felt that some of the material in this chapter was a bit dated, in particular the sections on TCP sequence number attacks (most recent OSes have improved their sequence generation routines to make it nearly impossible to do this) and the ping of death (which I don't remember working on anything after Windows 95 or Linux 2.0.23). The next chapter is a bit more valuable in its discussion of the basics of risk assessment and management. This leads into a discussion of actual design and implementation of security policy. Sample topics include physical/logical controls, data confidentiality, and policies/procedures for staff. And finally this section concludes with a good chapter on incident handling and response.

The final section, "Practical Implementation," is the Cisco-centric third of the book. Many parts of this section are a good reference to points covered on the CCSP exams, especially the SECUR test. The first chapter deals with configuring access controls and audit on Cisco devices from the PIX to switches and routers. A brief discussion of intrusion detection implementations is also included. The next chapter consists of primarily information dealing with firewall/screening router construction - content filtering, packet screening, and the various types of IOS filters. Several implementation examples are included to walk you through the process of configuring CBAC (content-based access control) and the Cisco PIX. From there the section moves to remote access security, with good sections on all Cisco based AAA (authentication, authorization, and accounting) features including lock-and-key and accounting-based billing. Finally, the book wraps up with a chapter on securing VPN, Wireless, and VOIP networks which focuses more on design than implementation, although there are still some Cisco (PIX) based examples. The book's appedices cover DDOS attacks, well-known port numbers, and guidelines for reporting and preventing intrusions.

Overall, I felt this was an excellent book which clearly fufilled its purpose. For the intermediate to advanced network security engineer this could act as an excellent desktop reference, while still being accessible enough to teach to the beginner. The writing style is clear and precise, and I found no technical errors in the material presented. As I mentioned, the book could act as an additional study aid for several security certifications, including the CISSP or the CCSP. I look forward to the next volume by Ms. Kaeo.

You can purchase Designing Network Security, 2nd Ed. from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

daltonlp writes "I haven't felt this satisfied after finishing a science fiction novel since Ender's Game. I waited some weeks to review it, to make sure I wasn't simply infatuated. Oryx and Crake is woven from a great many themes near and dear to SF, but it's primarily a retelling of the story of Adam and Eve--except in reverse (the world isn't beginning, but ending)." Read on for the rest of Dalton's review. Oryx and Crake author Margaret Atwood pages 374 publisher Random House, 2003 rating Worth reading reviewer Lloyd Dalton ISBN 0385503857 summary A retelling of the story of Adam and Eve--except in reverse. The world isn't beginning, but ending.

The novel is a mad scientist story, where humans play God for pleasure and profit. It's a last-human-left-alive story. It's a projection of a dystopic future, where all political and economic power is held by militaristic corporations.

Most of these themes have been explored before, and they're introduced in the first couple chapters of the book. But they're handled so well, I feel like I'm spoiling the reader's experience by listing them here. Never mind, read the book anyway. Maybe you've seen this stuff before, but you haven't seen it written like this.

The measure of science fiction isn't the uniqueness of its concepts--it's what the author can do using the ideas as tools. It's about how intensely a book can penetrate into the reader's imagination, and this is driven by a writer's talent (not the raw ideas).

Margaret Atwood writes stories that are deeply layered and voiced in an incisive, conversational tone. Despite its bleak themes, Oryx and Crake is far from depressing--it's mostly cheerful and upbeat, which turns out to be a fine way to write about obsession and love and revenge and the end of the world. Somewhat like Neal Stephenson, Atwood's writing doesn't take itself too seriously. It's chock full of wordplays and grimly humorous subtexts. The result is a book that works as both a dark comedy and an allegoric drama, but feels like a conversation between the author and the reader.

Some parts of Oryx and Crake approach horror--not blood & guts horror, but what someone from the 1700s might feel if a time traveler explained the basics of how nuclear weapons, school shootings and Internet porn work today. Atwood pulls very few punches when imagining the possible extensions of humanity's greed, lust, hatred, and cold-bloodedness. Her easy pace, artful characterization and humorous touch fully engages the reader's mind, and her willingness to shock takes full advantage of the open target. The result is a mental chill that takes a long time to fade.

It's not a perfect book. Even at 374 pages, some episodes of the story arc seem abbreviated. Some of Atwood's future visions seem a bit contrived, but this depends on whether she's going for humor, symbolism, shock value or sheer inventiveness on a given page. Most pages (including the following excerpt) are a well-stirred mixture:

"On day one they toured some of the wonders of Watson-Crick. Crake was interested in everything--all the projects that were going on. He kept saying "Wave of the future," which got irritating after the third time.

First they went to Decor Botanicals, where a team of five seniors were developing Smart Wallpaper that would change colour on the walls of your room to complement your mood. This wallpaper--they told Jimmy--had a modified form of Kirilian energy-sensing algae embedded in it, along with a sublayer of algae nutrients, but there were still some glitches to be fixed. The wallpaper was short-lived in humid weather because it ate up all the nutrients and then went grey; also it could not tell the difference between drooling lust and murderous rage, and was likely to turn your wallpaper an erotic pink when what you really needed was a murky, capillary-bursting greenish red.

That team was also working on a line of bathroom towels that would behave in much the same way, but they hadn't yet solved the marine-life fundamentals: when algae got wet it swelled up and began to grow, and the test subjects so far had not liked the sight of their towels from the night before puffing up like rectangular marshmallows and inching across the bathroom floor.

"Wave of the future," said Crake."

It's too early to tell if Oryx and Crake will earn Atwood the same acclaim as The Blind Assassin and The Handmaid's Tale. Regardless, it's a powerful book--unnerving, moving and well worth reading.

You can purchase Oryx and Crake from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.