Recently, I learned how broken the dispute resolution process is with Bank of America. I asked them to send me the receipts for 5 recent charges from the same Mexican Food place across the street from me. I love Mexican food, but there’s no way I could have eaten 5 meals in a row from this place (esp when I wasn’t even working from home that week), so something was awry.
Herein lies the rub. If they send me the receipts (which include signatures), I can no longer dispute the charges because now I’m in possession of the sales receipts. Even if the signatures on the receipts clearly show an invalid signature, I have forgone the ability to issue a charge back. I asked the customer support if they could visually verify that the 5 signatures closely matched all my other signatures, but that was impossible. They didn’t have the ability to view the receipts.
I find this totally absurd. Granted, using a signature as a form authorization is incredibly fallible, the fact that it’s not even relevant when disputing a charge, raises the question why do we even need to sign the receipt at all? The back of my credit card is not signed, so that means that they would have been required to view a valid form of identification, which obviously wasn’t the case and is rarely ever the case. I suppose it’s all a moot point. BofA reversed the charges regardless, which was nice of them. I would have just preferred a more thorough process.
Recently, I moved one of my SVN repositories onto a new server. Everything seemed fine until I tried to commit.
SVN complained:
svn commit . --message ‘….’
svn: Commit failed (details follow):
svn: Can’t close activity db: Error string not specified yet
And the server logs show:
[Wed Dec 03 22:53:20 2008] [error] [client 207.7.129.212] Could not create activity /svn/!svn/act/cc8c14b8-904b-4438-872d-e129baae67bb. [500, #0]
[Wed Dec 03 22:53:20 2008] [error] [client 207.7.129.212] could not close dbm files. [500, #89026]
[Wed Dec 03 22:53:20 2008] [error] [client 207.7.129.212] Can’t close activity db: Error string not specified yet [500, #89026]
Turns out, DAV keeps some cache files around in your SVN ‘dav’ directory. Removing all the ‘activ*’ files solved my problem.
And run compiz-check to see if there are any issues with your setup/hardware.
To get the features of OSX’s Docker, you’re going to want to install Cairo-Docker. Cairo-Docker is actually even MORE incredible than the traditional Docker, allowing for plugins and customization to the Nth degree.
I was recently contacted by someone who got stuck setting up Starling and realized that the documentation is relatively sparse on setting up Starling. The process is easy once you know how Starling works on the inside, but not looking in.
To get started, I will assume you have ruby and ruby gems already installed. This will depend on your flavor of distribution, but should not be difficult and come standard on every modern version of Linux I’ve used.
run:
gem install starling
Create the Starling queue directory in /var/spool/starling
Start staring with these minimum set of arguments:
Also, note that Starling creates a queue file for each key verbatim. So if a key is, ‘namespace/something’, then Starling will fail to do the set if the ‘namespace’ directory does not exist under the /var/spool/starling directory. You can also just not use ‘/’ in your keys.
Also, note that Starling does not automatically purge the queue files after it rotates them. You’ll want to cron a job to run periodically to delete them. We run this nightly to purge files not accessed in 4 days:
find /var/spool/starling/ -type f -atime +4 -delete
by creating a file in /etc/cron.daily/starling with those contents.
All that being said, we’re still very happy with it and process about a million jobs a day.
Please let me know in the comments if your still having problems!
VMWare can be a real bore to upgrade when there are major kernel updates. Very often, the supplied modules with VMWare will not compile.
For example, I got this today:
CC [M] /tmp/vmware-config0/vmmon-only/linux/driver.o
/tmp/vmware-config0/vmmon-only/linux/driver.c:197: error: unknown field ‘nopage’ specified in initializer
/tmp/vmware-config0/vmmon-only/linux/driver.c:198: warning: initialization from incompatible pointer type
make[2]: *** [/tmp/vmware-config0/vmmon-only/linux/driver.o] Error 1
The solution is always to use the non-standard installer available at:
http://groups.google.com/group/vmkernelnewbies/files?pli=1
Download the latest vmware-any-any-update tarball, decompress it, and run the included runme.pl script inside. It works just like the vmware-install.pl script distributed with VMWare, but this version includes patches to make everything run without a hitch.
The memcache protocol requires that all lines in the server response end with CRLN (\r\n). The Starling server doesn’t strictly obey this for the STATS command. The fix is trivial and the author has been notified of the fix.
Edit lib/starling/handler.rb and add the following gsub right before .freeze in the STATS_RESPONSE:
%sEND\r\n”.gsub(/\r?\n/, “\r\n”).freeze
And the same for QUEUE_STATS_RESPONSE:
STAT queue_%s_expired_items %d\n”.gsub(/\r?\n/, “\r\n”).freeze
add to del.icio.us
add to technorati favs
email this