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?