Inspirated

Recently, I needed to create some visualizations in a drawing area for one of my PyGTK apps. The PyGTK tutorial had an excellent writeup complete with a working example for immediate help. Unfortunately, my requirements were of a “grid” view on which other objects would be drawn. Naturally, I hoped for some variable on the GtkDrawingArea which I would set to true and have the grid lines drawn automatically. But since I couldn’t find any such magic setting in the API, I had to draw the lines manually.

Consequently, I could use either of the following approaches:

• Loop horizontally and vertically while draw_line()ing.
• Draw a 10×10 box as a tile and repeat it over the background.

The first approach would’ve worked faster but involved writing more code. The second was uglier — especially for larger images — but resulted in me having to add only a few lines to the example:

72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91

        xpm_data = ["10 10 2 1",
            " 	c #EEEEEE",
            ".	c #FFFFFF",
            "          ",
            " ........ ",
            " ........ ",
            " ........ ",
            " ........ ",
            " ........ ",
            " ........ ",
            " ........ ",
            " ........ ",
            "          "]
        tile_pixmap, tile_mask = gtk.gdk.pixmap_create_from_xpm_d(
            area.window, None, xpm_data)
        tile_gc = area.window.new_gc(fill = gtk.gdk.TILED,
            tile = tile_pixmap)
        width = int(self.hruler.get_range()[3])
        height = int(self.vruler.get_range()[3])
        area.window.draw_rectangle(tile_gc, True, 0, 0, width, height)

Turning this:

Into this:

Note that the 10×10 tiles’ borders match prettily with the markers on top and left rulers. There will definitely be some more efficient method for achieving this but for the time being tiling serves my needs perfectly.

Rarely do I feel the urge to jump on the buzzword bandwagon. This time, however, the product deserves the hype. Before you hear me any further, jump straightaway to the Nokia 900 website and stagger yourself into oblivion. Cliff notes:

• First Linux-based cellphone from Nokia — world’s largest manufacturer of mobile phones. The previous Linux tablets from the Finnish giants (e.g., N810) were nice but lacked the basic phone functionality.
• A plethora of insane mouth-watering features that are just too many to list here in their entirety.
• S**.

If you still aren’t convinced, let me be lazy and shamelessly copy some items from the linked page:

• ARM Cortex – A8 superscalar microprocessor core running at 600 MHz
• Up to 1 GB of application memory (256 MB RAM, 768 MB virtual memory)
• 3D graphics accelerator with OpenGL ES 2.0 support
• 32 GB internal storage
• 3.5G and WLAN connectivity
• Quadband GSM with GPRS and EDGE
• 5-megapixel digital camera
• Carl Zeiss optical lens
• Touch-sensitive screen
• Assisted-GPS receiver

Essentially, that’s iPhone+N810+N96+Neo FreeRunner for you. An year ago, I did have a feeling that Nokia was planning big things with Linux when it acquired Trolltech but I had absolutely no idea that the definition of “big” would be this exotic.

Can’t. Wait.

Recent X.org drivers for Intel chipsets have introduced a new acceleration method called UXA which is supposed to provide “simpler, faster” code. However, for whatever reason, this bleeding-edge feature actually results in a loss of performance and reliability for particular chipsets (e.g. 915 family) on most distributions (Fedora and Ubuntu to name the foremost). In order to work around these issues, two solutions can be used:

1. Enable Tiling in xorg.conf.

   Section "Device" Identifier "Videocard0" Driver "intel" Option "Tiling" "False" EndSection

   Section "Device" Identifier "Videocard0" Driver "intel" Option "Tiling" "False" EndSection

   This fix does help the low framerate issue encountered on most distros, but it introduces screen tearing on some installations and worse, can happen in occasional X crashes as well.

2. Use “greedy” MigrationHeuristic with EXA instead:

   Section "Device" Identifier "Videocard0" Driver "intel" Option "AccelMethod" "EXA" Option "MigrationHeuristic" "greedy" Option "NoDDC" EndSection

   Section "Device" Identifier "Videocard0" Driver "intel" Option "AccelMethod" "EXA" Option "MigrationHeuristic" "greedy" Option "NoDDC" EndSection

   While this completely bypasses the UXA acceleration, it seems to work well for most users.

For the time being, I’m sticking with the second workaround since I have no issues with using the older acceleration architecture until the new one achieves some decent stability.

Ladies and gentlemen, let’s bring our hands together for a clamorous round of applause. The greatest browser plugin since the invention of, well… browsers, has been unveiled. Welcome to Quake Live.

An year ago, anyone proposing the idea of running Quake III in a browser would have been sent to the local psych ward. Heck, even a week ago I would’ve been skeptical about practicality of any such development. But sometimes, it just feels wonderful to be proven wrong. This is one of those times and while I shoot railguns aimlessly in the other Firefox tab, I just can’t help staring at the screen in awe. In fact, I can even — for the time being — totally overlook any security concerns related to the plugin. If you own a decent browser, QL’s worth at least a try. I’m not a FPS fan either but this was just too good to be overlooked because of gaming preferences.

Going through the Planet Fedora feed, I spotted this excellent write-up which tries to explain Fedora-related patent questions such as “why the $*#@ won’t Red Hat give us MP3 playback support“. I would be straight-down lying if I said that the article offered nothing new to me. In fact, some answers, such as this one … :

Patent licenses are usually granted via payment of royalty based on the number of users. Since Fedora is free and open source software, the effective number of users is essentially unrestricted. Patent holders are generally unwilling to give a blanket patent license for unlimited use, and the royalty payments for these licenses would be too high to purchase them outright. Proprietary operating systems like Microsoft Windows include the cost of the patent license as part of the product being sold to the end users. Fedora is not sold commercially, so there is no way to recoup these substantial expenses. Even assuming funds are available to do so, licenses such as the GPL require a written patent grant (in regions where software patents are enforced) compatible with royalty free distribution and modification. Since meeting this requirement effectively nullifies the effect of a patent, patent holders are also generally unwilling to do this.

… clarified in my mind a few long-held confusions about Fedora’s reluctance regarding patent infringement. For the general user, RPM Fusion works around all that crap; but a read of the linked FAQ is recommended nevertheless for having an idea about the issues inherently involved with seemingly simple tasks such as playing DVDs.

Being a Unix geek has its own little benefits. For example, when a friend wants you to code a shell for his Operating Systems assignment, you can extort a lunch out of him for the services. Moreover, if you can somehow get him to convince his teacher for accepting submissions in Python, you can have s** with the code itself.

The bare-essentials shell was required to have the following:

• Support for internal commands such as cd or ls which would be implemented using system calls.
• Support for launching external programs with arguments provided to the shell — optionally putting them to background with an ampersand at the end of the arguments.

That is it. No fancy intput/output stream redirection, no jobs, no pipes. Just a simple launcher. A quick doze of reflective programming resulted in a class that checked the given commands against member functions (e.g., Shell.on_cd is queried for “cd path“) and called them to process the input. In case of unrecognized commands, the default handler is called which in turn uses the subprocess module and attempts to launch the command as an external program. Support for escaped or quoted arguments wasn’t required (the assignment recommended tokenizing strings at spaces), but the godsent module … :

import shlex
# ...
args = shlex.split(command)

… allowed me to support proper argument parsing with only half a line of code anyway. Similarly, connecting to the standard input/output of the child program wasn’t in the requirements, but the simple call … :

import subprocess
# ...
proc = subprocess.Popen(args,
	executable = args[0],
	stdin = sys.stdin,
	stdout = sys.stdout,
	stderr = sys.stderr)

… did the trick perfectly; allowing proper executions of commands such as “cat -“.

The complete code is downloadable here. Unfortunately, coding was the easy part. Getting the guy to pay for the extorted lunch wasn’t and as of this writing, I’m still deadlocked on that front.