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.
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.
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)
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:
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>.
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 : Broadcom Corporation BCM4313 802.11b/g/n Wireless LAN Controller [14e4:4727] (rev 01] ]05:00.0 Ethernet controller : 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.!