Thursday, 15 April 2010

AT&T network problems: coverage, speed, or none of the above?

AT&T has blamed issues with its network on smartphone users—sometimes pointing to iPhone users in particular—moving tons of data over its network. A new report from ABI Research says that Verizon and Sprint are moving much more data over their networks than AT&T, suggesting that its limited geographical coverage is to blame. However, AT&T says that the data and conclusions aren't very accurate.

The ABI report, titled "US Mobile Operator Traffic Profiles," claims that Verizon and Sprint networks carried far more data in 2009 than AT&T. This is despite the fact that AT&T has more active data devices on its network, and also typically rates as one of the fastest 3G data networks in the US. ABI researcher Dan Shey cited two main reasons for this seemingly illogical conclusion: 3G data modems, and wider coverage areas.

Both Verizon and Sprint have far more 3G laptop modems and mobile hotspots, like the MiFi, in use on their networks compared to AT&T. "It is laptop mobile data connections that have the most impact on operator data traffic levels," Shey said in a statement.

The study also cited Verizon's and Sprint's wider 3G coverage areas as contributing to their higher levels of data traffic. Certainly, if devices can be used in more areas, then there is a greater potential for higher data use.

However, AT&T told Ars that the study has a number of flaws, and that its conclusions don't support AT&T's own research. AT&T spokesperson Seth Bloom pointed out that based on analysis of third-party data, AT&T actually carries about half of all mobile data on its network. It also has twice the number of smartphone customers as the next nearest competitor, and mobile traffic has increased 5,000 percent over the last three years.

Bloom told Ars that the study overestimates data use from laptop users, and underestimates the impact of smartphone users. The ABI report estimates that laptop users use 25x more data than smartphone users, though AT&T cited a Frost & Sullivan study that put that number closer to 5x. ABI also assumes that iPhones use about 2x-3x more data than the average smartphone, whereas AT&T's own data says that iPhones and other similar phones consume as much as 10x the traffic of other devices. It's worth noting, too, that most data modem plans come with a monthly data cap, usually 5GB, while most smartphone plans have no such restriction.

Finally, Bloom said, the numbers just don't seem to add up. "For example, Sprint claimed 48.1 million customers to AT&T’s 85.1 million at the end of the fourth quarter 2009," Bloom told Ars. "If AT&T serves 37 million more customers, and more smartphone customers than any other US carrier, how could Sprint possibly carry more mobile data traffic?"

The impact of the wider geographical area also seems overemphasized. For users that find themselves in more remote areas, that wider coverage is very important. But AT&T's 3G coverage covers a wide range of urban areas, reaching about 75 percent of the population, and its 2G EDGE network covers far more.

ABI Research did not respond to our requests for comment on AT&T's objections to the report's content, but Bloom told Ars that AT&T had not been contacted by ABI to provide any data for the report.

Which network actually carried the biggest number of megabytes hardly matters to the vast majority of consumers, however. With pricing largely the same between carriers, most consumers are either picking the network that has the best coverage and reliability in their area, or the one that has the device they most want.

Friday, 9 April 2010

Early IE9 Platform Preview results show promise

We've argued that Microsoft needs to engage more with Web developers to give a better understanding of what the company is doing with its Web browser, allow them to provide feedback throughout the development process, and more broadly get them engaged with the development process. With Internet Explorer 9's Platform Preview, Microsoft has indeed taken steps to do exactly this. Though Microsoft still isn't releasing the nightly builds that other browsers offer, the Platform Preview definitely represents progress; it provides early access to IE9's core rendering and JavaScript engines, and will be updated approximately every eight weeks.

The eight-week cycle was chosen because Redmond felt this provided the best trade-off between getting regular updates into developers' hands, ensuring that the preview releases are reasonably robust, and getting useful feedback that integrates well with Microsoft's own development processes. Each version will undergo reasonably extensive testing during the eight-week period, giving ample opportunity for bugs to be filed. For its part, the IE team has committed to investigating every single bug filed, and resolving all that it can.

Indications are that the Platform Preview has thus far been quite successful. Sources close to the matter state that some 700,000 copies of the preview have been downloaded, and that interest has been global in spite of the preview being a US English-only release. The top three bug report areas are SVG, compatibility, and then CSS, which certainly indicates that developers are taking an interest in testing the browser's new features and ensuring they work correctly. Of the hundreds of bugs filed thus far, the same source says that around 60 percent of them have been addressed by the development team.

These download numbers are substantial, and it could be make a good case in favor of this slower release strategy. The Mozilla group's weekly Status Meetings include information about the number of users of different prerelease versions of Firefox. During the lead-up to the release of Firefox 3.5, several hundred thousand people used the major betas, but the nightly releases were much less used, with perhaps 10,000-15,000 users. The Platform Preview is not anything near as usable as the Firefox betas, so 700,000 downloads is a strong showing.

Ars talked with IE General Manager Dean Hachamovitch briefly about the Preview. He said that IE9 testers seemed particularly interested in the browser's performance and graphical capabilities, as these areas of the IE 9 Test Drive site had received most traffic. This is also reflected in some third-party reactions. NVIDIA recently used the IE9 Platform Preview to promote the graphical capabilities of its new Ion2 platform—capabilities that IE9 can, of course, exploit due to its extensive hardware acceleration (the same hardware acceleration that leaves Windows XP users out in the cold).

Stability vs. automation

Microsoft's approach to browser development shows a strong commitment to the ideal of a stable, versioned platform, something that developers could reliably target for consistent results. This attitude is carried through to the Platform Preview. Unlike, say, Chrome's dev channel which automatically updates about once a week, ensuring that developers always have access to an up-to-date version, the IE9 Platform Preview will require manual updating. Though this has the obvious downside that developers might forget or not notice that a new version has been released, and hence may result in testing of obsolete versions, it maintains the important (to Microsoft) notion of predictability. With Chrome, a page might work one day and be broken the next by an automatic update, a behavior that can be confusing at best. Microsoft doesn't want IE developers to face a similar experience; instead, they will have to take deliberate action to update.

On the other hand, automatic updates are, in a sense, part-and-parcel of the Web experience. Websites can change their appearance overnight, and while this can be confusing to some, it's an unavoidable fact of Internet life. The case can certainly be made that browsers should follow websites' lead and update themselves; this gives users a browser that (by and large) keeps on getting better—faster, more capable, and with new features. Though occasional regressions will happen (wherein a new version breaks something that used to work) a robust development process should make these rare.

These advantages were acknowledged by Hachamovitch, especially for the more savvy, technically aware user (that is, users who are unlikely to be fazed by new features and improvements appearing within their browser automatically). But the company still prefers to take the more conservative approach to avoid problems of users being surprised by changes.

Hachamovitch was noncommittal about what the second Platform Preview release would contain when released next month. At MIX10 we saw demonstrations of HTML5 video in a build of IE9. The version released last month, however, didn't include video support. HTML5 video is surely one of the most eagerly anticipated IE9 features. It will ship in a Preview release eventually, but we do not know when.

The Platform Preview program is still in its early stages, and this is the first time that Microsoft has developed its browser in this way; there may yet be refinements to the program as both the company and third parties learn the best way to work together, and there's no news yet of what will happen once IE9 moves into beta.

Thus far, at least, it looks like the scheme has been successful at getting third-party developers involved with IE9's development, which has to be good news for both sides.

Microsoft offers much-needed fix for Windows OSS development

Although Microsoft is beginning to acknowledge that the rich ecosystem of open source software can bring a lot of value to Windows users, the most popular open source software projects are largely developed on other platforms, which means that they aren't always easy to deploy on Windows. A relatively complex open source server stack can be rolled out on Linux with a few clicks, but it might take hours to get the same software installed and properly configured on Windows.

Microsoft developer Garrett Serack has identified a compelling solution to this problem. He is launching a new project to build a package management system for Windows with the aim of radically simplifying installation of popular open source software on Microsoft's platform. He calls it the Common Open Source Application Publishing Platform (CoApp).

Much like the package management systems that are a standard part of popular Linux distributions, the CoApp project will provide a delivery platform for packaged open source software libraries and applications, with support for dependency resolution and automatic updates. It could be a powerful tool for system administrators who want a WAMP stack or developers who want to port Linux applications to Windows.

Serack wants to use Microsoft's MSI format for the packages and intends to take advantage of WinSxS in order to deliver parallel binaries so that users will have access to multiple builds of the same library generated by different compilers. The project will also seek to establish some basic standards for filesystem layout so that files are put in consistent places.

He is coordinating the project with Microsoft's blessing, but the actual development effort will be community-driven—an approach that will hopefully enable CoApp to evolve in a way that best serves its users rather than being directed by Microsoft.

"The folks here at Microsoft have recognized the value in this project—and have kindly offered to let me work on it full-time. I'm running the project; Microsoft is supporting my efforts in this 100%," he wrote in a blog entry about the project on Wednesday. "The design is entirely the work of myself and the CoApp community, I don't have to vet it with anyone inside the company."

Making open source development on Windows suck less

Having ported several of my own Linux applications to Windows, I know from personal experience how insanely difficult it can be to set up a proper environment for developing open source software on Microsoft's operating system. For the last Qt application that I ported, the process of getting all of the dependencies installed took hours. I had to install CMake, find just the right version of Automoc, and compile OpenSSL from source.

My current Windows VM has a half a dozen different build systems and three separate sets of version control tools, all of which had to be installed individually. I also have two completely separate installations of MinGW and a rather heavy Cygwin setup. I need all of this crap in order to port my software to Windows, but it's a nightmare to maintain. I have to meticulously document every step of the setup process if I ever want to be able to do it again on a different Windows installation.

These headaches are enough to deter many open source software developers who would otherwise be releasing Windows versions of their applications. Spending a few hours developing on Windows often serves as a painful reminder of how much I depend on my distro's super cow powers. That is why I'm convinced that CoApp is a very good idea.

Cygwin arguably constitutes a package management system by itself, but it tends to be somewhat insular and isn't very native. Serack believes that CoApp offers an opportunity to do it the right way and close the gaps that isolate ported open source software components from the rest of the Windows ecosystem. If it's done properly, that could be very significant.

Although Linux enthusiasts tend to disdain Windows, porting Linux applications to Microsoft's operating system can open up a lot of opportunities. A Windows port can expose your application to a whole new audience, making it possible to attract new contributors. We have seen a number of prominent open source software projects benefit in that manner from Windows compatibility in the past.

A positive side effect of that phenomenon is that it introduces Windows application developers to open source frameworks and technologies. Broader adoption of cross-platform Linux-friendly software and toolkits on Windows would obviously help boost the availability of software for Linux.

Although I'm really impressed with Serack's vision, I'm a bit skeptical that a task of such magnitude and complexity can be fulfilled to an extent that would truly deliver on its potential. Such an undertaking will require considerable manpower. Ars readers who want to participate in the project or learn more can check out the CoApp page on Launchpad.

Thursday, 8 April 2010

Inside WebKit2: less waiting, less crashing

Anders Carlsson, an Apple employee, announced today on the WebKit mailing list an evolution of the WebKit project called WebKit2.

WebKit2's major aims are to bake both a "split process model" and a non-blocking API into the WebKit product—and by extension into Safari and any other client which takes advantage of the WebKit2 framework.

Google's Chrome browser launched in late 2008 with what's called a split process model, one in which each WebKit view runs in its own process. This means that when a bad plugin or a bug in the renderer causes an error, only that tab will crash instead of the entire browser.

IE8 has a similar system and Firefox is exploring one as well with Electrolysis. Apple's Safari 4 gained a related feature under Mac OS 10.6, which runs plugins like Adobe's Flash in a separate process and prevents the whole browser from crashing due to plugin faults. WebKit2 validates that approach by building support for split processes directly into the rendering engine.

Out of my way!

Another goal of WebKit2 is to implement the API to the framework in a completely non-blocking manner. This means that developers can hook into API methods with various kinds of callbacks in order to receive notifications from WebKit views.

For example, in my application I might want to load a webpage. I would call the loadWebsite method (which I just made up), pass it my URL, and additionally specify a callback method or block of code I would like to have attached to a particular event—say didFinishLoadForFrame (which I did not make up).

Whenever the webpage is done rendering, my code would be executed or my method called or pinged. This should result in much more responsive applications which hook into WebKit2. Theoretically, while the renderer is rendering something, the main application loop can move on to doing something else as requested by a user.

There are three techniques currently implemented to achieve this goal: notification-style client callbacks, policy-style client callbacks, and policy settings. A fourth method, code injection which can interact directly with the DOM, is proposed but not yet implemented. These are described in more detail on the project page.

The neat thing about Apple's implementation is that these abilities can be used and exploited by all downstream clients of WebKit2, since they are baked right into the framework—in contrast to the tack taken in Google Chrome. The end user of an application that uses WebKit2 will get a more stable product and developers can take advantage of these enhancements without having to implement their own solutions or jump through unnecessary hoops.

WebKit2 is currently supported on Windows and OS X—the two platforms on which Apple deploys Safari. Linux support is not mentioned at this time.