Slashdot Mirror

stevedcc writes "This weekend sees the release of The Hunt for Gollum, a Lord of the Rings fan-film. It'll be available on the web for free. The BBC are running an article about the making of the film, with a budget of £3,000 (spent mostly on costumes and make-up). There were 160 contributors involved, many over the internet." I hope it lives up to the trailer (linked from the BBC story); the finished film is approximately 40 minutes. memoryhole supplies links to YouTube for both the full trailer and a second trailer. Reader jowifi adds a link to NPR's story on the film, writing, "NPR discussed the legality of this type of creation with EFF lawyer Fred Von Lohman, who said it's not clear if such a production violates the copyright for Tolkien's work."

Ashmash writes "Benchmarks of the Btrfs filesystem have been published by Phoronix that compare it to the XFS, EXT3, and EXT4 file-systems. In the end they conclude that this next-generation Linux filesystem is not yet the performance king. In a great number of the tests, the EXT4 filesystem that was designed to be an interim step to Btrfs actually performs much better than the unstable Btrfs, albeit Btrfs still has more advanced features. Fedora 11 even took longer to boot when using Btrfs than EXT3 or EXT4."

krou writes "The Wrap has an interesting interview with Eric Schmidt on Google's new plan for news. Google is apparently planning on rolling out 'high-quality news' to users who are not actively searching for news. It's expected to launch in approximately six months' time, and the first two news organizations to be involved will be The New York Times and The Washington Post. 'Under this latest iteration of advanced search, users will be automatically served the kind of news that interests them just by calling up Google's page. The latest algorithms apply ever more sophisticated filtering — based on search words, user choices, purchases, a whole host of cues — to determine what the reader is looking for without knowing they're looking for it. And on this basis, Google believes it will be able to sell premium ads against premium content.' Although Schmidt said that companies like the New York Times won't get any of this ad revenue, he commented that it will push stories to users who want them, drive up traffic to those stories, and in turn bring higher advertising rates for those stories." As VentureBeat points out, Google hasn't officially confirmed any of this, and with no ad revenue going to the other companies, it only partially addresses complaints that Google is profiting unfairly from the work of news publications.

Hugh Pickens writes "European antitrust regulators, who have been aggressively pursuing what they see as anticompetitive practices among technology companies, could impose their largest fine ever in a market-dominance case against Intel. The commission began investigating Intel in 2000 after Advanced Micro Devices, its arch-rival, filed a complaint. In two sets of charges, in 2007 and 2008, the commission accused Intel of abusing its dominant position in chips by giving large rebates to computer makers, by paying computer makers to delay or cancel product lines, and by offering chips for server computers at prices below actual cost. Some legal experts speculate that Intel's fine could reach about a billion euros, or $1.3B. 'I'd be surprised if the fine isn't as high or higher than in the Microsoft case,' said an antitrust and competition lawyer in London. In 2004 Microsoft paid a fine of €497M, or $663M at current exchange rates, after being accused of abusing its dominance; the EU imposed another $1.3B fine in Feb. 2008."

edadams sends in a story about the legal questions that are starting to crop up over property disputes in virtual worlds. A lawsuit in March 2008 that stopped one Second Life user from selling a virtual product created by another user marked the beginning of a significant amount of casework for several law firms, in large part due to the way Second Life's currency interacts closely with real money. (And yes, apparently the product in that particular case was for cybersex — did you have to ask?) "As transactions grow in volume, it's inevitable that disagreements will crop up. Linden says that although it will enforce its terms of service, including its ban on violating other users' intellectual property, it can't settle most disputes for users." A lawyer for one intellectual property firm handled a case in which the co-ownership of virtual real estate had to be determined, ending with a financial settlement given to two users who helped a virtual land developer run a group of Second Life islands. As virtual worlds get more popular and their business models more directly affect real-life finances, we can expect these legal issues to become more common as well.

edadams sends in a story about the legal questions that are starting to crop up over property disputes in virtual worlds. A lawsuit in March 2008 that stopped one Second Life user from selling a virtual product created by another user marked the beginning of a significant amount of casework for several law firms, in large part due to the way Second Life's currency interacts closely with real money. (And yes, apparently the product in that particular case was for cybersex — did you have to ask?) "As transactions grow in volume, it's inevitable that disagreements will crop up. Linden says that although it will enforce its terms of service, including its ban on violating other users' intellectual property, it can't settle most disputes for users." A lawyer for one intellectual property firm handled a case in which the co-ownership of virtual real estate had to be determined, ending with a financial settlement given to two users who helped a virtual land developer run a group of Second Life islands. As virtual worlds get more popular and their business models more directly affect real-life finances, we can expect these legal issues to become more common as well.

CurtMonash writes "Web analytics databases are getting even larger. eBay now has a 6 1/2 petabyte warehouse running on Greenplum — user data — to go with its more established 2 1/2 petabyte Teradata system. Between the two databases, the metrics are enormous — 17 trillion rows, 150 billion new rows per day, millions of queries per day, and so on. Meanwhile, Facebook has 2 1/2 petabytes managed by Hadoop, not running on a conventional DBMS at all, Yahoo has over a petabyte (on a homegrown system), and Fox/MySpace has two different multi-hundred terabyte systems (Greenplum and Aster Data nCluster). eBay and Fox are the two Greenplum customers I wrote in about last August, when they both seemed to be headed to the petabyte range in a hurry. These are basically all web log/clickstream databases, except that network event data is even more voluminous than the pure clickstream stuff."

Time Doctor writes "The de-facto standard in Quake 3 engine technology, ioquake3, has hit version 1.36 recently. It includes a garbage bag full of improvements: in-game VOIP; optional external Mumble (voip); OpenAL; IPV6; anaglyph stereo rendering; Full x86-64 architecture support; Rewritten PowerPC JIT compiler, with ppc64 support; new SPARC JIT compiler, with support for both sparc32 and sparc64; improved console command auto-completion; persistent console command history; improved QVM (Quake Virtual Machine) tools; colored terminal output on POSIX operating systems; multiuser support on Windows systems (user-specific game data is stored in their respective Application Data folders); PNG format support for textures. Of course, there are even more fixes for security holes and other bugs in there. So, if you don't like ads and queues in your Quake 3 experience, get a copy of Quake 3 off Steam and copy your data files and key into your ioquake3 directory."

g2 in the desert writes "I live in a small rural community in the US Southwest, where broadband service varies from decent but very expensive, to lousy but less expensive. Now that the Federal Communications Commission has approved the use of the soon to be vacated White-Space Spectrum, I'm interested in helping the community build its own local Internet service, providing villagers another choice. Does anyone know what companies will be manufacturing hardware that will be required to utilize this spectrum, and what steps need to be taken in order to be in compliance with any FCC rules and regulations?"

r3lody writes "Styling Web Pages with CSS: Visual QuickProject Guide, by Tom Negrino and Dori Smith, helps the beginning web designer learn how to use CSS in a simple, easy-to-follow format. This being my first exposure to one of the Visual QuickProject Guides by Peachpit Press, I was both pleased and disappointed when I received this slim volume. I was pleased in the presentation and clear descriptions given to each aspect of Cascading Style Sheets (CSS). I was disappointed in the brevity of the text, and the lack of downloadable materials to use to follow the examples in the book." Read below for the rest of Ray's review. Styling Web Pages with CSS: Visual QuickProject Guide author Tom Negrino and Dori Smith pages 144 publisher Peachpit Press rating 7/10 reviewer Ray Lodato ISBN 0321555570 summary A beginner's guide to the proper use of CSS Each chapter starts with a brief explanation of its subject, followed by the major topics introduced via large, colorful titles. Finally, any "Extra Bits" provide follow-up explanations or point to where you can get further information.

Before any CSS is discussed, there is a general introduction including how the book is structured, the sample web site to be created, and what tools will be useful to create the site. For the tools, the authors recommend at least a text editor (not a word processor) and your favorite browser. BBEdit and TextWrangler are suggested for Mac owners, while Notepad is okay for Windows. I personally use Notepad++, which has styling cues for both HTML and CSS (as well as many others), so I would recommend it for Windows users. To insure compatibility with the browser, Tom and Dori say you should have Internet Explorer, Firefox, and Safari. Strangely, Opera is barely mentioned in the book. I tested the examples using the first two. Finally, a true CSS editor might be useful, as it will provide you with your options. They suggested MacRabbit's CSSEdit for Mac users, or WesternCIV's Style Master for either Macs or Windows. I used Style Master 4.6 for Windows during testing.

After the introductory chapter, CSS is explained starting with a chapter on the basics, with simple guidelines for their use. Classes (which can be used many times) are contrasted with ids (which can be used only once per HTML file), and the benefits of using external style sheets versus internal styles is explained.

The next three chapters build upon each other to provide gentle instruction on how to layout and style the text and images. Formatting menus, tables and headings are tackled next, followed by a chapter devoted to browser differences. Finally, alternative menu and page formatting and CSS debugging is discussed.

All of the major concepts of CSS are presented so that a beginner can easily understand them. While some ways of utilizing CSS properly can be the subject of debate, the authors have chosen a rational approach that serves the basic web designer well. The result is a set of web pages that follow a simply understood design, yet ensures that the layout and format is isolated to the CSS style document, rather than the HTML.

Over and over, Tom and Dori provide useful links to web sites with additional information on the intricacies of CSS, as well as providing suggestions for programs to help you with massaging images and references to other books for more in-depth coverage.

The best way to fully understand what Tom and Dori are trying to explain is to replicate the example web site (Alpaca Repo). Unfortunately, there is no link in the book or on PeachPit's web site to a set of downloadable images and html files. The only way I was able to replicate most (but not all) of the examples was to look at alpacarepo.com. It has six pages, two style sheets, and two photos. The book shows other photos and more complete pages, so it's a partial solution at best.

Overall, Styling Web Pages with CSS: Visual QuickProject Guide is a nice introduction to the potentially confusing topic of the proper use of CSS. Many of the fancier techniques are avoided for the more common and useful ones. The short length of the book allows the beginner to avoid the feeling of intimidation that can accompany reading a 1,000 page text that covers everything you never wanted to know. Even so, I felt less than satisfied after I finished. I wanted a little bit more than I was given. Even if the book doubled in size, it would still be accessible yet it could then leave the reader with a feeling of contentment. As this is the first QuickProject book I've read, that may simply be the target they were shooting for.

One final wish for Peachpit: please include downloadable files that the reader can access to duplicate the Alpaca Repo website. I was continually frustrated when I wanted to replicate what I had just read about, yet was missing JPEG files or extensive text that I could use. Consequently, I never felt as though I had actually gotten the hang of CSS.

You can purchase Styling Web Pages with CSS: Visual QuickProject Guide from amazon.com. Slashdot welcomes readers' book reviews — to see your own review here, read the book review guidelines, then visit the submission page.

r3lody writes "Styling Web Pages with CSS: Visual QuickProject Guide, by Tom Negrino and Dori Smith, helps the beginning web designer learn how to use CSS in a simple, easy-to-follow format. This being my first exposure to one of the Visual QuickProject Guides by Peachpit Press, I was both pleased and disappointed when I received this slim volume. I was pleased in the presentation and clear descriptions given to each aspect of Cascading Style Sheets (CSS). I was disappointed in the brevity of the text, and the lack of downloadable materials to use to follow the examples in the book." Read below for the rest of Ray's review. Styling Web Pages with CSS: Visual QuickProject Guide author Tom Negrino and Dori Smith pages 144 publisher Peachpit Press rating 7/10 reviewer Ray Lodato ISBN 0321555570 summary A beginner's guide to the proper use of CSS Each chapter starts with a brief explanation of its subject, followed by the major topics introduced via large, colorful titles. Finally, any "Extra Bits" provide follow-up explanations or point to where you can get further information.

Before any CSS is discussed, there is a general introduction including how the book is structured, the sample web site to be created, and what tools will be useful to create the site. For the tools, the authors recommend at least a text editor (not a word processor) and your favorite browser. BBEdit and TextWrangler are suggested for Mac owners, while Notepad is okay for Windows. I personally use Notepad++, which has styling cues for both HTML and CSS (as well as many others), so I would recommend it for Windows users. To insure compatibility with the browser, Tom and Dori say you should have Internet Explorer, Firefox, and Safari. Strangely, Opera is barely mentioned in the book. I tested the examples using the first two. Finally, a true CSS editor might be useful, as it will provide you with your options. They suggested MacRabbit's CSSEdit for Mac users, or WesternCIV's Style Master for either Macs or Windows. I used Style Master 4.6 for Windows during testing.

After the introductory chapter, CSS is explained starting with a chapter on the basics, with simple guidelines for their use. Classes (which can be used many times) are contrasted with ids (which can be used only once per HTML file), and the benefits of using external style sheets versus internal styles is explained.

The next three chapters build upon each other to provide gentle instruction on how to layout and style the text and images. Formatting menus, tables and headings are tackled next, followed by a chapter devoted to browser differences. Finally, alternative menu and page formatting and CSS debugging is discussed.

All of the major concepts of CSS are presented so that a beginner can easily understand them. While some ways of utilizing CSS properly can be the subject of debate, the authors have chosen a rational approach that serves the basic web designer well. The result is a set of web pages that follow a simply understood design, yet ensures that the layout and format is isolated to the CSS style document, rather than the HTML.

Over and over, Tom and Dori provide useful links to web sites with additional information on the intricacies of CSS, as well as providing suggestions for programs to help you with massaging images and references to other books for more in-depth coverage.

The best way to fully understand what Tom and Dori are trying to explain is to replicate the example web site (Alpaca Repo). Unfortunately, there is no link in the book or on PeachPit's web site to a set of downloadable images and html files. The only way I was able to replicate most (but not all) of the examples was to look at alpacarepo.com. It has six pages, two style sheets, and two photos. The book shows other photos and more complete pages, so it's a partial solution at best.

Overall, Styling Web Pages with CSS: Visual QuickProject Guide is a nice introduction to the potentially confusing topic of the proper use of CSS. Many of the fancier techniques are avoided for the more common and useful ones. The short length of the book allows the beginner to avoid the feeling of intimidation that can accompany reading a 1,000 page text that covers everything you never wanted to know. Even so, I felt less than satisfied after I finished. I wanted a little bit more than I was given. Even if the book doubled in size, it would still be accessible yet it could then leave the reader with a feeling of contentment. As this is the first QuickProject book I've read, that may simply be the target they were shooting for.

One final wish for Peachpit: please include downloadable files that the reader can access to duplicate the Alpaca Repo website. I was continually frustrated when I wanted to replicate what I had just read about, yet was missing JPEG files or extensive text that I could use. Consequently, I never felt as though I had actually gotten the hang of CSS.

You can purchase Styling Web Pages with CSS: Visual QuickProject Guide from amazon.com. Slashdot welcomes readers' book reviews — to see your own review here, read the book review guidelines, then visit the submission page.

Frequent Slashdot contributor Bennett Haselton writes with his take on the recent Time Warner Cable fiasco: "Net Neutrality crusaders at FreePress.net recently called attention to Time Warner's plan (later rescinded) to impose fines on users for going over bandwidth limits. I agree generally, but I think this is easily confused with the reasoning in favor of Net Neutrality, and it's important to keep the arguments separate." Read on for the rest of Bennett's thoughts.

On April 13th I received an e-mail from FreePress.net, one of the organizations that led the fight in favor of Net Neutrality:

Just as we're suffering economically, Time Warner Cable is trying to squeeze us even further, forcing millions of customers to pay steep fees for exceeding an absurdly low monthly limit on Internet use. [...] The company's scheme would cost customers $15 per month for one gigabyte — the equivalent of one 30-minute HD television show — with a penalty fee of $2 for every additional gigabyte over the limit.

Later, FreePress.net triumphantly announced that Time Warner had reversed their position. Now, I would appear to have painted myself into a corner on this issue, because I wrote in an editorial two years ago arguing in favor of Net Neutrality:

[Net Neutrality is] not about how much a service costs, but about the ethics of double-billing for it. [...] If vastly more people start trying to stream CNN over the Internet 24/7, and fully using the services that ISPs have "only been pretending to sell," as Brad Templeton put it, then ISPs may have to charge more for users who consume too much bandwidth, encouraging people to stay at today's average levels by rationing themselves and perhaps watching 24 on their $5,000 TV sets sometimes instead of downloading it off of BitTorrent to their laptop every week because it makes them feel like a haX0r. Much as we all love our unmetered connections, it wouldn't be a violation of Net Neutrality for ISPs to charge users for bandwidth hogging, to keep everyone from going too far above today's levels.

And yet, even after writing those words, I still think there is an argument against letting ISPs impose bandwidth fines, at least under some conditions. However, I think the argument is completely separate from the argument in favor of Net Neutrality, so it's important to derive both of them independently of each other.

I would try to make both arguments by deriving the conclusions from first principles. This might seem pedantic at times, but I think it's helpful to have a precise mathematical-style "proof" of why a conclusion follows from its premises, because then you can see how changing one premise would change the conclusion.

To me the simplest argument in favor of Net Neutrality follows from three assumptions. You don't have to agree with the assumptions, but I think that all three of them are obvious because the opposite would be untenable.

1. An ISP that blocks (or slows access to) certain websites is defrauding its users UNLESS either (a) the ISP has made its users aware of the filtering, or (b) it's overwhelmingly clear that the filtering protects the users or improves their experience (so more experienced users would assume it is taking place anyway). If your ISP has told you that they're selling "Internet access" but they're silently blocking some Web sites, then this is straightforward. You're paying for one thing, and the ISP is selling you something else that is inferior. In the incident that I wrote about, ISPs like Rogers.com that used AboveNet as their upstream provider, were actually blocking their subscribers from reaching certain websites, even though their customers thought they were getting unfiltered Internet access. Now if the ISP advertises that its Internet connections are filtered, as some "family friendly" providers do — so that virtually all users knew about the filtering — then this would not be a violation of Net Neutrality. And if the ISP is blocking mail from actual spam sources, then this is something that protects users and improves their experience, and so is usually not considered a violation of Net Neutrality either. But if the ISP is silently blocking access to Web sites, or blocking mail from servers that are not sending spam but simply because the ISP owner has a political disagreement with those server owners, then that would violate this principle.

2. "Make its customers aware" means just that — make its customers aware — and not bury something in the Terms of Service. Imagine if the opposite principle were accepted — that websites and software vendors could do anything they wanted as long as they put the right disclaimer in the 23rd paragraph of their site's or program's "Terms of Service" that nobody reads. Scam artists' eyes everywhere would light up with dollar signs thinking of the possibilities: Create a popular program and get people to install it, while putting a clause deep in the TOS that permits them to remotely take over your computer after you've installed their software! Or for a real-world example, Yahoo! once tried to amend the GeoCities Terms of Service to give Yahoo! the copyright on any content uploaded by their users. Yahoo! reversed itself after a public backlash, but even if they hadn't, it would have been good public policy for a court to say that Yahoo!'s copyright claim on their users' content was invalid. You can, of course, strengthen your legal rights by putting the right language in your Terms of Service, but it would mean total chaos if companies could bury "gotchas" in your TOS that are wildly contrary to what users are reasonably likely to assume.

3. If company A sells something to company B which company B then re-sells to the public, but company B almost certainly cannot resell the good without committing fraud as outlined above, then company A is complicit in the fraud as well. Some of AboveNet's defenders argued that they mostly sold Internet connectivity to ISPs, not to the public, and the ISPs knew that the connections were filtered. Even assuming this were true, the ISPs still would not be able to re-sell the service to the public without representing it as "regular Internet access" — nobody would pay full price for a broken or degraded connection when a competitor could offer a regular connection for the same price.

So, an ISP that blocks or degrades access to certain Web sites, when users think they are getting full unfettered Internet access, is cheating customers (or, in the case of a backbone provider, complicit in the downstream ISPs cheating their customers) in violation of the principles of Net Neutrality. QED. I would tentatively call these assumptions airtight; at least, I cannot think of any corporate behavior that violates one or more of these principles and should be allowed under good public policy.

By contrast, the argument against Net Neutrality — that the free market will ensure that ISPs provide effective service without the need for government regulation — relies on assumptions that might sound reasonable, but have loopholes, and the loopholes are precisely where Net Neutrality violations can slip through. An anti-Net-Neutrality editorial by Sonia Arrison, for example, argued that "consumers would never stand for blocked Web sites." However, in the case of AboveNet's filtering, downstream users did of course "stand for it," because they didn't know about it, and the natural assumption, when the user sees a website not responding, is to think that the site is down, not that their provider blocked it.

But the argument against bandwidth fines is different. While "broken" Internet access could never be sold to the public without some sort of misrepresentation, it is conceivable that people would still pay for Internet access even if the price were $15 for the first 1 GB and $2 per GB after that. However, it would still be good public policy to prohibit two variants of this scheme: (a) ISPs silently racking up charges, scummy-cell-phone-company style, against users who may not realize what charges they're incurring, and then shocking them with overage bills at the end of the month; and (b) ISPs charging draconian bandwidth fines in cases where they have a monopoly, or near-monopoly, on users' Internet access options.

Prohibiting "shock" overage bills essentially follows from principles #1 and #2 above — users should know what they're getting, and sneaking something into the fine print doesn't count. If someone is approaching their bandwidth limit, and is on track to run over (and incur a lot of charges) before the end of the month, it wouldn't be too much trouble to send them an e-mail or an automated (or live) phone call to warn the user what's going on. If the ISP objects that this would cost them too much, I'd say I'll happily pay $1 for the trouble of them placing a call to my house if it saved me $20 in surprise overages.

Prohibiting bandwidth fines in the case of monopoly situations simply follows from the principle that without competition, the bandwidth overage fees are likely to be much higher than they would be in a competitive market. It may not be the motivation of the ISP simply to make as much money as possible; perhaps they want to discourage high-bandwidth usage for other reasons. As FreePress.net theorized about the proposed Time Warner bandwidth surcharges: "This trick is designed to make customers think twice before switching off their cable TV and finding the shows they want online." But whether it's to squeeze subscribers for extra money or to stop them from streaming content from the Internet, either way, the plan could not be sustainable if users can find higher bandwidth at a lower cost from other providers. For most of its subscribers, Time Warner doesn't have a pure monopoly — in some areas, you can get only one cable Internet provider and only one DSL provider, but the two still compete with each other to provide "Internet access," and other areas have a choice between cable providers. However, in a situation with only a small number of competitors, companies can still keep prices higher than they would in a purely competitive market, because there are fewer chances for an upstart competitor to find ways to provide a more efficient service at a lower cost.

What if neither of these conditions were true? If an ISP actually did make sure that its subscribers knew about the bandwidth limits, and users got warnings if they were approaching those limits, and there were enough competing providers to ensure real competition, then in that situation it would be harder to make an argument against the bandwidth surcharges. (Admittedly, it may be something of an academic point, because there are so few situations where there are "enough competing providers" to guarantee healthy competition.)

But it's important to keep the arguments for Net Neutrality separate from the arguments against bandwidth surcharges. Bandwidth fines are bad mainly when there are few competing providers, because it will be hard for users to get a better deal somewhere else, and providers like Time Warner may have a vested interest in keeping users' bandwidth limits low to keep them glued to their TV. Violations of Net Neutrality are bad regardless of whether there are few or many competing providers, because users cannot avoid the harm if they're unlikely to discover what's happening in the first place.

Frequent Slashdot contributor Bennett Haselton writes with his take on the recent Time Warner Cable fiasco: "Net Neutrality crusaders at FreePress.net recently called attention to Time Warner's plan (later rescinded) to impose fines on users for going over bandwidth limits. I agree generally, but I think this is easily confused with the reasoning in favor of Net Neutrality, and it's important to keep the arguments separate." Read on for the rest of Bennett's thoughts.

On April 13th I received an e-mail from FreePress.net, one of the organizations that led the fight in favor of Net Neutrality:

Just as we're suffering economically, Time Warner Cable is trying to squeeze us even further, forcing millions of customers to pay steep fees for exceeding an absurdly low monthly limit on Internet use. [...] The company's scheme would cost customers $15 per month for one gigabyte — the equivalent of one 30-minute HD television show — with a penalty fee of $2 for every additional gigabyte over the limit.

Later, FreePress.net triumphantly announced that Time Warner had reversed their position. Now, I would appear to have painted myself into a corner on this issue, because I wrote in an editorial two years ago arguing in favor of Net Neutrality:

[Net Neutrality is] not about how much a service costs, but about the ethics of double-billing for it. [...] If vastly more people start trying to stream CNN over the Internet 24/7, and fully using the services that ISPs have "only been pretending to sell," as Brad Templeton put it, then ISPs may have to charge more for users who consume too much bandwidth, encouraging people to stay at today's average levels by rationing themselves and perhaps watching 24 on their $5,000 TV sets sometimes instead of downloading it off of BitTorrent to their laptop every week because it makes them feel like a haX0r. Much as we all love our unmetered connections, it wouldn't be a violation of Net Neutrality for ISPs to charge users for bandwidth hogging, to keep everyone from going too far above today's levels.

And yet, even after writing those words, I still think there is an argument against letting ISPs impose bandwidth fines, at least under some conditions. However, I think the argument is completely separate from the argument in favor of Net Neutrality, so it's important to derive both of them independently of each other.

I would try to make both arguments by deriving the conclusions from first principles. This might seem pedantic at times, but I think it's helpful to have a precise mathematical-style "proof" of why a conclusion follows from its premises, because then you can see how changing one premise would change the conclusion.

To me the simplest argument in favor of Net Neutrality follows from three assumptions. You don't have to agree with the assumptions, but I think that all three of them are obvious because the opposite would be untenable.

1. An ISP that blocks (or slows access to) certain websites is defrauding its users UNLESS either (a) the ISP has made its users aware of the filtering, or (b) it's overwhelmingly clear that the filtering protects the users or improves their experience (so more experienced users would assume it is taking place anyway). If your ISP has told you that they're selling "Internet access" but they're silently blocking some Web sites, then this is straightforward. You're paying for one thing, and the ISP is selling you something else that is inferior. In the incident that I wrote about, ISPs like Rogers.com that used AboveNet as their upstream provider, were actually blocking their subscribers from reaching certain websites, even though their customers thought they were getting unfiltered Internet access. Now if the ISP advertises that its Internet connections are filtered, as some "family friendly" providers do — so that virtually all users knew about the filtering — then this would not be a violation of Net Neutrality. And if the ISP is blocking mail from actual spam sources, then this is something that protects users and improves their experience, and so is usually not considered a violation of Net Neutrality either. But if the ISP is silently blocking access to Web sites, or blocking mail from servers that are not sending spam but simply because the ISP owner has a political disagreement with those server owners, then that would violate this principle.

2. "Make its customers aware" means just that — make its customers aware — and not bury something in the Terms of Service. Imagine if the opposite principle were accepted — that websites and software vendors could do anything they wanted as long as they put the right disclaimer in the 23rd paragraph of their site's or program's "Terms of Service" that nobody reads. Scam artists' eyes everywhere would light up with dollar signs thinking of the possibilities: Create a popular program and get people to install it, while putting a clause deep in the TOS that permits them to remotely take over your computer after you've installed their software! Or for a real-world example, Yahoo! once tried to amend the GeoCities Terms of Service to give Yahoo! the copyright on any content uploaded by their users. Yahoo! reversed itself after a public backlash, but even if they hadn't, it would have been good public policy for a court to say that Yahoo!'s copyright claim on their users' content was invalid. You can, of course, strengthen your legal rights by putting the right language in your Terms of Service, but it would mean total chaos if companies could bury "gotchas" in your TOS that are wildly contrary to what users are reasonably likely to assume.

3. If company A sells something to company B which company B then re-sells to the public, but company B almost certainly cannot resell the good without committing fraud as outlined above, then company A is complicit in the fraud as well. Some of AboveNet's defenders argued that they mostly sold Internet connectivity to ISPs, not to the public, and the ISPs knew that the connections were filtered. Even assuming this were true, the ISPs still would not be able to re-sell the service to the public without representing it as "regular Internet access" — nobody would pay full price for a broken or degraded connection when a competitor could offer a regular connection for the same price.

So, an ISP that blocks or degrades access to certain Web sites, when users think they are getting full unfettered Internet access, is cheating customers (or, in the case of a backbone provider, complicit in the downstream ISPs cheating their customers) in violation of the principles of Net Neutrality. QED. I would tentatively call these assumptions airtight; at least, I cannot think of any corporate behavior that violates one or more of these principles and should be allowed under good public policy.

By contrast, the argument against Net Neutrality — that the free market will ensure that ISPs provide effective service without the need for government regulation — relies on assumptions that might sound reasonable, but have loopholes, and the loopholes are precisely where Net Neutrality violations can slip through. An anti-Net-Neutrality editorial by Sonia Arrison, for example, argued that "consumers would never stand for blocked Web sites." However, in the case of AboveNet's filtering, downstream users did of course "stand for it," because they didn't know about it, and the natural assumption, when the user sees a website not responding, is to think that the site is down, not that their provider blocked it.

But the argument against bandwidth fines is different. While "broken" Internet access could never be sold to the public without some sort of misrepresentation, it is conceivable that people would still pay for Internet access even if the price were $15 for the first 1 GB and $2 per GB after that. However, it would still be good public policy to prohibit two variants of this scheme: (a) ISPs silently racking up charges, scummy-cell-phone-company style, against users who may not realize what charges they're incurring, and then shocking them with overage bills at the end of the month; and (b) ISPs charging draconian bandwidth fines in cases where they have a monopoly, or near-monopoly, on users' Internet access options.

Prohibiting "shock" overage bills essentially follows from principles #1 and #2 above — users should know what they're getting, and sneaking something into the fine print doesn't count. If someone is approaching their bandwidth limit, and is on track to run over (and incur a lot of charges) before the end of the month, it wouldn't be too much trouble to send them an e-mail or an automated (or live) phone call to warn the user what's going on. If the ISP objects that this would cost them too much, I'd say I'll happily pay $1 for the trouble of them placing a call to my house if it saved me $20 in surprise overages.

Prohibiting bandwidth fines in the case of monopoly situations simply follows from the principle that without competition, the bandwidth overage fees are likely to be much higher than they would be in a competitive market. It may not be the motivation of the ISP simply to make as much money as possible; perhaps they want to discourage high-bandwidth usage for other reasons. As FreePress.net theorized about the proposed Time Warner bandwidth surcharges: "This trick is designed to make customers think twice before switching off their cable TV and finding the shows they want online." But whether it's to squeeze subscribers for extra money or to stop them from streaming content from the Internet, either way, the plan could not be sustainable if users can find higher bandwidth at a lower cost from other providers. For most of its subscribers, Time Warner doesn't have a pure monopoly — in some areas, you can get only one cable Internet provider and only one DSL provider, but the two still compete with each other to provide "Internet access," and other areas have a choice between cable providers. However, in a situation with only a small number of competitors, companies can still keep prices higher than they would in a purely competitive market, because there are fewer chances for an upstart competitor to find ways to provide a more efficient service at a lower cost.

What if neither of these conditions were true? If an ISP actually did make sure that its subscribers knew about the bandwidth limits, and users got warnings if they were approaching those limits, and there were enough competing providers to ensure real competition, then in that situation it would be harder to make an argument against the bandwidth surcharges. (Admittedly, it may be something of an academic point, because there are so few situations where there are "enough competing providers" to guarantee healthy competition.)

But it's important to keep the arguments for Net Neutrality separate from the arguments against bandwidth surcharges. Bandwidth fines are bad mainly when there are few competing providers, because it will be hard for users to get a better deal somewhere else, and providers like Time Warner may have a vested interest in keeping users' bandwidth limits low to keep them glued to their TV. Violations of Net Neutrality are bad regardless of whether there are few or many competing providers, because users cannot avoid the harm if they're unlikely to discover what's happening in the first place.

Mad Hamster points out a NY Times report that the US Department of Justice has launched an antitrust inquiry (may require free registration) to take a look at the deal Google has made with book publishers and authors for its Book Search service. Quoting: "Lawyers for the Justice Department have been in conversations in recent weeks with various groups opposed to the settlement, including the Internet Archive and Consumer Watchdog. More recently, Justice Department lawyers notified the parties to the settlement, including Google, and representatives for the Association of American Publishers and the Authors Guild, that they were looking into various antitrust issues related to the far-reaching agreement. The inquiry does not necessarily mean that the department will oppose the settlement, which is subject to a court review. But it suggests that some of the concerns raised by critics, who say the settlement would unfairly give Google an exclusive license to profit from millions of books, have resonated with the Justice Department." Update — 4/29 at 14:25 by SS: CNet has new information on the extension Google was seeking in order to contact rightsholders for a decision on whether to join the settlement or opt out. Google had originally asked for 60 days, but a judge has now granted them four more months.

Mad Hamster points out a NY Times report that the US Department of Justice has launched an antitrust inquiry (may require free registration) to take a look at the deal Google has made with book publishers and authors for its Book Search service. Quoting: "Lawyers for the Justice Department have been in conversations in recent weeks with various groups opposed to the settlement, including the Internet Archive and Consumer Watchdog. More recently, Justice Department lawyers notified the parties to the settlement, including Google, and representatives for the Association of American Publishers and the Authors Guild, that they were looking into various antitrust issues related to the far-reaching agreement. The inquiry does not necessarily mean that the department will oppose the settlement, which is subject to a court review. But it suggests that some of the concerns raised by critics, who say the settlement would unfairly give Google an exclusive license to profit from millions of books, have resonated with the Justice Department." Update — 4/29 at 14:25 by SS: CNet has new information on the extension Google was seeking in order to contact rightsholders for a decision on whether to join the settlement or opt out. Google had originally asked for 60 days, but a judge has now granted them four more months.

An anonymous reader writes "What happens when a new ISP is started somewhere in the United States that completely blows out of the water all the other ISPs in the area, in terms of price and performance? Apparently, that question is being answered in North Carolina, where Greenlight Inc., a company started by a city government, is trying to offer faster, more reliable, and cheaper Internet service to the local residents. Time Warner and Embarq can't compete. So they are not only lobbying the state government to destroy the upstart competition, but are now using push polling methods to gain support, across the two cities that could benefit from the new ISP, for the 'Level the playing field' legislation they got introduced in the legislature." A local news outlet provides coverage more friendly to the incumbents' point of view.

david_adams writes "All the recent talk about various polls and elections being pranked or hijacked, serious and silly alike, prompted me to write an article about the technical realities behind online polling, and the political fallout of ever becoming subject to online voting for serious elections. Even if we were to be able to limit voting to legitimate, legal voters, the realities of social networking and the rise of Internet-based movements would dramatically alter the political landscape if online voting were to become commonplace."

number6x writes "LinuxDevices.com is reporting that the Open Invention Network has posted the details of three of the eight patents used by Microsoft in the Tom Tom suit (which Tom Tom settled last month), asking the community for prior art. These patents cover aspects of the FAT file system. You can find them on Post-Issue.org — see numbers 5579517, 5758352, and 6256642. OIN CEO Keith Bergelt believes that these three patents are of tenuous validity and will probably not survive a review. Bergelt believes that there's a good chance that the USPTO may well invalidate them before the end of the year.

Marzubus writes "Tele2, a popular Swedish ISP, has started to remove IP addresses from its logs. This is the second ISP in Sweden to adopt this new privacy protection strategy." We discussed not long ago when another ISP, Bahnhof, started doing the same. Perhaps this is the corporate equivalent of joining the Pirate Party.

Marzubus writes "Tele2, a popular Swedish ISP, has started to remove IP addresses from its logs. This is the second ISP in Sweden to adopt this new privacy protection strategy." We discussed not long ago when another ISP, Bahnhof, started doing the same. Perhaps this is the corporate equivalent of joining the Pirate Party.

judgecorp writes "Twitter is being criticized for spreading panic about swine flu. This is not just knee-jerk Luddism 2.0: it's argued that Twitter's structure encourages ill-informed repetition, with little room for context, while older Web media use their power for good — for instance Google's Flu Trends page (which we discussed last winter), and the introduction of a Google swine flu map." On a related note, reader NewtonsLaw suggests that it might be a good idea, epidemiologically speaking, to catch the flu now vs. later.

Less than a month after the announcement of Six Days in Fallujah , a video game based upon a real-life battle between US Marines and Iraqi insurgents in 2004, Konami has decided that it is too controversial, and abandoned plans to publish the game. The developer, Atomic Games, has not commented on Konami's decision other than to say an announcement will be made soon. Konami told a Japanese newspaper, "After seeing the reaction to the video game in the United States and hearing opinions sent through phone calls and e-mail, we decided several days ago not to sell it." While the game did receive a great deal of criticism, others were optimistic, including several outspoken veterans of the Iraq war. One of the major complaints was that in researching the battle, Atomic Games reportedly interviewed several insurgents. This prompted speculation that the insurgents were compensated for their help, though Atomic later denied that was the case. Konami's decision also may have been influenced by the fact that they seemed to represent it as entertainment, whereas Atomic's president, Peter Tamte, was more hesitant to describe it as "fun." He said, "The words I would use to describe the game — first of all, it's compelling. And another word I use — insight."

Less than a month after the announcement of Six Days in Fallujah , a video game based upon a real-life battle between US Marines and Iraqi insurgents in 2004, Konami has decided that it is too controversial, and abandoned plans to publish the game. The developer, Atomic Games, has not commented on Konami's decision other than to say an announcement will be made soon. Konami told a Japanese newspaper, "After seeing the reaction to the video game in the United States and hearing opinions sent through phone calls and e-mail, we decided several days ago not to sell it." While the game did receive a great deal of criticism, others were optimistic, including several outspoken veterans of the Iraq war. One of the major complaints was that in researching the battle, Atomic Games reportedly interviewed several insurgents. This prompted speculation that the insurgents were compensated for their help, though Atomic later denied that was the case. Konami's decision also may have been influenced by the fact that they seemed to represent it as entertainment, whereas Atomic's president, Peter Tamte, was more hesitant to describe it as "fun." He said, "The words I would use to describe the game — first of all, it's compelling. And another word I use — insight."

jamie found this note from Jason Scott, who organizes the Archive Team. They are busy downloading as much of Geocities as they can before it vanishes from the Net after Yahoo pulled the plug. (Note: that textfiles.com link is a good candidate for Readability.) "..after 48 hours of work, Archive Team has saved over 200,000 Geocities sites. We're now pulling in new sites at the rate of something like 5 a second. Is that fast enough? We'll see, won't we. ... A side-effect of the whole process is I now know way, way, way too much [sic] about Geocities than I ever expected to. We've had to dissect every aspect of how the site functions to understand how to mirror things, from its history through how it does crazy javascript ads. Some of it is stupid and some is hilarious... We think we have most every site from 1999 and before on Geocities that was left. ... It is more important to me to grab the data than to figure out how to serve it later. People who have been talking about copyright and stuff seem to think I'm going to sell it or take credit or some crap. I don't see how the final collection won't end up online, but how is elusive — maybe a torrent of a bunch of zip files, or as a curated collection, or as a bunch of hard drives. However it is, I'll make sure people can get it, somehow."

CWmike writes "Microsoft's decision to let Windows 7 users run Windows XP applications in a virtual machine may have been necessary to convince people to upgrade, but it could also create support nightmares, analysts said today. Gartner analyst Michael Silver outlines the downsides. 'You'll have to support two versions of Windows,' he said. 'Each needs to be secured, antivirused, firewalled and patched. If a company has 10,000 PCs, that's 20,000 instances of Windows.' The other big problem Silver foresees: Making sure the software they run is compatible with Windows 7. 'This is a great Band-Aid, but companies need to heal their applications,' Silver said. 'They'll be doing themselves a disservice if, because of XPM, they're not making sure that all their apps support Windows 7.'"

Michael J. Ross writes "Two decades ago, Web usage was limited to a single individual (Sir Tim Berners-Lee) using the only browser in existence (WorldWideWeb) running on a single platform (a NeXT Computer). Nowadays, billions of people access the Web daily, with the ability to choose from over a dozen browsers running on desktop computers, laptops, and a variety of mobile devices, such as cell phones. The number of possible combinations is growing rapidly, and makes it increasingly difficult for Web designers and developers to craft their sites so as to be universally accessible. This is particularly true when accounting for Web users with physical and cognitive disabilities — especially if they do not have access to assistive technologies. The challenges and solutions for anyone creating an accessible website are addressed in Universal Design for Web Applications, authored by Wendy Chisholm and Matt May." Keep reading for the rest of Michael and Laura's review. Universal Design for Web Applications author Wendy Chisholm and Matt May pages 198 publisher O'Reilly Media rating 5/10 reviewer Michael J. Ross with Laura Andres ISBN 9780596518738 summary An introduction to accessible Web design. The book was published by O'Reilly Media on 26 November 2008, under the ISBN 9780596518738, and weighs in at a slender 198 pages. The publisher offers a Web page for the book, where visitors will find a detailed description, a customer review, errata (there are none listed, as of this writing), a sample chapter (the 11th one, "The Process") in PDF format, and other items that may be of interest to the prospective reader. The authors as well have a website for the book, which offers the 20 accessibility checklist questions from Chapter 11, as well as slides from the authors' presentation at the Web 2.0 Expo on 17 September 2008 in New York City.

In the preface to their book, the authors explain that the purpose of universal Web design is to make Web content "work as efficiently as possible across the range of capabilities exhibited by both people and their chosen browsing technologies." While it has little to do with efficiency per se, maximum Web usability is a laudable goal for every designer and developer of a website or Web-based application. The consensus in the Web design community is that the most effective way to achieve this goal is through adherence to accepted usability standards and design practices, and those are the topics that the authors explore in the eleven chapters that compose this book: an introduction; selling universal design; metadata; structure and design; forms; tabular data; video and audio; scripting; AJAX and WAI-ARIA; Rich Internet applications; and the universal design process.

The first chapter serves as a brief introduction to the concept and overall purpose of universal design (UD), which the authors consider to be "the design of products and environments to be usable by all people, to the greatest extent possible, without the need for adaptation or specialized design" (as defined by architect Ron Mace). In view of the brevity and preliminary nature of this chapter's material, it should have been labeled as an introduction, and not a chapter. More importantly, the discussion is rather choppy, jumping among topics such as architecture, grocery stores, unemployment rates among the blind, and mobile phones. Readers will likely be confused by the authors' statement that "mobile and accessible design are also at opposite ends of the spectrum when it comes to meeting our stated goal," as that suggests that the more mobile the device, the least accessible platform it can ever be. Yet the gist of the discussion is clear: The need for maximally accessible websites is quite important — critical to those with various disabilities — and will become more so with the proliferation of Web-enabled mobile devices.

If any chapter in this book is going to raise hackles, it is surely the second one. It focuses on how to sell Web accessibility to decision-makers, such as convincing management that compliance with universal design standards — in creating a new site or re-creating an existing one — is worth the investment. This position could easily be supported with a thoroughly positive mindset, such as showing how enhanced accessibility for some is beneficial to all. Instead, the authors initially take a more negative approach, and begin the chapter with somewhat hostile descriptions of what it is like to not understand a movie, and the resistance the authors have encountered in selling accessibility to clients. The authors clearly want the reader to empathize with such people, but the methods employed are questionable — such as asserting that all of us can face a handicap at some point, and thus we can all be lumped together as "disabled." While the authors' passion for online resources being made available to everyone, is certainly laudable, there is nothing to be gained from making sweeping generalizations or lecturing the reader. (Overstating one's arguments tends to turn off listeners, and provides fodder for counterarguments.) The authors go on to define the four major categories of physical and situational disabilities, as they relate to website usage. They cite statistics for deafness and hard of hearing, but neglect to include tinnitus, which apparently has more sufferers than those first two conditions combined. Next, the authors provide selling points for employing universal design to increase a site's potential audience — humans and search engines — thereby increasing financial results and adhering to legal restrictions. Readers are referred to a number of pertinent resources, including the Web Content Accessibility Guidelines (WCAG), the Authoring Tool Accessibility Guidelines (ATAG), the User Agent Accessibility Guidelines (UAAG), the Accessible Rich Internet Applications Suite (WAI-ARIA), and the Mobile Web Best Practices (MWBP). Nearing the end of the chapter, the authors return to the minefield of how to convince the "prejudiced developer" and manager that they should learn and utilize accessibility best practices in creating websites for which they are responsible, especially when they see no value or need for it. Lastly, excellent arguments for the product benefits of continuous accessible design are briefly presented.

By the third chapter, Web designers and developers who purchased this book to learn specific accessibility techniques, may become a bit impatient, since nothing concrete has been presented up to that point (despite the claim later in the chapter that "We've devoted three chapters to making web applications accessible."). Fortunately, this chapter gets things going by addressing metadata and how it can be leveraged to increase content accessibility. The specific techniques discussed include the alt, height, and width attributes for image tags; document-level metadata, including title tags; and link text. The guidelines are definitely worthwhile, but the presentation could have been better edited. For example, the authors state that the alt text for a linked image is "a verb and represents where the link will take you" (page 27), but a destination is not a verb, and neither is the example provided ("next page").

Chapter 4 addresses the structuring and design of Web pages, and covers important topics of semantic markup, headings, links, lists, forms, tables, colors, layout choices, text sizing, fonts, and images. For some reason not explained to the reader, forms are discussed first, even before semantics, which is odd. Nonetheless, all of the suggestions provided are well worth learning and incorporating into one's own repertoire of Web coding and design principles. The authors rightly teach the maxim "separate structure and presentation," and demonstrate how to do this throughout the discussion of the aforesaid topics. Also addressed are flickering images — and one of the dangers thereof, photoepilepsy — and HTML e-mail messages.

Web forms possibly compose the most problematic type of page element, especially in terms of usability and accessibility, because they involve for more user input than any other. This is especially true with forms that use CAPTCHAs in an attempt to defeat form spam. Chapter 5 encompasses a useful discussion, with illustrative sample code, covering the key considerations for coding accessible forms — including labels, fieldsets and their legends, accesskey attributes, and tab order among elements. The authors state that a block of sample form code (page 54) is available on their website, but, as of this writing, it could not be found. Yet readers may not want to use that code anyway, since all of the labels and all of the input fields are separated, into two divs; no explanation is given as to why this nonstandard structure was chosen. Error handling is a subject that stymies countless inexperienced Web programmers, as evidenced by the oftentimes useless messages displayed on the sites that they have created, and the authors provide solid advice, with emphasis on client-side error handling. The chapter concludes with a somewhat short discussion of what they consider "Public Enemy #1 for blind, low-vision, and dyslexic people," the dreaded CAPTCHA, with links to two publications that propose alternatives.

Accessibility abuses are especially prevalent with three types of Web content: HTML tables and multimedia. These are the topics of chapters 6 and 7, respectively. Semantic use of HTML tables for tabular data is seeing a resurgence with the growing interest in accessible design, and Chapter 6 explains how to implement them properly. However, Figure 6-3 purportedly contains blue shading, but it is effectively invisible on the black-and-white printed page. Chapter 7 explains how to add captions and audio descriptions to audiovisual files, or outsource the work. But first the reader slogs through a detailed history of Web-based video that is unneeded, despite the authors' claims that knowledge of the history is important.

The next two chapters discuss the use of JavaScript and AJAX as they pertain to site accessibility, and could be combined into a single chapter. The first one briefly addresses a number of related topics: progressive enhancement, Unobtrusive JavaScript (again with an unnecessary history), keyboard activation of pop-up menus, limitations of :hover pseudoselectors, two recommended drop-down menu scripts, and tabbing order. One of the scripts is an open-source script that the authors claim can be downloaded from their website; but, like the form sample code mentioned above, the promised script is missing from their site. The authors later declare (page 107) that in this chapter they show "you how to add JavaScript to your HTML and CSS to make a web application," when in fact they do nothing of the sort. Entire books explain how to make Web applications — not something accomplished in a 15-page chapter. Chapter 9 focuses on AJAX and WAI-ARIA — specifically, the ways that the AJAX paradigm clashes with the current state of assistive technologies, and how ARIA may prove the best solution — resolving the keyboard activation problem covered in the previous chapter, and handling tab ordering in a more elegant manner — though still not ubiquitously implemented. The narrative's flow is interrupted with almost three pages of JavaScript that the reader is apparently not expected to implement as-is or even use as sample code to learn from, and thus looks suspiciously like padding.

In Chapter 10, the authors discuss the unfortunate lack of Web accessibility guidelines for Rich Internet applications (RIAs) developed using technologies such as Java, Flex, and Silverlight. To remedy this, the authors promise "a crash course in software accessibility as applied to Flex and Silverlight," but only deliver on the second half of that promise. For illustrating Silverlight development, they provide some of the code for creating a custom Digg button (although the term "buttons" is also confusingly used). The chapter concludes with mention of some tools from Microsoft for testing RIAs that utilize Microsoft Active Accessibility (MSAA).

The last chapter begins with a brief high-level perspective on the importance of baking accessibility into any new application or site from the start, and then explores numerous development and testing tools and other resources. Perhaps the material that will be most referenced in the future by readers, are the 20 key questions that a designer can use as a valuable checklist for evaluating a site she has created. The chapter concludes with some thoughts on strategies for successful universal design, for four different team sizes. The book's sole appendix consists of a table relisting the 20 key usability questions, and for each one, the specifications of the WCAG 2.0 Proposed Recommendation, the MWBP 1.0, and the UD4WA. This is followed by an index that proved quite disappointing, as it contains almost none of the entries that I attempted to look up.

Universal Design for Web Applications has numerous relatively minor flaws that could be fixed in a future edition: Some of the chapter summaries comprise only one or two sentences, and add no value to the book, since the chapters themselves are so short. Other chapter summaries contain new material not even mentioned in the respective chapters, and should be renamed as final sections. Many of the URLs are wisely presented as footnotes — instead of embedded in the text, as is done in many other technical books, which impedes reading flow. Unfortunately, this practice was not followed consistently throughout the book. In some passages, the writing style is rather unpolished; for instance, "mobile and accessibility as our criteria" (page 2), mixes adjective and noun. In other passages, the statements are hyperbolic; for instance, a reporter "found himself a hair's breadth from being eviscerated" (page 4). Some unexplained phrases will prove cryptic to many readers; for instance, "content adaptation" (page 24), "lolcats" (page 26), and "antipattern" (page 37). The use of a shortened URL (page 23) is inadvisable, since it depends upon the longevity of the particular service provider and the short URL that the service generated. Some of the terminology is inconsistent, e.g., the Enter key referred to as a "Return" key. The book contains a couple erratum: "to to" (page 12), and a sentence missing a verb (page 111, beginning with "Layering").

A visually annoying problem with this book is the manner in which, on far too many lines in the text, there is an inadequate amount of space between the words. Consequently, distinguishing individual words — particularly when trying to read at a fast pace — is made much more difficult. While skimming, each line begins to look like one extremely long word. There is no excuse for this, since there is plenty of space in the outer margins to have expanded the lines, and the number of pages is far less than in a typical computer book. This is not the first of the most recently published O'Reilly books to exhibit this problem, but I certainly hope it is the last. It is rather ironic to see this readability mistake in a book devoted to usability and accessibility. (Note that production decisions such as whitespace are not decided by the authors.)

Perhaps the most exasperating defect of all is that both instances of code that supposedly can be downloaded from the authors' website, are nowhere to be found, as of this writing — nor is the code available on the O'Reilly page for the book. In fact, a reader comment on that O'Reilly page indicates that the script code wasn't available on 30 December 2008, just weeks after the book's publication. This is quite unlike the level of follow-through typically seen with O'Reilly authors.

In some respects, the book could have been far better than the final product. It gets off to a weak start with a non-chapter, and then in several sections spends pages discussing the history of various technologies, but then fails to go into enough detail so the reader could use the current state of those technologies to implement what is promised in the book. It also could have been improved with much more detailed and usable discussions of such topics as scrolling, bypassing blocks of content, session time limits on forms, site maps, breadcrumb trails, usable CAPTCHA alternatives, typography, text case, paragraph justification, sign language, text direction, and techniques for providing text for image-heavy websites — as well as more complete code examples.

Nonetheless, Universal Design for Web Applications provides some valuable recommendations and pointers on how website designers, developers, and owners can greatly increase the accessibility of their sites to the growing variety of human and search engine visitors on the Internet.

Michael J. Ross is a freelance Web developer and writer. Laura Andres is a Unix administrator, Oracle DBA, and programmer.

You can purchase Universal Design for Web Applications: Web Applications That Reach Everyone from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Michael J. Ross writes "Two decades ago, Web usage was limited to a single individual (Sir Tim Berners-Lee) using the only browser in existence (WorldWideWeb) running on a single platform (a NeXT Computer). Nowadays, billions of people access the Web daily, with the ability to choose from over a dozen browsers running on desktop computers, laptops, and a variety of mobile devices, such as cell phones. The number of possible combinations is growing rapidly, and makes it increasingly difficult for Web designers and developers to craft their sites so as to be universally accessible. This is particularly true when accounting for Web users with physical and cognitive disabilities — especially if they do not have access to assistive technologies. The challenges and solutions for anyone creating an accessible website are addressed in Universal Design for Web Applications, authored by Wendy Chisholm and Matt May." Keep reading for the rest of Michael and Laura's review. Universal Design for Web Applications author Wendy Chisholm and Matt May pages 198 publisher O'Reilly Media rating 5/10 reviewer Michael J. Ross with Laura Andres ISBN 9780596518738 summary An introduction to accessible Web design. The book was published by O'Reilly Media on 26 November 2008, under the ISBN 9780596518738, and weighs in at a slender 198 pages. The publisher offers a Web page for the book, where visitors will find a detailed description, a customer review, errata (there are none listed, as of this writing), a sample chapter (the 11th one, "The Process") in PDF format, and other items that may be of interest to the prospective reader. The authors as well have a website for the book, which offers the 20 accessibility checklist questions from Chapter 11, as well as slides from the authors' presentation at the Web 2.0 Expo on 17 September 2008 in New York City.

In the preface to their book, the authors explain that the purpose of universal Web design is to make Web content "work as efficiently as possible across the range of capabilities exhibited by both people and their chosen browsing technologies." While it has little to do with efficiency per se, maximum Web usability is a laudable goal for every designer and developer of a website or Web-based application. The consensus in the Web design community is that the most effective way to achieve this goal is through adherence to accepted usability standards and design practices, and those are the topics that the authors explore in the eleven chapters that compose this book: an introduction; selling universal design; metadata; structure and design; forms; tabular data; video and audio; scripting; AJAX and WAI-ARIA; Rich Internet applications; and the universal design process.

The first chapter serves as a brief introduction to the concept and overall purpose of universal design (UD), which the authors consider to be "the design of products and environments to be usable by all people, to the greatest extent possible, without the need for adaptation or specialized design" (as defined by architect Ron Mace). In view of the brevity and preliminary nature of this chapter's material, it should have been labeled as an introduction, and not a chapter. More importantly, the discussion is rather choppy, jumping among topics such as architecture, grocery stores, unemployment rates among the blind, and mobile phones. Readers will likely be confused by the authors' statement that "mobile and accessible design are also at opposite ends of the spectrum when it comes to meeting our stated goal," as that suggests that the more mobile the device, the least accessible platform it can ever be. Yet the gist of the discussion is clear: The need for maximally accessible websites is quite important — critical to those with various disabilities — and will become more so with the proliferation of Web-enabled mobile devices.

If any chapter in this book is going to raise hackles, it is surely the second one. It focuses on how to sell Web accessibility to decision-makers, such as convincing management that compliance with universal design standards — in creating a new site or re-creating an existing one — is worth the investment. This position could easily be supported with a thoroughly positive mindset, such as showing how enhanced accessibility for some is beneficial to all. Instead, the authors initially take a more negative approach, and begin the chapter with somewhat hostile descriptions of what it is like to not understand a movie, and the resistance the authors have encountered in selling accessibility to clients. The authors clearly want the reader to empathize with such people, but the methods employed are questionable — such as asserting that all of us can face a handicap at some point, and thus we can all be lumped together as "disabled." While the authors' passion for online resources being made available to everyone, is certainly laudable, there is nothing to be gained from making sweeping generalizations or lecturing the reader. (Overstating one's arguments tends to turn off listeners, and provides fodder for counterarguments.) The authors go on to define the four major categories of physical and situational disabilities, as they relate to website usage. They cite statistics for deafness and hard of hearing, but neglect to include tinnitus, which apparently has more sufferers than those first two conditions combined. Next, the authors provide selling points for employing universal design to increase a site's potential audience — humans and search engines — thereby increasing financial results and adhering to legal restrictions. Readers are referred to a number of pertinent resources, including the Web Content Accessibility Guidelines (WCAG), the Authoring Tool Accessibility Guidelines (ATAG), the User Agent Accessibility Guidelines (UAAG), the Accessible Rich Internet Applications Suite (WAI-ARIA), and the Mobile Web Best Practices (MWBP). Nearing the end of the chapter, the authors return to the minefield of how to convince the "prejudiced developer" and manager that they should learn and utilize accessibility best practices in creating websites for which they are responsible, especially when they see no value or need for it. Lastly, excellent arguments for the product benefits of continuous accessible design are briefly presented.

By the third chapter, Web designers and developers who purchased this book to learn specific accessibility techniques, may become a bit impatient, since nothing concrete has been presented up to that point (despite the claim later in the chapter that "We've devoted three chapters to making web applications accessible."). Fortunately, this chapter gets things going by addressing metadata and how it can be leveraged to increase content accessibility. The specific techniques discussed include the alt, height, and width attributes for image tags; document-level metadata, including title tags; and link text. The guidelines are definitely worthwhile, but the presentation could have been better edited. For example, the authors state that the alt text for a linked image is "a verb and represents where the link will take you" (page 27), but a destination is not a verb, and neither is the example provided ("next page").

Chapter 4 addresses the structuring and design of Web pages, and covers important topics of semantic markup, headings, links, lists, forms, tables, colors, layout choices, text sizing, fonts, and images. For some reason not explained to the reader, forms are discussed first, even before semantics, which is odd. Nonetheless, all of the suggestions provided are well worth learning and incorporating into one's own repertoire of Web coding and design principles. The authors rightly teach the maxim "separate structure and presentation," and demonstrate how to do this throughout the discussion of the aforesaid topics. Also addressed are flickering images — and one of the dangers thereof, photoepilepsy — and HTML e-mail messages.

Web forms possibly compose the most problematic type of page element, especially in terms of usability and accessibility, because they involve for more user input than any other. This is especially true with forms that use CAPTCHAs in an attempt to defeat form spam. Chapter 5 encompasses a useful discussion, with illustrative sample code, covering the key considerations for coding accessible forms — including labels, fieldsets and their legends, accesskey attributes, and tab order among elements. The authors state that a block of sample form code (page 54) is available on their website, but, as of this writing, it could not be found. Yet readers may not want to use that code anyway, since all of the labels and all of the input fields are separated, into two divs; no explanation is given as to why this nonstandard structure was chosen. Error handling is a subject that stymies countless inexperienced Web programmers, as evidenced by the oftentimes useless messages displayed on the sites that they have created, and the authors provide solid advice, with emphasis on client-side error handling. The chapter concludes with a somewhat short discussion of what they consider "Public Enemy #1 for blind, low-vision, and dyslexic people," the dreaded CAPTCHA, with links to two publications that propose alternatives.

Accessibility abuses are especially prevalent with three types of Web content: HTML tables and multimedia. These are the topics of chapters 6 and 7, respectively. Semantic use of HTML tables for tabular data is seeing a resurgence with the growing interest in accessible design, and Chapter 6 explains how to implement them properly. However, Figure 6-3 purportedly contains blue shading, but it is effectively invisible on the black-and-white printed page. Chapter 7 explains how to add captions and audio descriptions to audiovisual files, or outsource the work. But first the reader slogs through a detailed history of Web-based video that is unneeded, despite the authors' claims that knowledge of the history is important.

The next two chapters discuss the use of JavaScript and AJAX as they pertain to site accessibility, and could be combined into a single chapter. The first one briefly addresses a number of related topics: progressive enhancement, Unobtrusive JavaScript (again with an unnecessary history), keyboard activation of pop-up menus, limitations of :hover pseudoselectors, two recommended drop-down menu scripts, and tabbing order. One of the scripts is an open-source script that the authors claim can be downloaded from their website; but, like the form sample code mentioned above, the promised script is missing from their site. The authors later declare (page 107) that in this chapter they show "you how to add JavaScript to your HTML and CSS to make a web application," when in fact they do nothing of the sort. Entire books explain how to make Web applications — not something accomplished in a 15-page chapter. Chapter 9 focuses on AJAX and WAI-ARIA — specifically, the ways that the AJAX paradigm clashes with the current state of assistive technologies, and how ARIA may prove the best solution — resolving the keyboard activation problem covered in the previous chapter, and handling tab ordering in a more elegant manner — though still not ubiquitously implemented. The narrative's flow is interrupted with almost three pages of JavaScript that the reader is apparently not expected to implement as-is or even use as sample code to learn from, and thus looks suspiciously like padding.

In Chapter 10, the authors discuss the unfortunate lack of Web accessibility guidelines for Rich Internet applications (RIAs) developed using technologies such as Java, Flex, and Silverlight. To remedy this, the authors promise "a crash course in software accessibility as applied to Flex and Silverlight," but only deliver on the second half of that promise. For illustrating Silverlight development, they provide some of the code for creating a custom Digg button (although the term "buttons" is also confusingly used). The chapter concludes with mention of some tools from Microsoft for testing RIAs that utilize Microsoft Active Accessibility (MSAA).

The last chapter begins with a brief high-level perspective on the importance of baking accessibility into any new application or site from the start, and then explores numerous development and testing tools and other resources. Perhaps the material that will be most referenced in the future by readers, are the 20 key questions that a designer can use as a valuable checklist for evaluating a site she has created. The chapter concludes with some thoughts on strategies for successful universal design, for four different team sizes. The book's sole appendix consists of a table relisting the 20 key usability questions, and for each one, the specifications of the WCAG 2.0 Proposed Recommendation, the MWBP 1.0, and the UD4WA. This is followed by an index that proved quite disappointing, as it contains almost none of the entries that I attempted to look up.

Universal Design for Web Applications has numerous relatively minor flaws that could be fixed in a future edition: Some of the chapter summaries comprise only one or two sentences, and add no value to the book, since the chapters themselves are so short. Other chapter summaries contain new material not even mentioned in the respective chapters, and should be renamed as final sections. Many of the URLs are wisely presented as footnotes — instead of embedded in the text, as is done in many other technical books, which impedes reading flow. Unfortunately, this practice was not followed consistently throughout the book. In some passages, the writing style is rather unpolished; for instance, "mobile and accessibility as our criteria" (page 2), mixes adjective and noun. In other passages, the statements are hyperbolic; for instance, a reporter "found himself a hair's breadth from being eviscerated" (page 4). Some unexplained phrases will prove cryptic to many readers; for instance, "content adaptation" (page 24), "lolcats" (page 26), and "antipattern" (page 37). The use of a shortened URL (page 23) is inadvisable, since it depends upon the longevity of the particular service provider and the short URL that the service generated. Some of the terminology is inconsistent, e.g., the Enter key referred to as a "Return" key. The book contains a couple erratum: "to to" (page 12), and a sentence missing a verb (page 111, beginning with "Layering").

A visually annoying problem with this book is the manner in which, on far too many lines in the text, there is an inadequate amount of space between the words. Consequently, distinguishing individual words — particularly when trying to read at a fast pace — is made much more difficult. While skimming, each line begins to look like one extremely long word. There is no excuse for this, since there is plenty of space in the outer margins to have expanded the lines, and the number of pages is far less than in a typical computer book. This is not the first of the most recently published O'Reilly books to exhibit this problem, but I certainly hope it is the last. It is rather ironic to see this readability mistake in a book devoted to usability and accessibility. (Note that production decisions such as whitespace are not decided by the authors.)

Perhaps the most exasperating defect of all is that both instances of code that supposedly can be downloaded from the authors' website, are nowhere to be found, as of this writing — nor is the code available on the O'Reilly page for the book. In fact, a reader comment on that O'Reilly page indicates that the script code wasn't available on 30 December 2008, just weeks after the book's publication. This is quite unlike the level of follow-through typically seen with O'Reilly authors.

In some respects, the book could have been far better than the final product. It gets off to a weak start with a non-chapter, and then in several sections spends pages discussing the history of various technologies, but then fails to go into enough detail so the reader could use the current state of those technologies to implement what is promised in the book. It also could have been improved with much more detailed and usable discussions of such topics as scrolling, bypassing blocks of content, session time limits on forms, site maps, breadcrumb trails, usable CAPTCHA alternatives, typography, text case, paragraph justification, sign language, text direction, and techniques for providing text for image-heavy websites — as well as more complete code examples.

Nonetheless, Universal Design for Web Applications provides some valuable recommendations and pointers on how website designers, developers, and owners can greatly increase the accessibility of their sites to the growing variety of human and search engine visitors on the Internet.

Michael J. Ross is a freelance Web developer and writer. Laura Andres is a Unix administrator, Oracle DBA, and programmer.

You can purchase Universal Design for Web Applications: Web Applications That Reach Everyone from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

An anonymous reader points out a ReadWriteWeb piece on an hour-long demo of Wolfram|Alpha (which we discussed at its announcement). Stephen Wolfram does not like to call it a "search engine," preferring instead the term "computational knowledge engine." It will open to the public in May. "The hype around Wolfram|Alpha, the next 'Google killer' from the makers of Mathematica, has been building over the last few weeks. Today, we were lucky enough to attend a one-hour web demo with Stephen Wolfram, and from what we've seen, it definitely looks like it can live up to the hype — though, because it is so different from traditional search engines, it will definitely not be a 'Google killer.' According to Stephen Wolfram, the goal of Alpha is to give everyone access to expert knowledge and the data that a specialist would be able to compute from this information."

mallumax sends word from the NYTimes that US government officials today declared a public health emergency over increasing cases of the swine flu first seen in Mexico. Here is additional coverage from CNN. From the Times: "American health officials [say]... that they had confirmed 20 cases of the disease in the United States and expected to see more as investigators fan out to track down the path of the outbreak. Other governments around the world stepped up their response to the incipient outbreak, racing to contain the infection amid reports of potential new cases from New Zealand to Hong Kong to Spain, raising concerns about the potential for a global pandemic. The cases in US looked to be similar to the deadly strain of swine flu that has killed more than 80 people in Mexico and infected 1,300 more." Reader "The man who walks in the woods" sends a link to accounts emailed to the BBC from readers in Mexico. While these are anecdotal, they do paint a picture of a more serious situation than government announcements have indicated so far.

Reader resistant sends in an update to our discussion a month back on the possibility of violent space weather destroying power grids worldwide during the upcoming solar cycle. Wired is running an interview with Lawrence Joseph, author of "Apocalypse 2012: A Scientific Investigation into Civilization's End," and John Kappenman, CEO of electromagnetic damage consulting company MetaTech. The piece brings two new threads to the discussion: the recently discovered presence of an unusually large hole in Earth's geomagnetic shield, magnifying our vulnerability, and possible steps we can take over the next few years to make the power grid more robust against solar flares and coronal mass ejections. There's also that whole Mayan 2012 thing. Quoting John Kapperman: "What we're proposing is to add some fairly small and inexpensive resistors in the transformers' ground connections. The addition of that little bit of resistance would significantly reduce the amount of the geomagnetically induced currents that flow into the grid. In its simplest form, it's something that might be made out of cast iron or stainless steel, about the size of a washing machine. ...we think it's do-able for $40,000 or less per resistor. That's less than what you pay for insurance for a transformer. [In the US] there are about 5,000 transformers to consider this for. ... We're talking about $150 million or so. It's pretty small in the grand scheme of things."

krou writes "In Dec. 2006, we discussed the Espresso Book Machine. Well, on April 27 the bookseller Blackwell will launch a three-month trial of the machine in its Charing Cross Road branch in London as a 'print on demand' service for shoppers in an effort 'to consign to history the idea that you can walk into a bookshop and not find the book you want.' When the trial begins, it will be able to print any of some 400,000 titles; Blackwell's overall goal is to extend this to a million titles by the summer, and to spread out more machines to the rest of its sixty stores once it works out pricing. Currently, they charge shelf price for in-print books, and 10 pence per page for those out of print (about $55 for a 300-page book), but are analyzing customer behavior to get a better pricing model. Says Blackwell chief executive Andrew Hutchings: 'This could change bookselling fundamentally. It's giving the chance for smaller locations, independent booksellers, to have the opportunity to truly compete with big stock-holding shops and Amazon ... I like to think of it as the revitalization of the local bookshop industry.' Their website notes that in addition to getting books printed in-store, in future you will be able to order titles via their site. (They also mention that one of the titles you can print is the 1915 Oxford Poetry Book, which includes one of Tolkien's first poems, 'Goblin's Feet.')" You'll also be able to bring in your own book to print — two PDF files, one for the book block and one for the cover.

An anonymous reader writes "Nassim Nicholas Taleb, a famous 'Quant,' has long been a strong critic of the use of mathematics and statistics in the financial markets. He has been very vocal in his books The Black Swan and Fooled by Randomness. In his article on edge.org, he says 'My outrage is aimed at the scientist-charlatan putting society at risk using statistical methods. This is similar to iatrogenics, the study of the doctor putting the patient at risk.' After the recent financial crisis, wired.com ran an article titled 'Recipe for Disaster: The Formula That Killed Wall Street' in which the quant David Li and his Gaussian Copula were crucified — we discussed it at the time. Now, I've recently been admitted to a graduate program of good repute in Computational & Applied Mathematics. There is a wide range of subjects in which you can pursue your PhD, one of them being Financial Mathematics. I had a passing interest in it for quite some time. In the current scenario, how advisable it is to pursue a PhD in this topic? What would my options be five years down the line? Will the so-called 'quants' still be wanted by the banks and other financial institutions, or will they turn to more 'non-math' approaches? Would I be better off specializing in less volatile areas of Applied Mathematics? In short, what is the future of Financial Mathematics in light of the current financial crisis?"

MaulerOfEmotards sends along an in-depth followup, from the Swedish press, of our discussion the other day about the biased trial judge in the Pirate Bay case. "The turmoil concerns Tomas Norström, the presiding judge of The Pirate Bay trial, who is suspected of bias after reports surfaced of affiliation with copyright protection organizations. For this he has been reported to the appeals court (in Swedish; translation here). The circus around the judge is currently focused on three points. First, his personal affiliation with at least four copyright protection organizations, a state the potential bias of which he himself fails to see and refuses to admit. Secondly, Swedish trials use a system of several lay assessors to supervise the presiding judge. One of these, a member of an artists' interest organization, was forced by Mr. Norström to resign from the trial for potential bias. The judge's failure to see the obvious contradiction in this (translation) casts doubts on his suitability and competence. Thirdly, according to professor of judicial sociology Håkan Hydén (translation), the judge has inappropriately 'duped and influenced the lay assessors' during the trial: 'a judge that has decided that "this is something we can't allow" has little problem finding legal arguments that are difficult for assisting lay assessors to counter.'" Click the link below to read further on Professor Hydén's enumeration of "at least three strange things in a strange trial." On a related note, reader Siker adds the factoid that membership in the Pirate Party exploded 150% in the week following the verdict. The Pirate Party now surpasses in size four smaller parties in Sweden, and is closing in on a fifth. Political fallout could ensue as soon as June, when an election for EU parliament will be held.
Professor Hydén continues with enumerating "at least three strange things in a strange trial" (translation): First, that someone can be sentenced for being accessory to a crime for which there is no main culprit: "This assumes someone else having committed the crime, and no such individual exists here... the system cannot charge the real culprits or it would collapse in its entirety." It is unprecedented in Swedish judicial history to sentence only an accessory. Second, that the accessories should pay the fine for a crime committed by the main culprits, "which causes the law to contradict itself." And third, that accessories cannot be sentenced to harsher than the main culprit, which means that every downloader must be sentenced to a year's confinement. Prof. Hydén sums up by saying that to allow this kind of judgement the Swedish Parliament must first pass a bill making this kind of services illegal, which it has not done.

ericatcw writes "There was a flurry of excitement earlier this week when the first Google Android netbook, the Skytone Alpha 680, was spotted by Slashdotters. Now, Computerworld has scored an exclusive interview with Skytone's co-founder. Among many tidbits, he reveals that the Alpha 680 builds upon the success of last year's $180 Alpha 400, which shipped 100,000 units, mostly in Europe under names such as Elonex OneT; that the new Alpha 680 will weigh 1.5 pounds, 25% less than the first Eee 701 netbook; that its ARM11 chip (basically the same as the one used in the iPhone) can handle YouTube video; and that he hopes to have Chinese manufacturing partners producing the $250 Alpha 680 within 3 months."

mariushm writes "After deciding to shelve metered broadband plans, it looks like Time Warner is cutting off, with no warning, the accounts of customers whom they deem to have used too much bandwidth. 'Austin Stop The Cap reader Ryan Howard reports that his Road Runner service was cut off yesterday without warning. According to Ryan, it took four calls to technical support, two visits to the cable store to try two new cable modems (all to no avail), before someone at Time Warner finally told him to call the company's "Security and Abuse" center. "I called the number and had to leave a voice mail, and about an hour later a Time Warner technician called me back and lectured me for using 44 gigabytes in one week," Howard wrote. Howard was then "educated" about his usage. "According to her, that is more than most people use in a year," Howard said.'"

FP writes "On Friday morning, lawyers urged a federal judge to bar RealNetworks from selling software that allows consumers to copy their DVDs to computer hard drives, arguing that the Seattle-based company's product is an illegal pirating tool. RealNetworks' lawyers countered later in the morning that its RealDVD product is equipped with piracy protections that limits a DVD owner to making a single copy and is a legitimate way to back up copies of movies legally purchased. This legal battle began with a restraining order last October which stopped the sale of RealDVD. More coverage is available at NPR. The same judge who shut down Napster is presiding over the three-day trial." Reader IonOtter points out that later in the day, Judge Patel sealed the court after DVD Copy Control Association lawyers "argued that public testimony of aspects of the CSS copy-control technology would violate trade secrets."

AshboryBassPlayer writes "Ugobe has filed for Chapter 7 bankruptcy — i.e., not reorganization but liquidation. We first discussed the company's Pleo robotic dinosaur toy in 2006. According to the company, 100,000 Pleos were sold in 2008. CEO Caleb Chung is optimistic about the auction value of intellectual property that Ugobe holds. Pleo featured 14 servo joints, a camera, and an SD Card for storage. The final street prices were commonly between $275 and $350, much higher than an earlier hoped-for price point under $200."

stoolpigeon writes "Google has announced the now public beta for the Google Analytics API (described here). The API lets developers create client applications that can pull analytics data, to mash it up with other data or to present it in new ways. The API has been available through a private beta program for about a year, and some applications are already out there: examples include Polaris on Adobe Air and Analytics for Android."

An anonymous reader writes in with an opinion piece from ZDNet Australia. "Here's what the official press release won't tell you about Ubuntu 9.04, which formally hit the streets yesterday: its designers have polished the hell out of its user interface since the last release in October. Just like Microsoft has taken the blowtorch to Vista to produce the lightning-quick Windows 7, which so far runs well even on older hardware, Ubuntu has picked up its own game."

Al writes "Technology Review has a in-depth article about the anonymous networking software Tor and how it is helping dissidents spread information in oppressive regimes such as Syria, Zimbabwe and Mauritania, and opening up the unfiltered web for users in many more countries. In China, for instance, the computers found in some web cafes are configured to use Tor automatically. Interestingly, some police agencies even use the software to hide their activity from suspects. As filtering becomes ever more common in democratic countries such as the US, perhaps Tor (and similar tools such as I2P), will become even more valuable."

Anita Kuno writes "I suggested Head First Rails to a friend before I even finished it. He was asking me questions that I didn't have time to answer, and I knew the book could explain better than I. My friend is impatient, and I was uncertain what his experience would be. At first he was frustrated, but I assured him the answers were in the book. The incremental style of Head First Rails includes some exercises that are designed to fail to reinforce the learning process. I was confident that his answer would be found in the pages and he trusted me enough to go back and continue the exercises. He later told me he is very happy with the book and grateful that I suggested it." Read on for the rest of Anita's review. Head First Rails author David Griffiths pages 429 publisher O'Reilly rating 8/10 reviewer Anita Kuno ISBN 978-0-596-51577-5 summary An Introduction to Ruby on Rails

Rails is a framework for creating web applications. It is written in Ruby. It uses a structure called MVC which stands for model view controller. Rails separates tasks so that operations are modularized. Once a development team understands Rails, its use can increase the speed of creating web applications. Head First Rails explains the beginning steps needed to create Ruby on Rails applications. It introduces vocabulary; teaches the basic relationships that comprise Rails: the model, the view, and the controller; and demonstrates code creation that controls the MVC interaction. The title 'Head First Rails: A Learner's Companion to Ruby on Rails' describes the approach of the book. The author acknowledges that this book is one of many that will assist the active learner to begin Ruby on Rails. Proficiency in the Rails framework requires accumulating information from a number of sources and the book mentions quite a few and encourages consultation of those resources.

While previous Rails experience is not required (nor is previous Ruby experience) it is expected that the reader have a working understanding of HTML & CSS as well as a basic understanding of a scripting language. Java, C# or PHP are mentioned as scripting examples. I had tried several beginning Rails books previously and Head First Rails was the first I could complete. I feel it is a reflection of the speed of development of the framework and the fact that most of the people that I know involved with Rails are so busy creating apps, they don't have time to teach the n00bs.

Head First Rails assumes that you already have Rails installed on your system. The home page for Head First Rails provides a link to the download page at rubyonrails.org by way of providing installation instructions. I didn't see a reference in the book's index to Rails installation, which I find rather odd. It would be a simple matter to include a short paragraph explaining why detailed instructions aren't included with the book (as is explained on the home page for the book) with a URL to the book's homepage. Ruby and Rails are both opensource software so they are freely available for all systems.

Head First Rails has images, illustrations and graphics that are used to introduce and underscore one concept at at time. The book is designed so that each page and its facing page comprise an experience of one concept. As you turn each page you are introduced to a concept, given details and challenged in some form. When you turn the page you are on to the next piece of information which builds upon what you have already learned. The format of the book is designed to promote information retention and some of the exercises may prove frustrating at certain points. The frustration promotes original thinking and information retention. I feel it is a valuable part of learning. Since I rarely have the time to focus on a book exclusive to the rest of my life, I find the format helpful. I can attend to other things and pick up the book after two weeks and continue from where I left off. It is helpful to have access to information that I can pick up and put down and still accumulate knowledge.

Head First Rails is conversational and encourages original thought. The exercises, which are the foundation of the book, are accompanied by code samples for download to encourage comparison. The first time we dive into an app and edit the specific files, I felt that the identification of which file we were editing and how to locate the file in the Rails application directory tree needed to be clarified a little better. Soon the examples fell into a rhythm and I knew where to find the information I needed.

One thing that did get my attention was the use of whitespace or lack thereof in code. I have been taught to use 2 spaces to indent Ruby code (which affects Rails code as well) and while the code samples did use the convention, I didn't see the indent by 2 spaces rule explicitly stated. I'm not confident that a n00b would just pick that up. They would probably have to be informed. My other whitespace comment concerns hashes. I have been taught to have one space between the key and hash delimiter and another single space between the hash delimiter and the value. I did not see this in the code samples. I frequently saw no space whatsoever separating the key, delimiter and value. I have come to understand that developers rate another developer's worth based upon code samples, and lack of whitespace when it is expected is viewed as a bad habit. The composer of said code might be either chastised or dismissed due to poor technique. Perhaps my understanding of the situation is extreme but again in a book for n00bs, the reader will copy exactly what they see. So if there isn't whitespace on either side of the hash delimiter in the book, how will the reader know to compose code using that convention?

A few of the author's terms were confusing. He uses the term 'scriptlets' to refer to ERB output tags, and 'expressions' to refer to ERB expression tags. The Rails developers I questioned about this were able to figure out what he meant by 'expressions' but none of them had ever heard of ERB output tags being called 'scriptlets'. Also, the author uses 'finder' to refer to dynamic finders and I think it would have been useful to use the term 'dynamic finder'. It is more specific and the keyword 'dynamic' is useful when employing a search engine to research the functionality of dynamic finders. A search for 'finders' doesn't return one Rails related hit on the first page, while a search for 'dynamic finders' gives me a Rails related hit as the first return.

These are small points and perhaps this is more reflective of the culture of Rails developers that informs me, but in a n00b book it is important to provide clear vocabulary and conventions. These small points may be the techniques that have the longest shelf life to the reader.

I have been waiting for this book to be written and available for at least a year and a half. This was the first beginning Rails book that I found that didn't assume I was transitioning from a background in PHP. I have been spending time with the Ruby and the Rails community for close to 2 years now and am grateful that I finally have an explanation of the topic that is accessible for me.

Rails is changing very quickly and even now is about to merge with Merb to create Rails 3.0. It is tough to say how long the information in Head First Rails will be relevant. If you are interested in this book because you think Rails is fashionable, you might be distracted by a new trend before you finish the book. If you are interested in Rails because you have seen what it can do, you recognize its power and you want to learn how to get that for yourself, you will recognize the value in these pages.

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

Anita Kuno writes "I suggested Head First Rails to a friend before I even finished it. He was asking me questions that I didn't have time to answer, and I knew the book could explain better than I. My friend is impatient, and I was uncertain what his experience would be. At first he was frustrated, but I assured him the answers were in the book. The incremental style of Head First Rails includes some exercises that are designed to fail to reinforce the learning process. I was confident that his answer would be found in the pages and he trusted me enough to go back and continue the exercises. He later told me he is very happy with the book and grateful that I suggested it." Read on for the rest of Anita's review. Head First Rails author David Griffiths pages 429 publisher O'Reilly rating 8/10 reviewer Anita Kuno ISBN 978-0-596-51577-5 summary An Introduction to Ruby on Rails

Rails is a framework for creating web applications. It is written in Ruby. It uses a structure called MVC which stands for model view controller. Rails separates tasks so that operations are modularized. Once a development team understands Rails, its use can increase the speed of creating web applications. Head First Rails explains the beginning steps needed to create Ruby on Rails applications. It introduces vocabulary; teaches the basic relationships that comprise Rails: the model, the view, and the controller; and demonstrates code creation that controls the MVC interaction. The title 'Head First Rails: A Learner's Companion to Ruby on Rails' describes the approach of the book. The author acknowledges that this book is one of many that will assist the active learner to begin Ruby on Rails. Proficiency in the Rails framework requires accumulating information from a number of sources and the book mentions quite a few and encourages consultation of those resources.

While previous Rails experience is not required (nor is previous Ruby experience) it is expected that the reader have a working understanding of HTML & CSS as well as a basic understanding of a scripting language. Java, C# or PHP are mentioned as scripting examples. I had tried several beginning Rails books previously and Head First Rails was the first I could complete. I feel it is a reflection of the speed of development of the framework and the fact that most of the people that I know involved with Rails are so busy creating apps, they don't have time to teach the n00bs.

Head First Rails assumes that you already have Rails installed on your system. The home page for Head First Rails provides a link to the download page at rubyonrails.org by way of providing installation instructions. I didn't see a reference in the book's index to Rails installation, which I find rather odd. It would be a simple matter to include a short paragraph explaining why detailed instructions aren't included with the book (as is explained on the home page for the book) with a URL to the book's homepage. Ruby and Rails are both opensource software so they are freely available for all systems.

Head First Rails has images, illustrations and graphics that are used to introduce and underscore one concept at at time. The book is designed so that each page and its facing page comprise an experience of one concept. As you turn each page you are introduced to a concept, given details and challenged in some form. When you turn the page you are on to the next piece of information which builds upon what you have already learned. The format of the book is designed to promote information retention and some of the exercises may prove frustrating at certain points. The frustration promotes original thinking and information retention. I feel it is a valuable part of learning. Since I rarely have the time to focus on a book exclusive to the rest of my life, I find the format helpful. I can attend to other things and pick up the book after two weeks and continue from where I left off. It is helpful to have access to information that I can pick up and put down and still accumulate knowledge.

Head First Rails is conversational and encourages original thought. The exercises, which are the foundation of the book, are accompanied by code samples for download to encourage comparison. The first time we dive into an app and edit the specific files, I felt that the identification of which file we were editing and how to locate the file in the Rails application directory tree needed to be clarified a little better. Soon the examples fell into a rhythm and I knew where to find the information I needed.

One thing that did get my attention was the use of whitespace or lack thereof in code. I have been taught to use 2 spaces to indent Ruby code (which affects Rails code as well) and while the code samples did use the convention, I didn't see the indent by 2 spaces rule explicitly stated. I'm not confident that a n00b would just pick that up. They would probably have to be informed. My other whitespace comment concerns hashes. I have been taught to have one space between the key and hash delimiter and another single space between the hash delimiter and the value. I did not see this in the code samples. I frequently saw no space whatsoever separating the key, delimiter and value. I have come to understand that developers rate another developer's worth based upon code samples, and lack of whitespace when it is expected is viewed as a bad habit. The composer of said code might be either chastised or dismissed due to poor technique. Perhaps my understanding of the situation is extreme but again in a book for n00bs, the reader will copy exactly what they see. So if there isn't whitespace on either side of the hash delimiter in the book, how will the reader know to compose code using that convention?

A few of the author's terms were confusing. He uses the term 'scriptlets' to refer to ERB output tags, and 'expressions' to refer to ERB expression tags. The Rails developers I questioned about this were able to figure out what he meant by 'expressions' but none of them had ever heard of ERB output tags being called 'scriptlets'. Also, the author uses 'finder' to refer to dynamic finders and I think it would have been useful to use the term 'dynamic finder'. It is more specific and the keyword 'dynamic' is useful when employing a search engine to research the functionality of dynamic finders. A search for 'finders' doesn't return one Rails related hit on the first page, while a search for 'dynamic finders' gives me a Rails related hit as the first return.

These are small points and perhaps this is more reflective of the culture of Rails developers that informs me, but in a n00b book it is important to provide clear vocabulary and conventions. These small points may be the techniques that have the longest shelf life to the reader.

I have been waiting for this book to be written and available for at least a year and a half. This was the first beginning Rails book that I found that didn't assume I was transitioning from a background in PHP. I have been spending time with the Ruby and the Rails community for close to 2 years now and am grateful that I finally have an explanation of the topic that is accessible for me.

Rails is changing very quickly and even now is about to merge with Merb to create Rails 3.0. It is tough to say how long the information in Head First Rails will be relevant. If you are interested in this book because you think Rails is fashionable, you might be distracted by a new trend before you finish the book. If you are interested in Rails because you have seen what it can do, you recognize its power and you want to learn how to get that for yourself, you will recognize the value in these pages.

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

Combat Wombat brings news that the legal battle between the Australian Commonwealth Scientific and Research Organisation (CSIRO) and a host of major tech corporations has come to end, with a large settlement going to the CSIRO. The fight was over a patent on wireless LAN technology, which already earned the CSIRO a victory in court over Buffalo Technology and a settlement with Hewlett-Packard. The remaining 13 companies, which include Dell, Intel, Microsoft and Nintendo, have now chosen to settle as well. "[The CSIRO] will use the money won from a Wi-Fi technology patent battle to fund further research. ... It is unclear how much money has flowed to the CSIRO, but experts say the technology would be worth billions of dollars if royalties were paid on an ongoing basis."

Combat Wombat brings news that the legal battle between the Australian Commonwealth Scientific and Research Organisation (CSIRO) and a host of major tech corporations has come to end, with a large settlement going to the CSIRO. The fight was over a patent on wireless LAN technology, which already earned the CSIRO a victory in court over Buffalo Technology and a settlement with Hewlett-Packard. The remaining 13 companies, which include Dell, Intel, Microsoft and Nintendo, have now chosen to settle as well. "[The CSIRO] will use the money won from a Wi-Fi technology patent battle to fund further research. ... It is unclear how much money has flowed to the CSIRO, but experts say the technology would be worth billions of dollars if royalties were paid on an ongoing basis."

jabjoe writes "Groklaw is highlighting a new document from the European Committee for Interoperable Systems (PDF) about the history of Microsoft's anti-competitive behavior. Quoting: 'ECIS has written it in support of the EU Commission's recent preliminary findings, on January 15, 2009, that Microsoft violated antitrust law by tying IE to Windows. It is, to the best of my knowledge, the first time that the issue of Microsoft's patent threats against Linux have been framed in a context of anti-competitive conduct.' The report itself contains interesting quotes, like this one from Microsoft's Thomas Reardon: '[W]e should just quietly grow j++ share and assume that people will take more advantage of our classes without ever realizing they are building win32-only java apps.' It also has the Gates 1998 Deposition."

An anonymous reader sends word of a new cybersecurity project to defend US networks from attacks and strengthen the government's "offensive capabilities in cyberwarfare." Right now, the most likely candidate to lead the project is the Director of the NSA, Keith Alexander, who was quick to assert that the NSA itself wouldn't try to run the whole show (something they've been criticized for in the past). Quoting the Wall Street Journal: "Cyber defense is the Department of Homeland Security's responsibility, so the command would be charged with assisting that department's defense efforts. The relationship would be similar to the way Northern Command supports Homeland Security with rescue capabilities in natural disasters. The NSA, where much of the government's cybersecurity expertise is housed, established a similar relationship with Homeland Security through a cybersecurity initiative that the Bush administration began in its final year."

iago-vL writes "Despite having their domain blacklisted by Conficker, the folks at Nmap have released version 4.85BETA8, which promises better detection of the Conficker worm. How? By talking to it on its own peer-to-peer network! By sending encrypted messages to a suspect host, the tools will get Conficker.C and higher to reveal itself. This curious case of using Conficker's own tricks to find it is similar to the last method that we discussed. More information from the author is available, as well as a download for the new release (or, if you're a Conficker refugee, try a mirror instead)."

schnucki brings word of new research which claims roughly one in twelve American children between the ages of eight and 18 are "pathologically addicted" to video games. The study, conducted by Douglas Gentile, director of the National Institute on Media and the Family at Iowa State University, says that "pathological status was a significant predictor of poorer school performance even after controlling for sex, age, and weekly amount of video-game play." However, Professor Cheryl Olson, who has conducted her own research into video game use, questioned Gentile's methodology, saying, "The author is repurposing questions used to assess problem gambling in adults; however, lying to your spouse about blowing the rent money on gambling is a very different matter from fibbing to your mom about whether you played video games instead of starting your homework."

eldavojohn writes "Jack Thompson was disbarred last year in Florida, putting a halt to annoying lawsuits targeting game makers and the constitutional rights of gamers. Well, he had appealed to the United States Supreme Court (scheduled to be heard last Friday) to get this overturned, but instead they declined to even hear his appeal. They wouldn't even give him the time to review his appeal, so it appears his disbarment for life stands. Florida had declined to file a response to Thompson's appeal, and it turns out they didn't need to. Sad day for Jack Thompson, but a great day for gamers everywhere." This comes shortly after Thompson was frustrated by the vetoing of some legislation he promoted in Utah.

eldavojohn writes "Jack Thompson was disbarred last year in Florida, putting a halt to annoying lawsuits targeting game makers and the constitutional rights of gamers. Well, he had appealed to the United States Supreme Court (scheduled to be heard last Friday) to get this overturned, but instead they declined to even hear his appeal. They wouldn't even give him the time to review his appeal, so it appears his disbarment for life stands. Florida had declined to file a response to Thompson's appeal, and it turns out they didn't need to. Sad day for Jack Thompson, but a great day for gamers everywhere." This comes shortly after Thompson was frustrated by the vetoing of some legislation he promoted in Utah.