Slashdot Mirror

theodp (442580) writes Unless some things change, UC Davis Prof. Norman Matloff worries that the Statistician could be added to the endangered species list. "The American Statistical Association (ASA) leadership, and many in Statistics academia," writes Matloff, "have been undergoing a period of angst the last few years, They worry that the field of Statistics is headed for a future of reduced national influence and importance, with the feeling that: [1] The field is to a large extent being usurped by other disciplines, notably Computer Science (CS). [2] Efforts to make the field attractive to students have largely been unsuccessful."

Matloff, who has a foot in both the Statistics and CS camps, but says, "The problem is not that CS people are doing Statistics, but rather that they are doing it poorly. Generally the quality of CS work in Stat is weak. It is not a problem of quality of the researchers themselves; indeed, many of them are very highly talented. Instead, there are a number of systemic reasons for this, structural problems with the CS research 'business model'." So, can Statistics be made more attractive to students? "Here is something that actually can be fixed reasonably simply," suggests no-fan-of-TI-83-pocket-calculators-as-a-computational-vehicle Matloff. "If I had my druthers, I would simply ban AP Stat, and actually, I am one of those people who would do away with the entire AP program. Obviously, there are too many deeply entrenched interests for this to happen, but one thing that can be done for AP Stat is to switch its computational vehicle to R."

A while ago you had a chance to ask Andrew "bunnie" Huang about hardware, hacking and his open source hardware laptop Novena. Below you'll find his answers to those questions. Why "bunnie"?
by Anonymous Coward Seriously, that's the first question I have whenever I see his name. I just can't get past it. What's the story behind that nickname? Please tell me so I can focus on his good works instead.

bunnie: “bunnie” is a shortened version of my full nickname, which is “vorpal bunnie”. In Monty Python and the Holy Grail, the vorpal bunnie is an innocuous-looking rabbit that would suddenly spring forth, decapitating King Arthur's knights with its sharp pointy teeth. It was also a mob in the Rogue clone “Moria”, and it had the interesting property of exponentially reproducing if you didn't kill it immediately. Whenever I ran into it, I would kite it around the dungeon until the level was overrun by vorpal bunnies.

It was around this time that I had to pick a handle for logging in to BBSes and I don't mean punbb, I mean the old 1200 baud dial-up jobs from the 80's. My friend helping me set up an account was probably just trolling when he recommended “vorpalbunnie” as a username, but lacking any other inspiration, I ran with it.

When I enrolled at MIT, it was 1992, and the Internet was still just a curiosity. I had to pick a logon for their computer system, Athena. I hated the generic-sounding default of “ahuang”, so I went with my BBS nickname. I had to shorten my username to bunnie because vorpalbunnie was too long – back then, usernames and passwords were often required to be less than eight to ten characters, rather than more.

Still, few people called me by bunnie, because well, the Internet wasn't very popular and aside from a messaging client called Zephyr, nobody saw my username. This all changed in 1998, when I was a TA for a required Computer Architecture class, and the professor in charge couldn't remember my actual name and he introduced me to about 300 students as “bunnie”. The name was unforgettable – nobody would remember Andrew once they had heard bunnie. I realized at this point I wasn't going to win against the nickname, and so I accepted my fate and henceforth adopted “bunnie” as my new identity.



Chinese industry
by Esteanil

What is the most important thing you wish you had learned earlier about manufacturing in China?

bunnie: Chinese. And how to use a squatting toilet.



Re:Chinese industry
by tchdab1

And speaking of learning, where have you learned things that you could not easily or ever have figured out on your own? Which environment or learning experience do you look back on with gratitude?

bunnie: This is an interesting question. There's a lot of things I couldn't have learned on my own. I don't think I could have taught myself physics; there is in fact a place for classroom learning. I don't want to overemphasize the value of textbooks, but a certain amount of textbook study is necessary, particularly in the hardware world, and having teachers who can explain difficult concepts to you through simple analogies and/or who take the time to understand what you're missing and give you the clues you need is important. Hardware is based upon physical principles and having a solid foundational knowledge of physics will help tie everything together.

That being said, book learning alone won't get you all the way there. There's a lot of practical hands-on knowledge that is not taught in classrooms but I have acquired through many mentors. Generally, I like to surround myself with people who are smarter than I am; you learn a lot just by observing the methods and manners of these people. Subjects like how to debug circuits, running manufacturing operations, how to manage people, how to negotiate, and how to hack are not easily figured out on your own. I like to watch people do these things, and learn from their techniques.

I think the key thing about the environment is that the transfer of knowledge really only happens in a situation where things are “being done”. In other words, you don't learn much from conferences, presentations, or lectures on these topics. I always find it a bit of an irony when I'm asked to lecture on things like manufacturing or hacking. When you can sit shoulder to shoulder with another engineer and watch them problem solve, that’s when you can really see their thought process. You can see all the failures they go through, and the twisting path they take to finally arrive at the answer. In a lecture or presentation, there tends to be a focus only on presenting the problem and the solution, but none of the intermediate failures. Those intermediate failures contain very valuable lessons, which is why hands-on learning is so important.

I'd say my “real” learning began in my PhD program, where you only had to take the courses you really needed to understand your research, and you could skip all the fluff. Also, in that environment, you got to sit with a bunch of peers who are all struggling with difficult questions, and you share notes about how you fail every week, and trade suggestions on how to improve; and you have the wisdom of a thesis advisor who can help guide you when you're really lost. The nice thing about starting my “real life” in the PhD program is that it was an environment where I could take huge risks, fail, and the only consequence is I'm set back on my graduation date. Once you step into a startup, you're burning capital and you're working to a deadline; you become much more risk-averse. That's probably the biggest difference I see between people who went straight to industry vs. graduate school: folks in industry are great at execution, but tend to stay with what they know. Folks who went to graduate school can be unreliable and late for deadlines, but they also tend to take more intellectual risk.



How do you become a professional hardware hacker
by werepants

What advice would you give to a person who wanted to make a living in the "Maker" tradition - being able to spend your days designing, engineering, and building on technically interesting and creative maker projects? I'm most interested in the career aspect, assuming that you've already obtained a preliminary education: would you look for a job with a similarly minded engineering firm, launch a kickstarter, start a hackerspace, hack together some things and try to sell them through a webstore, work as a freelance engineer, or something else entirely?

bunnie: Hardware hacking is a lifestyle. You sort of end up living in it – unlike software people, where all your code is stored in the cloud and all you need to perform is a laptop, hardware people accumulate boxes and boxes of parts, and need a lab full of equipment to get their work done. Novena is an attempt at consolidating some of that into a portable form factor but I'm never going to be able to give up a work bench equipped with a good Tektronix scope and a soldering iron.

Previously, I thought there were two career options in life: either go corporate, or go startup. There's a third path that's not often talked about – the “lifestyle business.” VCs and corporates ridicule this option, because its goal is to make enough money for you to sustain a lifestyle, but doesn't have a “future” – it won't scale to a billion dollars, it won't be acquired by a big company, and it probably won't ever IPO. This does not mean, however, that you have to live on instant ramen and bother your parents every year for money. Lifestyle businesses can grow to million-plus per year turnover businesses, and the margins can be quite good; so when you run the math, your net cash flow can be better than a corporate day job.

The key to starting a lifestyle business is to find a problem that someone has, and to solve it. This sounds really simple, but in fact in today's world of mass-manufactured solutions, what you find is you have cheap solutions that get you 90% of the way there, but few people have 100% solutions to their most pressing needs – and that last 10% is where all the difficulties lie.

A first-order test for whether you've found a genuine solution to a real problem is how much someone would pay for your solution. If someone has a real problem and they really need it solved immediately, and you can convince them you're going to actually solve it, the customer will typically pay a premium for that solution. I always wondered, for example, why there are equipment companies that can get away with selling specialty products that constitute not much more than a panel meter with an Arduino in a badly injection molded plastic case. Certainly, a multimeter can be a potent tool in the hands of someone with a degree in electrical engineering, but a measurement solution that you can hand to any untrained field worker and get correct, consistent results that you can rely upon is hard to come by. Compared to the cost of paying someone to drive out to the field and repeating measurements day after day, it's a steal to get a foolproof piece of kit for a few hundred bucks. In other words, it's not the value of the parts the customer is paying for – it's the value of getting it right the first time and every time after.

The biggest down side of a lifestyle business is that it's not consistent – typically you have one or two major clients, or your clients all concentrate in the same business area. This means your revenue can be highly unpredictable and your business will rise and sink with the macro-economic tides. Practically speaking, this means you need to stay debt-free – once you take on a mortgage or saddle yourself with a fancy car you bought with borrowed money, it's hard to accept the risk of running a lifestyle business. This is easier said than done; there is a lot of peer pressure to keep up with the Joneses, at least in America. One of the subtle benefits of living in Asia is the locals are cheap – the old money tends to understate their wealth and many millionaires ride the bus and eat regularly at the local food court to save a buck or two. It also doesn't hurt to to have a safety net of friends and family you can rely upon – knowing you can always call up your folks or having a sugar mama who can reliably cover rent during thin periods helps mitigate the risks of running a lifestyle business. Finally, it helps to take these risks before you have children, or simply decide to not have children at all – your priorities change once you have dependents who rely entirely upon you for their livelihood.



100% Open Hardware
by Anonymous Coward

At what point will we be seeing a 100% complete open hardware platforms, replaceable~ for modern OTS offerings? By that, I mean from silicon manufacture to FOSS binary. 100% open design, manufacture, and source code. I'd like to think this endeavour isn't more than a thought experiment.

Small Scale Chip Manufacturing?
by Cpt_Kirks

Where do you see small scale chip manufacturing, up to and including custom multi core CPU's, going in the near future?

bunnie: Combining these two questions into one answer.

There is a dirty secret about open software vs. open hardware. In open software, bits are virtually free to copy, store, and distribute. In contrast, for open hardware, atoms are all owned by someone or some organization; or if they aren't specifically owned (e.g., air, water, minerals in the ground), the access to said atoms are regulated by governments or warlords (in regions with no functioning government).

And thus, as you peel the onion of openness, you find yourself asking questions such as, “who owns this pick and place machine?” “who makes the lithographic stepper?” “how was this copper smelted?” “where did this tantalum come from?”. Why should F/OSS simply stop at silicon manufacture, after all? Or for that matter, why do people care so much about F/OSS chip manufacture, yet have no problem with the closed-source processes and machines being used to manufacture PCBs? At the end of the day, there's a fancy multi-million dollar tool that's being used to write the mask patterns for your IC or your PCB, and do you trust that to not have a back door? That machine also probably runs some flavor of Unix, or failing that, is probably loaded with GPL software that's not being used according to the license.

As a fun mental exercise, I looked into what it would take to make an MCU with the power of an Atmel AVR to replace the closed-source IC that's inside an Arduino. Currently, it seems you can design the Verilog hardware description, synthesize it, and lay out the logic using a fully open source tool chain (although you'll probably spend more time managing and fixing the design tools than you'll spend designing with them). However, you would still have to sign an NDA to get access to the process geometry files, and the EEPROM memory block is provided as a drop-in hard macro. As in, you don't get the source for the EEPROM, you simply leave an EEPROM-sized hole in your maskwork and the fab will slot in the respective polygons for you (there's a long list of plausibly legitimate reasons for why this is the case that I won't bore you with). So if you really wanted to insist that all the design source was open, you couldn't build something that could retain its program memory without power, which is kind of essential for a self-contained MCU like an Arduino.

And then, if you think through this exercise a bit further, even if I shared the high-level design source (Verilog, schematics, layouts) with the world, if users can't access the design rules for the fab process, they still can't practically modify the design; and even if they were okay to sign an NDA to get the process design rules, they'd still have to fork out tens of thousands of dollars to get samples made.

So at the end of the day, the idea of having a BSD-style “make universe” in hardware is tantamount to writing a manual for rebooting civilization from the ground up to the point of manufacturing silicon.

The open hardware community has struggled with this reality, and the best proposal I've heard to date is the concept of “layers of openness”. Hardware is built upon very strong and modular abstraction layers; it's not like software where you could, technically, reach around a virtual machine and tweak real machine parameters if you had to. Silicon is silicon, PCBs are PCBs, and although there are research projects to merge the two in practice there is a very bright and clear line dividing those two abstractions thanks to things like chemistry, physical laws and supply chain logistics.

While we never got as far as making iconographic labels for each layer of openness, there is an idea that well, it's sure better that the PCB design source is being shared than kept proprietary, even if the ICs are closed and the PCB manufacturing process is closed, and the design tool for the PCB is closed. So generally, the hardware community's consensus is that it's legit to say hardware is “open” if you're more open than the status quo; but in reality, if you look at the total amount of human design knowledge, capital investment, and manual labor that goes into making a piece of hardware, we're going to have to rely upon a complex web of suppliers and sub-contractors driven more strongly by issues such as cost management rather than openness for quite some time.

The good news is that as Moore's Law grinds to a halt, fab processes are becoming fully depreciated, dropping the up-front cost of doing a new IC design by orders of magnitude. This means an “open source” (at least at the level of HDL source code) CPU is probably just a couple years away. In fact, there is a team at the University of Cambridge that I'm advising that is making an honest run at building a usable open source CPU. I think their team has a great chance to meet their goal and I think it's definitely a step in a right direction. Their first run at it won't have the performance of top-notch mobile CPUs, but their current direction may include some very unique and meaningful architectural features that will set it apart from closed source alternatives when it comes to security and code reliability.



How was it growing up?
by haneefmubarak

How avid of a hacker were you when you were in high school and how supportive do you feel your friends and family were of your hobby?

bunnie: I started hacking – or rather tinkering – with electronics around the age of 8. By the time I was in high school I was a hopeless nerd (now that I think about it, I was a nerd before being a nerd was cool). High school was actually not too bad, because I went to a magnet school with other nerds, and my teachers and friends were very supportive.

The toughest times were in elementary and middle school. Kids that age have no concept of political correctness, and being both a meek nerd and the only Chinese boy in a midwest school set me up for a lot of bullying and ridicule. I had a couple of other outcast/nerd friends who I'd hang out with occasionally, but mostly, I just kept to myself. I'd just sit in the back of the cafeteria playing with my programmable calculator and reading datasheets (believe it or not, I would carry around as easy reading electronics catalogs and three-inch thick databooks published by Intel and other manufacturers). Most kids didn't even care to understand what I was looking at; they were more concerned if I could see through my squinty eyes and having fun flicking my large Asian earlobes so they would swell and become even bigger and more goofy looking. But being an outsider has its advantages; I was less constrained by the social pressure other kids felt, and overall I was having a lot of fun building hardware.

My parents were always extremely supportive and patient, and they often turned a blind eye toward things I would take apart but not quite get back together into its original fit and form. I think they were happy enough that their son would rather spend summer days in the basement hacking on the Apple II and reading volumes of “Getting started with Science” rather than chasing girls and smoking cigarettes stolen from the local convenience store.



Restrictions in the future?
by plover

Do you see manufacturers of the future attempting to put restrictions on hardware hacking, either more technical or legal? Will manufacturers order CPUs without I2C pins, or toy drones with UEFI secure boot operating systems? Have other countries put restrictions on hardware hacking that have affected you?

bunnie: I don't see pure hardware manufacturers putting restrictions on this. Manufacturers actually want lots of back doors and flexibility to probe their hardware, because they have to be able to debug or reprocess parts that fail to pass quality inspection. Scrap rate directly impacts the bottom line, so there's a strong financial incentive to make hardware that's easy to debug, and transitively, easy to hack.

The people who tend to put restrictions on hacking hardware are people who own content or run services on the hardware. Hardware in that case is seen as a barrier or a method to ensure lock-in to a particular platform, or to require payment for services. Occasionally, content providers are the same as the manufacturer, in which case you tend to see a lot more restrictions put in place on the hardware. As long as the hardware world isn't taken over by the Apples, Amazons, Microsofts and Googles of the world....oh wait, nevermind. We'll just have to keep on defending our rights as consumers by jailbreaking and hacking for some time to come.

But if someone is purely in the hardware business, they actually have no incentive to lock you out – they'll make all the money they ever will selling you the hardware in the first place, and if you bought it just to tinker with, that's just one more sale for them.



How do you go about discovering hacks?
by Joe Gillian

I haven't read your book (I will when I get off work) but I'm curious as to how exactly people discover these hacks. I mean, there's some really weird ones out there that make me question how people even thought to do them, such as hacking a PSP battery into service mode in order to load custom firmware or manually opening a PS2's disc tray to bypass the copy protection that only activated when the button to open or close the DVD drive was pressed. I know with the Xbox, there was a software hack (I don't know if it's the same one you found) with save files from certain games, but only specific versions of those games. So my question is, how do you go about looking for exploits?

bunnie: Surprisingly, many exploits are based on well-known holes or common mistakes made during implementation; it's almost as cliché as kicking in the door with the “unpickable” electronic lock. In hardware, there's almost always JTAG diagnostic ports or a serial console available, and most manufacturers don't bother to plug them. In software, there's a lot of complexity and things tend to leak at the seams, so poorly implemented APIs that lack bounds checks is a very common avenue for exploits. I actually don't think I've “invented” any exploits in my entire career; everything I've done you can find examples of in prior literature, or they are so obvious that one cannot really claim credit for it (a bit like climbing in through the window when the front door is locked – it's just common sense).

But generally, the first things you tend to look for are backdoors put in place for diagnostic or engineering purposes. I'd say 80% of the hardware I've hacked have welcome mats like this set out for me. Then, you look for opportunities to gain access to the code image within, either through dumping ROMs or injecting a small program that can dump RAM. If you can get the binary code, you can reverse engineer it and look for exploitable APIs and function calls. Lacking such code, you can attempt to characterize the system through fuzzing and scanning the available APIs; this involves, for example, injecting garbage into file structures, sending malformed packets or glitching wires and clocks to get the hardware into a vulnerable state. And then there is the whole host of somewhat more difficult vectors such as microscopy and side-channel analyses through power signatures and parasitic emissions, but you usually fall back to those only once all else has failed. There are also occasions where you are confronted with a CPU with an undocumented instruction set or a lack of documentation on its registers or interrupt handlers. In this case, it really helps to have an automated fuzzing framework because often times this boils down to doing a brute-force search of memory space for certain signatures and signs of the registers or behavior you're looking for.

And, one should never pass up trying obvious things, like googling for the root password included in the SoC's maker's devkit and trying that on the diagnostic console. This has worked surprisingly often...



Hacking the Xbox
by nmb3000

One of my first forays into the realm of hardware hacking was following along as you recorded your exploration of the original Xbox console. I was fascinated by the hardware, but enjoyed your analysis and methods even more. It was you that got me interested in hardware and hacking. (Aside: Thank you very much for releasing your book as a freely-available download and for the open-letter about Aaron and MIT)

What was the most memorable experience for you of your Xbox expose? Was there a particular part of the hardware that you found especially well-designed (or laughably poor)? A method that yielded unexpected success (or failure)? What kind of fallout from Microsoft did you face? I remember you posting the voicemail of the Microsoft employee asking you to remove the images of the Xbox ROM -- something I got a good laugh out of. And as a follow-up: do you have a feeling for how "secure" hardware has changed in the decade since the original Xbox launch?

Thanks for taking the time to answer our questions, and also for all the work you've done pushing for a world with both open software and open hardware.

bunnie: Thanks for reading the book! Actually, the book pretty comprehensively documents my experience hacking the Xbox, even a decade on there's no new secrets for me to give out. There's always that massive endorphin rush when your experiment works out – I remember the night I found the secret key I could barely sleep; I was trembling with excitement.

But it's also important to remember there's a lot of luck involved and at the end of the day I really prefer to do hacking for fun, and not as a business model. It's much easier to carve out a living, in my opinion, building things than breaking into things; sometimes you encounter things that are really difficult to break into and you end up expending much more resources and time than the contract is worth. So, I find it hard making money as a hacker: I either charge too little for the service, or I lose money completing a difficult job that I underestimated.

I think Microsoft has done a very professional and comprehensive job securing their latest generation of consoles. They hired some of the best and the brightest hackers to design it and they actually listened to them. You'd also be amazed at how incredibly hard it is to get management to sign off on silicon modifications to improve security, but these days more and more manufacturers are starting to “do it right”.

benrothke writes "It has been about 8 years since my friend Richard Bejtlich's (note, that was a full disclosure 'my friend') last book Extrusion Detection: Security Monitoring for Internal Intrusions came out. That and his other 2 books were heavy on technical analysis and real-word solutions. Some titles only start to cover ground after about 80 pages of introduction. With this highly informative and actionable book, you are already reviewing tcpdump output at page 16. In The Practice of Network Security Monitoring: Understanding Incident Detection and Response, Bejtlich takes the approach that your network will be attacked and breached. He observes that a critical part of your security posture must be that of network security monitoring (NSM), which is the collection and analysis of data to help you detect and respond to intrusions." Read below for the rest of Ben's review. The Practice of Network Security Monitoring: Understanding Incident Detection and Response author Richard Bejtlich pages 376 publisher No Starch Press rating 9/10 reviewer Ben Rothke ISBN 978-1593275099 summary Definitive guide to the new world of Network Security Monitoring (NSM) In this book, Bejtlich details how to design a NSM program from the initiation state. Being a big open source proponent, the book lists no proprietary tools and myriad open source solutions. The book is designed for system and security administrators, CIRT managers and analysts with a strong background in understanding threats, vulnerabilities and security log interpretation.

The book is about the inevitable, that attackers will get inside your network. While it's foreseeable they will get in, it's not inevitable that you have to be caught off-guard. For those who are serious about securing their network, this is an invaluable book that provides a unique and very workable model to create a fully-functioning NSM infrastructure.

The book is a hands-on guide to installing and configuring NSM tools. The reader who is comfortable using tools such as Wireshark, Nmap and the like will be quite at home here.

This is a book about how not to be surprised and its 13 chapters detail how to create and manage a NSM program, what to look for, and details myriad tools to use in the process.

The focus of the book is not on the planning and defense phases of the security cycle, hopefully, that is already in place in your organization, rather on the actions to take when handling systems that are already compromised or that are on the verge of being compromised, as detailed in the preface.

In chapter 1, the book details the difference between continuous monitoring(CM) and NSM; since their terms are similar and many people confuse the two. CM is big in the federal computing space and NIST provides an overview and definition of it here. The book notes that CM has almost nothing to do with NSM or even with trying to detect and respond to intrusions. NSM is threat-centric, meaning adversaries are the discussion of the NSM operation; while CM is vulnerability-centric; focusing on configuration and software weaknesses.

Also in chapter 1, Bejtlich asks the important question: is NSM legal? He writes that there is no easy answer to that questions and anyone using or deploying an NSM solution should first consult with their legal counsel; in order not to potentially violate the US Wiretap Act and other laws and regulations. This is especially true for those who are in European Union (EU) countries, as the EU places a high threshold on information security teams who want to monitor network traffic. Something as simple as running Wireshark on a corporate network in the US, would require court approval if done on an EU-based network.

One of the main NSM tools the book references and details is Security Onion (SO). SO is a Linux distro for IDS and NSM. Its based on Ubuntu and the distro contains Snort, Suricata, Bro, Sguil, Squert, Snorby, ELSA, Xplico, NetworkMiner and many other useful security tools.

The book details and explains how use these tools in an NSM environment. An important point Bejtlich makes in chapter 9 regarding the tools, is that analysts need tools to find intruders. But methodology is more important than just software tools. Tools collect and interpret data, but methodology provides the conceptual model. He explains that CIRT analysts must understand how to use tools to achieve a particular goal, but it is imperative and important to start with a good operational model first, and then select tools to provide data supporting that model.

The book has a short discussion of how cloud computing effects NSM. In a nutshell, the cloud throws a monkey wrench into an NSM effort. For example, it is generally not an option for SaaS offerings since customers are limited to the back-end logs.

The book closes with the observation that NSM is not just about all the tools that the author spent over 300 pages discussing, rather it is more about the workflows, metrics and collaboration. Unfortunately, this title does not detail the necessary workflows for a NSM and it is hoped that the follow-up to this book will.

The only negative in the book is that as CSO of Mandiant, Bejtlich references his firm's products, mainly their MIR appliance for a CIRT. In the spirit of objectivity and not trying to have the book come across as marketing PR, if an author is going to mention a product their firm sells, they should also mention alternative solutions.

For those looking for a comprehensive guide on the topic of NSM, written by one of the experts in the field, The Practice of Network Security Monitoring: Understanding Incident Detection and Responseis an excellent reference that is certain to make the reader a better information security practitioner, and their network more secure.

Reviewed by Ben Rothke.

You can purchase The Practice of Network Security Monitoring: Understanding Incident Detection & Response from amazon.com. Slashdot welcomes readers' book reviews (sci-fi included) -- to see your own review here, read the book review guidelines, then visit the submission page.

Michael Ross writes "Of all the computer programming languages, JavaScript may be enjoying the most unprecedented renaissance ever. Once derided as a toy language suitable only for spawning bothersome popups in browser windows, JavaScript is rapidly developing into a first-choice web technology on both the client side and the server side. One way to get started learning this ubiquitous language is the book Eloquent JavaScript: A Modern Introduction to Programming." Read below for the rest of Michael's review. Eloquent JavaScript: A Modern Introduction to Programming author Marijn Haverbeke pages 224 publisher No Starch Press rating 9/10 reviewer Michael Ross ISBN 978-1593272821 summary A concise and lighthearted tutorial on this popular web programming language. Written by Marijn Haverbeke, the book was published by No Starch Press on 3 February 2011, under the ISBN 978-1593272821. On the publisher's page for the book, visitors will find the table of contents and some reviews. (My thanks to the publisher for a review copy.) The author's book website offers much more, including HTML versions of the book (whose content differ from the print edition), errata (applicable only to the first printing of the paper edition), and an interactive code sandbox where you can run the examples (or at least some of them).

At a slender 224 pages, this volume might at first glance appear inadequate for covering such a sizable and rich language as JavaScript — and yet the table of contents suggests otherwise, with a dozen chapters covering language basics, functions, objects, arrays, error handling, functional programming, object-oriented programming, modularity, regular expressions, web programming, the DOM, browser events, and HTTP requests. In addition, readers may be reminded of how much information Kernighan and Ritchie were able to pack into the 228 pages of the first edition of their classic The C Programming Language.

Following a pleasant introduction, the first three chapters present the basics of JavaScript. In the first one, the author presents the language's fundamental grammar, specifically: values, data types, arithmetic operators, expressions, variables, control statements, the JavaScript environment, and program structure. The material assumes no prior knowledge of computer programming or even data representation.

In the second chapter, the author does a thorough job of explicating all aspects of functions, including definition form and order, variable scope, arguments, the call stack, closure, and other topics. The subsequent chapter addresses an area important to any programming language, namely, data structures — which in JavaScript are of two varieties, objects and arrays. The author illustrates some best practices, such as modularizing code.

Most programming books underemphasize or even completely neglect the critical topic of error handling, and thus it is encouraging to see the author of this book address it, as early as Chapter 4. He focuses on exception handling, and also touches upon the value of unit testing (incorrectly termed "automated testing"). The subsequent chapter describes functional programming, which is not to be confused with procedural programming, but rather refers to combining functions in order to achieve higher levels of abstraction in one's code, thereby reducing its size and better exposing its functionality amidst the syntactical clutter. One apparent technical flaw is the claim that, in HTML documents, the special characters <, >, and & always must be replaced by their entity values, even when surrounded by whitespace characters (page 78). (Incidentally, any book that mentions the KGS Go Server can't be all bad.)

Object orientation is the subject of the sixth chapter, the longest in the book. Despite the author's efforts, this material will likely prove to be the most challenging to readers, given the numerous idiosyncrasies of JavaScript's objects and their built-in methods. The next chapter explores a related topic, modularity, which unfortunately is not supported natively by JavaScript; the author presents some ideas to work around this limitation.

Of all the data processing performed by web sites and apps, a significant portion of it is text manipulation, where the use of regular expressions can be extremely valuable, despite the potential pitfalls. This is tersely covered in Chapter 8, which, in my opinion, should instead be located far earlier in the book, after the discussion on strings. The next chapter is a fast-paced examination of just some of the key aspects of client-side scripting using JavaScript. The only confusing portion is the reference to "the document tag" (page 155), with no explanation as to what that is. The last three chapters continue the discussion of in-browser programming, focusing on the Document Object Model (DOM), browser events, and HTTP requests. Some of the material feels dated, but it is a decent survey of relevant information.

The narrative is well written, aside from the use of long dashes when semicolons are called for and the occasional strange phrasing, such as "two backslashes follow each other" (page 12). Also, the book contains several erratum, most of them a simple mismatch of singular and plural forms: "The example show" (page 11), "executing a statements" (20), "is a special kind of objects" (46), "special type of objects is" (68), "with is em" (89; should read "is em"), "than of an" (90; should read "than an"), "new type of objects" (123), "used as to map" (146), "on [the] current field" (185), and "touched on [in] Chapter 9" (190).

The author wisely makes use of numerous examples, which are of two types: Most if not all of the fundamental concepts are illustrated with pithy examples — particularly in the first half. In Chapters 3, 5, 6, and 11, the author utilizes extended, fictional examples. Some readers may argue that these longer ones are excessively so — especially the terrarium — but there are many nuggets to be found in those pages. In fact, the book overall is largely free of fluff.

In terms of technical information, the book does not attempt to cover all the details of the language itself. Readers will appreciate that the author does not shrink from pointing out the weaknesses in JavaScript, as well as explaining the problems they may cause. One blemish is that many of the small sections of code contain a mixture of complete lines of code as well as standalone expressions (in bold), and usually those expressions are terminated with semicolons, giving them the appearance of lines of code. No doubt some readers will be confused by this convention.

From a production standpoint, the text is quite readable, except for the quite annoying and obvious problem that the font to indicate in-line source code looks almost identical to the non-code text font. There are few diagrams and even fewer screenshots, but that poses no difficulties.

At times this book is even fun to read, partly because of the use of non-silly humor, especially in the two examples of the eccentric (and cat-centric) aunt, and an unsocial reclusive programmer (imagine that).

If you choose to start your JavaScript journey with this book, it can quickly teach you a lot of technical information (relative to its size), and also programming wisdom.

Michael Ross is a freelance web developer and writer.

You can purchase Eloquent JavaScript: A Modern Introduction to Programming from amazon.com. Slashdot welcomes readers' book reviews (sci-fi included) -- to see your own review here, read the book review guidelines, then visit the submission page.

Michael Ross writes "Web designers, graphics artists, and others who create and edit digital images, have a number of commercial image-manipulation packages from which they can choose — such as Adobe Photoshop and Adobe Fireworks (originally developed by Macromedia). Yet there are also many alternatives in the open-source world, the most well-known being GNU Image Manipulation Program. GIMP is available for all major operating systems, and supports all commonly-used image formats. This powerful application is loaded with features, including plug-ins and scripting. Yet detractors criticize it as being complicated (as if Photoshop is intuitively obvious). Admittedly, anyone hoping to learn it could benefit from a comprehensive guide, such as The Book of GIMP." Keep reading for the rest of Michael's review. The Book of GIMP: A Complete Guide to Nearly Everything author Olivier Lecarme and Karine Delvare pages 676 pages publisher No Starch Press rating 9/10 reviewer Michael J. Ross ISBN 978-1593273835 summary A comprehensive tutorial and reference to GIMP 2.8. Authored by Olivier Lecarme and Karine Delvare, The Book of GIMP: A Complete Guide to Nearly Everything was published by No Starch Press on 22 January 2013, with the ISBN 978-1593273835. The publisher's page offers minimal information on the book and its authors, as well as a skimpy table of contents, and a free sample chapter (the fifth one, on composite photography). Lecarme has a companion website where visitors will find additional resources, including bonus filters, a forum (albeit almost empty), and a selection of the example images used in the book.

This title's 676 pages are organized into 22 chapters and six appendices. The first eight chapters compose "Part I — Learning GIMP"; the remaining chapters compose "Part II — Reference"; and the appendices compose the third part. In a brief but pleasant introduction, the authors encourage readers to follow along by installing GIMP on a local machine. Installation instructions can be found in Appendix E (which arguably should be the first appendix, to get readers started with a local installation). The book is based upon the most recent stable version of GIMP, namely 2.8, which reportedly introduced significant improvements over earlier versions.

As one might expect, the first chapter introduces the basics of the GIMP user interface, explaining how to find and open images, use the menu system in the main image dock, and perform basic editing operations, such as resizing and cropping. It also presents some essential concepts in GIMP — filters, layers, and drawing tools — and then discusses the use of a tablet in conjunction with GIMP. The next six chapters each focus on a major category of image work: photo retouching, drawing and illustration, logos and textures, composite photography, animation, and image preprocessing. The last chapter in the group covers utilizing GIMP for crafting the visual design of a website. The only problem I found in the narrative is the inconsistency in terminology, primarily the references to something as a "dock" on some occasions, and other times as a "window"; also, the "multi-dialog window" (page 4) is later called the "multi-docks window" (page 18). Nonetheless, the prose is straightforward and concise; there is a lot of information contained in each section. Consequently, anyone reading these tutorial chapters should take them at a modest pace, and frequently compare the authors' narrative and one's understanding of it with the screenshots and/or one's own results if following along (a practice I strongly recommend for this particular book, so one will better internalize the broad ideas as well as the details).

Each chapter concludes with a set of exercises, whose questions tend to be much more open-ended and difficult than those normally found in technical books. In fact, readers may be frustrated how some of the exercises challenge one to perform task completely unmentioned in the corresponding chapter. For instance, the very first one in the book, Exercise 1.1 (page 24), asks the reader to build a new dock with dialogs, even though at no point in the chapter was the reader told how to do anything remotely like this. Appendix B contains tips for a minority of the exercises.

The bulk of the book, "Part II — Reference," offers almost 400 pages of details on every aspect of GIMP: the user interface, its displays, layers, colors, selections, masks, drawing tools, transformation tools, filters, animation tools, scanning and printing images, image formats, scripts and plug-ins, and other methods of customizing the application — with each chapter starting with the basics. All of the information is terrific, but the thoughtful reader may wonder why the book begins with advanced topics — such as photo retouching, composite photography, animation, and website design — and later presents the detailed explanations of all the aforementioned aspects of using GIMP. It seems to me that it would have been better to present the Part II chapters first, and then present the advanced topics currently in Part I, except for what is now Chapter 1 ("Getting Started"), which would still be a fine way to begin the explication.

The third and final part contains half a dozen appendices, the first of which is a fascinating exploration of the science of human vision and the three main models of digital color representation. As noted earlier, the second appendix contains tips and hints for some of the chapter exercises. The third appendix is brief, but contains a wealth of online resources for anyone who would like to learn more about GIMP and its community. The next appendix contains a list of frequently asked questions and their answers, and is well worth reading. The fifth chapter explains how to install GIMP on computers running GNU/Linux, Unix, various Linux distros, Windows, and Mac OS X. The final appendix addresses batch processing of images, including the use of ImageMagick.

The production quality of this book is excellent (judging by the print copy kindly provided to me by No Starch Press for review). It was a smart choice on the part of the authors to request full-color images on every page, and the publisher's decision to do so, given the book's visual subject — even though it resulted in a heavier product (3.4 pounds).

Naturally, as a book discussing an image editor, this one makes extensive use of example photos and other images, which are extremely helpful to the reader. Only a few problems were evident; for instance, Figures 1.24 and 1.25 are so small that the cropping pointers are almost invisible. In some cases the descriptions or screenshots do not match what I saw when following along; for instance, on page 3, the author states that the three startup windows (Toolbox, Image, and multi-dialog) by default occupy the full width of the screen, which contradicts the screenshot in Figure 1.1, which shows the Image window at partial width.

The writing is generally clear and easy to follow, even though some of the phrasing is odd (e.g., "source text" to mean "source code"), perhaps because both authors are French. That could also account for the errata — for instance, "on [the] left" (page 15) and "its there" (page 22) — of which there were remarkably few for a book of this length.

If any reader is looking for a free and full-featured image-editing program, then by all means consider GIMP, as well as this outstanding tutorial and reference book.

Michael J. Ross is a freelance web developer and writer.

You can purchase The Book of GIMP: A Complete Guide to Nearly Everything from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

brothke writes "In the classic poem Inferno, Dante passes through the gates of Hell, which has the inscription abandon all hope, ye who enter here above the entrance. After reading The Tangled Web: A Guide to Securing Modern Web Applications, one gets the feeling the writing secure web code is akin to Dante's experience." Read below for Ben's review. The Tangled Web: A Guide to Securing Modern Web Applications author Michal Zalewski pages 320 publisher No Starch Press rating 10/10 reviewer Ben Rothke ISBN 1593273886 summary Incredibly good and highly technical book on browser security coding In this incredibly good and highly technical book, author Michal Zalewski writes that modern web applications are built on a tangled mesh of technologies that have been developed over time and then haphazardly pieced together. Every piece of the web application stack, from HTTP requests to browser-side scripts, comes with important yet subtle security consequences. In the book, Zalewski dissects those subtle security consequences to show what their dangers are, and how developers can take it to heart and write secure code for browsers.

The Tangled Web: A Guide to Securing Modern Web Applications is written in the same style as Zalewski's last book - Silence on the Wire: A Field Guide to Passive Reconnaissance and Indirect Attacks, which is another highly technical and dense book on the topic. This book tackles the issues surrounding insecure web browsers. Since the browser is the portal of choice for so many users; its inherent secure flaws leaves the user at a significant risk. The book details what developers can do to mitigate those risks.

This book starts out with the observation that while the field of information security seems to be a mature and well-defined discipline, there is not even a rudimentary usable framework for understanding and assessing the security of modern software.

In chapter 1, the book provides a brief overview of the development of the web and how so many security issues have cropped in. Zalewski writes that perhaps the most striking and nontechnical property of web browsers is that most people who use them are overwhelmingly unskilled. And given the fact that most users simply do not know enough to use the web in a safe manner, which leads to the predicament we are in now.

Zalewski then spends the remainder of the book detailing specific problems, how they are exploited, and details the manner in which they can be fixed.

In chapter 2, the book details that something as elementary as how the resolution of relative URL's is done isn't a trivial exercise. The book details how misunderstandings occur between application level URL filters and the browser when handling these types of relative references can lead to security problems.

For those that want a feel for the book, chapter 3 on the topic of HTTP is available here.

Chapter 4 deals with HTML and the book notes that HTML is the subject of a fascinating conceptual struggle with a clash between the ideology and the reality of the on-line world. Tim Berners-Lee had the vision of a semantic web;namely a common framework that allows data to be shared and reused across applications, companies and the entire web. The notion though of a semantic web has not really caught on.

Chapter 4 continues with a detailed overview of how to understand HTML parser behavior. The author writes that HTML parsers will second-guess the intent of the page developer which can leads to security problems.

In chapter 12, the book deals with third-party cookies and notes that since their inception, HTTP cookies have been misunderstood as the tool that enables online advertisers to violate users privacy. Zalewski observes that the public's fixation on cookies is deeply misguided. He writes there is no doubt that some sites use cookies as a mechanism for malicious use. But that there is nothing that makes it uniquely suited for this task, as there are many other equivalent ways to sore unique identifiers on visitor's computes, such as cache-based tags.

Chapter 14 details the issue of rogue scripts and how to manage them. In the chapter, the author goes slightly off-topic and asks the question if the current model of web scripting is fundamentally incompatible with the way human beings works. Which leads to the question of it if is possible for a script to consistently outsmart victims simply due to the inherent limits of human cognition.

Part 3 of the book takes up the last 35 pages and is a glimpse of things to come. Zalewski optimistically writes that many of the battles being fought in today's browser war is around security, which is a good thing for everyone.

Chapter 16 deals with new and upcoming security features of browsers and details many compelling security features such as security model extension frameworks and security model restriction frameworks.

The chapter deals with one of the more powerful frameworks is the Content Security Policy (CSP) from Mozilla. CSP is meant to fix a large class of web application vulnerabilities, including cross site scripting, cross site request forgery and more. The book notes that as powerful as CSP is, one of its main problems is not a security one, in that it requires a webmaster to move all incline scripts on a web page to a separately requested document. Given that many web pages have hundreds of short scripts; this can be an overwhelmingly onerous task.

The chapter concludes with other developments such as in-browser HTML sanitizers, XSS filtering and more.

Each chapter also concludes with a security engineering cheat sheetthat details the core themes of the chapter.

For anyone involved in programming web pages, The Tangled Web: A Guide to Securing Modern Web Applications should be considered required reading to ensure they write secure web code. The book takes a deep look at the core problems with various web protocols, and offers effective methods in which to mitigate those vulnerabilities.

Michal Zalewski brings his extremely deep technical understanding to the book and combines it with a most readable style. The book is an invaluable resource and provides a significant amount of information needed to write secure code for browsers. There is a huge amount of really good advice in this book, and for those that are building web applications, this is a book they should read.

Ben Rothke is the author of Computer Security: 20 Things Every Employee Should Know.

You can purchase The Tangled Web: A Guide to Securing Modern Web Applications from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Michael J. Ross writes "Web developers familiar with a particular programming language, such as PHP, typically turn to books and forums for assistance only when they confront a specific problem that they believe has probably been encountered by many of their peers in the past, and who have published their answers in print or online. Hence the growing popularity of programming "cookbooks", which eschew flowing narratives in favor of self-contained problem descriptions and solutions. One example of a book that combines both styles is Wicked Cool PHP: Real-World Scripts That Solve Difficult Problems, by William Steinmetz with Brian Ward." Keep reading below for the rest of Michael's review. Wicked Cool PHP: Real-World Scripts That Solve Difficult Problems author William Steinmetz with Brian Ward pages 224 publisher No Starch Press rating 5/10 reviewer Michael J. Ross ISBN 978-1593271732 summary Yet another PHP book that presents a variety of topics through sample code. Published by No Starch Press on 9 February 2008, under the ISBNs 1593271735 and 978-1593271732, Wicked Cool PHP aims to provide the reader with a wide-ranging collection of complete PHP scripts and code fragments that solve specific problems frequently encountered by PHP coders. It is not intended for explaining the fundamentals of PHP, but assumes that the reader already understands the basics of the language. The book covers PHP versions 5 and 6. On the book's Web page, visitors can purchase it online, download a sample chapter (Chapter 4: Working with Forms), and download most of the sample code.

The book's material is organized into a dozen chapters, covering a range of topic areas: some simple scripts; configuring PHP; PHP security; forms; text and HTML; dates; files; user and session tracking; e-mail; images; using cURL to interact with Web services; and three intermediate projects. A brief appendix shows the MySQL commands for creating the product_info table used in many of the book's scripts. The book's back cover claims that it offers 76 scripts, but at least one section (#69) does not contain a script.

The first chapter is titled "The FAQs of Life — The Scripts Every PHP Programmer Wants (or Needs) to Know." That's quite a claim, unfulfilled by the chapter's material, which covers only seven narrow topics, such as how to include another file in a script (require_once) and how to print an array (print_r). Furthermore, there is no common theme for the scripts chosen, aside from their addressing questions that one of the authors — who is not identified — sees repeatedly in PHP forums and discussion groups. Some are extremely basic (e.g., print_r), while others address topics that are far more advanced and deserving lengthier treatment (e.g. templating your site with Smarty). That last topic would have been much better presented as an intermediate project in the book's final chapter.

Configuring PHP is an area that can prove perilous for programmers who are new to the language, and are, for whatever reason, having difficulty setting up PHP on their home Web server. For such individuals, Chapter 2 should prove quite useful, because it offers a clear overview of how they can configure their own PHP installations to match their needs. Some of the configuration advice could be a lifesaver, depending upon the reader's circumstances — such as the information on using open_basedir to limit directory access to PHP (and energetic hackers).

However, on page 20, when the authors provide advice on how the reader can find the php.ini file, they suggest that Windows users should look in "C:\php." Actually, the default installation file path is "C:\Program Files\PHP" (unless the reader has altered the value of ProgramFilesDir in the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion key in their Windows Registry). They urge the reader to delete any phpinfo() script, for security reasons. But having such a script on a remote server could be quite valuable to the reader, at some point in the future; so it would be wiser to simply rename it, assuming that the reader has not allowed hackers to list file names on his or her Web server.

Several times in the book the authors advise the reader to set the error_reporting configuration option off for production servers — as well as for development servers lacking firewalls — so hackers and others do not see system information contained in error messages. But error_reporting is best used for specifying the level of error reporting, while the display_errors configuration option is best used for disabling the display of those errors to the site visitor. Errors should still be recorded in the Apache error log, so the developer can better diagnose what happened on a production site.

As with most first editions, this one contains several errata: "phpinfo()can" (page 21), "data to encrypted" (page 42), "six years" (page 55; should be 10 years, to match the code), and "timestamp() function" (page 82; should be "time() function").

In any book, a sizable number of minor flaws will prompt the careful reader to begin questioning the editing of the book. This is especially true when encountered in the first paragraph of the first page of the Introduction: "stumbled on to," which should instead be two words. But it goes beyond just issues of line editing — to a question of judgment. That very first page also contains "After you calm down," which is too flippant for what should be a professional work, as are other instances: "living hell" (page 4), "hash-ish" (page 40), and "Mac users... [like] to buy expensive gadgets for the sole purpose of looking stylish" (page 113). The authors frequently use the term "I" without specifying which author is being referred to; presumably it is the first author listed. On page 64, they state that they had previously mentioned the === operator, but I cannot find it anywhere, and neither could whoever created the book's index.

In the sample code, the authors use double quotation marks — instead of single ones — for most of the strings, few of which contain variables. This slows down the PHP interpreter by forcing it to check for variables within the strings, to be interpolated. Moreover, they are not consistent in the usage — occasionally switching over to single quotes instead, for no apparent reason. The same is true of in-line comments, which switch back and forth between Java and C styles.

The code in general is not entirely consistent throughout the book, e.g., using print() in most cases, but echo() in the remaining ones, with no explanation as to why. Perhaps this is the result of having two authors. Most HTML tag names are in lowercase, but a couple are in uppercase.

Some of the book's code appears invalid. For instance, on page 5, one of the statements (abbreviated here), echo "$row[product_name]," generates two errors: "unexpected T_ENCAPSED_AND_WHITESPACE" and "Use of undefined constant key — assumed 'product_name'." The correct code would be: echo "{$row[ 'product_name' ]}." On page 41, $cipher is set to the string "MCRYPT_SERPENT_256," which generates an error, and probably instead should be set to the constant MCRYPT_SERPENT, which works fine. $mode is set to the string "MCRYPT_MODE_CBC," but that should be a constant as well. On page 72, the regex pattern for matching HTML anchor tags does not match an entire opening tag, but just a portion of it. In the downloadable code for section #68, getpage.php fails because "<?" should be "<?php." Readers shouldn't have to debug a book's code just to get it to run without error. Did no one test the sample code before publication?! In the code for section #71, mapdemo.php generates index errors when run without any GET parameters, and does not generate a map when values are entered in the form.

Some of the code may work in certain circumstances, but not in others. For example, on page 70, the pipe character (|) is recommended as a substitute for the forward slash (/) for regex patterns containing many such slashes. But the pipe character is a very poor choice, because it has a special meaning in regex patterns, namely, as the 'or' operator, and thus cannot be used for any pattern that needs to use that operator. In section #49, calculate_time_difference() fails if one or both of the timestamps is the epoch time (time zero). In section #61, get_ip() assumes that two $_SERVER keys are set, and fails when they are not.

Some of the code works but can give beginners the wrong impression. For instance, on page 25, the authors present a configuration setting (incorrectly referred to as an "extension"): ini_set(max_execution_time, "240"). But max_execution_time is not placed in quotation marks. Even though this does not cause an error, a newbie may do the same with ini_get(), and become confused as to why PHP then (rightly) complains. (One could argue that PHP should also flag the ini_set() call as erroneous.) Section #50 could mislead newbie programmers into using that multi-line script instead of PHP's file_get_contents(). Section #51 similarly re-creates the wheel, namely, file_put_contents().

Lastly, some of the code, comments, and variable naming choices are quite puzzling. For instance, in section #30, validate_cc_number defines a variable as $false = false, but this "variable" never gets changed in the rest of the script. That is what constants are for. In the downloadable time difference scripts for Chapter 6, we find "print abs(5 — 62);" with no apparent purpose. In timediff.php, calculate_time_difference() checks for divide by zero errors for a variable that is never used as a denominator.

Unlike most computer programming books, this one has no acknowledgments of any technical reviewers. Given all of the problems in the code, it is possible that there actually were no technical reviewers, though it is difficult to imagine any reason why a publisher would choose that unwise route.

In terms of formatting of the material in the book, most of the left-hand pages (the even-numbered ones) have the page contents shifted too far to the right, almost running into the crease of the book, and leaving a glaring amount of wasted whitespace in the left-hand margin. The only exceptions are on pages 163, 164, and 172, where portions of code awkwardly jut out into the left margin.

The downloadable code archive is quite flawed, and a fair amount of the code needs to be cleaned up. For example, getpage.php contains a lot of redundant code. Much of the sample code in the book is not included in the archive; incredibly, this includes some of the largest scripts, such as the Smarty code in Chapter 1 and the credit card processing code in Chapter 4. In fact, the archive is missing the code for two entire chapters (2 and 3). Oddly enough, at least a couple scripts in the archive are not mentioned in the book. The archive needs a complete overhaul, including the cleanup or elimination of seemingly leftover scripts such as foo.php (three instances) and captcha_old.php.

On the positive side of the ledger, the book contains information that would be of interest to all levels of PHP programmers. For instance, readers who are just barely familiar with the language will benefit from the discussions concerning superglobals, form input security, date and file manipulation, and how to save user information with sessions and cookies. More advanced developers may profit from the discussions on encryption, PHPMailer, captchas, Web services, and other topics generally found later in the book.

In addition, many of the sections include a special subsection titled "What Can Go Wrong?," in which the authors consider potential problems with the code or overall approach presented in that section. Undoubtedly other technical books provide such information, interwoven with the main narrative; but explicitly identifying potential pitfalls is a worthy practice — one that we can only hope to see in other programming books in the future.

At 224 pages, it is a relatively slim volume, but contains a fair amount of useful information relative to its size — a pithiness welcome in the world of computer books. (Fortunately, the trend in the technical publishing world has shifted away from tomes sometimes exceeding 1000 pages that are padded with poorly-edited material shoveled in by multiple authors.)

Yet all in all, Wicked Cool PHP is largely disappointing. It contains no PHP scripts that could be considered "wicked cool." Moreover, the aforementioned code problems clearly call for an improved second edition, including a complete revision of the downloadable code archive. On the other hand, Wicked Cool PHP touches upon a number of key topics in PHP programming, with minimal fluff, and gets right to the point.

Michael J. Ross is a Web developer, writer, and freelance editor.

You can purchase Wicked Cool PHP: Real-World Scripts That Solve Difficult Problems from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

David Martinjak writes "Linux Firewalls, authored by Michael Rash and published by No Starch Press, covers five main topics: traditional packet filtering with iptables, port scan detection, snort rule translation, port knocking, and log visualization. At first I considered only skimming the chapters regarding iptables packet filtering. I have a good amount of experience with iptables, and have been running it for several years. Thankfully I decided to give the first chapter a good read. Right from the start, the book presented valuable information and pulled me in." Read on for the rest of David's review. Linux Firewalls author Michael Rash pages 336 publisher No Starch Press rating 9 reviewer David Martinjak ISBN 1-59327-141-7 summary Linux Firewalls discusses the technical details of the iptables firewall and the Netfilter framework that are built into the Linux kernel. The chapters about iptables packet filtering are crucial for any reader new to networking or firewall administration. Experienced users might pick up a tip or two, as well. Linux Firewalls contained a wealth of knowledge about packet structure in addition to a solid explanation of iptables usage. I was rather impressed by the variety of information presented in the early chapters. The book of course detailed the syntax and logistics of iptables, but also provided detailed examples of attacks at the network, transport, and application layers.

Packet filtering was followed by port scan detection. When I first started using GNU/Linux, one application in my toolbox was PortSentry. PortSentry was designed to counter-act port scans, and minimized the amount of information that could be discovered from a scan. I lost track of PortSentry for some reason, but was glad to have almost re-discovered it in a new form. PSAD is the Port Scan Attack Detector and was developed by the book's author, Michael Rash, along with contributions from the open source community.

PSAD was created as a lightweight network intrusion detection component. The book explained how PSAD can quickly react to port scans by analyzing iptables log entries; and effectively reduce the surface area exposed to the attacker. The differences between PSAD and PortSentry were also enumerated, which showed several advantages for using PSAD.

Linux Firewalls did a fantastic job of detailing how to install and configure PSAD. This seems to be par for the course with No Starch Press as each book I have read from them was meticulous with regards to installation and configuration specifics. Additionally, the topics of installing and configuring the book's other two main applications, fwsnort and fwknop, were also properly addressed.

I don't want to give away too much of the material in Linux Firewalls; so I will just say that the chapters on fwsnort, fwknop, and log visualization were all on par with the earlier sections of the book. The information did not let up at any point — there were useful examples and details throughout each chapter. Additionally, there was a good amount of consistency with regard to how the chapters progressed, and the type of information that was presented along the way. All together, Linux Firewalls was an impressive read.

There were no real disappointments with this book. The reading did get a bit tedious at times with regard to configuration specifics, but it was only due to the depth of helpful explanation. Had I been working with the applications while reading (instead of just reading), the content would have been much more relevant. In the end, however, the variety resulted in a rather impressive and enjoyable book. The coverage of psad, fwsnort, and fwknop were welcomed additions. Each of the central topics were thoroughly explained in an informative, yet engaging manner. Essentially, I did not want to stop reading.

The netfilter/iptables software is licensed under the GNU General Public License, and can be found at http://netfilter.org. The psad, fwsnort, and fwknop applications are licensed under the GNU General Public License Version 2, and can be downloaded from http://cipherdyne.org.

The publisher hosts a Web page which contains an online copy of the table of contents, portions of reviews, links to purchase the electronic and print versions of the book, and a sample chapter ("Chapter 10: Deploying fwsnort") in PDF format.

David Martinjak is a programmer, GNU/Linux addict, and the director of 2600 in Cincinnati, Ohio. He can be reached at david.martinjak@gmail.com.

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

s1axter writes "A week and a half ago I received Linux Appliance Design by Bob Smith, John Hardin, Graham Phillips and Bill Pierce, published by No Starch Press. This is one of No Starch's latest titles and was released in the beginning of April. As a hardware/embedded systems guy I was really eager to get my hands on the book. For those who don't know what the book is about, it's about making an application specific utility, an electronic tool or "appliance" that can be used for a specific task. The book defines an appliance as "A device designed to primarily perform a single function" and that's exactly what they do." Read on for the rest of S1axter's review. Linux Appliance Design author Bob Smith, John Hardin, Graham Phillips and Bill Pierce pages 344 publisher No Starch Press rating 9 reviewer s1axter ISBN 1-59327-140-9 summary A text on developing an application specific device, very informative

The book revolves around Laddie, an example alarm system for a building. The book includes a complete explanation of the system, what design features it uses, and a LiveCD with the final application for your hacking pleasure.

I have to say, Linux Appliance Design is well written and very, very thorough. This is not a beginner text, the authors focus on Linux programmers who understand C and Linux systems and want to take it a step further than conventional software. If you think this is a book for you, you should be a C/Linux guru, or dust off those old textbooks and brush up on your stuff before you pick it up.

When a friend asked me what was in the book I gave him the response, "Everything you need to make a sweet daemon with any interface you want". This is exactly what Linux Appliance Design is, a library in a book. Nostarch.com has a chapter list for the text, so you can see what I mean.

The layout for the text is well organized and starts where every project should, architecture and design. Personally I felt the authors were beating the dead horse after a couple of pages when everything kept coming back to separating interface from implementation, but hey, it's an important point that a lot of people seem to miss.

An interesting chapter is the explanation of the Run-time-access library the authors developed. Modeled from PostgreSQL, the RTA lib is an impressive solution that allows for daemon communication and configuration from any language that can talk to a database. This library is released under the GPL and can be downloaded from the companion site of the book The RTA is also used for the rest of the book, so don't skip it or you'll have no idea what they are talking about.

The text is not only an explanation of the Laddie system using the RTA, it is an all encompassing design text, which I really like. There are chapters dedicated to building different frontend UIs for the system and communication protocol discussion. This is what transforms the text from book into library. Each chapter can almost stand on its own as an application of that language or program. I was quite impressed with the web interface chapter and how the authors compared web servers and designed a system, and also with the framebuffer chapter on how to make a cool graphical interface.

A common theme for all the chapters is the structure. The authors discuss and design each element they use in the system before looking at one program or daemon. For anyone who has written or read development reports the format is very similar; explain what you designed, why you chose those components, why you passed on others, how the systems works and finally what you would do different next time. This format kind of reminded me lab reports in school, cover all question you think your professor audience might ask.

Overall Linux Appliance Design is a well written, detailed and thorough book with a lot of information. I would recommend this title mainly to someone who is interested in daemon development or server design however it can be read by anyone who wants to see a full project develop cycle.

s1axter is the main poster for Geeksinside.com. Geeksinside.com is a DIY, hardware hacking, technology blog that showcases links, reviews and project

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

David Martinjak writes "Nagios is an open source application for monitoring hosts, services, and conditions over a network. Availability of daemons and services can be tested, and specific statistics can be checked by Nagios to provide system and network administrators with vital information to help sustain uptime and prevent outages. Nagios: System and Network Monitoring is for everyone who has a network to run." Read on for the rest of the review. Nagios: System and Network Monitoring author Wolfgang Barth pages 464 publisher No Starch Press rating 9 reviewer David Martinjak ISBN 1593270704 summary Covers installing, configuring, and deploying Nagios to monitor systems and services on a network.

The book is authored by Wolfgang Barth and published by No Starch Press. The publisher hosts a Web page which contains an online copy of the table of contents, portions of reviews, links to purchase the electronic and print versions of the book, and a sample chapter ("Chapter 7: Testing Local Resources") in PDF format.

An amusing note to begin: this is one of the only books I have read where the introduction was actually worth reading closely. Many books seem to talk about background or history of the subject without providing much pertinent information, if any at all. In Nagios: System and Network Monitoring, Wolfgang Barth begins with a hypothetical anecdote to illustrate the usefulness of Nagios. The most important section in the introduction, however, is the explanation of states in Nagios. While monitoring a resource, Nagios will return of one of four states. OK indicates nominal status, WARNING shows a potentially problematic circumstance, CRITICAL signifies an emergency situation, and UNKNOWN usually means there is an operating error with Nagios or the corresponding plugin. The definitions for each of these states are determined by the person or team who administers Nagios so that relevant thresholds can be set for the WARNING and CRITICAL status levels.

The first chapter walks the reader through installing Nagios to the filesystem. All steps are shown, which proves to be very helpful if you are unfamiliar with unpacking archives or compiling from source. Users who are either new to Linux, or cannot install Nagios through a package manager, will appreciate the verbosity offered here. Fortunately, the level of detail is consistent through the book.

Chapter 2 explains the configuration structure of Nagios to the reader. This chapter may contain the most important material in the book as understanding the layout of Nagios is essential to a successful deployment in any environment. The book moves right into enumerating the uses and purposes of the config files, objects, groupings, and templates. All of this information is valuable and presented in a descriptive manner to help the reader set up a properly configured installation of Nagios. My biggest stumbling block in using Nagios was wrapping my brain around the relationships of the config files and objects. This chapter clears up all of the ambiguities I remember having to work out for myself. If only this book had been around a few years ago!

The sixth chapter dives into the details of plugins that are available for monitoring network services. This chapter explains using the check_icmp plugin to ping both a host and a specific service for verifying reachability. Additional examples include monitoring mail servers, LDAP, web servers, and DNS among others. There is even a section for testing TCP and UDP ports.

Next, the book covers checking the status of local resources on systems. At work, we have a system in production that could have been partitioned better. Unfortunately, /var is a bit smaller than it should be, and tends to fill up relatively frequently. Thankfully, Nagios can trigger a warning when there is a low amount of free space left on the partition. From there, we have Nagios execute a script that cleans out certain items in /var so we don't have to bother with it. We can also receive notification if the situation does not improve, and requires further attention. In addition to monitoring hard drive usage, the book includes examples for checking swap utilization, system load, number of logged-in users, and even Nagios itself.

Chapter 12 discusses the notification system in Nagios. You provide who, what, when, where, and how in the configs, and Nagios does the rest. The book does a fantastic job of explaining what exactly triggers a notification, and how to efficiently configure Nagios to ensure the proper parties are being informed of relevant issues at reasonable intervals. For example, the server team might be interested to know that /var is 90% full on one of the LDAP servers; however they don't need to be notified of this every thirty seconds. This chapter also covers an important aspect of Nagios known as flapping. Flapping occurs when a monitored resource quickly alternates between states. Nagios can be configured for a certain tolerance against rapid alternating changes in states. This means Nagios won't sound the alarm if the problem will resolve itself in a short period of time. Usually flapping is caused by an external factor temporarily influencing the results of the test from Nagios; and therefore has no long-term impact.

The last major chapter to mention here deals with essentially anything and everything about the Nagios Web interface. The main point of interaction between the administrator and Nagios is the fully featured Web interface. This chapter covers recognizing and working on problems, planning downtimes, making configuration changes, and more. I especially like that the book gives an overview of each of the individual CGI programs that the Web interface is composed of; as these files are important for UI customization.

The only aspect of this book that I did not care for was that the book reads like a reference manual at times. The first several chapters start out more conversational in tone with great explanations of the procedures and files; but later it sometimes feels like I am repeatedly reading an iterated piece-by-piece structure, filled in with the content for that chapter. That is not necessarily bad all together as it does provide consistency in the presentation of the information. Additionally, the level of detail is outstanding throughout the book. The explanations are never too short or too long. This is definitely a valuable book for administrators at all levels with fantastic breadth and depth of material. Administrators who are interested in proactive management of their systems and networks should be pleased with Nagios: System and Network Monitoring.

Nagios is licensed under the GNU General Public License Version 2, and can be downloaded from http://nagios.org.

David Martinjak is a programmer, GNU/Linux addict, and the director of 2600 in Cincinnati, Ohio. He can be reached at david.martinjak@gmail.com.

You can purchase Nagios: System and Network Monitoring from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Paul S. R. Chisholm writes "Inside the Machine: An Illustrated Introduction to Microprocessors and Computer Architecture, written by Ars Technica's Jon "Hannibal" Stokes, talks about how CPUs work, and how they've evolved and advanced in the past fifteen years. The result is detailed, very up-to-date (including descriptions of Intel's Core 2), generally clear, and covers a lot of fascinating material." Read below for Paul's review. Inside the Machine: An Illustrated Introduction to Microprocessors and Computer Architecture author Jon Stokes pages 320 publisher No Starch Press rating 8 reviewer Paul S. R. Chisholm ISBN 1593271042 summary A detailed look at how CPUs work, and how they've evolved and advanced in the past fifteen years

How on earth have CPUs advanced as fast as they have? How have we gone from 60 MHz Pentiums in 1993 to 3.73 GHz Xeons (with two cores) and 2.66 GHz Core 2 Extremes (with four!) today? Sure, Moore's Law and competition pushed the chip makers, but how did they implement all that extra performance? In Inside the Machine, Jon "Hannibal" Stokes provides a thorough, exhaustive, nearly exhausting look at what's at the heart of your computer. If Stoke's name sounds familiar, he's a founder and long-time contributor to Ars Technica. Anyone who liked his work there, his comprehensive articles and brightly colored diagrams, will probably enjoy this book a lot.

The first two chapters cover the basics of CPU operation and machine language. These are pretty good, though you'll probably need some assembler language experience to really understand everything in these chapters. Even without such experience, you'll pick up enough to get through the rest of the book.

The next two chapters get more advanced, covering pipelined and superscalar execution. CPUs don't execute one instruction at a time. Instead, they break instructions into smaller operations, and work on those smaller operations in parallel. These two chapters begin to tell how CPUs do that. (The book also discusses caching, another huge performance booster. For some reason, Stokes doesn't get to that until chapter 11.)

The rest of the book discusses specific CPUs. From Intel, we see the original Pentium, Pentium Pro, Pentium 4, Pentium M, Core, and Core 2. (Intel didn't release as much information about the Pentium II and III.) From the Apple/IBM/Motorola alliance, we learn about the 601 (the heart of Apple's first "Power Mac"), 603, 604, 750 (G3), 7400 (G4), and 970 (G5). In the middle of all that, there's also an excellent description of 64-bit computing, its advantages, and even its disadvantages.

Every buzzword you've ever heard about CPUs is covered: front end vs. back end, branch prediction, out-of-order execution, pipeline stalls, SIMD, direct-mapped vs. N-way set associative mapping. That sounds intimidating, but Stokes introduces the concepts one at a time, clearly and in detail. The next time an overclocking fanatic tries to tell you why his AMD CPU is so much better than your Intel CPU (or vice versa), you'll not only be able to follow the whole discussion, you'll be able to argue back.

Stokes turns all this into a (highly technical) history of CPU development. One chip's virtue is its successor's vice; one generation's shortcoming is another's opportunity.

This book reinforced something I already knew but don't often enough live by: Portability depends on architecture (for example, x86 vs. PowerPC), but high performance depends on microarchitecture (for example, Pentium M vs. Athlon 64 X2). Today's Core 2 chips have many high performance features missing from the 1993 original Pentiums. A good compiler like gcc can take advantage of those additional features. This is bad news if you're using a binary Linux distribution, compiled to a lowest common denominator. It's good news if you're building and installing Linux from source, with something like Linux From Scratch or Gentoo/Portage. It's also good news for just-in-time compilers (think Java, .NET, and Mono); they're compiling on the "target" machine, so they can generate code tailored for the machine's exact microarchitecture.

The full color diagrams were a big help in understanding Stokes's points. On the other hand, I'm not sure why the book was printed in hardcover. To make it look more like a textbook? Is that a good thing?

The text is packed with jargon, buzzwords, and TLAs (Three Letter Abbreviations). Most of that is unavoidable, but a glossary would have been nice. Each chapter builds on the previous ones, so most readers will want to read all the chapters in order, paying close attention the whole time. Even so, this book had a lot more forward references ("I'll define that shortly" or "We'll get to that later") than most technical books.

Don't expect much non-technical discussion. Exceptions: There is a very good description of the Pentium 4's obsession with higher and higher clock speeds, including marketing pressures, and the resulting performance increases and drawbacks. The occasional "Historical Context" sections are also quite nice. But you'll see nothing on Apple's decision to move from PowerPC to Core, or the competitive battle between AMD and Intel. For that matter, you'll see almost nothing at all about AMD or its products.

Personally, I think Stokes missed an important opportunity to talk in depth about multiprocessing. He spends only four pages on the subject, and that only as part the description of the Core Duo. You'd think there was never a multi-core G5. There's only a couple of paragraphs on the difference between multiple CPUs and multiple CPU cores. ("Dual dual-cores" and the AMD 4x4, anyone?) He declines to discuss how caches interact with multiple CPUs or multiple cores. That's unfortunate, because anyone doing multi-threaded software development really needs to understand cache issues, at just about exactly the level this book covers. But you'll find nothing here about cache coherency, or about what out-of-order execution results might be visible only to multi-threaded software.

Jon Stokes had an incredibly ambitious goal: to write an accessible book that covers much of the same ground as Hennessy and Patterson's Computer Architecture and Computer Organization and Design. I don't think he achieved that, but he came pretty close.

You can visit the book's home page or the author's blog.

Paul S. R. Chisholm has been developing software for 25 years. He's worked at AT&T Bell Laboratories, Ascend Communications / Lucent Technologies, Cisco Systems, and some small startups you've never heard of. His latest article, "'Pure Virtual Function Called': An Explanation," appeared in The C++ Source. He lives and works in New Jersey.

You can purchase Inside the Machine: An Illustrated Introduction to Microprocessors and Computer Architecture from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Michael J. Ross writes "Developers of Web sites, whether professional programmers or Web hobbyists, are oftentimes impressed by the more advanced functionality that can be achieved on a Web page using JavaScript. Yet these personal discoveries of JavaScript's power do not always motivate the developers to implement similar functionality on their own sites — partly because most of those custom-built JavaScript functions are cryptic, and make no attempt to show how the developer would customize the code for their own use. The majority of JavaScript books are of limited help in this regard, because they focus on the language details, illustrated only with code snippets. Many readers would benefit more from instruction via working examples, which is the approach used by The Book of JavaScript." Read the rest of Michael's review. The Book of JavaScript author David Thau pages 528 publisher No Starch Press rating 8 reviewer Michael J. Ross ISBN 1886411360 summary A guide for beginners to learn JavaScript via examples

The book was written by David Thau, a.k.a. "thau!," a veteran of the Internet and computer programming — especially JavaScript, which he has taught to countless other programmers, through this book, as well as numerous courses, conference presentations, and the tutorials he has written for Webmonkey.

Published by No Starch Press, the second edition of The Book of JavaScript appeared in December 2006. The publisher maintains a Web page for the book, where visitors can find an online copy of the book's table of contents, excerpts from reader reviews, links for purchasing the paper and electronic versions of the book, a sample chapter ("Chapter 2: Using Variables and Built-In Functions to Update Your Web Pages Automatically") as a PDF file, the errata discovered by the author and readers (several reported so far), and a link to the author's companion site.

Unlike some books' companion sites, this one is worth a visit, and not just to see a working example of the tip box described in chapter 8, which is used to show how to create an array. Thau's site has links for viewing, running, and downloading all of the sample code in the book's figures. In addition, the visitor can obtain copies of the book's JavaScript libraries, for doing cookies, form validation, and plug-in detection. There are links for viewing and downloading the three sample Web sites. However, in his AntWeb site, at least as of this writing, none of the images are showing up on his homepage. Another problem, of much less importance, is the strange behavior of the "Websites" and "Freeware" options on his "Chapters" drop-down list box. Choosing either one takes the visitor to his "Websites" page, but always displays "Freeware" in the drop-down. It is hard to imagine that this behavior is intentional.

The book's material spans 528 pages, most of which is found in 18 chapters, covering a variety of topics: an overview of JavaScript's capabilities, alternatives, and limitations, among other less technical issues; variables and built-in functions; browser detection and simple control flow; rollovers, events, images, and the "document" object; window manipulation and properties; creating your own JavaScript functions; Web forms; arrays and iteration; timing events; frames and image maps; handling form input and strings; cookies; dynamic HTML, CSS, and DOM; AJAX basics; XML; server-side AJAX; a sample application (an online to-do list); and debugging JavaScript and AJAX. The book also offers four appendices: answers to chapter assignments; online resources (tutorials, sample code, AJAX sites, and AJAX frameworks); a complete reference to JavaScript's objects and functions; the code for the book's two longest applications, namely, the Italian translator and the to-do list.

This second edition serves as a follow-up to the well-regarded first edition that came out seven years earlier. Both the book and the language itself have clearly withstood the test of time. There are several reasons for the popularity of that first edition: It taught the language and its capabilities largely through the use of complete JavaScript functions, each of which served as an illustrative example of not just the elements and rules of the language, but also straightforward ways of accomplishing common tasks in JavaScript. After all, looking at sample code is how most programmers prefer to learn or verify how a language works.

The book assumed no prior knowledge of JavaScript or any other computer language, on the part of the reader. This characteristic not only set it apart from the large number of other JavaScript titles published at that time, but it made the book more attractive to people new to programming in general and Web programming in particular. Such readers might also favor this book over others because of the author's approachable writing style, in which he fully explains topics in a leisurely manner, without the terseness seen in most programming language books. This is not to say that brevity in technical works is ever a mistake per se; the busy professional programmer wants to find answers as quickly as possible. But such brevity can quickly prove frustrating to non-techies, who lack the background for understanding terse explanations and for knowing where they can turn for clarification.

All of these laudable attributes of the first edition have been carried over into this latest edition. The primary change found in this second edition, is the coverage of AJAX (asynchronous JavaScript combined with XML). Even though the additional material substantially increases the length of the book, by 124 pages, the end result is still far from unwieldy — mostly due to several factors: The book's table of contents, along with the index, are detailed enough to make it relatively easy to find a particular topic in the book, assuming that it is included. The subsection listings in the table of contents, like good source code, make liberal use of whitespace for readability. In the text itself, coloring the headings and note numbers blue make them stand out.

Aside from the aforesaid problems with the book's companion site, there are a few other areas for improvement: It was noted earlier that the last appendix contains the sample code from chapters 15 and 17. The author states that these code listings were located in an appendix, rather than the chapters themselves, because they are too long. Actually, they comprise only a dozen pages, which would have been better located in the chapters where the reader expects to see them, and where they would be close at hand for referencing. The first listing is only two pages long, and definitely should be located in chapter 15. Even for the second listing, if the author is concerned about readers getting frustrated flipping through the 10 pages to find the continuation of the chapter's discussion, a simple note at the beginning of that code, as to what page the discussion is resumed, would be sufficient.

Some fundamental language elements of JavaScript are introduced fairly late in the book. For instance, it is noted above that an explanation as to how to create an array — an essential concept in just about any procedural language — is not found until the eighth chapter, on page 134. This is more than one third of the way into the book's 18 chapters. On the other hand, given that the author has chosen to present these language concepts, for the most part, only when needed and when describing the sample code, this later introduction of some key concepts might not prove much of a problem to most readers. However, this is a case in which the completeness and accuracy of the book's index, are even more critical than usual. In this regard, the book does not fail the reader, as the index appears to provide enough coverage.

The formatting of the code throughout the text is not entirely consistent, as evidenced by some open braces appearing on their own lines, thus wasting space, and in other cases on the same line as the preceding parenthesized expression, though separated by a pointlessly large number of spaces. Code level blocks are indented two or four spaces, seemingly at random. Continuation lines are indented exactly the same; they would be more clear if they had double the number of spaces as code level blocks. Of more importance to the reader attempting to figure out what code is serving what purpose, there are far too many large chunks of code lacking any comments, which are needed, since much of the code is not self-describing. In most of the functions, the only comment lines are those for hiding the JavaScript from outdated browsers — a practice that should have been phased out in this latest edition.

Any experienced programmer who needs a complete JavaScript reference book, or a book that covers all the language's elements in fine detail, would be best served by choosing a different book from this one. On the other hand, once they had secured such a book, they would likely find David Thau's contribution an enjoyable source of ideas on what can be done using JavaScript capabilities. For anyone who wishes to learn JavaScript in a practical and relaxed way, by reading clearly explained sample projects and their code, should be well pleased with The Book of JavaScript.

Michael J. Ross is a Web programmer, freelance writer, and the editor of PristinePlanet.com's free newsletter. He can be reached at www.ross.ws, hosted by SiteGround.

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

Michael J. Ross writes "Of all the popular programming languages now in use, Perl is perhaps the best suited for writing utilities — for several reasons, such as its text-processing capabilities, ease of addressing system resources, and minimal language overhead for input, output, list processing. It was designed to blend the rapid solution development of shell scripting with the powerful control constructs of third-generation languages. Consequently, Perl quickly became a favorite language for developing programs ranging from system administration utilities to CGI scripts that power Web sites. In fact, Perl has been called the glue that holds the Internet together. The tremendous flexibility and power of Perl is seen in Steve Oualline's book Wicked Cool Perl Scripts: Useful Perl Scripts That Solve Difficult Problems." Read the rest of Michael's review Wicked Cool Perl Scripts author Steve Oualline pages 336 publisher No Starch Press rating 8 reviewer Michael J. Ross ISBN 1593270623 summary 47 useful Perl scripts for Web site management or CGI, Linux or Unix system administration, managing pictures, etc.

Published by the cleverly named No Starch Press, Wicked Cool Perl Scripts comprises 336 pages, spanning 11 chapters, with a brief introduction, as well as an index. The book appeared in February 2006, and was published under the ISBN of 1593270623. No Starch Press maintains a Web page for the book, where readers can find a sample chapter (the third one, covering CGI debugging), in PDF format. There is a link for downloading all of the source code.

The book presents 47 scripts, grouped into 11 categories: general-purpose utilities, Web site management, CGI debugging, CGI programs, Internet data mining, Unix system administration, picture utilities, games and learning tools, development tools, mapping, and regular expression graphing. The scripts perform such functions as finding duplicate files on your PC, converting currencies, processing error logs, generating jokes randomly, getting stock quotes, and managing photos and other images. Some of the scripts play games, while others would be invaluable to any Linux or Unix system administrator. For readers with their own Web sites, the book offers scripts for verifying links, locating orphan files, detecting hackers, and locking them out. In addition, there is a script for counting the number of visitors to your site, and even one for presenting a guest book. Software developers will find the material valuable, as there are Perl scripts for generating code, locating dead code, and handling regular expressions — parsing and graphing them.

The scripts themselves are fairly wide ranging in complexity and size, with a few fitting on a single page of the book, while others require more than ten pages. Fortunately, the scripts generally contain enough comments to be clear in how they work to any programmer comfortable with the language. Nonetheless, the author explains how to run each script, what sort of results the reader should see, how the script works, and what modifications one might want to make to it ("hacking the script"). In addition, every one of the scripts contains a POD (Plain Old Documentation) section, though only in the downloadable version — not the version seen in the book, to save space.

It is doubtful that any beginning Perl programmer might mistake this book for a Perl primer or reference. The title alone makes clear that the focus is on the offered scripts themselves, and their ability to help the reader solve common problems. On the other hand, Perl programmers of any level of fluency with the language would benefit from reading through the scripts, as well as the author's explanation of how they address and solve each problem. I myself have been programming in Perl for ages, and yet I spotted CPAN modules that I can use in my own Perl scripts in the future.

The value of the scripts themselves to each individual reader, naturally depends upon what sort of tasks the reader would like to accomplish with Perl. The 11 categories of scripts are varied enough so as likely to be of use to just about anyone who would like to use the "Swiss Army knife of languages" for getting the job done on their computer, or that of their employer (as a system administrator). Personally I found most useful the scripts for detecting changed files, scanning Web sites for dead links, and parsing regular expressions.

There are other aspects to like about this book. It has a RepKover binding, to lay flat when open. The illustrations are clear and not excessive in number. Unlike some technical authors, whose weak attempts at humor simply make their obtuse material more annoying, Oualline is more subtle, such as his reference to the cost of Microsoft Windows CDs in a Hong Kong shop, or "Ingesting a Cheerio nasally." Well, perhaps not always subtle, but invariably welcome in what could otherwise be an extremely dry subject.

Like any book, there are some areas for improvement, perhaps in future editions: In the illustrations that employ rays pointing from one node to the next, some of the curved rays are remarkably jagged, as if they were not computer-generated. Far more importantly, some of the scripts could benefit from more internal comments, as well as having the code broken up into smaller functions, which improves clarity and maintainability. Also, some of the variables and functions could use more descriptive names. For instance, using two examples from a randomly chosen page: $file_name would be more clear than $cur_file (is it the file's name, full path, or contents?). print_file_cell() would be better than do_file() (do what to the file?).

But aside from those weaknesses, Wicked Cool Perl Scripts is a fine book that would be of interest to any Perl programmer, regardless of their expertise. In fact, the administrator of a Web site or a Linux/Unix server, would not even have to know the language in order to download these Perl scripts, and use them to solve problems on the job.

Michael J. Ross is a freelance writer, computer consultant, and the editor of the free newsletter of PristinePlanet.com.

You can purchase Wicked Cool Perl Scripts 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 "When reading about the computer crimes, we are usually told the victim's point of view. We learn about the thieves stealing thousands of credit card numbers and identity theft victims, who lost their credit history with the wallet they lost at the mall. But how do criminals ever get caught? Who performs the forensic search and participates in sting operations?" Read on for Alex's review of High-Tech Crimes Revealed, which addresses these questions. High-Tech Crimes Revealed author Steven Branigan pages 448 publisher Addison-Wesley rating 9 reviewer Alex Moskalyuk ISBN 0321218736 summary Cyberwar Stories from the Digital Front Steven Branigan is a cop, a system administrator, an Internet security consultant and network security researcher. Ex-employee of Bell Labs now is a founder of a company that "specializes in solving leading edge computer and network security issues."

The book is a collection of high-tech investigations performed by Branigan in cooperation with the police force and sometimes the Feds. Generally Branigan would be involved in forensic research of the evidence and be on the scene as the "computer expert" that cops would refer to when dealing with cybercrime.

Twelve chapters take us through some of the high-tech crimes that the Western world faces today. An attack on the telephone network (unauthorized access to the switches), backdoors left at the former employer, hacking into university networks and the well-publicized identity theft are all covered in the book. Branigan brings up anecdotal evidence from his own career, describes some of his cases in great detail, and provides advice for practitioners in the forensics field.

The author is a Linux/Unix/BSD guru, and he shares his methods for retrieving telltale data from the equipment that the criminals leave behind. He also talks about the generic problems that law enforcement faces when investigating a high-tech crime - how do you obtain a warrant, what's a proper way to conduct searches, how do you work with the confiscated computer so that all the data is left intact?

However, don't expect some secrets to pop-up in regards to data collection - Branigan uses commonly available Linux tools like grep for searching the suspect's hard drive for needed data. More often that not, the investigator, it turns out, depends on his experience, not the book knowledge - one has to recognize the network sniffer log when they see it, and be capable of recognizing the tools freely downloadable from security sites.

Thus it's not surprising that there are some chapters in the book dedicated purely to the author's experience in the field. He describes working with the hackers who have been arrested, discusses how rootkits are spread around, discusses the motivation behind the network attacks (it's not always money, to say the least), describes the structure of a hacking ring and their potential revenues and also talks about ways to unravel the networks. His motto? No crime is too small, and sometimes things so little as missing the rent can lead to more discoveries and tie-ins into bigger crimes.

If you're thinking about becoming a security consultant, a law enforcement officer or just a sysadmin with better than average knowledge of security, this book is an interesting read. It's not a textbook, nor it is technical by nature. It reads more like a detective story, except the stories are real, the culprits are real and so are the victims. One can read the book on two levels - as a forensics tutorial (however, don't expect extended technical tutorials and tools overview) or as an autobiography of a cop, who had to deal with high-tech crimes all his life. If you liked Art of Deception or Hacking: The Art of Exploitation , this title would be a perfect complement.

Chapter 3, If Only He Had Paid the Rent, is available online from Addison-Wesley.

Alex enjoys reading programming, technology and business tech books in his spare time. He also keeps a list of free books available on the Internet for tech readers on a budget. You can purchase High-Tech Crimes Revealed 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.

GMan00 writes "A flurry of BSD UNIX-related (Berkeley Software Distribution) books have hit the bookstores during the recent past, and more are on the way. From books specific to Secure Architectures with OpenBSD in April 2004 and the reissue of The Design and Implementation of the BSD Operating System for FreeBSD 5.x (expected in August 2004), to Michael Lucas' series of BSD Books from NoStarch Press, print documentation is certainly available for those interested in learning about the free, open source UNIX system which powers operations such as Yahoo! portal and Sendmail.org website, Verio and Pair hosting, not to mention web server survey site Netcraft. Dru Lavigne's BSD Hacks (O'Reilly and Associates, May 2004), is the latest book in these releases, and is an enormously useful resource for system administrators and end-users alike." Read on for the rest of George's review. BSD Hacks author Dru Lavigne pages 427 publisher O'Reilly & Associates rating 10 reviewer George ISBN 0596006799 summary A great array of hacks you can perform on your BSD box, many applicable to all the BSDs, including FreeBSD, NetBSD, OpenBSD and Darwin/OS X.

Dru writes the BSD Basics column on O'Reilly & Associates' OnLamp. Her clarity and fluid style are perfect for those looking to understand aspects of the BSD operating systems. I have had some email communications with Dru about various New York City *BSD User Group-related activities, and managed to speak with her several times at BSDCan this past May.

Like most computer nerds, Dru has a sense of humor. Unlike most, however, she's actually funny.

BSD Hacks is the first book that is almost solely focused on hacks for sysadmins, without boring you with the details for basic operating system installation and configuration that has been so well documented elsewhere. BSD Hacks is not just for sysadmins, though. Intermediate and advanced BSD users will also find the book an excellent tool. For those who find difficulty in BSD installs and other fundamentals, on the other hand, it's best to start with the FreeBSD Handbook, the NetBSD Guide or the OpenBSD FAQ.

There's lots of good hacks buried in the various BSD books, around the internet in different HOWTOs and tutorials. But BSD hacking is the sole purpose of BSD Hacks; there's no need to browse through install screens and overviews of TCP/IP before getting to the heart of the matter.

With 100 listed hacks, multiplied by an impressive level of detailed angles for each, Dru provides an array that demands the placement of this book right in your server room, not in a pile of "must-read-at-some-distant-point-in-the-future" texts.

The majority of hacks are applicable to all the BSDs, including Darwin and OS X, although some are specific to one BSD or another.

This review obviously can't list every hack, although you would be smart to sit and work through the book yourself over a weekend or two. But it is possible to provide a good flavor of BSD Hacks in brief. O'Reilly and Associates does give a good glimpse on their Sample Hacks page, but let's do a quick work through ourselves.

The first chapter is called "Customizing the User Environment," and is probably best for end-users looking to go beyond their first steps. But it does include some useful hacks, such as "Use an Interactive Shell" that certainly fit well into the arsenal of any sysadmin, not to mention Hack #12 "Use Multiple Screens on One Terminal."

The second chapter, "Dealing with Files and Filesystems" also contains gems for both end-users and sysadmins. The use of mtree, which maps a directory hierarchy, is mentioned as a tool for recovery. Later on in chapter 6, Dru details its use for making a hacked data integrity checker, thus filling the role often played by products such as Tripwire.

Another great tool Dru covers in the second chapter is g4u, a free ghosting program that gives you the ability to perform quick restores over ftp. Ghosting a drive image is an incredibly useful tool, whether it's about replicating servers or doing a quick reinstall and configuration when a server fails in an emergency.

Chapter 3 is entitled "Boot and Login Environments." It gives some hacks that aren't just for basic system administration, but also some useful security ones including changing your /etc/passwd file to Blowfish encryption and utilizing OPIE for one-time passwords, which is built into FreeBSD.

"Backup Up" is the focus of Chapter 4. It includes some very creative methods of dealing with maintaining that necessity, and also includes an excellent primer on Bacula, which is increasingly gaining prominence as a cross-platform backup system.

Chapter 5 covers "Network Hacks," and continues on educating a sysadmin. Included in this chapter is the tcpdump program, a vital tool for watching traffic flowing by your network interfaces.

There's a strong security focus in Chapter 6, entitled "Securing the System." While security hacks are sprinkled generously throughout the book, this chapter works with firewalling with IPF and PF, in addition to covering SSH and Snort. It also includes the earlier mentioned 'intrusion detection-lite' approach with mtree.

Chapter 7, "Going Beyond the Basics" explores scripting, analyzing dreaded buffer overflows and more. Dru also includes a bit on "Creating a Trade Show Demo," not something you'd expect documented in print anywhere, but nevertheless quite useful for anyone working for the BSDs at a conference.

Dru continues with "Keeping Up-to-Date" in Chapter 8, which includes useful details on upgrading and downgrading your installed ports.

The final chapter is "Grokking BSD." "Grok," as Dru comments, refers to the science fiction writer Heinlein's Martian phrase for having a "thorough understanding." Dru covers creating your own manual pages, dealing with custom patches, playing with dictionaries and more.

Certainly there are no walls between each chapter, as many of the hacks could be shifted around. All the more reason to work your way through the book from beginning to end.

One useful addition for this book could have been somehow denoting which of the BSDs (in some cases, it's all of them) to which each listed hack can be applied. Certainly not all are available to Darwin and Apple's OS X. And certainly there's no point in making the OpenBSD /etc/passwd file encrypted in Blowfish, since that is its default.

While many of the hacks are found somewhere in the manual pages, on some useful website, buried in another book or in the minds of some developer somewhere, they're not necessarily in the annals of official documentation. But there's no single book or site that provides the depth and breadth that Dru provides. She managed to tap into the thoughts of dozens of developers and sysadmins around the world, greatly enhancing the variety of hacks in this book.

As a side note, the scope of BSD Hacks isn't limited to just the BSD family. Many of these are likely applicable to Linux and the other UNIX systems. But with recent, impressive increases in the BSD install base, there's a good chance that you can access a BSD box somewhere.

Whether you're a sysadmin managing hundreds of servers, or a power user ready to go beyond the obvious, BSD Hacks belongs next to your CRT.

You can purchase BSD Hacks 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.

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.

porkrind writes "No Starch Press and The USENIX Association co-sponsored a discussion on the SCO vs. IBM case at the USENIX Annual Technical Conference. Now you can listen as Chris DiBona, Don Marti, Jon "maddog" Hall, and others explain the nuances of the case. Click here for the MP3."

porkrind writes "No Starch Press and The USENIX Association co-sponsored a discussion on the SCO vs. IBM case at the USENIX Annual Technical Conference. Now you can listen as Chris DiBona, Don Marti, Jon "maddog" Hall, and others explain the nuances of the case. Click here for the MP3."

porkrind writes "No Starch Press and The USENIX Association co-sponsored a discussion on the SCO vs. IBM case at the USENIX Annual Technical Conference. Now you can listen as Chris DiBona, Don Marti, Jon "maddog" Hall, and others explain the nuances of the case. Click here for the MP3."

porkrind writes "No Starch Press has announced its latest BSD title, Absolute OpenBSD, by Michael Lucas, scheduled to be in stores in July, 2003. Lucas is known as a FreeBSD contributor and the author of Absolute BSD. You can read all about it and pre-order now direct from No Starch Press or at Amazon."

porkrind writes "No Starch Press has announced its latest BSD title, Absolute OpenBSD, by Michael Lucas, scheduled to be in stores in July, 2003. Lucas is known as a FreeBSD contributor and the author of Absolute BSD. You can read all about it and pre-order now direct from No Starch Press or at Amazon."

porkrind writes "No Starch Press has announced its latest BSD title, Absolute OpenBSD, by Michael Lucas, scheduled to be in stores in July, 2003. Lucas is known as a FreeBSD contributor and the author of Absolute BSD. You can read all about it and pre-order now direct from No Starch Press or at Amazon."

porkrind writes "No Starch Press has announced its latest BSD title, Absolute OpenBSD, by Michael Lucas, scheduled to be in stores in July, 2003. Lucas is known as a FreeBSD contributor and the author of Absolute BSD. You can read all about it and pre-order now direct from No Starch Press or at Amazon."

porkrind writes "No Starch Press has announced its latest BSD title, Absolute OpenBSD, by Michael Lucas, scheduled to be in stores in July, 2003. Lucas is known as a FreeBSD contributor and the author of Absolute BSD. You can read all about it and pre-order now direct from No Starch Press or at Amazon."

bluethundr writes "For all of the years that it has been available, the only way to read the classic instructional text known as the Art of Assembly by Randy Hyde, was to read it online or download a PDF'd copy and print it out for your own bad sef. It would seem that No Starch Press stands poised to release a pre-bound (aka BOOK) version of this most highly esteemed volumes on the arcane topic on highly convenient dead tree media. I for one am very glad about this development. While I recognize the value of hypertext for reference, when it comes to learning any complex topic at length dead tree media is the way to go, hands down IMHO! I emailed the company to get a bead on when to expect this development and this was the reply: 'No, you are not misinformed. The scheduled publication date for Art of Assembly is March, 2003. I will have something posted on the website very soon, perhaps in the next couple of days. Thanks for the interest!'"

Slashback is back, with a largish handful of updates and new information about previously run stories. Topics this go-round include Xbox sales in Australia, the Novell / MySQL connection, Adam Smith (no, not that Adam Smith)'s bizarre anti-GPL statement mentioned yesterday, and more. Read on for the details.

I thought Adam Smith was in favor of free markets and the exchange of ideas. mrjive writes "The plot thickens. In response to yesterday's story, it turns out that the attack on the free software movement was attached to the end of the letter in question by Rep. Adam Smith, D-Wash, who happens to have Microsoft as his biggest beneficiary. The original authors of the letter have sent an angry response for essentially twisting its original purpose. Read the full scoop here."

For the even-fuller scoop, see Roblimo's article on NewsForge.

Not bottling it up inside of himself. An anonymous reader writes "Richard M. Stallman has responded to comments made a week ago in response to his own Linux kernel mailing list post about the BitKeeper controversy. 'A technical issue or project sometimes raises ethical issues,' Stallman began. He did not stop there. More on the (newly cached and therefore a little bit Slashdot-immune) Linux and Main . Be gentle."

Free knowledge for sale for free, etc. OverCode@work writes "The complete LaTeX source to Loki Software's game programming book, Programming Linux Games, is now available on the author's site. This book was reviewed here a while back. Mad props to the publisher for letting this happen."

Everybody'sSQL haggar writes "MySQL (commercial license) will be shipped as standard with NetWare according to this announcement. I consider it a follow-up to the Slashdot story about the PostgreSQL port for NetWare. Apparently, the options for NetWare users are widening, thanks to open-source products!"

An iBook in every (lobster)pot! Call Me Black Cloud writes "Some time ago Maine awarded a contract to Apple for laptops for school kids. MacCentral has an interview with Maine governor Angus King where he discusses the success of the program. Despite the Maine state legislature's attempts to kill the program, it continues on. Why? Well, a $1M grant from the Gates Foundation certainly helped. Over the summer Apple delivered 18,000 iBooks and installed 239 wireless networks in 239 schools."

So long as they're not mandatory. Polo writes "I noticed that the Garmin Rino 110 and 120 are shipping. If you don't remember, these are FRS/GMRS Radios with integrated GPS. You can transmit your position to other units so they can hear you and see where you are. Pretty cool. This is a follow-up to an older story"

What the market will bear. His Nastiness writes "Just a follow-up that I ran across that indicates that Steve Ballmer may have just been blowing hot air on not selling the XBox in Austrailia anymore. See the previous thread here."

Slashback is back, with a largish handful of updates and new information about previously run stories. Topics this go-round include Xbox sales in Australia, the Novell / MySQL connection, Adam Smith (no, not that Adam Smith)'s bizarre anti-GPL statement mentioned yesterday, and more. Read on for the details.

I thought Adam Smith was in favor of free markets and the exchange of ideas. mrjive writes "The plot thickens. In response to yesterday's story, it turns out that the attack on the free software movement was attached to the end of the letter in question by Rep. Adam Smith, D-Wash, who happens to have Microsoft as his biggest beneficiary. The original authors of the letter have sent an angry response for essentially twisting its original purpose. Read the full scoop here."

For the even-fuller scoop, see Roblimo's article on NewsForge.

Not bottling it up inside of himself. An anonymous reader writes "Richard M. Stallman has responded to comments made a week ago in response to his own Linux kernel mailing list post about the BitKeeper controversy. 'A technical issue or project sometimes raises ethical issues,' Stallman began. He did not stop there. More on the (newly cached and therefore a little bit Slashdot-immune) Linux and Main . Be gentle."

Free knowledge for sale for free, etc. OverCode@work writes "The complete LaTeX source to Loki Software's game programming book, Programming Linux Games, is now available on the author's site. This book was reviewed here a while back. Mad props to the publisher for letting this happen."

Everybody'sSQL haggar writes "MySQL (commercial license) will be shipped as standard with NetWare according to this announcement. I consider it a follow-up to the Slashdot story about the PostgreSQL port for NetWare. Apparently, the options for NetWare users are widening, thanks to open-source products!"

An iBook in every (lobster)pot! Call Me Black Cloud writes "Some time ago Maine awarded a contract to Apple for laptops for school kids. MacCentral has an interview with Maine governor Angus King where he discusses the success of the program. Despite the Maine state legislature's attempts to kill the program, it continues on. Why? Well, a $1M grant from the Gates Foundation certainly helped. Over the summer Apple delivered 18,000 iBooks and installed 239 wireless networks in 239 schools."

So long as they're not mandatory. Polo writes "I noticed that the Garmin Rino 110 and 120 are shipping. If you don't remember, these are FRS/GMRS Radios with integrated GPS. You can transmit your position to other units so they can hear you and see where you are. Pretty cool. This is a follow-up to an older story"

What the market will bear. His Nastiness writes "Just a follow-up that I ran across that indicates that Steve Ballmer may have just been blowing hot air on not selling the XBox in Austrailia anymore. See the previous thread here."

Slashback tonight brings you word on a games contest, an update to the famous spider-goat hybrid which grossed you out months ago, bad news for Galileo's last days, passable news for anyone following the David McOwen story and more. Read on for the updates :)

Make sure you slip this into the fine print of your consulting contracts. Adn writes "Newsbytes is reporting in a story that David McOwen, who was facing some pretty serious charges will be let go with a fine as against a much harsher fate. If utilizing so called "unused cycles" for the greater good is a crime (I know he was not charged for that per se... but bear with me here) then makes you consider uninstalling all those SETI@Home Screensavers doesnt it? Also a larger question...If the law (in these kinds of cases) operates on the 'intent' of the accused, what is the justification for even considering it a crime?"

Playing games builds your mind and your hand-eye coordination. Bill Kendrick writes: "The results are in for the SDL Game Contest held by No Starch Press, Linux Journal and Loki Games.

First place was awarded to LBreakout by Michael Speck. Second place went to Tower Toppler by Andreas Roever. My own game, Vectoroids just barely made third place over another asteroids-style game, Rock Dodgers by Paul Holt.

Congratulations! The full list of games is listed on No Starch's results page."

Guaranteed not to be your average Slashdot book review! Alex Chiu writes "Hello. This is alex chiu. I have written an online book at http://superiching.com Teaching people how to communicate with God using I-Ching. This online book is free for everyone to read. It's at least 5 times bigger than alexchiu.com. If interested, please release this news."

You may remember Alex from the interview we did with him a little while ago -- truly a unique individual.

Flying blind and a long way from home. Vertigo01 writes: "According to this article on CNN.com, galileo has encountered some technical problems on its flyby of Io and "for unknown reasons, went into safe mode" ... (sounds like my last Win98 install) ... flight engineers hope to restore normal operation for the duration of Galileo's life, but it looks like we won't get any more pictures of Io out of her."

Victoria's Secret probably won't put this on the box. FortKnox writes "Spider Silk is long known to be one of the strongest biological structure made (5 times stronger than steel by weight). Biologists have already genetically engineered goats to produce spider silk in their milk. Now, they have successfully extracted the protein and "spun" the silk. The next, and final step, is to mass produce the silk to be available commercially. Move over kevlar, here comes something better! I want to have the first biologically built house! I wonder how insulated spider silk is...."

Slashback tonight brings you word on a games contest, an update to the famous spider-goat hybrid which grossed you out months ago, bad news for Galileo's last days, passable news for anyone following the David McOwen story and more. Read on for the updates :)

Make sure you slip this into the fine print of your consulting contracts. Adn writes "Newsbytes is reporting in a story that David McOwen, who was facing some pretty serious charges will be let go with a fine as against a much harsher fate. If utilizing so called "unused cycles" for the greater good is a crime (I know he was not charged for that per se... but bear with me here) then makes you consider uninstalling all those SETI@Home Screensavers doesnt it? Also a larger question...If the law (in these kinds of cases) operates on the 'intent' of the accused, what is the justification for even considering it a crime?"

Playing games builds your mind and your hand-eye coordination. Bill Kendrick writes: "The results are in for the SDL Game Contest held by No Starch Press, Linux Journal and Loki Games.

First place was awarded to LBreakout by Michael Speck. Second place went to Tower Toppler by Andreas Roever. My own game, Vectoroids just barely made third place over another asteroids-style game, Rock Dodgers by Paul Holt.

Congratulations! The full list of games is listed on No Starch's results page."

Guaranteed not to be your average Slashdot book review! Alex Chiu writes "Hello. This is alex chiu. I have written an online book at http://superiching.com Teaching people how to communicate with God using I-Ching. This online book is free for everyone to read. It's at least 5 times bigger than alexchiu.com. If interested, please release this news."

You may remember Alex from the interview we did with him a little while ago -- truly a unique individual.

Flying blind and a long way from home. Vertigo01 writes: "According to this article on CNN.com, galileo has encountered some technical problems on its flyby of Io and "for unknown reasons, went into safe mode" ... (sounds like my last Win98 install) ... flight engineers hope to restore normal operation for the duration of Galileo's life, but it looks like we won't get any more pictures of Io out of her."

Victoria's Secret probably won't put this on the box. FortKnox writes "Spider Silk is long known to be one of the strongest biological structure made (5 times stronger than steel by weight). Biologists have already genetically engineered goats to produce spider silk in their milk. Now, they have successfully extracted the protein and "spun" the silk. The next, and final step, is to mass produce the silk to be available commercially. Move over kevlar, here comes something better! I want to have the first biologically built house! I wonder how insulated spider silk is...."

Long-suffering Slashdot reader WrinkledShirt contributes this review of John Hall's Programming Linux Games, and lays out the good and the bad in a book that's one of the few of its kind. More games are always good -- hopefully books like this one will spark some inspiration.

Programming Linux Games author John Hall pages 415 publisher No Starch Press rating 7.5 reviewer WrinkledShirt ISBN 1-886411-49-2 summary Well-written guide to a wide range of game-writing tools for Linux, but not a definitive reference work for any single task.

Introduction

The potential for linux gaming has really exploded in the last couple of years. In many cases, the potential has been realized -- Unreal Tournament, SimCity 3000, Tribes 2, Quake 3, Alpha Centauri, and many other successful Windows titles, have all been brought to Linux, with Loki leading the charge. Judging by the bottom line, there's a definite shortage of true cash-cow success stories in this enigmatic part of the industry, and hence, a shortage of good reference material for naive people hoping to produce that next cash cow.

However, we've reached such a point of critical mass of knowledge and technology that books had to start appearing sometime. So, despite the fact that there's no overwhelming market demand for Linux games and a high ratio of hobbyists to dedicated game developers for the OS, here we have a book aiming at taking amateur Linux game development to the next level.

However, much of the technology out there for game programming in Linux is still heavily in development, with many of the APIs and libraries still a long way away from a 1.0 release. Allegro and Clanlib are a couple of exceptions to this trend -- both are popular APIs that sadly don't get much more than a passing mention in the book. Their sexier counterpart, Sam Lantinga's SDL, gets a fair amount of treatment (no surprise there, considering John Hall was the lead author for a team based within Loki) -- but even this fairly feature-complete library, which Loki uses to port its games over from Windows, isn't explored in its entirety.

Instead, there are also crash courses in BSD sockets, package management, TCL, the framebuffer and various sound APIs, and what we end up with here is the consummate cookbook, a jack-of-all-trades-and-master-of-none tome that introduces us to a wide variety of Linux gaming topics while stopping short of being a definitive reference for any of them. Such is John Hall's work, an interesting, wide-ranging introduction to game programming for an operating system that few believed was capable of it not too long ago.

John Hall, an experienced game developer, participated in Loki's Civilization, Call to Power game hack, and is currently working for Treyarch developing that company's Spider-Man title for the PS2.

The Good

As far as cookbooks go, this is a good one, and there isn't much concerning Linux game API programming that isn't touched on. There's an ongoing case study (Penguin Warrior) that is developed over the course of the book. Each chapter introduces a fairly deep concept, gives a decent function reference related to the concept, then incorporates the knowledge into proof-of-concept code, and then uses the new-found knowledge to enrich the case study. The tone is straightforward and the execution is solid. The final game works well enough to give confidence that the reader could take the knowledge in this book and apply it to his or her own project, either to add new features or re-think old ones.

The book is also well-written -- the sample code is extremely well-commented and good error-handling is in place. He makes no assumptions about the knowledge of the reader, dealing with such introductory topics in Linux programming as vi vs Emacs, the FSH and make, although he never gets annoying or patronizing. *cough cough* LaMothe *cough*

Individual chapters stand out as being great introductory resources for material that doesn't have much in the way of documentation. The important aspects of SDL get good treatment in one complete and comprehensive unit. There's also a thorough chapter on audio programming, comparing and contrasting OpenAL, OSS, ALSA, Ogg Vorbis, and ESD (among others), and all this after showing off SDL's sound capabilities one chapter earlier. Many of the pitfalls associated with each of the different technologies, as well as the pitfalls of sound programming in general, are covered here. It's a great jumping-off point for those who don't know much about the audio end of things.

There's even a really neat chapter on incorporating TCL script interpretation within a program written in C. For anyone who's had trouble throwing together their own text parser for initialization scripts, or who's fed up with the constant recompiles needed when tweaking for the most arbitrary of changes of the game's AI, the information in this chapter is a godsend. In the Penguin Warrior case study, it's almost spooky how effective TCL turns out to be in making the computer ship chase and evade the human player.

Finally, I want to reiterate the effective use of the case study, Penguin Warrior. Having seen the way other game programming texts handle using samples to illustrate game programming concepts -- which is often a mish-mash, to say the least -- the way this book approached the issue is refreshing: there's one major project, and each chapter brings us closer to that project's completion. The code works as intended and goes a long way to convince the reader that the libraries and techniques explored in this book are near-commercial-level quality. (Networked games turned out to be choppy on my machine, but that was the only real black mark I could find in the program's execution.) If nothing else, John Hall deserves a good deal of thanks for proving that game development on Linux is a realistic and rewarding endeavor.

The Not So Good

At times, the generalist nature of the book left me wondering if Hall couldn't have gone just a little bit further in some of the topics. There's a decent enough synopsis about deployment using Loki's install tool, as well as packaging in general, although nothing related to the Penguin Warrior game itself, so we don't get to see the theory in practice as much as it could have been. Also, he teases us by early on by starting with the compiler, moving to the make utility, talking a bit about package management, and then mentions automake, but he stops short of really explaining how to bring that into an existing project. Considering all the fun little dependencies needed for multimedia programming in Linux, this would have been a valuable bit of information for anyone not used to deploying on the platform.

Another instance of this so-close-yet-so-far approach occurs when he talks about incorporating Mesa into an SDL program. He tantalizes us with a code sample illustrating how to use the SDL as a replacement for glut, but that's all -- the material doesn't really get deep enough to convince readers that a 3D neophyte really can abandon glut for the SDL, particularly when many OpenGL reference materials out there rely heavily on glut as a teaching aid for windowing and other utility functions. Loki primarily used SDL to handle its 3D utility programming, so at least we know it's possible, but given the exploding popularity of 3D games it's too bad this wasn't covered more.

It's sometimes hard to tell exactly who the book is intended for. The introductory chapters include discussions on topics such as the different gaming genres out there, despite the fact that game programming hopefuls who don't know that Quake is a first-person shooter must make up a really narrow audience. Also, it's almost enough to give one whiplash to see how quickly he dives into using ioctl() when only a couple of chapters earlier he was explaining the basics of using gcc. Next up soon after that? Strap yourself in, we'll be writing straight to /dev/fb0! It's almost comical to think about how much dangerous knowledge a newbie's been given over the course of the book. Still, like I said earlier, he never talks down to the reader, who because of this might feel compelled against better judgement to be whisked along into subject matter that really needs other support material to be of any real use.

Hall's a humble enough guy, which is great insofar as writing style is concerned, but in one of the last chapters, he starts questioning some of the choices he made while coding Penguin Warrior throughout the book. Specifically, he says he probably should have used C++ instead of C, Scheme instead of TCL, and UDP instead of TCP for the networking, and this is cold comfort for people who would have hoped that the author would have picked the best plan of attack from the beginning. That said, C, TCL, and TCP are appropriate choices due to the simplicity of execution and the fact that they introduce useful techniques from a design point of view. Still, there's no point giving readers a sense of wistful "What if?" if you don't have to. It also highlights that this book is more a beginner's API reference than a game programming book per se.

To take that point further, there also really isn't much in the way of abstract game programming theory. This book could have really distinguished itself as special if some content related strictly to game development was here. There's a mention of Gamasutra here, a method of quick division there, the equation of a distance from a point to a line thrown into the mix, and that's pretty much all there is. Topics not really covered include optimization, pathfinding, and cracker-proofing your code, and what is talked about on the subjects of artificial intelligence design, collision detection, and physics is all rudimentary ... For coverage on these sorts of topics, you'll have to look elsewhere.

Finally, and this is really not the fault of the author or the book, but one wonders if the time was right for much of this material -- or, at the very least, its highly generalist approach. DRI is making its presence felt, the various audio APIs out there are improving all the time, and the LSB is coming along nicely, but until there's a proven and stable multimedia base to work from, no definitive guide can be written, and this sort of organized dogpile is really the best we can hope for with so much stuff to cover. The SDL is a top-notch library for graphics programming, and it's likely an entire book could have been spent strictly on graphics programming using it, and the depth that such a book could have attained far surpasses what we're given here. Plus, in a year from now, who knows where any of these sound APIs will be? Of course, these might prove to be just esoteric issues in the grand scheme of this book.

Conclusion

Despite the criticisms I have of this book, I really don't want the message that is conveyed here to be anything but positive. There's a lot working for this book -- the chapters on SDL, sound programming and incorporating TCL and C are excellent, and will be especially helpful for people who are novices in these areas. Considering the alternatives (hitting dryly-written online docs or constantly shaking your Google to see what falls out), this book is a very attractive option. Programming a fully-functional multiplayer game would probably require more effort than might be suggested by the brevity of the chapter on socket programming, but that chapter is a solid introduction as well. The book as a whole is well-written and succeeds for the most part in its endeavor to make the best of a chaotic situation. I'd recommend this book to anybody who appreciates the messy-kitchen style of learning, or to anyone with decent hacking skills who just needs to break the ice when it comes to the Linux game APIs. And even though it gets slightly schizophrenic in its attempt to be both an introductory text and a definitive reference, this is the sort of book that could kickstart a new movement in Linux game development.

Table of Contents (exploded version here)

1. The Anatomy of a Game
2. Linux Development Tools
3. Linux Gaming APIs
4. Mastering SDL
5. Linux Audio Programming
6. Game Scripting Under Linux
7. Networked Gaming with Linux
8. Gaming with the Linux Console
9. Finishing Penguin Warrior
10. To Every Man a Linux Distribution

• Glossary of Terms
• Bibliography

Related Links

Sample Code
No Starch Press
Loki
SDL (List of SDL games)
OpenAL
DRI
Mesa
libsndfile
Gamasutra

You can purchase this book from Fatbrain.

Long-suffering Slashdot reader WrinkledShirt contributes this review of John Hall's Programming Linux Games, and lays out the good and the bad in a book that's one of the few of its kind. More games are always good -- hopefully books like this one will spark some inspiration.

Programming Linux Games author John Hall pages 415 publisher No Starch Press rating 7.5 reviewer WrinkledShirt ISBN 1-886411-49-2 summary Well-written guide to a wide range of game-writing tools for Linux, but not a definitive reference work for any single task.

Introduction

The potential for linux gaming has really exploded in the last couple of years. In many cases, the potential has been realized -- Unreal Tournament, SimCity 3000, Tribes 2, Quake 3, Alpha Centauri, and many other successful Windows titles, have all been brought to Linux, with Loki leading the charge. Judging by the bottom line, there's a definite shortage of true cash-cow success stories in this enigmatic part of the industry, and hence, a shortage of good reference material for naive people hoping to produce that next cash cow.

However, we've reached such a point of critical mass of knowledge and technology that books had to start appearing sometime. So, despite the fact that there's no overwhelming market demand for Linux games and a high ratio of hobbyists to dedicated game developers for the OS, here we have a book aiming at taking amateur Linux game development to the next level.

However, much of the technology out there for game programming in Linux is still heavily in development, with many of the APIs and libraries still a long way away from a 1.0 release. Allegro and Clanlib are a couple of exceptions to this trend -- both are popular APIs that sadly don't get much more than a passing mention in the book. Their sexier counterpart, Sam Lantinga's SDL, gets a fair amount of treatment (no surprise there, considering John Hall was the lead author for a team based within Loki) -- but even this fairly feature-complete library, which Loki uses to port its games over from Windows, isn't explored in its entirety.

Instead, there are also crash courses in BSD sockets, package management, TCL, the framebuffer and various sound APIs, and what we end up with here is the consummate cookbook, a jack-of-all-trades-and-master-of-none tome that introduces us to a wide variety of Linux gaming topics while stopping short of being a definitive reference for any of them. Such is John Hall's work, an interesting, wide-ranging introduction to game programming for an operating system that few believed was capable of it not too long ago.

John Hall, an experienced game developer, participated in Loki's Civilization, Call to Power game hack, and is currently working for Treyarch developing that company's Spider-Man title for the PS2.

The Good

As far as cookbooks go, this is a good one, and there isn't much concerning Linux game API programming that isn't touched on. There's an ongoing case study (Penguin Warrior) that is developed over the course of the book. Each chapter introduces a fairly deep concept, gives a decent function reference related to the concept, then incorporates the knowledge into proof-of-concept code, and then uses the new-found knowledge to enrich the case study. The tone is straightforward and the execution is solid. The final game works well enough to give confidence that the reader could take the knowledge in this book and apply it to his or her own project, either to add new features or re-think old ones.

The book is also well-written -- the sample code is extremely well-commented and good error-handling is in place. He makes no assumptions about the knowledge of the reader, dealing with such introductory topics in Linux programming as vi vs Emacs, the FSH and make, although he never gets annoying or patronizing. *cough cough* LaMothe *cough*

Individual chapters stand out as being great introductory resources for material that doesn't have much in the way of documentation. The important aspects of SDL get good treatment in one complete and comprehensive unit. There's also a thorough chapter on audio programming, comparing and contrasting OpenAL, OSS, ALSA, Ogg Vorbis, and ESD (among others), and all this after showing off SDL's sound capabilities one chapter earlier. Many of the pitfalls associated with each of the different technologies, as well as the pitfalls of sound programming in general, are covered here. It's a great jumping-off point for those who don't know much about the audio end of things.

There's even a really neat chapter on incorporating TCL script interpretation within a program written in C. For anyone who's had trouble throwing together their own text parser for initialization scripts, or who's fed up with the constant recompiles needed when tweaking for the most arbitrary of changes of the game's AI, the information in this chapter is a godsend. In the Penguin Warrior case study, it's almost spooky how effective TCL turns out to be in making the computer ship chase and evade the human player.

Finally, I want to reiterate the effective use of the case study, Penguin Warrior. Having seen the way other game programming texts handle using samples to illustrate game programming concepts -- which is often a mish-mash, to say the least -- the way this book approached the issue is refreshing: there's one major project, and each chapter brings us closer to that project's completion. The code works as intended and goes a long way to convince the reader that the libraries and techniques explored in this book are near-commercial-level quality. (Networked games turned out to be choppy on my machine, but that was the only real black mark I could find in the program's execution.) If nothing else, John Hall deserves a good deal of thanks for proving that game development on Linux is a realistic and rewarding endeavor.

The Not So Good

At times, the generalist nature of the book left me wondering if Hall couldn't have gone just a little bit further in some of the topics. There's a decent enough synopsis about deployment using Loki's install tool, as well as packaging in general, although nothing related to the Penguin Warrior game itself, so we don't get to see the theory in practice as much as it could have been. Also, he teases us by early on by starting with the compiler, moving to the make utility, talking a bit about package management, and then mentions automake, but he stops short of really explaining how to bring that into an existing project. Considering all the fun little dependencies needed for multimedia programming in Linux, this would have been a valuable bit of information for anyone not used to deploying on the platform.

Another instance of this so-close-yet-so-far approach occurs when he talks about incorporating Mesa into an SDL program. He tantalizes us with a code sample illustrating how to use the SDL as a replacement for glut, but that's all -- the material doesn't really get deep enough to convince readers that a 3D neophyte really can abandon glut for the SDL, particularly when many OpenGL reference materials out there rely heavily on glut as a teaching aid for windowing and other utility functions. Loki primarily used SDL to handle its 3D utility programming, so at least we know it's possible, but given the exploding popularity of 3D games it's too bad this wasn't covered more.

It's sometimes hard to tell exactly who the book is intended for. The introductory chapters include discussions on topics such as the different gaming genres out there, despite the fact that game programming hopefuls who don't know that Quake is a first-person shooter must make up a really narrow audience. Also, it's almost enough to give one whiplash to see how quickly he dives into using ioctl() when only a couple of chapters earlier he was explaining the basics of using gcc. Next up soon after that? Strap yourself in, we'll be writing straight to /dev/fb0! It's almost comical to think about how much dangerous knowledge a newbie's been given over the course of the book. Still, like I said earlier, he never talks down to the reader, who because of this might feel compelled against better judgement to be whisked along into subject matter that really needs other support material to be of any real use.

Hall's a humble enough guy, which is great insofar as writing style is concerned, but in one of the last chapters, he starts questioning some of the choices he made while coding Penguin Warrior throughout the book. Specifically, he says he probably should have used C++ instead of C, Scheme instead of TCL, and UDP instead of TCP for the networking, and this is cold comfort for people who would have hoped that the author would have picked the best plan of attack from the beginning. That said, C, TCL, and TCP are appropriate choices due to the simplicity of execution and the fact that they introduce useful techniques from a design point of view. Still, there's no point giving readers a sense of wistful "What if?" if you don't have to. It also highlights that this book is more a beginner's API reference than a game programming book per se.

To take that point further, there also really isn't much in the way of abstract game programming theory. This book could have really distinguished itself as special if some content related strictly to game development was here. There's a mention of Gamasutra here, a method of quick division there, the equation of a distance from a point to a line thrown into the mix, and that's pretty much all there is. Topics not really covered include optimization, pathfinding, and cracker-proofing your code, and what is talked about on the subjects of artificial intelligence design, collision detection, and physics is all rudimentary ... For coverage on these sorts of topics, you'll have to look elsewhere.

Finally, and this is really not the fault of the author or the book, but one wonders if the time was right for much of this material -- or, at the very least, its highly generalist approach. DRI is making its presence felt, the various audio APIs out there are improving all the time, and the LSB is coming along nicely, but until there's a proven and stable multimedia base to work from, no definitive guide can be written, and this sort of organized dogpile is really the best we can hope for with so much stuff to cover. The SDL is a top-notch library for graphics programming, and it's likely an entire book could have been spent strictly on graphics programming using it, and the depth that such a book could have attained far surpasses what we're given here. Plus, in a year from now, who knows where any of these sound APIs will be? Of course, these might prove to be just esoteric issues in the grand scheme of this book.

Conclusion

Despite the criticisms I have of this book, I really don't want the message that is conveyed here to be anything but positive. There's a lot working for this book -- the chapters on SDL, sound programming and incorporating TCL and C are excellent, and will be especially helpful for people who are novices in these areas. Considering the alternatives (hitting dryly-written online docs or constantly shaking your Google to see what falls out), this book is a very attractive option. Programming a fully-functional multiplayer game would probably require more effort than might be suggested by the brevity of the chapter on socket programming, but that chapter is a solid introduction as well. The book as a whole is well-written and succeeds for the most part in its endeavor to make the best of a chaotic situation. I'd recommend this book to anybody who appreciates the messy-kitchen style of learning, or to anyone with decent hacking skills who just needs to break the ice when it comes to the Linux game APIs. And even though it gets slightly schizophrenic in its attempt to be both an introductory text and a definitive reference, this is the sort of book that could kickstart a new movement in Linux game development.

Table of Contents (exploded version here)

1. The Anatomy of a Game
2. Linux Development Tools
3. Linux Gaming APIs
4. Mastering SDL
5. Linux Audio Programming
6. Game Scripting Under Linux
7. Networked Gaming with Linux
8. Gaming with the Linux Console
9. Finishing Penguin Warrior
10. To Every Man a Linux Distribution

• Glossary of Terms
• Bibliography

Related Links

Sample Code
No Starch Press
Loki
SDL (List of SDL games)
OpenAL
DRI
Mesa
libsndfile
Gamasutra

You can purchase this book from Fatbrain.

Long-suffering Slashdot reader WrinkledShirt contributes this review of John Hall's Programming Linux Games, and lays out the good and the bad in a book that's one of the few of its kind. More games are always good -- hopefully books like this one will spark some inspiration.

Programming Linux Games author John Hall pages 415 publisher No Starch Press rating 7.5 reviewer WrinkledShirt ISBN 1-886411-49-2 summary Well-written guide to a wide range of game-writing tools for Linux, but not a definitive reference work for any single task.

Introduction

The potential for linux gaming has really exploded in the last couple of years. In many cases, the potential has been realized -- Unreal Tournament, SimCity 3000, Tribes 2, Quake 3, Alpha Centauri, and many other successful Windows titles, have all been brought to Linux, with Loki leading the charge. Judging by the bottom line, there's a definite shortage of true cash-cow success stories in this enigmatic part of the industry, and hence, a shortage of good reference material for naive people hoping to produce that next cash cow.

However, we've reached such a point of critical mass of knowledge and technology that books had to start appearing sometime. So, despite the fact that there's no overwhelming market demand for Linux games and a high ratio of hobbyists to dedicated game developers for the OS, here we have a book aiming at taking amateur Linux game development to the next level.

However, much of the technology out there for game programming in Linux is still heavily in development, with many of the APIs and libraries still a long way away from a 1.0 release. Allegro and Clanlib are a couple of exceptions to this trend -- both are popular APIs that sadly don't get much more than a passing mention in the book. Their sexier counterpart, Sam Lantinga's SDL, gets a fair amount of treatment (no surprise there, considering John Hall was the lead author for a team based within Loki) -- but even this fairly feature-complete library, which Loki uses to port its games over from Windows, isn't explored in its entirety.

Instead, there are also crash courses in BSD sockets, package management, TCL, the framebuffer and various sound APIs, and what we end up with here is the consummate cookbook, a jack-of-all-trades-and-master-of-none tome that introduces us to a wide variety of Linux gaming topics while stopping short of being a definitive reference for any of them. Such is John Hall's work, an interesting, wide-ranging introduction to game programming for an operating system that few believed was capable of it not too long ago.

John Hall, an experienced game developer, participated in Loki's Civilization, Call to Power game hack, and is currently working for Treyarch developing that company's Spider-Man title for the PS2.

The Good

As far as cookbooks go, this is a good one, and there isn't much concerning Linux game API programming that isn't touched on. There's an ongoing case study (Penguin Warrior) that is developed over the course of the book. Each chapter introduces a fairly deep concept, gives a decent function reference related to the concept, then incorporates the knowledge into proof-of-concept code, and then uses the new-found knowledge to enrich the case study. The tone is straightforward and the execution is solid. The final game works well enough to give confidence that the reader could take the knowledge in this book and apply it to his or her own project, either to add new features or re-think old ones.

The book is also well-written -- the sample code is extremely well-commented and good error-handling is in place. He makes no assumptions about the knowledge of the reader, dealing with such introductory topics in Linux programming as vi vs Emacs, the FSH and make, although he never gets annoying or patronizing. *cough cough* LaMothe *cough*

Individual chapters stand out as being great introductory resources for material that doesn't have much in the way of documentation. The important aspects of SDL get good treatment in one complete and comprehensive unit. There's also a thorough chapter on audio programming, comparing and contrasting OpenAL, OSS, ALSA, Ogg Vorbis, and ESD (among others), and all this after showing off SDL's sound capabilities one chapter earlier. Many of the pitfalls associated with each of the different technologies, as well as the pitfalls of sound programming in general, are covered here. It's a great jumping-off point for those who don't know much about the audio end of things.

There's even a really neat chapter on incorporating TCL script interpretation within a program written in C. For anyone who's had trouble throwing together their own text parser for initialization scripts, or who's fed up with the constant recompiles needed when tweaking for the most arbitrary of changes of the game's AI, the information in this chapter is a godsend. In the Penguin Warrior case study, it's almost spooky how effective TCL turns out to be in making the computer ship chase and evade the human player.

Finally, I want to reiterate the effective use of the case study, Penguin Warrior. Having seen the way other game programming texts handle using samples to illustrate game programming concepts -- which is often a mish-mash, to say the least -- the way this book approached the issue is refreshing: there's one major project, and each chapter brings us closer to that project's completion. The code works as intended and goes a long way to convince the reader that the libraries and techniques explored in this book are near-commercial-level quality. (Networked games turned out to be choppy on my machine, but that was the only real black mark I could find in the program's execution.) If nothing else, John Hall deserves a good deal of thanks for proving that game development on Linux is a realistic and rewarding endeavor.

The Not So Good

At times, the generalist nature of the book left me wondering if Hall couldn't have gone just a little bit further in some of the topics. There's a decent enough synopsis about deployment using Loki's install tool, as well as packaging in general, although nothing related to the Penguin Warrior game itself, so we don't get to see the theory in practice as much as it could have been. Also, he teases us by early on by starting with the compiler, moving to the make utility, talking a bit about package management, and then mentions automake, but he stops short of really explaining how to bring that into an existing project. Considering all the fun little dependencies needed for multimedia programming in Linux, this would have been a valuable bit of information for anyone not used to deploying on the platform.

Another instance of this so-close-yet-so-far approach occurs when he talks about incorporating Mesa into an SDL program. He tantalizes us with a code sample illustrating how to use the SDL as a replacement for glut, but that's all -- the material doesn't really get deep enough to convince readers that a 3D neophyte really can abandon glut for the SDL, particularly when many OpenGL reference materials out there rely heavily on glut as a teaching aid for windowing and other utility functions. Loki primarily used SDL to handle its 3D utility programming, so at least we know it's possible, but given the exploding popularity of 3D games it's too bad this wasn't covered more.

It's sometimes hard to tell exactly who the book is intended for. The introductory chapters include discussions on topics such as the different gaming genres out there, despite the fact that game programming hopefuls who don't know that Quake is a first-person shooter must make up a really narrow audience. Also, it's almost enough to give one whiplash to see how quickly he dives into using ioctl() when only a couple of chapters earlier he was explaining the basics of using gcc. Next up soon after that? Strap yourself in, we'll be writing straight to /dev/fb0! It's almost comical to think about how much dangerous knowledge a newbie's been given over the course of the book. Still, like I said earlier, he never talks down to the reader, who because of this might feel compelled against better judgement to be whisked along into subject matter that really needs other support material to be of any real use.

Hall's a humble enough guy, which is great insofar as writing style is concerned, but in one of the last chapters, he starts questioning some of the choices he made while coding Penguin Warrior throughout the book. Specifically, he says he probably should have used C++ instead of C, Scheme instead of TCL, and UDP instead of TCP for the networking, and this is cold comfort for people who would have hoped that the author would have picked the best plan of attack from the beginning. That said, C, TCL, and TCP are appropriate choices due to the simplicity of execution and the fact that they introduce useful techniques from a design point of view. Still, there's no point giving readers a sense of wistful "What if?" if you don't have to. It also highlights that this book is more a beginner's API reference than a game programming book per se.

To take that point further, there also really isn't much in the way of abstract game programming theory. This book could have really distinguished itself as special if some content related strictly to game development was here. There's a mention of Gamasutra here, a method of quick division there, the equation of a distance from a point to a line thrown into the mix, and that's pretty much all there is. Topics not really covered include optimization, pathfinding, and cracker-proofing your code, and what is talked about on the subjects of artificial intelligence design, collision detection, and physics is all rudimentary ... For coverage on these sorts of topics, you'll have to look elsewhere.

Finally, and this is really not the fault of the author or the book, but one wonders if the time was right for much of this material -- or, at the very least, its highly generalist approach. DRI is making its presence felt, the various audio APIs out there are improving all the time, and the LSB is coming along nicely, but until there's a proven and stable multimedia base to work from, no definitive guide can be written, and this sort of organized dogpile is really the best we can hope for with so much stuff to cover. The SDL is a top-notch library for graphics programming, and it's likely an entire book could have been spent strictly on graphics programming using it, and the depth that such a book could have attained far surpasses what we're given here. Plus, in a year from now, who knows where any of these sound APIs will be? Of course, these might prove to be just esoteric issues in the grand scheme of this book.

Conclusion

Despite the criticisms I have of this book, I really don't want the message that is conveyed here to be anything but positive. There's a lot working for this book -- the chapters on SDL, sound programming and incorporating TCL and C are excellent, and will be especially helpful for people who are novices in these areas. Considering the alternatives (hitting dryly-written online docs or constantly shaking your Google to see what falls out), this book is a very attractive option. Programming a fully-functional multiplayer game would probably require more effort than might be suggested by the brevity of the chapter on socket programming, but that chapter is a solid introduction as well. The book as a whole is well-written and succeeds for the most part in its endeavor to make the best of a chaotic situation. I'd recommend this book to anybody who appreciates the messy-kitchen style of learning, or to anyone with decent hacking skills who just needs to break the ice when it comes to the Linux game APIs. And even though it gets slightly schizophrenic in its attempt to be both an introductory text and a definitive reference, this is the sort of book that could kickstart a new movement in Linux game development.

Table of Contents (exploded version here)

1. The Anatomy of a Game
2. Linux Development Tools
3. Linux Gaming APIs
4. Mastering SDL
5. Linux Audio Programming
6. Game Scripting Under Linux
7. Networked Gaming with Linux
8. Gaming with the Linux Console
9. Finishing Penguin Warrior
10. To Every Man a Linux Distribution

• Glossary of Terms
• Bibliography

Related Links

Sample Code
No Starch Press
Loki
SDL (List of SDL games)
OpenAL
DRI
Mesa
libsndfile
Gamasutra

You can purchase this book from Fatbrain.

An anonymous reader sent in this tidbit - Loki Software has recently released Programming Linux Games, a book about Linux game development. It covers SDL, several audio APIs, and the Linux framebuffer console. The publisher has more info. (If someone wants to review this, email Hemos.)