The FOSS.in experience

As some of you know (possibly because I have been raving about it so much) this year's FOSS.in was held at Bangalore from 1st to 5th of December. I attended the conference on 2nd and 3rd of December. My plan was to attend all the 5 days, but some inevitabilities at work made it impossible.

The trip started on a very good note as I boarded the Kingfisher flight from Lohagaon on 2nd of December. For the entire duration of the flight, I was kept entertained by the very nice show on the smallish personal TV : Kingfisher calendar girls. The flight was half an hour late which messed up my already tight schedule. I took a shuttle to Jayanagar from the airport (which takes approximately one and a half hour), went to the hotel room and was out within 90 seconds and reached Nimhans Convention Centre just in time to catch Rahul Sundaram's talk on the Fedora buildsystem. Before lunch, I also managed to catch some bits of the talk by James Morris on seLinux sandboxing. Kedar had a fun time mocking my formal attire. (In my defence, I didn't know people come casually to the conference. I thought everyone will be in tip-top formals)

After a surprisingly great lunch, I went to attend Kedar's talk on Fedora-ARM (the reason I was at the conference). The attendees included many Fedora guys, some interested students and some others that I cannot place. Kedar talked on the status of Fedora-ARM, how to contribute, ARM or secondary arch specific issues and other stuff. Read here for more info. Rahul inaugurated the dist-f13 tag with his gnote build. After that was Rahul's talk on how to create a customized Fedora remix. I was looking forward to this particular talk since the idea of making a remix for sheevaplug has been playing into my mind since a while now. It was insightful. I moved on to attend Holger Frether's "How to make WebKit faster". It wasn't what I was expecting, but Holger gave a nice demonstration of how to use a number of well-known and less-known tools to measure performance. His focus was on beagle-board. The best talk of the day was the Keynote by Harald Welte. He talked about bringing open-source to less explored platforms like GSM, RFID, etc. Very Very inspiring!

As the day wrapped up, we decided to head to the Forum Mall for some sight-seeing (ahem). After some window-shopping, trying out fresh baked cookies (which turned out to be horrible) and exploring the Landmark bookstore, we went to have a brilliant lunch at the Anand Adiyaar Bhavan. Later we stopped by at the Corner House for desserts. I dared to order  "Death by Chocolate" not thinking once why it was named so and ignoring Kedar's warnings. The result was disastrous. I never thought chocolate would ever nauseate me so much! A tip for the readers: if you ever order that at Corner House, share one between 5 people.

Attended Lennart Pottering's "Pulseaudio Internals" on the second day. He focused on the do's and dont's on System programming. Very insightful! He is a very good speaker. I wanted to talk to him (like REALLY wanted to talk to him), but a couple of guys just wouldn't let him go! They crushed my dream :-(.  After another fabulous lunch, attended Rahul's talk on PackageKit and Harald Welte's workout on GSM. Went to the Nokia Maemo's booth and got a peek into how they are using Linux on their ARM core. Maemo is one neat piece of hardware. I would certainly recommend it to anyone looking for an open-source phone.

I really wanted to attend the Keynote by Milosch Mariac, since rumour had it that they are using Fedora-ARM in their product. Kedar later confirmed that the rumour was indeed true. But, sadly I had to fly back to Pune :-(.

Some of the things that really impressed me were:

• Lots and lots of students attending the conference. They get a nice exposure through all the workouts and talks. 
• Wireless connectivity on the entire campus. Really made me realise how important my laptop is! I looked up so many terms that I heard/overheard. Very educational.
• There was nothing formal about it and people were so passionate about technology.
• Very Very educational.

It was my very first conference, so I wasn't as proactive as I should have been, but I was better at it on the 2nd day than the first. I look forward to FOSS.in 2010 :-).

PS: Kedar called me later just to tell me that he talked to Lennart and Milosch. grrrr. Jealous!

I want to shout this out a thousand times!

A recent discussion on a fedora mailing list:

> I'd suggest that anyone who sets up a system without any user accounts
> _and_ somehow needs a GUI to configure the system _and_ can't manage
> to figure out the settings to change so they can login as root should
> probably not be pretending to be a competent administrator.
>
> Are there not enough examples from Windows of why it's a terrible idea
> to run with full administrator privileges -- especially software like
> web browsers?
>
>   
Look guys, I didn't ask for a Lecture on how to do things your way, I
just ask where is Konqueror in Root.

How very true! Many a times, I know what risk I run by using GUI as root user, but I still want to. I have my calculations of risk. They have no right to disable running stuff as root. Make it hard. Okay. Spew out warnings. I don't care. But, just let the thing work! Disabling it is just imposing your viewpoints on everyone and it is NOT alright!

Lots of Love,
Me

Atomic operations from userspace

Lennart Pottering, the pulseaudio developer, has made some interesting observations on emulating atomic operations, using ARMv5 as a running example. Obviously, the post is about architectures who do NOT have hardware support and lack or have minimal kernel support. (However, some Andrew Hayley has noted an obscure kernel API for the purpose). A good read overall.

I don't fully understand the post yet, but I intend to dig deep into this once I get free time.

FYI

yum spookiness

Recently, I started getting tracebacks on a simple "yum update"

# yum update -y
Loaded plugins: fastestmirror, presto, refresh-packagekit
Setting up Update Process
Traceback (most recent call last):
  File "/usr/bin/yum", line 29, in <module>
    yummain.user_main(sys.argv[1:], exit_code=True)
  File "/usr/share/yum-cli/yummain.py", line 309, in user_main
    errcode = main(args)
  File "/usr/share/yum-cli/yummain.py", line 178, in main
    result, resultmsgs = base.doCommands()
  File "/usr/share/yum-cli/cli.py", line 352, in doCommands
    return self.yum_cli_commands[self.basecmd].doCommand(self, self.basecmd, self.extcmds)
  File "/usr/share/yum-cli/yumcommands.py", line 368, in doCommand
    return base.erasePkgs(extcmds)
  File "/usr/share/yum-cli/cli.py", line 641, in erasePkgs
    if not self.remove(pattern=arg):
  File "/usr/lib/python2.6/site-packages/yum/__init__.py", line 3023, in remove
    (e,m,u) = self.rpmdb.matchPackageNames([kwargs['pattern']])
  File "/usr/lib/python2.6/site-packages/yum/packageSack.py", line 224, in matchPackageNames
    exactmatch.append(self.searchPkgTuple(pkgtup)[0])
IndexError: list index out of range


Initially I thought it was due to corrupted yum metadata. So, I ran a "yum clean all" to no avail. But then, rpm also started acting spooky. "rpm -q kdelibs" returned nothing although I was pretty sure I had installed kdelibs (since amarok depends on it). Looked like a bombed rpm database.
So, the simple solution was to run "rpm --rebuilddb" which reconstructs the rpm database. Everything worked like a charm after this!

PS: This is more a note to myself than a post. If it helps anyone, well and good. :)

Using the IRC

(Following are some ways I know to ensure privacy and avoid someone spoofing your identity.)

First, I'll recommend registering yourself with a nickname so that no one can steal your identity.
Use this nice tutorial to register your nick on freenode. Other services will have their how-tos.

Second you might want to disable FINGER, TIME and VERSION requests.
FINGER enables getting personal information like Email. TIME gives out your location information and VERSION gives out the OS and client names and versions you are using. Knowing the versions, an attacker might try a specific exploit.
Here is a nice tutorial to do it in xchat. Look at the client specific documentation if you use a different client.

Also, you might want to hide yourself from the global who/whois list (The way to do it on freenode is:)
/umode +i
(+i = invisible mode)

Leave a comment if you know a good addition to this list.

Automake supports cscope and ctags!

Finally!
Automake includes support for automatic generation of cscope and ctags targets. Now, theoretically, you can take any open-source project which uses GNU build system (and manyyy of them do) and type "make cscopelist" or "make ctags" or "make tags" and it will automatically generate the tags! Not that generating tags was a very difficult process earlier, but with support in automake, we can tinker around with the tags a lot.

Eg. If there is an arch/ subdirectory in your source-code and you don't want your cscope tags to be polluted by the IA64 code that you don't really care about, you can do it very easily by modifying the Makefile.am file in the arch directory.

I.e. you can easily control how your tags are generated!

This is the commit that went in,
http://git.savannah.gnu.org/cgit/automake.git/commit/?id=ffad481680a4e6a8f220c70f07b105c9f3f2dfdf


Hail automake!

Masochism ...

Objective : Whenever volumes are mounted, I see volume icons on my Desktop. I want to hide the icons because they mess with my wallpaper.

Method 1 : Find a GUI option.
Result : None present

So, after half an hour of grep-ing in ~ and lsof-ing, I found out that the option I need to set is probably hidden deep down into one of the huge gconf schemas.

 So, I started to learn the gconftool-2 tool. Its one nasty command.

# gconftool-2 --dump / > /tmp/gconf-dump
# wc -l /tmp/gconf-dump
96086 /tmp/gconf-dump


Crap! that huge!
So, I grep-ed for various keywords for another 15 min. Thats when I got a match.


# grep volumes /tmp/gconf-dump
<key>/schemas/apps/nautilus/desktop/volumes_visible</key>
(hiding other results for the purpose of sanity)


So, thats the key I have to flip. Pored over the man-page of gconftool-2 and here is the magic command:


# gconftool-2 --type bool --set /schemas/apps/nautilus/desktop/volumes_visible false


Similarly, you can also turn-off, trash_icon_visible, network_icon_visible (hides samba mounts), home_icon_visible and computer_icon_visible. and voila! A clean desktop!

You'll have to logout and login back again to see the changes. Although, I am sure there's better way. (Like to ask gconfd to reload the config). But, its 2:00am already and I need some sleep. So, I'll update this post tomorrow!

Whew!

RPM Hell

End-users these days are rarely exposed to "rpm". They'll probably be using yum or PackgeKit (or a GUI-based software installer). RPM, FYI, is the backend package management tool used by Fedora, SuSe, Mandriva, etc (together known as the RPM-based distributions). And it sucks bigtime!

Although RPM has come a long way from what it was in the 1990s and early 2000s, it stands on poor foundations and is unlikely to get any better soon. Having worked on Fedora-ARM for over half a year now, I can see the glaring issues that it faces. Fedora has done a hell of a nice job of mitigating those, but when you start to dig deeper, you realise how filthy the RPM world is.

Here is a link to a VERY old pre-yum days paper, "RPM Hell". Its a google cache link since the site which hosted the original paper was down. Here is the original paper.
Now the interesting thing is that, most of the issues mentioned in this paper STILL EXIST and are very real!

Following issues stand out:

1) Package management is pathetic. If I want to install a terminal-based editor, in all probability, I might end-up installing a whole load of GTK and X crap that I am never going to use. The main reason for this is because RPM packages are monolithic. Large packages like emacs typically install all GUI files needed to support it in X even when it is a headless server. So, we have a (needless) dependency, emacs -> gtk. Now, gtk pulls in LOTS of its own dependencies which are really not required and I end up with a bloated installation. Now, this problem can be solved by splitting emacs into 2 packages. emacs-common and emacs-gtk and I just need to install emacs-common. But, we'll soon realise that there are many capabilities a software can provide and we can't keep making a separate package for each. We'll end up with an unwieldy distribution. So, RPM should have a way of internally defining capabilities and installing only those which are really required.

While we were working on the fedora-ARM project and making a basic rootfs for F-11, we had to build almost half of the GNOME packages to satisfy dependencies. WTH!! Gnome shouldn't even come in the picture yet! But thats what happens when you are working with monolithic packages!


2) There's no way to install multiple versions of a software. Now this is not really a RPM problem, it is an inherent Linux issue. Rules like, all executables go to /usr/bin make it difficult to install multiple versions, since there'll be file conflicts.
So, if "A" needs B-1.0.0 but, "C" needs B-2.0.0, you have to choose between A and C. Fedora has greatly alleviated this problem by making sure every package that requires "B" would require the same version of "B". There are a lot of rebuilds, etc for the purpose. And they are partly justified (If we don't force packages to move to newer versions, they never will and we'll end-up with 10 versions of each package installed on our system). But sometimes, you just need a way around! and there's no way you can do it.
eg. There was a time when we had a working package built aganist python 2.4 and the new distributions had python 2.6. Now there were some difficulties because of which we couldn't rebuild the package aganist python 2.6. Only if there could be multiple versions installed! But sigh! We had to devise some dirty workarounds to get stuff working.
 

There are many other issues that yum intelligently hides. Most of them are highlighted in the "RPM hell" link above. Guess its time to rethink RPM?

Adding a swap device

Lets assume you upgrade you RAM from 1 GB to 2 GB. Since, the swap device is usually statically created during install-time and you'll probably be stuck with less swap space than the recommended figure. Then, you have 3 options
1) Who needs extra swap?
2) Make a swap file (simpler, but slower)
3) Extend the swap device.

For Approach 2, you can use the "dd" command to created a file of required size and then use it as a loop device.

Lets see the Third approach in detail.

Run "$sudo parted --list" to get a list of block devices attached to the system.
Use "parted /dev/sda resize <partition-number> <start> <end>"

"/dev/sda" is the HDD on my machine. Replace appropriately from the "parted --list"'s output.
Take the "partition-number" from the "parted --list" command's output. Use the swap device's partition number. Adjust the start end as you wish (can be specified in MBs.. eg. parted /dev/sda resize 5 5000M 7000M"

You don't need to worry about keeping the space free or defragmenting the drives to avoid data loss. Parted (claims) to take care of it.

If you never had a swap space (and created a partition just now) or you are using a swap file,
Make a swapfs on the partition

"$mkswap <device>"
(eg. $mkswap /dev/sda5)

Then, tell the system to swap on that device
"$swapon <device>"
(eg. $swapon /dev/sda5)

Add an entry in /etc/fstab for persisting the settings
Sample entry:
"/dev/sda5     swap    swap    defaults    0 0"

Thats it!

Check whether everything went fine by,
"$cat /proc/swaps"

Recommended swap-space = twice of total physical memory.

enable "sudo" in Fedora..

One fine day I became tired of "su -" and entering the password every other minute. (Also, had to write a script which needed to sudo). So, I decided to enable sudo access. Its pretty simple.
There's a sudo'ers file : /etc/sudoers

Run "man sudoers" to find out exactly what format the file has to be in. It is a bit complex, but don't distress, you won't need its complexity unless you are a funky sysadmin. The sudoers file usually comes with the basic infrastructure and most-frequently-used categories defined. You can define your own categories too. (refer to "man sudoers")

One thing to remember is that the sudoers file should be modified *only* with the "visudo" command. visudo checks the syntax while exiting and optionally, replaces the old file if the syntax is found to be invalid.

Just append the following entry to your sudoers file
jitesh ALL=(ALL)    NOPASSWD: ALL

where, "jitesh" is the username on my machine.
"NOPASSWD: ALL" means that sudo won't ask for password. Use with care.

Avada Kedavra.

Saving yourself from the Avada Kedavra of Linux : rm -rf ./

http://www.linuxjournal.com/article/10428
(Link via cheezo)

Inline Assembly in C

I found this very simple and insightful tutorial. Its very good
http://www.ibiblio.org/gferg/ldp/GCC-Inline-Assembly-HOWTO.html

Fedora: A walk down the memory lane

(For the un-initiated, Fedora is a Linux Distro which was forked off from Red Hat in the early 2000s.)
A nice read:
http://www.raiden.net/articles/Fedora_A_Hat_with_a_History/

Talks about the evolution of Fedora, Red Hat, RPM and also some of the design decisions that has made Red Hat what it is today.

Treat Warnings as Errors

If you are reading this blog and have even a iotic sense of humour, you must have heard (and liked) this joke:

------

A man is smoking a cigarette and blowing smoke rings into the air.  His girlfriend becomes irritated with the smoke and says, "Can't you see the warning on the cigarette pack?  Smoking is hazardous to your health!" 

To which the man replies, "I am a programmer.  We don't worry about warnings; we only worry about errors."

-------

Ofcourse, I laughed my ass off when I first heard the joke. Awesome it was! But then, the last month totally changed my perception. (Probably because I faced the side-effects of that).

So, ARM architecture is very specific about alignment. It hates mis-aligned access (Its the side-effect of being an arch for embedded systems). Here is an example of unaligned access:

1 short short_arr[4];
2 long *long_ptr = short_arr;
3 blah = *long_ptr;

since the data type of short_arr is "short", gcc forces only a 16-bit alignment on the array (on 32-bit systems). but then, long_ptr is probably 32-bit and that screws up alignment for line 3. Although, i386 would work perfectly fine (but require one extra memory cycle), ARM will just give garbage data (if misaligned).

And many many many software packages are filled with such errors. Just to give you an example:
# cat /proc/cpu/alignment
User:           1265555

(this file is present only an ARM architecture because of ARMs peculiar alignment requirements)

See the number of alignment errors?
Packages like mhash (which calculate hash) build fine but fail run-time, this makes such errors difficult to track down.

So, always make it a point to compile your C programs with "-Werror" option. It treat warnings as errors. It is *very* important for your programs to work on just about any platform. Please pay attention to warnings, because warnings are there FOR A REASON. gcc developers aren't stupid!
(Although sometimes, you might be sure that even if gcc warns about misalignment, the access is aligned. eg, when you typecast an IP struct into a MAC struct, etc. These are the *only* times you can let go off the -Werror option)

But, until this point sinks into the mind of every developer, there's no option but to live in this mess. :(

Emacs splash-screen

So one fine day, I grew tired of the emacs splash-screen. You try to edit a file and emacs shows its splash-screen instead of the file contents and then you have to "Press any key to continue". So one day it got on my nerves and I decided that if I don't find a way to disable it, I am going to switch to vi. But, how can an editor as customisable as emacs NOT have an option to disable the splashscreen? Ofcourse it does! and it was the first result on my google search! (probably there are just too many people in this world irritated by the splashscreen, why doesn't emacs just do away with it?)

Simply add this line to your .emacs file:

(setq inhibit-splash-screen t)

yum plug-in : Presto

I have ranted about Presto in my earlier blogpost. Yum's fedora maintainers implemented this really cool idea of maintaining difference between binary packages instead of the binary packages themselves. It would help a lot to push out updates. I was sceptical at first about the amount of savings it would result in (because obviously binary difference is something very complicated). I expected a 20-30% saving. Although people kept reporting numbers of upto 90%.

Today, I decided it was time to "yum update" my machine. (crashing pidgin, crashing rhythmbox, bad font rendering). So, I ran yum update. It showed me a total download size of 876MB (i.e. the total size without presto.. since, presto is new and under beta.. its integration with yum is only perfunctory). So, I dozed off. Today I check my internet usage and guess what, the total usage yesterday night was less than 100MB. Awesome! (Usually, presto shows the difference. It prints out a line saying "This is actual download size and this was download size with presto". But, as I dozed off, the line went off the terminal limit).
Anyway, it is infact 90% savings! that is so awesome! Now I can "yum update" even during the day :D. No need to wait for the night free time.

Goooo fedora!!!!!

Linux sound level too low?

After having (finally) upgraded Fedora-11, I found it pretty annoying that the sound level was wayy too low. I mean, even with speaker volume set to full, system volume set to full and application volume set to full (not to forget pulseaudio volume .. which is another layer between the app and the system), the sound levels were only just enough for me to watch a movie without missing out a dialog. WTH! I have awesome speakers and they should ideally crack my windows. But here, even full volume was just barely enough. It hurt my ego (:P).

On Windows, the full volume is a real window-cracker. What is the problem with Linux then? (I could replicate the same issue on Ubuntu 9.04 too.. that should explain why I went for generic "Linux" and NOT "fedora"). Then I found this bug filed in the fedora bugzilla which made things clearer (actually, they didn't). Don't bother to read, it went swooosh over my head. The only thing that stuck was - How to solve the problem.

Here it is:
Make sure you have the package "alsa-utils" installed.

For fedora:
$ sudo yum install alsa-utils

For Ubuntu:
$ sudo apt-get install alsa-utils

Then, run
$ alsamixer -c 0
and increase the master volume beyond green area to the red area. (I understand that the red area implies increased noise, but I didn't really notice much of a difference with a slightly less than maximum setting. Even with max master volume, there is only a slightly noticeable noise)

I don't understand why this control is hidden away in such a manner. What is the whole point? Why not export a GUI for it? Weird. Probably they'll fix it in fedora 12. There's been a lot of work in the sound area in the last 6 months. There are going to be some bugs afterall. Anyway, this healed my ego :P. Linux sound is at-par with any other sound system! It makes me happy!

Emacs: linux-c-mode and Line numbers

Tired of the slow ssh access to one of the servers located outside India, I finally figured it was time to start playing with emacs to reduce the number of keystrokes needed.

First on, I wanted the linux-c-mode enabled *by default* whenever I open a file whose extension is ".c" (Yeah Yeah, I know extensions are meaningless for Linux.. but emacs is intelligent :) ). For all the other type of files, linux-c-mode should be OFF, because it will mess-up their indentation.
Second, line numbers should be displayed on the left-hand-side panel of each file I open. Then to go a particular line I just "M-g g". Simple.
Third, All this should be accessible to my user account as well as root user.

So, I edit the ~/.emacs file (create if not already present) like this (for the first goal):
(defun linux-c-mode ()
  "C mode with adjusted defaults for use with the Linux kernel."
  (interactive)
  (c-mode)
  (c-set-style "K&R")
  (setq tab-width 8)
  (setq indent-tabs-mode t)
  (setq c-basic-offset 8))

(add-to-list 'auto-mode-alist '("\\.c$" . linux-c-mode))


The first chunk defines the linux-c-mode (from Documentation/CodingStyle) and the last line enables it by default ONLY for *.c files. Simple!

For the second part, I got a script linum.el from google (Vedang says it has been integrated into emacs)
You can find the script here: http://jitesh.1337.googlepages.com/linum.el
Drop this script at /usr/share/emacs/site-lisp/

There's a problem with this script. It doesn't print a space after the line number. Sad!
Here is a patch I wrote to fix it: http://jitesh.1337.googlepages.com/linum.el.patch


Now I want to display line numbers for EACH file I open in emacs. So, I add the following lines in the .emacs file:
(require 'linum)
(global-linum-mode 1)

(First line is needed to autoload linum.el. The second line enables it by default)
To toggle the linum mode, use "M-x linum-mode"
Simple!


Finally, I wanted to give access to root user too.
A simple solution would be to make a symlink/hardlink from /root/.emacs to /home/jitesh/.emacs.
However, I wasn't too concerned about the other users on the system :) .So, I simply copied to .emacs file to /usr/share/emacs/site-lisp/site-start.d/ and renamed it as myinit.pl. So, now, these things get enabled by default for *all* users.

Now that everything is setup (and steps documented via this blog), let me go back to coding peacefully in emacs!

Upgrading to Fedora-11 (Leonidas)

Finally I got my hands on the brand new Fedora release. Fedora-11 (Leonidas). As I had a sneek-peak into the development process this time around (work reasons), I was pretty excited to upgrade to this new version. There are a couple of nice features in Fedora-11 that makes it awesome.
1) Presto: Delta-RPMs. If you are updating your system, yum now fetches only the *change* between two versions instead of pulling in the new version entirely. Savings of 60-70% of bandwidth have been reported.

2) PackageKit: Makes installation of new packages and plug-ins very easy and user-friendly.

Time for installation.
So, I booted into F10 and set the system up for the normal upgrade method that I use. Which is:
1) Insert the DVD.
2) Make a yum repo which points to the DVD.
3) Issue a "yum update"
4) Watch a movie while your system upgrades.

However, this time I decide to be a good boy and read the fedora docs first to see whether it had to say anything about upgrades. Turns out it was a good decision. Apparently, there is a bug which makes such an upgrade impossible and leads to a possibly "unusable system". Whew! close shave!

So, why the hell did they release F-11 when a method of upgrade was broken? Well, there were vibrant discussions in the fedora community over this bug and the final decision was: This upgrade method is not "recommended" and "supported" and hence, it isn't a F-11 blocker bug :(. Sigh!

So, guess I'll have to follow the "recommended and supported" method. Boot from DVD and choose "upgrade". I'll have to stare at the screen for an hour while the system upgrades :)
Looks like I'll wait for a respin which contains a fix.
(/me adds himself to the CC list for the bug)

Another caveat is that the rpm format has been changed in Fedora-11 to make it more secure. This makes upgrade impossible because the installed rpm simply cannot read these new rpms. The solution is: Fedora has issued an update to F-10 "rpm" package which is aware of this new format. So, you'll have to run a "yum update" on F-10 first (older Fedora's will have to be moved to fedora-10 and then updated via "yum update"). Once, this new "rpm" package is installed, then the upgrade should go smoothly. (Note: If you don't update "rpm", yum will fail with "MD5 sum mis-match" type of errors)

The delta between Fedora-10 and Fedora-11 is huge as compared to the previous deltas. There has been some heavy development. Lets see if Leonidas has the same majesty as the King ...

Debugging a segmentation fault using gdb

I am not a big proponent of gdb. If you *really* know what you are doing, gdb shouldn't be required. But, every now and then, you come across code that has used function pointers exclusively and then, hand-debugging becomes painful. gdb to the rescue.

You'll need the following pre-requisites to use gdb to debug a segmentation fault:
1) make sure you have compiled the executable WITH debugging symbols. i.e. the "-g" flag. eg
gcc -g -o hello hello.c
Without debugging symbols, gdb won't be able to do much.

2) Linux should core-dump on segmentation fault. Set:
ulimit -c unlimited
(man ulimit for more info)


Now just run that the excutable that is segfaulting. As soon as it segfaults, you should get an output something like "Segmentation fault (core dumped)". ls in your working directory and you will find a new core file has been created (probably with the name core.{pid})

Now, we just have to tell gdb to analyze this core. Here's how
gdb {executable} {dump file}

eg. gdb hello core.1324

Check out the output spit out by gdb and make sure that all debugging symbols have been loaded.
Now, on the gdb prompt:

(gdb) bt
(bt = backtrace .. prints stack strace)
with this backtrace you'll now know *exactly* where the program segfaulted. The code file, line number and the call which was the culprit.

You can even analyze variable values on any frame. Just change to that frame:
(gdb) frame {num}
eg. (gdb) frame 2

and use:
(gdb) info locals
(gdb) info args
to query the values of local variables and passed arguments, respectively.

With all this info, you can pin down the exact reason for the segfault pretty easily. Saves a lot of time!

Packages: Naming scheme

Its been a while since I wrote a nice article and today I just felt that inner need to write one. Today's topic is an introduction to the naming scheme used to manage packages. But, before that it'll be useful to distinguish between some similar terms.

Package: This is the common name that we generally use. Eg. "Amarok" is a package name
Build: A build is a particular release of a package. eg "Amarok-1.4.12-1.fc10" is a build. Note that a build specification is architecture independent.
RPM: An RPM is the architecture specific binary of a build. Eg. "Amarok-1.4.12-1.fc10.i386.fc10.rpm" is an rpm.
SRPM: Source RPM is architecture independent and contains the sources of the build packaged as an rpm. (Now, why would that be useful, you may ask. Why not a tarball? That'd take up another post to clarify. Queuing the topic)

Naming scheme:
Generally, a build is named in the following manner.
Name-Version-Release (popularly known as the NVR of a package)
Name: might be a simple name such as "Amarok". It can contain the hyphen character.
Version: Version is usually in x.y.z format. "z" being the least significant and "x" being the most significant. Usually, if a respun rpm contains only bug-fixes, only the "z" part is incremented. If there are some major changes or feature additions, "y" is incremented. An architectural change warrants an "x" increment.
But, some packages (like tzdata) use a different versioning scheme. (Since, tzdata package deals with timezone stuff, they find it convenient to include the year in the version. Eg. 2007k, etc.) But, an overwhelming majority use the x.y.z scheme.

Release: It is generally only a decimal number. It can be viewed as the minor version number. If the change is very small, so that incrementing even "z" is unjustified, release number is incremented. It might contain small bugfixes or other minor changes.

When, someone distributes a version of the rpm that deviates from upstream, (he has applied his own patches to the source) he should change the release number to reflect the same. A string is to be appended to the release number.
eg. If someone patches amarok to add his own cool new feature. He has to change the release number from "1" (say), to "1.fa1" or something similar. Just append a string at the end. So, when you see a non-standard package, you can instantly make out from the name.

RPMs also contain the architecture name along with the NVR.

Now, suppose you have 2 packages "blah-1.2.3-1.fc10" and "blah-1.2.3-1.fc11". And, there's a bug-fix which only applies to the fc10 version, what do you do? Certainly, you cannot change the Version number or Release number of the fc10 rpm because it was a "fc10" specific fix and hence, not a property of the build. In such a case, the build is spun as "blah-1.2.3-1.fc10.1". But this is a fairly rare case.


Well, This was a fairly basic post. But, this one merely does the job of heralding a series of posts on messing with RPMs and SRPMs. So, stay tuned!

Writing a resume ...

Resume writing has always been a mystery to me. A rather pointless exercise of listing what you've done in the last 20 years. I mean come on, what does the HR care whether I have secured 40% or 99.99% in the 10th standard? Unless physics and chemistry combine to form a software engineer much like blue and yellow combine to give green. Another thing that has endlessly puzzled me in a resume is "Hobbies". When I was briefly working with the TnP cell (2 hours, before I resigned), I've seen people having such amusing hobbies and the courage to pen them down on the resume. How can "Watching TV" "playing video games" or even "playing pranks" be included in the hobbies section on a resume? Why would the HR give a damn even if you have a hobby of mooning every stranger you see!! Utterly pointless...

But, then my brother gave me this amazing link. (much like the ads where you are fat and the girls are disgusted by you and they always prefer the slim ones and then your friend gives you a pill to make you super-slim within a day) It is titled "Tips for a slightly less awful resume". The author has had a good experience in resume screening. The points he has made clears many of the myths we have about resume writing and to say the least, they are ground-shaking. Whatever I thought were the best practices in resume writing are listed as a strict no-no with a very good line of reasoning. It is a must read for everyone who wants to make that resume of yours slightly less awful.

The post is a bit long and I am, myself very wary of long posts. I generally skip them, if they are not entertaining enough. With this one I was hooked till the last line. The man has got an amazing sense of humour and some really sharp sarcasm. The post isn't a sermon on the do's and don'ts of resume writing but a slightly less awful waste of time on how _not_ to screw-up your resume :)

Please do make it a point to read the post atleast once before you make your "awful" resume! :)