Enabling USB access for VirtualBox, and/or general libusb clients

Tipically, usb devices get a /dev node created automatically (provided you're on a recent Linux version) by udev system, with only root priviledges, so your applications have very limited raw access to them. This is ok if you have a driver, but when your application needs libusb access, this is a different matter.
Solution is quite easy: just ask udev to create specific nodes with your group access rights. Simpler way to do so is to create an udev rules file in /etc/udev/rules that instructs to set group to your own (instead of root).
For this example, we're about to make PicKit2 USB programmer to be accessible by its application (pk2cmd in this case), and also to VirtualBox running the Windows equivalent.
We go to /etc/udev/rules and create a file called 90-pickit2.rules (name is not very important, provided it doesn't overlap with another one, the initial number sets some sort of order upon load). File content could be something like this:

# Rules to make PicKit2 node readable and writable by users group

# Microchip 04d8, product 0033
ATTRS{idVendor}=="04d8", ATTRS{idProduct}=="0033", GROUP="users"

Note that 04d8 is device manufacturer (you should use your own, in this case this is Microchip) and 0033 is product ID for such manufacturer (0033=PicKit2). We want that the node created when such device is plugged in belongs to group users, so we have RW access to it.
After that, simply plug in your device, and must appear on your application with no more troubles (provided you already installed it:-)

GDB debugging tips

These are several hints when using gdb that are seldom used enough to forget them, but often still important and useful:

• Debugging child processes (e.g. allowing a breakpoint to work once the process forks): set follow-fork-mode child.
• Setting a hardware watchpoint: watch *(&<address>).

Electronic design - gEDA symbols

I will try to store here some of the symbols I had to build for some designs, that were not available at the standard libraries. These are not published on the official gEDA symbol sites because they are still incomplete or not fully tested, but may be of interest for someone that just needs them for a schematic, for an instance.

• Microchip PIC24FJ64GB108
• Microchip MCP9700T
• Maxim MAX3471
• National Semiconductor LP2981

Useful links for Linux administration

I will try to list here that useful links that tell how to do common things that you often forget...
Content on such links should be useful and I've used them some time, but it is not controlled in any way by me, so use them at your own risk!

• Generating certificates and keys for SSL: http://www.akadia.com/services/ssh_test_certificate.html

Booting with LILO when boot disk changes since installation

For a quite long time, there was a nasty dependency in LILO that screwed me up: I used to configure it by specifying the device name where the kernel image was (that is, root=/dev/XXX). This was ok until I built a small server based on the Via Artigo 2000...
It worked fine with the stock kernel, but once I compiled a specific tailored one, a pretty kernel panic appeared (complaining that it couldn't mount the root partition). The cause was simple: with the stock kernel, pata_via was used (so boot disk was /dev/hdc1 in my case, that is the compact flash disk), but with a tailored, more recent kernel, boot disk become /dev/sdb1 (yes, changed from ide to scsi and from 3rd to 2nd... :-(
After a year running with the stock kernel, the 500GB hard disk just said good-bye (not being the first, but this is a different story about poor quality of branded SATA disks...), so I decided to use a 4GB Compact Flash  for the root partition, and a new hard disk for data storage (and logs, etc.). Anyway, I decided it was time to spend some time to solve the problem about the "moving" disk devices and so... here is the solution I found. Despite this long preface, this solutions is also good when you have a system where you add/remove disks and/or controllers at some time :-)

The idea is to change references to the device by Volume IDs so we always refer to the same disk, despite its location in the bios/kernel disks list.
Unfortunately, LILO root= didn't accept the volume ID directly, so I finally had a mixed approach:

1. Used LABEL= in the places it is allowed.
2. Used new raw device specification otherwise

So here are the steps to perform (still on your old configuration):

1. Label your disks, specially the one you want to boot (but also other ones you want to mount). This is simply accomplished (for ext2 and the like) with e2label /dev/XXX NewLabel, where XXX is your partition device (like /dev/hdc1 in my case) and NewLabel is the label you want to use (16 chars max), in my case, it became "BootFlash4GB".
2. Edit your fstab file, so that disks are now referenced by their label instead of their device. That is, I had to change /dev/hdc1 to LABEL=BootFlash4GB, and also /dev/hdb1 to LABEL=DataDisk1.
3. This was the simple (and portable) part. You'll never need to change this again (provided you don't want to add new disks to your list of mounted ones). Now we want LILO to boot our tailored image, and here comes the real trouble: currently the Boot Flash disk is /dev/hdc1, but for the new kernel, it will become /dev/sdb1. This is impossible to manage by LILO alone, for as far as I could guess. The trick I successfully tried is to tell LILO to boot kernel as kernel itself requires (see this below) by removing the root= entry completely at the respective lilo.conf section. Then setting into the kernel image the partition it was intended to boot from, using rdev (in my case, this was rdev bzImage-2.6.36 8,17 where bzImage-2.6.36 is my tailored kernel, and 8,17 are the major,minor decimal device numbers for 0811 (hex) device sdb1). Don't be too upset with the last values: you will see them just before your kernel decides to freeze!
4. Of course, after changing lilo.conf and the image itself, run lilo to install changes.

And that's all!

Hope this may help you, and you weren't suffering the problem for so long at all... :-)

By the way, once you boot with your new image, be careful that now disk devices have changed, so you may want to update your lilo.conf to the new value (that is, change /dev/hdc1 to /dev/sdb1 and /dev/hdc to /dev/sdb in any sensible place). When you build another new image, you won't need to rdev it again while it doesn't change the disks/partition order, but it doesn't hurt if you re-set it to the same value.