DistroWatch Weekly, Issue 767, 11 June 2018

Feature Story (by Jesse Smith)

Android-x86 7.1-r1 Android-x86 is a port of the Android operating system for 32-bit and 64-bit x86 computers. In theory, Android-x86 make it possible to run the same Android operating system on a workstation or laptop computer as we might run on our phone. Android uses a version of the Linux kernel, much like GNU/Linux operating systems, but features different userland utilities and a different graphical user interface.



The latest release of Android-x86 (hereafter simply referred to as Android) is version 7.1-r1 which is available as a 809MB download. I grabbed a copy of this release in order to give it a test run in a VirtualBox virtual machine and on my laptop. When booting from the Android media, a boot menu is displayed, offering us the chance to try a live environment or install the operating system. My experiment with VirtualBox got off to a rocky start as Android failed to launch the live graphical environment. Sometimes the system would simply reboot when the live desktop option was selected and other times the system would lock up.



Installing



Taking the install option from Android's boot menu brought up a text console with a menu-driven interface. The installer asks us to partition the hard drive and tells us we should set up a partition with at least 4GB of disk space, though 8GB is recommended. Disk partitioning is handled by the cfdisk text-based partition manager. Once a partition has been created, we are asked to select a file system (FAT, ext4 and NTFS are supported). We are then asked if we want to install the GRUB boot loader to handle starting the operating system.



When the installer is finished we can restart the computer to try out our fresh copy of Android. Unfortunately, I could not get Android to boot and display a graphical interface in my virtual machine. I was able to get Android to boot in debug mode, but launching the system in debug mode would only get me to a minimal command line interface where I could run a few commands, like ls and top. From the command line I was unable to connect to any networks or launch the desktop environment.



Running Android on my laptop went more smoothly. The operating system was able to run its installer and boot without any tweaking on my part. Launching the new copy of Android the first time walked me through some configuration options. I was given the chance to select my preferred language, connect to a wireless network and optionally sign into a Google account to synchronize settings and contacts. With these steps completed we are presented with Android's desktop interface.





Android-x86 7.1 -- The default desktop

(full image size: 174kB, resolution: 1366x768 pixels)



Early impressions



The Android interface is roughly divided into four parts. There is a notification bar at the top of the screen which we can click to access recent notifications and settings. The bulk of the display is taken up with an empty desktop space where application icons can be placed. Below this empty space is a button that opens an application drawer. When the draw is open it shows us a large grid of icons for installed applications. At the bottom of the display are Android's customary Back, Home and Show Open Windows buttons.





Android-x86 7.1 -- The application drawer

(full image size: 122kB, resolution: 1366x768 pixels)



The interface was responsive on my laptop, but inconsistent in its appearance. Some buttons and icons were large while anything in the notification area was very small. The fonts in most applications are large and easy to read, but text in the settings area was very small. This gives the Android interface an imbalanced look. I found some pieces could be made to look smoother through the settings panel.



On the subject of settings, one issue I struggled with was Android uses inverse vertical scrolling. (Scrolling down takes us up the page, scrolling up moves down a page.) I found this jarring since it's the opposite of how most desktop environments respond.





Android-x86 7.1 -- The settings panel

(full image size: 43kB, resolution: 1366x768 pixels)



Another problem I had with the mouse pointer was items I moved the mouse over often got activated as though I had clicked on them. This resulted in a lot of apps and options being opened by accident. At first I thought this was due to an option which causes the interface to register a click after pointer movement, but this feature was turned off by default. In my case the mouse was just super sensitive.



Another issue which kept coming up was about once a every minute or two, a pop-up would appear, telling me the Play Services program had crashed. This did not appear to affect my tasks or my ability to install applications, but it did constantly interfere with my web browsing and typing.



Included software



One of my key concerns when I run Android on a desktop x86 computer instead of its native, mobile ARM environment is how well applications will run. The good news was I found that most programs included with Android (the photo gallery, application store, settings panel and so on) worked. Using them was sometimes awkward as they are designed to be run on small, touch-enabled displays. Attempting to navigate these apps with a mouse and keyboard is awkward at best.





Android-x86 7.1 -- Browsing the web with Chrome

(full image size: 549kB, resolution: 1366x768 pixels)



Trying to download and run additional software gave mixed results. Some programs worked as expected, others would crash at start-up. There does not appear to be any way to easily identify which programs will work and which will not, other than downloading and trying them.



One example of struggling with Android's software came about when I tried to watch Netflix. The Chrome browser which ships with Android worked really well for most things. I could browse websites, watch YouTube videos and check e-mail with it. But when signing into Netflix, any attempt to watch videos in the browser brought up a page telling me I had to use the Android app to watch Netflix. The Netflix app could be installed, but failed to launch, effectively blocking access to the streaming platform.





Android-x86 7.1 -- Installing an app from the Play store

(full image size: 243kB, resolution: 1366x768 pixels)



Other observations



Android ships with a terminal application for those of us who like to work from the command line. Many common UNIX utilities are included, making it easy to browse directories, monitor processes and manipulate files. One problem I ran into though was I could not get the secure copy (scp) and secure file transfer (sftp) programs to work. The former would always exit with an error saying “-x” was not a valid parameter (the -x flag was not being used). The latter program would not give any meaningful error, just exit. However, the secure shell (ssh) program did work and allowed me to login and manage remote machines. This left me in the weird position of performing file transfers through a pipe over secure shell rather than using the typical scp and sftp programs.





Android-x86 7.1 -- Monitoring processes from the terminal

(full image size: 154kB, resolution: 1366x768 pixels)



Android 7.1 ships with version 4.9.80 of the Linux kernel. This is a relatively modern kernel, not much older than the one I typically run on this laptop for work. However, while recent versions of Linux Mint, Ubuntu and MX Linux have typically provided me with two hours of battery life when listening to music or watching a movie, Android could not provide me with more than 40-50 minutes minutes of battery when browsing the web and adjusting settings. This puts Android at a disadvantage when we are on the go.



Conclusions



Android-x86 is a project which I think is interesting for its goal of getting Android onto more platforms and I can certainly see how it would be appealing for people who want to test Android applications across several types of devices. Unfortunately, Android is geared toward small, mobile devices and its interface, controls, applications and hardware support just do not translate well to larger personal computers. To me, trying to use Android on a laptop computer feels out of place, much like trying to use a word processor or virtual terminal feels out of place on a small, mobile device. It's possible to use, but not ideal and not entirely practical.



I think the Android-x86 team deserves a great deal of credit for getting Android working as well as it does - the system does boot, run and can launch several applications on my laptop. But the regular notifications of crashes, short battery life and limited number of applications make this operating system unappealing for daily use. I think Android-x86 is a good test platform for trying out Android and its apps on different sized screens and hardware, but it's not great for common desktop tasks. * * * * * 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)

Tips and Tricks (by Jesse Smith)

OpenSSH, pipes and file transfers In a few recent articles I have referred using the secure shell (ssh) command with a pipe to transfer data or files from one computer to another. For those not familiar with these two pieces of technology, let's start with a quick overview.



A pipe is a way for two programs to communicate, with one handing data to the other. One program creates a pipe and sends information into the pipe. Another program can then open the pipe and read this same information in the order it was sent. Pipes allow us to string a series of commands together to share and manipulate data. For example, the grep command finds lines matching a pattern in a text file and the sort command rearranges lines in alphabetical order. Using a pipe, we can use grep to find something, like names in an address book, and then use sort to put those names in order. Here is an example of a pipe gathering up the information from a search of an address book and passing the names to the sort command: grep "Name:" address-book.txt | sort The OpenSSH secure shell program is typically used to log into a remote computer and interactively run commands on the remote machine. In its simplest form, the secure shell (ssh) command accepts our username and the name of the remote computer we are going to log into and then runs a normal, interactive shell session over the network. Running ssh typically looks like this: ssh jesse@example.com Sometimes, if we just want to run one command on the remote computer and then immediately quit, we can specify the command to run at the end of the line. For example, here we get the amount of time the remote computer has been running using the uptime program: ssh jesse@example.com uptime One very nice feature of ssh is that we can pass information from it through a pipe on our local computer. For example, if the address-book.txt file I mentioned earlier is on the remote computer, we can search through it for names on the remote computer and then sort the results locally. For instance: ssh jesse@example.com grep "Name:" address-book.txt | sort Using pipes we can also run commands locally and then send the output to a file on another computer. Here we get a list of processes running on the local computer using the ps command and then save it in a log file on a remote computer for safe keeping. This works because secure shell passes the piped information from ps to the cat command running on the remote computer. The data is finally dumped into logfile. ps aux | ssh jesse@example.com 'cat > logfile' Note the command we run on the remote computer is placed inside single-quote marks. This separates the command run remotely from what we are doing locally. Without the single-quotes we would end up creating logfile on our local computer.



Apart from passing small pieces of information from local commands to remote commands, the ssh utility can be used to transfer files from one computer to another. Normally, we would use a command like secure copy (scp) to transfer a file from one place to another. However, if we do not have access to scp or we want to do some processing on a file's contents during the transfer, ssh becomes very useful. Here is an example where we perform a straight forward transfer from the local computer to a remote computer, backing up a tar archive: dd if=archive.tar.gz | ssh jesse@example.com dd of=backup-archive.tar.gz In the above example, we use the dd command, which copies data from one location or file to another. Here, the dd command loads archive.tar.gz as its input file (if) and sends the file over a pipe to the remote computer. On the remote machine we use the dd command again to create an output file (of) called backup-archive.tar.gz. This simple copy works, but is more cumbersome than the more commonly used scp version of the same action, which requires just the name of the file to copy and its destination. Using scp, the process would look like this: scp archive.tar.gz jesse@example.com:backup-archive.tar.gz Where using ssh with pipes really shines is when we want to perform an action on data during the transfer. For instance, what if there is a log file on a remote server and we want to compress it and then download a copy of the compressed log, all in one action? We can use pipes on the remote computer to compress a log file using gzip and then pass the compressed file through dd to our local computer. The command looks like this: ssh jesse@example.com 'cat /var/log/error.log | gzip | dd ' | dd of=error.log.gz Once again we see the string of commands on the remote computer is placed in single-quotes to isolate the remote processes from commands performed locally. After the above command runs, we end up with a compressed copy of the error log file.



Some people might look at the above example and wonder why the first instance of the dd command is run without any parameters. It seems somewhat pointless when gzip can compress the data and pass it along to our local computer. The reason for the empty dd command is gzip will refuse to dump compressed data to the console (aka standard output) as it would look terrible. However, gzip will pass compressed data out to another pipe. In the above example, the first dd command is there just to accept the compressed data from one pipe and then pass it along to the next step so that gzip will agree to run in this unusual set up. Once the data comes through the pipe to our local computer, the second dd command writes the compressed information to an output file (of) called error.log.gz.



These are just a few examples of how we can pass information and files from one computer to another using pipes and secure shell. There are lots of other ways to string commands together to get data from one computer to another over secure shell. These methods may look more complicated than using a simple copy command, but it's one way to string programs together to form one big command line rather than breaking data processing and file transfers into separate processes. * * * * * More tips can be found in our Tips and Tricks archive.





Released Last Week

GeckoLinux 150



GeckoLinux is a distribution based on openSUSE with a focus on providing a friendly, desktop platform with multimedia codecs out of the box. The project has published two new versions: Static 150 which is based on openSUSE's stable Leap edition, and GeckoLinux Rolling 999 which is based on openSUSE's rolling release Tumbleweed edition. " The GeckoLinux project is pleased to release updated spins of both Rolling and Static editions. GeckoLinux spins are based on the openSUSE distribution, with a focus on polish and out-of-the-box usability on the desktop. A large variety of customized desktop options are available in Static (based on openSUSE Leap) and Rolling (based on openSUSE Tumbleweed) editions. After installation to the hard disk, a GeckoLinux system will continue to receive updates from the openSUSE and Packman infrastructures. An installed system can even be upgraded smoothly to future openSUSE releases while at the same time retaining its unique GeckoLinux configuration. " There are several desktop spins and a BareBones minimal spin of each edition. More information on both editions can be found in the release announcements (Static, Rolling).



Devuan GNU+Linux 2.0.0



The "Veteran UNIX Admins" have announced the release of Devuan GNU+Linux 2.0.0, a new stable build from the project that forked Debian in late 2014 to build a systemd-free variant of the popular community distribution. Devuan's second release is based on Debian 9.0 and carries a code name of "ASCII": " We are happy to announce that Devuan GNU+Linux 2.0 ASCII stable is finally available. Devuan 2.0 ASCII runs on several architectures. Installer CD and DVD images, as well as desktop live and minimal live ISO images, are available for i386 and amd64. Ready-to-use images can be downloaded for a number of ARM platforms and SOCs, including Raspberry Pi, BeagleBone, OrangePi, BananaPi, OLinuXino, Cubieboard, Nokia and Motorola mobile phones several Chromebooks, as well as for VirtualBox, QEMU and Vagrant. The Devuan 2.0 ASCII installer ISOs offer a variety of desktop environments including Xfce, KDE, MATE, Cinnamon, LXQt, with others available post-install. " Read the release announcement and release notes for full details.





Devuan GNU+Linux 2.0.0 -- Running the Xfce desktop

(full image size: 83kB, resolution: 1280x1024 pixels)

* * * * * Development, unannounced and minor bug-fix releases

Linux Mint 19-beta (Announcement)

AUSTRUMI 3.8.1

Berry Linux 1.27

Live Raizo 9.18.05.31

Zeroshell 3.9.0

Oracle Solaris 11.4-beta

Omarine 3.2

PCLinuxOS 2018.06

SmartOS 20180607

Clonezilla Live 2.5.6-7

FreeBSD 11.2-RC2

Archman GNU/Linux 2018.06

Neptune 5-20180609

Tails 3.7.1

Torrent Corner

Upcoming Releases and Announcements

Opinion Poll

Running Android on a desktop/laptop computer This week we talked about Android-x86, a port of the Android operating system for consumer desktop and laptop computers. We would like to know what our readers think of running the Android operating system, typically used on phones and tablets, on a laptop or workstation. Would it be helpful to you to have a mobile-style OS running on desktop hardware, or is Android's design unsuited to your workstation habits?



You can see the results of our previous poll on openSUSE's key features in last week's edition. All previous poll results can be found in our poll archives.



Running Android on a desktop/laptop computer



I like the idea of having Android on my workstation/laptop: 312 (17%) I prefer a desktop-oriented OS for my workstation/laptop: 1348 (75%) No strong preference: 149 (8%)

DistroWatch.com News