LWN Weekly Edition
Front pageSecurity
Kernel development
Distributions
Development
Announcements
->One big page
This page
Previous weekFollowing week
| |||||||||||||
DistributionsRunning Android on x86The Android-x86 project released the first release candidate for its version 4.0 on March 1. The release is based on the Ice Cream Sandwich (ICS) release of the Android source code, and introduces some important new features — such as hardware video acceleration for all three major GPU vendors, and a usable live USB image. The Android-x86 project started off as an individual hobbyist effort, collecting patch sets against the upstream Android source that would allow developers to build the OS for specific hardware devices. As time went on, however, there was more and more consolidation and an ever-increasing pool of contributors. Thus, the project eventually grew into its current form, hosting Git repositories, producing ISO installers, and offering an email and IRC support community. The project is entirely volunteer-driven and -governed, although AMD is credited as adding support for several of its platforms, and there are individual developers from Intel and other companies credited with contributions in the release notes. Interestingly enough, the very first x86 port of the Android Linux kernel was done by a Google employee. After that, outside developers first took up the challenge of getting the Android kernel to run on their own hardware, starting with the ASUS Eee PC, drawing from Moblin's efforts to get the kernel to boot and WiFi drivers to compile for the Eee, and on Canonical's Ubuntu Mobile Internet Device (MID) edition to get the GMA500 graphics chip working. Since roughly 2010, the project has steadily added new hardware platforms with each release. The ice cream sandwich machine![[App settings]](/images/2012/androidx86-settings-sm.png)
The hardware supported by Android-x86 is still a subset of the Intel-compatible world. Intel has recently announced plans to bring Atom-based phones to the market in the latter half of 2012, which could boost interest in Android-x86 considerably, but for the moment the primary development targets are tablets and netbook-class portables. Each release is tested against specific devices; the current list supports ASUS Eee netbooks, the Dell Inspiron Mini Duo series, and several Lenovo offerings on the netbook side, plus the Viewsonic Viewpad, Samsung Q1U, and Viliv S5 tablets. All are Atom-based devices, and at the moment there are no 64-bit CPUs supported. The project makes an effort to support as many hardware features as possible on the target platforms, including suspend/resume buttons, battery status, touch screens, cameras, Bluetooth, GPS, and accelerometers. However, most of these hardware features are already found in mobile phones and ARM-based tablets. Providing a usable experience on netbooks involves supporting external monitors, mice, and keyboards, not to mention external storage devices and a wider range of video chipsets. ISOs of the 4.0-RC1 release are available for five hardware platforms, though more are certainly possible when the final 4.0 release is made. For comparison's sake, the 2.2 release from June 2011 (based on Android Froyo 2.2.2) supported seven separate platforms; subsequently there were test releases based on Gingerbread and Honeycomb, but neither was ever dubbed a stable release. In addition to the platform-specific ISO releases, there are nightly builds for "generic" PC hardware, and there are build instructions for the source itself. The ISO image weighs in at a modest 180 MB or so, depending on the device. 4.0-RC1 is based on the Android 4.0.3 source code release, using kernel 3.0.8 with kernel mode-setting (KMS). New to this release is hardware GPU acceleration for Radeon, NVIDIA, and Intel graphics, the addition of Chrome's V8 JavaScript engine (previous releases had used the JavaScript Compiler (JSC) instead), auto-mounting of hot-pluggable memory cards or USB storage, and experimental support for the Renderscript 3D rendering API. On the down side, wired Ethernet support is not working properly with the Android user space yet. The ISO images themselves have also been beefed up in some noticeable ways. The filesystem is now compressed with Squashfs to save space, the live USB option runs in "hybrid" mode to permit using available flash space as persistent storage, and there is a text-based installer that supports the ext2, ext3, NTFS, and FAT32 filesystems. TestingI ran 4.0RC1 on a Lenovo S10 netbook; unscientifically I found it to be much faster than most Android phones I have used. That is no surprise from a hardware standpoint, of course, but even people who don't care for Android on mobile devices may be surprised at the resulting experience on a faster CPU with additional memory. All of the hardware worked, including WiFi, Bluetooth, and the touchscreen (which tends to confuse other distributions). Browsing, synchronizing email and other data, and all of the other essential tasks work smoothly. It is easy to tell that the OS was originally designed for a phone or tablet, though. In addition to referring to all disk space as "the SD card" there are places where Android-x86 is difficult to use without a touchscreen device. For one thing, the project has added a software mouse cursor, and I had no trouble with my keyboard, but the unlock screen requires a swipe maneuver that is tricky to pull off on a touch pad. Second, although KMS correctly set the screen size to the S10's native resolution, that still results in large, Playskool-like menus and buttons. While they don't impede your ability to work, I cannot imagine liking it on a 24-inch desktop display where touch-sensitivity is not part of the arrangement. ![[Apps]](/images/2012/androidx86-apps-sm.png)
However, neither of those nitpicks is an indictment of the quality of the software. Surprisingly enough, despite warnings to the contrary on the Android-x86 wiki, the new release has full access to the Android Market and can install most third-party apps as well. The tricky part is that Android-x86 will only work with pure Dalvik apps — almost all of the Android apps that use the Native Development Kit (NDK) are built for ARM. Unfortunately (or fortunately, depending on who you ask), the architecture difference also rules out Adobe Flash and applications that employ it. However, as I discovered on the mailing list, there are beginning to be Android Market apps released specifically for the x86 architecture. Most are media players, which arguably have a greater need to optimize for speed, but their mere existence is intriguing. More to comeAndroid-x86 does not have a formal roadmap, apart from the general convention of following the upstream Android source code releases. However, the site lists a few specific projects targeted for the near future. There are always new hardware platforms and chipsets to worry about, such as the AMD Brazos line, and unsupported features popular in netbook designs, such as the CrystalHD video decoder chip. From the software side, Android-x86 does not yet have support for Android's native multitouch layer, although it is listed under "what we are working on now," and there is an effort by project maintainer Chih-Wei Huang to port the GStreamer multimedia framework to the OS. The GStreamer port would presumably replace Android's libstagefright as the multimedia abstraction library. In 2011, Collabora (home to many GStreamer developers) worked with ST Ericsson on an Android build of GStreamer, and that code remains available, although it seems highly unlikely to ever receive an official blessing from Google. On March 11, developer Stefan Seidel sent a proposal to the Android-x86 mailing list with two suggestions for streamlining the development process itself. The first was an attempt to move from the separate-trees-for-each-target-device model currently being used to a unified tree. In addition to reducing duplication of effort and simplifying QA, he said, unifying the main tree would allow the project to produce a "base image" with each release that could be further customized by adding commercial or binary add-ons (such as the Google app suite) via an overlay filesystem like UnionFS or AuFS. The second suggestion was partly an attempt to find a way around the difficulties posed by the Android sensor framework. The framework is what enables applications to access accelerometer or ambient-light sensor data. These sensors are far less common on Atom-based devices than in mobile phones, so many Android-x86 trees use a dummy library instead, which allows the user to simulate readings manually. Seidel proposes either overlaying real libraries over the dummy libraries for systems that support the sensors, or else adding a fail-over between the real and dummy libraries; in either case the end result would be that fewer hardware differences would exist to force developers to work on device-specific branches. The others on the list seem supportive of the suggestions, and on board with the underlying goal of unifying the trees. In the resulting thread, many other suggestions for where the project should head next cropped up, including localization, FUSE support, and 64-bit support, which seems indicative of a motivated community. What is not clear is whether or not there are very many people who use Android-x86 as a daily-use operating system. The question is interesting in light of how disruptive Android has been in the mobile phone market. If it takes off as a netbook offering, it would make for an unpredictable competitor for Google's other portable OS, ChromeOS, not to mention various other lightweight distributions. This is not to say that the project needs 24/7 users in order to be valuable, of course. Evidently plenty of people do find it useful; the project blog even noted back in April 2011 that Amazon.com was using Android-x86 as the guest OS on EC2 in order to provide its application "test drive" service. Still, a test drive is by its very nature short. Users that run an OS day-in and day-out uncover different bugs and usability woes. Should the traditional desktop Linux distributions be scared that Android will start eating into their market share? Probably not. But even as a volunteer-driven project with limited hardware targets, Android-x86 has produced a well-polished and usable release in very little time — one that comes with an pre-existing application ecosystem. Given that, the distributions would not be wise to ignore the possibility entirely.
Brief items Distribution quotes of the week
I think that the general point here is that in projects people need to be
able to ask for help, and people must be willing to offer help. Again, in
general, good management is about bringing these things together, whereas
bad management (as many of us are unfortunately all too aware) often
involves someone thinking that their job is merely to tell you what to do,
frequently not contributing to the activity in any way other than to
indicate that things must be done more quickly, as opposed to helping you
get your work done by giving you what you need.
-- Paul Boddie
When the totem law of Kbanga declares that displaying any words with two
consonant clusters is illegal on Fridays, the rest of the world doesn't
suffer. Being able to pop in a DVD and play it is something an average
person takes for granted. If oppressive laws in a single country stop a
good part of multimedia functionality, why should that functionality be
taken away from everyone else?
-- Adam Borowski
In talking with visitors to FOSDEM (that I am a co-organizer of, now) and
with customers, I has become clear to me over the years that Debian has a
reputation of being somewhat oldfashioned and stale. That if you want to
run the latest technologies, you should use something else. This reputation
may have been deserved when we were having trouble releasing sarge, over
half a decade ago, but it's entirely undeserved today, and I think it's
well past time that we do something about that.
-- Wouter
Verhelst
I've seen that work, had stones thrown at me, didn't mind. I've seen
others do it, worked out nicely in the end.
-- Gergely Nagy
However, this doesn't always work, as this is best done when the discussion can be taken private, to discourage others from throwing yet more fuel onto the fire. On the other hand, I do not believe in a flame-war-free world, either. We do need heated arguments from time to time, and I see nothing wrong with that, as long as it remains civilised and does not resort to name-calling and an insult duel (unless it's in monkey island style ;).
On the first part of your question --- assuming bad faith --- I think
little can be done to avoid that. It's something quite personal: some
are more prone to assume bad faith while other are more prone to assume
good faith. What we need to encourage on that front is a culture that
allow to change your mind once people discover their initial assumptions
were wrong and to publicly say so. There is nothing wrong in being
wrong. And there is a lot to gain from a community where people state
publicly "sorry, I was wrong" and other people do not think bad of them
because of that.
-- Stefano Zacchiroli
Arch Linux turns 10Here's a brief note on the Arch Linux tenth anniversary. "If you follow Arch Planet, you may have already heard the news that we are celebrating a decade of existence, with the release of 0.1 Homer on March 11, 2002. If you haven't already, grab some birthday cake and head over to Arch Planet to read several developers chronologies and wonderful words of praise for Arch Linux."
Release for CentOS-5.8 i386 and x86_64The CentOS project has released CentOS 5.8. "CentOS-5.8 is based on the upstream EL 5.8 release and includes packages from all variants including Server, Client, Virtualization, and Clustering. All upstream repositories have been combined into one to make it easier for end users to work with." See the release notes for details. The project has also published a list of updates included in this release.
Updated Debian 5.0: 5.0.10 releasedThe tenth and final update of the Debian oldstable distribution has been released. Debian 5.0.10 (lenny) mainly adds corrections for security problems. "The alpha and ia64 packages from DSA 1769 are not included in this point release for technical reasons. All other security updates released during the lifetime of `lenny' that have not previously been part of a point release are included in this update. Please note that the security support for the oldstable distribution ended in February 2012 and no updates have been released since that point."
"Squeeze" based Debian Edu version releasedThe Debian Edu Team has announced the release of Debian Edu "Squeeze" 6.0.4+r0. Debian Edu (aka "Skolelinux") is a Debian Pure Blend targeted at schools and educational institutions. "It covers PXE installation, PXE booting for diskless machines, and setup for a school server, for stationary workstations, and for workstations that can be taken away from the school network. Several educational applications like Celestia, Dr. Geo, GCompris, GeoGebra, Kalzium, KGeography and Solfege are included in the default desktop setup."
Ubuntu 10.10 (Maverick Meerkat) reachs end-of-lifeUbuntu has announced the end of life for 10.10 (Maverick Meerkat). No updates will be available after April 10, 2012, eighteen months after its release on October 10, 2010. The supported upgrade path from Ubuntu 10.10 is via Ubuntu 11.04.
Distribution News Debian GNU/Linux Debian Project Leader Elections 2012: CandidatesThere are three candidates in this year's Debian Project Leader election; Wouter Verhelst, Gergely Nagy and Stefano Zacchiroli.
Debian "sid" users beware of the dpkg 1.16.2 uploadThe dpkg 1.16.2 update to unstable may cause some headaches for users of Debian's unstable branch. "The previous multiarch in-core db layout was bogus, resulting in a possible inconsistent or broken on-disk db. If you are running any dpkg derived from code that has never been in the main git repo (this includes dpkg from the jenkins test builds [T], dpkg from experimental, dpkg from Ubuntu, one of the personal pu/ branches, etc), any of the following might affect you."
Newsletters and articles of interest Distribution newsletters
Dream Studio 11.10: Upgrade or Hands Off? (Linux.com)Carla Schroder reviews Dream Studio, a distribution aimed at multimedia creation. "Dream Studio installs with a vast array of audio, movie, photography, and graphics applications. It's a great showcase for the richness of multimedia production software on Linux. Audio is probably the biggest pain in the behind, as the Linux audio subsystem can be a real joy* to get sorted out. One of the best things Dream Studio does is box it all up sanely, and on most systems you just fire up your audio apps and get to work. It comes with a low-latency kernel, the JACK (JACK Audio Connection Kit) low-latency sound server and device router, and the pulseaudio-module-jack for integrating PulseAudio with JACK."
Shuttleworth: Ubuntu vs RHEL in enterprise computingMark Shuttleworth claims that Ubuntu deployments now exceed RHEL deployments for "large-scale enterprise workloads." "The key driver of this has been that we added quality as a top-level goal across the teams that build Ubuntu – both Canonical’s and the community’s. We also have retained the focus on keeping the up-to-date tools available on Ubuntu for developers, and on delivering a great experience in the cloud, where computing is headed."
Page editor: Rebecca Sobol |
|||||||||||||