Friday, April 30, 2010
Oops! An Oil Spill!
I'm confused. The oil rig in the Gulf Of Mexico exploded over a week ago. Why wait so long before deploying booms and attempting chemical dispersion? Why wait a week before using the U.S. military equipment and personal? Why wait until the oil reaches the shore before doing anything? Why? These and other questions are going come very soon after this is over, perhaps even before it is over.
Thursday, April 29, 2010
I Love Specifications
Since the application now runs on the production PC as well as on my development system, this was good milestone to show to the customer. Given how late this project is, they were surprisingly calm about everything. When they showed me the mechanical side of the project, it was obvious that thing's were, um, how shall I say, a wee bit different. It's not surprising really, as the original specification was all of two sentences, one of which stated that it worked like an app I did for them several years ago. <^_^;
Well, at least I know why they were so calm. Looks like we are doing another iteration! Have I mentioned lately how much I love specifications. -_^
Well, at least I know why they were so calm. Looks like we are doing another iteration! Have I mentioned lately how much I love specifications. -_^
Wednesday, April 28, 2010
Udev Rules! Not!
If someone tells you how great Linux is, they've probably never had deal with odd ball situations. Take udev, for example. Please! Take udev! I'm begging you! ^_^
I'm using the 8-in/8-out version of this USB I/O unit on a project. This hardware doesn't require any Linux kernel drivers which make me very happy. The manufacturer provides the source to a library which uses libusb to communicate with the device. The device does not store the firmware permanently so it must be downloaded every time you plug in the hardware. One quirk is that after the download, the device disconnects and reconnects with a different product ID, but the manufacturer includes udev rules to handle it.
My big mistake was that I setup the hardware on my desktop system, which is running Debian sid/unstable, before trying it on the production PC, which is running Debian lenny/stable. The configuration requires two udev rules (which are slightly different that the manufacture's version)
After some (understatement! ^^) investigation, I found that the following udev rule on Debian lenny was causing the problem.
The final rule set looks like this:
I'm using the 8-in/8-out version of this USB I/O unit on a project. This hardware doesn't require any Linux kernel drivers which make me very happy. The manufacturer provides the source to a library which uses libusb to communicate with the device. The device does not store the firmware permanently so it must be downloaded every time you plug in the hardware. One quirk is that after the download, the device disconnects and reconnects with a different product ID, but the manufacturer includes udev rules to handle it.
My big mistake was that I setup the hardware on my desktop system, which is running Debian sid/unstable, before trying it on the production PC, which is running Debian lenny/stable. The configuration requires two udev rules (which are slightly different that the manufacture's version)
SUBSYSTEM=="usb", ACTION=="add", ATTRS{idVendor}=="1605", ATTRS{idProduct}=="001c", RUN+="/sbin/fxload -t fx2 -D $env{DEVNAME} -I /usr/local/lib/USB-IDIO-16.hex"
SUBSYSTEM=="usb", ACTION=="add", ATTRS{idVendor}=="1605", ATTRS{idProduct}=="801c", GROUP="aiousb", MODE="664"
Of course, thinking that I could just copy this configuration over to the production PC, was just too optimistic. The first line works (the firmware is downloaded) but the second line doesn't set the device file group which is stuck as root.After some (understatement! ^^) investigation, I found that the following udev rule on Debian lenny was causing the problem.
SUBSYSTEM=="usb_device", ACTION=="add|change", PROGRAM="/bin/sh -c 'K=%k; K=$${K#usbdev}; printf bus/usb/%%03i/%%03i $${K%%%%.*} $${K#*.}'", ACTION=="add|change", NAME="$result"
At first I changed my custom rule to match the SUBSYSTEM and ACTION attributes, which worked for hotplugging and cold boot, but not for a warm boot. On a hunch I added the original rule back again, which worked!The final rule set looks like this:
SUBSYSTEM=="usb", ACTION=="add", ATTRS{idVendor}=="1605", ATTRS{idProduct}=="001c", RUN="/sbin/fxload -t fx2 -D $env{DEVNAME} -I /usr/local/lib/USB-IDIO-16.hex"
SUBSYSTEM=="usb_device", ACTION=="add|change", ATTRS{idVendor}=="1605", ATTRS{idProduct}=="801c", OWNER="root", GROUP="aiousb", MODE="0664"
SUBSYSTEM=="usb", ACTION=="add", ATTRS{idVendor}=="1605", ATTRS{idProduct}=="801c", OWNER="root", GROUP="aiousb", MODE="0664"
It looks a kind of clunky, so there is probably a better way to do it, but I'm way past the limit of my udev-fu, so I not going to poke at it any more. I'll worry about it when it stops working. Which will be at some inconvenient moment, I'm sure. udev works great, until it doesn't. ^_^
Tuesday, April 27, 2010
Bad Idea
Oh dear! How is this for a bad idea? Thankfully, it's only research for now but it's insane that they are even talking about the system as if it could ever be used safely under normal driving conditions. I don't care how good they think the software is, it'll never be able handle all the complex situations that a driver deals with everyday. I read somewhere that the most challenging part of the work day for most people, is the commute to and from work.
Monday, April 26, 2010
Ferrari 599XX
Although I'm not a big fan of Ferrari, I enjoyed this video of the 599XX breaking the lap record for production-derived sports cars at the Nurburgring Nordschleife. As this article notes, "production-derived" is seriously stretching the term for the 599XX, which, apart from name and looks, has very little in common in with the 599. Still, watching the 599XX blast around the 20km track is worth the 7 minutes it takes to complete the lap.
These long tracks are awesome and I wish Formula 1 had one on the calender. Unfortunately, long circuits do not make for good television coverage, which is the primary business of F1 these days. It's a shame really.
These long tracks are awesome and I wish Formula 1 had one on the calender. Unfortunately, long circuits do not make for good television coverage, which is the primary business of F1 these days. It's a shame really.
Sunday, April 25, 2010
Death And Taxes
This about the second one. Yes, it's that time of year again. This was the last weekend before the April 30 tax deadline and naturally I procrastinated until now. Anyway, it's all done so no worries. Despite being self-employed, my tax return is actually quite simple because I keep my business records in order. My return only takes a couple of hours to complete using tax preparation software. Still, it's the most annoying two hours ever. It's taxes damn it!
Saturday, April 24, 2010
Quote For Our Times
There has grown in the minds of certain groups in this country the idea that just because a man or corporation has made a profit out of the public for a number of years, the government and the courts are charged with guaranteeing such a profit in the future, even in the face of changing circumstances and contrary to public interest. This strange doctrine is supported by neither statute or common law. Neither corporations or individuals have the right to come into court and ask that the clock of history be stopped, or turned back.Not only is it the perfect quote for our times but the source makes it especially interesting. Who says science fiction is irrelevant?
- Robert A. Heinlein Life-Line
Subscribe to:
Posts (Atom)
