Slashdot Mirror

Antitechnologists, academic and other snoots, and neo-Luddites equate technology with the erosion of culture and civilization. A neat little book by Paul Johnson details how technology helped spark the Renaissance, which is an interesting perspective. One day historians may be writing similiar books about this time.

The Renaissance author Paul Johnson pages 197 publisher Modern Library Chronicles rating 7/10 reviewer Jon Katz ISBN 00679-64086-X summary how technology helped re-invent culture

The Renaissance is a short history of the period considered a high-water mark of humanity's relationship with the imagination. Historian Paul Johnson goes back to the Dark Ages to write about how the growth of intermediate technology sparked one of the greatest periods of cultural growth and invention, the Renaissance.

Technology made it possible, he concludes.

"This was," he writes, "the invention, followed by the extraordinarily rapid diffusion, of printing. The Romans produced a large literature. But in publishing it they were, as in many other fields, markedly conservative." The Romans, writes Johnson, knew about the codex -- a collection of folded and cut sheets, sewn together and enclosed within a binding. But they clung to the old-fashioned scroll as the normative form of the book.

In the Middle Ages, the spread of paper and the invention of printing by movable type was the central technological event leading the Renaissance, the spark that triggered an explosion in art, teaching, research and writing, Johnson writes. The invention of movable type for letterpress had three enormous advantages: it could be easily renewed, being cast from a mold; it could be used repeatedly until worn out; it introduced strict uniformity of lettering. (In a way, sounds like the Net's early architecture.)

Technology also had a profound affect on art, perspective, architecture and design, as Johnson also points out in this readable book.

The rest is, as they say history. Johnson tells it with authority, clarity and brevity. This is a neat book to give a teacher or parent muttering about all that time online, or lamenting the high culture of times past and the fact that kids have all gone to cultural Hell.

Sometimes unwittingly, "The Renaissance" connects the flowering of that period with the extraordinary outpouring of ideas, stories and culture made possible by the invention of the Net and the Web. Future historians may be writing about the history of this period in much the way Johnson takes on that one. It's always nice to know where we come from, as well as where we might be headed.

You can purchase this book at ThinkGeek.

Antitechnologists, academic and other snoots, and neo-Luddites equate technology with the erosion of culture and civilization. A neat little book by Paul Johnson details how technology helped spark the Renaissance, which is an interesting perspective. One day historians may be writing similiar books about this time.

The Renaissance author Paul Johnson pages 197 publisher Modern Library Chronicles rating 7/10 reviewer Jon Katz ISBN 00679-64086-X summary how technology helped re-invent culture

The Renaissance is a short history of the period considered a high-water mark of humanity's relationship with the imagination. Historian Paul Johnson goes back to the Dark Ages to write about how the growth of intermediate technology sparked one of the greatest periods of cultural growth and invention, the Renaissance.

Technology made it possible, he concludes.

"This was," he writes, "the invention, followed by the extraordinarily rapid diffusion, of printing. The Romans produced a large literature. But in publishing it they were, as in many other fields, markedly conservative." The Romans, writes Johnson, knew about the codex -- a collection of folded and cut sheets, sewn together and enclosed within a binding. But they clung to the old-fashioned scroll as the normative form of the book.

In the Middle Ages, the spread of paper and the invention of printing by movable type was the central technological event leading the Renaissance, the spark that triggered an explosion in art, teaching, research and writing, Johnson writes. The invention of movable type for letterpress had three enormous advantages: it could be easily renewed, being cast from a mold; it could be used repeatedly until worn out; it introduced strict uniformity of lettering. (In a way, sounds like the Net's early architecture.)

Technology also had a profound affect on art, perspective, architecture and design, as Johnson also points out in this readable book.

The rest is, as they say history. Johnson tells it with authority, clarity and brevity. This is a neat book to give a teacher or parent muttering about all that time online, or lamenting the high culture of times past and the fact that kids have all gone to cultural Hell.

Sometimes unwittingly, "The Renaissance" connects the flowering of that period with the extraordinary outpouring of ideas, stories and culture made possible by the invention of the Net and the Web. Future historians may be writing about the history of this period in much the way Johnson takes on that one. It's always nice to know where we come from, as well as where we might be headed.

You can purchase this book at ThinkGeek.

Like Gutenberg, and unlike some of the other self-taught inventive geniuses who spring to mind (like Franklin, Edison and Tesla), John Harrison was not a catholic inventor: his speciality was time. He did, though, draw from the fields of metallurgy, cabinetry and mechanics to find unconventional materials and techniques, and with what can be seen either as impossible optimism or sheer stubbornesss, Harrison managed to solve a problem which had killed thousands of his countrymen. By applying and extending the time-keeping technology of his time, he invented a means by which ships at sea could reliably determine their own longitude, and the story of how he did it ranks with any of the great dramas of science. Dava Sobel tells that story in Longitude: The True Story of a Lone Genius Who Solved the Greatest Scientific Problem of His Time.

Longitude author Dava Sobel pages 184 publisher Penguin rating 8.5 reviewer timothy ISBN 0140258795 summary Inventive genius rethinks the calculation of time and revolutionizes navigation.

A vexing problem, a golden fleece Specifically, from the age of around 30 (though Sobel points out that the time of his birth is only known within a few years), Harrison devised a series of time-keeping devices designed to keep time with accuracy orders of magnitude more accurate than the water, spring and pendulum-driven clocks of the day. The ferocity and diligence with which he wore down the technical gremlins conspiring to throw clocks off by seconds or minutes a day demonstrates a personal dedication as intense as those of the Las Alamos scientists laboring to forge the atomic bomb. Like those men, Harrison had something else in mind besides the joy of invention -- he was determined to win a prize which in modern money would mean millions of dollars, not to mention the prestige of royal recognition.

That prize (in the amount of 20,000 pounds) was set forth in a 1714 act of Parliament for anyone who could provide a practical method for ships at sea to determine their latitude to within half a degree.

With a clear sky and a sextant, finding latitude is relatively easy. Once it was widely accepted that the earth was a globe spinning about an axis perpindicular to the equator, the rest was (to our modern viewpoint) a piece of cake: locate a star (Polaris, at least in the Northern Hemisphere) which approximates an extension of that axis of spin, note the apparent angle from an observer's horizon, and perform some simple trigonometry. The problem with finding longitude is that no such simple trick exists.

By constructing elaborate star charts which correlate observed lunar and stellar positions, it was hypothesized (and eventually demonstrated in practice) that longitude could be determined using a complicated process of observing the sky (only at night, and only on a clear enough night to observe, of course), then comparing the stellar observations with a log of previous observations compiled by astronomers over a lunar-orbit cycle of 18 years. Though cumbersome, the amazine thing is that enough observations were compiled for this method of longitude determination to not only catch on, but for the charts to remain in continuous repair and revision until 1907. So desperate were navigators of the time to know where on the globe they sailed, even this tricky means was better than none at all.

Earthly contention A deftly-woven substory -- and perhaps really the main story -- is of the rivalry between the astronomers and the clockmakers, both in general and specifically in the case of Harrison and the man who turns out to be in parts both his competitor and his his judge, astronomer Nevil Maskelyne. For the early years of the race for a longitude method, the star-watchers held favor, as their methods were seen as purer and more reliable than those of the craftsmen whose tiny mechanisms were subject to mishandling as well as corrosion and other seagoing inevitabilities. Of all the entrants in this high-stakes race, Maske and Harrison represented probably the best (or at least the best-positioned) of each camp, so their struggles and the eventual outcome are particularly significant.

The culmination of Harrison's work came after 4 generations of refinement, a pocket-sized device, the appearance of which is at once antique and surprisingly modern. And (what should come no surprise), the Harrison chronometer keep startlingly accurate time -- good enough to comfortably meet the requirements of sought-after practicable longitude system. For reasons that make the book worth reading, collecting on that prize was anything but simple.

Reactions: As I read this book on the subway, I found myself nodding and grinning, and at times frowning obediently at the evil-landlord melodrama of Harrison vs. Maskelyne. The story of the unschooled inventor toppling the expectations and machinations of a well-connected science establishment isn't just interesting -- it's positively inspiring. It's hard not to know the eventual outcome just a few pages in, but Sobel keeps the story interesting by loosing the particulars slowly, revealing in turn setbacks and triumphs.

Though Sobel doesn't address this issue explicitly, the magnitude of the longitude prize and the thoroughly bureaucratic, arbitrary behavior of at least some of its keepers also raise the issue of state-funded science in general, and made me think of the moon race, mass immunizations and and everyone's favorite giant global network, no matter who invented it.

Longitude is also interesting for what it says about the transfer of information and ideas (if not technolgy itself) which went on in the time before today's Information Age.

Some more praise dressed up as complaint: The only gripe I have with this book is hardly fair, given it's brevity. But here it is: a few pages of illustrations and more detailed annotations (even an associated Web site) would make the book as much a starting point as a destination. While the reader-friendly avoidance of picayune detail is probably a wise compromise -- I know I appreciated it!, I do wish the book had a few pages at least of additional technical information. The glossy illustrations on and inside the front cover are some consolation at least, since they're good photographs (if small) on a nice glossy surface. That such an ommision is noticeable speaks well of this book -- most books leave me wishing they were shorter, not longer.

You can order this book from ThinkGeek.

Like Gutenberg, and unlike some of the other self-taught inventive geniuses who spring to mind (like Franklin, Edison and Tesla), John Harrison was not a catholic inventor: his speciality was time. He did, though, draw from the fields of metallurgy, cabinetry and mechanics to find unconventional materials and techniques, and with what can be seen either as impossible optimism or sheer stubbornesss, Harrison managed to solve a problem which had killed thousands of his countrymen. By applying and extending the time-keeping technology of his time, he invented a means by which ships at sea could reliably determine their own longitude, and the story of how he did it ranks with any of the great dramas of science. Dava Sobel tells that story in Longitude: The True Story of a Lone Genius Who Solved the Greatest Scientific Problem of His Time.

Longitude author Dava Sobel pages 184 publisher Penguin rating 8.5 reviewer timothy ISBN 0140258795 summary Inventive genius rethinks the calculation of time and revolutionizes navigation.

A vexing problem, a golden fleece Specifically, from the age of around 30 (though Sobel points out that the time of his birth is only known within a few years), Harrison devised a series of time-keeping devices designed to keep time with accuracy orders of magnitude more accurate than the water, spring and pendulum-driven clocks of the day. The ferocity and diligence with which he wore down the technical gremlins conspiring to throw clocks off by seconds or minutes a day demonstrates a personal dedication as intense as those of the Las Alamos scientists laboring to forge the atomic bomb. Like those men, Harrison had something else in mind besides the joy of invention -- he was determined to win a prize which in modern money would mean millions of dollars, not to mention the prestige of royal recognition.

That prize (in the amount of 20,000 pounds) was set forth in a 1714 act of Parliament for anyone who could provide a practical method for ships at sea to determine their latitude to within half a degree.

With a clear sky and a sextant, finding latitude is relatively easy. Once it was widely accepted that the earth was a globe spinning about an axis perpindicular to the equator, the rest was (to our modern viewpoint) a piece of cake: locate a star (Polaris, at least in the Northern Hemisphere) which approximates an extension of that axis of spin, note the apparent angle from an observer's horizon, and perform some simple trigonometry. The problem with finding longitude is that no such simple trick exists.

By constructing elaborate star charts which correlate observed lunar and stellar positions, it was hypothesized (and eventually demonstrated in practice) that longitude could be determined using a complicated process of observing the sky (only at night, and only on a clear enough night to observe, of course), then comparing the stellar observations with a log of previous observations compiled by astronomers over a lunar-orbit cycle of 18 years. Though cumbersome, the amazine thing is that enough observations were compiled for this method of longitude determination to not only catch on, but for the charts to remain in continuous repair and revision until 1907. So desperate were navigators of the time to know where on the globe they sailed, even this tricky means was better than none at all.

Earthly contention A deftly-woven substory -- and perhaps really the main story -- is of the rivalry between the astronomers and the clockmakers, both in general and specifically in the case of Harrison and the man who turns out to be in parts both his competitor and his his judge, astronomer Nevil Maskelyne. For the early years of the race for a longitude method, the star-watchers held favor, as their methods were seen as purer and more reliable than those of the craftsmen whose tiny mechanisms were subject to mishandling as well as corrosion and other seagoing inevitabilities. Of all the entrants in this high-stakes race, Maske and Harrison represented probably the best (or at least the best-positioned) of each camp, so their struggles and the eventual outcome are particularly significant.

The culmination of Harrison's work came after 4 generations of refinement, a pocket-sized device, the appearance of which is at once antique and surprisingly modern. And (what should come no surprise), the Harrison chronometer keep startlingly accurate time -- good enough to comfortably meet the requirements of sought-after practicable longitude system. For reasons that make the book worth reading, collecting on that prize was anything but simple.

Reactions: As I read this book on the subway, I found myself nodding and grinning, and at times frowning obediently at the evil-landlord melodrama of Harrison vs. Maskelyne. The story of the unschooled inventor toppling the expectations and machinations of a well-connected science establishment isn't just interesting -- it's positively inspiring. It's hard not to know the eventual outcome just a few pages in, but Sobel keeps the story interesting by loosing the particulars slowly, revealing in turn setbacks and triumphs.

Though Sobel doesn't address this issue explicitly, the magnitude of the longitude prize and the thoroughly bureaucratic, arbitrary behavior of at least some of its keepers also raise the issue of state-funded science in general, and made me think of the moon race, mass immunizations and and everyone's favorite giant global network, no matter who invented it.

Longitude is also interesting for what it says about the transfer of information and ideas (if not technolgy itself) which went on in the time before today's Information Age.

Some more praise dressed up as complaint: The only gripe I have with this book is hardly fair, given it's brevity. But here it is: a few pages of illustrations and more detailed annotations (even an associated Web site) would make the book as much a starting point as a destination. While the reader-friendly avoidance of picayune detail is probably a wise compromise -- I know I appreciated it!, I do wish the book had a few pages at least of additional technical information. The glossy illustrations on and inside the front cover are some consolation at least, since they're good photographs (if small) on a nice glossy surface. That such an ommision is noticeable speaks well of this book -- most books leave me wishing they were shorter, not longer.

You can order this book from ThinkGeek.

Chronic reviewer chromatic writes again, this time with a review of the newest iteration of what is probably the emblematic Perl book, the O'Reilly camel book. Read on to see how it stacks up to earlier versions of that work, and whether your Perl skills would benefit from reading through it.

Programming Perl (third edition) author Larry Wall, Tom Christiansen, & Jon Orwant pages 1067 publisher O'Reilly & Associates rating 9.5 reviewer chromatic ISBN 0-596-0027-8 summary The definitive guide to the Perl language, updated for 5.6.1.

The Scoop Longtime Perl fans know Programming Perl as the Camel, because of the cover animal. With the first edition in 1991, Perl programmers gained not only a charmingly appropriate mascot, but the ultimate language reference. True to form, this Camel's grown with the language. In the four years since the last release, it's increased in size by 67%.

Everything you liked about previous editions has returned, in one form or another. Additionally, this third edition covers the largest changes made for Perl 5.6 (actually 5.6.1, as the book's ahead of the current stable release by a bit) -- Unicode, threading, and more Perl guts.

While the previous editions were exceptionally well-written references, they were also aimed squarely at experienced programmers. This edition pushes back the starting blocks somewhat, providing a gentler introduction to the world of Perl. The wealth of new information is staggering, but as you'd expect from the luminous authors, even the core language reference is highly readable and entertaining.

What's to Like? Logically, the book is divided into five main sections. (Gone are the massive 80-page chapters of the second edition). The first section, one chapter, gives a good overview of Perl, as a language and a philosophy. It includes a quick introduction. The second section gives the language's gory details, covering just about everything you would need to know. It's arranged in terms of ascending complexity. The enhanced, extended, and improved regular expression chapter stands out as the best member of this group.

The third section discusses Perl as technology. Here's where Unicode comes in, as well as the internals of Perl (through the internal compilation process, using the debugger, or using XS to extend Perl with C code). Everything here is quite good. Expectably dry subjects like Unicode or threading are readable and even a little entertaining. If you're not convinced, you can skip around and still learn quite a bit.

The fourth section is devoted to Perl as culture, with discussions about portability, security, good practices, documentation, CPAN, and a bit of poetry. The security chapter is quite good, but left me wanting more information. Any chapter here is accessible if you've made it through the second section, so feel free to pick and choose what you need to know.

Rounding up the spare bits is the reference section. Not only will you find descriptions of the special variables, built-in functions, and standard library, but the organization and presentation of these descriptions has improved. Functions have little annotations listing which magic variables they set, possible exceptions they raise, and the like. That accounts for 150 pages of the overall goodness. Don't skip the glossary at the end, if you're confused or looking for amusement.

What's to Consider? While it's a temporary conundrum, it's a little odd to read about features that aren't quite implemented yet. This is most noticeable in the Unicode discussions and the chapter on threading. Occasionally, the authors will describe a feature and then admit that the specifics will likely change. (Have a look at the documentation.) Granted, the bulk of the language is mature and stable, and the definitive guide can't very well get by with ignoring major features, but it reads a little oddly.

The intended audience is still the serious Perl programmer. Dabblers and casual learners will find enlightenment and instruction. Realize, though, that while it's easier to start your journey here, absolute beginners would do well to explore a Learning Perl or Elements of Programming with Perl first. People who've programmed before (beyond dabbling with VB, or doing mouseovers in Web pages) should have little difficulty picking up the Perl language and mindset.

The only other possible improvement that comes to mind is expanding certain chapters. As noted before, there's more to say about security and efficiency. It would also be nice to have a chapter on common Perl idioms one might find in EFNet #Perl or at Perl Monks, or the latest Perl Mongers meeting. (Half of the fun is discovering and sharing new tricks and shortcuts.)

The Summary Part of being a good programmer is knowing where to turn for accurate and useful information. This is the place for all things Perl. If you use Perl regularly, put the new Camel on your shelf. Table of Contents

1. Overview
2. 1. An Overview of Perl
3. The Gory Details
4. 1. Bits and Pieces
   2. Unary and Binary Operators
   3. Statements and Declarations
   4. Pattern Matching
   5. Subroutines
   6. Formats
   7. References
   8. Data Structures
   9. Packages
   10. Modules
   11. Objects
   12. Overloading
   13. Tied Variables
5. Perl as Technology
6. 1. Unicode
   2. Interprocess Communication
   3. Threads
   4. Compiling
   5. The Command-Line Interface
   6. The Perl Debugger
   7. Internals and Externals
7. Perl as Culture
8. 1. CPAN
   2. Security
   3. Common Practices
   4. Portable Perl
   5. Plain Old Documentation
   6. Perl Culture
9. Reference Material
10. 1. Special Names
    2. Functions
    3. The Standard Perl Library
    4. Pragmatic Modules
    5. Standard Modules
    6. Diagnostic Messages
    
    Glossary
    Index

You can purchase this book at ThinkGeek.

Chronic reviewer chromatic writes again, this time with a review of the newest iteration of what is probably the emblematic Perl book, the O'Reilly camel book. Read on to see how it stacks up to earlier versions of that work, and whether your Perl skills would benefit from reading through it.

Programming Perl (third edition) author Larry Wall, Tom Christiansen, & Jon Orwant pages 1067 publisher O'Reilly & Associates rating 9.5 reviewer chromatic ISBN 0-596-0027-8 summary The definitive guide to the Perl language, updated for 5.6.1.

The Scoop Longtime Perl fans know Programming Perl as the Camel, because of the cover animal. With the first edition in 1991, Perl programmers gained not only a charmingly appropriate mascot, but the ultimate language reference. True to form, this Camel's grown with the language. In the four years since the last release, it's increased in size by 67%.

Everything you liked about previous editions has returned, in one form or another. Additionally, this third edition covers the largest changes made for Perl 5.6 (actually 5.6.1, as the book's ahead of the current stable release by a bit) -- Unicode, threading, and more Perl guts.

While the previous editions were exceptionally well-written references, they were also aimed squarely at experienced programmers. This edition pushes back the starting blocks somewhat, providing a gentler introduction to the world of Perl. The wealth of new information is staggering, but as you'd expect from the luminous authors, even the core language reference is highly readable and entertaining.

What's to Like? Logically, the book is divided into five main sections. (Gone are the massive 80-page chapters of the second edition). The first section, one chapter, gives a good overview of Perl, as a language and a philosophy. It includes a quick introduction. The second section gives the language's gory details, covering just about everything you would need to know. It's arranged in terms of ascending complexity. The enhanced, extended, and improved regular expression chapter stands out as the best member of this group.

The third section discusses Perl as technology. Here's where Unicode comes in, as well as the internals of Perl (through the internal compilation process, using the debugger, or using XS to extend Perl with C code). Everything here is quite good. Expectably dry subjects like Unicode or threading are readable and even a little entertaining. If you're not convinced, you can skip around and still learn quite a bit.

The fourth section is devoted to Perl as culture, with discussions about portability, security, good practices, documentation, CPAN, and a bit of poetry. The security chapter is quite good, but left me wanting more information. Any chapter here is accessible if you've made it through the second section, so feel free to pick and choose what you need to know.

Rounding up the spare bits is the reference section. Not only will you find descriptions of the special variables, built-in functions, and standard library, but the organization and presentation of these descriptions has improved. Functions have little annotations listing which magic variables they set, possible exceptions they raise, and the like. That accounts for 150 pages of the overall goodness. Don't skip the glossary at the end, if you're confused or looking for amusement.

What's to Consider? While it's a temporary conundrum, it's a little odd to read about features that aren't quite implemented yet. This is most noticeable in the Unicode discussions and the chapter on threading. Occasionally, the authors will describe a feature and then admit that the specifics will likely change. (Have a look at the documentation.) Granted, the bulk of the language is mature and stable, and the definitive guide can't very well get by with ignoring major features, but it reads a little oddly.

The intended audience is still the serious Perl programmer. Dabblers and casual learners will find enlightenment and instruction. Realize, though, that while it's easier to start your journey here, absolute beginners would do well to explore a Learning Perl or Elements of Programming with Perl first. People who've programmed before (beyond dabbling with VB, or doing mouseovers in Web pages) should have little difficulty picking up the Perl language and mindset.

The only other possible improvement that comes to mind is expanding certain chapters. As noted before, there's more to say about security and efficiency. It would also be nice to have a chapter on common Perl idioms one might find in EFNet #Perl or at Perl Monks, or the latest Perl Mongers meeting. (Half of the fun is discovering and sharing new tricks and shortcuts.)

The Summary Part of being a good programmer is knowing where to turn for accurate and useful information. This is the place for all things Perl. If you use Perl regularly, put the new Camel on your shelf. Table of Contents

1. Overview
2. 1. An Overview of Perl
3. The Gory Details
4. 1. Bits and Pieces
   2. Unary and Binary Operators
   3. Statements and Declarations
   4. Pattern Matching
   5. Subroutines
   6. Formats
   7. References
   8. Data Structures
   9. Packages
   10. Modules
   11. Objects
   12. Overloading
   13. Tied Variables
5. Perl as Technology
6. 1. Unicode
   2. Interprocess Communication
   3. Threads
   4. Compiling
   5. The Command-Line Interface
   6. The Perl Debugger
   7. Internals and Externals
7. Perl as Culture
8. 1. CPAN
   2. Security
   3. Common Practices
   4. Portable Perl
   5. Plain Old Documentation
   6. Perl Culture
9. Reference Material
10. 1. Special Names
    2. Functions
    3. The Standard Perl Library
    4. Pragmatic Modules
    5. Standard Modules
    6. Diagnostic Messages
    
    Glossary
    Index

You can purchase this book at ThinkGeek.

Reader stern contributed this review of Catch Me If You Can, Frank Abagnale's story of creative identity hacking on a level that makes Kevin Mitnick's look more like a Groucho mustache. Don't try this stuff at home ... or in the cockpit, or the operating room, please.

Catch Me If You can author Frank. W. Abagnale with Stan Redding pages 277 publisher Broadway Books rating 7/10 reviewer stern ISBN 0-7679-0538-5 summary Captivating tale of a young, creative criminal, defrauding banks and airlines in the 1970s.

It has been said that success depends on three things: skill, luck, and timing. Had Bill Gates been born six hundred years ago, he'd be assistant shit-shoveler for the Duke of Silesia. Conversely, Charlemagne, if born today, would probably be an auto mechanic. Sometimes you read about somebody whose skills were so remarkably out of place that you marvel at the thought of what they could have accomplished if they had only been born in a different time and place. Charles Babbage was born 100 years too soon. John Law, given the chance, would have ruled Wall Street.

Catch Me If You Can is the apparently true story of a man named Frank Abagnale. In the mid-1970s, when still a teenager, he ran away from home and supported himself by forging checks. To call him a forger, however, is to call Frank Lloyd Wright a guy who builds houses -- a simplification that does injustice to his tremendous skills. Abagnale developed fully documented alternate identities, including that of a Pan Am pilot, a pediatrician, a public prosecutor, and a college sociology professor. In each case, he was able to forge authenticating documents, and in many cases, he was able to procure the actual certificates, passcards, uniforms, and other accountrements of the trade. He was so convincing that, when accused by airport officials of being a fake pilot, other pilots (some of whom had known him for years) rose to defend him!

Under these guises (but especially in his role as airline pilot), Abagnale forged millions of dollars in checks, and defrauded banks around the world. He was able to avoid capture in part because his persona was very convincing, but also because he revolutionalized the art of check-kiting, printing false routing information on the bottom of each check that would send them circling the United States for days or weeks before a human intercepted them and determined that they were fake. Also, as a 'pilot', he was able to ride for free around the United States, Europe, and Asia, spreading his fake checks over a huge number of different banks in different cities. This made him much harder to catch.

Why is this book appropriate for Slashdot readers? You can take it as a lesson in hacking for somebody who was never given the chance to use a computer. Abagnale hacked the banking system; he hacked airline industry procedures. He even hacked the Swedish penal system. He found and exploited fault modes that normal users had never noticed. You can also take the book as a primer in social engineering. Abagnale would never have been able to get away with his hacks, especially the early ones, if he had not understood how to charm a bank teller. In fact, his choice of airline pilot as his first alternate identity was driven in part by the realization that female bank tellers would swoon for a man in the pilot's uniform.

What's Bad?

As in any book by a rogue and con man, there is no way that 100% of this book is true, and you're never really sure when you are reading an anecdote that was made up. You will probably find yourself reading each chapter while sniffing for B.S. Personally, I found two episodes particularly suspect -- his pretending to be a stock broker (his grasp of the terminology was much to weak to fool anybody really in the financial markets), and his claim to have fooled eight college girls into travelling around Europe with him for a Summer, thinking they were working for Pan Am.

The most convincing stories were those in which he makes an error -- other people caught him making mistakes so subtle that an outsider would probably never have made them up. For example, airline pilots catching him in an error about which carriers served which cities, or a Harvard Law graduate catching him in an error about the professors with which he had studied.

What's Good?

I have no doubt that, had he been born in a slightly different environment, Abagnale would have been a fiersome computer hacker (in the positive or negative sense). His model is a valuable one, even if he used his creative skills to evil ends. Most people take for granted that barcodes are magic, that passcards separate real employees from the masses, and that anybody with the right jargon and the right clothing is in the right place. In some sense, we run our society (certainly our schools and businesses) like the insect hives that fiercely resist any outsider. Once the invader gets inside, it's treated like a member of the family. Read correctly, Abagnale's story can be both an inspiration and a warning. It inspires the reader to find the weaknesses in the systems around him, and it warns us to beware of our natural instinct to trust people who seem like us. Sometimes they're faking, and sometimes they do not have our best interests at heart.

By the way, Abagnale was eventually caught and served time for his crimes, but ended up running a secure-documents company in Washington, DC, and teaching courses on financial fraud for the FBI.

Stern is the president of Information Markets Corp.

You can purchase this book at ThinkGeek.

Reader stern contributed this review of Catch Me If You Can, Frank Abagnale's story of creative identity hacking on a level that makes Kevin Mitnick's look more like a Groucho mustache. Don't try this stuff at home ... or in the cockpit, or the operating room, please.

Catch Me If You can author Frank. W. Abagnale with Stan Redding pages 277 publisher Broadway Books rating 7/10 reviewer stern ISBN 0-7679-0538-5 summary Captivating tale of a young, creative criminal, defrauding banks and airlines in the 1970s.

It has been said that success depends on three things: skill, luck, and timing. Had Bill Gates been born six hundred years ago, he'd be assistant shit-shoveler for the Duke of Silesia. Conversely, Charlemagne, if born today, would probably be an auto mechanic. Sometimes you read about somebody whose skills were so remarkably out of place that you marvel at the thought of what they could have accomplished if they had only been born in a different time and place. Charles Babbage was born 100 years too soon. John Law, given the chance, would have ruled Wall Street.

Catch Me If You Can is the apparently true story of a man named Frank Abagnale. In the mid-1970s, when still a teenager, he ran away from home and supported himself by forging checks. To call him a forger, however, is to call Frank Lloyd Wright a guy who builds houses -- a simplification that does injustice to his tremendous skills. Abagnale developed fully documented alternate identities, including that of a Pan Am pilot, a pediatrician, a public prosecutor, and a college sociology professor. In each case, he was able to forge authenticating documents, and in many cases, he was able to procure the actual certificates, passcards, uniforms, and other accountrements of the trade. He was so convincing that, when accused by airport officials of being a fake pilot, other pilots (some of whom had known him for years) rose to defend him!

Under these guises (but especially in his role as airline pilot), Abagnale forged millions of dollars in checks, and defrauded banks around the world. He was able to avoid capture in part because his persona was very convincing, but also because he revolutionalized the art of check-kiting, printing false routing information on the bottom of each check that would send them circling the United States for days or weeks before a human intercepted them and determined that they were fake. Also, as a 'pilot', he was able to ride for free around the United States, Europe, and Asia, spreading his fake checks over a huge number of different banks in different cities. This made him much harder to catch.

Why is this book appropriate for Slashdot readers? You can take it as a lesson in hacking for somebody who was never given the chance to use a computer. Abagnale hacked the banking system; he hacked airline industry procedures. He even hacked the Swedish penal system. He found and exploited fault modes that normal users had never noticed. You can also take the book as a primer in social engineering. Abagnale would never have been able to get away with his hacks, especially the early ones, if he had not understood how to charm a bank teller. In fact, his choice of airline pilot as his first alternate identity was driven in part by the realization that female bank tellers would swoon for a man in the pilot's uniform.

What's Bad?

As in any book by a rogue and con man, there is no way that 100% of this book is true, and you're never really sure when you are reading an anecdote that was made up. You will probably find yourself reading each chapter while sniffing for B.S. Personally, I found two episodes particularly suspect -- his pretending to be a stock broker (his grasp of the terminology was much to weak to fool anybody really in the financial markets), and his claim to have fooled eight college girls into travelling around Europe with him for a Summer, thinking they were working for Pan Am.

The most convincing stories were those in which he makes an error -- other people caught him making mistakes so subtle that an outsider would probably never have made them up. For example, airline pilots catching him in an error about which carriers served which cities, or a Harvard Law graduate catching him in an error about the professors with which he had studied.

What's Good?

I have no doubt that, had he been born in a slightly different environment, Abagnale would have been a fiersome computer hacker (in the positive or negative sense). His model is a valuable one, even if he used his creative skills to evil ends. Most people take for granted that barcodes are magic, that passcards separate real employees from the masses, and that anybody with the right jargon and the right clothing is in the right place. In some sense, we run our society (certainly our schools and businesses) like the insect hives that fiercely resist any outsider. Once the invader gets inside, it's treated like a member of the family. Read correctly, Abagnale's story can be both an inspiration and a warning. It inspires the reader to find the weaknesses in the systems around him, and it warns us to beware of our natural instinct to trust people who seem like us. Sometimes they're faking, and sometimes they do not have our best interests at heart.

By the way, Abagnale was eventually caught and served time for his crimes, but ended up running a secure-documents company in Washington, DC, and teaching courses on financial fraud for the FBI.

Stern is the president of Information Markets Corp.

You can purchase this book at ThinkGeek.

In addition to all the other books he has insightfully reviewed, chromatic has written this review of CGI Programming With Perl. This books sounds like a great resource for the builder of dynamic Web sites with a Perl background. And isn't it nice to see a book with "an unapologetic Unix flavor"?

CGI Programming with Perl author Scott Guelich, Shishir Gundavaram, & Gunther Birznieks pages 451 publisher O'Reilly & Associates rating 9 reviewer chromatic ISBN 1-56592-419-3 summary Your guide to the protocols and practices of CGI programming, with a look at current tools, tips, and tricks.

The Scoop Static web pages sufficed back when the web was young. Information flowed one way (like it does on most corporate sites today). Those days are long behind us -- if you want dynamic and interactive content, a whole host of technologies have appeared to fill in the gaps.

Enter Perl and CGI -- the original Swiss Army chainsaw of programming met the standard for exchanging data over HTTP and it was good. Thousands and thousands of programmers discovered this combination of power and simplicity, and the web has never been the same. Now, it's your turn to descend into the mysteries of query strings and stateless transactions, hoping to emerge successfully with the knowledge of simple -- yet interactive -- web programming.

In this second edition, the authors have gone far beyond CGI circa 1996. New topics include XML, search engines, security, and high performance Perl-based alternatives to CGI. How far we've come...

What's to Like? The book begins with an explanation of HTTP. Understanding the underlying protocol gives a picture of the whole process. The same is done for CGI, examing the interface -- the environment, input, output, and headers. It's simple enough that the description never bogs down, but detailed enough to explain difficulties CGI authors must work around (session management being high on the list).

From there, it's on to forms and HTML and, before spending much time trying to write a custom decoder for form data, it's off to CGI.pm. (That's important, because it's hard to get this right, even for authors of some other CGI programming books.) As befits the module, this chapter explains handling input, generating output, and handling errors.

Shift gears for a second, and think about embedding your code in your HTML. Try SSI, HTML::Template, or Embperl. (This is just a taste of the techniques available for templating -- see Template Toolkit or Mason for other nice ones.) Following that, grit your teeth and learn some of the JavaScript you've been putting off. Use it to add an additional client-side form input checker, hook it up to your Perl with WDDX, or discover the powerful Bookmarklet.

Consider security in chapter 8 -- now that you've learned some cool tricks but before you know enough to get into real trouble, discover the vulnerabilities and how you can program around them. Use Perl's Taint mode and your web server configuration to help you out. Do not skip this chapter -- read it, then read perldoc perlsec until you get it. (It's a good chapter, but security can be hard, so don't rely on just one source of information.)

The rest of the book is a tour of various tasks you might want to accomplish. They're good too, but things shine again in the last three chapters, with help for the new, curious, frazzled Perl CGI programmer. How do you get rid of that annoying 500 server error? How can you make your program worth using for the next three years instead of worth throwing away every three months? How can you write something that will handle a hundred users a day? A thousand? A front-page link on Slashdot? (The answer is more than just FastCGI or mod_perl, though they're definitely the heavy guns.)

It's definitely time for a second edition of this tome. The expanded coverage of CGI.pm and templating technologies is a welcome addition. Promoting the use of the existing well-tested, documented, and debugged tools will, hopefully, lead to more maintainable code. Unlike some other books, the example code is clean and worthy of emulation. Hit the references and recommendation section in Appendix A for more good information, including relevant RFCs. Really. (It's a good sign for a Perl book to mention both the CPAN and perldoc, as in Appendix B.)

What's to Consider? Be careful about copying code blindly from the first few chapters without reading at least chapter 8 (and perldoc perlsec in Perl's included documentation)! Simple examples are appropriate for teaching and personal testing, but could have disastrous consequences on publicly-accessible servers. To the authors' credit, even the simple example code runs with warnings, taint mode, and the strict pragma.

You'll need to know some Perl -- at least enough to follow along with somewhat-idiomatic code. Platform and portability wise, there's an unapologetic Unix flavor to the examples. Nearly everything should work on Win32 and other operating systems, but be aware of certain differences. As for web server information, it's Apache-specific. (Configuration for other platforms will be similar, but is left as an exercise for the reader.)

Some topics could use more treatment. It would have been nice to have more information on HTML::Mason (though admittedly complex, it's powerful and probably deserves more than a two page introduction) and XML and Middleware. New technologies like RSS and WAP need tools and users and programmers. There's also more to say on debugging CGI applications, though a pointer to the facetiously named Idiot's Guide could be helpful.)

The Summary Newly updated, chock full of good advice and, above all, high-quality code, this book is a great place to learn how to focus your Perl skills in a popular direction. Follow the advice presented, ask around for help if you need it, and have fun. Don't bother spending 24 hours or 21 days or whatever it is now, learn CGI programming with Perl the right way.

special thanks to the amazing Simone at O'Reilly for her help making these and other reviews possible!

Table of Contents

1. Getting Started
2. The Hypertext Transfer Protocol
3. The Common Gateway Interface
4. Forms and CGI
5. CGI.pm
6. HTML Templates
7. JavaScript
8. Security
9. Sending Email
10. Data Persistence
11. Maintaining State
12. Searching the Web Server
13. Creating Graphics on the Fly
14. Middleware and XML
15. Debugging CGI Applications
16. Guidelines for Better CGI Applications
17. Effeciency and Optimization

1. Works Cited and Further Reading
2. Perl Modules

You can purchase this book at ThinkGeek.

In addition to all the other books he has insightfully reviewed, chromatic has written this review of CGI Programming With Perl. This books sounds like a great resource for the builder of dynamic Web sites with a Perl background. And isn't it nice to see a book with "an unapologetic Unix flavor"?

CGI Programming with Perl author Scott Guelich, Shishir Gundavaram, & Gunther Birznieks pages 451 publisher O'Reilly & Associates rating 9 reviewer chromatic ISBN 1-56592-419-3 summary Your guide to the protocols and practices of CGI programming, with a look at current tools, tips, and tricks.

The Scoop Static web pages sufficed back when the web was young. Information flowed one way (like it does on most corporate sites today). Those days are long behind us -- if you want dynamic and interactive content, a whole host of technologies have appeared to fill in the gaps.

Enter Perl and CGI -- the original Swiss Army chainsaw of programming met the standard for exchanging data over HTTP and it was good. Thousands and thousands of programmers discovered this combination of power and simplicity, and the web has never been the same. Now, it's your turn to descend into the mysteries of query strings and stateless transactions, hoping to emerge successfully with the knowledge of simple -- yet interactive -- web programming.

In this second edition, the authors have gone far beyond CGI circa 1996. New topics include XML, search engines, security, and high performance Perl-based alternatives to CGI. How far we've come...

What's to Like? The book begins with an explanation of HTTP. Understanding the underlying protocol gives a picture of the whole process. The same is done for CGI, examing the interface -- the environment, input, output, and headers. It's simple enough that the description never bogs down, but detailed enough to explain difficulties CGI authors must work around (session management being high on the list).

From there, it's on to forms and HTML and, before spending much time trying to write a custom decoder for form data, it's off to CGI.pm. (That's important, because it's hard to get this right, even for authors of some other CGI programming books.) As befits the module, this chapter explains handling input, generating output, and handling errors.

Shift gears for a second, and think about embedding your code in your HTML. Try SSI, HTML::Template, or Embperl. (This is just a taste of the techniques available for templating -- see Template Toolkit or Mason for other nice ones.) Following that, grit your teeth and learn some of the JavaScript you've been putting off. Use it to add an additional client-side form input checker, hook it up to your Perl with WDDX, or discover the powerful Bookmarklet.

Consider security in chapter 8 -- now that you've learned some cool tricks but before you know enough to get into real trouble, discover the vulnerabilities and how you can program around them. Use Perl's Taint mode and your web server configuration to help you out. Do not skip this chapter -- read it, then read perldoc perlsec until you get it. (It's a good chapter, but security can be hard, so don't rely on just one source of information.)

The rest of the book is a tour of various tasks you might want to accomplish. They're good too, but things shine again in the last three chapters, with help for the new, curious, frazzled Perl CGI programmer. How do you get rid of that annoying 500 server error? How can you make your program worth using for the next three years instead of worth throwing away every three months? How can you write something that will handle a hundred users a day? A thousand? A front-page link on Slashdot? (The answer is more than just FastCGI or mod_perl, though they're definitely the heavy guns.)

It's definitely time for a second edition of this tome. The expanded coverage of CGI.pm and templating technologies is a welcome addition. Promoting the use of the existing well-tested, documented, and debugged tools will, hopefully, lead to more maintainable code. Unlike some other books, the example code is clean and worthy of emulation. Hit the references and recommendation section in Appendix A for more good information, including relevant RFCs. Really. (It's a good sign for a Perl book to mention both the CPAN and perldoc, as in Appendix B.)

What's to Consider? Be careful about copying code blindly from the first few chapters without reading at least chapter 8 (and perldoc perlsec in Perl's included documentation)! Simple examples are appropriate for teaching and personal testing, but could have disastrous consequences on publicly-accessible servers. To the authors' credit, even the simple example code runs with warnings, taint mode, and the strict pragma.

You'll need to know some Perl -- at least enough to follow along with somewhat-idiomatic code. Platform and portability wise, there's an unapologetic Unix flavor to the examples. Nearly everything should work on Win32 and other operating systems, but be aware of certain differences. As for web server information, it's Apache-specific. (Configuration for other platforms will be similar, but is left as an exercise for the reader.)

Some topics could use more treatment. It would have been nice to have more information on HTML::Mason (though admittedly complex, it's powerful and probably deserves more than a two page introduction) and XML and Middleware. New technologies like RSS and WAP need tools and users and programmers. There's also more to say on debugging CGI applications, though a pointer to the facetiously named Idiot's Guide could be helpful.)

The Summary Newly updated, chock full of good advice and, above all, high-quality code, this book is a great place to learn how to focus your Perl skills in a popular direction. Follow the advice presented, ask around for help if you need it, and have fun. Don't bother spending 24 hours or 21 days or whatever it is now, learn CGI programming with Perl the right way.

special thanks to the amazing Simone at O'Reilly for her help making these and other reviews possible!

Table of Contents

1. Getting Started
2. The Hypertext Transfer Protocol
3. The Common Gateway Interface
4. Forms and CGI
5. CGI.pm
6. HTML Templates
7. JavaScript
8. Security
9. Sending Email
10. Data Persistence
11. Maintaining State
12. Searching the Web Server
13. Creating Graphics on the Fly
14. Middleware and XML
15. Debugging CGI Applications
16. Guidelines for Better CGI Applications
17. Effeciency and Optimization

1. Works Cited and Further Reading
2. Perl Modules

You can purchase this book at ThinkGeek.

Contributed by readers FooBard and Scrymarch, the pair of reviews below ought to either bring back memories or spark some curiosity. Stranger In a Strange Land may not be everyone's favorite book -- even among Heinlein fans -- but it certainly strikes a chord. If you haven't read it, these reviews should give you a good idea of whether you'd like to.

Stranger in a Strange Land author Robert A. Heinlein pages 438 publisher Ace Books rating n/a reviewer FooBard, Scrymarch ISBN 0441790348 summary Undeniably intriguing, by turns illuminating and infuriating story of life on earth as viewed by a visitor with a special interest.

FooBard writes: "Review of Robert A. Heinlein's Stranger In a Strange Land, unabridged version.

I have read a lot, although not all, of Heinlein's work. Stranger is clearly his crown jewel, and for reasons that transcend science fiction. All great art transcends its genre, and this book is no exception. The story is not merely "robots and rocketships", but uses science fiction for a truly creative look at the human condition: religion, love, sex, money, power, government, relationships... what more could you want?

Footnote: This book is also the origin of the term "grok" (loosely meaning: to have a very deep understanding of), which is used so frequently in computer circles.

The Scenario

The story is based on Valentine Michael Smith (no relation), usually called Mike, or the Man From Mars. Mike is the son of two crewmembers of the first manned flight to Mars, and was born on Mars after that flight crash-landed. His parents died shortly after his birth, and he was raised by Martians.

"Martians?" you might say. "How quaint." Keep in mind that this was written a while ago (when Martians were still trendy), and suspend your disbelief. Just as in all good "classic" sci-fi, Heinlein's methods and situation aren't as important as his goals and ideas. Sci-fi isn't about the "sci" or the "fi", but about what it means to be human.

Mike struggles in adapting to life on Earth, first physically, then mentally. He grapples with his integration into the human race in his own unique way. His journey is sort of a coming of age, yet he really is of age in another society -- a society whose values are often polar opposites to those value that define our humanness. Throughout Mike's process, Heinlein reflects on what it means to be human, which is one of the best and richest themes used in literature.

In a historical context, the book itself also has an interesting history. Back when it was originally published, Heinlein was forced to cut quite a bit of the book, especially the racier parts. This version reflects the manuscript that Heinlein originally wanted. I have previously read the abridged version, although I must admit that I don't remember all the finer points. This version does seem to have a bit more sex and more material that makes fun of the Fosterite church, etc., so it packs more of a punch than I remember from the abridged version.

What's Good

Heinlein makes very interesting choices in his portrayal of Martian society, and specifically contrasts them to what is most human. Religion, love, sex, money, etc. are all missing in Martian society, and this contrast allows for wonderful parody and analysis. We watch Mike stumble through learning such basics as male vs. female, love, communication, why we have religion, how we use humor, death and how we fear it, money, privacy... Each time, Mike's character forces us to question the "why" behind those ideas in society that we take for granted. Religion (in our form) doesn't seem natural to him. He doesn't laugh. He doesn't understand the wonder of sex, nor why we have property. Heinlein deconstructs those ideas through his plot and the character of Mike, and creates a consistent philosophical view of the world. (Whether you agree with Heinlein's ideas and philosophies is a different matter. I happen to agree with most.)

To watch a character struggle through this discovery for an entire book would be painful; no one wants to see that much struggle without a bit of redemption. So Heinlein makes Mike into a very powerful figure, showing the strengths of Martian society: no money, complete power of mind over body (Mike grows muscles by "thinking them", and has strong telepathic and telekenetic abilities), and he has an unquestioning belief and tangible proof of the afterlife. His human friends learn as much from him as he does from them, and, by the end of the book, Mike seeks to remake Earth society with his new viewpoint.

Religion plays a central role in this book. Organized religion is roasted (especially through the device of the Fosterite church), while religion itself is held as uniquely human -- an answer to our mortality and a reflection of our need to understand our world. Towards the end of the book, Mike creates his own religion (in a sense) and actually follows through, in true literary fashion, to his logical ending: Mike is a clear Christ allegory. Mike is the human- who- is- more- than- and- not- quite- human, and comes to Earth to redeem our society, to challenge how we see ourselves in the universe, and eventually to die for our redemption.

Other characters also are mouthpieces for Heinlein. Jubal Harshaw (strikingly and too blatantly similar to Lazarus Long, from "Time Enough for Love") is the older, yet very open-minded mentor to Mike. Jill helps him explore the male/female relationships, and Ben Caxton works to act as a foil to both Jubal and Mike, allowing Heinlein to use those characters to clarify his points. Several other characters interplay with the main character to strengthen Heinlein's philosophical arguments.

What's Bad

I have only a few issues with the book. The story ends in a typically Heinleinian fashion, with all the characters in some kind of group marriage, where free love amongst highly intellectual people conquers all. Nuh-uh. I'm not buying it again -- especially after rereading "Time Enough for Love" not too long ago. His exploration of such a life is just a bit too drawn-out and idyllic.

Also, in Stranger, Heinlein tries to examine almost all of what it means to be human. Few books, even the classics, attempt such a grandiose exploration of the human condition and all that it encompasses. It's a bit too large of an undertaking, even for the unabridged version. At the end of the book, you feel like you've explored a lot of territory, but you don't quite "grok" it all.

What's In it for me?

Heinlein does a wonderful job in giving himself the situations in which to explore those themes, however, and he must be commended in his success in surpassing the "robots and rocketships" so prevalent among his peers. Heinlein is a master of taking sci-fi beyond the plots, and his character of Mike was his best medium for his talent. This book changed science fiction forever, and it's still among the best. Even if you have read this book before (as I had), this book forces an examination of what it means to be human, especially in a world where technology itself -- not the humanity behind it -- drives much of literature, not to mention the very fundamentals of our lives."

Another point of view, from Scrymarch: Thou art God - I mean Hi. If someone had said that phrase once more to me by the time I finished this book, I think I would have struck them. It is bandied about with a smug bantering style that characterizes the problems I have with the novel and I suspect the author himself.

It is the story of a human raised on Mars by Martians. He then comes to Earth and experiences American society, and the resultant culture-shock on the part of both the main character and the reader is the main point of book. Indeed, by the accounts of the cover it is supposed to upset every background assumption that underlies my existence. Why it fails, and the way it fails, I think is a peculiar result of the interaction between when it was written, the ?60s, and R.A. Heinlen.

The 21st or 22nd century, when the book is set, bears a remarkable resemblance to a certain decade in the 20th century. Some extra gizmos like flying cars are about; there is an obligatory world government; but Western society is essentially the same when it comes to things like the sexism that permeates every printed word on every page.

Sexism is in fact one of the themes of the book. Humanity is blessed with our division into opposite and complementary genders apparently, and we should get on with doin? what our sex does best. Sex is another major theme. It?s enjoyable, you see, and by allowing us to "grow closer" to one another all human tragedy and hunger will be able to be solved.

Martian culture, a meditative one which interacts with spirits as its main leaders, is not much of a shock. It is essentially a convenient mix of Eastern cultures and religions, with some interesting embellishments, such as cannibalism (the only idea which really gave me much of a start). The Martians are at least not humanoid in shape. It revolves around a concept of "grokking" which roughly translates as completely interacting or understanding something. After one has grokked, one can act, and waiting for the right moment to act is also fundamental. This approach to existence makes Martians unbelievably wise, of course, and so they have in turn gained tremendous psychic powers. One of these powers includes routinely making objects (usually clothes) disappear completely, which explains where all those Martian cities got to.

Anyway, the grand revelation Mars-boy receives drives him to found a cult (the rise of specious alien cults is one of the few prophetic aspects of the book). The cult hangs around and has sex with one another a lot, while telling each other they art God. Perhaps this was the appeal of the novel 40-ish years ago. It was a little too flippant for me.

Stranger in a Strange Land is a silly, dated book and the first I have ever seriously considered throwing against a wall.

Purchase this book at ThinkGeek.

Contributed by readers FooBard and Scrymarch, the pair of reviews below ought to either bring back memories or spark some curiosity. Stranger In a Strange Land may not be everyone's favorite book -- even among Heinlein fans -- but it certainly strikes a chord. If you haven't read it, these reviews should give you a good idea of whether you'd like to.

Stranger in a Strange Land author Robert A. Heinlein pages 438 publisher Ace Books rating n/a reviewer FooBard, Scrymarch ISBN 0441790348 summary Undeniably intriguing, by turns illuminating and infuriating story of life on earth as viewed by a visitor with a special interest.

FooBard writes: "Review of Robert A. Heinlein's Stranger In a Strange Land, unabridged version.

I have read a lot, although not all, of Heinlein's work. Stranger is clearly his crown jewel, and for reasons that transcend science fiction. All great art transcends its genre, and this book is no exception. The story is not merely "robots and rocketships", but uses science fiction for a truly creative look at the human condition: religion, love, sex, money, power, government, relationships... what more could you want?

Footnote: This book is also the origin of the term "grok" (loosely meaning: to have a very deep understanding of), which is used so frequently in computer circles.

The Scenario

The story is based on Valentine Michael Smith (no relation), usually called Mike, or the Man From Mars. Mike is the son of two crewmembers of the first manned flight to Mars, and was born on Mars after that flight crash-landed. His parents died shortly after his birth, and he was raised by Martians.

"Martians?" you might say. "How quaint." Keep in mind that this was written a while ago (when Martians were still trendy), and suspend your disbelief. Just as in all good "classic" sci-fi, Heinlein's methods and situation aren't as important as his goals and ideas. Sci-fi isn't about the "sci" or the "fi", but about what it means to be human.

Mike struggles in adapting to life on Earth, first physically, then mentally. He grapples with his integration into the human race in his own unique way. His journey is sort of a coming of age, yet he really is of age in another society -- a society whose values are often polar opposites to those value that define our humanness. Throughout Mike's process, Heinlein reflects on what it means to be human, which is one of the best and richest themes used in literature.

In a historical context, the book itself also has an interesting history. Back when it was originally published, Heinlein was forced to cut quite a bit of the book, especially the racier parts. This version reflects the manuscript that Heinlein originally wanted. I have previously read the abridged version, although I must admit that I don't remember all the finer points. This version does seem to have a bit more sex and more material that makes fun of the Fosterite church, etc., so it packs more of a punch than I remember from the abridged version.

What's Good

Heinlein makes very interesting choices in his portrayal of Martian society, and specifically contrasts them to what is most human. Religion, love, sex, money, etc. are all missing in Martian society, and this contrast allows for wonderful parody and analysis. We watch Mike stumble through learning such basics as male vs. female, love, communication, why we have religion, how we use humor, death and how we fear it, money, privacy... Each time, Mike's character forces us to question the "why" behind those ideas in society that we take for granted. Religion (in our form) doesn't seem natural to him. He doesn't laugh. He doesn't understand the wonder of sex, nor why we have property. Heinlein deconstructs those ideas through his plot and the character of Mike, and creates a consistent philosophical view of the world. (Whether you agree with Heinlein's ideas and philosophies is a different matter. I happen to agree with most.)

To watch a character struggle through this discovery for an entire book would be painful; no one wants to see that much struggle without a bit of redemption. So Heinlein makes Mike into a very powerful figure, showing the strengths of Martian society: no money, complete power of mind over body (Mike grows muscles by "thinking them", and has strong telepathic and telekenetic abilities), and he has an unquestioning belief and tangible proof of the afterlife. His human friends learn as much from him as he does from them, and, by the end of the book, Mike seeks to remake Earth society with his new viewpoint.

Religion plays a central role in this book. Organized religion is roasted (especially through the device of the Fosterite church), while religion itself is held as uniquely human -- an answer to our mortality and a reflection of our need to understand our world. Towards the end of the book, Mike creates his own religion (in a sense) and actually follows through, in true literary fashion, to his logical ending: Mike is a clear Christ allegory. Mike is the human- who- is- more- than- and- not- quite- human, and comes to Earth to redeem our society, to challenge how we see ourselves in the universe, and eventually to die for our redemption.

Other characters also are mouthpieces for Heinlein. Jubal Harshaw (strikingly and too blatantly similar to Lazarus Long, from "Time Enough for Love") is the older, yet very open-minded mentor to Mike. Jill helps him explore the male/female relationships, and Ben Caxton works to act as a foil to both Jubal and Mike, allowing Heinlein to use those characters to clarify his points. Several other characters interplay with the main character to strengthen Heinlein's philosophical arguments.

What's Bad

I have only a few issues with the book. The story ends in a typically Heinleinian fashion, with all the characters in some kind of group marriage, where free love amongst highly intellectual people conquers all. Nuh-uh. I'm not buying it again -- especially after rereading "Time Enough for Love" not too long ago. His exploration of such a life is just a bit too drawn-out and idyllic.

Also, in Stranger, Heinlein tries to examine almost all of what it means to be human. Few books, even the classics, attempt such a grandiose exploration of the human condition and all that it encompasses. It's a bit too large of an undertaking, even for the unabridged version. At the end of the book, you feel like you've explored a lot of territory, but you don't quite "grok" it all.

What's In it for me?

Heinlein does a wonderful job in giving himself the situations in which to explore those themes, however, and he must be commended in his success in surpassing the "robots and rocketships" so prevalent among his peers. Heinlein is a master of taking sci-fi beyond the plots, and his character of Mike was his best medium for his talent. This book changed science fiction forever, and it's still among the best. Even if you have read this book before (as I had), this book forces an examination of what it means to be human, especially in a world where technology itself -- not the humanity behind it -- drives much of literature, not to mention the very fundamentals of our lives."

Another point of view, from Scrymarch: Thou art God - I mean Hi. If someone had said that phrase once more to me by the time I finished this book, I think I would have struck them. It is bandied about with a smug bantering style that characterizes the problems I have with the novel and I suspect the author himself.

It is the story of a human raised on Mars by Martians. He then comes to Earth and experiences American society, and the resultant culture-shock on the part of both the main character and the reader is the main point of book. Indeed, by the accounts of the cover it is supposed to upset every background assumption that underlies my existence. Why it fails, and the way it fails, I think is a peculiar result of the interaction between when it was written, the ?60s, and R.A. Heinlen.

The 21st or 22nd century, when the book is set, bears a remarkable resemblance to a certain decade in the 20th century. Some extra gizmos like flying cars are about; there is an obligatory world government; but Western society is essentially the same when it comes to things like the sexism that permeates every printed word on every page.

Sexism is in fact one of the themes of the book. Humanity is blessed with our division into opposite and complementary genders apparently, and we should get on with doin? what our sex does best. Sex is another major theme. It?s enjoyable, you see, and by allowing us to "grow closer" to one another all human tragedy and hunger will be able to be solved.

Martian culture, a meditative one which interacts with spirits as its main leaders, is not much of a shock. It is essentially a convenient mix of Eastern cultures and religions, with some interesting embellishments, such as cannibalism (the only idea which really gave me much of a start). The Martians are at least not humanoid in shape. It revolves around a concept of "grokking" which roughly translates as completely interacting or understanding something. After one has grokked, one can act, and waiting for the right moment to act is also fundamental. This approach to existence makes Martians unbelievably wise, of course, and so they have in turn gained tremendous psychic powers. One of these powers includes routinely making objects (usually clothes) disappear completely, which explains where all those Martian cities got to.

Anyway, the grand revelation Mars-boy receives drives him to found a cult (the rise of specious alien cults is one of the few prophetic aspects of the book). The cult hangs around and has sex with one another a lot, while telling each other they art God. Perhaps this was the appeal of the novel 40-ish years ago. It was a little too flippant for me.

Stranger in a Strange Land is a silly, dated book and the first I have ever seriously considered throwing against a wall.

Purchase this book at ThinkGeek.

Woodrow Stool asks: "My business is software development and I am updating my home office. Does anyone have any experience with the latest and greatest task lights for workstations, such as the Eclipse? Any other suggestions for the best reasonably priced task lighting for a workstation environment?" I love my Eclipse, but I wonder if there are better options out there.

Sitting at your average Linux box is becoming simpler by the day, but the complexity and volume of information that that machine is likely to transmit and recieve is only getting greater. Reader Martin Barry contributed this review of Linux Routers. This book promises to unravel that complexity for the reader willing to trade some time and effort for a custom solution to their own routing requirements.

Linux Routers author Tony Mancill pages 329 publisher Prentice Hall rating 7 reviewer Martin Barry ISBN 0-13-086113-8 summary Fundamental look at replacing brand name routers with ones based on generic hardware and Linux. Develops concepts of core routing features and relevant extensions in the context of six router applications including LAN, WAN and Internet.

Overview Linux Routers is an interesting little book that pulls together the kind of information that one could find browsing various HOW-TOs and guides into a concise narrative explaining the tasks required to build and operate Linux-based routers.

Opening the book is a discussion on the fundamental theories underlying routing and the infrastruture required to implement routing solutions. For those (like myself) who have little exposure to network administration this will be particulary helpful as a lead in to the following chapters.

There is a chapter to further build on the basics of IP (addresses including RFC1918, subnetting, routing tables), ethernet (MAC addresses, ARP, switching) and wide area networks (types of links, integrating with telco hardware, billing).

The detail increases as the book progresses. It starts with the simplest installation, routing between two ethernet segments covering the basics of setting up Linux networking and routing. Methods of IP accounting are also introduced. Mention is also made of the Linux Router Project and the single floppy distribution they have developed.

Moving onto WAN routers introduces the telco issues and ways to preserve bandwdith (http proxy, caching dns). IPchains is introduced in the context of masquerading otherwise unroutable addresses. Various tools are listed in a section that demonstrates how to view traffic on the network for educational and debugging purposes. Monitoring of traffic over a router is also described, using MRTG to collect and beautify data. Chapter 7 includes methods of reducing said traffic such as http caches and a DNS slave at the remote site.

A border router to the Internet is used to raise related security issues and the use of proxy servers to screen access from the outside in or the inside out. This information bridges across chapters 6 and 8 and includes topics like packet filtering firewalls, port redirection and proxies. The flexibility of Linux is demonstrated by the ability to integrate routing and Internet servers on a single box. With obvious reservations about how wise that is, it is pertinent that failure detection, notification and recovery are all covered.

What's to like The information starts out simple and builds on itself in cyclical nature as the book progresses. The six scenarios are the ones likely to be encountered in a production environment and illustrate the benefits of using Linux routers.

The issues of choosing Linux as a router are well addressed, including discussions on thorny topics like "Total Cost of Ownership," and provide a framework for you to assess your own situation. The writer's style is clear and easy to read.

Different WAN and Internet telco links are discussed (POTS, frame relay, dedicated digital access circuit) including how to configure the link and what protocols to run over it.

Peripheral issues, such as troubleshooting tcp or proxy servers, are dealt with well. Information is provided to allow you to understand the integration with the routing infrastructure you are deploying. When the topic starts to drift from the task at hand the author makes good use of redirecting people interested in more detail to other references (Web sites, books).

What's annoying The author is a part of the Debian project so some things have a bit of a Debian slant on them (this includes the file system layout referred to and the config files). This shouldn't be too much of an issue for most people, though it will require a thorough understanding of one's own system or problem-solving via your distribution's manual. WAN hardware and software discussions are limited by the author's experience, with a particular brand of card and one software package (wanpipe -- of which the author is the Debian maintainer) being focused on.

Alternatives are mentioned, but not in great depth, and the examples therefore might not be portable to your choice of card or software.

Summary If you are comfortable with enabling routing, IPchains, proxy servers and troubleshooting tcp/ip on Linux, this book will be of little use other than to provide a step-by-step approach. On the other hand, if you currently use brand-name routers but have sometimes wondered whether that 486 in the corner could be put to good use, this book will certainly guide you on your travels.

Table of Contents Note: the author uses the elements to name boxen, hence the names of the chapters.

1. Routing Building Blocks (Hardware, Environment, Software)
2. IP, Ethernet and Telephony Basics (Routing, Ethernet, WAN)
3. Silicon - LAN Router (LAN Routing, IP Aliasing and Accounting)
4. Erbium - an Extranet Router (IP Masq, IP Monitoring)
5. Zinc - Frame Relay Router (WAN Hardware and Software, MRTG)
6. Oxygen - Internet Router (Security, Firewalling, Failure Detection)
7. Californium - Satellite Office Router (Caches and Slaves, Multifunction Routers, Remote System Support)
8. Hafnium - Internet Services Router (Proxying, IP Redirection, Routing Daemons, Emergency Recovery)

Appendices

• A) Links
• B) Compiling a Kernel
• C) Testing Strategies
• D) Ethics and Other Considerations
• E) GPL

You can purchase this book from ThinkGeek.

Sitting at your average Linux box is becoming simpler by the day, but the complexity and volume of information that that machine is likely to transmit and recieve is only getting greater. Reader Martin Barry contributed this review of Linux Routers. This book promises to unravel that complexity for the reader willing to trade some time and effort for a custom solution to their own routing requirements.

Linux Routers author Tony Mancill pages 329 publisher Prentice Hall rating 7 reviewer Martin Barry ISBN 0-13-086113-8 summary Fundamental look at replacing brand name routers with ones based on generic hardware and Linux. Develops concepts of core routing features and relevant extensions in the context of six router applications including LAN, WAN and Internet.

Overview Linux Routers is an interesting little book that pulls together the kind of information that one could find browsing various HOW-TOs and guides into a concise narrative explaining the tasks required to build and operate Linux-based routers.

Opening the book is a discussion on the fundamental theories underlying routing and the infrastruture required to implement routing solutions. For those (like myself) who have little exposure to network administration this will be particulary helpful as a lead in to the following chapters.

There is a chapter to further build on the basics of IP (addresses including RFC1918, subnetting, routing tables), ethernet (MAC addresses, ARP, switching) and wide area networks (types of links, integrating with telco hardware, billing).

The detail increases as the book progresses. It starts with the simplest installation, routing between two ethernet segments covering the basics of setting up Linux networking and routing. Methods of IP accounting are also introduced. Mention is also made of the Linux Router Project and the single floppy distribution they have developed.

Moving onto WAN routers introduces the telco issues and ways to preserve bandwdith (http proxy, caching dns). IPchains is introduced in the context of masquerading otherwise unroutable addresses. Various tools are listed in a section that demonstrates how to view traffic on the network for educational and debugging purposes. Monitoring of traffic over a router is also described, using MRTG to collect and beautify data. Chapter 7 includes methods of reducing said traffic such as http caches and a DNS slave at the remote site.

A border router to the Internet is used to raise related security issues and the use of proxy servers to screen access from the outside in or the inside out. This information bridges across chapters 6 and 8 and includes topics like packet filtering firewalls, port redirection and proxies. The flexibility of Linux is demonstrated by the ability to integrate routing and Internet servers on a single box. With obvious reservations about how wise that is, it is pertinent that failure detection, notification and recovery are all covered.

What's to like The information starts out simple and builds on itself in cyclical nature as the book progresses. The six scenarios are the ones likely to be encountered in a production environment and illustrate the benefits of using Linux routers.

The issues of choosing Linux as a router are well addressed, including discussions on thorny topics like "Total Cost of Ownership," and provide a framework for you to assess your own situation. The writer's style is clear and easy to read.

Different WAN and Internet telco links are discussed (POTS, frame relay, dedicated digital access circuit) including how to configure the link and what protocols to run over it.

Peripheral issues, such as troubleshooting tcp or proxy servers, are dealt with well. Information is provided to allow you to understand the integration with the routing infrastructure you are deploying. When the topic starts to drift from the task at hand the author makes good use of redirecting people interested in more detail to other references (Web sites, books).

What's annoying The author is a part of the Debian project so some things have a bit of a Debian slant on them (this includes the file system layout referred to and the config files). This shouldn't be too much of an issue for most people, though it will require a thorough understanding of one's own system or problem-solving via your distribution's manual. WAN hardware and software discussions are limited by the author's experience, with a particular brand of card and one software package (wanpipe -- of which the author is the Debian maintainer) being focused on.

Alternatives are mentioned, but not in great depth, and the examples therefore might not be portable to your choice of card or software.

Summary If you are comfortable with enabling routing, IPchains, proxy servers and troubleshooting tcp/ip on Linux, this book will be of little use other than to provide a step-by-step approach. On the other hand, if you currently use brand-name routers but have sometimes wondered whether that 486 in the corner could be put to good use, this book will certainly guide you on your travels.

Table of Contents Note: the author uses the elements to name boxen, hence the names of the chapters.

1. Routing Building Blocks (Hardware, Environment, Software)
2. IP, Ethernet and Telephony Basics (Routing, Ethernet, WAN)
3. Silicon - LAN Router (LAN Routing, IP Aliasing and Accounting)
4. Erbium - an Extranet Router (IP Masq, IP Monitoring)
5. Zinc - Frame Relay Router (WAN Hardware and Software, MRTG)
6. Oxygen - Internet Router (Security, Firewalling, Failure Detection)
7. Californium - Satellite Office Router (Caches and Slaves, Multifunction Routers, Remote System Support)
8. Hafnium - Internet Services Router (Proxying, IP Redirection, Routing Daemons, Emergency Recovery)

Appendices

• A) Links
• B) Compiling a Kernel
• C) Testing Strategies
• D) Ethics and Other Considerations
• E) GPL

You can purchase this book from ThinkGeek.

You asked, they answer. Jon Lasser and Jay Beale decided to kick their answers back and forth a few times in the style of Crossfire -- at least if Crossfire guests were security-obsessed, literate hackers with a knack for finding gaps in Linux and Unix security. And don't forget the book creds: Jon wrote the excellent Think Unix (want to buy it, huh?), and Jay is plugging away at (and just plain plugging) his upcoming tome from Addison-Wesley,Securing Linux the Bastille Way.

Jay Beale: Before we get to the questions, let me make an announcement. I've just recently been hired by MandrakeSoft (makers of Linux Mandrake) as their Security Team Director. They're sponsoring my work on Bastille and I'm working to better their distribution's general security. SecurityPortal.com interviewed me about this specifically.

Now, the questions:

1) Target audience
by DreamerFi

Bastille is a great project, but ultimately it targets people who sort-of know what they are doing. How do you feel about projects like the NetBSD/i386 Firewall Project who (whilst having all sources available) targets people who have no clue other than "I need security" by giving them a firewall that has an install that's about as simple as one can make it? Is this just a matter of defining the target audience different?

Jay: Really, it's not entirely targetted away from newbies. In fact, I sorta thought it was newbie-friendly. In designing the Bastille Linux hardening script, we originally sought to make a basic script, that would simply go through the sytem making changes. It could shut down unneeded programs/daemons, tighten up permissions and deactive bad protocols like telnet. At some point, we realized that this would leave many people believing we'd broken something... So, we decided we'd make the script interactive, asking the user before turning off telnet. Unfortunately, this meant that many of the target boxes never got hardened much. Since people didn't know why telnet was bad, they'd leave it on. So, I became a writer! Bastille carries a large number of explanations, targeted to the new user/sysadmin. By the way, the reasoning on deactivating telnet goes like this:

• Telnet is cleartext, allowing third parties to sniff passwords
• Telnet sessions can be intercepted and taken over by a man in the middle, using a simple tool like hunt.
• Finally, telnet can be replaced easily by the much safer Secure SHell, ssh.

Jon: Setting up a firewall for people with no clue is an interesting problem. It requires that the person do pretty much nothing nonstandard: once you need to punch a hole in the firewall, all of a sudden you need to know a lot of stuff again. Alternatively, you could leave the firewall pretty much wide-open and just block a couple of things, which is much easier to do but doesn't add all that much security. Setting up a firewall properly is hard work, and requires specialized skills to do it right: I'm not comfortable setting up a firewall for a company to protect secret stuff, and I tend to recommend hiring a (qualified, competent, specialized) consultant for the job.

For Bastille, we try to fulfill both of those possibilities with a single piece of software. We try to both make it simple to use (lots of defaults that won't break stuff) but make it possible to lock the system down tightly. In either case, user education is key.

Of course, most people don't read documentation, so it's all in the script. You can lead a horse to water, etc., so we try to do that. Bastille seems (to me, anyway) friendly to newbies who read carefully and take the time to understand. I'm not sure how to really help the others anyway.

2) Breaking out the cluestick ...
by mosch

Given the world's largest cluestick with which you could assault every single SysAd on the planet, what clues would you distribute, other than the use of bastille, and the knowledge that there's life outside computers?

Jay: I'd have one major clue that I think supersedes most: Educate yourself! In terms of security, there's few solutions that can beat a clueful sysadmin. On the other hand, any solution you choose for security usually turns to mush when a clueless admin makes the wrong mistake with it. For instance, you might have incredible encryption on your passwords and such, but if you choose "bob" for a password, your system can usually be brute forced!

Jon: Yeah, that's pretty much it. The only clue worth having is the one that allows you to find the other ones on your own.

3) Security is a process, not a thing.
by Skapare

How will Bastille allow users to treat their computer and network security as a "process" (as Bruce Schneier is quoted to say). Are there tools to help users deal with security "events"?

Jay: We're working on integrating this. Right now, we've got something very rudimentary that checks to see if a cracker's sniffer has been installed on your system. We're working on more. I'm currently hacking up a series of scripts, like Tiger, that will examine the current state of the system for anomalies.

Jon: Security is a process, there's no question about it. When I've got a process that works pretty much the same every time, I turn it into a checklist. Bastille, when it comes down to it, is essentially a checklist that performs the tasks listed on it. So Bastille lets you automate your existing process.

Jay: Yes. A checklist. Actually, in these days of rapidly upgrading (read replacing) your distribution every three-six months, the only way to use a checklist as long as Bastille's is to automate it!

Jon: Software development is also a process; Bastille is in a constant state of development. As we find new things that need fixing, we go to the software development part of the process, then the release part of the process, and then the users hopefully take it to the upgrading process. :-)

(Hint: for this process to work, you need to participate.)

4) "Missing" features?
by Coz

A two-part question:

What features do you feel are missing from Bastille as it stands today, and aren't in the roadmap you have for the immediate future?

What elements of system security do you feel should be part of the "core" (if not the kernel) of the operating system, and why (in your opinions) aren't they there already?

Jay: Part I is a tough one. I think I'd like to see an amazing intrusion detection system integrated in. I've also got some ideas for new offshoots of Bastille that I'll need some time to develop before I bring them up. Part II is somewhat easier. I think an operating system should implement seperated "compartments" so that one root-level program can't tromp all over another.

Further, we really should move away from this simple Unix distinction of "root" and "non-root." We can get a lot more granular than that. We're already seeing this latter bit, such that my web server runs as user www, my name server runs as user named, and so on... I wish we could take this farther, as it would really curb the potential for remote root compromise. As for why we don't have it all yet, consider the huge effort to move to these models... Now, we're getting this, through add-ons. Medusa DS9 is bringing us compartments and system call ACL's that apply even to root. The Linux capabilities work is getting us further to a point where we can confine root's actions.

5) Question
by JCCyC

What were the top 3 most asinine security holes you ever encountered on a GNU/Linux distro?

Jay: There have been a number of security holes that looked dumb in hindsight! I think the more interesting question is this, "what security holes right now are going to be seen as stupid later?" We're going to think that there shouldn't have been nearly so many world-executable setuid-root programs. We're going to seriously question having network-accessible system daemons (ftp, dns, web...) running with root authority. Luckily, we're just starting to question this now. Let's see where it goes...

Jon: I'm with Jay on this one. I don't think that any of the decisions that distributions make are particularly stupid, they're just aimed at different markets.

For example, I don't really think it's possible to completely secure either SuSE or Debian, due to the sheer number of packages included. That doesn't mean that this is the wrong decision to make, it's just aimed at a different population with different needs. (Of course, you can install either of those distributions perfectly well -- but you can't install everything, and you need some more knowledge to do it right than on some other platforms.)

6) Configuration
by FeeDBaCK

In what way does Bastille differentiate between different types of installs? Does it prompt the users about services? Will it shut off my apache service if I plan on making this machine a web server?

What third party tools do you install/recommend to help with the hardening of the system? Tripwire? tcpserver?

Do you incorporate any form of checking when doing your install to ensure that the box has not already been compromised, such as checking for common trojans/backdoors?

Jay: Oh no, another multiple-part question. OK, first, Bastille doesn't really do this distinguishing for you, when run in the default interactive mode. You make the choices, turning off services that you don't need, tightening the configuration on those you do. Second, I strongly recommend Tripwire. It's really the only way to know if your system has been compromised. I'd also recommend replacing your mail daemon with Postfix, as it's got an incredibly secure design. Third, no, we don't. Damn, that's a good idea. FeeDBaCK, want to help us develop that? E-mail me.

Jon: If the box has already been sufficiently compromised by a sufficiently capable and dedicated individual or group, it's a technical impossibility to detect it. Let's say you've cracked the box and installed some custom kernel modules that will report 'correct' file contents for, say, your PAM library even though it's been changed. Tough to do? Yeah. But possible. How would you defend against this?

That's not to say we shouldn't try, but I don't think we can provide adequate assurance on the issue ...

Jay: Jon's got a good point here. But we can, as FeeDBaCK suggests, do at least the trivial first measure of looking for known trojans.

7) Debian?
by luge

Do you guys have any plans to do something similar for Debian, or have others approached you about it? I'd love to apt-get install bastille, and have it do something similar to what I've heard it does for RH. Anyway, even if you don't, keep up the good work.

Jay: We are planning on it. I'm working on a new architecture, which makes it easy to extend Bastille to other distributions without doing the classical "porting" work. We'll include Debian and even Slackware! Watch freshmeat or our announcements list -- when we're in beta quality, I'll announce.

8) Not such a good name for a distro ...
by AFCArchvile

..especially if you want to convey security. Do you remember your late 18th century European history? Right. The Bastille in France was invaded and destroyed, prisoners were liberated, and the monarchy was overthrown by that terrible harbinger of death, La Guillotine.

I'd hate to see any Bastille Linux-oriented viruses or trojans. Maybe there will be one which triggers on July 14th of every year and echoes on the screen: "Libert=E9! Egalit=E9! Fraternit=E9!"

For more historical stuff on Bastille Day, check out this link to the French Embassy.

Jay: OK, so maybe it was a tough name. To tell you the truth, this year's July 14th LinuxSecurity.com interview hit on my birthday ... For the official answer, I'll let Jon pipe in here ...

Jon: Yup, all that bad stuff happened. But the building wasn't the problem: the building was incredibly secure by any standard. The problem was the administration.

So it is with computers.

Besides, we're not a distribution. :-)

9) Why is Bastille Necessary?
by DG

In a perfect world, the Bastille scripts would be unecessary, because the default installation of the distribution would have been hardened from the get-go.

Why do you feel that various distributions are so insecure by default? What are the most common mistakes they make? What kinds of changes need to happen at Red Hat to make your scripts unneeded?

Jay: Well, some of the insecurity comes from trying to reduce phone support costs. Consider for a second what would happen if Red Hat deactivated telnet on their machines, for the reasons I stated above. How many man-hours would go to the five-minute telephone calls, explaining to newbies that telnet was insecure and that ssh was a valid replacement? On top of this, remember that vendors are constantly being pushed to add more and more features. This often flies right in the face of effective security, which is generally much more minimalist.

The thing is, really, that it's not always as clear-cut as "mistakes." The most secure installation is utterly and completely useless. Much of what Bastille's actions make the system at least "inconvenient" and often require user/sysadmin education. Bastille-type hardening programs will always be necessary, especially for Red Hat, a company which has to keep its distribution featureful, easy to use, and convenient.

Jon: Convenience and security are almost always inversely proportional. Red Hat's target market has a whole bunch of people whose goal is to get a web server on the Internet in sixty minutes or less; higher security would only be a barrier to their customers' goals. They know their target market better than we do, but our market is for people who need something else.

Also, I think it's very unfair to single Red Hat out. We picked them as our first target due to their market penetration in the US and the relative ease of securing it, due to the limited quantity of stuff it installs.

Jay: I have to agree with Jon again here. I'll stop before I get on my rant, but companies develop where their users/customers ask them to. People are not asking Red Hat or MandrakeSoft or any other vendor for greatly enhanced security -- they're asking for more convienence, easy of use and a massive feature set -- and they're asking for it without much regard for the effect on security. This isn't intentional. The users just don't know better yet. This is where education must come in. (End rant)

10) Distribution specific, etc.
by matman

I have two questions actually.

The first: do you plan to make a non-distribution-specific hardening program/system/script? If so, how? It would be neat to have a consensus between distributions on file locations, etc to make this easier; do you plan on working with other distributions to come up with some sort of common interface or environment?

The second: do you plan on including any kernel-based capability, IDS, or ACL addons? A good default use of these features would greatly increase the security of linux in general, but they are prohibitively complex for most users. Thus, these are great things to have taken care of by the system -- do you plan on working on something to control these things (semi)automatically?

Jay: Yes, definitely. In fact, I'm currently working on a new internal architecture that easily supports this. In essence, we simply have to keep track of and store more data about each distribution. On top of this, we have to check the state of the system more thoroughly, looking for general files, instead of packages. We'll be able to support a lot more than just Red Hat Linux and Linux Mandrake.

Unfortunately, I don't think we'll ever get to the point where we can dictate file locations to the distribution makers. They're not even maintaining the same file locations from release to release! I think it's mostly an issue of preference for their individual package maintainers, really.

As for kernel-level capabilities/ACLs, I'm highly interested in this. I think the implementations are still immature, but it'll be exciting. Usability will be tough, but I think it can be achieved. We can make this optional for new users and perhaps only place restrictions on small parts of the system. This stuff shows a lot of promise.

A final meta-question
by Jay

The question everybody asks, in a million different ways (sorry, I'm not going through the thread again to pick out users; you know who you are):
Why do this? Why not just use OpenBSD?

Jon: Because people use Linux. Ultimately, standard is better than better. For most tasks, most of the time, assuming that the stuff meets minimum qualifications, it's better to have a single platform than multiple platforms that fulfill different needs.

Besides, a fair part of OpenBSD's security comes from its feature-limited default installation. They've been subject to the same FTP and DHCP exploits as everyone else, only the features aren't enabled by default. Heck, they're not enabled by default for most classes of Red Hat installs either. But people use them.

I'm not opposed to auditing, and I'm not opposed to more secure defaults. But most boxes sure seem to me to be hacked via holes that are known, that have been out for months, in services that aren't being used, and that haven't been patched. We speak to those systems first, since the low-hanging fruit is so extensive.

Jay: Yup. Further, Linux has room to surpass OpenBSD, in my opinion. Linux developers are doing more kernel-level security work, because of Linux's popularity as a standard. OpenBSD, as Jon points out, misses vulnerabilities, because their auditors are human and non-omniscient. Kernel-level security solutions, like Medusa DS9 or WireX's Immunix technology, are the only way to really stop the vulnerabilities that the audits miss. Linux can really rocket ahead here and I think the whole Bastille project will be eager to help.

In closing, please allow me to give some credit where it's due. You can read about this on the web pages: Bastille's and mine. Pete Watkins deserves serious praise for developing and sharing a great firewall. He's also helped take charge of Bastille 1.x enhancements. Sweth C. and Mike Rash have done great work in helping to build new modules and hack existing code. And Yoann V.'s ramping up the new architecture with me -- Bastille will be his baby too, soon. Bastille has benefited from a number of collaborators and sponsors, many of whom you'll find in future CREDITS files.

I've taken some time to read the Kevin J. Anderson/Brian Herbert written Dune: House Harkonnen, which is the second in the prequel series. Find out what I think about the potential blasphemy of Dune prequels *grin*.

Dune: House Harkonnen author Kevin J. Anderson & Brian Herbert pages 603 publisher Bantam Books, 2000 rating 6/10 reviewer Jeff "hemos" Bates ISBN 0553110721 summary Further explores the Galaxy of Dune, prior to the well known series

I've long been a confirmed Dune addict. One of my long lasting book passions has been collecting hardcover copies of each of the original series; when I found hardcover copies, then finding 1st edition hardcover copies. So, obviously when I found out that Brian Herbert, Frank's son, and well known science fiction author Kevin J. Anderson (most noted for his Star Wars series work) were going to be doing prequels to the series, I was quite anticipatory.

If you've read Dune: House Atreides, you can imagine my chagrin. OK, some people like it (I'm looking at you, Joseph Arruda), and I understand the reasons behind it. But that book was so abysmally horrid in terms of the one-dimensional characters that I figured Dune: House Harkonnen had to be better. After all, there was no where to go but up.

A tangent: I've never been a real fan of Kevin J. Anderson's work. In terms of the Star Wars series, Timothy Zahn pretty much defined that series, IMHO. So, to be upfront, Anderson is fighting an uphill battle with me.

The meat of the book is this: It explains where Feyd comes from, talks more about his parentage, and the relationships within the Harkonnen Family, which, surprise surprise, are pretty messy. But for those who are interested in the storyline and backdrop to the entire series, there's a lot of backgrond material on how the Atreides, Harkonnen and Corrinos interrelate.

But I'm a little puzzled about why the book is entitled House Harkonnen. Granted, we get the storyline about Feyd, how Rabban gets the name "Beast"...but that's about it in the Harkonnen end of things. The other plot lines are much more interesting.

The first is continuing the development of Pardot and Liet Kynes. You found out about Liet's background, growing up, and how he becomes the new Imperial Planetologist. You get some sense of his caring for Arrakis, as well as the the continuation from the prior book to the ecological project on Arrakis. Also on Dune, you found out more about the connections between the Fremen and the Bene Gesserit.

The Caladan/Arrakis has a number of points to it, some good and some so annoying it made me want to vomit. First bad one: Prince Vernius of Ix. Yes, I like the Ix portion of the storyline, and what the nasty Bene Tleilaxu are up to. But his character, and his sister annoyed me so much that I had a hard time getting through this section. Try counting how many times Vernius says "Vermilion Hells" between this book and the former. It's astonishing. Someone should teach the prince how to curse more. Seriously, though, those two characters are some of the weakest in the entire series. The relationship between the Princess and Leto is extremely predictable and stale. The only member of the whole family that I liked, the Earl Vernius has a plotline that extends basically the length of the book...for very little return.

One of the good parts of the Atredies portion is the meeting between Jessica and Leto - that's a good foundation. The other enjoyable part is Gurney Halleck - the storyline is not "enjoyable" but it's interesting.

So, overall, mixed review. If you are a Dune fanatic, like I am, you've probably already purchased it. If you aren't a fanatic, but are interested, I'd recommend reading the original series first. If you've read and liked it, this might be worth picking up - it's a quick read, and it's fun to head back to the Realm of the Padishah Emporer. But if you thought Dune was OK, but not great - DO NOT PICK THIS UP. If you are interested though, you can grab it from ThinkGeek.

I've taken some time to read the Kevin J. Anderson/Brian Herbert written Dune: House Harkonnen, which is the second in the prequel series. Find out what I think about the potential blasphemy of Dune prequels *grin*.

Dune: House Harkonnen author Kevin J. Anderson & Brian Herbert pages 603 publisher Bantam Books, 2000 rating 6/10 reviewer Jeff "hemos" Bates ISBN 0553110721 summary Further explores the Galaxy of Dune, prior to the well known series

I've long been a confirmed Dune addict. One of my long lasting book passions has been collecting hardcover copies of each of the original series; when I found hardcover copies, then finding 1st edition hardcover copies. So, obviously when I found out that Brian Herbert, Frank's son, and well known science fiction author Kevin J. Anderson (most noted for his Star Wars series work) were going to be doing prequels to the series, I was quite anticipatory.

If you've read Dune: House Atreides, you can imagine my chagrin. OK, some people like it (I'm looking at you, Joseph Arruda), and I understand the reasons behind it. But that book was so abysmally horrid in terms of the one-dimensional characters that I figured Dune: House Harkonnen had to be better. After all, there was no where to go but up.

A tangent: I've never been a real fan of Kevin J. Anderson's work. In terms of the Star Wars series, Timothy Zahn pretty much defined that series, IMHO. So, to be upfront, Anderson is fighting an uphill battle with me.

The meat of the book is this: It explains where Feyd comes from, talks more about his parentage, and the relationships within the Harkonnen Family, which, surprise surprise, are pretty messy. But for those who are interested in the storyline and backdrop to the entire series, there's a lot of backgrond material on how the Atreides, Harkonnen and Corrinos interrelate.

But I'm a little puzzled about why the book is entitled House Harkonnen. Granted, we get the storyline about Feyd, how Rabban gets the name "Beast"...but that's about it in the Harkonnen end of things. The other plot lines are much more interesting.

The first is continuing the development of Pardot and Liet Kynes. You found out about Liet's background, growing up, and how he becomes the new Imperial Planetologist. You get some sense of his caring for Arrakis, as well as the the continuation from the prior book to the ecological project on Arrakis. Also on Dune, you found out more about the connections between the Fremen and the Bene Gesserit.

The Caladan/Arrakis has a number of points to it, some good and some so annoying it made me want to vomit. First bad one: Prince Vernius of Ix. Yes, I like the Ix portion of the storyline, and what the nasty Bene Tleilaxu are up to. But his character, and his sister annoyed me so much that I had a hard time getting through this section. Try counting how many times Vernius says "Vermilion Hells" between this book and the former. It's astonishing. Someone should teach the prince how to curse more. Seriously, though, those two characters are some of the weakest in the entire series. The relationship between the Princess and Leto is extremely predictable and stale. The only member of the whole family that I liked, the Earl Vernius has a plotline that extends basically the length of the book...for very little return.

One of the good parts of the Atredies portion is the meeting between Jessica and Leto - that's a good foundation. The other enjoyable part is Gurney Halleck - the storyline is not "enjoyable" but it's interesting.

So, overall, mixed review. If you are a Dune fanatic, like I am, you've probably already purchased it. If you aren't a fanatic, but are interested, I'd recommend reading the original series first. If you've read and liked it, this might be worth picking up - it's a quick read, and it's fun to head back to the Realm of the Padishah Emporer. But if you thought Dune was OK, but not great - DO NOT PICK THIS UP. If you are interested though, you can grab it from ThinkGeek.

In a humorous departure from the normal question fare, B747SP asks: "In my office, we have a healthy disrespect for the comfort and safety of our colleagues, and the accompanying arms race is strong, and competitive. We've tried everything from hurling balls of paper back and forth, to stress balls, flying torpedoes, Nerf weaponry al-la thinkgeek.com, and even Air Soft guns (I did say no respect for safety!!!). OK, so that's my office. What about other Slashdotters? What ordnance do you use in your office to keep that sucker in the next cube on his toes? Do you build your weapons from stuff around the office, or do you buy from a store?"

Russell Pavlicek, Linux and Open Source evangelist, has written an impassioned little book that purports to explain to the non-geek world in particular why they should care about the Open Source movement and the success of OS systems like Linux and FreeBSD. Know what? He delivers.

Embracing Insanity: Open Source Software Development author Russell C. Pavlicek pages 177 publisher Sams Publishing rating 7/10 reviewer Jon Katz ISBN 0-672-31989-6 summary this books explains (to non-techs, esp) why Open Source is important.

There's a continuing avalache of technical/OS and other books and manuals, but very few that remind us why we should care about this stuff and, better yet, give us the tools, arguments and data to convince others.

"Embracing Insanity," by Russell C. Pavlicek (Linux Evangelist for Compaq's Professional Services organization, and 20-year computer industry veteran) is funny, smart and warm-hearted, something one could hardly expect from a book on the origins, meaning and history of the open source movement. Even though it's written by an OS veteran, it seems to be written mostly for the non-technical who need to come to terms with a movement that is both evolutionary and revolutionary.

Many of the people reading this will know some or all of the material in '"Embracing Insanity: Open Source Software Development."

This is a book to give your parents if they are wondering what you're doing up in your room all night, your teachers if they haven no clue as to why software has political, social and cultural implications, and perhaps as important, your boss, as he or she wonders why they need to understand open source and free software if they really want to do business in the 21st century.

It's not great literature, and doesn't purport to be. It is written with great heart, clarity and authority. "Embracing Insanity" is a history, a primer and a social biography. It explains what to do regarding OS, and what not to do, the sometimes bizarre nature and traditions of the OS culture.This is not a book that will confuse or scare off non-techies with language that isn't explained, or technical information taken for granted. Quite the contrary. It brings OS to life in a way that is completely accessible, explaining it's significance as a business and social model for many kinds of institutions, and its profoundly non-technological promise.

Pavlicek traces the growth of the OS and the free software movement, but he catches the weird (insane, perhaps) history and spirit of this particularly geek-driven phenomena. He sees OS as the liberation of the geek culture, for which he obviously has great feeling and empathy. One of his very neat ideas is that OS software development is "Essential Disruptive Technology," one of a hand of particular technologies that come out of nowhere to alter the direction of technical progress, change the rules, and catch all of the regular players off guard.

"...it is not so much that Open Source ventures onto technical ground that has never been explored before. But it does bring the rules and expectations from one area of technology (large computer systems) into another area (PC systems). And, most importantly, it does so in a way that defies the norms of the computer industry..." OS, he writes, is a new way of thinking about technology and computing, especially desktop computing.

"Embracing Insanity" is an proselytizing book (with a foreword by our own Robin "roblimo" Miller, Editor-In-Chief for the Open Source Development Network (formerly Andover.net). It's clear that Pavlickek has been trying to explain to people for years why anybody should care about OS, so he's written this book to make sure the argument continues and widens. "Embracing Insanity" is the view of a true believer about a movement that is widely misunderstood, and whose commercial and social significance is still lost on much of the non-geek world.

Pavlicek claims that OS explodes the myth of the anti-social geek. In a world where dread stereotypes of geeks pop up on the evening news nightly, nothing, he says, could be farther from the truth. Geeks are quite social, they just have a different set of priorities. The OS community, he says, uses a number of ways to sociall connect with each other, from basic Net tools like email and IRC, mailing lists and weblogs to the rapidly-proliferating OS news and discussion sites (like Linux Today). In the Linux community, bands of people come together all the time to talk about OS software and, in some cases, the free software movement.

Pavlicek covers some well-known OS history, but he also breaks some original ground, including when he talks about the moral values of OS beyond technology and software. One of the key values of OS and its community, he argues, is truth. "In a world where people are constantly exchanging ideas, evaluating concepts, and suggesting enhancements, it is vitally important that everyone speak the truth as he sees it. If someone fails to speak the truth, the process of creating software will be greatly impaired." The impact of anything less in the OS environment is devastating to the process of creating software. "If someone in charge of a piece of code willingly lies about how the code functions to other developers seeking to use that code, that person has caused great harm. Someone who lies to a development team could cost that team hundreds of even thousands of wasted hours of development. In that case, the liar has caused numerous individuals to waste precious hours of time chasing down a dead-end road."

There aren't too many media, social or political movements so dependent on truth or vulnerable to posturing, inaccuracies, hype and blatant falsehoods. Pavlicek explains why out this sometimes ill-tempered meticulousness is deeply rooted in geek culture, where mistakes have consequences, and where patience for fools and dissemblers is short. That could hardly be said of politics or media.

"Embracing Insanity" is an argument for OS, but Pavlicek bluntly spells out the business realities -- pro and con -- that underlie open source development. Is it good or bad for the bottom line, good or bad for the consumer, practical or not for everybody else? In addition to writing a primer of OS terms and names, he also dispels some myth and confusion. Lots of people don't know that Open Source isn't freeware, or that OS software isn't the same thing as public-domain software.

There aren't a lot of books coming out of the Open Source movement that you can hand to anyone with an interest in the future of technology -- that would cover a lot of people -- that so confidently captures the spirit, history and potential of one of the most interesting social and technological ideas in the world. OS may have started as a programming movement, but it has mushroomed well beyond that. Pavlicek grasps this big idea, even as many of his more technically-minded colleagues still resist it.

Geeks have had a hard time explaining the significance of OS to the world beyond. Now they don't have to. "Embracing Insanity" delivers on its promise to explain why society should care about this communal movement that seemed to come out of nowhere in response to the looming Microsoftization of the planet. It's almost a cliche in publishing to say a book is long overdue, but that's the perfect description here.

"Embracing Insanity" is the right gift for the people who have no idea what you're doing with your life, but may, for lots of important reasons, need or want to know.

Purchase this book at ThinkGeek.

Russell Pavlicek, Linux and Open Source evangelist, has written an impassioned little book that purports to explain to the non-geek world in particular why they should care about the Open Source movement and the success of OS systems like Linux and FreeBSD. Know what? He delivers.

Embracing Insanity: Open Source Software Development author Russell C. Pavlicek pages 177 publisher Sams Publishing rating 7/10 reviewer Jon Katz ISBN 0-672-31989-6 summary this books explains (to non-techs, esp) why Open Source is important.

There's a continuing avalache of technical/OS and other books and manuals, but very few that remind us why we should care about this stuff and, better yet, give us the tools, arguments and data to convince others.

"Embracing Insanity," by Russell C. Pavlicek (Linux Evangelist for Compaq's Professional Services organization, and 20-year computer industry veteran) is funny, smart and warm-hearted, something one could hardly expect from a book on the origins, meaning and history of the open source movement. Even though it's written by an OS veteran, it seems to be written mostly for the non-technical who need to come to terms with a movement that is both evolutionary and revolutionary.

Many of the people reading this will know some or all of the material in '"Embracing Insanity: Open Source Software Development."

This is a book to give your parents if they are wondering what you're doing up in your room all night, your teachers if they haven no clue as to why software has political, social and cultural implications, and perhaps as important, your boss, as he or she wonders why they need to understand open source and free software if they really want to do business in the 21st century.

It's not great literature, and doesn't purport to be. It is written with great heart, clarity and authority. "Embracing Insanity" is a history, a primer and a social biography. It explains what to do regarding OS, and what not to do, the sometimes bizarre nature and traditions of the OS culture.This is not a book that will confuse or scare off non-techies with language that isn't explained, or technical information taken for granted. Quite the contrary. It brings OS to life in a way that is completely accessible, explaining it's significance as a business and social model for many kinds of institutions, and its profoundly non-technological promise.

Pavlicek traces the growth of the OS and the free software movement, but he catches the weird (insane, perhaps) history and spirit of this particularly geek-driven phenomena. He sees OS as the liberation of the geek culture, for which he obviously has great feeling and empathy. One of his very neat ideas is that OS software development is "Essential Disruptive Technology," one of a hand of particular technologies that come out of nowhere to alter the direction of technical progress, change the rules, and catch all of the regular players off guard.

"...it is not so much that Open Source ventures onto technical ground that has never been explored before. But it does bring the rules and expectations from one area of technology (large computer systems) into another area (PC systems). And, most importantly, it does so in a way that defies the norms of the computer industry..." OS, he writes, is a new way of thinking about technology and computing, especially desktop computing.

"Embracing Insanity" is an proselytizing book (with a foreword by our own Robin "roblimo" Miller, Editor-In-Chief for the Open Source Development Network (formerly Andover.net). It's clear that Pavlickek has been trying to explain to people for years why anybody should care about OS, so he's written this book to make sure the argument continues and widens. "Embracing Insanity" is the view of a true believer about a movement that is widely misunderstood, and whose commercial and social significance is still lost on much of the non-geek world.

Pavlicek claims that OS explodes the myth of the anti-social geek. In a world where dread stereotypes of geeks pop up on the evening news nightly, nothing, he says, could be farther from the truth. Geeks are quite social, they just have a different set of priorities. The OS community, he says, uses a number of ways to sociall connect with each other, from basic Net tools like email and IRC, mailing lists and weblogs to the rapidly-proliferating OS news and discussion sites (like Linux Today). In the Linux community, bands of people come together all the time to talk about OS software and, in some cases, the free software movement.

Pavlicek covers some well-known OS history, but he also breaks some original ground, including when he talks about the moral values of OS beyond technology and software. One of the key values of OS and its community, he argues, is truth. "In a world where people are constantly exchanging ideas, evaluating concepts, and suggesting enhancements, it is vitally important that everyone speak the truth as he sees it. If someone fails to speak the truth, the process of creating software will be greatly impaired." The impact of anything less in the OS environment is devastating to the process of creating software. "If someone in charge of a piece of code willingly lies about how the code functions to other developers seeking to use that code, that person has caused great harm. Someone who lies to a development team could cost that team hundreds of even thousands of wasted hours of development. In that case, the liar has caused numerous individuals to waste precious hours of time chasing down a dead-end road."

There aren't too many media, social or political movements so dependent on truth or vulnerable to posturing, inaccuracies, hype and blatant falsehoods. Pavlicek explains why out this sometimes ill-tempered meticulousness is deeply rooted in geek culture, where mistakes have consequences, and where patience for fools and dissemblers is short. That could hardly be said of politics or media.

"Embracing Insanity" is an argument for OS, but Pavlicek bluntly spells out the business realities -- pro and con -- that underlie open source development. Is it good or bad for the bottom line, good or bad for the consumer, practical or not for everybody else? In addition to writing a primer of OS terms and names, he also dispels some myth and confusion. Lots of people don't know that Open Source isn't freeware, or that OS software isn't the same thing as public-domain software.

There aren't a lot of books coming out of the Open Source movement that you can hand to anyone with an interest in the future of technology -- that would cover a lot of people -- that so confidently captures the spirit, history and potential of one of the most interesting social and technological ideas in the world. OS may have started as a programming movement, but it has mushroomed well beyond that. Pavlicek grasps this big idea, even as many of his more technically-minded colleagues still resist it.

Geeks have had a hard time explaining the significance of OS to the world beyond. Now they don't have to. "Embracing Insanity" delivers on its promise to explain why society should care about this communal movement that seemed to come out of nowhere in response to the looming Microsoftization of the planet. It's almost a cliche in publishing to say a book is long overdue, but that's the perfect description here.

"Embracing Insanity" is the right gift for the people who have no idea what you're doing with your life, but may, for lots of important reasons, need or want to know.

Purchase this book at ThinkGeek.

Not every nerd career takes place entirely behind a flickering CRT. Ellen Knowlton Wilson takes a peek here at a book which exposes one of the hotter fields for those with a nose for sulfur, feet like leather, and a penchant for scientific danger: studying volcanos.

Volcano Cowboys: The Rocky Evolution of a Dangerous Science author Dick Thompson pages 326 publisher Thomas Dunne Books, St. Martin's Press rating 6.5 reviewer Ellen Knowlton Wilson ISBN 0-312-20881-2 summary A story about the evolution of a scientific goal, the prediction of explosive volcanic eruptions

Volcano Cowboys: The Rocky Evolution of a Dangerous Science begins a year before the 1980 eruption of Washington's Mount St. Helens volcano, and attempts to chronicle major developments in the field of eruption prediction over the next decade. This is done in an engaging manner, aimed toward the general reader. Thompson's many years of experience as a science writer for Time prepared him well for the writing of his first book. In the introduction he writes, "This is a book about how science operates. It is the story of how one scientific goal, the prediction of explosive eruptions, evolved during its most intense and productive periods, from the eruptions of Mount St. Helen to the cataclysm of Mount Pinatubo."

The book is divided into three parts. The first part covers the most well-known eruption of recent times in the U.S. -- the May 18, 1980, eruption of Mount St. Helens. The second portion covers the almost ten years from Mount St. Helens' main event to the explosive eruptions of Mount Pinatubo in the Phillipines, and the final part covers the response to activity at Mount Pinatubo in 1991.

The May 18, 1980 eruption of Mount St. Helens did not catch volcanologists entirely by surprise. In 1978, two geologists working for the United States Geological Survey, Dwight "Rocky" Crandall and Donal Mullineaux, published a report calling St. Helens "an especially dangerous volcano." After an initial flurry of panic by Washington state residents, not much was done to prepare for an eruption.

On March 20, 1980, a magnitude 4.2 earthquake was detected near Mount St. Helens. Originally, the scientists at the University of Washington who ran the seismic network felt the quake was associated with Mt. Hood, a volcano to the south of St. Helens. Arrival times were punched onto cards and run through the computer, revealing a surprise -- the event had originated directly under Mount St. Helens. The next day, UW scientists installed several seismographs on the restless volcano, which had previously been unmonitored. On Monday, March 24, Steve Malone, a seismologist at UW, contacted the U.S. Geological Survey in Denver.

Soon scientists from various branches of the USGS began to arrive in Washington to help monitor the eruption, but there was little precedent or organization, and tensions quickly rose. Thompson covers the details of the difficulties of coordinating a response to an eruption in a populated area with multiple agencies holding jurisdiction.

In part two of the book, Thompson covers developments in volcanology and eruption prediction between the May 18 Mount St. Helens eruption and the buildup of activity at Mount Pinatubo in the Phillipines. This section of the book is short, but important, since part three, which covers the response to the 1991 eruption of Pinatubo, is largly presented in contrast to the 1980 St. Helens response and thus relies on both preceding sections.

Part three, the response to the 1991 Pinatubo eruption, focuses on the team of "trained decision makers" that had evolved from events of the past. Many scientists involved in the 1980 St. Helens response were also involved in the 1991 Pinatubo response. Advances in technology were essential to the Pinatubo response as well. Some of Thompson's finest writing is in the final section of the book, where he allows more of the personal character of some scientists to shine through (and what volcanologists lack in common sense they often make up for in character.)

Overall, the book is an enjoyable one. I found a few small flaws -- a few sentences that must have slipped past a tired editor, a few incorrect details that I spotted only because I've worked with some of the people mentioned in the book. Having spent entirely too much time in my academic career thinking about volcanoes, particularly Mount St. Helens and Pinatubo, I am probably biased by my background into rating it slightly lower than it deserves.

There is plenty within its pages to fascinate all sorts of geeks. Aside from the obvious appeal of explosions and hot molten magma, there is some discussion of the hardware requirements for volcano monitoring -- can your Linux box withstand a pyroclastic flow? What sort of monitoring software can be designed to run on the only computer in a small Central American town on the flanks of a volcano? Food for thought ...

Table of Contents

Introduction
Part I: Mount St. Helens, 1980
1. Hoblitt's Floating Island, Summer 1979
2. Disbelief
3. The Musketeers
4. The Bulge
Field Notes: May 17, 1980/Mindy Brugman
5. Swanson
Field Notes: May 18, 1980/The St. Helens Observers
Part II: The Learning Season, 1980-1989
Field Notes: August 1980/The FPP Experiment
6. The Volcano Lab: St. Helens After the Blast
7. Mammoth Lakes: Between a Rock and a Hard Place
8. The Volcano Zoo
9. After Armero
Field Notes: December 15, 1989/Redoubt, Alaska
Part III: Mount Pinatubo, 1991
10. Trained Decision Makers
11. They'll Think You're a Hero
12. Eruption
Field Notes: August 1991/Bezymianny
Notes
Glossary
Acknowledgements
Index

Purchase this book at ThinkGeek. And if you enjoyed this review, check out Ellen Knowlton Wilson's page.

Not every nerd career takes place entirely behind a flickering CRT. Ellen Knowlton Wilson takes a peek here at a book which exposes one of the hotter fields for those with a nose for sulfur, feet like leather, and a penchant for scientific danger: studying volcanos.

Volcano Cowboys: The Rocky Evolution of a Dangerous Science author Dick Thompson pages 326 publisher Thomas Dunne Books, St. Martin's Press rating 6.5 reviewer Ellen Knowlton Wilson ISBN 0-312-20881-2 summary A story about the evolution of a scientific goal, the prediction of explosive volcanic eruptions

Volcano Cowboys: The Rocky Evolution of a Dangerous Science begins a year before the 1980 eruption of Washington's Mount St. Helens volcano, and attempts to chronicle major developments in the field of eruption prediction over the next decade. This is done in an engaging manner, aimed toward the general reader. Thompson's many years of experience as a science writer for Time prepared him well for the writing of his first book. In the introduction he writes, "This is a book about how science operates. It is the story of how one scientific goal, the prediction of explosive eruptions, evolved during its most intense and productive periods, from the eruptions of Mount St. Helen to the cataclysm of Mount Pinatubo."

The book is divided into three parts. The first part covers the most well-known eruption of recent times in the U.S. -- the May 18, 1980, eruption of Mount St. Helens. The second portion covers the almost ten years from Mount St. Helens' main event to the explosive eruptions of Mount Pinatubo in the Phillipines, and the final part covers the response to activity at Mount Pinatubo in 1991.

The May 18, 1980 eruption of Mount St. Helens did not catch volcanologists entirely by surprise. In 1978, two geologists working for the United States Geological Survey, Dwight "Rocky" Crandall and Donal Mullineaux, published a report calling St. Helens "an especially dangerous volcano." After an initial flurry of panic by Washington state residents, not much was done to prepare for an eruption.

On March 20, 1980, a magnitude 4.2 earthquake was detected near Mount St. Helens. Originally, the scientists at the University of Washington who ran the seismic network felt the quake was associated with Mt. Hood, a volcano to the south of St. Helens. Arrival times were punched onto cards and run through the computer, revealing a surprise -- the event had originated directly under Mount St. Helens. The next day, UW scientists installed several seismographs on the restless volcano, which had previously been unmonitored. On Monday, March 24, Steve Malone, a seismologist at UW, contacted the U.S. Geological Survey in Denver.

Soon scientists from various branches of the USGS began to arrive in Washington to help monitor the eruption, but there was little precedent or organization, and tensions quickly rose. Thompson covers the details of the difficulties of coordinating a response to an eruption in a populated area with multiple agencies holding jurisdiction.

In part two of the book, Thompson covers developments in volcanology and eruption prediction between the May 18 Mount St. Helens eruption and the buildup of activity at Mount Pinatubo in the Phillipines. This section of the book is short, but important, since part three, which covers the response to the 1991 eruption of Pinatubo, is largly presented in contrast to the 1980 St. Helens response and thus relies on both preceding sections.

Part three, the response to the 1991 Pinatubo eruption, focuses on the team of "trained decision makers" that had evolved from events of the past. Many scientists involved in the 1980 St. Helens response were also involved in the 1991 Pinatubo response. Advances in technology were essential to the Pinatubo response as well. Some of Thompson's finest writing is in the final section of the book, where he allows more of the personal character of some scientists to shine through (and what volcanologists lack in common sense they often make up for in character.)

Overall, the book is an enjoyable one. I found a few small flaws -- a few sentences that must have slipped past a tired editor, a few incorrect details that I spotted only because I've worked with some of the people mentioned in the book. Having spent entirely too much time in my academic career thinking about volcanoes, particularly Mount St. Helens and Pinatubo, I am probably biased by my background into rating it slightly lower than it deserves.

There is plenty within its pages to fascinate all sorts of geeks. Aside from the obvious appeal of explosions and hot molten magma, there is some discussion of the hardware requirements for volcano monitoring -- can your Linux box withstand a pyroclastic flow? What sort of monitoring software can be designed to run on the only computer in a small Central American town on the flanks of a volcano? Food for thought ...

Table of Contents

Introduction
Part I: Mount St. Helens, 1980
1. Hoblitt's Floating Island, Summer 1979
2. Disbelief
3. The Musketeers
4. The Bulge
Field Notes: May 17, 1980/Mindy Brugman
5. Swanson
Field Notes: May 18, 1980/The St. Helens Observers
Part II: The Learning Season, 1980-1989
Field Notes: August 1980/The FPP Experiment
6. The Volcano Lab: St. Helens After the Blast
7. Mammoth Lakes: Between a Rock and a Hard Place
8. The Volcano Zoo
9. After Armero
Field Notes: December 15, 1989/Redoubt, Alaska
Part III: Mount Pinatubo, 1991
10. Trained Decision Makers
11. They'll Think You're a Hero
12. Eruption
Field Notes: August 1991/Bezymianny
Notes
Glossary
Acknowledgements
Index

Purchase this book at ThinkGeek. And if you enjoyed this review, check out Ellen Knowlton Wilson's page.

Mike Knell contributed this review of what is perhaps the most definitive collection of Unix practice and wisdom. It's even been newly updated to reflect the widespread influence of the other*NIXes. In fact, just look at the names of those who contributed forwards to this edition, and you'll see how it ties together the old and new continents of the Unix world.

UNIX System Administration Handbook author Evi Nemeth, Garth Snyder, Scott Seebass, Trent R. Hein, et al. pages 850 publisher Prentice Hall rating 9/10 reviewer Mike Knell ISBN 0130206016 summary The updated third edition of one of the Holy Books Of UNIX.

Introduction

There are a few books which most sysadmins will mention in hushed tones when discussing reading material, and one of those is the famous "Red Book", the second edition of this book (the new edition's purple). I'd heard good things about it ever since people actually started paying me to do systems admin rather than just mucking about with computers for fun, so when the new third edition came along, I was keen to take a look at it.

The book aims to cover the basics in a wide range of areas that good UNIX admins need to know about. The contents range right through from booting the system and adding disks to dealing with users and the inevitable people-politics that help make the job so . . . varied and exciting. While the second edition covered six commercial versions of UNIX, the new edition has simplified this and now covers two commercial UNIX systems (Solaris 2.7 and HP/UX 11.00) and two free operating systems (Red Hat Linux 6.2 and FreeBSD 3.4), which accurately reflects the changes in the UNIX world since 1995. The last edition also came with a CD full of useful tools, but there's no such companion to the new edition -- near-universal Internet access for sysadmins has made such things far less useful than they used to be.

What's Bad?

The big shock upon getting hold of a copy of this book is the price tag. Here in Ireland, it's going for about IR£68 in shops, and the U.S. list price is $68. This is a lot to pay for a book, and to my mind it's quite likely to put off a number of potential readers. I can understand the price tag -- with four principal authors and 850 pages of dense information it's bound to be costly, but it's a shame that it had to be quite so expensive. Online it's available for about US$55, but that's still not cheap.

It should also be made clear right from the start that this is not a book for newcomers to UNIX. Don't look here if you're wondering how to list files or send mail -- there are plenty of books out there already that cover those areas more than adequately. The book assumes that the reader is already familiar with UNIX from a user's point of view.

What's Good?

When you get down to actually reading the book, though, it's immediately apparent that the authors really know their stuff. It's a book written from the perspective of people who know what it's like to be a sysadmin in the trenches. They have opinions that are obviously derived from painful experience, and aren't nervous about sharing them when the need arises -- if they think something sucks, they make damn sure you know about it. The information density is remarkably high for such a fat book, and the writing has a light touch which makes it extremely readable both as a desk reference and as bedtime reading. The advice given is sensible and solid, and I found myself nodding in agreement with the authors at some points, while feeling somewhat chastised and guilty at other points for not having done some of the things suggested. The humour helps to keep the book readable rather than getting in the way as it could easily have done.

As with all good computer books, there are cartoons (drawn crudely but funnily by Tyler Curtain) scattered through the book. My favourite is on the subject of "Co-operating With Windows." It involves, well, brides, rednecks and shotguns, something with which anyone who's ever gone through the pain of trying to make Windows machines play nicely in a UNIX environment will identify.

Things that only need a short chapter to cover the essentials (Web serving, for instance) aren't bogged down with extraneous detail, while the areas that always inspire fear among sysadmins (print services, DNS, mail ... ) are covered in all the necessary depth. Each chapter ends with a section of pointers to further information for those needing to know more than is covered in the book. The information is of high quality and feels very reliable, making it a good guidebook for those trying to find their way through the world of confusion, vendor-specific idiosyncrasies and divided loyalties that is UNIX administration.

So What's In It For Me?

If you're just interested in the basics of how to keep your Linux system running smoothly, you'd probably be better served by O'Reilly's "Running Linux" or any of the myriad similiar works out there. On the other hand, if you're starting out in system administration, or if you're an experienced sysadmin with anything less than universal guru status, this is a splendid book. The price is high, but if you're really serious about your work it's definitely money well spent -- think of it as an investment in your career.

Besides, with forewords from Linus Torvalds, Eric Allman, Marshall Kirk McKusick and Dennis Ritchie, who am I to argue? The only reason I've given it nine instead of ten out of ten is the price. To summarise -- I wish I'd read this book five years ago.

Table of Contents

1. Where To Start
2. Booting And Shutting Down
3. Rootly Powers
4. Controlling Processes
5. The Filesystem
6. Adding New Users
7. Serial Devices
8. Adding A Disk
9. Periodic Processes
10. Backups
11. Syslog And Log Files
12. Drivers And The Kernel
13. TCP/IP Networking
14. Routing
15. Network Hardware
16. The Domain Name System
17. The Network File System
18. Sharing System Files
19. Electronic Mail
20. Networking Management And Debugging
21. Security
22. Web Hosting And Internet Servers
23. Printing
24. Maintenance And Environment
25. Performance Analysis
26. Cooperating With Windows
27. Policy And Politics
28. Daemons
29. Colophon
30. Index

Purchase this book at ThinkGeek.

Mike Knell contributed this review of what is perhaps the most definitive collection of Unix practice and wisdom. It's even been newly updated to reflect the widespread influence of the other*NIXes. In fact, just look at the names of those who contributed forwards to this edition, and you'll see how it ties together the old and new continents of the Unix world.

UNIX System Administration Handbook author Evi Nemeth, Garth Snyder, Scott Seebass, Trent R. Hein, et al. pages 850 publisher Prentice Hall rating 9/10 reviewer Mike Knell ISBN 0130206016 summary The updated third edition of one of the Holy Books Of UNIX.

Introduction

There are a few books which most sysadmins will mention in hushed tones when discussing reading material, and one of those is the famous "Red Book", the second edition of this book (the new edition's purple). I'd heard good things about it ever since people actually started paying me to do systems admin rather than just mucking about with computers for fun, so when the new third edition came along, I was keen to take a look at it.

The book aims to cover the basics in a wide range of areas that good UNIX admins need to know about. The contents range right through from booting the system and adding disks to dealing with users and the inevitable people-politics that help make the job so . . . varied and exciting. While the second edition covered six commercial versions of UNIX, the new edition has simplified this and now covers two commercial UNIX systems (Solaris 2.7 and HP/UX 11.00) and two free operating systems (Red Hat Linux 6.2 and FreeBSD 3.4), which accurately reflects the changes in the UNIX world since 1995. The last edition also came with a CD full of useful tools, but there's no such companion to the new edition -- near-universal Internet access for sysadmins has made such things far less useful than they used to be.

What's Bad?

The big shock upon getting hold of a copy of this book is the price tag. Here in Ireland, it's going for about IR£68 in shops, and the U.S. list price is $68. This is a lot to pay for a book, and to my mind it's quite likely to put off a number of potential readers. I can understand the price tag -- with four principal authors and 850 pages of dense information it's bound to be costly, but it's a shame that it had to be quite so expensive. Online it's available for about US$55, but that's still not cheap.

It should also be made clear right from the start that this is not a book for newcomers to UNIX. Don't look here if you're wondering how to list files or send mail -- there are plenty of books out there already that cover those areas more than adequately. The book assumes that the reader is already familiar with UNIX from a user's point of view.

What's Good?

When you get down to actually reading the book, though, it's immediately apparent that the authors really know their stuff. It's a book written from the perspective of people who know what it's like to be a sysadmin in the trenches. They have opinions that are obviously derived from painful experience, and aren't nervous about sharing them when the need arises -- if they think something sucks, they make damn sure you know about it. The information density is remarkably high for such a fat book, and the writing has a light touch which makes it extremely readable both as a desk reference and as bedtime reading. The advice given is sensible and solid, and I found myself nodding in agreement with the authors at some points, while feeling somewhat chastised and guilty at other points for not having done some of the things suggested. The humour helps to keep the book readable rather than getting in the way as it could easily have done.

As with all good computer books, there are cartoons (drawn crudely but funnily by Tyler Curtain) scattered through the book. My favourite is on the subject of "Co-operating With Windows." It involves, well, brides, rednecks and shotguns, something with which anyone who's ever gone through the pain of trying to make Windows machines play nicely in a UNIX environment will identify.

Things that only need a short chapter to cover the essentials (Web serving, for instance) aren't bogged down with extraneous detail, while the areas that always inspire fear among sysadmins (print services, DNS, mail ... ) are covered in all the necessary depth. Each chapter ends with a section of pointers to further information for those needing to know more than is covered in the book. The information is of high quality and feels very reliable, making it a good guidebook for those trying to find their way through the world of confusion, vendor-specific idiosyncrasies and divided loyalties that is UNIX administration.

So What's In It For Me?

If you're just interested in the basics of how to keep your Linux system running smoothly, you'd probably be better served by O'Reilly's "Running Linux" or any of the myriad similiar works out there. On the other hand, if you're starting out in system administration, or if you're an experienced sysadmin with anything less than universal guru status, this is a splendid book. The price is high, but if you're really serious about your work it's definitely money well spent -- think of it as an investment in your career.

Besides, with forewords from Linus Torvalds, Eric Allman, Marshall Kirk McKusick and Dennis Ritchie, who am I to argue? The only reason I've given it nine instead of ten out of ten is the price. To summarise -- I wish I'd read this book five years ago.

Table of Contents

1. Where To Start
2. Booting And Shutting Down
3. Rootly Powers
4. Controlling Processes
5. The Filesystem
6. Adding New Users
7. Serial Devices
8. Adding A Disk
9. Periodic Processes
10. Backups
11. Syslog And Log Files
12. Drivers And The Kernel
13. TCP/IP Networking
14. Routing
15. Network Hardware
16. The Domain Name System
17. The Network File System
18. Sharing System Files
19. Electronic Mail
20. Networking Management And Debugging
21. Security
22. Web Hosting And Internet Servers
23. Printing
24. Maintenance And Environment
25. Performance Analysis
26. Cooperating With Windows
27. Policy And Politics
28. Daemons
29. Colophon
30. Index

Purchase this book at ThinkGeek.

A technical book with personality? Chromatic claims just that in his review of Linux Graphics Programming with SVGAlib. If you're a graphics guru, or are looking for a book that describes a lot of the low level functions that put pretty pictures on your screen, this one sounds like one you should at least consider.

Linux Graphics Programming with SVGAlib author Jay Link pages 513 publisher Coriolis Open Press rating 7.5 reviewer chromatic ISBN 1-57610-524-5 summary A tour of the SVGAlib library, designed to help you create new Linux applications or port existing applications to Linux.

The Scoop XFree86 isn't the be-all end-all of Linux graphics. Consider the embedded space, or dedicated turnkey apps, or console games, or... Jay Link introduces readers to SVGAlib in a flawed, but entertaining and useful tutorial. (If you've never heard of SVGAlib, it's a Linux-specific graphics library providing fast functions for full-screen use, joystick and keyboard input, and even 3D. It's undergone development and refinement for a few years, and it's easy to use but still powerful.) What's to Like? More than a listing of SVGAlib functions and their uses, the author covers a wide scope of graphics topics. They're all explored in the context of SVGAlib, but the basic principles apply to other libraries. Monitors display information the same way, polygons and primitives have the same algorithms, and something has to save the background before you draw something over top of it. The first three chapters cover libraries, competing tools, graphics modes, hardware fundamentals, and the primitive primitives. It's a good introduction to graphics in general.

Starting simply, SVGAlib functions obviously build on each other. For the most part, so do the chapters. Once you've mastered setting pixels and drawing lines, it's time to draw circles and arcs or fill in your shapes. You'll want fonts after that, and then animation. Basically, this is a book you can read straight through with little trouble. Link travels a lot of ground -- input devices, 3D development, raytracing, animation, and user interfaces. Appendices B and C list and describe the vga and vgagl functions of SVGAlib. Though usually short, the descriptions have information enough to be useful to a casual programmer, often listing caveats and gotchas.

The most enjoyable part of the book, though, is the author's enthusiasm. It's obvious he had great fun in writing the book, and that shines through his prose. It's infectious -- he's found something cool and wants to share that with the world. There's room to grow, too. The last two code chapters build a simple paint utility and discuss ways it could be improved. If you've done your homework up 'til that point, you should be able to complete it and add more whizbang features at will.

What's to Consider? The author's pretty casual. It's refreshing to read a technical book with personality. If you're a big X fan, though, or a closet Microsoft sympathizer, you might disagree with Link's rhetoric in a couple of spots. Of course, those aren't the people likely to pick up the book, leaving the rest of us free to chuckle along with the personable prose.

Two things might put you off if you're considering the purchase. First, it's not precisely a tutorial. Some chapters have pages of source code with little actual commentary. If your C-reading skills are low, be prepared to do a lot of homework to figure out what's going on. Second, there's also not a lot of explanation of the math involved. In places (geometric shapes, advanced primitive drawing, ray tracing) either dig up those old trigonometry notes or a battered copy of Michael Abrash's Zen of Graphics Programming (recommended in the text). This isn't an exploration of specific graphics theory as much as an exploration of the library.

The only thing I really disliked was the book's formatting. As is usual with techie books, warnings and notes are interspersed throughout the text. In a few spots, there also are glossary-like definitions mingled with notes, text, and figures in a hard-to-read mess of words, lines, and icons. More consistency would improve the readibility. Having additional explanations would have helped, but most of the code is clear enough that the a-ha factor comes into play. (Moderately experienced programmers can read the accompanying code and description and things will click the first or second time through). The overall tone says, "Here are the tools, now go explore and play and have fun."

The Summary Somewhat experienced programmers with a decent math background will get the most out of this book. It's an entertaining look at a library I'd overlooked for quite some time. For a good introduction to SVGAlib (and a healthy dose of fun programming), check it out. Table of Contents

1. Getting Started
2. Graphics Basics
3. First Programs
4. Complex Shapes, Formulas, And Functions
5. Color
6. Shades, Fills, And Patterns
7. Fonts
8. Fractals
9. Graphic Files
10. Basic Animation
11. Polygons
12. 3D Images
13. Raytracing And Photorealism
14. Game Basics
15. Using The Mouse And Joystick
16. Landscapes
17. A Look At Existing SVGAlib Applications
18. Simple Paint Program
19. Thoughts On A GUI
20. Video Card Drivers

1. GNU General Public License
2. Libvga Functions
3. Libvgagl Functions
4. ASCII Character Codes
5. Chipsets Supported By SVGAlib
6. A Brief History of SVGAlib
7. FAQs And Troubleshooting

Purchase this book at ThinkGeek.

A technical book with personality? Chromatic claims just that in his review of Linux Graphics Programming with SVGAlib. If you're a graphics guru, or are looking for a book that describes a lot of the low level functions that put pretty pictures on your screen, this one sounds like one you should at least consider.

Linux Graphics Programming with SVGAlib author Jay Link pages 513 publisher Coriolis Open Press rating 7.5 reviewer chromatic ISBN 1-57610-524-5 summary A tour of the SVGAlib library, designed to help you create new Linux applications or port existing applications to Linux.

The Scoop XFree86 isn't the be-all end-all of Linux graphics. Consider the embedded space, or dedicated turnkey apps, or console games, or... Jay Link introduces readers to SVGAlib in a flawed, but entertaining and useful tutorial. (If you've never heard of SVGAlib, it's a Linux-specific graphics library providing fast functions for full-screen use, joystick and keyboard input, and even 3D. It's undergone development and refinement for a few years, and it's easy to use but still powerful.) What's to Like? More than a listing of SVGAlib functions and their uses, the author covers a wide scope of graphics topics. They're all explored in the context of SVGAlib, but the basic principles apply to other libraries. Monitors display information the same way, polygons and primitives have the same algorithms, and something has to save the background before you draw something over top of it. The first three chapters cover libraries, competing tools, graphics modes, hardware fundamentals, and the primitive primitives. It's a good introduction to graphics in general.

Starting simply, SVGAlib functions obviously build on each other. For the most part, so do the chapters. Once you've mastered setting pixels and drawing lines, it's time to draw circles and arcs or fill in your shapes. You'll want fonts after that, and then animation. Basically, this is a book you can read straight through with little trouble. Link travels a lot of ground -- input devices, 3D development, raytracing, animation, and user interfaces. Appendices B and C list and describe the vga and vgagl functions of SVGAlib. Though usually short, the descriptions have information enough to be useful to a casual programmer, often listing caveats and gotchas.

The most enjoyable part of the book, though, is the author's enthusiasm. It's obvious he had great fun in writing the book, and that shines through his prose. It's infectious -- he's found something cool and wants to share that with the world. There's room to grow, too. The last two code chapters build a simple paint utility and discuss ways it could be improved. If you've done your homework up 'til that point, you should be able to complete it and add more whizbang features at will.

What's to Consider? The author's pretty casual. It's refreshing to read a technical book with personality. If you're a big X fan, though, or a closet Microsoft sympathizer, you might disagree with Link's rhetoric in a couple of spots. Of course, those aren't the people likely to pick up the book, leaving the rest of us free to chuckle along with the personable prose.

Two things might put you off if you're considering the purchase. First, it's not precisely a tutorial. Some chapters have pages of source code with little actual commentary. If your C-reading skills are low, be prepared to do a lot of homework to figure out what's going on. Second, there's also not a lot of explanation of the math involved. In places (geometric shapes, advanced primitive drawing, ray tracing) either dig up those old trigonometry notes or a battered copy of Michael Abrash's Zen of Graphics Programming (recommended in the text). This isn't an exploration of specific graphics theory as much as an exploration of the library.

The only thing I really disliked was the book's formatting. As is usual with techie books, warnings and notes are interspersed throughout the text. In a few spots, there also are glossary-like definitions mingled with notes, text, and figures in a hard-to-read mess of words, lines, and icons. More consistency would improve the readibility. Having additional explanations would have helped, but most of the code is clear enough that the a-ha factor comes into play. (Moderately experienced programmers can read the accompanying code and description and things will click the first or second time through). The overall tone says, "Here are the tools, now go explore and play and have fun."

The Summary Somewhat experienced programmers with a decent math background will get the most out of this book. It's an entertaining look at a library I'd overlooked for quite some time. For a good introduction to SVGAlib (and a healthy dose of fun programming), check it out. Table of Contents

1. Getting Started
2. Graphics Basics
3. First Programs
4. Complex Shapes, Formulas, And Functions
5. Color
6. Shades, Fills, And Patterns
7. Fonts
8. Fractals
9. Graphic Files
10. Basic Animation
11. Polygons
12. 3D Images
13. Raytracing And Photorealism
14. Game Basics
15. Using The Mouse And Joystick
16. Landscapes
17. A Look At Existing SVGAlib Applications
18. Simple Paint Program
19. Thoughts On A GUI
20. Video Card Drivers

1. GNU General Public License
2. Libvga Functions
3. Libvgagl Functions
4. ASCII Character Codes
5. Chipsets Supported By SVGAlib
6. A Brief History of SVGAlib
7. FAQs And Troubleshooting

Purchase this book at ThinkGeek.

The wide-ranging, erudite Duncan Lawie goes where few Slashdot reviewers have gone before, exploring books on the fringes of Science Fiction and wacky speculation in the interest of expanding your mind and his own. This time, he reports on Stanislaw Lem's classic work Solaris, first printed in English 30 years ago, and in Russian nearly 40. Read more to find out if it sounds like your kind of page-turner.

Solaris author Stanislaw Lem pages ~200 publisher Harcourt Brace (USA) rating 7.5 reviewer Duncan Lawie ISBN 0156837501b summary Deeply thoughtful, vastly different science fiction from beyond the English language.

The height of Stanislaw Lem's science fiction production was in the 1950s and 1960s though he has continued to produce lucid, powerful work since. Writing in Eastern Europe (in Polish), his influences were vastly different from those of Commonwealth and American authors of the same period. Access to his work in English first came years after it was written, some of them via another language. This has resulted in a delayed effect as his influence on the science fiction of the West fed in over the course of a generation. Despite - or perhaps because of - this, Lem is one of the most important science fiction authors of the twentieth century writing outside the English language and his works, including over a dozen novels and several short story collections, have been published in over 30 languages.

Solaris is one of Lem's early works of mature science fiction, differing significantly in focus from the Russian film based upon it and perhaps totally unrelated to Sun Microsystems' Unix. It tells of an episode in the continuing quest by humanity to understand an alien planet. This planet orbits two stars and yet maintains a regular path. It is a ocean-world and science believes that it is the action of this mass - which is not water -- which controls the planet's motion. The planet, which itself is called Solaris, has been studied by science for generations and a large part of the book is concerned with a form of literature review, telling the history of the highs and lows in that research and relating dozens of theories generated through the decades. The style is such that the book manages to relay all this scientific opinion without indicating any genuine support for any particular theory, though most observers seem to accept, to varying degrees, the idea that the ocean may be "alive."

The narrator, Kelvin, is a Solarist by training and has come from Earth to obtain his own first hand experience of the planet. In this period of declining research, he arrives at the research station to find it in disarray; the station leader dead and the other occupants utterly preoccupied with matters they will not explain and which Kelvin cannot understand. The development of Kelvin's character is central to the book. His history is related in tandem with that of Solarist research as he attempts to come to terms with himself and with events on the station. Kelvin is the rational man of science, attempting to understand the apparently incomprehensible. His story recapitulates the scientific journey to the heart of incomprehension as he attempts to handle the impossibly real experiences the planet seems to be imposing on him. Beyond this bulk of complexity, there is a clear perspective on Kelvin's position in the final pages which shows how far this ghostly story has come, and how far our species has yet to travel.

Given the origin of its author, and the vintage of the novel, it is hardly surprising that Solaris is so far removed from the American tradition of science fiction. The mood of the book is passive and thoughtful, building a paranoiac atmosphere through understatement and calm description. The alien environment of the planet is described in the language of science and yet manages to remain largely incomprehensible. The book appears to avoid any kind of extreme; no event so great as triumph or disaster is ever described as such. This approach can make it difficult to care about the characters but it sustains the quiet, brave despair at the heart of the novel. Perhaps in this it is a reflection of the Eastern European experience of the communist regime of the period? Science has failed to comprehend Solaris so utterly that it seems humanity must be in retreat. Even as the book closes there is no certainty regarding Solaris beyond phenomenology - or has the book displayed something of the spirit of the planet? Solaris is one of the most alien places in science fiction, at least for the Western Anglophone reader, whilst Solaris goes right to the heart of the questions that good science fiction should be exploring.

Purchase this book at ThinkGeek.

The Gimp, frankly, rocks. But like most pieces of complex software, it's a bit of a...problem to learn how to use. Enter chromatic's review of Carey Bunk's Grokking The Gimp. If you want to know more about image manipulation, check it out. Grokking the GIMP author Carey Bunks pages 342 publisher New Riders rating 8.2 reviewer chromatic ISBN 0-7357-0924-6 summary Principles of image manipulation explained in the context of the GIMP.

The Scoop One of the standout userland programs to come from Free Software development, the GIMP offers a powerful range of features for digital imagery. Unfortunately, not everyone's had the privilege of (or inclination for) sitting through 'Principles of Color' or similar classes. Not to fear, the author has - - and he's willing to share his knowledge.

Compounding the complexity challenge, the GIMP has its own way of doing things. Half of the work of editing an image seems to be making a good selection. Again, the author has theory to divulge and tips to present to improve your technique. Though only a few tools and methods are discussed, they are fundamental to all advanced operations. (Note that the book covers the as-yet unreleased 1.2 GIMP -- the 1.1.x betas have been quite usable for months.)

What's to Like? This attractive book is well-printed, with plenty of full-color images and good figures. It's also well-designed and the layout is excellent. The decision to add a few common problems and frequently asked questions at the end of most chapters is commendable. It's not designed as a reference book, but the index and table of contents are detailed enough to locate specific actions later.

Banks assumes little prior knowledge of the GIMP. Chapter one is a brief tutorial of the program's features and functions. More experienced users can skip this, though I found a couple of timesaving tidbits. The same may be said of chapter two, on layers, though the material quickly moves beyond what an average user might discover in an afternoon. The selections and masks chapters form the real foundation for most GIMP work -- how do you choose parts of your image to edit? A little theory, a few tools, and some examples later, you'll have multiple answers for that question.

The next two chapters pile on the theory. First, Bunks discusses the theory of color -- running the gamut (so to speak) from additive to subtractive, RGB, HSV, CMYK, and grayscale. There's plenty of math (more than one would need), and the explanations here are quite detailed. It's fundamental knowledge, and most readers can probably pick up just enough to get by. Don't skip ahead and miss the very useful touchup discussions in chapter 6. (The author considers them worth the price of the book -- given the results on some of my images, I'm inclined to agree.)

The final three chapters each cover different tasks one might wish to accomplish. Bunks explores various techniques while creating projects. Screenshots and commentary accompany step-by-step instructions. It's in these sections that the full power of the GIMP comes into play. Rounding things out are a handy keyboard shortcut guide and a detailed index.

What's to Consider? Things do get pretty heady in the theory section. Non-programmers (and people who haven't already worked with professional imaging) will have some slow going trying to absorb the math and colorspace information. It's not essential to use the GIMP, but knowing the differences between the modes and the limitations of each is necessary for most serious work.

Readers looking for a guide to the dozens of distributed plugins will be disappointed -- this book is more interested in the general techniques used in nearly every non-simple project. Finally, the book seems a little short. It's 342 pages, but the information is good enough that perhaps more subjects can be covered in a future edition. (That's a good thing.)

The Summary Nearly anyone will benefit from the deep magic behind the menu operations. Move past cheesy banners and poorly-executed lasso operations. Double the size and power of your toolbox, and get to know the GIMP. (If you're not convinced, browse the book online!)

Or buy it at ThinkGeek.

Table of Contents

1. GIMP Basics
2. Review of Layers
3. Selections
4. Masks
5. Colorspaces and Blending Modes
6. Touchup and Enhancement
7. Compositing
8. Rendering Techniques
9. Web-Centric GIMP

1. GIMP Resources
2. Keyboard Shortcuts

The Code Book remains a book good enough for another review, this time by the book-devouring stern. It's particularly interesting given the recent story that the code challenge it includes has been cracked. For another point of view, check out Jon Katz's review from a few months ago, nearly as enthusiastic. This book has already cost me several cups of coffee at BookPeople;), too!

The Code Book author Simon Singh pages 450 publisher Anchor Books rating 10/10 reviewer stern ISBN 0-385-49532-3 summary Engrossing history of code-making and code-breaking, with equal parts drama, biography, and tutorial.

Perhaps the most remarkable thing about Simon Singh's masterful The Code Book becomes clear at the end, when he provides seven coded messages. He starts with a simple substitution cypher and ends with what appears to be a form of public key encyrption. After only 350 pages, he has made codebreaking so exciting, so worthy an endeaver, and has explained the mechanics of the process so well, that you can't help but pick up a pencil and set to work.

When compared to other mass-market books on cryptography, Singh goes into much more detail on the contruction of cyphers, and the mathematics behind them. This makes the power and momentum of his writing a bit of a surprise. However, his thrill at the cracking of each code, and his understanding of the world-altering effects of each one, infect the reader.

The book contains everything you would expect -- Vigniere cyphers, the cracking of Enigma, a brief history of public key encryption. It also includes the Beale Treasure (crack a code, and there may still be millions in gold left to find), the Zimmerman telegram (which, when decoded by the British in 1917, drove the United States to declare war on Germany), and other stories of varying levels of familiarity. Most unusual, Singh includes the story of the decoding of Linear B and Egyptian Hieroglyphics. In other books, these chapters might seem very much out of place, as neither language was developed as a tool to keep things secret, and they are therefore distinctly out of place when next to commercial and military cyphers. That said, Singh's book is more about the thrill of decypherment and the intellect of code-breakers. Since the skills necessary to decode these languages closely resemble those of code-breakers, and since the triumph of victory is very much the same, they fit here.

What's Bad?

Codes and cyphers of importance in Britain and the United States dominate the book. There is almost no discussion of codes or codebreaking elsewhere. Perhaps Singh will address them in a later book. Also, for some, very sophisticated readers, much of the math will be overly simplistic. For some, very slow readers, later chapters will be difficult to follow. However, most people will find this book to be a treasure -- worth reading, and worth sharing with others.

What's Good?

From the perspective of the early 21st century, the weaknesses of old codes are obvious. As Singh walks us through the Cipher of Mary Queen of Scots, substitution codes and cyphers of increasing sophistication, the Vigniere cipher, we cover thousands of years worth of the science of secret writing. Today, computers bring us such tremendously powerful tools for cracking these codes, that you want to put a hand over your eyes and shake your head in embarassment for the governments, businesses, and hobbyists who should have known better. When Singh shows us the first Arabic document on the use of frequency analysis to crack substitution cyphers, I felt a pride similar to that I feel when I contemplate powered flight. As Singh's story progresses, it becomes clear that the advance of code-making, just like the advance in agriculture or the advance of transportation, carries within it the evolution of global civilizations. It includes technology, politics, trade, and the the demand for civil liberties (or privacy, which often amounts to the same thing).

Singh considers future technologies as well, especially quantum computing and its implications for modern, prime-number based encryption systems. He ends with quantum cryptography, perhaps the next paradigm in secrecy. If Singh is right, there is no principal in physics as we now understand it which will allow an untrusted party to decode messages encrypted with quantum cryptography.

He has also put up $15,000 for whoever can read the secret messages at the back of the book. The first few are easy, but they quickly get difficult. If the last few are what I think they are, a distributed computing network will be needed to crack them. Anybody volunteering to organize it?

Stern is the president of Information Markets Corp. You can purchase this book at ThinkGeek.

The Code Book remains a book good enough for another review, this time by the book-devouring stern. It's particularly interesting given the recent story that the code challenge it includes has been cracked. For another point of view, check out Jon Katz's review from a few months ago, nearly as enthusiastic. This book has already cost me several cups of coffee at BookPeople;), too!

The Code Book author Simon Singh pages 450 publisher Anchor Books rating 10/10 reviewer stern ISBN 0-385-49532-3 summary Engrossing history of code-making and code-breaking, with equal parts drama, biography, and tutorial.

Perhaps the most remarkable thing about Simon Singh's masterful The Code Book becomes clear at the end, when he provides seven coded messages. He starts with a simple substitution cypher and ends with what appears to be a form of public key encyrption. After only 350 pages, he has made codebreaking so exciting, so worthy an endeaver, and has explained the mechanics of the process so well, that you can't help but pick up a pencil and set to work.

When compared to other mass-market books on cryptography, Singh goes into much more detail on the contruction of cyphers, and the mathematics behind them. This makes the power and momentum of his writing a bit of a surprise. However, his thrill at the cracking of each code, and his understanding of the world-altering effects of each one, infect the reader.

The book contains everything you would expect -- Vigniere cyphers, the cracking of Enigma, a brief history of public key encryption. It also includes the Beale Treasure (crack a code, and there may still be millions in gold left to find), the Zimmerman telegram (which, when decoded by the British in 1917, drove the United States to declare war on Germany), and other stories of varying levels of familiarity. Most unusual, Singh includes the story of the decoding of Linear B and Egyptian Hieroglyphics. In other books, these chapters might seem very much out of place, as neither language was developed as a tool to keep things secret, and they are therefore distinctly out of place when next to commercial and military cyphers. That said, Singh's book is more about the thrill of decypherment and the intellect of code-breakers. Since the skills necessary to decode these languages closely resemble those of code-breakers, and since the triumph of victory is very much the same, they fit here.

What's Bad?

Codes and cyphers of importance in Britain and the United States dominate the book. There is almost no discussion of codes or codebreaking elsewhere. Perhaps Singh will address them in a later book. Also, for some, very sophisticated readers, much of the math will be overly simplistic. For some, very slow readers, later chapters will be difficult to follow. However, most people will find this book to be a treasure -- worth reading, and worth sharing with others.

What's Good?

From the perspective of the early 21st century, the weaknesses of old codes are obvious. As Singh walks us through the Cipher of Mary Queen of Scots, substitution codes and cyphers of increasing sophistication, the Vigniere cipher, we cover thousands of years worth of the science of secret writing. Today, computers bring us such tremendously powerful tools for cracking these codes, that you want to put a hand over your eyes and shake your head in embarassment for the governments, businesses, and hobbyists who should have known better. When Singh shows us the first Arabic document on the use of frequency analysis to crack substitution cyphers, I felt a pride similar to that I feel when I contemplate powered flight. As Singh's story progresses, it becomes clear that the advance of code-making, just like the advance in agriculture or the advance of transportation, carries within it the evolution of global civilizations. It includes technology, politics, trade, and the the demand for civil liberties (or privacy, which often amounts to the same thing).

Singh considers future technologies as well, especially quantum computing and its implications for modern, prime-number based encryption systems. He ends with quantum cryptography, perhaps the next paradigm in secrecy. If Singh is right, there is no principal in physics as we now understand it which will allow an untrusted party to decode messages encrypted with quantum cryptography.

He has also put up $15,000 for whoever can read the secret messages at the back of the book. The first few are easy, but they quickly get difficult. If the last few are what I think they are, a distributed computing network will be needed to crack them. Anybody volunteering to organize it?

Stern is the president of Information Markets Corp. You can purchase this book at ThinkGeek.

Cliff Lampe sheds light again on a subject you may be all too aware of whenever you open a desk drawer: complexity. Specifically, this review of Harnessing Complexity, which Cliff assures us is not of the "shallow business guru" variety, sounds like a great way to get a bird's eye view of a fascinating topic.

Harnessing Complexity author Robert Axelrod & Michael D. Cohen pages 184 publisher The Free Press rating 9.5 reviewer Cliff Lampe ISBN 0684867176 summary Become a professional Complexity Rassler!

The Scenario

Complexity science has grown increasingly popular in the past few years, with increased tools available for modeling, and increased examples of successful interventins in complex systems. Unfortunately, books on complexity have remained mostly crap, until now. In this slim book is a framework for not only understanding complex systems, but for doing something besides standing at the sideline and watching them unfold.

Axelrod and Cohen are founding members of the BACH group, which has been very influential in complexity research. They have been long standing members at either the Santa Fe Institute, which is the premiere complexity research facility in the world, or the University of Michigan's Study for Complex Systems, which has also had a large effect on the science. In other words, these are two cats who know their bidness. Now here's the good part. Axelrod and Cohen are solidly academic, but this book is not. The weakness of books on complexity is that they have either been written for other complexity theorists, making them inacessible, or for the general population, making them insipid. Even though both researchers have been studying this field for decades, and could have written something brillant yet obtuse, but instead they wrote something brilliant and useful.

The authors describe the characteristics of Complex Adaptive Systems in terms of the three main elements of those systems: variation, interaction and selection. The book is divided into roughly three parts, each dealing with one of these aspects. The systems described have many different components, and one of the contributions of this book is to provide a common vocabulary for these elements. Here's a sample bit of text that the authors claim would give you a rough summation of the book:

"Agents, of a variety of types, use their strategies, in patterned interaction, with each other and with artifacts. Performance measures on the resulting events drive the selection of agents and/or strategies through processes of error-prone copying and recombination, thus changing the frequencies of the types within the system."

There are many examples of complex systems that the authors use to bolster their explanations of complexity theory. How a disease spreads, how the military makes far reaching changes in philosophy, and of course evolution all drive home concisely crafted observations about complex adaptive systems. There's even a little gem that talks about the development of an open source project, specifically Linux. The authors discuss some conditions under which an open source development model might thrive, or at least make sense. As a favor to the authors, we'll make you read the book to find out what those are.

Complexity theory is not the same as chaos. Complex systems are not chaotic, though they do depend on variation in order to adapt, or change the equilibrium point. The important message here is that complex systems are not beyond our understanding, though it may be tough. Also, because complex systems depend on churn, if we can arrange ourselves at that point of churn, and try to direct we can affect systems that have been previously thought unalterable.

What's Good?

The tone of this book is killer. Combining lucid explanations with meaningful descriptions makes this very readable without diminishing the topic at all. The final chapter even outlines the rest of the book for you, boiling it down to the bare bones points that you should really take from the text. It might be helpful to read it first, and then go through and read the rest of the book.

The other strength of the book is how the authors manage to follow a strong academic tradition of supporting points with evidence without succumbing to making the book sound like the usual academic crap. All of the points made are supported not only with the great examples, but with evidence from a large body of research, mostly academic. The bibliography for this book would be a great place to start for any person or group interested in delving deeper into issues surounding complexity theory.

This assertion that we can understand complex systems, and exert influence over them is an important concept for a new paradigm for thinking. The systems being developed, computer or otherwise, are mostly examples of complexity in action. Whether it is an open source project being created or a new design team you are putting together, they are rarely systems that can be boiled down to simple cause and effects. The Newtonian view of a mechanical universe has polluted the very way in which we think about systems, the way in which we understand the universe. The people researching complex adaptive systems are working against that, and this book is a definitely volley in the right direction.

What's Bad?

This question is a matter of audience in the case of this book. It is definitely written for laymen, so if you are into the math of complexity research, or the modeling, then seek on crazy diamond. The intended audience here is the person who has to deal with complex, adaptive systems, but is not an expert in math. This book is intentionally short and brief, designed for those without a lot of leisure reading time. If you're after the uber compendium of complexity theory, this is not your book either.

While it is a minor point, the title of the book is annoying. It is understandable for marketing reasons, but it could turn off some smart people to reading the book, fearing it might be of the "Business Guru" shallow variety. Do not listen to these fear, buy this book.

So What's In It For Me?

If you've been interested in complexity theory, or need to work with complex adaptive systems (which everyone must) then this book has quite a bit to offer to you. Practical advice on how to exert influence in a complex environment could be invaluable to the reader. Besides the practical good it can do the reader, this book also has something to teach you about how you think about the world in general. Being aware of the complex systems around you, and thinking more deeply than black and white, or even gray, about these systems has benefits that far exceed your current job or project.

This book could also become valuable for the open source movement in general. Understanding complex, adaptive systems will also increase the chances for success of a number of possible open source projects as well as how to position them in software markets, which are themselves great examples of complex systems. It would be great if people involved with open source could champion this method of worldview both for its intrinsic and extrinsic benefits.

Purchase this book at ThinkGeek.

We've all read about some of the dumber patents issued recently by the United States Patent and Trademark Office [USPTO]. The Slashdot community is full of talent and creativity, so why not come up with our own stupid patent ideas instead of waiting for Amazon or Priceline or some other company to come up with something amusing? First prize is a $50 ThinkGeek Gift Certificate that I am paying for out of my own pocket, and will personally sign. The winner will be chosen on the basis of originality, believability, and humor value. To start things off, I will describe my own personal contribution to the Stupid Patent Pool: Zero Click Shopping.

As you know, Amazon has successfully patented "One Click Shopping," Barnes & Noble is angry about the patent, and Apple has bought into the idea. Such tomfoolery! This concept is no more deserving of a patent than something as basic as, say, the hyperlink.

So I decided to go Amazon one better and invent Zero Click Shopping:

"A method of using javascript or similar technology to produce a series of Web page-displayed images that, when "rolled over" by a customer's mouse in a predetermined order, either causes a purchase to be consummated or causes a series of preselected items to be placed in a single customer-accessible data file so that the customer can purchase all selected items at the same time instead of having to perform a series of separate transactions."

Remember, you saw it here first!

If anyone tries to patent this silly, rather obvious concept from this day forward, you can point them to this article to show that is was instantly obvious to anyone familiar with the "state of the art," which means that this idea should not be patentable.

But nowadays, the head of the USPTO seems to believe that every boneheaded concept deserves patent protection, and that if you don't like a patent, you are supposed to hire a lawyer and take it to court. Gaaah!

So let's take the idea and lampoon it -- minus the legal fees, of course.

Write a patent summary. It can be for anything, as long as it sounds credible and is written in patent-talk or a reasonable parody thereof. Post it here. We'll let the Slashdot moderators decide which ideas have merit (or at least humor value) and which don't.

The Slashdot Authors, acting in all of their usual chaotic glory, will decide which of the highest-moderated pseudo-patents wins the grand prize.

Three Honorable Mention winners will each receive a Slashdot t-shirt from ThinkGeek.

You must be a registered Slashdot user to win. Entries will be accepted until 11:59 p.m. (2359) GMT on Friday, October 13. Winners will be announced on Tuesday, October 16. Judges' decisions are final. (If you don't like them, hold your own contest, okay?) The purpose of this whole thing is to laugh, not to get rule-bound, so post away, have a good time, and may the dumbest... er... best ... idea win!

We've all read about some of the dumber patents issued recently by the United States Patent and Trademark Office [USPTO]. The Slashdot community is full of talent and creativity, so why not come up with our own stupid patent ideas instead of waiting for Amazon or Priceline or some other company to come up with something amusing? First prize is a $50 ThinkGeek Gift Certificate that I am paying for out of my own pocket, and will personally sign. The winner will be chosen on the basis of originality, believability, and humor value. To start things off, I will describe my own personal contribution to the Stupid Patent Pool: Zero Click Shopping.

As you know, Amazon has successfully patented "One Click Shopping," Barnes & Noble is angry about the patent, and Apple has bought into the idea. Such tomfoolery! This concept is no more deserving of a patent than something as basic as, say, the hyperlink.

So I decided to go Amazon one better and invent Zero Click Shopping:

"A method of using javascript or similar technology to produce a series of Web page-displayed images that, when "rolled over" by a customer's mouse in a predetermined order, either causes a purchase to be consummated or causes a series of preselected items to be placed in a single customer-accessible data file so that the customer can purchase all selected items at the same time instead of having to perform a series of separate transactions."

Remember, you saw it here first!

If anyone tries to patent this silly, rather obvious concept from this day forward, you can point them to this article to show that is was instantly obvious to anyone familiar with the "state of the art," which means that this idea should not be patentable.

But nowadays, the head of the USPTO seems to believe that every boneheaded concept deserves patent protection, and that if you don't like a patent, you are supposed to hire a lawyer and take it to court. Gaaah!

So let's take the idea and lampoon it -- minus the legal fees, of course.

Write a patent summary. It can be for anything, as long as it sounds credible and is written in patent-talk or a reasonable parody thereof. Post it here. We'll let the Slashdot moderators decide which ideas have merit (or at least humor value) and which don't.

The Slashdot Authors, acting in all of their usual chaotic glory, will decide which of the highest-moderated pseudo-patents wins the grand prize.

Three Honorable Mention winners will each receive a Slashdot t-shirt from ThinkGeek.

You must be a registered Slashdot user to win. Entries will be accepted until 11:59 p.m. (2359) GMT on Friday, October 13. Winners will be announced on Tuesday, October 16. Judges' decisions are final. (If you don't like them, hold your own contest, okay?) The purpose of this whole thing is to laugh, not to get rule-bound, so post away, have a good time, and may the dumbest... er... best ... idea win!

Are you an "isolate?" In Disconnected, University of Wisconsin computing professor William Wresch takes a look at the cultural divide between the information haves and have-nots of the world, from workers in Namibia to tribesmen in the Kalihari to isolates in America who, despite lots of technology, choose to stand apart from their peers and organizations. He makes an interesting case for the idea that access to information may ultimately have more to do with divisions in the world than nationalism, ethnicity or geography.

Disconnected: Haves and Have Nots in the Information Age author William Wresch pages 268 publisher Rutgers University Press rating 7/10 reviewer Jon Katz ISBN 0-8135-2370-2 summary disparities in information distribution and transmission

Are you a cultural isolate? According to Disconnected: Haves and Have Nots in the Information Age, by William Wresch, "isolates" comprise between 27% and 50% of the members of most corporate and private organizations.

"Many individuals," he writes, "have tenuous connections to the organizations they work for. They want no more to do with that organization than their job, or their paycheck, requires. They don't show up at the company picnic, read the company newsletter, or tune in to the company grapevine."

Wresch suggests that this is so because despite the explosion in new information technologies, most companies don't know how to get their employees to communicate with one another. He says it's impossible to imagine any Japanese organization reporting 7% alienated employees, much less 50%. U.S. organizations not only have huge numbers of isolated employees but still manage to survive and prosper.

Wresch cites Lucasfilms which discovered through internal research that there was almost no horizontal communication between editors, cinematographers, and artists, to which it responded by carefully restructuring its softball teams so that no team could have more than one person from the same department.

Curiously, Wresch portrays "isolates" as problem employees in need of curing. (I consider myself an isolate. I am quite happy to belong to an organization, but have no interest in showing up at the company picnic, reading the company newsletter, or wiring into the company grapevine. Nor do I want to join the company softball team (the idea of a Slashdot softball team is pretty amusing) to make me more social or communal. Working alone, or from something of a distance seems to me as valid a choice as being the kind of rah-rah team players the Disney Corporation breeds and encourages.)

But Disconnected is still a thoughtful, provocative study of a world in which there are vast and growing disparities between what people know and how they know it. His portrayals of information realities in other parts of the world are startling, an information context most Americans are losing touch with. He writes of "information exiles" whose culture or geography keep them disconnected from the information age. He also reminds us that our own techno-rich culture is still, in many ways, an anomaly in the world. He contrasts the way information moves around in the info-rich West with the way information moves (or doesn't) in Namibia, where he spent some time working and researching.

What will happen to the disconnected of the information age, he wonders? "As subsistence farming and handicrafts persisted through the industrial age, will the disconnected carry on, barely feeding themselves, producing the primitive and quaint for middle-class coffee tables? Early indications are that the disconnected will fare far worse than their predecessors in previous revolutions. The gap between the rich and the poor, the knowing and the ignorant, will be larger, the room along the margins far smaller."

Disconnected is a reminder that our own information experiences -- especially those in America, Asia and Western Europe -- aren't yet remotely typical of the world, where laborers often stand on street corners for hours, even days,waiting to hear some news about possible jobs. And even in our own hi-tech cultures, there are curious disparities between information haves and have-nots. Wresch, a computing professor at the University of Wisconsin, also raises a number of useful ideas about closing the information divide, from community computing centers to the conversion of civic and public affairs offices to electronic centers of information dissemination.

"Cultures of isolation aren't the only problems of personal information channels," he writes. "Since these channels are largely invisible, they can be filled with myths, lies, and hatreds. Few outsiders even know what is being said, nor do they have opportunities to correct even the most egregious errors. Yet error-prone or not, these are channels that supply much of the world's information."

You might not always agree with Wresch's conclusions, and he raises many more questions than solutions, but "Disconnected" is an interesting book (the writing isn't great but workable) which looks at information technology from an original perspective, especially for a computing academic. The book tells some uncomfortable truths about information and technology, and as happy as we are to play with our information-scarfing new toys and tools, it's an important reality check. Wresch essentially is writing about the forgotten people in the Information Revolution, the info-refugees and exiles, the people who fall between the cracks, unable or unwilling to use technology to collect information in an accessible or beneficial way.

Purchase this book at ThinkGeek.

Bruce Schneier, well-known security and encryption expert, and author of Applied Cryptography has recently had his newest book published, entitled Secrets & Lies: Digital Security in a Networked World, which explores the world of security as a system. Read the entire review below. Secrets & Lies: Digital Security in a Networked World author Bruce Schneier pages 412 publisher Johy Wiley & Sons, 09/2000 rating 10 reviewer Jeff "hemos" Bates ISBN 0471253111 summary A well written, well researched exploration of digital security as a system.

I've recently had the pleasure of reading Bruce Schneier's latest writing effort Secrets and Lies: Digital Security in a Networked World. A number of our readers may remember his prior book Applied Cryptography , which discussed the use of cryptography in our brave new digital world, and how the use of crytography would make things secure.

This time around, Schneier is much more cicumspect about the uses and application of cryptography. As he states in the introduction and throughout the book, when writing AC, he thought that the use of cryptography would make things more secure. He was correct - but the lesson he learned while working with companies and individuals, that we can't just add cryptography into a system and make it secure, but that systems must be designed from the bottom-up with security in mind. S&L draws upon a huge amount of experience working in the security field, making one central point: Any system, no matter how good the cryptography is, is only as strong as the weakest link. Yes, that's an old cliche, but it's one that bears repeating.

What makes it even more imperative to design system to be secure is the sheer amount of systems that aren't secure, and what the means for us. Some of the examples Schneier uses in S&L are simply frightening to consider were they to occur. And some of his ideas about what will come, and the tools we have will make you want to keep a good stash of gold kruggerands under your mattress.

Indeed, as he talks about in the introduction, part of the reason this book too so long to write was because he was depressed at the world of security around him. Looking at what companies were doing, at what people were doing, and the sheer amount of systems holes out there must be depressing - but it only drives home the point even moreso that we must design *systems* not just adding cryptography and thinking that's the magic pixie dust that can make everything better.

The book does an exceptional job of wending its way through various security measures, how they work, and how they fail. IMHO, one of the real strengths of this book is that it's something that a cryptography novice could read, as well as an expert. Certain sections of the book are dedicated to the nitty gritty behind systems, but there are also sections that are dedicated to simply laying out the process by which one should approach the systems. Indeed, the support blurb on the dust jacket is written by Jay S. Walk, the founder of priceline.com. This adds to the strength of the claim that the book can be for everyone.

Schneier is intimately involved with the security community - besides being the creater of the [Blowfish] and [Twofish] encryption algorithms and a frequent speaker at technical conferences, his company deals with this day in and day out. More to the point for a book, he can also write. It makes reading about Product Testing and Verification (Chapter 22) rather than a snooze, a treat. The book is one of those rare cross-overs - something to give your geek friends, and your [PHB], all of whom will appreciate it. The breadth of the book is revealed in the contents (Duh) and it's a good mixture of all the necessary elements. You'll learn about entropy in a system as well as Attack Trees, Threat Modeling and what all of this stuff means in day-to-day life.

I wholeheartedly recommend this book.

The Table of Contents and the preface are available on Counterpane's site; S&L's Chapter Three is on Amazon.

Purchase this book at ThinkGeek.

Jon Lasser is the author of ThinkUnix a new learning UNIX/how-to. While Danny Yee of dannyreviews actually wrote the review, I've read the book as well. It's good -- it's different from other learning Unix books because he really wants you to learn the concepts behind Unix -- to grok it. ThinkUnix author Jon Lasser pages 294 publisher Que 2000 rating 8 reviewer Danny Yee ISBN 0-7897-2376-x summary Rather than trying to be a detailed guide to a particular system, a comprehensive reference work, or a source of answers to particular problems, Lasser tries to teach the fundamental concepts of Unix and the Unix way of thinking.

In a world full of volumes like Linux: The Complete Reference, Debian GNU/Linux 2.1 Unleashed, Corel Linux for Dummies and so forth, Lasser's Think Unix is a breath of fresh air. Rather than trying to be a detailed guide to a particular system, a comprehensive reference work, or a source of answers to particular problems, Lasser tries to teach the fundamental concepts of Unix and the Unix way of thinking. He also captures something of the way in which Unix is a way of life and a culture, not just an operating system, with a good leavening of humour, history, and hackish lore. One consequence of this approach is that Think Unix will date far less quickly than most operating system books. I recommend it to computer science students, techies coming from non-Unix backgrounds, or anyone more interested in understanding the underlying ideas of Unix than solving particular problems.

Lasser starts with a chapter on documentation, explaining how to use "man" to read manual entries and touching on other forms of documentation. He then introduces the building blocks of Unix - files and processes and redirection and pipes. A brief look at TCP/IP networking, showing how to interact directly with some common network services using telnet, is followed by an introduction to vi and sed and basic regular expressions. Four chapters then deal with shell scripting in more detail, touching on differences between shells, variables and quoting, control structures, and aliases, functions, and scripts. A quick look at X explains its general design, something of the variety of window managers and desktops available, and basic configuration of startup, resources, and fonts.

Obviously a lot is left out of this (there is nothing about system administration, for example), but it provides solid foundations for further learning. And a number of topics sneak in "in passing": a mention of ssh (and associated legal issues) and a little bit about termcap and terminfo, among other things. Some practice problems are included, simple exercises to test understanding and help learning; answers to these are provided in the appendices, along with a short glossary (which includes pointers to other resources).

Think Unix has an unfortunate number of typos, including a few in code examples. And there are a few things I might have done differently (I'd have ditched most of the grainy greyscale half-page screenshots of different window managers and desktop environments, for example). Overall, however, it's a great book and the biggest problem it poses me is working out which of my "clueful but not Unix-literate" friends to pass my review copy on to.

Purchase this book at ThinkGeek.

A book review by Danny Yee <editor@dannyreviews.com>
Reviews of more than five hundred other books: Subjects | Titles | Authors | Latest

An anonymous reader wrote in to say "I was having a look at ThinkGeek's 6 Gb MP3 jukebox, and was interested to see that the software is Linux-based. There's a link at the bottom of the page: download Linux source. Interestingly, this link requires I 'sign' a license agreement with Compaq before downloading the source code. The license, amongst other (scary) things, says: CUSTOMER acknowledges and agrees that COMPAQ owns all rights, title and interests in and to the SOFTWARE and all Intellectual Property Rights therein." That can't be right, can it? What's going on here? Is it a simple case of Compaq needing reminding about the ground rules concerning Linux distribution? Perhaps they have not made any kernel modifications, and this license is for their application software? " Update: 09/13 05:16 PM by CT : we screwed this one up. The link is somewhat misleading since it says its a link to Linux Source, but its not actually the linux source, its just some code that runs on linux. Stop flaming please. Move along. Nothing to see here.

Well, in my digging through our book review bin, I found this review of The Linux Problem Solver, which somehow slipped through the cracks. Thanks to PotPieMan for doing the review and let's see what he thinks of the book. The Linux Problem Solver author Brian Ward (author of the Kernel-HOWTO) pages 239 publisher No Starch Press rating 6.5 reviewer PotPieMan ISBN 1-886411-35-2 summary This book aims to help systems administrators deal with both initial setup andconfiguration snafus and ongoing maintenance problems by combining standard tutorial explanations with over 100 problem-oriented troubleshooting sections.

The Scoop The Linux Problem Solver isn't a bad idea. While there are HOWTOs, IRC, and other ways of getting help, having a book that covers many of the mundane, day-to-day problems is potentially helpful. In this book, there are standard tutorial-type explanations which illustrate some of the most important command-line options and configuration file directives. The author lists relevant man pages in certain tutorial sections. In addition, there are numerous troubleshooting sections interspersed throughout the tutorials. In these sections, the reader is given a symptom (like "Large files don't print"), a problem (such as "The default maximum size is too small"), and the final solution. In some cases, the given problems and solutions could probably prove quite helpful, especially when used in conjunction with the numerous available HOWTOs. The book also includes a CD, which supposedly includes a bunch of helpful utilities, in addition to serving as a bootable rescue CD. Unfortunately, my proof copy of the book did not include the CD. To give an overview of the book's layout, here is a brief list of topics covered in each chapter to expand on the table of contents below:

• Chapter 1: general introduction, Linux system basics (init, syslogd, devices, and the like) Chapter 2: setting up network interfaces, inetd, firewalls, network security and diagnostics Chapter 3: NFS clients and servers, NIS, Rdist and SSH with Rdist Chapter 4: SAMBA, Netatalk, Squid Chapter 5: printing with LPRng, including network and non-PostScript printing Chapter 6: installation from tarballs, explanation of the Encap organization scheme Chapter 7: kernel configuration, compilation, and installation; module setup Chapter 8: backups with tape drives, automated backups, crash recovery Chapter 9: shell startup files, X startup files, xdm, and X resources What's Bad? I found that much of the writing in
• The Linux Problem Solverwas difficult to read--the text didn't flow like a troubleshooting book should. The author, it seems, attempted to construct his discussion in a terse manner to keep the chapters focused on individual topics. While many may like this approach, I found myself rereading parts because there wasn't enough explanation.

  Another related problem I found was that some of the examples in the tutorials were not introduced, and when they were, there were inconsistencies between the explanations and the actual command-line or configuration file examples. This is a relatively minor problem--although one that should have been caught in the editing phases. (And it may have been; I received an "uncorrected proof.") There were also, in some instances, grammatical errors which were probably fixed during the editing process.

  I was also disappointed by the organization between the general tutorial discussion and the problems. The troubleshooting sections didn't always follow the topic of the text, coming at rather random times for some of the topics. Unfortunately, because of the overly terse writing style, it made more sense to me to separate the general tutorial and the troubleshooting sections, which was done in some places. With a bit more transitional text, I think that the troubleshooting sections could have flowed much better with the setup and configuration tutorials.

  I found some small problems with text formatting, which may have been corrected in a more final version of the book. While quite minor, there were mistakes in heading and subheading styles which detracted from the organization of individual chapters.

  What's Good? The layout of the chapters was generally pretty good. The topics within each chapter made sense together. Most Linux administration topics were covered, with some being covered too briefly for my tastes. X, a topic that I thought would be relatively important to systems administrators, received less than 10 pages (compared to an entire chapter on installing software from source tarballs), with hardly any mention of networking X. (One could argue, however, that X networking is becoming less important as workstations become less expensive.)

  Out of all the chapters, the printing chapter seemed most comprehensive. There were a few inconsistencies between the text and the provided examples which were annoying, but not to the point where I became confused. I liked the discussion of network printing (through LPRng, AppleTalk, and SAMBA) and of printing to non-PostScript printers, topics that are probably pertinent for many administrators of Linux workstations.

  I like the problem-oriented presentation of the setup and maintenance issues, despite the organization problems. As a systems administrator, having a reference like this might be nice during those times when you just can't figure out what's wrong. Some of the book was very well written and helpful, like the Netatalk section. This section was well-organized, with examples introduced and explained cleanly. The troubleshooting tips flowed nicely with the tutorial text. If more of the book flowed as well as the Netatalk section, it would have received a much better score.

  So What's In It For Me? If you want a reference that combines standard tutorials with troubleshooting, The Linux Problem Solver is a book to consider. I would recommend it to those who are newer to Linux or systems administrators who are new to maintaining more than they can handle. For experienced administrators, this book probably wouldn't expose any big secrets. Nevertheless, the book offers numerous suggestions on how to make life easier, like the Encap package management system to help with upgrades and removal of packages.

  Before purchasing the book online, however, I would go to a bookstore and flip through it. You may like the writing style, and you may find the troubleshooting very helpful. But because of the sometimes hard-to-follow writing, I don't see myself using the book on a daily basis. Rather, I'll be sticking with the HOWTOs and man pages.

  Table of Contents

  1. About This Book
  2. Network Installation
  3. NFS, NIS, and Rdist
  4. MS-Windows and AppleTalk Networks, Web Proxy Server
  5. Printing
  6. Installing Software from Source Code
  7. Kernel Upgrades
  8. Backups and Crash Recovery
  9. User Environments
  Purchase this book from ThinkGeek..

Duncan Lawie contributed this review of Mary Gentle's A Secret History, a book which sounds like a must-read for followers of historical fiction, science fiction, medieval fiction, feminist revisionism and more. Interestingly, British readers are entrusted with the whole thousand-plus-page story, while the publishers thought that Americans would like to take things a little more gently.

Ash: A Secret History author Mary Gentle pages 1110 publisher Gollancz (UK) Avon Eos (U.S.) rating 9.5 reviewer Duncan Lawie ISBN 0380788691 summary A powerful, expansive, genre-blurring work, impressive in detail and astounding in scope.

Mary Gentle wrote her first published novel, A Hawk in Silver, at the age of 18, though it took her some time to find a publisher. Her first adult science fiction work, Golden Witchbreed, suffered a similar hiatus. Her subsequent writing career has been informed by her late decision to embrace academia, exploring areas such as militarism, feminism, Plato and the Renaissance world view. She wraps these potentially dry subjects, though, with a delight in imparting (possibly twisted) information and an energy for entertaining. Her eclectic approach has carried her across genre boundaries; her latest work displays this characteristic and the richness such cross-fertilisation can bring.

Ash: A Secret History has been released in the UK as a single volume of over 1100 tightly packed pages, while the book's American publishers are putting it out in four parts, with the last part due before year's end (The Book of Ash: #1 A Secret History, #2 Carthage Ascendant, #3 The Wild Machines, #4 Lost Burgundy). At heart, this is the story of a female mercenary commander in Europe and North Africa in the late 1470s. Ash, who grew up in the baggage train of assorted mercenary companies, is a survivor of harsh conditions. As the book proper opens, she leads a company of 800 fighting men (and women), aided by an apparently miraculous inner voice which offers her explicit tactical combat instructions. Ash is an incredibly well-realised character. She is a soldier by training and inclination, but she is also a well-rounded human being. Her skills as a leader of people match her battle prowess and her ability to take quick advantage of a changing situation. This Demoiselle-Captain is a strong character, utterly convincing in her tone, her inner life and its visible expression in the text. She is the cornerstone of the novel, present in almost every page.

Ash's story is presented as an academic work, originally published by a University Press in 2001. This fictional outer story is described as a translation of medieval Latin manuscripts (the work of Dr. Pierce Ratcliff, professor of War Studies), a major revision and modernisation of the "Lost History of Burgundy." The book also includes correspondence between Ratcliff and his editor annotated by another hand and inserted in differing typeface within the main body of the text. These affectations are easy to overlook early on in the book as Ash leads her company on the battlefields of Europe and is rewarded with court intrigue. However, the unsettling differences between the history in the main text and our own history are increasingly the subject of Ratcliff's correspondence. This fancy of commentary allows modern academia to creep into the interstices of the book without unbalancing the unscientific world of miracles, acting as a regulator when the plot seems to wander off into the realms of fantasy or alternate history. The concreteness of Gentle's writing carries the story in incredible directions without ever challenging the suspension of disbelief. Looking back on the early chapters from the perspective of the book's end there is a sense of astonishment at how far the story has travelled. As sunny summer fades to horrific winter the tone becomes heavier, reflecting a growing seriousness, but the writing never loses its sense of balance between light and shade.

The solidity of the book comes from a combination of detail and character. Throughout, the reality of medieval life is clear. The characters live in a world where armour rusts and rain runs down inside every knight's plating; ice and bad luck are as dangerous as lances and arrows. The mercenaries' life is displayed through reference to the polyglot of languages they speak and the language they use. (Ratcliff confesses early on that Ash swears "rather a lot" and explains that he has used modern equivalents rather than medieval blasphemies). There is a wonderful precision in the terminology also; a generic word for the tools of war is never used where a specific one is available -- artillery includes cannon, arquebus (or hackbutt), trebuchet, bombard, mangonel, ballista and catapult -- and where necessary, Dr. Pierce Ratcliff provides a footnote to explain the term. Ratcliff and his correspondents gradually become just as real as the mercenary company, though they do not leap out of the first page; it is a wrench to recall that this may not be a translation and that Ratcliff is not really toiling away on it at a North African archaeological site.

Any attempt to provide a full precis of a plot as long and gloriously complex as that Ash: A Secret History has to offer must fail in the attempt, while revealing details which ought to be allowed to delight the reader firsthand. That plot includes perhaps a touch of sentiment, but this is no more than a balance for the harshness, holding the book in a dynamic tension rather than allowing it to slide into the unremitting horror of war. While the book may appear in the disguise of the BCF (Big Commercial Fantasy), it is not really so easy to pigeonhole. Neither is it the simple historical romance it first appears to be, or the alternate history it shows signs of becoming. Though the scientific roots of this work are well hidden in the first few hundred pages, Ratcliff develops theories which owe a great deal to high physics and hard science fiction. High drama and rich plotting in both time frames draw the book to an intense climax. The ending is shattered, splintered, hugely open to re-interpretation -- and the last revelations don't become clear until some time after the final pages are turned. Though I feel that Ash: A Secret History is science fiction, this book is so good at blurring genre boundaries, and is such an excellent work, that every genre will try to claim it as its own.

Readers intrigued by this book may be interested in this recent interview with Gentle.

You can purchase this book at ThinkGeek.

Duncan Lawie contributed this review of Mary Gentle's A Secret History, a book which sounds like a must-read for followers of historical fiction, science fiction, medieval fiction, feminist revisionism and more. Interestingly, British readers are entrusted with the whole thousand-plus-page story, while the publishers thought that Americans would like to take things a little more gently.

Ash: A Secret History author Mary Gentle pages 1110 publisher Gollancz (UK) Avon Eos (U.S.) rating 9.5 reviewer Duncan Lawie ISBN 0380788691 summary A powerful, expansive, genre-blurring work, impressive in detail and astounding in scope.

Mary Gentle wrote her first published novel, A Hawk in Silver, at the age of 18, though it took her some time to find a publisher. Her first adult science fiction work, Golden Witchbreed, suffered a similar hiatus. Her subsequent writing career has been informed by her late decision to embrace academia, exploring areas such as militarism, feminism, Plato and the Renaissance world view. She wraps these potentially dry subjects, though, with a delight in imparting (possibly twisted) information and an energy for entertaining. Her eclectic approach has carried her across genre boundaries; her latest work displays this characteristic and the richness such cross-fertilisation can bring.

Ash: A Secret History has been released in the UK as a single volume of over 1100 tightly packed pages, while the book's American publishers are putting it out in four parts, with the last part due before year's end (The Book of Ash: #1 A Secret History, #2 Carthage Ascendant, #3 The Wild Machines, #4 Lost Burgundy). At heart, this is the story of a female mercenary commander in Europe and North Africa in the late 1470s. Ash, who grew up in the baggage train of assorted mercenary companies, is a survivor of harsh conditions. As the book proper opens, she leads a company of 800 fighting men (and women), aided by an apparently miraculous inner voice which offers her explicit tactical combat instructions. Ash is an incredibly well-realised character. She is a soldier by training and inclination, but she is also a well-rounded human being. Her skills as a leader of people match her battle prowess and her ability to take quick advantage of a changing situation. This Demoiselle-Captain is a strong character, utterly convincing in her tone, her inner life and its visible expression in the text. She is the cornerstone of the novel, present in almost every page.

Ash's story is presented as an academic work, originally published by a University Press in 2001. This fictional outer story is described as a translation of medieval Latin manuscripts (the work of Dr. Pierce Ratcliff, professor of War Studies), a major revision and modernisation of the "Lost History of Burgundy." The book also includes correspondence between Ratcliff and his editor annotated by another hand and inserted in differing typeface within the main body of the text. These affectations are easy to overlook early on in the book as Ash leads her company on the battlefields of Europe and is rewarded with court intrigue. However, the unsettling differences between the history in the main text and our own history are increasingly the subject of Ratcliff's correspondence. This fancy of commentary allows modern academia to creep into the interstices of the book without unbalancing the unscientific world of miracles, acting as a regulator when the plot seems to wander off into the realms of fantasy or alternate history. The concreteness of Gentle's writing carries the story in incredible directions without ever challenging the suspension of disbelief. Looking back on the early chapters from the perspective of the book's end there is a sense of astonishment at how far the story has travelled. As sunny summer fades to horrific winter the tone becomes heavier, reflecting a growing seriousness, but the writing never loses its sense of balance between light and shade.

The solidity of the book comes from a combination of detail and character. Throughout, the reality of medieval life is clear. The characters live in a world where armour rusts and rain runs down inside every knight's plating; ice and bad luck are as dangerous as lances and arrows. The mercenaries' life is displayed through reference to the polyglot of languages they speak and the language they use. (Ratcliff confesses early on that Ash swears "rather a lot" and explains that he has used modern equivalents rather than medieval blasphemies). There is a wonderful precision in the terminology also; a generic word for the tools of war is never used where a specific one is available -- artillery includes cannon, arquebus (or hackbutt), trebuchet, bombard, mangonel, ballista and catapult -- and where necessary, Dr. Pierce Ratcliff provides a footnote to explain the term. Ratcliff and his correspondents gradually become just as real as the mercenary company, though they do not leap out of the first page; it is a wrench to recall that this may not be a translation and that Ratcliff is not really toiling away on it at a North African archaeological site.

Any attempt to provide a full precis of a plot as long and gloriously complex as that Ash: A Secret History has to offer must fail in the attempt, while revealing details which ought to be allowed to delight the reader firsthand. That plot includes perhaps a touch of sentiment, but this is no more than a balance for the harshness, holding the book in a dynamic tension rather than allowing it to slide into the unremitting horror of war. While the book may appear in the disguise of the BCF (Big Commercial Fantasy), it is not really so easy to pigeonhole. Neither is it the simple historical romance it first appears to be, or the alternate history it shows signs of becoming. Though the scientific roots of this work are well hidden in the first few hundred pages, Ratcliff develops theories which owe a great deal to high physics and hard science fiction. High drama and rich plotting in both time frames draw the book to an intense climax. The ending is shattered, splintered, hugely open to re-interpretation -- and the last revelations don't become clear until some time after the final pages are turned. Though I feel that Ash: A Secret History is science fiction, this book is so good at blurring genre boundaries, and is such an excellent work, that every genre will try to claim it as its own.

Readers intrigued by this book may be interested in this recent interview with Gentle.

You can purchase this book at ThinkGeek.

Madman Chromatic (coder, writer, thinker) sheds even more light on the books lurking on store shelves designed to lure, and then snare, new or uncertain users into trying out -- and actually enjoying! -- this wacky "Linux thing." This time around, the texts he's chosen cover the topics of installation and day-to-day operation of a Linux system in greater depth than the Dummies series dares to, but they're still aimed squarely at competent, literate users rather than only at technical gurus. Read on for his insights into Using Linux, Linux Configuration & Installation, and the Linux Essential Reference.

Various Introductory and Reference Books author (Varies by title) pages n/a publisher (Varies by title) rating n/a reviewer chromatic ISBN (Varies by title) summary Three books intended to provide clear guidance and reference to the Linux sysadmin

This week's edition takes a look at three very different books. We have tutorials, theory and techniques, and thick juicy slabs of opts. Step through instructions and stay on the sidewalk, get your hands dirty on your own if you're the trailblazing type, or read up on what you always thought someone should code, if you're stuck at your desk.

Title (Author) Using Linux (Jack Tackett, Jr / Steven Burnett) Publisher, ISBN QUE, 0789717468 Included Stuff none Intended Audience RedHat users. Scope Installation and basic introduction to Linux. Technical Correctness Occasional weird advice. (In one spot, the authors describe a very insecure PATH setting without explaining that it's dangerous.) Writing style Varies with chapter author. Other Two-thirds of the way through the book, there are a number of mildly annoying typesetting errors. Unfortunately, they tend to appear near literal command-lines. Hopefully this will be corrected in a second edition.

Using Linux is a cross between a reference-book and a tutorial. Each chapter takes a different subject (Networking, Working with Hard Drives) and breaks it up into common tasks -- each listed in the copious table of contents and the large index. For example, if you're interested in setting up a file system, you can flip right to page 495 and choose between the RedHat tool or editing /etc/fstab yourself. Though RedHat tools receive a lot of attention, they're not presented as the only way to get things done. In a pinch, you'll find command line equivalents for common tasks given near the graphical description.

Accompanying the chapter text are occasional sidebars. These label figures, give a bit of historical perspective, and dish out useful tidbits of information that don't fit into the normal flow. This is less distracting than the usual approach of goofy icons and inset boxes often found in other books.

What's nice about this book is that it covers more subjects than most of the others. It's thick, but not unreasonably so. It's easy to read, but packed with details. Instead of covering only the handful of things every (home) user will need, the authors add information about removable drives, fax configuration, and file system cleanup, to name a few topics. Also nice is a brief chapter on building installations from source code (both make and Imake style systems) -- there's another world out there beyond RPM.

The task-oriented approach doesn't spend much time on theory, preferring a gentle overview and usage specifics. Obviously, there's more to learn than what's presented, but people more interested in results will prefer this decision. The system administration section really stands out, for an introductory book, and the appendix listing common Linux commands and glossary of terms will come in handy.

All things considered, this is a solid book. The breadth of information is good, and the flow of topics means it's readable from start to finish. Occasional flaws detract slightly, but they're not fatal.

[You can purchase this book at FatBrain.]

Title (Author) Linux Configuration & Installation (Patrick Volkerding, Kevin Reichard, Eric Foster-Johnson) Publisher, ISBN M&T Press, 0764570056 Included Stuff Slackware 3.5 CD-ROM, with extra disk full of additional programs. Intended Audience The do-it-yourself type. No prior Unix knowledge is necessary, though some experience with the command line will come in handy. Scope Installation and introduction to Slackware. Very good overview of the general Linux way to do things. Technical Correctness Quite good. Writing style Easy to read, though still technical. Other The version reviewed is the 4th edition -- somewhat dated (1998), but not out of touch. If there's a newer edition, get it! If not, you won't go astray with this one.

With help from Patrick Volkerding (Slackware creator) himself, this book teaches the do-it-yourself distribution. Expect a tremendous amount of detail -- in the first chapter alone, there are dozens of links to a Web site for more information about Linux and particular hardware. Fully half the book falls under installation and initial configuration issues, though this includes tinkering with your window manager, setting up networking, and recompiling your kernel (topics usually saved for later in other books). The fourth edition added a section on Slackware and portable computing, with pages of links to information on particular laptop models and information on synchronizing your Palm Pilot.

Chapter seven introduces the command line (though people following along will have used it -- with gentle prodding). It's a whirlwind, 50-page tour that explains a bevy of tools and tricks both concisely and thoroughly enough for day to day work. Following that are applications -- text editors, text formatters, graphics viewers, and the like. A short section on system administration covers scheduling, managing accounts, checking performance, but relatively little about security. Finally, chapter ten delves in to Linux programming -- toolkits, languages, tools, and scripts. Maybe the hors d'ouvres will whet your appetite to learn more, or at least help you with the magic "./configure; make; make install;" incantations.

The appendices list additional sources of information and the contents of the CD-ROM. Don't overlook the supplemental information, either -- including 30 pages of extra package description. (If you're going to install Slackware yourself, you ought to know what you need and what additional options there are.)

The only reason to overlook this book is its age, which is a shame. Things haven't changed so much that the knowlege presented is obsolete -- considering that the hands-on Slackware approach often leads to true and deep understanding. Unless you're too intimidated to experiment, you can learn a great deal, even from a two-year-old text.

This book is eminently readable. Readers with some technical background will appreciate the slightly geeky, no nonsense approach, while users new to Unix in general will benefit from the quality explanations. When the publishers see fit to release a 5th edition of this book, it deserves very serious consideration.

[You can purchase this book at FatBrain.]

Title (Author) Linux Essential Reference (Ed Petron) Publisher, ISBN New Riders, Included Stuff none Intended Audience Users and administrators already comfortable with the command line. Scope Common and uncommon commands and switches. If you can imagine a task, it's likely listed here in glorious detail. Technical Correctness Good. Writing style Reference style -- very concise, little prose. Not something you'd read straight through. Trust me. Other The organization by topic here is nice. I've used it a few times already, just to look up something I knew had a command option somewhere.

For the user already familiar with shell basics, running programs, and using 'shutdown' instead of flipping the switch, a reference of commands and options might come in handy. That's the idea behind Linux Essential Reference. If you already know what you want to do but not how to do it, flip to the appropriate section and discover all of the little timesavers and niceties you've always wanted but never knew existed.

What sets this book apart from other works, including the man and info pages, is the excellent organization. Not only are commands grouped by category, the sections are (roughly) arranged according to complexity. (Although if you're not familiar with cd, mv, cp, and at least pico before looking something up, get thee to a tutorial!) For example, the Kernel chapter subsections are, in order, 'Installing New Kernels', 'Using Modules', 'Device Files', 'The /proc Filesystem', and 'Kernel Message Logs.'

Rather than reformatting man pages, the author has gone to quite a bit of work, rewriting often terse descriptions into longer examples. This is helpful with the lesser-known options (ls -T 4). The amount of detail, more than in any other work, makes this a good reference. (If you do read it all the way through, you'll have something to put on your technical reviewing resume.)

As seems to be usual, this book is divided into a user section and an administrator section. Administration gets a stronger treatment here, with information on LAN-specific tools. It's not limited to the home user's point of view, which makes it more useful to system administrator-types. The security chapter, including tcpwrappers and ipchains configuration, stands out as informative, though brief.

This book answers the question, "Okay, now what?" If you're feeling experimentative after polishing off one of the others, but you want a little more direction than the command prompt usually provides, having this book on your desk will prove valuable.

[You can purchase this book from ThinkGeek.]

Madman Chromatic (coder, writer, thinker) sheds even more light on the books lurking on store shelves designed to lure, and then snare, new or uncertain users into trying out -- and actually enjoying! -- this wacky "Linux thing." This time around, the texts he's chosen cover the topics of installation and day-to-day operation of a Linux system in greater depth than the Dummies series dares to, but they're still aimed squarely at competent, literate users rather than only at technical gurus. Read on for his insights into Using Linux, Linux Configuration & Installation, and the Linux Essential Reference.

Various Introductory and Reference Books author (Varies by title) pages n/a publisher (Varies by title) rating n/a reviewer chromatic ISBN (Varies by title) summary Three books intended to provide clear guidance and reference to the Linux sysadmin

This week's edition takes a look at three very different books. We have tutorials, theory and techniques, and thick juicy slabs of opts. Step through instructions and stay on the sidewalk, get your hands dirty on your own if you're the trailblazing type, or read up on what you always thought someone should code, if you're stuck at your desk.

Title (Author) Using Linux (Jack Tackett, Jr / Steven Burnett) Publisher, ISBN QUE, 0789717468 Included Stuff none Intended Audience RedHat users. Scope Installation and basic introduction to Linux. Technical Correctness Occasional weird advice. (In one spot, the authors describe a very insecure PATH setting without explaining that it's dangerous.) Writing style Varies with chapter author. Other Two-thirds of the way through the book, there are a number of mildly annoying typesetting errors. Unfortunately, they tend to appear near literal command-lines. Hopefully this will be corrected in a second edition.

Using Linux is a cross between a reference-book and a tutorial. Each chapter takes a different subject (Networking, Working with Hard Drives) and breaks it up into common tasks -- each listed in the copious table of contents and the large index. For example, if you're interested in setting up a file system, you can flip right to page 495 and choose between the RedHat tool or editing /etc/fstab yourself. Though RedHat tools receive a lot of attention, they're not presented as the only way to get things done. In a pinch, you'll find command line equivalents for common tasks given near the graphical description.

Accompanying the chapter text are occasional sidebars. These label figures, give a bit of historical perspective, and dish out useful tidbits of information that don't fit into the normal flow. This is less distracting than the usual approach of goofy icons and inset boxes often found in other books.

What's nice about this book is that it covers more subjects than most of the others. It's thick, but not unreasonably so. It's easy to read, but packed with details. Instead of covering only the handful of things every (home) user will need, the authors add information about removable drives, fax configuration, and file system cleanup, to name a few topics. Also nice is a brief chapter on building installations from source code (both make and Imake style systems) -- there's another world out there beyond RPM.

The task-oriented approach doesn't spend much time on theory, preferring a gentle overview and usage specifics. Obviously, there's more to learn than what's presented, but people more interested in results will prefer this decision. The system administration section really stands out, for an introductory book, and the appendix listing common Linux commands and glossary of terms will come in handy.

All things considered, this is a solid book. The breadth of information is good, and the flow of topics means it's readable from start to finish. Occasional flaws detract slightly, but they're not fatal.

[You can purchase this book at FatBrain.]

Title (Author) Linux Configuration & Installation (Patrick Volkerding, Kevin Reichard, Eric Foster-Johnson) Publisher, ISBN M&T Press, 0764570056 Included Stuff Slackware 3.5 CD-ROM, with extra disk full of additional programs. Intended Audience The do-it-yourself type. No prior Unix knowledge is necessary, though some experience with the command line will come in handy. Scope Installation and introduction to Slackware. Very good overview of the general Linux way to do things. Technical Correctness Quite good. Writing style Easy to read, though still technical. Other The version reviewed is the 4th edition -- somewhat dated (1998), but not out of touch. If there's a newer edition, get it! If not, you won't go astray with this one.

With help from Patrick Volkerding (Slackware creator) himself, this book teaches the do-it-yourself distribution. Expect a tremendous amount of detail -- in the first chapter alone, there are dozens of links to a Web site for more information about Linux and particular hardware. Fully half the book falls under installation and initial configuration issues, though this includes tinkering with your window manager, setting up networking, and recompiling your kernel (topics usually saved for later in other books). The fourth edition added a section on Slackware and portable computing, with pages of links to information on particular laptop models and information on synchronizing your Palm Pilot.

Chapter seven introduces the command line (though people following along will have used it -- with gentle prodding). It's a whirlwind, 50-page tour that explains a bevy of tools and tricks both concisely and thoroughly enough for day to day work. Following that are applications -- text editors, text formatters, graphics viewers, and the like. A short section on system administration covers scheduling, managing accounts, checking performance, but relatively little about security. Finally, chapter ten delves in to Linux programming -- toolkits, languages, tools, and scripts. Maybe the hors d'ouvres will whet your appetite to learn more, or at least help you with the magic "./configure; make; make install;" incantations.

The appendices list additional sources of information and the contents of the CD-ROM. Don't overlook the supplemental information, either -- including 30 pages of extra package description. (If you're going to install Slackware yourself, you ought to know what you need and what additional options there are.)

The only reason to overlook this book is its age, which is a shame. Things haven't changed so much that the knowlege presented is obsolete -- considering that the hands-on Slackware approach often leads to true and deep understanding. Unless you're too intimidated to experiment, you can learn a great deal, even from a two-year-old text.

This book is eminently readable. Readers with some technical background will appreciate the slightly geeky, no nonsense approach, while users new to Unix in general will benefit from the quality explanations. When the publishers see fit to release a 5th edition of this book, it deserves very serious consideration.

[You can purchase this book at FatBrain.]

Title (Author) Linux Essential Reference (Ed Petron) Publisher, ISBN New Riders, Included Stuff none Intended Audience Users and administrators already comfortable with the command line. Scope Common and uncommon commands and switches. If you can imagine a task, it's likely listed here in glorious detail. Technical Correctness Good. Writing style Reference style -- very concise, little prose. Not something you'd read straight through. Trust me. Other The organization by topic here is nice. I've used it a few times already, just to look up something I knew had a command option somewhere.

For the user already familiar with shell basics, running programs, and using 'shutdown' instead of flipping the switch, a reference of commands and options might come in handy. That's the idea behind Linux Essential Reference. If you already know what you want to do but not how to do it, flip to the appropriate section and discover all of the little timesavers and niceties you've always wanted but never knew existed.

What sets this book apart from other works, including the man and info pages, is the excellent organization. Not only are commands grouped by category, the sections are (roughly) arranged according to complexity. (Although if you're not familiar with cd, mv, cp, and at least pico before looking something up, get thee to a tutorial!) For example, the Kernel chapter subsections are, in order, 'Installing New Kernels', 'Using Modules', 'Device Files', 'The /proc Filesystem', and 'Kernel Message Logs.'

Rather than reformatting man pages, the author has gone to quite a bit of work, rewriting often terse descriptions into longer examples. This is helpful with the lesser-known options (ls -T 4). The amount of detail, more than in any other work, makes this a good reference. (If you do read it all the way through, you'll have something to put on your technical reviewing resume.)

As seems to be usual, this book is divided into a user section and an administrator section. Administration gets a stronger treatment here, with information on LAN-specific tools. It's not limited to the home user's point of view, which makes it more useful to system administrator-types. The security chapter, including tcpwrappers and ipchains configuration, stands out as informative, though brief.

This book answers the question, "Okay, now what?" If you're feeling experimentative after polishing off one of the others, but you want a little more direction than the command prompt usually provides, having this book on your desk will prove valuable.

[You can purchase this book from ThinkGeek.]

Some writers on the Free software movement speak as if the kernel hackers, security experts and fanatical sysadmins who drive Linux and other Free operating systems are martyrs -- folks who may code out of love, but who ultimately are on what could be seen as a suicide mission rather than a milk run. The typical free software guy (and in fact, the typical software guy, period ) gets treated as a one-dimensional character, with the projects they work on reduced to meaningless blurbs. Peter Wayner knows better -- he takes to heart the notion that history is written by the winners, and proceeds to write history. Read on to see why I'm recommending his new book Free For All to my father. A correction: Theo de Raadt (whose name I had originally mispelled, sorry Theo) pointed out that I'd slipped in "Open" where I should have said "Net." Apologies to all involved in each.

Free For All author Peter Wayner pages 340 publisher Harper Business rating 8.2 reviewer timothy ISBN 0066620503 summary From-the-trenches history in the making, a survey course on how, why and when Free software took over.

Future Perfect Free For All's subtitle ("How Linux and the Free software movement undercut the high-tech titans") well expresses the attitude that Wayner lets filter through every page of this book. Wayner writes as if from the perspective of a computer historian 10 or 20 years from now, mentioning casually the tools and methods which allowed (past tense) the Free software movement to flourish as if dismissing in many cases the overwhelming dominance of closed software today. Most desktops, it's true, are running some version of Windows, and despite the popularity of Linux and the BSDs, there are still chickens left to hatch before the count. But in the 1920s and 30s, there were still plenty of horsecarts, too: Wayner proclaims that the internal combustion engine of the day is the virtual engine under the hood of our computers.

It's a forgiveable act of hubris, though, considering that Wayner also points out the plentiful high ground that Free software has newly gained, recently regained, or never lost claim to, and it's a convincing list. Slashdot readers, for instance, may know that Apache serves the majority of today's Web sites, but does the average Barnes and Noble browser, even in the computer section, know just what Apache is? This book wastes few opportunities to point out areas where Free software is the obvious best choice, not just a grin-and-bear-it low-cost alternative to something better.

Historical perspective Wayner sets most of this book in the 1990s -- the reference to Linux in the title makes that a clear and sensible decision -- but makes frequent and welcome trips back in time to temporal locations from the age of Big Iron in the 1960s to Richard Stallman's 1984 GNU Manifesto. To those of us born in the 1970s or later, these episodes serve as welcome reminders of all the history we can learn of only through such means.

To that end, the book offers details and anecdotes about the creation of the Unix and Unixlike operating systems that are on the rise now, from the post-breakup copyright battles over the original source code of AT&T Unix to the serendipitous ignorance of Finnish student Linus Torvalds, who didn't know that there already was all-but-the-polish of a free Unix system already available.

It's not the case, though, that the entire Free software community is presented as one big happily family. More like an extended family with skeletons in several closets and some bickering both around the dinner table and otherwise, but for all that a generally harmonious bunch. The issue of licensing, and of hotly debated terms which might seem to an outsider hopelessly semantic, are raised at several points. Wayner contrasts Richard M. Stallman's vision of Free software (whether you see it as humble or grandiose) with the viewpoints of Eric Raymond, Bruce Perens and others. Stallman and the GNU project seem to get the lion's share of attention, with the obvious justification that without the GNU tools, a free Unix workalike would seem like a quixotic dream.

The time-shuttling approach that he takes with each chapter brings a benefit that makes this book an easy one to put down (for a few minutes, at least) -- it means that each chapter stands as an interesting monologue on some aspect of the Free software movement, and can be read as an enjoyable short essay. Taken together though, the chapters don't just entertain and milk nostalgia from silicon: they make a good case for the premise of the title. Ironically (if you see it this way) this means undercutting some of the arguments that Microsoft is a monopoly. Perhaps Microsoft was a monopoly, but the cut is made and the tree is toppling.

Interestingly, among the copious information about the origins and present state of the various BSD projects (Net, Free, Open), Wayner speaks a good deal about the whispered-about (and shouted-about) animosity between OpenBSD project leader Theo de Raadt and the developers of the other BSD varieties. While de Raadt spoke openly with Wayner, and the NetBSD developers seemingly did not, what ermerges is a slightly more interesting picture than I've seen before about this, and it confirms some positive things I've heard about the whole OpenBSD project. (A project which I think has caused improvement in many other software projects with its unyielding security focus.)

Minor Gripes Wayner's writing is informal -- no stiff upper lip here. That's not a bad thing, but the prose slips regularly into casualisms and jargon, parts of which work better than others, but none so distracting to detract greatly from the story being told. (As if I'm one to complain about that!)

The other problem I have with the storytelling in Free For All is the litany of rhetorical descriptions of hackers which are introduced in order to refute them for no clear reason. No, not all hackers have long scruffy beards; Yes, RMS and Alan Cox do. No, not all hackers are pale and anti-social; Yes, some of them are. Maybe its just that I've heard these things said before so many times that it just doens't seem relevant any more. Perhaps many of these "human interest" elements really will fascinate readers who'd not considered them before.

Recommended Reading Who should read this book? I mentioned that I'm recommending it to my father, for the simple reason that this is one of the few books I've seen which are down-to-earth readable but still meaty enough to walk away from with a satisfied feeling, not like you've just been Dummied.

In fact, it reminds me of Stephen Levy's Hackers, in part because it shares a sense of exhiliration and admiration for the people involved, as well as a freewheeling, back-to-the-story-in-progress story telling style. The hackers who make the BSD projects run, and the Linux kernel expand and shrink as code is cultivated and reined in, may be inspired software geniuses. But they share in the unglamorous, painstaking dogwork as well as the glory, and beam a kind of virulent enthuiasm for the cool stuff they're constantly on the cusp of. Wayner gives an over-the-shoulder peek at what that means which doesn't require a C.S. degree, and serves as its own character glossary.

Add this book to the pile that includes Hackers, The Secret Guide to Computers and Open Sources for readable, fascinating, fun computer history that's also relevant for your pointy headed boss.

You can purchase Free for All at Fatbrain.

Tonight at The Usual is our now traditional LWCE mega party. This time it's brought to us by OSDN, VA Linux, and all the assorted sites like Linux.com, Themes.org, SourceForge, ThinkGeek and what have you. The party is of course to celebrate the Debian 2.2 release. Music will be provided by San 'NeTTwerk' Mehat DJing and featuring Jon 'CowboyNeal' Pater scratching. The party starts at 8pm and continues well past my bed time.

Alex Bischoff asks: "At work, I'm forced to suffer in my cubicle with overhead fluorescent lighting. So, I've given some thought to building a "roof" to block out that light, at which point I could use my own incandescent lighting to light the area (or perhaps an Eclipse Computer Light). Anyhow, at first I was going to just drape a sheet across the top of the cubible walls, and weigh them down somehow. But, after some thought, I'm thinking that might be too low, as the cubicle walls are only about five feet high (so would "stilts" for the sheet work?). So, has anyone built a 'cubicle roof' before? Any ideas on how to go about this?" Maybe a 'cubicle tent' would be more appropriate here? Especially for those cubicle warriors who are unusually tall.

Cliff Lampe sheds light today on a book that he actually reviewed in the year 2003, but which due to a glitch in the Slashcode has appeared today. What would you do in a world where privacy is non-existent, and certainty absolute? How would you act? It's interesting to consider how ubiquitous observation and long-term record keeping cause us to approach this mythical world (at least in certain aspects of our lives) even without wormholes.

The Light of Other Days author Arthur C. Clarke and Stephen Baxter pages 316 publisher Tom Doherty Associates rating 8 reviewer Cliff Lampe ISBN 0312871996 summary Solid, with strong characters and interesting ideas. The Scenario

It's a stone's throw into the future, and an aggressive Northwest coast company (hmmmm) has developed a new technology for sending data. Harnessing a small wormhole, people are able to send data through the worm hole instantaneously. Alright, suspend disbelief and give them the benefit of the doubt on that one. This piece is just in the very beginning, and things are gonna get a whole lot wackier as we go on.

Some sort of megalomaniac entrepeneur owns the company that patents this technology, as well as several media holdings. He realizes that light waves are just another form of information, and if he can send a wormhole to some programmed location, he gets the scoop on all of his competitors. What's it mean? He can examine documents on the desks of world leaders, catch the famous in all sorts of pecadilloes, and arrange coverage of natural disasters in intimate detail and immediately. As you may imagine, the government catches wind of this and things start going to hell. This is the most interesting central idea to this book. What happens when there is no privacy at all? When your neighbors could buy a machine that allows them to watch you shagging your girlfriend if they wanted to? How are people going to cope with such an open social environment?

But hang on space fans. While society is still reeling from this total loss of privacy, the company with the wormhole patent discovers that by adjusting its strnegth, you can actually watch things from the past as they happen. Eventually they work out sound and navigation, so you can in essence watch any point in history from any angle as many times as you want.

This is the other central theme of this book that makes it interesting. Faced with an infallible memory of events, do things get better or worse? We all lie to ourselves constantly. Memory is more of a negotiation between the brain and the psyche than any sort of reliable record. How do we survive when our illusions are stripped away from us, and we have no more excuses? Every one of your mistakes is there for you, to relive in technicolor as many times as it takes for you to slit your wrists. And soon, it's not only your own sins and errors that come back to haunt you, but those of your entire species. This book deals with the loss of our myths, illusions and constructed realities, and how we go about putting them all back into place.

What's Good?

The best part of this book is the strength of the central ideas. It is plain-old interesting to consider an eventuality where all pretenses of privacy are stripped away, where it becomes nearly impossible to drop off the grid. What lengths will people go to to avoid their spying neighbors? In the book, a secret society gets started to help some people hide themselves away, some people commit suicide and others just give in to it. What would you do?

Another fascinating aspect of this book is the rate of technological change that occurs in it. No sooner does society have to adjust to having no privacy in the present, but the technology shifts and they have to give up their privacy in the past as well as the wormhole is strengthened to allow real time observation of past events. People start to put wormholes in their heads to form some sort of thought collective (yes, like in Diamond Age) and the technology takes a further twist at the end of the book. This whirlwind tour of technological changes imparts a sense of how it must feel for the characters in the book.

Clarke and Baxter do an admirable job of weaving together their individual strengths as authors. The descriptions of the deep past, which is Baxter's purview, are compelling and the contributions of Clarke's are as obvious and as well produced. Baxter has proven to be a quality sci-fi writer and is ably supported by one of the mythic legends of the genre.

What's Bad?

The same whirlwind introduction of elements that are a strength of this story at times become ravelled at the edges and leave a feeling of plot holes. There were times that the story shifts so much that I felt like rubbing my neck in sympathethic whiplash pains. While this does create an impression of confusion that is appropriate to the central themes of the book, it is also distracting at points in the story.

Also, there is a good bit of this book that deals with the personal relationships of the main characters. It's not that these interactions are poorly done, it's just that I would have preferred that ink be spent on delving more into applications of the technology at the center of the story. Now, I'm not one of those wackos that is against any sort of attention to the personal lives of the characters in my sci-fi, but it seemed extraneous in this particular offering.

So What's In It For Me?

At the time of writing, this book is ubiquitous in airports and other places where they have paperback bestsellers available. The Light of Other Days is a perfect read for those types of "trapped-in-a-hellish-flying-box" kind of situations. It's a gripping, complex and thought-provoking book that does not get bogged down in obtuse situational plot devices.

While this may not ever become a classic of sci-fi, it is well worth the effort if you've been looking for something to read. This is definitely above the pack of recent sci-fi offerings and should catch your attention for some relaxing hours of speculation on how you would use your own personal wormhole.

Purchase this book at ThinkGeek.

Cliff Lampe sheds light today on a book that he actually reviewed in the year 2003, but which due to a glitch in the Slashcode has appeared today. What would you do in a world where privacy is non-existent, and certainty absolute? How would you act? It's interesting to consider how ubiquitous observation and long-term record keeping cause us to approach this mythical world (at least in certain aspects of our lives) even without wormholes.

The Light of Other Days author Arthur C. Clarke and Stephen Baxter pages 316 publisher Tom Doherty Associates rating 8 reviewer Cliff Lampe ISBN 0312871996 summary Solid, with strong characters and interesting ideas. The Scenario

It's a stone's throw into the future, and an aggressive Northwest coast company (hmmmm) has developed a new technology for sending data. Harnessing a small wormhole, people are able to send data through the worm hole instantaneously. Alright, suspend disbelief and give them the benefit of the doubt on that one. This piece is just in the very beginning, and things are gonna get a whole lot wackier as we go on.

Some sort of megalomaniac entrepeneur owns the company that patents this technology, as well as several media holdings. He realizes that light waves are just another form of information, and if he can send a wormhole to some programmed location, he gets the scoop on all of his competitors. What's it mean? He can examine documents on the desks of world leaders, catch the famous in all sorts of pecadilloes, and arrange coverage of natural disasters in intimate detail and immediately. As you may imagine, the government catches wind of this and things start going to hell. This is the most interesting central idea to this book. What happens when there is no privacy at all? When your neighbors could buy a machine that allows them to watch you shagging your girlfriend if they wanted to? How are people going to cope with such an open social environment?

But hang on space fans. While society is still reeling from this total loss of privacy, the company with the wormhole patent discovers that by adjusting its strnegth, you can actually watch things from the past as they happen. Eventually they work out sound and navigation, so you can in essence watch any point in history from any angle as many times as you want.

This is the other central theme of this book that makes it interesting. Faced with an infallible memory of events, do things get better or worse? We all lie to ourselves constantly. Memory is more of a negotiation between the brain and the psyche than any sort of reliable record. How do we survive when our illusions are stripped away from us, and we have no more excuses? Every one of your mistakes is there for you, to relive in technicolor as many times as it takes for you to slit your wrists. And soon, it's not only your own sins and errors that come back to haunt you, but those of your entire species. This book deals with the loss of our myths, illusions and constructed realities, and how we go about putting them all back into place.

What's Good?

The best part of this book is the strength of the central ideas. It is plain-old interesting to consider an eventuality where all pretenses of privacy are stripped away, where it becomes nearly impossible to drop off the grid. What lengths will people go to to avoid their spying neighbors? In the book, a secret society gets started to help some people hide themselves away, some people commit suicide and others just give in to it. What would you do?

Another fascinating aspect of this book is the rate of technological change that occurs in it. No sooner does society have to adjust to having no privacy in the present, but the technology shifts and they have to give up their privacy in the past as well as the wormhole is strengthened to allow real time observation of past events. People start to put wormholes in their heads to form some sort of thought collective (yes, like in Diamond Age) and the technology takes a further twist at the end of the book. This whirlwind tour of technological changes imparts a sense of how it must feel for the characters in the book.

Clarke and Baxter do an admirable job of weaving together their individual strengths as authors. The descriptions of the deep past, which is Baxter's purview, are compelling and the contributions of Clarke's are as obvious and as well produced. Baxter has proven to be a quality sci-fi writer and is ably supported by one of the mythic legends of the genre.

What's Bad?

The same whirlwind introduction of elements that are a strength of this story at times become ravelled at the edges and leave a feeling of plot holes. There were times that the story shifts so much that I felt like rubbing my neck in sympathethic whiplash pains. While this does create an impression of confusion that is appropriate to the central themes of the book, it is also distracting at points in the story.

Also, there is a good bit of this book that deals with the personal relationships of the main characters. It's not that these interactions are poorly done, it's just that I would have preferred that ink be spent on delving more into applications of the technology at the center of the story. Now, I'm not one of those wackos that is against any sort of attention to the personal lives of the characters in my sci-fi, but it seemed extraneous in this particular offering.

So What's In It For Me?

At the time of writing, this book is ubiquitous in airports and other places where they have paperback bestsellers available. The Light of Other Days is a perfect read for those types of "trapped-in-a-hellish-flying-box" kind of situations. It's a gripping, complex and thought-provoking book that does not get bogged down in obtuse situational plot devices.

While this may not ever become a classic of sci-fi, it is well worth the effort if you've been looking for something to read. This is definitely above the pack of recent sci-fi offerings and should catch your attention for some relaxing hours of speculation on how you would use your own personal wormhole.

Purchase this book at ThinkGeek.

Having tragically misplaced the crank on his hot-rodded Underwood, the singular Jon Katz had to revert to his backup activity, devouring words from other writers. Crank restored, here he reviews The Engines of Our Ingenuity, a book which sounds like excellent browsing material for anyone who enjoys reading Henry Petroski, Donald Norman, Stewart Brand or other techno-historical commentators.

The Engines Of Our Ingenuity author John Lienhard pages 262 publisher Oxford University Press rating 8/10 reviewer Jon Katz ISBN 0-19-513583-0 summary How technology and creativity have affected history.

In a timely and very entertaining new book, mechanical engineer and radio commentator John Lienhard recounts the history of human invention and the ways in which technology and ingenuity have affected human history, from the genetic mishap that created wheat, to the monks who built the first mechanical clocks, to the rise of modern computing.

For centuries engineers were a marginalized species, toiling away to design and build the modern world even though few people understood or appreciated what they did. But a few particularly literate engineers -- technologist/writers like Samuel Florman -- created a small but potent literary genre devoted to technology and its impact on society. John Lienhard's "Engines of Our Ingenuity" is a worthy example of this genre -- the author is a mechanical engineer and professional writer -- recounting the history of the world's tinkerers and technologists, from Archmides and his screw pump to the monks who came up with mechanical clocks (an artifact of medieval monasteries) to modern engineers.

Lienhard (who hosts an NPR radio program on technology and creativity believes that technology is a mirror of humanity, and his book is a highly readable affirmation of that theory. He writes about technology with humor, insight and a reservoir of historical perspective. He also warns about the dangers of unthinking technology, and of the technological hubris epidemic in America.

But Lienhard also chronicles one of the world's earliest genetic mishaps -- the accidental creation of modern what by starving farmers. This and other anecdotes provide a bit of pause in the age of the Human Genome Project, when it seems as if the tools to bend evolution's rules are close at hand.

Fittingly, he also refers to the Code of Hammurabi, one of the first codified systems of law, dating back to the days of Babylonian dominance. That code dictated that if a mason constructed a building which collapsed and killed the owner, the mason would be summarily executed. Imagine the bloodbath if modern engineers and inventors were held accountable that way.

"Getting things right is a far bigger worry in today's dense technology than it was thousands of years ago," Linehard writes. "Yet while we do not threaten to amputate surgeon's hands or kill engineer's children, our resulting technologies are still surprisingly safe. Only one person in ten million dies each year from the structural failure of a building. And tens of millions of Americans safely make commercial flights between the rare fatalities that do occur."

Lienhard also traces in Enginesthe strange ways in which technologies evolve -- like the fact that telephone companies took decades to figure out that people's interest in phones was primarily social, not commercial.

He offers an inventive take on the rise of the computer which, he suggests, basically invented itself. "We instinctively build machines that resonate with us," he says. "The technologies of writing and printing each altered the way in which we see the world. Each opened our eyes to the expanded possibilities they presented to us. Each profoundly changed our civilization."

This is not only an entertaining but an informative and useful book in a world in which technology has become a central social, cultural and economic force. Few people really want to talk much about it, or understand its history. Lienhard trains his sights on the intersection of technology and culture, and there could hardly be a more timely, entertaining or relevant book on the subject, especially for people who care about technology and it's impact on society.

Purchase this book at ThinkGeek.

Having tragically misplaced the crank on his hot-rodded Underwood, the singular Jon Katz had to revert to his backup activity, devouring words from other writers. Crank restored, here he reviews The Engines of Our Ingenuity, a book which sounds like excellent browsing material for anyone who enjoys reading Henry Petroski, Donald Norman, Stewart Brand or other techno-historical commentators.

The Engines Of Our Ingenuity author John Lienhard pages 262 publisher Oxford University Press rating 8/10 reviewer Jon Katz ISBN 0-19-513583-0 summary How technology and creativity have affected history.

In a timely and very entertaining new book, mechanical engineer and radio commentator John Lienhard recounts the history of human invention and the ways in which technology and ingenuity have affected human history, from the genetic mishap that created wheat, to the monks who built the first mechanical clocks, to the rise of modern computing.

For centuries engineers were a marginalized species, toiling away to design and build the modern world even though few people understood or appreciated what they did. But a few particularly literate engineers -- technologist/writers like Samuel Florman -- created a small but potent literary genre devoted to technology and its impact on society. John Lienhard's "Engines of Our Ingenuity" is a worthy example of this genre -- the author is a mechanical engineer and professional writer -- recounting the history of the world's tinkerers and technologists, from Archmides and his screw pump to the monks who came up with mechanical clocks (an artifact of medieval monasteries) to modern engineers.

Lienhard (who hosts an NPR radio program on technology and creativity believes that technology is a mirror of humanity, and his book is a highly readable affirmation of that theory. He writes about technology with humor, insight and a reservoir of historical perspective. He also warns about the dangers of unthinking technology, and of the technological hubris epidemic in America.

But Lienhard also chronicles one of the world's earliest genetic mishaps -- the accidental creation of modern what by starving farmers. This and other anecdotes provide a bit of pause in the age of the Human Genome Project, when it seems as if the tools to bend evolution's rules are close at hand.

Fittingly, he also refers to the Code of Hammurabi, one of the first codified systems of law, dating back to the days of Babylonian dominance. That code dictated that if a mason constructed a building which collapsed and killed the owner, the mason would be summarily executed. Imagine the bloodbath if modern engineers and inventors were held accountable that way.

"Getting things right is a far bigger worry in today's dense technology than it was thousands of years ago," Linehard writes. "Yet while we do not threaten to amputate surgeon's hands or kill engineer's children, our resulting technologies are still surprisingly safe. Only one person in ten million dies each year from the structural failure of a building. And tens of millions of Americans safely make commercial flights between the rare fatalities that do occur."

Lienhard also traces in Enginesthe strange ways in which technologies evolve -- like the fact that telephone companies took decades to figure out that people's interest in phones was primarily social, not commercial.

He offers an inventive take on the rise of the computer which, he suggests, basically invented itself. "We instinctively build machines that resonate with us," he says. "The technologies of writing and printing each altered the way in which we see the world. Each opened our eyes to the expanded possibilities they presented to us. Each profoundly changed our civilization."

This is not only an entertaining but an informative and useful book in a world in which technology has become a central social, cultural and economic force. Few people really want to talk much about it, or understand its history. Lienhard trains his sights on the intersection of technology and culture, and there could hardly be a more timely, entertaining or relevant book on the subject, especially for people who care about technology and it's impact on society.

Purchase this book at ThinkGeek.