Slashdot Mirror

bucketman writes "Saw this book at Chapter's and bought it and read it straight away. I've been kind of sitting on it for a month or two because my reaction to this book was so strong that I kind of wanted to see if time would mellow it. Well, it hasn't and I'm ready to post now. Note that this book has already been reviewed on Slashdot once, but I've decided to send in my review anyway, as it presents more detail as well as an alternate point of view and might be of interest." Read on below for bucketman's take on the book (and the methodology). Agile Software Development with Scrum author Ken Schwaber and Mike Beedle pages 158 publisher Prentice Hall rating 1 reviewer bucketman ISBN 0130676349 summary Presents the Scrum software development process.

Extreme Programming (AKA XP) has been an interest of mine for some time, as I struggle to find ways to make it easier to say "yes" to in my domain (embedded systems) and it is in the study of this other development process that I first heard of Scrum. Both XP and Scrum are development processes under the "umbrella" of the Agile Alliance.

First and foremost, let's cover what Scrum is, as presented in this book. I will compare Scrum with XP as I go, for reasons that will become obvious later on.

You have the Scrum Master, who is more or less half technical lead and half project manager. He is defined as being responsible for the success of Scrum. I think the closest thing that XP defines to this is the Coach, but it's a poor fit at best.

You have the Product Backlog, where all the stuff that people want in the product is written (called Work) along with assigned priorities for each item and an estimate of some form indicating how long it will take to do. The assumption is that items with high priority will have more accurate estimates and more precise specifications and the low priority stuff will be more or less SWAGs. The Product Backlog also contains Issues, which are more or less problems that gate one or more Work items. Issues are turned into Work by the Product Owner (see below) at his discretion. The analogous concepts in XP is the Story and the Tasks.

You have the Product Owner. He owns the Product Backlog document and the prioritizations within. While he may need to consult others in the effort to do his job, it is his responsibility to maintain the list of work and issues, to decide the prioritizations and to decide what work will be done in the next Sprint (see below). The Product Owner also owns the estimates in the Product Backlog. It is expected that he consults with development to derive these numbers. These estimates are said not to be binding on the Scrum Team (see below). The XP role akin to this is the Customer, with the exception that, in XP, estimation comes solely from development.

The Scrum Team is just the set of technical people working on the product. So testers, documentation people, developers etc. Should aim to be around seven people (i.e. the "optimal" group size).

The Sprint is the development iteration. It should typically aim to be 30 days. It has a Sprint Goal, which defines the overall objective of the Sprint (think of it as a mission statement just for the iteration), and a set of items from the Product Backlog to develop during the iteration. These items are chosen during the Sprint Planning Meetings mainly by the Product Owner. A secondary meeting is held with just the Scrum Team and Scrum Master to decide who will do what and in what order within the Sprint. Also done in this meeting is the breakdown of Work to Tasks, which are smaller units no longer than 4 to 16 working hours in duration. The XP Sprint equivalent is simply the iteration. To my knowledge, there is no equivalent concept to the Sprint Goal. XP's Planning Game does the work of both the Sprint meetings noted earlier.

Because the duration of the Sprint is respected first and foremost, the Sprint Goal is used to determine what content to remove from the Sprint in the event it is discovered that the deadline is at risk. So, we move work from the Sprint to the Product Backlog while attempting to honor the Sprint Goal in order to satisfy our (e.g.) 30 day schedule. If that is not possible (and in some other situations, like irresolvable organizational impediments) the Sprint is canceled and redone from the Planning Meeting.

You have the Sprint Signature, which tracks the expected Work done against the actuals and provides a day-to-day description of what happened in the Scrum Team (similar to, nut much smaller than, the project log spoken of by Steve McConnell).

Once the Sprint is on, no one outside the Scrum team has anything to do with the Scrum team. XP, again AFAIK, does not state this, but the fact that iterations are, if anything, even shorter than Sprints means that in all but the worst cases, the stakeholders will likely be willing to wait until the next iteration to redirect the effort. In any event, because both processes return so frequently to the customer for guidance and because both processes allow the customer to introduce change throughout the lifecycle,, there is less risk that the customer will feel their wishes are not being respected. Lastly, XP's customer and Scrum's Product Owner both funnel all requirements to development. All the project stakeholders then direct their requests to this person. In so doing, the stakeholders never get told "no" per se, but rather are told that at worst their request won't be evaluated until the next iteration/Sprint planning meeting.

At the daily Scrum Meeting, each Scrum Team member answers the following questions:

• What did you do since the last Scrum Meeting?
• What will you do between now and the next Scrum Meeting?
• What, if anything, impeded your progress?

So, you say how you did yesterday against your commitment from yesterday. You say what you plan to do today. All this is recorded in the Signature which is kept by the Scrum Master. Lastly, you note any obstacles that got in your way. It is the Scrum Master's job to note these and remove them immediately. The Scrum Master is expected to report on his progress in this area at each meeting as well. If the obstacle is a failure to make a decision, the Scrum Master is responsible for making that decision immediately - failing that, to ensure it gets made that day. I really like that, BTW, as experience has made clear to me that, on balance, the risk of making the wrong decision has a much lower negative effect on a team than does leaving it in limbo frequently. In the Scrum meeting, no one is allowed to speak save for the Scrum Team and Master. Others may attend but may not speak. This is intended to keep to meeting focused and short. I like this part but suspect that to do it successfully, you'd be wise not to invite anyone that's not intended to speak.

The Sprint Review is held at the Sprint's end and is intended to be a half-day forum where the Scrum Team presents to the stakeholders what it accomplished during the Sprint. The loose equivalent in XP is the final (for that iteration) successful execution of the Customer Tests (nee Acceptance Tests). I say "loose" because the XP concept is stronger - the iteration's deliverable is not only presented but accepted.

To get the Scrum process to scale, a Scrum of Scrums is used where Scrum Masters from multiple Scrum Teams attend a Scrum Meeting run by a Scrum uber Master.

So, AFAICT, that's pretty much it.In reality, I don't see a whole book's worth of content coming out of this.

So what else do they discuss? There's a fair bit on work environments, the ill effects of heavy weight processes and so on - basically restating stuff in less detail that most everyone who will read this book would be likely to have read elsewhere.

There's a lot on the characterization of Scrum in terms of Process Control Theory and why it would be expected to be a better fit for software development than would other processes. This left me cold, frankly, because I tend to read these books looking for what to do, how to do it and what benefit I should expect to see. The underlying science of it is of some interest but not nearly so important to me as the answers to those three questions. Also I already implicitly favor these iterative approaches. So do many, many others - after all, the evolutionary lifecycle model and the "mini-milestones" proposed by McConnell in "Rapid Development" echo both XP and Scrums concepts.

We also get stuff like this:

"Overlapping development phases: In an environment where some of the requirements are discovered while simultaneously something is created with the information at hand, it is imperative that the phases of discovery, invention, and testing overlap to drive the creation of a new product to completion through self-consistency. Most problems in new product development arise when the phases of the project are separated. Empirically, this overlap in phases enhances shared responsibility and cooperation, stimulates involvement and commitment, sharpens a problem-solving focus, encourages initiative taking, develops diversified skills, and heightens sensitivity toward market conditions."

Other than "don't use the waterfall lifecycle," what exactly does all that mean? The end of it is completely unsubstantiated. It drives me nuts when development books do things like this. That paragraph doesn't say much of anything AFAICT but nonetheless manages to set expectations way too high.

Here's another (about the psychological effects of Scrum on the Scrum team):

"They become deeply involved in their work. Scrum drives individuals to focus, commit and excel.
They focus on the work and lose concern for themselves.
They experience an altered sense of time.
They consistently produce at high levels of accomplishment.
Scrum allows developers to concentrate most of their time in developing software, and by doing so developers enter 'flow' state."

I don't know what any of that means and I'd be scared to find out.

Out of nowhere, you get statements like this:

"Scrum requires a balance of individuals with at least 50% of them to be experts ..."

Well, I guess that's that then. I think I could define a process which would have demonstrably improved efficiency over the lifecycle with just that one statement - worse comes to worst just sack the other half and away you go :) Anyway, this requirement appears for the first time on page 121 in a book with all of 154 pages. It's hard to say if it's intended to be taken seriously - if it were, you'd think it would have been a lot more front and center.

But let's go back to what Scrum is, as shown earlier. IMHO, it is not a lot more than XP with at least the following removed (this from memory, please don't be too harsh):

• Continuous integration
• Refactoring
• Unit testing
• Paired programming
• Collective ownership
• Customer-defined acceptance tests
• The "yesterday's weather" estimation practice
• Sustainable pace (nee "the 40 hour work-week")

So, all the hard/useful technical bits from XP are removed. In return, we get the Daily Sprint Meeting, the Sprint Goal, the Sprint Signature, and the emphasis on decision-making by the Scrum Master. The remainder of the Scrum practices have analogues in XP, as I've shown above. It's for this reason I found myself smiling when the book notes success in industry in wrapping XP in Scrum - from what I can see, XP wrapped in Scrum *is* XP :)

The book is careful to point out that any and all of these "missing" practices (refactoring, unit testing et al) may be used but that Scrum does not prescribe them. And that's fine, but I'm evaluating it on what it actually does prescribe - if Scrum can take credit for what it does not prescribe, they it can lay claim to infinite credit after all. This is maybe a small point but it's important to what follows. Because Scrum does not tell us what to do in these areas, I'm assuming that they are free to vary.

So, if you accept my characterization of Scrum as XP with all the hard technical bits removed. what might you see in a Scrum project?

If you follow Scrum's iterative path with no refactoring to offset the inevitable software entropy, the software would tend to lose architectural unity quixkly. It would be easy to break and hard to fix. - and so on and so on, for all the ills which refactoring is intended to address. If Scrum does not prescribe refactoring explicitly, then we must assume that not doing it is an acceptable Scrum path. If Scrum requires refactoring as a key practice, it should say so. XP and Scrum turn every project into a maintenance project but XP bolsters that position with all the technical practices that ensure the team is *really* good at maintenance. Scrum does none of this. Combine the lack of refactoring with no prescribed regression (unit) testing and I think it becomes clear that Scrum projects that do neither would risk devolving into code and fix affairs.

Because we have no review process prescribed in Scrum, which XP provides via paired programming, and no stated ownership model, we would expect to see Scrum projects which explicitly prescribe neither ending up with code like little fiefdoms where the divisions between one guy's code and another's are painfully obvious. We also would expect to see de facto individual code owners with all the gone-to-greener-pastures risk that entails.

Because we have no estimation practice prescribed we would expect to see poor estimates. Because the Product Owner owns these estimates, there's no reason to expect them to be meaningful at all.

And in return for all this, what do we get? We get the Sprint Goal, which is a fine idea, IMHO. It defines, a priori, a way to sensibly cut work within an iteration. We get the fast decision-making from the Scrum Master. This is also fine by me. We get the intense project progress tracking of the daily Scrum Meeting and the Sprint Signatures. Hmmm ....

And so, at long last, and very much in my long-winded way, I'm finally ready to state my real conclusion about Scrum ...

But first here's another quote from the book :) It's an example Sprint Signature description:

Day 16-17 The team is discouraged by all the work remaining and didn't work during the weekend. No changes in estimated time remaining.

Day 18 The team works more and its remaining work declined. The team then met with the Product Owner and the Scrum Master to determine what tasks could be reduced or removed while still meeting the goals of the Sprint. Some Sprint backlog was dropped; other estimates were lowered because not as much functionality had to be supported. Overall estimated work remaining reduced to 1400 hours. If all this work is completed, the team will still meet the Sprint Goal, although with functionality implemented less completely.

Day 19 The team continues work toward the Sprint Goal using the new Sprint Backlog. Estimated work remaining declines.

Day 20-30 Team is motivated because it can still meet the Sprint Goal if it works hard. The team works regularly including during the weekends. Estimated work remaining declines to zero as the team meets its Sprint Goal by the 31st day."

Here's one thing I've learned in the working world - death marches don't just happen on their own. It's not easy keeping a real death march going. You need to brutally cut and slash the work items in the finest detail to ensure that what you're committing to is actually what's absolutely necessary. To do this, you need to get stakeholders interested enough to grovel around in these nasty details. To really run a death march (and sustain one), you need to track everything everyone's doing down to the granularity of hours so you can tell immediately if someone has returned to a normal level of effort (people will tend to do this long before their actual *hours* spent at work decline). You need to make this tracking of effort very public so people feel intense peer pressure to keep their effort as high as their colleagues. You need to keep the goal always seemingly in reach and make sure this perception is held by everyone on the team because once the expectations are obviously unrealistic, most people will slack off. As long as the goal looks possible with significant effort, people will still buy into it.

And, in the end, that's what I think of Scrum: if you take away all those XP practices and don't replace them with anything, I think you end up with a really good way to run a code and fix death march. And if you put back all those practices, you're pretty much doing XP. I believe parts of Scrum can be lifted and applied in other processes (particularly XP) but that you'd be insane to adopt Scrum as defined in this book without addressing the risks detailed above."

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

Thomas Boutell writes "Are we alone in the universe? Any curious human being will recognize the question. David Grinspoon's Lonely Planets is a broad, newcomer-friendly and often hilarious exploration of the subject of extraterrestrial life. David Grinspoon is a respected planetologist with a particular focus on Venus. He is also a very engaging writer, able to translate dry scientific ideas for a general audience without patronizing. Most surprisingly, he can tell a joke, and as a representative of the scientific tribe, he can also take one. His first-hand experiences growing up surrounded by luminaries like Carl Sagan and Isaac Asimov enable him to tell the story of astrobiology and SETI as few others can." Read on for the rest of Boutell's review. Lonely Planets author David Grinspoon pages 440 publisher Ecco / Harper-Collins rating 10 reviewer Thomas Boutell ISBN 0060185406 summary A marvelously accessible, irreverent and fun exploration of the possibilities for other life in the universe.

Grinspoon, though, never falls victim to the temptation to proclaim that intelligent aliens are a scientific certainty, nor does he ridicule those who come to a belief in aliens by a less-than-scientific route.

The book begins with a historical perspective, telling the old stories of Copernicus, Galileo, Kepler and Lowell in fresh and surprising ways. This makes even these chapters recommended reading for experts as well as newcomers to astronomy. Grinspoon is not content to repeat the usual pieties about these scientific "saints." For instance, he reveals that Galileo did much to intentionally antagonize the pope in his writings about the solar system. He also discusses the more off-the-wall beliefs that many early luminaries of science have held. He explores the link between the end of the earth-centered view of the universe and the beginning of a centuries-long popular craze for the idea of planets around every sun, and intelligent beings on every planet.

The second section of the book deals with the science of suns, planets, moons, and the potential life in, on and around them. All of the popular candidates, including Mars, Europa, and Titan, are discussed in nonscientist-friendly detail. Unearthly life is a broad subject, and Grinspoon does not cover it with perfect evenness. His chapters on cosmology, the early Earth, chemical evolution, and the cambrian explosion are great stuff; but after a quality discussion of DNA, he builds up the idea that RNA most likely evolved first, with ever quite saying what RNA is or explaining its role in our cells today.

But this is a rare omission. The science in the book is sound, and the footnotes and asides consistently entertaining. No song reference or movie quote is left unquoted, always to good effect. Throughout, Grinspoon maintains an almost unheard-of humility, always careful to point out how much we simply don't know about life on Earth, let alone life elsewhere.

The third and final section of the book could never have been written by a less honest or more egotistical scientist. It may also help that he plays in a reggae band. Titled "Belief," part three begins with a discussion of the development and present state of SETI, the Search for Extraterrestrial Intelligence, as nearly anyone with a screensaver knows. Grinspoon explores Fermi's paradox -- if they exist, why haven't they arrived on Earth, or at least said hello by radio? He doesn't duck the hard questions, and he brings us the human story of the SETI pioneers on both sides of the Iron Curtain. He acknowledges that the strong desire to believe in aliens is as something almost religious for many people, including scientists. And he gives the UFOlogists their due, taking a fascinating journey to the San Luis Valley of Colorado. If something really hasn't been adequately explained, he acknowledges that: "there are mysteries. Are we unfaithful to the church of Science if we admit that there are mysteries?" But he does point the finger at a few flimflam artists, and doesn't hide his disappointment with certain alien-visitation true believers who should probably know better.

Maybe the temptation to believe is not so hard to forgive. Where our knowledge is imperfect, our beliefs and hopes always become entwined. Grinspoon ends the book with a meditative chapter on "astrotheology," pulling together the threads of science and faith, exploring the moral implications of intelligent life elsewhere and sharing his own beliefs in the matter.

I recommend this book both for space buffs and for less "scientific," less skeptical readers on their gift lists. The book is worth reading for many reasons -- engaging writing, a friendly introduction to the science involved, eye-opening history, and a chance to learn a skilled planetologist's best guesses at what we may discover living or not living on, in or around Mars, Europa, and yes, Venus. Not since Sagan and Asimov passed away has there been a science writer with such a voice.

Will anyone hate this book? Maybe -- new agers, pot-haters, and supporters of the Bush administration could get their noses out of joint... but only if they read every footnote, and completely fail to take a joke. Most will be as entertained and informed as the rest of us.

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

Motor writes "Coalescent is the first book in a new trilogy (Destiny's Children) by Stephen Baxter, a hard SF author with an impressive bibliography; Raft, Ring, and the awesome Manifold trilogy (Time, Space, Origin), among others. Baxter is an engaging writer whose ideas are as numerous as they are interesting and original. Coalescent spans history from the Roman era to 20,000 years in the future, and examines the beginnings and evolution of a strange form of human society. It has three main narratives." Read on to find out what they are, and for the rest of Motor's review. Coalescent: Destiny's Children, Book One author Stephen Baxter pages 480 publisher Gollancz rating 9 reviewer Motor ISBN 0575074248 summary Sisters matter more than daughters. Ignorance is strength. Listen to your sisters.

One thread follows George Poole, an educated and intelligent man in modern day Britain. After his father's sudden death, George has to put his affairs in order, and in the process discovers a previously unknown twin sister sent away to join "The Puissant Order of Holy Mary Queen of Virgins", a secretive (but apparently respectable) sixteen-hundred-year old religious order in Rome. He decides to find out more, and begins to investigate with the help of an old school friend, a member of a "fringe group of outsiders united by new technology" who communicate via the Internet and moderate each other's contributions to keep things ordered -- what a bizarre idea.

At the same time in Rome, Lucia is a fourteen-year old member of the Order who finds herself, unlike her fellow sisters, undergoing some alarming physical changes... puberty.

The other narrative thread follows Regina, a girl born around 400 A.D in Roman Britain. She is spoiled and pampered until her world is shattered by the death of her father and the ending of Roman rule in Britain.

Of the three threads, Regina's story is by far the most vivid and compelling. It is easy to read the broad sweep of history books documenting the decline and fall of the Roman Empire, but what did it mean for the people living through it? Currency, the rule of law, the specialised labour needed to provide metal, and the army to keep the peace... all gone. As one of the characters (Peter, in the "George" thread) says, "It must have been like a nuclear war." No longer enjoying the protection of the Emperor and his armies, the scattered and disorganised British have to fend for themselves against the invading Saxons intent on looting, pillaging and removing all traces of Roman civilisation. Regina must learn how to survive, and eventually her drive and ruthlessness leads her to Rome to confront her past and make a better future for her daughter. Driven by instinct and a desire to protect her family from the barbarian sackings of Rome, she establishes an unusual way of life which threatens to change the meaning of what it is to be human.

There is a great deal more, but it would be unfair to reveal too much and spoil things for others. The dangling threads (the mysterious Kuiper Belt anomaly) and hints (the war 20,000 years hence) leave plenty for future novels in the trilogy to push the story further into big science, big ideas and deep time that Baxter is well known for. Coalescent is scrupulously researched, intriguing, educational and has a genuine effect on the way you see social interactions and communities. Hard to beat, and highly recommended.

You can purchase Coalescent 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 "Back when dinosaurs roamed the earth and NCR made Unix computers I first started to program for a living. Back then when someone said 'script' they meant a shell script, generally for a Bourne shell." Even if the definition of "scripting" has grown somewhat, honestpuck argues, the old meaning still has merit and use. Read on for his review of the latest edition of Unix Shell Programming. Unix Shell Programming, Third Edition author Stephen G. Kochan and Patrick Wood pages 406 publisher SAMS rating 8 - Well written, good topic coverage, some small flaws reviewer Tony Williams ISBN 0672324903 summary Good introduction to shell programming and using the shell

Now that we have languages such as Perl and Python, much of shell scripting has been forgotten. The need still arises for the times and places where running Perl would be just that little bit too much overhead; cron jobs, process start and stop scripts, even machine start and stop scripts. For these we could best go back to the old ways. Combining the power of the common Unix tools, pipes and scripts in a fairly obscure and slightly arcane syntax is not easy to pick up, though the language's simplicity does, in some ways, make it easier than more complex ones such as Perl. This book does a good job at introducing shell programming and I found it an excellent book when I needed a refresher.

I don't want to sell this volume short: you won't just learn about shell programming. The first ninety or so pages provide an excellent guide to getting the best out of the shell, and the last chapter is devoted to the features specific to an interactive shell such as command-line editing and using the history.

The authors have chosen to use the POSIX standard Bourne shell ('bash', available on many *nix systems, is a superset of the POSIX standard). That seems the right decision, given that it is so universally available and usually the default shell.

The book is well structured, starting out with a brief look at *nix operating systems before introducing the shell followed by some basic tools; cut, paste, sed, tr, grep, sort and uniq. One minor quibble, the book explains how to redirect STDOUT to a file and STDERR to a file, but not how to redirect both to the same file. That aside, these few chapters provide a good introduction to the shell.

The text goes on to systematically explore shell programming starting with variables and arithmetic. The chapters are kept short, in a good order and have a number of exercises at the end of each. The structure of the book and the order each new concept is introduced is well thought out; at each stage small examples are given that only use material already introduced and are complete in performing a task. In early chapters they are fairly trivial but by the end there is a fairly complete rolodex program written in shell script that would be a good model for anything you wished to do.

There is also a good summary of the shell syntax and common commands in Appendix A and good 'Further Information' in Appendix B. Kudos must go to the authors for a list of books for further reading that is not ashamed of mentioning other publishers, indeed they say "One of the best sources of books on Unix-related topics is O'Reilly and Associates" and list volumes from them before mentioning their own publishers.

There are some small typographic errors in the text but I did not find any in the script examples I tried. I found it to be well written and readable throughout, perhaps an advantage of a third edition in a slow moving technology.

You can visit the Sams web page devoted to the book which has the Table of Contents and the third chapter available for download. It has no errata or source code, I looked to see if the authors maintained a site for the book but could not find one.

I would recommend everyone read this book once or twice, it provides a comprehensive, well written tutorial on one of the most basic (and often overlooked) tools at your disposal. Even Windows users could install Cygwin and gain the benefit of a good POSIX compliant shell and this book. It also has the advantage that once purchased it will be useful for many, many years to come - the language has not changed noticeably in twenty five years and should not change in another twenty five.

You can purchase Unix Shell Programming, Third Edition from bn.com. Slashdot welcomes readers' book reviews -- to submit a review for consideration, read the book review guidelines, then visit the submission page.

mseaborne writes "So, why should anyone be interested enough in XForms to want to read XForms Essentials in the first place? Well, if you make your living sweating over hot JavaScript and HTML, fighting against technologies never really intended to help you write even fairly simple forms that require such mundane, work-a-day functionality as cross-field validation, data prepopulation, or even reliable data typing; then XForms may be for you. If there are forms you would love to deploy over the Web, but they are too many, or are too complex to even attempt with HTML 4, then for you too, XForms could be the answer." Mark is also an interested party in XForms' success and improvement; he says he "joined the XForms Working Group after all the hard work had already been done." His review continues below. XForms Essentials author Micah Dubinko, pages 240 publisher O'Reilly rating 9 reviewer Mark Seaborne ISBN 0596003692 summary Introduction and reference to XForms 1.0

The motivation for XForms came from a realisation that the Web has pretty much ignored the needs of forms-based sites up to now, beyond the simplest and most trivial of uses. That more complex forms do exist on Web sites today says more about the ingenuity of their authors than about the utility of HTML forms. XForms is designed to make form authoring, maintenance, deployment and redeployment to different platforms, work.

XForms removes the need for reams of script to make a web form function. No longer must you code business (or any other sort of) logic right into the UI. Instead, you write rules against the XML data structures you want forms to populate (that's right, data structures, not name value pairs, unless that is actually what you want). XForms lets you bind the UI to the data structures directly (or indirectly, if you want to be really clever). The UI responds to changes to the data, rather than the other way round, and suddenly life really does become much easier. Granted, you must first make the mental leap from a procedural to a declarative frame of mind, but once that is achieved you will soon be reaping the benefits.

Rather than pontificate on the wonders of XForms (and I am biased, being a Working Group member), I would urge you instead to take a look at Micah Dubinko's book. (Micah is even more biased than me, having been a Working Group member for much, much longer.) No purchase is necessary; you can read the full text online, though I will admit that even I did end up getting the hard copy eventually. The book is small, and paper still has something over HTML, even when viewed on an Apple PowerBook.

Given that you can read Micah's book on the web, I really would urge people to look at it before attempting the rec. itself. The intended audience for the XForms rec. is the XForms implementer, rather than the XForms author. So, short and well-written as it undoubtedly is, this is not an easy read. If you are not sure how much time to invest looking at XForms, you could do worse than read the first chapter of Micah's book. It explains why XForms is as it is, and how it got there. It lays down the principal problems with HTML forms, and explains how XForms is better.

Having roused your curiosity in Chapter 1, the second chapter works through an example form. It introduces the reader to XForms functionality, and points to the ways in which XForms is built on a foundation of much-loved and popular W3C recommendations, such as XPath, XML Schema and CSS. Fortunately Micah does not assume that the reader is fully conversant with these technologies; he has written very serviceable introductions to them in subsequent chapters.

Most of XForms Essentials is a reference to the XForms recommendation, with enough examples and usage notes to make entries useful to beginners and old hands alike. Micah provides tips on how to get the most out of XForms, and how to miss the most common pitfalls: for example, how to avoid the need to write complex XPath expressions. There is even a dedicated troubleshooting chapter which people will probably find invaluable, for a while at least. However, as your forms become more ambitious, you will probably hit problems not dealt with by Micah. I think this is inevitable, given the youthfulness of the standard and its implementations. Micah has said that he will update the text as necessary. People should watch his blog site to see what Micah adds.

Micah's text is concise and pithy throughout. Consequently, one of the chief virtues of XForms Essentials is that it is short. To be fair, this partly stems from the conciseness of the XForms recommendation itself. However, it is also an indication that some topics are only covered briefly. For example, there is very little mention of security issues. XForms Essentials certainly doesn't tell you how to deploy forms onto the web. I suspect that some omissions result from the lack of a body of XForms deployment experience as yet as much as from a desire to keep the book short and focused. Micah does, for example, make some useful suggestions about authoring best practices, but these are necessarily sketchy. They do get you thinking, though, about the possibilities opened up by XForms.

The final chapter covers extending XForms. At the moment this mostly means how to use scripting with XForms. I suspect that people initially drawn to this section will ultimately not find it nearly as useful as they first thought, as XForms really does remove the need for most scripting. However, it would be ridiculous to suggest that scripting does not have its place in web development, and Micah suggests what that place might be.

Micah has combined several functions in this book. XForms Essentials answers the question of the moment, "Why XForms?", and so helps to justify interest in yet another W3C recommendation. It is a very good introduction to XForms for the complete beginner, and a handy, desktop reference for the everyday author. You may only read the outer chapters once or twice, but the core of the book will remain invaluable.

What is really missing from the book is any good information on XForms implementations. This is fair enough, the book will remain useful as implementations come and go. However, Micah has written an article describing ten XForms implementations. The article is up-to-date enough to be very useful. The fact that Micah was able to find ten implementations already speaks volumes for the interest generated by XForms (as well as suggesting that the spec is quite implementable). Please bear in mind that Micah's list is selective, not exhaustive!

I have now spoken to a number of people new to XForms (as are we all just now), many of whom use Micah's book, and all report that it is a useful resource to have around. Every one has ended up buying it in the end.

Mark Seaborne works as a technical architect for Origo Services Ltd, the XML message standards body for the UK Life Insurance Industry. When your eyes get tired, you can purchase XForms Essentials from bn.com. Slashdot welcomes readers' book reviews -- to submit a review for consideration, read the book review guidelines, then visit the submission page.

daltonlp writes with the review below of John Gall's 1977 work Systemantics, writing "Most of the systems described by the author are societal or economic systems (governments, corporations, universities). Computer programs are mentioned, but they aren't the primary focus. But Systemantics doesn't distinguish between types of systems. In fact, its theories and arguments seem especially applicable to computer systems." (Read more below.) Systemantics author John Gall pages 111 publisher Quadrangle / The New York Times Book Company (1977) rating Insightful +5 reviewer Lloyd Dalton ISBN 0812906748 summary "A complex system that works is invariably found to have evolved from a simple system that works." Years ago, I saw this quote and committed it to memory. I've finally had the pleasure of reading the book it comes from. I was amazed that Systemantics was written in 1977. It's far more relevant today than it was then, because more people write more software today.

That means theories like
Systems in general work poorly or not at all.

Some might question whether this is really true for computer systems built with modern technology. After all, for a computer to function, millions of microscopic parts must act in perfect synchronicity at superhuman speed.

But in reality, computers fail much more frequently than we notice. A large chunk of their innards are dedicated to failing gracefully. There's ecc in just about every piece of hardware. Without it, computer hardware would fail too often to be usable. Software is no different--it can fail sooner or later, gracefully or catastrophically, but it's going to fail. Overall, computers work poorly, but they work.

Complex systems usually operate in failure mode.

In other words, something's always broken at any point in time. The measure of a complex system's quality is how drastically a particular failure impacts the rest of the system.

Loose systems last longer and work better.

Most Slashdot readers probably read the above and think either "Hallelujah!" or "Duh." But it's a small example of something I liked a lot about Systemantics. Buried under several layers of satire and pessimism is a genuine desire to help the reader avoid the mistakes of past systems designers and managers. There's more to this book than just pessimism.

What's Bad: Systemantics suffers a little from being a quarter-century old. Several references to Watergate and a few other cultural nods may be a bit lost on anyone under 40.

But the book's only real flaw is the author's occasional condescending tone. Every dozen pages or so, Gall takes the opportunity to criticize a real-world example. Some of these anecdotes serve as supporting evidence for an argument. Others are genuinely entertaining (the section on Job Goals and and Objectives is outstanding). But the author sometimes tries too hard to be satirical, and comes across as flat or patronizing, or departs on tangents unrelated to the book's central ideas.

Summary: Despite small imperfections, there's a wealth of real knowledge in this small volume. The author helpfully outlines the main points at the book's end (some of which I've bulleted above). The book's overall message couldn't be more clear if it summarized itself. Which it nicely does:

It is hardly necessary to state that the very first principle of Systems design is a negative one: Do it without a system if you can.

Systems are seductive. They promise to do a hard job faster, better, and more easily than you could do it by yourself. But if you set up a system, you are likely to find your time and effort now being consumed in the care and feeding of the system itself.

• New problems are created by its very presence.
• Once set up, it won't go away, it grows and encroaches.
• It begins to do strange and wonderful things.
• It breaks down in ways you never thought possible.
• It kicks back, gets in the way, and opposes its own proper function.
• Your own perspective becomes distorted by being in the system.
• You become anxious and push on it to make it work.

Eventually you come to believe that the misbegotten product it so grudgingly delivers is what you really wanted all the time. You are now a Systems-person.

You can find used copies of Systemantics from bn.com and other online sources, though good-condition copies fetch high prices. Slashdot welcomes readers' book reviews -- to submit a review for consideration, read the book review guidelines, then visit the submission page.

Alex Moskalyuk writes "Remember those 'how-to' and 'home improvement' books that you enjoyed reading as a little kid? In the first half of the last century there was a variety of books, with names like 'Boy Mechanic' or '1,000 Projects for a Boy,' which would give a teenager a variety of projects to work on productively. Building bird houses, creatively reusing helmets from World War I, and later different projects that had to do with radio and transistors - in the pre-television age all that guaranteed some creative time for geeks (whether kids or adults) and allowed them pick up skills, necessary perhaps in real life." Alex reviews below a book that fills a similar niche for the present day, outlining all 13 projects in Linux Toys: 13 Cool Projects for Home, Office and Entertainment. Whether you'd consider all of the projects toys is up to you. Linux Toys: 13 Cool Projects for Home, Office and Entertainment author Chris Negus. Chuck Wolber pages 360 publisher John Wiley & Sons rating 9/10 reviewer Alex Moskalyuk ISBN 0764525085 summary Variety of Linux-based projects for home, business or just for fun

Things changed in 21st century, so what's a geek to do? As for the household products, you can probably always get stuff cheaper at Wal-Mart than build it yourself. Radio-related projects just don't seem that much fun anymore, since there's little sense of discovery.

Linux Toys is just the book that fills that void.

What's covered Chris Negus (author of the Red Hat Linux Bible) and Chuck Wolber (from Tacoma LUG) came up with 13 different projects that one can do at home. All of them require a PC running Linux (the authors use and recommend Red Hat Linux 9, since that's the environment where the projects have been tested) and a variety of hardware (including none besides the PC), depending on which project you decide to go with. What are the projects? The entire listing is at the book's Web site, but here's a list of all thirteen with short descriptions of what's accomplished in the end (not necessarily in the same order as the chapters):

1. Digital Picture Frame: excellent endeavor if you have an old useless laptop with nice LCD screen lying around. The book has detailed step-by-step guide with pictures on how to turn an old laptop into a fancy picture frame playing a slideshow of digital images stored on the hard drive locally or uploaded from network (in case the old laptop has a network card and you decide to keep it when assembling the picture frame). By the way, these things do cost a lot commercially, while P200 and lower laptops are virtually free.
2. Arcade Game Player: how to turn an old computer with a good monitor into the arcade game player running XMame. Your house guests can then use joystick to play Donkey Kong, Pac-Man, Asteroids at your next Blast from the Past party.
3. Digital Answering Machine: using the Red Hat Linux box as an answering machine that listens for incoming telephone calls (via vgetty), converts the voice messages into digitally compressed sound files and notifies the receiver about new voice message via e-mail.
4. Home Music System: have an old PC with fairly large hard drive and some good home entertainment speakers? This project allows the reader to build a jukebox used to play Ogg Vorbis files. The authors use ltJukebox and freedb for music management and information retrieval. The ltJukebox software (which comes with the book's CD) automatically rips the music CDs into .ogg files, though digitizing your collection (if you haven't done it yet) might take a while. After that, however, a standalone computer nicely tucked somewhere in the room behind the speaker system can provide for hours of music. And if you plug it into the network, you'll have the ability to change settings and playlists via telnet.
5. Home Video Archive: ever wanted to digitize your VHS collection? This chapter uses ffmpeg and nvrec for capturing and xawtv for adjusting television input. The authors then use Hauppauge WinTV Go and WinTV Theater TV capture card and then record the videos off the TV input into an AVI file. The resulting file is then burned to a CD/DVD (still using Linux tools) as well as into the VCD format that's recognized by most DVD players.
6. Personal Video Recorder: ever dreamed of cutting TiVo's market share with your own devices? Well, perhaps, maybe within just one market -- your house. The authors use the same nvrec utility to record the TV input, XmlTV and WebVCPlus for downloading the data on television shows and using Web interface to choose the ones you would like to record. Unlike TiVo though, this home-built digital PVR can only play the recorded shows on a Linux PC in AVI format, but if you followed the previous project, you can burn the resulting file into VCD format.
7. Providing dial-up access: this basic project is perhaps familiar to all those who bear the title Network Administrator or used to work for an ISP, but for beginners in the field (and especially for beginners with Linux) it provides a detailed step-by-step plan on how to setup your own dial-up server and become a small ISP. A computer permanently connected to the Internet with a static IP is required for this project.
8. Web hosting business: assuming that a computer with static IP address from the previous project and a domain name are available, this project takes the reader through the details of becoming a Linux hoster. This project is especially interesting, since it's applicable to those who have pretty good knowledge of the OS. Numerous online how-to's and manuals take you through separate processes, like adding user accounts, configuring Apache, setting up disk quotas, but few are "turnkey" solutions, where after closing up the book on the last page you can start the hosting business right away.
9. Home network with a Linux box: rather detailed description of properly configuring iptables, NAT, as well as DHCP and Samba servers to run the home network with a Red Hat Linux 9 box as a server with the firewall and various Linux/Windows clients connecting to it.
10. Video streaming server: set up a camcorder, Web cam or security camera to broadcast the video to the Internet. The authors use a camcorder and ffserver software to stream the video.
11. Temperature Monitor: here a temperature sensor kit from DigiTemp needs to be purchased and connected to the telephone cable, which, in turn, will connect to the parallel port. Apparently the ordering page is down as of writing this review, but DigiTemp developer uses Dallas Semiconductors temperature sensors. Then the software provided with the book (ltweather) allows you to look at the current temperature, log it consistently and display it on a Web page if needed.
12. Linux and some games on a single floppy: re-using that 3.5'' drive for something practical is the purpose of this project. Although the result - single-floppy with some essential Linux and character-based games on it, can be hardly practical in the modern world, perhaps it's worth playing with just to see how little you need to get the whole OS going from scratch.
13. Controlling RC cars from Linux: if you have a large collection of RC cars (and according to the spam messages I am getting, they're the hottest trend this Christmas), there's a variety of things you can do when suddenly instead of using the remote control you engage a Linux PC. Unattended races, testing your AI algorithms for entering DARPA autonomous vehicle challenge, writing some complex artificial life, where species of all sorts can see how well they can survive in a crowded world. The authors use a LynX-PORT board, a fairly expensive, but according to the authors, quite useful I/O board that could be re-used for all sorts of projects.

The Book With 274 pages of useful information (excluding the cover pages), the book creates a very favorable impression. The writing is clear and succinct; each chapter follows the same structure with an overview of the project first, the list of things needed for the project second, a step-by-step guide third, some additional information for those willing to go further fourth, and summary of the project fifth. Each step that requires interaction with a Linux box has the exact command-line instructions spelled out, no matter how basic. (On page 44, for example, the authors provide the mount /mnt/cdrom command, even though knowledge of this step is expected of a Linux user at the command line). Where interaction with the GUI is required, a screenshot is provided. The Troubleshooting section explains what might go wrong with a Red Hat Linux 9 box and how to react to it.

Furthermore, there is no dependence on previous chapters, making each project independent. You will not be told to "start up the video capturing as you have learned in the previous chapter" or refer to "previously described procedures". Theoretically, you could rip out the pages for a single project and give them to someone with no previous knowledge of the project and expect them to complete it.

Pictures are indispensable. Granted, they wouldn't be very useful for the Linux on a Floppy project, but for something like a digital picture frame, where you're required to disassemble an old laptop and play with the parts, it's essential. The pictures are all black-and-white, and by "pictures" I mean real photographs, not diagrams explaining how things should be done in theory.

The authors' sense of humor permeates the book, which makes it an enjoyable read. For example, on page 255, when completing the Linux RC toy car project, the photo of the race has a caption about every Linux car crossing the "Finnish" line. (Tip: Linus didn't always live in California). The layout of the book also makes it convenient to read and follow. A bar across the top of the page always tells you which project you're on. When enumerating the things required for the project, the authors use bulleted lists with clear explanations.

Another thing worth mentioning is the book's integration with the Web. The book's Web forums allow you to post questions and impressions from each specific project. The authors are also accepting submissions for new Linux Toys from the readers. The Web site in this sense is remarkable, as with too many technical books the so called "companion Web site" is not truly a companion, but a marketing pitch followed by a bookstore link.

Overall, I think Chris Negus and Chuck Wolber have done a very nice job. If I had more time, I would explore more of the projects personally (so far I am started on rebuilding my home network, but I do want to try out the digital picture frame, being a proud owner of Compaq LTE P100 laptop). The book would be a good read for anyone looking for some cool hobby projects, and perhaps would be a good gift for technically inclined kids, who are interested in technology.

Speaking from a different perspective, Linux Toys is the book needed by the open source community. While the usual arguments of being able to look at the OS's source code and concepts of Free software only vaguely interest most individuals, a book like this would spark interest in Linux OS as providing the opportunities to create a variety of cool toys and have fun doing it.

Read more of Alex's reviews of technical and tech business books. You can purchase Linux Toys: 13 Cool Projects for Home, Office and Entertainment from bn.com. Slashdot welcomes readers' book reviews -- to submit a review for consideration, read the book review guidelines, then visit the submission page.

Simon P. Chappell writes "Security is not just for the paranoid anymore. There is plenty of documented evidence to show that there are people that are out to get you (and your information). Sun's J2EE framework brings a work-chest with many powerful tools in it, but with power there is always complexity, and many of these tools, especially the security-oriented tools, are under-used because of this. Pankaj Kumar's book J2EE Security is a guide to using these tools when building security into your Servlets, EJBs, web services and web applications." Read on for the rest of Chappell's review. J2EE Security for Servlets, EJBs, and Web Services author Pankaj Kumar pages 426 (12 page index) publisher Prentice Hall rating 9 reviewer Simon P. Chappell ISBN 0131402641 summary A great combination of security primer and cookbook. What is J2EE Security? J2EE Security covers a very wide range of techniques and mechanisms: Access control based on permissions and authentication of identity; encryption of data passing in or out of an application; and validation of presented credentials. These are the big things: needless to say, there are levels of detail below each of these three. What do I know about J2EE Security? More than I did when I started reading this book! In my experience, security is either bolted on at the last minute or badly implemented using home-grown techniques. As one who has seen or tried both of these approaches, I was determined to seek out the better way, so when the chance to review this book came along I jumped at it. Overview The first section, with chapter one and two, is "The Background." Chapter one is a security primer and should be old hat to most of the readership of Slashdot. Chapter two is a tour of the Java language strictly from a security perspective. This is interesting and very informative, even for a long-time Java programmer like me.

The second section is "The Technology," and includes chapters three through seven. Chapter three is a discussion of cryptography with Java and would have been worth the price of the whole book for me if (I hadn't have gotten it for free as a review copy)! :-) Chapter four covers PKI (Public Key Infrastructure) with Java. Managing certificates is explained as well as the steps necessary to issue and revoke your own. Chapter five is a discussion of access control. Access control in Java is available based on the origin of the code (the applet effect), the signer of the code or the logged-in user. Chapter six concerns securing the wire. This is the use of encryption for the transmission channel, SSL in a web browser being the most obvious example, where everything served over HTTPS is encrypted. Chapter seven secures the message. This covers message encryption for those times in life where you have to use a non-encrypted transfer medium as well as techniques for authentication, so that the message you do send can be guaranteed to be authentic and provably from you.

The third section is "The Application." Chapter eight discusses the security aspects of RMI based applications, especially using the Java security managers. Chapter nine reviews web application security using both declarative and programmatic security, giving examples using Apache Tomcat.Chapter ten discusses EJB security, including JNDI-based client authentication, SSL and declarative access control. Chapter eleven talks about the security issues associated with web services using the Apache Axis tool to illustrate the points. Chapter twelve is a wrap up of the whole book.

What's To Like The book is logically divided into chapters on each of the main aspects of security that apply to J2EE. These chapters are then located within three sections: background, technology and application. This sequence worked nicely for me, each chapter getting more detailed. This way I knew how deep I was by how far into the book I'd gotten.

The main thing that struck me about this book was that it was designed to be practical. Mr. Kumar not only explains his point and gives you example source code, but he has written a freely available security toolkit, to demonstrate each of the points he makes. The Java Security Tool Kit (JSTK) is a very nice addition to the book's text. Being able to try out the concept being explained really helps. This approach takes example code to another level and I hope other authors will take note.

What's To Consider There is almost nothing to nit-pick concerning the book, but I do have one complaint about the JSTK software. The supplied shell scripts in the bin directory all had MS-DOS end-of-lines. This prevented them running unmodified on my OS X iBook. I had to remove all of the ^M's. This may also be a problem under Linux, but I have not had an opportunity to test there yet. Once the end-of-line problem was fixed, the software worked like a charm. Summary A great combination of security primer and cookbook. If you're a serious crypto-freak then you probably don't need this book. If you're a regular Java programmer looking to move to the next level in your understanding and practice of security in your J2EE applications, then this is an excellent book to purchase and learn from. Table Of Contents

1. A Security Primer
2. A Quick Tour of the Java Platform
3. Cryptography with Java
4. PKI with Java
5. Access Control
6. Securing the Wire
7. Securing the Message
8. RMI Security
9. Web Application Security
10. EJB Security
11. Web Service Security
12. Conclusions
Appendix A: Public Key Cryptography Standards
Appendix B: Standard Names - Java Cryptographic Services
Appendix C: JSTK Tools
Appendix D: Example Programs
Appendix E: Products Used For Examples Appendix F: Standardization Bodies

Simon P. Chappel would like Tim O'Reilly to call him to discuss the great Java book he's itching to write. You can purchase J2EE Security from bn.com. Slashdot welcomes readers' book reviews -- to submit a review for consideration, read the book review guidelines, then visit the submission page.

ElectricAnt writes "First of all, I should mention that this book is complementary to Softwar: An Intimate Portrait of Larry Ellison and Oracle reviewed earlier here. Everyone Else Must Fail has not been approved, endorsed or edited by Oracle or Larry Ellison, so it could be that many things were said out loud for the first time. Karen Southwick is a journalist who has covered many technology subjects, and written three previous books about Silicon Valley's business side. She wrote this book, at least partially, based on the interviews with former Oracle executives who were either fired by Larry (as Ray Lane) or left Oracle to start their own business (Tom Siebel)." Read on for the rest of ElectricAnt's review. Everyone Else Must Fail: The Unvarnished Truth About Oracle and Larry Ellison author Karen Southwick pages 320 publisher Crown Business rating 6/10 reviewer ElectricAnt ISBN 0609610694 summary The way you shouldn't run your business My first impression was that this book was a former employee's act of revenge against the big bully boss, but as you read along you see that Southwick kept a neutral point of view, presenting only the facts without jumping to the conclusions.

As you would expect, there is more business than technology in the book, not to say that this is bad, but you'll find only the top slice of Oracle's business: sales, marketing, consulting etc. You won't find many discussions on how, why and which technology has been created or adopted by Oracle -- it's mostly how this technology has been sold to customers, and what happened afterwards.

Southwick covers nearly all of Oracle's history, starting with 1979 and up to mid-summer 2003 when Oracle launched its campaign to acquire PeopleSoft. The book's starts with a quote attributed to Genghis Khan ("It is not sufficient that I succeed. Everyone else must fail.") which Larry Ellison obviously likes and uses quite often. After a start like that, it's all downhill from there.

Larry Ellison is portrayed as a natural leader: visionary, extraordinary productive and effective. At the same time, he is the "supreme dictator," "extreme narcissist," "most controversial CEO," all this is combined to make "a grandiose, deeply flawed, yet extraordinary, human being." My favorite quote in this book belongs to Rich Hagberg (a management consultant). When he drives by Oracle's towers, he says, "I tell my kids that's where Darth Vader lives." This is not the book's only harsh definition of Ellison. If Softwar is an "intimate" portrait of Larry Ellison then Everyone Else Must Fail is definitely an "intimidating" portrait of him.

Oracle's culture is defined as "brutal, draining, and filled with potential pitfalls." The relationship between Larry and his subordinates, and what's equally important, with Oracles customers (the Oracle mindset is described as "use 'em and dump 'em.") Everyone is expendable, success must be achieved by all means, and everything is measured by how useful a person is to help Ellison implement his vision.

The list of dumped Oracle executives includes Tom Siebel of Siebel, Craig Conway of PeopleSoft, Greg Brady of i2 Technologies, Marc Benioff of Salesforce.com, Gray Bloom of Veritas, the list goes on and on. As soon as Larry Ellison feels that an executive gains popularity with customers, employees, and can, potentially, outplace him, he will find a reason to get rid of that person. Due to Ellison's personal "insecurity" to deliver the news face-to-face, many of those execs were fired "remotely," usually over the phone, and while on vacation. Coincidentally, almost all of them were fired just before the next portion of their stock options vested. Some of the discharged workers filed wrongful termination suits, but few of them won: none of them have talked to Larry since.

Only Bob Miner, Oracle's co-founder, top developer of Oracle's DB, and later head of development, is shown as a friend. Unfortunately, Bob Miner died in 1994 of lung cancer and Larry was left in the void. Over the last three years, Ellison fired all key members of his management team and concentrated all power in his own hands, leaving Oracle without much a needed counterbalance to Ellison's whimsical desires. With increased competition from IBM and Microsoft, unhappy customers, and flawed leadership, Karen Southwick questions the future of Oracle but leaves the question open.

The customers of Oracle DB were technology experts and didn't mind the need to fiddle with the product until they got it working; the real problems started when Oracle began to release ERP and CRM applications. These applications use the technology and don't invent it. In Ellison's eyes, though, the technology is "cool"; he likes to create technology and respects engineers, he doesn't like to perfect it. If something goes wrong with the product, the company attitude seems to be that it's because customers did something stupid.

I found the comparison between Oracle, Microsoft and IBM very interesting: both Oracle and Microsoft are seen as "technology" companies, both have core technologies (database and operating system) and everything else revolves around them, "you better buy everything from us or you're out." It's a sink-or-swim approach.

By contrast, IBM has marketed itself as a "solution" company that brings whatever customer asks for, the best-of-breed approach. However, in positioning .NET as an enterprise system, Microsoft makes one step forward to the solution approach. Oracle still hasn't make any steps in that direction.

A few things in the book are very entertaining -- for example, the story of Rick Bennett, who single-handedly served Oracle as an advertising agency from 1984 to 1990, the most aggressive ads Oracle ever ran were created by him. When Ingres was acquired by ASK Computer Systems Oracle ran a full page ad: "WE KICK ASK." This and some other examples of Oracle's ads from that era can be found on Bennett's website.

If you're looking for a recipe how to piss off your customers, screw up your employees, alienate your partners this book is for you: it has a detailed description how to achieve all that based on Larry Ellison's extensive experience.

You can purchase Everyone Else Must Fail: The Unvarnished Truth About Oracle and Larry Ellison from bn.com. Slashdot welcomes readers' book reviews -- to submit a review for consideration, read the book review guidelines, then visit the submission page.

Dylan Harris writes "I love writing software, and I enjoy reading other people's source -- how they've expressed instructions, the subtle differences when two good programmers use the same language for the same task. Then there's the pleasure of working through a new computer language: how its structure, its form, changes the way a problem is approached, a solution is expressed. Strange as it may seem, I get the same pleasure from reading poetry, but more so. Seeing a poem written in an old familiar form, say a sonnet, is like meeting someone else's code in a language I know. New poems in new forms are new programs in new languages; exciting ideas renewed, refreshed, expressed in different ways." Read on for Dylan's review of a collection from Loss Pequeno Glazier which combines these worlds of expression. Anatman, Pumpkin Seed, Algorithm author Loss Pequeno Glazier pages 100 publisher Salt rating bloody good if you like the stuff reviewer Dylan Harris ISBN 1844710017 summary Computer infected modern poetry

I can get put off by a lot of avant-garde poetry's excess use of strange words. Take Glazier's newly published first collection Anatman, Pumpkin Seed, Algorithm. He's succumbed to the usual academic habit of filling his poems with obscure incomprehensibility, like http, chmod, EMACS ... hang on a second, I know these words. They're not literary jargon, they're software babble, the words I work with. If there isn't a schadenfreude sense of humour behind this chap's use of computer terminology in his poetry, there damn well ought to be. I love the image I get of poetry literati, finding poems stuffed with precision from a different kind of language professional, muttering "what the &hellip?"

Look, don't get me wrong, this collection isn't easy. The poems, mostly prose poems, are impressions, sequences of events, themed associations, riddled with puns (sharper than that), observation and humour. Imagine yourself a tourist, walking down a Mexican / Cuban / Texan / Costa Rican town's main street, staring at the activity, the buildings, the air, everything a slap of newness. Now realise I was snug in an English pub on a cold November night drinking some rather good warm beer, reading "Semilla de Calabaza (Pumpkin Seed)," the central sequence of this collection. I'm guided by Glazier, I'm the gawping tourist, I'm hit by his local knowledge, I'm a stranger but I know this town, I'm the visitor and I've lived here forever.

I'd better give you some samples of his work. It's not so easy, each poem is a long whole; chopping bits out destroys the context, much of the expression. Remember, too, I enjoy new ways of saying old things. Perhaps you'll see this collection's appeal to me from this chunk of the fifth "White-Faced Bromeliards on 20 Hectares (An Iteration)":

Finding a pumpkin seed in your vocabulary. A dead tree becomes
a bromeliad alter. Policia Rural. Brahmin cattle. Los Angeles,
Costa Rica's fresh furrows against smoky ridge. Banana chips on
the bus. Una casada, comida tipica lava gushing glowing twilight
plumes & sputters. Before sunset, bathing in a river heated by
lava's flow.

So why on earth am I reviewing a collection of poetry for /. ? As you've probably already sussed, Glazier's a computer chap. He's professor and Director of The Electronic Poetry Center at New York, Buffalo. He knows our not-Unix / Windows wars; they're here in the poetic armoury. It's like having your own private antagonism codified into opera, suddenly there's an aria about DLLs, or caches, and the damn thing works a treat and it damn well shouldn't. It's still his flow of impressions, but now he's taking tourists around our home town, our systems, our neighbourly rows, our familiar world is slapping them with strangeness, they're asking tourist questions, they're got tourist awe, tourist doubts.

From "One Server, One Tablet, and a Diskless Sun":

And what
kind of bugs? Lorca's mystical crickets?
H.D.'s butterflies? Though I think they
must--if the mind does have an eye--be
cockroaches fat, brightly lit, and mightily
glowing. Flying through the mind shaft to
assault any mental indiscretion. Perhaps a
relative of Burroughs introduced this
term. (Stick that in your machine and
add it up!) What vision of mainframe!
What robust modems! What processor
speed!

Some of my worst bugs have embarrassingly been "cockroaches fat, brightly lit, and mightily glowing." I'd better change the subject. It's probably obvious I believe poetry and programming share something vital. As Glazier says, in "Windows 95" (Ironic? You tell me.):

"In a sense code
resembles classical poetry. The requirements of meter (poetry)
and syntax (code) pose both limitations and challenges for the
good poet / programmer to adhere to and overcome in the
process of writing a great poem / program."

The one weakness of this collection, perhaps, cannot be avoided; Glazier's an electronic poet, a web poet; for all his care, the hyperlinks feel like they're still there, hidden and used; the slide-show web pages are unflowing still on paper. Don't get me wrong; these poems work well, but I just get the feeling, which I cannot properly justify, that they're butterflies killed, pinned and collected, fascinating, very beautiful, but their essence is the flittering movement you can never see in a book. But that's not such a problem; you could always browse The Electronic Poetry Center for Glazier's pages.

I didn't know Glazier's work when I bought this collection. It's published by the print-on-demand Australian/UK publisher Salt. I tend to buy their collections simply because they publish them; they seem to have developed the habit of excellence.

You can also purchase Anatman, Pumpkin Seed, Algorithm from bn.com. Slashdot welcomes readers' book reviews -- to submit a review for consideration, read the book review guidelines, then visit the submission page.

William Ryan writes "SQL Server CE is Microsoft's preferred database backend for its Compact Framework initiative. Compact Framework is a cool technology, but it's still in its infancy. This book does a lot to help you get started using SQL Server CE." Read on for the rest of Ryan's review, or revisit his November review of a related book, The Definitive Guide to the Compact Framework . SQL Server CE Database Development with the .NET Compact Framework author Rob Tiffany pages 450 publisher Apress rating 10 reviewer William Ryan ISBN 1590591194 summary A start to finish discussion of using SQL Server with SQL Server CE on the Compact Framework

This book comprises 10 Chapters in just under 450 pages, including the indexes and usual book stuff. Since CE supports ASNI Sql, there are a few chapters that discuss using SQL to manipulate databases, which are probably not necessary for most database programmers. Chapters 4-8 are dedicated to DDL (data definition language), DML (data manipulation language), and taking advantage of metadata. It's a good discussion of these subjects, and I guess an author must include them to be thorough, but if you aren't that familiar with SQL, you probably have some learning to do before diving into data-driven PDA apps.

Enough about the background, though. The book really excels in two areas, one of which I think is probably useful to any developer, even if you don't use the Compact Framework or Microsoft Products. That area is security.

Far too many developers blow off security concerns, or claim to care but do little or nothing about actually increasing security. Let's face it: no matter how secure your OS is, no matter how killer your firewall is, today there are a lot of people trying to break your app and they aren't always outside of your company. Tiffany points to a GIGA Information Group article criticizing the industry for ignoring security on mobile devices.

A lot of what he says is focused on security issues that are 'common sense,' and yet ones that people ignore all the time. It's kind of a shame that a writer needs to explain the benefits of using 'Strong Passwords,' but let's face it, no matter how well you write your app, it won't be secure if you leave the front door open.

In no way am I saying that the author's discussion of security is limited to such elementary topics, but he does a great job of bringing many issues into focus and suggesting ways to deal with them.

The other area that this book really excels in is getting you through replication. This is not a fun topic if you don't know what you are doing and there isn't a lot of literature out there to help you get through PUSH/PULL subscriptions and the like. Pragmatically speaking, of the topics this book covers, Tiffany's coverage of replication is probably going to benefit people the most, because if you can't sync your PDA with your server, you are effectively out of gas. If you aren't a Sql CE user you won't appreciate the value of this chapter, but love MS or hate them, the newsgroups and forums are filled with folks with the same sorts of problems that the author works diligently to get you through.

It's hard to know what will and won't work yet on the Compact Framework and CE. It's quite helpful to have a list of common functions that are supported listed in depth -- another thing I liked about this book.

What else? Well, the text was well written, very similar to his last book on Pocket Access (Pocket PC Database Development with eMbedded Visual Basic) and easy to read. If you are a total newbie to CE, you can use this book and hit the ground running. Everything that you need to write professional apps is included, and I can't find anything that Tiffany omitted.

I really appreciate the fact that the author wrote an entire book on such a niche subject. Many areas, particularly the Compact Framework, don't have a lot of literature on them and if you are writing SQL Server CE, you are on your own...until now.

If you develop in CE, or plan to, this book is a Must Have.

You can purchase SQL Server CE Database Development with the .NET Compact Framework from bn.com. Slashdot welcomes readers' book reviews -- to submit a review for consideration, read the book review guidelines, then visit the submission page.

DrCarbonite writes "Spidering Hacks is a well-written guide to scripting and automating your data-seeking forays onto the Internet. It offers an attractive combination of the solving the problems you have and exposing you to solutions that you weren't aware you needed." Read on for Martin's review of the book. Spidering Hacks author Kevin Hemenway and Tara Calishain pages 402 publisher O'Reilly rating 8 reviewer Jeff Martin ISBN 0596005776 summary A wide-ranging collection of hacks detailing how to be more productive in Internet research and data retrieval

Introduction Spidering Hacks (SH), by Kevin Hemenway and Tara Calishain, is a practical guide to performing Internet research that goes beyond a simple Google search. SH demonstrates how scripting and other techniques can increase the power and efficiency of your Internet searching, allowing the computer to obtain data, leaving the user free to spend more time on analysis.

SH's language of choice is Perl, and while there are a few guest appearances by Java and Python, some basic Perl fluency will serve the reader well in reading the Hack's source code. However, regardless of your language preference, SH is still a useful resource. The authors discuss ethics and guidelines for writing polite and properly behaved spiders as well as the concepts and reasoning behind the scripts they present. For this reason, non-Perl coders can still stand to learn a lot of useful tips that will help them with their own projects.

Overview

Chapter 1, Walking Softly, covers the basics of spiders and scrapers, and includes tips on proper etiquette for Web robots as well as some resources for identifying and registering the many Web robots/spiders that exist on the Internet. Hemenway and Calishain should be credited for taking the time to be civically responsible and giving their readers appreciation for the power they are utilizing.

Chapter 2, "Assembling a Toolbox," covers how to obtain the Perl modules used by the book, respecting robots.txt, and various topics (Perls LWP and WWW::Mechanize modules for example) that will provide the reader with a solid foundation throughout the rest of the book. SH does a great job introducing some topics that not all members in its target audience may be familiar with (i.e., regular expressions, the use of pipes, XPath).

Chapter 3, "Collecting Media Files," deals with obtaining files from POP3 email attachments, the Library of Congress, and Web cams, among other sources. While individual sites described here may not appeal to everyone, the idea is to provide a specific example demonstrating each of certain general concepts, which can be applied to sites of the reader's choosing.

Chapter 4, "Gleaning Data from Databases," approaches various online databases. There are some interesting hacks here, such as those that leverage Google and Yahoo together. This chapter is the longest, and provides the greatest variety of hacks. It also discusses locating, manipulating, and generating RSS feeds, as well as other miscellaneous tasks such as downloading horoscopes to an iPod.

Hack #48, Super Word Lookup, is a good example of why SH is so intriguing. While utilizing a dictionary or thesaurus via a browser is simple, having the ability to do so with a command-line program allows the user an automated approach, reducing distractions.

Chapter 5, "Maintaining Your Collections," discusses ways to automate retrieval using cron and practical alternatives for Windows users.

Chapter 6, "Giving Back to the World," ends SH by covering practical ways the reader can give back to the Internet and avoid the ignominious leech designation. This chapter provides information on creating public RSS feeds, making an organization's resources available for easy retrieval by spiders, and using instant messaging with a spider.

Conclusion

There are extensive links provided throughout the book, and this indirectly contributes to SH's worth. The usual O'Reilly site for source code is available and Hemenway also provides some additional code on his site. A detailed listing of the hacks covered in SH is also available online from SH's table of contents.

The Hacks series is a relatively new genre for O'Reilly, but it is rapidly maturing and this growth is reflected in Spidering Hacks. Hemenway and Calishain have done good work in assembling a wide variety of tips that cover a broad spectrum of interests and applications. This is a solid effort, and I can easily recommend it to those looking to perform more effective Internet research as well as those looking for new scripting projects to undertake.

You can purchase Spidering Hacks from bn.com. Slashdot welcomes readers' book reviews -- to submit a review for consideration, read the book review guidelines, then visit the submission page.

Sethb writes "For Us, The Living, Robert A. Heinlein's first novel, written in 1938, is not a lost masterpiece. It is, however, a fascinating piece of writing for the Heinlein fan to ingest. It's not a book you should give to a friend to introduce them to Heinlein, in fact, it works best as what it is, the last piece of Heinlein's work to be published, and it should almost certainly be one of the last pieces someone starting to read Heinlein should attempt." Read on for Sethb's review. M : CBC also has a feature about the book. For Us, The LIving author Robert A. Heinlein pages 288 pages publisher Scribner rating 3 reviewer Seth Bokelman ISBN 074325998X summary Great piece for die-hard Heinlein fans, not for newbies.

The book starts with an excellent foreword from Spider Robinson, a friend of Heinlein's as well as a fan, and an excellent Sci-Fi writer in his own right. Spider lays it all out for you in the foreword: this book isn't strong on stories, it's strong on ideas. People who found Heinlein's later works too preachy should steer clear, as this book is probably his preachiest. Robinson speculates that Heinlein really wanted to convey his radical ideas, having just lost a political race, and spent too much of the book standing on the proverbial soapbox, and not enough telling a good story. He says that Heinlein learned from this, and went on to become a master storyteller, learning that people are much more likely to sit still for the lecture if it's embedded in a gripping story.

And that leads me to exactly what's wrong with For Us, The Living. There's very little story in it. There is a plot, and it goes like this. Perry, our hero, (n reality a thinly veiled version of Heinlein himself), is involved in a car accident in 1939, and wakes up in the year 2086 in the body of someone who looks very much like himself, but the original inhabitant of the body chose to end his life (shades of Stranger in a Strange Land here). Our Hero was discovered in the snowy Nevada mountains by a woman named Diana, who is a professional dancer and lives in the mountains. She takes him back to her place to recover, and they're lounging around her house naked by the second page of the book.

From then on, the rest of the book is primarily spent following our hero as he is lectured (literally at times) on the ways of the future, covering topics such as polygamy/polyamory, nudism, the stupidity of jealousy, economics, religion, and the treatment of criminals as patients who need to be cured, rather than miscreants who need to be punished. Many of the ideas that turn up later in Heinlein's books, especially his later books, appear here for the first time. The book is very much, as Spider calls it in the foreword, Heinlein's literary DNA. This is the primordial ooze from which the later books, (Time Enough For Love, Stranger in a Strange Land, Starship Troopers, The Moon is a Harsh Mistress, and dozens more) are formed.

I found Heinlein's predictions of the future very interesting. Since the book was written in 1938-1939, the world hadn't witnessed World War II yet, though Heinlein predicts it. In his version, the U.S. stays out of the War, and Europe eventually self-destructs. Heinlein gets quite a bit of the future right, and quite a bit of it wrong. For instance, in 2086, they still haven't landed a man on the moon, though they're working on it. And, while in the future everyone has terminals (seen in later Heinlein novels) from which they can access live video and audio, information is still printed on paper and transported physically via pneumatic (and magnetic) tubes. But, given that it was written before the atomic age, those things are forgiven, and they're part of what makes the book interesting to read.

It's very obvious why this book wasn't published in 1939 -- it's not very good. Also, much of the subject matter is so controversial and sexual to this day that no major publisher would have dared print it then. The book is a bit rough, and a bit "off" in places. For instance, Heinlein uses a two-page footnote(!) to give us Diana's life story, rather than weave it into the story or the dialogue, something he'd never do in his later work, and the story only starts to get compelling in the last 50 pages or so, once the bulk of the lectures are past us.

So do I recommend this book? Yes and no. If you're a Heinlein fan, and you've read most, if not all, of his other work, then you'll love this book, and you should get a copy right now. It's a great snapshot of Heinlein's writing while he was still struggling to define it himself. If you've never read a Heinlein book, don't start here, pick up Starship Troopers, or Have Spacesuit, Will Travel. If you've read a few Heinlein books, read a few more before you try this one, especially Time Enough For Love, and his later works. I've read everything he ever published, and was sad when I finished off The Menace From Earth, as I'd run out of Heinlein to read. This book provided me with one more thrill, and it made me appreciate how strongly Heinlein held his convictions, and how far he came as a writer, from this, his first attempt.

Now that Bob & Ginny Heinlein have passed on, however, this is almost certainly the last significant piece of Heinlein's writing left unpublished, and for us, the living, it's fun to have something new from the Grand Master to curl up with on a cold winter night.

You can purchase For Us, The Living from bn.com. Slashdot welcomes readers' book reviews -- to submit a review for consideration, read the book review guidelines, then visit the submission page.

honestpuck writes "Back before the advent of Mac OS X, my favourite (and for many years, only) development environment was one variety of Unix or another. The nicest thing about Unix was that the development environment stayed pretty much the same regardless of the variety; this stayed the same with the introduction of Linux." Honestpuck examines how true this still is (as well how accurate the chosen title is) in his review of Prentice Hall's The Linux Development Platform, below. The Linux Development Platform author Rafeeq Ur Rehman and Christopher Paul pages 320 publisher Prentice Hall PTR rating 7 reviewer Tony Williams ISBN 0130091154 summary Good guide to developer tools

The Linux Development Platform might be better titled "The GNU Development Platform" since almost all of the tools discussed come from the FSF, and those that don't are nevertheless open source; as a result they will run on almost any Unix variety. You know that the 'Linux' in the title is almost just a marketing ploy, but we will forgive Prentice Hall and the authors. Certainly more people will buy this book to learn about using these tools under Linux than under any other *nix variety.

The book starts with a short chapter on software development per se before getting down to the nuts and bolts. It starts in the obvious spot, with editors, and quickly covers choosing an editor before taking a brief look at Emacs, Jed and VIM. The rest of the book is devoted to much less contentious issues.

As a whole, the text provides a good grounding in using gcc, make, CVS and GDB, with enough extra information on smaller tools and larger issues (such as cross-platform and embedded systems) that you will not need more than this book and, perhaps, the man pages to understand and use these tools. Of course others, have written entire volumes on each of these topics, but for most of us this book will provide the information we need.

The Linux Development Platform comes with a CD containing the source for a fair number of the tools discussed, so you can build any tools which happen to be missing on your platform, though some of the included apps are, of course, already a version or two behind.

The writing is mixed in quality: while never bad, it has a slightly heavy, technical feel to it, often a bit wordy or cumbersome. This rarely gets in the way of understanding, but it does slow you down. The topic coverage is good, moving from a beginner level right through to a good understanding of each tool discussed. More importantly, all the tools you will need are covered.

I imagine this would make an excellent companion text for any programming course: note that it doesn't provide details on any programming language, but covers everything else you need to know regarding the development tools. It is thinnest in the discussion of editors, really only giving a brief overview of each. I cannot really see this as a fault since detailed coverage really would take a separate book, and this quick look is better than pretending to cover the topic well and failing. The other possible weakness is that there is almost no coverage of general Linux usage, so calling the book The Linux Development Platform is a bit of a misnomer -- it is really devoted to the tools available for development, not the underlying operating system at all. Once again, I feel that this lack is not serious; most buyers should know enough about the operating system and any attempt to cover it adequately would have swelled the size and cost of the book.

Prentice Hall PTR have a site for the book with a Table of Contents or you can see the whole book in HTML format at FAQs.org.

I would recommend this book to anyone who would like a good, general introduction to developing software on a Unix platform. Though it's not a cheap book, it is a good one. It was certainly a relief for me to find a good book in Prentice Hall's 'Bruce Peren Open Source Series' after a couple of flawed ones.

You can purchase The Linux Development Platform from bn.com. Slashdot welcomes readers' book reviews -- to submit a review for consideration, read the book review guidelines, then visit the submission page.

Dan Clough writes "I found Linux Power Tools to be a useful book, although it does have some shortcomings. It's a 644-page, well-written book that covers almost all aspects of managing, administering, and optimizing a working Linux system. The book's cover claims the target audience as intermediate to advanced users, but I think that beginner to intermediate would be more accurate. More advanced users may find Linux Power Tools a little beneath their level." Read on for the rest of Dan's review. Linux Power Tools author Roderick W. Smith pages 644 publisher Sybex rating 8 of 10 reviewer Dan Clough ISBN 0782142265 summary Well-written introductory and intermediate material; a useful jumping off point for many tasks though not the definitive source for specialized ones.

The text doesn't cover installing a Linux system, but does point out some of the differences among the major distributions in common use today, specifically Debian, Mandrake, RedHat, Slackware, and SUSE. Much of the distro-specific information is contained in a chapter on package management (RPM, deb, tar.gz, and the GUI tools for the aforementioned distros). I found this book a good reference for a new user (and especially someone self-administering their Linux box for the first time), but most "expert" users will not find much here that they don't already know.

The author covers a wide range of software that is frequently used. This includes the major desktop environments KDE and Gnome (with a brief discussion of alternate window and file managers which can be used to create your own custom environment), and office application suites (fairly simple overviews of OpenOffice.org, KOffice, and Gnome Office). Also covered are the two most common bootloaders (LILO and GRUB), printer configuration options (LPRng and CUPS), and a pretty basic section on command-line shells and scripting. There are a couple of chapters that touch on the basics of doing backups (using tar), and some general methods of improving the security of a Linux system (such as using proper passwords and stopping unnecessary services). These topics are followed up by several sections on basic networking configuration (TCP/IP, DHCP, and DNS), and controlling network access with firewalls, TCP wrappers, and xinetd service restrictions.

The last few chapters cover setup and operation of various common server applications, including Apache, FTP, Sendmail, Postfix, SSH, and VNC. All of these server descriptions are of the "general overview" variety, and additional resources will be required by someone trying to configure them for the first time. The book includes a basic glossary aimed at beginners, and an excellent index. The inside front and back covers contain a nice list of essential Linux configuration files, with their default locations, although distro-specific variations are not included.

The two sections that I found the most useful are the kernel customization chapter, and the one on optimizing the X Window System configuration.

Although the kernel chapter contains information that can be found elsewhere, it offers a very understandable explanation, and should make the process of compiling a custom kernel (for performance optimization) achievable for someone who hasn't done it before. In short, everything I needed to know about was right there in one place, and eliminated the need to bounce back and forth between the numerous how-to documents available online. By following this book's guidelines, I was able to successfully compile a kernel optimized for my AthlonXP CPU, containing only the drivers I need, which resulted in noticeable improvements in bootup time, application loading times, and desktop responsiveness.

In the X Window System chapter, the use of options in the XF86Config(-4) config file was well explained, including how to set custom modelines useful for a non-standard screen resolution and/or refresh rate. Font configuration was very clearly discussed, and included directions for adding additional fonts, and enabling smoothing (anti-aliasing) in applications.

Linux Power Tools is an excellent reference book, well suited to assisting in specific tasks related to Linux system administration. There is no real new information here, but this book does better than most at having many things you want to know very accessible in one reference volume. I would compare it favorably with another of my favorite books -- O'Reilly's Running Linux. In fact I've found it to be even more valuable for some specific tasks. It is very complete and recent (copyright 2003), and I highly recommend it to other intermediate level system administrators.

You can purchase Linux Power Tools from bn.com. Slashdot welcomes readers' book reviews -- to submit a review for consideration, read the book review guidelines, then visit the submission page.

hawkeegn writes "This is the latest book in the O'Reilly "Annoyances" series. Over the last few years, I've managed to glean several valuable tips about Windows 95 and 98 from the Annoyances books about those OSes. So even if I've used computers for years, I looked with glee and anticipation (well maybe not glee, much more like relief) when I discovered this book was out." Read on for hawkeegn's review of PC Annoyances. PC Annoyances author Steve Bass pages 175 publisher O'Reilly Publishing rating 8 reviewer hawkeegn ISBN 0596005938 summary How to deal with common PC annoyances, like Windows, Email, Microsoft Office, sound & video and hardware issues.

How often do you sit down for a relaxing session at your PC, only to discover you can't find that file you saved six months ago but forgot the name of it. Or to go into Word and realize several dreary tasks could mre easily be put into macros if only you knew how? Or you decide to browse the Web only to be "attacked" by pop-ups and extra windows? AAUGHH!

This book deals with the folk who use Windows and PC's. I realize there are those who loathe Windows ("Linux rools d00d!") and point to the chapter on Windows annoyances as an example of an OS gone terribly wrong. However, until the day comes that everyone uses Linux (or finds a way around Billy Boy's "evil empire"), we're stuck with it. But I digress.

The book's several chapters are divided into specific topics, like E-mail, Windows, the Internet, MS Office, Windows Explorer. Music, Video & CDs, and last but not least Hardware. And yes there's a few suggestions and software for dealing with spam. Spam spam, spam, spam, wonderful spammmmm...not! Also mentioned are items like turning off return receipt (who cares whether or not your sender received your message, it got sent didn't it?), embedded images in email, and so on. There are also sections on dealing specifically with flaws in Outlook Express, Eudora, AOL, and Hotmail.

One thing that bummed me a little personally was that the chapter on Windows annoyances for the most part are for Windows XP. In fact, the author strongly recommends, in fact almost implores you, gentle reader, to switch from Win 98 to XP. In spite of my system running slowly and sometimes crashing (and the fact that I'm rather broke these days), I'll stick with my 98 for now. Of course, one could point out if previous versions of Windows had been created "right" or "ran correctly," there wouldn't be need for a whole chapter (or even reams of books) on Microsoft fixes or how to get it to run properly.

The Internet chapter deals with getting rid of pop-ups while browsing, and introduces a nifty tool for checking dead links on your bookmarks. It's quite annoying to save a page on your favorite band or obscure sport and then discover three months later it's disappeared. Also mentioned are a few "tricks" with using Google and even AOL IMs, like making AOL IM an "ad-free" zone. In fact, several tricks in this book are centered on cutting down the amount of on-line advertising we all seem to be bombarded with.

MS Office ... ah yes, Office. What would we ever do without it? What can we do with it? Among other tips, the author describes ways of "outfoxing" Word's Auto Correct feature (but gee, Mr Word officer, I swear that's the way rutabaga is spelled!) and my personal favorite: getting rid of Clippy -- Yeah! Also mentioned are some nifty tricks for using Excel and Power Point.

Windows Explorer ... ah yes, Windows Explorer. Not bad, but it could be better. And the author points us to two alternatives to Explorer: Power Desk and Total Commander, two inexpensive utilities that do everything WE does and more. However, if you insist on staying loyal to WE, there are some nice tips here about dealing with it.

The last two chapters discuss ways of making it easier to listen to tunes on your PC, watching video streams, and recording audio from any source. But most importantly, the author advises that if you share CDs with others to use 74-minute CDs because not all CD ROMs are created equal. The 80-minute CDs may get cranky if they're put in an old CD ROM that won't read them.

Last but not least, the Hardware chapter touches upon such wondrous things as "The Wonders of a Modem Reset," "tuning up your monitor," and also a way to keep that color ink printing cartridge you just bought to last more than two weeks, just by switching your prints to the lowest quality for most of your work. When you're broke like myself, those $50 printer cartridges add up fast!

I've just touched upon a few tips here ... the book has many more, all designed to be very helpful to the PC user.

The back inside cover has a place where the CD with all these nifty utilities should be, except O'Reilly decided to save a few bucks on the book's cost by pointing to a URL and telling we gentle readers to go there to get the utilities. Alas, I'm lazy and impatient (not to mention being too damn cheap to get a DSL line) so I haven't gotten around to getting most of the utilities yet. My bad. I've gotten used over the years to books that had the CD that I could just slide into my drive and install away. I have however so far gotten SpyBot, AMDeadLink, and MailWasher. Great stuff, and I do plan to download at least a few more of these utilities. Of course, the web site where you download all this stuff is a great plug for PC World.

The "enlightened ones," as I mention, won't need to bother with this book, as they have Linux, or a Mac. But the rest of us, who do battle with our PCs daily, will get a lot of useful information out of this book.

You can purchase PC Annoyances from bn.com. Slashdot welcomes readers' book reviews -- to submit a review for consideration, read the book review guidelines, then visit the submission page.

prostoalex writes "Reviewing Richard Stevens' Unix Network Programming is akin to reviewing the New Testament for a Christian audience, or The Elements of Style for English majors. Everyone who is somehow involved in network programming on Unix/Linux systems generally refers to the tome as ultimate learning resource and the best reference out there." Read on for the rest of Alex's review. Unix Network Programming, Vol. 1: The Sockets Networking API, Third Edition author W. Richard Stevens, Bill Fenner, Andrew M. Rudoff pages 1024 publisher Addison-Wesley rating 9 reviewer Alex Moskalyuk ISBN 0131411551 summary Ultimate reference guide for network programming, protocol implementation, server-client applications on Unix

Those just starting in the field will eventually come across so many "Stevens book" references that it will eventually end up in their library. In a nutshell: Unix Network Programming is a must for anyone involved in writing network-enabled clients or server applications, requiring a variety of protocols.

The first edition of the book came out in 1990, and quickly became the college textbook and professional reference for anyone trying to get experience in the field. This is the third edition of first volume of Unix Network Programming, titled The Sockets Networking API. Volume 2 deals with Interprocess Communications and so far exists only in the 2nd edition. W. Richard Stevens didn't live to see the 3rd edition published, and the new book has Bill Fenner and Andrew M. Rudoff listed as co-authors.

The table of contents for Unix Network Programming provides a very good overview of what's packed into 31 chapters and 5 appendices that provide 950 pages of information on network programming (Addison Wesley states it's 1024 pages, but page 947 is the start of the bibliography, followed by an index which was designed by W. Richard Stevens himself for better usability). The book starts with the basics, with an introduction to network protocols and OSI model in chapters 1 and 2. The authors move on to socket programming (supporting TCP, UDP, and SCTP protocols), providing a working example of a TCP client-server application (Chapter 5) as well as SCTP client-server (Chapter 10). DNS service is covered in Chapter 10, with some additions dealing with IPv6 implementations.

The largest part of the book -- Advanced Sockets -- covers a wide range of technologies and generally it's not expected that you cover this part chapter by chapter. Chapter 12 would be of special use for anyone dealing with IPv4 and IPv6 implementations simultaneously. The authors provide an example of an IPv4 client working with an IPv6 server and vice versa. Then it proceeds to daemon processes, I/O operations on Unix, threads, raw sockets, advanced techniques for programming UDP and SCTP sockets, broadcasting and multicasting technologies, finishing off with the chapter on streams.

To avoid recapping the table of contents, it's worth mentioning that if you're an experienced network developer and have read previous editions of Stevens' book, you will find that that the book has been updated with IPv6 APIs and example code (including interoperation with IPv4 in aforementioned Chapter 12), information on the POSIX Single Unix Spec v3, a chapter on key management for IPsec (19), and three new chapters (9,10,23) on SCTP.

But wait a minute, what about the second edition, didn't it have 34 chapters, while this third one has only 31? Description of the XTI (X/Open Transport Interface) is gone, and that used to fill chapters 28,29,30,31 and 32 of the previous edition. The authors note that XTI API "has fallen out of common use and even the most recent POSIX specification does not bother to cover it." T/TCP (TCP for Transactions) is dropped as well, so if your applications still rely on either XTI or T/TCP, perhaps donating the 2nd edition to the local church library can wait.

The information above would be of interest to the professionals in the field, but what about the beginners? Can a reader expect to become proficient with developing network applications by absorbing Stevens' book? Unix Network Programming indeed makes a very good effort to be as inviting and simple as possible to the first-time reader, even while it is trying to be informative for those who've read the chapters several times. The authors generally start with the description of the solved problem, then specify the ways to solve the problem in English -- only after that do they introduce an example solution in C. The code is quite clean and universal to be re-used on Unix boxes with C++, Perl, etc. Where a proper OS function call is necessary, it's used with an explanation of what it does, and where the functionality asks for a new function, the authors introduce their own.

Don't let the word Unix in the title fool you into thinking that you will need a separate book for Win32 platform (or Linux, for that matter). Apparently, there are differences in OS-specific function calls, but as far as protocols and implementation of specific functionality, the book would provide useful examples for Microsoft developers as well. What about Apple Mac OS X? On page xxi the authors claim the code has been tested on Mac OS X on PowerPC, HP-UX 11i on PA-RISC, AIX 5.1 on PowerPC, FreeBSD 4.8 on x86, Linux 2.4.7 on x86, FreeBSD 5.1 on SPARC and Solaris 9 on SPARC.

If you're reading the book for the first time, but have been through a network class before, you might skip Chapters 1 and 2, where the basics of network interaction (port numbers, OSI model, Internet protocol suite, netstat command, TCP connections, etc.) are covered. It makes sense to peruse the starting chapters if you are not familiar with SCTP.

Since many colleges in the United States and around the world use this title for their network programming classes, a handful of exercises follows each chapter. The questions are not programming projects, just quick self-test opportunities, e.g. Chapter 18 (Routing Sockets) is followed by the question: "What would you expect the sdl_len field of a datalink socket address structure to contain for a device named eth10 whose link-layer address is a 64-bit IEEE EUI-64 address?"

Some of the things from Stevens' book (like the desire to write a wrapper function for everything) might drive you crazy, although if you accept the author's style and follow the textbook by typing up and trying the source code, you will end up with a rather nice API library for all occasions by the time you get through the first two parts. It would also certainly be nice if the book, despite the title, included at least an appendix on Windows-specific implementations for those developing clients for the Microsoft platform.

Unix Network Programming is indispensable if any part of your professional or academic career involves writing client-server applications or programs requiring network communications. A good knowledge of C and familiarity with Unix internals is required, while the book is gentle enough to provide good guidance for the beginner in the network programming field. As W. Richard Stevens' mentioned in one of the interviews, "When I hit something that I don't understand, I take a detour and learn something new. This often makes my books late by a few months, but I think accuracy and completeness are essential."

You can purchase Unix Network Programming, Vol. 1: The Sockets Networking API, Third Edition from bn.com. Slashdot welcomes readers' book reviews -- to submit a review for consideration, read the book review guidelines, then visit the submission page.

CrankyFool writes "On advice of a foolish sci-fi bookstore clerk, I once purchased the entire Honor Harrington series in preparation for a long trip. The upcoming days would find me in a cold sweat reading these books, all the while muttering 'unclean ... unclean ...' and wishing I had something, anything, else to read. They were bad. They were very, very bad. To paraphrase Pratchett, they were so bad they went though the other side of bad and were simply not very good anymore. Look, there go some one-dimensional bad guys! Look, there goes the one-dimensional good guy (well, person)! Look, she's put in impossible tactical odds and yet somehow still manages to triumph! Look, she gets no respect back at home! Look, the next book rehashes the EXACT SAME PLOT. Needless to say, I do not like David Weber, nor do I like the Honor Harrington books. I am deeply distrustful of anyone who does." Read on to see what this has to do with Walter Jon Williams newest book, Dread Empire's Fall: the Praxis. Dread Empire's Fall: The Praxis author Walter Jon Williams pages 448 publisher HarperTorch rating 2 reviewer Roy Rapoport ISBN 038082020X summary Weber as imagined by Williams. Liked Harrington? You'll Like Martinez.

So it's a damn, damn shame that DEF:tP feels like it's written by Weber, because I really like Walter Jon Williams. I liked his cyberpunkish Hardwired and Voice of the Whirlwind. I liked his fantasy City on Fire and Metropolitan. I really liked his story of how a culture may select Gods to manage the most dangerous of technologies (Aristoi), and I thought his comedies (The Crown Jewels, Rock of Ages, and House of Shards) were, well, just damn funny.

I don't know what happened here, other than maybe Williams has Weber's arm up his ass -- that's the only explanation I can come up for this book.

The background, at least, is somewhat interesting: The Shaa, an alien race, have subjugated everyone around them for thousands of years to the point where nobody even thinks of the concept of rebellion -- everyone's been assimilated into the Shaa empire. This includes the Terrans (whose process of subjugation is the cause of the naming of the battleships Bombardment of Los Angeles, Bombardment of Delhi, Bombardment of Buenos Aires, and a few others) and the Naxid, who were the first race to be subjugated by the Shaa. The Naxid, by the way, are insectile (or insectoid, as the book prefers to call them). As everyone knows, insectile creatures are inherently evil. You'll be happy to know that one of the other races, the Torminels, is a race of nocturnals hunters, with "a plump and furry body." As is appropriate for teddy bears, the Torminels appear to be relatively harmless but when pushed are discovered to be ferocious and honorable fighters. Gotta love the Ewoks!

Anyway, back to the story: Everyone's living in harmony. Unfortunately, the Shaa, who are functionally immortal, have been slowly suiciding because, well, they're bored, and finally the last Shaa kills himself. Will the perfect order his race forced the universe into remain unchanged as he wished? Don't count on it.

Remember the Naxid? They're insectile (sorry, insectoid), and so do the only thing that an insectile (or insectoid) race is allowed in sci-fi books: They try to take over. All the other races band together to try to beat them. Apparently, Dread Empire's Fall will be the saga of that war. Thousands will fight, and millions will die. No one knows who will live and who will die. Anyone's life could be snuffed out at the next moment.

Well, as long as we define "anyone" to be "not Gareth Martinez or Caroline Sula." See, Gareth Martinez (who, by the way, is tall and considered handsome by some, very intelligent, and is cursed by a provincial accent and a lowly birth that means he just gets no respect) is one of our two protagonists. And Caroline Sula, described as "pale, nearly translucent skin, emerald-green eyes, white-gold hair worn collar-length ... Martinez threw the picture into 3D and rotated it, and Sula didn't have a single bad angle" is also very, very smart. Caroline, by the way, has a nasty little secret that you'll be very, very surprised to have revealed to you if you've been recently lobotomized and consequently not figured it out fairly early in the book.

Anyway, The Praxis covers the death of the last Shaa (whose name is Anticipation of Victory, by the way. Normally referred to by everyone as Vic, I'm sure, unless his mother was very angry at which point I'm sure it was "Anticipation of Victory you clean your room RIGHT NOW!") and the beginning of the take-over attempt by the Naxid. You'll be delighted to know that Martinez figures out what they're up to, but nobody listens to him, so he only manages to save one ship. And then, against overwhelming odds, manages to escape. You'll be delighted to find out that our heroine, Caroline Sula, when put in her own precarious position (not to blow the plot, but it involves overwhelming odds against her and almost certain death) manages to do PHENOMENALLY well. Really, she becomes quite the hero. No, wait, why is everyone laughing?

Gareth and Caroline, by the way, hook up very briefly but due to Caroline's little secret not much comes of it and she runs away to ignore him for approximately 400 pages until, three pages before the ending of the book, she sends him a note that basically says "Wow, you and I are both the heroes of this saga and so are destined to be incredibly lucky. Wanna hook up?" No, I'm not really embellishing this much.

The aforementioned 400 pages pass by relatively quickly (how quickly? I bought the book approximately ten hours ago, and have spent much of the intervening time having dinner with my family, downloading p^Hdrivers from the net, and writing this minireview). They are filled with one-dimensional characterizations (see this good-for-nothing non-com? Don't worry about him -- he'll be good-for-nothing until the last drop. This tough but incredibly smart retired weapons chief? Good guy. You can trust him not to screw up. Ever. This aristocracy Captain who likes soccer more than having a functional warship? Go ahead and write him off) and questionable strategic thinking.

Williams does throw some interesting twists into the DEF universe. The Shaa empire is ruled by the laws of The Praxis, the major religion everyone's bought into. The Praxis forbids most of the more interesting uses of technology -- bioengineering is forbidden, as is AI. FTL weapons are non-existent and FTL travel is done only through wormholes. This means that when dealing with intrasolar warfare, the main weapons are missiles. However, because missiles can't be controlled by AI, and because communication can't be FTL, the further away the missiles are from you (and the closer to the enemy), the less able you are to control them. Hence, missiles are shepherded by pinnaces, small one-person ships. Typically, a pinnace controls a volley of missiles and flies with them toward the enemy. If the pinnace pilot is very lucky and very good, they even survive, though most people don't think of this much as the last conflict the Shaa empire had (before this upcoming rebellion) was 3400 hundred years ago and lasted six days. Aside from wormhole travel, all other tech is decidedly hard sci-fi -- lasers and missiles, and both explosive and propulsion power is provided by simple anti-matter. Acceleration couches are an important fixture on ships. In fact, acceleration plays a pretty important role in most of the battles (and Williams makes one of the races both supreme tacticians and incapable of anything more than 2G. OK, that's different).

Really, though, there's nothing there to redeem the one-dimensional characters, the simplistic prose, the improbable odds our heroes manage to slog through with great distinction, and the waste of your time. If you like Weber's Harrington series, you probably want to check it out. If you're the sort of Walter Jon Williams fan who simply has to read everything he writes, your decision will be clear. As to the rest of you ... stay away.

In case you're interested, Williams has a homepage.

You can purchase Dread Empire's Fall: The Praxis from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

David McClintock writes "In David A. Schmaltz's new book, The Blind Men and the Elephant: Mastering Project Work, we find a powerful metaphor for the collaborative work involved in software or systems development. The metaphor is simple -- like the book title, it comes from John Godfrey Saxe's famous poem about the six blind men from Indostan. Simply put, Schmaltz is saying that your project is an invisible elephant. It's standing in a room, waiting to be revealed by a group of groping teammates." Read on for McClintock's review to see how well the analogy stands. The Blind Men and the Elephant: Mastering Project Work author David A. Schmaltz pages 160 publisher Berrett-Koehler rating 10 reviewer David McClintock ISBN 1576752534 summary With a powerful central metaphor, Schmaltz shows how to make your collaborative projects personally rewarding.

Each participant on a collaborative project encounters a piece of that project, rarely the whole elephant. We grasp whatever we can -- an ear, a tail, a trunk, a leg, a tusk, a broad, flat side. Based on what we grasp (our piece of the project) we extrapolate an understanding of the whole: a fan, a rope, a snake, a tree, a spear, a wall. Schmaltz develops these analogies in terms of project experience. We encounter a fan that brings us fresh air, a rope that binds us together, a snake that abuses our trust, a tree that evolves in structure above and beneath the surface, a spear that puts us on the defensive, a wall that challenges our personal progress. A chapter is devoted to each analogy.

This isn't a storybook, though. These simple metaphors are touchstones for Schmaltz's broad exploration of what makes projects meaningful. Schmaltz sheds light on the dark matter of project management -- the stuff that blocks us from succeeding on projects as individuals and as teams. He even leads us through the panicked self-talk that runs through a manager's head at the start of a project. With rich writing that's rare in management books, Schmaltz gives us a 360-degree view of project management itself -- project management is this book's invisible elephant. The elephant emerges.

You won't find any worksheets, diagrams, flow charts, procedures, instructions, or textbook problems in this book. Schmaltz gives us something more valuable and memorable: fresh ways to think about how we approach and manage projects. For example, managers should encourage each person to find a personal project within each project, something personally "juicy" to sustain interest and make the effort valuable. Going beyond the stated objectives of a project, each of us needs to ask ourself, "What do you want?" -- and to keep asking that until our personal goals emerge. These goals don't compete with the team's purpose -- they bind us to the project's success. This is the process of what Schmaltz calls "finding your wall."

Just as managers should encourage this kind of buy-in rather than try to externally motivate a team, managers should not impose a prefabricated structure onto a team. Schmaltz argues that when people find a personally juicy goal within a project, they will strive to organize their efforts in an efficient, organic manner -- without taking that twenty-volume project methodology off the shelf.

On a person-to-person level, Schmaltz asserts that despite the risk of getting cheated by snake-like deceivers, project members are most wise to interpret people's actions generously, assuming the best and freely offering trust and help. Using the results of a computer programming competition in which the Prisoner's Dilemma was solved by having the imprisoned conspirators refuse to implicate each other, Schmaltz shows that offering trust as a first principle can lead to bigger win-wins, more often.

Schmaltz consults on high-tech projects through his firm, True North project guidance strategies, based in Walla Walla, Washington. He hosts the Heretic's Forum, a Web space designed to "capture dangerously sane ideas." In addition to his periodic newsletter, Compass, he has published one previous book, This Isn't a Cookbook.

That invisible elephant, the powerful analogy at the center of this book, will enrich the way you approach new projects and reconsider problems -- especially the parts of problems that remain invisible to you on current projects. As Schmaltz wishes in a sort of benediction, "May this elephant emerge whenever you engage."

Reviewer David McClintock is president of Wordsupply.com. You can purchase The Blind Men and the Elephant: Mastering Project Work 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 "Titling a volume 'Online! The Book' and putting "The perfect gift for any computer user!" amongst other hyperbole on the back cover must rank as this years greatest act of hubris." Honestpuck has a strong opinion of whether this hubris is justified or insane -- read on below for his review. Online! The Book author John C. Dvorak and Chris Pirillo (with Wendy Taylor) pages 701 publisher Prentice Hall PTR rating 3 reviewer Tony Williams ISBN 0131423630 summary Padding, information and errors all in the one volume. Could be worse, but not by much.

If only John C. Dvorak and Chris Pirillo (with Wendy Taylor) had been able to deliver. If only they had not strewn the book with error, verbiage and irrelavancy. Ah, well.

This volume in its 700 pages (divided into 28 chapters) tries to cover everything from hardware basics to voice over IP, in between touching on e-commerce, security, web programming, networking, content management and business websites, to name just six of the topics perhaps each better suited to a volume of their own.

This book skims, and skims fast, over a number of important and vital topics while dwelling on others that many will find useless. Chris Pirillo seems to be an expert on marketing, so that gets thirty pages, while web programming languages get ten. We get forty pages of 'Hardware Basics,' which cover information vital to getting online such as operating systems, varieties of Intel chips, video cards and gaming audio drivers. I know that if I wanted to find the perfect spot to put breakout boxes about Babbage and von Neumann (essential to any book about getting online) I'd put them in the chapter on viruses. It seems as if the three authors said "we're contracted to seven hundred pages so let's just throw in topics we know a lot about until we get to seven hundred pages -- then stop."

Then there are the errors. We get editing errors like the text that tells us a 'geostationary satellite' orbits at 'about 22,300 miles,' next to a diagram showing the number 20,300 miles. We get errors in logic like the breakout box that has "DNS servers may run Apache, which is an open source Web server program" and goes on to imply that all DNS servers will run a web server. We get errors in grammar. We get paragraphs like "Although there are dynamic Web page URLs (meaning they change, or at least part of it does), most are static (stay the same). These can be dynamic by use of a programming error or dynamic because someone named the URL extension without adding a link elsewhere on the web site." With sentence construction like that I'm still not sure if the claim intended is true or not.

Did I like anything about this book? Sure, the chapter on 'How A Modem (Really) Works' was full of good solid information. Other chapters were similar, particularly the two following on networking and handhelds, phones and PDAs. Others did contain some good information, just surrounded by dross.

You can go to the book's website, which is basically just a single page with yet more hyperbole ("Everything is here. Well-written. Comprehensive.") or visit the Prentice Hall page, which actually gives you a table of contents and a sample chapter. Just don't go straight to the Prentice Hall PTR home page and search for books with "Online" in the title, as that won't find it. Instead search for books with "Book" in the title.

I'd only recommend this book to those who want to spend a lot of time finding the good bits, a few minutes chuckling over some of the errors, and thirty dollars on a paperweight. If you're really looking for a 'perfect gift' for people new new to the net, then find something cheaper covering just the essentials, and for those more expert, find a volume that actually covers a topic of interest well.

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

doom writes "The general concept of Robert Ehrlich's book is absolutely superb: Nine Crazy Ideas in Science: A Few Might Even Be True. Here, someone with a technical background (Ehrlich is a physics prof at George Mason) and an open mind investigates in detail a number of 'crazy' ideas, to see if there's anything to them. The execution of the idea is not quite as superb, but Robert Ehrlich has done better at this difficult job than anyone else I know of. This book is highly recommend as a good review of the evidence on some scientific controversies." Read on for doom's review, in which he goes through Erlich's nine-part list, but mind the spoilers. Nine Crazy Ideas in Science: A Few Might Even Be True author Robert Ehrlich pages 244 publisher Princeton University Press rating Great idea, very good execution reviewer doom ISBN 0691070016 summary A scientist evaluates some "crazy ideas"

Here's the deck of nine ideas under consideration:

• More Guns Mean Less Crime
• AIDS is Not Caused by HIV
• Sun Exposure is Beneficial
• Low Doses of Nuclear Radiation Are Beneficial
• The Solar System Has Two Suns
• Oil, Coal, and Gas Have Abiogenic Origins
• Time Travel is Possible
• Faster-than-Light Particles Exist
• There Was No Big Bang

The game here is that Ehrlich is not telling you in advance what his conclusions were. He says he's tried to keep an open mind, and claims that during his investigations he actually changed his mind about some things (though he never says about what exactly).

So in this review I'm going to give you generalities first, and bury "the butler did it" type information after a SPOILER warning.

One of the problems with the execution of this work is that you can pretty often tell when Ehrlich is enthusiastic about an idea just from his general tone as he writes about it... and conversely, in retrospect I think I should've been able to spot when he disagreed with, because the writing in those chapters was a little confusing.

Part of his schtick is that at the end of each chapter he rates the idea on a scale of 0 to 4 "cuckoos". Oddly enough I often find that I strongly disagree with his cuckoo ratings even just based on the evidence that he presents. But the absolute magnitude of my disagreements are typically no more than a single "cuckoo".

I was worried about some of his evaluation criteria (see the introduction available on-line as a sample chapter), because he includes several points that strike me as fairly dicey: "Who proposed the idea?"; "How attached is the proposer to the idea?" and "Does the proposer have an agenda?" These all relate to judging the person rather than the idea itself. (Consider that "consider the source" and "ad hominem argument" are pretty much the same as far as logic goes.) But he does clearly understand that these are just rules of thumb, and I note with some amusement that he doesn't resort to these particular rules anywhere in the later chapters. He's more interested in the logic of the arguments, which is as it should be.

I could bring up lots of quibbles (and I probably will after the spoiler warning), but overall I found this to be a great breezy read. I learned quite a bit from it. While nothing here made me do a reversal of my beliefs, I was often surprised that the evidence for something was stronger or weaker than I'd supposed.

Here we have an educated, astute, person doing a relatively independent review of some controversial, interesting technical subjects. Why aren't there more books like this?

Ah, but at least there's one more! I see that a sequel has just come out: Eight Preposterous Propositions: From the Genetics of Homosexuality to the Benefits of Global Warming . I bet I'll be submitting a review on that one shortly ...

Anyway, now into the nitty gritty. Here's your SPOILER WARNING. Skip the following if you want to play the "guess where he's going" game with this book. Let's take it chapter by chapter:

More Guns Mean Less Crime

I'm a "right to bear arms" kind of guy myself, and I was surprised that the data doesn't seem to support private ownership of guns as a crime deterrent. Ehrlich argues persuasively that the statistical evidence for this is very weak. I appreciate the fact that Ehrlich concludes that both the pro and anti gun sides are nuts: he rates them 3 and 2 "cuckoos" respectively, where a 3 is "almost certainly not true" and 2 is "very likely not true."

But here, we come to my first strong disagreement with him. If the effects aren't strong enough to measure, why the asymmetry in the "cuckoo" rating for the pro and anti side? I might rate them both at a 2 myself.

AIDS is Not Caused by HIV

I've had the impression that the the Duesberg hypothesis was pretty screwy, but I was willing to tentatively consider it might have something of value. For example, what about the possibility that multiple diseases are now being diagnosed incorrectly as one single syndrome "HIV"?

But Ehrlich's analysis satisfies me that there's not much of scientific value in Duesberg's ideas at all. I don't argue with his 3 cuckoo rating (but I wouldn't blame you if you thought it deserved the full 4).

Sun Exposure is Beneficial

Ehrlich concludes that this looks fairly plausible, and gives it a 0 cuckoo rating, pretty much as I would have expected. Many people might find this surprising though, certainly the popular impression these days seems to be that sunlight is deadly.

Low Doses of Nuclear Radiation Are Beneficial

Here, Ehrlich lays out the case for "radiation hormesis", and I really don't think this is that fantastic a notion (the difference between a poison and a medicine is often a matter of dosage, why wouldn't this be true of radiation?). But radiation is so demonized in the popular imagination that "radiation is good for you" comes off an insane joke. Ehrlich takes it seriously, and essentially concludes that while there are reasons for suspecting that this effect exists, it hasn't been entirely established. And here we have one of my quibbles: he awards it 1 cuckoo, which translates to "probably not true, but who knows". But there is no reason for saying it's probably not true. If something is not crazy, just not established, I would be inclined to award it "0 cuckoos," aka "Why not?"

The Solar System Has Two Suns

This is the "Nemesis" hypothesis, which it will probably come as no surprise is rated at 2 cuckoos. The short version of the story: originally they looked at part of the extinction record, and it looked like there was a definite cycle. But if you look at the whole record it doesn't seem to be there.

Oil, Coal, and Gas Have Abiogenic Origins

This is subject that's been of some interest to me, ever since I heard Thomas Gold give a talk on this idea about a decade ago. It turns out that this is now looking much less like "an intriguing possibility" and much more like a truth awaiting a few funerals before it will be declared established. The odds are good that "fossil fuels" don't actually come from fossils, rather they're from hydrocarbons that pre-existed the formation of the earth, which means we're probably not going to run out of them. (So that means we can ignore those environmental wackos, right? Nope: imagine what happens to the atmosphere if we keep ramping up the rate at which we burn this stuff.)

Ehrlich rates this at 0 cuckoos, but maybe he should have invented a "-1 cuckoo" for this one.

Time Travel is Possible

2 cuckoos: no surprises.

Faster-than-Light Particles Exist

Ehrlich mentions in his introduction in the interests of "full disclosure" that he's actually strongly attached to one of the ideas discussed here (the existence of tachyons), but by the time I'd gotten to that chapter I'd entirely forgotten about this, and I was disappointed to realize that he was being an advocate, not an independent reviewer (it includes a picture of him wearing a "no tardy-centrism" T-shirt).

Ehrlich rates this at 0 cuckoos, but come on. Even just based on the write-up he presents, it's a clear 1 cuckoo.

There Was No Big Bang

Clocks in at 3 cuckoos, as you might expect.

You can purchase Nine Crazy Ideas in Science: A Few Might Even Be True from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

whirlycott writes "In case you're not up to date on what design patterns are, let's do a quick crash course before we jump into a book review on the subject. Design patterns were thrust into the software development mainstream by the book Design Patterns in 1995 (aka the GoF book). A pattern involves three components: first, a description of a generalized recurring problem; second, an abstract solution that is generally accepted; and third, a name for the sake of convenience. Patterns save time and effort by supplying developers with a shared language when discussing common problems. O'Reilly's new J2EE Design Patterns book is a timely, easy-to-read catalog of architectural patterns specific to the J2EE platform." Read on for the rest of whirlycott's review. J2EE Design Patterns author William Crawford and Jonathan Kaplan pages 368 publisher O'Reilly rating 8/10 reviewer Philip Jacob ISBN 0596004273 summary Detailed collection of patterns suitable for beginners or architects alike

If you are working on frameworks, integration projects or system components, it is my belief that you'll almost certainly pick up some ideas from this book. J2EE Design Patterns is organized according to the different layers that you might find in a multi-tier architecture: presentation, business, database, messaging, and others. Consequently, if you're a JSP developer on a project team, youll be able to get some ideas for how to organize your work as well as how to interface it with, for example, controllers, if you're following an MVC framework. Or, if you're integrating various distributed non-Java systems, you'll want to read the chapters on Business Tier Interfaces and Enterprise Concurrency.

Judging by my friends' bookshelves, another popular Java patterns book is Core J2EE Patterns. If you already own this book, you will find that this new offering from O'Reilly doesn't contain as many patterns per se, but seems to go into a greater level of detail describing each pattern and supplementing it with more code samples. A nice feature of the O'Reilly book is that each pattern gets ample coverage in enough detail for you to understand the actual problem, the causes and -- equally importantly -- how to put a solution into place. Each pattern is described using some UML notation and code samples (Chapter 2 contains a UML primer).

One of the problems that I've encountered reading books on the subject is that some steer so deeply into abstraction that they become hard to understand. Others are so stylistically repetitive that trying to read them becomes mind numbing. Fortunately, neither problem surfaced during the time that I spent reading this book. The authors avoided the visual repetition of the traditional Problem / UML / Goal / Actors format that other books follow by moving this type of description into an appendix. That lets the body of the book flow more easily and also supplies the reader with a handy quick reference in the back pages.

Do I have any complaints? Well, this book certainly doesn't suffer from any fatal flaws. But it seems that an acknowledgement of the popularity of certain components could have been included. For example, while specific MVC frameworks, like the ubiquitous Struts, were mentioned, Object-Relational mappers were not; I read some of the chapters and winced at the code samples that manipulated SQL strings and felt grateful that I'm using the wonderful Hibernate O/R mapping engine. Of course, for various reasons, some readers won't be able to use tools like these, and a book about patterns has to maintain a certain level of abstraction in order to maintain any lasting credibility. But the section on Object-Relational Mapping doesnt even mention that a class of tools exists without the use of EJB CMP (Container Managed Persistence). Thats a real shame, because manually moving data from the object world to the relational world and vice versa is time-consuming and error-prone (and frequently unnecessary) work.

It's a good book, with 285 pages of text and 53 pages of appendices. I've owned it for four days, and I've already managed to steal some of these ideas for the projects I'm working on.

Philip Jacob works for Eyeglasses.com. You can purchase J2EE Design Patterns from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Simon P. Chappell writes "Life is busy enough without writing your own infrastructure code. With all of the high-quality frameworks available today, it's no longer necessary to even think about writing low-level code (except as a technical exercise, or to express your inner geek :-) Our problem today, is to review and select the best available framework for our needs. This is a non-trivial task, but help is at hand with Java Frameworks and Components by Michael Nash." Read on for the rest of Chappell's review. Java Frameworks and Components: Accelerate Your Web Application Development author Michael Nash pages 477 (14 page index) publisher Cambridge University Press rating 9 reviewer Simon P. Chappell ISBN 0521520592 summary A tour de force! With only one quibble, this is the definitive work on Web Application Frameworks. Overview This book is a superb exploration of the current state of the web application development framework market. Both commercial and open-source/free frameworks are examined in detail.

The book works through a logical progression, starting with a discussion of what a framework is (and, of course, what it isn't) before moving on to an examination of the benefits that they bring to development efforts. The meat of the book is in the next couple of chapters where a framework (no pun intended) is explored to select and compare frameworks. A list of current frameworks is given, each being described, with strengths and weaknesses highlighted.

The trailing chapters cover aspects of development that are affected by the use of frameworks, including the obvious ones like IDE support and methodologies.

What's To Like The aspect that most impressed me was the depth of research that has obviously gone into this book. I think most of us know that frameworks are good, and a reasonable number of us could list several reasons why they are good, but I suspect that very few of us could generate such a comprehensive and cogent rationale for using a framework.

The information density in this book is quite high. Normally, I read technical books quite quickly, but this one took a while, because every good point prompted much thought and consideration. This was impressive to me after seeing so many books coming to the market that have simplification as their rationale for existence. The selection of an appropriate framework for web application development is not a simple task and this book takes it very seriously.

While non-free frameworks might be a non-issue for some of the Slashdot crowd, those of us working in corporate I.S. have to be very aware of the differences and our local management's attitudes concerning it. The book does come out strongly in favour of open-source and free software, but does not let this bind the discussion in any way. Commercial and free software are judged equally and fairly throughout.

Pragmatic is a much over-used word these days, but I would describe this book as pragmatic. The advice given concerning framework selection, urged people to consider many factors, including existing frameworks used in-house, the type of project, the degree of accordance between the services provided by the framework and the requirements for the system being written. I have seen many a framework selected because it was buzzword compliant, so this advice was a refreshing change.

What's To Consider

After enjoying the book, to reach the case studies and be disappointed was, well, disappointing. The case studies seemed rushed and lacking in substance. The idea of comparing and contrasting the four leading frameworks to solve the same problem was a good one, but somehow it didn't quite come off. The Struts case study got to me the most: I have conniptions everytime I see business logic in actions! Perhaps the case studies could be dropped in a future edition?

Summary

A tour de force! With only one quibble, this is the definitive work on Web application frameworks.

Table Of Contents

1. Components and Application Frameworks
2. Components: The Future of Web-Application Development
3. Application Frameworks: What Do They Provide and What Are the Benefits?
4. Choosing an Application Framework
5. A Catalog of Application Frameworks
6. Comparing Frameworks
7. Open Source and Components/Frameworks
8. Development Methodologies and Design Patterns
9. Integrated Development Environments
10. Strategies for Using Frameworks: Best Practices
11. Conclusions: The Future of Frameworks and Components
Appendix. Case Studies

You can purchase Java Frameworks and Components: Accelerate Your Web Application Development from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

milaf writes "Who doesn't know about XML nowadays? Quite a few people, actually: there has been so much hype around it that some people think that XML is a programming language, a database, or both at the same time. On the other hand, if you are a developer, chances are that you feel that -- no matter its usefulness -- there is not much to XML. After all, it may take just a few hours to get the hang of creating and parsing an XML document. Maybe this is why most of the many and voluminous books discuss numerous XML-related technologies, but say less about the usage of XML itself." Read on for milaf's review of a book that takes the opposite tack. Effective XML: 50 Specific Ways to Improve Your XML author Elliotte Rusty Harold pages 336 publisher Addison-Wesley rating 10/10 reviewer milaf ISBN 0321150406 summary Very well written collection of topics on XML Best Practices

In Effective XML: 50 Specific Ways to Improve Your XML, Elliotte Rusty Harold takes a different approach: know your elements and tags -- they are not the same thing! -- and weigh your choices in a context, because any technology applied for the wrong reasons may fail to deliver on its promises.

Following Scott Myers' groundbreaking Effective C++, the author invites us to re-evaluate seemingly trivial issues to discover that life is not as simple as it seems in the world of XML. In each of the 50 items (chapters), he gets into the inner workings of the language, its usage and related standards, thus giving us specific advice on how to use XML correctly and efficiently. The 300-page book is divided into four parts: Syntax, Structure, Semantics, and Implementation. Yet in the introduction, the author sets the tone by discussing such fundamental issues as "Element versus Tag," "Children versus Child Elements versus Content," "Text versus Character Data versus Markup," etc. On these first pages the author started earning my trust and admiration for his knowledge and ability to get right to the point in a clear and simple language.

The first part, Syntax, contains items covering issues related to the microstructure of the language, and best practices in writing legible,maintainable, and extensible XML documents. (In it, over 19 pages are dedicated to the implications of the XML declaration!) That seems a lot for one XML statement that most people cut-and-paste at the top of their XML documents without giving it much thought, doesn't it? Actually not, if you follow the author's reasoning and examples.

The second part, Structure, discusses issues that arise when creating data representation in XML, i.e. mapping real-world information into trees, elements, and attributes of an XML document; it also talks about tools and techniques for designing and documenting namespaces and schemas.

The third part, Semantics, explains the best ways to convert structural information represented in XML documents into the data with its semantics. It teaches us how to choose the appropriate API and tools for different types of processing to achieve the best effect. This chapter has a lot of good advice for creating solutions that are simple, effective, and robust.

The final part, Implementation, advises the reader on design and integration issues related to the utilization of XML; these issues include data integrity, verification, compression, authentication, caching, etc.

This book will be useful to a professional with any level of experience. It may be used as a tutorial and read from the cover to cover, or one can enjoy reading selected items, depending on the experience and taste. The book's very detailed index makes it an excellent reference on the subject as well. In the prefix to the book, the author writes, "Learning the fundamentals of XML might take a programmer a week. Learning how to use XML effectively might take a lifetime." I'm not sure about the "lifetime" -- that's an awfully long time for using one technology -- but for the most confident of us this still may not be enough :) . Your mileage may vary, but I suspect that you could shave a few months off that time by browsing through this book once in a while. Most importantly, it will make you a better professional and make you proud of the results of your work. Wouldn't this worth your while?

You can purchase Effective XML: 50 Specific Ways to Improve Your XML 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 "There are dozens of titles on 'corporate excellence.' Management types like them. They teach the best practices from known companies and let you know how ABC Inc. or XYZ Corp. became such a glorious business as it is. In Search of Excellence (ISBN: 0446385077) is one of them, deserving the title of 'management bible' from its publishers. Apart from the minor detail that some of the data in the book was faked. At times like these, where do you turn for a good management advice?" Read on for Alex's review of an alternative text, Merrill R. Chapman's In Search of Stupidity. In Search of Stupidity: Over 20 Years of High-Tech Marketing Disasters author Merrill R. Chapman pages 256 publisher APress rating 10 reviewer Alex Moskalyuk ISBN 1590591046 summary Over 20 Years of High-Tech Marketing Disasters

Rick Chapman, on the back of the dustcover, features an impressive resume of MicroPro, Ashton-Tate, IBM, Inso, Microsoft, Novell, DataEase, Stromberg, Sun Microsystems, Teradata and Ziff-Davis. For those who just recently caught up to speed with the computer industry, some names might sound unfamiliar. Indeed, a great many tech companies were driven into the ground either by poor management practice or poor product planning.

About the book

The author explores the stories of Digital Research, MicroPro, Ashton-Tate, Borland, Motorola, Novell, Netscape and a slew of ASPs (Application Service Companies), as well as dot-coms, to derive lessons on mismanagement. Chapman also talks about current behemoths, IBM, Intel and Microsoft, telling stories of numerous product failures and the ways the companies have managed to deal with each blow. Apple Computer is also mentioned, but don't forward a copy of the title to your local friendly Mac zealot -- contemplating Apple's current market share and influence on the market (with some speculations on what could have been done), Chapman calls Apple the world's largest irrelevant company.

Want to learn secret skills of ruining a perfectly good product line? How about being a great company for thousands of developers and then pissing off almost 100 percent of them? Want to get a clear roadway on publishing two parallel software products that compete with one another, while even the sales people are unable to clarify the differences? In Search of Stupidity takes the reader on the joyous ride, following closely the growth and downfall of technological giants.

Developers! Developers! Developers!

Famous Joel Spolsky provided a preface for Chapman's title, where he provided some interesting statistics about world's largest consumer software companies as well as thoughts on the issue of who runs the company better -- programmers or business majors? "When Pepsi-pusher John Sculley was developing the Apple Newton, he didn't know something that every computer science major in the country knows: handwriting recognition is not possible. This was at the same time that Bill Gates was hauling programmers into meetings begging them to create a single rich text edit control that could be reused in all their products," writes Spolsky, implying that people who run software or hardware companies better have some knowledge about their business.

Chapman's critique of that preface runs throughout the book -- the famous setback that can be expected from the developer's community is the notion that the code should be re-written for the new version, as the old one simply is too buggy and it's easier to start anew.

What's good about the book

In the introduction chapter Chapman provides a great overview of what to expect in the book. His style is lively, full of analogies and old tales. The book is marked by a good sense of humor, without actually going into jokes (except for occasional re-telling of Intel Pentium FPU-related humor). All the companies who were not big enough to deserve a separate chapter but still stupid enough to be in the book are mentioned in introduction. Street Technologies, who in an advertising brochure bravely claimed the owner of its software could "eliminate half of the work force," and whose literature probably never made it through the mail room. Syncronys, who sold the SoftRAM product, which promised to "double your computer memory," except for the fact it didn't actually do it. Project Iridium from Motorola, which burned through $5 billion before figuring out that market for thousand-dollar phones and hundred-dollar service charges was a bit limited.

The table of contents can be found on the book Web site, and from the subchapter names like "The Great Pentium Bunny Roast" one can deduct that the book is full of good humor mixed with sarcasm. Sometimes Chapman is merciless when mentioning some of his stories' subjects. Here's his introduction to a chapter on Netscape vs. Microsoft battle:

If you like the horror movies, you know the cast usually sports a character you've come to think of as The Idiot Who Deserves to Die. He's the knucklehead who runs screaming into the path of Godzilla just as the giant reptile is heading out to spend a relaxing afternoon destroying Tokyo, and gets squashed like a bug. The dimwit who sticks his noggin out of the deserted cabin in the woods and yells out "Mad slasher? What mad slasher?" just before the mad slasher decapitates him. The space-bound fumble-fingers who always manages to drop his blaster right when the Tentacle of Doom is zeroing it on him for lunch. If Marc Andreessen, co-founder of one-time wonder company Netscape, ever gives up high tech for a career in horror movies, he'll play that character.

The author does provide a pretty good collection of facts on just what Netscape has done wrong, and how Microsoft's onslaught could have been avoided, so the quoted paragraph is not just an attempt to personally insult Andreessen. Here's a story of Ashton-Tate and its leader Ed Esber, who eventually ruined the company:

Esber did fancy himself something of a business guru, and one of his favorite quotes was "A computer will not make a good manager out of a bad manager. It makes a good manager faster and a bad manager worse faster." He had something there. It had taken George Tate about 5 years to build Ashton-Tate to software giant status; it would take Ed Esber only 2.5 years to put the company on the road to ruin. And Esber had a PC on his desk the entire time.

Debunking the myths

Besides providing a lot of good stories from the history, Chapman also tries to dispell some myths about the industry. Most of the myths somehow involve Microsoft, which is hardly surprising, provided Chapman dedicated more attention to software companies than hardware companies. He describes the attitude towards the company in the early stages of the industry development, points out why ISVs flocked towards DOS/Windows instead of more stable OS/2, and denies the common belief that Bill Gates' project owes most of its success to the deal with IBM to put DOS on the PC.

Chapman also analyzes the mistakes made, and shows how Apple Computer could've been the 99% market share vendor right now, but a few stupid mistakes in the company's past allowed for better short-term gains while leading the company into oblivion. In the last chapter, the demise of dot-coms and application service providers is told in a sort of haphazard way, without going into details of any specific company. Chapman keeps his sense of humor and is not so full of sarcasm and "I told you so" attitude as Philip Kaplan's F'd Companies .

Overall

The book is an enjoyable read, and with roughly 250 pages of interesting and fact-packed text makes an informative one, too. Even if you have been in the industry long enough to know better about the mistakes Chapman names, the book is worth reading just to re-fresh the past memories and learn some juicy details about the companies' internals (Chapman personally worked in MicroPro's WordStar team and at Ashton-Tate, among others). For others, it's a great learn to take a look at serious and less-serious screw-ups by major technological companies.

Each chapter is preceded by a caricature. The chapter on MicroPro shows WordStar and WordStar 2000 pointing a gun to one another's head with an apparent attempt to pull the trigger. The chapter on OS/2 (titled The Idiot Piper) shows that very idiot piper playing apparently a tune of OS/2, while the products designed for the operating system are heading off the cliff. Chapter on Intel's Pentium flop features bunny suits dancing around the barbecue fire with equations like "9/3 = 2.999" on their aprons.

In Search of Stupidity is an excellent source of information, analysis and good laughs. It's one of the few industry titles that will give you a large supply of stories to re-tell to other developers over a beer. Chapman's book is also an excellent case study collection of anti-management rules that one should avoid when running a high tech company.

You can purchase In Search of Stupidity 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 Ryan writes "If you are new to the .NET Compact Framework, you are about to embark upon a challenging yet rewarding path by writing CF applications. For the experienced CF developer, you know there is a lot to learn, and that it's constantly evolving. However, Dan Fergus and Larry Roof's new book, The Definitive Guide to the Compact Framework (available from Apress) is something you'll want in your library regardless of your familiarity with the CF. The book is just short of 1,000 pages including the index, tables of contents etc. It's composed of 22 chapters and 6 appendices. It also includes Microsoft's UI Design guidelines for the Compact Framework, which was a really nice touch by the authors." Read on for the rest of Ryan's review. The Definitive Guide to the Compact Framework author Dan Fergus & Larry Roof pages 1011 publisher Apress rating 10 reviewer William Ryan ISBN 1590590953 summary This article reviews Dan and Larry's new book on the Compact Framework (SP) with the .NET Compact Framework (.NETcf). This book is the longest in terms of content on the Compact Framework to Date

The authors made Chapter 1 as interesting as the beginning of a computer book is going to get. The two best parts in the introduction, IMHO, are the discussions of the differences between eVB (eMbedded Visual Basic) and the Compact Framework as well as the differences between the full framework and the CF.

Chapter 2 is where the rubber hits the road, so to speak, and walks you through getting started and a Hello, World application. This is where the authors' attention to detail really becomes obvious. Instead of a standard such program that simply pops up a MessageBox displaying "Hello, World," the authors come up with a cool sample that gives you a good introduction to CF programming.

Chapter 3 talks about designing interfaces. Typically, a lot of developers may take this for granted (have you ever met a developer that didn't think they were a UI Expert?), but there is limited real estate on a PDA, and I think Larry's guidelines are excellent.

Chapter 4 is probably best described as "The last guide to CF controls that you'll ever need." It's packed with examples on how to use everything in the toolbox, and you can tell the authors really put some thought into coming up with interesting and useful examples. While experienced developers will certainly find this chapter helpful, beginning developers would be well advised to buy the whole book even if this were the only chapter. Although I really liked this chapter, the authors sort of skimped on one important area here, but it's not a big deal: If you want to write custom controls and have them placed in the Visual Studio designer, you have to jump through a few hoops. The authors tell you what these hoops are, but don't tell you how to jump through them. In all fairness though, if they covered everything to the level of detail this subject entails, the book would be 20,000 pages and take years to write.

Not every control that you have in your toolbox on the desktop is available here, and if you want to spice up your UI, you'll probably want to roll your own controls. Chapter 5 builds on the topic of custom controls, and delves into building your own. The next two chapters still concentrate on UI issues, mainly menu items and drawing your own graphics. If you intend to write your own control or do anything interesting with your interface, getting familiar with the graphics library is a must.

After discussing the UI, the authors veer off into the CF File System. By its very nature, the PDA has a different file system than the desktop, and is something that many new developers have a fair amount of headaches with. Roof and Fergus show you how to move around files and directories, and how to create a text file or binary. The first time I read the chapter, I was disappointed that XML wasn't discussed when writing files, but there's good reason for this; they dedicated an entire Chapter to XML later on.

With the UI and file system explained, the authors next move into the important area of data access. After all, unless you are simply playing games on the PDA, it probably needs to interact with a database somewhere and I can assure you, just about every common task that you may encounter is discussed in depth. The show you how to bind controls to data, retrieve it from a Web Service, retrieve it from a SQL Server on a local network, use SQL CE to take advantage of replication and using XML as a Data Access technology. Since a PDA may get its data from many different sources, the ability to manipulate XML is very handy. Every problem that I ever encountered regarding data access in the CF was covered here and they have some really interesting ideas on how to implement things.

The book moves on to networking. There were only two chapters dedicated to networking and I would have liked to see more, but they definitely address just about everyt task that you'll routinely face. In all fairness to the authors though, there's about 100 pages dedicated to mobile networking and web services, and it's certainly not glossed over.

Chapter 17 takes a turn into Unmanaged code and P/Invoke and is probably my favorite chapter of the book. Why? Well, because a lot of things aren't yet supported on the CF and many probably won't be. So using Interop is the only way to get stuff done. I've developed CF programs for almost a year now, and this chapter got me through two problems that I hadn't been able to figure out previously. Beginning CF developers may not find this chapter as interesting as I did because it involves API calls, but trust me, this part is a life saver! Then they go right into showing you a really practical example of using Interop and their examples address things that I constantly see asked in newsgroups.

I was impressed by the authors' discussion of some really popular 3rd-party tools. Microsoft has a POOM example, but it leaves a lot to be desired. The authors show you how to use many of its features, and then present a very popular POOM Outlook implementation that is about as cool as it gets.

The rest of the book is pretty much a wind-down. It shows you how to build a help system, create setup applications and HTML reports. However, the authors did something really cool and slipped in a chapter on configuration files and how to use them. Registry access in the CF takes some time to learn (and if you didn't read Chapter 17, good luck!) and traditional configuration files aren't natively supported. However, they create their own implementation and it's very easy to understand. I've thought about implementing a solution like this for a while, but never got around to doing it. Fortunately, Larry and Dan took care of it for me. This is definitely a solution that you will probably want to use over and over.

The last part of the book is the appendices. This stuff is thorough and packed with solutions to all of those little problems that are so pesky when you are first starting out. These serve not only to get you past a whole slew of common frustrations, but they reinforce what was presented in the book I think the degree of detail that they included in the end was another superb touch by two guys who really care about their readers.

In summary, this book is a must by for many reasons. It covers a very broad range of information and it covers the majority of it in great detail. They walk you through getting started, building cool applications and deploying them. They give you a complete arsenal or tools to help build solutions with, and I can't think of anything that they ignored. They also give you the appendices, which, as I mentioned above, will get you through a lot of common pitfalls after you've built your application. As of this writing, I have compiled and run all of the code through Chapter 15 and found it well documented and accurate, but Apress can always be counted on for this. Editorially, the content was interesting and well presented and I found the layout very pleasing.

Without a doubt, this book is really great and something that you'll surely want to purchase if you are going to write CF code.

You can purchase The Definitive Guide to the Compact Framework 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 "Everything about Cisco Networking Simplified screams accessibility: the landscape layout, the softback cover, the illustrations drawn without a ruler that literally take the sharp edges off of computers, servers, and switches (router icons, fortunately, are already round). A note on the cover indicates for the curious that the book is in full color. Each short chapter is broken into 'at-a-glance' subsections on each topic, headed 'Why Should I Care?' and 'What Are the Problems to Solve?'" Read on for the rest of Cohn's review of what he calls an imperfect but good beginner's guide to networking generally, not just Cisco products. Cisco Networking Simplified author Paul Della Maggiora, Jim Doherty pages 268 publisher Cisco Press rating 6 reviewer Michael Bennett Cohn ISBN 1587200740 summary Networking terminology and concepts for novices.

This book is clearly written for two types of people: executives from a non-technical background who get flustered when speaking to network engineers, and networking novices looking for a friendly introduction to the subject before they begin serious study for, say, the CCNA.

When I first opened Cisco Networking Simplified, I was a bit put off by the intensity with which I felt the authors and illustrator were trying to convince me just how down-to-earth they are. The organization of the book is such that it's so easy to flip through, the pithy explanations so easy to digest, that one might grow quickly suspicious that here is a book designed more to make the reader feel at ease than to actually teach her anything.

But one would be wrong. CNS is a good basic reference book. It's short because it sticks to the essentials. It's weirdly-inked illustrations do make the concepts clearer. And the friendly tone never gets smarmy. On the contrary, Maggiora and Doherty anticipate a newcomer's reaction to the material well enough to know when to be terse, and when to insert whimsical asides. The unofficial eighth (political) and ninth (technical religion) layers of the OSI model and the use of ISDN to mean It Still Does Nothing are fun tidbits, well-placed, and perhaps even useful as mnemonic devices. The paragraph explaining that "routers switch and switches route," is appropriately illustrated with two people scratching their heads. That the authors make room for "Algorhyme," Radia Perlman's poem describing the Spanning Tree Algorithm (which she also wrote), shows that they know the difference between cute and distracting, and cute and relevant.

There are some problems, though. For example, the discussion of classful addresses is outdated. The class A, B, and C system is presented as the solution to a problem caused by unanticipated Internet growth. That may have once been true, but now the time when the class system was itself perceived as the next wave of that problem has already come and gone (gone, because outside isolated or masqueraded networks, class addressing has been replaced with CIDR). An executive who reads this book and then asks his engineers whether the company has been assigned a class A, B, or C address isn't going to get a lot of respect. A more serious problem is the confusing definition of the term DCE. On page 209, it's "data circuit-terminating device." On page 210, it's "data communications equipment." The first definition is more popular according to a google search, but makes less sense (where does the "E" come from?). Perhaps both definitions are somehow valid, but in a book like this, it shouldn't be the reader's job to figure out which one. And ISDN gets two detailed pages with illustrations, while the more popular (in the U.S.) DSL gets little more than a paragraph.

Also, to call this book Cisco Networking Simplified is not really accurate. A better title might have been: Cisco Presents: Networking Simplified. Cisco has no special claim to, say, IP addressing, which is discussed in some detail. Of course, to write a basic networking book without discussing IP would be silly, and Cisco makes a lot of products that deal with IP addressing. But so do a lot of other companies.

In short, I recommend this book (three of five stars), but with caveats. Technically-minded people who already have some experience in the networking field will probably be put off by the coloring book look-and-feel (but then, it wasn't written for them). Novices who are reading this book as the first step on their way to certification may find that, ironically, it provides much more information on certain subjects (voice over IP, for example) than may be sought. It's hard to imagine anyone reading this book straight through of their own volition: it's a beginner's reference. If you're confused by a topic as it's dealt with in another networking book, you can be fairly sure that if CNS covers that topic, then it contains the simplest explanation of that topic that you're likely to find.

You can purchase Cisco Networking Simplified 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 "In the high-tech industry few people achieve such glamour and general recognition as Larry Ellison, the chief executive officer of Oracle Corp. Ellison is known for provocative interviews, for being called the industry's 'other billionaire,' for being brutal to the competitors while staying within ethical limits, and for genuine opposition to a Redmond-based software company called Microsoft." Read on for the rest of Alex's review. Softwar : An Intimate Portrait of Larry Ellison and Oracle author Matthew Symonds, Larry Ellison pages 528 publisher Simon & Schuster rating 7/10 reviewer Alex Moskalyuk ISBN 074322504X summary Insight of Larry Ellison and his corporate identity known as Oracle Corp.

Matthew Symonds took a leave of absence from The Economist in March 2000 to follow Ellison in his daily routines, his management meetings, his sales calls and his regattas. But he is not the only author of the book. After the manuscript was ready by Symonds' standards, Larry Ellison took over the footnotes. Both co-authors agreed not to change each other's text, but Ellison felt he had to clarify certain points about his life, career, and vision. Softwar is somewhere in the middle between biography and autobiography -- the life of Larry Ellison is retold by another author, although the book is uniquely personal with Ellison's remarks constantly adding to the personal touch of the book. Statements like "It was a big mistake, and it was my mistake. I didn't think that Microsoft Windows would crush IBM OS/2 and all the other desktop systems -- but it did" allow Ellison to showcase his personal viewpoint in a straightforward and succinct manner.

Unlike many biographies, Softwar doesn't start with Ellison's poverty-ridden childhood in a poor Russian-immigrant family, where he was an adopted kid. That story comes much later, but from the Chapter 1 we're involved in Oracle's selling process, with Ellison talking to the Japanese executives, Ellison giving a keynote speech, Ellison talking to his sales reps - it's all about Ellison, and it's all about selling. Rarely in the book will you see a description of the actual coding process or any description of software development practices at Oracle, which by revenue ranks second among the global software corporations. It's all about sales calls, support calls, commissions, discounts and sales numbers in the million and billion dollar range - Ellison is as concentrated on the financial revenues as a CEO could possibly be.

A supporter of open standards, Ellison does not like the cacophony of enterprise-scale products offered to the companies. "If Detroit ran like Silicon Valley, nobody would sell cars -- just parts", he proclaims. "Customers would have to figure out which were the best parts -- a Honda engine, a Ford transmission, a BMW chassis, GM electrical system -- and buy them and try to assemble them into a working car. Good luck. I know it sounds crazy, but that's how companies put together business systems today".

Since Symonds followed Ellison everywhere he went, the readers get to see Ellison's lifestyle, observe his Japanese gardens in Atherton, meet with Oracle vice-presidents and sales people, follow him in regattas, while listening to a heavy dose of why Oracle E-Business Suite is going to revolutionize many businesses around the country.

The author covers Ray Lane's departure from Oracle in great detail, while Ellison is profuse with comments on why Lane needed to be let go. Market moves of Oracle's main competitors -- Siebel, SAP and PeopleSoft -- are also followed closely, with obligatory disparaging remarks coming from Ellison about what's wrong with each competitor's business. Sometimes I felt the book got too much into describing Oracle politics, like departmental and subdivisional re-organizations with pointers on who was managing which operation, but perhaps the book would lose detail without it. If you have been employed at Oracle, or know some of the people personally, perhaps it's interesting; most of the time the descriptions of policy changes in sales force compensation is perhaps too mundane for a biographical book.

For instance, on page 139 Symonds describes Lane's pending departure to become the CEO of Novell. Symonds presents Lane's point of view:

"He said he'd talked to the board and he thought $2.5 million in options was the right number. You deserve it. I thought he'd gone way overboard, so of course I stayed. I didn't find out until I left Oracle that the board was pissed off about this. No one ever told me, and I certainly wasn't holding Oracle up for money."

Lane's quote is followed by an asterisk with a footnote from Ellison: "Not a holdup? He said he was going to Novell because of the money. I offered him more money to stay. It was a classic holdup. He stayed."

This book being a recent publication, it covers a lot of Oracle products in detail, supplemented by Ellison's viewpoints on how this or that product is going to change a certain business or industry. While Oracle is hardly a household name outside the IT field, the author makes a great effort to explain Oracle server product family in simple terms, without going too basic. Competition (and general resentment) with Microsoft runs throughout the company, and Ellison is not afraid to accentuate it. Mark Jarvis, a senior marketing official, supplied an interesting quote about Microsoft's practices and current Linux outlook: "Linux is the first thing that customers ask about. They love it." And as for Microsoft, "When they felt threatened by Netscape, it was just another company with a known HQ that could go out and bomb. But that won't work with Linux, just as it didn't work with Apache. Apache creamed them, and so will Linux. Microsoft has lost the server war."

Softwar provides an interesting insight into one of the largest software corporations, its business practices and famous personality of its chief executive officer. While this book prefers not to discuss the burned-up Ferraris on Highway 101 and personal jet fighters, we see Ellison as a serious and dedicated businessman. Ellison shares his experience from the past mistakes, talks about the current practices, and what he sees best for the company, emphasizes the idea of network computer as still useful and applicable to desktops, envisions Linux taking over the world (with Oracle supplying a lot of backend databases) and provides his insight into the future of technology. The book is a great read for those willing to find out more about Oracle or Ellison personally, as well as a primer on technology development and its future (from Oracle standpoint).

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

ajm writes "The Scar is China Mieville's second novel set in the world of Bas-Lag. His first, Perdido Street Station, has already been reviewed on Slashdot. However, The Scar is not a sequel. Though the events it describes take place after those in Perdido Street Station, they don't depend on them. The setting isn't the city of New Crobuzon, and the story of Issac Dan der Grimneblin, Lin, and Yagharek is not continued in The Scar." Read on for the rest of ajm's review. The Scar author China Mieville pages 638 publisher Del Rey rating 9 reviewer ajm ISBN 0345444388 summary genre-breaking steampunk fantasy - a must read

I'll try not to reveal too much of the plot in this review. It doesn't spoil the book if you know what's going to happen next (I've read it a couple of times myself), but watching it all unfold through the language of China Mieville is far better than reading my bland precis here. I'll just say that it's gripping enough to make you want to keep reading, and to linger over the marvelous settings. It's also a more straightforward narrative than Perdido Street Station, so if you found the twists in that one a bit confusing don't let it put you off The Scar. To get my biases and preferences on the table, I'm normally a straightforward science fiction reader of the usual suspects, for instance William Gibson, Neal Stephenson, some David Webber, Peter Watts (you've got to read Starfish), Ken Macleod, and Richard Paul Russo.

Bas-Lag, the setting for The Scar, is a strange world. Physically it's not clear it's even spherical. Technologically, it's steampunk, with punch card-driven calculating engines, steam-powered heavy industry, and airships. Magic, referred to as thaumaturgy, works in this world, but the understanding of it is like late 19th Century physics. The scientists of Bas Lag know there is a physical underpinning to thaumaturgy, and they understand some of the particles and forces involved. It is manipulated by calculation and machines, not spells and wands, but some are more skilled in its use than others. The inhabitants themselves are of many different races. Some (the beetle headed kepri, the cactacae, and the remade) will be familiar if you've read Perdido Street Station. Others, for instance the ab-dead, the anophelii, and the grindylow, are new. None seems out of place in Bas Lag, and all have a part to play in the story. The richness of the setting, with all of its excellently described details, really brings Bas-Lag to life.

The story is told mostly from the point of view of Bellis Coldwine, a linguist fleeing New Crobuzon on the first vessel she can get passage on, a prison ship taking a cargo of remade prisoners to one of New Crobuzon's colonies. She and the other main characters in the book are interesting -- not just for their strangeness, but for how they adapt themselves to and deal with the situations they find themselves in. For instance, there's Uther Doul, born in the city of High Chromlech, where the reanimated high-caste dead rule over the living; Tanner Sack, remade in New Crobuzon's punishment factories with tentacles grafted to his chest; and the Lovers, the scarred rulers of the most powerful part of a very strange city.

As in Perdido Street Station, China Mieville uses language wonderfully, particularly descriptive language. All the small details have the perfect names, from pubs called "Unrealized Time" and "The Clock and Cockerel" (now isn't that an excellent name for a pub?), to ships called "Grand Easterly" (shades of Isambard Kingdom Brunel) and "Terpsichoria," to the Witchocracy, Hive of the Jet Sorrow. His descriptions of places and characters are just as good. In other reviews of his work, you'll see comparisons to Charles Dickens and Stephen King, and in fact just about every other descriptive writer you could name.

For me, the main theme of the book is scarring -- physical and emotional -- what it means and what its effects are. All of the main characters in the book, and even the land of Bas-Lag itself, have been scarred. For some, as a chirgeon says, "Scars are not injuries, Tanner Sack. A scan is a healing. After injury, a scar is what makes you whole." For others, like the Lovers, scars are a source of power while for the scabmettlers they are protection.

I'd highly recommend The Scar to just about anyone, apart from hard-core space opera fans perhaps. It's an enjoyable read, but it's also a good book in a larger sense. The first two thirds are perhaps superior to the last third but when it's all so good who am I to quibble? It has great descriptive passages combined with a interesting plot involving compelling characters, set in a fully realized world. The only problem is, how is China Mieville going to top it in his next book?

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

Rathumos writes "The network security world has been waiting patiently for a definitive study of internet worms and defenses against them. Defense and Detection Strategies against Internet Worms by Dr. Jose Nazario has arrived to fill that space with a clear and concise analysis of the current state of worm defense." Read on for the rest of Rathumos' review. Defense and Detection Strategies against Internet Worms author Jose Nazario pages 322 publisher Artech House rating 10 reviewer Duncan Lowne ISBN 1580535372 summary This book provides a solid approach toward detection and mitigation of worm-based attacks.

Publishing a book on a subject as dynamic as internet worms can never result in a complete volume. The near-weekly outbreaks of modified versions of old worms and completely new designs is enough to frustrate the efforts of even the most prolific anti-virus software developers, let alone those who try to provide an overview of their study.

Nevertheless, Nazario accomplishes a clear and concise summary of the state of worms today. Seeded by a paper ('The Future of Internet Worms', Nazario, Anderson, Connelly, Wash) written in 2001, Defense and Detection Strategies against Internet Worms encourages the reader to focus on the directions worm development might take in the future, with a specific view toward anticipation of, and prepartion for, future attacks.

The book begins with a discussion of the departure worms take from traditional computer virii. An outline of the benefits for the black-hat toward a worm-based attack, as well as a brief analysis of the threat model posed by worms, provide ample reason for the computer security professional to take the study of internet worms very seriously.

Beyond this introduction, the book is laid out in four major sections. The first introduces to the reader some background information crucial to the study of worms. The author discusses the history and taxonomy of past worm outbreaks, from their sci-fi origins (think John Brunner's Shockwave Rider) through modern-day outbreaks. A thorough analysis of various worms' traffic patterns is presented, with data broken down by infection rates, number of infected hosts, and number of sources probing specific subnets. Finally, the construction and lifecycle of worms are presented, with particular attention paid to the interaction between the worms' propagation techniques and the progression of their lifecycles.

The second section of the book (ch. 6 - 8) studies the trends exhibited by past worm outbreaks. Beginning with an examination of the processes and mechanisms of infection, it progresses on to a survey of the network topologies generated by a worm's distribution. Specific infection patterns are examined, along with case studies of worm outbreaks that have exhibited such patterns. Further, this section examines the common characteristics of vulnerable targets, from older UNIX and VMS mainframes through desktop systems onward to infrastructure equipment and embedded systems. A discussion of the payload transmission methods that have made recent worm attacks so devastatingly effective, and an explaination of why liberal use of a clue-hammer on users is not by itself enough to control and prevent further outbreaks, complement chapter nine's analysis and speculation of the future of internet worms.

Section three (ch. 9 - 11) focuses on worm detection strategies, and is more distinctly aimed at the already-overworked network security professional. Effective methods of detecting scans and analyzing a worm's scan engine are presented with a focus on timely and efficient protection from further infection. Monitoring techniques for quickly recognizing, analyzing and responding to worm outbreaks leads into a detailed description of well-placed honeypots and dark network monitors ("black holes"). Discussion of the (so-far) most effective method of worm detection, signature analysis, completes the section, and covers host-based and logfile signatures, along with a brief overview of analyzing logfiles using commonly available utilities.

The final section of the book (ch. 12 - 16), per the book's namesake, aims at defense strategies against worm outbreaks. Beginning with the obvious first steps which anyone reading the book ought to have implemented (firewalls, virus detection software, sandboxing, and patching-patching-patching), the section progresses into less widely used but equally important proxy-based defense methods, and continues on to cover slowing down infection rates and fighting back against existing worm networks. For the sake of thoroughness, an overview of the legal implications of attacking worm nodes receives its fair share of attention simply to alert the reader of the potential pitfalls of proactive defense.

Defense and Detection Strategies against Internet Worms is decidedly aimed at the experienced network security professional, but holds a much broader appeal than most technical books. With its thorough historical analysis of worm progression over the past thirty years, anyone with even a remote interest in the past, present or future of the only network security issues to consistently make headlines in the mainstream press will find this both an entertaining and enlightening read. Overall, it makes a valuable addition to any geek's bookshelf.

You can purchase Defense and Detection Strategies against Internet Worms from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Matt Will writes "The Official Samba 3 How-To and Reference Guide was written by John H. Terpstra and Jelmer Rinze Vernooij in collaboration with the core developers of the Samba-Team (www.samba.org) and expert end users. The book is written with special focus towards administrators of Microsoft Windows systems, giving them a first insight into the capabilities of Samba and a well guided step-by-step guide for migrating systems from a Microsoft solution to Samba." Read on for the rest of Will's review. The Official Samba-3 HOWTO and Reference Guide author John H. Terpstra, Jelmer R. Vernooij pages 736 publisher Prentice Hall rating 9 reviewer Matt Will ISBN 0131453556 summary Good summary of setting up, using, and troubleshooting Samba 3

The book itself For people with little time, the book starts with the chapter "FastStart: Cure for the Impatient," which features many example configurations of working solutions, each illustrating working setups using Samba to different ends -- as a file and print server, CD-ROM server, etc.

In the following chapters, the How-To and Reference Guide deals with all aspects of server and security modes, domain control and backup domain control and stand-alone configurations. Each of the chapters include further example configurations as well as in-depth discussion of the chapter's topic, and a "common errors" section that answers the most obvious real life errors.

In the third part of the book (Advanced Configuration) the reader is presented with detailed information on the topics of network browsing, account information databases, and group mapping from MS Windows to the Unix world, as well as file, directory and share access controls and file and record locking. There is also a second chapter about security in this part of the book.
Still in the third part, the book explains the new features of Samba 3.0.0, for instance interdomain trust relationships and distributed file systems.

Two very thorough chapters explain the conventional printing support with Samba, as well as printing via the newer print system CUPS. Following short chapters about winbind and network management, the Guide explains how to set up and maintain system and account policies, and how to exercise desktop profile management, and provides short but informative chapters about PAM authentication, Windows/Samba network integration, character sets, and some words about backups and high availability.

Part 4 of the Samba How-To Guide deals exclusively with updating and migrating from Samba 2.x to Samba 3.0.0, including an example migration from a NT4 PDC to a Samba-3 PDC and a user guide to the SWAT (graphical interface for configuring Samba) tool.

In part 5 (Troubleshooting) the reader is given a very good checklist to verify all functions of the Samba installation are working correctly and a guide how to analyze and solve problems with Samba.

In the appendices, the book gives information on how to obtain and compile Samba, lists supported platforms, gives hints for performance tuning, dhcp and dns, and includes the man pages to the Samba programs and configuration files.

Primary audience The book is written for people in the "Windows world" who want to take a look into the services and possibilities Samba offers for them. Beginners get very detailed information which things are possible with Samba and which are not (for now), as well as the necessary background for installing and configuring Samba on a Unix/Linux system. For the advanced user, there are still some diamonds of new information and also a good reference for all the new settings and options in the new Samba release. Personal Rating I can recommend this book to everyone interested in Samba - especially the new 3.0 version - no matter if you are new to Samba or even an experienced user of the software who is interested in expanding your knowledge and trying new features. It has its place on my bookshelf of very useful documentation.

You can purchase The Official Samba 3 HOWTO and Reference 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.

Like any large enterprise, Microsoft is an aggregate, not a monolith. This is true not only of the company as a massive business entity made up of various committees, departments and divisions operating out of multiple campuses around the world, but also as a company in the original sense, a group of people working for a common purpose. Countless analysts have dissected Microsoft's corporate culture to figure out Microsoft's financial success. Karin Carter, an ex-Microsoftie herself, decided instead to write about how mid-level Microsoft employees view the place; there are programmers, middle managers, and handful of others here -- just 19 Microsoft employees (some, like Carter, former employees) with a range of academic and social backgrounds who ended up working for Gates and Ballmer's software company in "that drippy upper-left corner of the map." The result is Microsoft in the Mirror; read on for my review. Microsoft in the Mirror author Karin Carter pages 246 publisher Pennington Books rating 7 reviewer timothy ISBN 097252990X summary Revealing look at Microsoft from its employees, including war stories from the company's early days.

Microsoft in the Mirror is written for a general audience, though some of the stories it contains are probably going to draw grins or nods only from readers interested in software and programming.

The collection of employee portraits -- first person, no last names -- starts with Carter's account of being hired (as an admin), then promoted over the course of years at the company to Editorial Assistant and eventually into management. Carter joined Microsoft when the company had a few hundred employees and called itself MicroSoft. Working in multiple divisions and levels of employeedom gave her a chance to see more of Microsoft than many employees see of the companies that employ them. (The book continues with a chapter apiece for the others; Carter's account is actually split into two, bookending the 18.)

Mirror is a breezy, personal self-portrait -- maybe too breezy and personal for some tastes; just a few pages into her text, Carter has already been through one boyfriend (her initial draw to Seattle), and a 9-year marriage (maybe I should be surprised that she mentioned it at all), and several job titles. Given the company's growth rate in its early years, perhaps this compression is necessary, but I would have enjoyed finding out more about the early days in detail, a Microsoft equivalent to the way Steven Levy describes an important stretch of computer culture in Hackers.

Though Carter's is a complete and interesting Microsoft experience (complete with sudden, transient wealth), most of the best content in this book comes from the other employees she prompted to share their stories. They speak with their own voices, in a range of prose styles and breadths; they range from chatty to Garrison Keillor-style droll, and though many of the employees' responses overlap (for instance, nearly all of them talk about their Microsoft stock options, either because those options made them rich, or because the shares and options they mishandled still haunt them), each one adds to the picture of Microsoft -- the corporation -- as a complex and demanding employer, and Microsoft -- the workplace -- as one where dress is casual, coworkers are (mostly) respectful and friendly toward each other, and office pranks are mostly good natured and elaborate.

(A few of the programmers profiled had their offices remodeled by coworkers: Peter's floor was covered with sod, complete with instructions to water it by activating the room's sprinkler head with a helpfully supplied lighter, and Stewart arrived for his second day of work to find his office occupied -- completely -- by an inflated pink weather balloon.)

Carter (and her respondents) don't try to separate the personal from the corporate: at a company where perqs like windowed offices for programmers and well-stocked snack rooms for everyone are tradeoffs for long days and nothing-is-impossible project schedules, that would be impossible. This is refreshing at first, but after several chapters I found some of the stories mixing in my head.

The first chapter I read was written by Yoshi, an ambitious and confident former Adobe employee, who engineered his way into a job at Microsoft when he saw Microsoft's development of TrueType looming ominously on Adobe's future -- and cutting the value of his company stock in half. So he jumped ship.

"I figured that if I took a project at Adobe that was directly relevant to MS, I would have a good chance of landing a job. So I did that, and we subscribed to the Seattle Times Sunday edition to start scoping out places to live."

Unlike some of the profiled employees, Yoshi didn't leap to Microsoft to enjoy intellectual freedom to explore abstract problems, or because the management and dress code was looser than elsewhere. Those things may be nice, but Yoshi did it for the money, including 3,000 shares of MSFT, with no apologies. His story, and tough-guy cynical attitude, also made me think of the contractor fired over a blog posting. He sums up his attitude like this:

"So I am a software mercenary. The old style of work and pensions in extinct. You get compensated if you work hard but it is merely a long contract. I am loyal as long as I am paid for my time and effort. I am a hired gun. I believe there is no dishonor to this view. In fact, I think it is more realistic and closer to how MS thinks of its people."

By contrast, Stewart's stretch at Microsoft paints a far rosier picture of Microsoft's management as well as the company in general. Stewart started out as a summer intern, profiling the Xenix kernel ("hog heaven" for a college student), and programmed in a string of other jobs throughout Microsoft, including a mid-career stint on liason duty with IBM in Boca Raton, Florida. Clashing corporate cultures in the shared office space meant that "Microsoft employees racked up more security violations per day than an IBM employee would have in a year because we didn't follow the dress code and we didn't care about tailgating through the door." Microsoft is thought of today as the stodgy company in some quarters; 'twasn't always so, and the rest of Stewart's Boca Raton story makes this even clearer.

Stewart's Microsoft story is also one of the more challenging to Microsoft critics; he describes the Microsoft managers under whom he worked as supportive, hands-off and efficient, and Microsoft's coders as anything but sloppy or lazy. That "Microsoft doesn't care about security" is a casualism that many outside Microsoft have come to accept because of the confluence of Windows security flaws, simple repetition of the allegation, and (as I see it) envy. According to Stewart,

"One of the thing I liked at Microsoft was that most of the programmers there, in addition to being very bright, cared about writing quality, robust code. ... People cared about their code being as bug free as possible and were willing to sacrifice their weekends and social lives in order to write the best code they could. It was an attitude I saw throughout my twelve and a half years at Microsoft."

It's not surprising that people within the organization see Microsoft so differently; after all, the employees profiled come from different backgrounds and worked at different jobs within the company. More interesting to me is that in so many ways they agree with each other. Nearly all of them maintain that Microsoft is or was a rewarding place to work, and nearly all of them caution against something that may make recent CS graduates wince -- letting too much money go to your head. People who retired, or could have retired, in their mid-30s, really do have to ponder the problems that come with having too much money. (Mainly, that it can change your relationships to other people in unpleasant ways.)

The other employees profiled include Gerhardt (who arrived in Seattle on one week's notice from Germany, straight out of graduate school) and Ian, University of Waterloo graduate who was pushed to Microsoft in part by a Canadian recession. Work weeks of 120 hours, and sometimes only 80 (he "thought he was on vacation" when that happened) eventually led to chronic fatigue and insurance problems for Ian. In those days, he says, "Microsoft was still small enough that that once you were in, you were really in." Microsoft short circuited his insurance policy's depletion by giving him a job that he could do even while weakened, so he could remain covered by the company health plan while he recovered -- in other words, the sort of thing that a Big Faceless Corporation might not be expected to do.

Anne's is one of the shorter chapters, written with seeming restraint (and relief to be an ex-Microsoft employee) as she describes a work environment with mostly good relations between immediate coworkers and a fair amount of job satisfaction, but acrimony and bitterness between groups doing similar tasks, and "silly politics" surrounding the company's constant reorganizations that led to unnecessary stress.

Reading lightly, it's easy to get the impression that Microsoft hires only smart, competent people. Less-than-stellar managers and co-workers are mentioned in here, but mostly they're summed up with short, dismissive descriptions. I wonder whether this is more out of a good-natured desire to accentuate the positive or an illustration of our litigious society and fear of professional retribution. I would have enjoyed reading much more about what made them so awful, not out of shadenfreude, but out of simple curiosity, and to know how the vaunted Microsoft management machine dealt with them in the long term.

A three-part appendix rounds out the book. There's a short glossary of terms reflecting the book's general audience, defining abbreviations like DEC, HR and IT. A few Microsoft-specific ones are on the list too; can you guess what "calling in rich" means? A three-page timeline traces Microsoft's history from 1975 nearly up to the present day; since this book isn't about the details of Microsoft's history or its interaction with the U.S. federal court system, it's no crime that this timeline ends in 2002 and glosses over legal clashes. I'm most grateful for Carter's third appendix, which is a list of the prompts she sent to elicit the employee responses this book contains.

Since the computer industry in young (in all respects, but in particular the business of selling packaged, ready-to-run software), it's also changing rapidly. That means that even though the stories in Mirror reflect the recent past, they show how fast companies' relative fortunes shift and how quickly reputations change. A book like this -- mostly sympathetic to Microsoft, written by insiders -- doesn't pretend to be objective or to present a complete picture of the company, but it makes thought-provoking background reading if the word "Microsoft" makes you see red.

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

Dan Clough writes "Mastering Red Hat Linux 9 is a huge, very complete guide to Red Hat Linux 9. It's over 900 pages, and includes the "Publisher's Edition" of RH9 on 2 CDs. It is written in a style which should accommodate Linux newcomers and more experienced users alike. There are a lot of examples, code snippets, and screenshots throughout the book. In fact, sometimes the abundance of these tend to make the material a little long to wade through. Experts should have no trouble skipping over the sections they don't need, though." Read on for the rest of Dan's review. Mastering Red Hat Linux 9 author Michael Jang pages 942 publisher Sybex rating 8 of 10 reviewer Dan Clough ISBN 078214179X summary Good summary for operating a Linux system; though it uses Red Hat, it's not Red Hat-dependent.

The book starts out with an introduction to Linux, and has a good chapter on preparing to install, including hardware checklists. This is followed by a very detailed step-by-step explanation of installing Red Hat, both locally and via network. A nice part of this is a troubleshooting chapter for solving installation problems. Part Two explains the basics of using the command line, how filesystems work in Linux, and using the shell for various tasks.

Part Three includes chapters for administering users and groups on your new system, and how the RPM software package management process works. Other chapters in this part explain the bootup process and how to configure it, various ways to perform system backups, and other common administration tasks such as cron jobs and logs. Especially useful should be Chapter 12 which explains how to update/compile your own kernel. There are very good examples of the myriad kernel options, mostly by using the xconfig utility.

The next several chapters go over how to configure and use the X Window display system, including good examples from the XF86Config file. This is followed by detailed explanations of configuring and using the Gnome and KDE desktop environments. The KDE discussion is very good, considering Red Hat is more known for its use of Gnome as the default desktop. Chapter 18 introduces many of the more commonly used graphical applications in Linux, such as OpenOffice.org, Gnome Office, and the KOffice suite. Chapter 19 should be very handy for Linux/RH new users, as it outlines the Red Hat graphical configuration utilities which allow customization of the desktop look-and-feel and other system preferences.

Chapters 20-22 cover basic Linux networking. The first part of this section gives a very understandable primer on TCP/IP and network terminology. This is followed up by excellent discussions on how to setup and manage networking on your Linux computer, including security recommendations and firewall/masquerading methods. Once you've got your network running safely, there are additional chapters which cover topics such as remote access and xinetd services, and various server applications installation and operation. These include DNS, DHCP, CUPS printing operations, FTP servers (and clients), NFS and NIS, and mail servers (sendmail). Some of these services are probably more than most home users would need, and the sendmail operation in particular is a little difficult to understand.

Chapter 29 (Using Samba) will probably be a great help for people desiring to integrate a Linux system with existing Windows computers on a network. It offers an excellent tutorial on how to share files and resources across the LAN, and includes an explanation of the SWAT configuration utility which greatly simplifies initial setup for newcomers. The final chapter in the book explains how to install and setup a basic webserver using the Apache software. The appendix of the book is a relatively short section called the Linux Command Reference. There is some handy information in this, although it seems to be organized somewhat haphazardly. The book's index, on the other hand, seems to be very complete.

Overall, I found this book to be a very useful reference tool. It is basic enough for most beginners to get all the help they need, and has a good amount of usable knowledge for more advanced Linux users. One thing I realized is that much of the information here is not necessarily Red Hat-specific, so it can be helpful to users of other Linux distributions as well.

You can purchase Mastering Red Hat Linux 9 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 "The Visual Display of Quantitative Information is a recognised classic on statistical graphics; to the 1983 original, this 2001 edition adds some additional graphics, extra colour, and corrections. It is a broad-ranging work, covering history, theory and practice and, despite the formal title and scholarly references, not at all narrowly academic. It assumes only a very basic understanding of statistics." Read on for the rest of Danny's review. The Visual Display of Quantitative Information author Edward R. Tufte pages 197 publisher Graphics Press 2001 rating 10 reviewer Danny Yee ISBN 0961392142 summary the classic work on statistical graphics

Tufte begins with the different kinds of informational graphics (maps, time-series, narratives, and relational graphics), describing their origins and evolution and presenting examples of excellence in their design. Many of these are fascinating in their own right -- two that I particularly appreciated were Minard's depiction of Napoleon's disastrous retreat from Moscow and an 11th century map of China.

"For many people the first word that comes to mind when they think about statistical charts is 'lie.'" Tufte gives examples of different kinds of deceit in graphics, along with some principles for maintaining graphical integrity. He goes on to consider the reasons for the poor quality of many informational graphics: one is the relegation of their design to those with art training but without an understanding of either the substance of the material or of quantitative (statistical) methods.

Part two begins by introducing some terminology and theory for describing graphics. The principle "Above all else show the data" is formalised as maximization of the data-ink ratio, and illustrated with some "before and after" examples of erasure of redundant or non-data-ink. Tufte excoriates various kinds of "chartjunk": moire vibration (the disconcerting effect caused by repeating patterns), the overuse of grids, and the "ducks" created when the design takes precedence over everything else.

Tufte gives specific suggestions for the design of box plots, bar charts, and scattergraphs. He argues for the use of multifunctioning graphical elements -- building data measures or grids out of the data itself, for example, by using labels that also show the end points of the data ranges. And he looks at ways of maximizing data density (within reason) and using "small multiples," or repeated smaller graphics. A final chapter steps back to consider the balance between text, text-tables, tables, semi-graphics, and graphics -- "Given their low data-density and failure to order numbers along a visual dimension, pie charts should never be used" -- and to touch on the aesthetics of proportion and scale.

All of this is liberally illustrated with examples, drawn from across the natural and social sciences. Despite the space devoted to these, The Visual Display of Quantitative Information packs a lot in, avoiding repetition or verbosity. Tufte's own tables and graphs are appropriately effective and the volume as a whole is elegantly put together: though it's more than that, it could be appreciated simply as a work of art. Tufte also finds room to survey publication practices across a select sample of international newspapers and journals, comparing the data density of graphics and the proportion of relational graphics (involving at least two variables that aren't temporal or spatial).

Most obviously, The Visual Display of Quantitative Information should be read by those involved in writing, editing, or designing documents or displays that contain statistical graphics -- from professional editors, technical writers, academics, and journalists right down to high school students. But others may appreciate it too: it has changed the way I look at informational graphics.

Danny has written over 700 book reviews. You can purchase The Visual Display of Quantitative Information from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the (recently updated) book review guidelines, then visit the submission page.

Simon P. Chappell and Eric Kaun contributed reviews of Jess in Action, Ernest Friedman-Hill's introduction to Jess, a pure Java rule-based system developed at Sandia National Laboratories. Kaun writes "Jess in Action presents the Jess rule-based framework, and explores it through four meaty and well-chosen examples: a console tax forms advisor, a console PC repair assistant, a Swing HVAC controller, and a servlet-based purchasing agent. The examples vary greatly in their designs and styles of interaction between Jess and Java, and expose patterns in a concrete context. It's especially nice the way each example builds on the functionality of the one before, such as a text-based question/interview module that is extended into a Swing GUI." Chappell points out that the book's author is also Jess' creator, so he speaks from authority. Read on for both reviews. Jess in Action author Ernest Friedman-Hill pages 480 publisher Manning Publications rating 9 reviewer Simon P. Chappell, Eric Kaun ISBN 1930110898 summary Introduces rules and declarative programming style using JESS.

Eric Kaun's review, continued Jess in Action starts with an introduction to rule-based systems, goes through the basics of the Jess language, and then dives into the examples; the appendices include API references to both Jess functions and Jess's Java APIs, and numerous links and references are scattered throughout the book. If I have any complaint about the organization, it's that the book could have been even more example-driven, abandoning (or shortening) the chapter on syntax and basic functions and introducing them only when used in an example; the rest could have been left to the appendix of Jess functions.

The book is interesting and readable, but dense with concepts, so it contains only 388 pages of actual text, and 50 pages of appendices will take some (well-spent) time to get through. A second skimming impressed me anew with the richness of the material, and the productive way in which it's presented, so I recommend reading the book once to get the overall feel, and then going through it again with the working Jess command shell, editor, and command line in front of you. Or an IDE if you must. :-)

Jess itself consists of a rule language, a runtime engine which supports forward and limited backward-chaining, and APIs for integration with Java; there are many add-on tools for Jess, referenced throughout the book. As with most rules engines, rules are specified as declarative patterns, not procedural code.

Jess in Action is well worth your time and attention, at the least for its exploration of rules, and at most for presenting a strong, flexible platform to tackle what is probably one of the uglier parts of your development process: the sequencing and parameterization of business decisions. Although the list of Cons below is longer, they're just nit-picking; this is an excellent, entertaining, and productive read that will likely expand your programming horizons considerably.

Pros

• Clearly, concisely, and entertainingly written for Java programmers of any background
• A strong introduction to two important topics: rules and declarative programming style
• Well-chosen and developed working examples, each with a different design style
• The description of the author's unit test framework for rules in Appendix C is a nice touch

Cons

• Early discussion of Jess syntax focuses too much on Java-like procedural style
• More of a tutorial - not long enough to be a good reference (though that would probably require a detailed Jess Patterns book)
• Discussions of development methodology and knowledge engineering are unnecessary, as they're covered better elsewhere and a short summary adds little to the book
• There's no single list of rule and Jess-related links; references to tools and discussions are scattered throughout the book
• There are no general references to rules and rule-based systems for theory and background

Simon P. Chappell's review While part one of the book has two slim chapters to introduce rule-based systems to the casual reader, the rest of the book is a no-messing user guide, reference manual and tutorial on using Jess. If you want to learn about rule-based systems, this should not be your first book. If you know of rule-based systems and have decided to use Jess, then run, don't walk to the bookstore and purchase a copy of this book.

I liked the solid, yet gentle, progression through part two, where the basics of using Jess are explained. The explanations were clear and each concept was introduced in a sequence that built upon the previous concepts and information. For example, I had thought that rules were all you had to worry about in rules-based systems, but it turns out that because rules operate on facts, designing the representation of those facts is a pre-condition of designing rules. (Right, I know you knew that, but it was new to me! :-)

Parts three through six are complete case-studies of the application of Jess in increasingly complex applications. The examples are well-explained and the rationale for each step is discussed in sufficient detail to educate but not bore.

Part seven is a self-described 'grab bag' of stuff that didn't fit in any of the other parts of the book. This section spends some time looking at using XML with JESS, including markup languages for rules, and interfacing with Jess from EJBs and Application Servers.

Lastly, there's the fact that the author of the book is also the author of the software in question. Dr. Friedman-Hill obviously knows Jess better than anyone else in the world and this shows through in the way that he not only explains how to achieve activities in and with Jess, but he also takes time, here and there, to explain some of the design decisions and trade-offs in its creation.

You can purchase Jess in Action from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the (recently updated) book review guidelines, then visit the submission page.

danny writes "Having problems with your sex life? Read on for my review of Dr Tatiana's Sex Advice to All Creation -- it may not get you laid, but you can have some fun learning about the evolutionary biology and natural history of sex." With that disclaimer in mind, read on for the rest. Dr. Tatiana's Sex Advice to All Creation author Olivia Judson pages 308 publisher Vintage rating 9 reviewer Danny Yee ISBN 0099283751 summary the evolutionary biology of sex

Dr. Tatiana's Sex Advice to All Creation mimics a write-in advice column, in which anthropomorphised animals of all kinds ask for help with their sex lives. That is just the framework, however, for an entertaining tour of the natural history and evolutionary biology of sex. Pretty much every aspect of animal sex is at least touched on, though the "all creation" of the title is an exaggeration -- there's only the occasional reference to plants and bacteria, with nothing (for example) on the fascinating topic of pollination.

The columns are grouped thematically in thirteen chapters, divided into three parts. Part one covers the "expenses" involved in sex, female promiscuity, conflicts between males, and alternative strategies for those who are poor and small. Part two covers sex and cannibalism, sex and violence (male and female), love potions and homosexuality, and monogamy. And part three looks at incest, at hermaphroditism, facultative sex and other variants, and at asexuality and theories for the evolution and persistence of sex.

Each column typically runs to four or five pages, beginning with a question.

Dear Dr. Tatiana,

I'm an Australian redback spider, and I'm a failure. I said to my darling, "Take, eat, this is my body," and I vaulted into her jaws. But she spat me out and told me to get lost. Why did she spurn the ultimate sacrifice?

Dr. Tatiana never answers directly, but looks around first at other species with similar or related problems

"... most guys prefer not to be eaten at all. ... In the scorpion Paruroctonus mesaensis, the male whacks his partner several times before racing off; in the wolf spider Lycosa rabida, the male tosses his lover in the air, leaving her in a crumpled heap as he hurries away.

... In the bristle worm Nereis caudata, something similar goes on but for once it's the man who eats his wife.

... Do other males eat their mates? I have never heard of it. But note: this is not to say males don't eat females. They do. Just not during sex. Platonic cannibalism is a problem for creatures from apes to amoebae. It's depraved out there."

and sets the question in a broader context

"... It goes without saying that such a death wish can evolve only in special circumstances. That is, being eaten must mean you leave more offspring than if you are spared. So far, your species is the only one known to meet this criterion. A male redback who gets himself munched fertilizes more eggs than a male who survives. Why? ... it turns out that sex takes longer when she's chewing away on you, which gives you the chance to deliver more sperm and thus fertilize more eggs. So your challenge is to make yourself more appetizing."

before finishing with the answer, if there is one.

"The secret is picking your moment. Female redbacks aren't greedy; when they're not hungry, they don't eat. If you offer yourself right after she's feasted, forget it. You've got to wait until she gets that mean and hungry look in all eight of her beady little eyes. And then, for what you are about to receive, may your kiddies be truly thankful."

Links to many different areas of biology are explored.

"Lysin, the protein that determines whether an abalone sperm can enter an abalone egg, is evolving at record speed. Tantalizingly, abalone are also splitting into new species at a startling rate."

And for those who want to follow up specific topics in the technical literature, there are thirty pages of notes, giving annotated references for each column, with pointers into a forty page bibliography. (Though a short recommended reading list of non-technical popular works on evolution would have been a more useful inclusion for most readers.)

Sex Advice to All Creation assumes no background in biology, and there's the occasional wordy or repetitive explanation. But even scientists for whom the evolutionary biology is old hat are likely to find some new details in the natural history. The chatty tone and the framing conceit of an advice column -- extended in the last chapter to a mock television show -- remain entertaining and decorative, never pushed so far they become annoying or distort the science.

"If you are not a hermaphrodite, incest is best if you come from a species where males have only one set of genes. If you're not a member of such a species, I urge you to avoid sex with your nearest and dearest."

You can purchase Dr. Tatiana's Sex Advice to All Creation from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Joel Eidsath writes "Imagine that you found yourself in a position to write a resume for the whole human species. It is a metaphor that Charles Murray uses several times in his book, Human Accomplishment: The Pursuit of Excellence in the Arts and Sciences, 800 B.C. to 1950." Murray not only collects such examples in this book, but attempts to explain why and how they emerge. Murray obviously courts controversy with this book; expect reactions similar to the ones drawn by The Bell Curve, which he co-authored. (Do 97% of the world's significant scientists come from the West? Can personal eminence be objectively measured? Is "accomplishment" really amenable to description by charts and graphs?) Read on for Eidsath's review. Human Accomplishment: The Pursuit of Excellence in the Arts and Sciences, 800 B.C. to 1950 author Charles Murray pages 688 publisher HarperCollins rating Thought-provoking reviewer Joel Eidsath ISBN 006019247X summary A statistical history of human accomplishment.

For our species' resume, you probably would not list to put "Defeated Hitler" as one of humanity's accomplishments, because it sounds too much like 'Beat my Heroin Addiction.' You would want to include things like 'Painted the Roof of the Sistine Chapel' or 'Discovered General Relativity.' In other words, you would want to include examples of human excellence throughout the ages.

Not only has Murray set out to compile this resume, but he sought to do it for a reason that is at the same time both interesting and audacious: once you have compiled a list of the several thousand most important creators and discoverers of all time, you can stick it into a database. The idea is that with this database a person can spot trends in accomplishment; he can identify regions and cities where excellence has clustered; he can evaluate qualities of political systems that spur innovation and those that stifle it. Murray's book is a stunning profusion of graphs and plots that do much more to teach us about accomplishment that most narrative histories.

For this to work, however, Murray first had to tackle the problem of differing opinions on who exactly deserves a place in the database. Everybody's list would differ -- yours, mine, and Charles Murray's. There would be substantial similarities between our lists, to be sure; nobody is going to leave out Newton, Darwin, Goethe, Shakespeare, Confucius, or al-Mutanabbi. But when it comes to lesser achievements, the arguments would be endless. Does Hooke make it into the list of the top 20 physicists of all time, or does Pascal make it into the list of the top 10 mathematicians?

So what Murray has done is to split up accomplishment into a number of fields and tried to take a neutral measure of each person's respective 'eminence' in the field. He measures 'eminence' by taking a number of comprehensive sources on each field and counting the references to each person and how many paragraphs they get. The sources are from as many different languages as possible and Murray does a good job of avoiding the distorting effects of ethnocentrism. He uses sharp cutoff dates at 800 B.C. and 1950 A.D. to limit the data.

What Murray winds up with is a procedurally neutral measure of human accomplishment that is stable when new sources are added or taken away, and also has good face validity. In Medicine, for example, Pasteur is first with an index score of 100, Koch is third with 90 and Freud (for clinical descriptions of mental illnesses) is 18th with a score of 34.

The Lotka Curve Murray's other major work made a certain kind of statistical curve a household word, and Human Accomplishment prepares a second candidate for improving public statistical awareness: the Lotka Curve. In the mid-1920s, Alfred Lotka noticed an interesting pattern in scientific journals. About 60% of people publish only one article for a journal. The number of people publishing more that this falls off very fast with the number of articles. This makes up a Lotka curve and is almost L shaped.

It turns out that in just about every field of human accomplishment significant figures fall along a Lotka curve. In Western literature, Shakespeare is far out along the horizontal part of the curve, Goethe a bit less so, and a whole host of lesser figures make up the nearly vertical part of the data set.

Dead White Males

Despite using several data collection techniques that wind up exaggerating the influence of non-Western cultures, Murray's data shows a strong majority of Westerners among the significant figures of world history.

Fully 97% of significant figures in the sciences come from the West. The same figure is arrived at from looking only at significant events. Even America is dwarfed by European accomplishment in the sciences, hosting less than 20% of significant figures before 1950 compared to Europe's nearly 80%. Europe's dominance over America is even greater in the arts. And though Murray makes sure to calculate what is an upper limit for artistic accomplishment in non-Western parts of the world, the graph is substantially the same as that for the sciences.

One of the astonishing parts of Murray's data is how it demonstrates the significant effects of legal equality. Jewish achievement after 1850 skyrocketed due to their newfound position before the law. Between 1910 and 1950, Jewish achievement tripled despite even the Third Reich and the Holocaust.

The graph of the achievement of woman displays a different pattern, despite their having gained substantial legal equality in the past century. Though there are slight increases in the numbers, women only represent a few percent of Murray's significant figures after 1900. Nor does the data available for the years beyond 1950 bear out any substantial increase in women's achievement during the second half of the twentieth century. Murray provides several possible explanations. Despite legal equality, women did not gain the same degree of immediate social equality that other groups did. Moreover, the substantially greater demands of parenthood upon women make achievement harder.

Decline

The last section of Human Accomplishment is somewhat surprising. When adjusted for population, Murray's numbers show a decline in accomplishment after 1800. When numbers are used that take not only total population in account, but also urban population and educated population, the decline has brought us down to nearly pre-Renaissance levels. For example, we have 65 playwrights alive today for every one in Elizabethan England. Yet do we have dozens of Shakespeares? The picture is even more stark when the 12,000 members of the screen Writers Guild are taken into account.

As a percentage, the number of significant figures in the sciences compared to the total population has dropped a great deal; this is despite a far greater percentage of working scientists and far more science and technical journals being published.

Murray goes through the data and shows why he believes that the decline is real and is not explicable by any procedural artifacts brought about by his methods. It is a somewhat disturbing conclusion to a great work.

You can purchase Human Accomplishment: The Pursuit of Excellence in the Arts and Sciences, 800 B.C. to 1950 from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

For a sysadmin, putting "MIT Network Operations" on a resume must feel pretty satisfying. James Kretchmar got the job, and now has written the book. ALecs writes with his review of Kretchmar'sOpen Source Network Administration, below. Open Source Network Administration author James M. Kretchmar pages 220 publisher Prentice Hall (PTR) rating 9 reviewer Joshua Malone ISBN 0130462101 summary A brief tutotrial on using several open source packages to monitor and administer system networks Open Source Network Administration covers a number of open source tools designed to aid in managing computers and TCP/IP networks. The tools discussed in this book are all free, and are all top-quality tools that have earned their place in any system administrator's arsenal of administration and debugging tools. Included in this book are:

• SNMP (a protocol for managing network devices and hosts)
• MRTG (the Multi Router Traffic Grapher - a bandwidth utilization meter)
• Neo (a network device administration tool that speaks SNMP)
• Oak (a syslog watcher and digester)
• Nagios (an active network/host monitoring tool)
• Flow Tools (tools for processing Cisco NetFlow data)

This book also discusses more basic debugging tools such as ping, traceroute, tcpdump and others. Finally, Kretchmar provides some pointers on building your own tools using bash, perl, sed and awk.

Kretchmar is a network engineer for MIT and has gotten a lot of practical experience in managing large networks and unruly hosts. In this book, he imparts a large amount of that experience in over 200 quick-reading, no-nonsense pages. He tells you what a tool can do, how to get it and build it and provides examples of some typical uses. While beginning network administrators will feel comforted that he takes enough time to explain the tools he talks about, experienced ones can safely jump right to his equally well-explained configuration examples without missing anything crucial.

This book read so quickly and was so straightforward that it really inspired me to fix up some areas of my network monitoring that I knew were lacking, but hadn't bothered to fix. In particular, his chapter on Oak motivated me to implement an instant messaging infrastructure (like one he mentions using at MIT) to receive event notices quickly and without dependence on e-mail. While it's no bible (my staple, the Unix System Administration Handbook, is over 800 pages), this book provides a great start on quite a few great tools - many of which I plan to investigate soon.

I was a bit puzzled at his inclusion of instructions for building each tool when most of them are simply ./configure; make; make install. Only one of the tools seemed to actually merit building instructions. At least you can't say he isn't thorough.

I give this book nine stars (out of ten) simply because it really made me realize how easy it is to configure a lot of automation that Ive been wanting. The cover price of U.S. $44.99 strikes me as a bit high in the market, but it is significantly discounted at most online book stores. I still have to recommend The Unix System Administration Handbook first, however. It is more expensive, but contains much more scope and detail than this book. Those who have digested USAH, though, should consider picking this book up from your favorite e-tailer.

You can purchase Open Source Network Administration from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page. Reviewer, Virginia Tech alum and CHUUG member Josh Malone has been a Unix Systems and Network Administrator in Charlottesville, VA for three years.

Michael Yuan writes "Enterprise JavaBean (EJB) is one of the most widely used technologies in enterprise Java. It is designed to be a scalable and flexible distributed framework. In EJB, almost everything can be done in several different ways and it offers the developer the maximum flexibility to choose the right approach for the project in hand." Yuan provides a review, below, of Bitter EJB, to guide programmers interested in large-scale Java development. Update: 10/27 18:27 GMT by T : Peter Wayner provides a somewhat deeper look at the book as well, also below. Bitter EJB author Bruce Tate, Mike Clark, Bob Lee, Patrick Linskey pages 412 publisher Manning rating 9 reviewer Michael Yuan, Peter Wayner ISBN 1930110952 summary Anti-patterns in Enterprise JavaBean development

However, every coin has two sides: the other side of "freedom of choice" is "complexity". Although EJB is an incredibly powerful tool in the hands of experience architects, it is subject to a lot of misuse by novice developers who do not make sound choices. For example, some developers might use a BMP entity bean to map each database table in the system; or access entity beans directly from a distributed layer; or store large amount of data in session objects ... The list goes on. Although those approaches are technically possible, they are hardly the most efficient ways in most cases. Such problems have not only caused many projects to fail but also tarnished EJB's reputation. In fact, the complexity of EJB is often quoted as an argument for other enterprise platforms.

For EJB developers, it is crucial to learn from other people's experiences and follow proven best practices. That helps to reduce the complexity of the platform. Manning's "Bitter EJB" is a very timely book written by well-known experts in the EJB field: Bruce Tate, Mike Clark, Bob Lee and Patrick Linskey. Unlike other "architectural" books, Bitter EJB teaches best practices through common mistakes (anti-patterns). It focuses on "what not to do" but still encourages developers to come up with liberal (everything not forbidden is OK) and innovative solutions. After all, EJB is about flexibility and freedom of choices.

Part I of the book is an overview of anti-patterns in the EJB specification. The EJB specification itself has several major design problems when it first came out in March 1998. EJB v1.1 and v2.0 have gone great length to fix the anti-patterns in the specification. But early adopters may have already developed some anti-patterns in their applications. For new developers, the history also serves as a valuable lesson on what EJB is really for and how different components in the specification fall into their current places. In this part, the authors also provide an excellent recount on what went wrong in the high profile TSS Java PetStore benchmark.

Part II is about session and message-driven beans. Those beans are mainly used in the integration layers. Topics covered in this part include how to deal with large database results, whether to maintain session states, the limitations of XML and much more.

Part III covers EJB persistence. Entity EJBs are probably the most confusing types of components. Many experts have advocated to abolish entity EJBs altogether in favor of other simpler persistence frameworks such as the JDO or even simple JDBC facades. The authors discuss the pros and cons of entity EJBs and covers most leading alternatives. For those who must use entity EJBs, this book also offers useful advices on a range of topics including how to reduce round trips, shorten primary keys and handle expensive database joins etc.

Part IV covers broader topics including performance tuning, testing, building and packaging. One big problem that even EJB developer can recognize the complex deployment descriptors. One chapter of the book is dedicated to reduce code duplication, automate the deployment process and avoid the "integration hell". The last chapter of the book provides an overview of "what's next" in the EJB space.

Overall, it is an excellent book for all EJB developers and other enterprise developers who want to learn from the successes and failures of EJBs."

Peter Wayner's review:

Although there may be as many 36 plots in all of literature, the compartively new world of computer books has really had only one: this new technology is simple, very simple, and it will make your life better and your teeth whiter. Bruce Tate opened up a second plot in his book Bitter Java by exploring just how even the best programming ideas have dark sides. Now he's back with three other authors exploring the world of Bitter EJB.

This book is more fruit from the same tree. Or, to hack the Java MemeStream even more, more beans for the same mill. If you use Enterprise Java Beans (EJB), or think about using them, you should read this book to see what can go wrong. The title shows how naming schemes can be misleading because either the authors aren't really that bitter, or because they're focused entirely on EJBs. This book does not belong in the same camp with the Java==SUV crowd. These authors are really admirers who just want to warn people how to avoid problems with Java and EJB.

Tate and his new co-authors, Mike Clark, Bob Lee, and Patrick Linskey are all consultants who seem to use Java a lot, at least when they're not cheating death. One of the cuter grace notes in the book is a collection of war stories from extreme sports that are mixed in as an allegorical taste of what's to come. Before exploring the problems with a Java concept known as enterprise beans, they tell a kayaking story that ends with the sentence, "Then we hear a loud crunch and look up to see Eric's stern stationary at the top of the drop, revealing the sitaution that every kayaker dreads the most -- the vertical pin."

After stories like this, the book goes on to explore just how the very fancy enterprise beans toolkit can produce an application that moves slower than a stream filled with honey. Each chapter is filled with antipatterns, or lessons about the software learned the hard way. They're sort of like points on the map that say, "There be dragons here."

The book is divided into four parts. The first section, termed "The Basics," explores the simple ways that EJB technology goes bad. The toolkit was heavily hyped as the perfect solution for building business websites that interface seamlessly with large databases. As the business grew, new servers could be added without grief. Alas, as this section points out, there are many reasons why an elephant gun can be the wrong weapon for getting rid of mice in your house.

The next section on "Networks and Messages" describes how good ideas can turn into slow code when people misuse the fancy tools for scaling EJBs. In theory, the EJB toolkit will split up processes simply across multiple machines to handle more customers, but in practice all of the communication can slow things down considerably.
The section on "EJB Persistence" describes how the much-hyped system for seamlessly storing away enterprise beans in databases can weigh down a system. My only beef is that they left out much information on Prevayler, a much-maligned and misunderstood ultra-light toolkit that is like an anti-EJB persistence layer in every possible way. I'm enamored with it, if only because it's such a radical move away from the monolithic APIs like EJBs. While they liken using EJBs to snowboarding in fresh powder with a 100lb pack on your back, Prevayler is sort of like boots-only hiking.


The last section isn't about EJBs per se, but similar toolkits and projects that often get used with EJB. There are antipatterns to avoid with JUnitPref and Ant, too. Some of these suggestions, like some in the rest of the book, aren't terribly new or brillant, but it can't hurt to get another lecture on the importance of testing your code.

The book shines when it's exploring what goes on behind the slick facade of the API. Sure, the EJB toolkit will dutifully load up data from any object on any server in your farm, but you better be careful invoking some of these these methods because the network is slow. The book often points out how invoking that one simple method from the sales literature can start up dozens of sluggish threads. Peeling away the layers helps understand and explain why the system fails.

Many of these lessons aren't limited to Java or EJB. I wouldn't be surprised if the group of authors was busy rewriting the book with examples from .NET. Unfortunately, some programming problems are very hard, and building a toolkit with a simple API won't make them go away. In fact, the simple appearance can cause more trouble when the programmer can't understand what the secret mechanism inside is doing. Almost all of the problems in this book arise from programmers who believe the sales literature when it tells them not to pay attention to what that little bot behind the curtain is doing. If you're working in the world of EJB consulting on big iron, then you've got no choice but to start thinking about what's behind that curtain.

You can purchase the Bitter EJB 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 is the author of 13 books including Java RAMBO Manifesto and Translucent Databases.

Logic Bomb writes "Everyone's favorite way to begin a post on Slashdot is 'IANAL, but...' Having said that a few times myself, when I saw this book I figured it might be nice to get at least a little formal information on what the heck I was writing about. Literary Law Guide for Authors was not quite what I was looking for, but it was extremely informative." Read on for Logic Bomb's review. Literary Law Guide for Authors: Copyright, Trademark, and Contracts in Plain Language author Tonya Marie Evans and Susan Borden Evans pages 190 publisher FYOS Entertainment rating Excellent reviewer Logic Bomb ISBN 0967457963 summary A practical guide to copyright and trademark law

The content of the book really is as the title claims. It is a practical explanation of legal concepts, written by practicing lawyers. It is not a theoretical exploration, it is not a detailed history, and it is most definitely not criticism. The primary audience is writers who want a good understanding of the law before getting involved with the publishing industry or attempting to self-publish. The writing itself is beautifully concise and precise. Given the topic, there are passages that require long lists of examples and distinctions to maintain accuracy. If you have never encountered thorough legal writing before, it can be a bit daunting.

Literary Law Guide begins by explaining copyright in great depth. In this book, that only means 10 pages. But the table of contents for that section alone lists the following:

• Protecting Ideas
• When Copyright Ownership Begins
• Showing the World That You Own Your Work
• What a Copyright Owner Has the Right to Do
• Scope of Copyright Protection
• The Elements of Copyrightable Works
• Copyright Registration
• How to Investigate the Copyright Status of a Work
• Where to Search for Information about Registered Copyrights
• Transfer of Copyright
• Reclaiming Your Copyright After Transfer

Further sections consider fair use, work for hire, copyright infringement (an important topic for Slashdot), and the complications of registering copyright for online works. The latter section even lists the rules for what portions of source code must be submitted to register copyright on software.

That's only the first half of the book's text. Trademark gets the next 30 pages. Once again the authors provide thorough explanations of concepts and actual legal procedures. The final section is on contracts. Given the book's nature, it's really about publishing contracts for writers, but the information is still useful.

The book includes a CD with a handful of Copyright and Trademark Office forms in PDF and Word files of sample publishing contracts. These materials are also printed over 90 pages in the book itself. With the exception of the contracts, this is fairly superfluous. The forms are all readily available online.

Overall, Literary Law Guide has value for several segments of the Slashdot readership. Programmers, especially those working independently, can gain invaluable information on the available means for protecting or profiting from their work. Those interested in Free content (not just software) can better understand issues surrounding licensing and the public domain. Everyone who reads the book will have a better understanding of the issues we spend so much time discussing.

Perhaps because it is targeted towards the world of traditional writing, Literary Law Guide may leave a Slashdot reader unsatisfied at the coverage of digital-age issues. However, I think the fault for that really lies with a legal structure that is, as we all know, far behind the times. A book on the law can only cover what law there is. As the authors put it, in what may be the greatest understatement on this issue I've seen:

In light of this twenty-first century reality, some scholars believe that the law lags far behind in closing the gap between yesterday's statutes and tomorrow's technology.

The final recommendation: if you want to know more about copyright and trademark than you'll easily discover using Google, this book is for you.

You can purchase Literary Law Guide for Authors: Copyright, Trademark, and Contracts in Plain Language from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Mark Burroughs writes "Leave it to a SubGenius preacher to take normally mundane subjects, like software maintenance, and expose the unholy conspiracy behind them. I think the following quote from the introduction sums up the tone of the book nicely: 'Rather than shield your eyes from the sordid realities of the software industry, I am going to dust off my old 8mm films and let you take a good look at the uncensored truth for yourself. You may want to keep a paper bag handy in case you get sick.'" You know you want to read on for the rest of Burrough's review. Software Exorcism author Right Reverend Bill Blunden pages 351 publisher Apress rating two thumbs up reviewer Mark Burroughs ISBN 1590592344 summary Tactics for Maintaining Legacy Code

Reverend Blunden's sermons focus on things that the college professors, in their tweedy jackets, will never talk about. As such, this book should be required reading by computer science majors, who often have a number of misconceptions concerning the industry that they are about to enter.

I doubt very highly that your instructors will tell you how to handle all the nasty little things that can occur when humans work in groups: backstabbing, stonewalling, sabotage, etc. The sad truth is that the people who do actually learn about these tactics (under the guise of "organizational behavior") are MBAs, the people who end up being managers. Folks, the deck has been stacked: The MBAs have been given whips, and the CS majors have all been given saddles. It's called animal husbandry; ... now go look up the word "cull."

Glancing at the back cover of the book, Reverend Blunden looks like the type of subversive individual that the ATF would like to have a chat with. As such, he is not one to let the reader leave without a few useful weapons (some of which may be questionable from a legal standpoint ... but hey, business is war). For example, the book tells you construct a paper trail so that even the shiftiest weasel cannot switch sides if it's suddenly convenient. Reverend Blunden even goes so far to refer the reader to a vault purveyor in New York so that evidence can be stored securely at home (hint: it's sure as hell not safe at the office). Don't kid yourself; a solid paper trail can save you during a witch-hunt.

The book also looks at how to deal with legacy code in situations where internal competition has encouraged people to hoard information, or to escape responsibility via promotion (i.e. VPs have been known to develop amnesia about the code they worked on). It explains the forces that cause these shenanigans to occur and then describes how to flush the guilty party out into the open, where their slimy tactics won't work. As before, generating a trail of evidence and possessing a degree of intellectual humility go a long way.

Then there is privacy, an issue that employers will definitely try to skirt. Management types tend to be keen on metrics to measure productivity. In addition, software engineers typically have access to code, or algorithms, that may be considered proprietary secrets. This has led many companies to monitor their engineers in some way or another (i.e. key loggers, remote desktops, sniffers, TEMPEST, etc.). Reverend Blunden provides a couple of easy, but extremely effective, counter tactics that the reader can use to foil this kind of Big Brother antics.

At the end of the day, Reverend Blunden tells it like it is. He hasn't been bought off and he doesn't have an agenda. His only goal is to warn new hires about the various landmines that exist, buried under the polite exterior of the corporate landscape. You may not like what he has to say, but no one ever said that software engineering was a pretty job. If they did, they were telling you a lie. Praise Bob.

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

TechGuy949 writes ".NET Remoting is a technology that is often overlooked due to Microsoft's intense focus on promoting XML Web Services technology. In actual fact, .NET remoting is often a more appropriate solution than Web Services, and it certainly performs better and scales better when used properly. Ingo Rammer has written a technically sound, very informative book on .NET remoting technology, which is a good thing, given that there are still far too few titles available on this important technology." Read on for the rest of TechGuy949's review of Advanced .NET Remoting. Update: 10/23 17:28 GMT by T : Please note: the reviewer writes for Apress (publisher of this book); book reviewers are encouraged to read the book review guidelines linked below, and to disclose any such relationship. I regret not knowing this before the review ran. Advanced .NET Remoting author Ingo Rammer pages 404 publisher APress rating 8 reviewer TechGuy949 ISBN 1590590252 summary A two-part overview of .NET Remoting, from intro to advanced material.

My Overview and Summary Advanced .NET Remoting breaks out into a two-part book. The first four chapters are at the introductory level, while later chapters are considerably more advanced. The book begins with an informative conceptual discussion on what .NET remoting technology is, but then quickly moves on to more specifics, entirely focused on generous code examples (which actually work, barring one or two stray lines here and there, which I found easy to correct).

I picked up this title needing to get a solid introduction to .NET remoting, and the first part of this book does not disappoint. If you stop reading after the first four chapters (after spending time working on each and every code example). you will feel like you have a solid grasp of the basics of .NET remoting. However, you need to delve into the second part of the book to realize that .NET remoting is a deep and complex topic that is going to require considerable effort on your part to understand.

The second part of the book is not for the faint-hearted. The complexity level ratchets up several notches, and holds nothing back. It delves into advanced topics such as .NET remoting internals, including message sinks, channel sinks, formatters, and transport protocols, and shows you how to customize each part. Ingo's goal is for you to really understand how the .NET Framework implements remoting. The discussion here often borders on the theoretical, but it always stays grounded in relevant code examples.

Intermediate to advanced developers will greatly appreciate this book if they are looking for an in-depth, no holds barred discussion of .NET remoting.

What's in the Book Chapters 1-4 are an introduction to .NET remoting and configuration. Ingo starts with a conceptual discussion to help you understand how .NET remoting fits into the larger picture. He then presents a remoting example that provides an excellent introduction to the core aspects of remoting, including different types of remoting objects; marshalling objects by reference; serializing objects; and using interfaces to share type information. Chapter 4, on configuration, shows you how to use configuration files to simplify your remoting code, and to make it easier to port across different deployment environments.

Chapter 5 is about securing .NET remoting. This chapter was disappointingly short and did not provide enough depth. Also, some security implementation features have changed in v1.1 of the framework, so this section is not the most relevant one in the book. To his credit, Ingo has published a 1.1 update on his website that specifically addresses relevant changes to security implementation in the .NET framework.

Chapter 6 is where things start to get advanced. This chapter discusses object lifetime issues, and shows you how to control the lifetime of remotable objects, through "leasing" and "sponsorship." It also shows you how to implement asynchronous remoting calls using delegates and events. Chapter 6 is a must-read.

Chapter 7-10 is where things get really advanced. These chapters shows you how the .NET framework implements remoting, and it studies the 5 elements of remoting in great depth (Proxies, Messages, Message Sinks, Formatters and Transport Channels). This chapter is packed, and is a must-read for understanding advanced .NET remoting issues, especially when you need to heavily customize the implementation. Intermediate developers will have a harder time with these chapters, and may not find all of the material relevant to a basic .NET remoting implementation.

Chapter 11 closes out the book with an interesting look at how to implement .NET remoting techniques in a client application in order to manage the objects more effectively. Again, intermediate developers will have difficulty with this chapter, which is the most theoretical in the book. Advanced developers will appreciate it however, especially with Ingo's lead-in warning that 100% of the material in the chapter is undocumented by Microsoft!

Table of Contents

1. Introduction to Remoting
2. .NET Remoting Basics
3. Remoting in Action
4. Configuration and Deployment
5. Securing .NET Remoting
6. In-Depth .NET Remoting
7. Inside the Framework
8. Creation of Sinks
9. Extending .NET Remoting
10. Developing a Transport Channel
11. Context Matters

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

hanksdc writes "With the proliferation of wireless networking over the past year, it has become easier and easier for even the most budget-minded geeks to afford wireless gear for their homes, offices, and neighborhoods. Rob Flickenger's latest, Wireless Hacks expands upon his previous book on the topic, Building Wireless Community Networks , and takes its reader by the hand on a fast-paced run through a large assortment of hacks related to wireless networking." Read on for the rest of hanksdc's review. Wireless Hacks author Rob Flickenger pages 286 publisher O'Reilly rating 8 reviewer hanksdc ISBN 0596005598 summary Tips and Tricks for getting the most out of your wireless network

From the back cover we find that the book is targeted towards the intermediate to advanced wireless user, and I found that definitely to be the case. Some of the hacks use a lot of technical jargon, and assume a fair amount of background knowledge from the reader. You should probably already know how to get a wireless link up and running to really benefit from the book. But don't let that be a deterrent if you're a newbie. It's still a fun read, and provides a lot of ideas for the inquisitive and creative mind.

The book is very readable, (all the Hacks series books I have read would, like their venerable ancestor, UNIX Power Tools , make for great bathroom books). Each hack is self-contained, and can be read in just a few minutes. You can read the book straight through, or browse around, find what interests you and go from there. Most hacks have references to other hacks in the book, so reading it can be like browsing a web page sometimes. Many hacks also have references to further sources of information on the topic covered.

There are hacks here for UNIX/Linux platforms mainly, but all you Ti/Al-Powerbook zealots will find plenty to lick your lips over as well, with several of the hacks devoted to wireless networking with OS X. There are even some for the Windows users as well. Many of the hacks (since they deal with hardware) could be utilized on any platform. Well, ok, you might have a bit of a hurdle to get your Pirouette cantenna hooked up to your vintage Apple ][c, but this book makes a good breeding-ground of ideas for those so inclined.

The book is divided into several chapters, each devoted to a particular topic. Each chapter contains a number of hacks related to that topic:

• Chapter 1, "The Standards," covers the alphabet soup of current wireless protocols, with a brief introduction to each.
• Chapter 2, "Bluetooth and Mobile Data," covers Bluetooth technology (need to use your Bluetooth-enabled cell phone to act as a modem for your laptop in a pinch? If only those phones weren't so pricey...*sigh*)
• Chapter 3, "Network Monitoring," is all about finding out what's going on on the local network, including various ways to sniff traffic, broadcast network services, perform network discovery, and analyze traffic.
• Chapter 4, "Hardware Hacks," gets down to the metal, discussing topics ranging from boosting signal strength to building your own access point from micro form-factor hardware to cabling and antenna guides.
• Chapter 5, "Do-it-Yourself Antennas," describes various ways to build your own antennas all the way from Pringles cans to milled aluminum wave guides (Don't forget to use ventilation when soldering ;-).
• Chapter 6, "Long distance Links," offers tips on setting up, well, long distance wireless links.
• Chapter 7, "Wireless Security," dispels the vendor-propagated myths of WEP 'security,' and gives practical advice on how you can avoid the guy next door from sniffing your private traffic (not that you'd have anything to hide, of course...).

The book's website has a full table of contents, listing each hack, if you're interested.

Throughout the book there is a lot of information repeated from Building Wireless Community Networks, as well as a few hacks copied over from Linux Server Hacks [Slashdot review here], but all together it makes a very useful collection, and a nice addition to O'Reilly's Hacks series.

So what's my take on it? If you're doing just about anything with an 802.11x network, you'll likely find something fun or useful here. If you're brand new to wireless networking, you may want to come up to speed with something a bit more tutorial-oriented. Perhaps one drawback to the book is its recipe-style format. There's not a lot of background information offered with each hack, but rather a lot "do this, then this, and you get this." If you're not used to hacking and experimenting with things, you might find yourself a bit lost. It certainly isn't a college textbook, which can be both good and bad, depending on what you're looking for.

Overall, if you're the forward-thinking, range-extending, hardware-tinkering, soldering-iron wielding, average slashdot reader, you'll probably find it a fun read with lots of good ideas to offer.

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

rjnagle writes "Eric S. Raymond (or ESR) is widely known for the groundbreaking series of essays in his book, The Cathedral and the Bazaar. In TCatB, he makes a credible case for why open source sofware works so well, and why community-supported software won't put developers out of a job. (I once attended a delightful talk he gave where, among other things, he gave sartorial advice to open source developers, urging them to avoid formal suits at presentations to CEO's as a way to give off the auras of foreign dignitaries unused to local customs). The arguments presented in Cathedral and the Bazaar were persuasive and original and now regarded as obvious. In his new book, Art of Unix Programming (available for free on the web), ESR stakes an even bolder claim: that initial design decisions make Unix uniquely well-suited to take advantage of open source's power. This book is an attempt to explain why Unix is so...well, Unixy." Read on for the rest of Nagle's review of The Art of Unix Programming. The Art of Unix Programming author Eric S. Raymond pages 560 publisher Addison Wesley rating great and free on the web! reviewer Robert Nagle ISBN 0131429019 summary Instructive for the Student; Profound for the Professional

On the surface, this book is a gentle introduction to programming; but in reality it is an attempt to explain the Unix aesthetic; at times I felt as if I were reading less a technical guide than an art history book, a chatty account of Gothic Architecture as told by someone who helped build a few churches himself. ESR articulates a set of design principles for Unix, which because of succintness deserve reprinting here.

1. Rule of Modularity: Write Simple Parts connected by clean interfaces.
2. Rule of Clarity: Clarity is better than cleverness.
3. Rule of Separation: Separate policy from mechanism; separate interfaces from engines.
4. Rule of Simplicity: Design for simplicity; add complexity only where you must
5. Rule of Parsimony: Write a big program only when it is clear by demonstration that nothing else will do.
6. Rule of Transparency: Design for visibility to make inspection and debugging easier.
7. Rule Of Robustness: Robustness is the child of transparency and simplicity.
8. Rule of Representation: Fold Knowledge into data, so program logic can be stupid and robust.
9. Rule of Least Surprise: In interface design, always do the least surprising thing.
10. Rule of Silence: When a program has nothing surprising to say, it should say nothing.
11. Rule of Repair: Repair what you can--but when you must fail, fail noisily and as soon as possible.
12. Rule of Economy: Programmer time is expensive; conserve it in preference to machine time.
13. Rule of Generation: Avoid hand-hacking; write programs to write programs when you can.
14. Rule of Optimization: Prototype before polishing. Get it working before you optimize it.
15. Rule of Diversity: Distrust all claims for one true way.
16. Rule of Extensibility: Design for the future, because it will be here sooner than you think.

ESR shows how to follow these general principles while writing Unix programs. The central metaphors of Unix (that everything is a file, and data-streams that can be piped and redirected) are intuitive, and maximize transparency and separation. About pipes, he writes:

A subtle but important property of pipes and the other classic Unix IPC (Interprocess Communication) is that they require communication between programs to be held down to a level of simplicity that encourages separation of function. Conversely, the result of having no equivalent of the pipe is that programs can only be designed to cooperate by building in full knowledge of each others' internals (p 81, Chapter 3)

Interestingly, the real opposing aesthetic to the Unix aesthetic is not Microsoft (which really is a hybrid), but Macintosh:

The Macintosh's unifying idea is so strong that most of the other design choices we discussed above are either forced by it or invisible. All programs have GUIs. There is no CLI at all. Scripting facilities are present but much less commonly used than under Unix; many Mac programmers never learn them. Mac OS's captive-interface GUI metaphor (organized around a single main event loop) leads to a weak scheduler without presumption... Mac OS applications are not, however, invariably monster monoliths. The system's GUI support code, which is partly implemented in a ROM shipped with the hardware, and partly implemented in shared libraries, communicates with Mac OS programs through an event interface that has been quite stable since its beginnings. Thus, the design of the operating system encourages a relatively clean separation between application engine and GUI interfaces.

ESR's criticism right here (and throughout the book) is not necessarily condemnation. In fact, ESR recognizes that Macintosh as a competing aesthetic has a lot to offer that Unix does not. For example, Mac file attributes (in which a file has both data and resource "forks") provide mechanism for richer GUI support. Thus, we have (ESR says) developers "who work from the interface inward, rather than the engineer outward." In contrast, the Unix byte-stream metaphor may make it hard to conceptualize the meaning of operations such as Create, Open, Read, Write and Delete.

With Unix, the Rule of Least Surprise suggests that the developer delegate interface functions to a GUI or to another program. Instead of creating a built-in editor inside an application, the developer should allow the user to choose which editor to use. Instead of making a robust and easy-to-use interface, the Unix developer should produce a command line utility first, and then let someone else create a separate and independent GUI layer. (Rule of Separation). Xcdroast is a perfect example of a GUI layer for the command line program, cdrecord.

The Command Line Interface (CLI) may scare off new users, but it offers endless scripting and batching capabilities for programs (and smooth IPC). Also, it offers expressiveness to developers. "The Unix programmer," ESR writes, "is likely to see defaulting away from expressiveness as a sort of cop-out or even betrayal of future users, who will know their own requirements better than the present implementer. Ironically, though the Unix attitude is often construed as a sort of programmer arrogance, it is actually a form of humility -- one often acquired along with years of battle scars" (p.304, "Interfaces,")

ESR distinguishes between interface complexity and implementation complexity. Unix projects often involve tradeoffs on these two. The Unix developer prefers a lean and simple implementation at the expense of a usable interface; ESR writes:

Programs that mediate between the user and the rest of the universe notoriously attract features. This includes not just editors but Web browsers, mail and newsgroup readers, and other communication programs. All tend to evolve in accordance with the Law of Software Envelopment, aka Zawinski's Law. 'Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones that can'".

The book devotes considerable space to showcasing Unix best practices (which in most cases, means readable config files, limiting the program's scope, providing access to sufficient debug information and making it easy to hack). He offers sensible advice about when to use minilanguages ("don't extend your way to it, one patch and crufty feature at a time"), why to limit the number of available command-line switches (each one increases debug time), why optimization has few payoffs ("Moore's law implies a 26% performance gain just by buying new hardware every six months") and why bottoms-up programming can work better than top down design(because "it gives you time and room to refine a vague specification" when "...you are programming in an exploratory way, trying to get a grasp on hardware or software or real-world phenomena you don't completely understand.").

One of the most instructive chapters was about J. Random Newbie, a fictional programmer fresh out of college who understands basic programming concepts and the value of reuse. ESR presents a scenario of how Newbie nonetheless ends up rewriting rather than reusing, relying more on his own code than that of others. When he changes jobs, "he is likely to discover that he can't take his toolkit with him" and may even find it to be useless at a new job with different proprietary tools, languages and libraries. Thus, ESR writes:

Programmers have reuse (and other good practices that go with it, like modularity and transparency) systematically conditioned out of them by a combination of technical problems, intellectual-property barriers, politics and personal ego needs. Multiply J. Random Newbie by a hundred thousand, age him by decades, and have him grow more cynical and more used to the system year by year. There you have the state of much of the software industry, a recipe for enormous waste of time and capital and human skill -- even before you factor in vendors' market-control tactics, incompetent management, impossible deadlines, and all the other pressures that make doing good work difficult. (p.420, "Reuse")

This book is a good introduction for this newbie programmer (as well as a warning about what to expect). It offers practical advice about which license and language to use, how to set up documentation, how to decipher the standards process, how to check things into CVS and how to submit a patch to an open source project.

The chapter on Unix's history puts the current SCO/IBM controversy into perspective. Unix has always been dogged by exertions of commercial control, and ESR accurately conveys how the software world is constantly swinging back and forth from periods of intensely-creative free-spirited openness to periods of commercial control.

I was struck by several of ESR's observations: that Linus Torvald's "refusal to be a zealot" was a contributing reason why Linux was able to succeed; that both the patch utility and email probably did more to advance the Open Source movement than mere "consciousness raising."

In summary, this book is a great help for the student programmer. It synthesizes a lot of ideas and insights from other programming gurus, and is full of insights, aphorisms and fun digressions (no surprise to readers of ESR's other works). The experienced programmer, on the other hand, might find the book more profound than practical. Invoking the Zen metaphor (and even including Unix koans at the book's end), ESR shows us how the abstract nature of programming provides insight into problem-solving, design and yes, even a kind of enlightenment. The book, available for free on the Net, is probably better to read on vacation or an airplane or as a welcome break when stumped by a programming problem. More practical books on Unix programming exist (I happen to recommend Mark Sobell's), but ESR's book will stay with you long after you have finished reading, providing countless hours for reflection and appreciation of Unix's Unix-nature.

Robert Nagle (aka Idiotprogrammer), believes that plone is the best thing since garage door openers, and is a strong supporter of music sharing. You can purchase The Art of Unix Programming from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

rjnagle writes "Eric S. Raymond (or ESR) is widely known for the groundbreaking series of essays in his book, The Cathedral and the Bazaar. In TCatB, he makes a credible case for why open source sofware works so well, and why community-supported software won't put developers out of a job. (I once attended a delightful talk he gave where, among other things, he gave sartorial advice to open source developers, urging them to avoid formal suits at presentations to CEO's as a way to give off the auras of foreign dignitaries unused to local customs). The arguments presented in Cathedral and the Bazaar were persuasive and original and now regarded as obvious. In his new book, Art of Unix Programming (available for free on the web), ESR stakes an even bolder claim: that initial design decisions make Unix uniquely well-suited to take advantage of open source's power. This book is an attempt to explain why Unix is so...well, Unixy." Read on for the rest of Nagle's review of The Art of Unix Programming. The Art of Unix Programming author Eric S. Raymond pages 560 publisher Addison Wesley rating great and free on the web! reviewer Robert Nagle ISBN 0131429019 summary Instructive for the Student; Profound for the Professional

On the surface, this book is a gentle introduction to programming; but in reality it is an attempt to explain the Unix aesthetic; at times I felt as if I were reading less a technical guide than an art history book, a chatty account of Gothic Architecture as told by someone who helped build a few churches himself. ESR articulates a set of design principles for Unix, which because of succintness deserve reprinting here.

1. Rule of Modularity: Write Simple Parts connected by clean interfaces.
2. Rule of Clarity: Clarity is better than cleverness.
3. Rule of Separation: Separate policy from mechanism; separate interfaces from engines.
4. Rule of Simplicity: Design for simplicity; add complexity only where you must
5. Rule of Parsimony: Write a big program only when it is clear by demonstration that nothing else will do.
6. Rule of Transparency: Design for visibility to make inspection and debugging easier.
7. Rule Of Robustness: Robustness is the child of transparency and simplicity.
8. Rule of Representation: Fold Knowledge into data, so program logic can be stupid and robust.
9. Rule of Least Surprise: In interface design, always do the least surprising thing.
10. Rule of Silence: When a program has nothing surprising to say, it should say nothing.
11. Rule of Repair: Repair what you can--but when you must fail, fail noisily and as soon as possible.
12. Rule of Economy: Programmer time is expensive; conserve it in preference to machine time.
13. Rule of Generation: Avoid hand-hacking; write programs to write programs when you can.
14. Rule of Optimization: Prototype before polishing. Get it working before you optimize it.
15. Rule of Diversity: Distrust all claims for one true way.
16. Rule of Extensibility: Design for the future, because it will be here sooner than you think.

ESR shows how to follow these general principles while writing Unix programs. The central metaphors of Unix (that everything is a file, and data-streams that can be piped and redirected) are intuitive, and maximize transparency and separation. About pipes, he writes:

A subtle but important property of pipes and the other classic Unix IPC (Interprocess Communication) is that they require communication between programs to be held down to a level of simplicity that encourages separation of function. Conversely, the result of having no equivalent of the pipe is that programs can only be designed to cooperate by building in full knowledge of each others' internals (p 81, Chapter 3)

Interestingly, the real opposing aesthetic to the Unix aesthetic is not Microsoft (which really is a hybrid), but Macintosh:

The Macintosh's unifying idea is so strong that most of the other design choices we discussed above are either forced by it or invisible. All programs have GUIs. There is no CLI at all. Scripting facilities are present but much less commonly used than under Unix; many Mac programmers never learn them. Mac OS's captive-interface GUI metaphor (organized around a single main event loop) leads to a weak scheduler without presumption... Mac OS applications are not, however, invariably monster monoliths. The system's GUI support code, which is partly implemented in a ROM shipped with the hardware, and partly implemented in shared libraries, communicates with Mac OS programs through an event interface that has been quite stable since its beginnings. Thus, the design of the operating system encourages a relatively clean separation between application engine and GUI interfaces.

ESR's criticism right here (and throughout the book) is not necessarily condemnation. In fact, ESR recognizes that Macintosh as a competing aesthetic has a lot to offer that Unix does not. For example, Mac file attributes (in which a file has both data and resource "forks") provide mechanism for richer GUI support. Thus, we have (ESR says) developers "who work from the interface inward, rather than the engineer outward." In contrast, the Unix byte-stream metaphor may make it hard to conceptualize the meaning of operations such as Create, Open, Read, Write and Delete.

With Unix, the Rule of Least Surprise suggests that the developer delegate interface functions to a GUI or to another program. Instead of creating a built-in editor inside an application, the developer should allow the user to choose which editor to use. Instead of making a robust and easy-to-use interface, the Unix developer should produce a command line utility first, and then let someone else create a separate and independent GUI layer. (Rule of Separation). Xcdroast is a perfect example of a GUI layer for the command line program, cdrecord.

The Command Line Interface (CLI) may scare off new users, but it offers endless scripting and batching capabilities for programs (and smooth IPC). Also, it offers expressiveness to developers. "The Unix programmer," ESR writes, "is likely to see defaulting away from expressiveness as a sort of cop-out or even betrayal of future users, who will know their own requirements better than the present implementer. Ironically, though the Unix attitude is often construed as a sort of programmer arrogance, it is actually a form of humility -- one often acquired along with years of battle scars" (p.304, "Interfaces,")

ESR distinguishes between interface complexity and implementation complexity. Unix projects often involve tradeoffs on these two. The Unix developer prefers a lean and simple implementation at the expense of a usable interface; ESR writes:

Programs that mediate between the user and the rest of the universe notoriously attract features. This includes not just editors but Web browsers, mail and newsgroup readers, and other communication programs. All tend to evolve in accordance with the Law of Software Envelopment, aka Zawinski's Law. 'Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones that can'".

The book devotes considerable space to showcasing Unix best practices (which in most cases, means readable config files, limiting the program's scope, providing access to sufficient debug information and making it easy to hack). He offers sensible advice about when to use minilanguages ("don't extend your way to it, one patch and crufty feature at a time"), why to limit the number of available command-line switches (each one increases debug time), why optimization has few payoffs ("Moore's law implies a 26% performance gain just by buying new hardware every six months") and why bottoms-up programming can work better than top down design(because "it gives you time and room to refine a vague specification" when "...you are programming in an exploratory way, trying to get a grasp on hardware or software or real-world phenomena you don't completely understand.").

One of the most instructive chapters was about J. Random Newbie, a fictional programmer fresh out of college who understands basic programming concepts and the value of reuse. ESR presents a scenario of how Newbie nonetheless ends up rewriting rather than reusing, relying more on his own code than that of others. When he changes jobs, "he is likely to discover that he can't take his toolkit with him" and may even find it to be useless at a new job with different proprietary tools, languages and libraries. Thus, ESR writes:

Programmers have reuse (and other good practices that go with it, like modularity and transparency) systematically conditioned out of them by a combination of technical problems, intellectual-property barriers, politics and personal ego needs. Multiply J. Random Newbie by a hundred thousand, age him by decades, and have him grow more cynical and more used to the system year by year. There you have the state of much of the software industry, a recipe for enormous waste of time and capital and human skill -- even before you factor in vendors' market-control tactics, incompetent management, impossible deadlines, and all the other pressures that make doing good work difficult. (p.420, "Reuse")

This book is a good introduction for this newbie programmer (as well as a warning about what to expect). It offers practical advice about which license and language to use, how to set up documentation, how to decipher the standards process, how to check things into CVS and how to submit a patch to an open source project.

The chapter on Unix's history puts the current SCO/IBM controversy into perspective. Unix has always been dogged by exertions of commercial control, and ESR accurately conveys how the software world is constantly swinging back and forth from periods of intensely-creative free-spirited openness to periods of commercial control.

I was struck by several of ESR's observations: that Linus Torvald's "refusal to be a zealot" was a contributing reason why Linux was able to succeed; that both the patch utility and email probably did more to advance the Open Source movement than mere "consciousness raising."

In summary, this book is a great help for the student programmer. It synthesizes a lot of ideas and insights from other programming gurus, and is full of insights, aphorisms and fun digressions (no surprise to readers of ESR's other works). The experienced programmer, on the other hand, might find the book more profound than practical. Invoking the Zen metaphor (and even including Unix koans at the book's end), ESR shows us how the abstract nature of programming provides insight into problem-solving, design and yes, even a kind of enlightenment. The book, available for free on the Net, is probably better to read on vacation or an airplane or as a welcome break when stumped by a programming problem. More practical books on Unix programming exist (I happen to recommend Mark Sobell's), but ESR's book will stay with you long after you have finished reading, providing countless hours for reflection and appreciation of Unix's Unix-nature.

Robert Nagle (aka Idiotprogrammer), believes that plone is the best thing since garage door openers, and is a strong supporter of music sharing. You can purchase The Art of Unix Programming 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: "One of the greatest mysteries of today is whether a pirate is good or bad. On one hand, Disney campaigns against digital piracy while making a movie ( "Pirates of the Caribbean") pushing a theme park ride that celebrates life under the Jolly Roger. On one hand, we celebrate Talk Like a Pirate Day, while on the other hand this fine, upstanding investment company was fined $19.7m for copyright infringement and no one used the word 'Pirate.' This is the world that greets the paperback edition of Pirate Hunter, Richard Zacks's excellent history of the late so-called pirate, Captain William Kidd." Read on for the rest of Peter's review. Pirate Hunter author Richard Zacks pages 426 publisher Hyperion rating 8 reviewer Peter Wayner ISBN 0786884517 summary The life and times of an real pirate.

While Kidd's name may be synonymous with piracy in our culture's muddled collective memory, the book establishes that the sailor was nothing of the sort. If anything, he was framed by powerful forces trying to maintain a struggling business model. Why does that sound familiar?

This book is a wonderful example of what a talented writer and a relentless researcher can do with records that date from the 17th century. Kidd was born in Scotland in 1654, lived to see the 18th century, and recorded some of his daily life in log books that were sometimes sketchy and sometimes voluminous. By synthesizing the information from Kidd's papers, various British archives, ships logs, correspondence and other ephemera, Zacks was able to build a detailed narrative around Kidd's last major voyage. Did you know that in 1699, the going price for fine silks and other exotic fabrics was about 3 yards per piece of eight? Or perhaps that Cotton Mather preached to Kidd on January 21, 1700 on Jeremiah 17:11? I shudder to think what someone will be able to do with the Wayback machine.

By 1696 when the book begins, Kidd was one of the wealthiest landowners in the United States living in a river front mansion near Wall Street. His block and tackle helped build Trinity Church where his family sat in the fourth row each Sunday. Kidd married well and his wife gave him a child. Kidd was, according to his marriage certificate, a gentleman. Still, as Richard Grasso found out, this wasn't enough to stop the political winds from turning an seemingly honest dollar into ill-gotten plunder.

The pirate world, on the other hand, was a different place from the tip of Manhattan. The men on a true pirate ship sailed hard, tortured the weak ships they could find, and then spent their earnings on rum and women in sketchy ports of call that asked no questions. It was, according to the dreaded pirate Bartholomew Roberts , "A merry life and a short one."

Still, despite the disrespect for the rules of property, the pirate life offered many other socially advanced customs that outdistanced the civilized world where the Kings and Queens proclaimed they ruled by divine right. Zacks points out that pirate ships were run as strict democracies and the captains could be deposed at any time by a recall election known as a parlay. "All food and liquor was to be shared equally, a mind-boggling concept for sailors long used to watching officers dine and guzzle for hours on end," he notes.

So why did Kidd leave his comfortable New York home and head to sea again? Zacks establishes that Kidd was given a commission by four lords in the British admirality. Kidd received a new ship, a crew, and the instructions to capture any of the pirates who were plaguing the British East India companies. Kidd was to be a pirate hunter, a fighter for good, not evil, who would conveniently split his takings with his four backers. Some details of the commission were kept secret because the backers were going to keep the treasure and avoid giving the goods back to the rightful owners who lost the treasure to the pirates in the first place. This was a cousin to the doctrine proclaiming that two wrongs make a right.

The book sails through Kidd's voyage in exquisite detail. It's a pirate story that sometimes wilder and sometimes slower than any fiction writer could offer. Somewhere along the trip, the rumors begin to circulate that Kidd had turned pirate. Zacks suggests the whispers began as an act of treachery by one of his old partners who did dabble in piracy. The partners could cover their own tracks by blaming Kidd. The rumors fed into the Royal Navy's faulty intelligence network which dutifully hyped the size of the pirate world in order to serve its own ends.

Along the way, it becomes clear that piracy was as much a different political system as a violent crime against property. When the laws and strictures of society grow too binding, men might slip them off and sail into the sunset. Piracy was a decision to forgo the social contract that most had never signed in the first place, in most cases because the social contract offered by the official government was not particular gracious. Zacks compares life on a pirate ship to life under the British flag when the opportunity presents itself.

Who received a greater share of the wealth? Which class structure was more rigid? Who was responsible for more privation and inhumanity? It's impossible to do the calculus, but Zacks makes it clear that the pirates understood something of what Bob Dylan's theorem that you must be honest to live outside the law. At one bitterly ironic point, the black so-called pirates on Kidd's ship are treated with much more respect than the white ones, but only because the captors know that the black ones will fetch a nice price at the slave market in London.

In Kidd's case, the question of his piracy oscillates in a mechanism of a war between political factions. Zacks suggests that the English East India company, which was sort of the Microsoft of the day when sea trade was high tech, fanned the rumors of Kidd's departure from fair society to ingratiate itself before the Grand Moghul in India. Kidd's commission to take so-called pirate ships put him at odds with the work of the trading company which launched merchant ships skirting their own set of rules.

So the book evolves on two levels. The men fight with guns and ships that are all just extensions of lawyers and corporations. Kidd's struggle to gain a fortune, repay his backers, and return to his wife in New York gets caught in the middle of the greater evolution of English law, American rebellion, French imperialism, and old fashioned greed, . Was he a pirate or gentleman? Does he plunder enough pirates to repay his backers? Does he survive to clear his name? It would be a shame to ruin this fine story by revealing the ending of the book. Of course, the deeper questions of the true nature of piracy and its hold on our imagination, continue to resonate today.

Peter Wayner is the author of Policing Online Games , a book about pirate hunting of a sort, and Java RAMBO Manifesto , an exploration of how to live without a database. You can purchase Pirate Hunter from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Cory R writes "Although many of us may hate to admit it, aesthetics matter even to hard-headed techies. Our software is skinnable, our email is filled with HTML, and our cases glow with colorful lights. Graphic design is pervasive and expected. Programming style is debated endlessly and many of us lust after Apple hardware which can command a premium price in part because of its styling. The age of aesthetics is here and in The Substance of Style: How the Rise of Aesthetic Value Is Remaking Commerce, Culture, and Consciousness, Virginia Postrel explains where it came from and what it means." Read on for the rest of Cory's review. The Substance of Style: How the Rise of Aesthetic Value Is Remaking Commerce, Culture, and Consciousness author Virginia Postrel pages 237 publisher HarperCollins rating 8.5 reviewer Cory R. ISBN 0060186321 summary Postrel says this is an age of aesthetics. Style is important because it has genuine value. Functionality and style may be equally important. Postrel points out:

"Those old sci-fi movies were wrong. the 21st century doesn't look at all the way they said it would. We citizens of the future aren't wearing conformist jumpsuits, living in utilitarian high-rises, or getting our food in the form of dreary-looking pills. On the contrary, we are demanding and creating a stimulating, diverse, and strikingly well-designed world. We like our vacuum cleaners and mobile phones to sparkle, our backpacks and laptops to express our personalities."

Postrel's writing is easy to read and the text flows effortlessly. Her opening chapter ("The Aesthetic Imperative") describes how manufacturers and other businesses cannot escape style issues. Starbucks is a recurring example: she says "Curmudgeons may grouse about the price of its coffee, but Starbucks isn't just selling beverages. It's delivering a multisensory aesthetic experience, for which customers are willing to pay several times what coffee costs at a purely functional Formica-and-linoleum coffee shop." In a crowded and incredibly competitive marketplace, style is one of the few ways to differentiate yourself.

In chapter two, "The Rise of Look and Feel," Postrel describes the changing role of aesthetics over the past century. She discusses the rise of mass production, 1930's trends of streamlining everything (why should a toaster be aerodynamic?), wartime utilitarianism, and businesses' changing emphasis on style. Much of this, she says, was spurred by the rural-to-urban population shift. As cities grew, niche markets became concentrated enough that businesses could cater to them. Markets fragmented and elements of niche styles were adopted and transformed by the mainstream.

Chapter three ("Surface and Substance") looks at the power of pretty surfaces. The discussion ranges from Hilary Clinton's hair, to the destruction of the World Trade Center towers in 2001. Do surfaces have genuine value? Postrel definitely thinks so.

The fourth chapter ("Meaningful Looks") studies the messages that can be conveyed by aesthetics. "Identity is the meaning of surface," Postrel says. "Before we say anything with words, we declare ourselves through look and feel: Here I am. I'm like this. I'm not like that. I associate with these others. I don't associate with those." Look at punk rockers for a great example: at the same time punks are rebelling against society, they are conforming to tenets and garb of their sub culture.

Chapter five ("The Boundary of Style") explores the impact of aesthetic choices on those around you. Much of the chapter deals with architectural issues and building codes or deed restrictions. I think it is one of the more balanced chapters and, as someone who has just bought his first home in a deed-restricted community, had a lot of material that I found very interesting. By the end of the chapter, I disliked deed restrictions even more.

The final chapter is called "Smart and Pretty." It revolves around the idea that "pretty or smart" is a false dichotomy. Making things beautiful or interesting is as important as making them work. Postrel goes one step further and cites the work of usability guru Donald Norman, who argues that attractive things actually work better. I have a hard time explaining it, but I agree. Hammering out text on my iMac is a different experience than doing the same on my Windows or Linux box. The Apple machine oozes with creativity. Maybe it's contagious?

Postrel's argument for the value of aesthetics is definitely one-sided, but I wouldn't go so far as to call her a cheerleader. Her logic is solid, intertwined, and backed up with thirty-two pages of notes at the end of the book. The flaw in the book lies in the arguments she doesn't make -- specifically, she doesn't spend much time on dealing with misleading surfaces (facades). For a few pages she talks about people who dress not for who they are, but for who they aspire to be. I would have liked to see more about those who display whatever it is they think you want to see. Politicians do this for a living.

Unless you belong to the adornment-is-for-fools camp, you will enjoy this book. Its subject is one that I have never devoted much thought to, but after reading The Substance of Style, I can't help but be more critical of the surfaces around me and I can better appreciate the ones that are well designed.

You can purchase The Substance of Style: How the Rise of Aesthetic Value Is Remaking Commerce, Culture, and Consciousness from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

doom writes "For those of you who haven't been paying attention, when the The Perl Cookbook by Tom Christiansen & Nathan Torkington came out in 1999 it immediately became one of the primary references in the perl world. It's one of the first places you should check before making a move with perl, right up there with search.cpan.org, itself. Now we've got the second edition. What's the diff? The diff is 58 new recipes and program examples (list provided below), plus two new chapters on mod_perl and XML (which provide an additional 27)." Read on for doom's complete review. The Perl Cookbook, 2nd Edition author Tom Christiansen & Nathan Torkington pages 927 publisher O' Reilly rating 9 reviewer doom ISBN 0596003137 summary How to do common tasks in perl

The new recipes cover a number of subjects. One of the prominent themes is how to use perl's new unicode support, as well as the new I/O layers feature. The coverage of web programming has definitely been fleshed out with recipes on XML-RPC, SOAP and so on, plus the new chapter on mod_perl. Also of interest of course are the additional recipes on database access with DBI.

The mod_perl chapter is a good succinct introduction, with some very cute recipes in it (though admittedly a lot of these are also covered in the excellent Mod_perl Developer's Cookbook by Young, Lindner and Kobes out from Sams). For example "Transparently Storing Information in URLs" shows how to embed information in any arbitrary position inside a URL. This quickly shows the kind of things you can do with a PerlTransHandler and a PerlFixupHandler. The chapter closes with what looks like a good introduction to "Template Toolkit", which I would probably be very excited about if I wasn't already familiar with the (also discussed) HTML::Mason.

I really enjoyed reading the XML chapter (a subject I'm less familiar with): I predict that you'll find this to be the fastest way through the XALPHABET XSOUP without drowning. For me, this was almost worth the price of the book.

Very little has been removed (hence the page count has gone from 757 to 927), and where I have been able to find a deletion, there are usually very good reasons for it. For example, the first edition takes the trouble to tell us that qr// was introduced in perl 5.005, but the new edition drops the babble about versions there, because for most of us, anything before 5.6 is now ancient history. However, I do miss this particular irrelevant parenthetic aside that's been deleted now:

Remember that the opposite of read is not write but print, although oddly enough, the opposite of sysread actually is syswrite. (split and join are opposites, but there's no speak to match listen, no resurrect for kill, and no curse for bless.)

(p.295, first edition, compare to p.323, second edition.)

In general, it's difficult to think of anything seriously wrong with the Perl Cookbook. I might suggest that in some places they fall into the trap of talking about all the ways to do it, rather than just the best ways, (e.g. recipe 7.5 "Storing Filehandles into Variables" seems a bit complicated).

And maybe there are some slight problems with order of presentation, as with the new perl 5.8 feature of "I/O Layers", which is mentioned a few times before it's finally discussed in the beginning of Chapter 8 (though really, it's amazing that there aren't more problems like this: this is supposed to be reference work, and yet it usually works well as a tutorial also).

I've got one big complaint about the 2nd edition though: they changed the numbering of existing recipes! I've been writing code with comments like

# Schwartzian transform. See Perl Cookbook, recipe 4.15

and now it turns out I should've been specifying an edition number also. Please: "Cookbook" authors, come up with a numbering scheme that remains invariant with new editions... if you can't always just append to the end of the chapter, there's nothing wrong with tacking another dotted decimal on the end. We're programmers, we can handle it.

And speaking of the "Schwartzian transform" that recipe has a very clear, self-explanatory name "Sorting a List by Computable Field", but in the first edition, there was also a footnote explaining that many people call this the Schwartzian Transform, named after Randall Schwartz, who invented the technique. With this second edition, that footnote has been quietly dropped. Guys, if you're going to carry on a feud, this is really not the way to do it. It just makes you look bad.

O'Reilly's perl.com site has a series of articles by the authors, featuring some recipes from the book:

• Cooking With Perl
• Cooking With Perl, part 2
• Cooking With Perl, part 3

Appendix: New recipes and examples (not including the two new chapters):

• Using Named Unicode Characters
• Treating Unicode Combined Characters as Single Characters
• Canonicalizing Strings with Unicode Combined Characters
• Treating a Unicode String as Octets
• Properly Capitalizing a Title or Headline
• Constant Variables
• Implementing a Sparse Array
• Creating a Hash with Immutable Keys or Values
• Matching Nested Patterns
• Writing a Subroutine That Takes Filehandles as Built-ins Do
• Storing Multiple Files in the DATA Area
• Reading an Entire Line Without Blocking
• Treating a File as an Array
• Setting the Default I/O Layers
• Reading or Writing Unicode from a Filehandle
• Converting Microsoft Text Files into Unicode
• Comparing the Contents of Two Files
• Pretending a String Is a File
• Working with Symbolic File Permissions Instead of Octal Values
• Writing a Switch Statement
• Coping with Circular Data Structures Using Weak References
• Program: Outlines
• Overriding a Built-in Function in All Packages
• Customizing Warnings
• Writing Extensions in C with Inline::C
• Cloning Constructors
• Copy Constructors
• Saving Query Results to Excel or CSV
• Escaping Quotes
• Dealing with Database Errors
• Repeating Queries Efficiently
• Building Queries Programmatically
• Finding the Number of Rows Returned by a Query
• Using Transactions
• Viewing Data One Page at a Time
• Querying a CSV File with SQL
• Using SQL Without a Database Server
• Graphing Data
• Thumbnailing Images
• Adding Text to an Image
• Program: graphbox
• Turning Signals into Fatal Errors
• Multitasking Server with Threads
• Writing a Multitasking Server with POE
• Accessing an LDAP Server
• Sending Attachments in Mail
• Extracting Attachments from Mail
• Writing an XML-RPC Server
• Writing an XML-RPC Client
• Writing a SOAP Server
• Writing a SOAP Client
• Program: rfrm
• Using Cookies
• Fetching Password-Protected Pages
• Fetching https:// Web Pages
• Resuming an HTTP GET
• Parsing HTML
• Extracting Table Data

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

celloguy writes: "HackNotes Linux and Unix Security Portable Reference is a great security reference for IT professionals. It presents information in a clear, concise, easy-to-digest manner and sticks to facts and practical approaches to security." Read on for the rest of celloguy's review. (And maybe some grumpy readers can elaborate more on this book's flaws, since celloguy didn't find many.) HackNotes Linux and Unix Security Portable Reference author Nitesh Dhanjani pages 224 publisher McGraw-Hill Osborne Media rating 9 reviewer Michael Reynolds ISBN 0072227869 summary HackNotes(tm) Linux and Unix Security Portable Reference is a great security reference for IT professionals.

The intended audience for this book is primarily IT professionals who have some experience in systems administration and security. The book is organized into logical sections: Part 1 deals with hacking techniques and defenses, Part 2 deals with host hardening, and Part 3 contains special topics. Each part is divided into chapters that follow a logical progression.

Part 1 starts with footprinting, which includes basic information gathering about potential targets. The chapters then proceed further into the stages of an attack (port scanning, obtaining a shell, privilege escalation) and finishes by discussing some of the techniques hackers use to cover their tracks. The services covered in this section include FTP, Telnet, SSH, SMTP, HTTP, HTTPS, R-services, NFS, Samba, POP, IMAP, MySQL, X, and VNC. An interesting point here is that these services are listed in ascending order with respect to their port numbers.

Part 2, Host Hardening, examines some vulnerabilities common to most systems and includes remedies. Choosing good passwords is discussed, as well as how to set password policies. Though the author warns of the dangers of weak passwords, I would have liked to see a more thorough explanation of how to choose passwords. The section goes on to explain how to disable unnecessary services and harden remote services. At the end of this section are chapter on good practices related to user and system privileges, as well as logging.

Part 3 contains some interesting material, including a whole chapter on the Nessus Attack Scripting Language (NASL), wireless hacking, hacking with the Sharp Zaurus PDA. The section on wireless networks contains some fairly standard material (WEP is insecure, using AirSnort, etc.) but nevertheless serves as a good reminder to use caution when deploying wireless networks. The final chapter, Hacking with the Sharp Zaurus PDA, is especially interesting and details all sorts of fun things you can do with this handheld device, including scanning for wireless networks, connecting to remote machines via SSH, and using VNC to control remote machines.

The Good

This book does an excellent job of presenting information in a clear and easy-to-understand manner. It avoids theories and concepts and delivers just the facts that a systems administrator needs to evaluate and protect a Unix or Linux system. It also makes use of helpful icons throughout the book which draw attention to key points. For example, hacking techniques have a sword icon next to them while defense techniques are listed with a shield. This visual feedback makes it easy to focus in on specific techniques and helps organize the material in a more usable manner. The content of the book is especially good, and the author does a thorough job of covering the basic hacking techniques as well as methods of defense against these techniques.

Another great feature of this book is the inclusion of a reference center in the middle of the book. This section, marked by easy-to-find blue pages, contains a wealth of relevant reference information, such as common commands, common ports, IP addressing, online resources, useful netcat commands, an ascii table, HTTP codes, and important files.

Suggestions

It's hard to find much wrong with this book. However, I felt that a few things were glossed over. For example, the section on passwords was extremely brief and gave no suggestions for choosing good passwords or for how long to set password expirations. In addition to the discussion on TCP Wrappers, I would have also liked to see some mention of using iptables for creating a software firewall.

Summary

HackNotes(tm) Linux and Unix Security Portable Reference is an excellent security reference for IT professionals and systems administrators. The clear, concise presentation of the book makes it easy to digest and use as a practical resource. It is well-organized and thorough and covers a wide range of situations. If you maintain one or more Unix or Linux machines, this book belongs on your shelf.

You can purchase HackNotes Linux and Unix Security Portable Reference 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 "Even Grues Get Full is the fourth and latest collection of cartoons from User Friendly. I got this collection because a friend said the third collection was brilliant 'from cover to cover.' I have to say that this collection did have some exceptionally good moments, but 'from cover to cover,' I think not." Honestpuck's review continues, below. Even Grues Get Full author J.D. "Iliad" Frzer pages 122 publisher O'Reilly rating 8 - Funny reviewer Tony Williams ISBN 0596005660 summary Chock full o' laughs. Funny, didn't split my sides or spit coffee out my nose, but funny

To start, I didn't find the inside title page even worth a smile, the only joke 'Even Grues Get Full' had already been on the front cover and I'd noticed its repetition on the back one as well.

To investigate a little further I read the 'Foreword' by Wil Wheaton. OK, it did have one good Wesley joke but mostly it seemed to be saying how much he didn't mind Iliad making fun of him in the strip.

Then we get to the strips. Yeah, some are funny. I laughed a bit. Iliad certainly knows a good tech joke when he draws one - even if he does seem to make a lot of jokes at the expense of the Windows operating system -- which seems to be a combination of shooting fish in a barrel and politically incorrect making fun of the crippled and lame. However some things are just not funny, Mr Frazer.

What about those cartoons from page 78 to 83. To start off, no self respecting Lego geek with two hundred and seventy million dollars would buy two million sets of Lego Mindstorms. I'd only (sorry, I mean 'He'd only') buy one and a half million to leave cash left over for buying a couple of hundred thousand Lego models of the Millenium Falcon -- I mean, "D'uh!" Oh, and about the cartoon on page 82: missing a 16-wheel cog to complete your project is no laughing matter you know. I don't see what's so amusing about building a missile silo out of Lego either -- I'm going to build a carry box for my cat when I can get enough blue 12 x 1 bricks.

Then there's the series about the visiting MBA. No real geek would fall in love with a woman merely because her name, 'Pearl,' was a homonym for a scripting language - get real. If her name had been 'See' or 'Jarvah,' maybe. But not funny, Iliad.

Frankly, I think this book is full of the usual 'User Friendly' rubbish. Jokes at the expense of those poor users (hey, they don't know any better), clueless management (hey, they don't know any better) and socially disadvantaged and deprived geeks (hey, we don't know any better.) Joking about the outstanding, well-informed and upright citizens that work in the sales and marketing departments of our IT firms and ISPs? Shame on you J.D. Oh, and poking fun at poor Larry Ellison just cause he isn't as rich as Bill is just downright mean.

I think Tim O'Reilly should be ashamed to publish this book. I guess the only reason he does is that Iliad hasn't poked fun at him (yet).

I wouldn't recommend this book to anyone. It's just chock full of jokes that only a Linux-loving geek could find funny. Cartoons full of references that only a Perl programming geek would understand. I didn't learn a single thing about programming in C# for .NET ot the latest protocols used in Active Directories -- a totally useless tech book, really.

Look, just go to the User Friendly web site and see some more recent examples from this deeply disturbed cartoonist, or go to the O'Reilly book page and check out a few strips from the book itself and you will agree with me.

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