Latest Entries »

Flash has been slow in supporting 64 bit browsers, so a popular approach to have Flash on a 64 bit Linux machine is to use the 32 bit version of Flash, and then use a plugin wrapper called NSPluginWrapper to make it available to browsers. In most Linux distributions, this has become pretty standard.

Opera, however, has its own plugin wrapper, which handles 32 bit Flash just fine, and which confuses NSPluginWrapper. As a result, guess what? You install adobe-flash, then you install nspluginwrapper, and there you have Flash on Firefox and Chrome, but not Opera! The solution is to tell Opera to use the 32 bit plugin instead of the wrapper. Below is how to do that.

  1. First let’s assume that you have installed Opera and Flash from your package manager (this greatly depends on your distribution).
  2. Find out where the plugin’s shared object is installed:
    locate | xargs file
    On my Gentoo installation the result is

    /opt/Adobe/flash-player32/plugin/ ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, stripped
    /usr/lib32/nsbrowser/plugins/ symbolic link to `/opt/Adobe/flash-player32/plugin/’
    /usr/lib64/nsbrowser/plugins/ ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, stripped

    The first item in the output is the place that the plugin is installed. The second is just a symbolic link to the first, which is not very important. The third result is the plugin wrapper. 64 bit Chrome and Firefox will ignore the first two items and use the wrapper (where it works), and so does the default configuration of Opera (where it doesn’t work).

  3. Now open Opera, go to Preferences..., Advance tab, click on Content on the left, then Plug-in Options... on the right. A dialog will appear to let you know where plugins are being looked for (Plug-in path). On my system it shows:
    This is a colon-separated list, which means plugins will be looked for in /usr/lib64/opera/plugins and /usr/lib64/nsbrowser/plugins. Thus it will find the wrapper above instead of the 32 bit version.
  4. Click on Change Path... and add the location of the right plugin. For my case, the resulting path is
  5. Restart Opera and everything should be fine!

Today I migrated a bunch of virtual machines and there was this little bug that brought some headache. My planned workflow was, for each domainname in old VM host:

  • Copy disk images to new VM host
  • Copy the domain’s XML file to new host
  • Run virsh define domainname.xml

Unfortunately, that was far from the truth, because I was greeted by a blank console. virsh list said that the domain was running, but there was no sign of life from it. virsh console gave the blank console, virsh shutdown doesn’t do anything besides the promise that it will shutdown the domain soon. Luckily I learned about virt-manager, which gives me a real console that can see all output that should be on the screen, including the boot messages. To you it may seem a little backward, but I actually learned to use virsh before virt-manager. It says:

Boot failed: not a bootable disk. No bootable device.

Using virsh edit domainname and read the XML really carefully, I found the problem:

<disk type=’file’ device=’disk’>
<driver name=’qemu’ type=’raw’/>
<source file=’/srv/vms/domain/root.qcow2′/>
<target dev=’hda’ bus=’ide’/>

As you can see, somebody marked root.qcow2 as a raw image. Holy cow! Obviously it was not a raw image, it’s qcow2! Changing that single entry let my machine boot just fine. The same thing happened to several servers that I was migrating.

Now, why? I log on to the old VM host and run virsh edit domainname to see whether it was I or another sysadmin who made this silly mistake. To my surprise the “driver” line wasn’t there. Aha, so it was virsh define who added that line, and failed to take into account the type of the disk image. A version check shows that the old host is using 0.6.1 whereas the new host is 0.7.5.

Suggested fix: libvirt 0.7.x (where x >=6) can/should do one of the following:

  1. Try to detect the type of the image. A simple file root.qcow2 can determine whether the file is raw or qcow2 or whatever other format.
  2. Stop adding the driver line. Seriously, the specs say that it’s optional, so there is no need to add a wrong entry. I think without the driver line libvirt will detect the type at VM start time just fine. One of my servers ran fine on a file named root.qcow2, which is actually a raw image ;)

Recently I started to work with a lot of servers, and it’s simply annoying to have that shell prompt without colors, or a default plain Vim config without the plugins I so love. So I searched on how people keep their configuration across multiple (Linux) machines, and narrowed down on 2 most popular approaches. However, in the end, I chose not to follow any of them, but a modified version of my own.

Approach #1: Dropbox

This is thoroughly explained on Nixtutor. Basically you install Dropbox on all machines, put config files in a folder inside the Dropbox, then link things from there to your home. Easy!

Approach #2: Version control system

If you think about it, dotfiles can be considered a software project, be it personal or shared. That way, it makes perfect sense to put them into your favorite version control system. Usage is very programmer friendly: you create a project, put your dotfiles there, then have copies of the project on all machines you care about, and link things from there to your home. Geeky!

Both approaches can be augmented by a simple script that create the symbolic links from the actual dotfiles inside your Dropbox folder or your repository. Unfortunately there are faults that put me off using any of the two (see below next).

Approach #3 (which I’m using): A modified version of #2

  • Keep dotfiles on GitHub (surprise!)
  • Write an install script that will download individual files / exported project from GitHub (the one you can access via the huge “Download” button) and put them in the right place, making backups as needed.
  • On a new machine, download the install script from GitHub, chmod, execute and that’s it.
  • Customizations can be made on each machine as needed.
  • New versions of the configuration can be retrieved simply by re-running the install script. If customizations have been made, merge with the backed-up dotfiles. This can be improved by having the install script detect things and automatically open something like vimdiff, but I don’t feel the need for it now.

And why exactly is #3 better than #1 or #2?

Mainly it’s because of the annoyance one has by using Git for #2

  • [Dropbox] I like Dropbox but the hacky installation is not really suitable for servers.
  • [Git] Tricky access control destroys the purpose of having a distributed repository. On any machine other than my one workstation, I can’t push because I don’t have the SSH keys that I use for GitHub.
  • [Git] It’s cumbersome to handle third party code like Vim plugins. If you put them in your own repository you create duplicated code which is bad. If you link to other repositories using submodules you are in for a lot of headache maintaining them, not to mention the time it will take to clone the submodules. For large/popular plugins, downloading a tar.gz archive of the project (thanks to GitHub for providing this feature) is so much faster because it doesn’t include their history, which you don’t care about.

Update: And here is that GitHub repository of mine, with the install script that I talked about: terminal-dotfiles.

I have just performed a BIOS upgrade for the first time and while it doesn’t solve the problems I wanted it to solve, knowing how to do it gives me a good feeling.

Actually the thanks go to EZ Flash, the utility employed by the current BIOS, which is described as “the best, the safest and the most convenient way to update BIOS”. Asus sure did a good job in choosing it for my laptop :) If you are about to upgrade your BIOS, go ahead and read EZ Flash 2 – the safest way to update BIOS.

The article was not flawless, at least not for my laptop. I tried EZ Flash with a “FAT/FAT32 formatted USB Flash Disk with only one partition” but no file showed up for me to choose the new ROM to upgrade to. I found out, I need to make a drive without any partition (aka a superfloppy drive). Here is how to do that from Linux (assuming the drive is mapped to /dev/sdb):

# Run the partition table manipulator
fdisk /dev/sdb
# Press 'p' to print the partition table and double check this is the drive you want to format
# Press 'o' (lowercase letter) to create a new partition table
# Press 'w' to write the changes and exit

# Create a FAT filesystem on the drive, -I is to force mkfs to create the filesystem on the whole drive
mkfs.vfat -I /dev/sdb

And you are done, now copy the ROM you downloaded from Asus and reboot, pressing F4 on boot to start flashing!

For quite some time I have been using NTFS as “data” partitions for my Linux installation. It has a history dated back to the day I was still dual-booting Linux and Windows. Having NTFS partitions that hold shared data was obvious. Then I began multiple-booting multiple Linux installations (and Windows), and found out having data partitions that do not support permissions makes it easier to share data between Linux installations. I deleted Windows a long time ago, but still keep those data partitions as NTFS.

Today I try to get MongoDB to work on my computer, and I run mongod --dbpath=/ntfs/mount/point/database. After long hours of frustration and “What’s wrong with the computer?” I found out if I run mongod --dbpath=/home/phunehehe/database then things turn out perfectly OK.

This reminds me of the time long ago, when I was learning J2EE. The exact same problem happened to Glassfish and/or NetBeans. Firstly I installed them (the “portable” version) on an NTFS partition, I ran my helloworld project and got inexplicable exceptions. I tried to find the problem, and ultimately had to reinstall both. Just for the quick test, I install them in my home directory “They won’t work anyway, so just click next and delete them afterwards”. To my amazement the project ran flawlessly. I installed the thing back on my data partition, exceptions again.

I know I should have tested Glassfish/NetBeans more carefully to find out which one was the bad boy, but I was chasing an assignment back then. Now seeing the problem with MongoDB, I am seriously thinking against having those data partitions in NTFS. Fortunately I have prepared for this by asking How to setup a “data” partition shared by multiple Linux OS’es?. 99.99% of the time things will work just fine, but it’s the subtle 0.01% that causes errors you cannot explain.

I’m off to ext4 now. Bye bye NTFS.

Choosing a license for FOSS

First of all I’m not a lawyer and second I’m not trying to teach you how to choose a license. I am merely recording how I landed on the Mozilla Public License (MPL) as my favorite FOSS license. Also, I do not dislike, hate or aim to insult any other licenses, as all FOSS work is respectable.

I am starting a project that I want to be opensource and hosted on GitHub as I work on it. So I register an account there (yes shame on me, I haven’t got a GitHub account up til now) and start to poke around. Having been familiar with Google Code for a while, I look for a place to pick a license for my project. That option is nowhere to be found. Instead the Terms of Service basically says that I’m on my own with licenses. Hating licenses as much as I hate [company name removed], I think it’s a good time to learn about them.

Being a Gentoo user who happened to have read about handling licenses and know about license groups, I immediately think of these two lists:

There are just too many for me — a lazy reader of law and everything law-related. Luckily I found on the website of the Open Source Initiative, “License that are popular and widely used or with strong communities“. 8 doesn’t look like an incredibly small number, but it’s enough for me to drill down and read about them.

To speed up the process, I decide on the characteristics of the license of my dream, then filter the list. I want a license that:

  1. Requires those who benefits from my code to contribute back (like the GPL, but not like the GPL, see next item)
  2. Is not as restrictive as the GPL. To some extent I agree with the criticism: “That’s a bit like the person who made the nails you used claiming he has the right to your entire house.”
  3. Is preferably compatible with the GPL. To some other extent I like the idea of the GPL, so if somebody else uses my code and want to release their code as GPL they should be able to.
  4. Is easy to read and understand (added after reading the terms of the LGPL)
  5. Has anything else a license should give me: I shall have the credit for my work, people don’t sue me, blah blah blah

For each license in the list, I go to Wikipedia to find out the easy details and read the full text of the interesting ones:

  • Apache License: Too permissive
  • BSD licenses: Too permissive
  • GNU General Public License (GPL): Too restrictive
  • GNU Lesser General Public License (LGPL): Too complicated. I think it takes both a lawyer and a good software engineer to understand this text. When I try to read it I understand why it was previously named “Library General Public License”, but unless I have too, I don’t want to take this route.
  • MIT license: Too permissive
  • Mozilla Public License (MPL)
  • Common Development and Distribution License (CDDL)
  • Eclipse Public License (EPL)

So here comes the little comparison of the 3 short-listed candidates. The MPL, the CDDL and the EPL all support weak copyleft (requirements 1 and 2). However there are small points that make the MPL more appealing to me:

  • I don’t like the fact that the CDDL comes from Sun, which is dead. I think I’m being paranoid, but I’m uncomfortable to hear that I won’t receive updates for the license.
  • I can’t seem to grasp the implications the EPL placed on patents and the US copyright law’s definition of derivative works (too long, isn’t it?).
  • Both the CDDL and the EPL have some controversy associated with them. If only I were more knowledgeable about the law… For now I’ll try to stick with what I understand. The MPL also comes with the thing called the tri-license, which sounds crazy at first, but I have found that I like it.
  • Both the CDDL and the EPL are GPL-incompatible. The MPL has a provision that allows another license as an alternate choice. I like the idea of providing my things in MPL, and allowing people to use it as GPL if they so wish.

So today I learned a lot about software licensing, which is tiring but also inspiring.

Every once in a while you need to copy files from one computer to another. Across different operating systems, a sneakernet (read: copying files using a USB flash drive) seems to be the best option because most (if not all) computers can handle a USB. However, the process may be cumbersome if:

  • You have to deal with large file(s). As the file size grows you will realize that this approach is not efficient. You need to copy from the first computer to the USB, then copy from the USB to the second computer (then optionally delete the file in the USB).
  • You have to do it several times. Maybe because the files are too large for one time transfer, or maybe because you forget some files on the first trip. If the file is 4GB and you have a 2GB USB then you even have to split and join the file.
  • You don’t have a portable USB disk drive :(

Enter Python, a place where just about everything is ready-made and included! Here are the steps to share your files with Python’s built-in HTTP server:

  1. Install Python on the first computer (the one with the files to share). This is mainly for Windows because most Linux distributions as well as Mac OS X include Python. Yeah!
  2. Put the two computers into the same network. For example, by connecting them using a LAN cable and setting their IP addresses to and respectively.
  3. On the first computer (with IP address, open up a command prompt, navigate to the folder where the files are kept. Execute the command python -m SimpleHTTPServer 8000 (where 8000 is a port number that can be omitted)
  4. Now on the second computer open up a web browser (any web browser: Firefox, Chromium, even IE) and visit and download your files at


Sometime ago I was wondering if there is a lightest way to have GUI in Linux. The short answer is, you need the X server and a window manager. There are many window managers to choose from, ranging from Compiz – the fancy compositing window manager – to the lightweight window manager dwm. Ubuntu uses Metacity as the default window manager for GNOME, and KWin for KDE.

If you don’t care about dazzling effects or if you have a slower computer, you may not like GNOME or KDE that much, because they are packed with functionalities that you cannot or don’t want to use. In this post I will try to show how you can get your job done without a desktop environment, by using Metacity without GNOME.

Using GNOME Display Manager

First you need to add a login manager session by creating a file /usr/share/xsessions/metacity-session.desktop with this content:
[Desktop Entry]
Comment=Metacity without GNOME

Then create the file that will get executed by the above Exec part (create a file /usr/local/bin/metacity-session):
if test -z "$DBUS_SESSION_BUS_ADDRESS"; then
eval `dbus-launch --sh-syntax --exit-with-session`
metacity --replace ccp & wmpid=$!
sleep 1
if [ -f ~/.metacity-session ]; then
source ~/.metacity-session &
xterm &
# Wait for WM
wait $wmpid

You will need to make the file executable by running sudo chmod a+x /usr/local/bin/metacity-session.

Now create the configuration file ~/.metacity-session. To begin with, you can let its content be
gnome-panel &
nautilus -n &

which makes your session look like GNOME (note the & at the end of each line, it’s required).

And you’re done, log out and you can see your entry “Metacity” in the Sessions option at the bottom of the page.

Using startx

If you want to get rid of the login screen altogether, create the file ~/.xinitrc and add the programs you want to start, such as
#!/usr/bin/env bash
gnome-panel &
nautilus -n &
exec metacity

Remember, the last line should contain exec plus your favorite window manager (in this example I use metacity)

Remember to disable or uninstall GDM. Upon booting you will have a terminal console in which you can log in. After that type startx to bring up the X server.

There, your session will be super light!


CustomXSession – Ubuntu Wiki
CompizStandalone – Community Ubuntu Documentation

Congratulations Unix and Linux – Stack Exchange!

I am definitely supporting this Unix & Linux Q&A site!

The new Unix & Linux Stack Exchange site is now open to the public!

After just 7 days in private beta, we’ve already got 364 users who have asked 133 questions and written 437 answers. We’re off to a good start, and it’s time to unleash this baby on the public and see if it flies. (Sorry; mixed metaphor.)

Tell all your friends, blog about it, tweet about it, and write the URL ( in chalk on the sidewalk in front of your neighbor’s house. Or paint. No, never mind, better use chalk.

Most importantly, go to the site now and start earning reputation and badges! We’ll see you there! Right now! <– that is the URL again <– it has not changed in the last 10 microseconds

All the best,

The Stack Exchange Team

Recently I wanted to install Dropbox on my Ubuntu box. I didn’t want to download the deb file and install it manually so I first added the Ubuntu repository of Dropbox by going to Software Sources >>> Other Software >>> Add and entering the line
deb lucid main
Then of course Software Sources complained about some invalid authentication, because I haven’t added authentication for the new repository. As the instruction from Dropbox says, this should easily be done with
sudo apt-key adv --keyserver --recv-keys 5044912E
Unfortunately I’m under a proxy server with authentication and I don’t want to mess with proxy settings just yet, I point my browser to and search for “dropbox”. Finally I reached a page that looks like this

Public Key Server — Get “0xfc918b335044912e ”

Version: SKS 1.1.0


After some trial and error I figured out how to use this information.
First you need to copy the text from -----BEGIN PGP PUBLIC KEY BLOCK----- to -----END PGP PUBLIC KEY BLOCK----- (including those two lines). Then save it into a file, let’s say key.gpg. Now go to Software Sources >>> Authentication >>> Import Key File and point to that file you saved. Now you should have the new repository ready.