 |
 |
|
|
|
|
|
|
I apologize for letting n8gray.org fall off the planet for so long. My server got migrated without warning and events in real life overtook me as well. In any case, the site’s back up now and I hope everything’s working again. Please let me know if you find something broken! I get a lot of mail from people wishing Forget-Me-Not worked in Leopard. For them, I’m happy to report some hopeful news. A while back I was contacted by a senior Apple representative who expressed interest in helping me revive Forget-Me-Not. In the end, after consulting with Apple engineers, it was decided that the way to go forward would be to provide a new API suitable for FMN. This conclusion was slightly surprising to me, because it seems like the API we’re using should be suitable, but then again I’m not an Apple engineer. In any case, if you want to revive FMN, please file a bug report at http://bugreport.apple.com (requires a free ADC membership) and say you want to support the enhancement in bug report 6018339. You don’t have to say much of anything, just make sure to reference that bug number — Apple considers duplicate bug reports “votes”, so you want to make dead sure they know it’s a duplicate. Before you get your hopes up, please understand that this contact was made back in the early summer and nothing much has come from it. Hopefully a few “votes” for the issue will get the ball rolling again. In bygone days of yore I wrote a rather angry post about my Edirol PCR-30 midi controller, whose key contacts failed after essentially zero use. In my post I mentioned e-mailing Roland support about the issue but I got no response, so I just let it drop. After all, the thing was out of warrantee and I had other stuff to deal with. Last week I randomly decided to google around and see if anybody else had found a solution to the problem. Well, the results of the search were pretty interesting. The problem was ubiquitous — tons of folks with PCR controllers built around the same time as mine reported it on forums and review sites. (This was not the case when I first discovered the problem, by the way.) Some people reported that opening the keyboard and rubbing the key contacts with a stiff pencil eraser brought them back to life, which got me thinking. These things are just electrical contacts, right? Why not put conductive paint on the contacts? That should get them working again for good! So I did a goog for “conductive paint” and one of the first links that came up was this one. And hey, can you believe it? They sell a “Rubber Keypad Repair Kit”! (MG Chemicals, cat. #8339.) Hallelujah, exactly what I wanted! It’s actually designed for repairing remote controls, but midi controllers work on the same principle. I decided to order one and gave it a shot. (BTW, my experience with Action Electronics was very good.) How did it turn out? Well, it was good but not great. The kit did, in fact, manage to revive almost all of my keys. Why didn’t it work for all of them? Well, each key actually has two contacts underneath, and a bit of experimentation revealed that the time interval between closing the two contacts is quite important for the keyboard performance. (I assume this is how they sense the velocity with which you struck the key.) If they close in the wrong order, for example, no note is triggered. I think that the added thickness of the paint (which didn’t always go on particularly smoothly) caused timing problems with some of the keys, perhaps even causing the contacts to close in the wrong order. I tried sanding off the paint and repainting the bad keys, but it never quite worked for all the keys. I tried to live with this for a while — it was, after all, a big improvement over the keyboard’s previous condition. But the fact is, there are times in any musician’s life when only D# will do, and using D or E as a workaround just doesn’t cut it. Finally, I decided that it couldn’t hurt to call Roland and try talking to a live person. After some bouncing around in their phone system (boy do they have awful muzak when you’re on hold!) they actually gave me approval to send in my keyboard! This despite it being many years out of warrantee and my admission that I’d tried to fix the problem myself! I was a little bit afraid that their technician would investigate the problem, find the contacts covered with conductive paint, and stamp DENIED on my RMA ticket with an evil laugh, but no such thing happened. I suspect they just swapped out the whole keyboard assembly without ever uncovering my handiwork — why bother removing all the keys when this is a known defect? So after 3 days I had my PCR-30 back in fully working condition for no cost other than the time and gas required to drop the thing off at the nearby Roland factory and pick it up again. Kudos to Roland for making good after all these years! So anyhow, the moral of the story is that talking to people by phone works better than e-mail, at least if those people are Roland employees. Or maybe it’s that conductive paint doesn’t work as well as you might hope. This took me waaaay too long to figure out. A while back I set up printer sharing (with browsing) on my Ubuntu-based server. My Mac (running Tiger at the time) found the server just fine and it all just worked — I couldn’t believe how simple it was! But then I upgraded to Leopard, and among the (numerous) casualties was the shared printer. No matter what I tried, what protocol I used, what driver I used, the shared printer just wouldn’t work. After hours of banging my head against the keyboard I let it go. About 9 months have passed, and today I decided to take one more swing at. Can you believe it? I found the problem! There were two problems really. First, to access a shared printer on another machine, you have to turn on print sharing on your machine. This defies all logic, but there you go. Second, for some utterly inscrutable reason Apple decided to *dis*able the CUPS browsing protocol, leaving only Bonjour browsing working. ???? Stupid. Stupid. Stupid. It’s as if they said “let’s make sure Mac users will have lots of trouble printing to Linux servers, that’ll improve our customer satisfaction!” To fix this lameness, do the following: cupsctl BrowseProtocols='"cups dnssd"'
Combining these two tips, the shared printer finally appeared in the “Default” pane of the new printer dialog and printing to it just worked. Hopefully Apple makes this more sensible in Snow Leopard… Oh Mama! Another Backup Bouncer post! You might think that I, the author of Backup Bouncer, the crusader for end-user verification of backup tools, would have run BB on Time Machine at some point. If so, you have seriously underestimated my laziness. But this morning I got an e-mail from a user asking for help testing TM with BB, and this finally spurred me to do the test myself. Here’s how you test Time Machine with Backup Bouncer: $ mkdir ~/bb # We need to trick BB into thinking this is a volume it created $ touch ~/bb/bbouncer-vol $ sudo bbouncer create ~/bb # Now do a Time Machine backup and wait till it's done $ mv ~/bb ~/bb-orig # Now restore the ~/bb directory from Time Machine. # Try not to catch SPACE MADNESS!!! $ bbouncer verify -d ~/bb-orig ~/bb On my Leopard 10.5.3 machine here’s what I get with BB 0.1.3: Verifying: basic-permissions ... ok (Critical) Verifying: timestamps ... ok (Critical) Verifying: symlinks ... ok (Critical) Verifying: symlink-ownership ... FAIL Verifying: hardlinks ... FAIL (Important) Verifying: resource-forks ... Sub-test: on files ... ok (Critical) Sub-test: on hardlinked files ... FAIL (Important) Verifying: finder-flags ... ok (Critical) Verifying: finder-locks ... ok Verifying: creation-date ... ok Verifying: bsd-flags ... FAIL Verifying: extended-attrs ... Sub-test: on files ... ok (Important) Sub-test: on directories ... ok (Important) Sub-test: on symlinks ... ok Verifying: access-control-lists ... Sub-test: on files ... ok (Important) Sub-test: on dirs ... ok (Important) Verifying: fifo ... FAIL Verifying: devices ... FAIL Verifying: combo-tests ... Sub-test: xattrs + rsrc forks ... ok Sub-test: lots of metadata ... ok The only annoyance is that hardlinks aren’t preserved, but that’s not surprising considering the way hardlinks are used internally by TM to prevent wasted space. (I should point out that the hardlink failure here is not the same as the Apple rsync one I mentioned earlier today, and it’s not nearly as bad.) These results are not perfect but I would have no problem recommending TM backups to any less-than-hardcore user. I just released Backup Bouncer 0.1.3. I’ve changed the output format to print the “priority” of a test along with its outcome, which hopefully should clear up some confusion among less experienced users. On a tip from Patrick Power I’ve added a new test that combines resource forks and hard links. Unfortunately, Apple’s rsync fails this test in OS X 10.5.3: ------------------ rsync-apple ------------------ Verifying: basic-permissions ... ok (Critical) Verifying: timestamps ... ok (Critical) Verifying: symlinks ... ok (Critical) Verifying: symlink-ownership ... ok Verifying: hardlinks ... ok (Important) Verifying: resource-forks ... Sub-test: on files ... ok (Critical) Sub-test: on hardlinked files ... FAIL (Important) Verifying: finder-flags ... ok (Critical) Verifying: finder-locks ... FAIL Verifying: creation-date ... FAIL Verifying: bsd-flags ... ok Verifying: extended-attrs ... Sub-test: on files ... ok (Important) Sub-test: on directories ... ok (Important) Sub-test: on symlinks ... FAIL Verifying: access-control-lists ... Sub-test: on files ... ok (Important) Sub-test: on dirs ... ok (Important) Verifying: fifo ... ok Verifying: devices ... ok Verifying: combo-tests ... Sub-test: xattrs + rsrc forks ... ok Sub-test: lots of metadata ... ok If you add a resource fork to a file that’s hardlinked to another file then only one of the files gets copied. Some of the changes in BB 0.1.3 were a bit invasive and Bash is not the greatest of programming languages, so please keep your eyes open for bugs. If you see something in your results that doesn’t make sense just let me know. A friend recently pointed out that BB gets some love on the Carbon Copy Cloner product page. This is quite satisfying to me, since my indirect goal with BB was to get it into the hands of the folks making the tools. The primary goal was always to let users validate backup tools on their own, but it was always clear that this would end up putting pressure on the tool makers. When a user comes to you and says, “your tool fails backup bouncer test foo,” you either pay attention or lose a customer. This is very empowering for end-users, but one can see how it has the potential to irritate tool developers if they disagree with BB’s test methodology. My Popcorn Hour PCH A-100 media streamer has a mipsel architecture, which led me to wonder, “what the heck does mipsel mean anyway?” As it turns out, the difference between mips and mipsel is that mips is big-endian and mipsel is little-endian. Mystery solved. Wisdom from the mouth of Amaya on a trip to McDonalds (even latte-liberals need fast food every now and then), where she had a Happy Meal: I think the grownup meal is called a Sad Meal. It’s sad because it doesn’t have a toy. Mind you, she was completely serious about this statement and delivered it with a totally straight face. Had my mouth been full of soda it would have come shooting out of my nose for sure… I just upgraded the blog to Wordpress 2.5.1. I did some testing, but please let me know if anything’s busted. |
|
 |
 |
This, no doubt, is due to the hackery involved to make