Fast math ops

Just wanted to stash this little tidbit here in case I needed it for something.

This Slashdot article bringing up Origin of Quake3’s Fast InvSqrt(). The original article is a bit of a sleuthing expedition looking for the origins of this little code snippet and makes for an interesting read along with pointing to some other interesting sources.

The algorithm is a remarkable in the way it hides a lot of complexity in a simple looking package. All it does is calculate 1/sqrt(x), but does it very quickly using a cleverly written Newton-Raphson method.

Continue reading “Fast math ops”

Tape to tape

Sometimes there are little side projects I help tackle just because they’re interesting.
So at work we’ve got this LTO tape library that’s used for archiving images. We’re in the process of migrating off the tape library onto SAN and an IBM Tivoli tape library. In the meantime, there are a handful of older tapes (that we’ve found so far) that the LTO library has managed to mangle over the past few years. Fortunately it’s just the leader section of the tape that’s been mangled or broken, so we don’t think there’s been any actual data loss.
It’s only a small number of tapes out of the hundreds of so in the library, so it probably wouldn’t be a problem if the data on the tapes wasn’t recoverable. Naturally the easy thing to do would be to send the tapes to one of those data recovery services and have them do the salvage work. But, that costs big bucks and being a Department of Very Little Budget, it’s a last resort option.
What we do have are a bunch of spare LTO drives and a bunch of unused Sun Ultra servers. ding!, on comes the light bulb and we figure if we can connect the LTO drives to one of the Ultras, we can copy one tape to the other using dd(1)! Brilliant! Then we can brag about saving the department thousands of dollars!
Only if it works.
Found a couple of spare molex connectors in the Ultra box to provide power to the drives, and a SCSI cable lying around (just need to find one more now). The tape drives are high voltage differential SCSI-3. I’m not sure what the computer’s SCSI card is, but with my luck it’s the low voltage version.
So that’s where we are now. One LTO drive connected and scrounging around for another SCSI cable to connect the other one. Might end up having to scrounge up some HVD SCSI cards too. Who knows. I have no idea if this will even work but it will be very cool if it does.

It’s Dan’s fault

Thanks to Dan for getting me stuck on Google Reader.

Here are some of the tidbits I’m sharing via Google Reader. I even added a new module to the sidebar. I need to find out how to style it so it fits the look of the blog a little better.

Now to figure out why my random image block isn’t working anymore…

Software engineering for scientists

The November/December issue of Computing in Science and Engineering has a great article titled Software Carpentry. It’s basically a crash course on software engineering for non-programmer scientist types that need to write programs. All the courseware is online, or if you happen to live near University of Toronto, you can sign up to take the course.

From the website’s overview:

Many scientists and engineers spend much of their lives programming, but only a handful have ever been taught how to do this well. As a result, they spend their time wrestling with software, instead of doing research, but have no idea how reliable or efficient their programs are.

This course is an intensive introduction to basic software development practices for scientists and engineers that can reduce the time they spend programming by 20-25%. All of the material is open source: it may be used freely by anyone for educational or commercial purposes, and research groups in academia and industry are actively encouraged to adapt it to their needs.

Sounds just like me. I’m looking forward to going through the course material and learning something useful that I can use to re-work some of my existing programming projects.

RFID credit cards and (lack of) privacy?

A story over at Slashdot points to an NYT article describing how some researchers cobbled together a device to read those newfangled RFID credit cards. Everything was built using OTS components, and the researchers say an even smaller device could be made. So conceivably, a nefarious bad guy cracker with a modicum of skills could cobble one together, mingle through crowds and lift info off these cards through people’s pants and purses.

The finding comes at a time of strong suspicion among privacy advocates and consumer groups about the security of the underlying technology, called radio frequency identification, or RFID. Though the systems are designed to allow a card to be read only in close proximity, researchers have found that they can extend the distance.

The actual distance is still a matter of debate, but the claims range from several inches to many feet. And even the shortest distance could allow a would-be card skimmer to mill about in a crowded place and pull data from the wallets of passersby, or to collect data from envelopes sitting in mailboxes.

Naturally credit card companies and banks say this is a highly impractical attack method given that other methods (i.e. phishing) are so much more effective. Excellent application of security through obscurity. I guess they haven’t learned that even if it might be less practical than current methods, it just becomes another item in the bad guys’ arsenal.

NYT also provides a link to a paper by the researchers. It’s an interesting read with a lot of good info on how the RFID cards work.