Category Archives: open source

Users petition Asus over locked bootloader in Asus Transformer Prime

The new Asus Transformer Prime TF201 Android tablet is winning praise for its performance and flexibility. It is driven by NVIDIA’s quad-core Tegra 3 processor and can be equipped with a keyboard and dock that extends battery life and makes the device more like a laptop.

All good; but techie users are upset that the bootloader is encrypted, which means the kernel cannot be modified other than through official Asus updates.

A petition on the subject has achieved over 2000 signatures. Detailed discussion of the implications are here.

image

Why do vendors lock the bootloader? One reason is for support, since it increases the user’s ability to mess up their machines. On the other hand, most users who hack to this extent understand what they are doing. This comment from the petition stood out for me:

We understand that custom firmware cannot be supported by ASUS, but we consider that it is our right to customise our devices in any way we wish: once bought, the Prime is our property alone to modify if we choose.

This is something we have taken for granted in the PC era, but the tablet era is looking different, with locked-down devices that give vendors more control. The success of the Apple iPad suggests that most users do not mind if the result is a good experience. It is a profound change though, and one that makes users vulnerable to vendors who are slow or reluctant to provide updates.

Android: good or bad for Java? Oracle claims harm but I am sceptical

Patent blogger Florian Mueller quotes a statement filed by Oracle in its legal dispute with Google over its use of the Java language in Android:

Android’s growth in the mobile device market has been exponential, steadily diminishing Java’s share. For instance, Amazon’s newly-released Kindle Fire tablet is based on Android, while prior versions of the Kindle were Java-based. Android has been gaining in other areas as well, with Android-based set-top boxes and even televisions appearing this year. These are markets where Java has traditionally been strong but is now losing ground to Android. The longer Android is allowed to continue fragmenting the Java ecosystem, the more serious the harm to Java becomes, and the more difficult it is to try to unwind. Oracle suffers harm in the form of lost licensing opportunities for its existing Java platform products, and the enterprise-wide harm from fragmentation of Java, which reduces the ‘write once, run anywhere’ capability that has historically provided Java such great value.

The Kindle is an interesting example. I had not realised that the pre-Fire Kindle runs Java, but Oracle shows it as a case study and indeed, here are the javadocs.

Android infuriates Oracle because it uses the Java language, but has its own virtual machine called Dalvik. Dalvik bytecode is different from Java bytecode.

I have no expertise on the legal position, but while I can see Oracle’s point it is also true that Android has greatly boosted interest in Java development. Although Google has fragmented Java, the fact that the language is the same benefits Oracle insofar as it increases the pool of Java developers who may also be inclined to create Java applications on the server or in other contexts.

The interesting question to ask is where Java would be without Android. On mobile, it would likely be close to death. Apple’s iOS platform is equally as resistant to Java as to Adobe Flash. RIM Blackberry used to be a Java platform, but is moving away:

While we will continue to support our BlackBerry Java developer community as they build for BlackBerry smartphones, after further investigation we decided against supporting BlackBerry Java on BlackBerry BBX. We concluded that the BlackBerry Java experience on the BlackBerry PlayBook platform would ultimately not satisfy us, our development community, or our customers as the platform continues to evolve.

Microsoft has no interest in Java on the Windows Phone OS or in the Windows 8 OS that will likely replace it on devices.

Oracle’s claim is in the context of a legal dispute, and as Mueller observes, the company is happy to show off growing interest in Java in its press releases – though without mentioning the A word.

Of course you can understand why Oracle might want to enjoy the benefit of Java’s Android boost as well as the reward of a legal victory over Google.

PS: interesting that Oracle’s Java press release seems to be served by Microsoft .NET:

image

HP contributes webOS to open source. Where next for HP mobile devices?

HP has announced that webOS, the mobile operating system acquired with Palm, will become an open source project:

HP will make the underlying code of webOS available under an open source license. Developers, partners, HP engineers and other hardware manufacturers can deliver ongoing enhancements and new versions into the marketplace.

HP will engage the open source community to help define the charter of the open source project under a set of operating principles:

  • The goal of the project is to accelerate the open development of the webOS platform
  • HP will be an active participant and investor in the project
  • Good, transparent and inclusive governance to avoid fragmentation
  • Software will be provided as a pure open source project

Despite the upbeat language, the fact that HP does not state that it will actually manufacture any webOS devices suggests that this is more a retreat than an advance. What kind of investment will HP put into webOS, if it is not selling devices?

Another problem is that Google Android is doing a great job meeting the demand for a freely available and mostly open source mobile operating system, leaving little space for other projects such as webOS or the Intel-sponsored MeeGo.

The question that interest me: where will HP now go with its mobile devices? There are several possibilities. It could do nothing, and focus on servers and PCs, thereby missing out on what is potentially a huge market. It could throw its hand in with Microsoft, with Windows 8 tablets sometime next year, and maybe some future version of Windows Phone. Or it could embrace Android, which still seems to have unstoppable momentum despite poor sales for most Android tablets.

Sencha’s Michael Mullany talks about Flash developers “flailing around for an alternative” and the Big App Rewrite

I spoke to Michael Mullany, CEO of Sencha, a company which creates HTML5 frameworks and tools for desktop and mobile browsers. Ext JS is aimed at desktop browser applications, while Sencha Touch is for mobile devices, currently Apple iOS, Google Android and Blackberry 6+. Sencha’s tools include Ext Designer, a visual application builder for Ext JS, and Sencha Animator, a designer for CSS 3 animations. Sencha Touch apps can also be packaged as native apps for iOS or Android.

At its developer conference in Austin USA earlier this month, attended by around 600, the company announced Sencha.io, a cloud service for mobile web apps, as well as presenting Sencha Touch 2.0, a major update.

image

Mullany talks on his blog about “The Big App Rewrite”:

It’s a world where HTML5 powers the client apps, and they’re enriched with local APIs that execute on everything from traditional desktops to Smart TV’s. And cloud services provide the fabric that enables continuous, shared experiences across the diversity of end-devices. We think this is the platform for the web.

Sencha is perfectly in tune with the trends towards cloud, HTML5 and mobile, which is why I was keen to speak to Mullany. I asked him to contrast Ext JS and Sencha Touch with JQuery and JQuery Mobile.

JQuery is a pretty tiny library that helps with Dom abstraction and animations but that’s it. JQuery UI gives you some visual components as well but Ext-JS is the full enchilada. It’s supposed to be the web equivalent of Cocoa or the Microsoft Windows presentation foundation. It’s got an event system, a theming system, a very rich set of user interface controls, its object oriented, and it’s got a complex layout system so you can build nested layouts that have very complex event handling among different parts of the user interface. We’ve seen user interfaces that have several thousand data elements on a page.

It also has a model-view-controller architecture library on the client side so you can structure your code properly for large applications, it’s got a theming system so you can variable-ise your colours, shapes and look and feel very easily. It also has a full data package so you can do very rich data manipulation on the client, bind data in various complex ways across variables, it’s very different than J query.

And just like you’d probably never use Ext-JS on a public web page, you’d never use JQuery to build something like Marketo or Salesforce VisualForce or a Documentum content management system, all of which use Ext-JS. Ext-JS is one of the most popular behind the firewall development libraries for desktop development.

Now on the mobile side the difference is slightly less. JQuery mobile does give you a set of user interface widgets, but the difference is also similar to the desktop … Sencha Touch is designed to let you do anything you could do with Cocoa Touch or an Android SDK or a Windows Mobile SDK. Its intent is to equip you to develop native quality experiences with native style interaction, things like fixed user interface chrome, multiple independent scrollable areas, nested layouts, those kinds of capabilities.

Our performance tends to be better cross-platform, we’ve done more performance work, we have our theming system, we have an MVC library, we have a templating system. With JQuery mobile you tend to want to add multiple things together and you can certainly assemble a collection of things that will look like Sencha Touch, but Sencha Touch is designed to be integrated, everything is designed to work the same, and the general feedback is that even though Sencha Touch is a much richer system that takes some insight to learn, you get better applications out of it.

I also asked about the new cloud service, Sencha.io. A notable feature is that according to Mullany developers do not have to touch the code that runs on the cloud, they just call its API from the client:

We call it the first client-centric HTML5 cloud, which is a set of authentication, data, data synchronisation, and geo-location services that help people build mobile applications without needing to write server side code. So you literally write your client side application in HTML 5 using Sencha SDKs and then you store your user’s data and you store your user’s authentication credentials in our cloud. You don’t have to worry about mucking around with anything from Ruby on Rails to PHP to Java, it’s all abstracted behind these very clean APIs. We think that’s the future of mobile development, that you’ll have these very thin abstracted server-side services, and and these very rich mobile clients that have off-line state and local data storage powered by HTML5. We think that model is the future of mobile web development and we obviously hope that Sencha.io will be the most popular back-end.

Sencha’s frameworks are open source and dual-licenced. You can use both Touch and Ext JS freely under the terms of the GPL v3. There is also free commercial licencing for Sencha Touch, while commercial licences for Ext JS are paid for. Sencha also has commercial tools, and I asked Mullany to describe the tool products:

We really see the three legs of the business being cloud, tools, and SDKs. We just did a preview of the Sencha Designer 2.0 release at our conference. That has support for Sencha Touch in it so you can drag and drop Sencha touch applications together and then actually package them from within the tool. The intent is also to allow you to hook up to cloud APIs from within the tool as well so it is an integrated, easy-to-use visual application builder for both desktop and touch. So that’s targeted at developers.

Sencha Animator is a little bit different. There’s no JavaScript in it really at all. It is a pure CSS 3 animation tool, and it is a traditional visual timeline with keyframe manipulation, and a style visual editor for creating rich animations.

The market we’re targeting for that is people doing interactive brand advertising on mobile. That’s where you have ubiquitous support for CSS 3 animations that are hardware accelerated so they tend to be the best performance. It’s also very web content friendly so you don’t have to write your application in Sencha Touch just to use Animator, it’s pure CSS output that you drop into whatever piece of content that you want to build.

The reason we built it is because we saw people flailing around for an alternative to doing Flash ads on mobile. Because Flash was banned from iOS, it meant that a whole segment of rich advertising that was based on Flash for the desktop had nowhere to go. They weren’t going to build native iOS applications, it had to be web. So the question then was what do you build it in, do you use JavaScript animation, do you use SVG, do you use Canvas, do you use some of the other graphic technologies such as Web GL? The answer is that CSS 3 is really the highest performance and cognitively pretty easy to wrap your head around.

People “flailing around for an alternative to doing Flash ads?” Mullany has his own agenda, but his comments do highlight the problems caused for Adobe by the success of Flash-free iPhone and iPad. I cannot help thinking that Sencha would be an attractive acquisition for Adobe or certain other companies, but I am sure smarter people than myself have thought of that.

Post sponsored by Monster for the best in IT jobs.

Adobe’s Falcon JS: Compile Flex code to HTML and Javascript

Adobe has issued further information about its intention to donate the Flex SDK, which builds Flash applications from XML and ActionScript, to the Apache Software Foundation. Specifically, the donation will include:

  • BlazeDS, the free version of LiveCycle Data Services
  • Falcon, the new Flex compiler due to be completed in 2012
  • Falcon JS, a previously unannounced project

Of these, Falcon JS is the most eye-catching. This is an “experimental cross-compiler from MXML and ActionScript to HTML and JavaScript.” In other words, Falcon JS has the potential to give developers a migration path from Flash to HTML clients. Note that it is described as a cross-compiler rather than a porting tool, so it may well be that the output is not easily edited. The Google Web Toolkit works like this, converting Java to JavaScript but not in a form that anyone is expected to edit. Adobe also adds:

We have undertaken some experimental work in this area, but remain unsure as to the viability of fully translating Flex-based content to HTML. The Falcon JS cross-compiler, referenced above, represents this early work.

What about the most sensitive of Adobe’s statements, that HTML is the long-term solution for enterprise applications? Adobe says:

In time (and depending upon your application, it could be 3-5 years from now), we believe HTML5 could support the majority of use cases where Flex is used today.

and adds:

We intend to make investments in HTML-related technologies, so that we can help advance HTML5 to make it suitable for enterprise applications.

I am not sure to what extent the new statement will ease the worries of Flex developers; but at least Adobe is clear about its intentions. While there are benefits in the Flex SDK moving to Apache, overall the message is that Adobe is hastening towards HTML 5. I am surprised, considering the progress the company has made in creating a strong cross-platform toolkit for mobile and desktop applications. Although no-one should doubt that Adobe will continue to support and evolve Flex as a development platform, it has in effect declared it to be a legacy technology, and I would guess that the effect will be to depress the level of activity there.

Adobe favours HTML over Flex, retreats from its enterprise app platform

Adobe has stated that Flex, the xml-based language for developing applications that run on the Flash runtime (also known as AIR) will gradually give way to HTML 5:

In the long-term, we believe HTML5 will be the best technology for enterprise application development. We also know that, currently, Flex has clear benefits for large-scale client projects typically associated with desktop application profiles.

The company is also giving the Flex SDK to an open source foundation:

we are planning to contribute the Flex SDK to an open source foundation in the same way we contributed PhoneGap to the Apache Foundation when we acquired Nitobi.

though Adobe will continue to contribute to its development. Adobe also states that it will continue to develop the Flash Builder IDE for Flex.

I am surprised by this announcement. I understand Adobe’s reasons for abandoning Flash for mobile devices, but since you can use Flex with the packager for iOS or the captive runtime for other mobile devices, it is not necessary to abandon Flex as well.

But is Adobe abandoning Flex? Not as such; in fact the statement linked above says that Adobe is still “committed to Flex” and “committed to Flash Builder”. The problem though is that there are several clues showing that Flex is in decline and no longer strategic.

First there is the statement about HTML5 versus Flex in the long-term.

Second, Adobe says it is not sure what is happening to the Flex roadmap as discussed recently at the MAX conference in Los Angeles:

The Flex roadmap will be determined by the governing board once it’s been established. We plan to contribute framework features previously highlighted as part of Adobe’s Flex roadmap, into this new project.

Third, the delivery of a project to an open source foundation can be interpreted as a signal that a company wants  to distance itself and lacks commitment to its long-term success. I would not make that argument with respect to PhoneGap, but for Flex I am not so sure.

It may already be too late. Imagine you are an Adobe partner trying to sell a Flex project to your customer. What answer do you have when your customer says, “but isn’t Adobe moving to HTML 5?”

When Adobe made its first announcement about the change in its business model I came up with the phrase more publishing, less programming. That view was further strengthened by CEO Shantanu Narayen’s recent post:

The future of the Internet comes down to content – creating it and monetizing it. This is where our customers rely on Adobe, and it’s what is shaping our strategy moving forward.

I take this then as not only a retreat from Flex, but a retreat from enterprise application development in favour of content creation tools.

Charles Humble at InfoQ has an informative post on this issue here.

Subversion 1.7 released: just one .svn directory per working copy

Yesterday saw the 1.7 release of Subversion, the widely used open source version control system. It is a significant release with many new features, bug-fixes and performance improvements, and I suggest reading the release notes or complete change log. One thing to highlight is that the default working copy metadata storage is now a single sqlite database per working copy, rather than a .svn direction containing metadata in sub-directory.

I upgraded my TortoiseSVN, which is already updated to 1.7, and tried upgrading one of my own projects. Here is the .svn folder before the upgrade:

image

and after

image

Those pesky .svn folders can be a nuisance so this is a welcome change, although there is a downside as the release notes warn:

It is not safe to copy an SQLite file while it’s being accessed via the SQLite libraries. Consequently, duplicating a working copy (using tar, cp, or rsync) that is being accessed by a Subversion process is not supported for Subversion 1.7 working copies, and may cause the duplicate (new) working copy to be created corrupted.

Subversion is less fashionable since the advent of distributed version control systems like git and mercurial; though for corporate development Subversion remains popular because a centralised system is easier to control.

WANdisco’s Jessica Thornsby has a helpful post on the new 1.7 features more details on the benefits of the new working copy metadata managements system.

Google offers the web a new language called Dart – but why?

Google has announced an early preview of Dart, a new language for web applications. The news is not a surprise, especially if you have been keeping track of the developer conference GOTO Aarhus, whose organisers had pre-announced that Google would be announcing its new language there, as indeed it did.

image

Dart is a curly-brace language like JavaScript, Java, C, C++ and C#. In Dart, as in C# and Java, a class can implement multiple interfaces, but only inherit from a single class. Dart supports both static and dynamic typing. Google says it can be executed by a Dart VM, or converted to JavaScript:

Dart code can be executed in two different ways: either on a native virtual machine or on top of a JavaScript engine by using a compiler that translates Dart code to JavaScript. This means you can write a web application in Dart and have it compiled and run on any modern browser. The Dart VM is not currently integrated in Chrome but we plan to explore this option.

Google also says that you will be able to “execute Dart code directly in a VM on the server side”, so you can infer that Google has Dart in mind as an alternative PHP as well as to JavaScript. The company is using the phrase “structured web programming” to describe Dart, and this phrase appears in the announcement and as the subtitle on the Dart site. The implication is that JavaScript code tends to be poorly structured and that Dart will promote more maintainable code.

In the preview Dart only runs in Chrome, Safari 5 and Firefox 4+ – spot the missing browser vendors.

At first glance, Dart looks like a promising language, though I find myself asking what it is really for, when it bears a strong family resemblance to existing languages, and bearing in mind that the Google Web Toolkit, which compiles Java to JavaScript, already enables structured programming for web applications. The list of problems which Dart solves in the technical overview is not all that compelling.

Google states that:

Developers have not been able to create homogeneous systems that encompass both client and server, except for a few cases such as Node.js and Google Web Toolkit (GWT).

This is or was one of the attractions of Microsoft Silverlight, presuming you use C# on both server and client, but Silverlight is a plug-in that was never going to run on an iPad and from which Microsoft itself is now retreating; though it is worth noting that Dart is not unlike C#, especially the latest version of C# with dynamic features.

I guess that Dart is a consequence of the failure of ECMAScript 4.0, which was a cooperative effort to create a more modern and advanced JavaScript. Google is now going it alone; the key question is whether it can win support from others such as Apple and Microsoft, or whether this will be a Google language for Google on the server and Chrome on the client, or an interesting experiment that never really catches on.

Do we need Dart? I would value hearing from others what you think of Google’s proposal.

Adobe acquires PhoneGap company Nitobi

Adobe has announced the acquisition of Nitobi, the company which created and sponsors the open source PhoneGap project for creating cross-platform mobile applications using HTML5 technology.

Apparently this does not affect the plan to donate PhoneGap to the Apache Software Foundation:

We are also excited to announce our donation of the PhoneGap code to the Apache Software Foundation,” said Dave Johnson, chief technology officer, Nitobi. “Adobe has been fully supportive of our decision.

Adobe already offers PhoneGap integration in Dreamweaver 5.5, though I found some gaps in this initial release.

I spoke to Nitobi CEO André Charland earlier this year.

Smart move, though it will be interesting to see how Adobe now balances mobile app development with PhoneGap vs mobile app development with Flash – both of which are cross-platform approaches.

Here at Adobe’s MAX conference in Los Angeles I will be quizzing Adobe about how it plans to evolve its design and development tools to better support PhoneGap.

PhoneGap likely to move to Apache Software Foundation

Nitobi’s Brian LeRoux, who works on PhoneGap, has announced the start of a process to move the project to the Apache Software Foundation:

We have initialized the process to contribute PhoneGap to the Apache Software Foundation (ASF). The process is straightforward beginning w/ a submission of a proposal to the ASF that describes the move in detail. We’ve been looking at different options for a foundation contribution since the beginning. Now is the time. PhoneGap is hugely adopted and the IP belongs in an org aligned w/ our goals, philosophy and the web. It will remain free software, licensed as it always has been: Apache/BSD/MIT.

Apparently the name may change thanks to a trademark dispute.

PhoneGap seems to have plenty of momentum and is turning up in a variety of tools, including Adobe DreamWeaver and Embarcadero RAD PHP XE2, to mention two I am aware of.