The Kernel and I are one now

Inspired by this xkcd : http://xkcd.com/456/

Once upon a time there lived a Devoted Linux User

Bestowed upon him was the moniker /dev/luser

For long he put up with the tantrums of Ubuntu

And the mandatory biannual tearing of hairs too

Then one day he had a life altering epiphany

Or perhaps, I daresay, just a drink too many

He let out a violent scream that shook the Earth

“Curse be upon you, O Canonical, O Shuttleworth!”

Down the stairs, into the basement he did resign

Locked the door, complete with a “Do not disturb” sign

Hours turned to days, days into several weeks

Yet from beyond the door came not a single squeak

He left the basement neither to wine nor to dine

Neither to unload his bowels nor to release his brine

His loyal friends, worried for his health and sanity

Decide to break the door down with utmost urgency

As the dust settles, a ghastly scene meets their eyes

For the room is full of spiders, cobwebs and flies

In the far corner, sitting on a chair, back turned to them

/dev/luser typing feverishly, all ten fingers in tandem

Screen an undecipherable wall of scrolling green text

Which /dev/luser groks keenly without breaking a sweat

Bravest friend takes a cautious step forward. A big folly!

His first step lands upon something circular and shiny

A primal fear grips him as he bellows loudly, “NOOO!”

For embossed on the CD were the letters “GENTOO”

Time slows down, everything gets frozen in space

Except /dev/luser who persists typing at unabated pace

He turns back, his eyes bloodshot, his face lifeless

His voice, inhuman and robotic, pierces bone and flesh

“Forget the why, forget the when, forget the how”

“All I remember is that kernel and I are one now”

Advertisements

Haskell: Using already computed part of list to compute further list

I faced a rather difficult (for a functional programming noob anyway) problem while coding in Haskell recently. Say I have a list which needs updating. Flex some FP muscles and you realise that if you have a function to update a single element, like:

updElem :: a -> a
updElem cur = --definition goes here

then the function to update the list of elements is simply defined as:

updList :: [a] -> [a]
updList = map updElem

Pretty simple. A basic observation here is that if we denote original list by Lo and updated list by Lu, then Lu[n] depends on Lo[n]. Now here’s the problem I faced. In my case, Lu[n] depended not only on Lo[n], but also Lu[n-1]. Not a big issue, I say, and proceed to redefine my updElem as

updElem :: a -> a -> a
updElem cur prev = --definition

And what about updList? It gets redefined thusly

updList :: [a] -> [a]
updList (prev:cur:[]) = [updElem cur prev]
updList (prev:cur:rem) = updElem cur prev : updList (cur:rem)

I gave myself 3 gentle pats on the back for coming up with this function and proceeded to test it out. It failed. Big time. Compiler having failed me, I resorted to my favorite debugger – pen and paper! I walked through each recursive call of updList and it wasn’t hard to see why it was bombing out – the pattern match is matching against Lo the whole time and I need my prev to come from Lu, not Lo.

Realizing the problem was but a small part of the solution. Fixing it is where the headache lay. Lu, while being created, needed reference to it’s own previous element to grow further. I guess the main reason I got stuck here was because I got thinking that I needed to access the stack of updList somehow since that is where the state of Lu will be stored while being created.

Several fruitless hours later, I gave up and sought help of the expert minds over at Stack Overflow. When I saw the solution posted there, I banged my head on the nearest wall for each pat I had awarded myself earlier, plus one. Picking up my jaw up from the floor, I proceeded to implement the simplistically brilliant solution which had totally eluded me so far. Here I present to you the final and correct version of updList in all it’s idiomatic glory:

updList :: [a] -> [a]
updList xs = zipWith updElem xs shifted
where shifted = 0 : updList xs

Where comes the magic number 0 from, you ask? Notice how in this entire post I have been silent about what element of the updated list Lu[0] depends on? Well it really depends on your problem. In my case, assuming it depends on 0 is works fine enough. Otherwise, if [a] is a list of your custom data types, perhaps you can introduce a null type constructor to replace the zero.

Installing and configuring dwm under Ubuntu

dwm is an ultra-minimal tiling WM written in C. Ubuntu offers a binary package, but it’s kind of pointless since the only way to configure dwm is by editing its source code and recompiling. Instead we will grab the latest source from the project website directly.

First install the dependencies needed for compiling dwm along with the package suckless-tools which contains a bunch of utilities for use with dwm.

$ sudo apt-get install build-essential libx11-dev libxinerama-dev sharutils suckless-tools

Now grab the dwm source code from the project website and extract it locally.

$ cd /usr/local/src
$ sudo wget http://dl.suckless.org/dwm/dwm-6.0.tar.gz
$ sudo tar xvzf dwm-6.0.tar.gz
$ chown -R `id -u`:`id -g` dwm-6.0
$ cd dwm-6.0

Before proceeding further with compilation, have a look at the README file. It tells you to modify the config.mk file to match your system. However the defaults work just fine on a normal Ubuntu system. So, go ahead and compile!

$ sudo make clean install

At this point, dwm is installed as /usr/local/bin/dwm, but you still need to add an entry for dwm so that it shows as an option in your login screen. For this we will install dwm from the repositories which, as I said before, is not of much use. But, it will also install a file /usr/share/xsessions/dwm.desktop which is what we need. So we will back up this file, remove dwm, and restore the backup file.

$ sudo apt-get install dwm
$ sudo cp /usr/share/xsessions/dwm.desktop{,.bak}
$ sudo apt-get purge dwm
$ sudo mv /usr/share/xsessions/dwm.desktop{.bak,}

Now we are all set to log in to our dwm setup! So log out and log back in to dwm session to be greeted with a shiny new desktop that looks something like this:

Default dwm under Ubuntu 11.10

Default dwm desktop

There you go, unabashed simplicity for you, right there. No oversized icons to waste screen space, no system trays, taskbars, panels to distract you and no apparent way to launch applications. What you do have is an narrow bar running along the top edge of the screen displaying some numbers and symbols with “dwm-6.0” written in the right corner. This bar is known as….we’ll just call it bar for now. Try pressing Alt+B to toggle the bar visibility. The numbers you see are virtual desktops (called tags in dwm) – dwm provides 9 of them by default. Try Alt+[Num] to switch between tags. The weird “[]=” symbol you see next to the tags is your current tiling layout. dwm offers three layouts by default – tile ([]=), monocle ([M]) and float (>). The “dwm-6.0” string you see in the far left can actually be changed to show useful information like current date, time, network status, battery status etc.

This is a good time to get yourself acquainted with dwm’s keyboard shortcuts. Remember, keyboard shortcuts are of prime importance in tiling WMs and you should know them as your life depended on it. You can configure them to your liking, but it helps to get acquainted with a few default ones:

Alt+Shift+Enter
    Launch xterm
Alt+Shift+C
    Kill a client (a window, if you must insist)
Alt+t
    Switch to tile layout
Alt+m
    Switch to monocle layout
Alt+f
    Switch to floating layout
Alt+b
    Show/hide bar
Alt+p
    Launch dmenu
Alt+[num]
    Switch to tag [num]
Alt+Shift+Q
    Quit dwm

dmenu is an application launcher from the author of dwm following the same minimalist philosophy as dwm. It is a part of the suckless-tools package we installed earlier.

Now we will try out the tiling modes of dwm. First close any open clients (Alt+Shift+C) and switch to tile mode (Alt+t). Now open up xterm using dmenu. Press Alt+p and you should see the bar get replaced by something like this

dmenu under Ubuntu 11.10

dmenu

Start typing the name of the app you wish to launch, and once dmenu has narrowed down the search, select it using arrow keys and press Enter. Launch xterm this way. It will occupy the entire screen. (Number 1 has been added by me)

single client open in dwm

Single xterm client.

Open another xterm client (using either dmenu or Alt+Shift+Enter). You will find the previously open xterm automatically resize and move to make space for this newly opened xterm.

two clients open in dwm

Two xterm clients.

Here, area 1 is called the master area and area 2 is called the stack area. The master area can hold a single client while the stack area holds all the remaining ones. Any newly opened clients always occupy the master area and the existing clients gets pushed into the stacking area. Open up a couple more xterms to see how it works You can switch focus between clients using Alt+j and Alt+k. Focused clients are denoted by a blue border while the rest have gray border. You can move a focused client from stacking area to master area using Alt+Enter. Play around with these shortcuts till you get the hang of how exactly the tiling works. Finally, you can change the ratio between master and stacking areas using Alt+h and Alt+l.

multiple clients in dwm

1 Client in master, 4 in stack with highly skewed area ratio

Now switch over to monocle layout (Alt+m) to have the focused client occupy the entire screen. Note how the “[]=” sign in the bar changes when you switch layout. This layout is equivalent to maximized windows in floating WMs. Note that Alt+j, Alt+k and Alt+Enter shortcuts will work in this layout too.

The final layout is the floating layout which is equivalent to your conventional floating WMs. Move the clients around using Alt+LMB+Drag and resize them using Alt+RMB+Drag. Note that you can switch individual clients into floating mode without affecting the layout of the rest by using Alt+Shift+Space. Floating clients always stay above the tiled ones.

Tags in dwm are a more powerful version of virtual desktops in KDE/Gnome etc. A client can have more than one tag associated with it and you can view all clients from any number of tags simultaneously. Use Alt+[num] to view all clients having tag [num], Alt+Ctrl+[num] to view clients having tag [num] in additon to currently visible clients, Alt+Shift+[num] to associate focused client to tag [num] and Alt+Ctrl+Shift+[num] to associate in addition to current tag associations.

There is still a lot more tweaking you can do before you using dwm as a full-fledged replacement for Unity. This includes configuring a system tray so you can use NetworkManager applet under dwm, displaying some meaningful information in the bar instead of the the curt “dwm-6.0”, configuring dwm by editing it’s source code (Have a look at /usr/local/src/dwm-6.0/config.h file to get started) and making your gnome themes and settings carry over to your dwm session (if you open any gnome apps at this point, they will have an ugly theme and unreadable fonts).

PS: Use “nautilus –no-desktop” in dmenu to launch nautilus, or else it will mess up your dwm session. A default rule in dwm specifies firefox should open in tag 9 by default. Happy tiling!

A quick way to determine endianness

One way is to write a C program that goes:

#include <stdio.h>
int main()
{
   unsigned int i = 1;
   char *c = (char*)&i;
   if (*c)
       printf("Little endian");
   else
       printf("Big endian");
   return 0;
}

Another way is to run a one-liner in your terminal. It goes:

[ "$(echo hi | iconv -t utf-16 | od -N2 -An -t x1 | tr -d ' ')" = "fffe" ] && echo "Little Endian" || echo "Big Endian"

It takes advantage of the magic number 0xFEFF that UTF-16 encoding adds before any text. Look here for more info.

DWM – Or how I learned to stop floating and love the keyboard

It began four years ago when I switched from XP to Ubuntu. It happened again two years ago when I migrated from Ubuntu to Arch. It repeated a year ago when I ditched KDE in favor of Openbox. Now, after twelve whole months of relative calm in the 1049088px digital utopia I had established using Openbox, XFCE4 Panel, Conky and a dozen cronjobs, a newer, more esoteric succubus is here to lure me away from my virtual Shangri-La. In just two weeks, it has already made me succumb to it enigmatic charms. I feel nauseated when faced with conventional floating window managers now, and make a mental note to sacrifice a baby in my dreams for each pixel I see wasted on petty trivialities like taskbars, titlebars, system trays, minimize buttons, maximize buttons, close buttons and other pointless doodads.

What is a tiling window manager (WM) anyway?

Let’s start with what a window manager is first. It is, as the name implies, a piece of software that manages all your open windows, nothing less nothing more. Whenever you perform an action on a particular window, like move, resize, minimize, maximize or close, you are interacting with a WM. Every OS running a GUI has a WM running too. Of course, presenting an end-user with just a bunch of windows to move around isn’t considered nice manners. Hence WMs are often relegated to being just another process in the system started alongside a myriad others to provide a nice and coherent and, not to mention, bloated experience to the user.

It shouldn’t come as a surprise that there is variety in WMs too. The ones that most people are used to, courtesy to them being default in Windows, GNOME, KDE and Mac alike, are called floating WMs. The title window “manager” is outright misleading here, since the actual window management is left to you, the user. It is you who has to manually move the window to desired position and resize it to the right size. The WM only remembers the position of the window and controls placement and ordering of newly opened windows. This works fine so long as you work solely with maximised windows. But try viewing more than one window side by side and the inherent shortcoming of the floating approach shines through.

As if moving and resizing to get the windows to fit without overlapping critical parts of each other wasn’t enough, you are forced to do it again for a newly opened window. And again for each new window you open! To add smelly icing to the crumbling cake, try closing a window now and scratch your sorry ass trying to fathom what good that gaping hole, about the same size as the one in your underwear, left on your desktop offering the world a peek at the aubergine panties of Jenna Jameson wallpaper, is for.

Enter Tiling WMs.

These WMs take a totally different approach to managing windows, in the sense that all windows belong to the same 2D plane. Basically, they abandon the faux-3D illusion of floating WMs (in which windows can overlap each other) and respect the fact that 2D surfaces (your monitor, in case you happen to be thinking about babies overrun by bulldozers) aren’t good for representing 3D.So, in tiling WMs, windows never overlap each other. Think about it. Most of the frustration of using a floating WM arises from the fact that non-maximised windows can – and will – overlap each other, forcing you to go through the resize-move-open-resize-move-close-resize-move-rinse-repeat rigmarole. These problem just doesn’t exist in tiling WMs.

This simpler mode of representing non-overlapping windows in one plane has an added benefit that each window can now be thought of as simple rectangular subsection of a larger rectangle. But what about those gaping underwear-sized wallpaper-exposing holes that are the bane of floating WMs? In tiling WMs, the holes are themselves guaranteed to be rectangles.And what do you put in a rectangle (besides a baby emerging from a bar soap manufacturing line)? Hint: it starts with a W, ends with a W and is not a wheelbarrow.

Since all windows and holes are rectangles, what is the point of having any holes at all? Why not let a window take the maximum dimensions it can take without overlapping other open windows? This is exactly what tiling WMs do, and is probably their biggest advantage too. They live up to their title of window “manager” in a way more glorious than floating WMs fail to. Not having to worry about rearranging windows each time a new one opens is a huge productivity booster once you have more than a couple open. You may feel a lack of control, what with your currently open windows suddenly moving and shrinking to make way for new one, or expanding to fill a void left by a closed window, at least initially. But trust the WM, it knows it’s job better than you do. You will be astonished to discover how much more effective this can be once you get over the getting-used-to phase.

Did I mention that all tiling WMs can be controlled entirely though the keyboard? Yup, they manage to totally circumvent the need for what is perhaps the most recognizable piece of desktop computing equipment ever – the ubiquitous-as-a-motherfuck – mouse! This ideology of ditching the pointy rodent in favour of its CTP-advancing cousin gels well with other stellar Unix applications like vim, tmux, the CLI itself and the excellent vimperator (or its newer cousin pentadactyl) add-on for Firefox.

DWM on Arch Linux

Which tiling WM you choose is purely a matter of personal preference. I chose dwm because it did the most of what I needed and none of what I didn’t. Here’s the last statement again with a bit more loquacity:

It’s Small

  • Weighing in at just under 41kb (compiled binary size), I have seen mere crash dumps of heavyweight programs with size greater than this thing

It’s a joy to configure

  • This depends on how well you know C, since the only way to modify any settings is by editing its source code and recompiling. While it may sound like a chore to recompile each time you make one small change, it also offers the freedom to customise in ways that a text-based config file just can’t

It’s fast and lightweight

  • “# init 5” will never be a reason to get a much-needed toilet break anymore!

Arch Linux offers a binary package for dwm, but it’s kind of pointless since you need the source code for configuring it. There’s also a couple of PKGBUILDs floating around in the AUR. But being the extraordinary piece of software that dwm is, it is only fitting to run it an extraordinary manner. So, I just have a .dwm directory in my home that contains the dwm source code and makefiles, along with my custom scripts and conky configs to run with dwm.

Configuring dwm is done by editing the config.h file (and, if you are feeling particularly masochistic, the dwm.c file). The file is commented well enough to make editing a trivial matter for people even remotely familiar with C. Note that you need to recompile and restart dwm in order for the changes to take effect. To make the process a bit less painful, first configure dwm to restart instead of exit on quit function is called. Start dwm from within a while loop inside your ~/.xinitrc or whatever script you use to start dwm:

while true; do
    dwm 1 &gt; ~/dwmlog 2 &gt;&amp; 1 || exit
done

Now make a shell alias for compiling dwm:

alias cdwm="pushd ~/.dwm; sudo make clean install; popd"

Replace ~/.dwm with whatever directory your source files are located in.
Now, just run cdwm followed by Mod+Shift+Q (or your custom keybind for quit function) to apply the changes without losing currently open windows.

In case you find that you need some functionality that dwm doesn’t provide, try searching for a patch before messing around with the dwm.c file. Good places to look for patches are:

Do browse through the links at the bottom of the dwm site for more dwm foo.

That’s about it! Happy tiling and baby-squashing!

DSDT editing: Put an end to your ACPI woes

Background:

Ever since I installed Openbox, one of the major frustrations was the fact that it started up with display brightness set at 100%. It wasn’t an issue in either KDE or Windows whose respective power management profiles did the job for me. Since I don’t use any sort of power management program in Openbox, manually setting the brightness to a saner level using brightness keys each time was a pain. For a while, I resorted to an ugly “hack” of sorts : a script that wrote brightness value directly to relevant file in /sys (in my case it is /sys/class/backlight/acpi_video0/brightness). Here is the script:

#! /bin/bash
# The value 15 is obtained from
#`cat /sys/class/backlight/acpi_video0/max_brightness`
function usage()
{
  echo -e "Usage : $0 <value>\n"
  echo -e "<value> is an integer between 1 and 15\n"
}
case $1 in
[1-9]|1[0-5])
  echo $1 > /sys/class/backight/acpi_video0/brightness;
*)
  usage;
esac

I call it an ugly hack because

  1. It requires root access to change brightness
  2. It needs to be set up to execute on start of each DE/WM separately.

I needed a more “universal” and elegant solution than having supuser access just to change brightness.

The dmesg output on my machine contained an error that caught my attention:

[Firmware Bug]: ACPI: No _BQC method, cannot determine initial brightness

Poring through the ACPI Specs (which contains a wealth of information for those willing to sift through all the 700+ pages), I found out that my salvation lay in DSDT editing.

For the unitiated:

ACPI is to laptop users what oxygen is to mankind. BIOS, by itself, provides very basic support for all the hardware typically found inside a laptop. It cannot, for example, handle what happens on opening/closing the laptop lid, plugging in/out the the AC adapter, pressing the brightness keys etc. Sleep and hibernate are two essential features for any laptop user which are too complex for BIOS to handle. All these laptop-specific tasks are instead handled by ACPI. The biggest advantage of ACPI is that it is OS-agnostic. So, ACPI features that work flawlessly on Windows can be almost always expected to work on Linux (the almost part will be explained in a moment).

DSDT is a table that describes the ACPI properties and functions of all your hardware. If certain ACPI feature is missing or functioning improperly on your laptop, you can safely put the blame on a badly coded DSDT. DSDT is written in a language known as ASL (ACPI Source Language) that looks at lot like C. Just like C, it needs to compiled before it can be used by the system. This is where the problem creeps in. ASL compilers are provided by Microsoft and Intel. Like all things Microsoft, their compiler is far too lenient when it comes to ASL syntax compared to Intel’s. Hence, DSDTs compiled using MS compiler are generally buggier and more problematic than Intel-compiled ones. Windows includes all sorts of hacks to mask the ineffectiveness of the MS compiler while Linux typically suffers in some way or the other (laptop not sleeping/hibernating, fan spinning constantly, brightness keys not working etc.).

Lament not, you can extract the DSDT of your system, edit it to fix the errors, and replace the original DSDT with the fixed one to resolve most issues.

Working with the DSDT:

Grab the latest copy of the Intel ASL Compiler from your distro repositories or the source code from here.

Extract the DSDT of your system:

$ sudo cat /sys/firmware/acpi/tables/DSDT > dsdt.aml

Decompile the extracted DSDT:

$ iasl -d dsdt.aml

This will generate a dsdt.dsl file that you can open in any text editor and start editing. But it’s a better idea to recompile the file to see if it produces any errors

iasl -tc dsdt.dsl

On my laptop, it produces following output:

$ iasl -tc dsdt.dsl

Intel ACPI Component ArchitectureASL Optimizing Compiler version 20110112-64 [Jan 20 2011]Copyright (c) 2000 - 2011 Intel Corporationdsdt.dsl 4119: 0x00000000, // LengthError 4122 - ^ Invalid combination of Length and Min/Max fixed flags

dsdt.dsl 4133: 0x00000000, // Length

Error 4122 - ^ Invalid combination of Length and Min/Max fixed flags

dsdt.dsl 8951: Name (_T_1, Zero)

Remark 5111 - Use of compiler reserved name ^ (_T_1)

dsdt.dsl 8952: Name (_T_0, Zero)

Remark 5111 - Use of compiler reserved name ^ (_T_0)

dsdt.dsl 9009: Name (_T_1, Zero)

Remark 5111 - Use of compiler reserved name ^ (_T_1)

dsdt.dsl 9010: Name (_T_0, Zero)

Remark 5111 - Use of compiler reserved name ^ (_T_0)

dsdt.dsl 9091: Name (_PLD, Buffer (0x10)

Error 4080 - Invalid object type for reserved name ^ (found BUFFER, requires Package)

dsdt.dsl 9153: Name (_T_1, Zero)

Remark 5111 - Use of compiler reserved name ^ (_T_1)

dsdt.dsl 9154: Name (_T_0, Zero)

Remark 5111 - Use of compiler reserved name ^ (_T_0)

dsdt.dsl 9211: Name (_T_1, Zero)

Remark 5111 - Use of compiler reserved name ^ (_T_1)

dsdt.dsl 9212: Name (_T_0, Zero)

Remark 5111 - Use of compiler reserved name ^ (_T_0)

dsdt.dsl 9288: Name (_PLD, Buffer (0x10)

Error 4080 - Invalid object type for reserved name ^ (found BUFFER, requires Package)

dsdt.dsl 9305: Name (_PLD, Buffer (0x10)

Error 4080 - Invalid object type for reserved name ^ (found BUFFER, requires Package)

dsdt.dsl 10489: Name (_T_2, Zero)

Remark 5111 - ^ Use of compiler reserved name (_T_2)

dsdt.dsl 10490: Name (_T_1, Zero)

Remark 5111 - ^ Use of compiler reserved name (_T_1)

dsdt.dsl 10491: Name (_T_0, Zero)

Remark 5111 - ^ Use of compiler reserved name (_T_0)

ASL Input: dsdt.dsl - 12135 lines, 370000 bytes, 4042 keywords

Compilation complete. 5 Errors, 0 Warnings, 11 Remarks, 10 Optimizations

5 errors and 11 remarks. How you go about resolving these errors if a matter of personal preference. You can search the internet for the error number, which helps most of the time. Or you can actually try learning ASL from the ACPI specs and then get down to the debugging business, like real men do.

Here’s how I fixed my DSDT:

Error 4122: http://www.insanelymac.com/forum/lofiversion/index.php/t189272-100.html

Remark 5111: Replace all instances of _T_# within scope (i.e. within a pair of curly braces) by T_#

Error 4080: Unsolved, but not critical.Apparently, the kernel takes the remedial measure when it encounters this error http://lists.acpica.org/pipermail/devel/2010-July/000164.html

Once the DSDT was clean, it was time to get back to the original problem. As the dmesg output clearly stated, the method _BQC had not been defined in my DSDT at all. Fortunately, it was a simplistic method that merely returned one of the values specified by the _BCL method. I defined it in the Device (LCD) section after the _BCL method:

Method (_BQC, 0, NotSerialized)
{
    Return (0x1E)
}

This corresponded to the brightness level 5 of the “ugly hack” described above. Once finished, it was time to make my laptop use the fixed DSDT instead of the old one. The general steps to do so are explained here. Arch Linux users can follow the ABSmethod to recompile the kernel instead. Note that recompiling the kernel is the only way to do it in Arch, and it can take a good 30-45 mins of fast-scrolling gibberish on the terminal on a decent-spec PC.

Once the “fixed” kernel was compiled and bootable, I had the simplistic pleasure of staring into the LCD screen that didn’t blind me each time it turned on,  and geek’s satisfaction of running a clean DSDT … atleast till the next kernel update!

Arch Linux and Me

I have been using this wonderful distro on my laptop for the past 3 months. Now I have reached a level of comfort with it that makes the idea of switching to or even trying out another distro seem outrageous, blasphemous, traitorous. Yep, I will consider myself a traitor if I ever abandon Arch in favor of another distro. The point of no return has been passed. In this post, I will try to put out all the experiences I have had with Arch Linux ever since I decided to install it to the present day.

The Beginning…:

Want something to drool over.? How about this:

Intel Core i5 460m @ 2.53 Ghz

4GB DDR3 RAM @ 1066Mhz

ATI Radeon Mobility HD5470

Take the above three lines, add a few more phrases, like 320GB HDD, 14″ WXGA Display etc. to spice things up, wave your text-to-hardware conversion wand over the mix and Behold.! the technological marvel you now have in front of you is what I call my laptop and what Dell calls Inspiron 14R N4010. On shipping, it came pre-installed with yours truly – one and only Windows 7. But this was to change soon. The star child of MS was soon to meet it’s humbler, less pretentious sibling. I could have taken the coward’s path and stuck with graphical distros like Ubuntu or Mint or Opensuse.

* (Mind you, back in my desktop days, I had been an avid Ubuntu user when, one fine day, my stone age relic of a desktop succumbed to XP’s “Luna“tic charms and refused to get “turned on” by Ubuntu’s lustful “human” touch. Since my CD-ROM had found a place in silicon heaven a few years (or was it centuries.?) ago and the concept of booting from USB was too modern for my desktop’s antiquated tastes, I was left at the sole mercy of XP’s fickle whims for a whole year.) *

But then it dawned on me, I am a die-hard geek doing a course in Information Technology. Should I really care about things like ease of use, simplicity of installation, fancy point-n-click wizards for mundane tasks.?. No, I needed something that exposed to me to all it’s inner nitty-gritty of working, something that, instead of trying to hide it’s bloated, slow, and clunky code under the garb of a fancy-looking but equally bloated, slow, and clunky GUI, stayed away from the bloat in the first place, something that is put together so simply and efficiently that it leaves you in awe in each time you use it.

That something is Arch Linux.

What’s Arch.?

Four words perfectly sum up Arch Linux : Keep It Simple, Stupid.! A fresh install of Arch is nothing more than a kernel, bootloader, basic utilities we expect on every Linux system like cp, ping, grep etc and a few Arch-specific tools. It provides no GUI, no audio support, no pre-configured network settings, no users except root, no automount for USB drives, CD/DVDs etc by default. Everything is left for the end user to install and configure. What it does provide are two excellent tools to get the job done, namely pacman and Arch Build System (or ABS)

Pacman:

A package manager can make or break a Linux distro. In Arch’s case, pacman more than makes up this distro and a few neighbouring ones too. The three main switches that govern most of it’s usage are -S (or –sync) which deals with packages available in repositories, -Q (or –query which deals with locally installed packages) and -R (or –remove) which deals with removing packages. Examples follow:

To install package foo:

pacman -S foo

To cleanly remove a package alongwith with its unneeded dependencies and configuration files:

pacman -Rsn foo

To get info on any installed package:

pacman -Qi foo

And (best for the last.!) the ‘magic’ command:

pacman -Syu

This command is what makes Arch a rolling release distro. You run it and your entire system is brought up-to-date with all installed packages upgraded to latest available versions automatically. In distros like Ubuntu, if upstream (the actual developer of the program) releases a newer version of a software than what is available in repos, you either have to wait six months for new Ubuntu version to include the this package or compile it from source. Not in Arch. Here, the developers release the newer version to the repos within 2-3 days of upstream release AFTER testing it for stability (a common criticism against rolling release model is that packages released into the repos are often untested, resulting in an unstable system and unexpected bugs, which is just plain FUD).

Another area where pacman excels is speed.Here’s why:

$ time pacman -Rsn libreoffice
..<snip>..
Total Removed Size: 321.83 MB
Do you want to remove these packages? [Y/n] y
..<snip>..
real 0m4.683s                 <-- dafuq?!
user 0m0.637s
sys 0m0.320s

That’s 320 mb worth of software uninstalled in less than 5 secs. Let’s see how fast it installs:

$ time pacman -S libreoffice
..<snip>..
Total Installed Size: 321.83 MB
Proceed with installation? [Y/n] y
..<snip>..
real 0m18.833s                <--dafuq?!
user 0m16.646s
sys 0m0.557s

Less than 20 secs. A typical Windows install of libreoffice can take upto 5 minutes. This is a package manager with it’s a** on fire.!

Arch Build System (ABS):

In their hunt for software, most distro users are afraid to venture beyond the reaches of their respective distro’s repos and with a good reason.Installing software from source code typically involves downloading the source tarball from the developer’s site, untarring it, referring the DEPS (or equivalent) file to know what it depends on, hunting for those missing dependencies, referring the README (or equivalent) for instructions on compiling, actually compiling the source code and finally installing the generated binary file. Uninstalling is another headache that forces you to remove every single file owned by the package.

Enter ABS. With it, you can create pacman binaries from any source code package. The binary can then installed to the system with pacman -U /path/to/binary. The keyword here is PKGBUILD. It’s a simple text file that contains details like the URL where the source code is located, the dependencies of the package, the package version etc. and functions like build() which details the exact steps needed to compile the source code. Finding the PKGBUILD for a package is not very difficult courtesy the Arch User Repository (AUR). The AUR is a huge collection of PKGBUILDs that are uploaded and maintained by the Arch users. If a software you are looking for is not available in the official repos, you can almost always be sure to find a PKGBUILD for it in the AUR.

The functionality of ABS extends beyond providing packages not included in repos. The Arch developers offer a “PKGBUILD tree” of  sorts for all packages available in repos. This gives you a choice between installing repo packages using pacman -S foo or building it from source using ABS (particularly useful if you want to compile a package in some other way than what the the package maintainer intended (Pssst….custom kernel.!)). To get this “PKGBUILD tree”  on your system, do a pacman -S abs followed by abs. This will download PKGBUILDs for all repo packages and store them neatly under /var/abs. Installing from a PKGBUILD is as simple as copying the PKGBUILD to a temporary directory (/var/abs/local is a sensible choice), cd‘ing there and running makepkg -s. The generated pacman binary can be installed with pacman -U <binary>.

Networking Woes:

So the famous saying goes, “A Linux system that works flawlessly on first try is not worth the effort.” The outright fabrication popular adage definitely held true in my case. Trouble began before the installation could. You see, I had downloaded the netinstall iso which includes only the kernel and installation scripts. During installation, it connects to the servers and downloads the latest and greatest versions of all specified packages (as opposed to bundling the entire kitchensink in the install CD/DVD itself) to give you the newest, freshest install possible. IF you can manage to get a working conection before beginning the installation, that is. For me, this was easier said than done: the installer could not find any network interfaces to connect to the internet with. Logging in from another console, I did an ifconfig -a which confirmed my fear: only the loopback interface had been detected. Feeling a bit dejected, I let lspci -n give me the following insight on my NICs:

.....
04:00.0 Network controller [0280]: Broadcom Corporation BCM4313 802.11b/g/n Wireless LAN Controller [14e4:4727] (rev 01]
]05:00.0 Ethernet controller [0200]: Atheros Communications AR8152 v1.1 Fast Ethernet [1969:2060] (rev c1)
.....

A hour of Googling and IRCing later, I knew the cause of my networking woes. Support for my Ethernet NIC had been added in kernel 2.6.34 while the kernel on the install CD was 2.6.33. As for my Wireless NIC, it needed a binary blob from Broadcom to perform it’s duties. Once the cause was known, solution was another 572MB plus a few more away. The newer kernel on the Archboot CD detected my ethernet and the AUR package enabled wireless connectivity. What exactly had I accomplished.? I could now, by a mere click of an inconspicious button, set off a chain of TCP packets to travel at blazing speeds through the humungous complexity of fibre-optic pathways criss-crossing the length and breadth of the planet to reach with unerring precision their intended destination, a UNIX server clocking billions of cycles per seconds on it’s 16-core Intel Xeon processor, which scours the deep recesses of it’s underlying filesystem structure to retrieve a very specific document and sends it back over the same labyrinthine pathways to finally reach my browser window, all because I wanted to read my favourite XKCD comic. Or, for the brewity-conscious, I was now a part of the Internet.

Multimedia Keys in Openbox:

Here I will describe how I got my multimedia keys working in Openbox. The complete listing of multimedia keys and their keycodes is:

$ xev | grep -A2 --line-buffered '^KeyRelease' | sed -n '/keycode /s/^.*keycode \([0-9]*\).* (.*, \(.*\)).*$/\1 \2/p'
246 XF86WLAN
244 XF86Battery
232 XF86MonBrightnessDown
233 XF86MonBrightnessUp
121 XF86AudioMute
122 XF86AudioLowerVolume
123 XF86AudioRaiseVolume
173 XF86AudioPrev
172 XF86AudioPlay
171 XF86AudioNext
199 XF86TouchpadToggle

The intended function of each key is pretty evident from it’s name. The keys that worked without any extra configuration were XF86WLAN and XF86MonBrightness[Down|Up]. To get the rest working, I added the following code to the keyboard section of rc.xml:

<keybind key="XF86AudioMute">
<action name="Execute">
<command>amixer -q set Master toggle</command>
</action>
</keybind>
<keybind key="XF86AudioLowerVolume">
<action name="Execute">
<command>amixer -q set Master playback 10%- unmute</command>
</action>
</keybind>
<keybind key="XF86AudioRaiseVolume">
<action name="Execute">
<command>amixer -q set Master playback 10%+ unmute</command>
</action>
</keybind>
<keybind key="XF86TouchpadToggle">
<action name="Execute">
<command>~/bin/tptoggle</command>
</action>
<!--more-->
</keybind>
<keybind key="XF86AudioPrev">
<action name="Execute">
<command>/usr/bin/exaile -p</command>
</action>
</keybind>
<keybind key="XF86AudioNext">
<action name="Execute">
<command>/usr/bin/exaile -n</command>
</action>
</keybind>
<keybind key="XF86AudioPlay">
<action name="Execute">
<command>/usr/bin/exaile -t</command>
</action>
</keybind>

~/bin/tptoggle is an executable file containing the one-liner:

/usr/bin/synclient TouchpadOff=`expr $(synclient -l | grep TouchpadOff | grep -o .$) = 0`

Getting the XF86Audio* keys to work with Exaile was easy since it supports most of it’s GUI functions from CLI too. I have no idea whether other music players can do the same thing. I haven’t yet found a way to get the XF86Battery key to display anything meaningful.

…And The End.

I am currently using KDE 4.6 (Openbox is fun, but KWin’s effects reign supreme.! :P). Need to use Catalyst drivers since open source ATI drivers don’t support 3D for my GPU…yet. With kernel 2.6.37, brcm80211 driver has been integrated as a kernel module, allowing me to get rid of the Broadcom’s STA driver for my wireless. Sleep doesn’t work, probably because of catalyst drivers acting up. That about sums it up. The distro purrs along flawlessly, needing only a bit of attention when pacman -Syu is performed. This one’s here to stay.!