If I was at Google, I think my 20% project would be adding voice support to Google Calendar. It would be pretty sweet to be able to press a button on my phone and say “February 3rd, 3PM, doctor’s appointment, remind 1 hour”. It would read back what it heard and you’d say “confirm” to set it.
I guess it would be like Jott but free, and not requiring phone calls. Your voice would be HTTP POST’d up to the server or something like that.
I realize I’m probably way late to the game here, but for whatever reason I did not notice this problem until today. Comcast has started responding to bogus DNS requests, sending people to some crap-tastic search portal.
Up until now Comcast hasn’t given me too much to complain about. The service is reliable, the speed is good, they usually get techs out when needed. But this right here is despicable Internet-breaking behavior. I hope it backfires on them in a very big way.
They do offer a method that supposedly allows you to opt-out, I’m waiting to see how that works out.
The spreadsheet that manages to turn this CSV field:
"Foo \"Bar\""
into:
Foo \Bar\""
??? I guess the “standard” way to quote a ” is with another “, but even so, how did it manage to mangle the text like this?
Argh. I see that Wordpress and/or Firefox smarted up my quotes. I just can’t win today.
T-Mobile made the unfathomable choice to discontinue e-mail support, instead requiring users to go to live chat. However, you wouldn’t know this when visiting their support page:
Chat with Customer Care Specialist >
Fill out a quick form to chat live with one of our specialists. If all agents are busy, you can even send us an e-mail instead of waiting.
So, I typed up a nice long descriptive email, something that they would need to read and investigate before responding. But because T-Mobile doesn’t do email support any more, I’m being forwarded to their “instantservice.com” provided live chat service. Of course, they’re not going to be able to help, because they won’t have time to investigate the problem. Brilliant.
They keep calling our office, every line we have. I guess they’re some anti-fraud service, but they use telemarketing, which makes them scum. Double scum for trying to reach us like this four times today. (Of course, when you pick up the line, there’s nobody on the other end, so it’s completely ineffective anyway.)
(AKA: MeucciSolutions, for the Google.)
A pox on Apple MagSafe designers. MagSafe is pretty awesome in general, but Apple uses the same plug for both their 60W and 85W power supplies. Unbeknownst to me, I had been using a 60W power supply from a Macbook to power my MBP. It wasn’t until I saw scorch marks on the power cable that I realized something was seriously wrong. Sloppy design.
First, Paypal wouldn’t let Esther add her credit card to her account. She and I both have the same card number (of course).
So, I called Paypal. They have one of those horrible voice activated systems. They ask you to enter or say your phone number (even though you’re calling from a phone and they could use ANI..). If there is ANY noise in the background, the system believes you’re entering a phone number verbally.
When I finally got the system to take my number, it said it did not recognize it. But when I was transferred to a person (by saying “Customer Service” multiple times, because that’s not an option on the menu, of course!) he knew exactly who I was and asked me to verify my account.
Finally, I’m told that it’s simply not possible to add the same account number to two Paypal accounts. So I guess we have to share one Paypal account (and thus eBay account?) to pay for things. How dumb is all of this?
I’m seeing some funky “new” (to me) behavior that I’m having trouble tracking down. Maybe y’all have seen it before. Using kernel 2.6.18-6-686 (debian etch), I can have a shell script open in vi, and suspend vi to run it. But on 2.6.26-1-686 (debian lenny) I get this error:
host:~/dir# ./shellscript -foo
-bash: ./shellscript: /bin/bash: bad interpreter: Text file busy
If I exit out of vi I can run the script just fine. I can also run the script with “sh shellscript”. strace reveals that the failure is happening super early on:
host:~/dir# strace ./shellscript -foo
execve("./shellscript", ["./shellscript", "-foo"], [/* 19 vars */]) = -1 ETXTBSY (Text file busy)
It looks like the kernel must be checking for exclusive advisory locks before proceeding. I have checked around Google and I see others have had the same trouble, and they’re always told to make sure the file isn’t open by some other process. But I can’t find where new behavior was introduced. Best I can gather, it’s just accepted as the norm now. Seems awfully weird to me.
UPDATE: As noted in the comments, the kernel isn’t doing flock before execve. It’s just preventing you from running commands if the file is open for writing. It’s old behavior. I only saw it now because old nvi didn’t keep the write file handle open (or at least, not in the same way) and new nvi does.
