DistroWatch Weekly, Issue 847, 6 January 2020

Feature Story (by Jesse Smith)

Android-x86 9.0 Android-x86 is an unofficial port of the Android operating system to the x86 hardware architecture. The port allows people to run and install Android on desktop computers and laptops. While Android usually runs on mobile devices with touch screens, this port brings the operating system to other personal devices and enables users to run some Android applications on their laptop or workstation. Not all applications run, or are stable, but many are, providing a familiar interface and collection of applications for people who usually run Android-powered phones and tablets.



Installing



The ISO for Android-x86 is approximately 910MB in size. Booting from the disc brings up a menu offering to launch either a live desktop environment or install the operating system. If we take the install option a series of text-based menus are displayed which guide us through setting up the operating system on our hard drive. There are not many steps, we begin by being asked to partition the disk and there is a text-based partition manager available to guide us through modifying the disk. Then we are asked to select a partition to use for the Android operating system. We can choose to format the Android partition with the ext4, NTFS or FAT32 filesystems. I went with ext4. There aren't any tips on this screen so I'm not sure if the project has recommendations or use cases for one filesystem over another. At any rate, the Android files are then copied to the computer and the boot loader is installed. We can then choose to set up the system directory with read-only or read-write permissions and I took the latter. Then we can reboot the computer and start exploring Android-x86.



The live session



Taking the live session option from the Android-x86 install media walks us through a series of configuration screens. The same screens we would see after installing the operating system and running it for the first time. The first one gives us the chance to change font size and screen resolution and enable screen magnification. We can also pick our preferred language. We are then given the chance to connect to wireless networks and then check for software updates. We are given the chance to connect to an existing Google account to synchronize data and applications. Then we set the date and time and, optionally, enable location services and network scanning. Android also asks permission to send usage data to the developers (I presume it means Google's team, rather than the Android-x86 developers). We can then create a PIN or access code that will lock-protect our device. In the end we are asked if we want to use the Quickstep or Taskbar home screen.



Early impressions



Most of the setup steps seem straight forward, but the question of using Quickstep or Taskbar is a bit vague and there aren't any previews of what these desktop layouts will look like. I found that Quickstep is basically the classic Android desktop. There is a notification area at the top of the screen. A Google search field is below that. Some applications icons - such as those for accessing the Chrome browser, GMail, a music player and image viewer - are on the desktop area and the bottom of the screen holds the Back, Home, and Window buttons. Or as I have come to think of them: the vague Arrow, Circle, and Square icons. The Taskbar home screen is quite similar, except the desktop has a panel across the bottom of the display where we can find an application menu (in the bottom-left corner), task switcher (bottom-centre), and a system tray (in the bottom-right).



Of the two, the Taskbar screen is much easier to navigate when using a laptop or workstation. The Quickstep screen has, as far as I can tell, no application menu, no way to access power or screenshot options (apart from pushing the machine's physical power button), and no clear way to access most settings. The Taskbar desktop provides these options through the application menu, making it quicker and easier to navigate. Both versions of the desktop area use a soft pink wallpaper and, while there are tools available to change the wallpaper, there are no other sample images included.



Early on the desktop style kept switching from the Taskbar back to the Quickstep layout. I soon realized that every time I clicked the Home button the desktop would reset unless I made Taskbar the default desktop application, rather than just running it once.



On a similar note, something that frequently frustrated me was I was constantly clicking desktop elements by accident. Android-x86 uses both long-clicks to bring up menus and swipe gestures in a number of situations. As a result I would often end up triggering a new menu or hitting a control at the edge of the screen while moving windows or swiping notifications. This, combined with the search options and connection toggles that are scattered around the desktop, meant I was often besieged by new windows and pop-ups while using the laptop's mouse. Using the touch screen directly helped, but it is an awkward way to explore a laptop's interface.



Something I noticed early on was that when running Android-x86 with the Quickstep interface, application windows would always open in full screen mode. When I switched over to the Taskbar interface, some applications would still run in full screen mode. This made it harder to switch between programs using the taskbar. However, when in Taskbar mode, most windows would open as small windows on the desktop. These tiny windows are always much too small to be practical and often their font was too small to read comfortably, even when I had increased the size of system fonts.



Hardware



I ran into a few issues early on when trying to explore Android-x86. I began by running the operating system in a VirtualBox environment. The system started to boot, reported it had found its media and then nothing happened, the system just locked up. I was able to run the system installer inside VirtualBox and this appeared to go well. However, once Android was installed I was unable to boot it from my hard drive. The operating system could be selected from the boot menu, but it would lock up before reaching the graphical splash screen. In short, I was unable to get Android to run inside VirtualBox, but the installer worked.



On my laptop, the operating system worked much better. Both the live system and installer worked. Android-x86 detected my touchpad and registered taps as clicks. I don't like that Android uses "natural scrolling", reversing the way scrolling works with the touchpad. Wireless networking functioned and the system was responsive. My laptop's touch screen capabilities worked too and often provided a smoother interface than using a mouse. Throughout my trial the system remained stable, though individual apps did not always work.



Included software



Android-x86 ships with a small handful of pre-installed applications. The Chrome web browser, a camera application, an image viewer, file manager, and terminal application are provided. There is a note taking application, though it seems less flexible than a typical text editor. We also have access to a calendar and calculator.



There is a settings panel which helps us deal with networks, make small adjustments to the interface, and connect to on-line accounts. The Android settings, particularly with regards to the interface, are not particularly flexible. There are ways to tweak the desktop, but it typically involves installing third-party applications rather than using the settings panel.



Installing and running additional software



Assuming we have a Google account, we are able to install and update applications through the Google Play Store. This software centre is fairly easy to browse for popular items or we can search for programs by name. The Play Store has a huge amount of software and there is a lot of overlapping function between its apps. This can make it difficult to find a specific program, or a useful program, as often many applications will have very similar names and features.



Acquiring applications that work on Android-x86 seems to be luck of the draw. Lots of little programs work and a few big ones, like Chrome, work. But I generally found software worked about as reliably on Android-x86 as a coin toss.



Even when software installed and ran properly, there were sometimes issues. For instance, I tried a couple of screenshot applications and while two of them would run, neither could save a screenshot. Between this and Android-x86's inability to run in VirtualBox, I was unable to get any screenshots during this trial.



To make matters worse, app interfaces sometimes did not work in a consistent way. Whether a program's Back button appeared in the upper-left corner of the screen or I'd need to use the system's Back button at the bottom of the screen seemed to be random, sometimes even within the same application. This meant I sometimes had to move the mouse up and down the height of the screen just to perform the same action twice.



Conclusions



I want to say that I'm impressed that the Android-x86 team has been able to port Android to the x86 family of processors. The operating system is stable, works with my physical hardware (though not in VirtualBox) and runs quickly. This is quite a feat and the fact than many applications run on this ported platform is also impressive.



However, Android-x86 is not at all practical as a desktop operating system. Its interface is unsuited to keyboard and mouse navigation, the desktop and apps have inconsistent interfaces, the desktop layout will keep changing if we don't lock it into one form or the other. Most programs do not look right in windowed mode.



While Android provides a huge amount of software in its Play Store, we are flooded with choices, many of which will not run well on the ported operating system. This makes trying to get the functionality we want very difficult and involves a good deal of trial and error.



Technologically, Android-x86 is very interesting and I could see it being useful for people who want to test their Android apps without having a mobile device. However, while this project is very interesting, I don't think it is nearly as polished or practical as most GNU/Linux distributions. Other than developers and very keen Android fans, I don't think there is much of an audience for this operating system. * * * * * Hardware used in this review



My physical test equipment for this review was a de-branded HP laptop with the following specifications: Processor: Intel i3 2.5GHz CPU

Display: Intel integrated video

Storage: Western Digital 700GB hard drive

Memory: 6GB of RAM

Wired network device: Realtek RTL8101E/RTL8102E PCI Express Fast

Wireless network device: Realtek RTL8188EE Wireless network card * * * * * Visitor supplied rating



Android-x86 has a visitor supplied average rating of: 7/10 from 48 review(s).

Have you used Android-x86? You can leave your own review of the project on our ratings page.





Miscellaneous News (by Jesse Smith)

Hyperbola switching to OpenBSD base, Mint polishes user interface, Debian votes on init diversity, Fedora to address performance on memory-starved systems The Hyperbola project is a community driven effort to provide a fully free (as in freedom) operating system, featuring a completely libre Linux kernel. However, the Hyperbola team is planning to change direction and shift bases from GNU/Linux to a fork of OpenBSD. " Due to the Linux kernel rapidly proceeding down an unstable path, we are planning on implementing a completely new OS derived from several BSD implementations. This was not an easy decision to make, but we wish to use our time and resources to create a viable alternative to the current operating system trends which are actively seeking to undermine user choice and freedom. This will not be a 'distro', but a hard fork of the OpenBSD kernel and userspace including new code written under GPLv3 and LGPLv3 to replace GPL-incompatible parts and non-free ones. " Further details on the change can be found in the Hyperbola announcement. * * * * * The Linux Mint team is currently working on some changes to polish their distribution's user interface and address minor issues with the latest version. " Before we move ahead and start working on Linux Mint 20 and LMDE 4, we'll make a few adjustments and fix some of the things you expressed in your feedback. First, I noticed some of you regretted the removal of keyboard shortcuts in Cinnamon's grouped window list. When we removed this feature, we assumed it wasn't discoverable and so very few people were likely to use it. It looks like we were wrong, so we'll bring this feature back. We finally managed to solve the 1px border bug which impacts full screen windows in Cinnamon, and we also have a fix for the screensaver lag. We'll be pushing these fixes as package updates. The new version of the System Reports tool was very well received but the root password notice confused a huge number of people. I talked to some of our IRC moderators and it's their number 1 complaint with the new release. We'll review this and find a solution for it. " The project's monthly newsletter also talks about the newly released MintBox3 computer. The MintBox3 is a small, passive cooling computer that ships with Linux Mint installed. Details on the new generation of the MintBox can be found in the Compulab press release. * * * * * The Debian project has been debating how to handle having multiple init implementations packaged for the distribution. Some Debian developers would like to actively support multiple init systems (such as OpenRC, SysV init, and runit) while others would prefer to streamline things and only support systemd, which is currently the default init software. There has been a good deal of discussion over whether to support multiple init choices and, if so, how to do that. The project eventually voted on a series of options with the winner being "systemd, but we support exploring alternatives". " The Debian project recognizes that systemd service units are the preferred configuration for describing how to start a daemon/service. However, Debian remains an environment where developers and users can explore and develop alternate init systems and alternatives to systemd features. Those interested in exploring such alternatives need to provide the necessary development and packaging resources to do that work. " Essentially this makes systemd the one official init implementation for Debian while allowing package maintainers to work on supporting alternatives. * * * * * Ben Cotton has written about a proposal for the upcoming release of Fedora 32 which would cause the operating system to kill off memory-heavy processes when the system is running out of RAM and swap space. " Fedora editions and spins, have the in-kernel OOM (out-of-memory) manager enabled. The manager's concern is keeping the kernel itself functioning. It has no concern about user space function or interactivity. This proposed change attempts to improve the user experience, in the short term, by triggering the in-kernel process killing mechanism, sooner. Instead of the system becoming completely unresponsive for tens of minutes, hours or days, the expectation is an offending process (determined by oom_score, same as now) will be killed off within seconds or a few minutes. This is an incremental improvement in user experience, but admittedly still suboptimal. There is additional work on-going to improve the user experience further. " Details on the proposal can be found in the Fedora wiki. * * * * * These and other news stories can be found on our Headlines page.





Questions and Answers (by Jesse Smith)

Adopting Wayland and delta-Deb packages Recently I have received two questions about the adoption of technologies, specifically Wayland and delta-Deb packages. More specifically, the questions were asking why Wayland and delta-Deb have not been more widely adopted and used. Since there is a common theme here - apparently useful technologies not being adopted - I would like to talk about both of them in this week's column.



Let's talk about Wayland first. Wayland is a protocol and design for a new way applications and desktop environments can draw things on our screens. It is intended as a replacement for the aging X protocol and software. Using Wayland, the idea goes, desktop environments will be able to offer a faster, cleaner code base that doesn't suffer from the same bugs and legacy security concerns X.Org has.



What tends to confuse people is that, while X is both the common name of a protocol (X11) and the software (X.Org) which implements that protocol, Wayland is just a protocol and reference implementation. That is, Wayland tells us how software can communicate and implement a new approach to displaying things on our screens. But Wayland is more an idea, a blueprint, than a thing that runs on our computers. Each desktop and window manager needs to create its own implementation of the Wayland design.



This means GNOME has its own Wayland display server, KDE has another, Unity8 has another. If Xfce, LXQt and other desktops also want to use Wayland's design they need to create (or adopt) their own implementation of the Wayland design. This means each desktop environment may have different levels of completeness and implement different features through the Wayland protocol. In contrast, there is (for most practical purposes) one X.Org implementation[1] and each desktop environment can use the same X.Org package and enjoy the same common set of features it offers.



All of this is to say that while Wayland offers some nice ideas with fewer moving parts, fewer security concerns in some instances, and promises smoother video output, there are some problems in practise. It takes a lot of work for desktops to implement a new window manager that talks the Wayland protocol. Each desktop needs to create its own implementation which can lead to an inconsistent experience across desktop environments. Also, some applications (particularly closed source programs) expect to talk to X.Org and therefore Wayland needs to provide a compatibility layer for those programs. This makes shifting from one approach (X.Org) to the other (Wayland) an uphill process.



To make matters more complicated, to the end user (even to most application developers) there is no practical difference between running X.Org or Wayland display servers. There are some theoretical benefits to Wayland, but the end user will almost never see them. On most machines, with the typical default settings, running most applications, it is virtually impossible to tell the difference between a Wayland session and an X.Org session. This means there is relatively little incentive for users or developers to put in the effort to migrate from one approach to the other.



Wayland is largely being adapted by the two biggest desktop projects, GNOME and KDE. However, the relative lack of practical benefits and the amount of developer hours required to make the switch mean most of the smaller desktop environment projects have not made the transition. Probably because they do not have a lot of developer resources to spend on creating a technology most people do not feel they need. It's not that Wayland isn't useful (it has some good ideas), but it is competing against an old, ingrained technology that has been deemed "good enough" by most people. This situation makes for a slow transition. * * * * * Now, moving on to delta-Deb packages. Usually when we upgrade software packages on our system, a new complete copy of the new package is downloaded. The old version is removed and the new version is installed in its place. This is a relatively simple series of transactions. However, downloading the entirety of a new software package can be a waste of network bandwidth when we only need to change a few small files. If there is a bug in LibreOffice that only requires changing a single, small 1MB library then it is wasteful to download the whole 187MB all over again.



Delta packages contain just the changes between two versions of a package. This means we can download just the differences between one version and the next, potentially saving large amounts of bandwidth in the process. The Fedora project was one of the few to push the idea of using delta packages (delta-RPMs) by default and it could easily reduce the package manager's bandwidth usage by half.



The bandwidth saving seems like an attractive idea so it is understandable most users would be interested in using delta packages when they are available. So why are more distributions not using these smaller packages? To be entirely up front, I haven't surveyed distribution developers about this, however, I think there are a handful of key issues involved that make delta packages less attractive to distribution maintainers than to the users.



One is that these delta packages take up space on the server and then need to be synchronized between servers. This means more storage space and more bandwidth is required by the project. The end-user may benefit, but the distribution itself needs to bear extra costs to share all of these little packages between its mirrors.



The next issue is someone needs to create and monitor the creation of all these delta packages. For each package. For each version of the distribution. This type of work can balloon very quickly. For a project with 50,000 packages and three supported versions, we are looking at a minimum of 150,000 packages. If each of those also needs a delta package, that is a lot of package building and testing to monitor.



I suspect the increase in network speeds to most areas of the world has been a factor too. When Fedora started deploying delta-RPMs it was still fairly common for many users to have connections too slow to stream video. These days many people, even in more rural areas, have the bandwidth to download most of a month's updates in under a minute. This makes reducing the user's bandwidth a lower priority.



Again, we see a cost/benefit issue, just as we did with Wayland. A delta package offers a little benefit to the user, but a relatively high cost to the distribution maintainers. This makes it a low priority and unlikely to be implemented unless someone steps forward with the time and resources to cover the cost of making delta packages a reality. * * * * * 1 - Earlier I wrote that there is one X.Org implementation. By which I meant most distributions ship and use the same X.Org software. There are other implementations of the X11 protocol which can be used in special cases. It is rare, but they do exist. However, virtually all Linux distributions ship the same implementation and so we can usually think of X.Org as being a common base for any applications which need to use the X11 protocol. * * * * * Additional answers can be found in our Questions and Answers archive.





Released Last Week

Torrent Corner

Upcoming Releases and Announcements

Opinion Poll (by Jesse Smith)

Delta package updates In our Questions and Answers column we talked about delta package updates. A delta package contains just the changes between one version of a package and the next, saving the user from downloading the entire package over again. This can offer significant bandwidth savings when upgrading large packages, such as LibreOffice and Firefox. We would like to hear whether your distribution uses delta packages when upgrading. Let us know what you think of delta package updates in the comments.



You can see the results of our previous poll on disk encryption and file vaults in last week's edition. All previous poll results can be found in our poll archives.



Delta package updates



My distro uses delta package updates: 114 (11%) My distro does not use delta package updates: 506 (51%) I use some distros with and some without this feature: 85 (9%) Unsure: 292 (29%)

Website News (by Jesse Smith)