Gregarius » BetaNews.Com » avril 9, 2010

BetaNews.Com (7 non lus)

The big change coming to Safari 5: Kernel-level multi-processing

Publié: avril 9, 2010, 11:53pm CEST par Scott M. Fulton, III

By Scott M. Fulton, III, Betanews

Apple has been challenging Google on many fronts this week -- first with its mobile platform, then with its advertising platform. Earlier today, its developers launched the first volley in the battle's third front, releasing the first public code for the next WebKit rendering and processing kernel that will likely drive the Safari 5 browser.
With Google Chrome using a reworked form of WebKit, the Apple team did something that perhaps any other free and open source developer would be publicly stoned for doing, but which Apple might just have the savvy to get away with: It openly one-upped another developer's open contribution.
"WebKit2 is designed from the ground up to support a split process model, where the Web content (JavaScript, HTML, layout, etc) lives in a separate process," wrote Apple developer Anders Carlsson to WebKit's public mailing list yesterday. "This model is similar to what Google Chrome offers, with the major difference being that we have built the process split model directly into the framework, allowing other clients to use it."
The "process split" model to which Carlsson refers is the architecture that enables processes spawned by the browser, including add-ons and Web apps, to be run as separate processes in the operating system while still being protected by the browser's "sandbox." Google's Chromium team developed the first such model in working form for its Chrome browser.
But it was the Chromium team that tried one-upping Apple first, by extracting just the WebKit rendering engine from its open source project files, and replacing its JavaScript interpreter with V8. That may have been a smart move from a performance standpoint at the time. However, in implementing its innovative multi-process model, the Chromium team split the rendering code into two components: a single process host, and a multi-process-capable agent. The two components were designed to communicate with one another via proxy, as Chromium's developers first explained: The renderer and rendering host jointly comprise, they said, "Chromium's 'multi-process embedding layer. It proxies notifications and commands across the process boundary. You could imagine other multi-process browsers using this layer, and it should have dependencies on other browser services."
We could imagine it, certainly; but sharing open source concepts often comprises doing something more than merely imagining. The WebKit team that originated the components that Chromium split into parts, have imagined something different: They foresee moving the user interface components into the multi-process realm, and then enabling APIs from other applications to communicate with those forked processes individually. That way, conceivably, a new single kernel can drive multiple browser tabs whose processes reside on different CPU cores.
"Notice that there is now a process boundary, and it sits below the API boundary," reads a document published by Apple's WebKit team yesterday. "Part of WebKit operates in the UI process, where the application logic also lives. The rest of WebKit, along with WebCore and the JS engine, lives in the Web process. The Web process is isolated from the UI process. This can deliver benefits in responsiveness, robustness, security (through the potential to sandbox the web process) and better use of multicore CPUs. There is a straightforward API that takes care of all the process management details for you."
Unlike Chrome and the Chromium team's work, the WebKit team goes on, they have a responsibility to provide a framework for others to explore and use for their purposes. So if they do a multi-process framework, then it must be in such a way that other developers (even including Google) could facilitate it. However, the facilitators themselves have no such responsibilities. WebKit gently chided Google for having developed Chrome under strict secrecy (something I suppose Apple knows nothing about).
"That was an understandable choice for Google -- Chrome was developed as a secret project for many years, and is deeply invested in this approach," reads WebKit's wiki today. "Also, there are not any other significant API clients. There is Google Chrome, and then there is the closely related Chrome Frame. WebKit2 has a different goal: We want process management to be part of what is provided by WebKit itself, so that it is easy for any application to use. We would like chat clients, mail clients, Twitter clients, and all the creative applications that people build with WebKit to be able to take advantage of this technology. We believe this is fundamentally part of what a Web content engine should provide."
That element which distinguishes WebKit's development philosophy from that of Chrome and Chromium (at least in Apple's eyes) may very well draw a new contour around the type of program -- or rather, the type of platform -- that Safari may yet become. Rather than having a tab for Twitter and a tab for Facebook and a tab for iTunes, a future Safari for all platforms (Mac, iPhone, iPad, Windows) could include a kind of "embedded desktop," or Web-top, where independent applications may reside. They might not appear to run under the context of the browser at all, and if you looked inside each of these processes, you might consider them independent too, capable of being accessed independently through API function calls. But a proxy/stub relationship may connect these processes to the WebKit2 core.
That would go a long way towards solving the iPad's single-tasking problem. The new architecture might also provide a kind of extended platform for something else Apple launched this week: its iAd revenue-sharing advertising system. Imagine, if you will, an advertisement that runs out of the context of the browser. It would not even have to run in the context of the Web page; instead, it could be delivered through one of the applications to which the Safari user subscribes. It might not even be something you can block, not through the ordinary means with which Firefox and IE users are already accustomed. It could even be a potential new revenue stream (or, more accurately, a river) for iTunes.
While you're imagining that...we'll be right back.
Copyright Betanews, Inc. 2010
Two Linux-based text editors reveal a market for Notepad work-alikes

Publié: avril 9, 2010, 8:09pm CEST

By Jack M. Germain, LinuxInsider

Download gedit text editor for Linux from Fileforum now.
Text editors are becoming more essential in today's Web-based computing world. Gone are the days when users need hard-copy versions of their documents. Also gone are the days when documents need to be gussied up with fancy fonts and fanciful page formatting.
Now HTML handles the visual tune ups for online document displays converted from text documents. For the bulk of documentation now created with computers, text displays suffice. Content is what matters. When a more formal document requires graphical alure, word processors such as AbiWord and OpenOffice will take a plain text file to the more visual level. The Linux OS probably has more text-writing apps than any other computing platform. For many users, a text editor will meet or exceed writing needs most of the time. Two popular text editors are gedit and Leafpad.
Text editors are not all the same. Some have a basic feature set that makes the app more suitable to a variety of writing tasks. Others are very simple with basic text-entry capability.
Gedit falls into the first category. It is text editor bundled in the Gnome desktop environment. Leafpad is a simple GTK+ text editor that focuses on simplicity. Its lightweight structure makes it a good choice for compact distro configurations.
Gedit is relatively simple to use, but do not dismiss this app as being wimpy. It has all the power typical users need for general purpose text handling.
For instance, gedit has full support for internationalized text (UTF-8) coding. It also supports configurable syntax highlighting for C, C++, Java, HTML, XML, Python, Perl and many other programming languages.
One of gedit's most useful enhancements is its ability to handle multiple open files. The app uses a tabbed page structure. Clicking on a page tab displaying the file title across the top of the app window lets you move quickly through the list of open files.
While the tabbed navigational structure is essential to my workflow, gedit has a feature set that includes must-have writing tools such as several levels of Undo/Redo and File reverting options.
This text editor also has Print and Print Preview, so I can check on the hard copy results if I need to have more than a digital copy of the document. The Clipboard support is also essential for cut/copy/paste functions.
The Search and replace feature has a nifty option or two I do not see in most other text editors. It has an incremental search command that lets me step through locations in the document containing my search string. Couple this with he Clear Highlight command and gedit is a very convenient app for processing text.
Gedit has settings for auto indentation and text wrapping. It supports line numbering and bracket matching as well the ability to turn on/off the right margin line and set the right margin column number for wrapping. For me, being able to turn off current line highlighting is a big plus. So is the ability to configure fonts and colors.
In fact, it is in the preferences panel that gedit excels. Program options for viewing and editing choices are a check box away. For example, under the Editor tab, I can set the tab width and whether or not to insert spaces instead of tabs. There I can also choose to create a backup copy of files before saving and set the autosave interval.
One of the most powerful features is Plugins, which is built into the preferences panel. This feature really puts gEdit in the high-end class of text editors. For example, it is here that options for changing the case of selected text, turning on document statistics and spell checking, adding a file browser pane, and snippet insertions are controlled -- and there's much more.
Leafpad has a much smaller feature set than text editors typically labeled "high end," such as gEdit or Kate. However, the Linux OS is filled with not-so-able text editors that do much less than Leafpad. In a Linux world of high-end and low-end text editors, Leafpad claims the middle ground.
Download Leafpad text editor for Linux from Fileforum now.
Leafpad lacks the ability to open more than one file at a time, but that is OK if you need a fast and simple app for entering notes or maintaining To-Do lists and such.
This text editor has a tiny footprint on system resources, and it allows multiple instances to run. That makes for an ideal workaround. I open several copies of Leafpad, adjusting the size of the window for the tasks at hand. This lets me refer to several pages of research notes and other reference content simultaneously.
Leafpad's tiny feature set includes a codeset option (Some OpenI18N registered) and Auto codeset detection (UTF-8 and some codesets). It has an unlimited Undo/Redo feature.
Leafpad taps into the system fonts library so users are not stuck with a single default font. A preview window in the Options tab shows what each font looks like in each of the four accompanying styles -- Regular, Italic, Bold, and Bold Italic. Similarly, point sizes range from 6 to 72.
The bare-bones feature set includes Auto/Multi-line Indent, the option to turn on/off line numbers display and Drag and Drop editing. The only other enhancements are Cut/Copy/Paste/Delete under the Edit menu and Search/Replace options.
The Print Preview option is also useful. Print Previews are not always a close match to the actual printed page an editor app delivers, but that is not the case with Leafpad. What you see in the preview window is pretty much what you get on the printed page.
Gedit and Leafpad are two handy text editors. Rather than choosing one over the other, use both. Having them both available gives you plenty of flexibility.
Gedit is a more full-featured writing app with most of the high-end bells and whistles needed for fast and efficient text handling. Leafpad is much more basic, but it has enough features to raise it from the muck of unambitious typing-only apps.
Originally published on LinuxInsider.
© 2010 ECT News Network. All rights reserved.
© 2010 BetaNews.com. All rights reserved.
Copyright Betanews, Inc. 2010
Don't tell spammers that you're on vacation

Publié: avril 9, 2010, 8:01pm CEST par Joe Wilcox
By Joe Wilcox, Betanews

Microsoft has made the right decision to temporarily turn off Hotmail's vacation (e.g., out-of-office) reply feature. Flip the switch off permanently, I say.
"In our fight against spam, we sometimes have to make hard choices, and we had to make one this week. We discovered that spammers were using Hotmail's automatic vacation reply feature to send spam from their Hotmail accounts," Krish Vitaldevara, Windows Live Hotmail lead program manager, blogged late yesterday. I missed the post because of Apple's iPhone OS 4 launch (I blogged "Apple shows developers the money" and "Clash of the titans: Apple, Google battle for the mobile Web"). I spotted the announcement first at LiveSide about an hour ago.
Vitaldevara continues: "We decided to temporarily shut off the feature in order to shut down the spam. Of course, we know some of you like and use automatic vacation replies to let people know when you can't respond to e-mail for a while, and we'll turn this feature back on as soon as we've worked out the best way to prevent it from being misused by spammers."
I'm surprised it's taken so long for this kind of problem to surface. For years I've recommended against using out-of-office replies because they reveal to spambots valid email addresses. Two best practices for avoiding spam:
- Never use out-of-office replies
- Turn off automatic HTML rendering
I'm amazed that so few people make the connection between out-of-office replies and spam, considering how much of the crap is anonymously sent. Your vacation reply reveals that the email address is valid, and that can open a torrent of additional spam.
Automatically loading images is another sure way to validate an email address. Spammers typically include clear gifs -- meaning you can't see them -- in HTML email. These images, also known as Web beacons, call back to a server, letting the spammer know the email address is valid. Outlook and most email applications or Web mail services turn off email image rendering by default. But, of course, people turn on the feature because the mail looks prettier.
Like many other people, my inbox collected porn spam during the late 1990s. Once I disabled automatic image rendering, the porn spam subsided over about six months. I rarely get this kind of spam anymore, and on the rare occasions I do images don't load anyway. Hey, I'm married and a one-woman guy.
I applaud Microsoft for making the tough but smart decision about vacation replies. I would encourage the company to go further and help people to change their behavior. There are plenty of better ways to inform people when you're away, such as status messages on Facebook, IM, LinkedIn, Twitter or Windows Live --heck, even location-based services like Foursquare. The only people who really need to know you're out of the office or away from home are the people you know. Don't tell the spammers.
Copyright Betanews, Inc. 2010
The true cost of iAd

Publié: avril 9, 2010, 6:43pm CEST par Carmi Levy

By Carmi Levy, Betanews

Despite all the buzz this week that the upcoming major update to the iPhone/iPod touch/iPad operating system was all about multitasking and APIs, the real story was iAd. Although multitasking-deprived Apple fans haven't been holding their breath for almost three years waiting for an advertising framework, the new mobile ad network is infinitely more significant to the future of the platform than the ability to run more than one app at a time.
In many respects, iAd is nothing short of a full frontal assault on Google. While Google's model for generating ad revenue from activity-linked behaviors has rewritten the rules of advertising over much of the past decade, the path for the mobile market has not been as linear. Desktops and laptops have more than enough bandwidth and screen real estate to easily accommodate subtle text-based ads (or not-so-subtle dancing-cow banners) without significantly disrupting the end user experience. Indeed, many users can become so engaged in a given service -- search, mail, productivity, mapping, whatever -- that they virtually ignore the presence of ad-containing boxes toward the edge of the screen. Even if they're aware of them, the delivery paradigm on a traditional desktop, evolved in recent years to a ruthless level of efficiency, is largely responsible for Google's meteoric corporate rise.
The desktop ad paradigm isn't portable
What works on a large screen that we often stare at for hours during the course of a typical workday doesn't necessarily work on a much smaller screen that we glance at quickly as we rush from one meeting to the next. On smartphones, there isn't enough room or time for end users to consume ads the Google way. So the industry's inability to date to concoct a formula that works now gives Apple just enough of a window of opportunity for its own formula -- namely, in-app ads.
Like everything in the Apple universe, however, this new capability comes with a cost.
But because I'm an optimist, I'll focus first on the good stuff. Developers will love iAd because it addresses a few of the key issues that have made coding for the iPhone something of a thankless process for many. Coders must first navigate an approval process that is still less transparent than it needs to be, and that consequently results in some submissions spending weeks or months in approval limbo. Once approved, their titles must fight for attention amid a vast, fast-growing sea of competing apps. The pricing model doesn't do them any favors, either, as average selling prices have dropped significantly since the days of packaged software.
Giving developers the newfound ability to continue to make money via their apps, while also moving beyond the sell-once revenue model that's so long defined the industry, is a sea change that could give developers additional reasons to stick with Apple, while resisting the lure of up-and-coming competitors like Google's Android.
There's a downside, too
Not everything is perfect in iAd-land, however. If developers are happy that they've got new opportunities to make money, then end users must certainly be dreading yet another incursion of advertising into yet another aspect of their lives.
Although advertisers in recent years have found ever more creative places to plaster their messages in the real world -- on police cruisers, on the back of subway tickets and even atop urinals in public washrooms -- nothing approaches the aggressiveness with which they've invaded the online world. Ordinary Web pages become riots of Whack-a-Mole, as end users try to squash unwanted and unwelcome pop-ups. Advertisers use non-standard interfaces to keep the ads displayed for a precious extra few seconds before the elusive close box can be found and clicked on. Workflow grounds to a halt as ever more intrusive ad delivery mechanisms take over what used to be pristine online ground.
What's annoying to the average end user on a 23-inch screen is infinitely worse on a smartphone. Not everyone has an unlimited data plan. For those who do not, the prospect of multitasking applications seamlessly sucking up bandwidth to fill the in-app advertising pipeline is frightening. For mobile users who've become accustomed to lightening their data load while on the go, they now face the prospect of data overages to support ads they never asked for and never wanted.
Even if they are on an unlimited plan, the annoyance factor is potentially much higher because all that background ad-related data transfer takes bandwidth away from the stuff folks are trying to get done, like messaging, mapping, and searching. Thanks to the newly-multitasking-capable iPhone OS v4.0, it's entirely conceivable that a few apps pulling down ad content could easily saturate one's wireless connection. Think about everyone complaining about 3G coverage in urban areas today. Now multiply the problem by 4.
Who owns your data now?
In-app advertising also opens up a veritable Pandora's Box of privacy issues, specifically around how developers will use location- and user-based knowledge to tailor what's delivered. Since the process, delivered within the context of a given application, is one level removed from the operating system, who's accountable for the inevitable privacy concerns that will erupt when a misbehaving developer configures a misbehaving app to cross a privacy/confidentiality line or two? I see a lot of finger-pointing between Apple and developers when the first headlines begin to filter out, as well as a lot of nervous iPhone owners wondering, just who has access now to the trove of supposedly private data in their pockets, and what do they intend to do with it?
I don't begrudge Apple's desire to level the mobile advertising playing field and use its iPhone-related successes to date to give it a leg up in its quest to join Google as a Web services powerhouse. Advertising pays the freight for a growing range of online services, and it would be naïve to assume smartphones won't eventually become advertising platforms in their own right.
But in rushing toward a monetized mobile future and going for Google's jugular, Apple needs to ensure it doesn't damage the cherished end user experiences that got it to its current market position in the first place. The iAd platform will succeed or fail depending on how finely Apple can balance the competing needs of its often divergent stakeholders.
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. 2010
Unfazed, FCC plods ahead with Broadband Plan, starts a flame war with Verizon

Publié: avril 9, 2010, 6:01pm CEST par Scott M. Fulton, III

By Scott M. Fulton, III, Betanews

In a pair of blog posts since the DC Circuit Court of Appeals' finding Tuesday that the Federal Communications Commission lacked the statutory authority to tell Comcast how to manage traffic on its broadband network, the FCC demonstrated it had officially joined the Internet era by making the dispute into a flame war.
No, the Court did not revoke the FCC's natural authority to regulate the Internet industry, the Commission stated yesterday. However, it may have removed the FCC's epaulets and badge, along with its right to serve as what General Counsel Austin Schlick called "the cop-on-the-beat for 21st Century communications networks."
"Does the FCC still have a mission in the Internet area? Absolutely. The nation's broadband networks represent the indispensable infrastructure for American competitiveness and prospects for future job creation, economic growth, and innovation," Schlick wrote. "The Court did not adopt the view that the Commission lacks authority to protect the openness of the Internet."
Actually, it did. Specifically, the DC Court took the FCC to the proverbial woodshed for presuming that when Congress -- or, more accurately, specific congresspersons -- set policy guidelines rather than made legislation, the Commission could assume those guidelines to be a congressional mandate. The Court cited a 1976 case concerning the National Association of Regulatory Utility Commissioners (NARUC), where the same DC Court overturned the same FCC's authority to regulate how utility companies could make use of the then-nascent digital capabilities of cable TV lines to report, for example, electricity consumption. The FCC could not, the Court found, regulate the use of a medium outside of its mandate for communications. The Court also cited three other significant cases, including some in which it found in the FCC's favor, which are introduced in Betanews' story yesterday.
...Unlike the way it successfully employed policy statements in Southwestern Cable and Midwest Video I, the Commission does not rely on section 230(b) [of the Communications Act of 1934] or section 1 [of the portion of the Act that created the FCC] to argue that its regulation of an activity over which it concededly has no express statutory authority (here Comcast's Internet management practices) is necessary to further its regulation of activities over which it does have express statutory authority (here, for example, Comcast's management of its Title VI cable services). In this respect, this case is just like NARUC II. On the record before us, we see "no relationship whatsoever"...between the Order [regulating Comcast] and services subject to Commission regulation. Perhaps the Commission could use section 230(b) or section 1 to demonstrate such a connection, but that is not how it employs them here.
Instead, the Commission maintains that congressional policy by itself creates "statutorily mandated responsibilities" sufficient to support the exercise of section 4(i) ancillary authority. Not only is this argument flatly inconsistent with [the four key cases establishing ancillary authority, see Betanews' Thursday story], but if accepted it would virtually free the Commission from its congressional tether. As the Court explained in Midwest Video II, "without reference to the provisions of the Act" expressly granting regulatory authority, "the Commission's [ancillary] jurisdiction...would be unbounded."...Indeed, Commission counsel told us at oral argument that just as the Order seeks to make Comcast's Internet service more "rapid" and "efficient"...the Commission could someday subject Comcast's Internet service to pervasive rate regulation to ensure that the company provides the service at "reasonable charges"...Were we to accept that theory of ancillary authority, we see no reason why the Commission would have to stop there, for we can think of few examples of regulations that apply to Title II common carrier services, Title III broadcast services, or Title VI cable services that the Commission, relying on the broad policies articulated in section 230(b) and section 1, would be unable to impose upon Internet service providers. If in Midwest Video I the Commission "strain[ed] the outer limits of even the open-ended and pervasive jurisdiction that has evolved by decisions of the Commission and the courts"...and if in NARUC II and Midwest Video II it exceeded those limits, then here it seeks to shatter them entirely.
This is easily the strongest language to date from the DC Court on the limits of the FCC's regulatory powers. Essentially, the Court is saying that the FCC cannot accept Congress' request for it to build a Broadband Plan for the nation (as well as to decide what "broadband" really means anyway) as justification for telling Comcast it can't throttle BitTorrent downloads.
Which is why yesterday afternoon's response from the FCC's Schlick is so astonishing. Blatantly, Schlick's post states that the Court's ruling has only limited effect on the Broadband Plan, which he characterizes as a new kind of mandate. And just who granted the Commission that mandate? Why, Congress, of course, in its request for it to produce the Broadband Plan:
In 2009, Congress directed the agency to develop a plan to ensure that every American has access to broadband. Just three weeks ago, the Commission released its National Broadband Plan. The Plan contains more than 200 recommendations for bringing high-speed service to underserved individuals and communities, and using broadband to promote American competitiveness, education, healthcare, public safety, and civic participation.
The Comcast/BitTorrent opinion has no effect at all on most of the Plan. Many of the recommendations for the FCC itself involve matters over which the Commission has an "express statutory delegation of authority." These include critical projects such as making spectrum available for broadband uses, improving the efficiency of wireless systems, bolstering the use of broadband in schools, improving coordination with Native American governments to promote broadband, collecting better broadband data, unleashing competition and innovation in smart video devices, and developing common standards for public safety networks.
Next: After Comcast, the FCC sets its scopes on Verizon...
In a ceremonial flexing this morning of a muscle the Court said the FCC shouldn't have, Commission Chief of Staff Edward Lazarus posted a blog entry taking Verizon CEO Ivan Seidenberg to task for comments he made last Tuesday in a speech to the Council on Foreign Relations. In recent months, the FCC has suggested the presence of a looming spectrum crisis, citing recent comments from attorneys and executives of Verizon's rival AT&T, warning of an apocalyptic event some call the exaflood. In that terrible time, demand for bandwidth would become so huge that the Internet would literally run out of spectrum like a desert lake runs out of water.
The Commission had been leveraging those warnings to make its case for potentially reclaiming bandwidth from US broadcasters and repurposing it for wireless Internet communications. For their part, broadcasters argue they may still make use of unused spectrum allocated to them, perhaps for becoming Internet service providers themselves.
But in his speech Tuesday, Verizon's Seidenberg said there was no such crisis on this, or potentially any, horizon. He used that proclamation as leverage for Verizon's ongoing argument that technology problems are best resolved by market forces rather than by regulation.
"Now, of course, if I took the self-serving approach, it would be okay, screw the broadcasters. Let's get their spectrum and we can put it to use in our wireless and cellular business or broadband business," said Seidenberg in response to a question from the audience. "My reaction is going to surprise you. I don't think the FCC should tinker with this. I think the market's going to settle this. So in the long term, if we can't show that we have applications and services to utilize that spectrum better than the broadcasters, then the broadcasters will keep the spectrum.
"Cable companies have bought spectrum over the last 10 or 15 years that's been lying fallow. They haven't been using it," the Verizon CEO continued. "So here the FCC is out running around looking for new sources of spectrum, and we've got probably 150 MHz of spectrum sitting out there that people own that aren't being built on. I don't get that. This annoys me...Not to leave the broadcasters out of the debate, there are lots of issues that we have with retransmission and things of that nature we need to solve. But basically, confiscating the spectrum and repurposing for other things, I'm not sure I buy into the idea that that's a good thing to do."
But is there a spectrum crisis looming, the questioner persisted? Sure, responded Seidenberg, if we decide to put the equivalent of a transmission tower in everyone's back pocket: "If video takes off, could we have a spectrum shortage in five or seven years? Could be, but I think that technology will tend to solve these issues. And...I happen to think that we'll advance fast enough that some of the broadcasters will probably think, let me cash out and let me go do something different. So I think the market will settle it. So I don't think we'll have a spectrum shortage the way this document [the Broadband Plan] suggests we will."
The FCC's Lazarus saw Seidenberg as somewhat of a turncoat, abandoning what he had thought was a team effort to prove a spectrum crisis existed. Citing prior efforts by Verizon to promote the identification of new spectrum that could be allocated for broadband, Lazarus wrote, "The recent statements by Verizon's CEO are rather baffling. The fact is, Verizon played a major role in building an overwhelming record in support of more mobile broadband spectrum, consistently expressing its official view that the country faces a looming spectrum crisis that could undermine the country's global competitiveness...The National Broadband Plan record contains widespread agreement and a solid foundation of factual evidence on the need for the FCC to pursue policies that would free up 500 MHz for mobile broadband by 2020. We hope to work with Verizon and other companies across the communications sector on ways to achieve the important goal of ensuring that the United States has world-leading mobile broadband infrastructure."
In other words, hopefully Verizon will come back around and rejoin the Plan, writes Lazarus. In recent months, the FCC had used the spectrum crisis as a way of tying the Internet to the concept of the airwaves (which the FCC does regulate statutorily) as opposed to private pipelines (which it does not). If it could focus public attention on the airwaves and wireless as the homebase of the Internet, then it could prove it has more than ancillary authority to serve as its "cop-on-the-beat." But that argument may have already been choked off earlier this week.
Any authority for the FCC to regulate the Internet directly will need to be mandated by Congress, and not with existing law but with new law. Any effort to produce that new law will inevitably confront opponents sounding the battle cry against "big government." Market forces, unfortunately, will not resolve that looming crisis.
Copyright Betanews, Inc. 2010
Apple shows developers the money

Publié: avril 9, 2010, 2:04am CEST par Joe Wilcox

By Joe Wilcox, Betanews

Earlier today, Apple unveiled its iAd advertising platform as part of iPhone OS 4. Over the next couple of days pundits will rail about Apple competing with Google in advertising. As I explain in the previous post, "Clash of the titans: Apple, Google battle for the open Web," there is a more fundamental, worldview war underway. Apple isn't trying to compete with Google so much as make its mobile platform more appealing. The right approach is simple: Make lots of people rich.
Apple is building out a mobile platform around iPhone OS and extended services. There are right ways to make a platform more appealing, and Apple did just that with today's announcement. Successful platforms share five common traits:
1) There are good development tools and APIs for easily making good applications. 2) There is at least one killer application people really want. 3) There is breadth of useful applications. 4) Third parties make lots of money. 5) There is a robust ecosystem.
The fourth of these characteristics is the most important. No matter how good the platform, third parties will only support it if they can make money. The classic competing example is Apple versus Microsoft in the 1980s and 1990s.
Apple retained tight control over its operating system, while Microsoft licensed DOS and later Windows. Microsoft's approach allowed a huge ecosystem of hardware manufacturers, resellers and software developers to make money. Large businesses saved millions of dollars deploying PC hardware and software (instead of mainframes and terminals) and later generated revenue from new business processes and efficiencies. More third parties made more money supporting Microsoft's platform than Apple's. It's the fundamental reason why the Macintosh lost the PC wars in the 1980s and early 1990s.
There is a sixth attribute that follows the other five: Scale. Once there is enough third-party support, the platform and extended ecosystem rapidly scales, such that it's like a tsunami washing away any competitors. From that point, there no longer is choice. Developers will create software and consumers and businesses will buy into the platform. More for businesses than consumers, there also comes a point where it costs more to switch than to stick with the platform. This describes the state of Microsoft's Office-Windows-Windows Server platform.
Apple's app store/iPhone OS platform is remarkable for how quickly third parties supported it, how rapidly they made money from it and how suddenly there is scale -- at least around applications. The hardware numbers are good but not great, nearly 86 million iPads, iPhones and iPod touches sold combined. There is no single reason for Apple's mobile success although products and services released in 2001 are foundational to much of Apple's late-Noughties gains.
Logistically, Apple started with the same platform approach that failed in 1980s and 1990s but reimaged it for the 2000s. Like Macintosh, with iPhone, Apple maintains tight control over hardware, software and services. But the company did much better offering an appealing platform for developers and mobile device buyers. Something else: No Microsoft monopoly. Apple didn't have to compete with an entrenched incombent on handsets the way it did on personal computers. The phone market is highly fragmented (even among Nokia handsets).
The strategy worked in part by building in a direct mechanism by which developers could make money. Apple provided in App Store ways for developers to easily distribute software, to get paid for their apps and to protect them from rampant piracy. Flipped around, consumers can easily buy, sync and pay for the applications.
Until today, iPhone OS developers sold their applications or gave them away for free. The problem with free is free. How do developers make money from free stuff? With iAd, Apple will provide developers another way to monetize their applications, which will be more important to content publishers like the New York Times or to developers giving away stuff for free.
"These developers have to find a way to make some money, and we'd like to help them," Apple CEO Steve Jobs said during today's iPhone OS 4 launch event.
As I explain in the companion post, built-in advertising isn't direct competition to Google. Apple's iAd is confined to its mobile platform. However, Apple is offering developers even more ways to make money and on a platform already highly scaled. During today's iPhone OS 4 event, Hasan Ahmad tweeted to me: "iAd demo -- All Android developers just packed their bags and went for the iPhone." If he's right, they'll be looking for the money.
Copyright Betanews, Inc. 2010
Clash of the titans: Apple, Google battle for the mobile Web

Publié: avril 9, 2010, 1:25am CEST par Joe Wilcox

By Joe Wilcox, Betanews

Today marks the beginning of the great Apple-Google war. Contrary to what some other people will write, it's not advertising competition but something more fundamental. This clash of the titans is about competing worldviews -- whether the future mobile Web will be about the browser or applications.
There have been skirmishes over these opposing worldviews, but Apple's iAd platform is finally a declaration of war -- not because it could compete with Google's search-based advertising platform but because it provides a better way for mobile applications to make money. Somebody has to pay for all those free mobile apps. Apple will offer developers the advertising platform and give them a 60-percent cut.
Worldviews Apart
Businesses fundamentally seek to make money, but corporate cultural worldviews determine the means. Terms like philosophy or principles are often overlooked by bloggers or journalists writing about corporations and competition among them. Perhaps these concepts are more the study of academics, but they shouldn't be. These operational principles overreaching corporate philosophies shape the worldviews the companies bring to the marketplace.
In December 2009 post "Google's 'Open' definition: Simply brilliant business, but is it evil?" I explained the differences between Google and Microsoft worldviews. Quickly recapping, Microsoft's model presumes that companies produce something and are paid for it. The thing produced belongs to the producer. By comparison, Google's so-called "open" model presumes everything should be free, around which third parties profit indirectly and from things they didn't necessarily create or control.
The Apple-Google worldview clash is similar but different. Like Microsoft, Apple's business is about platforms and applications. Google's business is about information and services. Apple profits directly from products it develops and sells to businesses or consumers. Google mostly profits indirectly from content or information someone else created. Its intellectual property is tied to the means, not the end.
In approaching the mobile Web, Apple leverages its strengths as an end-to-end hardware/software developer. By comparison, Google already offers services in the cloud via the browser. Apple's worldview is more applications-centric while Google's is more Web-centric. Apple wants to pull computational and informational relevance to applications, while Google seeks to shift relevance to the Web.
The Problem with Free is Free
Where these two worldviews clash is the mobile device, such as the smartphone. HTML5 promises rich Internet applications consumable in a browser, which favors Google's worldview and search-and-advertising business model. Mobile applications favor Apple, which tightly controls the hardware-software platform -- and applications development by the APIs it chooses to expose and the terms dictated to developers.
By comparison -- and only by comparison -- Apple's mobile platform is fundamentally more closed than Google's. Apple's platform is narrow, built around devices, software and services it controls. Google's platform is deep, with search and advertising services spanning the Web and an open-source mobile operating system (Android). Google has built a huge economy around search, keywords and advertising.
Until today, iPhone OS developers sold their applications or gave them away for free. The problem with free is free. How do developers make money from free stuff? There is no pervasive Google search and advertising economy on iPhone OS devices, because most of the activity takes place in applications not in the Web browser. Apple tightly controls the applications stack, which is a Google-free zone. With iAd, Apple will provide developers another way to monetize their applications, which will be more important to content publishers like the New York Times or to developers giving away stuff for free.
Apple is not interested in the browser-centric mobile Web, regardless of Safari's presence. During the Q&A following today's iPhone OS 4 event, Apple CEO Steve Jobs affirmed there would be no support for Adobe Flash or for Java. Their absence reflects Apple's app-centric approach. Flash and Java belong in the Web-centric world, and Flash is a developer platform. Apple doesn't want competition from another development platform on iPhone OS devices. The application-centric mobile Web keeps Apple in control.
Closed vs Open Approaches
In his April 2 post "Why I won't buy an iPad (and think you shouldn't, either)", Cory Doctorow astutely identifies what's wrong with Apple's mobile platform: It's closed. He writes about Apple's content lockdown:
For a company whose CEO professes a hatred of DRM, Apple sure has made DRM its alpha and omega. Having gotten into business with the two industries that most believe that you shouldn't be able to modify your hardware, load your own software on it, write software for it, override instructions given to it by the mothership (the entertainment industry and the phone companies), Apple has defined its business around these principles. It uses DRM to control what can run on your devices, which means that Apple's customers can't take their 'iContent' with them to competing devices, and Apple developers can't sell on their own terms.
From earlier in the post:
What does Marvel do to 'enhance' its comics [on iPad]? They take away the right to give, sell or loan your comics. What an improvement. Way to take the joyous, marvellous sharing and bonding experience of comic reading and turn it into a passive, lonely undertaking that isolates, rather than unites. Nice one, Misney.
By comparison, Google's worldview favors a more open approach to content, information availability and software and services development. The Google free economy (supported by search, keywords and advertising) has turned my industry, journalism, on its head (Man does that hurt!). But information remains free. Rich Internet Applications consumable in any browser are freely available. Software development and cloud services use more open standards and development tools. The majority of this kind of Internet, in its mobile form, is consumed in the Web browser -- even as applications' role increases on Android and competing handsets.
So, Apple and Google mobile device worldviews differ in two fundamental ways: Closed/tightly controlled versus more open/loosely controled and applications versus browser centricity.
Which platform wins remains uncertain, despite all the hobgoblining around from Apple defenders insisting it will be iPad/iPhone/iPod touch. There also are hints Google is directionally changing towards Apple. Google is unifying applications and services and offering more mobile apps for different mobile platforms. Google also is integrating apps and services around Android handsets. The winning platform, if one is to dominate will make lots of people rich. While I've focused here on Apple and Google as titans, Nokia is still the reigning mobile device maker by a huge margin, Research in Motion dominates the smartphone market and Microsoft is plotting a comeback. There are plenty of platforms in play, but Apple and Google are the most opposing.
Copyright Betanews, Inc. 2010