Slashdot Mirror

bpfinn writes "Are you working on your own anti-spam solution? Would you like to compare notes with other coders? You'll get your chance at the Spam Conference in Cambridge on January 17, 2003. Among the speakers are: Paul Graham (of "a plan for spam" fame), ESR, John Graham-Cumming (of "POPFile" fame), and Matt Sergeant from MessageLabs. According to the homepage, this conference will be very informal: "no fees, sponsorships, proceedings, luncheons, contests, etc. Just a series of quick, concentrated talks, and then we all go off and get Chinese food." Slashdotters who are peeved about spam can register here."

zonker writes "January 17th will be the first (annual?) meeting of the Spam Conference held in Cambridge, Massachusetts. The informal meeting will feature Paul Graham, John Graham-Cumming, John "Cap'n Crunch" Draper among others (possibly including ESR though he hasn't yet confirmed). The free conference will consist of a number of talks about new ways to combat the growing spam problem, after which everyone's going out and getting some Chinese food. Should be an informative and fun meeting and a chance to meet some interesting people."

Missing Bookmarks asks: "I accidentally deleted my bookmarks. I lost my 'Lore' folder, where I was collecting links to the classic folklore of the computer science subculture - things like Ken Thompson's Reflections on Trusting Trust, The Tanenbaum-Torvalds Debate, Dijkstra's Go To Statement Considered Harmful, and The Alice and Bob after-dinner speech. I don't need anything from The Jargon File (like The Story of Mel), because that stuff is obviously easy to find. I've listed all the things I could remember; please help me find the ones I've forgotten."

Missing Bookmarks asks: "I accidentally deleted my bookmarks. I lost my 'Lore' folder, where I was collecting links to the classic folklore of the computer science subculture - things like Ken Thompson's Reflections on Trusting Trust, The Tanenbaum-Torvalds Debate, Dijkstra's Go To Statement Considered Harmful, and The Alice and Bob after-dinner speech. I don't need anything from The Jargon File (like The Story of Mel), because that stuff is obviously easy to find. I've listed all the things I could remember; please help me find the ones I've forgotten."

Slashback brings you another flurry of updates (below) on the recently reported Mozilla security leak, the Greek gaming ban (you'll never guess), the mega-hour TiVO mod mentioned earlier today, the long-term healthiness of the Atkins Diet, and more. Read on for the details.

Go ahead and get this one out of the way. Seth Scali writes: "The decision last week that ruled the Greek ban on video games as unconstitutional has been overturned, and a new trial has been ordered. Story from TheRegister is here. Don't take your GBA on that trip to Athens just yet ..."

It takes a strong man. Reader edrock200 submitted the story about a TiVO mod which could expand system capacity to more than 1000 hours of recording. The story as shown says that 9thTee is the card's developer; edrock200 corrects this "'The QuadCard, like the AirNet and TurboNet adapters also sold through 9thTee, were developed by a TiVo user named Nick Kelsey (known as 'jafa' on the TiVo Community Forum.) 9thTee is the distributor - though I don't want to take anything away from them, they have been remarkably supportive of the TiVo community and they deserve kudos for taking the financial risks of selling these add-ons.'

'It is truly amazing what Nick has been able to do with his electronics expertise.'"

Thanks for the clarification!

The Lizard sleeps with one eye open. An anonymous reader writes "MozillaZine have updated their article on the recently reported minor security bug in Mozilla [Note Slashdot posting]with the news that a fix has been completed. The bug allowed the webmaster of a site to find out where a user went after their site. The fix means that there are again no known security bugs in Mozilla. Presumably, updates to Mozilla-based browsers (Netscape, Galeon, Chimera etc.) will follow."

What about the all-shrimp-and-chili-paste diet? Schlemphfer writes "A few months back, Slashdot featured a NY Times story that talked about the Atkins diet in glowing terms. This week, the Times has published a Jane Brody article raising serious questions about whether Atkins-style diets are dangerous and unsustainable. Brody is one of the most prominent and respected nutrition journalists, so it's worthwhile to read her take on the matter. Brody's article, which cites some important new research, may be an eye-opening read for Slashdot readers who took the plunge with Atkins back in July." (The NYT requires free registration.)

Suddenly everyone is in deadly earnest. Ian Cumming was one of several people to write with evidence of smileys predating the smileys unearthed by Mike Jones of Microsoft Research. He forwarded an informative message from Brian Dear of Birdrock Ventures, which reads in part:

"On the PLATO system, emoticons were much richer -- made using multiple characters displayed on top of each other. It was possible to type, say, a single character, then press SHIFT-space (which moved the cursor exactly one space backwards), then type another character. The second would display on top of the first. You could keep doing this for multiple characters and create many different faces, beer glasses, martini glasses, all kinds of things. And people peppered their emails and notesfile (PLATO's newsgroups) postings with them all the time."

And what is the PLATO system? The short version is this: PLATO was (is) an education-centered computer system developed at the University of Illinois at Urbana-Champaign. Luckily for you, Dear is writing a book about PLATO. His site is fascinating, and the book promises to be as well. Here is a page showing the richness of PLATO emoticons.

Reader Grant Barrett also writes: "The earliest (not first: you can never precisely say which was first) recorded smiley in print discovered so far was found by etymologist and word researcher Barry Popik who posted this message to the email list of the American Dialect Society. He discusses the yellow smiley face which everyone knows, but this particular smiley is the familiar punctuation-based emoticon. (On a side note, he has uncovered some evidence that Harvey Ball *did not* invent the familiar yellow-faced smiley.)"

That reference puts the typographic smiley all the way back to 1953, and as Barrett mentions, was in print rather than online. He also points out that "ESR's Jargon File cites a 'rival claim by Kevin McKenzie, who seems to have proposed the smiley on the MsgGroup mailing list, April 12 1979.'"

But there's only one groove per side ... To all those who thought that the optical-scanning method for playing vinyl was an elaborate joke, note that you can download the creator's code if you'd like. This is not the easy way to do things, but is one way.

PizzaFace writes "Personal communication devices always allowed people to communicate easily and to coordinate their plans at the spur of the moment. As PCDs became widespread, they allowed their owners to converge rapidly in large groups, for purposes social or political. Now something else is happening. Ubiquitous PCDs give each owner multiple simultaneous opportunities for communication or convergence. People surf their PCD network from one conversation to another, and physically surf the most promising of the gatherings to which the network invites them. Their web of social contacts is as broad as the globe and as shallow as a cell phone's keystroke. What happens when people become nodes on a network? Joel Garreau reports provocatively in the Washington Post. His sample is skewed by Washington's summer influx of interns, who come from around the country to work for little or no pay in part because they're chasing 'peak experiences,' and who have lots of disposable time and energy, no local roots or tethers, and an unusually large network of like-wired acquaintances." I think the conventional (and most descriptive) term for this behavior is flash crowd.

Russ Nelson writes "The Public Software Fund's first project has been funded for two months worth of development. Tom Jennings (of Fidonet fame) will be writing software to do peer-to-peer file sharing of free software RPM packages, improving the existing free software packages up2date, /current/, and BitTorrent. This will keep new distro releases from being slashdotted."

guanxi writes: "IEEE Spectrum has an interesting article about hacking and specifically, the "hacker's nirvana on wheels", all the way from hot-rodding to reprogramming your digital ignition. Of course, I neither endorse nor recommend any of the procedures mentioned, any of which may be inherently dangerous to your life and your warranty. "

Politech has a couple of good articles on political developments in the post-Napster world. (That's almost a Katz phrase there, isn't it?) The folks behind Kazaa, when they're not busy spying on their userbase, took the time to write to the Senate Foreign Relations Committee after a bashing they took a few weeks ago. Kazaa's new owners suggest a general royalty fee, perhaps similar to the recent webcasting fees, be put in place to compensate intellectual property holders for file-sharing. Meanwhile, the European Commission takes a look at digital rights management. Looks like Europe will get its own version of the SSSCA.

guanxi writes: "This article by James Fallows in The Atlantic is one of the most interesting I've read all year. It describes how innovators in government are applying the concept of the Bazaar: The many eyes of 'Open-Source Intelligence' movement that provides better intelligence than classified sources, and a b2b-like marketplace created by World Bank employees that distributes aid more efficiently than the bureaucratic process."

woggo queries: "I'm a CS grad student working on a large research project (over 1 million lines of code, supported on many platforms). The project has been under development for several years, and the build system is nontrivial for end-users. We'd like to make it easier to build our software, and I'm investigating the feasibility of migrating to GNU autoconf. I need to demonstrate that the benefits of autoconf outweigh the costs of migrating a large system of makefiles with a lot of ad-hoc kludge-enabling logic. Has anyone made a similar case to their advisor/manager? Does anyone have some good 'autoconfiscation' war stories to share? (I've already seen the Berkeley amd story and the obvious links from a google search....)" Depending on the intricacies of the build process, such a conversion might take an awful lot of work. It might be easier to put a nicer face on the "nontrivial build process", although there is something to be said for the ease of "./configure; make; make install"

MrHat writes: "Eric S. Raymond's CML2, or 'Configuration Menu Language' -- part of the next-generation Linux kernel build system -- is now officially ready for 2.5. CML2 includes a compiler for a domain-specific configuration language, used to configure kernel subsystems and resolve dependencies between them. CML2 and Linux 2.5 will 'ship' with several different configuration interfaces, including an adventure game, whipped up by ESR during an extended flight. The story from the horse's mouth (or LKML, if you prefer):'This release resolves all known logic bugs and rulebase problems. The only things left on the to-do list are convenience features and some minor improvements in the test/coverage tools. This code is now officially ready for the 2.5 fork.'"

Randy Rathbun submitted a Reuters article about the arrest of Dmitri Sklyarov. Cryptome has collected the press release and criminal complaint filed against Sklyarov by the United States, at the urging of Adobe Corporation. The complaint specifically mentions the ROT-13 "encryption" used by at least one "protected ebook" company, so the jokes made about the DMCA before are now true: crack ROT-13, go to jail. Sklyarov is currently imprisoned without bail. We've received a note that another Russian developer who was at the conference with Sklyarov has posted more information about the arrest - can someone provide a translation in the comments? Update: 07/18 10:57 PM by S : This Las Vegas Sun Article provides more interesting details (Thanks to possible for the link).

brent_linux writes: "ESR has developed a new kernel configuration system called CML2. Recently (as in yesterday) he posted to the kernel mailing list that he had added a new configuration for Expert Users. This new interface follows the interface developed from the old infocom text based adventure games. Commands such as 'look,' 'nearby,' and 'go' are used to navigate and options are items that you 'take' or 'put.' Check out the mailing list for his messages or download CML2 for yourself and check it out."

People who love sausage and respect the law should never watch either one being made. Law professor and copyright expert Jessica Litman takes a hard look at the process which makes copyright law, and most readers will likely finish her new book, Digital Copyright, with their respect for the law substantially lessened. This is the book for everyone who has ever gotten fed up with IANAL posts and wanted answers that were a bit more informed, everyone who's gotten tired of soundbite analysis of Napster and overheated mailing list discussions. If you're looking for one book to help you understand the Digital Millennium Copyright Act and the past and future of copyright law, this is it.

Digital Copyright author Jessica Litman pages 208 publisher Prometheus Books rating 10/10 reviewer Michael Sims ISBN 1-57392-889-5 summary how copyright law is like sausage-making

For a free introduction to Professor Litman's work, you may want to see her webpage, taking special note of the various articles and papers linked at the bottom. Several of her previous articles have been revised into chapters of Digital Copyright, so if you don't find them interesting, the book isn't likely to interest you (though the book is written for a slightly more general audience than the papers).

Almost every discussion of copyright on the web degenerates into name-calling between a faction that insists "copyright is property - you're STEALING!" and a faction that insists "copyright is a bargain between the public and producers, it exists solely to promote the progress of science and the arts, and the producers are trying to gouge the public within an inch of its life". Litman's book will show you the roots of those two viewpoints, the heavy propaganda effort by the copyright industry that has made that shift in law from the second to the first and is trying to make that shift in public perception, and you'll be one up on the average copyright debater.

She goes into excruciating, fascinating, absorbing detail about the process that produced current copyright law and is highly likely to produce future copyright law - the bribes to Congress, the back-room deals, the slimy public relations tactics, the elected officials who don't want to spend the time to learn about a tangential, unimportant issue like copyright. The history of copyright law shows that this is not a new issue - these same battles have been fought over each new medium of storing or transmitting information, and Litman mentions, at least briefly, each of those battles. With each new medium came an expansion of copyright law to cover that medium and a narrowing of the rights of readers/viewers/listeners, until we've reached the Digital Millennium Copyright Act, which arguably allows publishers cradle to grave control of every copyrighted work they produce.

One of the major themes expressed in the book is the disconnect between how the average layman supposes that copyright law is and how it actually works. In general, people who haven't read copyright law have many misunderstandings about it, and often refuse to accept the real law when it is presented, because it doesn't make a lot of sense and they have a fundamental belief that law should make sense. Indeed, the odds are (at least in my experience) that any individual random person asserting facts about copyright law is dead wrong.

When you have laws that have been written and revised for one hundred years with no significant input from the public, only people who want to maximize their profits from the resulting law, there's going to be a disconnect.

And that's the "sausage" aspect of this book. Most people respect the law, even copyright law, even if they don't understand it (they obey what they think the law is, or what they think it should be). But after reading this book, I think most people won't respect copyright law any more - they'll realize that copyright law is just a method for a very few companies and industries to maximize their profits at the public's expense, and they'll simply cease to respect it. I'm not at all certain this is a bad thing. A little less respect for authority would probably do American society some good. But be aware of the consequences: if you want your daughter to grow up thinking that making an MP3 from a CD you own is theft, don't use this book for bedtime reading. It will warp impressionable minds.

Chapter 1, Copyright Basics, is just as you'd expect: an overview of copyright law. It's not deep, but the rest of the book does not require in-depth knowledge of copyright law. It's a book written for a popular audience, with enough footnoted references that scholars won't be disppointed or short-changed.

Chapter 2 is available online (so is the introduction). Litman maps out where she intends to go in chapter 2, so it's really the best sales pitch for the book: read it, and you'll either be hooked or not.

Chapter 3 covers compromise - the compromise between copyright interests that creates modern copyright law. When you realize that Congress literally and explicitly (and apparently, shamelessly) rubber-stamps the law written from start to finish by corporate copyright interests, you may feel the bile rise in your throat.

Chapter 4 is a short thought experiment: if you were a lawyer representing the public, and the "bargain" of the 1976 copyright statute was presented to you, would you accept it?

Chapter 5 is an important chapter for advocacy efforts. It covers metaphors, and the important role they play in debate. We've seen this play out in recent news as perjorative terms like "pirate" are applied to organizations like 2600, which, after all, is not even accused of copying a single thing unlawfully, while the New York Times and other large publishers, which freely admit that they copied tens of thousands of articles which they had no rights to in order to sell them for a profit, are called pirates by no one (one newspaper article, in the Christian Science Monitor, mentioned that the individual writers describe this as "cyber-piracy" - that's the closest I got to an adverse characterization of the publishers' position). This "piracy gap" illustrates perfectly Litman's point - controlling the metaphor for any given debate or conflict is of utmost importance.

Chapter 6 covers the collision between copyright lawyers and computers/the internet. Imagine: a world where every single use of any piece of information involved making a copy, if only in a computer's RAM. Suddenly, the right to "make copies", which once covered only the initial production of copyrighted materials, is invoked with every single usage of a material. And instead of revising the law to have roughly the same effect as it used to, copyright interests seized on revising the law in favor of its letter, not its spirit. (Though Litman doesn't mention Lessig here, she's making exactly the same argument that Lessig is in his book Code and Other Laws of Cyberspace , and I wish it was expanded just a bit.) The chapter generally covers the efforts in the early 1990's that will lead up to the Digital Millennium Copyright Act.

Chapter 7, Creation and Incentives, examines what sort of incentives are actually needed to get people to create copyrighted works. In the face of all evidence, the copyright industry argues that massive incentives are needed. There's a great hypothetical, which I won't ruin for you here, that looks at the copyright incentives needed in two major industries today.

Chapter 8 is titled "Just Say Yes to Licensing!". I don't think I really need to discuss the subject matter here, do I? She points out that the paper which led to the DMCA recommends massive citizen re-education programs - since the law didn't fit with public perceptions, clearly the public's perceptions were at fault, not the law.

Chapter 9 covers the DMCA's passage - each little bargain hammered out by one copyright interest or another, all at the public's expense.

Chapters 10 and 11 cover Napster, DeCSS, and similar areas that regular slashdot readers will be familiar with.

The final two chapters examine the requirements for a digital copyright law that will comport with the expectations of Americans - whose expectations include items like being able to read a work they've published on a device of their own choosing without violating copyright law - and yet still provide an incentive to authors. Although there is nothing wrong with the solution Litman proposes, one gets the impression that it is a sort of pro forma exercise, that she knows there is no realistic hope of her solution being implemented.

Overall, the work is both a strong piece of scholarship (Litman has been studying this for years, and it shows in every footnote) and solid read. Readers on a budget can get the flavor and most of the arguments by reading her papers online, but the work as a coherent whole is solid addition to the library of anyone who cares about copyright issues. Highly recommended.

I'd like to also mention another book about the DMCA, one that I'm not going to do a full review on. Marcia Wilbur has a self-published book titled DMCA, which can be located through various booksellers. I received a copy from the author, and it is about as different from Digital Copyright as night is from day. DMCA draws very strongly from online debates -- it's fast-paced, rushed, very much a persuasive work rather than an informative, scholarly one, and could use some serious copy-editing. Nevertheless, it's an interesting read, and the only paper work I've seen to date that accurately captures the flavor of online discussions about the DMCA.

You can purchase Digital Copyright at Fatbrain.

Mark Bainter writes: "ESR has released CML2 the new config tool for the linux kernel. I'm sure the softies amoung us will love it, but frankly I think it sucks. Half the things listed as features I'd list as bug reports. A few "highlights": In CML2 it will automatically select and deselect required features related to the option you are manipulating. Options don't appear at all when not needed instead of being greyed out, and the language has been changed to declaritive instead of imperitive. And last but certainly not least, it runs on Python." Interesting discussion on the current kernel traffic about the new tool, too -- but it sounds mostly positive. Thank you, Eric, for bringing arcane kernel issues closer to earthlings.

For those inundated with data -- numbers, names, dates, temperatures, colors, seismographic sensor output, voting records(!), or anything else -- the paltry concerns of user interface may be less important than the assurance that they can make something useful from all that stuff. Data munger extraordinaire chromatic has again delivered his insightful dissection of a programming book aimed at people with Perl knowledge and a lot of data to wade through, and No, it's not from O'Reilly. Maybe it's for you.

Data Munging with Perl author David Cross pages 283 publisher Manning Publications rating 9 reviewer chromatic ISBN 1-930110-00-6 summary Dave explores Perl's unique and compelling abilities tomanage and manipulate data of all types, sizes, and shades.

The Scoop Larry Wall, so goes the story, needed to glue together two systems on opposite sides of the country. Calling on the virtues of Laziness (why throw together something for just one job) and Hubris (why not write a new language?), he created Perl. Though it's found new niches in the post-web world, Perl earns its bread and butter munging data.

Dave Cross has put together a friendly and handy compendium of techniques, tricks, and best practices. Suitable for raw novices to experienced intermediates, Data Munging with Perl is a gentle but firm romp from flat text, past structured and binary files, to the realm of custom parsers. Clean examples and lots of modules accompany the explanations.

What's to Like? The book plots a natural course through topics ordered by complexity. It opens with a theoretical overview of data processing. This introduces terminology and outlines the general types of data one might encounger. Additionally, the author writes with the authority of experience when exploring the basic approaches and best practices. While other books aimed at novice users shy away from programs-as-filters and data structures, Cross prefers to instill good habits from the start.

Beyond munging data, the book provides a decent introduction to idiomatic and effective Perl programming. While the brief tutorial won't magically produce new JAPHs, the thoughtful and continual devotion to good technique and skill will inspire smarter programmers. More important than knowing many useful tricks is knowing when and how to use a handful of tools -- and where to go for more.

The overall level of quality is excellent. The binary data chapter stands out as the clearest explanation available, and the information on munging dates and times will save readers plenty of grief. Additionally, the entire parsing section introduces a handful of powerful but sorely-underused tools to handle HTML, XML, and even creating custom parsers. Rounding out the curriculum is an appendix that explores the larger modules, mentioned earlier, in more detail (XML::Parser, DBI, Date::Manip).

What's to Consider? Only two things might turn readers from this book. The first is its deceptive length. While the text is short, the examples are clear and the text packs a lot of wallop in what's there. Careful readers who follow the links to other resources will have little trouble supplementing their education. (On the other hand, another ten pages describing Parse::RecDescent would have been a nice addition. It's hard to fault the author for deferring to the module's voluminous documentation.)

Second, longtime Perl programmers may find little new material, particularly if they are familiar with the wealth of modules on the CPAN. The intended audience is clearly new and underexperienced programmers. While there's plenty of good advice presented well, the book falls more toward the tutorial side of the aisle than the reference section. This does not detract from the book, but it does narrow the base of potential readers slightly.

The SummaryManning Publications continues its fine line of Perl books with the consistent and powerful Data Munging with Perl. Coders looking to transform data somehow and hackers who want to take advantage of Perl's unique features will improve their knowledge and understanding. If you find yourself working with files or records in Perl, this book will save you time and trouble. Table of Contents

1. Introduction
2. 1. Data, data munging, and Perl
   2. General practices to use when munging data
   3. Generally useful Perl idioms
   4. Pattern matching
3. Data Munging
4. 1. Unstructured data
   2. Record-oriented data
   3. Fixed-width & binary data
5. Simple Data Parsing
6. 1. More complex data formats
   2. HTML
   3. XML
   4. Building your own parsers
7. Conclusion
8. 1. Looking back -- and ahead
   1. Modules reference
   2. Essential Perl

You can purchase this book at ThinkGeek.

An Anonymous Coward writes: "According to Eric S. Raymond in this article, 'hackers don't have to be helpless chum in the dating-game shark pool. We have some advantages; with a little understanding of human ethology we can learn how to use them effectively.'" Anyone who says brains aren't sexy doesn't get turned on by a liter of gray tissue.

Steven Levy's Crypto is a brief history of the men involved in developing modern cryptography. If you've read Applied Cryptography or another work with a mathematical emphasis on crypto, you've heard their names -- Diffie, Hellman, Chaum, Rivest, Shamir, Adleman, Zimmermann, and so forth. But the other books on cryptography typically neglect the human side in favor of the math. Crypto aims to fill that hole.

Crypto author Steven Levy pages 356 publisher Viking/Penguin rating 9/10 reviewer Michael Sims, drfalken, topeka ISBN 0-670-85950-8 summary A history of the people involved in developing modern cryptography

Several people were interested in reviewing this book. We try to be accomodating, so this is a mega-review by myself and slashdot readers drfalken and topeka. I'll try to be brief.

Michael's review:

I didn't expect to like Crypto. I was frankly put off by the subtitle on the front cover: "How the Code Rebels Beat the Government -- Saving Privacy in the Digital Age." Every time I send an unencrypted email (because none of my correspondents use encryption, because it isn't built-in) or think about the law (CALEA) which requires my ISP and telephone company to accomodate the government in wire-tapping my communications, I realize that this just isn't true. While the cryptographers thought they were winning battles, the government has so far been winning the war. From the sub-title, I expected the book to be a rah-rah cheerleading history of these noble crypto-knights wielding their ciphersabers with gleeful abandon against the fascist, corrupt, and evil Big Brother.

It turns out to be a much better book than I had expected. The author has collected most of his information through personal interviews, and it ends up being a very readable and very personal account of the past 30 years of cryptographic research and commercial development -- both in the public sphere, and, to some extent, in U.S. and British intelligence agencies. The author treats his subjects fairly - the government is not demonized as I expected, and the cryptographers are not idolized (much). There is essentially no math in this book, beyond the bare minimum necessary to understand the main concepts of cryptography. Together with, say, The Codebreakers for early history and Applied Cryptography for the math, it would make a comprehensive and thorough look at the history and science of cryptography.

drfalken's review: The ubiquity of encryption technology employed by everything from bank machines to e-tailers is now taken for granted. Most people fail to realize, though, the profound impact that this component of the digital world has had on the Information Age. Illumination of this point is the formidable task of Crypto.

The renowned author of Hackers and Insanely Great remains true to form, transforming an obscure, dry and complex subject into an addictive page-turning thriller. He takes us from the hippie culture of academic math research in the 70s, through the dark underworld of government intelligence, into the development of the modern information age. Each step emphasizes the central conflict of the story: American national security vs. the right to individual privacy.

While this conflict has largely been resolved, the story contains important lessons that can be applied to the contemporary struggles over technologies like DeCSS and peer-to-peer media 'sharing.' Levy doesn't make any such connections in the book, but it is impossible to read Crypto without seeing how history is repeating itself in these other areas. This makes Crypto and important book to read. Everyone from the RIAA to 2600 subscribers can learn a lot from this well organized retelling of the past 30 years of crypto history. There's a certain futility involved in trying to put the genie of progress back in a bottle. There's also a case to be made for the management of progress so that it is used with the greatest benefit and smallest detriment to all. Perhaps the most remarkable revelation in the book is how the adversarial nature of 'the geeks' vs. 'the spooks' allowed for the maturation of a sensitive technology in a safe and thoughtful manner.

Anyone who has read Wired or Newsweek over the past 5 years will have read excerpts from Crypto. Levy spent a long time researching this book, which makes sense considering the story he is telling is one that was developing during his period of research. Many of the events he recounts are ones he covered as a journalist at the time that they happened. Some time spent in the Wired archives shows the extent to which he has been one of the journalists closest to the crypto revolution since the release of PGP and the popularization of the Internet.

The book begins with the story of Whit Diffie and his wild ambition to simply learn more about the black art of electronic cryptography. In the early 70s the government monopoly on information relating to serious crypto was nearly complete. Coming from the mindset of the Open Source community, Levy's tale of the early crypto research climate describes a cathedral that makes Microsoft look like the Debian project. The resulting story, therefore, highlights the magnificence of the public key breakthrough, the boldness of the RSA discovery and the daring of Paul Zimmermann's PGP.

If you're looking for a history of Cryptography, get The Code Book by Simon Singh, or Codebreakers by David Kahn instead of this book. Crypto is a contained story dealing exclusively with the American Cryptographic Experience from Diffie-Hellman, through RSA, and PGP. It is effectively a collection of short, intertwined biographies of the saviors of privacy, from Adleman to Zimmermann. This is not to say that Levy ignores the math; on the contrary, his explanation of the magnitude of the public key concept hits home even harder than the impressive work by Simon Singh.

Especially in light of recent Slashdot stories, Crypto is highly recommended, for novices and Cypherpunks alike. It's a coming of age story for American technology, and a great addition to the bookshelf of modern American history.

topeka's review:

The first time I heard the term "elegant" applied to a technical problem was a bit of a revelation for me. Until then, elegance, to me, was a visual quality that could only be achieved by painters and poets. When I began to see the elegance in solutions to technical and mathematical problems, I was hooked into a world of intellectual curiosity. Cryptography immediately filled the mold of a highly complex and technical problem with a beautiful and elegant solution when it was first explained to me several years ago. The idea clicked again when I read Raymond's The Cathedral and the Bazaar and equated that elegance to "scratching a particular itch". This intellectual curiosity seems to drive the open source community.

However, in 1967, when James Ellis (of the secret British agency, GCHQ) first came up with the idea of public key cryptography, his theory was buried. Until then, solutions to cryptographic problems were a dirty process. If it was easy to create a cipher, than it was just as easy to break it. As such, Ellis's breakthrough was simply too pretty to be trusted and as a result, it lay locked away until 1997. Steven Levy's new book, Crypto is the story of the individuals who transformed cryptography from a dirty art, which only the most elite governments dabbled in, to an elegant mathematical solution available to the public in hundreds of different forms. It was all done by a community of individuals who preached openness and sought out clean solutions to tough, technical problems.

Levy starts out his story in the same place as he started with an earlier famous work, at the Massachusetts Institute of Technology. He narrates the story of Whitfield Diffie, the co-creator of public key cryptography. Starting in 1969 as Diffie sought shelter from the Vietnam war working for a defense contractor, Levy discusses Diffie's transformation from examining ideas about cryptography as merely a hobby, to an all out obsession. Diffie is transformed from a man thinking about cryptography on the weekends to a man criss-crossing the country in one run-down Datsun after another, searching for any and every piece of information about cryptography. Diffie would not broach the wall of cryptography until he was pointed to another researcher in California, who seemed to be investigating the same concepts. Levy chronicles the fateful partnership that occurred with Marty Hellman and the subsequent invention of public key cryptography, at least its theory.

At this time, there were few works published on the subject of cryptography. In fact, only government agents and a few privileged defense contractors were able to expend meaningful resources on crypto research. It seems that while Levy's work is a story of the people who waged a war to bring crypto to the public, it is also the story of that wars' enemy, the National Security Agency. The cryptography bureaucracy, gaining most of its resources during the Second World War, had built quite a palace around anything that involved codes. In the years to come, the NSA would fiercely defend its position of strength. From its early attempts to classify David Kahn's famous work, The Codebreakers, to its involvement in the creation of the Digital Encryption Standard and its invention of the Clipper Chip. As Crypto defines it, the spooks were able to keep their lock on cryptography by invoking a mentality of "if only you knew what I know..." in classified briefings to politicians and contract negotiations with defense contractors like IBM. What the NSA never expected, was for anyone to try and find out what it was that they knew. With the publishing of the Diffie-Hellman paper, "New Directions in Cryptography," one of the NSA's most viable opponents would begin their work where Diffie and Hellman's theories left off, implementation.

Ron Rivest, Adi Shamir and Leonard Adleman, through a four-month period of intense brainstorming, would eventually implement and patent the Diffie-Hellman concept of public key cryptography while working as faculty at MIT. As Levy chronicles it, the algorithm, which would become popularly known as RSA, was named for the order in which each mathematician gave to the project. Rivest, who spearheaded the search for the implementation was listed first and Adelman, who merely poked holes in Rivest and Shamir's proposals, had to be convinced that he had even contributed enough to the project to be listed on the paper. Until this point, the description of cryptographic algorithms in scientific texts had always been done using letters of the alphabet to depict members in a cryptographic exchange. The creators of RSA introduced the now famous cryptographic characters, Alice, Bob and the unruly Eve, to describe their new breed of algorithms. Levy is able to highlight the mentality of the three mathematicians, some of which at first, thought the problem was nothing more than a clever puzzle and too grounded in the real world to be successfully dealt with by mathematicians. He shows their transformation to the church of cryptography, as the elegance of the new algorithms would prove as beautiful as the theorems of Gauss and Euclid.

The story continues with RSA Data Security, the vehicle Rivest would use to commercialize his algorithm. To talk about RSA Data Security is to talk about patent use. Both the Diffie-Hellman algorithm, as well as RSA, were actually patented by Stanford University and MIT, respectively. When the patents were granted, those Universities then had the option to either free the patents or restrict them. As history has painfully shown, they did not choose to free them. RSA Data security was built on this decision -- an MIT patent. It was sometimes difficult to read this section of the book with the same exuberance that Levy writes about it. Nonetheless, it is a reminder of the state of our intellectual property laws today in the United States.

Levy's narration eventually leaves the story of RSA to tell that of Phil Zimmerman, someone who could rightly be called a crypto-anarchist. Once again we are treated to an in depth discussion of the motivation that created Pretty Good Privacy. Levy contrasts the use of legal patents by RSA Data Security to bring encryption to the masses, to the complete ignorance of them by Zimmerman in his creation of PGP to achieve the same goal.

Finally, in my favorite section of the book, Levy discusses the controversy that surrounded a device known as the Clipper Chip. It was originally invented by the NSA as a complete key-escrow system, named the Capstone Chip. Later, as AT&T attempted to market the first encrypted telephone device, the Capstone chip became the Clipper Chip as the FBI and other Executive branch officers rushed to implement a brain-dead subset of the original system before the AT&T device made it to market. An entirely amusing fiasco, Levy lays the entire story out from beginning to end.

Lastly, includes an epilogue telling the story of the British agents at GHCQ, who beat Whitfield-Diffie and RSA -- a story that the GCHQ refused to let surface until the mid 1990s.

Levy tells a story about people. If you are looking for a technical discussion of the different aspects of cryptography then you would be better off with Schneier's Applied Cryptography or Singh's The Code Book. However, to understand the freedom that cryptographic technologies bring us, we must understand the history that it stands on. This is what Levy provides. A comprehensive history of the events that took cryptography out of the hands of the NSA and into the hands of political dissidents, CEOs, Nazis, you and me (not to mention mozilla, pgp, ssh, and gpg).

You can purchase Crypto at ThinkGeek.

SRS Webby writes "Eric Raymond has updated his The Art of Unix Programming page with two new chapters - Chapter 3: Unix's Zoo of Languages and Chapter 4: A Developer-Friendly Operating System." This is actually fairly old, but its a nice slow friday. Personally I'm resolving this by re-reading every Penny Arcade.

SRS Webby writes "Eric Raymond has updated his The Art of Unix Programming page with two new chapters - Chapter 3: Unix's Zoo of Languages and Chapter 4: A Developer-Friendly Operating System." This is actually fairly old, but its a nice slow friday. Personally I'm resolving this by re-reading every Penny Arcade.

SRS Webby writes "Eric Raymond has updated his The Art of Unix Programming page with two new chapters - Chapter 3: Unix's Zoo of Languages and Chapter 4: A Developer-Friendly Operating System." This is actually fairly old, but its a nice slow friday. Personally I'm resolving this by re-reading every Penny Arcade.

sonnerbob asks: "There was this article at Wired (which I'm sure has already been submitted), but what I found most interesting was the reference to Privacilla.Org which intends to 'loosely follow the open source software development model described by Eric Raymond.' Since I do subscribe in large part to 'free market liberalism', the principles of the Cato Institute, and try to convey as much at WebVeil.Com, I would like to read the comments from Slashdotters, both on the open source approach and the angle on the privacy issue itself."

The iBiblio.org domain name is so new that Google still doesn't show it, but a search for the site's previous name, MetaLab.unc.edu, turns up over 600,000 responses. To Linux users, it is the home of the Linux Documentation Project and the world's largest repository of downloadable Linux and Open Source software, but that is not what it started out to be and it is still not iBiblio's primary purpose, although Linux and Open Source and the community concepts behind them are integral to iBiblio in many ways.

It says on the iBiblio FAQ page that iBiblio "stands above other digital libraries" by maintaining "a close relation to the open source models for development and management of collections." The FAQ page also says, "We're all about freedom, man! Free Tibet, free Burma, Free Love, you get the picture. We offer a free platform for the exchange of free thought. We host tons of cultural sites like the DocSouth Project, Zen@iBiblio, and North Carolina Raves (all of which can be seen from our collections index). We are also one of the first servers to mirror the original Linux kernel, so you can tell we're big on free software, too."

Paul Jones, listed on the who we are page as "fearless leader," has been the project's director since it began in 1992. He is a computer scientist, a poet, and a professor of both journalism and library science. He has eclectic tastes in music, a high forehead, hair that ripples over his shoulders, and speaks in an accent you could call Mayberry PhD; imagine a good ol' boy-talking leftover hippie who co-wrote The Web Server Book (which later morphed into The Unix Web Server Book, Second Edition, and you have Paul pegged -- and some insight into the nature of the iBiblio collection, which could be loosely defined as 'information and amusements Paul likes or needs or thinks a whole lot of other people might like or need.'

The iBiblio collection policy is vague; "eclectic" is the polite word. There is a fair amount of southern U.S. culture (the Mayberry part) and plenty of scholarly studies (the PhD part), and lots of everything else. The Web's longest-running comic (since 1993), Dr. Fun, is hosted by iBiblio. So is the Virtual Shtetl, an online repository for Yiddish language and culture.

The current iBiblio name was chosen, in large part, because it was available. Paul says, "Naming anything on the Internet these days is a combination of what's available and what you're trying to say." The old SunSite name had to go when the site's relationship with original sponsor Sun Microsytems (amicably) dissolved several years ago. Then, Paul says, people both in the free software community and the rest of the world seemed to associate the MetaLab name almost entirely with the software aspect of the site (which only makes up about half of it), and when the latest sponsor, red hat center, donated $4 million to the project, a name change was in order -- but not to one that had either redness or hatness in it.

"Bob Young felt like since this was the first and biggest [charitable] project he had done," Paul says, and since they were going to have many changes in the site, "... he also wanted to try to do a little bit different name. He noticed when he kept certain names, say like red hat center and Red Hat, Incorporated, that people got them confused." So instead of a Red Hat-boosting name, it became iBiblio, a made-up word that alludes well to librararyness -- and is easy to remember once you get your tongue around it correctly, pronoucing the first "i" long so that you are saying, "eye - bib - lee - oh."

Right now the amount of material iBiblio can hold is limited only by server capacity. "We have plenty of bandwidth," Paul says. And now, new hardware is going online steadily, paid for in large part by the Red Hat center grant. It all runs Linux for reasons that go beyond the current sponsorship. Indeed, the MetaLab/SunSite relationship with Linux started before Red Hat was formed, and came about almost entirely by accident.

"Originally," Paul says, "the first U.S. [Linux] mirror site was for a brief time a place called banjo, at concert dot net, and that's right up the road from us. I forget how many Megabytes the kernel was then, perhaps 30 -- now that doesn't seem like anything, but at the time it seemed like quite a bit -- and they were getting a little bit of traffic, several hundred file transfers a day. It was enough to make them nervous. They were a small company, just getting going.

"Jonathan Magid, who in fact still works with me, was an undergrad who was interested in operating systems, and he came to me and said, 'You know, there are these guys that are cooperatively building an operating system, and you can have it.' I said, 'Oh yeah? When can I run it?' He said, 'Well, you can only run the kernel, the rest'll be coming soon.' At first I said, 'We don't really need another operating system.' I already had a Mac, we had Suns, and we had PCs, so what did we need another operating system for? He [Jonathan] said, 'This one, you can actually work on yourself if you want to,' and I thought this was kind of nice, we'll try that out, and we sort of rescued it from banjo before they got in trouble [over the traffic], and we've never stopped [hosting Linux] since."

Paul has no accurate count of the number of Linux and free software files currently hosted at iBiblio.org. He says, "I know the separate distros, each one is an entire tree of its own, we carry about thirty-some distros. We have between four and six thousand community-contributed files. Some are active and some are now becoming historic, but the librarian part of me doesn't want to throw anything away."

In a little side note, Paul adds, "After Jonathan got overwhelmed as the Linux portion took off, I said, 'We need to find somebody who really cares about this who will come in and help us out.' Jonathan suggested a friend, Eric Troan, who he said would work for 'a couple of t-shirts.'"

Troan stuck around for a while, but eventually got hired by then-new Red Hat (Paul says Troan was Red Hat employee number four), and another Eric, surname Raymond, got involved and continued his participation until, Paul says, he more-or-less accidentally found himself flying yon and hither speechifying and writing as the prime spokesman for the entire open source movement.

Paul cannot remember exactly how long Raymond worked on MetaLab; "You'd have to ask Raymond," he says. "About three years, I think, but I'm not positive."

This lack of certainty, this semi-anarchy, this sense of people coming and going, each bringing something to the whole, shows why iBiblio is inextricably linked to the free software and Open Source movements in ways that extend beyond software into both management style and general philosophy. Some volunteers have made noticeable, even site-shaking contribitions. Paul credits Eric Raymond, for instance, with bringing Trove, an open-source distributed archiving system for use at large software archive sites, with him.

But other equally-valuable contributions may be less visible than Trove, and many iBiblio contributors may be unknown within the Linux, open source, and free software communities, where the International Union of Pure and Applied Chemistry [IUPAC] or the Vietnam Multimedia Archives are not daily discussion topics.

The point to all this is that open source software and concepts have uses beyond the confines of the programming community, and that iBiblio.org, with new money from a foundation that owes its funding to open source software, is an endless experiment in open source and library science (which might also be called "library art" in the iBiblio context), and how a combination of the two can evolve as a public resource if given money, time, and a little (but not too much) guidance.

Chaoli the Grey asks: "Long before everybody and their mother used the Internet there were neo-pagan and occult ftp-archives and newsgroups. Margot Adler notes in her book _Drawing Down the Moon_ that among neo-pagans, '[an] amazingly high percentage [works] in computer, scientific and technical fields'. Appendix B in the Jargon File states that 'There is a definite strain of mystical, almost Gnostic sensibility that shows up even among those hackers not actively involved with neo-paganism, Discordianism, or Zen.' But has the interest in things mystical and occult among computer geeks watered down after the masses found computers and the Net? Do hackers still believe in magic or practice a mystical religion?" A risky question, as most of us have beliefs that we feel strongly about, but it is an interesting question nonetheless. So those interested in sharing what they believe in, please feel free. I'm sure others may find it interesting. The one thing I do ask is that you not judge people based on the information that is shared here, as all that is bound to do is cause problems.

Chaoli the Grey asks: "Long before everybody and their mother used the Internet there were neo-pagan and occult ftp-archives and newsgroups. Margot Adler notes in her book _Drawing Down the Moon_ that among neo-pagans, '[an] amazingly high percentage [works] in computer, scientific and technical fields'. Appendix B in the Jargon File states that 'There is a definite strain of mystical, almost Gnostic sensibility that shows up even among those hackers not actively involved with neo-paganism, Discordianism, or Zen.' But has the interest in things mystical and occult among computer geeks watered down after the masses found computers and the Net? Do hackers still believe in magic or practice a mystical religion?" A risky question, as most of us have beliefs that we feel strongly about, but it is an interesting question nonetheless. So those interested in sharing what they believe in, please feel free. I'm sure others may find it interesting. The one thing I do ask is that you not judge people based on the information that is shared here, as all that is bound to do is cause problems.

Ah, there you are! You must have come to hear the details about selling your vote online? No, perhaps then you'd like to know what LinuxWorld thought was coolest at LWCE, or what words ESR has added to the infamous Jargon File. All below, folks, all below.

Good thing politicians are in such strong ethical trim. In case you were thinking of selling your vote (early and often) in the next national election, it seems that there are legal barriers. Sort of like at least certain other activities which are legal if you do them for fun, but illegal if you take cash, the lawmakers seem to like the prostitution on their side of the castle wall. Or do they always vote their consciences?

GMontag writes: "This Wired story tells how Voteauction.com has shut itself down after public pressure and threats from various bureaucrats.

A telling quote by Doug Kellner, a Manhattan representative on the New York City Board of Elections: 'The message to get out to the public is that posting (intent to sell votes) to a website even in jest is a serious matter. It could subject you to prosecution, or in New York you could forfeit your vote,' Kellner said, referring to a New York state law that imposes a one-year forfeiture on vote buyers and sellers.

So, this is more political speech that is 'illegal'? So far, it has been nothing but a discussion of vote auctioning and a college paper. Amazing that the bureaucrats what to 'do something' about this, but rounding up car thieves keeps 'slipping through the cracks.'"

Note to non-U.S. citizens: since this law probably doesn't apply to you, feel free to sell your votes online.

Radio Radio it's a sad salvation. wodelltech writes "With regard to the recent VMSK article/comments, readers might find the announcement at http://ibiquitydigital.com interesting."

Basically, this is an announcement of the merger of Lucent Digital Radio (which, little did I know, is just a few miles from my present dwelling) and USA Digital Radio, which sounds like an interesting step toward better choices in local radio. (Can't someone please give me good talk, all day?) Here's a snippet:

Today, radio in the United States is broadcast using analog signals. iBiquity Digital will enable broadcasters to send a digital signal, capable of containing CD-quality audio with crystal clear reception and additional wireless data for a variety of consumer applications such as station and program content, stock and news information, local traffic and weather, and much more, over existing radio frequencies, without denigrating transmission of current analog programming.

But is there a downloadable palm module? A Klingon translation? Anomie-ous Cow-ard writes "The ever-popular Jargon File has been updated to version 4.2.2."

So if you want to correctly use terms like "smoot," "ANSI standard pizza," and "dirty genitals," make sure to arm yourself with ESR's help. And you can look at the file's change log here.

Buzzword compliance is certainly a mission-critical optimization *ahem, mumble* ... Captain_Carnage writes "The LinuxWorld website has an article about itstop five productstoday. Featured are a rollable rubber keyboard from Broumand (only an e-mail address given), a user resource allocation/accounting tool from Aurema, an IDE-based RAID card from 3ware, a Linux-based router/VPN box from Linux Wizardry, and a High-Availability clustering product from Mission Critical Linux."

These all seem like cool products, but slashdot readers have known about the rubber keyboard for months. As for the others, any other nominations for the coolest products recently released? If the field is open, I have to say the pneumatic chair at the Loki booth, even if it isn't yet available and will cost 5 or 10 grand, and Slackware folding frisbees.

Ah, there you are! You must have come to hear the details about selling your vote online? No, perhaps then you'd like to know what LinuxWorld thought was coolest at LWCE, or what words ESR has added to the infamous Jargon File. All below, folks, all below.

Good thing politicians are in such strong ethical trim. In case you were thinking of selling your vote (early and often) in the next national election, it seems that there are legal barriers. Sort of like at least certain other activities which are legal if you do them for fun, but illegal if you take cash, the lawmakers seem to like the prostitution on their side of the castle wall. Or do they always vote their consciences?

GMontag writes: "This Wired story tells how Voteauction.com has shut itself down after public pressure and threats from various bureaucrats.

A telling quote by Doug Kellner, a Manhattan representative on the New York City Board of Elections: 'The message to get out to the public is that posting (intent to sell votes) to a website even in jest is a serious matter. It could subject you to prosecution, or in New York you could forfeit your vote,' Kellner said, referring to a New York state law that imposes a one-year forfeiture on vote buyers and sellers.

So, this is more political speech that is 'illegal'? So far, it has been nothing but a discussion of vote auctioning and a college paper. Amazing that the bureaucrats what to 'do something' about this, but rounding up car thieves keeps 'slipping through the cracks.'"

Note to non-U.S. citizens: since this law probably doesn't apply to you, feel free to sell your votes online.

Radio Radio it's a sad salvation. wodelltech writes "With regard to the recent VMSK article/comments, readers might find the announcement at http://ibiquitydigital.com interesting."

Basically, this is an announcement of the merger of Lucent Digital Radio (which, little did I know, is just a few miles from my present dwelling) and USA Digital Radio, which sounds like an interesting step toward better choices in local radio. (Can't someone please give me good talk, all day?) Here's a snippet:

Today, radio in the United States is broadcast using analog signals. iBiquity Digital will enable broadcasters to send a digital signal, capable of containing CD-quality audio with crystal clear reception and additional wireless data for a variety of consumer applications such as station and program content, stock and news information, local traffic and weather, and much more, over existing radio frequencies, without denigrating transmission of current analog programming.

But is there a downloadable palm module? A Klingon translation? Anomie-ous Cow-ard writes "The ever-popular Jargon File has been updated to version 4.2.2."

So if you want to correctly use terms like "smoot," "ANSI standard pizza," and "dirty genitals," make sure to arm yourself with ESR's help. And you can look at the file's change log here.

Buzzword compliance is certainly a mission-critical optimization *ahem, mumble* ... Captain_Carnage writes "The LinuxWorld website has an article about itstop five productstoday. Featured are a rollable rubber keyboard from Broumand (only an e-mail address given), a user resource allocation/accounting tool from Aurema, an IDE-based RAID card from 3ware, a Linux-based router/VPN box from Linux Wizardry, and a High-Availability clustering product from Mission Critical Linux."

These all seem like cool products, but slashdot readers have known about the rubber keyboard for months. As for the others, any other nominations for the coolest products recently released? If the field is open, I have to say the pneumatic chair at the Loki booth, even if it isn't yet available and will cost 5 or 10 grand, and Slackware folding frisbees.

Adam Brate, Slashdot reader, sent us a review of Cyberselfish: Technolibertarianism, a book which takes a look at the "cyber" culture, and what it means. It sounds interesting, although perhaps a bit off-base - comment below if you've read it. Cyberselfish author Pulina Borsook pages 256 publisher PublicAffairs, 05/2000 rating 8/10 reviewer Adam Brate ISBN 1891620789 summary A Critical Romp Through the Terribly Libertarian Culture of High Tech I heard about Cyberselfish when driving around Vermont Memorial Day weekend from used bookstore to used bookstore. The NPR station was broadcasting an interview with Cyberselfish author Paulina Borsook, a writer who worked for Wired during its glory years. I was put off by the book's wretched title, but engrossed by the subject: the powerful undercurrent of libertarianism that flows through high-tech circles. I have been astounded but not amazed at the deeply adolescent and peevish libertarian attitudes that so many techies cling to, from gun worship to fear of governmental Internet regulation. Listening to Borsook speak intelligently and cogently about technolibertarianism made me want her book very much.

This month I garnered a copy of Cyberselfish, and I'm still appalled with the title (which comes from an eponymous essay for Mother Jones she wrote in July 1996, when such cyberlanguage wasn't so cybertrite). Cyberselfish is a book-length essay, in fact a somewhat thinly edited series of linked essays. There's a rush of immediacy and wit; for a random example, "Polyamory is the preferred term of art; it's gender-neutral, where polygamy and polyandry are not, and allows for all persuasions of partner choice (gay/straight/bi/it depends)." With the freshness and informality comes flaws. There is too much repeated material in the book. It's clear that essays written at different times have been cobbled together. Reading the book straight through is like reading some multi-volume series straight through, in which the characters and history are rehashed at the beginning of each book.

Cyberselfish looks at a few specific examples of technolibertarianism in depth: Bionomics, cypherpunks, Wired magazine, and Silicon Valley's impressive lack of philanthropy. Each time Borsook exposes the compassionless, fearful, posturing, politically myopic core, without dismissing the good aspects of the high-tech culture and individuals. For example, she thinks fighting for privacy rights is good, but obsessing about it and descending into rabid, paranoid ranting on alt.cypherpunks is scary. She moves smoothly from the historical to the academic to the personal, deliberately exposing her own frailities and biases while she examines those of others.

To give a deeper example of the content of Cyberselfish, Bionomics is the use of biological (and particularly Darwinian) metaphors to describe economic processes, as popularized by Michael Rothschild (Bionomics: Economy as Ecosystem) and then the The Bionomics Institute (TBI). Borsook convincingly points out through both empirical observation and reasoned analysis that Bionomics boils down to economic libertarianism, where government involvement is wrong and the most cut-throat, efficient and entrepeneurial businesses are the best. Ecological metaphors are used in Bionomics only when they're useful and sexy: The ecosystem of Hawaii was used as a metaphor for the fragility of protected industries. Under Bionomics logic, Hawaii's beautiful, lush, peaceful ecosystem is to be derided. Bionomics uses metaphors to draw syllogistic conclusions. Doing that can be powerfully convincing but amounts to hand-waving and emotional appeals. Borsook cuts through the smoke and mirrors.

After a few years, the Bionomics Institute conferences were (literally) taken over by the Cato Institute, the premier libertarian think tank in the nation. The annual Bionomics conterences began in 1993. The 1997 conference was the Cato/Bionomics Conference; 1998, the "Annual Cato Institute/Forbes ASAP Conference on Technology and Society." TBI morphed into software-startup Maxager, which intends to offer Bionomical tools to companies. Borsook wonders what meaning can be ascribed to the success or the failure of the company. If Maxager fails, is it because it wasn't Bionomically good enough, or just because of the many uncontrollable factors that cause the vast majority of startups to fail? If it succeeds, does it validate Bionomics, or just the good connections the founder has with Silicon Valley venture capitalists?

The other chapters are just as interesting. Cyberselfish sharply describes all the archetypes of the technolibertarians, from the neo-hippie polyandric Burning Man attendee to the Lexus-driving, 100-hour-a-week, plugged-in entrepeneur with a sprawling bungalow in Santa Clara county.

One of the most crystalline passages in the book describes Eric Raymond's leaking of the Halloween Document, written by Microsoft program manager Vinod Valloppillil. The two clearly have vast ideological differences, the open-source cowboy and the Evil Empire functionary, but they're both hard-core libertarians, an entirely unreported fact. In Borsook's words, "It was rather like discovering that both a liberal and a conservative senator had both acquired their law degrees from Yale: no news here."

As I said before, the book is somewhat haphazardly put together, and nearly every sentence is to some degree contentious; even someone who agrees with her basic position will find reason to quibble. Cyberselfish doesn't come near to answering all the questions it raises. Borsook doesn't really tackle the paradox that "libertarians celebrate the cult of the individual" but Open Source celebrates the collective. What does it mean to be an Open Source libertarian?

I personally think it's somewhat unfair to attack those flaws, as they're inexorably part of Cyberselfish's loose, immediate, opinionated, and conversational style. It's kind of like how Slashdot's open forums allow for a review like this and the inevitable "hot grits" responses.

Purchase this book at fatbrain.

Iambic Pentametor writes "Back in April, Slashdot had a story covering the first two rounds of a forum at The American Prospect between Eric S. Raymond, Lawrence Lessig, Nathan Newman, Jeff A. Taylor, and Jonathan Band. The third round is here. ESR's latest is pretty inspiring and despite some squabbling, each of the combatants make some good points."

Proctors dropped us the following note after jetting home from the Global Linux 2000 meeting in Seoul, Korea. His account is brief, but it conveys a spirit of adventure and fun which only the thought of an RMS / ESR sing-along can.

Back from Korea and Global Linux 2000 with a killer case of jet-lag. All I gotta say is: it was an amazing experience. The show started with a ribbon cutting ceremony: Cliff Miller of Turbo, Tim Ney, the U.S. ambassador, the Korean minister of information and communication, among others, were all handed white gloves and a pair of scissors by a group of young women dressed in traditional Korean dresses. On the count of three, everyone cut the ribbon at once -- in front of a huge crowd of people and a corps of press.

In fact, that has to be one of the most incredible things about Global Linux 2000 -- Here we are: the North and South are reconciling after 50 years, Bill Gates is in town and the media kept showing up over and over in droves to cover the show and conference. It was a media flack's wet dream -- believe me, I know. It showed the enthusiasm of the Koreans for Linux.

But that wasn't the only miracle: ESR and RMS sat together briefly at a dinner reception for the participants in the Linux Greenhouse and friends. It was my birthday and after everyone sang "Happy Birthday," Richard stood up and did his own version -- only to be followed by Eric. I was sitting there, listening to them both sing to me and all I could think was "This is a oner." But it got better ...

The Greenhouse was going fab. The reason I got into this - why I love it (besides the obvious -- the pure genius of the hackers, basic principals of it) was for the enthusiasm. It's catching. And the Greenhousers are no different. This is a multi-national group of people who have companies that are doing everything from programming GNOME for PDAs to teaching GNU/Linux to more than 700,000 adult students in Sweden. They had meetings, they hacked, they danced together on the dancing machines that are the big thing in Korea -- kind of like karaoke for your feet.

Speaking of karaoke -- a bunch of us piled into this bus to go to the night market in Seoul and discovered that the bus was a KARAOKE bus. ESR sang "Deeper Shade of Pale" (he can really sing), and we all sang "We are the Champions." Eric changed the lyrics to "We'll keep on hacking to the end." It was wrong -- very, very wrong.

The night market is a giant, monolithic monument to entrepreneurship that's open all-night, every night. Hundreds of little stalls hawk everything from dried fish to Linux Sport tennis shoes. I do not lie -- someone in Korea named their shoes 'Linux Sport.' We had to buy a pair, really we did.

Did I mention that EVERYONE has a cell phone? Little old ladies, ten-year-old kids -- the young kids decorate them with 'Hello Kitty' charms and costumes (think Halloween for your cell phone). The food was completely wonderful - except the kimchee. I know, I'm a traitor -- but I have a very hard time getting behind rotten cabbage in hot sauce.

Photos will be posted soon on the Greenhouse site and ESR is threatening to add this trip to his travel diary -- where he'll put this little postcard to shame.

ESR ^[?] sent a feature about the Microsoft Web Server Backdoor - interesting stuff, and makes some good points about Open Source.

News services all over the world reported today (14 April 2000) that Microsoft programmers had inserted a security-compromising back door in their FrontPage web server software. Thousands of websites worldwide may be affected. Representative coverage of this story can be found at http://news.cnet.com/news/0-1003-200-1696137.html.

Amidst all the nervousness about yet another Windows security hole, and not a little amusement at the passphrase the Microsoft programmers chose to activate the back door ("Netscape engineers are weenies!") there is one major implication of this story that is going unreported.

This back door seems to have been present since at least 1996. That's four years -- *four years* -- that nobody but the pranksters who wrote it has known about that back door. Except, of course, for any of the unknown crackers and vandals who might have found it out years ago. All the world's crackers certainly know about it now after the worldwide media coverage.

Webmasters all over the world are going to be pulling all-nighters and tearing their hair out over this one. That is, webmasters who are unlucky enough to work for bosses who bought Microsoft. At the over 60% of sites running the open-source Apache webserver, webmasters will be kicking back and smiling -- because they know that Apache will *never* have a back door like this one.

Never may sound like a pretty strong claim. But it's true. Because back doors (unlike some other kinds of security bugs) tend to stand out like a sore thumb in source code. They're hard to conceal, easy to spot and disable -- *if you have access to the source code*.

It's the fact that the compromised Microsoft DLL was distributed in opaque binary form that made it possible for the good guys to miss this back door for four long years. In the Apache world, every every one of the tens of thousands of webmasters who uses it has access to the Apache source code. Many of them actually look at code difference reports when a new release comes out, as a routine precaution against bugs of all kinds.

Under all that scrutiny, a back door would be unlikely to escape detection for even four *days*. Anybody competent enough to try inserting a back door in Apache knows this in their bones. So it would be pointless to try, and won't be tried.

What's the wider lesson here?

It's pretty clear. Anybody who trusts their security to closed-source software is begging to have a back door slipped on to their system -- with or without the knowledge of the people who shipped the code and theoretically stand behind it. Microsoft HQ is doubtless sincere when it says this back door wasn't authorized. Not that that sincerity will be any help at all to the people who will have to clean up the mess. Nor will it compensate their bosses for what could be millions of dollars in expenses and business losses.

If you don't have any way to know what's in the bits of your software, you're at its mercy. You can't know its vulnerabilities. You can't know what *other people might know about it that you don't*. You're disarmed against your enemies.

Does this mean every single webmaster, every single software consumer, has to know the source code of the programs they use to feel secure? Of course not. But open source nevertheless changes the power equilibrium of security in ways that favor the defence -- it means back doors and bugs have a short, inglorious lifetime, because it means the guys in white hats can *see* them. And even if not every white hat is looking, potential black hats know that plenty of them will be. That changes and restricts the black hats' options.

Apache has never had an exploit like this, and never will. Nor will Linux, or the BIND library, or Perl, or any of the other open-source core software of the global Internet. Open-source software, subject to constant peer review, evolves and gets more secure over time. But as more crackers seek and find the better-hidden flaws in opaque binaries, closed-source software gets *less* secure over time.

Who knows what back doors may be lurking right now in other Windows software, only to be publicly acknowledged four years in the future? Who *can* know? And who in their right mind would be willing to risk their personal privacy or the operation of their business on the gamble that this is the *last* back door in Windows?

The truth is this: in an environment of escalating computer-security threats, closed source software is not just expensive and failure-prone -- it's *irresponsible*. Anyone relying on it is just asking, *begging* to be cracked. If theory didn't tell us that, the steadily rising rate of Windows cracks and exploits over the last eighteen months would.

Cockcroaches breed in the dark. Crackers thrive on code secrecy. It's time to let the sunlight in. --

http://www.tuxedo.org/~esr
Eric S. Raymond

"...quemadmodum gladius neminem occidit, occidentis telum est."
[...a sword never kills anybody; it's a tool in the killer's hand.]
-- (Lucius Annaeus) Seneca "the Younger" (ca. 4 BC-65 AD),

Academic head of the MIT Media Lab Alex Pentland and Eric S. Raymond (ESR), software evangelist and straight-shooting author of some of the Free software world's most influential essays, will be there. If you can cough up zero dollars (or the equivalent in lire, pesos, krugerands, galactic credits, etc.) and get to Boston on Friday (31st March) or Saturday (1st April), you'll be well met at the 3rd annual Geek Pride Festival.

The Festival is free and brought to you by Andover.Net / VA Linux, Addison-Wesley and SwitcHouse.

Also in attendance will be the esteemed Cmdr. Taco himself, Rob Malda, and Christopher Locke and David Weinberger, authors of The ClueTrain Manifesto. Listen to them address the assembled throngs, and ask questions. In addition to speakers, there will be food, chair massages, a $500 cash-prize Quake III competition, an install fest with support from the Boston Linux Users Group, and booths representing groups like Perl Mongers, the Free Software Foundation and more.

Roblimo will be there, enjoying the street party he secretly believes is being thrown for his and lovely wife Debbie's wedding anniversary, and JonKatz may be there as well. The first person to ask Katz about his dog and the manhole, then transmit a recording of his reaction to hemos, will win an as-yet-undetermined fabulous prize. If you can't make it to Boston for April Fool's Day, you can vicariously experience the gathering via downloadable video and audio, available for the same price as the festival, less the cost of getting there.

Academic head of the MIT Media Lab Alex Pentland and Eric S. Raymond (ESR), software evangelist and straight-shooting author of some of the Free software world's most influential essays, will be there. If you can cough up zero dollars (or the equivalent in lire, pesos, krugerands, galactic credits, etc.) and get to Boston on Friday (31st March) or Saturday (1st April), you'll be well met at the 3rd annual Geek Pride Festival.

The Festival is free and brought to you by Andover.Net / VA Linux, Addison-Wesley and SwitcHouse.

Also in attendance will be the esteemed Cmdr. Taco himself, Rob Malda, and Christopher Locke and David Weinberger, authors of The ClueTrain Manifesto. Listen to them address the assembled throngs, and ask questions. In addition to speakers, there will be food, chair massages, a $500 cash-prize Quake III competition, an install fest with support from the Boston Linux Users Group, and booths representing groups like Perl Mongers, the Free Software Foundation and more.

Roblimo will be there, enjoying the street party he secretly believes is being thrown for his and lovely wife Debbie's wedding anniversary, and JonKatz may be there as well. The first person to ask Katz about his dog and the manhole, then transmit a recording of his reaction to hemos, will win an as-yet-undetermined fabulous prize. If you can't make it to Boston for April Fool's Day, you can vicariously experience the gathering via downloadable video and audio, available for the same price as the festival, less the cost of getting there.

Zortoaster wrote a review of a book that might be of interest to folks around here:" In lieu of the Norwegian police's crackdown on 16-year-old hacker Jon Johansen, who broke the DVD copying protection, Paul A. Taylor's book Hackers raises a series of interesting questions about crackers and cracking. The book scores high on content but lacks somewhat in presentation. He manages to spell out issues that are often only implicit in the computer security debate, and is able to paint a multi-faceted picture of the hacker, represented by the cracker, community setting it apart from the very black and white, good or bad, presentation of hackers in the mass media." Hackers author Paul A. Taylor pages 224 publisher Routledge, London: 09/1999 rating 7/10 reviewer Zortoaster ISBN 0415180724 summary In lieu of the Norwegian police's crackdown on 16 -year-old hacker Jon Johansen who broke the DVD copying protection, Paul A. Taylor's book Hackers raises a series of interesting questions about crackers and cracking. The book scores high on content but lacks somewhat in presentation. Hackers and hacking

Hackers starts out with a discussion on the hacker, what he (as is pointed out in the book, the hacker is almost always a 'he') does, and why he does what he does. Somewhat sadly, although fairly well-founded, is Taylor's choice of terminology. He chooses to consistently address the cracker as hacker. A hacker is not a cracker, but a cracker is always a hacker (put in more technical terms: the cracker is a subset of the hacker class -- think object orientation here), which is a point Taylor seems to willfully ignore. That he chooses to use the terminology in this manner is rather sad because it puts an ugly stain on the respectability of the hackers -- those of us who not meddling in computer break-ins or other dubious activities, but merely hack code to produce cool software. Throughout the rest of this review I will be using the term cracker to refer to Taylor's hackers, and hacker when referring to real hackers

However, since crackers are a subset of hackers, much of Taylor's discussion on the hack and hacking is applicable to the hacker community at large. This is one of the things that makes Hackers an interesting read. For a newcomer to the hacker community Taylor's discussion on the 'hack' is quite enlightening. Even for oldtimers his discussion may shed some new light on the hack. Contrary to existing material on the matter, like the Jargon File, Taylor is the first to spell out the criteria implicit in earlier treatises on the hack: 1) simplicity, 2) mastery, and 3) illicitness [as in 'against the rules', reviewers comment] (p.15). This latter criteria is in its use of the 'illicitness' term only applicable to the cracking activity. In a sense it is applicable to hacking as well. Then in the shape of 'against the rules'. We are not neccessarily talking against the rules of justice, but against what the system's rules say is possible. In that sense, calling the third criteria illicitness hints at somewhat dubious activities, but is in fact not. It is an important element in the regular hack (if such thing as a regular hack does exist), too.

Taylor manages to view the hacker community from a fresh angle. Being a sociology researcher his angle is quite different from that represented by for instance Eric S. Raymond or Gisle Hannemyr. One drawback is that Taylor draws on Steven Levy's overly romanticized hacker ethics as presented in Levy's book of 1984: Hackers. It is time someone tried looking somewhat deeper into the hacker psychology to realize that while Levy's five tenets may to a certain degree represent attitudes within the hacker community, it is not, contrary to what Levy proposes, an ethos by which hackers live and die (apart from this, though, Levy's book is highly enjoyable and recommended reading). I'm also having some problems accepting the psychosexual theories on hacking that Taylor proposes. They seem a bit far fetched to me. It's been a while since everybody agreed that Freud's psycho-therapy was kind of overly sex-fixated.

Taylor addresses a largely ignored issue in hacker literature, that of the gender question. Why are there next to no female hackers? He addresses the point through looking at societal factors, by explaining how the community is a masculine environemnt -- the new wild west, so to say -- and the fact that electronic communication creates misogynity through its anonymity. At the end of the chapter it is a bit hard to grasp what Taylor's point is, though (see Presentation for more).

Another issue thoroughly treated is the question of hacker motivation. What drives the hacker to hack? Taylor's background within sociology is again helpful, as he regards the issue from a fresh perspective. Hacker motivation has previously been treated by Eric Raymond in his essay Homesteading the Noosphere . Taylor's angle is to compare academic theories on hacker motivation with the the reasons the hackers' themselves give. From the discrepancy between these two angles he lists four reasons for hacking: obsession, curiosity, boredom, and the feeling of power. If not directly contradicting Raymond's view -- that hackers hack simply to gain peer esteem and status within the community -- Taylor gives Raymond's view a more multi-faceted hue. He goes beneath the drive for esteem, trying to address the reasons why anyone would need to gain esteem from their peers. As such, Taylor manages to add something new to a discussion that has been on the brink of going stale.

Issues on computer security and cracking

Taylor's main focus on crackers is how society at large is to deal with them. Are crackers to be treated as criminal masterminds plotting to bring the world to its knees, or simply misguided kids trying to do something exciting with their computer knowledge? Several views are drawn up, with Taylor quoting representatives of each view without really making any kind of judgment himself as to the better way of handling crackers. It is an exercise in how difficult the question truly is.

A number of other quite intriguing cracker/computer security issues are spelled out by Taylor, as well. Issues include who is to blame when a computer system has been cracked? The system administrator for not maintaining sufficient security or the cracker for breaking into a system to which he doesn't have legal access? Should anti-cracking laws be targeted at stopping all kinds of illegal computer use, or are there degrees to the crime being committed? Is printing your personal CV on the company's printers even though it is explicitly forbidden to use company equipment for personal use to be treated as a computer crime equal to that of breaking into a banking system and tampering with the data?

Taylor also questions the computer security companies' motivations (and rightly so, one might add). Are they simply running a protection racket like that of the mafia, using cracking and virus alerts to scare their customers into investing in expensive counter-measure software? Or are they avenging angels siding with the innocent, the not particularly compu-fluent masses? Using the dichotomy of the computer security industry vs. the crackers, Taylor raises the issue of whether good computer security can only be achieved through knowing the enemy, the crackers. Can crackers and computer security consultants work together in a symbiosis, or are they eternal enemies never to be reconciliated?

Another issue dealt with is how crackers are to be handled. Should their acts be punished in the harshest way, or should they be helped into redirecting their activities into more useful terms? The question is whether the cracker is to be treated as a nuisance or as an asset. Taylor treats this issue quite thoroughly referring from the parliamentary discussion in Britain. He also discusses in what ways legislation can prevent cracking. He shows how little the law enforcement agencies know about cracking and how they employed overkill (refer to the Norwegian police's recent raid on the hacker who broke the DVD encryption).

Presentation

However intriguing the book might be it is presented in a very unorderly and weird way. The pages are filled with rather long quotations from various e-mails, books, interviews, etc. I gather the intention is to present the reader with the direct opinions of the book's "main characters," giving us in a way a first person view of the matter. The idea is nice, but the effect is that it ruins the fluidity of the text, making the book somewhat hard to follow. Also: it is at times quite difficult to grasp what message Taylor is trying to convey when he is expressing himself through the extracts of other people's opinions. Quotes are OK, but when, without exaggeration, 50% of the average page is taken up by quotations it is a little bit too much of the good stuff.

Having said that, the book is very structured, each chapter building nicely on previous chapters. The conclusion at the end of almost all chapters helps clarify Taylor's opinions a bit, which is nice. Still, it does not weigh up for the confusion created by the excessive use of quotations.

Conclusion

Taylor succeeds with explaining the relationship between crackers and the computer security industry, presenting the matter in a more multifaceted way than that of the mass media. The book is a definite must for those wanting an introduction to the social sides of computer security. However, I find it rather amazing that a book written in 1999 seems to totally ignore the writings of Eric Raymond, as these are probably the best works on how hackers view their own culture. Despite this, I believe Hackers might prove an interesting read even for the hardcore hacker, if only as an alternative look at our own culture.

Purchase this book at fatbrain.

Zortoaster wrote a review of a book that might be of interest to folks around here:" In lieu of the Norwegian police's crackdown on 16-year-old hacker Jon Johansen, who broke the DVD copying protection, Paul A. Taylor's book Hackers raises a series of interesting questions about crackers and cracking. The book scores high on content but lacks somewhat in presentation. He manages to spell out issues that are often only implicit in the computer security debate, and is able to paint a multi-faceted picture of the hacker, represented by the cracker, community setting it apart from the very black and white, good or bad, presentation of hackers in the mass media." Hackers author Paul A. Taylor pages 224 publisher Routledge, London: 09/1999 rating 7/10 reviewer Zortoaster ISBN 0415180724 summary In lieu of the Norwegian police's crackdown on 16 -year-old hacker Jon Johansen who broke the DVD copying protection, Paul A. Taylor's book Hackers raises a series of interesting questions about crackers and cracking. The book scores high on content but lacks somewhat in presentation. Hackers and hacking

Hackers starts out with a discussion on the hacker, what he (as is pointed out in the book, the hacker is almost always a 'he') does, and why he does what he does. Somewhat sadly, although fairly well-founded, is Taylor's choice of terminology. He chooses to consistently address the cracker as hacker. A hacker is not a cracker, but a cracker is always a hacker (put in more technical terms: the cracker is a subset of the hacker class -- think object orientation here), which is a point Taylor seems to willfully ignore. That he chooses to use the terminology in this manner is rather sad because it puts an ugly stain on the respectability of the hackers -- those of us who not meddling in computer break-ins or other dubious activities, but merely hack code to produce cool software. Throughout the rest of this review I will be using the term cracker to refer to Taylor's hackers, and hacker when referring to real hackers

However, since crackers are a subset of hackers, much of Taylor's discussion on the hack and hacking is applicable to the hacker community at large. This is one of the things that makes Hackers an interesting read. For a newcomer to the hacker community Taylor's discussion on the 'hack' is quite enlightening. Even for oldtimers his discussion may shed some new light on the hack. Contrary to existing material on the matter, like the Jargon File, Taylor is the first to spell out the criteria implicit in earlier treatises on the hack: 1) simplicity, 2) mastery, and 3) illicitness [as in 'against the rules', reviewers comment] (p.15). This latter criteria is in its use of the 'illicitness' term only applicable to the cracking activity. In a sense it is applicable to hacking as well. Then in the shape of 'against the rules'. We are not neccessarily talking against the rules of justice, but against what the system's rules say is possible. In that sense, calling the third criteria illicitness hints at somewhat dubious activities, but is in fact not. It is an important element in the regular hack (if such thing as a regular hack does exist), too.

Taylor manages to view the hacker community from a fresh angle. Being a sociology researcher his angle is quite different from that represented by for instance Eric S. Raymond or Gisle Hannemyr. One drawback is that Taylor draws on Steven Levy's overly romanticized hacker ethics as presented in Levy's book of 1984: Hackers. It is time someone tried looking somewhat deeper into the hacker psychology to realize that while Levy's five tenets may to a certain degree represent attitudes within the hacker community, it is not, contrary to what Levy proposes, an ethos by which hackers live and die (apart from this, though, Levy's book is highly enjoyable and recommended reading). I'm also having some problems accepting the psychosexual theories on hacking that Taylor proposes. They seem a bit far fetched to me. It's been a while since everybody agreed that Freud's psycho-therapy was kind of overly sex-fixated.

Taylor addresses a largely ignored issue in hacker literature, that of the gender question. Why are there next to no female hackers? He addresses the point through looking at societal factors, by explaining how the community is a masculine environemnt -- the new wild west, so to say -- and the fact that electronic communication creates misogynity through its anonymity. At the end of the chapter it is a bit hard to grasp what Taylor's point is, though (see Presentation for more).

Another issue thoroughly treated is the question of hacker motivation. What drives the hacker to hack? Taylor's background within sociology is again helpful, as he regards the issue from a fresh perspective. Hacker motivation has previously been treated by Eric Raymond in his essay Homesteading the Noosphere . Taylor's angle is to compare academic theories on hacker motivation with the the reasons the hackers' themselves give. From the discrepancy between these two angles he lists four reasons for hacking: obsession, curiosity, boredom, and the feeling of power. If not directly contradicting Raymond's view -- that hackers hack simply to gain peer esteem and status within the community -- Taylor gives Raymond's view a more multi-faceted hue. He goes beneath the drive for esteem, trying to address the reasons why anyone would need to gain esteem from their peers. As such, Taylor manages to add something new to a discussion that has been on the brink of going stale.

Issues on computer security and cracking

Taylor's main focus on crackers is how society at large is to deal with them. Are crackers to be treated as criminal masterminds plotting to bring the world to its knees, or simply misguided kids trying to do something exciting with their computer knowledge? Several views are drawn up, with Taylor quoting representatives of each view without really making any kind of judgment himself as to the better way of handling crackers. It is an exercise in how difficult the question truly is.

A number of other quite intriguing cracker/computer security issues are spelled out by Taylor, as well. Issues include who is to blame when a computer system has been cracked? The system administrator for not maintaining sufficient security or the cracker for breaking into a system to which he doesn't have legal access? Should anti-cracking laws be targeted at stopping all kinds of illegal computer use, or are there degrees to the crime being committed? Is printing your personal CV on the company's printers even though it is explicitly forbidden to use company equipment for personal use to be treated as a computer crime equal to that of breaking into a banking system and tampering with the data?

Taylor also questions the computer security companies' motivations (and rightly so, one might add). Are they simply running a protection racket like that of the mafia, using cracking and virus alerts to scare their customers into investing in expensive counter-measure software? Or are they avenging angels siding with the innocent, the not particularly compu-fluent masses? Using the dichotomy of the computer security industry vs. the crackers, Taylor raises the issue of whether good computer security can only be achieved through knowing the enemy, the crackers. Can crackers and computer security consultants work together in a symbiosis, or are they eternal enemies never to be reconciliated?

Another issue dealt with is how crackers are to be handled. Should their acts be punished in the harshest way, or should they be helped into redirecting their activities into more useful terms? The question is whether the cracker is to be treated as a nuisance or as an asset. Taylor treats this issue quite thoroughly referring from the parliamentary discussion in Britain. He also discusses in what ways legislation can prevent cracking. He shows how little the law enforcement agencies know about cracking and how they employed overkill (refer to the Norwegian police's recent raid on the hacker who broke the DVD encryption).

Presentation

However intriguing the book might be it is presented in a very unorderly and weird way. The pages are filled with rather long quotations from various e-mails, books, interviews, etc. I gather the intention is to present the reader with the direct opinions of the book's "main characters," giving us in a way a first person view of the matter. The idea is nice, but the effect is that it ruins the fluidity of the text, making the book somewhat hard to follow. Also: it is at times quite difficult to grasp what message Taylor is trying to convey when he is expressing himself through the extracts of other people's opinions. Quotes are OK, but when, without exaggeration, 50% of the average page is taken up by quotations it is a little bit too much of the good stuff.

Having said that, the book is very structured, each chapter building nicely on previous chapters. The conclusion at the end of almost all chapters helps clarify Taylor's opinions a bit, which is nice. Still, it does not weigh up for the confusion created by the excessive use of quotations.

Conclusion

Taylor succeeds with explaining the relationship between crackers and the computer security industry, presenting the matter in a more multifaceted way than that of the mass media. The book is a definite must for those wanting an introduction to the social sides of computer security. However, I find it rather amazing that a book written in 1999 seems to totally ignore the writings of Eric Raymond, as these are probably the best works on how hackers view their own culture. Despite this, I believe Hackers might prove an interesting read even for the hardcore hacker, if only as an alternative look at our own culture.

Purchase this book at fatbrain.

Zortoaster wrote a review of a book that might be of interest to folks around here:" In lieu of the Norwegian police's crackdown on 16-year-old hacker Jon Johansen, who broke the DVD copying protection, Paul A. Taylor's book Hackers raises a series of interesting questions about crackers and cracking. The book scores high on content but lacks somewhat in presentation. He manages to spell out issues that are often only implicit in the computer security debate, and is able to paint a multi-faceted picture of the hacker, represented by the cracker, community setting it apart from the very black and white, good or bad, presentation of hackers in the mass media." Hackers author Paul A. Taylor pages 224 publisher Routledge, London: 09/1999 rating 7/10 reviewer Zortoaster ISBN 0415180724 summary In lieu of the Norwegian police's crackdown on 16 -year-old hacker Jon Johansen who broke the DVD copying protection, Paul A. Taylor's book Hackers raises a series of interesting questions about crackers and cracking. The book scores high on content but lacks somewhat in presentation. Hackers and hacking

Hackers starts out with a discussion on the hacker, what he (as is pointed out in the book, the hacker is almost always a 'he') does, and why he does what he does. Somewhat sadly, although fairly well-founded, is Taylor's choice of terminology. He chooses to consistently address the cracker as hacker. A hacker is not a cracker, but a cracker is always a hacker (put in more technical terms: the cracker is a subset of the hacker class -- think object orientation here), which is a point Taylor seems to willfully ignore. That he chooses to use the terminology in this manner is rather sad because it puts an ugly stain on the respectability of the hackers -- those of us who not meddling in computer break-ins or other dubious activities, but merely hack code to produce cool software. Throughout the rest of this review I will be using the term cracker to refer to Taylor's hackers, and hacker when referring to real hackers

However, since crackers are a subset of hackers, much of Taylor's discussion on the hack and hacking is applicable to the hacker community at large. This is one of the things that makes Hackers an interesting read. For a newcomer to the hacker community Taylor's discussion on the 'hack' is quite enlightening. Even for oldtimers his discussion may shed some new light on the hack. Contrary to existing material on the matter, like the Jargon File, Taylor is the first to spell out the criteria implicit in earlier treatises on the hack: 1) simplicity, 2) mastery, and 3) illicitness [as in 'against the rules', reviewers comment] (p.15). This latter criteria is in its use of the 'illicitness' term only applicable to the cracking activity. In a sense it is applicable to hacking as well. Then in the shape of 'against the rules'. We are not neccessarily talking against the rules of justice, but against what the system's rules say is possible. In that sense, calling the third criteria illicitness hints at somewhat dubious activities, but is in fact not. It is an important element in the regular hack (if such thing as a regular hack does exist), too.

Taylor manages to view the hacker community from a fresh angle. Being a sociology researcher his angle is quite different from that represented by for instance Eric S. Raymond or Gisle Hannemyr. One drawback is that Taylor draws on Steven Levy's overly romanticized hacker ethics as presented in Levy's book of 1984: Hackers. It is time someone tried looking somewhat deeper into the hacker psychology to realize that while Levy's five tenets may to a certain degree represent attitudes within the hacker community, it is not, contrary to what Levy proposes, an ethos by which hackers live and die (apart from this, though, Levy's book is highly enjoyable and recommended reading). I'm also having some problems accepting the psychosexual theories on hacking that Taylor proposes. They seem a bit far fetched to me. It's been a while since everybody agreed that Freud's psycho-therapy was kind of overly sex-fixated.

Taylor addresses a largely ignored issue in hacker literature, that of the gender question. Why are there next to no female hackers? He addresses the point through looking at societal factors, by explaining how the community is a masculine environemnt -- the new wild west, so to say -- and the fact that electronic communication creates misogynity through its anonymity. At the end of the chapter it is a bit hard to grasp what Taylor's point is, though (see Presentation for more).

Another issue thoroughly treated is the question of hacker motivation. What drives the hacker to hack? Taylor's background within sociology is again helpful, as he regards the issue from a fresh perspective. Hacker motivation has previously been treated by Eric Raymond in his essay Homesteading the Noosphere . Taylor's angle is to compare academic theories on hacker motivation with the the reasons the hackers' themselves give. From the discrepancy between these two angles he lists four reasons for hacking: obsession, curiosity, boredom, and the feeling of power. If not directly contradicting Raymond's view -- that hackers hack simply to gain peer esteem and status within the community -- Taylor gives Raymond's view a more multi-faceted hue. He goes beneath the drive for esteem, trying to address the reasons why anyone would need to gain esteem from their peers. As such, Taylor manages to add something new to a discussion that has been on the brink of going stale.

Issues on computer security and cracking

Taylor's main focus on crackers is how society at large is to deal with them. Are crackers to be treated as criminal masterminds plotting to bring the world to its knees, or simply misguided kids trying to do something exciting with their computer knowledge? Several views are drawn up, with Taylor quoting representatives of each view without really making any kind of judgment himself as to the better way of handling crackers. It is an exercise in how difficult the question truly is.

A number of other quite intriguing cracker/computer security issues are spelled out by Taylor, as well. Issues include who is to blame when a computer system has been cracked? The system administrator for not maintaining sufficient security or the cracker for breaking into a system to which he doesn't have legal access? Should anti-cracking laws be targeted at stopping all kinds of illegal computer use, or are there degrees to the crime being committed? Is printing your personal CV on the company's printers even though it is explicitly forbidden to use company equipment for personal use to be treated as a computer crime equal to that of breaking into a banking system and tampering with the data?

Taylor also questions the computer security companies' motivations (and rightly so, one might add). Are they simply running a protection racket like that of the mafia, using cracking and virus alerts to scare their customers into investing in expensive counter-measure software? Or are they avenging angels siding with the innocent, the not particularly compu-fluent masses? Using the dichotomy of the computer security industry vs. the crackers, Taylor raises the issue of whether good computer security can only be achieved through knowing the enemy, the crackers. Can crackers and computer security consultants work together in a symbiosis, or are they eternal enemies never to be reconciliated?

Another issue dealt with is how crackers are to be handled. Should their acts be punished in the harshest way, or should they be helped into redirecting their activities into more useful terms? The question is whether the cracker is to be treated as a nuisance or as an asset. Taylor treats this issue quite thoroughly referring from the parliamentary discussion in Britain. He also discusses in what ways legislation can prevent cracking. He shows how little the law enforcement agencies know about cracking and how they employed overkill (refer to the Norwegian police's recent raid on the hacker who broke the DVD encryption).

Presentation

However intriguing the book might be it is presented in a very unorderly and weird way. The pages are filled with rather long quotations from various e-mails, books, interviews, etc. I gather the intention is to present the reader with the direct opinions of the book's "main characters," giving us in a way a first person view of the matter. The idea is nice, but the effect is that it ruins the fluidity of the text, making the book somewhat hard to follow. Also: it is at times quite difficult to grasp what message Taylor is trying to convey when he is expressing himself through the extracts of other people's opinions. Quotes are OK, but when, without exaggeration, 50% of the average page is taken up by quotations it is a little bit too much of the good stuff.

Having said that, the book is very structured, each chapter building nicely on previous chapters. The conclusion at the end of almost all chapters helps clarify Taylor's opinions a bit, which is nice. Still, it does not weigh up for the confusion created by the excessive use of quotations.

Conclusion

Taylor succeeds with explaining the relationship between crackers and the computer security industry, presenting the matter in a more multifaceted way than that of the mass media. The book is a definite must for those wanting an introduction to the social sides of computer security. However, I find it rather amazing that a book written in 1999 seems to totally ignore the writings of Eric Raymond, as these are probably the best works on how hackers view their own culture. Despite this, I believe Hackers might prove an interesting read even for the hardcore hacker, if only as an alternative look at our own culture.

Purchase this book at fatbrain.

Zortoaster wrote a review of a book that might be of interest to folks around here:" In lieu of the Norwegian police's crackdown on 16-year-old hacker Jon Johansen, who broke the DVD copying protection, Paul A. Taylor's book Hackers raises a series of interesting questions about crackers and cracking. The book scores high on content but lacks somewhat in presentation. He manages to spell out issues that are often only implicit in the computer security debate, and is able to paint a multi-faceted picture of the hacker, represented by the cracker, community setting it apart from the very black and white, good or bad, presentation of hackers in the mass media." Hackers author Paul A. Taylor pages 224 publisher Routledge, London: 09/1999 rating 7/10 reviewer Zortoaster ISBN 0415180724 summary In lieu of the Norwegian police's crackdown on 16 -year-old hacker Jon Johansen who broke the DVD copying protection, Paul A. Taylor's book Hackers raises a series of interesting questions about crackers and cracking. The book scores high on content but lacks somewhat in presentation. Hackers and hacking

Hackers starts out with a discussion on the hacker, what he (as is pointed out in the book, the hacker is almost always a 'he') does, and why he does what he does. Somewhat sadly, although fairly well-founded, is Taylor's choice of terminology. He chooses to consistently address the cracker as hacker. A hacker is not a cracker, but a cracker is always a hacker (put in more technical terms: the cracker is a subset of the hacker class -- think object orientation here), which is a point Taylor seems to willfully ignore. That he chooses to use the terminology in this manner is rather sad because it puts an ugly stain on the respectability of the hackers -- those of us who not meddling in computer break-ins or other dubious activities, but merely hack code to produce cool software. Throughout the rest of this review I will be using the term cracker to refer to Taylor's hackers, and hacker when referring to real hackers

However, since crackers are a subset of hackers, much of Taylor's discussion on the hack and hacking is applicable to the hacker community at large. This is one of the things that makes Hackers an interesting read. For a newcomer to the hacker community Taylor's discussion on the 'hack' is quite enlightening. Even for oldtimers his discussion may shed some new light on the hack. Contrary to existing material on the matter, like the Jargon File, Taylor is the first to spell out the criteria implicit in earlier treatises on the hack: 1) simplicity, 2) mastery, and 3) illicitness [as in 'against the rules', reviewers comment] (p.15). This latter criteria is in its use of the 'illicitness' term only applicable to the cracking activity. In a sense it is applicable to hacking as well. Then in the shape of 'against the rules'. We are not neccessarily talking against the rules of justice, but against what the system's rules say is possible. In that sense, calling the third criteria illicitness hints at somewhat dubious activities, but is in fact not. It is an important element in the regular hack (if such thing as a regular hack does exist), too.

Taylor manages to view the hacker community from a fresh angle. Being a sociology researcher his angle is quite different from that represented by for instance Eric S. Raymond or Gisle Hannemyr. One drawback is that Taylor draws on Steven Levy's overly romanticized hacker ethics as presented in Levy's book of 1984: Hackers. It is time someone tried looking somewhat deeper into the hacker psychology to realize that while Levy's five tenets may to a certain degree represent attitudes within the hacker community, it is not, contrary to what Levy proposes, an ethos by which hackers live and die (apart from this, though, Levy's book is highly enjoyable and recommended reading). I'm also having some problems accepting the psychosexual theories on hacking that Taylor proposes. They seem a bit far fetched to me. It's been a while since everybody agreed that Freud's psycho-therapy was kind of overly sex-fixated.

Taylor addresses a largely ignored issue in hacker literature, that of the gender question. Why are there next to no female hackers? He addresses the point through looking at societal factors, by explaining how the community is a masculine environemnt -- the new wild west, so to say -- and the fact that electronic communication creates misogynity through its anonymity. At the end of the chapter it is a bit hard to grasp what Taylor's point is, though (see Presentation for more).

Another issue thoroughly treated is the question of hacker motivation. What drives the hacker to hack? Taylor's background within sociology is again helpful, as he regards the issue from a fresh perspective. Hacker motivation has previously been treated by Eric Raymond in his essay Homesteading the Noosphere . Taylor's angle is to compare academic theories on hacker motivation with the the reasons the hackers' themselves give. From the discrepancy between these two angles he lists four reasons for hacking: obsession, curiosity, boredom, and the feeling of power. If not directly contradicting Raymond's view -- that hackers hack simply to gain peer esteem and status within the community -- Taylor gives Raymond's view a more multi-faceted hue. He goes beneath the drive for esteem, trying to address the reasons why anyone would need to gain esteem from their peers. As such, Taylor manages to add something new to a discussion that has been on the brink of going stale.

Issues on computer security and cracking

Taylor's main focus on crackers is how society at large is to deal with them. Are crackers to be treated as criminal masterminds plotting to bring the world to its knees, or simply misguided kids trying to do something exciting with their computer knowledge? Several views are drawn up, with Taylor quoting representatives of each view without really making any kind of judgment himself as to the better way of handling crackers. It is an exercise in how difficult the question truly is.

A number of other quite intriguing cracker/computer security issues are spelled out by Taylor, as well. Issues include who is to blame when a computer system has been cracked? The system administrator for not maintaining sufficient security or the cracker for breaking into a system to which he doesn't have legal access? Should anti-cracking laws be targeted at stopping all kinds of illegal computer use, or are there degrees to the crime being committed? Is printing your personal CV on the company's printers even though it is explicitly forbidden to use company equipment for personal use to be treated as a computer crime equal to that of breaking into a banking system and tampering with the data?

Taylor also questions the computer security companies' motivations (and rightly so, one might add). Are they simply running a protection racket like that of the mafia, using cracking and virus alerts to scare their customers into investing in expensive counter-measure software? Or are they avenging angels siding with the innocent, the not particularly compu-fluent masses? Using the dichotomy of the computer security industry vs. the crackers, Taylor raises the issue of whether good computer security can only be achieved through knowing the enemy, the crackers. Can crackers and computer security consultants work together in a symbiosis, or are they eternal enemies never to be reconciliated?

Another issue dealt with is how crackers are to be handled. Should their acts be punished in the harshest way, or should they be helped into redirecting their activities into more useful terms? The question is whether the cracker is to be treated as a nuisance or as an asset. Taylor treats this issue quite thoroughly referring from the parliamentary discussion in Britain. He also discusses in what ways legislation can prevent cracking. He shows how little the law enforcement agencies know about cracking and how they employed overkill (refer to the Norwegian police's recent raid on the hacker who broke the DVD encryption).

Presentation

However intriguing the book might be it is presented in a very unorderly and weird way. The pages are filled with rather long quotations from various e-mails, books, interviews, etc. I gather the intention is to present the reader with the direct opinions of the book's "main characters," giving us in a way a first person view of the matter. The idea is nice, but the effect is that it ruins the fluidity of the text, making the book somewhat hard to follow. Also: it is at times quite difficult to grasp what message Taylor is trying to convey when he is expressing himself through the extracts of other people's opinions. Quotes are OK, but when, without exaggeration, 50% of the average page is taken up by quotations it is a little bit too much of the good stuff.

Having said that, the book is very structured, each chapter building nicely on previous chapters. The conclusion at the end of almost all chapters helps clarify Taylor's opinions a bit, which is nice. Still, it does not weigh up for the confusion created by the excessive use of quotations.

Conclusion

Taylor succeeds with explaining the relationship between crackers and the computer security industry, presenting the matter in a more multifaceted way than that of the mass media. The book is a definite must for those wanting an introduction to the social sides of computer security. However, I find it rather amazing that a book written in 1999 seems to totally ignore the writings of Eric Raymond, as these are probably the best works on how hackers view their own culture. Despite this, I believe Hackers might prove an interesting read even for the hardcore hacker, if only as an alternative look at our own culture.

Purchase this book at fatbrain.

Zortoaster wrote a review of a book that might be of interest to folks around here:" In lieu of the Norwegian police's crackdown on 16-year-old hacker Jon Johansen, who broke the DVD copying protection, Paul A. Taylor's book Hackers raises a series of interesting questions about crackers and cracking. The book scores high on content but lacks somewhat in presentation. He manages to spell out issues that are often only implicit in the computer security debate, and is able to paint a multi-faceted picture of the hacker, represented by the cracker, community setting it apart from the very black and white, good or bad, presentation of hackers in the mass media." Hackers author Paul A. Taylor pages 224 publisher Routledge, London: 09/1999 rating 7/10 reviewer Zortoaster ISBN 0415180724 summary In lieu of the Norwegian police's crackdown on 16 -year-old hacker Jon Johansen who broke the DVD copying protection, Paul A. Taylor's book Hackers raises a series of interesting questions about crackers and cracking. The book scores high on content but lacks somewhat in presentation. Hackers and hacking

Hackers starts out with a discussion on the hacker, what he (as is pointed out in the book, the hacker is almost always a 'he') does, and why he does what he does. Somewhat sadly, although fairly well-founded, is Taylor's choice of terminology. He chooses to consistently address the cracker as hacker. A hacker is not a cracker, but a cracker is always a hacker (put in more technical terms: the cracker is a subset of the hacker class -- think object orientation here), which is a point Taylor seems to willfully ignore. That he chooses to use the terminology in this manner is rather sad because it puts an ugly stain on the respectability of the hackers -- those of us who not meddling in computer break-ins or other dubious activities, but merely hack code to produce cool software. Throughout the rest of this review I will be using the term cracker to refer to Taylor's hackers, and hacker when referring to real hackers

However, since crackers are a subset of hackers, much of Taylor's discussion on the hack and hacking is applicable to the hacker community at large. This is one of the things that makes Hackers an interesting read. For a newcomer to the hacker community Taylor's discussion on the 'hack' is quite enlightening. Even for oldtimers his discussion may shed some new light on the hack. Contrary to existing material on the matter, like the Jargon File, Taylor is the first to spell out the criteria implicit in earlier treatises on the hack: 1) simplicity, 2) mastery, and 3) illicitness [as in 'against the rules', reviewers comment] (p.15). This latter criteria is in its use of the 'illicitness' term only applicable to the cracking activity. In a sense it is applicable to hacking as well. Then in the shape of 'against the rules'. We are not neccessarily talking against the rules of justice, but against what the system's rules say is possible. In that sense, calling the third criteria illicitness hints at somewhat dubious activities, but is in fact not. It is an important element in the regular hack (if such thing as a regular hack does exist), too.

Taylor manages to view the hacker community from a fresh angle. Being a sociology researcher his angle is quite different from that represented by for instance Eric S. Raymond or Gisle Hannemyr. One drawback is that Taylor draws on Steven Levy's overly romanticized hacker ethics as presented in Levy's book of 1984: Hackers. It is time someone tried looking somewhat deeper into the hacker psychology to realize that while Levy's five tenets may to a certain degree represent attitudes within the hacker community, it is not, contrary to what Levy proposes, an ethos by which hackers live and die (apart from this, though, Levy's book is highly enjoyable and recommended reading). I'm also having some problems accepting the psychosexual theories on hacking that Taylor proposes. They seem a bit far fetched to me. It's been a while since everybody agreed that Freud's psycho-therapy was kind of overly sex-fixated.

Taylor addresses a largely ignored issue in hacker literature, that of the gender question. Why are there next to no female hackers? He addresses the point through looking at societal factors, by explaining how the community is a masculine environemnt -- the new wild west, so to say -- and the fact that electronic communication creates misogynity through its anonymity. At the end of the chapter it is a bit hard to grasp what Taylor's point is, though (see Presentation for more).

Another issue thoroughly treated is the question of hacker motivation. What drives the hacker to hack? Taylor's background within sociology is again helpful, as he regards the issue from a fresh perspective. Hacker motivation has previously been treated by Eric Raymond in his essay Homesteading the Noosphere . Taylor's angle is to compare academic theories on hacker motivation with the the reasons the hackers' themselves give. From the discrepancy between these two angles he lists four reasons for hacking: obsession, curiosity, boredom, and the feeling of power. If not directly contradicting Raymond's view -- that hackers hack simply to gain peer esteem and status within the community -- Taylor gives Raymond's view a more multi-faceted hue. He goes beneath the drive for esteem, trying to address the reasons why anyone would need to gain esteem from their peers. As such, Taylor manages to add something new to a discussion that has been on the brink of going stale.

Issues on computer security and cracking

Taylor's main focus on crackers is how society at large is to deal with them. Are crackers to be treated as criminal masterminds plotting to bring the world to its knees, or simply misguided kids trying to do something exciting with their computer knowledge? Several views are drawn up, with Taylor quoting representatives of each view without really making any kind of judgment himself as to the better way of handling crackers. It is an exercise in how difficult the question truly is.

A number of other quite intriguing cracker/computer security issues are spelled out by Taylor, as well. Issues include who is to blame when a computer system has been cracked? The system administrator for not maintaining sufficient security or the cracker for breaking into a system to which he doesn't have legal access? Should anti-cracking laws be targeted at stopping all kinds of illegal computer use, or are there degrees to the crime being committed? Is printing your personal CV on the company's printers even though it is explicitly forbidden to use company equipment for personal use to be treated as a computer crime equal to that of breaking into a banking system and tampering with the data?

Taylor also questions the computer security companies' motivations (and rightly so, one might add). Are they simply running a protection racket like that of the mafia, using cracking and virus alerts to scare their customers into investing in expensive counter-measure software? Or are they avenging angels siding with the innocent, the not particularly compu-fluent masses? Using the dichotomy of the computer security industry vs. the crackers, Taylor raises the issue of whether good computer security can only be achieved through knowing the enemy, the crackers. Can crackers and computer security consultants work together in a symbiosis, or are they eternal enemies never to be reconciliated?

Another issue dealt with is how crackers are to be handled. Should their acts be punished in the harshest way, or should they be helped into redirecting their activities into more useful terms? The question is whether the cracker is to be treated as a nuisance or as an asset. Taylor treats this issue quite thoroughly referring from the parliamentary discussion in Britain. He also discusses in what ways legislation can prevent cracking. He shows how little the law enforcement agencies know about cracking and how they employed overkill (refer to the Norwegian police's recent raid on the hacker who broke the DVD encryption).

Presentation

However intriguing the book might be it is presented in a very unorderly and weird way. The pages are filled with rather long quotations from various e-mails, books, interviews, etc. I gather the intention is to present the reader with the direct opinions of the book's "main characters," giving us in a way a first person view of the matter. The idea is nice, but the effect is that it ruins the fluidity of the text, making the book somewhat hard to follow. Also: it is at times quite difficult to grasp what message Taylor is trying to convey when he is expressing himself through the extracts of other people's opinions. Quotes are OK, but when, without exaggeration, 50% of the average page is taken up by quotations it is a little bit too much of the good stuff.

Having said that, the book is very structured, each chapter building nicely on previous chapters. The conclusion at the end of almost all chapters helps clarify Taylor's opinions a bit, which is nice. Still, it does not weigh up for the confusion created by the excessive use of quotations.

Conclusion

Taylor succeeds with explaining the relationship between crackers and the computer security industry, presenting the matter in a more multifaceted way than that of the mass media. The book is a definite must for those wanting an introduction to the social sides of computer security. However, I find it rather amazing that a book written in 1999 seems to totally ignore the writings of Eric Raymond, as these are probably the best works on how hackers view their own culture. Despite this, I believe Hackers might prove an interesting read even for the hardcore hacker, if only as an alternative look at our own culture.

Purchase this book at fatbrain.

Zortoaster wrote a review of a book that might be of interest to folks around here:" In lieu of the Norwegian police's crackdown on 16-year-old hacker Jon Johansen, who broke the DVD copying protection, Paul A. Taylor's book Hackers raises a series of interesting questions about crackers and cracking. The book scores high on content but lacks somewhat in presentation. He manages to spell out issues that are often only implicit in the computer security debate, and is able to paint a multi-faceted picture of the hacker, represented by the cracker, community setting it apart from the very black and white, good or bad, presentation of hackers in the mass media." Hackers author Paul A. Taylor pages 224 publisher Routledge, London: 09/1999 rating 7/10 reviewer Zortoaster ISBN 0415180724 summary In lieu of the Norwegian police's crackdown on 16 -year-old hacker Jon Johansen who broke the DVD copying protection, Paul A. Taylor's book Hackers raises a series of interesting questions about crackers and cracking. The book scores high on content but lacks somewhat in presentation. Hackers and hacking

Hackers starts out with a discussion on the hacker, what he (as is pointed out in the book, the hacker is almost always a 'he') does, and why he does what he does. Somewhat sadly, although fairly well-founded, is Taylor's choice of terminology. He chooses to consistently address the cracker as hacker. A hacker is not a cracker, but a cracker is always a hacker (put in more technical terms: the cracker is a subset of the hacker class -- think object orientation here), which is a point Taylor seems to willfully ignore. That he chooses to use the terminology in this manner is rather sad because it puts an ugly stain on the respectability of the hackers -- those of us who not meddling in computer break-ins or other dubious activities, but merely hack code to produce cool software. Throughout the rest of this review I will be using the term cracker to refer to Taylor's hackers, and hacker when referring to real hackers

However, since crackers are a subset of hackers, much of Taylor's discussion on the hack and hacking is applicable to the hacker community at large. This is one of the things that makes Hackers an interesting read. For a newcomer to the hacker community Taylor's discussion on the 'hack' is quite enlightening. Even for oldtimers his discussion may shed some new light on the hack. Contrary to existing material on the matter, like the Jargon File, Taylor is the first to spell out the criteria implicit in earlier treatises on the hack: 1) simplicity, 2) mastery, and 3) illicitness [as in 'against the rules', reviewers comment] (p.15). This latter criteria is in its use of the 'illicitness' term only applicable to the cracking activity. In a sense it is applicable to hacking as well. Then in the shape of 'against the rules'. We are not neccessarily talking against the rules of justice, but against what the system's rules say is possible. In that sense, calling the third criteria illicitness hints at somewhat dubious activities, but is in fact not. It is an important element in the regular hack (if such thing as a regular hack does exist), too.

Taylor manages to view the hacker community from a fresh angle. Being a sociology researcher his angle is quite different from that represented by for instance Eric S. Raymond or Gisle Hannemyr. One drawback is that Taylor draws on Steven Levy's overly romanticized hacker ethics as presented in Levy's book of 1984: Hackers. It is time someone tried looking somewhat deeper into the hacker psychology to realize that while Levy's five tenets may to a certain degree represent attitudes within the hacker community, it is not, contrary to what Levy proposes, an ethos by which hackers live and die (apart from this, though, Levy's book is highly enjoyable and recommended reading). I'm also having some problems accepting the psychosexual theories on hacking that Taylor proposes. They seem a bit far fetched to me. It's been a while since everybody agreed that Freud's psycho-therapy was kind of overly sex-fixated.

Taylor addresses a largely ignored issue in hacker literature, that of the gender question. Why are there next to no female hackers? He addresses the point through looking at societal factors, by explaining how the community is a masculine environemnt -- the new wild west, so to say -- and the fact that electronic communication creates misogynity through its anonymity. At the end of the chapter it is a bit hard to grasp what Taylor's point is, though (see Presentation for more).

Another issue thoroughly treated is the question of hacker motivation. What drives the hacker to hack? Taylor's background within sociology is again helpful, as he regards the issue from a fresh perspective. Hacker motivation has previously been treated by Eric Raymond in his essay Homesteading the Noosphere . Taylor's angle is to compare academic theories on hacker motivation with the the reasons the hackers' themselves give. From the discrepancy between these two angles he lists four reasons for hacking: obsession, curiosity, boredom, and the feeling of power. If not directly contradicting Raymond's view -- that hackers hack simply to gain peer esteem and status within the community -- Taylor gives Raymond's view a more multi-faceted hue. He goes beneath the drive for esteem, trying to address the reasons why anyone would need to gain esteem from their peers. As such, Taylor manages to add something new to a discussion that has been on the brink of going stale.

Issues on computer security and cracking

Taylor's main focus on crackers is how society at large is to deal with them. Are crackers to be treated as criminal masterminds plotting to bring the world to its knees, or simply misguided kids trying to do something exciting with their computer knowledge? Several views are drawn up, with Taylor quoting representatives of each view without really making any kind of judgment himself as to the better way of handling crackers. It is an exercise in how difficult the question truly is.

A number of other quite intriguing cracker/computer security issues are spelled out by Taylor, as well. Issues include who is to blame when a computer system has been cracked? The system administrator for not maintaining sufficient security or the cracker for breaking into a system to which he doesn't have legal access? Should anti-cracking laws be targeted at stopping all kinds of illegal computer use, or are there degrees to the crime being committed? Is printing your personal CV on the company's printers even though it is explicitly forbidden to use company equipment for personal use to be treated as a computer crime equal to that of breaking into a banking system and tampering with the data?

Taylor also questions the computer security companies' motivations (and rightly so, one might add). Are they simply running a protection racket like that of the mafia, using cracking and virus alerts to scare their customers into investing in expensive counter-measure software? Or are they avenging angels siding with the innocent, the not particularly compu-fluent masses? Using the dichotomy of the computer security industry vs. the crackers, Taylor raises the issue of whether good computer security can only be achieved through knowing the enemy, the crackers. Can crackers and computer security consultants work together in a symbiosis, or are they eternal enemies never to be reconciliated?

Another issue dealt with is how crackers are to be handled. Should their acts be punished in the harshest way, or should they be helped into redirecting their activities into more useful terms? The question is whether the cracker is to be treated as a nuisance or as an asset. Taylor treats this issue quite thoroughly referring from the parliamentary discussion in Britain. He also discusses in what ways legislation can prevent cracking. He shows how little the law enforcement agencies know about cracking and how they employed overkill (refer to the Norwegian police's recent raid on the hacker who broke the DVD encryption).

Presentation

However intriguing the book might be it is presented in a very unorderly and weird way. The pages are filled with rather long quotations from various e-mails, books, interviews, etc. I gather the intention is to present the reader with the direct opinions of the book's "main characters," giving us in a way a first person view of the matter. The idea is nice, but the effect is that it ruins the fluidity of the text, making the book somewhat hard to follow. Also: it is at times quite difficult to grasp what message Taylor is trying to convey when he is expressing himself through the extracts of other people's opinions. Quotes are OK, but when, without exaggeration, 50% of the average page is taken up by quotations it is a little bit too much of the good stuff.

Having said that, the book is very structured, each chapter building nicely on previous chapters. The conclusion at the end of almost all chapters helps clarify Taylor's opinions a bit, which is nice. Still, it does not weigh up for the confusion created by the excessive use of quotations.

Conclusion

Taylor succeeds with explaining the relationship between crackers and the computer security industry, presenting the matter in a more multifaceted way than that of the mass media. The book is a definite must for those wanting an introduction to the social sides of computer security. However, I find it rather amazing that a book written in 1999 seems to totally ignore the writings of Eric Raymond, as these are probably the best works on how hackers view their own culture. Despite this, I believe Hackers might prove an interesting read even for the hardcore hacker, if only as an alternative look at our own culture.

Purchase this book at fatbrain.

Zortoaster wrote a review of a book that might be of interest to folks around here:" In lieu of the Norwegian police's crackdown on 16-year-old hacker Jon Johansen, who broke the DVD copying protection, Paul A. Taylor's book Hackers raises a series of interesting questions about crackers and cracking. The book scores high on content but lacks somewhat in presentation. He manages to spell out issues that are often only implicit in the computer security debate, and is able to paint a multi-faceted picture of the hacker, represented by the cracker, community setting it apart from the very black and white, good or bad, presentation of hackers in the mass media." Hackers author Paul A. Taylor pages 224 publisher Routledge, London: 09/1999 rating 7/10 reviewer Zortoaster ISBN 0415180724 summary In lieu of the Norwegian police's crackdown on 16 -year-old hacker Jon Johansen who broke the DVD copying protection, Paul A. Taylor's book Hackers raises a series of interesting questions about crackers and cracking. The book scores high on content but lacks somewhat in presentation. Hackers and hacking

Hackers starts out with a discussion on the hacker, what he (as is pointed out in the book, the hacker is almost always a 'he') does, and why he does what he does. Somewhat sadly, although fairly well-founded, is Taylor's choice of terminology. He chooses to consistently address the cracker as hacker. A hacker is not a cracker, but a cracker is always a hacker (put in more technical terms: the cracker is a subset of the hacker class -- think object orientation here), which is a point Taylor seems to willfully ignore. That he chooses to use the terminology in this manner is rather sad because it puts an ugly stain on the respectability of the hackers -- those of us who not meddling in computer break-ins or other dubious activities, but merely hack code to produce cool software. Throughout the rest of this review I will be using the term cracker to refer to Taylor's hackers, and hacker when referring to real hackers

However, since crackers are a subset of hackers, much of Taylor's discussion on the hack and hacking is applicable to the hacker community at large. This is one of the things that makes Hackers an interesting read. For a newcomer to the hacker community Taylor's discussion on the 'hack' is quite enlightening. Even for oldtimers his discussion may shed some new light on the hack. Contrary to existing material on the matter, like the Jargon File, Taylor is the first to spell out the criteria implicit in earlier treatises on the hack: 1) simplicity, 2) mastery, and 3) illicitness [as in 'against the rules', reviewers comment] (p.15). This latter criteria is in its use of the 'illicitness' term only applicable to the cracking activity. In a sense it is applicable to hacking as well. Then in the shape of 'against the rules'. We are not neccessarily talking against the rules of justice, but against what the system's rules say is possible. In that sense, calling the third criteria illicitness hints at somewhat dubious activities, but is in fact not. It is an important element in the regular hack (if such thing as a regular hack does exist), too.

Taylor manages to view the hacker community from a fresh angle. Being a sociology researcher his angle is quite different from that represented by for instance Eric S. Raymond or Gisle Hannemyr. One drawback is that Taylor draws on Steven Levy's overly romanticized hacker ethics as presented in Levy's book of 1984: Hackers. It is time someone tried looking somewhat deeper into the hacker psychology to realize that while Levy's five tenets may to a certain degree represent attitudes within the hacker community, it is not, contrary to what Levy proposes, an ethos by which hackers live and die (apart from this, though, Levy's book is highly enjoyable and recommended reading). I'm also having some problems accepting the psychosexual theories on hacking that Taylor proposes. They seem a bit far fetched to me. It's been a while since everybody agreed that Freud's psycho-therapy was kind of overly sex-fixated.

Taylor addresses a largely ignored issue in hacker literature, that of the gender question. Why are there next to no female hackers? He addresses the point through looking at societal factors, by explaining how the community is a masculine environemnt -- the new wild west, so to say -- and the fact that electronic communication creates misogynity through its anonymity. At the end of the chapter it is a bit hard to grasp what Taylor's point is, though (see Presentation for more).

Another issue thoroughly treated is the question of hacker motivation. What drives the hacker to hack? Taylor's background within sociology is again helpful, as he regards the issue from a fresh perspective. Hacker motivation has previously been treated by Eric Raymond in his essay Homesteading the Noosphere . Taylor's angle is to compare academic theories on hacker motivation with the the reasons the hackers' themselves give. From the discrepancy between these two angles he lists four reasons for hacking: obsession, curiosity, boredom, and the feeling of power. If not directly contradicting Raymond's view -- that hackers hack simply to gain peer esteem and status within the community -- Taylor gives Raymond's view a more multi-faceted hue. He goes beneath the drive for esteem, trying to address the reasons why anyone would need to gain esteem from their peers. As such, Taylor manages to add something new to a discussion that has been on the brink of going stale.

Issues on computer security and cracking

Taylor's main focus on crackers is how society at large is to deal with them. Are crackers to be treated as criminal masterminds plotting to bring the world to its knees, or simply misguided kids trying to do something exciting with their computer knowledge? Several views are drawn up, with Taylor quoting representatives of each view without really making any kind of judgment himself as to the better way of handling crackers. It is an exercise in how difficult the question truly is.

A number of other quite intriguing cracker/computer security issues are spelled out by Taylor, as well. Issues include who is to blame when a computer system has been cracked? The system administrator for not maintaining sufficient security or the cracker for breaking into a system to which he doesn't have legal access? Should anti-cracking laws be targeted at stopping all kinds of illegal computer use, or are there degrees to the crime being committed? Is printing your personal CV on the company's printers even though it is explicitly forbidden to use company equipment for personal use to be treated as a computer crime equal to that of breaking into a banking system and tampering with the data?

Taylor also questions the computer security companies' motivations (and rightly so, one might add). Are they simply running a protection racket like that of the mafia, using cracking and virus alerts to scare their customers into investing in expensive counter-measure software? Or are they avenging angels siding with the innocent, the not particularly compu-fluent masses? Using the dichotomy of the computer security industry vs. the crackers, Taylor raises the issue of whether good computer security can only be achieved through knowing the enemy, the crackers. Can crackers and computer security consultants work together in a symbiosis, or are they eternal enemies never to be reconciliated?

Another issue dealt with is how crackers are to be handled. Should their acts be punished in the harshest way, or should they be helped into redirecting their activities into more useful terms? The question is whether the cracker is to be treated as a nuisance or as an asset. Taylor treats this issue quite thoroughly referring from the parliamentary discussion in Britain. He also discusses in what ways legislation can prevent cracking. He shows how little the law enforcement agencies know about cracking and how they employed overkill (refer to the Norwegian police's recent raid on the hacker who broke the DVD encryption).

Presentation

However intriguing the book might be it is presented in a very unorderly and weird way. The pages are filled with rather long quotations from various e-mails, books, interviews, etc. I gather the intention is to present the reader with the direct opinions of the book's "main characters," giving us in a way a first person view of the matter. The idea is nice, but the effect is that it ruins the fluidity of the text, making the book somewhat hard to follow. Also: it is at times quite difficult to grasp what message Taylor is trying to convey when he is expressing himself through the extracts of other people's opinions. Quotes are OK, but when, without exaggeration, 50% of the average page is taken up by quotations it is a little bit too much of the good stuff.

Having said that, the book is very structured, each chapter building nicely on previous chapters. The conclusion at the end of almost all chapters helps clarify Taylor's opinions a bit, which is nice. Still, it does not weigh up for the confusion created by the excessive use of quotations.

Conclusion

Taylor succeeds with explaining the relationship between crackers and the computer security industry, presenting the matter in a more multifaceted way than that of the mass media. The book is a definite must for those wanting an introduction to the social sides of computer security. However, I find it rather amazing that a book written in 1999 seems to totally ignore the writings of Eric Raymond, as these are probably the best works on how hackers view their own culture. Despite this, I believe Hackers might prove an interesting read even for the hardcore hacker, if only as an alternative look at our own culture.

Purchase this book at fatbrain.

hasse writes "The Swedish Interactive Institute has developed an interesting new game called Brainball. The rules are simple; a steel ball on the playing field is controlled by biosensors on the players' heads, and the player with the least brain activity wins. A slackers game if I ever saw one. Kinda reminds me of the Amiga guru meditation game. The text about Brainball is only in Swedish but they've got an English section here."

Every year I pick a new years resolution and ever year it doesn't come true. This year I've opted to set my sights low so I can greatly increase the chance of suceeding for once. This year my resolution is to continue converting oxygen into carbon dioxide. Read on to learn what resolutions RMS, ESR, Jon Katz, CowboyNeal, Mandrake and others have for the year 2000.

Jason Haas from LinuxPPC has the following resolutions: "248x768 @ 85 Hz, Merge my world domination plans with Linus's tree, Kawasaka W650:It will be mine (a Virago would be ok), Restart akido, and mv competition to /dev/null

Jon Katz , Slashdot's favorite gasbag says " I wish for Walt Disney to thaw himself out, climb out of his Cryogenimatronic Vault, show up at Walt Disney World and wreak havoc on the corporate weenies who desecrated EPCOT, his model city of tomorrow. Maybe join with the Seattle protesters and touch off a war against corporatist weenies everywhere. "

Emmett Plant is the latest editorial addition to the Slashdot Authors roster. His resolution is "to start a company called 'EmmettLinux,' which will be responsible for creating no product whatsoever. We will employ a highly-paid staff of fifty people who will show up every day and start throwing money into a furnace. I hope to IPO by March and use the cash to hire 2,000 more moneyburners and open an office in Hong Kong. I will leave soon after, selling all of my stock and retiring to the Bahamas."

Chris J. DiBona , Linux Community Evangelist for VA Linux Systems, President of SVLUG, and Grant Chair for LI, has resolved the following: ".Sleep is high on my list, but I really just like to have more time to read, this year has been pretty hard-core. I'd also like to spend more time learning power supply electronics, dc-dc transformers and such. I'm already pretty good with the digital side of things, but this is a big gap in my knowledge. Can I give more than two? I'd also like a puppy. A puppy with an X10 Cam mounted on its collar so I can put a "puppy cam" online."

Rusty Russell , kernel hacker and mad genius wishes to Learn to cook. Or trade kernel code for food. Or buy a fire extinguisher.

Eric S. Raymond is perhaps better known simply as esr... and if you don't know who he is, well, ouch. He resolves to " Catch up with my email and cut down on my traveling. It's nice to be needed, but 50% time on the road is getting ridiculous..."

Raster aka "That Enlightenment Guy" who is the only living person with more typos than me resolves simply to use procmail to allow more sleep time.

Mandrake resolves "I really need to start taking better care of my body. I haven't really worked out in about a year - and I eat too much garbage (junk food / fast food), and I REALLY need to stop drinking coke. I go through 2liters like most people drink cans of coke. I don't think it'll happen any time soon - but hopefully I'll at least be a little healthier by the end of the year."

Trae McCombs , aka X, aka MC, aka 'That Linux.com guy' resolves to "Learn to eat more foods, Incorporate working out into my lifestyle, Work less than 14hrs a day, Be kinder to others, Listen more, Talk less, Learn to code, Read more, Keep true to my ideals..."

Scott Draeker , the President of Loki Entertainment Software resolves to release a first tier Linux game which is not available for windows. Hard to argue with that one.

Kurt DeMaagd , aka The Pope, aka Rob's Roommate and the BSI number cruncher has the following:

1. Combat bimetallism and establish the gold standard for currency.
2. Negotiate the DeMaagd-Hay-Pauncefote treaty, allowing the U.S. to unilaterally construct an isthmian canal.
3. Establish an American protectorate in Cuba.
4. Suppress the Boxer uprising.

Mind you if you look closely at Kurt's resolutions, you might notice that they look strikingly similiar to President William McKinley's adminstration's high points. I'm going to have to up kurts medication.

Illiad , creator of the ever popular User Friendly comic strip says "I resolve to only take responsibility for those choices that I have control over. That means I have to give up on the idea of educating the technically-resistant, the doublespeak-inclined, and the village idiot."

Richard M. Stallman , founder of the Free Software Founding and the GNU Project gave us suggested resolutions for Slashdot readers: They are 1. Do not install any non-free software your computers and 2. Do not buy from Amazon until they stop using software patents for aggression.

CowboyNeal , the man, the myth, the legend. The guy who responds when users can't figure out how to login. The guy who maintains the slashboxes. And the guy who inhabitants the living room in the Geek Compound, resolves that he shall "Shower Every Week, whether I needs it or not." All of the co-workers in this office who have orafactory functionality thank him. It doesn't matter to me much either way.

Jim Jagielski , aka jimjag or jim@apache.org or jim@jaguNET.com, resolves to call sleep(28800) a lot more often.

Nitrozac is the creator of After Y2k... which as best as I can tell means she's about to work herself out of a job. But regardless she says "If civilization manages to hold on to its tenuous existence, I'd like to find a cure for Agalmatophilia, and have others join me to rid the world of this illness that causes so much needless suffering. If civilization crumbles, my Post-Apocalypse Resolution is to learn how to do 16-bead graphics on my abacus, so I can continue the comic. ;-)"

And finally (thank god because my wrists are tired) is Jeff "Hemos" Bates , a man who needs no introduction (but he does need a solid smack to the head).He says "With the coming of El Ano Neuvo, I resolve that I'm going to continue my battle against the dread forces of The Krull Invasion. I think that I might also try to learn some grammar. Per'aps. And maybe I'll learn how to spell a few more words as well".

ESR as chimed in to say his bit on the recent quake problems that popped up following the source release. Its definitely a problem that will happen again and something that needs to be handled. Read what he has to say about it.

The following was written by ESR. You know who he is already ;)

The case of quake cheats The open-source community got a lump of coal in its Yule 1999 stocking from renowned hacker John Carmack, the genius behind id Software and such games as Castle Wolfenstein, Doom, and the Quake series. Carmack's .plan file noted a problem that has swiftly emerged since the Quake 1 source was released under GPL; it seems that some people have used their ability to modify the Quake client as a mechanism for cheating.

This may at first sight seem a trivial issue -- who cares if a few testoterone-pumped teenagers cheat at a shoot-em-up game? But in today's internetworked world, countermeasures against Quake cheating arguably provide an important laboratory model for cases that are decidedly not trivial, such as electronic commerce, securities trading, and banking.

The Quake model is made particularly relevant by its open-source connection. Open source advocates (including me) have been making a strong argument over the last two years that open-source software such as Linux and Apache is fundamentally more secure than its closed-source competitors. Cryptographers have long understood that no encryption system can really be considered well-tested until it has been energetically and repeatedly attacked by experts who have full knowledge of the algorithms it uses. Open-source advocates argue that there is nothing special about cryptography but its high stakes -- that, in general, open peer review is the only road to systems which are not merely accidentally secure by obscurity, but robustly secure by design.

Carmack, therefore, caused a bit of a flutter on Slashdot when he went on to to suggest that only a pair of closed-source encryption programs could solve the Quake-cheating problem. The problem, as he correctly pointed out, is that asking the open-source client to verify its own correctness won't work; a sufficiently clever cracker could always write a client that would simulate the right kinds of responses and then cheat.

A debate ensued, with several people pointing out that trusting the client half of a client-server pair is bad security policy whether the client code is open or closed. Fundamentally, there's no way for the server to be sure it isn't talking to a clever simulation of `correct' behavior. Thus, opening the source to Quake 1 didn't create security problems, it merely exposed one that was already present (and exploitable, and for all anyone knew already secretly exploited) in the design of the game.

Carmack weighed in to make clear that the Quake-cheating problem is subtler than many of the debators were assuming. It's not possible for a cheating client to give a player infinite ammunition or life points; the server does not in fact trust the client about these things, and manages them itself. This is correct design; whether or not it's open-source, a bank should not depend on a customer's client software to tell the bank what the cutomer's balance is!

Carmack observes that "the [cheating] clients/proxies focus on two main areas -- giving the player more information than they should have, and performing actions more skillfully."

The serious "more information" cheats depend on a performance hack. In order to hold down the number of updates of the Quake world it has to pass to the client, the server gives the client information about the location of objects and opponents that the player can't yet see, but might be able to see before the next update. The server then counts on the client not to make those things visible until they "should" be (e.g, until the user gets to a particular location in the maze the client is simulating). A cheating client can reveal an opponent seconds before the player would turn the corner and expose himself to fire.

The "more skillfully" cheats substitute the computer's speed and accuracy for tasks that the server and other players expect the player's hands and brain to be performing. Carmack talks about "aim bots" which automatically lock the player's gun onto visible opponents and fire it with inhuman accuracy.

And indeed it's hard to see how either of these sorts of cheats can be prevented given an open-source client and no way independent of the client itself to check that the client is honest. Thus Carmack's suggestion of a closed-source Quake-launcher program that would take a checksum of the client binary, communicate with the server to make sure the binary is on an approved list, and then handle communication with the server over a cryptographically-secured channel.

Carmack's argument seems watertight. What's wrong with this picture? Are we really looking at a demonstration that closed source is necessary for security? And if not, what can we learn about securing our systems from the Quake case?

I think one major lesson is simple. It's this: if you want a really secure system, you can't trade away security to get performance. Quake makes this trade by sending anticipatory information for the client to cache in order to lower its update rate. Carmack read this essay in draft and commented "With a sub-100 msec ping and extremely steady latency, it would be possible to force a synchronous update with no extra information at all, but in the world of 200-400 msec latency [and] low bandwidth modems, it just plain wouldn't work." So it may have been a necessary choice under the constraints for which Quake was designed, but it violates the first rule of good security design: minimum disclosure.

When you do that, you should expect to get cracked, whether your client is open or closed -- and, indeed, Carmack himself points out that the see-around-corners cheat can be implemented by a scanner proxy sitting between a closed client and the server and filtering communicatiuons from server to client.

Closing the source of the client may obscure the protocol between client and server, but that won't stop a clever cracker with a packet sniffer and too much time on his hands. Carmack confirms that even without the packet sniffer or access to source there are a variety of ways to flush out anticipatory information, ranging from tweaking the gamma and brightness on your screen to banish shadows to hacking your graphics card's device drivers to do transforms of the world model (such as making walls transparent).

We're back in familiar territory here; the history of computer security is littered with the metaphorical (and in some cases maybe literal) corpses of people who thought security through obscurity was sufficient. Crackers love that kind of naivete and prey on it ruthlessly.

The aim-bot cheat is trickier to prevent. The difference between human and aim-bot actions is measured only in milliseconds of timing. Changing the protocol to stop it from leaking information won't banish aim-bots; it would take the server doing statistical analysis of player action timings to even detect them, and (as Carmack points out) "that is an arms race that will end with skilled human players eventually getting identified as subtle bots."

Fortunately, the aim-bot cheat is also much less interesting from a general security point of view. It's hard to imagine anything but a twitch game in which the client user can cheat effectively by altering the millisecond-level timing of command packets. So the real lesson of both cheats may be that a closed-source program like Carmack's hypothetical secured program launcher is indeed a good idea for security -- but only if you're a hyperadrenalized space marine on a shooting spree.

(Any computer game at which computers are better than most humans has analogous cheats, some of which aren't even detectable in principle. Carmack observes "correspondence chess has been subverted from its original intent by players using computers." This isn't something security design can fix.)

If Quake had been designed to be open-source from the beginning, the performance hack that makes see-around-corners possible could never have been considered -- and either the design wouldn't have depended on millisecond packet timing at all, or aim-bot recognition would have been built in to the server from the beginning. This teaches our most important lesson -- that open source is the key to security because it changes the behavior of developers.

Open source keeps designers honest. By depriving them of the crutch of obscurity, it forces them towards using methods that are provably secure not only against known attacks but against all possible attacks by an intruder with full knowledge of the system and its source code. This is real security, the kind cryptographers and other professional paranoids respect.

It's the kind of security the Linux kernel and the Apache webserver have, and the kind people victimized by the Melissa and Chernobyl viruses and Back Orifice and the latest Microsoft-crack-of-the-week don't have. If you're betting your personal privacy or your business's critical functions on the integrity of software, it's the kind of security you want, too.

To recap, the real lessons of the Quake cheats are (a) never trust a client program to be honest, (b) you can't have real security if you trade it away to get performance, (c) real security comes not from obscurity but from minimum disclosure, and most importantly (d) only open source can force designers to use provably secure methods.

So, far from being a telling strike against open source, the case of the Quake cheats actually highlights the kinds of biases and subtle design errors that creep into software when it's designed for closed-source distribution and performance at the expense of security. These may be something we can live with in a shoot-em-up, but they're not tolerable in the running gears of the information economy. Avoiding them is, in fact, a good reason for software consumers to demand open source for anything more mission-critical than a Quake game.

Eric S. Raymond

Everyone at this point has heard and seen about VA Linux Systems succesful IPO. Lesser known is the fact that ESR ^[?] is on the Board of VA. Yesterday seems to have been a time of personal reflection on the his new situation. Click below to read ERSR's musings on sudden wealth.

A few hours ago, I learned that I am now (at least in theory) absurdly rich.

I was at my machine, hacking, when I got email congratulating me on the success of the VA Linux Systems IPO. I was working on my latest small project -- a compiler for a special-purpose language I've designed called Scriptable Network Graphics, or SNG. SNG is an editable representation of the chunk data in a PNG. What I'm writing is a compiler/decompiler pair, so you can dump PNGs in SNG, edit the SNG, then recompile to a PNG image.

"Congratulations? That's interesting," said I to myself. "I didn't think we were going out till tomorrow." And I oughtta know; I'm on VA's Board of Directors, recruited by Larry Augustin himself to be VA's official corporate conscience, and it's a matter of public record that I hold a substantial share in the company. I tooled on over to Linux Today, chased a link -- and discovered that Larry Augustin had taken the fast option we discussed during the last Board conference call. VA had indeed gone out on NASDAQ -- and I had become worth approximately forty-one million dollars while I wasn't looking.

Well, that didn't last long. In the next two hours, VA dropped from $274 a share to close at $239, leaving me with a stake of only thirty-six million dollars. Which is still a preposterously large amount of money.

You may wonder why I am talking about this in public. The first piece of advice your friends and family will give you, if it looks like you're about to become really wealthy, is: keep it quiet. It's nobody else's business -- you don't want to look like you're gloating, and you don't want to be deluged with an endless succession of charity appeals, business propositions, long-lost best friends, and plain bald-faced mooching.

Trouble with the "keep it quiet" theory is that I've made my bucks in a very public way. When you're already a media figure, and your name is on the S-1 of a hot IPO, and email from friends and journalists starts coming in like crazy as the stock breaks first-day-gainplaying it coy swiftly ceases to look like a viable option.

Besides, it wouldn't be fair to dissemble. I serve a community. I'm wealthy today because my efforts to spread the idea of open source on behalf of that community helped galvanize the business world, and earned the respect and the trust of a lot of hackers. Larry thought that respect was an asset worth shelling out 150,000 shares of VA for. Fairness to the hackers who made me bankable demands that I publicly acknowledge this result -- and publicly face the question of how it's going to affect my life and what I'll do with the money.

This is a question that a lot of us will be facing as open source sweeps the technology landscape. Money follows where value leads, and the mainstream business and finance world is seeing increasing value in our tribe of scruffy hackers. Red Hat and VA have created a precedent now, with their directed-shares programs designed to reward as many individual contributors as they can identify; future players aiming for community backing and a seat at the high table will have to follow suit. In this and other ways (including, for example, task markets) the wealth is going to be shared.

So while there aren't likely to be a lot more multimillion-dollar bonanzas like mine, lots of hackers are going to have to evolve answers to this question for smaller amounts that will nevertheless make a big difference to individuals; tens or hundreds of thousands of dollars, enough to change your life -- or wreck it.

(Gee. Remember when the big question was "How do we make money at this?")

The first part of my answer is "I'll do nothing, until next June". Because I'm a VA board member, under SEC regulations there's a six-month lockout on the shares (a regulation designed to keep people from floating bogus offerings, cashing out, and skipping to Argentina before the share price crashes). So it's not strictly true that I'm wealthy right now. I will be wealthy in six months, unless VA or the U.S. economy craters before then. I'll bet on VA; I'm not so sure about the U.S. economy :-).

Assuming the economy does not in fact crater, how is wealth going to affect my life in six months? Honestly, I think the answer is "not much". I haven't spent the last fifteen years doing the open-sourcefor the money. I'm already living pretty much exactly the way I want to, doing the work that matters to me. The biggest difference the money will make to me personally is that now I should be able to keep doing what I love for the rest of my life without worrying about money ever again.

So I expect I'll just keep on as I've been doing. Hacking code. Thinking and spreading subversive thoughts. Traveling and giving talks. Writing papers. Poking various evil empires a good one in the eye whenever I get a chance. Working for freedom.

I expect most other hackers confronted with sudden wealth will make similar choices. Reporters often ask me these days if I think the open-source community will be corrupted by the influx of big money. I tell them what I believe, which is this: commercial demand for programmers has been so intense for so long that anyone who can be seriously distracted by money is already gone. Our community has been self-selected for caring about other things -- accomplishment, pride, artistic passion, and each other.

OK, so maybe I'll break down and finally get a cell phone. And cable broadband so I can surf at smokin' speed. And a new flute. And maybe a nice hotrodded match-grade .45 semi for tactical shooting. But really, I don't want or need a lot of stuff. I'm kind of Buddhist that way; I like to minimize my material attachments. (My family gripes that this makes me hell to buy Christmas presents for.)

I'm not going to minimize my attachments by giving it all away, though, so you evangelists for a zillion worthy causes can just calm down out there and forget about hitting me up for megabucks. I am *not* going to be a soft touch, and will rudely refuse all importunities.

I'm not copping this harsh attitude to protect my money, but rather to protect the far more precious asset of my time. Because I don't want to have to become a full-time specialist in deciding whose urgent pitch to buy, I'm going to turn everybody down flat in advance. Anyone who bugs me for a handout, no matter how noble the cause and how much I agree with it, will go on my permanent shit list. If I want to give or lend or invest money, *I'll* call *you*. (Sigh...)And yes, there are causes I'll give money to. Worthy hacker projects. Free-speech activism. Firearms-rights campaigns. Tibet, maybe. I might buy a hunk of rainforest for conservation somewhere. Megabucks are power, and with power comes an obligation to use it wisely. I'll give carefully, and in my own time, and only after doing my homework -- too much charity often kills what it means to nurture. And enough about that.

Ironically enough, one result of my getting rich is that I will probably start charging for speaking appearances, now that nobody can plausibly accuse me of doing it for the money. I won't charge open-source user groups or schools, but I will cheerfully extract a per diem from all the business conferences that keep wanting me to to boost their box office. Charging a price for my time will separate the expensive conferences that attract powerful people from the marginal events where the hacker community would get less leverage from my presence.

For the same reason, I'm still going to insist that anybody who wants me to give a talk has to cover my expenses and eliminate hassles. But I also expect I'll still carry my own luggage. And I'll never get too proud to crash on somebody's daybed when the local user group is too broke to cover a hotel.

But enough trivialities; I'm going to get back to work. I've got the SNG compiler stage almost done. Next up, I need to refactor the pngcheck code so I can give it a report-format option that generates SNG syntax. Then, I need to think about supporting MNG...
--
Eric S. Raymond

C|Net recently made waves with its "Top 10 Hacks" story which seemed to say that Hack==Website Defacement. Derek Glidden found that wrong. And I'm glad he did because he's proposed that we do our own top 10 hacks. He's written a fabulous article, and challanges us to come up with a real list of hacks: The good stuff. Not the script kiddie stuff that the media likes to use to generate extreme headlines. Read this story. Its a good one.

A lot of people pointed out in Slashdot's recent coverage of an article run on C|Net called "The Top 10 Subversive Hacks of All Time" that 8 out of the 10 so-called "Hacks" listed were merely website defacements and not deserving of the "Hack" label at all. Here's your chance, as the Slashdot community, to set the record straight!

C|Net, perhaps in some kind of bizarre response to millenia fever, has lately been printing a few "Top 10 Lists" of sensational-sounding topics but rather lame content:

The Top 10 Technology Terrors - Billed as "10 products that will scare you to death" complete with a cute little Grim Fandango-esque skeleton as a mascot. Of course Back Orifice is on the list. Are you terrified yet?

Top Ten Terrors That Scare Web Builders - I'm not even sure where this article is supposed to be going. I know when I'm building a website I'm always "scared" of the Y2K problem as it relates to interfacing with my mainframe...

Ten Tricks for Digital Pranksters - Which I'd hoped might be at least slightly amusing, but turns out to be amusing in the same way that going to a K-Mart, finding the Commodore 64's on display, disabling BREAK and writing that BASIC program '10 PRINT "K-MART SUCKS "; 20 GOTO 10' was amusing when I was 12. (But then, it's not a "Top Ten" list, so I shouldn't complain.)

Given the trend, one wonders when their "Top 10 Pr0n Websites That Will Make Your Child Grow Up Into A Pervert If He or She So Much As Thinks About The URL", "Top 10 Most Violent Video Games Guaranteed To Make The Flesh Of Your Flesh And Blood Of Your Blood Turn Into A Deviant Sociopath Who Will Probably Shoot Up A McDonalds By The Time They're 25" or "Top 10 Really Annoying Top 10 Lists That We've Broken Up Into One Page Per Entry To Maximize Our Banner Ad Display" lists will show up.

Regardless of whether or not C|Net gets it in general, (I think I've made my opinion on that clear by now. :) they surely dropped the ball on their "Hacks" article. Rob and the gang at Slashdot liked my suggestion that the question be put to the Slashdot community and find out what you consider a "Great Hack."

So what is a "Hack"?

A lot of people reading that article were disappointed that C|Net decided to more or less define "Hack" as being equivalent to "website defacement", completely ignoring the traditional, more creative and useful meaning of the word. (Notice here how I deftly sidestep the whole 'hacker' vs. 'cracker' debate...) How should we determine what's a "Great Hack", much less the Top 10 of All Time, then?

Eric Raymond's Jargon File defines "Hack" in the first two meanings as:

"1. n. Originally, a quick job that produces what is needed, but not well. 2. n. An incredibly good, and perhaps very time-consuming, piece of work that produces exactly what is needed."

(Which are entirely contradictory, but hackers never let mundane things like paradoxes slow them down.) He further refines the meaning in Append ix A, "The Meaning of Hack" as:

"Hacking might be characterized as `an appropriate application of ingenuity'. Whether the result is a quick-and-dirty patchwork job or a carefully crafted work of art, you have to admire the cleverness that went into it."

If you'll notice, nothing in these definitions say anything about a "Hack" being computer-related. There have been many great Hacks that are not computer-related; it's just that people tend to associate the word "hack" with computers.

Adding to the ideas defined above, an "All-Time Great Hack" will probably also have:

• longevity - people should still be talking about it 20 or 30 years later, or even beyond.
• social and/or technological impact - it should change some aspect of life, either by directly changing every-day life or indirectly by changing how people view the world
• "eleganc e" - note however, that this does not necessarily equate simplicty. (Some people may consider the Saturn V booster a truly moby hack, as it got its job done precisely well with no doubt as to its purpose, but was anything but simple.)
• that not-easily definable quality of "I shoulda thought of that!" A Great Hack doesn't have to be "not immediately obvious" - it may just be something nobody else has done yet. For example: the WWW - there's nothing "unobvious" about defining a set of page layout macros that include text and graphics and a way to transmit and view them, but it didn't become commonplace until Tim Berners-Lee made it a big deal.

Some examples of things I would consider "Great Hacks" by these guidelines:

• Putting Apollo 11 on the moon - the NASA engineers at the time of the Apollo project are, to my mind, some of the greatest hackers in history. When you consider the state of technology at the time, what they accomplished is amazing.
• Ken Thompson's "cc hack" - No explanation necessary. A truly elegant hack that is already part of computer folklore.
• Both the "development" of AT&T UNIX into BSD UNIX and the way BSD was distributed, essentially creating the first widespread market demand for "open source software."
• Of course, no Slashdot feature article would be complete without mentioning: the development of the Linux Kernel, both for what it is and how it was/is developed.

But wait, there's more!!

In his Appendinx on "The Meaning Of Hack", ESR also says:

"An important secondary meaning of hack is `a creative practical joke'."

and MIT's Gallery of Hacks defines "hack" as:

"The word hack at MIT usually refers to a clever, benign, and "ethical" prank or practical joke, which is both challenging for the perpetrators and amusing to the MIT community (and sometimes even the rest of the world!)."

A sure point of dissent in this definition is going to be the "ethical" clause. I'll take the easy road out and leave this point to be decided by the audience - if enough people think a particular hack is a "Great Hack" regardless of ethics - then into the pot it goes.

On the other hand, the closest thing I can think of to a "Great Hack" that skirts ethical boundaries is the Robert Morris Worm. It's an event that will live in infamy in the lore of the Internet for all times for the problems it caused, but that it could accomplish what it did shows an incredible understanding of the way the systems worked and how they were interconnected at the time it happened.

It's still not entirely easy to think of "All-Time Great Hacks" that fit this definition, including the "ethical" clause:

• The canonical example is usually the MIT hack of the Harvard-Yale football game in which MIT students caused a six-foot weather baloon covered with the letters "MIT" to inflate at the 40 yard line during a pause in gameplay
• In the Slashdot article, "Uruk" pointed out that Orson Welles' broadcast of "The War Of The Worlds" in 1938 is arguably the best example of this definition of "Hack" that the world has ever known

So we have two definitions to deal with: The "Classic" Hacks, and the "MIT-Style" Hacks. It may or may not be worthwhile to separate these out into two distinct categories - I think we'll have to wait to see if there are enough unique entries in each category to require two lists.

What now?

In this feature, I would like you to list what you think are the "Greatest Hacks of All Time" and after a time to let enough people enter their suggestions and comments, I'll come back and gather up the most popular/frequent responses. Those suggestions will go up as a Slashdot poll, and the top ten from that poll will be officially listed in a subsequent feature article: "Slashdot's Top 10 Hacks of All Time" along with a bit of background on each one; rather like C|Net, except we'll put them all on one page for you.

There is only one restriction I would like to impose on suggestions: they have to be able to be documented somehow. I used to know a guy who could make his TRS-80 machines play music with software that somehow buzzed the floppy disk motor at different rates, which is a neat hack, but as I have no idea where he lives, if he still has a copy of his software, or even where to find a TRS-80 to play with anymore it's not a good candidate for this.

I've defined what it takes for a hack to be a "Great Hack", I've given some examples to help "seed the idea pool", and now it's your turn: what do you think should go on Slashdot's list of the Top 10 Hacks of All Time?

C|Net recently made waves with its "Top 10 Hacks" story which seemed to say that Hack==Website Defacement. Derek Glidden found that wrong. And I'm glad he did because he's proposed that we do our own top 10 hacks. He's written a fabulous article, and challanges us to come up with a real list of hacks: The good stuff. Not the script kiddie stuff that the media likes to use to generate extreme headlines. Read this story. Its a good one.

A lot of people pointed out in Slashdot's recent coverage of an article run on C|Net called "The Top 10 Subversive Hacks of All Time" that 8 out of the 10 so-called "Hacks" listed were merely website defacements and not deserving of the "Hack" label at all. Here's your chance, as the Slashdot community, to set the record straight!

C|Net, perhaps in some kind of bizarre response to millenia fever, has lately been printing a few "Top 10 Lists" of sensational-sounding topics but rather lame content:

The Top 10 Technology Terrors - Billed as "10 products that will scare you to death" complete with a cute little Grim Fandango-esque skeleton as a mascot. Of course Back Orifice is on the list. Are you terrified yet?

Top Ten Terrors That Scare Web Builders - I'm not even sure where this article is supposed to be going. I know when I'm building a website I'm always "scared" of the Y2K problem as it relates to interfacing with my mainframe...

Ten Tricks for Digital Pranksters - Which I'd hoped might be at least slightly amusing, but turns out to be amusing in the same way that going to a K-Mart, finding the Commodore 64's on display, disabling BREAK and writing that BASIC program '10 PRINT "K-MART SUCKS "; 20 GOTO 10' was amusing when I was 12. (But then, it's not a "Top Ten" list, so I shouldn't complain.)

Given the trend, one wonders when their "Top 10 Pr0n Websites That Will Make Your Child Grow Up Into A Pervert If He or She So Much As Thinks About The URL", "Top 10 Most Violent Video Games Guaranteed To Make The Flesh Of Your Flesh And Blood Of Your Blood Turn Into A Deviant Sociopath Who Will Probably Shoot Up A McDonalds By The Time They're 25" or "Top 10 Really Annoying Top 10 Lists That We've Broken Up Into One Page Per Entry To Maximize Our Banner Ad Display" lists will show up.

Regardless of whether or not C|Net gets it in general, (I think I've made my opinion on that clear by now. :) they surely dropped the ball on their "Hacks" article. Rob and the gang at Slashdot liked my suggestion that the question be put to the Slashdot community and find out what you consider a "Great Hack."

So what is a "Hack"?

A lot of people reading that article were disappointed that C|Net decided to more or less define "Hack" as being equivalent to "website defacement", completely ignoring the traditional, more creative and useful meaning of the word. (Notice here how I deftly sidestep the whole 'hacker' vs. 'cracker' debate...) How should we determine what's a "Great Hack", much less the Top 10 of All Time, then?

Eric Raymond's Jargon File defines "Hack" in the first two meanings as:

"1. n. Originally, a quick job that produces what is needed, but not well. 2. n. An incredibly good, and perhaps very time-consuming, piece of work that produces exactly what is needed."

(Which are entirely contradictory, but hackers never let mundane things like paradoxes slow them down.) He further refines the meaning in Append ix A, "The Meaning of Hack" as:

"Hacking might be characterized as `an appropriate application of ingenuity'. Whether the result is a quick-and-dirty patchwork job or a carefully crafted work of art, you have to admire the cleverness that went into it."

If you'll notice, nothing in these definitions say anything about a "Hack" being computer-related. There have been many great Hacks that are not computer-related; it's just that people tend to associate the word "hack" with computers.

Adding to the ideas defined above, an "All-Time Great Hack" will probably also have:

• longevity - people should still be talking about it 20 or 30 years later, or even beyond.
• social and/or technological impact - it should change some aspect of life, either by directly changing every-day life or indirectly by changing how people view the world
• "eleganc e" - note however, that this does not necessarily equate simplicty. (Some people may consider the Saturn V booster a truly moby hack, as it got its job done precisely well with no doubt as to its purpose, but was anything but simple.)
• that not-easily definable quality of "I shoulda thought of that!" A Great Hack doesn't have to be "not immediately obvious" - it may just be something nobody else has done yet. For example: the WWW - there's nothing "unobvious" about defining a set of page layout macros that include text and graphics and a way to transmit and view them, but it didn't become commonplace until Tim Berners-Lee made it a big deal.

Some examples of things I would consider "Great Hacks" by these guidelines:

• Putting Apollo 11 on the moon - the NASA engineers at the time of the Apollo project are, to my mind, some of the greatest hackers in history. When you consider the state of technology at the time, what they accomplished is amazing.
• Ken Thompson's "cc hack" - No explanation necessary. A truly elegant hack that is already part of computer folklore.
• Both the "development" of AT&T UNIX into BSD UNIX and the way BSD was distributed, essentially creating the first widespread market demand for "open source software."
• Of course, no Slashdot feature article would be complete without mentioning: the development of the Linux Kernel, both for what it is and how it was/is developed.

But wait, there's more!!

In his Appendinx on "The Meaning Of Hack", ESR also says:

"An important secondary meaning of hack is `a creative practical joke'."

and MIT's Gallery of Hacks defines "hack" as:

"The word hack at MIT usually refers to a clever, benign, and "ethical" prank or practical joke, which is both challenging for the perpetrators and amusing to the MIT community (and sometimes even the rest of the world!)."

A sure point of dissent in this definition is going to be the "ethical" clause. I'll take the easy road out and leave this point to be decided by the audience - if enough people think a particular hack is a "Great Hack" regardless of ethics - then into the pot it goes.

On the other hand, the closest thing I can think of to a "Great Hack" that skirts ethical boundaries is the Robert Morris Worm. It's an event that will live in infamy in the lore of the Internet for all times for the problems it caused, but that it could accomplish what it did shows an incredible understanding of the way the systems worked and how they were interconnected at the time it happened.

It's still not entirely easy to think of "All-Time Great Hacks" that fit this definition, including the "ethical" clause:

• The canonical example is usually the MIT hack of the Harvard-Yale football game in which MIT students caused a six-foot weather baloon covered with the letters "MIT" to inflate at the 40 yard line during a pause in gameplay
• In the Slashdot article, "Uruk" pointed out that Orson Welles' broadcast of "The War Of The Worlds" in 1938 is arguably the best example of this definition of "Hack" that the world has ever known

So we have two definitions to deal with: The "Classic" Hacks, and the "MIT-Style" Hacks. It may or may not be worthwhile to separate these out into two distinct categories - I think we'll have to wait to see if there are enough unique entries in each category to require two lists.

What now?

In this feature, I would like you to list what you think are the "Greatest Hacks of All Time" and after a time to let enough people enter their suggestions and comments, I'll come back and gather up the most popular/frequent responses. Those suggestions will go up as a Slashdot poll, and the top ten from that poll will be officially listed in a subsequent feature article: "Slashdot's Top 10 Hacks of All Time" along with a bit of background on each one; rather like C|Net, except we'll put them all on one page for you.

There is only one restriction I would like to impose on suggestions: they have to be able to be documented somehow. I used to know a guy who could make his TRS-80 machines play music with software that somehow buzzed the floppy disk motor at different rates, which is a neat hack, but as I have no idea where he lives, if he still has a copy of his software, or even where to find a TRS-80 to play with anymore it's not a good candidate for this.

I've defined what it takes for a hack to be a "Great Hack", I've given some examples to help "seed the idea pool", and now it's your turn: what do you think should go on Slashdot's list of the Top 10 Hacks of All Time?

C|Net recently made waves with its "Top 10 Hacks" story which seemed to say that Hack==Website Defacement. Derek Glidden found that wrong. And I'm glad he did because he's proposed that we do our own top 10 hacks. He's written a fabulous article, and challanges us to come up with a real list of hacks: The good stuff. Not the script kiddie stuff that the media likes to use to generate extreme headlines. Read this story. Its a good one.

A lot of people pointed out in Slashdot's recent coverage of an article run on C|Net called "The Top 10 Subversive Hacks of All Time" that 8 out of the 10 so-called "Hacks" listed were merely website defacements and not deserving of the "Hack" label at all. Here's your chance, as the Slashdot community, to set the record straight!

C|Net, perhaps in some kind of bizarre response to millenia fever, has lately been printing a few "Top 10 Lists" of sensational-sounding topics but rather lame content:

The Top 10 Technology Terrors - Billed as "10 products that will scare you to death" complete with a cute little Grim Fandango-esque skeleton as a mascot. Of course Back Orifice is on the list. Are you terrified yet?

Top Ten Terrors That Scare Web Builders - I'm not even sure where this article is supposed to be going. I know when I'm building a website I'm always "scared" of the Y2K problem as it relates to interfacing with my mainframe...

Ten Tricks for Digital Pranksters - Which I'd hoped might be at least slightly amusing, but turns out to be amusing in the same way that going to a K-Mart, finding the Commodore 64's on display, disabling BREAK and writing that BASIC program '10 PRINT "K-MART SUCKS "; 20 GOTO 10' was amusing when I was 12. (But then, it's not a "Top Ten" list, so I shouldn't complain.)

Given the trend, one wonders when their "Top 10 Pr0n Websites That Will Make Your Child Grow Up Into A Pervert If He or She So Much As Thinks About The URL", "Top 10 Most Violent Video Games Guaranteed To Make The Flesh Of Your Flesh And Blood Of Your Blood Turn Into A Deviant Sociopath Who Will Probably Shoot Up A McDonalds By The Time They're 25" or "Top 10 Really Annoying Top 10 Lists That We've Broken Up Into One Page Per Entry To Maximize Our Banner Ad Display" lists will show up.

Regardless of whether or not C|Net gets it in general, (I think I've made my opinion on that clear by now. :) they surely dropped the ball on their "Hacks" article. Rob and the gang at Slashdot liked my suggestion that the question be put to the Slashdot community and find out what you consider a "Great Hack."

So what is a "Hack"?

A lot of people reading that article were disappointed that C|Net decided to more or less define "Hack" as being equivalent to "website defacement", completely ignoring the traditional, more creative and useful meaning of the word. (Notice here how I deftly sidestep the whole 'hacker' vs. 'cracker' debate...) How should we determine what's a "Great Hack", much less the Top 10 of All Time, then?

Eric Raymond's Jargon File defines "Hack" in the first two meanings as:

"1. n. Originally, a quick job that produces what is needed, but not well. 2. n. An incredibly good, and perhaps very time-consuming, piece of work that produces exactly what is needed."

(Which are entirely contradictory, but hackers never let mundane things like paradoxes slow them down.) He further refines the meaning in Append ix A, "The Meaning of Hack" as:

"Hacking might be characterized as `an appropriate application of ingenuity'. Whether the result is a quick-and-dirty patchwork job or a carefully crafted work of art, you have to admire the cleverness that went into it."

If you'll notice, nothing in these definitions say anything about a "Hack" being computer-related. There have been many great Hacks that are not computer-related; it's just that people tend to associate the word "hack" with computers.

Adding to the ideas defined above, an "All-Time Great Hack" will probably also have:

• longevity - people should still be talking about it 20 or 30 years later, or even beyond.
• social and/or technological impact - it should change some aspect of life, either by directly changing every-day life or indirectly by changing how people view the world
• "eleganc e" - note however, that this does not necessarily equate simplicty. (Some people may consider the Saturn V booster a truly moby hack, as it got its job done precisely well with no doubt as to its purpose, but was anything but simple.)
• that not-easily definable quality of "I shoulda thought of that!" A Great Hack doesn't have to be "not immediately obvious" - it may just be something nobody else has done yet. For example: the WWW - there's nothing "unobvious" about defining a set of page layout macros that include text and graphics and a way to transmit and view them, but it didn't become commonplace until Tim Berners-Lee made it a big deal.

Some examples of things I would consider "Great Hacks" by these guidelines:

• Putting Apollo 11 on the moon - the NASA engineers at the time of the Apollo project are, to my mind, some of the greatest hackers in history. When you consider the state of technology at the time, what they accomplished is amazing.
• Ken Thompson's "cc hack" - No explanation necessary. A truly elegant hack that is already part of computer folklore.
• Both the "development" of AT&T UNIX into BSD UNIX and the way BSD was distributed, essentially creating the first widespread market demand for "open source software."
• Of course, no Slashdot feature article would be complete without mentioning: the development of the Linux Kernel, both for what it is and how it was/is developed.

But wait, there's more!!

In his Appendinx on "The Meaning Of Hack", ESR also says:

"An important secondary meaning of hack is `a creative practical joke'."

and MIT's Gallery of Hacks defines "hack" as:

"The word hack at MIT usually refers to a clever, benign, and "ethical" prank or practical joke, which is both challenging for the perpetrators and amusing to the MIT community (and sometimes even the rest of the world!)."

A sure point of dissent in this definition is going to be the "ethical" clause. I'll take the easy road out and leave this point to be decided by the audience - if enough people think a particular hack is a "Great Hack" regardless of ethics - then into the pot it goes.

On the other hand, the closest thing I can think of to a "Great Hack" that skirts ethical boundaries is the Robert Morris Worm. It's an event that will live in infamy in the lore of the Internet for all times for the problems it caused, but that it could accomplish what it did shows an incredible understanding of the way the systems worked and how they were interconnected at the time it happened.

It's still not entirely easy to think of "All-Time Great Hacks" that fit this definition, including the "ethical" clause:

• The canonical example is usually the MIT hack of the Harvard-Yale football game in which MIT students caused a six-foot weather baloon covered with the letters "MIT" to inflate at the 40 yard line during a pause in gameplay
• In the Slashdot article, "Uruk" pointed out that Orson Welles' broadcast of "The War Of The Worlds" in 1938 is arguably the best example of this definition of "Hack" that the world has ever known

So we have two definitions to deal with: The "Classic" Hacks, and the "MIT-Style" Hacks. It may or may not be worthwhile to separate these out into two distinct categories - I think we'll have to wait to see if there are enough unique entries in each category to require two lists.

What now?

In this feature, I would like you to list what you think are the "Greatest Hacks of All Time" and after a time to let enough people enter their suggestions and comments, I'll come back and gather up the most popular/frequent responses. Those suggestions will go up as a Slashdot poll, and the top ten from that poll will be officially listed in a subsequent feature article: "Slashdot's Top 10 Hacks of All Time" along with a bit of background on each one; rather like C|Net, except we'll put them all on one page for you.

There is only one restriction I would like to impose on suggestions: they have to be able to be documented somehow. I used to know a guy who could make his TRS-80 machines play music with software that somehow buzzed the floppy disk motor at different rates, which is a neat hack, but as I have no idea where he lives, if he still has a copy of his software, or even where to find a TRS-80 to play with anymore it's not a good candidate for this.

I've defined what it takes for a hack to be a "Great Hack", I've given some examples to help "seed the idea pool", and now it's your turn: what do you think should go on Slashdot's list of the Top 10 Hacks of All Time?

C|Net recently made waves with its "Top 10 Hacks" story which seemed to say that Hack==Website Defacement. Derek Glidden found that wrong. And I'm glad he did because he's proposed that we do our own top 10 hacks. He's written a fabulous article, and challanges us to come up with a real list of hacks: The good stuff. Not the script kiddie stuff that the media likes to use to generate extreme headlines. Read this story. Its a good one.

A lot of people pointed out in Slashdot's recent coverage of an article run on C|Net called "The Top 10 Subversive Hacks of All Time" that 8 out of the 10 so-called "Hacks" listed were merely website defacements and not deserving of the "Hack" label at all. Here's your chance, as the Slashdot community, to set the record straight!

C|Net, perhaps in some kind of bizarre response to millenia fever, has lately been printing a few "Top 10 Lists" of sensational-sounding topics but rather lame content:

The Top 10 Technology Terrors - Billed as "10 products that will scare you to death" complete with a cute little Grim Fandango-esque skeleton as a mascot. Of course Back Orifice is on the list. Are you terrified yet?

Top Ten Terrors That Scare Web Builders - I'm not even sure where this article is supposed to be going. I know when I'm building a website I'm always "scared" of the Y2K problem as it relates to interfacing with my mainframe...

Ten Tricks for Digital Pranksters - Which I'd hoped might be at least slightly amusing, but turns out to be amusing in the same way that going to a K-Mart, finding the Commodore 64's on display, disabling BREAK and writing that BASIC program '10 PRINT "K-MART SUCKS "; 20 GOTO 10' was amusing when I was 12. (But then, it's not a "Top Ten" list, so I shouldn't complain.)

Given the trend, one wonders when their "Top 10 Pr0n Websites That Will Make Your Child Grow Up Into A Pervert If He or She So Much As Thinks About The URL", "Top 10 Most Violent Video Games Guaranteed To Make The Flesh Of Your Flesh And Blood Of Your Blood Turn Into A Deviant Sociopath Who Will Probably Shoot Up A McDonalds By The Time They're 25" or "Top 10 Really Annoying Top 10 Lists That We've Broken Up Into One Page Per Entry To Maximize Our Banner Ad Display" lists will show up.

Regardless of whether or not C|Net gets it in general, (I think I've made my opinion on that clear by now. :) they surely dropped the ball on their "Hacks" article. Rob and the gang at Slashdot liked my suggestion that the question be put to the Slashdot community and find out what you consider a "Great Hack."

So what is a "Hack"?

A lot of people reading that article were disappointed that C|Net decided to more or less define "Hack" as being equivalent to "website defacement", completely ignoring the traditional, more creative and useful meaning of the word. (Notice here how I deftly sidestep the whole 'hacker' vs. 'cracker' debate...) How should we determine what's a "Great Hack", much less the Top 10 of All Time, then?

Eric Raymond's Jargon File defines "Hack" in the first two meanings as:

"1. n. Originally, a quick job that produces what is needed, but not well. 2. n. An incredibly good, and perhaps very time-consuming, piece of work that produces exactly what is needed."

(Which are entirely contradictory, but hackers never let mundane things like paradoxes slow them down.) He further refines the meaning in Append ix A, "The Meaning of Hack" as:

"Hacking might be characterized as `an appropriate application of ingenuity'. Whether the result is a quick-and-dirty patchwork job or a carefully crafted work of art, you have to admire the cleverness that went into it."

If you'll notice, nothing in these definitions say anything about a "Hack" being computer-related. There have been many great Hacks that are not computer-related; it's just that people tend to associate the word "hack" with computers.

Adding to the ideas defined above, an "All-Time Great Hack" will probably also have:

• longevity - people should still be talking about it 20 or 30 years later, or even beyond.
• social and/or technological impact - it should change some aspect of life, either by directly changing every-day life or indirectly by changing how people view the world
• "eleganc e" - note however, that this does not necessarily equate simplicty. (Some people may consider the Saturn V booster a truly moby hack, as it got its job done precisely well with no doubt as to its purpose, but was anything but simple.)
• that not-easily definable quality of "I shoulda thought of that!" A Great Hack doesn't have to be "not immediately obvious" - it may just be something nobody else has done yet. For example: the WWW - there's nothing "unobvious" about defining a set of page layout macros that include text and graphics and a way to transmit and view them, but it didn't become commonplace until Tim Berners-Lee made it a big deal.

Some examples of things I would consider "Great Hacks" by these guidelines:

• Putting Apollo 11 on the moon - the NASA engineers at the time of the Apollo project are, to my mind, some of the greatest hackers in history. When you consider the state of technology at the time, what they accomplished is amazing.
• Ken Thompson's "cc hack" - No explanation necessary. A truly elegant hack that is already part of computer folklore.
• Both the "development" of AT&T UNIX into BSD UNIX and the way BSD was distributed, essentially creating the first widespread market demand for "open source software."
• Of course, no Slashdot feature article would be complete without mentioning: the development of the Linux Kernel, both for what it is and how it was/is developed.

But wait, there's more!!

In his Appendinx on "The Meaning Of Hack", ESR also says:

"An important secondary meaning of hack is `a creative practical joke'."

and MIT's Gallery of Hacks defines "hack" as:

"The word hack at MIT usually refers to a clever, benign, and "ethical" prank or practical joke, which is both challenging for the perpetrators and amusing to the MIT community (and sometimes even the rest of the world!)."

A sure point of dissent in this definition is going to be the "ethical" clause. I'll take the easy road out and leave this point to be decided by the audience - if enough people think a particular hack is a "Great Hack" regardless of ethics - then into the pot it goes.

On the other hand, the closest thing I can think of to a "Great Hack" that skirts ethical boundaries is the Robert Morris Worm. It's an event that will live in infamy in the lore of the Internet for all times for the problems it caused, but that it could accomplish what it did shows an incredible understanding of the way the systems worked and how they were interconnected at the time it happened.

It's still not entirely easy to think of "All-Time Great Hacks" that fit this definition, including the "ethical" clause:

• The canonical example is usually the MIT hack of the Harvard-Yale football game in which MIT students caused a six-foot weather baloon covered with the letters "MIT" to inflate at the 40 yard line during a pause in gameplay
• In the Slashdot article, "Uruk" pointed out that Orson Welles' broadcast of "The War Of The Worlds" in 1938 is arguably the best example of this definition of "Hack" that the world has ever known

So we have two definitions to deal with: The "Classic" Hacks, and the "MIT-Style" Hacks. It may or may not be worthwhile to separate these out into two distinct categories - I think we'll have to wait to see if there are enough unique entries in each category to require two lists.

What now?

In this feature, I would like you to list what you think are the "Greatest Hacks of All Time" and after a time to let enough people enter their suggestions and comments, I'll come back and gather up the most popular/frequent responses. Those suggestions will go up as a Slashdot poll, and the top ten from that poll will be officially listed in a subsequent feature article: "Slashdot's Top 10 Hacks of All Time" along with a bit of background on each one; rather like C|Net, except we'll put them all on one page for you.

There is only one restriction I would like to impose on suggestions: they have to be able to be documented somehow. I used to know a guy who could make his TRS-80 machines play music with software that somehow buzzed the floppy disk motor at different rates, which is a neat hack, but as I have no idea where he lives, if he still has a copy of his software, or even where to find a TRS-80 to play with anymore it's not a good candidate for this.

I've defined what it takes for a hack to be a "Great Hack", I've given some examples to help "seed the idea pool", and now it's your turn: what do you think should go on Slashdot's list of the Top 10 Hacks of All Time?

C|Net recently made waves with its "Top 10 Hacks" story which seemed to say that Hack==Website Defacement. Derek Glidden found that wrong. And I'm glad he did because he's proposed that we do our own top 10 hacks. He's written a fabulous article, and challanges us to come up with a real list of hacks: The good stuff. Not the script kiddie stuff that the media likes to use to generate extreme headlines. Read this story. Its a good one.

A lot of people pointed out in Slashdot's recent coverage of an article run on C|Net called "The Top 10 Subversive Hacks of All Time" that 8 out of the 10 so-called "Hacks" listed were merely website defacements and not deserving of the "Hack" label at all. Here's your chance, as the Slashdot community, to set the record straight!

C|Net, perhaps in some kind of bizarre response to millenia fever, has lately been printing a few "Top 10 Lists" of sensational-sounding topics but rather lame content:

The Top 10 Technology Terrors - Billed as "10 products that will scare you to death" complete with a cute little Grim Fandango-esque skeleton as a mascot. Of course Back Orifice is on the list. Are you terrified yet?

Top Ten Terrors That Scare Web Builders - I'm not even sure where this article is supposed to be going. I know when I'm building a website I'm always "scared" of the Y2K problem as it relates to interfacing with my mainframe...

Ten Tricks for Digital Pranksters - Which I'd hoped might be at least slightly amusing, but turns out to be amusing in the same way that going to a K-Mart, finding the Commodore 64's on display, disabling BREAK and writing that BASIC program '10 PRINT "K-MART SUCKS "; 20 GOTO 10' was amusing when I was 12. (But then, it's not a "Top Ten" list, so I shouldn't complain.)

Given the trend, one wonders when their "Top 10 Pr0n Websites That Will Make Your Child Grow Up Into A Pervert If He or She So Much As Thinks About The URL", "Top 10 Most Violent Video Games Guaranteed To Make The Flesh Of Your Flesh And Blood Of Your Blood Turn Into A Deviant Sociopath Who Will Probably Shoot Up A McDonalds By The Time They're 25" or "Top 10 Really Annoying Top 10 Lists That We've Broken Up Into One Page Per Entry To Maximize Our Banner Ad Display" lists will show up.

Regardless of whether or not C|Net gets it in general, (I think I've made my opinion on that clear by now. :) they surely dropped the ball on their "Hacks" article. Rob and the gang at Slashdot liked my suggestion that the question be put to the Slashdot community and find out what you consider a "Great Hack."

So what is a "Hack"?

A lot of people reading that article were disappointed that C|Net decided to more or less define "Hack" as being equivalent to "website defacement", completely ignoring the traditional, more creative and useful meaning of the word. (Notice here how I deftly sidestep the whole 'hacker' vs. 'cracker' debate...) How should we determine what's a "Great Hack", much less the Top 10 of All Time, then?

Eric Raymond's Jargon File defines "Hack" in the first two meanings as:

"1. n. Originally, a quick job that produces what is needed, but not well. 2. n. An incredibly good, and perhaps very time-consuming, piece of work that produces exactly what is needed."

(Which are entirely contradictory, but hackers never let mundane things like paradoxes slow them down.) He further refines the meaning in Append ix A, "The Meaning of Hack" as:

"Hacking might be characterized as `an appropriate application of ingenuity'. Whether the result is a quick-and-dirty patchwork job or a carefully crafted work of art, you have to admire the cleverness that went into it."

If you'll notice, nothing in these definitions say anything about a "Hack" being computer-related. There have been many great Hacks that are not computer-related; it's just that people tend to associate the word "hack" with computers.

Adding to the ideas defined above, an "All-Time Great Hack" will probably also have:

• longevity - people should still be talking about it 20 or 30 years later, or even beyond.
• social and/or technological impact - it should change some aspect of life, either by directly changing every-day life or indirectly by changing how people view the world
• "eleganc e" - note however, that this does not necessarily equate simplicty. (Some people may consider the Saturn V booster a truly moby hack, as it got its job done precisely well with no doubt as to its purpose, but was anything but simple.)
• that not-easily definable quality of "I shoulda thought of that!" A Great Hack doesn't have to be "not immediately obvious" - it may just be something nobody else has done yet. For example: the WWW - there's nothing "unobvious" about defining a set of page layout macros that include text and graphics and a way to transmit and view them, but it didn't become commonplace until Tim Berners-Lee made it a big deal.

Some examples of things I would consider "Great Hacks" by these guidelines:

• Putting Apollo 11 on the moon - the NASA engineers at the time of the Apollo project are, to my mind, some of the greatest hackers in history. When you consider the state of technology at the time, what they accomplished is amazing.
• Ken Thompson's "cc hack" - No explanation necessary. A truly elegant hack that is already part of computer folklore.
• Both the "development" of AT&T UNIX into BSD UNIX and the way BSD was distributed, essentially creating the first widespread market demand for "open source software."
• Of course, no Slashdot feature article would be complete without mentioning: the development of the Linux Kernel, both for what it is and how it was/is developed.

But wait, there's more!!

In his Appendinx on "The Meaning Of Hack", ESR also says:

"An important secondary meaning of hack is `a creative practical joke'."

and MIT's Gallery of Hacks defines "hack" as:

"The word hack at MIT usually refers to a clever, benign, and "ethical" prank or practical joke, which is both challenging for the perpetrators and amusing to the MIT community (and sometimes even the rest of the world!)."

A sure point of dissent in this definition is going to be the "ethical" clause. I'll take the easy road out and leave this point to be decided by the audience - if enough people think a particular hack is a "Great Hack" regardless of ethics - then into the pot it goes.

On the other hand, the closest thing I can think of to a "Great Hack" that skirts ethical boundaries is the Robert Morris Worm. It's an event that will live in infamy in the lore of the Internet for all times for the problems it caused, but that it could accomplish what it did shows an incredible understanding of the way the systems worked and how they were interconnected at the time it happened.

It's still not entirely easy to think of "All-Time Great Hacks" that fit this definition, including the "ethical" clause:

• The canonical example is usually the MIT hack of the Harvard-Yale football game in which MIT students caused a six-foot weather baloon covered with the letters "MIT" to inflate at the 40 yard line during a pause in gameplay
• In the Slashdot article, "Uruk" pointed out that Orson Welles' broadcast of "The War Of The Worlds" in 1938 is arguably the best example of this definition of "Hack" that the world has ever known

So we have two definitions to deal with: The "Classic" Hacks, and the "MIT-Style" Hacks. It may or may not be worthwhile to separate these out into two distinct categories - I think we'll have to wait to see if there are enough unique entries in each category to require two lists.

What now?

In this feature, I would like you to list what you think are the "Greatest Hacks of All Time" and after a time to let enough people enter their suggestions and comments, I'll come back and gather up the most popular/frequent responses. Those suggestions will go up as a Slashdot poll, and the top ten from that poll will be officially listed in a subsequent feature article: "Slashdot's Top 10 Hacks of All Time" along with a bit of background on each one; rather like C|Net, except we'll put them all on one page for you.

There is only one restriction I would like to impose on suggestions: they have to be able to be documented somehow. I used to know a guy who could make his TRS-80 machines play music with software that somehow buzzed the floppy disk motor at different rates, which is a neat hack, but as I have no idea where he lives, if he still has a copy of his software, or even where to find a TRS-80 to play with anymore it's not a good candidate for this.

I've defined what it takes for a hack to be a "Great Hack", I've given some examples to help "seed the idea pool", and now it's your turn: what do you think should go on Slashdot's list of the Top 10 Hacks of All Time?