Slashdot Mirror

Thanks to Janice Wright for returning with a review of O'Reilly's PalmPilot: The Ultimate Guide (2nd Edition). It's the 2nd edition, written by David Pogue and Jeff Hawkins - click below to learn how to make the most of your PalmPilot. PalmPilot: The Ultimate Guide (2nd Edition) author David Pogue, Jeff Hawkins pages 597, publisher O'Reilly rating 9/10 reviewer Janice Wright ISBN 1565926005 summary An excellent book to teach you how to make the most of your Pilot Wow - I'm impressed. With my Pilot that is. I bought a Pilot 6 months ago so that I could carry my agenda (which I keep in MSOutlook on my desktop computer) to meetings with me. For six months I used it essentially as an electronic version of my filofax that I could also play backgammon or Sokoban on; and that was all. Then I read David Pogue's "well-written, nicely designed exploration of the Palm" (to quote Jeff Hawkins in the 'Forward').

Now I think of my pilot as a computer, one that will provide almost as much hackish enjoyment as my Linux box... as a matter of fact I'm now following the microLinux project with great interest and wondering how long it will be before I can upgrade to a Palm/Handspring device that will run Linux, a POP3 client and support a wireless modem. In the preface, Pogue says "Taking your Palm further: that's what this book is about." He delivers on that one-hundred percent.

David Pogue's "Palm Pilot - The Ultimate Guide" is absolutely excellent. It did take forever to read, though, because I kept stopping every few pages to optimize my Pilot with the tricks I had just learned, or to turn an easter egg on (yes, the book tells you where all(?) of the easter eggs are). The book has everything from office productivity tips for suits (when transferring lots of data from the expense program to Excel, you can end up with multiple spreadsheets which you have to total seperately, p. 228) to great hackish tidbits for hardcore geeks (like how to turn on verbose hot-sync logging, p.142).

Like many people I completely ignored the manual that came in the box with my Pilot, so some of the stuff Pogue covers, like ferinstance the Ronomatic stroke, is probably actually in the manual (l've only ever looked at it once - to try to solve an installation failure problem. The manual was unhelpful, and I found the information I needed to solve the problem in the FAQs at PalmCentral.com. The problem and solution are on page 181.

What's good and/or my favorite bits:

• the musical notation for the palm chimes on p.137
• the official solution vs. the better solution to upgrading
• the way it explained why a backgammon game I had installed and then deleted kept 'coming back' every time I HotSynched
• even though I will probably never surf the web on my pilot the explanation of how ProxiWeb works is mega cool.

What's bad:

• didn't really need four pages on the various classic games that you can download from 3Com
• doesn't mention quickwrite in the 'graffiti alternatives' section

Table of Contents
I. This Is Your PalmPilot Speaking

The 3x5 inch powerhouse

Setup and guided tour

Typing without a keypad

The four primary programs

Other built-in programs
II. Palm Meets PC

HotSync, step-by-step

Installing new palm programs

Palm desktop (win&mac)
III. The Undiscovered PalmPilot

The electronic book

The secret multimedia world

Database and number crunching
IV. The PalmPilot Online

Email anywhere

The web in your Palm

Paging, faxing, printing, and beaming

Palm VII: wireless email, wireless web
V. Troubleshooting and Upgrading

Troubleshooting

The Palm family, model by model
VI. Appendixes

CD-ROM
A few notes about the CD-ROM that comes with the book: Though it was obviously outdated by the time the book went to press, it will save you hours of hunting for the best software and, depending on the speed of your modem of course, a significant amount of download time (for those of us unfortunate enough to live in corners of the world with metered phone calls, you will probably save yourself the price of the book within weeks). I've been working my way through a variety of 'world' clocks (ones that show multiple timezones), trying to find one that I like; because there are half-a-dozen on the CD, this is pretty painless. The Catalog software resident on the CD makes it easy to find what you are looking for, and in many instances, shows you what the program is going to look like. I've 'trialed' a lot more software on my PalmPilot than I would have ever been bothered to download.

And yes - I did write this review on my Pilot, mostly on trains & on the London Underground. Speaking of which: as soon as I get the time, I'm gonna figure out how to make ImageViewer docs, so that I can update the London Underground map for the Pilot - the one that's currently available still has Mornington Crescent crossed out!

Purchase this book at Amazon.

Janet, please send your name, address, t-shirt size, and this article's URL to roblimo so we can send you your t-shirt. (Everyone who writes a Slashdot review or feature now gets a free t-shirt!)

Simon Singh has written a readable and timely book about what he suggests is the Golden Age of Cryptography, complete with tales of code-breaking intrigue from Mary Queen of Scots to the NSA. Codes have dramatically altered the history of the world. Quantum cryptography will take the evolution of secrecy to a completely different level. The Code Book author Simon Singh pages 401 publisher Doubleday rating 8/10 reviewer Jon Katz ISBN 0-385-49531-5 summary The evolution of cryptography, from Mary Queen of Scots to the NSA

Simon Singh has written a readable, comprehensible and significant book about cryptography.

"The Code Book: The Evolution of Secrecy From Mary, Queen of Scots, to Quantum Cryptography" (Doubleday, $US 24) chronicles the obsessive human interest in and importance of codes, from Elizabethan England to the intrigue-riddled halls of the NSA and the era of quantum cryptography.

Secrets and the codes that protect them are important. They've brought about the rise and fall of monarchs and won wars; in some techno-circles, cryptography is almost becoming a religion. Issues surrounding codes speak directly to the Net, computing, freedom, privacy and power. Singh, a British author, producer and physicist, wrote the best-selling "Fermat's Enigma," and directed a documentary on Fermat's Last Theorm that aired on PBS's "Nova" series.

From tales of buried treasure, to stories of how the legendary mathematician and code breaker Alan Turing secretly helped defeat the Nazis and how Navajos (called code walkers) used their language to fight the Japanese, Singh puts our contemporary fascination with cryptography into perspective. He writes crisply and logically, and an instinct for talking about cryptography in terms of its most interesting tales.

"For two thousand years, codemakers have fought to preserve secrets while codebreakers have tried their best to reveal them," he explains. "It has always been a neck-and-neck race,with codebreakers battling back when codemakers seemed to be in command, and codemakers inventing new and stronger forms of encryption when previous methods had been compromised."

This battle becomes increasingly more intense and relevant, as the free-wheeling structure of the Internet increasingly collides with the perceived interests of individual citizens, with privacy, and with the interests and operations of law enforcement officials and national security organizations.

Singh suggests that we are entering a golden age of cryptography. He quotes one cryptographer as saying: "It is now possible to make ciphers in modern cryptography that are really, really out of reach of all known forms of cryptanalysis. And I think it's going to stay that way." This view, writes Singh, is supported by one of the NSA's Deputy Directors, who told him: "If all the personal computers in the world - approximately 260 million computers - were to be put to work on a single PGP encrypted message, it would take on average an estimated 12 million times the age of the universe to break a single message."

"The Code Book" even ends with "The Cipher Challenge: 10 Steps to $15,000." Singh offers a code -breaking challenge in 10 separate stages. I'll pass, but some of you might want take a shot at it.

Cryptography is a complex, even arcane subject for laypeople and non techno-heads to read about it. To Singh's credit, he's written a book that cryptographers and newbies can love equally. "The Code Book" unlocks the sometimes impenetrable complexity that surrounds cyptography, an achievement all its own.

You can pick this book up at Amazon.

GrokSoup writes "Magnificently loopy -- and spot-on -- profile of Jim Clark in Sunday's NY Times Magazine. In it, writer Michael Lewis manages to make the profoundly unsympathetic multibillionaire Clark at least somewhat sympathetic, while simultaneously dissecting the venture capital food chain, getting inside the Valley culture, describing Clark's many missteps, and generally doing a yeoman job of promoting his upcoming book. Read it." Great stuff! Up there with The Soul of a New Machine, but about the financial side of things. I strongly second GrokSoup's "read it."

There's been quite a bit of attention to Neal Stephenson's Cryptonomicon as well as The Diamond Age. The Big U, reviewed here by Sebbo, is one of his earliest books. Click below to read more - and to try your hand at the questions at the end of the review. The Big U author Neal Stephenson pages 307 publisher Vintage rating 8/10 reviewer Sebbo ISBN 0394723627 summary tephenson's first published novel is a funny and Stephenson's first published novel is a funny and disturbing satire about american colleges and the collapse of civilization. The Scenario

In the late 1980s, I was in High School. A friend of mine named Matt Lawsky, browsing through the remainder bin at a local bookstore, found a strange-looking paperback he'd never heard of. He bought it and took it home to read. Shortly thereafter, he pressed his new favorite book on me, insisting that I have a look at it.

It might be overstatement to say that The Big U changed my life, but it certainly helped gel my already-forming perspective. The Big U careens between soap-opera, adventure novel, venomous satire, and pure silliness--often in the course of a couple pages. Though the book is of average length, it feels like a big novel due to the accumulation of characters, groups, and events. It is never less than entertaining, and often hilarious and moving--sometimes at once.

The first half of the book is a sharp and nasty description of a large college called American Megaversity. Though we get some looks at classes and faculty members, the real concern is the students and the groups they belong to. Important groups include the Megaversity Association for Reenactments and Simulations (MARS), which is the gaming club, later renamed the Grand Army of Shekondhar the Fearsome. The student left is represented by the Stalinist Underground Battalion (SUB), and the student religious right is the Temple of Unlimited Godhead (TUG), an "outlaw breakaway Mormon sect." As with all subsequent Stephenson novels, characters recieve ludicrous Dickensian names: the geeky protaganist is Casmir Radon; the hallucinogen-addled Stalinist leader is Dex Fresser; the president of the school is Septimus Severius Krupp. Other names, though as jokey, are a little subtler. the uberhacker with godlike powers over the school mainframe and master-key access to every building on campus is named Virgil Gabrielson.

Interestingly, the drunken and violent yahoos who are the primary cause of suffering for some of the main characters are identified neither with the fraternities or the sports teams, but are simply their own group, initially the Wild and Crazy Guys, and later, the Terrorists. Their female counterparts, the Airheads, over the course of the first half of the book take up wearing ski masks to informal public gatherings (like cafeteria meals) since it saves them so much time applying makeup.

Though this is all mostly played for laughs, a few scenes of grief and violence (including a horrifying attempted rape) emphasize that the environment is no joke for some of the students trying to live in it.

In the second half, faculty and maintenance workers go on strike, and a number of the students revert to bicamerality.

What am I talking about? In brief: In The Origin of Conciousness in the Breakdown of the Bicameral Mind, author Julian Jaynes asserts that until about 3000 years ago, people weren't concious in the way that we are, but instead were something like schitzophrenic robots who heard divine voices speaking to them from the right hemispheres of their brains. Some characters in The Big U use their conciousnesses little enough that they begin to revert to this state, and begin hearing voices coming out advertising billboards and washing machines. You'll find other ideas cribbed from Jaynes in Snow Crash. A good summary of Jaynes in the context of The Big U can be found here.

I can't particularly reccommend Bicameral, by the way, except to conniseurs of kooklit. Though immensely clever, his evidence mostly comes from idiosyncratic interpertation of fine points of the wording in the Old Testament and the Illiad. While the observation that people seem to have talked to the gods a lot more frequently back then is prety reasonable, Jaynes generally comes across as someone so in love with the hammer he built that he can't resist declaring everything he sees a nail.

Where was I? Oh, soon, civilization utterly collapses when the maintenance workers (Crotobaltslavonian refugees) sieze comtrol of the nuclear waste disposal site beneath the school. This breakdown percipitates, and Stephenson lovingly describes the process with his characteristic gusto for any scene of mass mayhem. The semester progresses from the live-ammo foodfight in the cafeteria (sample quote: "Unfortunately a stray weapons burst had struck a pressure vat by the exit. The top of the vat exploded off, blasting a neat hole throught the ceiling, and the vat, torn loose by the recoil, tumbled over and spilled thousands of gallons of Cheezy Surprise Tetrazzini onto the floor.") to the complex territorial divisions as several armed gangs stake out different areas of strategic value.

Did I mention the giant mutant sewer rats? There are giant mutant sewer rats.

Eventually the protaganists manage to effect a mass evacuation, end the Crotobaltslavonian nuclear threat, and bring the story to a satisfying conclusion. I shall close my summary with words from the book's introduction: "What you are about to read is not an abberration: it can happen in your local university too. The Big U, simply, was a few years ahead of the rest."

Availability Okay, okay I admit it. Some of my affection for The Big U derives from the way I first read it Matt and I watched the growing Cult of Stephenson with a little dismay, as the pioneers of any wildeness are saddened as their forests becomes farms and then bedroom communities.

Now comes the bad news: this book is incredibly rare. Copies online go for $200 to $500. Rumors have circulated that Stephenson had been suppressing the book, but sources close to him deny this. I'm not sure who has the rights to the damn thing now, so I'm not sure who you should be bugging to reprint it. If Stephenson holds the rights, perhaps we can persuade him to make it freely available. Anyone know his e-mail address?

Analysis There are numerous bad people in The Big U; the Terrorists are cruel, stupid, and violent; the trustees are selfish and hypocritical; the Crotobaltslavonians are ruthless killers. The villain of the story, however, is arguably the building itself. American Megaversity is one enormous cinderblock-and-florescent-tube structure, called the Plexus--a portmanteau, presumably, of complex and campus. "The Plex's environmental control system was designed so that anyone could spend four years there wearing only a jockstrap and a pair of welding goggles and yet never feel chilly or find the place too dimly lit." Eight identical dormitory towers loom over the main structure. The building is therefore uniform and impersonal in style throughout, with no real privacy or comfort. This anonymity and affectlessness of dormitory life under these conditions, Stephenson suggests, are deeply dehumanizing and promote irresponsibility. He makes it clear, though that the madness does not end at the walls of the American Megaversity, taking swipes along the way at the news media and AM's board of trustees. Geeks The role of geeks in all this is interesting. The story's sort-of-protagonist, Casmir Radon, is a resumed-ed physics student in his 30s, with no social skills. He's an anomaly at American Megaversity, since he's there hoping to learn things by attending classes, an agenda alien to the partiers, zealots, time-markers and wheeler-dealers who make up the bulk of the school's population.

Fred Fine, the head of MARS, has a flimsy grasp on reality (brought on, Stephenson fashionably hints, by too much life-action D&D), but, interestingly, is exceptionally suited to the post-collapse plex, and his Grand Army of Shekondar the Fearsome becomes a major power, primarily due to their posession of the All-Purpose Plex Armed Strife Mobile Unit (APPASMU), a tank designed for dormitory hallways, a project originally built as a joke.

One subplot concerns the battles of Virgil Gabrielson with the Worm, a malicious program written by the previous maintaner of the school mainframe, which Gabrielson describes at one point as "probably the greatest intellectual achievement of the ninteen-eighties."

After civilization has collapsed, down in the science departments, "research and classes continued obliviously. Most of the [math/science] folks regarded the whole war/riot as a challenge to their ingenuity."

The computer use in The Big U is a glimpse into the twilight of the Mainframe Age. Some students write their papers on PCs, but all hacking is centered on the Janus 64 mainframe, with its custom OS, the Operator, mastery of which gives Virgil Gabrielson demiurgic power in the school's little universe.

In general, Stephenson mocks the nerds of American Megaversity quite sharply, particularly the members of MARS, but he also presents their isolation from reality as a psychological and practical survival skill when reality is an inhospitable place.

Pick this book up at Amazon.

Discussion Questions:

1. What are Stephenson's views on relativism? How does his assesment of its results compare with that in The Diamond Age?
2. Compare and contrast AM President S.S. Krupp with Uncle Enzo in Snow Crash.
3. What American college is AM a parody of?
4. Does Ephram Klein's carefully-plotted murder of his ex-roommate make him a less sympathetic character? Does his vindication on the issue of bicamerality indicate that he is also correct on the role of the building in the breakdown of Plex civilization?
5. Were the giant rats really necessary? I mean, really?
6. Which character(s) are autobiographical?

First Prediction: January l, 2000. People will be ticked off to suddenly realize the Millenium is a year away. Join Sir Arthur Clarke, me, a Princeton plasma physicist and hopefully hordes of geeks and nerds in the first 21st century Slashdot Predict-A-Thon. Your history of the 21st century is as good -- and as welcome -- as anybody else's.

If you read one geeky non-fiction book this year, you might want to make it Sir Arthur C. Clarke's "Greetings, Carbon-Based Bipeds!", crammed with enough ideas, arguments and predictions to keep any techno-head going for months.

Predictions are only a tiny part of this ultra-brilliant collection of essays, whose topics range from 1930's visions of rockets and radar to space flight, quantum physics and sci-fi ruminations.

But Sir Arthur's visions of the 21st century are prescient and succinct. I've listed some of them here, followed by a few of my own (so identified) and one or two from a Princeton physicist and e-mail pal. Throw in your own:

From Sir Arthur Clarke:

2002. The first commercial device that produces clean, safe power by low-temperature nuclear reactions goes on the market. Economic and geopolitical catacylsms follow, and on December 10, for their (controversial, to say the least) discovery of so-called cold fusion, Pons and Fleischmann receive the Nobel Prize for Physics.

2004. First (publicly admitted), lab-created, human clone is introduced.

2012. Aerospace planes enter regular commercial service.

2014 Construction begins on the Hilton Orbiter Hotel, built by assembling and converting the giant shuttle tanks that had previously been allowed to fall back to Earth.

2009. A city in a third world country is devastated by the accidental explosion of an A-bomb in its armory [timely given the news from Japan]. After a brief debate in the United Nations, all nuclear weapons are destroyed.

.

2015. An inevitable by-product of the quantum generator is complete control of matter at the atomic level. Thus the ancient dream of alchemy is realized on a commercial scale, often with surprising results. Within a few years, copper and lead cost twice as much as gold - since they are more useful.

2016. All existing currencies are abolished. The megawatt hour becomes the unit of exchange.

2020. Artificial intelligence (AI) reaches the human level. From now on, there are two intelligent species on Earth - one evolving far more rapidly than biology would ever permit. Interstellar probes carrying AI machines are launched toward the nearer stars.

2021. The first humans on the Red Planet encounter unpleasant surprises.

2025. Brain research finally leads to an understanding of the senses and direct inputs become possible, bypassing eyes, ears, skin, etc. The inevitable result is the Braincap, to which the 20th Century's Sony Walkman was a primitive precursor. Anyone wearing a metal helmet fitting tightly over the skull can enter a universe of experience, real or imaginary - and can even merge in real time with other minds.

2040. The universal replicator, based on nanotechnology, is perfected: any object, however complex, can be created given the necessary raw materials and the appropriate information matrix. Diamonds or gourmet meals can be made literally from dirt.

2050. "Escape from utopia." Bored by life in this peaceful and unexciting era, millions decide to use cryonic suspension to emigrate into the future in search of adventure. Vast "hibernacula" are established in the Antarctic at the lunar poles.

2095. The development of a true "space drive" - a propulsion system reacting against the structure of space time - makes the rocket obsolete and permits velocities close to that of light. The first human explorers set off to the nearby star systems that robot probes have already found promising sites for exploration.

While in no way putting myself in Sir Clarke's class, I'll stick my neck out and offer a few of my own predictions.

Digital Democracy.

2020. Electronic democracy is legally mandated in the United States, replacing some of Congress's pre-Net obstructionist, rhetorical and representative elements and functions. Maybe Congress made some sense in a time when people couldn't around or get information quickly, but less and less as America wires up. States and local municipalities re-create Revolutionary-era town meetings online to resolve regional and local issues.

All elections are tabulated digitally. The fractious, fragmented, eternally unresolvable two-party political-media system on display on Washington-based talk shows daily is gradually replaced by online discussions, research and information-sharing and instant voting that actually resolves issues by majority rule. Washington, like Bonn, is re-engineered from a national capitol to a hi-tech enclave.

Americans vote from polls, neighborhood kiosks, offices or homes using their Citizen ID's and passwords. All legislation is discussed and voted on online, before the government takes action. Congress is eventually abolished. Federal regulatory agencies are de-centralized, their vast Washington bureaucracies disassembled, re-located into smaller parts in diverse places.

E-publishing.

Instead of buying dozens of books a year, readers will buy one - it's pages digitally and graphically constructed to display, then delete or return books that are read - and use their digital tablet repeatedly. The e-books will be indistinguishable from the traditional kind. Each will have it's own text style and graphics, bought, borrowed and returned by wireless modem. Writing will become more open and collaborative, writers sharing ideas, research and the writing process with the people who will buy their works.

Digital Justice.

Non-criminal litigation will be resolved online. Lawyers will post briefs and testimony to pre-assigned Websites, where judges will consider misdemeanor and civil cases and render their verdicts online. Sophisticated legal software programs will sort through testimony and precedents and help make knowledgeable, rapid rulings.

E-cash.

Coin and cash currencies are abolished in favor of virtual money. All retailing becomes global, a free-market economic system permeates the world, and all economies are linked.

Supercomputing emerges as a powerful social tool.

Supercomputers radically accelerate research and information sharing. They cure cancer, blindness and other diseases, retard aging, find genetic keys to ending violence.

The Techno-Wars.

The bloody Technology Wars break out. Small-scale but violent conflicts erupt in many cities as technology-deprived Americans, increasingly condemned to poorly-paying menial jobs or displaced completely by computing technologies, stage riots. This unrest spreads to Third World and technologically-underveloped countries. A violent Luddite movement organizes, conducting a rash of terrorist attacks against technological targets and facilities.

Intelligent Computers

2030. Intelligent (or AI) computers advance to the level of a species, as Arthur Clarke predicts. A-life expands and flourishes, forming separate and distinct communities and traits. These machines demand - and are granted - the same equal rights humans have, including freedom of speech and thought, and the right to vote. AI machines do not, as some sci-futurists have long predicted, seek to violently conquer humanity. But they do compete with humans economically, creating corporations, products and services. Human entrepeneurs like the Bill Gates's of the future are unable to compete, especially in hi-tech arenas.

Genetic Purity.

2040. The United Nations passes bitterly controversial Genetic Purity Acts, mandating that genetic engineering be used to eliminate disease, intellectual inferiority and other human "disorders and malfunctions." "Ugly", "unhealthy", and "emotionally " human beings are not brought to conception. "Abnormal" humans (rent "Gattica" if you haven't already seen it) retreat to distant corners of the world, or begin resistance movements designed to thwart genetic engineering discrimination. Enormous class divides are created between societies with access to medical/genetic engineering and those less developed. The human race becomes homogeneous, boring and culturally unified. Genetic engineering has eliminated disease, prolonged life and destroyed biological individuality.

Predicting the future is a sport, not a science. If there's one reliable predictiction regarding technology, it's that it's not predictable.

In the best spirit of Slashdot and the Web, I've gotten some feedback and a couple of predictions even before the column was written, one from an e-mail pal - Andy Burlingame, who has a BS in Aeronautical & Astronautical Engineering at Ohio State University and is working on a Ph. D. in plasma physics at Princeton.

Even writing here, it's unusual to get the chance to run these ideas by someone as well-qualified as Andy [cburling@Princeton.EDU].

As luck would have it, he's been working on a space plane project called Hypersoar. He said the biggest potential market for space planes is same day package delivery, then the military, then commercial airlines. The biggest problem: "passengers will almost certainly be puking the whole way and will probably have to be wheeled off the plane on stretchers because of the nausea. The upside is that you can go from South Dakota to Tokyo in about an hour and a half."

This technology, says Andrew, should be available by 2020.

Some of his other comments:

"Quantum computing. There are lots of people that can give better guesses than me as far as this subject goes. Recently I've heard they've found two ways to make lots of qbits, the building blocks of quantum computers.

"On the surface of Superfluid, Helium 3 electrons are trapped in potential wells and can act as qbits. Second, very cold silicon can do similar things (see Scientific American from August, I think.)

"Quantum computers make factoring large numbers into primes about as simple as multiplication. All electronic data transmission becomes insecure. Corporations start to rely on paper again. Those space planes will be very important for fast, secure communication. 2020-2025 The NSA might already have this.

" Fusion Power. This will provide a virtually unlimited energy source. From an energy standpoint, with fusion a glass of water has as much energy as a glass of gasoline, and fusion would only use a very, very small fraction of that water (the heavy water.) The big problem: How do you get the energy out of a fast neutron? Predicted benefits: We won't run out of energy when we run out of oil. Electricity from fusion will still cost about the same as electricity from natural gas, so no great social change there. This should be available by 2050.

"Clark's #7, sensory input. I just talked to a professor of neurophysiology here and he told me a few interesting things. He said that we would definitely be able to do this within 100 years. There's lots of research into this area, especially the eyes. Today we have a pad you can wear on your back that has thousands of pins in it. These pins put light pressure on the skin of your back to form a "braille" image of the b/w image from a camera. With practice, people are able to see with their skin. Fully jacking the brain should be do-able by 2100 he says definitely. I think he was being conservative.

"Way, way in the future our society becomes rich enough to put oil and raw materials back into the earth. Recognizing that society could collapse and that it could never recover without all the natural resources we've used, we do put the oil and metal back. Putting it back as it we found it might be a bit silly. Perhaps we will just provide storehouses, but we can't make things too accessible, or the developing society will use all the resources too quickly and never develop the tech to use solar or fusion power and mine the solar system.

"The idea that future civilizations could not rise due to the lack of natural resources was first noted by Niven in the Ringworld series as far as I can tell... I think I sort of remember something like that much earlier from Clark in "Children of the Stars."

"Your predictions certainly seem to be aimed at starting conversations. Lots of people will disagree with you, but they will talk. "

Hope so. Thanks, Andy.

Everybody else, jump on in.

You can pick up the Clarke's book at Amazon.

Duncan Lawie recently reviewed Alfred Bester's The Stars My Destination. This time around, he's taken a look at Kim Stanley Robinson's Antarctica. Click below to read more. Antarctica author Kim Stanley Robinson pages 672 publisher Bantam Books rating 7/10 reviewer Duncan Lawie ISBN 0553574027 summary Compelling description in a slow moving work from the master of hyper-real science fiction. Kim Stanley Robinson is a standard bearer of what has become known as 'Californian science fiction'. The tag seems overly obvious given his early Orange County trilogy but more usefully describes a kind of modestly utopian S.F. which has an awareness of politics and human nature. He is best known for his Mars trilogy.

The situation described at the outset of Antarctica, set a few decades into the future, is a natural progression from the current day. Antarctica is already a home to scientific communities and is becoming a playground for adventurers and the rich. The most remote continent is attracting increasing interest as money and technology bring it within reach. The nature of the Antarctic environment is being affected by human activity in the rest of the world. This, in turn, may also affect us profoundly. These topics are as relevant in Michigan and Melbourne as at McMurdo Station. From these present realities the author attempts to build a gentle plot of science, tourism, ecoterrorism and the value of the last continent to the future of our planet.

KSR seems more interested, however, in the continent itself and its effects on those who spend time there. The novel exhibits in all its characters the profound effect that Antarctica has on those who fall into it's grasp. Wherever else in the world they might go, they are drawn back. Whether they wish to exploit it's wealth or preserve it's austere beauty they are under a spell where simply being in Antarctica makes life more real. Whether shepherding idiot tourists or measuring the compass orienation of random pebbles, these are merely the price paid to be truly alive.

Much of the novel is a travelogue. Sweeping descriptions - the view from above what is now McMurdo Station, the arrival at the South Pole - are reminiscent of Sara Wheeler's travel book Terra Incognita. There are parallels between one protagonist's activities in the Dry Valleys and KSR's own visit as part of the US Antarctic Program's Artists and Writers Program. It is the descriptive aspect of his writing which makes the book worth reading. In fact, KSR writes so convincingly that it can be difficult determine whether what is described is literally true, literally fiction or simply has not yet occurred. Like the Mars trilogy, the writing is such that, looking back, much of what has been read feels like profound personal experience. This is the greatest success of KSR's 'maximalist' style of writing. However, at times the plot slows visibly in order to accommodate the detail. The plot is a servant of exposition and discussion rather than an animator.

An example of this is lengthy discussion of early explorers, principally Scott, Shackleton, and Amundsen who, KSR suggests, form the only shared culture of the continent. It is hardly surprising that this is so: many of the familiar Antarctic places are named by them or for them; they managed several of the final big 'firsts' possible on this planet; they are from the last age of heroes and their stories, though debated and rewritten, are powerful. One protaganist's journey across the ice is a metaphor for coming to terms with both the myth and the reality of the "old boys".

There is a temptation to attempt to fit KSR's works into a single future history. Antarctic science is used in the Mars program. This is as true in the real world as it is in KSR's writing. Antarctica is thematically in accord with the Mars trilogy: there is the intense interest in science and concern for ecological questions; there is a warm, human perspective; there is a cold and unforgiving world. However, this need only mean that this is the work of the same man. He didn't actually visit Antarctica until after the Mars trilogy was virtually finished but, like many of his characters, he wants to go back. This may explain why the novel fits better into the genre of Antarctic writing than into the science fiction genre. There is a danger in this book that the reader may be similarly mesmerised by the ice. Antarctica is a continent that almost no-one initially experiences first-hand and this taste is as honest as any. In a certain sense the novel has been a success if it leads the reader on to Apsley Cherry-Garrard's The Worst Journey in the World and the many books, good and bad, lined up behind that masterpiece.

Pick this book up at Amazon.

Duncan Lawie recently reviewed Alfred Bester's The Stars My Destination. This time around, he's taken a look at Kim Stanley Robinson's Antarctica. Click below to read more. Antarctica author Kim Stanley Robinson pages 672 publisher Bantam Books rating 7/10 reviewer Duncan Lawie ISBN 0553574027 summary Compelling description in a slow moving work from the master of hyper-real science fiction. Kim Stanley Robinson is a standard bearer of what has become known as 'Californian science fiction'. The tag seems overly obvious given his early Orange County trilogy but more usefully describes a kind of modestly utopian S.F. which has an awareness of politics and human nature. He is best known for his Mars trilogy.

The situation described at the outset of Antarctica, set a few decades into the future, is a natural progression from the current day. Antarctica is already a home to scientific communities and is becoming a playground for adventurers and the rich. The most remote continent is attracting increasing interest as money and technology bring it within reach. The nature of the Antarctic environment is being affected by human activity in the rest of the world. This, in turn, may also affect us profoundly. These topics are as relevant in Michigan and Melbourne as at McMurdo Station. From these present realities the author attempts to build a gentle plot of science, tourism, ecoterrorism and the value of the last continent to the future of our planet.

KSR seems more interested, however, in the continent itself and its effects on those who spend time there. The novel exhibits in all its characters the profound effect that Antarctica has on those who fall into it's grasp. Wherever else in the world they might go, they are drawn back. Whether they wish to exploit it's wealth or preserve it's austere beauty they are under a spell where simply being in Antarctica makes life more real. Whether shepherding idiot tourists or measuring the compass orienation of random pebbles, these are merely the price paid to be truly alive.

Much of the novel is a travelogue. Sweeping descriptions - the view from above what is now McMurdo Station, the arrival at the South Pole - are reminiscent of Sara Wheeler's travel book Terra Incognita. There are parallels between one protagonist's activities in the Dry Valleys and KSR's own visit as part of the US Antarctic Program's Artists and Writers Program. It is the descriptive aspect of his writing which makes the book worth reading. In fact, KSR writes so convincingly that it can be difficult determine whether what is described is literally true, literally fiction or simply has not yet occurred. Like the Mars trilogy, the writing is such that, looking back, much of what has been read feels like profound personal experience. This is the greatest success of KSR's 'maximalist' style of writing. However, at times the plot slows visibly in order to accommodate the detail. The plot is a servant of exposition and discussion rather than an animator.

An example of this is lengthy discussion of early explorers, principally Scott, Shackleton, and Amundsen who, KSR suggests, form the only shared culture of the continent. It is hardly surprising that this is so: many of the familiar Antarctic places are named by them or for them; they managed several of the final big 'firsts' possible on this planet; they are from the last age of heroes and their stories, though debated and rewritten, are powerful. One protaganist's journey across the ice is a metaphor for coming to terms with both the myth and the reality of the "old boys".

There is a temptation to attempt to fit KSR's works into a single future history. Antarctic science is used in the Mars program. This is as true in the real world as it is in KSR's writing. Antarctica is thematically in accord with the Mars trilogy: there is the intense interest in science and concern for ecological questions; there is a warm, human perspective; there is a cold and unforgiving world. However, this need only mean that this is the work of the same man. He didn't actually visit Antarctica until after the Mars trilogy was virtually finished but, like many of his characters, he wants to go back. This may explain why the novel fits better into the genre of Antarctic writing than into the science fiction genre. There is a danger in this book that the reader may be similarly mesmerised by the ice. Antarctica is a continent that almost no-one initially experiences first-hand and this taste is as honest as any. In a certain sense the novel has been a success if it leads the reader on to Apsley Cherry-Garrard's The Worst Journey in the World and the many books, good and bad, lined up behind that masterpiece.

Pick this book up at Amazon.

Duncan Lawie recently reviewed Alfred Bester's The Stars My Destination. This time around, he's taken a look at Kim Stanley Robinson's Antarctica. Click below to read more. Antarctica author Kim Stanley Robinson pages 672 publisher Bantam Books rating 7/10 reviewer Duncan Lawie ISBN 0553574027 summary Compelling description in a slow moving work from the master of hyper-real science fiction. Kim Stanley Robinson is a standard bearer of what has become known as 'Californian science fiction'. The tag seems overly obvious given his early Orange County trilogy but more usefully describes a kind of modestly utopian S.F. which has an awareness of politics and human nature. He is best known for his Mars trilogy.

The situation described at the outset of Antarctica, set a few decades into the future, is a natural progression from the current day. Antarctica is already a home to scientific communities and is becoming a playground for adventurers and the rich. The most remote continent is attracting increasing interest as money and technology bring it within reach. The nature of the Antarctic environment is being affected by human activity in the rest of the world. This, in turn, may also affect us profoundly. These topics are as relevant in Michigan and Melbourne as at McMurdo Station. From these present realities the author attempts to build a gentle plot of science, tourism, ecoterrorism and the value of the last continent to the future of our planet.

KSR seems more interested, however, in the continent itself and its effects on those who spend time there. The novel exhibits in all its characters the profound effect that Antarctica has on those who fall into it's grasp. Wherever else in the world they might go, they are drawn back. Whether they wish to exploit it's wealth or preserve it's austere beauty they are under a spell where simply being in Antarctica makes life more real. Whether shepherding idiot tourists or measuring the compass orienation of random pebbles, these are merely the price paid to be truly alive.

Much of the novel is a travelogue. Sweeping descriptions - the view from above what is now McMurdo Station, the arrival at the South Pole - are reminiscent of Sara Wheeler's travel book Terra Incognita. There are parallels between one protagonist's activities in the Dry Valleys and KSR's own visit as part of the US Antarctic Program's Artists and Writers Program. It is the descriptive aspect of his writing which makes the book worth reading. In fact, KSR writes so convincingly that it can be difficult determine whether what is described is literally true, literally fiction or simply has not yet occurred. Like the Mars trilogy, the writing is such that, looking back, much of what has been read feels like profound personal experience. This is the greatest success of KSR's 'maximalist' style of writing. However, at times the plot slows visibly in order to accommodate the detail. The plot is a servant of exposition and discussion rather than an animator.

An example of this is lengthy discussion of early explorers, principally Scott, Shackleton, and Amundsen who, KSR suggests, form the only shared culture of the continent. It is hardly surprising that this is so: many of the familiar Antarctic places are named by them or for them; they managed several of the final big 'firsts' possible on this planet; they are from the last age of heroes and their stories, though debated and rewritten, are powerful. One protaganist's journey across the ice is a metaphor for coming to terms with both the myth and the reality of the "old boys".

There is a temptation to attempt to fit KSR's works into a single future history. Antarctic science is used in the Mars program. This is as true in the real world as it is in KSR's writing. Antarctica is thematically in accord with the Mars trilogy: there is the intense interest in science and concern for ecological questions; there is a warm, human perspective; there is a cold and unforgiving world. However, this need only mean that this is the work of the same man. He didn't actually visit Antarctica until after the Mars trilogy was virtually finished but, like many of his characters, he wants to go back. This may explain why the novel fits better into the genre of Antarctic writing than into the science fiction genre. There is a danger in this book that the reader may be similarly mesmerised by the ice. Antarctica is a continent that almost no-one initially experiences first-hand and this taste is as honest as any. In a certain sense the novel has been a success if it leads the reader on to Apsley Cherry-Garrard's The Worst Journey in the World and the many books, good and bad, lined up behind that masterpiece.

Pick this book up at Amazon.

O'Reilly's Running Linux is something of an established textbook on learning Linux from the beginning to getting deeper in the innards. The latest version is written by Lar Kaufman, Matt Welsh and Kalle Dalheimer. Click below to read the review of the newest edition of the book. Running Linux, 3rd Edition author Lar Kaufman, Matt Welsh, and Matthias Kalle Dalheimer pages 752 publisher O'Reilly rating 9/10 -- reviewer chromatic ISBN 156592469X summary This book tells you what you need to know to install, configure, and begin mastering Linux. Note: this review is based on a Draft copy of Running Linux.

Overview You've decided to take the Linux plunge. You have a computer all set up and you have your shiny new CD in hand. You're excited and nervous all at the same time. You've put in some time on your shell account at work, but you're not a power user. This dual-booting thing might be for you. But the CD just sits there next to the black screen... where do you go from here?

"Running Linux" seeks to take you from that first icy shock of installation to the deep end of recompiling kernels, upgrading system libraries, and tweaking your X configuration.

The intended audience is people with some previous Unix experience who are willing to get their hands dirty under the hood of their installations. There are frequent references to man pages and HOWTOs for gory details.

What's good? The authors take an early distribution-neutral stance, glossing over some of the slick configuration utilities in favor of editing text files. While that may dissuade some users, it has the benefits of being universally applicable as well as more educational.

The section on installation is particularly good, discussing common pitfalls, partitioning techniques (and preferences), and various configurations, including dual booting. The Samba information is also quite good.

"Running Linux" covers a wide scope of other utilities, from Apache to gdb, Tcl/Tk to the GIMP.

What Might Bite Back? There's a lot of material covering a lot of subjects. This means that there's not much fat here -- just the bare essentials. Consider this your roadmap and be ready check the references provided when you need to know more.

Some of the applications covered appear only by personal preference. For example, fvwn, elm, and smail are discussed, while WindowMaker, pine, and sendmail are not. That's not a big issue, however.

Feel free to jump around between the chapters -- the arrangement is more encyclopedic than progressive. Common tools such as vi or Emacs appear in chapter 9, while kernel upgrades and modules show up in chapter 7.

One of the larger limitations in the draft copy was the conspicuous absence of GNOME-related material. Thankfully, the final version includes an appendix written by members of the GNOME team. (One of the authors, Matthias Dalheimer, develops KDE.)

The Bottom Line If you're the curious type, looking to play around with Linux, and you need a little friendly advice and some suggestions on where to look for further information, this is the place to start. If you've used Linux for a while, and want to start understanding your system, this is also the book for you.

Pick this book up at Amazon.

Table of Contents (abbreviated) Preface
Chapter 1. Introduction to Linux
Chapter 2. Preparing to Install Linux
Chapter 3. Installation and Initial Configuration
Chapter 4. Basic Unix Commands and Concepts
Chapter 5. Essential System Management
Chapter 6. Managing Filesystems, Swap, and Devices
Chapter 7. Upgrading Software and the Kernel
Chapter 8. Other Administrative Tasks
Chapter 9. Editors, Text Tools, Graphics, and Printing
Chapter 10. Installing the X Window System
Chapter 11. Customizing Your X Environment
Chapter 12. Windows Compatibility and Samba
Chapter 13. Programming Languages
Chapter 14. Tools for Programmers
Chapter 15. TCP/IP and PPP
Chapter 16. The World Wide Web and Electronic Mail
Appendix A. Sources of Linux Information
Appendix B. The GNOME Project
Appendix C. Installing Linux on Digital/Compaq Alpha Systems
Appendix D. LinuxPPC: Installing Linux on PowerPC Computers
Appendix E. Installing Linux/m68k on Motorola 68000-Series Systems
Appendix F. Installing Linux on Sun SPARC Systems
Appendix G. LILO Boot Options
Appendix H. Zmodem File Transfer

ZDNet reports that David Bowie is now hosting the controversial art exhibition "Sensation" on his website. If you've been in a cave for the last week, this is the British exhibition that is annoying the hell out of NYC mayor Rudy Giuliani. He has said he will pull funding to the Brooklyn Museum, and even Sen. Bob Smith (R-NH) is making political hay in Washington.

Some may recall the NEA flap started in 1989 by a Mapplethorpe photo exhibit (for a recap, try the book Culture Wars ). The threat of censorship has loomed over publicly-funded galleries and artists ever since. The news behind the news is that the internet will now allow a curious country to see the artwork that our government is telling us is evil; ten years ago, all the newspapers could print were lurid descriptions by the would-be censors. Will this make a difference?

I'd like to take a quick moment to welcome Duncan Lawie to our expanding list of book reviewers. Duncan comes from a background of professional book review, and has choosen one of the grand-dames of science fiction novels, Alfred Bester's The Stars My Destination. Click below to learn more about one of the most important works in modern science fiction. The Stars My Destination (also published as Tiger! Tiger! ) author Alfred Bester pages 220 publisher Vintage Books rating 8/10 reviewer Duncan Lawie ISBN 067976780 summary A strong novel which is fresh, readable and relevant over forty years after publication. Alfred Bester was first published in the S.F. pulps in 1939, moved into the comics industry, principally with DC (he created the "Green Lantern Oath"), and went on to radio, television and magazines. Through much of his life, he retained a part-time career in science fiction. He is widely considered part of the S.F. pantheon, with The Stars My Destination, published in 1956, being one of the works to confirm that position.

When the future of the future changes so rapidly it may seem surprising that this book is still in print. In fact, it has recently been republished in Britain with an introduction in which Neil Gaiman claims it as the perfect cyberpunk novel. It also fulfils H.G. Wells recommendation that the science fiction author one particular advance in science and chronicle what follows. In this novel, Bester accepts that faster than light spaceships are impossible and posits a future where individuals can "jaunt" i.e. teleport the self through the power of the mind. The discovery of this possibility as teachable to all, at a greater or lesser level, transforms the society of Earth. With a maximum jaunt in the region of 1000 miles, however, exploration and colonisation of the Solar System occurs in the "old fashioned way". Naturally enough, in the old fashioned way, war breaks out between the outer and inner planets.

So far, The Stars My Destination sits amidst the mainstream of fifties science fiction. John W. Campbell, the influential editor of Astounding (now Analog), felt that accentuated mental and psychic powers would mark the future of humanity; almost every science fiction reader believed that we would occupy the solar system in the near centuries; many in North America felt it inevitable that the history of Earth and her colonies would reflect that of Britain and her American colonies. What makes the book exceptional is the central character, Gully Foyle, "a man of physical strength and intellectual potential stunted by lack of ambition".

The story would not be possible without jaunting and interplanetary conflict but, while these are essential to the structure of the tale, character is the subject. Gully Foyle is a dull creature when the novel begins, who has reacted to life rather than taking part. When the Vorga leaves him to die he begins a transformation, powered by fear, anger and thirst for revenge. He studies the manuals and saves himself, developing into a convincing thug in his first attempts to destroy the Vorga. From this, via despair and continuing desire for revenge, he becomes a master criminal and, perhaps, the saviour of the human race. His actions are counterpointed by Central Intelligence and a radioactive private investigator. Foyle's associates become enemies and his victims become assistants. He is shaped and tempered by blows and adversity.

The book is full of ideas but Bester keeps tight control over them. He displays the broad canvas in the prelude and proceeds to fill it with telling detail - there is no point in putting fences around a spaceport, for example, when anyone can jaunt five miles. The elements of plot are exposed carefully, drawing the reader on as Foyle's fantasy of revenge grows so hugely that the possibility of planetary destruction is well within the bounds. The final revelations telescope the sense of the novel yet again.

There are a few pointers to the age of the book. The language is more formal than most writing today. Sex is implicit and implied rather than explicitly described. Nevertheless, Gully Foyle, unlike so many heroes of S.F.'s first decades, has not dated. He is archetype and individual and he has a tale which demands to be read.

Purchase this book at Amazon.

Related Links

• Analog
• Interzone
• More on Alfred Bester

Something that we all strive for and pride ourselves on is our intelligence. But are there things that can make us smarter then the machines we've made? Clampe takes a look at Donald A. Norman's book Things That Make Us Smart: Defending Human Attributes in the Age of the Machine to find out. Things That Make Us Smart: Defending Human Attributes in the Ag author Donald A. Norman pages publisher Perseus Books rating 8/10 reviewer Clampe ISBN 0201626950 summary Hey, it turns out that we are smart! The Scenario

Many people may be familiar with one of Norman's other books, "The Design of Everyday Things". Well, the good news is that this book is as engaging, and the bad news is that it isn't all that much different. Norman, the uber-advocate of person centered design, uses this book to debunk the motto of the 1933 Chicago World's Fair "Science Finds, Industry Applies, and Man Conforms".

Things That Make Us Smart has a double meaning. Norman spends a decent chunk of this book explaining how humans have very defined cognitive abilities, like pattern recognition. Not only do we have these cognitive abilities, but we're good at them. If you are ever at a cocktail party (which most geeks avoid) and someone says your name, you are likely to pick it up out of a host of other ambient noises in the room. So the first meaning of the title of this book is that humans have abilities that prove we are smart. The second meaning is that we have created cognitive artifacts to extend the limits of our mentalities. These are the "things" that make us smart. Now, we are used to thinking of tools expanding our physical abilities. We use a hammer so we don't pulp our hands while smashing them against the head of a nail. We use a car because we can't run that fast. What Norman explains is that we have also created a ton of tools that help us expand our mind's capability.

It starts with cuneiform. We have bad memories for facts, so when we wanted to remember facts we started writing them on clay tablets. Books were great innovations, since they help us not only remember stuff, but allow us to write down our thoughts and share them with people we'll never meet. Computers have developed as the latest tool we use to expand our cognitive abilities. They do things we can't do very well, and vice versa. We can only hold about 5-7 things in our memory at any one time. Computers can handle lots more. Still, before you start looking for your personal Hal, there are important things that we can do that our computers cannot. Even computers running un a Linux OS. A computer sees a picture of a butterfly as just dots on a screen (yes, I know they are working on this at Bellcore) while we are immediately able to apply meaning to those dots. My favorite example that Norman uses is shooting a free throw. The very things that for us are easy, like identifying the hoop, are incredibly tough for the computer. However, whereas we have big troubles with accuracy the computer can shoot all day once it has figured out the calculation.

Now this would be a great situation if we were intelligent about it. Technology helps us to do the things nature did not wire our brains to do. However, so much of the current market of technology is centered around what the machine needs or can do that we are expecting humans to conform to the technology, making us the tools to the machines. It's an easy trap to fall into. Humans can tolerate a lot of ambiguity. It's one of those things that makes us smart, but Norman argues that we should be designing in a way that augments our lives, not living in a way that validates our design.

What's Good?

This is a great introduction to Donald Norman for those who have not read him. A great bathroom book, you can skip around alot and the examples are engaging. The early part of the book also does a great job of teaching cognitive psychology, with sensical examples and descriptions of human cognitive processes. Also, the theory of user centered design is extremely important, and Norman does a wonderful job of supporting its tenets.

What's Bad? If you already know a lot about Human Computer Interaction, or are pretty good with cognitive psychology, this book may seem to slow. Also, it's only a mild variation on other Norman books, though if you've not read any to this point, start with this one. The second half of the book is light on quantative evidence, but that's more because you've entered the land of large statements about the meaning of life from the author rather than that he doesn't know how to quantify results.

So What's In It For Me?

If you do any programming, or put together sites for general viewing, this is a valuable book for the argument towards user centered design. Almost anyone can find something out of this offering, from the defense of lowly human cognition, to the descriptions of how we can use technology more intelligently.

Other important links... Buy this book at Amazon .

Buy Norman's latest book, The Invisible Computer, which we'll review soon. If you're interested in serious usability engineering, this is the book to get, Usability Engineering by Jakob Nielsen.

Something that we all strive for and pride ourselves on is our intelligence. But are there things that can make us smarter then the machines we've made? Clampe takes a look at Donald A. Norman's book Things That Make Us Smart: Defending Human Attributes in the Age of the Machine to find out. Things That Make Us Smart: Defending Human Attributes in the Ag author Donald A. Norman pages publisher Perseus Books rating 8/10 reviewer Clampe ISBN 0201626950 summary Hey, it turns out that we are smart! The Scenario

Many people may be familiar with one of Norman's other books, "The Design of Everyday Things". Well, the good news is that this book is as engaging, and the bad news is that it isn't all that much different. Norman, the uber-advocate of person centered design, uses this book to debunk the motto of the 1933 Chicago World's Fair "Science Finds, Industry Applies, and Man Conforms".

Things That Make Us Smart has a double meaning. Norman spends a decent chunk of this book explaining how humans have very defined cognitive abilities, like pattern recognition. Not only do we have these cognitive abilities, but we're good at them. If you are ever at a cocktail party (which most geeks avoid) and someone says your name, you are likely to pick it up out of a host of other ambient noises in the room. So the first meaning of the title of this book is that humans have abilities that prove we are smart. The second meaning is that we have created cognitive artifacts to extend the limits of our mentalities. These are the "things" that make us smart. Now, we are used to thinking of tools expanding our physical abilities. We use a hammer so we don't pulp our hands while smashing them against the head of a nail. We use a car because we can't run that fast. What Norman explains is that we have also created a ton of tools that help us expand our mind's capability.

It starts with cuneiform. We have bad memories for facts, so when we wanted to remember facts we started writing them on clay tablets. Books were great innovations, since they help us not only remember stuff, but allow us to write down our thoughts and share them with people we'll never meet. Computers have developed as the latest tool we use to expand our cognitive abilities. They do things we can't do very well, and vice versa. We can only hold about 5-7 things in our memory at any one time. Computers can handle lots more. Still, before you start looking for your personal Hal, there are important things that we can do that our computers cannot. Even computers running un a Linux OS. A computer sees a picture of a butterfly as just dots on a screen (yes, I know they are working on this at Bellcore) while we are immediately able to apply meaning to those dots. My favorite example that Norman uses is shooting a free throw. The very things that for us are easy, like identifying the hoop, are incredibly tough for the computer. However, whereas we have big troubles with accuracy the computer can shoot all day once it has figured out the calculation.

Now this would be a great situation if we were intelligent about it. Technology helps us to do the things nature did not wire our brains to do. However, so much of the current market of technology is centered around what the machine needs or can do that we are expecting humans to conform to the technology, making us the tools to the machines. It's an easy trap to fall into. Humans can tolerate a lot of ambiguity. It's one of those things that makes us smart, but Norman argues that we should be designing in a way that augments our lives, not living in a way that validates our design.

What's Good?

This is a great introduction to Donald Norman for those who have not read him. A great bathroom book, you can skip around alot and the examples are engaging. The early part of the book also does a great job of teaching cognitive psychology, with sensical examples and descriptions of human cognitive processes. Also, the theory of user centered design is extremely important, and Norman does a wonderful job of supporting its tenets.

What's Bad? If you already know a lot about Human Computer Interaction, or are pretty good with cognitive psychology, this book may seem to slow. Also, it's only a mild variation on other Norman books, though if you've not read any to this point, start with this one. The second half of the book is light on quantative evidence, but that's more because you've entered the land of large statements about the meaning of life from the author rather than that he doesn't know how to quantify results.

So What's In It For Me?

If you do any programming, or put together sites for general viewing, this is a valuable book for the argument towards user centered design. Almost anyone can find something out of this offering, from the defense of lowly human cognition, to the descriptions of how we can use technology more intelligently.

Other important links... Buy this book at Amazon .

Buy Norman's latest book, The Invisible Computer, which we'll review soon. If you're interested in serious usability engineering, this is the book to get, Usability Engineering by Jakob Nielsen.

Something that we all strive for and pride ourselves on is our intelligence. But are there things that can make us smarter then the machines we've made? Clampe takes a look at Donald A. Norman's book Things That Make Us Smart: Defending Human Attributes in the Age of the Machine to find out. Things That Make Us Smart: Defending Human Attributes in the Ag author Donald A. Norman pages publisher Perseus Books rating 8/10 reviewer Clampe ISBN 0201626950 summary Hey, it turns out that we are smart! The Scenario

Many people may be familiar with one of Norman's other books, "The Design of Everyday Things". Well, the good news is that this book is as engaging, and the bad news is that it isn't all that much different. Norman, the uber-advocate of person centered design, uses this book to debunk the motto of the 1933 Chicago World's Fair "Science Finds, Industry Applies, and Man Conforms".

Things That Make Us Smart has a double meaning. Norman spends a decent chunk of this book explaining how humans have very defined cognitive abilities, like pattern recognition. Not only do we have these cognitive abilities, but we're good at them. If you are ever at a cocktail party (which most geeks avoid) and someone says your name, you are likely to pick it up out of a host of other ambient noises in the room. So the first meaning of the title of this book is that humans have abilities that prove we are smart. The second meaning is that we have created cognitive artifacts to extend the limits of our mentalities. These are the "things" that make us smart. Now, we are used to thinking of tools expanding our physical abilities. We use a hammer so we don't pulp our hands while smashing them against the head of a nail. We use a car because we can't run that fast. What Norman explains is that we have also created a ton of tools that help us expand our mind's capability.

It starts with cuneiform. We have bad memories for facts, so when we wanted to remember facts we started writing them on clay tablets. Books were great innovations, since they help us not only remember stuff, but allow us to write down our thoughts and share them with people we'll never meet. Computers have developed as the latest tool we use to expand our cognitive abilities. They do things we can't do very well, and vice versa. We can only hold about 5-7 things in our memory at any one time. Computers can handle lots more. Still, before you start looking for your personal Hal, there are important things that we can do that our computers cannot. Even computers running un a Linux OS. A computer sees a picture of a butterfly as just dots on a screen (yes, I know they are working on this at Bellcore) while we are immediately able to apply meaning to those dots. My favorite example that Norman uses is shooting a free throw. The very things that for us are easy, like identifying the hoop, are incredibly tough for the computer. However, whereas we have big troubles with accuracy the computer can shoot all day once it has figured out the calculation.

Now this would be a great situation if we were intelligent about it. Technology helps us to do the things nature did not wire our brains to do. However, so much of the current market of technology is centered around what the machine needs or can do that we are expecting humans to conform to the technology, making us the tools to the machines. It's an easy trap to fall into. Humans can tolerate a lot of ambiguity. It's one of those things that makes us smart, but Norman argues that we should be designing in a way that augments our lives, not living in a way that validates our design.

What's Good?

This is a great introduction to Donald Norman for those who have not read him. A great bathroom book, you can skip around alot and the examples are engaging. The early part of the book also does a great job of teaching cognitive psychology, with sensical examples and descriptions of human cognitive processes. Also, the theory of user centered design is extremely important, and Norman does a wonderful job of supporting its tenets.

What's Bad? If you already know a lot about Human Computer Interaction, or are pretty good with cognitive psychology, this book may seem to slow. Also, it's only a mild variation on other Norman books, though if you've not read any to this point, start with this one. The second half of the book is light on quantative evidence, but that's more because you've entered the land of large statements about the meaning of life from the author rather than that he doesn't know how to quantify results.

So What's In It For Me?

If you do any programming, or put together sites for general viewing, this is a valuable book for the argument towards user centered design. Almost anyone can find something out of this offering, from the defense of lowly human cognition, to the descriptions of how we can use technology more intelligently.

Other important links... Buy this book at Amazon .

Buy Norman's latest book, The Invisible Computer, which we'll review soon. If you're interested in serious usability engineering, this is the book to get, Usability Engineering by Jakob Nielsen.

Thanks to D3 for reviewing Stephen Northcutt's Network Intrusion Detection: An Analysis Handbook. Recently published, this book is designed for those of you trying to keep people outside of your machines. Click below for more. Network Intrusion Detection: An Analyst's Handbook author Stephen Northcutt pages 267 publisher rating 8/10 reviewer D3 ISBN summary Any company or group that is serious about doing Intrusion Detection should read this book. Background

I have been learning about real computer and network security since January of this year. Thankfully I have been working under someone who really knows his stuff and once worked with the author, Stephen Northcutt. I have attended SANS '99 in Baltimore and will be at the New Orleans conference in October. I am by no means an expert on security or cracking. However, it is one of the most interesting aspects of what I do. I feel this book will be an essential tool in my career development.

To me the field of computer network security seems like a blossoming flower. Yes, people have been hacking, cracking, and fixing systems since the dawn of computing. However, I firmly believe once the we have recovered from the Y2K hangover, security will be the big buzz. You can already see it happening in the media with the attention certain incidents have had.

So where does Northcutt's book fit in? If you are an admin charged with securing the way your company interacts with other companies, the internet, your internal employees, e-mail, etc. this book can be an excellent resource. Keep in mind that Intrusion Detection is not a starting point. It is an integrated part to the overall picture. Having cool intrusion detection at your site does little good if you don't even have a decent firewall, acceptable use policies, e-mail filters, safe CGI's on your web, and current patch levels to your systems. Yes, you will be able to know where you were cracked from but you will have still been cracked. Likewise, if you don't understand networking and protocols to an advanced admin level this book may be a bit intimidating.

A search for Network Intrusion Detection on Amazon on Monday showed me a total of 3 titles on the subject and Northcutt's was one of them. He is certainly an expert in the field, having been the lead on the Navy Shadow Intrusion Detection Team for DoD, as well as being the current Chief Information Warfare Officer for the U.S. Ballistic Missle Defense Organization.

The Book

The best advice on how to get the value out of this book comes from the opening of chapter 6 which reads "If you do not have a lot of experience with Internet Protocol (IP), here's a suggestion to get the most out of this book: read Chapters 6, 7, and 8 twice." Northcutt starts out with a review of the Mitnick attack on Tsutomu Shimomura's system. The format of using real world examples carries throughout the rest of the book. His writing style is much the same as his lectures at SANS. He draws you in to interact with the examples he has chosen. Instead of just pointing out what he wants you to see he will ask you to think about what part of a given signature is important. Then he'll ask you to go back and look again for what he feels important. I wish textbooks in college were written this way because it helped me learn.

Included with Ch. 1 is a review of TCP/IP packet structure. Chapter Two carries on with introducing signatures and filters. This clearly explains how to tell what particular attack the script kiddie used to bring down your site. The chapter on Architectural Issues is a nice overview of sensor placement, hardware, and other implementation factors. This comes off as a little light with respect to comparing and contrasting, especially with regard to choice of OS. To be fair, these generalities will probably help keep the book relevant in the ever changing world of OS/Hardware combo. The final two chapters prior to the critical 6, 7, and 8 trio, deal with important factors to consider a good IDS solution should have and a review of known commercial and government software. Unfortunately the rapid changes involved in this field prevent a complete overview of all the available products out there. My suggestion is to read Ch. 4 more closely if you are about to make a decision on an IDS. It will help you ask the right questions to get the solution which will best suit your needs.

As I alluded to above, Chs. 6 through 8 are the guts of the book. The tcpdumps give you a real insider's view of what some classic attacks look like. Again, Northcutt is very thourough in what he presents. The exploits, like the IDS solutions, are also an ever evolving series and there is no way to write a book to cover them all. The point here is to begin to educate the eyes of the analyst. Only someone who has an idea of what traffic is normal versus what smells can hope to make good decisions when it comes to sounding the alarm. As Northcutt points out, sometimes the difference is as subtle as what port is being used. He is encouraging in that you can find the signature "fingerprint" of a given attack. He even admits that there are strange patterns he's seen but has not yet solved what tool or script was used to generate them.

Chapter 9's Introduction to Hacking takes you from the target to the attacker. With data from a crack where the attacker forgot to remove the history file, you can see how quickly a box can be 'owned'. Ten gives a look into coordinated attacks while Eleven shows some of the tools of the trade. The final chapters deal with convincing management to do things the right way and gives a taste of where IDS is heading. I don't mean to downplay the importance of these chapters. Keep in mind that the best way to play with cool toys on your job is to have management backing!

Summary

Any company or group that is serious about doing Intrusion Detection should read this book. Northcutt's tongue in cheek humor keeps things from getting too heavy. His reference to the best remote NT administration tool being a car had me chuckling for a while. The information provided is very thorough. His examples are clear and informitive. The areas where I wanted more information, he provides links to help follow up. I wouldn't be surprised if crackers used this as a reference to develop ways around detection and so the cycle will continue. I should also add the book went through technical review by Tim Aldrich, M. Dodge Mumford (of NFR), Judy Novak, and Larry Paccone.

Purchase this book at Amazon.

Contents

Acknowledgments

Tell Us What You Think

Introduction

Shadow History

Shadow Friends

1. Mitnick Attack

2. Introduction to Filters and Signatures

3. Architectural Issues

4. Interoperability and Correlation

5. Network-Based Intrusion Detection Solutions

6. Detection of Exploits

7. Denial of Service

8. Intelligence Gathering Techniques

9. Introduction to Hacking

10. Coordinated Attacks

11. Additional Tools

12. Risk Management and Intrusion Detection

13. Automated and Manual Response

14. Business Case for Intrusion Detection

15. Future Directions

Index

Dava Sobel's "Galileo's Daughter" is a brilliant, deeply moving account of the life of Galileo, a primal geek who altered the way humans look at the world, and of his tragic and mysterious relationship with his brilliant daughter, cloistered in a convent. "Galileo's Daughter" author Dana Sobel pages 419 publisher Walker rating 9/10 reviewer Jon Katz ISBN 0-8027-1343-2 summary Brilliant and powerful account of one of the first geeks

Albert Einstein considered Galileo Galilei to be "the father of modern physics - indeed of modern science altogether."

In a sense, the obsessive, rebellious and gadget-minded Galileo (1564-1642) was one of the first Geeks, and in the context in which he lived and worked, one of the bravest.

He was brilliant, humble and funny, qualities rarely seen in contemporary geeks and nerds, or anybody much. He was profoundly grateful to be able to use science to seek out the truth. In 1609, he set up a telescope in the garden behind his house, pointed it skyward, and saw never-before-seen stars and constellations.

"I render infinite thanks to God for being so kind as to make me alone the first observer of marvels kept hidden in obscurity for all previous centuries. "

It was gracious of Galileo to offer thanks, since he himself received precious few acknowledgements in his lifetime. He sent his out-of-wedlock daughter off to a convent when she was 12 and never saw her again, then ran afoul of the Catholic Church and the Inquisition for his heretic notion that the earth and planets revolved around the sun.

Yet, while he never set foot outside his native Italy, his discoveries rocked the world. His most remarkable invention, the telescope, enabled him to alter the conventional reality of the civilized world and to reinforce the then - stunning argument that the Earth moves around the sun. In a sense, he hacked the universe, attacking and solving the biggest problem in both science and theology. For this, he was hauled before the Holy Office of the Inquisition, accused of heresy, and forced to spend the final years of his life under house arrest.

Of his three illegitimate children, the oldest, (born Virginia in 1600, but re-named Suor Maria Celeste after she took vows of poverty and retreated permanently from the world, since illegitimate daughters were considered unfit for marriage) shared Galileo's brilliance and love of science.

She became his most determined supporter and prolific-letter-writing confidante, though he never saw her again. Her letters and life (his to her at the convent were destroyed once he was targeted by the Inquisition).

Dava Sobel's "Galileo's Daughter: A Historical Memoir of Science, Faith and Love," by (Walker, US $27) expands the story of Galileo, his amazing accomplishments, adding his heart-breaking relationship with his daughter. It's a stunning book, beautiful and powerful, and it brings us back to the Florence of the Medicis and the papal court during an era when humanity's very perceptions of its place in the universe was being upended by one brave man.

In our time, Galileo would probably have ended up a zillionnaire, profiled on "Dateline" and shifting his stock-option wealth from one fund to another. In his own, he was tried and found guilty of heresy, "ordered in the name of His Holiness the Pope and whole body of the Holy Office to the effect that the said opinion that the Sun is the center of universe and the Earth moves must be entirely abandoned, nor might he from then on in any way hold, teach, or defend it by world or in writing; otherwise the Holy Office would proceed against him," which would have meant torture and death.

As the foreword to the book itself explains, this isn't a mawkish contemporary family story.

"Theirs is not a tale of abuse or rejection or intentional stifling of abilities. Rather, it is a love story, a tragedy and a mystery."

People who love science, technology and exploration will be knocked out by this volume, with its wealth of illustrations and gorgeous design. So will people who simply love a great and brilliantly-rendered story.

Pick this book up at Amazon.

SEGV has returned and is continuing his excellent set of reviews. This time around, we're looking at Martin Fowler's (with Kent Beck, John Brant, William Opdyke, and Don Roberts) Refactoring: Improving the Design of Existing Code. Click below for more details. Refactoring: Improving the Design of Existing Code author Martin Fowler with Kent Beck, John Brant, William Opdyke, pages 431 publisher Addison-Wesley rating 9/10 reviewer SEGV ISBN summary Just what the working programmer ordered: a catalogue of practical refactorings with solid advice on when and how to apply them.

Overview

This book could very well do for refactoring what the "Gang of Four" book did for design patterns. In fact, with the number of contributing authors, this might well become known as the "Gang of Five" book. (They contributed content to chapters 3 and 12 through 15.)

Organization

Refactoring leaps in feet first with an extended example. I found this to be a surprisingly effective opener: it didn't overwhelm me, and left me hungry for more. The first chapter follows a sample program through several incremental refactorings, and the reader gets the idea via osmosis.

To illustrate the technique of refactoring, the first chapter presents the original code on the left page, and the resulting code on the right, with changes in bold. This presentation, coupled with explanatory text, makes it easy to see what's going on and focus on what's happening. It's as if you're looking over the author's shoulder as he edits, compiles, and tests code in his development environment.

What is Refactoring?

Now that you've done a refactoring, you might be curious to know more about what refactoring is. The next few chapters provide the relevant background.

Refactoring is what the book's subtitle suggests: changing code in in ways that preserve behaviour, but improve the way that behaviour is generated. This could be as trivial as renaming a method, or as tricky as separating domain and presentation classes.

Why go through this trouble? In the end, the code is different but it acts the same; there has been no new functionality added. Why? You do this to place yourself in a better position to add new functionality to the software. If you don't, you eventually end up with spaghetti code that is unmaintainable and will not support new functionality at all.

I think anyone who has worked on real code can appreciate the need for refactoring. In fact, most good programmers already do it, although perhaps only on a subconscious level. What this book aims to do is to raise that ad-hoc activity to a higher level of applied technique. Just as there are principles and practices in GUI design (as opposed to merely throwing widgets together randomly), there are principles and practices in refactoring activity: this book catalogues them.

Catalogue

Sandwiched between introductory and summary chapters is the meat of the book: a catalogue of over seventy refactorings. This catalogue follows in the footsteps of the highly successful Design Patterns format: Pattern Name and Classification, Intent, Also Known As, Motivation, Applicability, Structure, Participants, Collaborations, Implementation, Sample Code, Known Uses, and Related Patterns. Since the individual refactorings are less complex than patterns, this catalogue uses the format: Name, Summary, Motivation, Mechanics, and Examples.

The idea is the same. The name and summary provide a definitive vocabulary and a reference-card example. The motivation explains the relevance of the refactoring. The mechanics cover the step-by-step details of how the refactoring is executed. Then a series of examples demonstrate the variations.

Applicability

I like the catalogue. Although some refactorings seem deceptively trivial, it is useful to have them laid out in step-by-step detail. You never know when you will make a mistake, and when you absolutely positively must fix a bug or add a feature by the next day, and need to refactor to do it, slow and steady wins the race.

Further, other refactorings are not so trivial and familiar, and it is certainly useful to have their traps and pitfalls exposed. Frequently, they rely on the smaller refactorings themselves.

I can see this book becoming well-used in a shop with plenty of production code.

Supplementary Material

The non-catalogue chapters are informative as well. I especially appreciate the metaphor of bad smells in the code: the "if it stinks, change it" philosophy is the perfect counter-point to the oft-cited "if it ain't broke, don't fix it" mentality.

The chapter on refactoring tools discusses the possibility of automating much of the mechanical work of refactoring. Although there is a Refactoring Browser for Smalltalk, I suspect that Java and C++ versions are a little ways off. I'd wager that, as with the UML, tool support will lag industry practice for some time.

Style

As always, the author's writing style is down-to-earth and easy to read. Martin tells you straight up what he's found useful and what he hasn't. He tells you where he's made mistakes, and where the risk is less pronounced.

I like the way he goes through an example, then goes through it again under different conditions, thereby revealing the many-splendoured variations. Frequently he continues examples that were left off from other refactorings.

Plenty of further reading is suggested; I always like that.

Flaws

The book has a Java focus, and that is the language used for the examples. There is some mention of Smalltalk and C++, but not much; far less than Design Patterns, for example. Still, the book is quite understandable to anyone with object-oriented development experience.

The book references design patterns; some refactorings even apply and manipulate patterns. However, I wish there were more direct references to the Design Patterns book. That would especially help those new to both refactorings and design patterns.

There are a few minor typos (nothing major), so check the author's web site for errata and try to get a recent printing if you can.

Recommendation

It's no secret that I think this is a book whose time has come. I'm hoping it will codify my approach to refactoring, to help me be more efficient in my development.

I recommend this book as both a practical catalogue, and as a general work on the theory and practice of refactoring. I think that the refactoring community will grow much as the patterns community before it, and that we will see more published on the subject.

Until then, this book is a good start.

Purchase this at Amazon.

TABLE OF CONTENTS

Foreword
Preface
1. Refactoring, a First Example
2. Principles in Refactoring
3. Bad Smells in Code
4. Building Tests
5. Toward a Catalog of Refactorings
6. Composing Methods
7. Moving Features Between Objects
8. Organizing Data
9. Simplifying Conditional Expressions
10. Making Method Calls Simpler
11. Dealing with Generalization
12. Big Refactorings
13. Refactoring, Reuse, and Reality
14. Refactoring Tools
15. Putting It All Together
References
List of Soundbites
Index

In his new book, "Weaving the Web," Tim Berners-Lee describes how he created the WWW and his vision and hope for it. Any declarations from this brilliant and selfless man are important and worth paying attention to, but brace yourself: the writing style is somewhere between low-key and comatose, the vision noble but almost hopelessly naive. Weaving The Web author Tim Berners-Lee pages 225 publisher Harper San Francisco, US $26 rating 6/10 reviewer Jon Katz ISBN summary How the Web Was Weaved; Where the Web Should Go

Tim Berners-Lee seems to be as nice as he is brilliant, which almost makes one fear for him and the future of his amazing creation, the World Wide Web.

It also makes for a curiously out-of-focus book. It's hard to overstate the importance of his invention; but his own version of the experience is about as exciting as a Pop-Tart. Berners-Lee was one of Time magazine's selections as the 100 greatest minds of the Twentieth Century. This is almost surely true, but doesn't necessarily translate into white-knuckle story-telling.

"Hope in life comes from the interconnections among all the people in the world," he writes near the conclusion of "Weaving The Web," (cowritten by Mark Fischetti, published by Harper San Francisco, $US 26).

"We believe that if we all work for what we think individually is good, then we as a whole will achieve more power, more understanding, more harmony as we continue the journey. We don't find the individual being subjugated by the whole. We don't find the needs of the whole being subjugated by the increasing power of an individual. But we might see more understanding in the struggles between these extremes?"

Then again, we might not. Genius programmers tend to be inward-looking, understandably, and Berners-Lee appears either not to hear or not to want to pay much attention to the frenzied pace of Web development and change. He's much too reflective.

Should we then feel that we're getting smarter as we evolve, he muses? Not really. "Just better connected - connected into a better shape. The experience of seeing the Web take off by the grassroots effort of thousands gives me tremendous hope that if we have the individual will, we can collectively make of our world what we want."

Any declaration by Berners-Lee is an important one, given who he is and what he's done. But it's a good thing he's occupying the 3Com Founders chair at the MIT Laboratory for Computer Science, where perhaps he can work and think, safe from the rapacious Great Whites circling his creation.

As most Slashdot readers know, Berners-Lee is the Oxford-educated physicist who patched together the software that became the World Wide Web while working at the CERN physics lab (the name CERN comes from the name of the International council, the Conseil Europeen pour la Recherche Nucleaire, which created the lab) outside Geneva.

In the tradition of the brilliant architects of the modern Internet and WWW - Vint Cerf, Jonathan Postel, Linus Torvald - Berners-Lee chose not to make billions from his ideas, but to use his prodigious gifts instead to keep the culture as free and accessible as possible.

For the past five years, he has served as director of the World Wide Web Consortium, whose goal is to ensure that the fundamental software for identifying and sharing information on the Web remains a public, widely accessible standard. This is a monumental political notion, one little appreciated in the offline world, where the very idea of distributing information freely seems traumatizing.

If the Consortium succeeds, there will be something approaching universal access to the Web. If it doesn't, the Web will go the way of mainstream media and become corporatized, privatized, fragmented and soul-less. And some people - but not its inventor - will profit even more from it than they already do.

Berners-Lee is puzzled by the insistence of so many U.S. interviewers on asking about his failure to cash in on the Web. He made eBay, eTrade and Amazon possible, but hasn't made a nickel from them himself.

His failure to grasp the elemental reality of American capitalism permeates this book. "What is maddening," he writes is the "terrible notion that a person's value depends on how important and financially successful they are, and that that is measured in terms of money." No American would wonder at this idea, which is not only terrible but at the heart of American life.

It's also critical to "Weaving the Web," which divides into two parts. The first tells the story of how the author embraced hyptertext and invented the Web in the face of widespread apathy and indifference from his colleagues. This makes for interesting but already widely reported history -- in Web-time, almost ancient. Then there is Berners-Lee's style, which is somewhere between low-key and comatose.

Describing widespread collegial resistance to his ideas at a pivotal moment, he writes: "Some people were intrigued, but many never accepted my argument. Rather than enter into useless debate, I simply forged ahead with HTML and showed the Web as much as possible."

He relates how in l991 he released his "World Wide Web" program to a limited number of CERN researchers. "Word spread within the high-energy physics community," he recalls,"furthered by the cross-pollinating to travel." The Web was born. This is actually the dramatic high point in the book.

The second part of "Weaving The Web" describes how the Web might be kept open despite all the mounting pressures to seal off chunks of it, which is the true drama facing the Web.

Berners-Lee's creation is no longer the exclusive playground of brilliant and creative hackers, nerds, geeks and academics; the big boys are massing at the gate. Entertainment and retailing are the Web's two biggest functions these days, along with e-trading. Increasingly, the ethos behind the Web isn't connectivity but greed.

Berners-Lee seems to float above this harsh, increasingly Darwinian reality. His dream is to have the Web become a much more powerful means of collaboration between people - a place where users come not only to browse but to create - and have those collaborations extend to computers. "Machines become capable of analyzing all the data on the Web - the content, links, and transactions between people and computers."

Both parts of Berners-Lee's dream are admirable, if not exactly stirring, but they're oddly disconnected from the ferocious practicalities of Web design, economics and competition. They're also written in so flat, technical and inaccessible a way that the non-geek hasn't got a prayer, a lost opportunity from an author sure to be remembered as a seminal technological figure of the century.

One of the Internet's great ironies is that it's grown so dramatically and remained so free primarily because none of the most powerful institutions in American life - government, journalism, business - paid it much attention in the first decades of its existence. It exploded before Congress, regulatory agencies, corporations, lawyers or the mass media had a chance to curb, control, exploit or acquire it.

That is, sadly, no longer the case. The predators are paying a lot of attention. Government regulators and law enforcement authorities are drooling over the Net and Web as unclaimed bureaucratic turf. Powerful institutions like law, medicine and education are frantic about the open sourcing of information - the sometimes involuntary use, re-use and sharing of information once closely held and copyright.

And business has now grasped that the techno-economy - in a few years, economists estimate the Net will be a trillion dollar economy in its own right - isn't winding down but just cranking up. The Web has become, for all these parties, too important to ignore.

Not surprisingly, Berners-Lee argues for the continued universality of the Web across the spectrum of human invention. People and organizations may have different motivations for putting things on the Web, but "for information to be universal, it can't discriminate between these. The Web must include information that is free, very expensive, and every level in between. It must allow all the different interest groups to put together all manner of pricing and licensing and incentive systems and always, of course, allow the user to just say no."

We need this kind of univerality, Berners-Lee argues, because that's how people operate in the real world. If the Web is to represent and support the "web of life" off-line, it has to cross all kinds of social, cultural and geographic boundaries.

A good argument, and well made. But what does it really mean?

The problem for the reader is that it's hard to find anybody arguing that the Web shouldn't be open - including the people trying to cordon it off and suck it dry. The problem with the way this book is written is that it ensures that mostly, Berners-Lee will end up preaching to the converted. He fantasizes about where the Web ought to go, but don't look for any useful guidance in how to actually get there.

The Web's next major stage, he writes, has enormous promise to radically increase the creative productivity of groups, corporations, society, depending on the evolution of new technical standards that the Web consortium is developing.

If the Web's first stage was about addressing and presenting documents, the next --- based on XML (extensible mark-up language) and RDF (resource description framework) -- may allow the Web to become more intuitive, intelligent and logical. The benefits are obvious, Berners-Lee says, the dangers a "Balkanization of the Web."

If companies, for example, insist on creating their own XML tags that aren't universally readable, the Web would no longer be an open medium for sharing information.

How would Berners-Lee prevent this from happening? How can anyone?

His simplistic response: support the Web Consortium in its fight as guardian of the Web.

As its creator, Berners-Lee is already one of the century's most influential scientists. But reading "Weaving the Web," one senses that his scientific skills are way ahead of his political and cultural instincts.

Fair enough. Supporting the Web Consortium is a worthy idea; it's hard to believe all but a handful of those reading this review on Slashdot would disagree.

But Berners-Lee is almost naïve in interpreting the political, cultural and economic context in which the battle for an open Web will will take place, and how profoundly different that environment is from the one facing the Internet's architects when they were designing domain names and protocols a generation ago.

He underestimates the rapacious power of American capitalism, especially the new media variety. The Information Age has spawned a whole new breed of corporate monsters - CBS Viacom, Time Warner, Microsoft, the Sun-Netscape Alliance, AOL, the computer companies, the telcoms - whose very existence depends on controlling chunks of the new digitally-sparked economy, sealing territory off and charging for access to information and services.

None of these billion-dollar powerhouses are likely to fall quietly in behind the Web Consortium because it's the right thing to do. Armed with lawyers, capital, and lobbyists who are influential in shaping policies in Washington, they're moving towards the Net with a fury.

They're not likely to encounter much in the way of organized resistance. Most Americans on the Web are amusing themselves with games and movie sites, e-trading or shopping. The computing professionals at the core of Web design and commerce take their freedom online for granted; they've never experienced any other reality.

In the United States, corporations have only one ideology: make the most money at all times in the most expedient way. There's no room in their management philosophies for ceding money to equalizing fantasies about the Web. If the Web is to remain as open and universally accessible as Berners-Lee and millions of others would like, there is only one way that's going to happen - head for the trenches and join in one of the bloodier brawls in the history of capitalism.

Because the Web is so individualistic a medium, with the technology surrounding it evolving so rapidly, it's difficult to imagine it being ovewhelmed by even these behemoths in the same way they've gobble up much of the rest of American culture and journalism. But it's not nearly as impossible as sometimes arrogant and spoiled nerds and geeks like to think.

Apart from the dangers of corporatism, the American political culture is one of the more primitive in the West. In Scandanavia countries have worked feverishly to wire up their governments, schools and residents. Not here. Presidential candidates like Elizabeth Dole have made restricted access to the Internet the centerpieces of their campaigns. Even techno-political opportunists like Clinton and Gore spend more time talking about V-Chips than Net access for kids. The primary response of the U.S. Congress to the emergence of the Net and the Web has been to pass not one but two laws restricting freedom of speech online. Blocking and filtering technologies have proliferated.

This week, in fact, a German policy research group teamed up with a U.S. scholar of the First Amendment to urge the creation of an international rating and filtering system for the Internet, a step towards the irrational and censorious rating systems that already presume to make movies and TV shows "safe" for children. The proposal generated substantial media attention and approval in the United States.

Overall, the response to the Web's growth hasn't been a movement to ensure universal access to digital technology, but a campaign to regulate, curb and privatize the net and the Web.

Despite all the hype about the government's efforts to rein in Microsoft's aggressively monopolistic business practices, few analysts believe the federal government is really a match for gargantuan Microsoft, or can actually curb its power.

If Berners-Lee has identified the right issue - keeping the Web open and free -- "Weaving the Web" stumbles badly in offering concrete solutions. An open Web won't depend on standards and protocols nearly as much as on politics and power. The epic political struggle of the 21 st Century looks to be about individualism versus corporatism, and the Net and the Web will be prominent battlegrounds.

Berners-Lee is heroic in his creativity and selflessness, but unless you want to fling "Weaving The Web" at the charging legions of the Sun-Netscape Alliance, his literary venture isn't as useful or inspiring as the author or his great creation.

Purchase this book at Amazon.

Thanks to darrn chamberlain for an excellent review of the Lincoln Stein and Doug MacEachern book Writing Apache Modules with Perl and C. This is an excellent book for those considering working with Apache and mod_perl, and helpful for C programmers. Click below for more details. Writing Apache Modules with Perl and C author Li pages 724 publisher O'Reilly, ISBN: 156592567X rating 9.5/10 reviewer darren chamberlain ISBN summary Absolutely essential for anyone who is considering using Apache and mod_perl. C programmers may need more. The Scenario

If you're like me, your first introduction to Perl ^[?] was in the form of CGI ^[?] scripts. A few years ago, I inherited a few dozen ancient CGI scripts (Perl and otherwise) that required Immediate Attention. CGI led to Perl, and to Apache ^[?] ; Perl and Apache led, naturally enough, to mod_perl ^[?] , once I started hitting the performance bottlenecks inherenent in CGI programming. After researching mod_perl, building a mod_perl-enalbed Apache, and reading all the available online documentation, I got it up and running--and I was suitably impressed.

So, when O'Reilly ^[?] announced a book devoted to programming Apache with Perl, I was extremely excited. The book starts with an introduction and history of web programming, introduces CGI and other types of web programming (server API ^[?] 's, such as ISAPI and NSAPI; embedded processors, such as mod_perl, mod_dtcl, and mod_pyapache; FastCGI; Java ^[?] servlets ^[?] ; ActiveX ^[?] ; and client-side scripting languages, such as VBScript ^[?] and JavaScript ^[?] ), and then describes the Apache module architecture, using some simple examples ("Hello, World" in Perl and in C). Then it gets good, covering dynamically generated content; the hobgoblin of HTTP, state; and all the other stuff that gives CGI programmer nightmares (like authentication and authorization).

What's Bad?

Although the title reads '... with Perl and C', the emphasis is very obviously on Perl. The C API reference chapters (chapters 10 and 11, pages 505 through 631) are very thorough, but almost all the examples are in Perl only. In fact, the authors go so far as to recommend that almost all Apache modules be written in Perl, and not C, except for very small modules or modules that need that extra speed boost or small memory footprint of being compiled into the server (page 13: "Anything you can do with the C API you can do with mod_perl with less fuss and bother."). Their reasoning is sound: mod_perl modules and scripts require a server restart at most, and often not even that, while for C modules, Apache itself must be recompiled; but I was expecting more in this area, perhaps a larger section on using DSO. After the book was published, however, several of the Perl-only examples were ported to the C API, and are available for download.

A few of these examples have already been published, and in these cases the book is mostly redundant. Notably, the Apache::NavBar module (which Lincoln uses on the server in his lab) and the Apache::AdBlocker module (chapters 4 and 7), appeared in The Perl Journal last year (issues 12 and 11). This is not that big a deal, since both of these modules are incredibly useful and probably deserve to be published in a few more places, but two brand new modules would have been most welcome, especially since the book's target audience probably also reads The Perl Journal.

What's Good?

There's a lot to like here. Since I'm a Perl programmer by trade and disposition, I personally liked the fact that 99.9% of the examples were written in Perl. With only a few exceptions, the modules could be copied into the right locations and run immediately; the exceptions were the modules that made use of either other programs (Chapter 5's Hangman program which uses a relational database to store state information) or specialized Apache features (Chapter 7's Apache::AdBlocker module, which requires proxy functionality).

Much of the text and all of the source code is available on the web at www.modperl.com. Chapters 6, 7, 8, and 9 can be found on the web site for the book, as can all the Perl modules and some of the examples in functional form (Apache::Magic and hangman).

Chapter 9 is the key chapter, and the heart of the book. It describes in great detail all the Apache:: modules. If you use mod_perl at all, download and print this chapter. Memorize it. Use your favorite indexing script to make it searchable. Everything you need to know about mod_perl is here in this chapter.

The appendices are also excellent, although, because it is an Apache book, I would have figured that several of the sections would be regular chapters, and not relegated to the end. The appendices are divided pretty evenly between concentrating on Perl and on C, unlike most of the rest of the book.

So What's In It For Me?

Fortunately for people like me, there is a lot of information about mod_perl on the web; The Perl Journal has had several articles on it, WebMonkey has had an article or two, and so on. There is a comprehensive mod_perl developer's guide on the offical Apache/Perl site. Lincoln Stein uses it a lot on his site and in his software. And, of course, we have the man pages and perldocs. So why do we need a book?

A few reasons. First and foremost, few of those sources go into the kind of detail that this book does, while still being approachable. Second, the book focuses on Apache, programming Apache, and (to a lesser extent) programming applications on the web; Perl and C are the means here, not the end. The in-depth technical discussions are about Apache: how it translates URI's to filenames, how it handles subrequests and internal redirects, how it maps files to MIME types. It then presents techniques for usurping these functions, customizing each phase of the reponse process, and explains when and why you would want to do this, instead of letting Apache do it's own thing. Creating checksums on the fly, compressing and decompressing data, creating extremely flexible HTML preprocessors, and modifying outgoing and incoming headers are some just some of the given examples.

The reference chapters are probably the single most valuable thing about the book. If you are a Perl programmer on a budget, you can download chapter 9 from the web site, but the C programmers out there have to buy the book to get the C API refernce. The C reference is 2 chapters (126 pages) long, and covers all the functions in precise detail.

For those among you who are using Microsoft operating systems, the book pays special attention to building, installing, and configuring mod_perl and Apache on Win32 systems, where it is different from Unix and Unix-like systems. Most of the actual modules are very similar (except for the obvious ones, such as scripts that call sendmail and the scripts that access MySQL), but the installation and building of mod_perl (or ApacheModulePerl.dll) are very different. The process is described in enough detail to make it possible, without boring those readers to whom it is irrelevant.

Conclusion

Programming Apache/mod_perl without this book is like writing Perl without the camel book. It can be done, but it is much easier and more enjoyable with the book. The writing is clear, informative, straight-forward, and, at times, amusing. The authors are the definitive sources for information on mod_perl and CGI programming, and this is reflected in every aspect of the book. While not as definitive for C programmers, it is still the best Apache API reference out there, other than the actual source code itself.

Purchase this book at Amazon.

Errata Table of Contents

1. Server-Side Programming with Apache
2. A First Module
3. The Apache Module Architecture and API
4. Content Handlers
5. Maintaining State
6. Authentication and Authorization
7. Other Request Phases
8. Customizing the Apache Configuration Process
9. Perl API Reference Guide
10. C API Reference Guide, Part I
11. API Reference Guide, Part II

1. Standard Noncore Modules
2. Building and Installing mod_perl
3. Building Multifile C API Modules
4. Apache:: Modules Available on CPAN
5. Third-Party C Modules
6. HTML::Embperl--Embedding Perl Code in HTML

Given the recent well deserved critical acclaim that surrounds Neal Stephenson's Cryptonomicon , we thought it would be good to also remember that he's written other great books as well. Clampe has graciously offered to review Stephenson's prior book. Click below for more details. The Diamond Age or A Young Lady's Illustrated Primer author Neal Stephenson pages 499 publisher Bantam Books rating 9/10 reviewer Clampe ISBN summary Interesting offering from everyone's new favorite The Scenario

First off, let me say we know that Diamond Age came out 1995. It is not our intention to review every book ever written, but Stephenson has received so much attention lately from Cryptonomicon that it is of some use to show that he did not spring fully formed from the head of Zeus. For those old school fans of Stephenson, this review will allow them to sit in renewed righteousness, while helping the new fan pick their next Stephenson read, assuming they managed to pound through all nine hundred plus pages of Cryptonomicon.

I'm going to spare you the book synopsis other than to say that this is a science fiction novel set in the not too distant future. It is heavy into nanotechnology, and treats the subject with insight and forethought. The real glory of this book, however, is in its examination of the nature of intelligence, human social interaction, and culture.

Stephenson crafts a very believable story centered around a genius nanotechnologist who breaks the rules of his tribe to help his daughter, and the young girl from a poor background he inadvertantly helps. The development of Nell, the tortured child who rises above her early experiences, allows the author to dive deeply into the differences between knowledge and intelligence, offering up a richly detailed conversation with the reader.

What's Bad?

There are passages in the book where the protagonist is in a computer story of sorts, engaged in a fantasy setting. While these pieces aren't bad per se, I treated them a little like the poetry fragments in Tolkien. They're OK sometimes, but I skipped them maybe more than I should have. There is also a very annoying character named Miranda who seems superfluous to the story to me.

The other trouble I have with the book is the way it ends. Now Stephenson, like Orson Scott Card, seems to have a damned tough time ending a book. For Card it stems from deep personal philosophies, but I'm not sure that's the case for Stephenson. Still, while the last five pages of the book slide, it does not detract significantly from the rest of the book.

What's Good?

Alot. First of all, this is a very believable view of life after nanotechnology hits its stride. It's also a great forecast on future geopolitical tensions, and how the next century will deal with group identification when physical distance is overwhelmed by omnipresent communications.

Still, the most enjoyable part of this book is the examination of what makes people both intelligent and driven. Stephenson seems to say that a rough childhood can sometimes create an adult who is super intelligent. Many Slashdotters may agree with this sentiment. Though it's not a completely convincing argument, it is good to see a book treat it not in just a singular character sense, but as a larger social phenomenon.

So What's In It For Me?

Reading this book will not only satisfy that craving for quality science fiction, but will make you think also. Very few writers are able to do that, and Stephenson seems to have it down. It's one of those books where a few weeks after finishing it you'll still turn some of its ideas around in your noggin. It's probably not as good as Cryptonomicon, but it's pretty darned close.

Go buy this book. Do whatever it takes to convince Stephenson to continue writing quality science fiction.

Other important links... Check out the Slashdot review of Cryptonomicon .

Buy this fine text at Amazon

Probably a good number of you have read Ender's Game, an amazing science-fiction novel by Orson Scott Card ^[?] . That book was followed by a seris of books starring Ender, the main character from Ender's Game. Now Card is taking us back to the time of the first book and telling the story again through different eyes. Thanks to J. Patrick Narkinsky and boog3r for writing review of the new book Ender's Shadow Ender's Shadow author Orson Scott Card pages 380 publisher To rating 9/10 reviewer dave@lpb.net & patrick@freeware.org ISBN summary Card's latest in the Ender Saga details the life of Bean J. Patrick Narkinsky's Review

Like most geeks of my age, I greatly enjoyed the book Ender's Game by Orson Scott Card. This book describes the story of a child (named Ender) who is selected at the age of six for special training to lead an army against an alien species. Ender, like most geeks, experienced profound isolation from most of his contemporaries -- in part because of his exceptional intelligence.

Ender's Game was followed by three sequels. None of the sequels were as good as the original; in them, Ender lost his edge and became a relatively moderate man rather than a brilliant child. Because of this, I was frankly not expecting much from Card's latest attempt. Especially Since Ender's Shadow does something that is almost unprecedented in fiction: it re-tells the events of Ender's Game from the perspective of a relatively minor character in Ender's Game.

My first thought when I heard the premise of this book was "Oh no... Card has turned into another Piers Anthony". I thought that Card was probably beating a great story and a good fictional "universe" to death by trying to go to the bank with it too many times.

I was pleasently surprised. While Ender's Shadow recounts the same basic events reported in Ender's Game, it does them in a genuinely fresh manner; from a fresh point of view. When Robert Heinlein tried to retell stories in his later books, the result was always horrible, hackneyed plots. Card has succesfully avoided this pitfall, mainly by adding substantial original material not found in Ender's Game. This book doesn't just try to connect with Ender's Game. It has its own story to tell.

Most importantly, this book is not about Ender Wiggin: it is about Bean. It starts with Bean, as a child of around four ("he thinks") on the streets of Rotterdam. The first section of the book gives us a glimpse of Bean's life as a child, without parents, on the streets of Rotterdam. It is not long before Bean is under mortal danger from an older child on the streets, and is fortunate enought to make his way into Battle School through little more than good luck.

In Battle School, Bean is like a second Ender. He is as bright as Ender. However, unlike Ender, Bean is isolated from the students and in league with the teachers. It is made clear throughout that Bean is the second string; that he is there in case Ender fails and his primary task is often to make sure that Ender does not fail.

This arrangement brings out Card's peculiar genius as writer: writing about brilliant children in a way that is actually reminiscient of what brilliant children have actually experienced. Bean, like most geeks, experiences profound isolation. Yet, somehow he thrives on this. Some of his abilities (for example a remarkable ability for logical induction) remind me of the things which isolated me in my youth.

The bottom line is that I enjoyed Ender's Shadow for the same reasons that I enjoyed Ender's Game: great writing, good plot, and excellent characters. Most of all, like its predecessor, Ender's Shadowreminds me that I am not in fact alone in the memories of my school years; that at least one writer must have experienced the isolation that I felt because he can write about it so well.

Dave Hauser (boog3r)'s Review

I think the hardest part about writing a review on a good SciFi book is that you can't candidly discuss details on the subject matter. You end up with a nice paradox: How to convince the reader the book was actually good without telling much about the subject matter. You must instead rely upon the delivery and tale-weaving skill of the author while glossing over the details of the first twenty pages of the book for bait.

My experience with Card's writing is not complete, but what stories of his I have managed to read have sent my imagination places few other authors have managed. Heinlein and Card both take my mind and heart for great roller coaster rides through a menagerie of worlds. Ender's Shadow is what you might call a 'synquel' to Ender's Game. It takes the life of Bean and tells the same tale through his eyes. An interesting and very daunting task considering the magnitude of Ender's game. I believe Card delivered with a full platter, maybe out-doing Ender's Game a little too much.

Bean is a small child living in poverty on the streets of a futuristic Rotterdam. He is a boy with an interesting history and an even more interesting future. Facing certain starvation he joins a 'family' comprised of other maligned children formed on the street and rides the wave to a spot in Battle School. While there he learns about, studies and eventually meets and befriends the star of Ender's Game, Ender Wiggin. They unite in a quest to tame Battle School and prepare for a war against the 'Buggers' or Formics, a species of insectoids governed by a hive mind. Throughout the book there are numerous intertwinings, embellishments and explanations of events from Ender's Game; but told from a different viewpoint so as to be completely new. If it has been a while since you have read Ender's Game, much of it will be new and you will find yourself looking for that old, beat up copy you have lying around.

Downs

If anything might be wrong with this book it is the power Card bestows upon Bean. From what you get out of the first book it seems Ender is the main man running the show, he is the commander and the others are subordinates (not to mention good friends). I can't be sure if it was indeed Card's plan to elaborate on Ender's story and place Bean as the glue-holding-everyone-together. In many ways Bean eclipses Ender in certain skills but they both have their own independent strong points.

One thing Card should have incorporated was hyperlinks to corresponding passages between the two books. I'll be looking eagerly for this...

Ups

This book rocks! It paints a whole new picture of a world many of us love and cleans up a canvas that was already subjected to the brush. Card deftly intertwines a new story into an old and meshes them together into a new entity. A lot of work went into cross-referencing the two story lines and then individual quotes. Card even went to the trouble of adding new insight on characters that appear later in the series as having had contact with Bean during his stint on the streets of Rotterdam.

Slants

I admire Card himself through his writings, it warms me to think there are people who try to write without bias on a certain subject when advantage can be taken. If Card is guilty of this commonality I see it mainly as altruism on his part, trying to improve humanity in his small part through his books. One undertone does surface through most of his books: faith or religion. Parts of his stories will almost always have a thought on faith or theology. Sometimes it is educational in nature, rarely is it preachy. More often it enhances and adds to the story where other authors might use it to thump the proverbial soapbox.

In the Future

If Card is willing and imparts upon us a new volume in the Ender Saga, I would love a telling of the political intrigue Demosthenes and Locke play and how Achilles becomes a weak link in the Russian play for power.

Purchase this book at Amazon

Probably a good number of you have read Ender's Game, an amazing science-fiction novel by Orson Scott Card ^[?] . That book was followed by a seris of books starring Ender, the main character from Ender's Game. Now Card is taking us back to the time of the first book and telling the story again through different eyes. Thanks to J. Patrick Narkinsky and boog3r for writing review of the new book Ender's Shadow Ender's Shadow author Orson Scott Card pages 380 publisher To rating 9/10 reviewer dave@lpb.net & patrick@freeware.org ISBN summary Card's latest in the Ender Saga details the life of Bean J. Patrick Narkinsky's Review

Like most geeks of my age, I greatly enjoyed the book Ender's Game by Orson Scott Card. This book describes the story of a child (named Ender) who is selected at the age of six for special training to lead an army against an alien species. Ender, like most geeks, experienced profound isolation from most of his contemporaries -- in part because of his exceptional intelligence.

Ender's Game was followed by three sequels. None of the sequels were as good as the original; in them, Ender lost his edge and became a relatively moderate man rather than a brilliant child. Because of this, I was frankly not expecting much from Card's latest attempt. Especially Since Ender's Shadow does something that is almost unprecedented in fiction: it re-tells the events of Ender's Game from the perspective of a relatively minor character in Ender's Game.

My first thought when I heard the premise of this book was "Oh no... Card has turned into another Piers Anthony". I thought that Card was probably beating a great story and a good fictional "universe" to death by trying to go to the bank with it too many times.

I was pleasently surprised. While Ender's Shadow recounts the same basic events reported in Ender's Game, it does them in a genuinely fresh manner; from a fresh point of view. When Robert Heinlein tried to retell stories in his later books, the result was always horrible, hackneyed plots. Card has succesfully avoided this pitfall, mainly by adding substantial original material not found in Ender's Game. This book doesn't just try to connect with Ender's Game. It has its own story to tell.

Most importantly, this book is not about Ender Wiggin: it is about Bean. It starts with Bean, as a child of around four ("he thinks") on the streets of Rotterdam. The first section of the book gives us a glimpse of Bean's life as a child, without parents, on the streets of Rotterdam. It is not long before Bean is under mortal danger from an older child on the streets, and is fortunate enought to make his way into Battle School through little more than good luck.

In Battle School, Bean is like a second Ender. He is as bright as Ender. However, unlike Ender, Bean is isolated from the students and in league with the teachers. It is made clear throughout that Bean is the second string; that he is there in case Ender fails and his primary task is often to make sure that Ender does not fail.

This arrangement brings out Card's peculiar genius as writer: writing about brilliant children in a way that is actually reminiscient of what brilliant children have actually experienced. Bean, like most geeks, experiences profound isolation. Yet, somehow he thrives on this. Some of his abilities (for example a remarkable ability for logical induction) remind me of the things which isolated me in my youth.

The bottom line is that I enjoyed Ender's Shadow for the same reasons that I enjoyed Ender's Game: great writing, good plot, and excellent characters. Most of all, like its predecessor, Ender's Shadowreminds me that I am not in fact alone in the memories of my school years; that at least one writer must have experienced the isolation that I felt because he can write about it so well.

Dave Hauser (boog3r)'s Review

I think the hardest part about writing a review on a good SciFi book is that you can't candidly discuss details on the subject matter. You end up with a nice paradox: How to convince the reader the book was actually good without telling much about the subject matter. You must instead rely upon the delivery and tale-weaving skill of the author while glossing over the details of the first twenty pages of the book for bait.

My experience with Card's writing is not complete, but what stories of his I have managed to read have sent my imagination places few other authors have managed. Heinlein and Card both take my mind and heart for great roller coaster rides through a menagerie of worlds. Ender's Shadow is what you might call a 'synquel' to Ender's Game. It takes the life of Bean and tells the same tale through his eyes. An interesting and very daunting task considering the magnitude of Ender's game. I believe Card delivered with a full platter, maybe out-doing Ender's Game a little too much.

Bean is a small child living in poverty on the streets of a futuristic Rotterdam. He is a boy with an interesting history and an even more interesting future. Facing certain starvation he joins a 'family' comprised of other maligned children formed on the street and rides the wave to a spot in Battle School. While there he learns about, studies and eventually meets and befriends the star of Ender's Game, Ender Wiggin. They unite in a quest to tame Battle School and prepare for a war against the 'Buggers' or Formics, a species of insectoids governed by a hive mind. Throughout the book there are numerous intertwinings, embellishments and explanations of events from Ender's Game; but told from a different viewpoint so as to be completely new. If it has been a while since you have read Ender's Game, much of it will be new and you will find yourself looking for that old, beat up copy you have lying around.

Downs

If anything might be wrong with this book it is the power Card bestows upon Bean. From what you get out of the first book it seems Ender is the main man running the show, he is the commander and the others are subordinates (not to mention good friends). I can't be sure if it was indeed Card's plan to elaborate on Ender's story and place Bean as the glue-holding-everyone-together. In many ways Bean eclipses Ender in certain skills but they both have their own independent strong points.

One thing Card should have incorporated was hyperlinks to corresponding passages between the two books. I'll be looking eagerly for this...

Ups

This book rocks! It paints a whole new picture of a world many of us love and cleans up a canvas that was already subjected to the brush. Card deftly intertwines a new story into an old and meshes them together into a new entity. A lot of work went into cross-referencing the two story lines and then individual quotes. Card even went to the trouble of adding new insight on characters that appear later in the series as having had contact with Bean during his stint on the streets of Rotterdam.

Slants

I admire Card himself through his writings, it warms me to think there are people who try to write without bias on a certain subject when advantage can be taken. If Card is guilty of this commonality I see it mainly as altruism on his part, trying to improve humanity in his small part through his books. One undertone does surface through most of his books: faith or religion. Parts of his stories will almost always have a thought on faith or theology. Sometimes it is educational in nature, rarely is it preachy. More often it enhances and adds to the story where other authors might use it to thump the proverbial soapbox.

In the Future

If Card is willing and imparts upon us a new volume in the Ender Saga, I would love a telling of the political intrigue Demosthenes and Locke play and how Achilles becomes a weak link in the Russian play for power.

Purchase this book at Amazon

The return of Doc Technical is marked by his review of the upcoming O'Reilly book Mastering Algorithms with C. Click below if you wish to learn more about this Kyle Loudon book. Mastering Algorithms with C, 1st Ed. August 1999 author Kyle Loudon pages 560 publisher O'Reilly and Associates, ISBN= rating 6.5/10 reviewer Doc Technical ISBN summary A flawed but wide-ranging book for intermediate toexpert programmers. [Reviewers Disclaimer: This review is based on a pre-publication copy of the book, so some changes may have occurred in the published copy. Most of my comments relate to structure and content, and I expect they'll remain valid.]

There are many books on programming algorithms, and quite a few of them use C for their examples, but even so, I was looking forward to this new book from O'Reilly.

Most of the existing algorithm books were designed as college text books. While they have their place, there is certainly room for a book that approaches the subject matter in the informal, clear writing style and practical focus that is O'Reilly's trademark. Unfortunately, for me at least, Mastering Algorithms in C was not that book.

My Problem with Algorithms One of O'Reilly's strengths has always been their attention to the structure of their books. O'Reilly books are usually well designed, with logical and reader-friendly layouts. But Mastering Algorithms with C has a layout that I found somewhat vexing.

The chapter on linked lists serves to illustrate. An introductory section describes three kinds of lists, then briefly describes several applications for them (mailing lists, memory management, scrolled lists in GUIs, etc.). This is followed by a brief section describing the basic concepts of linked lists.

>From there the chapter moves directly to an implementation of linked lists, starting with a section called "Interface for Linked Lists". This section enumerates each function in a linked list library. For each function we are given its function prototype, followed by its return value, a brief description of the function's purpose, and finally, its algorithmic complexity in O-notation.

The next section is called "Implementation and Analysis of Linked Lists". After a paragraph describing some data structures, we are presented with a listing of the C header file, list.h, followed by a lengthier description of each of the functions described in the previous section. Finally, we are presented with a code listing of list.c.

And this is where I started having a problem.

First, I feel the author plunges much too quickly into implementation before providing a proper context. Let's assume that the reader knows nothing about linked lists (that's why, after all, they bought the book). Before describing a specific implementation, shouldn't the reader be clued in on the basic operations (independent of the implementation language) performed on linked lists: adding a node, deleting a node, etc.? While a little of this is given early on, the author seems in a rush to move on to the implementation.

And when we have the implementation described, the information is spread across (at least) three locations. For example, the function list_ins_next is first introduced in the "Interface" section, its prototype is shown in the list.h file, a more detailed description is provided in the "Implementation" section, and finally the actual code is presented in the list.c code listing. This forces the reader to jump around quite a bit to get all the info about each function.

How Much Should the Reader Know? How much should the writer assume you know about linked lists (or any of the other algorithms described in this book)? If the reader already understands the basic concepts of linked lists, and if they're already a C programmer, they most likely wouldn't need this book. So let's assume the reader is starting at ground zero (or its general vicinity) when it comes to linked lists.

If that's the case, then I would expect the writer to present a relatively "bare bones" implementation, at least for basic algorithms like lists.

Instead, what is presented is an almost object-oriented implementation with init and destroy functions, function pointers, and other details that may provide a clean implementation but may be an impediment to the authors primary duty: teaching the reader the algorithm.

For much the same reasons, I found many of the examples out of sync with what was being taught. While virtual memory paging schemes are a lot of fun, they're a hell of a thing to spring on some poor sucker trying to grasp the concept of linked lists.

Finally, I had some problems with the author's prose style. This may be more my preconception of how an O'Reilly book should read. Luckily, you can (and should) make your own decision. O'Reilly has Chapter 13, Numerical Methods, available at their web site.

But Wait While I have problems with this book, I don't mean to imply the book is bad. It's a fair book, I just don't think it's great book. It covers a lot of territory. For me, its main fault is that it fails to explain concepts clearly and basically enough before diving into the code.

On the plus side, I found the figures that illustrate concepts throughout the book to be clear and helpful. The selection of which algorithms to cover is also quite good, as these are all areas that a wide variety of programmers will face at some point in their work.

If you already have a moderate understanding of the algorithms, and want a text that presents a clear and documented implementation of them, then you may want to consider this book.

Pick this book up at Amazon.

Table of Contents:

Preface

1. Preliminaries
   1. Introduction
   2. Pointer Manipulation
   3. Recursion
   4. Analysis of Algorithms
2. Data Structures
   1. Linked Lists
   2. Stacks and Queues
   3. Sets
   4. Hash Tables
   5. Trees
   6. Heaps and Priority Queues
   7. Graphs
3. Algorithms
   1. Sorting and Searching
   2. Numerical Methods
   3. Data Compression
   4. Data Encryption
   5. Graph Algorithms
   6. Geometric Algorithms

Scott McCartney's Eniac is a beautifully researched, immensely readable, and surprisingly poignant look at the two men who worked for three years in the frenzied atmosphere of World War II to successfully build Eniac, the world's first digital, electronic computer.

One of the most amazing things about their very overdue story is that most of us have never heard of either of them.

ENIAC: The Triumphs and Tragedies of The World's First Computer author Scott McCartney of the Wall Street Journal pages 262 publisher Walker rating 8/10 reviewer Jon Katz ISBN summary The forgotten men who built the world's first computer

Quiz:

Who invented the telephone?

The electric light bulb?

Launched the first manned flight?

We all know, of course. We've been schooled from the age of five to know. The creators of some of the greatest American technology are legends, household words, patriotic icons and shamans, their homes and labs turned into historic landmarks and museums.

But who built the first electronic computer?

A group of sixth-grade New Jersey students, asked that question earlier this year, divided their responses between Bill Gates and Steve Jobs. A nine-year-old Virginia student guessed, "Radio Shack."

The fact that most people - even on a website like this - have no idea of the answer is why Scott McCartney's "ENIAC: " "the Triumphs and Tragedies of the World's First Computer" is such a smart and timely book. Talk about prophets without honor.

Computing hit like the Big Bang. The International Data Corporation (IDC) estimates the amount of commerce conducted over the World Wide Web will top $1 trillion by 2003. Yet the Net's history is murky. The people who profit from modern computers are well known, but the people who actually developed them are forgotten.

Last week, as the Internet celebrated its 30th birthday, a scientist present at the UCLA lab (the first node of ARPAnet was installed at the UCLA Network Measurement Center, where a research group connected the IMP to their Sigma 7) where it was partially created told a reporter that nobody even bothered to take a picture.

Scott McCartney, a staff writer for the Wall Street Journal, decided to remedy that sad reality. His book tells the virtually unknown story of two scientists, the late John Mauchly and Presper Eckert, and their tenacious three-year struggle to build the legendary ENIAC in a secret workshop at the University of Pennsylvania. Mauchly and Eckert are rarely written about in computer anthologies and histories, not even mentioned in Stephen Segaller's otherwise thorough "Nerds 2.0.l, A Brief History Of The Internet" published last year. A plaque at the University of Pennsylvania commemorates the spot where ENIAC was put together, but doesn't even list the names of its inventors.

Mauchly and Eckert were obsessed with the idea of using electricity to make computing machines "think." Ridiculed and ignored by their colleagues, they found unlikely benefactors in the U.S. Army, desperate to find some way to calculate artillery shell trajectories as the Allies were getting chopped to bits attacking entrenched German positions in Italy and World War II.

Despite the fact we more or less know how it turns out, "ENIAC" is a scientific thriller, with McCartney skillfully and knowledgeably tracing the assembling of this unprecedented machine, with its countless vacuum tubes, cables and gears.

Although ENIAC was commissioned at the beginning of the War, Mauchly and Eckert didn't finish it until the fall of 1945, as peace descended. It had taken 200,000 man-hours of work and cost $486,804.22. What the Army got for its money was a thirty-ton monster that filled 1,800 square feet - the size of a three-bedroom apartment in many cities. What the rest of us got was modern computing, the Net and the World Wide Web.

ENIAC had forty different units, including twenty accumulators, arranged in the shape of a U, all connected by a ganglion of heavy black cable as thick as fire hose. It was 1,000 times faster than any numerical calculator, 500 times faster than any existing computing machine. In thirty seconds, ENIAC could calculate a trajectory, something that would require twenty hours with a desk calculator, or fifteen minutes on the machine then called the Differential Analyzer. Today's supercomputers, ENIAC's descendants, can perform the same task in three microseconds.

In the wrong hands, this would be a potentially Byzantine and impenetrable tale, but McCartney presents it with the perfect blend of skill, clarity, and most remarkably, humanity. He never forgets, or lets us readers forget, that like any story about technology, this is really a story about human beings. Mauchly and Eckert are well-drawn, fully developed characters in this powerful but ultimately sad, story.

Although the pair worked brilliantly together to build ENIAC, in the aftermath, their relationship, their work and their personal lives all suffered. Beset by back-stabbing, academic and legal intrigues, their own great naivete, and by financial and private setbacks, they were outflanked and financially outmaneuvered by other scientists, and by IBM and other emerging firms. Although they belatedly filed a patent on ENIAC, they spent much of the rest of their lives unsucessfully defending their invention against legions of claimants and competitors.

Worse, they have been almost universally forgotten by the astonishing subculture they made possible - at least, until now.

"ENIAC" is a not only a compelling and entertaining read, but offers the added satisfaction of helping right one of the more egregious oversights of the Information Age.

Purchase this book at Amazon.

Thanks to our own Justin for the review of author Havoc Pennington (excellent name)'s GTK+/Gnome Application Development. Click below to learn more.

GTK+/Gnome Application Development author Havoc Pennington pages 492 publisher New Riders: ISBN 0-7357-0078-8 rating 6.5/10 reviewer Justin ISBN summary Learn how to develop a GNOME application from scratch using gnome-libs and various GNU development tools. Master the canvas, and expand your knowledge of GTK+/GDK/glib while you're at it. The book is released under an open license so that the book will have no problems keeping up to date with whatever is current in GNOME. It is browseable on the web at http://developer.gnome.org/doc/GGAD/ and can be checked out from GNOME CVS - it is in the GGAD module.

The book is not just a simple explanation of gnome-libs. Rather, it is a book meant to take you from beginning to end of a full GNOME application. GGAD starts off just where it should, with a ~50 page review of glib and GTK+. These sections were fairly well written, and I was able to understand them well. Keep in mind, however, that they are not for beginning glib/GTK+ hackers. The internals of how the libraries work are sometimes mentioned and I can imagine them being confusing to the first time GTK+ hacker. More advanced hackers can probably skip most of these sections, but even an intermediate GNOME hacker could gain a better understanding of how glib and GTK+ work.

The next sections discuss topics like what non-code files are required for a GNOME application (Makefiles, .desktop files, documentation, pixmaps, etc.) They are useful, and I thought occupied the right amount of space (not too little, not too much :)

Next comes a chapter I probably expected to come a bit later on. "Gnome Application Basics" is a summary of internationalization, popt, and configuration data. Unfortunately, I found the sections on configuration data a bit difficult to understand, and disliked seeing example code using some of C++'s more advanced features. Now we arrive at chapter 6, the chapter I think most GTK+ hackers looking to get into GNOME development will find most interesting. It is a discussion of the GnomeApp widget, GnomeUIInfo structs for menus, status bars, online help, tooltips, etc. Chapter 7 will probably also be useful to the same people. It is a quick (10 page) discussion of the GnomeDialog widget, and discusses several types of widgets. It well-written and very complete. Finally we have arrived at the last section of the book - "Advanced GTK+/Gnome Techniques". It is definitely for the more advanced hackers in the house. Chapters 10 and 11 are a very intensive (read: decently written chapter covering some slightly obscure topics in a lot of depth) overview of the GTK+ object system and a somewhat lengthy how to on the use of GDK (some parts I think may come in hand, some parts are probably pretty obscure). Chapter 11 is a titled "Writing a GtkWidget" and is well-written, but I question its usefulness to anyone but library developers. Unlike other sections, I felt this chapter had far too much actual code embedded within it (at least in the second half).

Next is a chapter I expect many people have been waiting their entire lives for ;) It is the long-awaited GnomeCanvas chapter. It is a ~25 page chapter which explains how to use the GnomeCanvas widget. The next chapter, Writing a GnomeCanvasItem makes a good counterpart, and the two work well together to teach the use of the canvas. It is a complex widget, so it may be hard to understand, however. I was lost at times, but I think this was probably me and not the book.

And that's most of it. The next 140 pages or so are all Appendices, some I found useful and interesting, others I found boring and skippable. However, I really must say that Appendix C, "Frequently Asked Questions", was very good and one of my favorite parts of the book :) The only remaining disappointments I had were the fact that the book was aimed towards very advanced developers (which was probably the major disappointment for me), and that libxml was not covered in at least small detail. I know that not everything can be covered, but XML is becoming central to many parts of GNOME.

Purchase this book at Amazon

1. Overview
   1. Introduction
   2. glib: Portability and Utility
   3. GTK+ Basics
2. Building a Gnome Application
   1. Creating Your Source Tree
   2. Gome Application Basics
   3. The Main Window: GnomeApp
   4. User Communication: Dialogs
   5. Gnome Applicatio Checklist
3. Advanced GTK+/Gnome Techniques
   1. The GTK+ Object and Type System
   2. Gdk Basics
   3. Writing a GtkWidget
   4. GnomeCanvas
   5. Writing a GnomeCanvasItem
4. Appendices
   1. GTK+/Gnome Object Hierarchy
   2. Table of Header Files
   3. Frequently Asked Questions
   4. Online Resources
   5. Code Listings
   6. Open Publication License Version 1.0

One of the pre-eminent reviewers on Slashdot, SEGV, has returned with a review of something a bit more esoteric than our normal book review fare. Melanie Mitchell's latest work, An Introduction to Genetic Algorithms, is the subject of today's review, and is well worth the reading for those interested in said subject. Click below to find out more. An Introduction to Genetic Algorithms author Melanie Mitchell pages 209 publisher rating 8/10 reviewer SEGV ISBN summary An excellent, brief introduction to a fascinating field. ISBN 0-262-63185-7 (PB), 0-262-13316-4 (HB)

Background

It was in the early nineties when I became interested in these sorts of things. I was enrolled in a commerce program, but somehow got onto reading such popular science books as Levy's Artificial Life: A Report from the Frontier Where Computers Meet Biology and Waldrop's Complexity: The Emerging Science at the Edge of Order and Chaos.

Those books made me make my next degree a computer science degree.

Emergent Computation

I was fascinated by the idea of computation emerging from the bottom up: from simple rules acting together in simple ways. This is in marked contrast to the traditional artificial intelligence view that complex behaviour typically only arises from the top down: from the complex interactions of complex rules.

I could appreciate the uses of traditional AI techniques, but emergent computation seemed somehow right to me.

Genetic Algorithms

Notwithstanding my simplistic explanation, there's an obvious example right in front of us. Evolution is a relatively simple process (everyone's heard of Darwin, right?) that has produced very complex output (e.g. us). What if we could harness the power of this evolutionary computation?

John Holland had the idea of mimicking this process of evolution within the computer. He encoded potential solutions as strings of zeroes and ones (the language of the computer), much as human genotypes consist of DNA strands. He developed these strings into actual solutions and measured their success against a particular problem, much as we might measure our success in life. Then he bred another generation, selecting the best individuals to reproduce ("survival of the fittest"), and applying crossover ("sex") and mutation on the strings for good measure.

That's another simplistic explanation, but as time went on these strings got better and better at solving the problem. And it didn't matter which problem. The same process could be used on almost any problem. He called this process a genetic algorithm ("GA").

An Introduction

This book is a good introduction to that world. The first three chapters present an overview of the field, and illustrate how GAs can be applied both in practical problem solving and in more theoretical research environments.

The author explains some of the history and background of GAs, the biological terminology, and its equivalent GA terminology. She provides examples and uses figures effectively.

The entire book has an "overview" feel to it. It isn't very long, and aims for breadth rather than depth. Mitchell writes with clarity, and is great at explaining the subject matter. It's not a difficult book to read.

Theory and Practice

The next two chapters cover the theory and practice of genetic algorithms. Chapter 4 is the most difficult, as it covers Holland's Schema Theorem and other mathematical and statistical observations. Fortunately, you don't lose much if you gloss over the equations, and they're there if you're into that sort of thing.

Chapter 5 is the fun stuff. Mitchell doesn't provide code, but that's okay because the explanation is lucid and sufficiently detailed to implement in code. She discusses ways of encoding the problem, implementing selection methods and the various genetic operators, and setting the parameters of the GA.

To test this theory and practice, each chapter concludes with thought exercises and computer exercises.

Applicability

Dating from 1996, the book benefits from being relatively up-to-date. It borrows from papers and studies up until then, which you'll recognize if you've browsed through other literature (such as the Santa Fe Institute's Artificial Life Proceedings).

Mitchell does reserve a critical view. She's careful to point out where further study is required, and that's important as this remains a maturing area of computer science. She also points out promising avenues for future study.

Summary

I found this book to be an excellent introduction to the field, even though I'd read articles and papers on GAs beforehand. I'd recommend it to anyone interested in genetic algorithms and ready to go beyond the popular science descriptions, but not yet ready for the hardcore books and not willing to waste time on the poorer quality "GAs made E-Z" books.

Basically, this is an excellent quality "GAs in a Nutshell" book. When you've finished it, you might be interested in Goldberg's Genetic Algorithms in Search, Optimization, and Machine Learning.

The book's official site contains a more detailed table of contents, while Mitchell's book page contains solutions to selected thought exercises, an expanded index, and errata.

You can purchase this book at Amazon.

TABLE OF CONTENTS

Preface
Acknowledgements
1. Genetic Algorithms: An Overview
2. Genetic Algorithms in Problem Solving
3. Genetic Algorithms in Scientific Models
4. Theoretical Foundations of Genetic Algorithms
5. Implementing a Genetic Algorithm
6. Conclusions and Future Directions
Appendix A: Selected General References
Appendix B: Other Resources
Bibliography
Index

One of the pre-eminent reviewers on Slashdot, SEGV, has returned with a review of something a bit more esoteric than our normal book review fare. Melanie Mitchell's latest work, An Introduction to Genetic Algorithms, is the subject of today's review, and is well worth the reading for those interested in said subject. Click below to find out more. An Introduction to Genetic Algorithms author Melanie Mitchell pages 209 publisher rating 8/10 reviewer SEGV ISBN summary An excellent, brief introduction to a fascinating field. ISBN 0-262-63185-7 (PB), 0-262-13316-4 (HB)

Background

It was in the early nineties when I became interested in these sorts of things. I was enrolled in a commerce program, but somehow got onto reading such popular science books as Levy's Artificial Life: A Report from the Frontier Where Computers Meet Biology and Waldrop's Complexity: The Emerging Science at the Edge of Order and Chaos.

Those books made me make my next degree a computer science degree.

Emergent Computation

I was fascinated by the idea of computation emerging from the bottom up: from simple rules acting together in simple ways. This is in marked contrast to the traditional artificial intelligence view that complex behaviour typically only arises from the top down: from the complex interactions of complex rules.

I could appreciate the uses of traditional AI techniques, but emergent computation seemed somehow right to me.

Genetic Algorithms

Notwithstanding my simplistic explanation, there's an obvious example right in front of us. Evolution is a relatively simple process (everyone's heard of Darwin, right?) that has produced very complex output (e.g. us). What if we could harness the power of this evolutionary computation?

John Holland had the idea of mimicking this process of evolution within the computer. He encoded potential solutions as strings of zeroes and ones (the language of the computer), much as human genotypes consist of DNA strands. He developed these strings into actual solutions and measured their success against a particular problem, much as we might measure our success in life. Then he bred another generation, selecting the best individuals to reproduce ("survival of the fittest"), and applying crossover ("sex") and mutation on the strings for good measure.

That's another simplistic explanation, but as time went on these strings got better and better at solving the problem. And it didn't matter which problem. The same process could be used on almost any problem. He called this process a genetic algorithm ("GA").

An Introduction

This book is a good introduction to that world. The first three chapters present an overview of the field, and illustrate how GAs can be applied both in practical problem solving and in more theoretical research environments.

The author explains some of the history and background of GAs, the biological terminology, and its equivalent GA terminology. She provides examples and uses figures effectively.

The entire book has an "overview" feel to it. It isn't very long, and aims for breadth rather than depth. Mitchell writes with clarity, and is great at explaining the subject matter. It's not a difficult book to read.

Theory and Practice

The next two chapters cover the theory and practice of genetic algorithms. Chapter 4 is the most difficult, as it covers Holland's Schema Theorem and other mathematical and statistical observations. Fortunately, you don't lose much if you gloss over the equations, and they're there if you're into that sort of thing.

Chapter 5 is the fun stuff. Mitchell doesn't provide code, but that's okay because the explanation is lucid and sufficiently detailed to implement in code. She discusses ways of encoding the problem, implementing selection methods and the various genetic operators, and setting the parameters of the GA.

To test this theory and practice, each chapter concludes with thought exercises and computer exercises.

Applicability

Dating from 1996, the book benefits from being relatively up-to-date. It borrows from papers and studies up until then, which you'll recognize if you've browsed through other literature (such as the Santa Fe Institute's Artificial Life Proceedings).

Mitchell does reserve a critical view. She's careful to point out where further study is required, and that's important as this remains a maturing area of computer science. She also points out promising avenues for future study.

Summary

I found this book to be an excellent introduction to the field, even though I'd read articles and papers on GAs beforehand. I'd recommend it to anyone interested in genetic algorithms and ready to go beyond the popular science descriptions, but not yet ready for the hardcore books and not willing to waste time on the poorer quality "GAs made E-Z" books.

Basically, this is an excellent quality "GAs in a Nutshell" book. When you've finished it, you might be interested in Goldberg's Genetic Algorithms in Search, Optimization, and Machine Learning.

The book's official site contains a more detailed table of contents, while Mitchell's book page contains solutions to selected thought exercises, an expanded index, and errata.

You can purchase this book at Amazon.

TABLE OF CONTENTS

Preface
Acknowledgements
1. Genetic Algorithms: An Overview
2. Genetic Algorithms in Problem Solving
3. Genetic Algorithms in Scientific Models
4. Theoretical Foundations of Genetic Algorithms
5. Implementing a Genetic Algorithm
6. Conclusions and Future Directions
Appendix A: Selected General References
Appendix B: Other Resources
Bibliography
Index

One of the pre-eminent reviewers on Slashdot, SEGV, has returned with a review of something a bit more esoteric than our normal book review fare. Melanie Mitchell's latest work, An Introduction to Genetic Algorithms, is the subject of today's review, and is well worth the reading for those interested in said subject. Click below to find out more. An Introduction to Genetic Algorithms author Melanie Mitchell pages 209 publisher rating 8/10 reviewer SEGV ISBN summary An excellent, brief introduction to a fascinating field. ISBN 0-262-63185-7 (PB), 0-262-13316-4 (HB)

Background

It was in the early nineties when I became interested in these sorts of things. I was enrolled in a commerce program, but somehow got onto reading such popular science books as Levy's Artificial Life: A Report from the Frontier Where Computers Meet Biology and Waldrop's Complexity: The Emerging Science at the Edge of Order and Chaos.

Those books made me make my next degree a computer science degree.

Emergent Computation

I was fascinated by the idea of computation emerging from the bottom up: from simple rules acting together in simple ways. This is in marked contrast to the traditional artificial intelligence view that complex behaviour typically only arises from the top down: from the complex interactions of complex rules.

I could appreciate the uses of traditional AI techniques, but emergent computation seemed somehow right to me.

Genetic Algorithms

Notwithstanding my simplistic explanation, there's an obvious example right in front of us. Evolution is a relatively simple process (everyone's heard of Darwin, right?) that has produced very complex output (e.g. us). What if we could harness the power of this evolutionary computation?

John Holland had the idea of mimicking this process of evolution within the computer. He encoded potential solutions as strings of zeroes and ones (the language of the computer), much as human genotypes consist of DNA strands. He developed these strings into actual solutions and measured their success against a particular problem, much as we might measure our success in life. Then he bred another generation, selecting the best individuals to reproduce ("survival of the fittest"), and applying crossover ("sex") and mutation on the strings for good measure.

That's another simplistic explanation, but as time went on these strings got better and better at solving the problem. And it didn't matter which problem. The same process could be used on almost any problem. He called this process a genetic algorithm ("GA").

An Introduction

This book is a good introduction to that world. The first three chapters present an overview of the field, and illustrate how GAs can be applied both in practical problem solving and in more theoretical research environments.

The author explains some of the history and background of GAs, the biological terminology, and its equivalent GA terminology. She provides examples and uses figures effectively.

The entire book has an "overview" feel to it. It isn't very long, and aims for breadth rather than depth. Mitchell writes with clarity, and is great at explaining the subject matter. It's not a difficult book to read.

Theory and Practice

The next two chapters cover the theory and practice of genetic algorithms. Chapter 4 is the most difficult, as it covers Holland's Schema Theorem and other mathematical and statistical observations. Fortunately, you don't lose much if you gloss over the equations, and they're there if you're into that sort of thing.

Chapter 5 is the fun stuff. Mitchell doesn't provide code, but that's okay because the explanation is lucid and sufficiently detailed to implement in code. She discusses ways of encoding the problem, implementing selection methods and the various genetic operators, and setting the parameters of the GA.

To test this theory and practice, each chapter concludes with thought exercises and computer exercises.

Applicability

Dating from 1996, the book benefits from being relatively up-to-date. It borrows from papers and studies up until then, which you'll recognize if you've browsed through other literature (such as the Santa Fe Institute's Artificial Life Proceedings).

Mitchell does reserve a critical view. She's careful to point out where further study is required, and that's important as this remains a maturing area of computer science. She also points out promising avenues for future study.

Summary

I found this book to be an excellent introduction to the field, even though I'd read articles and papers on GAs beforehand. I'd recommend it to anyone interested in genetic algorithms and ready to go beyond the popular science descriptions, but not yet ready for the hardcore books and not willing to waste time on the poorer quality "GAs made E-Z" books.

Basically, this is an excellent quality "GAs in a Nutshell" book. When you've finished it, you might be interested in Goldberg's Genetic Algorithms in Search, Optimization, and Machine Learning.

The book's official site contains a more detailed table of contents, while Mitchell's book page contains solutions to selected thought exercises, an expanded index, and errata.

You can purchase this book at Amazon.

TABLE OF CONTENTS

Preface
Acknowledgements
1. Genetic Algorithms: An Overview
2. Genetic Algorithms in Problem Solving
3. Genetic Algorithms in Scientific Models
4. Theoretical Foundations of Genetic Algorithms
5. Implementing a Genetic Algorithm
6. Conclusions and Future Directions
Appendix A: Selected General References
Appendix B: Other Resources
Bibliography
Index

One of the pre-eminent reviewers on Slashdot, SEGV, has returned with a review of something a bit more esoteric than our normal book review fare. Melanie Mitchell's latest work, An Introduction to Genetic Algorithms, is the subject of today's review, and is well worth the reading for those interested in said subject. Click below to find out more. An Introduction to Genetic Algorithms author Melanie Mitchell pages 209 publisher rating 8/10 reviewer SEGV ISBN summary An excellent, brief introduction to a fascinating field. ISBN 0-262-63185-7 (PB), 0-262-13316-4 (HB)

Background

It was in the early nineties when I became interested in these sorts of things. I was enrolled in a commerce program, but somehow got onto reading such popular science books as Levy's Artificial Life: A Report from the Frontier Where Computers Meet Biology and Waldrop's Complexity: The Emerging Science at the Edge of Order and Chaos.

Those books made me make my next degree a computer science degree.

Emergent Computation

I was fascinated by the idea of computation emerging from the bottom up: from simple rules acting together in simple ways. This is in marked contrast to the traditional artificial intelligence view that complex behaviour typically only arises from the top down: from the complex interactions of complex rules.

I could appreciate the uses of traditional AI techniques, but emergent computation seemed somehow right to me.

Genetic Algorithms

Notwithstanding my simplistic explanation, there's an obvious example right in front of us. Evolution is a relatively simple process (everyone's heard of Darwin, right?) that has produced very complex output (e.g. us). What if we could harness the power of this evolutionary computation?

John Holland had the idea of mimicking this process of evolution within the computer. He encoded potential solutions as strings of zeroes and ones (the language of the computer), much as human genotypes consist of DNA strands. He developed these strings into actual solutions and measured their success against a particular problem, much as we might measure our success in life. Then he bred another generation, selecting the best individuals to reproduce ("survival of the fittest"), and applying crossover ("sex") and mutation on the strings for good measure.

That's another simplistic explanation, but as time went on these strings got better and better at solving the problem. And it didn't matter which problem. The same process could be used on almost any problem. He called this process a genetic algorithm ("GA").

An Introduction

This book is a good introduction to that world. The first three chapters present an overview of the field, and illustrate how GAs can be applied both in practical problem solving and in more theoretical research environments.

The author explains some of the history and background of GAs, the biological terminology, and its equivalent GA terminology. She provides examples and uses figures effectively.

The entire book has an "overview" feel to it. It isn't very long, and aims for breadth rather than depth. Mitchell writes with clarity, and is great at explaining the subject matter. It's not a difficult book to read.

Theory and Practice

The next two chapters cover the theory and practice of genetic algorithms. Chapter 4 is the most difficult, as it covers Holland's Schema Theorem and other mathematical and statistical observations. Fortunately, you don't lose much if you gloss over the equations, and they're there if you're into that sort of thing.

Chapter 5 is the fun stuff. Mitchell doesn't provide code, but that's okay because the explanation is lucid and sufficiently detailed to implement in code. She discusses ways of encoding the problem, implementing selection methods and the various genetic operators, and setting the parameters of the GA.

To test this theory and practice, each chapter concludes with thought exercises and computer exercises.

Applicability

Dating from 1996, the book benefits from being relatively up-to-date. It borrows from papers and studies up until then, which you'll recognize if you've browsed through other literature (such as the Santa Fe Institute's Artificial Life Proceedings).

Mitchell does reserve a critical view. She's careful to point out where further study is required, and that's important as this remains a maturing area of computer science. She also points out promising avenues for future study.

Summary

I found this book to be an excellent introduction to the field, even though I'd read articles and papers on GAs beforehand. I'd recommend it to anyone interested in genetic algorithms and ready to go beyond the popular science descriptions, but not yet ready for the hardcore books and not willing to waste time on the poorer quality "GAs made E-Z" books.

Basically, this is an excellent quality "GAs in a Nutshell" book. When you've finished it, you might be interested in Goldberg's Genetic Algorithms in Search, Optimization, and Machine Learning.

The book's official site contains a more detailed table of contents, while Mitchell's book page contains solutions to selected thought exercises, an expanded index, and errata.

You can purchase this book at Amazon.

TABLE OF CONTENTS

Preface
Acknowledgements
1. Genetic Algorithms: An Overview
2. Genetic Algorithms in Problem Solving
3. Genetic Algorithms in Scientific Models
4. Theoretical Foundations of Genetic Algorithms
5. Implementing a Genetic Algorithm
6. Conclusions and Future Directions
Appendix A: Selected General References
Appendix B: Other Resources
Bibliography
Index

Red Hat may be tightening use of its trademark. Robb Sands, an independent reseller of Linux products who generates many of his sales through Amazon.com's auction site, says, "I received a call from a representative of the fraud/legal department of Amazon named Elyssa Back about 1 p.m. eastern time today who said I would need to modify my product and advertising when used in conjunction with a product that is not the official boxed set."

Sands says that, according to Amazon.com, Red Hat no longer allows their trademarked "Red Hat" name to be used on any product other than their official boxed "Red Hat Linux" sets.

Amazon.com spokesperson Sharon Greenspan says, "Right now we're looking into a possible Intellectual Property violation involving Red Hat Linux software. We are talking to Red Hat and the sellers of such products." Sharon says she'll call Slashdot as soon as knows more; she seemed as surprised by this news as was everyone else.

A well-known Linux products vendor has confirmed to me personally, off the record, that yes, Red Hat is trying to keep outsiders from using the "Red Hat" name when selling anything other than official Red Hat boxed sets, and that Red Hat no longer wants their trademark used on GPLed or repackaged versions or their products.

Red Hat itself cannot comment on this story at this time. They are in a legally mandated "quiet period" following their recent IPO, which does not end until September 6th. Meanwhile, if you have more information about this matter, please psot it below or e-mail me privately: roblimo@nOsPaMslashdot.rg

Kathleen Ellis, editor of the Privacy News Portal, has written an excellent feature about how The President's Export Council Subcommittee on Encryption (PECSENC) has recommended dropping almost all export controls on strong crypto, and why it is unlikely that this group's recommendations will be acted on in any meaningful way. (More below)

White House Subcommittee Endorses Crypto Reform.
Will Someone Please Listen?
By Kathleen Ellis

Another shot was fired in one of the longest-lasting and most contentious battles regarding Internet policy last Wednesday, when a White House advisory subcommittee announced it has recommended that the Clinton Administration all but reverse its restrictive stance on the export of encryption products.

The President's Export Council Subcommittee on Encryption (PECSENC) was formed earlier this year by the White House to provide guidance in the U.S. Government's development of encryption policy, which has been the subject of heated debate. As many Slashdot readers already know, the government has insisted for years that liberalizing encryption export could cause serious problems for national security by giving terrorists and criminals access to the technology. Of course, net activists and industry folk assert that the right to privacy supercedes the wishes of any bureaucrat, and that terrorists and criminals can just as easily get their crypto from any other country that does not restrict cryptographic exports.

Critics of the Administration's policy had expected to gain little support through the subcommittee's recommendations. William Crowell, the subcommittee's chairman, is currently President and CEO of Cylink Corporation, an internet security firm, but previously served as Deputy Director for the National Security Agency. Several committee members also had ties to law enforcement or other government agencies; Stewart Baker, an attorney with the Washington-based Steptoe & Johnson, is former general counsel to the NSA and is a vocal opponent of loosening restrictions on encryption. Steve Walker is former president of Trusted Information Systems (now owned by Network Associates), a leading producer of key escrowed encryption products, which the FBI has lobbied to make mandatory even for domestic use.

Despite these ties, however, the subcommittee cited a need for the U.S. government to "recognize market realities" and reverse its course on encryption policy. Among its recommendations:

- License-Free Zones: Recognizing that the European Union is planning to drop all cryptographic export rules between member countries, the US should likewise identify a list of countries which do not pose any major terrorist threat, and allow encryption export (hardware and software products) without a license.

- On-Line Merchants: On-line merchants based in other countries will be added to the list of business types permitted to have encryption products exported to them from the US. Banks and a limited number of other financial institutions currently enjoy this license exception.

- Mass-market hardware and software: Mass-market products which utilize up to 128-bit key length triple DES will enjoy license exception. "The US government should recognize the difficulty of controlling mass-market products once they are allowed to be exported to even limited sectors".

The subcommittee also suggests eliminating cumbersome reporting requirements for manufacturers of encryption products, as well as removal of source code, cryptographic Application Programming Interfaces and devices such as encrypting routers from the list of restricted technologies.

So cypherpunks across the nation will soon be free to export their code at will? Subcommittee chairman William Crowell is hesitant to say yes. "The Administration will have its own ideas about which of these recommendations are implementable. Vice President Gore has said that the administration would consider additional liberalization over what they announced last year, so it was important to get these recommendations to the table while they were thinking about it". He expects that the administration will make further changes to its export policy based on the recommendations sometime in September.

There are other signs of change on the horizon regarding the government's attitude toward encryption. The successor to the current Data Encryption Standard algorithm, which will be used by the U.S. Government for a multitude of purposes, will be chosen by the National Institute of Standards and Technology with the next few months. Four out of the five Advanced Encryption Standard finalists were developed, at least in part, by cryptographers based overseas or holding foreign citizenships. The fact that such decisions could be made by NIST requires the acknowledgement, at least on some level, that good encryption can be produced in countries not affected by U.S. export law, and hence, can be made available around the world.

However, one prominent activist is still skeptical about the potential effect this announcement may actually have on U.S. policy. "This doesn't change policy, this is just yet another group that has come forward and said 'the U.S. policy is abysmal, it needs to be scrapped'" says David Banisar, Deputy Director of Privacy International, and co-author of "The Electronic Privacy Papers". "Many distinguished groups in the past have made similar recommendations...the Clinton Administration has thus far rejected any attempts to dramatically reform export control laws".

Banisar likened the potential influence of the PECSENC recommendations to those of a report published by the National Research Council in 1996. Much more conservative than the PECSENC subcommittee's suggestions, "Cryptography's Role In Securing the Information Society" was written by a committee comprised of government officials, representatives from the computing industry, and academics. The NRC committee's recommendation that 56-bit DES encryption took two years for the Bureau of Export Administration to implement, and many of the other valuable points in the report have never been implemented. The NRC report suggested that U.S. policy should take into account the "nonconfidentiality uses" encryption has to offer. U.S. policy still does not support the use of encryption for the purposes of authentication, which the committee identified as an "important crime-fighting measure". Indeed, one would think that the F.B.I. and the Department of Commerce would hasten to encourage the use of such technologies.

Banisar also expressed concerns about the provisions favoring online merchants. "The e-commerce exports have already been promised to online merchants...they will get what they want, which helps the Clinton Administration divide and conquer their opposition". Banisar stated that civil libertarians lost a powerful lobbying ally when banks were granted the same licensing exemptions now promised to entrepreneurs online. "When a wealthier group gets what they want, they stop fighting, and the everyday users get screwed."

It also seems that the recommendations do not go far enough to help the people who need encryption technology most. Barbara Simons is President of the Association for Computing Machinery and one of the members of the PECSENC committee. "It appears that the recommendations don't address the needs of people working for human rights in countries with repressive regimes," she says.

The human rights issue is a valid one within the debate on U.S. encryption policy. The American Association for the Advancement of Science's Cryptography, Scientific Freedom, and Human Rights program trains human rights workers to use encryption technology in countries like Guatemala and China, where oppressive governments have a way of making insurrectionists disappear. A letter from AAAS to the House or Representatives Committee on International relations states that "human rights activists are killed, tortured, disappeared and jailed for trying to expose horrendous abuses...[they] use encryption to protect themselves, the victims and eyewitnesses they are interviewing, and human rights colleagues around the world when they communicate sensitive information on grave abuses of human rights".

It would be wise and compassionate for the Clinton Administration to authorize a new class of license exceptions for human rights workers travelling into countries that don't fall under the "favored nations" exemptions for encryption exports. If national security were really a concern in these cases, they could add strict guidelines describing who the software could legally be distributed to within those countries. Unfortunately, PECSENC seems to have overlooked this important issue.

Despite these shortcomings, there are some definite gains to be made by following PECSENC's recommendations. Net activists will be keeping their fingers crossed when the White House reviews them next month. Progress has been far too slow in coming, and if there's ever been a time for our government to start making some positive decisions, this certainly is it.

Thanks to chromatic, who has returned with another book review. This time around it's O'Reilly's Programming Web Graphics with Perl & GNU Software. Excellent book for prospective Webmasters - give it a look. Programming Web Graphics with Perl & GNU Software author Shawn P. Wallace pages 441 publisher O'Reilly rating 8/10 reviewer chromatic ISBN summary If you want to spice up your website with graphics generated on the fly or automate graphic manipulation tasks with Perl, Shawn Wallace points you in the right direction and gives you the tools you'll need to hone your skills.

The Scenario

You're an experienced webmaster looking for new ways to present information to your customers. Perhaps you want to create a graph showing hits per hour, or you need to convert all of your GIFs to PNGs, and you know that Perl would be perfect, if only there were a module somewhere.... Or maybe you'd like to write some Perl-Fu, but don't know how to start.

What's Bad?

The book seems a little short, for all of the topics presented. I'd have liked to see more examples, but there is a lot of ground to cover, and the references given at the end of each chapter provide places to go for more information.

What's Good? General Impressions

For the most part, the information presented is platform-neutral. There is a slight Unix bias, but all of the examples should work with various web servers on most platforms with no modifications. It's also pragmatic -- though the HTML 4.0 specification is mentioned, the author recommends HTML 3.2 until more browsers comply with the 4.0 specification.

The code is very clean and well-commented. Intermediate Perl programmers should have no difficulty following along.

The GIMP is covered thoroughly, with a chapter describing normal operation and basic Perl-Fu, and two Appendixes, a Quick Reference Guide and a Procedure Reference Guide. (Very handy!)

Each chapter lists a handful of references for more information. Think of this book as an introduction to the subjects, and a reference guide after you have the basics down.

Section by Section Intro to Web Graphics

Chapter one, Image File Formats, delves into the three most popular graphics formats used on the web today: GIF, JPEG, and PNG, describing file formats, color options, transparency, animation, and the like. There's a section describing which format is appropriate for which usage, and a small discussion of the LZW patent issue.

Chapter two, Serving Graphics on the Web, looks at the web server and web browser, and their roles in serving and displaying images. This chapter is a kind of overview of the rest of the book, with simple CGI and HTML examples peppering the technical description.

Chapter three, A Litany of Libraries, simply describes several useful free graphics libraries (several of which have their own chapters).

Graphics Programming Tools

The meat of Programming Web Graphics is in this section. Each chapter focuses on one tool/library, discussing its strengths and giving real-world examples, the bulk of the material is a Nutshell-style listing of methods and data. Much of the book's value is here.

Chapter four, On-the-Fly Graphics with GD, looks at the GD module for standard, quick GIF manipulation.

Chapter five, Industrial-Strength Graphics Scripting with PerlMagick, discusses ImageMagick and PerlMagick, for more complicated (and, more likely, off-line) tasks.

Chapter six, Charts and Graphs with GIFgraph, talks about the GIFgraph module for creating graphs, pie charts, and so forth.

Chapter seven, Web Graphics with the Gimp, delves into the GIMP, with a brief introduction and tutorial. The focus is on two things: using the GIMP to create or to modify web graphics, and creating Perl plug-in scripts for the GIMP.

Dynamic Graphic Techniques

Chapter eight, Image Maps, describes server and client side image maps. Example scripts build a "wander engine" (a sort of database-backed set of rooms, traversable with a web browser).

Chapter nine, Moving Pictures: Programming GIF Animation, focuses on the nitty gritty of GIF89a, and describes creating animations with PerlMagick and GIFScript.

Chapter ten, Web Graphics Cookbook, is a sort of catch-all for examples. It provides scripts for a broken image error graphic generator, a robust and secure access counter, JavaScript rollovers, a Web Cam discussion, creating ASCII ALT tags with AAlib, and making thumbnails easily.

Chapter eleven, Paperless Office? Not in Our Lives: Printing and the Web, describes the PostScript language in brief, and documents the PostScript module, paying attention to the GhostScript package.

Appendixes

Appendix A, A Simple PNG Decoder in Perl, contains the source to the PNGObject module.

Appendix B, Quick Reference Guide to the Gimp, briefly describes the menus and dialogs of the Gimp.

Appendix C, Procedure Reference for the Gimp, documents the API to the GIMP's internal Procedural Database. Procedures are listed according to their functionality, such as managing images, or working with layers and channels.

So What's In It For Me?

If you're a moderately experienced Perl programmer with a web site to play with, and if you're interested in using Perl to make your graphics mastering much easier, pick up this book!

That's a pretty specific audience, but anyone else who has an interest in these things (especially the big three -- GD, PerlMagick, and Perl-Fu) will benefit from the specific chapters and the function references. It's an eclectic book, and there's a lot of information presented. The author has done a tremendous amount of research on lots of different subjects (Generate PostScript receipts from web forms? I never would have guessed), and this book has expanded my ideas of what is possible.

The cover animal is a collared titi, a small South American monkey.

Buy this book at Amazon.

I recently read Po Bronson's sophomore effort, The First 20 Million is Always the Hardest (TF20MIATH), and had a few gripes about it. Click below to read mine, and to share your own critiques - compliments - comments - ramblings about the book. The First 20 Million is Always the Hardest author Po Bronson pages 237 publisher Random House rating 4/10 reviewer Jeff "hemos" Bates ISBN summary An attempt at writing a fictional Silicon Valley Story

Several months ago I read Bronson's latest book, The Nudist on the Late Shift . It was good - not quite Microserfs , but definitely worth the time I spent reading it.

So, with that in mind, and having heard a little bit about his other material, I kept an eye open for Bombardiers or TF20MIATH, and eagerly fell upon the first of the two that came to me.

Most of TF20MIATH's main characters are engineers, "iron-men" in the parlance of the book, who work for a research facility that's supposed to attract only the best and brightest. You aren't paid a lot of money to work there. You do it for the love of the work, and to prove you're an Iron Man, or "uber-mann." However, the work done at the lab does have commercial properties, and the lab is funded by commercial companies. The largest sponsoring company, much like AMD, is trying to compete with Intel. This fact creates some of the book's conflict.

The lead character, Andy, joins the lab after quitting his job at that psuedo-AMD company, but his desires to work at The Lab are (major summarization here) soon quenched by the other main character, Francis Benoit, who is constantly seeking to prove that he is the Super-Iron-Man of them all.

One of the ongoing battles of the book is between the powerful "big iron machines" the lab is known for developing and the evolving world of thin client, networked machines. Bronson's treatment of this conflict, coupled with the somewhat Messianic light that these cheap Internetworked computers will bring to the world writ large, is the books's central thought. It's a good thought, and I think it's one that has some validity. That is, as the world's population gets more education, and computers spread, I think things will get better. So does Bronson. And he says this again and again, in slightly different words each time.

The story itself, which in a way is a story about the world of the suits meeting the world of engineers, with the obvious party losing, falls short. The introduction of a female bit player who becomes Andy's girlfriend is contrived. Problems develop in the relationship, and we never hear if they are resolved or not. The disapperance of a fairly major character (Salman) is explained poorly, and is never mentioned again in any fashion.

Summary time: The story involves jealousy and politicking amongst the Iron Men Engineers while they as a caste also do battle with the Universe of the Suits. The main character must resolve issues with his girlfriend. All characters wrestle with problems, includings things like whether or not they will be fired, whether or not they can code something, and whether or not they can afford to buy better food.

It's not a bad book, it's just that unless this type of writing is your favorite, there are better books to read. There's a good book inside this one, but the problem is that the good book is only about one-third the length of the published version. Bronson is an author who seems to constantly be trying to figure out how to best tell a Silicon Valley story. In Nudist he did it succesfully, but in TF20MIATH he didn't. My recommendation: You won't regret reading this, but there's better stuff around..

You can buy TF20MIATH at Amazon.

I recently read Po Bronson's sophomore effort, The First 20 Million is Always the Hardest (TF20MIATH), and had a few gripes about it. Click below to read mine, and to share your own critiques - compliments - comments - ramblings about the book. The First 20 Million is Always the Hardest author Po Bronson pages 237 publisher Random House rating 4/10 reviewer Jeff "hemos" Bates ISBN summary An attempt at writing a fictional Silicon Valley Story

Several months ago I read Bronson's latest book, The Nudist on the Late Shift . It was good - not quite Microserfs , but definitely worth the time I spent reading it.

So, with that in mind, and having heard a little bit about his other material, I kept an eye open for Bombardiers or TF20MIATH, and eagerly fell upon the first of the two that came to me.

Most of TF20MIATH's main characters are engineers, "iron-men" in the parlance of the book, who work for a research facility that's supposed to attract only the best and brightest. You aren't paid a lot of money to work there. You do it for the love of the work, and to prove you're an Iron Man, or "uber-mann." However, the work done at the lab does have commercial properties, and the lab is funded by commercial companies. The largest sponsoring company, much like AMD, is trying to compete with Intel. This fact creates some of the book's conflict.

The lead character, Andy, joins the lab after quitting his job at that psuedo-AMD company, but his desires to work at The Lab are (major summarization here) soon quenched by the other main character, Francis Benoit, who is constantly seeking to prove that he is the Super-Iron-Man of them all.

One of the ongoing battles of the book is between the powerful "big iron machines" the lab is known for developing and the evolving world of thin client, networked machines. Bronson's treatment of this conflict, coupled with the somewhat Messianic light that these cheap Internetworked computers will bring to the world writ large, is the books's central thought. It's a good thought, and I think it's one that has some validity. That is, as the world's population gets more education, and computers spread, I think things will get better. So does Bronson. And he says this again and again, in slightly different words each time.

The story itself, which in a way is a story about the world of the suits meeting the world of engineers, with the obvious party losing, falls short. The introduction of a female bit player who becomes Andy's girlfriend is contrived. Problems develop in the relationship, and we never hear if they are resolved or not. The disapperance of a fairly major character (Salman) is explained poorly, and is never mentioned again in any fashion.

Summary time: The story involves jealousy and politicking amongst the Iron Men Engineers while they as a caste also do battle with the Universe of the Suits. The main character must resolve issues with his girlfriend. All characters wrestle with problems, includings things like whether or not they will be fired, whether or not they can code something, and whether or not they can afford to buy better food.

It's not a bad book, it's just that unless this type of writing is your favorite, there are better books to read. There's a good book inside this one, but the problem is that the good book is only about one-third the length of the published version. Bronson is an author who seems to constantly be trying to figure out how to best tell a Silicon Valley story. In Nudist he did it succesfully, but in TF20MIATH he didn't. My recommendation: You won't regret reading this, but there's better stuff around..

You can buy TF20MIATH at Amazon.

I recently read Po Bronson's sophomore effort, The First 20 Million is Always the Hardest (TF20MIATH), and had a few gripes about it. Click below to read mine, and to share your own critiques - compliments - comments - ramblings about the book. The First 20 Million is Always the Hardest author Po Bronson pages 237 publisher Random House rating 4/10 reviewer Jeff "hemos" Bates ISBN summary An attempt at writing a fictional Silicon Valley Story

Several months ago I read Bronson's latest book, The Nudist on the Late Shift . It was good - not quite Microserfs , but definitely worth the time I spent reading it.

So, with that in mind, and having heard a little bit about his other material, I kept an eye open for Bombardiers or TF20MIATH, and eagerly fell upon the first of the two that came to me.

Most of TF20MIATH's main characters are engineers, "iron-men" in the parlance of the book, who work for a research facility that's supposed to attract only the best and brightest. You aren't paid a lot of money to work there. You do it for the love of the work, and to prove you're an Iron Man, or "uber-mann." However, the work done at the lab does have commercial properties, and the lab is funded by commercial companies. The largest sponsoring company, much like AMD, is trying to compete with Intel. This fact creates some of the book's conflict.

The lead character, Andy, joins the lab after quitting his job at that psuedo-AMD company, but his desires to work at The Lab are (major summarization here) soon quenched by the other main character, Francis Benoit, who is constantly seeking to prove that he is the Super-Iron-Man of them all.

One of the ongoing battles of the book is between the powerful "big iron machines" the lab is known for developing and the evolving world of thin client, networked machines. Bronson's treatment of this conflict, coupled with the somewhat Messianic light that these cheap Internetworked computers will bring to the world writ large, is the books's central thought. It's a good thought, and I think it's one that has some validity. That is, as the world's population gets more education, and computers spread, I think things will get better. So does Bronson. And he says this again and again, in slightly different words each time.

The story itself, which in a way is a story about the world of the suits meeting the world of engineers, with the obvious party losing, falls short. The introduction of a female bit player who becomes Andy's girlfriend is contrived. Problems develop in the relationship, and we never hear if they are resolved or not. The disapperance of a fairly major character (Salman) is explained poorly, and is never mentioned again in any fashion.

Summary time: The story involves jealousy and politicking amongst the Iron Men Engineers while they as a caste also do battle with the Universe of the Suits. The main character must resolve issues with his girlfriend. All characters wrestle with problems, includings things like whether or not they will be fired, whether or not they can code something, and whether or not they can afford to buy better food.

It's not a bad book, it's just that unless this type of writing is your favorite, there are better books to read. There's a good book inside this one, but the problem is that the good book is only about one-third the length of the published version. Bronson is an author who seems to constantly be trying to figure out how to best tell a Silicon Valley story. In Nudist he did it succesfully, but in TF20MIATH he didn't. My recommendation: You won't regret reading this, but there's better stuff around..

You can buy TF20MIATH at Amazon.

Dredd13 writes "Amazon.Com announced today that they are rethinking their position on Purchase Circles. They are going to permit people to remove their purchases from being added to Purchase Circles, as well as allowing companies to opt-out of the Purchase Circle listings. Personally, I think that it should be explicitly opt-in for companies, because it is far too easy for a company to have its secrets unknowingly leaked to the world via its book purchases. If a precedent is set allowing Amazon.Com to do this, then before a company allows purchases from an online retailer, they may have to spend time and energy researching the company making sure silly things like Purchase Circles don't affect them. " Opt-out sure is an interesting choice. I know one of my old employers is actually quite upset by the whole idea of purchase circles.

Occasionally someone submits a feature that really raises my eyebrow. Jack William Bell did just that by submitting 'Open Source as an Ant Farm'. Its a really interesting piece that talks about code as art, and much more. Its quite funny, and its got a lot to think about. Click now, you won't regret it. Open Source as an Ant Farm by Jack William Bell

Where Open Source is concerned, hyperbole from the digerteratti hype meisters proliferates nearly as quickly as the hyperlinks they hype. Let's face it -- Clapton has been deposed; Linus Torvalds is now God. And those pundits shouting his divinity the loudest can^Òt even tell a stack register from a walrus. I wonder if Jesus had the same problem?

This constant lionizing of Linus is getting on my nerves. I mean, he is probably a great guy and all (if you know what I mean), but a great man? Usually you wait until people are safely dead (and unable to further embarrass themselves) before heaping those kinds of laurels on their heads. If I was he I would start worrying about that strange human proclivity for taking our living idols down a notch once in a while. Or even nailing them to a tree. Not to mention burning at the stake, drawing and quartering and satirizin g on TV.

But I knew things were getting ridiculous this last week when I saw three different weblogs pointing to the same dumb article using variations on the same dumb caption: 'Open Source as an Art Form' . I mean come on, just because a bunch of nutzoid art types gives Torvalds an award for Linux doesn't mean that an operating system or a development model is art! Yeesh!

Not that I don't think of programming as art mind you. After all I am a programmer myself and I often like to compare what I do to the creation of art. A kind of raw industrial art perpetuated underneath the digital world by Morlo cks like myself while the Eloi cavort on the surface, unaware of the immense complexity (and fragility) of their world. In other words code is art, but it is exclusionist art. No more approachable to the everyday person than a Jackson Pollock work. And twice as incomprehensible!

After all if everyone could do it, it wouldn't be art, would it? It would be just another craft. And if everyone could appreciate good code the way I appreciate the Impressionists then it would be 'Classical' (read 'Dead') Art. Not something alive and thriving. Bubbling and fermenting and making funny smells the way the process of hacking out good code does.

But, you say, it is being appreciated just as you would like! After all, isn't that what the award was all about?

Well, no frankly. Not even close. In my opinion if you can't write good code you can't appreciate good code. At the most you can only appreciate the end result, the compiled program. And, while some programs are definitely 'art' in their own right, many others cannot be described as such based on their even visible-to-the-user external features. And Linux, while a work of art in my programmer eyes, is really just a kernel. A piece of code that, if everything is working right, the user will never see directly. Some of my peers would agree with this. Some will not. As always opinions are all over the map...

One poster on Slashdot tried to have it both ways when he opined "Which part of the programming is the art? Is it the code, neatly formatted, with creative comments and clever algorithms or is it the finished product? When you look at 'art' in a museum, all you see is the finished product . . . So which is the art? The code or the program? I personally think it's the program, and beautiful programs usually have very nice/efficient/clean code."

While another lamented "When the New Yorker compares Open Source to the Algonquin roundtable, the seventh seal will be complete and Microsoft will be free to release Windows 2000."

And another asks "So how is this art going to be displayed? Will art galleries have framed printouts of C code, or will they just give out Linux CDs?"

How indeed? Well, if you read the dumb article I mentioned above you will find the author's thesis is that neither the source code nor the compiled Linux kernel code is the issue, rather the art in question is the Open Source development model that built it! He bases this proposition the following facts:

• China Youth Daily used the Microsoft consternation over Open Source for propaganda purposes.
• The Open Source development model (as described by Eric Raymond) is about cooperation and participation.
• Indian Potlatches were about cooperation and participation.
• The Surrealists did some stuff that involved cooperation and participation.
• A lot of twentieth century art uses 'quotation' (like painting soup cans or sampling 1970's Rock and Roll for Rap music) and 'quotation' is kind of like Open Source, isn't it?
• John Myatt's art forgery scam was kind of like 'quotation' too! And it was kind of like art as well
• When some people share a pseudonym to do wacky performance art, and then someone else uses the same nom de plume to crack a web site or to write an on-line 'tag-team' novel you have cooperation and participation and quotation and propaganda all rolled into one, with an Internet connection as a sweetener!

My first thought on reading the article was "Huh?" Then I reread and listed the salient points above and reiterated "Huh?"

Clearly Harvey Blume isn't a programmer. If he was I wouldn't trust him to code a 'for' loop based on his demonstrated grasp of simple logic. Nonetheless if he had simply stated that Open Source programming with the Bazaar model is 'Art' because he says it was art I would have much less to quibble with. After all art, like beauty, is in the eye of the beholder. Only he didn't. Instead he chose to defend his allegation using arguments that indicate he doesn't understand anything about the subject. In other words, I cannot say Mr. Blume is wrong, but I can state with near certainty that he is the wrong person to make the claim. He might be right, but for the wrong reasons.

So, assuming you can call a development model an art form -- how do you hang it on the wall? I would argue that it is already there. The main point about Open Source is that it is (wait for it) . . . OPEN! Duh^Å Unlike 'Closed' development the source code is available for all to see. And often the discussions between developers are available as well, archived on one list server or another. In the Internet sense you can't get up against the wall any more that that!

But what does the average art lover see hanging there? Open Source as an Art Form? I think not. More like Open Source as an Ant Farm! At most they will get a glimpse of we scurrying workers as we toil underground. But they will never, ever understand. As I said before, I am OK with that.

Non programmer types can present art awards for Linux or even Sendmail if they like, but it doesn't signify to me. In my opinion these awards mean nothing until they are given by someone who understands why the jargon file definition of 'Recursion' is funny. Until then I would rather they just threw money. Wouldn't you?

Thanks to both danimal and Doc Technical for reviews of the latest and greatest O'Reilly book, Randy Jay Yarger, George Reese, and Tim King's MySQL and mSQL. An excellent book for those who are looking to do database development (and MySQL powers Slashdot!), click below for more details. MySQL & mSQL author Randy Jay Yarger, George Reese, and Tim King pages 506 publisher O'Reilly rating 8.5/10 reviewer Dan Weeks & DocTechnical ISBN summary A good introduction to the world of relational databases and an excellent reference for MySQLand mSQL. First Review: Doc Technical

This is certainly one of the more orthogonal books I've read of late. Besides the obvious axis of MySQL and mSQL, the book also covers the implementation of these databases on Unix, Windows 95 and Windows NT. And it covers a wide variety of programming languages, including perl, Python, PHP, Java, C, and C++.

While this is certainly a good book, in fact a very good book, this wide coverage means that the average reader may need to skip around a bit to get to the parts of the book they need. A Linux perl mSQL programmer will necessarily take a different path through the book then, say, a Windows NT mySQL database administrator.

Not that straying down the wrong path is always a bad thing. It was interesting to read about the quirky differences between different OS implementations.

"Windows 95 leaks about 200 bytes of main memory for each thread creation." [page 41]

"...[D]atabase and table names are case-sensitive under Unix and case-insensitive under Win32." [page 43]

The book is divided into three broad sections: "Getting Started with MySQL and mSQL", "Database Programming", and a final "Reference" section which spans fully half the book. O'Reilly's high standards for editing, layout, writing, and clarity are all evident throughout.

What I Liked Best For MySQL users, this book may appear to present a bit of a quandary. MySQL already comes with a 400+ page reference manual, and a quite nice one at that. But actually, the O'Reilly book covers much material the manual doesn't.

Chapter 2 covers relational database design, and serves as an excellent introduction for the uninitiated. Some college texts could learn a lesson on clarity from the authors' explanation of normal forms.

Chapter 6 has an interesting, short history of the development of SQL.

Chapter 7 describes some of the other free SQLs available, and also provides some insight into those features that MySQL/mSQL don't provide: things like stored procedures, triggers, transactions, and subselects. This chapter is useful for people trying to decide which SQL engine they need. If your sitting on the fence, trying to decide on MySQL/mSQL versus a commercial SQL offering, this chapter may help you decide.

The book's cover declares "Databases for Moderate-Sized Organizations & Web Sites", and the book delivers on this promise by including web-oriented sections on general CGI programming, Perl, and PHP.

The second half of the book provides a good reference to the MySQL/mSQL API's for several languages, as well as the MySQL/mSQL utilities, and a good reference for SQL itself. Most of this information is available elsewhere, and in more detail, but it's useful seeing the various language APIs presented side-by-side, particularly if you're not sure what language you might want to use. I've been contemplating Python programming for a while, and the simplicity of its MySQL API is certainly seductive.

What's Missing It's hard to find fault with the material included in the book, but I was surprised by some of the things that were left out.

There really is no ground-zero, simple mySQL/mSQL tutorial. For people beginning with a new SQL engine, it would be helpful to have a chapter that holds their hand, showing them how to create a database, then create a simple table, the insert records into the table, using the mysql utility. Tutorials are available for MySQL on the net (see www.mysql.com) and one is provided in the MySQL Reference Manual.

The book covers programming using a wide range of languages, but arguably one of the most popular languages, C, seems to get comparitively little coverage. There are only about six pages devoted to C programming, and one of those is a list of API functions. I would have welcomed more. [Admittedly, there is more on C in the book's Reference section, but this covers individual API calls, and doesn't provide any longer examples.]

There were a few rare cases in the book where I disagreed with the authors, or at least thought they needed to add a bit of additional amplification. On page 109, they state that:

"If you know that a lot of clients will be asking for the same summary information often... just create a new table containing that information and keep it up to date as the original table changes."

I have a bit of a nit to pick with this, as seven pages later they discuss the lack of a feature called triggers that would greatly simplify keeping a summary table in sync. Without a trigger, you'll have to devise your own method for keeping a summary table in step with the original table, which may be non-trivial depending on how often the original table changes and how often the summary table is accessed.

Summary This book tries to cover a lot of ground, and so it necessarily hits turf that some subset of readers won't care about.

For the seasoned MySQL programmer or database administrator, this book is a fine companion to the Reference Manual. With its clear introduction to SQL and relational database design, it also makes a good introduction to new SQL users in general.

Second Review - Dan Weeks

The Scenario There comes a time in every project when storing and retrieving data from flat files or proprietary formats (i.e., MS Excel) is no longer feasible. A Relational Database Management System (RDBMS) would be great, but Oracle, Sybase, and Informix can't be justified because of the cost. Along comes MySQL and mSQL, two of many freely available Database Management Systems. While neither of these DBMS's are as full featured and robust as their more mature brethren, they can definitely hold their own in the world of databases. For small and medium sized organizations and web sites either of these DBMS's can provide a sufficient level of functionality and flexibility to store and retrieve your data. What's Bad? The only shortfall I could find is the lack of references to other, more advanced books on the subject of database design and normalization (although that probably doesn't fit in with the publishers motives, but it would be nice). The book is well rounded and all of the authors are very knowledgeable and well written. What's Good? The first thing that struck me as absolutely wonderful about this book is the structure. By breaking the book into three sections the authors have allowed for many different database users to find this book valuable. Getting Started with MySQL and mSQL The first section, Getting Started with MySQL and mSQL has everything the novice needs to at least get one of the packages up and running so that they can experiment with a database system. The authors do a great job of making sure that the reader can skip sections if they don't pertain to them. Introductory topics like What is a Database? and History of MySQL are essential in making sure the subject matter is well rounded and accessible to everyone (especially to people like myself that did not take database classes at university). Later chapters explain and detail database design and normalization in a manner that is easy to understand so that the first databases you build won't suffer from repetition and data inconsistencies. The authors also do a good job of explaining SQL and specifically the variants that MySQL and mSQL use.

One of the high notes is the single chapter, Other Mid-Range Database Engines. Not only do the authors recognize that there are other database engines out there, they also point out what features MySQL and mSQL lack.

Making it Go The second section of the book, Database Programming, is a well written set of chapters that start off with the architecture of databases and client-server application and how they relate to data processing. The authors then quickly take you into the guts of interfacing with the database. They cover CGI, Perl, Python, PHP and other embedded HTML styles, C/C++, and Java. While I have only ever used Perl, Python, and C to interface to a database I can say that the chapters on the other API's seem to do just as good a job and at least allowed me to understand (if even in the most simple of terms) how those languages function in relation to your database engine of choice.

We all love our nutshell books, especially the XXX In A Nutshell series because they are great references. The foresight of the authors is incredibly prevalent in the third section, Reference. The authors actually took the time to make a ...In A Nutshell type of reference and then stick it into the book. Reference chapters that i have found invaluable so far are SQL (which includes separate sections for MySQL and mSQL's variations), and MySQL and mSQL System Variables. Other sections include C, PHP and Lite, Python, Perl, JDBC, and programs and utilities associated with MySQL and mSQL.

So What's In It For Me? If you are at all interested in database programming or you run a database at a small- to mid-sized organization or web site then this book is a must have. For those people that are in need of a little instruction on database design and normalization this book would be a good start. If you have been working with either MySQL or mSQL for a while then this book may be a bit basic for you, but the reference chapters will more than make up for the cost of the book.

Purchase this book at Amazon.com

Table of Contents

Preface
I. Getting Started with MySQL and mSQL
   1. Introduction to Relational Databases
   2. Database Design
   3. Installation
   4. MySQL
   5. mSQL
   6. SQL According to MySQL and mSQL
   7. Other Mid-Range Database Engines
II. Database Programming     121
   8. Database Application Architectures   9. CGI Programming
   10. Perl
   11. Python
   12. PHP and Other Support for Database-driven HTML
   13. C and C++
   14. Java and JDBC
III. Reference     229
   15. SQL Reference
   16. MySQL and mSQL System Variables
   17. MySQL and mSQL Programs and Utilities
   18. PHP and Lite Reference
   19. C Reference
   20. Python Reference
   21. Perl Reference
   22. JDBC Reference
Index

It's a great read, but there's not much to celebrate in "The Celebration Chronicles." Andrew Ross takes us deep into the strange world of Disney's hi-tech, meticulously planned model community of the future, still under construction in murky swampland south of Walt Disney World. The Celebration Chronicles: Life Liberty, and The Pursuit of Pr author Andrew Ross pages 340 publisher Ballantine Books rating 10/10 reviewer Jon Katz ISBN summary An unflinching look at Walt Disney's dream of the model community

What happens when one of the world?s richest and best-known corporations decides to build a prototype community of the future?

In "The Celebration Chronicles: Life, Liberty, and the Pursuit of Property Value in Disney?s New Town," sociologist Andrew Ross recounts his year living in an apartment in Disney?s new Florida town Celebration, witnessing the combustible mixture of corporatism, utopianism, media, technology, urban planning and politics with middle-class American life.

By and large, it was time well spent. If you care about technology, the nature of the mega-corporation or urban planning, this is an important and surprisingly touching story. Ross delineates the impossible expectations and inexorable pressures on even the best-intentioned modern corporation, as well as the genuine yearning of ordinary people to live in the kind of place Walt Disney invoked in his sometimes creepily cheery theme parks.

Disney reigned in the age of the corporate plutocrat, when moguls not only made money but could use their powerful companies to advance particular political or social interests.

Thus, Bill Paley made CBS News a great news organization mostly because he wanted to. Today, his stockholders would never let him spend money for anything as foolish and wasteful as good journalism. Nor would IBM?s shareholders look kindly on the discarded patriarchal traditions of Big Blue. It?s a rare corporate mission that lasts more than a year or two.

But the old Disney company was always something of a laboratory and playground for its founder?s fantasies. Horrified at the suburban sprawl that engulfed his beloved Southern California, Walt conceived of Disney Land in part as an antidote and a respite. Though it?s easy to jeer at the Mouse and its many tentacles, it?s dishonest not to acknowledge how many millions of people love the things Walt Disney built, and have been drawn to his creations and visions. Disney?s theme parks are about the closest thing America has these days to a universal cultural experience.

More than anything, Disney said he wanted to build a place where people were free of cars, smog and noise and were drawn into contact with one another; where a sense of community and personal contact could be restored. And perhaps most significantly, where the power of technology would be carefully harassed for the common good.

In his mind, Disney Land and Walt Disney World weren?t mere amusement parks, but prototypes of new kind of communities. He was a classic technological utopian, unwavering in his conviction that technics could solve the world?s problems. He imagined that the innovations he pioneered - from monorails to highly advanced waste disposal systems - would move beyond his parks, into the wider world. Disney gave his engineers and futurists nearly free rein, and their accomplishments captured the public imagination in a much deeper way than their real-world equivalents - epochal periods like the Space Age - ever did.

EPCOT was, in fact, to be the world?s premiere showcase for innovative new technologies. Disney had dreamed for years about this Experimental Prototype Community of Tomorrow; he hoped to build it for 20,000 employees who would run his giant new resort complex in central Florida.

The pedestrian, not the car, would be king. The city?s retail center would be encased in a giant bubble, surrounded by concentric zones allocated to high-density apartment housing, green belts and recreation (playgrounds, churches and schools). Surface transportation would be clean and electrical, garbage whisked away by underground systems, a sense of community encouraged by architectural design, community gathering spots and activities, and lavishly funded schools.

Disney never got to built his city of the future, of course. His vision turned out to be mistaken: the Space Age collapsed abruptly and inexplicably, and the defining technology of this era has been the computer and the Internet, not inter-galactic travel.

His idea was probably doomed, anyway, as the nature of corporations changed dramatically. Companies like Disney are no longer run by powerful decision-makers, autocrats who can muscle through tough decisions, but by amorphous analysts, lawyers, boards of directors and stockholders.

The modern mega-company has neither the mandate nor the attention span to invest in long-term innovation and creativity; the CEO who worries about anything but short-term profits will soon be looking for work. Most large corporations specialize in acquiring and divesting themselves of things other people have created.

Thus, Disney?s worst fears came true. His successors, led by his brother, junked his elaborate plans (never fully disclosed) for a modern city and turned EPCOT into a giant corporate exhibit center and international food court.

But the idea didn?t die completely. It just ended up taking a different form.

In the late 80?s, Disney CEO Michael Eisner, as big a monomaniac as Walt, revived a chunk of Disney?s idea when he gave the go ahead for the construction of Celebration, a meticulously -designed (even the "downtown" retail outlets are chosen by Disney execs) town the company is still constructing for 20,000 people in the swampland south of Walt Disney World. The stampede for houses was so intense that the company chose residents by lottery.

From its Victorian downtown to its obsessively- groomed parks, Celebration is the ultimate planned community. All its "antique"-styled homes are wired for Net access and the town boasts a progressive school, hospital and high-tech infrastructure. Some of the world?s best architects were hired to design its public and residential buildings. Yards were kept small and houses close together so that neighbors would be forced to run into one another and form connections. Elaborate regulations govern everything from paint colors to lawn care.

Celebration also quickly became a focal point of the New Urbanism movement - a philosophy that calls for a mix of old and new housing styles and seeks alternatives to the sprawl, traffic, strip malling and social isolation engulfing much of America.

It?s still way to early to know whether Celebration can work, but Ross - who?s director of American studies at New York University - encountered plenty of problems during his year-long stay. People still drove miles to discount chain stores for better prices and wider selections that the aesthetically-pleasing but non-utilitarian Celebration retail district offers. The innovative school was, from the first, bitter controversial among parents.

Since the town was never incorporated, but part of the Disney empire in Florida, town officials were appointed by the company, not elected. (Disney is not into representative democracy. According to the amazing agreement the company reached with state officials, Walt Disney World is operated more like the Vatican then a business operating under local and state laws).

The mother corporation inspired a bizarre love-hate relationship with residents, who accorded it almost mythic powers and had ridiculous expectations that it would keep their homes and their town as meticulously clean and efficient as its theme parks. Real life, of course, is vastly more complex than the Magic Kingdom and subject to a different set of economic laws.

But the modern corporation isn?t into anything for the long haul. After intense and creative early involvement, the Disney officials who worked on Celebration all moved on, and pressure grew for profits rather than experimentation.

Although Disney architects designed every detail of Celebration, the corporation took little responsibility for the work of the contractors who actually built it. There were widespread complaints about the poor quality of housing construction - leaky roofs, crumbling walls. Hit-and-run journalists delighted in poking fun at Mousetown and pounded Celebration whenever anything went wrong.

From the first, the company feared that digital connectivity might prove too empowering for its uneasy residents, so the town?s computers network - one of the most touted elements of Celebration early on - remained primitive. The town?s rural, central Florida neighbors remained suspicious and hostile.

Meanwhile, disenchanted residents found themselves in an awkward spot, says Ross. Many invested their life savings in their expensive homes and didn?t want bad publicity to endanger their investments. Ross has taken the deepest look yet at Disney?s experimental town. His writing reflects the fact that he was an outsider, a self-professed writer and visitor who never seemed to completely permeate the town?s carefully constructed veneer. But what he did get to see was plenty interesting.

"The Celebration Chronicles" is a fair-minded and intelligent look at this strange community. Ross avoids the temptation to paint Disney as callous and evil, but he also fails to give us a vivid picture of what life there is really like for the mixed (old and young, married and single, gay and straight) demographic community forming there. Celebration residents are quoted, but life there is not really captured.

Celebration is ultimately a sad, even hopeless story. Clearly, many Americans are unhappy with the noise, enforced mobility and disconnection of contemporary life, even as they rush to malls to save every penny they can. It?s depressing that an entertainment conglomerate is the only prominent entity in the America that has taken any bold step towards addressing these concerns. The federal government has largely opted out of urban planning, and most corporations are too volatile and bottom-line driven to persevere through ambitious, even radical undertakings.

Here was one of the bolder efforts in modern times to return some sense of community and beauty to a country whose home dwellers are forced to choose between declining urban environments that are either declining or ascending so quickly as to price out the middle class, and ugly and increasingly congested suburban ones. Celebration, an effort at a better middle ground, deserved more support scrutiny than either Disney or the media has provided. To that end, "The Celebration Chronicles" is compelling reading and long overdue reporting.

Reading this surprising and original book, it?s hard to avoid the feeling that the real and most insurmountable problem Celebration faces is that the iron-willed, single-minded bully who conjured it up and whose ghost hovers over every one of those carefully-manicured lawns - Walt himself - wasn?t around to push his dream to fruition.

Purchase this book at Amazon.

Talin has written one of the more interesting pieces that I've seen in a while, piercing the bubble of idyllic life that many people, and giving insight into what is, for all intents and purposes an industry. His synopsis: "I've been in the computer games industry since about 1983...I've come to the conclusion that the industry has gradually, imperceptibly, transformed from a cozy industry full of creative freedom and fun into a rather unpleasant place to work." Click below for more.

My name is Talin, and I've been in the computer games industry since about 1983. I've had a lot of fun, as well as a few "hits". I'm best known for the 1986 Amiga game "The Faery Tale Adventure", for which I still get occasional fan mail. I've worked on about a dozen projects all told, the most recent being a massively multiplayer game for SegaSoft's HEAT network.

I'm always amused be people's reactions when I tell them that I work in the computer games industry. "Computer games!" they say, "Gee, that must be fun!" At such times I usually pause, thinking "How do I break it to them?"

I've been in the industry a long time (since around 1983), and I've watched carefully the changing nature of the business. I remember the busts and booms, the changing platforms, the rise and fall of many companies. And I've come to the conclusion that the industry has gradually, imperceptibly, transformed from a cozy industry full of creative freedom and fun into a rather unpleasant place to work.

Computer game developers work in an industry where 90% of the profit is made from 10% of the products. Or to put it another way, 90% of the products simply die in the marketplace. Sometimes this is because the products themselves are dreck; There certainly is a lot of poorly designed, poorly debugged, formulaic, or simply content free products out there. In other cases, good products wither on the vine because they are inadequately marketed, or because they can't get through all of the noise and fluff that's clogging up the distribution chain.

When the games industry started, distributors were begging for product, but now you have to bribe Fry's or CompUSA a couple of hundred thousand to get your product placed somewhere where customers will actually see it.

And this doesn't even include the large number of products that never make it to market. In some cases, a publisher or development company runs out of money before it can finish a game, or is eaten by a larger company which immediately develops a case of indigestion and dies. (This has happened to my own projects twice.)

Having been involved in a number of large, multi-million dollar projects that never got released, or were pathetically marketed, I sometimes wonder whether the computer games industry isn't perhaps a net loss to the Gross National Product. I'm not even talking about the amount of lost productivity from people playing games (which I don't consider "lost"). Rather, what I mean is that it sometimes seems like more investment money is actually wasted developing and marketing failed games than is made in profits from successful ones.

Most of my industry colleagues that I've talked to about this have expressed similar feelings. One person said that the games industry is "a transfer of funds from the rich to the lucky". In my opinion, one would be foolish to invest in a game company.

Perhaps it's different in the big game publishers, where they crank out the same formulaic sports action game or first-person shooter over and over again. But in the smaller companies where I've spent my career, the vast majority of projects either never make it to market, or completely tank once they get there.

The economic realities of developing games induces what I call "The Lottery Mentality". Lotteries are based on the idea that we tend not to be able to think very rationally about small differences in probability. The California State Lottery has been called, for example, "a tax on people who can't do math". In the games industry, this takes the form of lying to ourselves about the potential chances of creating a "hit" game. We all know that our game has only a small chance of becoming a "hit" and thereby making a profit, yet we fool ourselves into thinking: "Yes, but MY game is going to be the ONE". As one producer put it: "You don't think anyone _intentionally_ tries to make a mediocre game?" (Well, there are some in fact who do, but that's beside the point.) But the fact is that your game is almost certainly going to be mediocre, in sales if not in quality, whether you like it or not.

The lottery mentality is what keeps investors pumping large amounts of money into the sinkhole of games development. After all, it's a very exciting, fast-paced, high-tech and "cool" sinkhole. It's "the wave of the future". I've watched how games get funded, and it's usually less a matter of the technical feasibility and artistic merits of the game, than it is the personal charm of the CEO of the development company. To paraphrase Alexis de Tocqueville: "What a fragile thing is human reason."

I should point out that my argument only applies to games written for computers, not game consoles. The economics of the console market are very different, primarily because the console manufacturers maintain a strict editorial control over what games can be published. As a result, the distribution chain for console-based software is far more consistent in quality. On the other hand, there's far less opportunity for innovation in the console market, and this is only partly explained by the strong 'parental' influence of the console manufacturers. Because consoles don't have keyboards, console games are extremely limited in the kinds of social interaction that they can support, which means that console-based games tend to be focused around kicking, jumping, hitting, running, and other brute force physical activities. This in turn limits the console market to a fairly narrow demographic, one that isn't interested in complex social interaction. Similarly, because consoles don't have hard drives, they are limited to games which are mostly "stateless", meaning that the player can only affect a small number of selected variables in the game environment.

Failed products and harsh economics aren't the only reason why the games industry has become a miserable place.

Part of the reason why I fled from Hollywood in the early 80's was because I realized that Hollywood, with it's creativity-stifling unions, bureaucratized studios, and disreputable agents, was not the way to a happy life. Not everyone gets to be a Spielberg or a Lucas, and in fact the vast majority of workers toil away at one narrowly-defined job with no creative freedom whatsoever. The few truly inspired creators, the ones with the really unique ideas, are targets for exploitation and fraud. When I realized, a few years ago, that the whole "Siliwood" thing was a bust, and that Hollywood was not going to take over, I breathed a sigh of relief.

Now I find the games industry is becoming more and more like Hollywood itself, where each person has his or her little job compartment or specialty, and must never stray outside of it for fear of stepping on someone's territory. "I don't understand," says the manager, "I thought you said you wanted a position as a programmer. Now you're telling me you want a position as an artist?" Even when they know and accept you as a multi-talented, multi-skilled person, they still have trouble figuring out ways to apply your skills in anything but a single narrowly-defined capacity.

I should also mention that the games industry has little respect for experience. What the games industry runs on is youthful energy. It loves to exploit 19 year old programmers who work 10-12 hours a day, get paid less than the standard wage for programmers in other industries, and don't know squat about software engineering principles. There are very few 40-year-old game programmers; I'm one of few who hasn't been "burnt out" by the murderous pace. But more and more I feel like I don't "fit in". I find myself less and less interested in doing the same games over and over again, targeted at an audience of 14-year old males who have been programmed by evolution to enjoy the thrill of combat and the hunt. Quake and Unreal are _great_ games from a design and technical standpoint, but frankly they bore me. (In case you are wondering, my two favorite games are Might and Magic II, and Civilization II).

Despite the fact that the games industry has aged tremendously in both it's bureaucratic structure and the sophistication of the technology, the software engineering practices it uses are still juvenile. It amazes me to find managers who have copies of classic works like Rapid Development_, _Writing Solid Code_, and _Peopleware_ on their bookshelves, yet somehow fail to actually apply the principles in those books. The culture of the industry is simply too strong, and trying to take the time to do things right (so that it saves time later) is like slogging through mud. The whole process by which games are budgeted and scheduled, for example, is something that I find amazing that anyone could take seriously.

Anybody who's studied software engineering knows that a schedule which underestimates the time needed to develop a project actually makes the project take _longer_. Countless case studies have shown this to be true. Yet we insist on shipping projects "by Christmas season" so that programmers are forced to waste their time, trying to "hurry up" to meet an arbitrary deadline. We continue to throw budgets and schedules together quickly, so that we can have them ready for a meeting with the publisher, without ever consulting the people who will actually work on the project (most of whom haven't been hired yet.)

The result is completely predictable: programmers that are under extreme stress who in turn create code full of bugs and defects. Project that end up a year later than they were scheduled. Isn't it interesting that some of the most successful game companies have adopted a "it will be done when it's done" policy?

Part of the problem is that our industry labors under the illusion that it is "like Hollywood". Film producers are usually able to turn out a film on time and within budgetary limits. But there's a difference -- film producers don't have to re-invent the camera each time they do a production. There are no "stable" technologies in the computer games industry, and the average useful life of a game "engine" is about two years.

The games industry is primarily an engineering industry, which means that what we do is solve problems. But solving problems, especially highly complex ones, knows no timetable. No one can predict how long it will take to invent a particular thing, because every invention is an accident, albeit a fortuitous one. The best you can do is increase the probability of such an accident occuring, a process which I have dubbed "accident husbandry."

Despite the fact that constant invention is critical to the industry, game companies still refuse, as far as I can tell, to fund any kind of research. Instead, each new game is itself a "research prototype", full of risks and unknowns. You might as well write "and here a miracle occurs" right on the PERT chart and be done with it.

Job stability is another thing that is lacking in the computer games field. It seems to be a common practice in small development companies to lay off the entire development team upon completion of a project. Usually this is because a small development company can only afford to pay salaries while a project is actually being funded by an outside source. It takes a long time to negotiate such a contract, and often the previous product finishes before the negotiations are complete. As a result, the development company has no choice but to unburden itself of workers who aren't producing any revenue. As a result of this high turnover rate, development companies are unable to maintain a solid body of institutional knowledge. Worse, it inclucates a sense of futility in the engineering staff. As one worker put it: "If you ship, you'll be fired." Don't get me wrong. I still like games. But the games industry isn't games.

I'm not advocating that the sources of funding should simply dry up. But I wish that investors and project planners would be more careful. Firstly, because I'm ethically offended by the idea of wasting other people's money. And secondly, because I'm sick of spending a year of my life working on a beautiful project, only to watch it go down in flames (And yes, I admit that there were times when the fault was my own...but not most of the time.)

I think that we'd all be happier if fewer games were actually produced. In my opinion, the primary result of this would be a higher percentage of good games on the market. Of course, there wouldn't be quite as many jobs, but I can tell you that there are a lot of fun, exciting jobs out there that have nothing to do with the games industry. For example, I recently I took a job at an e-commerce company. Now, I have absolutely no interest in e-commerce per se. But I found to my surprise that there are a lot of things about this job that are really fun:

• I get to do real research, to tinker around with new concepts
• I'm living on "internet time": Product cycles are in weeks, not years
• My experience and knowledge are highly respected.
• People look to me for help and answers, not to grind away code in silence
• Schedules are reasonable and flexible
• I'm learning a lot of new technologies
• I'm getting a chance to do something different for a change.
• The gender balance is a lot closer to 50%
• They appreciate and exploit my multiple skills and game-designer sensibilities.
• I get to think about social issues as well as technical ones
• The people are excited and enthusiastic rather than feeling burnt out.
• The pay is better

Of course, I still have a lot of game ideas I want to do...I'm not going to follow the example of Chris Crawford, and say "Farewell forever, games industry!" This isn't the first time I've taken a break away from games to do other work (for example, in 1987 I wrote a professional music sequencer, Music-X.)

But these days I'm far less interested in broadcasting my own ideas and stories (the "Death From Above" content distribution model), than I am in empowering the end-users to be able to realize their own ideas and fantasies. If I chose to do another game, it would have to be on very specific terms: An R&D project up front to eliminate the major risks, solid commitment to sound engineering principles, a rational schedule (or better yet, no schedule at all), and a project premise that involved a high level of social consciousness. "Community is King" is my motto now.

Alternatively, I think I'd enjoy just develop games as a hobby, completely open-sourced, and make money some other way. I've found that being an amateur game creator is more emotionally rewarding than being a After all, I'm in this for the fun, and for the chance to express myself creatively. If I wasn't, I'd be selling insurance or something.

Talin (Talin@ACM.org)
www.sylvantech.com/~talin
www.hackertourist.com/talin

Talin has written one of the more interesting pieces that I've seen in a while, piercing the bubble of idyllic life that many people, and giving insight into what is, for all intents and purposes an industry. His synopsis: "I've been in the computer games industry since about 1983...I've come to the conclusion that the industry has gradually, imperceptibly, transformed from a cozy industry full of creative freedom and fun into a rather unpleasant place to work." Click below for more.

My name is Talin, and I've been in the computer games industry since about 1983. I've had a lot of fun, as well as a few "hits". I'm best known for the 1986 Amiga game "The Faery Tale Adventure", for which I still get occasional fan mail. I've worked on about a dozen projects all told, the most recent being a massively multiplayer game for SegaSoft's HEAT network.

I'm always amused be people's reactions when I tell them that I work in the computer games industry. "Computer games!" they say, "Gee, that must be fun!" At such times I usually pause, thinking "How do I break it to them?"

I've been in the industry a long time (since around 1983), and I've watched carefully the changing nature of the business. I remember the busts and booms, the changing platforms, the rise and fall of many companies. And I've come to the conclusion that the industry has gradually, imperceptibly, transformed from a cozy industry full of creative freedom and fun into a rather unpleasant place to work.

Computer game developers work in an industry where 90% of the profit is made from 10% of the products. Or to put it another way, 90% of the products simply die in the marketplace. Sometimes this is because the products themselves are dreck; There certainly is a lot of poorly designed, poorly debugged, formulaic, or simply content free products out there. In other cases, good products wither on the vine because they are inadequately marketed, or because they can't get through all of the noise and fluff that's clogging up the distribution chain.

When the games industry started, distributors were begging for product, but now you have to bribe Fry's or CompUSA a couple of hundred thousand to get your product placed somewhere where customers will actually see it.

And this doesn't even include the large number of products that never make it to market. In some cases, a publisher or development company runs out of money before it can finish a game, or is eaten by a larger company which immediately develops a case of indigestion and dies. (This has happened to my own projects twice.)

Having been involved in a number of large, multi-million dollar projects that never got released, or were pathetically marketed, I sometimes wonder whether the computer games industry isn't perhaps a net loss to the Gross National Product. I'm not even talking about the amount of lost productivity from people playing games (which I don't consider "lost"). Rather, what I mean is that it sometimes seems like more investment money is actually wasted developing and marketing failed games than is made in profits from successful ones.

Most of my industry colleagues that I've talked to about this have expressed similar feelings. One person said that the games industry is "a transfer of funds from the rich to the lucky". In my opinion, one would be foolish to invest in a game company.

Perhaps it's different in the big game publishers, where they crank out the same formulaic sports action game or first-person shooter over and over again. But in the smaller companies where I've spent my career, the vast majority of projects either never make it to market, or completely tank once they get there.

The economic realities of developing games induces what I call "The Lottery Mentality". Lotteries are based on the idea that we tend not to be able to think very rationally about small differences in probability. The California State Lottery has been called, for example, "a tax on people who can't do math". In the games industry, this takes the form of lying to ourselves about the potential chances of creating a "hit" game. We all know that our game has only a small chance of becoming a "hit" and thereby making a profit, yet we fool ourselves into thinking: "Yes, but MY game is going to be the ONE". As one producer put it: "You don't think anyone _intentionally_ tries to make a mediocre game?" (Well, there are some in fact who do, but that's beside the point.) But the fact is that your game is almost certainly going to be mediocre, in sales if not in quality, whether you like it or not.

The lottery mentality is what keeps investors pumping large amounts of money into the sinkhole of games development. After all, it's a very exciting, fast-paced, high-tech and "cool" sinkhole. It's "the wave of the future". I've watched how games get funded, and it's usually less a matter of the technical feasibility and artistic merits of the game, than it is the personal charm of the CEO of the development company. To paraphrase Alexis de Tocqueville: "What a fragile thing is human reason."

I should point out that my argument only applies to games written for computers, not game consoles. The economics of the console market are very different, primarily because the console manufacturers maintain a strict editorial control over what games can be published. As a result, the distribution chain for console-based software is far more consistent in quality. On the other hand, there's far less opportunity for innovation in the console market, and this is only partly explained by the strong 'parental' influence of the console manufacturers. Because consoles don't have keyboards, console games are extremely limited in the kinds of social interaction that they can support, which means that console-based games tend to be focused around kicking, jumping, hitting, running, and other brute force physical activities. This in turn limits the console market to a fairly narrow demographic, one that isn't interested in complex social interaction. Similarly, because consoles don't have hard drives, they are limited to games which are mostly "stateless", meaning that the player can only affect a small number of selected variables in the game environment.

Failed products and harsh economics aren't the only reason why the games industry has become a miserable place.

Part of the reason why I fled from Hollywood in the early 80's was because I realized that Hollywood, with it's creativity-stifling unions, bureaucratized studios, and disreputable agents, was not the way to a happy life. Not everyone gets to be a Spielberg or a Lucas, and in fact the vast majority of workers toil away at one narrowly-defined job with no creative freedom whatsoever. The few truly inspired creators, the ones with the really unique ideas, are targets for exploitation and fraud. When I realized, a few years ago, that the whole "Siliwood" thing was a bust, and that Hollywood was not going to take over, I breathed a sigh of relief.

Now I find the games industry is becoming more and more like Hollywood itself, where each person has his or her little job compartment or specialty, and must never stray outside of it for fear of stepping on someone's territory. "I don't understand," says the manager, "I thought you said you wanted a position as a programmer. Now you're telling me you want a position as an artist?" Even when they know and accept you as a multi-talented, multi-skilled person, they still have trouble figuring out ways to apply your skills in anything but a single narrowly-defined capacity.

I should also mention that the games industry has little respect for experience. What the games industry runs on is youthful energy. It loves to exploit 19 year old programmers who work 10-12 hours a day, get paid less than the standard wage for programmers in other industries, and don't know squat about software engineering principles. There are very few 40-year-old game programmers; I'm one of few who hasn't been "burnt out" by the murderous pace. But more and more I feel like I don't "fit in". I find myself less and less interested in doing the same games over and over again, targeted at an audience of 14-year old males who have been programmed by evolution to enjoy the thrill of combat and the hunt. Quake and Unreal are _great_ games from a design and technical standpoint, but frankly they bore me. (In case you are wondering, my two favorite games are Might and Magic II, and Civilization II).

Despite the fact that the games industry has aged tremendously in both it's bureaucratic structure and the sophistication of the technology, the software engineering practices it uses are still juvenile. It amazes me to find managers who have copies of classic works like Rapid Development_, _Writing Solid Code_, and _Peopleware_ on their bookshelves, yet somehow fail to actually apply the principles in those books. The culture of the industry is simply too strong, and trying to take the time to do things right (so that it saves time later) is like slogging through mud. The whole process by which games are budgeted and scheduled, for example, is something that I find amazing that anyone could take seriously.

Anybody who's studied software engineering knows that a schedule which underestimates the time needed to develop a project actually makes the project take _longer_. Countless case studies have shown this to be true. Yet we insist on shipping projects "by Christmas season" so that programmers are forced to waste their time, trying to "hurry up" to meet an arbitrary deadline. We continue to throw budgets and schedules together quickly, so that we can have them ready for a meeting with the publisher, without ever consulting the people who will actually work on the project (most of whom haven't been hired yet.)

The result is completely predictable: programmers that are under extreme stress who in turn create code full of bugs and defects. Project that end up a year later than they were scheduled. Isn't it interesting that some of the most successful game companies have adopted a "it will be done when it's done" policy?

Part of the problem is that our industry labors under the illusion that it is "like Hollywood". Film producers are usually able to turn out a film on time and within budgetary limits. But there's a difference -- film producers don't have to re-invent the camera each time they do a production. There are no "stable" technologies in the computer games industry, and the average useful life of a game "engine" is about two years.

The games industry is primarily an engineering industry, which means that what we do is solve problems. But solving problems, especially highly complex ones, knows no timetable. No one can predict how long it will take to invent a particular thing, because every invention is an accident, albeit a fortuitous one. The best you can do is increase the probability of such an accident occuring, a process which I have dubbed "accident husbandry."

Despite the fact that constant invention is critical to the industry, game companies still refuse, as far as I can tell, to fund any kind of research. Instead, each new game is itself a "research prototype", full of risks and unknowns. You might as well write "and here a miracle occurs" right on the PERT chart and be done with it.

Job stability is another thing that is lacking in the computer games field. It seems to be a common practice in small development companies to lay off the entire development team upon completion of a project. Usually this is because a small development company can only afford to pay salaries while a project is actually being funded by an outside source. It takes a long time to negotiate such a contract, and often the previous product finishes before the negotiations are complete. As a result, the development company has no choice but to unburden itself of workers who aren't producing any revenue. As a result of this high turnover rate, development companies are unable to maintain a solid body of institutional knowledge. Worse, it inclucates a sense of futility in the engineering staff. As one worker put it: "If you ship, you'll be fired." Don't get me wrong. I still like games. But the games industry isn't games.

I'm not advocating that the sources of funding should simply dry up. But I wish that investors and project planners would be more careful. Firstly, because I'm ethically offended by the idea of wasting other people's money. And secondly, because I'm sick of spending a year of my life working on a beautiful project, only to watch it go down in flames (And yes, I admit that there were times when the fault was my own...but not most of the time.)

I think that we'd all be happier if fewer games were actually produced. In my opinion, the primary result of this would be a higher percentage of good games on the market. Of course, there wouldn't be quite as many jobs, but I can tell you that there are a lot of fun, exciting jobs out there that have nothing to do with the games industry. For example, I recently I took a job at an e-commerce company. Now, I have absolutely no interest in e-commerce per se. But I found to my surprise that there are a lot of things about this job that are really fun:

• I get to do real research, to tinker around with new concepts
• I'm living on "internet time": Product cycles are in weeks, not years
• My experience and knowledge are highly respected.
• People look to me for help and answers, not to grind away code in silence
• Schedules are reasonable and flexible
• I'm learning a lot of new technologies
• I'm getting a chance to do something different for a change.
• The gender balance is a lot closer to 50%
• They appreciate and exploit my multiple skills and game-designer sensibilities.
• I get to think about social issues as well as technical ones
• The people are excited and enthusiastic rather than feeling burnt out.
• The pay is better

Of course, I still have a lot of game ideas I want to do...I'm not going to follow the example of Chris Crawford, and say "Farewell forever, games industry!" This isn't the first time I've taken a break away from games to do other work (for example, in 1987 I wrote a professional music sequencer, Music-X.)

But these days I'm far less interested in broadcasting my own ideas and stories (the "Death From Above" content distribution model), than I am in empowering the end-users to be able to realize their own ideas and fantasies. If I chose to do another game, it would have to be on very specific terms: An R&D project up front to eliminate the major risks, solid commitment to sound engineering principles, a rational schedule (or better yet, no schedule at all), and a project premise that involved a high level of social consciousness. "Community is King" is my motto now.

Alternatively, I think I'd enjoy just develop games as a hobby, completely open-sourced, and make money some other way. I've found that being an amateur game creator is more emotionally rewarding than being a After all, I'm in this for the fun, and for the chance to express myself creatively. If I wasn't, I'd be selling insurance or something.

Talin (Talin@ACM.org)
www.sylvantech.com/~talin
www.hackertourist.com/talin

Talin has written one of the more interesting pieces that I've seen in a while, piercing the bubble of idyllic life that many people, and giving insight into what is, for all intents and purposes an industry. His synopsis: "I've been in the computer games industry since about 1983...I've come to the conclusion that the industry has gradually, imperceptibly, transformed from a cozy industry full of creative freedom and fun into a rather unpleasant place to work." Click below for more.

My name is Talin, and I've been in the computer games industry since about 1983. I've had a lot of fun, as well as a few "hits". I'm best known for the 1986 Amiga game "The Faery Tale Adventure", for which I still get occasional fan mail. I've worked on about a dozen projects all told, the most recent being a massively multiplayer game for SegaSoft's HEAT network.

I'm always amused be people's reactions when I tell them that I work in the computer games industry. "Computer games!" they say, "Gee, that must be fun!" At such times I usually pause, thinking "How do I break it to them?"

I've been in the industry a long time (since around 1983), and I've watched carefully the changing nature of the business. I remember the busts and booms, the changing platforms, the rise and fall of many companies. And I've come to the conclusion that the industry has gradually, imperceptibly, transformed from a cozy industry full of creative freedom and fun into a rather unpleasant place to work.

Computer game developers work in an industry where 90% of the profit is made from 10% of the products. Or to put it another way, 90% of the products simply die in the marketplace. Sometimes this is because the products themselves are dreck; There certainly is a lot of poorly designed, poorly debugged, formulaic, or simply content free products out there. In other cases, good products wither on the vine because they are inadequately marketed, or because they can't get through all of the noise and fluff that's clogging up the distribution chain.

When the games industry started, distributors were begging for product, but now you have to bribe Fry's or CompUSA a couple of hundred thousand to get your product placed somewhere where customers will actually see it.

And this doesn't even include the large number of products that never make it to market. In some cases, a publisher or development company runs out of money before it can finish a game, or is eaten by a larger company which immediately develops a case of indigestion and dies. (This has happened to my own projects twice.)

Having been involved in a number of large, multi-million dollar projects that never got released, or were pathetically marketed, I sometimes wonder whether the computer games industry isn't perhaps a net loss to the Gross National Product. I'm not even talking about the amount of lost productivity from people playing games (which I don't consider "lost"). Rather, what I mean is that it sometimes seems like more investment money is actually wasted developing and marketing failed games than is made in profits from successful ones.

Most of my industry colleagues that I've talked to about this have expressed similar feelings. One person said that the games industry is "a transfer of funds from the rich to the lucky". In my opinion, one would be foolish to invest in a game company.

Perhaps it's different in the big game publishers, where they crank out the same formulaic sports action game or first-person shooter over and over again. But in the smaller companies where I've spent my career, the vast majority of projects either never make it to market, or completely tank once they get there.

The economic realities of developing games induces what I call "The Lottery Mentality". Lotteries are based on the idea that we tend not to be able to think very rationally about small differences in probability. The California State Lottery has been called, for example, "a tax on people who can't do math". In the games industry, this takes the form of lying to ourselves about the potential chances of creating a "hit" game. We all know that our game has only a small chance of becoming a "hit" and thereby making a profit, yet we fool ourselves into thinking: "Yes, but MY game is going to be the ONE". As one producer put it: "You don't think anyone _intentionally_ tries to make a mediocre game?" (Well, there are some in fact who do, but that's beside the point.) But the fact is that your game is almost certainly going to be mediocre, in sales if not in quality, whether you like it or not.

The lottery mentality is what keeps investors pumping large amounts of money into the sinkhole of games development. After all, it's a very exciting, fast-paced, high-tech and "cool" sinkhole. It's "the wave of the future". I've watched how games get funded, and it's usually less a matter of the technical feasibility and artistic merits of the game, than it is the personal charm of the CEO of the development company. To paraphrase Alexis de Tocqueville: "What a fragile thing is human reason."

I should point out that my argument only applies to games written for computers, not game consoles. The economics of the console market are very different, primarily because the console manufacturers maintain a strict editorial control over what games can be published. As a result, the distribution chain for console-based software is far more consistent in quality. On the other hand, there's far less opportunity for innovation in the console market, and this is only partly explained by the strong 'parental' influence of the console manufacturers. Because consoles don't have keyboards, console games are extremely limited in the kinds of social interaction that they can support, which means that console-based games tend to be focused around kicking, jumping, hitting, running, and other brute force physical activities. This in turn limits the console market to a fairly narrow demographic, one that isn't interested in complex social interaction. Similarly, because consoles don't have hard drives, they are limited to games which are mostly "stateless", meaning that the player can only affect a small number of selected variables in the game environment.

Failed products and harsh economics aren't the only reason why the games industry has become a miserable place.

Part of the reason why I fled from Hollywood in the early 80's was because I realized that Hollywood, with it's creativity-stifling unions, bureaucratized studios, and disreputable agents, was not the way to a happy life. Not everyone gets to be a Spielberg or a Lucas, and in fact the vast majority of workers toil away at one narrowly-defined job with no creative freedom whatsoever. The few truly inspired creators, the ones with the really unique ideas, are targets for exploitation and fraud. When I realized, a few years ago, that the whole "Siliwood" thing was a bust, and that Hollywood was not going to take over, I breathed a sigh of relief.

Now I find the games industry is becoming more and more like Hollywood itself, where each person has his or her little job compartment or specialty, and must never stray outside of it for fear of stepping on someone's territory. "I don't understand," says the manager, "I thought you said you wanted a position as a programmer. Now you're telling me you want a position as an artist?" Even when they know and accept you as a multi-talented, multi-skilled person, they still have trouble figuring out ways to apply your skills in anything but a single narrowly-defined capacity.

I should also mention that the games industry has little respect for experience. What the games industry runs on is youthful energy. It loves to exploit 19 year old programmers who work 10-12 hours a day, get paid less than the standard wage for programmers in other industries, and don't know squat about software engineering principles. There are very few 40-year-old game programmers; I'm one of few who hasn't been "burnt out" by the murderous pace. But more and more I feel like I don't "fit in". I find myself less and less interested in doing the same games over and over again, targeted at an audience of 14-year old males who have been programmed by evolution to enjoy the thrill of combat and the hunt. Quake and Unreal are _great_ games from a design and technical standpoint, but frankly they bore me. (In case you are wondering, my two favorite games are Might and Magic II, and Civilization II).

Despite the fact that the games industry has aged tremendously in both it's bureaucratic structure and the sophistication of the technology, the software engineering practices it uses are still juvenile. It amazes me to find managers who have copies of classic works like Rapid Development_, _Writing Solid Code_, and _Peopleware_ on their bookshelves, yet somehow fail to actually apply the principles in those books. The culture of the industry is simply too strong, and trying to take the time to do things right (so that it saves time later) is like slogging through mud. The whole process by which games are budgeted and scheduled, for example, is something that I find amazing that anyone could take seriously.

Anybody who's studied software engineering knows that a schedule which underestimates the time needed to develop a project actually makes the project take _longer_. Countless case studies have shown this to be true. Yet we insist on shipping projects "by Christmas season" so that programmers are forced to waste their time, trying to "hurry up" to meet an arbitrary deadline. We continue to throw budgets and schedules together quickly, so that we can have them ready for a meeting with the publisher, without ever consulting the people who will actually work on the project (most of whom haven't been hired yet.)

The result is completely predictable: programmers that are under extreme stress who in turn create code full of bugs and defects. Project that end up a year later than they were scheduled. Isn't it interesting that some of the most successful game companies have adopted a "it will be done when it's done" policy?

Part of the problem is that our industry labors under the illusion that it is "like Hollywood". Film producers are usually able to turn out a film on time and within budgetary limits. But there's a difference -- film producers don't have to re-invent the camera each time they do a production. There are no "stable" technologies in the computer games industry, and the average useful life of a game "engine" is about two years.

The games industry is primarily an engineering industry, which means that what we do is solve problems. But solving problems, especially highly complex ones, knows no timetable. No one can predict how long it will take to invent a particular thing, because every invention is an accident, albeit a fortuitous one. The best you can do is increase the probability of such an accident occuring, a process which I have dubbed "accident husbandry."

Despite the fact that constant invention is critical to the industry, game companies still refuse, as far as I can tell, to fund any kind of research. Instead, each new game is itself a "research prototype", full of risks and unknowns. You might as well write "and here a miracle occurs" right on the PERT chart and be done with it.

Job stability is another thing that is lacking in the computer games field. It seems to be a common practice in small development companies to lay off the entire development team upon completion of a project. Usually this is because a small development company can only afford to pay salaries while a project is actually being funded by an outside source. It takes a long time to negotiate such a contract, and often the previous product finishes before the negotiations are complete. As a result, the development company has no choice but to unburden itself of workers who aren't producing any revenue. As a result of this high turnover rate, development companies are unable to maintain a solid body of institutional knowledge. Worse, it inclucates a sense of futility in the engineering staff. As one worker put it: "If you ship, you'll be fired." Don't get me wrong. I still like games. But the games industry isn't games.

I'm not advocating that the sources of funding should simply dry up. But I wish that investors and project planners would be more careful. Firstly, because I'm ethically offended by the idea of wasting other people's money. And secondly, because I'm sick of spending a year of my life working on a beautiful project, only to watch it go down in flames (And yes, I admit that there were times when the fault was my own...but not most of the time.)

I think that we'd all be happier if fewer games were actually produced. In my opinion, the primary result of this would be a higher percentage of good games on the market. Of course, there wouldn't be quite as many jobs, but I can tell you that there are a lot of fun, exciting jobs out there that have nothing to do with the games industry. For example, I recently I took a job at an e-commerce company. Now, I have absolutely no interest in e-commerce per se. But I found to my surprise that there are a lot of things about this job that are really fun:

• I get to do real research, to tinker around with new concepts
• I'm living on "internet time": Product cycles are in weeks, not years
• My experience and knowledge are highly respected.
• People look to me for help and answers, not to grind away code in silence
• Schedules are reasonable and flexible
• I'm learning a lot of new technologies
• I'm getting a chance to do something different for a change.
• The gender balance is a lot closer to 50%
• They appreciate and exploit my multiple skills and game-designer sensibilities.
• I get to think about social issues as well as technical ones
• The people are excited and enthusiastic rather than feeling burnt out.
• The pay is better

Of course, I still have a lot of game ideas I want to do...I'm not going to follow the example of Chris Crawford, and say "Farewell forever, games industry!" This isn't the first time I've taken a break away from games to do other work (for example, in 1987 I wrote a professional music sequencer, Music-X.)

But these days I'm far less interested in broadcasting my own ideas and stories (the "Death From Above" content distribution model), than I am in empowering the end-users to be able to realize their own ideas and fantasies. If I chose to do another game, it would have to be on very specific terms: An R&D project up front to eliminate the major risks, solid commitment to sound engineering principles, a rational schedule (or better yet, no schedule at all), and a project premise that involved a high level of social consciousness. "Community is King" is my motto now.

Alternatively, I think I'd enjoy just develop games as a hobby, completely open-sourced, and make money some other way. I've found that being an amateur game creator is more emotionally rewarding than being a After all, I'm in this for the fun, and for the chance to express myself creatively. If I wasn't, I'd be selling insurance or something.

Talin (Talin@ACM.org)
www.sylvantech.com/~talin
www.hackertourist.com/talin

Thanks to Cliff Lampe for his review of Ed Regis' book Nano: The Emerging Science of Nanotechnology. The author of Who Got Einstein's Office?, and similar books, Regis' takes a look at the personalities and social history behind nanotechnology. Click below to read more. Nano: The Emerging Science of Nanotechnology author Ed Regis pages 340 publisher Little, Brown and Company rating 8/10 reviewer Cliff Lampe ISBN summary Nice narrative about everyone's favorite fringe... The Scenario

Ed Regis, in this 1996 offering, makes the comparison between the believers of the advent of Nanotechnology and cults. K. Eric Drexler plays the role of charismatic leader, there is a belief in an utopian Breakthrough and a nearly blind faith in the correctness of their vision. The Nano faithful look at each other as if they are in on a grand joke of some sort. What Regis attempts to do with his book is to convince the non-Believing among us. By painting a human face on the technology through a description of Drexler himself, Regis converts by making this seem like a story of humanity rather than technology. It's much the same technique that Matthew used to convince people of the validity of Christianity in an earlier text on a novel idea.

Chances are that you are already in one of two camps. If you are already a Believer, you know that the inevitable march of molecular nanotechnology is knocking on the door. If you are a Doubter, it sounds like a load of steaming hooie that this drastic a change of technology could happen in our lifetime.

Whether you are a Believer or a Doubter, Regis is trying to speak to you with this engaging and readable book. By outlining the history of atom level research, and creating a parallel story related to Drexler's advocacy of the technology, Regis is able to blend a human story with a description of nanotech that is more engaging than Engines of Creation and less techy than Nanosystems.

What's Bad?

There is definitely a paeanistic edge to this book. Regis takes some pain to paint Drexler in the most positive light possible. He even seems to minimize Feynman's contributions, painting the physicist as a curmudgeon to prove that while he may have mentioned the idea twenty ideas ago, it took Drexler to get the ball rolling on manipulating matter on the molecular level.

While Regis does a good job of analyzing fuller aspects of the implications of nanotechnology, especially in the latter half of the book, he often doesn't go far enough in his analysis of these effects. "Slant" by Greg Bear is a better picture of the World After if you are interested in the topic. One last caveat is that the three year time period since publication of the book has seen some exciting changes in the field which are of course not covered therein.

What's Good?

This book has a lot going for it. The narrative voice is engaging and makes for an easy read. Regis also does a good job of balancing a plausible description of the technology with succinct scientific descriptions, avoiding some of the super techno speak of previous books on nanotechnology that threatened to cross the eyes of the simple geek. Also, it does a good job of addressing how the technology has been surprising in it's progress, moving less quickly than expected at some points and more quickly at others.

So What's In It For Me?

You get an entertaining read that, while biased, presents a view of nanotechnology that is vastly more satisfying than the smattering of magazine articles or usenet posts that have described the development of the technology so far. It's also a good book if you are a Believer dwelling amongst the unfaithful, to describe what precisely it is that gets you so excited to your friends and loved ones. I had my spouse read excerpts to prove that I wasn't coming up with this crap on my own.

The other thing you hopefully get from this book, especially if you are a Believer, is a renewed sense of vigor and excitement about the possibilities of this technology. Personally, as a Believer I came back with a strong sense of the future, and of the role this emerging technology will play in it.

Other important links... Check out the Foresight Institute and tell 'em Hemos sent ya.

Buy this fine text at Amazon

The return of SEGV brings with it a review of Michael J. Hammel's The Artists' Guide to the GIMP. This is an interesting book for those artists and wanna-be artists using the GIMP, and wanting to learn more what you/they can do-click below for more information. The Artists' Guide to the GIMP author Michael J. Hammel pages 340 publisher S rating 8/10 reviewer SEGV ISBN summary A well-done user manual for the GIMP. Walks the reader through common GIMP tasks with practical advice and suggestions.

User Manual

The GIMP has been hailed as an open source alternative to such commercial image manipulation "killer apps" as Adobe Photoshop. However, there are obvious areas where the GIMP falls short. For example, it does not come with a commercial quality printed user manual.

Now GIMP aficionados have an option: Michael Hammel has written what amounts to a user manual for the GIMP. It is "meant to be a reference guide for non-technical users -- people who want to use the GIMP to do real work."

Topic Coverage

The book covers release 1.0 of the GNU Image Manipulation Program. The first half covers GIMP features and functionality. The second half contains many examples of filters and script-fu effects applied to images.

The book does not cover GIMP development, particularly plug-ins and scripting. However, the author does mention that these are potential topics for revised editions.

The introductory chapters cover such basics as graphics formats, colour models, resolution, and so forth. The author also briefly covers SANE, Ghostscript, the GFig plug-in, the gimprc file, and fonts.

Explanatory Style

The author adopts a relatively informal explanatory style which I found easy and enjoyable to read, while not detracting from the topic at hand. It is clear that the author understands what he is writing about, and also how to communicate with the casual reader.

He offers tips throughout the text, from effective settings for specific dialogs to how to scan three-dimensional objects. He's also at ease enough to criticize aspects of the application where deserved, such as inconsistent dialogs or awkward interfaces. This honesty reassures the reader that he's on her side.

The author points out where GIMP and Photoshop are alike and differ, which will be a boon to readers with experience with the latter.

Tutorial Approach

Many of the chapters conclude with a tutorial summarizing the material covered: 16 pages in all. They are easy enough to follow and serve to reinforce the concepts learned.

Frequently the author employs a "how-to" approach when describing a feature. For example, he uses an image of a skyline to demonstrate how guides can help select buildings. He enumerates the steps you might take to correct a scanned image.

Book and CD-ROM

The book is printed on glossy paper in full colour. This is important, as many of the images illustrate subtle graphic effects. For example, an image may be a slightly brightened or blurred version of another.

I'm not sure how well the book would stand up to everyday use. My copy developed a cracked spine, so it's possible to lose a page or two if the reader is not careful.

The CD-ROM contains the software, although I'm sure most will acquire later versions from the net. It also includes the book's tutorials, images, and more images from the author's collection, as well as documentation, resources, and links.

There are plenty of tables of shortcuts and modifiers, but strangely no quick reference card (an obvious added value).

Drawbacks

The book as one or two minor drawbacks. Generally, there are a couple of places where the text could have been improved.

Some extended explanations (e.g., crop tool) are very confusing. The reader is hard put to make progress without the application running in front of her. Admittedly, part of the blame for this lies with the application itself.

The author references some Linux Journal covers, yet does not provide their images for illustration.

Summary

I've seen industry award-winning commercial user manuals, and this book is in that league. If you're looking for a simple user manual for the GIMP, this is it.

If you're looking for a more advanced manual or reference, you might be a little bit disappointed. There are still stones left un-turned.

If you're looking for an art book, again you might be disappointed. It isn't a text on graphic design, although there are tips throughout.

It's a user manual for the GIMP.

You can pick it up at Amazon.

TABLE OF CONTENTS

Preface
1. Introduction
2. GIMP Basics
3. GIMP Windows
4. The Toolbox
5. Selections
6. Layers and Channels
7. Colors and Text
8. Drawing and Painting
9. Using Transforms
10. Gradients
11. Scanning, Printing, and Print Media
Part 2: Filters and Script-Fu Effects
12. Artistic
13. Blur
14. Colors
15. Distorts
16. Edge-Detect and Combine
17. Enhance
18. Glass Effects
19. Light Effects
20. Map and Miscellaneous
21. Noise
22. Render
23. Script-Fu
Glossary
Appendix A: The gimprc File
Appendix B: Keyboard Shortcuts
Appendix C: Adding Fonts to Your System
Index
About the CD-ROM

Despite his long turnaround time, I still have not yet killed CowboyNeal for his long-delayed review of Jeff Tranter and Paul Raines' Tcl/Tk in a Nutshell. Part of the well known O'Reilly Nutshell series, this is a great book for those getting seriously into Tcl/Tk, or those who need a desktop reference. Click below for more information. Tcl/Tk in a Nutshell author Paul Raines & Jeff Tranter pages ? publisher O'Reilly and Associates rating 7/10 reviewer CowboyNeal ISBN summary Not for beginners, this book makes a wonderful desktop reference.
Rating: 7/10 What's Good? Being another book in the "nutshell" series, it's no surprise that this book contains all the commonly used commands in Tcl/Tk. Designed to sit on your desktop and help you look up those commands you forgot, this book is a weclome aid to any forgetful Tcl/Tk programmer. Each description has just enough to help one remember the command, without going too in-depth. Each section is devoted to the most oft-used Tcl/Tk tools, such as Expect and [incr Tcl]. The chapters covering the C interfaces use the same style as Java in a Nutshell's class reference, simply listing the function name, it's arguments, and the argument types. While not the best instructional aid, if you already know the function, it's just enough to remind you of how to use it. I really liked the compactness and simplicity of this in previous "nutshell" books, and I like it here as well. When covering some of the extentions of Tcl/Tk (Tix, for example), longer, more in-depth explanatations of each option and/or argument are given, as many people may not have used Tix before. Chapter 15, "Hints and Tips for the Tcl Programmer," is particularly useful, as it contains many "gotchas," the "Tcl way" of doing things, and things that might confuse beginning Tcl/Tk programmers (such as Tcl's parsing), and even a few things that Tcl/Tk gurus may want to brush up on. What's Bad? What I like about some "nutshell" books is that they often provide enough background for one to learn the language that is the subject of the book and begin programming in it. An example of this "Java in a Nutshell", one of my favorites. This book, however, assumes the reader is already a competent Tcl/Tk programmer, and makes no attempts to give an introduction to Tcl or Tk. I read this book in the hopes of picking up Tcl/Tk, but unfortunately it was not written to teach. When I do learn Tcl/Tk, however, I'll have a valuable resource handy to assist me in my coding. Some of the Tcl/Tk tools covered may not be used by everyone (such as Tclodbc), which may make some people as if some parts of the book will go unused. I found that if one uses only the core Tcl/Tk commands, then the majority of the book won't even aid you, as it is aimed at Tcl/Tk extensions. What else is bad? In all seriousness, I couldn't even nitpick further. For a desktop Tcl/Tk reference, this one is tough to beat. I even found myself liking the index. Who should buy this book? If you already know Tcl/Tk, then this book will be a great aid, especially of you use extensions, such as Oratcl or [incr Tcl], then this book will be a great help in remembering the commmands you don't use often, but need to get a quick synopsis of. If you're looking to learn Tcl/Tk, I wouldn't recommend this book, as it doesn't got into a great amount of detail. It would probably help one who hasn't written Tcl/Tk in a while, and is feeling a little rusty get back up to speed quickly.

You can pick it up at Amazon.

Table of Contents

Preface

1. Introduction
2. Tcl Core Commands
3. Tk Core Commands
4. The Tcl C Interface
5. The Tk C Interface
6. Expect
7. [incr Tcl]
8. [incr Tk]
9. Tix
10. TclX
11. BLT
12. Oratcl
13. Sybtcl
14. Tclodbc
15. Hints and Tips for the Tcl Programmer

Appendix - Tcl Resources

Index

Kurt Gray sent a review of Beginning Linux Programming, by Neil Matthew & Richard Stones. Click here to learn how to contribute more code. Beginning Linux Programming author Neil Matthew & Richard Stones pages 710 publisher Wrox Press rating 8/10 reviewer Kurt Gray ISBN summary A fair time worthy of your UNIX programming virginity.

Hark Ye Newbies, the Clue Phone Ringeth!

The trees felled to print this book died for a worthy cause: to entice more programmers to hang out at Camp Linux, especially newbie programmers. Our two friendly co-authors, their three editors, and a small army of technical reviewers and other hangers-on, will gently take your quivering little hand and whisk you away into the enchanted forests of shell programming, curses, terminals, file I/O, pipes, sockets, shared memory, DBM files, Tcl, Tk, HTML, CGI, gdb debugging, and some other crazy places that would scare your Mom if she ever found out. The descriptions of each topic are clear and almost every page includes a tasty morsel of sample code, constantly assuring that reader that even drooling idiots like you can write real-world UNIX applications in short time.

Dropping the "L" Word:

Fortunately the content is not biased toward any particular distribution of Linux, but in fact it's not particularly biased toward Linux either. I am hard-pressed to find any part of the book that can not be applied to UNIX in general, so I think a more appropriate title for this book would be "Beginning UNIX Programming", but I suppose the drawbacks of doing so would mean 1) whining tech journalists would complain of the lack of Linux programming books because they didn't bother searching under "UNIX programming", and 2) Linux is a flavor of UNIX anyway so you may well teach newbie programmers the UNIX way of doing things.

Perspective:

What I'm reading here is the actually the third printing of this book, circa 1997, (first printing in 1996) and many things have happened in Linux development since then so unfortunately there's no mention of GIMP, GNOME, Gtk, KDE, Qt, MySQL, Mesa, WindowMaker, and other areas that currently hold the interest of so many Linux hackers. And true, perhaps these topics too advanced for a book called "Beginning Linux Programming" but the book does attempt to touch upon all aspects of Linux programming so why not say a little bit about the APIs that are hosting the coolest parties.

What's Good:

• Very comprehensive. It would be hard to read this book and still be confused about UNIX architecture.
• Clear examples. Unlike so many programming books where the example code spools on and on for pages, the examples in this book are divided into easily digestible bite sized code snippets, separated by block of text to explain what's going on every step of the way.
• Quick guides to common tools: This book explains the simple yet non obvious commands every UNIX programmer has become familiar with: gcc, make (and Makefiles), gdb, patch, diff, tar, cflow, cxref, indent, lclint, etc. It takes care of most of the questions you'll find posted in comp.os.unix.programming newsgroups.
• Bonuses: It seems to me the authors did not have to discuss topics such as using DBM databases, HTML authoring, and CGI programming in this book, but they do so anyway which makes it all the more harder to keep this book out of arm's reach.

What's Bad:

• PERL, anyone? There's a whole chapter devoted to Tcl and yet only 2 pages devoted to a little something, maybe you've heard of this thing, called "perl"?!
• Open Source, anyone? Fails to reiterate the most valuable asset of Linux which pertains to programmers: it's (almost) entirely Open Source. The code is all there right under your nose! Feel free to browse through it and tell the developers what you think. And sure you could spend many weeks writing your own special application but chances are someone out there has already started an Open Source project to develop exactly what you need. That's what set's Linux apart from so many other flavors of UNIX is the prevailing code license: "GNU's not UNIX!".
• A little bit dated: Since its current printing is from 1997, there's no mention of the newer APIs common in Linux these days (GNOME, KDE, etc. etc.).
• Guilty of declaring fixed-size string buffers: Most of the C code examples reinforce bad habits such as feeding external data directly into fixed-length character buffers. Some examples should have titled "How to Make A Core Dump File". I don't think you can say enough to persuade C programmers to consider the stability and security of their applications. You may accuse me of nit-picking here, but I thinks its best to teach programmers while they're young so to save them a major rewrite later on.

Overall: It's a keeper. I think even the seasoned UNIX programmer would find it useful due to the variety of topics covered therein. Handy for answering the simple questions like "How I read/write to a DBM file again?" This copy is staying in my office bookshelf.

Pick this book up at Amazon.

Table of Contents:

Chapter 1: Getting Started

What is UNIX? What is Linux? GNU, Free Software Foundation, The C Compiler, C header files and libraries, UNIX philosophy

Chapter 2: Shell Programming

What is a shell? Pipes and redirection, shell as a programming language, shell syntax, example app: audio CD collection cataloger

Chapter 3: Working with Files

UNIX file structure, System Calls and Device Drivers, Library Functions, Low-level file access, Standard I/O library (in C), File and Directory Maintenance, Scanning Directories, Errors, Advanced Topics (file descriptors and memory mapped I/O)

Chapter 4: The UNIX Environment

Program arguments, Environment variables, Time and Date, Temp files, Host information, Logging, Resources and Limits

Chapter 5: Terminals

Reading and writing to the terminal, the terminal driver and interface, the termios structure, terminal output, identifying the terminal type, detecting keystrokes

Chapter 6: Curses

Compiling with curses, Basic curses features, keyboard input, multiple curses windows, subwindows, the keypad, color, example app: The CD audio collection using a curses interface

Chapter 7: Data Management

Managing memory, memory allocation, the NULL pointer, lock files, deadlocks, databases (dbm), Example app: The audio CD catalog using dbm

Chapter 8: Development Tools

The make command and Makefiles, Source code control (RCS, SCSS), writing man pages, making patches and tar files

Chapter 9: Debugging (C code)

Types of errors, code inspection, using gdb, more debugging tools (ctags, cxref, cflow, prof, gprof, lint) Assertions, Memory Debugging (ElectricFence, purify, Checker)

Chapter 10: Processes and Signals

Process structure, viewing processes, system processes, process scheduling, waiting for a process, input and output redirection, threads, signals, signal sets.

Chapter 11: Interprocess Communication: Pipes

Process types, Sending output to popen, the pipe call, parent and child processes, reading closed pipes, pipes used as standard input and output, named pipes: FIFOs, Example: the CD catalog as a client/server application

Chapter 12: Semaphores, Message Queues, and Shared Memory

Semaphores, UNIX semaphore facilities, shared memory, message queues, queue efficiency, IPC status commands

Chapter 13: Sockets

Socket connections, socket addresses, host and network byte ordering, Network information, the Internet daemon, socket options, Multiple clients, the select() function

Chapter 14: Tcl: Tool Command Language

"Hello World" in Tcl, Tcl commands, calculations, substitutions, error handling, arrays, lists, procedures, Input/Output, Tcl extensions, expect, [incr Tcl], TclX, networking, graphics, Tk, tgdb

Chapter 15: Programing for X

X server, X protocol, Xlib, X clients, X toolkits, X Window Manager, the X programming model, the Tk Toolkit, windows programming, configuration files, Tk widgets, geometry management, inter-application communication, Example app: a bitmap display program in Tk, Java, X programming with Java

Chapter 16: Programming for the Internet: HTML

What is the World Wide Web, writing HTML, HTML tags, HTML tables, HTML hyperlinks, serving HTML pages (Apache), Server-side Includes

Chapter 17: Internet Programming 2: CGI

the FORM tag, the INPUT tag, WWW encoding, Writing a server-side CGIprogram, decoding form data, using perl as a back end to the CGI, returning HTML to the client, Tips and Tricks, Example app: the CD catalog online written as a CGIapp in C

Appendix A: Portability

Language portability, reserved names, hardware portability, sizes, byte order, char, union packing, structure alignment, pointer sizes, moving to C++

Appendix B: FSF and the GNUProject

The GNUproject and GNUPublic License

Appendix C: Internet Resources

Newsgroups, WWW locations, FTP archives, CD vendors, Linux specific

Appendix D: Bibliography

Standards, other documentation, other cool books not related to computers.

Index

Picture of Tux

Survey Card

Back Cover

Top Surface of My Desk

My Feet

The Carpet

Foundation of this Building

Gravel

Bedrock

Hell

Bedrock

Australia

Space...

To understand Bill Gates, writes author Gary Rivlin in his new book, you have to first understand the people who have been laboring so ferociously -- and unsuccessfully -- to bring him down. The Plot to Get Bill Gates author Gary Rivlin pages ? publisher Time Business rating 7/10 reviewer Jon Katz ISBN summary This book is the story of these idiosyncratic, sometimes rabid cabal of Silicon Valley muck-a-mucks known within Microsoft as "Captain Ahab's Club" for their obsessive pursuit of Redmond's own contemporary version of Moby Dick.

Aside from Daddy Warbucks, billionaires aren't very popular. Beyond the obvious reasons - envy and resentment - they tend to be a strong-willed, arrogant lot. Rockefeller, J.P. Morgan - don't generally get to be billionaires through sensitivity and thoughtfulness.

Still, even by billionaire standards, Bill Gates seems hard to warm to. For one thing, he's the richest billionaire ever, topping more than $50 billion at last report. He seems almost lug-headedly arrogant, building a shockingly ostentatious digital place outside Seattle, practically mooning the judge during his recent anti-trust testimony, and of course, bludgeoning, acquiring, cutting down and stream-rolling innumerable competitors over the years.

Almost nobody seems to love him, not even other rapacious, slash-and-turn tycoons.

Gates is also personally elusive. He is not charming, charismatic, or appealing. His best-selling business books are vapid and cold. The carefully orchestrated interviews he gives - always in friendly, even adoring environments -- are banal. They reveal little vision or daring.

And for the many entrenched individualistic, Libertarian elements of the Net and Web, he is a nightmare: monopolistic and greedy and the purveyor of over-priced, ever obsolete, buggy software that exploits consumers and promotes computing ignorance.

Yet there he is, firmly atop the digital heap, a colossus who engulfs, devours, co-opts or buries wave after wave of competitors. Who now has so much money and power that he's become an icon rather than a CEO, capturing our imagination no matter what his gargantuan conglomerate does. Gates has nothing left to prove. And it's way too late to cut him down to size.

According to Gary Rivlin, author of the new book "The Plot to Get Bill Gates," (Times Business, $US 25), the people who hate Gates and are out to get him - the likes of Scott McNealy of Sun, Marc Andreessen and James Barksdale of Netscape, venture capitalist John Doerr, various anti-trust lawyers and government officials have become a culture all their own.

This book is the story of these idiosyncratic, sometimes rabid cabal of Silicon Valley muck-a-mucks known within Microsoft as "Captain Ahab's Club" for their obsessive pursuit of Redmond's own contemporary version of Moby Dick. (And that's not counting the nerds and geeks working in the open source and free software movements.)

For many of these people, says Rivlin, Gates has become an obsession. They talk and think about him constantly. He is always looking over their shoulder, the invisible man at every business meeting. What would Gates do? What does he think? What is he up to? They dump on him behind his back, then swoon at the sight of him.

At some point, writes Rivlin, Gates ceased to simply be a powerful computer industry figure, and instead, "infiltrated the world's dream life." A small universe of talented, driven people are working night and day to cut Gates down to size. But Rivlin's book suggests it may be too late for that.

Instead of tracking Microsoft software, Rivlin's mission is to track the various reincarnations of its CEO, "Gates 3.1", and the grievances - some substantial, some frivolous and ill-informed - that so many have against him.

This is fertile ground. Media coverage of Gates has been shallow. Gates is typically demonized or lionized, and neither stereotype seems quite right. Rivlin's notion - to understand Gates through his many adversaries - may offer the most telling insights yet into the reasons he's so successful, perhaps the best insight into Gates that we're ever going to get.

Rivlin presents a fair, intensely researched and direct account of the people who have taken Gates on, the generally losing struggles they've waged, and the insanely overheated business climate in Gates and his foes have been operating.

Gates inspires much stronger emotions in his adversaries than among the general public. Many of plots against him not only fail, they sometimes do more damage to the plotters than the target.

In fact, "The Plot To Get Gates" is as much a business history about the rise of Microsoft and the computing industry as it is a conspiracy story.

Amid much Gatesian hype and hysteria, it's refreshing to encounter some history and facts and a linear account of Microsoft's intricate battles and strategies.

Gates has prevailed mostly because he is a monomaniac, concludes Rivlin, because he believes he can and must win every time. He believes he is smarter, tougher than anybody else. He might be right.

According to Rivlin's chronicle, Gates is an indestructible life form: Chop off one leg and three more grow back; knock him over and he get gets up taller. Every effort to best him seems only to make him stronger, richer and more ferocious. Even the most savage assaults seem mostly to annoy him, like the original Godzilla swatting down those pesky jet fighters.

If you can judge a man by his enemies, Gates looks better. Rivlin doesn't show us anyone more agile or noble.

Still, this account comes at an odd time in Microsoft's history which may finally be doing to Gates what all of his many determined detractors couldn't.

While there's no sign that his company will totter and fall anytime soon, one has the sense that the history of the Net and the Web are moving past the man. Microsoft and its software are still pre-eminent, but the company no longer seems to be at the heart of the action.

The open source and free software movements - the literal antitheses of Microsoft and it's business philosophy -- have gained a strong foothold on the Net, demonstrating at a minimum that one can live digitally without turning over money to Microsoft, presenting the business world with its first real alternative. And stunningly successful new business platforms -- eBay, MP3, e-trading sites, ICQ and Hotline messaging systems - have sprung up entirely apart from Gates and Microsoft.

His company's many expensive lunges into the media world - Slate, MSN, MSNBC, the Sidewalk sites - are all struggling, sold, or on the block. It isn't Gates? new ideas that keep him so flush; it's the old ones, so durably profitable.

Rivlin's saga of the many, mostly unsuccessful efforts to challenge Gates and Microsoft are compelling for what they reveal about the man, especially since he (despite the media that swarm around him) has revealed so little about himself.

Gates is ferociously tenacious, competitive and - at least when it comes to defining his own role --- fleet-footed. He has an amazing capacity to re-engineer himself - thus his company -- no small skill in so fluid and brutally competitive a marketplace. Like the late Chairman Mao, he does business with a revolutionary fervor, zero tolerance for competition, and a continuous sense of (sometimes brutal) upheaval and renewal.

There is, nonetheless, an unyielding blandness about the man that makes it as difficult to hate him as to like him.

If we know more about Gates than we do about Onassis, Rockefeller or Morgan, it's sometimes tougher to care. Stacked up against history's billionaires, we have to struggle not only to understand him, but to remember why we want to.

Buy this book at Amazon.

wtpooh writes "CNN has a review of Ender's Shadow, an upcoming book by Orson Scott Card which retells the events of Ender's Game from the perspective of Bean, one of the children under Ender's command. I always liked Bean, so I'm really looking forward to this. According to Amazon, it will be available on August 31. You can also read the first four chapters of the book at Card's web site". Despite all the recommendations, I've never bothered to read Ender's Game. I think that will have to change very soon.

After a bit of an absence, Arjen Laarhoven has returned with a stellar review, this time of Eric Greenberg's new book Network Application Frameworks. Click below if you are interested in the design and implementation of networks in combination with the applications that run on them. Network Application Frameworks author Eric Greenberg pages 406 publisher Addison-Wesley rating Useful i reviewer Arjen Laarhoven ISBN summary 9/10 Overview Network Application Frameworks (NAF) is about networks and the applications that utilize them. This seems like kicking in an open door. Maybe. Many people tend to forget that networks and applications are symbiotic entities that perform a wide variety of tasks to help people and companies to do their work efficiently and effectively.

People who develop network-aware applications mostly take the infrastructure on which their applications run for granted. Little thought is given to the amount of traffic their applications generate, and when performance problems arise, they go complaining to the network people that network performance stinks and that they should do something about it.

NAF presents an amazing amount of information about this and many other problems that arise in today's networked world. More importantly, it also provides information about how these problems can be avoided or solved. The book is roughly divided into 3 parts:

1. An introduction to the the concept of Network Application Frameworks
2. The TCP/IP protocol suite
3. Specific information about the technology that is in wide use today, with solutions that Microsoft, Novell and IBM provide. Also, technology that isn't very widely used but has a very big impact on the industry is discussed. A separate chapter about The Open Group's DCE (Distributed Computing Environment) is an example of this.

The most striking feature of this book is that it provides a reasonable level of detail without losing sight of the big picture. A lot of specific technologies are discussed, like TCP/IP, DCE/DFS, Java, object technology, CORBA, ODBC, COM, ActiveX, NetWare, SNA, CICS and a host of other alphabet soup. Again, all these things are discussed without losing sight of interoperability, performance, security and ease of use (for both the users and the administrators).

I thought myself to be a pretty knowledgable person about programming and the use of the network in applications. NAF made it painfully obvious that I'm not. That is to say, like many other programmers, I worked in a blissful ignorance with respect to the big picture. For example, writing a program using the UNIX sockets API is one thing, but developing an application with taking performance, security and the use of services like LDAP, NDS and the Windows NT directory services is a whole other story.

While this book is an eye-opener for the tech folks like myself, it is also very informative reading for network designers and IT managers. By reading and thinking about the information that is provided in NAF, people with different backgrounds are ``educated'' in thinking about networks and applications from a number of different perspectives. Exactly that is what is missing all too often in computer and network departments of companies today. An awareness of the big picture. I think that by reading this book, people from different backgrounds (programmers, network designers and managers) can appreciate the problems and talk to each other about the solutions to these problems.

What's in it for me? A whole lot. Depending on your background, I think you can learn a lot about networks, network topology, services, security and performance. Also, software technology like Java, CORBA, Directory Services (X.500, LDAP, NDS and the Windows NT Directory Services and Active Directory) is covered in considerable depth. A lot is said about legacy systems, with the most important example being the systems and network technologies from IBM (mainframes, SNA and CICS).

All these things are covered without losing sight of the fact that these different technologies can (and have to) be put together to provide a solution that works. Integration is the buzz-word these days, and not only integration of the obvious Windows and UNIX stuff, but also time-tested solutions and technology from Novell and IBM. With every discussion about a specific platform, be it Windows NT, NetWare or IBM's SNA, a lot of information is provided on why and how to integrate these different systems into a coherent whole.

What's good? NAF is a very readable book, without avoiding technical discussions when necessary. Every chapter begins with a ``mind map'' of the topics that are discussed. Although this was new to me, I found it a very helpful thing to get a comprehensive overview of the topics and their relationships.

At the end of each chapter is a summary of the things that are discussed, and a list of references is given to books and articles that go into more depth about a particular topic.

Technical discussions are clarified by a lot of illustrations. I think I saw W. Richard Stevens saying in an interview "If I can't make a picture, I don't understand it." How true. For example, the topic of security (public key cryptography and the workings of Kerberos) is not exactly a simple one. The illustrations accompanying the text add a lot to gain an understanding of the more complex ideas.

Another good thing I want to point out are Eric's considerations about proprietary technology. For example, we all know Microsoft is very good at locking customers into a MS-only solution. In discussing proprietary technologies Eric points out the risks and benefits of going with one vendor for a particular solution and forces the reader to think for himself about these issues based on the information provided. He certainly is a proponent of open technologies but without forgetting about the other solutions that are available.

The last chapter provides a condensed overview of practically all the topics that are discussed in more depth in the previous chapters. This is very helpful if you encounter an abbreviation or concept and you have forgotten what it exactly meant.

What's bad? IMHO, not much. You may not like relatively big proportion of Microsoft technology that is discussed (chapters 7, 8 and 9), but fact is that a lot of Windows stuff is in use, and that it's not going away, though how much we would like to.

The references to NT5 are kinda obsolete, but it's not Eric's fault that Microsoft changed the name of that OS (the book was published in November 1999).

With the current pace of change in the computer industry, some things are bound to have changed since the book was published. For example, I don't know if all the things about Windows 2000's Active Directory are actually implemented.

Conclusion All in all, I think that NAF is a very valuable book to read. I certainly learned a lot about the integration of networks and applications.

Everyone who works in the enterprise software business, be it as an adiministrator or developer, can gain a lot of insight and specific information by reading this book and thinking about it.

Table of Contents (abbreviated)

• Preface

• 1. What Is a Network Application Framework?
• 2. Core Network Application Framework Technologies
• 3. The TCP/IP Protocol Suite
• 4. IP Routing
• 5. Internet Protocol Version 6 (IPv6)
• 6. The Open Group Distributed Computing Environment (DCE)
• 7. Microsoft and WOSA
• 8. The NT4 Directory Service
• 9. NT5 Active Directory Services
• 10. Novell NetWare
• 11. IBM
• 12. Design Rule Summary

• Index

Links to Web pages related to Network Application Frameworks

• Seine Dynamics, Inc (The company of the author)
• Addison-Wesley's page on NAF

You can buy this book at Amazon.

After a bit of an absence, Arjen Laarhoven has returned with a stellar review, this time of Eric Greenberg's new book Network Application Frameworks. Click below if you are interested in the design and implementation of networks in combination with the applications that run on them. Network Application Frameworks author Eric Greenberg pages 406 publisher Addison-Wesley rating Useful i reviewer Arjen Laarhoven ISBN summary 9/10 Overview Network Application Frameworks (NAF) is about networks and the applications that utilize them. This seems like kicking in an open door. Maybe. Many people tend to forget that networks and applications are symbiotic entities that perform a wide variety of tasks to help people and companies to do their work efficiently and effectively.

People who develop network-aware applications mostly take the infrastructure on which their applications run for granted. Little thought is given to the amount of traffic their applications generate, and when performance problems arise, they go complaining to the network people that network performance stinks and that they should do something about it.

NAF presents an amazing amount of information about this and many other problems that arise in today's networked world. More importantly, it also provides information about how these problems can be avoided or solved. The book is roughly divided into 3 parts:

1. An introduction to the the concept of Network Application Frameworks
2. The TCP/IP protocol suite
3. Specific information about the technology that is in wide use today, with solutions that Microsoft, Novell and IBM provide. Also, technology that isn't very widely used but has a very big impact on the industry is discussed. A separate chapter about The Open Group's DCE (Distributed Computing Environment) is an example of this.

The most striking feature of this book is that it provides a reasonable level of detail without losing sight of the big picture. A lot of specific technologies are discussed, like TCP/IP, DCE/DFS, Java, object technology, CORBA, ODBC, COM, ActiveX, NetWare, SNA, CICS and a host of other alphabet soup. Again, all these things are discussed without losing sight of interoperability, performance, security and ease of use (for both the users and the administrators).

I thought myself to be a pretty knowledgable person about programming and the use of the network in applications. NAF made it painfully obvious that I'm not. That is to say, like many other programmers, I worked in a blissful ignorance with respect to the big picture. For example, writing a program using the UNIX sockets API is one thing, but developing an application with taking performance, security and the use of services like LDAP, NDS and the Windows NT directory services is a whole other story.

While this book is an eye-opener for the tech folks like myself, it is also very informative reading for network designers and IT managers. By reading and thinking about the information that is provided in NAF, people with different backgrounds are ``educated'' in thinking about networks and applications from a number of different perspectives. Exactly that is what is missing all too often in computer and network departments of companies today. An awareness of the big picture. I think that by reading this book, people from different backgrounds (programmers, network designers and managers) can appreciate the problems and talk to each other about the solutions to these problems.

What's in it for me? A whole lot. Depending on your background, I think you can learn a lot about networks, network topology, services, security and performance. Also, software technology like Java, CORBA, Directory Services (X.500, LDAP, NDS and the Windows NT Directory Services and Active Directory) is covered in considerable depth. A lot is said about legacy systems, with the most important example being the systems and network technologies from IBM (mainframes, SNA and CICS).

All these things are covered without losing sight of the fact that these different technologies can (and have to) be put together to provide a solution that works. Integration is the buzz-word these days, and not only integration of the obvious Windows and UNIX stuff, but also time-tested solutions and technology from Novell and IBM. With every discussion about a specific platform, be it Windows NT, NetWare or IBM's SNA, a lot of information is provided on why and how to integrate these different systems into a coherent whole.

What's good? NAF is a very readable book, without avoiding technical discussions when necessary. Every chapter begins with a ``mind map'' of the topics that are discussed. Although this was new to me, I found it a very helpful thing to get a comprehensive overview of the topics and their relationships.

At the end of each chapter is a summary of the things that are discussed, and a list of references is given to books and articles that go into more depth about a particular topic.

Technical discussions are clarified by a lot of illustrations. I think I saw W. Richard Stevens saying in an interview "If I can't make a picture, I don't understand it." How true. For example, the topic of security (public key cryptography and the workings of Kerberos) is not exactly a simple one. The illustrations accompanying the text add a lot to gain an understanding of the more complex ideas.

Another good thing I want to point out are Eric's considerations about proprietary technology. For example, we all know Microsoft is very good at locking customers into a MS-only solution. In discussing proprietary technologies Eric points out the risks and benefits of going with one vendor for a particular solution and forces the reader to think for himself about these issues based on the information provided. He certainly is a proponent of open technologies but without forgetting about the other solutions that are available.

The last chapter provides a condensed overview of practically all the topics that are discussed in more depth in the previous chapters. This is very helpful if you encounter an abbreviation or concept and you have forgotten what it exactly meant.

What's bad? IMHO, not much. You may not like relatively big proportion of Microsoft technology that is discussed (chapters 7, 8 and 9), but fact is that a lot of Windows stuff is in use, and that it's not going away, though how much we would like to.

The references to NT5 are kinda obsolete, but it's not Eric's fault that Microsoft changed the name of that OS (the book was published in November 1999).

With the current pace of change in the computer industry, some things are bound to have changed since the book was published. For example, I don't know if all the things about Windows 2000's Active Directory are actually implemented.

Conclusion All in all, I think that NAF is a very valuable book to read. I certainly learned a lot about the integration of networks and applications.

Everyone who works in the enterprise software business, be it as an adiministrator or developer, can gain a lot of insight and specific information by reading this book and thinking about it.

Table of Contents (abbreviated)

• Preface

• 1. What Is a Network Application Framework?
• 2. Core Network Application Framework Technologies
• 3. The TCP/IP Protocol Suite
• 4. IP Routing
• 5. Internet Protocol Version 6 (IPv6)
• 6. The Open Group Distributed Computing Environment (DCE)
• 7. Microsoft and WOSA
• 8. The NT4 Directory Service
• 9. NT5 Active Directory Services
• 10. Novell NetWare
• 11. IBM
• 12. Design Rule Summary

• Index

Links to Web pages related to Network Application Frameworks

• Seine Dynamics, Inc (The company of the author)
• Addison-Wesley's page on NAF

You can buy this book at Amazon.