November Status Report

In no particular order:

• I trashed my Windows Vista partition, which I was not using, and installed CentOS 6. Why CentOS 6?  I want to run XILINX ISE WebPACK, which can run on Linux, but is only certified to run on RHEL this version and Suse Linux Enterprise that version. I have a board with a Xilinx part on it, and I want to play with it. Rather than screwing around with my default Ubuntu desktop box to get Xilinx to work (it's supposed to be possible), I decided to install the nearest thing to RHEL around: CentOS. My intention is to make an "engineering workstation" type system, like my old Sun workstation that I used on the job.
• CentOS 6 has it's quirks. Red Hat uses a program called prelink to (try to) speed up the system. YMMV, as they say. What it does do, and does very well, is trash Dropbox, an online file storage provider. Dropbox is currently  important in my life because I store  my notes on it. I do love my notes. Prelink does a good job of prelinking things that should not ever be prelinked. To tell prelink to cut it out, you have to edit the file /etc/prelink.conf and blacklist the program being trashed. Yup. The prelink guys want you to opt out, not opt in. I give them credit for being so inclusive. For a program like Dropbox, blacklisting can be an iterative process. You think you have it fixed, but then Dropbox gets trashed again, so you have to tweak your blacklist... again.The magic temporary fix is sudo yum reinstall dropbox dropbox-nautilus, which will at least temporarily give you back Dropbox. (Yeah, I enabled sudo. Just shoot me, I come in peace, from Debian. Sorta, kinda.) I think that I have the proper blacklisting sorted out, but only time will tell. 

For the record, here's the lines I added to /etc/prelink.conf to blacklist Dropbox:
-b dropbox*
-b dbcli*
We'll see how this works out in the long run. Yesterday when I booted CentOS 6, Dropbox was still working, and all is in harmony.

• The GUI based package manager, which is based on PackageKit and YUM,  is slower than cooking Irish oatmeal. I have no idea why. Running yum from the command line does not seem too slow, so it has to be something with how they're updating/searching/building the local package database. For the record, synaptic and APT seem much faster. 
• Of course Ubuntu has the annoying apt-xapian-index thing going on...  very annoying. See:

High CPU Usage on Ubuntu By update-apt-xapi Process (Note that you have to fix the /etc/cron.daily/apt file as well as the /etc/cron.weekly/apt-xapian-index file. Ubuntu belives in wearing  both a belt and suspenders braces.)

•  I did a fresh install for my Ubuntu system. I went from 11.04 "Natty Narwhal" to 11.10 "Oneiric Ocelot". Supposedly they have improved the wonderful, shiny new Unity user interface. I tried it (again); it's still not what I'm looking for. No surprise. I fixed this with a sudo apt-get install lubuntu-desktop kupfer and life is beautiful again.
• Ubuntu 11.10 has packages for a complete GNU gcc toolchain, including hardware debugging,  for a TI MSP430 target. In theory one would not have to ever build the friggen' thing again. In practice, the gdb-msp430 package will not install:

E: /var/cache/apt/archives/gdb-msp430_7.2~mspgcc-7.2-20110612-1ubuntu1_amd64.deb: trying to overwrite '/usr/share/gdb/python/gdb/__init__.py', which is also in package gdb 7.3-0ubuntu2

The bug is already in the Ubuntu launchpad bug tracker.  

• Another problem with an official Ubuntu package for a MSP430 toolchain is that an official package will follow the Debian standard for where files go: executable binaries go in something like /usr/bin, libraries in something like /usr/lib, and so forth. The toolchain is scattered through your system, albeit in a logical way. This may make using Eclipse's C/C++ Cross Compiler Support  and C/C++ GDB Hardware Debugging plugins a pain to use. One reason I like Eclipse is it gives you a GUI type debugger in Linux. I do so like to point and click...

Note the handy Eclipse configuration form, found under Project --> Properties --> C/C++ Build --> Settings, at least on my system. It's trying hard to make your life easier. Really. I think that Eclipse is assuming that you have the whole the cross compiler toochain stored in one location, such as /usr/local/foo or /opt/bar. If you can give it a valid prefix, such as msp-430- or arm-none-eabi-, and a valid path to the toolchain's executables, such as /opt/msp430/bin or /opt/CodeSourcery/Sourcery_G++_Lite/bin, your life will be much easier because you will have fewer wonderful Eclipse form boxes to fill out. This may work for putting your executable binary things in /usr/bin, and the rest of the files somewhere in the file system. I don't know. If someone fixes the gdb-msp430 package I'll find out. My preference is too keep all the toolchains separate, but if everything plays nicely and I don't have to build the mspgcc toochain ever again, I'll be happy.