eBay Strikes Again

Though not eBay of course, but its bidders.

I think I have already expressed my feelings about bidders on eBay who push the price of an item far beyond the item's retail price. I still fail to understand the nature of such behavior, yet recently eBay has given me a couple more examples.

Recently I have been on the hunt for cheap water filter replacements. Amazon.co.uk has a six-pack of them for 16 GBP with the traditional Amazon free delivery. I thought I would check up eBay before making a purchase. Recently, an item ended - as a result of 14 bids the winner got the same six-pack for 16 GBP + 4.99 GBP for delivery. How crazy is that?

Another example - I've been looking to purchase a coffee Moka pot. Again, 21 GBP for a brand new one delivered at Amazon vs astonishing 21 GBP + 6 GBP delivery on eBay.

I still fail to understand what motivates these people to push the bids up so high. Clearly, anyone making bids on eBay is aware of Amazon and would at least check what the retail price of the item is before making a bid. I was thinking that maybe some tend to think that the delivery from an eBay seller for which they have to pay an extra may be faster than Amazon's free service, but then again, these people have 5-7 days to wait for an auction to end, thus time is hardly critical for them. I can't understand why one would not only prefer a shady eBay seller with no warranty or returns against good old Amazon.

Whatever the reason, it all makes me sad and angry. I come on eBay to hunt for good deals and expect them to be lower than the retail price of the item. Unfortunately, many a time this is not the case.

Awesome WM: Remove Border from Maximized Windows

I am currently using quite a bright theme with my Awesome WM on Linux and the borders of an active window are of quite a bright blue color. While this really helps in easily identifying the active window in a tiled layout (i.e. with several terminal windows side by side), such a bright border can become a nuisance when it appears at all times around a maximized window such as Firefox.

Here is a simple workaround to remove the border from maximized windows and put it back when a window is unmaximized:

Replace this line:
client.add_signal("focus", function(c) c.border_color = beautiful.border_focus end) 

with the following code:
client.add_signal("focus",
        function(c)
                if c.maximized_horizontal == true and c.maximized_vertical == true then
                        c.border_width = "0"
                        c.border_color = beautiful.border_focus
                else
                        c.border_width = beautiful.border_width
                        c.border_color = beautiful.border_focus
                end
        end)


The apparent shortcoming is that the window must have to be focused at least once for this to work - I haven't found a better hook other than focus to attach the code to.

How to transfer Amazon EC2 instances from one account to another

OK, I have to write it down right away before I forget all the details.

Tomorrow is the last day of my Amazon AWS Free Tier, so once again, just like a year ago, I had to create a new account to keep running a micro Linux instance for free (digression: I've spent some time comparing the EC2 prices to Hetzner virtual hosting and as it turns out, it makes no sense to pay for EC2 with my demands, Hetzner will turn out to be much cheaper. However, since it's free, nothing can beat it).

Last time I've done this I actually had to manually transfer all my data to a new Linux installation. This time I thought there were better ways to do that, as I couldn't afford to waste all the time recreating all the setup over again.

So, here's what you need to do to transfer a running EBS instance to a different account:

0. Take a note of the specs of the AMI that you're using. Most important parts are the architecture (i386 or x86_64 and the aki of the kernel being used).

1. Set up a new account while still using the old one. You can even use the same credit card, all you need is a different email address.

2. There are two ways you can go here. The aim is to create a snapshot that is owned by the new account, not "rented" from the old account:
2.1. Use the old account to create a snapshot of the running AMI, then share the snapshot with the new account.
2.2. In the old account share the running AMI with the new account. Then, in the new account create a local snapshot of that AMI.

3. Either way, you should end up with a snapshot that is owned by the new account. To confirm, remove all sharing from AMIs and snapshots in the old account.

4. Open up the snapshots list in the new account and click "Create image". Set up the AMI as usual but be sure to check that architecture and the aki match those that were used before with this AMI. Otherwise, the instance will appear to have started but will not respond to any interaction.

5. Use the new AMI to start a new instance as usual.

And you're done. Now you can double check that everything is working fine and remove the snapshot which uses up the S3 space, and can easily exceed the 5GB Free Tier allowance.

Cray

Whenever I become rich, in the lobby of my building I will have a Cray-1 instead of a fountain:

Linux Power Usage

I have been obsessed by the power usage of Linux on my Lenovo T400 ever since I first installed it. The reason is that I still can't get over the fact that in Linux the same hardware consumes more power than in Windows, leading to a shorter battery life as a result. The funny thing is that now that my laptop is 3.5 years old, its battery has lost 40% of its original capacity, bringing the time on battery from impressive 6-7 hours to the usual 3-4. Yet I tend not to notice this drastic deterioration but instead continue to fight with the fact that in Linux my laptop works 15 minutes less than running Windows. It is a matter of principle now, I guess.

In any case. Up until very recently I've been running Arch Linux and have been a very happy camper about that. Yet, when Kubuntu 12.04 came out I couldn't help but write it to a USB flash and boot up to see what progress has been made. What I did notice is that a fresh Kubuntu consumes less power than my Arch setup for which I had carefully enabled every possible power-saving feature. I compared the system in the idlest possible mode: hard drive was stopped, all powertop tweaks enabled, the brightness on 50%, wireless killed. With these parameters my Arch showed consumption of 12.8-12.9 Watts, yet Kubuntu yielded 11.8. One Watt difference is indeed impressive and enough to get me started.

First thing to note is that in the example above Kubuntu is loaded from a live USB flash, a completely bare system with no extra software installed. Arch, on the other hand, has been in constant use for quite a while and has a number of additional software installed. While I took care to exit any active applications (such as Firefox, Skype, Kopete, etc.) that might influence the test, I understand that a number of services might still have been running. My primary suspect is VMWare - even though there were no virtual machines running, powertop showed that some power has been consumed by running vmware daemons. Of course, it means that such a comparison can not be a clean one, yet it makes sense to take not of these values for future reference.

My next step (out of sheer curiosity) was to compare the same idle consumption of other flavors of Ubuntu to see how desktop environments influence it. I have also tried Chakra Linux running KDE which is the closest one can get to a clean Arch install without having to spend a week setting it up from scratch. Also, Windows is included as a sort of a sad point of reference. Here are the results. As above, all measurements were taken with killed wireless, brightness at 50%, installed powertop with all tweaks enabled and suspended hard drive:
Kubuntu - 11.8
Ubuntu - 11.9
Xubuntu - 11.6
Chakra - 12.0
Windows - 10.5

The results are rather self-explanatory. It appears that Ubuntu developers have really put a lot of thought into the power saving features of their distribution. Yet it is the XFCE flavour that can utilize them best, apparently due to the much "lighter" nature of the desktop environment which does not use any hardware-accelerated effects unlike Unity and KDE's Plasma. But otherwise Ubuntu results are all within statistical deviation. Chakra does slightly lag behind Kubuntu with a difference of 0.2 Watts, but it is hardly a noteworthy difference. And of course, one can only dream to achieve a Windows result of 10.5 Watts in Linux.

I understand that such a method of testing power consumption where the system is put into its maximum idle state is hardly the best, and is distant from the real-life use patterns. Yet it is the only way I thought of that would put all of the systems in the same conditions, thus allowing for a comparison.


After seeing these results I thought I would give Kubuntu a go as a permanent installation and see how it deals with real-life tasks. I archived my Arch partition and installed Kubuntu and the same set of software that I have been running on Arch. Now, running the same test as above gives me a result of 12.5-13.0 Watts, which is exactly comparable to what I have had in Kubuntu. It thus appears that a loaded system, even with all the visible applications turned off, still consumes about 0.8 Watts more power than a clean one loaded from a live USB. To sum up:
Clean Kubuntu: 11.8
Used Kubuntu: 12.5-13 (difference of 0.7 or more)
Chakra (i.e. clean Arch): 12.0
Used Arch: 12.8-12.9 (difference of 0.8 or more).

It is thus visible that the difference between the two systems is indeed negligible with Arch consuming the same amount of power as Kubuntu when tested with loaded configurations. Subjectively though, it seems that Kubuntu is using less power under normal use, or at least "calms down" to a lower consumption after load faster than Arch had, but that might only be an impression and there is no way to measure this for sure. I am still anxious to see the power consumption of a clean Arch installation (not Chakra, which is deemed somewhat bloated by some) and I hopefully will, the next time I install Arch.


Finally, another small experiment in this series of tests yielded a rather strange result. Instead of disabling wireless, quitting all the running apps, etc. I decided to see how much power the systems consume right after startup, without any modifications whatsoever. The conditions are as follows: all applications running (Skype, Kopete, qBittorrent), wireless is connected and transmitting something (though nothing in particular is being downloaded). The only tweaks I've done was to set brightness to 50% and suspend the hard drive. The Windows setup essentially runs the same set of similar applications, so a comparison can be made. Results:

Used Kubuntu in the max idle state: 12.5-13
Used Kubuntu in the untouched state: 12.4-12.6
Used Windows in the max idle state: 10.5
Used Windows in the untouched state: 12.5

These results are indeed interesting. It is easy to see that disabling wireless and all running applications makes no difference to Linux whatsoever (while I surely did expect disabling wireless alone to save at least 0.5 Watts of power). In Windows, however, it brings the consumption down by 2 Watts. This leads me to believe that there are some techniques in use in Windows that allow the system to go to a deeper state of sleep once there is nothing to do. For some reason, Linux is incapable of doing the same. However, under normal usage for everyday tasks it seems that both Windows and Linux consume a rather similar amount of power, with Windows' benefit being its ability to go into deeper states of sleep after a high load. Linux seems to be doing it slower and never goes as far down as 10-11 Watts achievable in Windows.


It's difficult to draw any conclusions from these findings. Comparing power consumption of different Linux distributions is a difficult task when the differences are in tenths of a Watt. Comparing Windows and Linux is more difficult still. For now at least, it appears that all Linux systems consume a similar amount of power, however, there is an approximately 0.8 Watt difference between a bare system and a system that has been used for a while and thus has more daemons running. Power consumption under Windows is still the lowest possible, being approximately 1-2 Watts lower than Linux in idle states. Under normal workload however, it seems that the consumption of both systems is similar.

vgaswitcheroo conquered!

For quite a while switchable graphics on my Lenovo T400 laptop has been the only thing that wasn't working properly (or at all) in Linux. Inability to keep the both cards enabled for when I wanted to use one of them in Windows led to me using the weak integrated Intel card for the sake of power consumption, as it was disastrous to leave the discrete ATI Radeon 3450 on for lengthy periods of time - system power consumption jumped up to 25-30 Watts.

A while ago David Airlie has come up with a solution - vga_switcheroo which enabled the support for switchable graphics in Linux. While it was soon merged in the kernel, the technology remained rather unstable. The biggest problem was that once a discrete card was disabled with vga_switcheroo and the system suspended or hibernated, on wake up the discrete card was in semi-enabled state: the vga_switcheroo showed it as disabled, yet it still consumed about 60% of its normal consumption, bringing the system wattage up to 19-20 Watts. This led me to use the integrated card for pretty much everything, as enabling the discrete one in BIOS involved a lengthy process with a reboot, multiple passwords, etc.

Just yesterday I thought I would have a look at the progress with this issue. It appears that a solution to the suspend problem has been found, though it is far from elegant: it involves enabling both cards before suspending the system and disabling one of them back on wake up. After a day of testing I can say that it seems to be working without any quirks.

So, what needs to be done:

1. Make sure that the kernel used supports vga_switcheroo. Grep the kernel config for CONFIG_VGA_SWITCHEROO=y.
2. Enable switchable graphics in BIOS and check that vga_switcheroo is seeing both of the cards, run cat /sys/kernel/debug/vgaswitcheroo/switch.
3. Check that the drivers for both cards are installed (i.e. xserver-xorg-video-intel and xserver-xorg-video-radeon)
4. Do the following to select an active graphics card at boot time (according to this article). It should also be noted that quite the same effect can be reached by simply putting echo "OFF" | tee /sys/kernel/debug/vgaswitcheroo/switch into /etc/rc.local.
1. Create the file /etc/initramfs-tools/scripts/local-top/hybrid_boot_options with the following content:

   #
   # Standard initramfs preamble
   #
   prereqs()
   {
   :
   }
   
   case $1 in
   prereqs)
           prereqs
           exit 0
           ;;
   esac
   
   # source for log_*_msg() functions, see LP: #272301
   #. /scripts/functions
   
   #
   # Helper functions
   #
   message()
   {
           if [ -x /bin/plymouth ] && plymouth --ping; then
                   plymouth message --text="$@"
           elif [ -p /dev/.initramfs/usplash_outfifo ] && [ -x /sbin/usplash_write ]; then
                   usplash_write "TEXT-URGENT $@"
           else
                   echo "$@" >&2
           fi
           return 0
   }
   
   run_switcheroo()
   {
           local hybridopts
           hybridopts="$1"
   
           if [ -z "$hybridopts" ]; then
                   return 1
           fi
   
           local IFS=" ,"
           for x in $hybridopts; do
                   message "Switching hybrid graphics to $x"
                   echo $x | tee /sys/kernel/debug/vgaswitcheroo/switch
           done
           return 0
   }
   
   #
   # Begin real processing
   #
   
   # Do we have any kernel boot arguments?
   for opt in $(cat /proc/cmdline); do
           case $opt in
           hybridopts=*)
                   run_switcheroo "${opt#hybridopts=}"
                   ;;
           esac
   done
   
   exit 0
   

2. Make the file executable
3. Run sudo update-initramfs -c -k all to create an updated init image
4. Add hybridopts=OFF to kernel boot options in GRUB config. To make it permanent when using GRUB2, add it to /etc/default/grub and run sudo update-grub.
5. To make sure that the discrete card remains off after suspend (according to this article by Stefan Huber which also contains further useful advice and scripts) create the following file: /etc/pm/sleep.d/91vga_switch, make it executable and add write the following:

   #!/bin/sh
   case "$1" in
           hibernate|suspend)
                   echo "ON" > /sys/kernel/debug/vgaswitcheroo/switch
                   ;;
           thaw|resume)
                   echo "OFF" > /sys/kernel/debug/vgaswitcheroo/switch
                   ;;                                                                      
           *) exit $NA                                                                     
                   ;;
   esac
   

That's it!
A rather simple but effective solution. With these settings the system will start with the discrete card disabled (which however can be changed when needed by altering kernel boot options in GRUB) and will maintain this state after suspend or hibernation.
Furthermore, it is possible to switch to a discrete graphics card when necessary without rebooting the system. To do that run echo DDIS | sudo tee /sys/kernel/debug/vgaswitcheroo/switch and restart the X session. The next X session should be using the discrete card with the integrated one disabled.


UPD: It turns out that the init config mentioned in step 4 is not in fact working, at least in Kubuntu 12.04. It is thus easier to achieve the same effect by using the rc.local file as mentioned above.

UPD2: As it turns out, vga_switcheroo is compatible only with the free radeon driver, not the fglrx one. As the performance of the free driver in 3D is quite poor, it hardly makes any sense to switch to the discrete card to play games, etc. - the performance boost in 3D will most likely be negligible when compared to the integrated Intel card. Thus, the best approach would be to use the switchable graphics with the discrete card always disabled, yet use it when booting in Windows.

KDE 4.8 Window Switcher

I've just upgraded to KDE 4.8 on my Arch setup. The upgrade went smoothly, though was from the Arch [testing] repository, and so far it seems everything's stable and some of the bugs that were haunting me were eliminated.

One thing I noticed is that they changed the Task Switcher (Alt-Tab) behaviour slightly, now the Thumbnail option displays thumbnails which are so large that 4 or 5 fit in my screen at most. Now this is hardly a nice thing since once there's more than that, they don't form a second row, but rather go beyond the screen while not showing the user in any way that they do. So you end up seeing only 4 or 5 thumbnails in your Alt-Tab switcher while in fact you might have many more apps open.

I decided to change the thumbnail size to about what it used to be. I was very fortunate since KDE 4.8 introduced QML scripts for the Task Switcher. So basically, all you need to do to change the options of any switcher bundled with KDE is to tweak a .qml text file - as easy as that.

Now, to reduce the size of thumbnails in Thumbnails mode you have to open /usr/share/apps/kwin/tabbox/thumbnails.qml and change the following line to your liking:

property int thumbnailWidth: 200


Then change a setting in System Settings so that KDE could reread the configuration - and that's it!