With the recent introduction of Ubuntu Touch a very interesting change of strategy is emerging for Canonical.
As Phoronix and others have discovered, Ubuntu Phone and Touch are using SurfaceFlinger as their compositor. SurfaceFlinger uses OpenGL ES to render applications screens/windows in a hardware accelerated way using the OpenGL driver of the GPU directly.
Now, Canonical is promising a completely integrated experience for Ubuntu 14.04 which will run Phone, Touch, TV and Desktop applications in one common GUI environment. How will they be able to fulfill their promise for Linux desktop applications currently running on Xorg?
So far, everyone has believed that the Ubuntu desktop is migrating from Xorg to Wayland. This migration has been going so slow that there is actually no visible sign of happening any time soon. It seems that Canonical has slightly changed the “to” part of their migration plans. They are not moving to Wayland, they are moving to SurfaceFlinger.
I, for one, think that this is a brilliant idea.
Compared to Android’s SurfaceFlinger, Wayland has not much appeal from the “possible benefits” point of view. SurfaceFlinger is developed by Google and is already deployed on countless Android devices. It has a sizable amount of developers working on it and its future is certain as long as Android is with us (which is pretty likely given its current market share and trends). Migration to Wayland hasn’t started in earnest so there would not be much effort thrown out of the window.
With the recent merging of the Android and the mainline Linux kernels, porting Linux desktops to Android hardware has already become somewhat easier. Wifi, Bluetooth and other hardware components can be accessed through the Android kernel released by the producer of the SOC/board. The biggest remaining problems are making Xorg and audio working. Xorg is used by all desktop applications while audio is used by only some (media players, screen-capture apps…etc). Xorg seems to be a fairly big problem because Android hw producers usually don’t provide X drivers at all and that makes the porting effort a show-stopper for hardware which otherwise run Android very well.
An Ubuntu desktop running on SurfaceFlinger would be a much easier subject for porting to common Android hardware compared to the current situation (as the quickly growing number of devices supporting Ubuntu Touch demonstrates this spectacularly). OpenGL ES driver comes with the Android kernel, released by the hw manufacturer, so SurfaceFlinger works right-away.
The most important part of the migration to Wayland has been the GTK and Qt backend implementations. These can also be created relatively quickly for SurfaceFlinger so 90% of the standard Linux apps would display on it right away (Qt may already has Android/SurfaceFlinger support based on their Git repository)
OK, but SurfaceFlinger is only one part of the problem, what about the rest?
It is very much possible that Canonical/Ubuntu is planning to migrate heavily to Android backend services (not only SurfaceFlinger) in order to take advantage of the huge popularity of Android among the hardware manufacturers.
Possibly, a wrapper may be created for the PulseAudio API to execute sound services with AudioFlinger. The opposite was deemed possible by one of the developers of PulseAudio, so it is certainly an option. This would make the typical audio-using Linux desktop application work on top of Android’s AudioFlinger on a stock Android kernel released by the SOC/board manufacturer.
Other Android services may also be targeted in a similar way. Hardware accelerated video playing would be a notable example but acceleration sensor, camera and GPS services would also become easy accessible for traditional Linux applications.
With such a services-migration completed, one could do a mostly complete Ubuntu port in a matter of days to Android hardware and the required skills would be way-fewer than they are now. As a result, Ubuntu would be available for almost every hardware which supports Android. Some of the ports would be done by Canonical (Nexus devices) and most of them by the community (with the Cyanogen community doing the heavy lifting in many cases).
I think this is a good strategy since it brings Linux desktop applications to commodity Android hardware. Personally, I don’t care what backend services allow my applications to run as long as they do it efficiently and without (many) bugs.
Closing the gap between Android technologies and the Linux desktop would allow the latter to stay competitive and make an integrated experience possible. Linux desktops would eventually become capable of running Android applications (Dalvik would be just another Java-like VM, next to OpenJDK and Snoracle Java) Also, Linux desktop applications may become able to run on Android as first-class citizens (by packaging the necessary wrapper libraries to SurfaceFlinger and others).
Why do I think this is a necessity?
It is widely rumored that the next major version of Android will introduce some kind of desktop environment for keyboard/mouse work. This would allow Android to start shipping on desktop PCs. Given the weight of Google, I imagine that PC vendors would immediately start selling x86/PC hardware with Android. They already do it with ChromeOS which is much more limited than Android, so a desktop-toting Android version would easily beat that in functionality (huge number of apps and an ecosystem rapidly growing up to the weight that of Windows).
In an environment like that, desktop Linux would rapidly loose its remaining competitive advantage and very soon the desktop would be dominated by Android alone (only in the Linux camp, not meaning Windows, although I think that it would eventually become a strong Windows-competitor). If desktop Linux is as easy to port to any hardware as Android and runs Android apps next to traditional Linux apps, the competitive advantage remains.
It is way too early to tell if the above is the plan of Canonical but using SurfaceFlinger points to this direction. I would definitely like to see Ubuntu and other desktop Linuxes on every possible Android devices.
Soon after the article had been published, Canonical announced the development of their own compositor (Mir) and declared SurfaceFlinger as a component to be removed from the Ubuntu phablet stack. This mostly invalidates the assumption on their strategy. If Mir will be able to work with binary OpenGL ES drivers of GPU producers, that will probably make Ubuntu easier to port but definitely not as easy as an OS heavily based on Android technologies.
The Touchpad has been discontinued by HP when the company has changed its business strategy recently (getting rid of the whole PC business arm).
A lot of people think that this was an absolutely unnecessary and sorely mistaken step, especially in light of the possible revival of the Touchpad after the PC business has been separated. Not that the Touchpad is a very competitive device in its current form. It has many glaring design mistakes by HP like missing ports (HDMI out, USB host), no expandable storage …etc but it also has many good features like its high-quality IPS-screen, Beats audio system and over-clockable processor.
WebOS also has a huge disadvantage compared to iOS and Android: very few applications, and this seems to be quite a show-stopper in the current situation (a chicken-and-egg problem).
How could HP make this product more successful without resorting to souch brutal fire-sales like the one we have recently seen?
I believe, that HP should exploit one of the big strengths of the core of WebOS: Linux.
WebOS is built on the Linux kernel and it already uses a set of Linux desktop technologies on top of it (Gstreamer, PulseAudio…etc). In a particular sense, it is a heavily customized Linux distribution (distro), like Ubuntu, which is purposefully made incompatible with the grand armada of Linux desktop applications in order to allow applications which use strictly WebOS-only APIs.
The development strategy of allowing WebOS-only applications makes sense, since it ensures a consistent level of user experience (e.g.: all applications are properly touch-oriented) and makes it easy to enhance the foundations of WebOS without breaking applications. However, it locks HP into an uphill battle which seems impossible to win from the current situation.
Therefore, I suggest a change of development strategy, which concurrently allows significantly enhancing the number of applications available for WebOS and makes the system appealing for different use-cases.
The main component of the new strategy would be to allow running full-desktop Linux applications on the Touchpad in a so-called Desktop Mode. This Desktop Mode would automatically activate when WebOS senses a keyboard or mouse attached to the system (only Bluetooth in case of the Touchpad).
Desktop Mode would make it possible to use the TouchPad as a Linux netbook while keeping the touch oriented interface for the tablet-mode. Best of both worlds.
Desktop Mode would be a completely standard, lightweight Linux desktop (e.g: XFCE). and would run the traditional Linux desktop applications and also display the WebOS applications in separate windows. This work environment would not be very different from the Webtop interface of the Motorola Atrix but it would not be such a limited environment. It would be a full-blown, configurable Linux desktop with all of its advantages.
Ideally, you should be able to easily switch back and forth between the Desktop Mode and the Card Interface of WebOS (possibly with a dedicated hw button on new models).
Since Desktop Mode would run every imaginable Linux desktop applications (including Java, Python and even Mono ones), it would make the TouchPad an extremely versatile mobile device. It would be more welcome in the enterprise than its competitors.
The hardware of the TouchPad (dual-core processor clocked at 1.7 Ghz and 1GB RAM) should be absolutely able to handle both Desktop Mode and the Card Interface applications concurrently. Obviously, desktop heavyweights like OpenOffice would open and run slower, but I imagine they would be fast enough to be usable. HP could ship Desktop Mode with lightweight applications (Abiword, Gnumeric…etc) while allowing the easy installation of heavy programs (at your own peril).
The best option for the Desktop Mode would be a chrooted Ubuntu instance because that would mean a very powerful application environment with a lot of readily installable aplications in its repositories (appstore). The WebOS Internals team already ship the X-Server for WebOS, so a well-working Linux desktop is absolutely doable on top of WebOS.
HP could also sell a netbook-kit as an accessory to the Touchbook, which would include a case with a built-in stand and a built-in keyboard. When the TouchPad is in the case and oriented for netbook-mode, the Desktop Mode would automatically activate.
Of course, this solution would not fully compensate the inherent weaknesses of the Touchpad but it would make it more appealing for those people who consider netbooks as usable devices and expect their tablet to be as capable as their predecessors in mobility.
I believe it is high-time that Apache and Google created a new, Java-like programming language, platform and VM which can easily accomodate the ports of the Java base libraries, all of the Apache developed Java libraries/applications and the typical, popular open-source libraries like Hibernate.
Java should start off on the same road as LibreOffice under a different name.
The new “Java” language should be sufficiently close to Java that a one-to-one source converter tool can be written for trivial porting of Java libraries. Apache Harmony is a good basis for this but Snoracle patents will have to be worked around.
The platform should be completely modular and compatible with the packaging systems of Linuxes (apt/yum) and other repository based packaging systems, so that self-containing application packaging can be avoided (this is the case now with most Java applications).
While the language should be backward-compatible with Java, it should incorporate most of the new language advancements of .Net, Python and Ruby. Of course only those which don’t kill basic Java language features like strong-typing.
The new “Java” platform should have an Apache-led, democratic governing body. Similar to the JCP but without veto rights for anyone.
When the platform matures to 1.0 (if Google backs the project with enough cash, it could be reached quickly, since Harmony is likely a good starting point), Apache and Google should publicly announce that they stop active Java development, freeze all of their Java-based projects until they get ported to the new platform. Google should deprecate Java in the App Engine and thus forcibly move developers to the “new” Java. This migration should be easy/trivial.
This would of course practically kill Java but the new “Java” platform would become much stronger than Java has ever been because of the following:
- Since it would be distributed under the Apache license, it would be very commercial-friendly and appealing to companies. We can expect every sane company moving to the new platform in the medium term especially because:
- This platform would be truly open and the stewards (Apache/Google and possibly others) respected and trusted (esp. Apache)
- Nobody actually believes that Oracle will be a good steward of Java.
- Oracle will want to squeeze every last penny of Java (will hurt Java developers/users) without actual development of the platform. Just like they did with Oracle Forms and Reports.
- Due to the open-source nature, packaging and modularity of the new platform, all Linuxes would happily include the new platform and this new “Java” would soon become the primary development language of Linux projects, completely ousting Mono/.NET on the way. Those Linux projects would run on Windows as well so they would strengthen the migration path from Windows to Linux.
- Strong Linux support would bring a substantial developer base to the platform (the open-source developer crowd).
- Google would officially switch to this platform and the success of Android would help its rise considerably.
- Android would bring a substantial developer base (huge number of Android developers)
- Running Android applications on desktops would become possible which doesn’t make sense now but it will soon, since a lot of Android apps will be soon rewritten for tablets and thus become eligible for desktop use.
- The new language should become a primary citizen on the LibreOffice platform. Possibly a basis for every new, larger development in LibreOffice.
- When projects like Maven and Ant get frozen on the old Java platform, developer migration will ensue en-mass to the new “Java”.
The new platform would quickly dominate the server-side, where Java is the strongest currently and Linux is on the rise. It would also quickly dominate the mobile space due to Android.
It is possible that the new platform would also become successful on the desktop, at least in the enterprise space where a lot of Java desktop applications are deployed. The Linux desktop would be the first, possibly it would be followed by the Windows desktop.
Java in its current form, under the stewardship of Oracle, is destined to slow decline. Only a radical renewal like this could put it firmly back to the map of relevancy.
Although the Oracle – Google Java lawsuit looks ugly, there is a possibility that something good comes out of it: full Java SE appications running on Android.
That would be an awesome success for Oracle since it is by nature (steward of Java) interested in running Java applications in Android devices. Devices shipping with Android (tablets with dual-core ARM processor and 512Mb to 1 GB of RAM) are powerful enough to run full Java applications, even with Swing. Desktop applications are quite common in the enterprise space and would make Android devices very appealing in this segment. Especially in the tablet form factor.
Due to the overwhelming success of Android, Oracle would gain a lot of possible support contracts for Java SE on Android (support contracts are the ones Oracle is usually after)
Oracle should get over the need for controlling where Java SE can go (it is currently not allowed on phones) and remove these restrictions. Most of them don’t make any sense anyway.
Google and Oracle should work together to create a flawless SE JVM for Android (the Linux runtime is probably a good basis for that) and make sure that graphical Java programs (Swing) run nicely and feel native on Android. Sun has made a lot of optimizations for ARM Cortex A9 level processors, that work should not be lost.
Synergies between Java and Android are already very strong, this step would correct Google’s original mistake of leaving out SE compatibility of Android (I know the reasons but still I think it was a big mistake nontheless).
Smartbooks are an upcoming mobile computing device category built around ARM’s Cortex A8 and A9 line of processors. These devices are awaited with great anticipation because they promise a mixture between smartphone features (ultra-portable, 3G connected, always-on) and the functionality of netbooks/laptops (>9″ screen, seamless web browsing, laptop-like computing performance…etc) at a price point lower than that of current netbooks (sub-$300). Some smartbooks will arrive in the tablet form factor, some of them will come in the more traditional laptop form factor. All of them are expected to be comparable to netbooks in processing power (see this and this).
It is an intriguing question whether smartbooks will widen Linux adoption and erode the often criticised monopoly of Windows on pc-like computing devices.
Since the desktop line of Windows currently doesn’t run on ARM processors, we can exclude XP/Vista/7 from the list of likely contenders as smartbook operating systems. Windows 7 successors are currently not planned to be ported to ARM and even that wouldn’t be a complete solution since Windows applications will have to be ported as well (a very wide, close-sourced ecosystem).
Microsoft has Windows CE for ARM processors. Windows CE has already been deployed several smartbook-like devices (e.g. the original Psion Netbook) so it is definitely a contender in this market. However, WinCE 6.5 currently doesn’t support multiple or multi-core processors and more than 512Mb of RAM so advanced ARM SOCs like the Tegra2 would be very much limited by this OS. Solving multi-processor support will require significant investment from Microsoft. Incompatibility with the desktop line of Windows is also a severe limiting factor for WinCE. WinCE devices cannot be sold on the appeal of general Windows-compatibility, the user will not be able to install Windows applications onto the device.
Linux on the other hand has a very good technical background on ARM. It has no limitations for processing cores and operating memory and has targeted distributions for this architecture. Android is an outstanding example but several well-known distributions – like Ubuntu – have ARM ports in addition to their x86 base edition. Also, due to the fact that most of the Linux applications are open-source, they are at least possible to port, so we can expect the full usual complement of desktop Linux applications to show up on an ARM Linux distribution when the need becomes visible for them.
Technical factors aside, there is always the argument for Linux: being free . This may be important with smartbooks due to the very low targeted price point which doesn’t tolerate even moderate OS licensing fees (like $50/unit). So unless Microsoft gives Windows CE for practically free, Linux has the advantage here.
Since Windows CE has practically no advantages over Linux on ARM (in fact quite the opposite), Linux has a fairly good chance to be deployed on smartbooks as the primary operating system shipping with the device. Now, we can get into specifics. What kind of Linux and what kind of GUI?
Google’s Android is a very special Linux distribution. It’s touch-oriented GUI is simple and usable but it doesn’t run X-Windows so lacks the usual full-fledged Linux applications (Android applications are specifically written for the Dalvik virtual machine and its APIs in Java.) With this in mind, and considering the current frenzy around Android, I expect it to be deployed heavily on smartbook tablets. This form-factor is ideal for use cases in which full-fledged desktop applications are not necessary (e.g.: a web tablet with media player capabilities). More advanced Linux users will likely be able to install a full desktop Linux onto their tablets but the average consumer will be satisfied with Android.
However, laptop-like smartbooks with keyboards are better served with a full-desktop Linux like Ubuntu due to the fact, that on these devices, buyers will expect full-fledged applications like OpenOffice, Thunderbird, Firefox…etc. Android would be very limiting for the use cases expected from a netbook/smartbook (editing complex text documents, spreadsheets, using a full-fledged browser, email client…etc). I believe, the exact GUI environment is not really important for this kind of smartbooks although some netbook specific desktop environments (like Ubuntu Netbook Remix and Moblin) may be more efficient for smartbook models with low-resolution screens (below 1024×768).
My conclusion is that every kind of smartbook device can be put to its full potential with a properly customized Linux variant. Manufacturers seem to be aware of this since most of the already announced products are known to ship with Android (e.g.: Notion Ink Adam) or hinted to ship with some kind of Linux (e.g.: Lenovo Skylight).
Smartbooks are an upcoming line of affordable, mobile computing devices. Their use case scenarios fit in well with currently popular Java desktop applications (e.g.: Azureus/Vuze bittorrent client, RSSOwl feed aggregator…etc) and there are still a lot of websites using Java applets or webstartable Java applications for auxiliary functions (like mass upload of files). Moreover, many company intranets contain desktop Java based technologies (e.g. fast data entry forms, GIS mapping clients…etc). Due to this, affordable, Java capable devices may spur wider adoption of mobile computing within companies. Finally, the new JavaFX rich internet application framework (an Adobe Flash competitor) seems to be heavily supported by Oracle, so we can expect advancements on JavaFX deployments on public and intranet websites. JavaFX has similar Java requirements as Java applets.
For these reasons, it is interesting how smartbooks can be expected to work with desktop Java software.
Since the upcoming smartbooks are mostly based on ARM, we need to analyse how Java is supported on the latest ARM system-on-chip (SOC) processors.
Originally, ARM created dedicated Java support in their processors through its Jazelle technology. This provided hardware acceleration in a CLDC profile environment (Java edition for smartphones and other embedded applications). Jazelle provides better startup times until the Hotspot compiler can compile Java bytecode to native ARM code. If the device is memory constrained, it is possible to use Jazelle alone, without the Hotspot compiler. Some details about this can be found here.
In a smartbook environment CLDC is not enough, the full Java Standard Edition is expected in order to make the computer be able to run complex desktop programs like Azureus.
A number of upcoming smartbooks are based on the Qualcomm Snapdragon platform (which is roughly an ARM Cortex A8 level processor). A recent development (June 2009) that Java standard edition has been ported and optimized for the Snapdragon platform (details here). It is unknown if the Snapdragon uses Jazelle and the optimizations include Jazelle but it is likely since other Qualcomm ARM processors include this technology. This is encouraging from the Java perspective (the article mentions 32x improvement in application performance) but the Snapdragon and Cortex A8 processors may be generally not fast enough for complex applications.
The more powerful smartbooks will be based on dual core Cortex A9 processors (like the nVidia Tegra 2). These are generally assumed to be comparable to latest Atoms in performance. For this processor type, Sun has recently demonstrated their optimized Java 6 Standard Edition environment (2009 Oct, details are here). Cortex A9 processors include Jazelle by default and it is likely that SOC manufacturers will also include them in their end products.
Conclusion: With proper customizations by the device manufacturer, Java applications may perform better on Cortex A8/A9 based ARM systems than on comparable Atom chips because of the inherent Jazelle hardware support and the ARM specific optimizations done by Sun. The safe bet – from the Java perspective – would be on dual core Cortex A9 based systems since these will certainly have the necessary processing power for desktop applications.
The success of smartbooks remains to be seen but it is safe to say that Java will have good support on these systems and customers of such machines may expect reasonable performance from their Java applications.