Gregarius » BetaNews.Com » septembre 21, 2009

BetaNews.Com (9 non lus)

Five reasons why Google's Jaiku is more boring than Twitter

Publié: septembre 21, 2009, 11:42pm CEST par Tim Conneally
By Tim Conneally, Betanews

The Helsinki Institute for Information Technology (HIIT) today announced the impending publication of the results of its microblogging study. In a peek forward, the Institute revealed that most respondents using Google-owned "lifecasting" service Jaiku are either very bland, or are not using the service properly.
According to the Institute, the five most common status updates on the service are:
- "Working"
- "Home"
- "Work
- "Lunch"
- "Sleeping"
Extremely mundane stuff, not exactly the kind of content that would attract tons of new users to the service.
Your first question might be: Why did they study Jaiku and not Twitter, a perceptibly larger service capable of a much larger data set? One word: Finnish. Since the study was conducted in Helsinki, the same city where Jaiku was founded, the fit is natural.
The userbase of Jaiku has not been publicly disclosed, but the site's traffic versus Twitter's is pitiful at best. Compete.com says that Twitter had 23.5 million unique visitors during the month of August while Jaiku had only 36,610.
Furthermore, the Institute's study found that most of the traffic on Google's version of Twitter is driven by "a small supercore of the Jaiku population," which receives over 50% of the site's comments.
The question remains: Why did Google even buy Jaiku? In 2007, the MIT Technology Review took the Jaiku purchase as a signal of the eventual "Google Phone". However, the microblog was not ported over to an Android app at the operating system's launch, and still hasn't been.
Instead, Google moved Jaiku to its hosted development environment Google App Engine and open-sourced its development. The service's SMS integration was discontinued in June in the US, and was replaced with a mobile Web site.
While even Twitter, the most successful microblogging service by a country mile, suffered from poor engagement with new users, Jaiku managed to earn the reputation for being even less user friendly.
Now it's got a study backed by the Helsinki Institute for Information Technology that says its content is boring.
Copyright Betanews, Inc. 2009
For AMD, keeping it too simple may be too stupid

Publié: septembre 21, 2009, 10:59pm CEST par Carmi Levy

By Carmi Levy, Betanews

The "Keep It Simple, Stupid" rule works in business as well as in everyday life, primarily because it forces us to focus on the one or two basic issues we need to make the right decision. My kindergarten teacher shortened it to "KISS," perhaps in the interest of simplicity. When you're driving a car: Know where you are, know where you're going. Leader of the free world: Keep your hands clean, know what you're aiming at. Reprogramming your iPod/in-vehicle audio system interface: Pull over, let the semi pass you.
More data, please
The computer market never got the memo -- or if it did, maybe no one could make sense of it. This is a good thing, though, because when you're investing in a technology, more data is always preferable to less. Whatever parameters you're measuring -- processor architectures and speeds, types of memory, hard drive spin velocities and capacities, or display resolutions and refresh rates -- the more you know about what's going on under the hood, the more likely you are to make a sensible buying decision that you can live and work with.
Now all of a sudden, AMD wants to dumb this process down because some people find it too confusing. And that scares me more than a little. The company's just-announced Vision program aims to replace the information-stuffed process of buying a computer with one based on three categories: Vision, Vision Premium, and Vision Ultimate, each of which corresponds to a particular end user need. Plain old Vision machines define the low end, and will do the trick for Web browsers and basic game players. Vision Premium might be suitable for gamers interested in something more challenging than Solitaire or Sudoku, as well as HD video. Vision Ultimate addresses the most demanding gamers and content creators. Early next year, Vision Black-based machines that target high-end users will join the party.
There's an eerie resemblance here to "Vista Premium" and "Vista Ultimate," but I suppose AMD didn't get that memo, either.
A slightly blurred vision
After a generation of PC marketing being driven by and targeted at technically inclined folks who used the often arcane parameters of hardware capability to measure bottom line performance and calculate value propositions, my mother-in-law is now calling the shots. If AMD's strategy plays out, consumers who don't understand the difference between level 2 and level 3 cache will now find it easier to choose the right solution.
I get that. I've seen my mother-in-law's eyes glaze over when I try to explain the benefits of 7,200 RPM drives versus 5,400 RPM ones. She doesn't much care that a quad-core processor lets her edit photos and video more smoothly than a dual-core one, and she wishes I'd stop trying to get her to upgrade her webcam from her current, lame VGA device that washes out in the low light of her home office to an HD-capable one that doesn't make her and my father-in-law look like stop action ghosts. While I quote numbers to illustrate the benefits, she waits for Wal-Mart to drop the price on a cheap machine she'd like to install in the kitchen.
What about the rest of us?
So she'll appreciate AMD's gesture. It's the rest of the world I'm worried about. Taken to its ultimate extreme, simplified computers will make it virtually impossible to make real, side-by-side comparisons. Want to know if $699 is too much? Tough. No longer will savvy customers be able to laugh off the know-it-all salesperson's claim that no one else can match their price. How can you appreciate a product's capabilities when its basic guts are deliberately hidden from view? Simplified marketing may make life easier for the uninitiated, but does the message have to be so diluted that folks with more than a little knowledge can't dig a little bit deeper on their own?
When otherwise educated customers are forced to buy based on vague notions of role- or task-matched performance, the entire process begins to look suspiciously like the one from the most recent silent auction at my children's school. In amongst the various items up for bids -- the gift certificates, logoed clothing, and small electronics -- was an envelope with a single word printed neatly across the seal: "Surprise." Based on similar experiences from past years, there was an even chance that the envelope contained a booby prize, such as a yellowed old bumper sticker or a collection of discarded scripts from last year's school play. Well-meaning parents, hoping this was a non-booby-prize year, nevertheless bid the mystery envelope up to $50 before the night ended, and ended up with a $25 gift certificate at a local coffee shop for their donation.
I'd hardly expect someone laying down hundreds or thousands of dollars at a profit-seeking technology store would be as understanding as these involved parents were. If the recession has taught us anything, it's the value of a dollar. Computers are not sold in sealed envelopes, and customers aren't supposed to guess, even vaguely, at what might be inside.
A better kind of simple
Intel already gets the message. While it arguably kicked off the simplification parade with the Centrino brand, and has been gradually moving away from feeds and speeds ever since, shoppers who understand GHz and Gbps can still pull out info sheets at the store and geek out to their heart's content. To its credit, Intel recognizes that today's PC buyers come in all sorts of shapes, sizes, and levels of knowledge. And a one-size-fits-all, universally-simplified marketing strategy fails to give the tech-savvy buyer sufficient background to make the right decision.
I appreciate why AMD is going simple. Data released last week by iSuppli shows its market share down by 1.4% to 11.5%, while Intel's is up by 1.5% to 80.6% -- its highest since 2005. Companies in decline need to do radical things to change their fortunes. But ticking off the large percentage of the market that still has a clue isn't a great way to start. Even my kindergarten teacher would agree.
Carmi Levy is a Canadian-based independent technology analyst and journalist still trying to live down his past life leading help desks and managing projects for large financial services organizations. He comments extensively in a wide range of media, and works closely with clients to help them leverage technology and social media tools and processes to drive their business.
Copyright Betanews, Inc. 2009
The EC's charges: Did Intel really threaten Dell if it shifted toward AMD?

Publié: septembre 21, 2009, 9:51pm CEST par Scott M. Fulton, III

By Scott M. Fulton, III, Betanews

If the European Commission's antitrust case against Intel seemed completely clear and convincing up to now, this morning's publication of its formal provisional explanation of its charges (PDF available here) -- actually delivered last May 13 but only made public today -- muddies the waters somewhat. For while there is indeed some smoke, and certain excerpts would imply the existence of a gun from which the smoke emanated, the presence of far more smoke from various other sources not only un-resolves some questions, but adds some new ones to the mix.
Most surprising of all is the EC's explanation of rebates Intel allegedly provided to Dell Computer in exchange for limited exclusivity, the existence of which has actually not been denied. A thorough read of the evidence explained by the Commission reveals that the rebate program was apparently conceived by Dell, not Intel. And although e-mails between redacted Dell executives did warn of possible retributions by Intel had their deal not been kept as promised, those same e-mails indicate Dell had other reasons of their own to pursue exclusivity.
Though Dell had originally sold PCs with Intel CPUs exclusively since its founding, it started considering adopting some AMD chips as far back as 2002, according to Dell evidence cited by the EC. During this time, Intel typically sold CPUs to its OEM customers for a category of prices it called "Customer Authorized Price" -- essentially a way of dressing up its typical prices to look as though customers deserved and earned them. Still, big customers negotiated discounts; and at the time, Dell was the biggest one. Intel admitted that its biggest customers tended to negotiate "discounts" (why wouldn't they?); though some internal documents apparently referred to the earliest proposed forms of these discounts as "rebates."
When Dell and Intel did settle on a name for these discounts, they were called the Dell Meet Competition Program ("meet-comp," or MCP). Essentially, it enabled Dell to execute certain flexible pricing terms that it could specify, provided that it met certain sales goals. Although the goals themselves were redacted from the EC's published document, it appears Dell was the one specifying what the goals were, at least in initial negotiations.
"Intel specifies that the [name of program redacted] MCP program was designed 'to enable Dell to respond to unexpected marketplace conditions with enhanced flexibility,'" cites the EC's provisional statement, quoting evidence provided by Intel. A separate citation from Dell's evidence is described thus: "Dell negotiated with Intel that a small portion of the MCP discount could vary based on Dell's success in meeting specific criteria negotiated on a quarterly basis."
Here, Dell referred to the benefits it received from Intel as "discounts;" but from time to time in its own citations, it referred to them interchangeably as "rebates."
As Dell began seriously examining including AMD processors in its product mixes, beginning with an evaluation of its server processors in December 2002, its accountants considered the potential future impact of introducing AMD into its product line. According to Dell evidence cited by the EC, it was during a private Dell executives' presentation that month that the effects of a hypothetical Intel retaliation were first considered. Executives whose names were redacted from the public EC document considered Dell data suggesting that Intel could retaliate against a Dell pick-up of AMD-based equipment by providing competitive discounts, or rebates, to competitors (their names were also redacted). Those discounts could be executed by Intel in the interest of maintaining the balance of its market share.
The following February, another internal Dell presentation made the point, according to Dell evidence, that "Retaliatory [redacted] could be severe and prolonged with impact to all LOBs [Lines of Business]." And the next month, another: "Anticipated Intel response wipes out all potential [redacted] upside from going with AMD."
These collective presentations apparently drove home their point to a Dell senior executive, whose name here was also removed. In an analysis memo directed toward other senior executives, this person stated, "Bottom line is that I don't see how we make AMD a positive for Dell. The end game is inevitable, the cost to support AMD is high, […], and the net loss of MCP will far outweigh any gain we get by doing a limited toe-dip with a couple of server platforms."
Most noteworthy about this citation is the phrase "the cost to support AMD is high," which seems to come out of the blue. If Dell also estimated the cost to upgrade and improve its customer support services for the addition of AMD-based processors to the line (a reasonable assumption), the EC did not provide any evidence of it.
Next: Can Intel be held responsible for Dell's assumptions?
Similar conclusions about Intel's possible retaliation were drawn by Dell for over three years, according to a plurality of e-mails cited by the EC. But a statement from Dell to the European Commission on precisely this subject actually begins with the following two words: "Dell assumed."
"Dell assumed that shifting some purchases to AMD would result in a reduction of MCP. But Dell did not know precisely how much MCP would decline, in what manner and over what time period. Dell understood that Intel would not welcome such a decision, as it would be viewed as a significant shift in the historical relationship between the companies," Dell told the EC. "As indicated in the documents, the Dell team sought to forecast this negative impact across a range of potential scenarios, including some which predicted a substantial reduction in MCP, and did not rule out the possibility that such reduction might be disproportionate to the reduction in the volume of Dell's purchases from Intel."
At some point in time, Intel did pick up on Dell's conclusions, and started leveraging its own assessed fears of its retaliations to its own advantage, according to Intel internal e-mails cited by the EC. For one dinner meeting (presumably at or near Dell's Round Rock, Texas headquarters), an Intel representative was advised thus: "Somehow, with finesse, we need [Dell Senior Executive] to understand that if Dell adds AMD to their product line they no longer have a meet-comp exposure -- We have a meet comp exposure so we must prioritize opportunities on a case by case situation."
But that meeting took place in January 2003. What the EC characterizes as Dell's response to that meeting actually came (if you read the dates) over three years later, in February 2006, when as the EC describes it, Dell made statements to the press indicating that it would continue its exclusivity arrangement with Intel. The EC cited Intel's response to those press reports as though it had hit the jackpot, with one Intel exec writing to another that Dell's news constituted "the best friend money can buy."
However, I was one of the reporters at the time to whom Dell was talking about Intel exclusivity, and that's not what I was told. In fact, Dell announced its Opteron partnership with AMD in May 2005, in an event for which I was briefed by both Dell and AMD. Also, I was being prepared for a conference including several tech reporters, including myself, with Chairman Michael Dell personally. There he told me and my counterparts exactly the opposite news: that Dell was actively considering AMD for consumer PCs, in addition to the server PC deal announced the previous month.
In fact, the stories that had been published elsewhere (which the Intel executives apparently believed), were wrong, as my then-colleague Wolfgang Gruener and I accurately reported for TG Daily. However, the EC's evidence specifically points to the Intel executives' response to the incorrect news report from elsewhere, saying, "This demonstrates the direct link between Dell's policy of Intel exclusivity and Intel payments."
The EC does cite Intel's objection that its case as presented "does not legitimately support an inference of an exclusivity agreement between Intel and Dell." The alleged lack of evidence was responded to by the EC in a press release this morning, which alleged that such a gap constituted "concealment." That press release construed the alleged concealment as helping Intel to "conceal the conditions in its arrangements with PC manufacturers and Media Saturn Holdings," the German retailer that sold Intel PCs and parts exclusively for several years. However, the actual EC provisional statement makes no such allegation tying Dell to MSH -- these are actually two separate affairs. The provisional statement does take Intel and Dell both to task for failing to keep minutes of their meetings during which their MCP rates were negotiated. "Dell also makes clear that there is no complete written agreement outlining the terms of the MCP," the statement reads.
Intel has alleged that the European Commission may be either withholding, or actively refusing to seek, evidence that may be exculpatory towards Intel. This includes documents uncovered in its ongoing civil trial in Delaware, plus evidence that should have been uncovered during a meeting between EC representatives and apparently the same Dell senior executives whose names were redacted from their memos.
But in its defense, the Commission argues that it doesn't have to take notes: "Intel's arguments are misconceived. In the first instance, there is no general obligation for the Commission to take minutes of meetings," it writes. It goes on to cite European case law: "There is…no general duty on the part of the Commission to draw up minutes of discussions in meetings or telephone conversations with the complainants which take place in the course of the application of the Treaty [of the European Community]'s competition rules."
The EC's statement on its decision also went into detail regarding Intel's alleged dealings with the aforementioned Media Saturn franchise, and with Hewlett-Packard.
Copyright Betanews, Inc. 2009
Like HP, Dell also acquires a Perot empire for enterprise services

Publié: septembre 21, 2009, 8:09pm CEST par Tim Conneally

By Tim Conneally, Betanews

Though Dell has extended its brand to consumer electronics of all sorts, the company's latest drive is straight into enterprise services, a segment of the IT market which has helped HP retain a competitive edge on Dell in hardware sales.
Today, Dell announced it will be acquiring Perot Systems in a $3.9 billion all-cash transaction expected to be completed in January.
"We've really been transforming Dell in a number of ways," CEO Michael Dell told CNBC this morning. "One of the ways we're doing that is by becoming a solutions integrator, providing the best value solutions to help companies run a very efficient enterprise architecture...and the addition of the Perot Systems team here will really allow us to extend that to a much broader set of customers."
Indeed, in the last year and a half, Dell has grown its IT services portfolio by acquiring IP Storage Area Network company EqualLogic, and then later enterprise e-mail service company MessageOne. This morning, Michael Dell said the market for services like those from EqualLogic has grown more than four times in just over a year.
With the addition of Perot Systems, Dell is expanding its IT consulting business; and the company today said this acquisition will let Dell offer a broader range of IT services and solutions by optimizing how they're delivered, extend Perot Systems' capabilities and customer segments, and supply Dell systems to more Perot customers.
This is important to note because nearly 80% of Dell's revenue comes from enterprise hardware sales; and the company will need a diversified revenue stream to outgrow chief competitor HP.
HP, currently the world's leading computer manufacturer, made a similar acquisition last year when it picked up EDS for $13 billion. EDS was founded in 1962 by none other than H. Ross Perot, who 26 years later founded Perot systems in the very same town of Plano, Texas.
Copyright Betanews, Inc. 2009
Justice Dept.: What right does Google have to e-book exclusivity?

Publié: septembre 21, 2009, 7:42pm CEST par Scott M. Fulton, III

By Scott M. Fulton, III, Betanews

In a court filing that seriously jeopardizes a proposed settlement of the e-book publishing dispute between Google and members of the Authors Guild and other publishing groups, the US Dept. of Justice has raised serious allegations that the settlement as it stands now may violate the country's antitrust law. The keyword here is "may," as that final determination "may" be up to a judge.
The main problem is this: Google would like to be able to electronically publish a wide variety of titles, including out-of-print works whose publishers or former rights holders may not even exist anymore. The keyword here is still "may." The settlement as proposed is clearly between those publishers that do exist and Google; but can Google necessarily claim the right to unilaterally assume that all those who didn't respond, aren't necessarily present?
Silence has never implied consent before, and this time is no exception, claim DOJ attorneys in a court filing last Friday. What's more, Google may not have the exclusive right to claim just what it has the exclusive right to, if no one else claims it first.
"The rights conferred are so amorphous and malleable," the attorneys write, "that it is difficult to see how any class representative could adequately represent the interests of all owners of out-of-print works (including orphan works). The parties appear willing to address this problem by limiting the future rights that may be controlled by the Registry and Google."
The "Registry" to which the attorneys refer is an independent database of out-of-print titles, to be maintained and operated by an as-yet-undetermined source separate from Google. The government officially supports this aspect of the settlement, at least as an ideal. But since print publishing through the centuries hasn't used such registries historically (imagine a comprehensive list of everything we don't know about), it's essentially impossible to determine for fact, the attorneys argue, which works are officially "orphans." "One goal of the settlement -- making large numbers of copyrighted works available to the public in electronic form while providing compensation to authors and publishers -- is a public benefit that, to date, has not come to pass due to certain realities of the copyright system, including, for example, the fact that copyright owners are not required to formally register or otherwise assert their ownership," writes the DOJ.
It's all a bit of a conundrum, but the results are plain and simple, they argue: For the government to agree to the settlement, it would need to ask all parties whether it's acceptable; and "all parties" in this instance would imply that somebody, somewhere, represents the interests of rights holders for orphan books. That's not exactly like saying that dead people need to be alive to have their cases heard; there are matters of something called "estates." Who knows just what types of injuries or infringements these estates would claim, if they could?
No one, says the government, citing a Supreme Court case involving a class-action settlement proposal that was supposed to benefit individuals who may have been exposed to asbestos at work, but who hadn't filed claims yet because they hadn't shown symptoms yet. On the surface, it would be nice to save them some money and settle on their behalf for the sake of their future; on the other, you can't make up the amount of that settlement out of thin air.
In such cases, the attorneys wrote, "the courts have cast doubt on the circumstances in which class representatives could adequately represent absent class members with respect to as-yet uncertain injuries or rights that were far removed from the facts underlying the complaint."
And what constitutes a "symptom" in the case of rights holders of orphaned works who may not know their rights today, but discover them in the future after Google has already scanned and published their books online? The settlement as proposed guarantees the existing rights holders the right to prohibit Google from scanning and publishing their works. That's a little different than setting aside some cash; in this case, an orphaned works claimant can't exactly prohibit Google from putting on the Internet something that's already there.
The government's other problem with the proposed settlement is that it would enable Google to negotiate with the existing rights holders for a fair price. Depending on how the market is structured at the time, that could constitute collusion under existing anti-trust laws, which would prefer that rights holders name their prices and that Google (and every other e-publisher in the market) accept them at face value. On the other hand, should Google wish to provide e-books at a discount, the settlement would have Google negotiate with rights holders to do this -- which the DOJ says is unfair to Google. A physical book retailer has the right to offer discounts without making deals with publishers; Google should have that same right, says the DOJ.
So the settlement as proposed may be contrary to current antitrust laws, but in so many contrary respects to one another as to not favor one side or the other as the "trust" in this situation. No matter: The DOJ still recommends that US District Court reject the settlement.
Copyright Betanews, Inc. 2009
Preview of Windows 7 netbooks, PCs from Asus, Samsung, and ViewSonic

Publié: septembre 21, 2009, 5:58pm CEST par Jacqueline Emigh

By Jacqueline Emigh, Betanews

In a flashback to the more prosperous years before the current "deep recession," hordes of truly enthused journalists crowded dozens of vendors' booths at a revitalized Pepcom pre-holiday event in New York City last week, waiting for their turns to get up close and personal with forthcoming consumer electronics wares.
ViewSonic, a company known until now mostly for its monitors, introduced a total of four new PCs at Pepcom's press event Thursday night.
The ViewSonic entries include the Windows XP-driven All-in-One PC VPC100 (shown above), plus three Windows 7 systems: the 13-inch ViewBook Pro VNB131 notebook; 10-inch ViewBook VNB102 netbook; and PC mini VOT132 (below), an Intel Dual Core Atom 330 processor-based mini-netbook aimed at serving as the centerpiece for building your own all-in-one system.
ViewSonic's 10-inch VNB102 wraps an Atom N270 CPU, 1 GB of RAM and a 160 GB hard drive in a traditional netbook form factor, for $349 with a three-cell battery or $399 for a six-cell version.
Also in its bustling booth, ViewSonic showed off two new palm-sized MovieBooks for playing back movies on a 4.3-or 5-inch screen while you're on the go.
For its part, Samsung gave its first US look at two more Windows 7 netbooks: the N140, a 10.1-inch, 2.8-pound replacement for the NC10, touted as raising battery life from five hours to 11 hours; and the N510, an 11.6-inch device featuring an HDMI port, along with an Nvidia Ion graphics chip for running high-definition movies and 3D games.
Slated for US shipment in November, the N140 will run Windows 7 Starter Edition while the N510 will run Windows 7 Home Premium Edition, said Jason B. Redmond, a senior manager at Samsung for marketing communications. The N140 will come in both black and burgundy flavors.
Redmond told Betanews that Samsung will also update its existing Go netbooks, first rolled out last summer, with both 3G wireless and Windows 7 Starter Edition following Microsoft's launch of Win7 on October 22.
Asus made the first public display anywhere of its already announced 14-inch UL80V ultraportable and 16-inch N61Vg multimedia notebooks, along with its 20-inch EeeTop ET2002 HD entertainment center and two new netbooks: the 8.9-inch Disney Netpal for kids and the 10.1-inch Eee PC 1008HA Seashell.
Although the Asus notebooks were outfitted with Windows 7, the Disney Netpal still sported Windows XP. In sort of a proof-of-concept, though, Asus installed Windows 7 on the Seashell just for the Pepcom event, to show that the new OS will work on a netbook.
Josh Norem, senior technical marketing specialist at Asus, told Betanews that all of Asus' recently announced notebooks and netbooks will be running Windows 7 by the November time frame.
He hedged a bit, however, when asked about other future products from Asus, perhaps in reaction to press leaks of an Asus product roadmap, widely circulated a few weeks ago.
Will Asus release additional Windows 7 products in November? "Probably," Norem answered on Thursday. Are any more Linux netbooks on Asus' drawing boards? "Not at this time," he replied.
As for the revamped Skype video phone, a major update to the "industry first" announced at a Pepcom event last year, the new and more streamlined unit -- known as the AiGuru SV1T -- features a touch screen and other enhancements for much easier dialing and navigation.
Norem said Asus is targeting its latest desktop VoIP videophone at senior citizens and others who are daunted at the thought of making Skype calls on a PC. The phone runs its own WebOS, produced by Asus, according to Norem.
Meanwhile, other vendors, including Lenovo have also been pre-announcing Windows 7 PCs over the past month or so.
As sort of a counterpoint to the Windows 7 frenzy, HTC gave hands-on demos in New York City on Thursday of the Hero, an Android phone set for release by Sprint in October. But will the new consumer electronics products -- whether Windows 7- or Android-driven -- stimulate consumer spending enough this holiday season to give the economy a significant jolt? No doubt we could all use a little Christmas this Christmas.
Copyright Betanews, Inc. 2009
All-new test results: What browser will you use to run Web apps?

Publié: septembre 21, 2009, 5:34pm CEST par Scott M. Fulton, III
By Scott M. Fulton, III, Betanews

Three laptop computers, all of them cool-looking, all with well-respected brands, all have the features you want, all sell for the same price. This isn't going to be a toy for you; it will be, for at least the next few years, the engine for your work and your livelihood. How do you make a purchasing decision? You check online to see which one is the better performer, and which one other customers prefer.
Five Web browsers, all of them cool-looking, all with well-respected brands, all have the features you want, all of them...are free. But this isn't going to be a newspaper reader or a Twitter feed carrier for you; it will be, for at least the next few weeks, the engine for your work and your productivity. Sure, you'll install all of them. But which one will you install as your default, and which one will you trust with your everyday applications?
Click here for a complete introduction to the Betanews Comprehensive Performance Index.
When the everyday functionality of Microsoft Office moves to the Web, and PCs are sold not with Office installed but with desktop shortcuts to Office Web Apps instead, and when the applications you run depend on the Web browser you choose, the decision you make about Web browsers will be more important than ever before. If you care about whether an AMD processor that sells for eight dollars less than its Intel counterpart can perform at the same levels under overclocking, or whether adding a second graphics card will crank out ten more frames per second after you add that fourth monitor, then you should care about the performance of your software platform. The differences here are not so incremental.
At Betanews, we've been testing Windows-based Web browsers with greater and greater accuracy throughout this year, with the objective of being able to give you a simple and indisputable way to consider their all-around performance. All through that time, we've been listening to your responses as to how we can improve our methods, and we've been getting a lot of responses.
Here's what we've learned from you:
- You want a simpler, flatter index. Just as the Dow Jones Industrial Average represents the general state of investment in the American economy for any point in time, you need one number that represents the all-around performance of every browser in the field, something you can remember and discuss.
- You also want all the data. Specifically, you want to be able to see exactly how that final index number is obtained. Our verbal explanations haven't always been enough, and you know from personal experience that a browser we've called relatively slow is actually faster in the areas that matter specifically to you.
- You want us to cast our net wider, and find a fairer and more accurate way to assess basic performance. You've told us that page load times, to you, represent basic performance -- if a page loads faster, it's a faster browser. But timing how fast a browser loads Yahoo or Facebook, for example, is a process loaded with uncontrolled variables -- the pages change, the network ebbs and flows, and ads can be textual or in interactive Java 3D. You need a fair and regulated means for assessing real-world page loading speed.
- You warned us not to trust browsers' different methods for reporting their own load times. Since different browsers work in various ways, for example, they fire the JavaScript onLoad event at different times, for different reasons -- so we can't accept onLoad as the complete "finish line." Instead, we need to pay attention to the whole page loading process, specifically with regard to how soon the scripts inside a page can access the elements of that page and start styling and displaying them.
We already had four tests in our previous Web browser suite, and after careful research, we've added four more that focus on areas that you say matter to you, and that some of you say we've overlooked. And as usual, you're right: If we're going to claim to measure "all-around" performance, we need to cover all the bases.
On the next page, we introduce our new solution and our response to your many, many very good suggestions. This is your comprehensive index.
Next: How Betanews will measure Web browser performance...
The Betanews Comprehensive Relative Performance Index (CRPI)
Click here for a complete introduction to the Betanews Comprehensive Performance Index.
Today, we unveil something very CRPI. It's an acronym that we hope sticks -- yes, I'm calling it the "creepy index," and you can too. One of the features you told us you wanted was a more thorough explanation of what's covered, and how our testing works. Now you have it.
Starting today, Betanews will present our newly expanded browser test suite, and our single CRPI index number to represent relative all-around performance on all Windows platforms. The link above will take you to our very exhaustive explanation of how the new test works. For our regular readers, we will continue for a short time to report (but not chart) some browser scores on our old index just for comparison purposes with previous articles.
And for those of you who want the absolutely complete breakdown of all our scores in each test, now you have that too. The complete set of charts are now available by clicking the picture at right. (You're welcome.) Now, here are our first set of CRPI results:
As you can see, despite everyone's best efforts to shake things up, the running order of browsers in the race actually has not changed at all. Our CRPI numbers are lesser in value than our old index for a few reasons: We've discovered areas where the speed demon browsers we had been reporting on are not really so swift. So you won't be seeing numbers approaching "20" in our new index, at least for awhile.
Adding rendering tests to our suite did make things better for Opera. Although it's still behind, the gap between Opera 10 (CRPI: 6.38) and Firefox 3.5.3 RTM (7.35) is not nearly as insurmountable as it once seemed. In page loading tests, Opera is a very strong performer along with Safari; and in CSS rendering, Opera is the absolute champion. In fact, as our complete charts will now show you, the just-released RTM version of Opera 10 scores better at CSS rendering on Vista (!) than any other browser on any other platform, including XP and Win7. Vista, the slowest platform of all. We were so baffled by this result that we performed this test multiple times over the weekend, and it's verified: Opera 10 was twice as fast at rendering on Vista as it was on XP (12.68 for Vista, 6.11 for XP).
What baffled us even more was the performance of the latest Opera 10.1 daily snapshot build under the same conditions: It performed poorly in Vista for the same test (3.89 for Vista, 8.37 for XP), while its score improved in XP.
Opera's overall scores improved on the CSS rendering battery, in part, because of adjustments we made to this battery in response to some readers' assertions, which turned out to be correct: Opera was mis-reporting its own rendering times in XP, not being fair to itself. In one of the new test batteries we added for the CRPI -- testing simple DHTML geometric plotting -- Opera is also an astounding performer, posting a score of 3.83 in XP compared to 2.17 for Firefox 3.6 Alpha 2 and 2.43 for the overall performance champion up to now, Google Chrome 3 (CRPI: 15.27).
Our additions and adjustments proved what our eyes were telling us, that Opera really is the faster renderer...at least most of the time. If only rendering were everything, Opera would still be king.
Meanwhile, Firefox reigns supreme with simpler computational tests. Right now, it's the champion of the Celtic Kane battery, with Firefox 3.6 Alpha 2 (CRPI: 8.82) posting an 11.21 score there in XP versus Opera 10's 3.18. The first private builds of Firefox 3.7 Alpha 1 are posting even better scores; but it appears the newest Mozilla browser's computational scores come at the expense of rendering ability, which may be why 3.7's overall CRPI comes in just above the RTM version, at 7.36.
It's in the computational scores where Chrome earns its racing stripes. Right now, Chrome 3's performance on the SunSpider JavaScript test yields a score of 63.74, with the dev build of Chrome 4 (CRPI: 14.69) not far behind at 62.65. With Firefox 3.6 Alpha 2 posting Mozilla's best SunSpider score of 32.89, you can see that Chrome truly is almost twice as fast as Firefox in heavy computation.
Where does Safari shine? We wish we could provide an accurate CRPI for Safari's test builds. The reason we can't is because Safari testing involves grafting the latest version of the WebKit renderer to the Safari front-end. While doing so dramatically improves the test browser's rendering scores, it sacrifices much of Safari's computational scores and all of its AJAX scores, rendering the overall CRPI score meaningless. The test build is useless as an all-around browser.
But the release version of Safari 4 has its strengths, as our added test batteries revealed. When using multiple JavaScript libraries for CSS selectors, Safari 4 (CRPI: 14.42) posted a fantastic 10.56 score in our new SlickSpeed battery on XP SP3, versus 12.43 for both stable and dev builds of Chrome. And Safari would be the page load leader with a 10.94 score on XP, were it not for Chrome 4's bewilderingly impressive 11.94 score there on Win7. That seemed to be a blip to us too, so again, we re-tested and re-tested and came up with the same results each time.
Our new scoring system makes things a bit flatter and a bit fairer. But thanks to Chrome 3's continually superior computational scores, it's still our performance leader. Apple Safari 4 is very close behind, and actually ahead of the Chrome 4 dev platform overall. The minor difference in our scores between the release versions of Chrome and Safari certainly wouldn't be enough for folks with a Mac at home to decide not to install Safari on their Windows-based platforms at work.
In the coming days, as we test Microsoft's Office Web Apps for the first time, we'll report on which browsers run the Technical Preview apps better and faster, and which ones show signs of stress. But the browser development field is a full-scale battle now for performance supremacy, and Betanews will be the one giving you the full-field rundown.
Copyright Betanews, Inc. 2009
The Betanews Comprehensive Relative Performance Index: How it works and why

Publié: septembre 21, 2009, 5:34pm CEST par Scott M. Fulton, III
By Scott M. Fulton, III, Betanews

After several months of intense research, helped along by literally hundreds of reader suggestions, Betanews has revised and updated its testing suite for Windows-based Web browser performance. The result is the Comprehensive Relative Performance Index (CRPI). If it's "creepy" to you, that's fine.
We've kept one very important element of our testing from the very beginning: We take a slow Web browser that you might not be using much anymore, and we pick on its sorry self as our test subject. We base our index on the assessed speed of Microsoft Internet Explorer 7 on Windows Vista SP2 -- the slowest browser still in common use. For every test in the suite, we give IE7 a 1.0 score. Then we combine the test scores to derive a CRPI index number that, in our estimate, best represents the relative performance of each browser compared to IE7. So for example, if a browser gets a score of 6.5, we believe that once you take every important factor into account, that browser provides 650% the performance of IE7.
As you'll see, we believe that "performance" means doing the complete job of providing rendering and functionality the way you expect, and the way Web developers expect. So we combine speed, computational efficiency, and standards compliance tests. This way, a browser with a 6.5 score can be thought of as doing the job more than five times faster and better. Here now are the eight batteries we use for our suite, and how we've modified them where necessary to suit our purposes:
- The Nontroppo CSS rendering test. Up to now, we've been using a modified version of a rendering test used by HowToCreate.co.uk, whose two purposes have been to time how long it takes to re-render the contents of multiple arrays of <DIV> elements and to time the loading of the page that includes those elements. The reason we modified this page was because the JavaScript onLoad event fires at different times for different browsers -- despite its documented purpose, it doesn't necessarily mean the page is "loaded." There's a real-world reason for these variations: In Apple Safari, for instance, some page contents can be styled the moment they're available, but before the complete page is rendered, so firing the event early enables the browser to do its job faster -- in other words, Apple doesn't just do this to cheat. But the actual creators of the test themselves, at nontroppo.org, did a better job of compensating for the variations than we did: Specifically, the new version now tests to see when the browser is capable of accessing that first <DIV> element, even if (and especially when) the page is still loading.
  Here's how we developed our new score for this test: There are three loading events: one for Document Object Model (DOM) availability, one for first element access, and the third being the conventional onLoad event. We counted DOM load as one sixth, first access as two sixths, and onLoad as three sixths of the rendering score. Then we adjusted the re-rendering part of the test so that it iterates 50 times instead of just five. This is because some browsers do not count milliseconds properly in some platforms -- this is the reason why Opera mysteriously mis-reported its own speed in Windows XP as slower than it was. (Opera users everywhere...you were right, and we thank you for your persistence.) By running the test for 10 iterations for five loops, we can get a more accurate estimate of the average time for each iteration because the millisecond timer will have updated correctly. The element loading and re-rendering scores are averaged together for a new and revised cumulative score -- one which readers will discover is much fairer to both Opera and Safari than our previous version.
- Celtic Kane's JavaScript suite. The independent developer who calls himself Celtic Kane is noted for developing a battery of simplified tests, which first became noteworthy for having demonstrated the rendering ability of Opera over its competition at the time, Mozilla Firefox and IE7. What impresses us about CK is its ability to render a "signature" of eight integer scores that distinguish just about each version of each browser we test -- whereas many other tests are susceptible to variations in the environment, CK is relatively quite stable. As before, each of the eight tests in the CK battery (array handling, date and timing object manipulation, error handling, math objects, regular expressions, string objects, DOM manipulation, and AJAX declarations) are judged for relative performance against IE7, and the result is averaged for a cumulative score.
- SunSpider JavaScript benchmark. Maybe the most respected general benchmark suite in the field focuses on computational JavaScript performance rather than rendering -- the raw ability of the browser's underlying JavaScript engine. Though it comes from the folks who produce the WebKit open source rendering engine that currently has closer ties with Safari, though is also used elsewhere, we've found SunSpider's results to appear fair and realistic, and not weighted toward WebKit-based browsers. There are nine categories of real-world computational tests (3D geometry, memory access, bitwise operations, complex program control flow, cryptography, date objects, math objects, regular expressions, and string manipulation), some of which overlap with Celtic Kane, although we feel those that do overlap should be treated more importantly anyway. All nine categories are scored and average relative to IE7 in Vista SP2.
Next: The additions and changes we've made...
The additions and changes we've made to our performance index
- The Mozilla 3D cube by Simon Speich (Testcube 3D) is an unusual discovery from an unusual source: an independent Swiss developer who devised a simple and quick test of DHTML 3D rendering while researching the origins of a bug in Firefox. That bug has been addressed already, but the test fulfills a useful function for us: It fills precisely the gap in our test suite that we've been needing to fill, testing only graphical dynamic HTML rendering -- which is finally becoming more important thanks to more capable JavaScript engines. And it's not weighted toward Mozilla -- it's a fair test of anyone's DHTML capabilities. There are two simple heats whose purpose is to draw an ordinary wireframe cube and rotate it in space, accounting for forward-facing surfaces.
  Each heat produces a set of five results: total elapsed time, the amount of that time spent actually rendering the cube, the average time each loop takes during rendering, and the elapsed time in milliseconds of the fastest and slowest loop. We add those last two together to obtain a single average, which is compared with the other three times against scores in IE7 to yield a comparative index score.
- The SlickSpeed CSS selectors test suite is a new and probably controversial addition to our suite, but as you'll see, we addressed the reason for the controversy and compensated for it. As JavaScript developers know, there are a multitude of third-party libraries in addition to the browser's native JS library, that enable browsers to access elements of a very detailed and intricate page (among other things). For our purposes, we've chosen a modified version of SlickSpeed by Llama Lab, which covers many more third-party libraries including Llama's own. This version tests no fewer than 56 shorthand methods that are supposed to be commonly supported by all JavaScript libraries, for accessing certain page elements. These methods are called CSS selectors (one of the tested libraries, called Spry, is supported by Adobe and documented here).
  So Llama's version of the SlickSpeed battery tests 56 selectors from 10 libraries, including each browser's native JavaScript (which should follow prescribed Web standards). Multiple iterations of each selector are tested, and the final elapsed times are rendered. Here's the controversial part: Some have said the final times are meaningless because not every selector is supported by each browser; although SlickSpeed marks each selector that generates an error in bold black, the elapsed time for an error is usually only 1 ms, while a non-error is as high as 1000. We compensate for this by creating a scoring system that penalizes each error for 1/56 of the total, so only the good selectors are scored and the rest "get zeroes."
  Here's where things get hairy: As some developers already know, IE7 got all zeroes for native JavaScript selectors. It's impossible to compare a good score against no score, so to fill the hole, we use the geometric mean of IE7's positive scores with all the other libraries, as the base number against which to compare the native JavaScript scores of the other browsers, including IE8. The times for each library are compared against IE7, with penalties assessed for each error (Firefox, for example, can generate 42 errors out of 560, for a penalty of 7.5%.) Then we assess the geometric mean, not the average, of each battery -- the reason we do this is because we're comparing the same functions for each library, not different categories of functions as with the other suites. Geometric means will account better for fluctuations and anomalies.
- Nontroppo table rendering test. As has already been proven in the field, CSS is the better platform for rendering complex pages using magazine-style layout. Still, a great many of the world's Web pages continue to use HTML's old <TABLE> element (created to render data in formal tables) for dividing pages into grids. We heard from you that if IE7 is still important (it is our index browser after all), old-style table rendering should still be tested. And we've decided to concur.
  The creator of our CSS rendering test has created a similar platform for testing not only how long it takes a browser to render a huge table, but how soon the individual cells (<TD> elements) of that table are available for manipulation. When the test starts, it times the duration until the browser starts rendering the table and then ends that rendering, from the same mark, for two index scores. It also times the loading of the page, for a third index score. Then we have it re-render the contents of the table five times, and average the time elapsed for each one, for a fourth score. The four items are then averaged together for a cumulative score.
- Nontroppo standard browser load test. (That Nontroppo gets around, eh?) This may very well be the most generally boring test of the suite: It's an extremely ordinary page with ordinary illustrations, followed by a block full of nested <DIV> elements. But it allows us to take away all the variable elements and concentrate on straight rendering and relative load times, especially when we launch the page locally. It produces document load time, document plus image load times, DOM load times, and first access times, all of which are compared to IE7 and averaged.
- Acid3 standards compliance test. The function of the Acid3 test has changed dramatically, especially as most of our browsers become fully compliant. IE7 only scored a 12% on the Acid3; but today, most of the alternative browsers are at 100% compliance, with Firefox at 93% and flirting with 94%. So it means less now than it did in earlier months to have Acid3 yield an index score of 8.33, which is the score for any browser that scores 100% thanks to IE7. Now that cumulative index scores are closer to 20, having an eight-and-a-third in the mix has become a deadweight rather than a reward. So for the first time, we're making Acid3 count in a different way: For the other batteries that have to do with rendering (all three Nontroppos and TestCube 3D), plus the native JavaScript library portion of the SlickSpeed test, we're multiplying the index score by the Acid3 percentage. As a result, the amount of any non-compliance with the Web Standards Project's assessment is applied as a penalty against those rendering scores. Today, only Mozilla and Microsoft browsers are affected by this penalty, and Firefox only slightly -- all the others are unaffected.
The physical test platform we've chosen for our tests is a triple-boot system, which enables us to boot different Windows versions from the same large hard drive. Our platforms are Windows XP Professional SP3, Windows Vista Ultimate SP2, and Windows 7 Release Candidate.
All platforms are always brought up to date using the latest Windows updates from Microsoft, prior to testing. We realize, as some have told us, that this could alter the speed of the underlying platform. However, we expect real-world users to be making the same changes, rather than continuing to use unpatched and outdated software. Certainly the whole point of testing Web browsers on a continual basis is because folks want to know how Web browsers are evolving, and to what degree, on as close to real-time a scale as possible. When we update Vista, we re-test IE7 on that platform to ensure that all index scores are relative to the most recent available performance, even of that aging browser on that old platform.
The physical test unit is an Intel Core 2 Quad Q6600-based computer using a Gigabyte GA-965P-DS3 motherboard, an Nvidia 8600 GTS-series video card, 3 GB of DDR2 DRAM, and a 640 GB Seagate Barracuda 7200.11 hard drive (among others). Three Windows XP SP3, Vista SP2, and Windows 7 RC partitions are all on this drive. Since May 2009, we've been using a physical platform for browser testing, replacing the virtual test platforms we had been using up to that time. Although there are a few more steps required to manage testing on a physical platform, you've told us you believe the results of physical tests will be more reliable and accurate.
Copyright Betanews, Inc. 2009
FCC chair lays down groundwork for net neutrality rules

Publié: septembre 21, 2009, 4:06pm CEST par Tim Conneally

By Tim Conneally, Betanews

At the Brookings Institution in Washington, DC today, Federal Communications Commission chairman Julius Genachowski discussed the Commission's plans for preserving net neutrality with the addition of two new tenets to the FCC's existing open Internet principles.
"Why has the Internet proved to be such a powerful engine for creativity, innovation, and economic growth?" Genachowski asked, "A big part of the answer traces back to one key decision by the Internet's original architects: to make the Internet an open system."
Both of the new policies will be focused on Internet Service Providers, a link in the chain of Internet access whose power has been the subject of debate for years. The first of the new open Internet Principles will prevent ISPs from regulating the content and applications their subscribers can access, and the second will call on ISPs to be more transparent about their traffic control systems and network management policies.
"We cannot know what tomorrow holds on the Internet, except that it will be unexpected; that the genius of American innovators is unlimited; and that the fewer obstacles these innovators face in bringing their work to the world, the greater our opportunity as citizens and as a nation," Chairman Genachowski said this morning.
"Today the free and open Internet faces emerging and substantial challenges. We've already seen some clear examples of deviations from the Internet's historic openness. We have witnessed certain broadband providers unilaterally block access to VoIP applications (phone calls delivered over data networks) and implement technical measures that degrade the performance of peer-to-peer software distributing lawful content. We have even seen at least one service provider deny users access to political content. And as many members of the Internet community and key Congressional leaders have noted, there are compelling reasons to be concerned about the future of openness."
Chairman Genachowski proposed today that the FCC adopt former Chairman Michael Powell's "Four Freedoms" (PDF here) as commission rules, and add the two new ISP-specific policies, which Genachowski referred to as "non-discrimination," and "transparency."
"The fifth principle...means [ISPs] cannot block or degrade lawful traffic over their networks, or pick winners by favoring some content or applications over others in the connection to subscribers' homes. Nor can they disfavor an Internet service just because it competes with a similar service offered by that broadband provider. The Internet must continue to allow users to decide what content and applications succeed."
In regards to the transparency principle, Genachowski said, "Today, broadband providers have the technical ability to change how the Internet works for millions of users -- with profound consequences for those users and content, application, and service providers around the world...We cannot afford to rely on happenstance for consumers, businesses, and policymakers to learn about changes to the basic functioning of the Internet. Greater transparency will give consumers the confidence of knowing that they're getting the service they've paid for, enable innovators to make their offerings work effectively over the Internet, and allow policymakers to ensure that broadband providers are preserving the Internet as a level playing field. It will also help facilitate discussion among all the participants in the Internet ecosystem, which can reduce the need for government involvement in network management disagreements."
Copyright Betanews, Inc. 2009