2007-02-22
Posted in Geek Stuff, Web Wandering & Opinion
at 21:45
Have you ever worried about the lifetime of your stored data? You should.
- Google did a study that has shown an hard drive reliability to be even lower than previously thought.
- Professionally pressed DVDs and CDs have a shorter lifespan than recordable ones due to the materials involved. (Sorry, no link. Let me know if you have one.)
- Hard drive density is now so high that error correction is constantly active (Again, let me know if you remember where I read this)
Now that I’ve scared you a bit, you’re probably asking about the one format type I seem to be leading to. Recordable Optical discs.
If you’re curious, I’ll provide links, but I’ll summarize for the busy: When backing up, use DVD+R (Avoid DVD-R) discs and make sure they were manufactured in Japan or Taiwan. (Especially avoid Indian discs) If your job depends on it, make sure you get “Archival-grade” discs.
Here are the details:
And, as usual, store your stuff in a cool, dry place and use cases made from acid-free plastic. That alone will probably make your old DVD-Rs and CD-Rs stay readable for twice as long. 
Permalink
Posted in Geek Stuff
at 2:10
Yes, there is a legitimate reason for removing devices, and a special way to do it. In my case, I needed to because my cheap USB numpad exported two evdev-compatible devices with the same name. This confused evdev-plug… especially since one of them is completely inert.
The trick is to find the modalias for the troublesome interface in question. That will uniquely identify that evdev interface file leaving the other one untouched. Assuming the device node is /dev/input/event6, this should do the trick:
udevinfo -a -p `udevinfo -q path -n /dev/input/event6` | grep 'ATTRS{modalias}=="usb'
Take the output of that line and substitute it into this udev rule: (See my previous post for details))
BUS=="usb", ATTRS{modalias}=="usb:v1267p0103d0101dc00dsc00dp00ic03isc00ip00", OPTIONS="ignore_device"
It should be pretty self-explanatory.
UPDATE: On a related note, if you are using one of those Mouse+Keyboard USB-to-PS/2 bridges and don’t mind the lack of “Plug and Play”-like flexibility, the simplest way to select one of the two devices is to use something like this:
Driver "evdev"
Option "Name" "CHESEN PS2 to USB Converter"
Option "Phys" "*/input0"
You can get the values for Name and Phys using
cat /proc/bus/input/devices
Permalink
2007-02-20
Posted in Site Updates
at 4:18
Well, I’ve finally got my blog back up. It seems that there’s some kind of bug (impossible to trigger in the default configuration, I’d assume) in the newest version of PHP 5 which causes ./ and ../ includes to fail, and which doesn’t play nice with apache’s DirectoryIndex-based redirection. (the feature that lets www.foo.com load www.foo.com/index.html) WordPress makes use of such things in several important places.
I’ve managed to work around that by using symlinks for the ../ includes and by removing the ./ or ../ wherever I found it, but I don’t know what the security implications of such a change are and the post preview window doesn’t work correctly now.
Any input on the problem and what I did to work around it would be greatly appreciated. Also, if you find any features which are still broken, please let me know so I can add the workaround there too. Finally, if you know how to fix it properly, please let me know so I can forward your message to my webhost.
Permalink
2007-02-17
Posted in Geek Stuff
at 15:10
As programs start to take advantage of the evdev interface for input devices, it’s only a matter of time before you trip over the default permissions. The big problem is that you can’t just edit the default udev rule for /dev/input/event*, because that would also allow any other user on the system to read your keystrokes. Your passwords, for example.
If you’re like me, you’re probably trying to alter the permissions for a device which can’t be used to input sensitive data anyway. For example, a joystick or gamepad. In such a case, the solution is to override the permissions for just that device. In such a case, letting any user read the permissions is actually a benefit, because you could run your media player as a different user than your normal login name (if you’re feeling paranoid) and still control it via whatever joystick-control module it offers. (XMMS, Audacious 1.3 alpha, and MPlayer all offer such an option)
Anyway, down to business. First, find some uniquely-identifying information for your device. If it’s a USB device, that would be your vendor and product IDs, which can be retrieved using lsusb:
ssokolow@darkstar ~ $ sudo lsusb
Password:
Bus 004 Device 002: ID 046d:08d7 Logitech, Inc.
Bus 004 Device 001: ID 0000:0000
Bus 002 Device 015: ID 045e:0026 Microsoft Corp. SideWinder GamePad Pro
Bus 002 Device 014: ID 046d:c00c Logitech, Inc. Optical Wheel Mouse
Bus 002 Device 005: ID 05e3:0604 Genesys Logic, Inc. USB 1.1 Hub
Bus 002 Device 001: ID 0000:0000
Bus 005 Device 001: ID 0000:0000
Bus 003 Device 001: ID 0000:0000
Bus 001 Device 001: ID 0000:0000
ssokolow@darkstar ~ $
Now, udev will normally stop parsing rules when it finds a match, but there is a nice little trick that can be used to alter only the permissions, without having to override the default settings. (thereby ensuring that any changes to the defaults will still apply) In my case, this is what I did…
ssokolow@darkstar ~ $ sudo echo >> /etc/udev/rules.d/10-local.rules << EOF
BUS=="usb", ATTRS{idVendor}=="045e", ATTRS{idProduct}=="0026", MODE:="0644"
EOF
ssokolow@darkstar ~ $
Important: Don’t copy and paste this. My blogging software “helps me” by taking a page out of Microsoft’s book and substituting typographical quotes. (even inside <code> blocks)
For those who don’t know, >> tells the shell to append rather than create if the file already exists and << specifies that we will be using a Here Document. The trick to this is the “:=” assignment operator used for MODE. It tells udev that this assignment should be final without stopping the rule processing. That is, the defaults will be used, but the permissions specified by them will be ignored.
If you need something a little different. For example, giving specialized names to device nodes, or working with a non-USB device, there are also tools to make that nice and easy. Give the following resources a try and you’ll see what I mean:
Happy hacking.
Permalink
2007-02-09
Posted in Web Wandering & Opinion
at 1:45
*sigh* I just spent the last two hours helping my brother customize the look of his MySpace page and my only conclusion is that the MySpace developers are either idiots, or coding with their hands tied behind their backs, metaphorically speaking.
For example:
- MySpace has the worst site design, usability and intuitiveness-wise, of any site I’ve ever visited. Maybe that’s why teens like it so much. Their parents can’t understand a single thing about it.
- MySpace pages aren’t valid HTML.
- MySpace “HTML” is almost devoid of classes and IDs
- You can’t put your styles into the page’s header. You have to stick a style block inside the “About Me” box, leading to what one site calls FOBUC: “Flash Of Butt-Ugly Content”.
- The # symbol is stripped from all inputted text as an only half-effective block against using CSS to kill the adbox. The same purpose has also lead to an inability to attach CSS to IFrames. This prevents you from linking to an anchor and from styling by ID.
- The preview box doesn’t correctly represent certain CSS-based changes to your page.
- The image upload system checks by extension and refuses .jpeg files as “not PNG, JPEG, or GIF” because they don’t end in butchered .jpg extensions.
- More atrocious behaviour that I know I’m sure forgotten about.
…and through all this, they trumpet the ability to customize your own page. Inconceivable. I could do better in my sleep!
Permalink
2007-02-03
Posted in Geek Stuff, Web Wandering & Opinion
at 4:22
Two of my favorite list-form jokes: How to shoot yourself in the foot using various languages, and how different kinds of people in the computer industry go about hunting elephants. Enjoy.
Permalink
