Slashdot Mirror

Ponca City writes "JR Minkel writes on Space.com that as NASA celebrates the 10th anniversary of astronauts living on the space station — and with construction essentially complete — the question remains: will the International Space Station ever really pay off scientifically? The space agency contends that the weightless environment provided by the station offers a unique way of unmasking processes of cell growth and chemistry that are hidden on Earth, but some critics don't see a zero gravity laboratory as filling a crucial scientific need. Gregory Petsko, a biochemist at Brandeis University, says the only basic science justification he has ever heard for the station is that protein molecules form superior crystals in the microgravity of space than they do on Earth and a best-case scenario, in terms of return on investment, would be if a space-grown crystal were used to design a blockbuster pharmaceutical drug that worked by precisely targeting one of those proteins. Naturally NASA sees things differently. 'I think those who are naysayers haven't given us a chance — haven't given us enough time to show what we can do. We're just now turning the path to be able to go full force on our science. In the past we had to fit it in around assembly, we didn't have the facilities available, and the crew was always busy.'"

An anonymous reader writes "Progress on metal-insulator-metal diode manufacturing was just reported online in the professional journal Advanced Materials (abstract). For the first time a high-performance 'metal-insulator-metal' diode was created with cheap materials. This is a fundamental discovery. It could change the way manufacturers produce electronic products at high speed, on a huge scale, and at a very low cost, even less than with conventional methods."

eldavojohn writes "A new analysis of millennia old mummy bones (abstract; full article is paywalled) shows high concentrations of tetracycline, which indicates empirical knowledge and use of antibiotics — most likely consumed in beer. The researchers traced the source of the antibiotics to the soil bacteria streptomyces present in the grain used to ferment the beer. Astonishingly enough, 'Even the tibia and skull belonging to a 4-year-old were full of tetracycline, suggesting that they were giving high doses to the child to try and cure him of illness.' The extent of saturation in the bones leads the scientists to assert that the population regularly consumed tetracycline antibiotics knowing that it would cure certain sicknesses."

chichilalescu writes "I've had the feeling for a long time that people refuse to listen to scientists. The following is from an article on Ars Technica: 'It's hardly a secret that large segments of the population choose not to accept scientific data because it conflicts with their predefined beliefs: economic, political, religious, or otherwise. But many studies have indicated that these same people aren't happy with viewing themselves as anti-science, which can create a state of cognitive dissonance. That has left psychologists pondering the methods that these people use to rationalize the conflict. A study published in the Journal of Applied Social Psychology [abstract here] takes a look at one of these methods, which the authors term "scientific impotence" — the decision that science can't actually address the issue at hand properly.' The study found that 'regardless of whether the information presented confirmed or contradicted [the subjects'] existing beliefs, all of them came away from the reading with their beliefs strengthened."

__roo writes "American researchers think they have found the answer to the question of why overhearing cell phone chats are annoying. According to scientists at Cornell University, when only half of the conversation is overheard, it drains more attention and concentration than when overhearing two people talking. According to one researcher, 'We have less control to move away our attention from half a conversation (or halfalogue) than when listening to a dialogue. Since halfalogues really are more distracting and you can't tune them out, this could explain why people are irritated.' Their study will be published in the journal Psychological Science."

Diamonddavej writes "The BBC reports that researchers at the University of Edinburgh have found that Galactic Cosmic Rays (GCRs) somehow makes trees grow faster. GCRs vary according to the 11-year solar cycle, with more GCRs hitting the Earth during solar minimum when there is a lull in the solar wind, which normally acts to protect the inner solar system from external galactic radiation. The mechanism might have something to do with GCRs increasing cloud cover, which diffuses sunlight and increases the efficiency of photosynthesis. Nevertheless, the researchers remain mystified and are requesting further ideas and research collaboration to test hypotheses. (How about Radiation Hormesis, AKA 'Vitamin-R?')" Here is the paper's abstract at the journal New Phytologist. The researchers say: "The relation of the rings to the solar cycle was much stronger than to any climatological factors. ... As for the mechanism, we are puzzled."

Science Daily is reporting that the virus behind cold sores has been found to be a major cause of the insoluble protein plaques found in the brains of Alzheimer's disease sufferers. Researchers believe the herpes simplex virus is a significant factor in developing the debilitating disease and could be treated by antiviral agents such as acyclovir, which is already used to treat cold sores and other diseases caused by the herpes virus. Another future possibility is vaccination against the virus to prevent the development of Alzheimer's in the first place. The research was just published in the Journal of Pathology (abstract).

Hugh Pickens writes "Vaughn Bell has written an interesting essay at Scientific American about grief hallucinations. This phenomenon is a normal reaction to bereavement that is rarely discussed, although researchers now know that hallucinations are more likely during times of stress. Mourning seems to be a time when hallucinations are particularly common, to the point where feeling the presence of the deceased is the norm rather than the exception. A study by Agneta Grimby at the University of Goteborg found that over 80 percent of elderly people experience hallucinations associated with their dead partner one month after bereavement, as if their perception had yet to catch up with the knowledge of their beloved's passing. It's not unusual for people who have lost a partner to clearly see or hear the person about the house, and sometimes even converse with them at length. 'Despite the fact that hallucinations are one of the most common reactions to loss, they have barely been investigated and we know little more about them. Like sorrow itself, we seem a little uncomfortable with it, unwilling to broach the subject,' writes Bell. 'We often fall back on the cultural catch all of the "ghost" while the reality is, in many ways, more profound.' "

StCredZero writes with word of a research team from the University of Illinois who have developed a way to manufacture nanowires of any length from various materials. Not, unfortunately, carbon nanotubes, or we would be looking for news on space elevators soon. The process is analogous to drawing with a fountain pen — as liquid is drawn from a reservoir, a solvent (water or an organic) evaporates and the solute precipitates onto a substrate. The researchers have demonstrated a way to spin and wind a nanowire onto a spool; they have produced a coil of microfiber 850 nm in diameter and 40 cm long. Here's the abstract from the journal Advanced Materials.

GrumpySimon writes "Recently, the well-read science blog Retrospectacle posted an article on a scientific paper that concluded that alcohol augments the antioxidant properties of fruit. The blog post reproduced a chart and a table from the original article and everything was fully attributed. When the publisher John Wiley & Sons found out, they threatened legal action unless the chart and table were removed. Understandably, this whole mess has stirred up quite a storm of protest. Many people see Retrospectacle's action as plainly falling under fair use. There is a call for a boycott of Wiley and Wiley's journals."

An anonymous reader writes "Linux is a kernel, not an operating system. So what is Mac OS X's kernel? The Mach microkernel. The debate around Monolithic (Linux) and Micro (Mach) kernels continues, and there is a great chapter online about the Mach system from the very good book 'Operating System Concepts'. Which design is better? I report, you decide." Warning: link is to a PDF.

getling writes "Looks like Steve Jobs is almost as unhappy about personal details being publicized as he is with Mac secrets. The book publisher Wiley, who is releasing a new unauthorized biography of Jobs has had its entire line of books banned from Apple stores as a result of their unhappiness with the content of the book. Wiley, publisher of the popular Dummies series of books, as well as the Bible series, is quite surprised, due to the fact that they view the book to show Jobs in a largely positive light ..."

honestpuck (Tony Williams) writes "With Apple's iPods sitting under many Christmas trees come the morning of December 25th, the question arises as to what might sit well next to it. I'm suggesting one of these three books might be just the ticket." Read on for Williams' reviews of three iPod books. (See each) author (See each) pages (See each) publisher (See each) rating (See each) reviewer honestpuck ISBN (See each) summary Three different books on the iPod. The iPod Fan Book iPod Fan Book author Yasukuni Notumi pages 90 publisher O'Reilly Media rating 6 ISBN 0 596 00776 0

The first impression you get of O'Reillys iPod Fan Book is of the packaging. A small volume (about the same height as the iPod and twice the width) it comes with a half-height wrap that has the title and author on the front and the bar code, price and a short contents on the back. Take this off and you have a full-size cover with all the simple elegance of the white iPod itself. The front features the wheel of a 4G iPod and the back has just the Apple logo and "iPod" in Apple's distinctive typeface below it. Remove this second cover and you have a book with a simple design of grey with a white border, the back is blank and the front has the title and the subtitle "Go everywhere with iPod" in small type.

This concentration on design flows through the rest of the book. It is visually stunning; at the same time, effort has been made to make the design useful. The pages are visually tabbed to make it easy to navigate the seven chapters. Each chapter is tabbed in a different color reflected through use of that color within the chapter. Full color pictures and screen dumps add to the legibility and usability of the book.

This book is also full of useful information for the newcomer to the iPod. A small amount is covered in the documentation you get with the iPod, but a great deal is not. Apart from a useful chapter on accessories, the book focuses on methods of getting the best from an iPod and how to organise your music.

To sum up this book: it is a little more style than substance and falls short of being the ideal book for all newcomers to the iPod (and even less for experienced users). On the other hand, the style makes the information that is provided readily accessible for all. I'd say this is the perfect companion to an iPod for a teen-age girl and if my 12-year-old daughter was getting the mini she has been hinting for, a copy of this would be included. (I expect that anyone who spent more than ten minutes deciding on the colour of their mini would probably love the elegance and style of this thin volume.) The price of $14.95 retail makes it a great impulse buy or stocking stuffer.

Hacking iPod + iTunes and iPod & iTunes Hacks

The other two volumes I looked at might seem like two peas in a pod. Scott Knaster's Hacking iPod + iTunes and Hadley Stern's iPod & iTunes Hacks certainly have a similarity in their titles and have almost identical cover prices of a fraction less than $25. The content of about half of each of these volumes covers the same territory, too. There are, however, differences in both the style and content between them. So, how to decide?

Hacking iPod + iTunes author Scott Knaster pages 259 publisher Wiley Publishing rating 8 ISBN 0764569845

For one thing, it seems that Knaster concentrates more on iTunes than the iPod, while Stern seems a closer balance between the two but once again this is only a slight difference.

Both volumes are clearly, and both cover a range of information for users all the way from a relative newcomer (someone who has read the supplied documentation and played around with their iPod and iTunes for a few days) to users who want to push the envelope by installing Linux, hacking iTunes with AppleScript, or finding cheap ways to stream music, to name just a few of the more adventurous topics covered.

The first real difference between the two volumes I found was that Stern has a few more hardware hacks, including some of the surreal sort of hack that often makes these books so much fun -- who would have thought of making your own iPod case out of cardboard, for example? Stern's book is also much more a Macintosh user's book: fully twenty of the one hundred hacks, for example, are devoted to AppleScript. (Not that Knaster ignores AppleScript - he has a chapter almost entirely devoted to it.) Knaster goes into more detail about such "hacks" as podcasting, RSS feeds, email and the iTunes Music Store.

iPod & iTunes Hacks author Hadley Stern pages 417 publisher O'Reilly Media rating 8 ISBN 0596007787

The books also differ in their layout and style. Stern, like all of O'Reilly's "Hacks" book authors, has a slightly dry, informative style with a large number of references to other hacks in the book in the instructions. Knaster's style is a little more tongue-in-cheek, with far fewer references to other parts of the book. Somehow Knaster's style appealed to me a little more, though he seems at times to take a little longer to give you all the information you needed.

Stern's examples are also a little more self-contained, while Knaster tends to give you a start, point you in the right direction and tell you where to go to get all that you needed. The two different ways they approach running Linux on the iPod is typical: Stern uses the uClinux kernel and gives you detailed instructions on how to get that into your iPod using dd, while Knaster uses the Linux on iPod project and gives less detailed instructions. Stern also tells you about Podzilla and a small pointer on developing applications for the iPod while Knaster just leaves you with Linux installed.

Deciding between these two volumes comes down to personal taste, and happily both authors provide samples for you online. For Knaster's book you can go to the Wiley site for Hacking iPod + iTunes , where you can get a table of contents, the index and the first chapter. You can also visit Knaster's site for Hacking iPod + iTunes , where he has a blog on the iPod and pointers to more hacks from the book and some other cool and useful stuff.

For Stern's book you can go to O'Reilly's page for iPod & iTunes Hacks for the usual table of contents and index. It also has a link to a page with ten example hacks, there is also an article on O'Reilly's "Digital Media" website with a further five example hacks.

I'm not going to attempt to decide between these two volumes for you. If you think either might be useful, then have a look at the examples and decide which style suits you best.

You can purchase iPod Fan Book , iPod & iTunes Hacks and Hacking iPod + iTunes from bn.com. Slashdot welcomes readers' book reviews. To see your own review here, carefully read the book review guidelines, then visit the submission page.

prostoalex writes "A lot of avid PC users got first introduced to the computers through games. Some later turned their hobbies into full-time jobs. The ExtremeTech series of Wiley books aims at the readers who are curious about technology and are willing to dedicate some time to personal to projects that educate and develop skills. Before this review starts reading as a press release, I will throw in a link to my review of another title, Linux Toys, the book that pioneered the series." Read on for Alex's review of Wi-Fi Toys. Wi-Fi Toys author Mike Outmesguine pages 408 publisher Wiley rating 9 reviewer Alex Moskalyuk ISBN 0764558943 summary 15 cool wireless projects for home, office and entertainment

Wi-Fi Toys by Mike Outmesguine offers 15 projects for radio enthusiasts and those, who have never dealt with wireless networking beyond buying an 802.11 access point at local electronics store. Former US AirForce and National Guard engineer, the author is currently running a technology services company.

Assume for a minute that you have had limited experience with wireless technologies, but are young, ambitious, and eager to dive into the deep sea of wireless data. What kind of projects would be fun to play with? What kind of projects would be educational as well as useful? Probably improving the reception via various antenna hacks would be a cool thing to do, and improving access point to increase coverage would be another way to wow the neighbors with your wireless skills. Discovering other people's networks and wardriving is a must for any wireless security beginner. The author dedicates the first three parts of the book (table of contents here) to building antennas, wardriving and hacking access points. Yes, the book requires toying with hardware and occasionally being outside in the fresh air.

The first chapter, Building Your Own Wi-Fi Antenna Cable, is available online in PDF format and it talks about building your own antenna cable. The rest of the chapters in Part 1 take the reader through building a paperclip antenna, creating a tin can antenna, and modifying the existing access point with a high gain antenna.

Probably there are some people that read the last sentence and asked themselves, "So what is a high gain antenna?" Which brings us to the next point - the readability of the book. Outmesguine did a really nice job outlining the projects step by step and supplying all the major steps with the photos. The pictures are black-and-white, and so are the diagrams. Overall the pictures turned out nicely, but I wish the author had the color version on the Web site, since some of the images (like on page 79), displaying computer graphics on dark backgrounds, did not turn out very detailed. Everything essential to the project is there, but still, color photos and screenshots would have made the difference in some cases.

The author does a good job of explaining terminology before launching into the project. Where needed, Mike Outmesguine provides helpful diagrams, that any radio amateur is probably already aware of, but they still make a nice and readable book for the rest of us. Also, the goal of the chapters is not just build the toy and get done with it as soon as possible. For example, in chapter 4 when talking about modifying the existing access point, the author understands that the only reason you want to do that is to increase the WiFi coverage in your house. So a few pages are dedicated to propagation losses, interference and everything radio-related that the reader needs to take into account before strengthening the access point with a high-gain antenna.

Chapter 14 is probably the coolest in the book, as it talks about creating a car-to-car wireless link for the purpose of... videoconferencing involving two Webcams and Microsoft NetMeeting. Naturally, this is not for driver-to-driver communication, but in case you've got two cars on the road trip, the passengers now can use their WiFi-enabled laptops (and by now everyone should have one) to launch a video conference.

Overall the book reads great, even if you're not serious about doing some projects, it's still fun to follow photographs and see what Mike and the contributors have done in terms of wireless projects. Each chapter is presented as a single project, so with the exception of terminology knowledge there's no preceding knowledge that needs to be there, so one could theoretically start with a digital picture frame (Chapter 15) that hangs on the wall, downloading the pictures via the wireless link and playing occasional videos.

Overall, this is an interesting book to read, and if you've been looking for simple and intermediate projects involving radio technologies and WiFi, the Wi-Fi Toys is packed with useful information.

You can purchase Wi-Fi Toys from bn.com. Slashdot welcomes readers' book reviews. To see your own review here, carefully read the book review guidelines, then visit the submission page.

aphexbrett writes "Clever geometry is the basis of a new material that is said to be ideal for secure data encryption and dense optical information storage. The material consists of a lattice of onionlike spheres in which the particle core and its layers each contain a different dye. The material can hold four or more pieces of information in one spot--not just two as in binary optical data storage. And it opens a door to high-density three-dimensional optical data storage. Read a summary of the research over at C&EN News."

Peter Wayner writes: "If you're a handicapped Windows user, Microsoft offers suggestions and assistance -- but XBox users were out of luck until Andrew 'Bunnie' Huang finished his book Hacking the XBox. Don't be fooled by the title. Officially, Huang's excellent book is not about helping the differently-abled. That would be against the law. Huang was forced by the DMCA to hide his humanitarianism under the cloak of 'reverse engineering' because this is one of the few legitimate uses given a small amount of protection by the law. But if you've got an urge to help the handicapped or any other reason to tinker with your XBox, buy this book before the Man sees through this ruse." Read on for the rest of Peter's review. Hacking the XBox author Andrew "Bunnie" Huang pages 288 publisher No Starch Press rating 9 reviewer Peter Wayner ISBN 1593270291 summary How and why to crack the seal on your Xbox.

There are many reasons why you might want to take apart your XBox, but one of the best ones I can imagine is making it easier for people who can't see, hear or move too well to play the same video games as the rest of us. Searching Microsoft's web site for documents containing both "handicapped" and "xbox" reveals only a suggestion for how to change the degree of difficulty of your Zoo Tycoon Game.

Someone who might want to retrofit a new pointing device or some other enabling gadget onto the XBox might start with the chapter describing how to fix a real USB cable onto the XBox. The chapter, like most in the book, is heavily illustrated with step-by-step pictures and instructions for clipping the cables in the right place and soldering them back together. Some of this might seem a bit rudimentary, but the detail can't hurt. In many cases, the real challenge is finding a way to take apart the case or the pack of wires in the right way. Smashing it isn't always an option. This is a book about mathematics, electronics, and taking apart plastic boxes.

Alas, just doing a bit of soldering isn't going to be enough unless you can make the right drivers. To help those who might want to reprogram their XBox, Huang devotes much of the book to stripping away the layers of the XBox security system, a story that is part mystery and part journey through the security layers in the system. The book is arranged in a very roughly chronological order. While it is mainly a book that teaches you how to reverse engineer the XBox, it is also a story of how he overcame the obstacles presented by the encryption. He talks as much about the unsuccessful paths as the ones that paid off. (This is, I think, an ideal model for the scientific community. It's much more educational than the terse papers that present the results as fait accompli.)

This part of the book quickly gets quite complicated, because Microsoft obviously tried hard to produce a secure machine that could provide a fair platform for people to play games. Getting the XBox to run any old software is not an easy task, but Huang describes several major techniques for drilling through the various layers of security. Again, he offers detailed pictures and instructions for construction special tools that snarf signals from a bus. Then he explains how he managed to grab the right keys for decrypting some of the most important data. Although it's a technical book, it unfolds like a spy novel.

The book is also very politically thoughtful. While the clueless will equate the word "hacking" in the title with piracy, money laundering, terrorism, and not phoning home on mother's day, Huang frames every step with a discussion of whether it is motivated by good or evil. He's not interested in building a tool to pirate XBox games and points out that many of the modifications aimed at running Linux on the Xbox do not help the pirates in any way. If anything, they make the games entirely unplayable.

Huang does want to defend the right to tinker, citing Ed Felten and others in a defense of something we're rapidly losing. I've heard horror stories from Army Majors about Windows PCs that refused to boot after failing to find a C drive. Do we really want to build machines that can't be retrofitted or fixed in the field? Many war movies are saved by the young private who (like Huang) is willing and able to tinker.

If you don't respond to pulls on the heartstrings, you might want to read one of the concluding chapters from the EFF's Lee Tien about the current legal climate. There are few exemptions for tinkering and many of them are limited. Reverse engineering is okay if you're a big corporation making a competing product, but that didn't help 2600 magazine when they were accused of trying to help people view DVDs on their Linux machine. I can only imagine what they would do to someone with very bad vision who wanted to enable a special zoom feature on their Xbox.

The book was originally going to be published by Wiley, but the company balked when it realized there were stiff legal penalties for helping handicapped people use computers. Even the Massachusetts Institute of Technology felt that it would be better for Huang to disassociate itself from Huang and his humanitarian efforts. The university only relented after pressure from a few good professors who helped the university understand the value in Huang's mission. Huang decided to publish the book himself with the help of his girlfriend, Nikki Justis. The two of them should be commended for turning out such a beautiful, professional book. If you're intrigued by the xbox, interested in helping the handicapped, or just trying to learn how to reverse engineer things before things get worse, check out this book. It's a wonderful contribution to the literature.

To close, I'm offering a pair of cool projects with the hope that Huang's book will inspire people to tinker:

• Sonic Information -- The sound in games like Quake is pretty good, but what if it was rendered with enough precision to let blind people grok the scene? The echoes from the tapping of a white cane already carry plenty of information to the blind. What if they could compete on an equal footing with the sighted? Who would win?
• Eye Movement Measuring tools -- Tools exist for sensing the position of our eyes. A quadriplegic game could just look in the right direction and shoot. Clearly some work would need to be done to encode all of the shift-left-left-down-right maneuvers from the games. This could help all of us. The thumb you save from repetitive motion injuries could be your own.

Note: Since this review was written, Hacking the Xbox has found a publisher in the form of No Starch Press. The original self-published version will probably be a sought-after collectable ;)

Peter Wayner is the author of Translucent Databases and ten other books. None rely on the DMCA. Hacking the Xbox is due in July at bn.com; you can also go directly to the book's page at No Starch Press. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

An anonymous reader submits "According to Nature's report : "A new ink changes colour at the flick of a switch." It now named Photonic Ink, or P-Ink. "P-Ink's iridescent colours depend upon a process called diffraction." "To make the colour of the ink tunable" the team led by Geoffrey Ozin "packs a polymer gel between its stacked spheres" which can change size "when it is soaked in solvent and shrinks when it dries". In addition, it "conducts electricity", and "altering the voltage tunes the ink's colour smoothly through the spectrum." more detail also can found on Advanced Materials."

davorg contributes this review of Wiley's new Red Hat Linux 8 Bible, writing "I've never been much of a fan of large computer books and, to be honest, this one hasn't done much to change my opinion. These large books often seem a little confused about their target audience. They often cover everything from very basic concepts to very complex ones, and I don't really believe that anyone really needs that breadth of coverage. Or, at least, not all at the same time and from the same book." You'll find the rest of Dave's review below. Red Hat Linux 8 Bible author Christopher Negus pages 1062 publisher Wiley rating 6 reviewer davorg ISBN 0764549685 summary Wide but shallow overview of Red Hat Linux 8.0

This book is a great example of that. It comes complete with three CDs containing Red Hat Linux (which, I assume, are the same as or very similar to the three that come with Red Hat's own shrink-wrapped product) and it therefore starts with installing Red Hat Linux. However, some thousand or so pages later, the same book is talking about some really quite advanced systems administration tasks. I'm really not sure that the same audience will need both of those ends of the spectrum.

Let's take a look at the contents in more detail:

Chapter 1 gives a useful review of Red Hat Linux. It pretty much assumes that the reader knows nothing about Linux and goes into some detail about what Linux is and where it comes from. It even takes time out at one point to explain what an operating system is. The book does score a few early points for knowing the difference between "hackers" and "crackers" and using the terms correctly. This chapter ends with a more detailed look at Red Hat Linux and some of the changes that were introduced with version 8.0. Chapter 2 covers the installation of Red Hat Linux. It does a good job of explaining this in a way that would be clear to someone with no previous knowledge of how to do this.

Chapter 3 is the start of the second major section of the book which introduces the day-to-day use of Red Hat Linux. In chapter 3 we look at logging into the system and get an introduction to using Unix from the command line. Chapter 4 goes into a similar level of detail on using the two dominant GUI environments -- Gnome and KDE. For a beginner, it may have made more sense to have these chapters the other way round as most Red Hat installations will boot straight into a GUI environment and one of Red Hat's changes for version 8.0 was to make it far harder to work out how to get a shell window open.

Chapter 5 starts to look at at Linux applications. It begins with a table of common Windows applications and their Linux counterparts. It then goes on to discuss finding, downloading and installing new applications where, to my mind, it would have been more sensible to first look at using some of the pre-installed applications. The chapter also includes details on using the Red Hat Packager Manager (rpm) and running Windows applications using WINE.

Chapters 6 to 9 each look at a separate application area and present a very brief overview of the applications available in that area. Chapter 6 is about producing documents, chapter 7 about games, chapter 8 about multimedia and chapter 9 about the Internet. In all of these chapters the overviews are necessarily very short and it's hard to see how anyone could get much useful work done after reading them. It would be better if the chapters contained references to further reading, but they don't even mention the man pages.

Chapter 10 starts the next section of the book, which is about system administration. It contains a useful overview of a number of the most common administrative tasks like mounting disk drives, monitoring system usage or setting the date and time. Chapter 11 is about administering users. Chapter 12 looks at automating system tasks. It includes an introduction to shell scripting and a useful description of the start-up and shutdown cycle. Chapter 13 covers backing up and restoring files. Chapter 14 is possibly the most useful chapter in the book for the complete Linux beginner as it contains an overview of security issues. This is particularly important with the increase in the number of people who leave their computers permanently attached to their broadband connections.

The forth and final section looks at networking, with chapters on setting up a LAN, a print server, a file server, a mail server and many other shared resources. This section also includes a chapter on getting your network connected to the internet. As with much of the rest of the book, space constraints prevent these chapters from going into great depth, and there are very few references to other material.

So what did I think overall? Well, as I said, it's too big. But on the other hand it's too small. It's too big in that it covers such a wide range of topics that very few people are likely to be interested in all of it. It's too small in that it just doesn't have the space to go into great depth about most of the topics is covers. I think that it would be far more useful if was three books: Red Hat 8 Linux Users Bible, Red Hat 8 Linux Admin Bible and Red Hat 8 Networking Bible. Each of them could be smaller than this volume, but still cover the material in more detail.

Having said that, the material all seems accurate. The few times I noticed something that I thought was wrong, on checking I found that I was mistaken. So if want you really want is a broad (but in places shallow) overview of Red Hat Linux then this could well be the book for you.

And it's also cheaper than the "official" Red Hat Linux products.

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

An anonymous reader writes: "I have been called upon to conduct some science workshops for children of various ages, and I'm looking for some good demos. In particular, I've found that demos are most effective at getting students to think when they give a surprising or unexpected result, such as the classic two-slit experiment (or, for the extreme crowd, demonstrating the Leidenfrost effect by sticking one's hand into a vat of molten lead [PDF]). I'd like the Slashdot crowd's suggestions." Please don't do the lead one.

Slashback tonight with some rare bits of good news, at least for those who liked BBC Ogg Vorbis streams, or who use AES to protect data. Plus, a (final?) turn in the Greek gaming ban, and another visit to Dummies hell.

Let's get with it on those .ogg portables, OK? rassie writes "Checking back at what used to be one of my most visited sites, I noticed that I might start using it again very soon. The BBC is returning to streaming in ogg format. From the page:
Update (2002-09-24): Yay, the legal issues have been resolved. We now have rights to all the of the BBC's radio output. Hopefully we should start kicking off these streams soon."

Your email is still (probably) safe. BitterOak writes "A recent Slashdot story reported that AES might have been broken by the new XL attack of Courtois and Pieprzyk. However, it appears there aren't enough linearly independent equations for this attack to work against AES. Cryptographer T. Moh has a brief explanation here, and Don Coppersmith posted a comment on the NIST AES discussion forum (under General Cryptanalytic Attacks), which comes to the same conclusion. Coppersmith is one of the world's greatest cryptographers, so it seems safe to assume that AES has not been broken at this point."

Hey, now it's just like most of the U.S.! yoink! writes "The BBC is running the following story detailing the end of the short-lived electronic gaming ban in Greece. The Government realised that (hopefully) relatively little gambling was involved with those playing computer, and console games all over the country. The decision to clarify those games which are, in fact, electronic gambling facilities are the only forms of electronic gaming with which the revised legislation now concerns itself."

The lawyers sound like ... dummies. Blue Aardvark House writes "I am an author for the Slash site Slackers Guild. Recently Nastard, the owner of Slackers Guild received a threatening letter from Wiley Publishing concerning the site's Slacking for Dummies document. Nastard's reply is here."

Update: 09/27 03:31 GMT by T : Note: the Slacker's Guild website seems to have slacked, and the links no longer work. For the text of the letter sent by Wiley to Nastard, search below for comment #4340698 by SiMac; for the response, see comment #4340840 by decaying. Also, the "Slacking for Dummies" document link now points to Google's cache.

It's not the first time that Wiley has hunted down obvious parody works; they've even fired off similar mail because someone used "Dummies" in the subject line of an email.

Peter Wayner writes: "In a world where Ali had to meet Frazier and Luke had to meet his father, it was only a matter of time before buzzwords like Java and eXtreme Programming found themselves together on the same marquee. A pair of new books examines some open source Java development tools and outlines how they can be put to use by those trying to master their workload by adopting the techniques of eXtreme programming." Read on for his latest review, which is really two reviews in one. (see each) author (see each) pages (see each) publisher (see each) rating (see each) reviewer Peter Wayner ISBN (see each) summary Two books which explore the use of Ant in Java software development

The two books are excellent examples of how the book industry organizes and disciplines the often crazy explosion of new tools, approaches, structures and metaphors developed by the software industry. Ant: The Definitive Guide by Jesse Tilly and Eric Burke comes from O'Reilly, the masters of producing missing manuals for open source projects. The other, Java Tools for eXtreme Programming: Mastering Open Source Tools including Ant, JUnit, and Cactus by Richard Hightower and Nicholas Lesiecki was published by John Wiley and Sons. Both provide a clear, example-driven exploration of the tools at hand.

The books are probably driven by the success of Kent Beck's Extreme Programming Explained: Embrace Change , a manifesto that outlined Beck's belief that the best way to develop code was with small teams of programmers and users who constantly reworked the software. His most controversial and attention grabbing notion demanded that the programmers work in pairs sharing one computer, one mouse and one keyboard. The constant interaction forced everyone to actually communicate with each other without sending emails and that, more than anything else, may be responsible for the success of his vision. His book spawned a few others on how programmers can plan to apply his vision.

Meanwhile, on the other side of the buzzword galaxy, the Apache group was quietly creating some of the coolest Java development and deployment tools around. Ant was and still is one of the most revolutionary, even though it was just a simple reworking of the classic UNIX make command. Its creator, James Davidson, grew so frustrated with the shell interface of the make command that he wrote a Java-centric version that moved all of the compilation, compression, and distribution inside one Java process. Now, no one has to wait for another Java Virtual Machine to start up to compile each class file independently.

While Davidson's Ant isn't much different than make at first glance, it's hard to overestimate the power of giving programmers a clever tool with plenty of hooks into the development process. Anyone can write new tasks for Ant, and some clever folks have built great new widgets that do things like enforce style guidelines or grab new code from a CVS tree. The structure of Ant lets the programmer dig deeply into the build process. The organic growth and dynamic flexibility shows how close Java can be to Lisp.

Tilly and Burke do a good job capturing the spirit of the tool. Their book follows O'Reilly's time-tested and market-proven simple-examples technique to illustrate how to use Ant for your projects. The chapters in the first half of the book outline how to use and extend Ant for your project. The strength of the book may be the way the authors casually include practical advice about the bugs and idiosyncracies of the tool. While Ant is quite capable, there are a number of little limitations to the XML parser that can drive new users a bit nuts. The second half of the book is a detailed description of the API, the data types and the other practical documentation.

In one sense, it's not really fair to lump this book in with all of this gloss about Extreme Programming. because it's just another methodical O'Reilly book with Dover artwork on the cover. It's important to realize that these tools aren't directly tied to the extreme programming movement. Ant was just created by a Java programmer who hated to wait. Everything else came afterwards when he opened the API.

Ant: The Definitive Guide author Jesse Tilly & Eric M. Burke pages 260 publisher O'Reilly rating 7 ISBN 0-597-00184-3 summary A methodical, in-depth look at the Java tool.

The other book, however, explicitly illustrates how some popular open source tools can help the process of extreme programming. Hightower and Lesiecki's book is much broader than Tilly and Burke's because they want to tackle so much more. They don't want to just provide a missing manual for the tool-- they want to give the world a road map on how they use Ant and its cousins JUnit, HTTPUnit, and Cactus to build better applications. It should be noted that Hightower and Lesiecki work for a consulting group called eBlox and a number of other eBlox programmers are listed as contributors to the book. I think it's fair to say that anyone who hires eBlox will get eXtreme Programming results built with this methodology.

The best part about this book is the wide scope. Ant remains the central taskmaster responsible for building the software, but the book explains how to incorporate other tools for testing the software. The authors embrace one of the extreme programming central beliefs that programmers should define how to test their code before it is actually written. The book explains how to use JUnit, Cactus, and HTTPUnit to set up rules to test every class file. After ANT fires up the compiler, it turns around and runs the tests on the code.

Java Tools for eXtreme Programming author Richard Hightower and Nicholas Lesiecki pages 513 publisher John Wiley and Sons rating 7 ISBN 0-471-20708-X summary How to use some Java tools to transform extreme programming theory into reality.

I don't think that eXtreme Programming or any of these tools is the last word on the subject. The biggest problem is that testing a piece of code is guaranteed to be fairly rudimentary. No programmer can come up with test cases to push all of buttons in all possible combinations. The structure and discipline provided by this approach can help, but the book makes it clear that no amount of pairs programming or extremism will remove the need for the guidance of good programmers.

If anything these tools and the books about them should serve as inspiration for the next round of tools even more focused on extreme programming. The tools are impressive, but there is plenty of room for more innovation. None of them is aimed at explicitly coordinating the work of multiple developers and none of them is designed to provide much structure to the refactoring process. These areas are still very much arts, but there's no reason why tool suites like Ant can't evolve some rational approach to solving them. Perhaps the Slashdot audience can provide some informative postings with pointers to the next generation of cool tools.

Hightower and Lesiecki's book feels a bit more rudimentary and basic than Tilly and Burke's, in part because they cover so much more ground. Although their book is broader, it doesn't go into as much depth about Ant as Tilly and Burke's. The examples are simpler, too, and Hightower and Liesiecki seem mainly interested in getting you excited about building and testing software with the tools. There just isn't as much room for details. If you're interested in learning as much as you can about Ant, choose the book devoted to it. If you want to learn how to use a diverse set of tools to build and test your program in an extreme way, go for that book.

Peter Wayner blends the buzzwords of security, privacy, and data warehousing together in his latest book, Translucent Databases. It shows how to ensure that only the right people see the right information and the wrong people get nothing. His other new book, Disappearing Cryptography, mixes the buzzwords of being, nothingness, steganography, and cryptography. You can purchase both Ant: The Definitive Guide and Java Tools for eXtreme Programming from bn.com. Slashdot welcomes readers' book reviews -- to submit yours, read the book review guidelines, then hit the submission page.

David Kennedy writes: "Java Tools For Exteme Programming: Mastering Open Source Tools including Ant, JUnit and Cactus by Hightower & Lesiecki is a welcome addition to my bookshelf at work. It tackles a gap in the Java book market in dealing with the thorny issues of testing, integration and deployment." The rest of his review is below. Java Tools For Exteme Programming: Mastering Open Source Tools including Ant, JUnit and Cactus author Richard Hightower & Nicholas Lesiecki pages 516 publisher Wiley Computer Publishing rating 8 reviewer David Kennedy ISBN 047120708X summary Practical introduction to Java tools for Extreme Programming, with an emphasis on immediate results rather than deep theory.

In recent years there has been a increased emphasis on Agile Software Development. The most prominent of these methodologies is probably Extreme Programming.

What sets Extreme Programming apart from most other Agile Technologies, in my opinion at least, is that it has provided practical, easy-to-use tools to support its way of working. Most of these tools (Ant, JUnit etc) are Open Source and freely available. However popular these tools have been with the Open Source and Extreme Programming communities, it has arguably been difficult to introduce them to traditional IT development environments. This has been primarily due to the problems of justifying spending time on 'playing' with something and the difficulties of retro-fitting new tools to an existing development environment (think projects of 150+ people which have been releasing for 5-10 years for some idea of the potential problems).

It's worth noting that when embarking on a new, large-scale project it's very difficult to find a book discussing the issues of controlled builds, integration and deployment in practical terms. The most valuable aspect of Java Tools for eXteme Programming is that it's alone in its market niche.

The book is mainly useful as (a) an introduction to the various building and continuous testing tools out there and (b) a tutorial to getting them setup and working on your computer. As the authors note, there's a critical period where the user must get some result after playing with the tool for a short period of time or just give it up as 'too difficult.'

From a technical standpoint the book is very readable, but it doesn't tackle any one subject in great depth. It certainly provides enough information to get you up and running, and also, perhaps more valuably, illustrates how to integrate the tools together. It's an excellent primer for those who want to use the tools but are unsure of how exactly to start.

What's covered? Here are the chapter headings:

1. Introduction and Key Concepts
   1. Introduction to Extreme Programming
   2. J2EE Deployment Concepts
   3. Example applications
2. Mastering the Tools
   1. Continuous integration with Ant
   2. Building Java Applications with Ant
   3. Building J2EE applications with Ant
   4. Unit testing with JUnit
   5. Testing Container Services with Cactus
   6. Functional Testing with HttpUnit
   7. Measuring Application Performance with JMeter
   8. Load Testing with JUnitPerf
3. API and Tag Reference
   1. Ant Tag Reference
   2. Ant API Reference
   3. JUnit API Reference
   4. Cactus API Reference
   5. HttpUnit API Reference

If you use some of these tools already will you learn anything? Probably -- I personally have been using JUnit to test EJBs for almost nine months now but didn't know about JUnitPerf or Cactus.

Should you buy it? If you're new to the tools, then Yes. If you work in a professional but traditional IT shop, I'd buy one for the group (I have). It'd be particularly useful when dealing with management and proposing changes to working processes, or when trying to bring co-workers up to speed and sell them the benefits of agile ways of working.

You can visit the book's website at Wiley. You can purchase the Jave Tools For Extreme Programming from bn.com. Want to see your own review here? Just read the book review guidelines, then use Slashdot's handy submission form.

David Kennedy writes: "Java Tools For Exteme Programming: Mastering Open Source Tools including Ant, JUnit and Cactus by Hightower & Lesiecki is a welcome addition to my bookshelf at work. It tackles a gap in the Java book market in dealing with the thorny issues of testing, integration and deployment." The rest of his review is below. Java Tools For Exteme Programming: Mastering Open Source Tools including Ant, JUnit and Cactus author Richard Hightower & Nicholas Lesiecki pages 516 publisher Wiley Computer Publishing rating 8 reviewer David Kennedy ISBN 047120708X summary Practical introduction to Java tools for Extreme Programming, with an emphasis on immediate results rather than deep theory.

In recent years there has been a increased emphasis on Agile Software Development. The most prominent of these methodologies is probably Extreme Programming.

What sets Extreme Programming apart from most other Agile Technologies, in my opinion at least, is that it has provided practical, easy-to-use tools to support its way of working. Most of these tools (Ant, JUnit etc) are Open Source and freely available. However popular these tools have been with the Open Source and Extreme Programming communities, it has arguably been difficult to introduce them to traditional IT development environments. This has been primarily due to the problems of justifying spending time on 'playing' with something and the difficulties of retro-fitting new tools to an existing development environment (think projects of 150+ people which have been releasing for 5-10 years for some idea of the potential problems).

It's worth noting that when embarking on a new, large-scale project it's very difficult to find a book discussing the issues of controlled builds, integration and deployment in practical terms. The most valuable aspect of Java Tools for eXteme Programming is that it's alone in its market niche.

The book is mainly useful as (a) an introduction to the various building and continuous testing tools out there and (b) a tutorial to getting them setup and working on your computer. As the authors note, there's a critical period where the user must get some result after playing with the tool for a short period of time or just give it up as 'too difficult.'

From a technical standpoint the book is very readable, but it doesn't tackle any one subject in great depth. It certainly provides enough information to get you up and running, and also, perhaps more valuably, illustrates how to integrate the tools together. It's an excellent primer for those who want to use the tools but are unsure of how exactly to start.

What's covered? Here are the chapter headings:

1. Introduction and Key Concepts
   1. Introduction to Extreme Programming
   2. J2EE Deployment Concepts
   3. Example applications
2. Mastering the Tools
   1. Continuous integration with Ant
   2. Building Java Applications with Ant
   3. Building J2EE applications with Ant
   4. Unit testing with JUnit
   5. Testing Container Services with Cactus
   6. Functional Testing with HttpUnit
   7. Measuring Application Performance with JMeter
   8. Load Testing with JUnitPerf
3. API and Tag Reference
   1. Ant Tag Reference
   2. Ant API Reference
   3. JUnit API Reference
   4. Cactus API Reference
   5. HttpUnit API Reference

If you use some of these tools already will you learn anything? Probably -- I personally have been using JUnit to test EJBs for almost nine months now but didn't know about JUnitPerf or Cactus.

Should you buy it? If you're new to the tools, then Yes. If you work in a professional but traditional IT shop, I'd buy one for the group (I have). It'd be particularly useful when dealing with management and proposing changes to working processes, or when trying to bring co-workers up to speed and sell them the benefits of agile ways of working.

You can visit the book's website at Wiley. You can purchase the Jave Tools For Extreme Programming from bn.com. Want to see your own review here? Just read the book review guidelines, then use Slashdot's handy submission form.

SilverStr writes: "With all the recent discussion on organizations rethinking their security strategies, I thought I would do a review on one of my favorite books. I have stayed pretty quiet on /. over the years, but security is something I don't think developers anywhere should be taking lightly. Hopefully some of them will get something out of my review and pick this book up." Read on for the rest of his review of Ross Anderson's Security Engineering. Security Engineering: A Guide to Building Dependable Distributed Systems author Ross Anderson pages 612 publisher Wiley Computer Publishing rating 9.5 reviewer SilverStr ISBN 0-471-38922-6 summary An exceptional book on the dynamics of security engineering. A must have on all developers shelves who care about digital security and its impact on system design.

Introduction

The complexities of security engineering go beyond the ideals of understanding buffer overflows and considering that patching your systems is not an option. Many a Slashdot article (particularly the latest one on Louis Bertrand's OpenBSD presentation) has comments on the failings of code design. In Ross Anderson's book Security Engineering: A Guide to Building Dependable Distributed Systems, Ross goes into impeccable detail into the aspects of building systems resilient to malicious attack, abuse and programming error.

The book is well laid out, and in my opinion Ross properly segmented the topics in a way that makes the sections easy to read. The first section is focused on the many concepts of digital security such as protocols, access control and cryptography, and is written in a way so that you do not require a technical background to understand. It was refreshing to read how Ross explains cryptography in such a non-threatening manner that you can understand it without having to refer to Applied Cryptography from Bruce Schneier. Many authors have tried this in the past, and failed.

The second part of the book goes into considerable detail about practical and important applications such as banking and network attacks and defense. I have to be honest with you, I don't read a lot of books on software engineering that go into Radar Jamming and Nuclear Command and Control systems, and I found that sort of discussion exciting. (Although I have no interest in writing security code for the next cruise missile that will move the world to a level of DefCon quicker than that in movies like War Games, I still was quite interested in the approach.) Many of the examples and case studies that Ross explains bring the whole topic together to help strengthen the point about security engineering and its application to each system. Further to this, Ross' writing made me shutter to think about just how popular applications like bankcard systems have been written to be so weak and vulnerable. Before the book's main content, Ross includes an explanation the legalities of publishing some of this information. It wasn't until I started reflecting on some of the case studies that I realized how potent and valuable some of this information is, especially when I thought of potential risks that should have been mitigated and were not. Ross' examples should be considered textbook cases, though, and not information that can be drastically abused.

The third part looks into the organizational and policy issues faced with security engineering. From office politics to security and the law, this section goes into depth about managing security engineering and its affects on business and people. Compared to the rest of this book I found some of the topics in this section too short on detail, feeling like just a glancing blow, but still giving the reader enough information to seek more in depth content if they so choose. (Check out the bibliography for such information.) Discussing issues such as Carnivore, digital copyright, and system evaluation and assurance, this section rounds out the book quite well.

Why to Consider this Book

If you are a developer considering security (which should be all developers, anyways) this book provides a good balance on security engineering, and serves as an excellent reference work. It can work well as a textbook introducing developers to security engineering, and can be used as a good introduction to many dynamics of digital security. (Hint to COMP professors outside of Cambridge: get your students to read this book -- after you do of course).

Although you might not be able to use the section on radar jamming and its countermeasures directly, you may still be able to use principles in writing protected electronic systems while working on that new wireless system for Ma Bell. And finally, you should use this book as a brick in the foundation of learning on the concepts of writing secure code.

Something else you should consider in this book is the extensive bibliography in the back. If you want to follow up with more detailed information in any one section, Ross did an tremendous job in providing pointers to research papers and work done by others to read and research on. This in itself made the book well worth the money, as for me I have already read up and used some of the works I didn't have indexed to me before.

Wrap Up

If you are going to read this book and look for samples to write secure code, you are going to pick up the wrong book. This book is a cornerstone in building a strong foundation and understanding of security engineering. This book is goes beyond understanding the practical components of buffer overflows, stack smashing and code audits for review, and takes the reader into a new plain of understanding when it comes to security engineering. It is not a cookbook for lazy script kiddies to learn how to attack weak systems, but can be used to allow you to learn from others mistakes. You don't have to be a developer working on security systems to gain some knowledge from this text. Areas in the book such as that on E-Commerce can very much help bridge the chasm of bad web application design and can help you refrain from getting in the trap of fast application development full of vulnerabilities and exposing users to unnecessary online risk.

It is the responsibility of all developers to understand the risks they expose their software and their clients to. I am sure some developers will have some excuse where their web forms and applications do not require them to learn such silly things. That's fine. Hopefully I wouldn't need to use your systems. For the rest of us though, this is a must read.

Table of Contents

Part One

1. What Is Security Engineering
2. Protocols
3. Passwords
4. Access Control
5. Cryptography
6. Distributed Systems

Part Two

1. Multilevel Security
2. Multilateral Security
3. Banking and Bookkeeping
4. Monitoring Systems
5. Nuclear Command and Control
6. Security Printing and Seals
7. Biometrics
8. Physical Tamper Resistance
9. Emission Security
10. Electronic and Information Warfare
11. Telecom System Security
12. Network Attack and Defense
13. Protecting E-Commerce Systems
14. Copyright and Privacy Protection

Part Three

1. E-Policy
2. Management Issues
3. System Evaluation and Assurance
4. Conclusions

Bibliography

You can purchase Security Engineering from Fatbrain. Want to see your own review here? Just read the book review guidelines, then use Slashdot's handy submission form.

Stephanie Black contributes this review of a book which might be nice to have around if someone suggests that Open Source is "not for business use." Managing Open Source Projects is one of a class of books that will probably expand hugely in the next few years. Managing Open Source Projects author Jan Sandred pages 189 publisher John Wiley & Sons rating 9 reviewer Stephanie Black ISBN 0-471-40396-2 summary A HOWTO on putting the principles and advantages of Open Source programming to work.

First Impressions There is a word for this book: SWEEEET!

It's short, too, but before you grumble about paying nearly 30 bucks for something that's less than 200 pages, you might want to look at the concept of quality. It's worth every blessed dime, plus taxes (if applicable).

Managing Open Source Projects opens with a history of the movement, thus providing background information and context to prospective or actual managers of Open Source projects. In this sense alone, Sandred has set himself apart from numerous other authors on the subject, providing an overview of a movement which has been over 30 years in the making, and whose restructuring of the "old-economy" is just beginning.

The development of the browser wars is dealt with in this history, a subject not everyone is familiar with. What it amounts to is a lesson in 'instant karma' that Netscape Inc. learned after doing a lot of damage to the Mosaic browser, ("mozilla" comes from "Mosaic killer"), and subsequently having the same done unto them by the Redmond Contingent(TM). Sandred sort of implies that this lesson had more than a cursory role in the 1998 opening of the Mozilla source code, which staggered the industry all round. Obviously, Netscape learned several somethings from the experience.

The author moves on to discuss the relevance of open source to business. (You knew *that* was coming, didn't you?). Sandred raises the common assumption of business known as Brooks' Law ('the performance of programming teams does not scale so as to increase the productivity of the team'), and then uses the history of Linux development to illustrate the inadequacy of this model in describing the open source development process. In sum, Sandred asserts that the differentiating factor is what he calls the "political attitude" of the open source model, which breeds a different leadership style. The "administrative overhead" required by each member of a development team may increase with each new developer, but without the geographic restrictions posed by a code farm, there is a wider base of "administrators" to choose from. (Now you know what to tell your boss.).

Chapters 8-10 cover a variety of tools useful (and commonly used) in building open source works, and methodologies used to set up the project (including the team). You've heard of Sourceforge, right? CVS? Or maybe "The Slashdot Effect"?

Highlights There are some portions of Managing Open Source Projects that are guaranteed "feel good" items which remind any open source developer of why we do what we do.

In his discussion of open source philosophy, Sandred points out that the viability of the open source model is not restricted to software:

"With computers, perfect copies of a digital work can easily be made, modified, and distributed by others, with no loss to the original work. Individuals interact and share informa- tion,and then react and build upon it; this is not only natural, it is also the only way for individuals to succeed in a commu- nity. In essence, the idea of open source is basic to the natural propagation of digital information among humans in a society. This is why the traditional notion of copyright does not really make sense on the Internet." (p. 52)

He points out that the United Nations has adopted an open source approach to distributed assets, including (especially) information. The link between democracy and freedom of information is clear, and iterated not only by Sandred, but by UN Secretary-General Kofi Annan, and Dr. Gro Harlem Brundtland, Secretary-General of the World Health Organization.

It's not "just" a software development model anymore.

Imperfections There are some small issues this writer has to take with Mr. Sandred's pronouncements, among them the following:

"All software cannot be developed open source. Open source software tends to concentrate on infrastructural design and back-end software. Open source benefits from incremental de- sign, which means back-end systems. End-user applications are hard to write. These applications deal with graphical user interfaces, which are very complex to write, almost always customized, and comprise other skills like graphical inter- face design." (p.160)

This writer would, upon reflection, argue with pretty much everything in this paragraph, save for the self-evident last statement. Both the GNOME and KDE projects are about providing desktop applications, and the managers to go with them. Most window managers provide applications to go with their "suites". There are productivity software suites in progress.

Ah, well, it's one bad moment of two in the entire book.

Mr. Sandred makes an unwitting gaffe in his discussion of "Five Open Source Commandments" in Chapter 12: the last of these reads 'Join a project rather than starting your own.' While joining another project is helpful, even useful, it does not replace the "developer's personal itch" that Sandred quotes from Eric Raymond's 19 lessons (Cathedral and the Bazaar, O'Reilly, 1999), in Chapter 2. Do both!

Conclusion Don't just sit there -- go get the book, even if you're not currently involved in, or planning on, managing an open source project. The information is timely, the pace is lively, and Sandred has provided a wealth of insight into the open source movement's past, present and future. While some of his work has perceptual errors, these are few. The rest of it is pure gold.

You can purchase this book at Fatbrain.

You want to code all day (or as long as you can stand), whether from home or in an office environment that suits you, with the right soda in the fridge, and friendly coworkers to ask questions when the going gets tough. You want a job in a field that will keep you interested for more than the first orientation meeting, and one that lets your skills be useful -- right down to your favorite programming language. Gavin Bong contributed this review of Programming Interview Exposed: Secrets to Landing Your Next Job, a book designed to lead interviewees for programming positions into the jobs they want.

Programming Interview Exposed author John Mongan and Noah Suojanen pages 272 publisher John Wiley & Sons rating 8/10 reviewer Gavin Bong ISBN 0471383562 summary A book to help developers achieve success in their technical interviews.

Introduction

Many people consider an interview a Kafkaesque experience, where all your skills (technical and social) come under the microscope. My toughest interview was one where I sat in a conference room faced with five hungry interviewers and "How many lines of code have you written in your career?" was considered small talk.

The promise

This book will not teach you how to handle small talk, but still may do wonders for you in your next interview. The author's promise, that reads: "If you work on learning to solve not just the specific problem we present, but the types of problems, you'll be able to handle anything they throw at you," is certainly ambitious, but they've succeeded admirably in my opinion.

General overview of book

Chapters 1 and 11 are short and sweet, but impart important lessons on how to negotiate offers, preparing for open-ended questions like "What are your career goals?" and generally convincing the employer that you can fit into their culture. Appendix A's coverage of writing technical resumes is brief but sufficient. Their bottom-line message is: craft a resume to sell your skills; don't write an autobiography.

The rest of the book comprises a review of common programming questions you may face, as well as a selection of puzzles that appear regularly in technical interviews.

The secrets summarized

The authors' secrets to technical interview success can be summarized as follows:

1. Make sure you master the programming language that the job asks for.
2. Practice solving problems and study heuristic methods.
3. Master common data structures like linked lists, strings, trees & graphs.
4. Be conversant in programming paradigms like recursion and Big O notation. And depending on the area of expertise that the interviewer is looking for, brush up on topics like concurrency, networking and database concepts.

Let's dissect these bullet points one by one

(1) The authors expect the interviewee to master every feature of the language that the job calls for, including the quirky and obscure ones. Personally, I think that knowing the core elements plus the specific features that the employer is looking for is more than enough. For example, in the Java paradigm; multithreading would be considered core, while knowing JNDI would be a speciality. But take note that an interview is not something you study for. It's not like a certification exam. You certainly need a couple of projects using that language under your belt to be absolutely prepared.

In interviews where you can choose the programming language, the authors caution against using lesser languages like Javascript or Visual Basic. But my opinion is that -- if it's used appropriately, and within the bounds of the job description -- any of these should be fine.

(2) G. Polya once said "Experience in solving problems and experience in watching other people solving problems must be the basis on which heuristic is built." The authors have kept to this spirit and included a generous number of challenging puzzles to exercise your brain. This is no coincidence, as both authors graduated from Stanford, where Polya once taught. Solutions are provided, but more importantly they've also included descriptions of the thought processes that underlies them. And by the way, the types of puzzles listed here probably wouldn't be out of place in a MENSA exam or the U.S. Computing Olympiad.

The authors also offer practical suggestions on how to solve problems, such as "Think out loud by explaining what you're doing," and "If you're stuck, consider looking at a specific/general example of the problem."

(3) The book offers one full chapter on linked lists. The author is justified in this, as linked lists can be operated upon by a multitude of operations. And each operation can usually be coded with a minimal number of lines of code. Ignore this advice at your peril.

(4) From experience, the authors have found that if you don't put down a particular skill in your resume; questions on those topics will not generally arise. So by setting the right expectations; you'll be able to get through the interview with fewer tangled nerves. But general programming knowledge questions like "What does it mean to be a 32 bit OS?" or "What is the difference between C++ and Java?" should be expected. Chapter 10 offers a healthy sample of them.

Weakness

One of the strengths of this book is that it focuses fully on the topic at hand which is "programming interviews" and never gets sidetracked. However it does have its weaknesses, in that there's very little mention of the high possibility of questions on component programming models (EJB,COM/COM+,CORBA). I think component-based software development (using off-the-shelf components) is the future of our industry (whether open or closed source) and companies are not interested in creating software from scratch. Also missing from the book is any mention of localization or internationalization of software.

Is it worth buying?

At 272 pages, this book can easily be skimmed in one sitting. But its value will not be apparent until you start solving the included problems/puzzles yourself and understanding the pattern of interview questions. This book is not a magic bullet that will guarantee you success in every technical interview, but having a rough estimate of what you will face is certainly better than being surprised.

Who is the target audience?

This book is especially relevant to recent computer science graduates who are just entering the industry. It may also be useful to technical recruiters and software managers (who assume the role of interviewers) who want to get some insights into the interview processes used by other companies. It might not be appropriate for people from other technical disciplines like system administrators or DBAs. Seasoned programmers may still get some benefit from the book although you've probably had first-hand experience with most of the questions/problems posed in the book.

Table of contents

• Chapter 1: The Job Application Process
• Chapter 2: Approaches to Programming Problems
• Chapter 3: Linked Lists
• Chapter 4: Trees and Graphs
• Chapter 5: Arrays and Strings
• Chapter 6: Recursion
• Chapter 7: Other Programming Topics
• Chapter 8: Counting, Measuring and Ordering Puzzles
• Chapter 9: Graphical and Spatial Puzzles
• Chapter 10: Knowledge Based Questions
• Chapter 11: Non-Technical Questions
• Appendix A: Resumes

Purchase this book at FatBrain.