The Mothership

I can never keep these straight since I keep forgetting the exact rules around pointer type qualifiers, so for my own reference:

const X * foo;    // Cannot change what is being pointed at, can change the pointer
    foo = &bar;   // Allowed
    *foo = bar;   // Not Allowed

X const * foo;    // Equivalent to the above

X * const foo;    // Cannot change the pointer value, can change what is pointed at
    foo = &bar;   // Not Allowed
    *foo = bar;   // Allowed

const X * const foo; // Cannot change either the pointer value or the target
    foo = &bar;   // Not Allowed
    *foo = bar;   // Not Allowed

I love you guys and all, and the occasional power trip is fun, but when you make me a moderator three times within five days it starts to become more of a chore than a treat, and it tempts me to decline moderation permanently…

Looks like there’s a security vulnerability in recent versions of Mozilla and Firefox on Windows. Fixes are already up at mozilla.org.

As much as we like to crow about IE’s vulnerabilities (and they’re still far ahead in sheer number and severity), it has to be remembered that nobody is perfect. No development method is invulnerable. No target is immune from attack.

Tip for the day: Restarting ‘udev’ on a running system is a really, really bad idea if you ever want to see any of your pseudo-ttys again. I couldn’t log in via SSH or even start another xterm until I rebooted.

Otherwise though, it seems like it works fairly well so far under Slackware 10. The entries in /dev are minimized to those actually relevant to the system, and I can assign node names based on things like vendor strings, so my camera always appears as /dev/camera instead of varying between /dev/sda1 or /dev/sdb1 depending on what order I plugged things in.

As always, there are quirks. My USB multi-card reader only shows up as the basic whole-device node (e.g., /dev/sda) if no cards are actually in it at boot time, as is usually the case. In order to actually get at the files though, you need the partition nodes (e.g., /dev/sda1, /dev/sda2, etc.), and they don’t show up. Unfortunately, with these kinds of devices, inserting a card doesn’t actually cause a USB event, so the kernel and udev don’t know that there’s now a card there on which it should go scan the partitions.

Fortunately there’s a workaround; you can force udev to always create the partition nodes with something like the following in udev.rules:

BUS="usb", SYSFS{product}="Multi-Card Reader", NAME{all_partitions}="usbcard"

Then I can access my SD card in the reader with /dev/usbcard1.

And, of course, the above pseudo-tty problem…