Distro-hop Linux Desktops like a pro!

Considering Linux for your daily driver? Not settled on a distro yet? Here's how you can distro-hop like a pro without disrupting your daily workflow.

1. Manage a separate /home partition, or a separate drive altogether. Keep all your files and profiles in one place.

2. Install distros on separate partitions. Limit to 2 distros at a time unless you have enough disk space to go around.

3. Use distro repositories for only essential applications.

4. Install your daily driver applications from 3rd party sources:

a) Flatpak

FlatPaks are installed within the distro like any other apps from distro repositories. Install them for all distros you are hopping between. Many modern repository frontends have started including support for FlatPaks directly within them.

b) AppImage from app developer

AppImages stay in your /home and don't require reinstalling every time you install a new distro.

c) If neither FlatPak nor AppImage is available, then installers directly from the app developer. Install these apps within your /home partition.

5. Get familiar with your boot loader. I use systemd-boot as I find it easy to work with than Grub. You might have another preference.

There it is. You've now minimized application version related incompatibilities (looking at you Firefox and Thunderbird) and your settings and profiles travel with you when you hop.

What are your tips or tricks that have helped you distro hop like a pro?

How I learned to program in Scala: The Nexus 5 experiment

Few months back I broke up my long term affair with Mono and I started looking into the the Play Framework from TypeSafe as a replacement stack.

Through Play Framework, I discovered Scala and the wonders of functional programming. My interest grew even deeper when I installed Scala on my laptop and tried some example code in the REPL tool (think Scala interactive shell).

However, I found very soon that I was not able to dedicate enough time during the week to learning Scala due to my full time day job doing .Net development.

Something had to be done.

I thought, I have this wonderfully powerful device on me all the time - my Nexus 5. Surely, I should be able to put it to use to help me spend more time with Scala. So began the experiment.

I rooted my Nexus 5, installed "Linux Deploy" from Google Play Store and installed a chroot Arch Linux environment. I also installed JuiceSSH client and a VNC viewer application. I already had "Terminal IDE" installed which comes with a great android keyboard geared towards software development on Android.

The last piece to the puzzle, I bought a $25 ANKER bluetooth keyboard compatible with my Nexus 5.

I fired up the Arch chroot on my phone, downloaded tmux and vim using pacman and oracle java 7 packages from AUR (some PKGBUILD tweeking was needed).

Then I installed TypeSafe Activator from AUR. I also downloaded vim plugins like vim-scala and CtrlP which proved to be of great help.

It worked!!!

Using the setup described above, I was able to not only learn how to program Scala, I am also able to write software using Play Framework. I can test the same on my phone's browser. The code is backed up on github and I can work on the same codebase from anywhere - as long as I have my Nexus 5 and data connection.

And after the recent KitKat update with Cast Screen - I am able to cast my phone's screen to my big screen HD TV over ChromeCast. This solves the issue of developing on the relatively small Nexus 5 screen.

This experience has made me appreciate VIM, TMUX, and the terminal in general at a whole new level. Even when on my laptop, I now find myself doing more and more coding in VIM instead of IntelliJ.

Think about it, you can now get a decent android box or even a phone, and with a setup similar to what I described, have an almost full fledged development environment. Rich graphical applications can be written in Scala using Swing (sigh) and possibly other graphical toolkits and can be tested within the Arch (or other Linux distro) chroot using VNC.

Side note about Oracle Java instead of OpenJDK: I went with Oracle Java instead of OpenJDK due to an "issue" with OpenJDK on arm chips. Its something to do with JVM running in "mixed mode".

Update: ArchLinux + ATi Catalyst issue

After doing some more reading about the ATi Catalyst 12.6 driver release and upgrade information, I realized that the my hardware, Radeon HD 6250, was indeed supported. The "Unsupported Hardware" watermark was probably a bug that will hopefully be fixed in one of the future releases, whenever that might be. I did find a resolution for the time being that removes the watermark on the ArchLinux Wiki page for ATi Catalyst.

It involves running this following script:

#!/bin/sh
DRIVER=/usr/lib/xorg/modules/drivers/fglrx_drv.so
for x in $(objdump -d $DRIVER|awk '/call/&&/EnableLogo/{print "\\x"$2"\\x"$3"\\x"$4"\\x"$5"\\x"$6}'); do
 sed -i "s/$x/\x90\x90\x90\x90\x90/g" $DRIVER
done

Once this script is run, and the X server is restarted, the watermark disappears. All other functionality, especially OpenGL rendering etc, seems to be intact. Good enough for me.

However, this highlights the problem of having closed source, proprietary hardware drivers. Had the drivers been open, this issue would have been fixed not too long after the drivers get released. Hopefully the open source "radeon" will catch up in performance and features with the proprietary drivers and we won't have to worry about these kinds of issues in the future.

ArchLinux - Use at your own risk

Update: update-archlinux-ati-catalyst-issue.html

I have an HP Pavilion g series laptop running ArchLinux. With 17" wide screen and quad code AMD A6 processor, I really have nothing to complain. I love Arch. It allows me to be on the bleeding edge. Among all the other distros that I have tried in the past, Arch gave me the most control with out as much hassle. Today, I use ArchLinux exclusively on my laptop. And getting front row passes for being able to try the latest and greatest of features of Linux almost makes me giddy. Except, I am stuck with AMD Radeon graphics built in the APU.

AMD/ATi are not very keen about providing regular driver updates for the AMD Radeon chip that is in my computer. The open source driver lags far behind the proprietary driver in features. The proprietary driver relies on xorg-server version 1.11 while the latest xorg-server is version 1.12. Staying stuck with xorg-server 1.11 means that while my X server is slightly behind on features and security updates, but also are all the components that depend on it, for instance, XFree86 drivers for my input devices. During every system wide update, I have to be extra careful as to not update any of the XFree86 drivers as there is not a hard dependency extablished for xorg-server between the versions that I use. An incompatible input device driver renders my keyboard and touchpad unuseable as soon as X session takes over, regardless of me using the laptop keyboard and touchpad, or an external keyboard and mouse.

This was a little easier until a few days ago. The version of Catalyst driver available was 12.4 which had a hard dependency on xorg-server 1.11. All I had to worry about were XFree86 drivers.

Few weeks ago, AMD released a new Catalyst driver for newer hardware, version 12.6. Unfortunately for me, my hardware is not capable of utilizing that driver as it was excluded from the driver. When I installed it without reading the Arch Wiki page about the upgrade, I noticed that bottom right corner of my screen displayed a watermark - Unsupported Hardware. 12.6 version of Catalyst however is listed as an upgrade to the 12.4 version of Catalyst. So now it shows up in my list of upgrade. Changing the pacman mirror for Catalyst resolved the issue as the new mirror only had 12.4 available for download.

A few nights ago, I was in bed at around 10:30 PM and I was hoping to sleep right away. I decided that since I hadn't run a system update in the past few days, I'd go ahead and run a quick update before sleeping. I fired up Apper, a universal KDE package manager that works with Pacman as well as Apt-Get for debian based systems, and saw 30 some applications awaiting updates. I scrolled down the list and unchecked the usual suspects: xorg-server 1.12, etc. I realized that somehow, I had failed to notice Catalyst version 12.6 in the list of updatable software and did not exclude it. I realized my mistake one X server restart later when the nasty watermark became visible. I figured it was not as big a deal and fired up Apper with the intention of downgrading the Catalyst driver to 12.4. Except, it wasn't there. I decided to switch to the open source driver for the time being while I investigated what might have happened. The open source driver was installed and I was at the login menu. All looked good, except, my keyboard and touchpad wouldn't work. The open source driver has a dependency on latest version of xorg-server. I realized later that when I installed tthe open source driver which caused the xorg-server upgrade, I hadn't selected the XFree86 input driver for synaptic to be upgraded. The version of the input driver that was installed had a dependency on older version of xorg-server and now the missmatch was causing rendering my laptop useless as soon as X session started.

Fast forward couple of very frustrating hours and I was able to break the boot process before X session loaded to get terminal access to a half ready system. Then after remounting the root partition as read/write, I unstalled xorg-xserver and all the installed dependencies. A reboot later into a more usable and now network aware system, using terminal, I installed the open source ati driver. Once I was able to log into the KDE session, I fired up Apper again, and this time more careful about it, I manually downloaded the correct version of Catalyst driver from the mirror site, uninstalled the open source driver and downgraded xorg-server and the hard dependencies as well as XFree86 input driver. I then using pacman installed the 12.4 version of the Catalyst driver and restarted X server. I was now able to login and use the system and begin my efforts at documenting my experience.

Walking on "The Arch Way"

I had once started down the Arch path before. Back then the intent was to revive old Fujitsu Tablets. As soon as the Live image fired up I abandoned it. It was then I realized that Live CD doesn't mean Live CD with X. Yesterday I found myself research Arch in my quest to find a lean Linux distribution that was on a rolling release. Arch was the answer and it had the latest versions of all software that I needed current.

Having used Linux for over six years, I was still intimidated by Arch because of what I read about it. GUI installers are against "The Arch Way". There was this whole text-file-based configuration editing step that I had read about and was not too fond of. However, the part that scared me the most about the non-GUI installer was the disk partioning. I have 100GB of data on my home partition that I wasn't going to sort through before installing Arch. Also, I was not too thrilled by the idea of running a back up of that data over USB either. Frankly, I felt that "The Arch Way" was frankly getting in my way. But sticking with Kubuntu was no longer the option and I couldn't find any other Linux distribution to be a viable alternative either. I decided to read through the beginner's guide on the ArchWiki and fire up a virtual machine to get a feel for the installation process and to see what the final product might look like.

To my surprise, the installation was not nearly what I had expected. It was very straight forward and methodical. Having already read the beginner's guide also made it a lot easier to follow through. I made sure I familiarized myself with the partitioning utility during the installation. Besides the computer's host name, I did not have to change any of the defaults in the configuration editing step. The defaults were quite sufficient. I was able to follow the steps from the beginner's guide and setup X and KDE and was able to boot into KDE session on the new Arch VM. To be certain, I tried this routine one more time and made some mental notes.

Since I was going to install Arch on my laptop, I decided to not hook up the ethernet cable for Internet and rather do the post installation updates over WiFi. I already had my wpa_supplication configuration file in my home directory. I would come in handy during post installation. I made note of the UID of my user account under Ubuntu. This would surely come in handy once Arch is installed.

During the installation:

1. On partitioning section, I made sure that I didn't reformat my home partition.

2. On the configuration editing step, I changed the HOSTNAME to what I had previously had under Ubuntu.

3. I skipped editing the network configuration as that was needed only for ethernet based Internet updates.

4. On the package selection step, I selected sudo and all the network and wireless related packages.

After the installation, after reboot, I checked to see if my home partition was still intact. And it was. I created a new user for my login and used the UID that I got when I was still running Ubuntu. I fired up the WiFi with the following command:

wpa_supplicant -Dwext -i wlan0 -cwpa.conf -B

dhcpcd

I was connected to Internet through WiFi which I validated by issing a ping to www.google.com. I modified the /etc/pacman.d/mirrorlist file to uncomment the mirrors for my updates. After that I ran the pacman update command:

pacman -Syu

This updated the pacman database and started the initial update process. Once the update was done, I followed the instructions from the beginner's guide to install X and then KDE. I followed the KDE guide on the Wiki to setup kdm as the display manager. Once KDE was installed, I rebooted. After the reboot, I was presented a graphical login screen. Once inside KDE session, I had to restart wpa_supplicant for WiFi. I also realized that the network daemon was slowing the boot process. I disabled it from the rc.conf file.

The Wiki mentioned about graphical tools for package management and KPackageKit/Apper was one of them. Since I had used Apper with Kubuntu and was familiar with its functionality, I decided to install it. Installation of Apper was probably the trickiest thing to figure out during this entire exercise. But I was able to install it from AUR. Once Apper was installed, installing other software became a piece of cake. I installed all the plasma widgets and plasmoids. This enabled me to use the Network Management plasma widget that I was accustomed to under Kubuntu. Since it needed NetworkManager to function, I installed NetworkManager daemon and enabled it in rc.conf file. On the next reboot, I had networking and I could get on the WiFi using KDE's network management settings.

I did realize that while I had my home folder from previous setup, my desktop and KDE settings had disappeared. Since I knew that Kubuntu stored user level configuration under ~/.kde/share, I decided to take a look. I did find that there was a ~/.kde4 folder under home along with ~/.kde. This was it. Arch was using the ~/.kde4 folder instead of ~/.kde which was why my previous settings had not taken effect in the new setup. I copied the share folder from .kde to .kde4 folder and logged out. After loggin back in, I was in a familar workspace.

With all my software installed under the ArchLinux and with my original KDE settings restored, it feels like I never switched distributions.

One of the things that I had forgotten to do was to create a group by the same name as the user as Kubuntu did. That caused a temporary permissions issue which I was able to resolve without much difficulty.

I hope this information will be helpful to those who are considering to move to a different distribution but my be intimidated by what they might have read about it.

Good bye Kubuntu

I never thought it'd come to this. I was content with what I had. I had been using Kubuntu full time since their 7.04 release. Kubuntu was the realization of my love for the KDE desktop environment as it offered near latest builds of KDE desktop and all of the software that I needed for everyday computing. I was a happy camper.

While I was already familiar with Linux, KDE desktop was what converted me into a fulltime Linux user and Kubuntu was the only distribution that I had found to implement KDE well. So the decision to switch away from Kubuntu to another KDE based desktop was a difficult one. There were three factors that led me to consider an alternate KDE distribution.

Until a few months ago, I used my computer only for regular everyday tasks like for messaging, surfing, e-banking, online shopping, etc. I did some programming, but that was mostly as a hobby. Few months ago I started spending more time doing application development for more than just recreation. I mostly develop using the Mono framework on my Linux machine. Since Mono is integrated with Ubuntu, to ensure stability, Canonical does not offer updates to Mono very often for Ubuntu. Mono packages for Ubuntu lag behind the official Mono releases and recently the gap has only widened. Since, and this is by design, Mono itself lags behind the latest .Net Framework, to be able to utilize the power of the latest release of Mono, I have had to compile it from source on my laptop on number of occasions. I've had to do this after every Ubuntu upgrade every six months since the Ubuntu upgrade would cause some of the dependencies to be overwritten.

Canonical releases Ubuntu on a schedule with one release in April and the other in December. This means that while the system receives regular updates, major features and enhancements are only released with those scheduled releases. These features and enhancements are not only those that Canonical might include in the new releases of Ubuntu, but they might also include enhancements to Desktop Environment and to the Linux Kernel etc. Sometimes, waiting for a full release in order to avail some of these enhancements doesn't seem justifiable.

I would have still continued using Kubuntu, if it weren't for the news that I came across couple days ago. Canonical will be discontinuing funding the development of Kubuntu. Now for some perspective, Canonical had one paid full time developer who is responsible for KDE implementation in Kubuntu who they would no longer fund for the effort and Canonical would continue to provide only infrastructure support to Kubuntu. I am sure that this does not mean the end for Kubuntu. But it might mean that KDE related updates to Kubuntu would become more infrequent over time. Due to the lack of full time developmental resources from Canonical, the effort might even be taken over by the community for KDE related maintenance.

I did some research on different Linux distributions to replace Kubuntu on my laptop. The criteria was set: I needed a distribution that would allow me to easily install and upgrade to the latest versions of software, especially Mono Framework and KDE, along with the latest Linux Kernel updates. After reviewing my choices against the criteria, there was only one clear winner - ArchLinux. I chose Arch over other Linux distributions because of its rolling release and the availability of latest versions of the software that I use almost everyday. I now have KDE 4.8 and Mono 2.10.8 installed under ArchLinux on my laptop. After installing Apper for package management, I've also found myself on familiar grounds again. The transition was as smooth as one could hope for and I am already beginning to enjoy my new distribution.

I will always have fond memories of Kubuntu though, as the distribution through which I first experienced Software Freedom. But it is time to move on.