Error 1322

I just spent many minutes trying to figure out why LibreOffice 3.5.4 (the latest version) is giving me this error when I try to install it:

Error 1322.A portion of the path  exceeds the length allowed by the system.

After trying the installer from the root of the C: drive didn't solve the problem, I installed the Microsoft Fix-It, which is an update to the venerable Windows Installer Cleanup Utility. That didn't solve the problem either. I thought it was an issue with that particular machine, but after trying it on another machine (and another version of Windows) I concluded that something must be wrong with the installer.

I searched Google and LibreOffice's bug tracker. Amazingly, I wasn't finding anyone else who had this problem. I even computed the SHA1 hash on the installer on my flash drive and compared it to the SHA1 hash of the installer as downloaded on my hard drive, to make sure the flash drive wasn't corrupting my files.

Finally, I went into μTorrent on my main PC to force it to re-verify the original download. For some reason the program wasn't running. When I fired it up, μTorrent resumed downloading the installer at 81%. Turns out, Sue closed μTorrent because it was interfering with her Hulu streaming.

Mercurial does not support HTTPS SNI

If you read my blog for content, please skip this entry, as it will disappoint. I am writing this entry so it's indexed by Google. I spent hours yesterday struggling with this issue, and various searches on Google were not fruitful. I hope this helps someone else.

I wanted to set up Mercurial repositories on my server using HTTPS, using a StartSSL certificate. But when I tried to check out a repository using TortoiseHg or the official 'hg' client, I would get this error:

SSL3_GET_SERVER_CERTIFICATE: certificate verify failed

Whereas if I browsed to the same URL using any web browser, the browser would have no complaints about the SSL certificate.

Turns out that the Mercurial does not support Python 3 yet, requiring Python 2. And Python 2 does not support Server Name Indication, an feature of SSL/TLS that allows the web server to send an SSL certificate appropriate to the virtual host requested. Without SNI, my web server was sending its default SSL certificate, which did not match hg.qnan.org.

The solution for me was to configure my web server to send the Mercurial SSL certificate to the default virtual host, since (hopefully) 'hg' will be the only client accessing my webserver without SNI support. Alternately, you could configure your web server to use a custom path for the WSGI script rather than its own subdomain/vhost. Then the default SSL certificate should work fine, and you'd point people to the equivalent of qnan.org/hg/<repo>.

Private Mercurial repositories

I got tired of the ad-hoc way I share my files between my personal laptop, my work laptop, my desktop PC, my Linux server,  and the teacher workstation at the private school where I'm teaching summer classes. In addition to not always having access to the files I want, I also wasn't sure which version is latest.

I am familiar with Dropbox and other cloud solutions, but I like having more control over my data. And, my company's firewall blocks them.

This weekend I've set up private Mercurial repositories through my web server. Now the master copy of my files is on my Linux server, and all my computers can sync from it. Plus, my files are now version-controlled. I got a SSL certificate from StartSSL, a great company that's been providing free, quality certs for a long time.

(Needless to say, I comply with the letter and the spirit of my company's data security policies. I push to my server only files that are my own and have no connection to my project.)

For professional Mercurial and Git hosting, I recommend Bitbucket. They offer free repositories for open-source projects, and even free private repositories for up to 5 users.

Philip's LabVIEW Quick Start

I created a one-page guide to LabVIEW, a powerful graphical programming environment. The direct beneficiaries are high school intern candidates for Rockwell Collins, but I hope anyone who's interested in LabVIEW will benefit.

Hellbender

I will always have a fond place in my heart for the PC game Hellbender.

While my middle-school peers were forging relationships and social skills, I would play Hellbender with an acquaintance over a direct telephone connection. Yes, dear reader, I would put in his home phone number into the game, and my PC would use its built-in modem to dial his number. His computer would be listening and would accept the connection. Then we'd play.

The game came on the official install CD of Windows 95. To this day, it's available for download from Microsoft. (Strictly speaking it's the demo, but the demo is all I know.) The entire thing is just 13.5 megabytes!

What ancient games are dear to you?

Dwolla, please resolve the Fee Dilemma for us

A letter I wrote recently to Dwolla. For background, Dwolla is an up-and-coming payment network that competes with credit cards and Google Wallet. When paying someone by smartphone app (and probably via the web interface), the payer has to resolve the Fee Dilemma™: does the 25-cent fee come out of the payer's balance or from the amount being transferred (a-la PayPal)? I argue that this choice is harmful.

Hello. I'd like to suggest for Dwolla to make a decision about whether the sender or the receiver eats the 25-cent fee, and to remove that decision from the user.

Right now, as an IT consultant, I am pitching Dwolla to a local retailer. Additionally, starting next month, my fiance will accept Dwolla as a vendor at a farmer's market.

In both cases, the businesses have to figure out what to do about the 25-cent fee. Should they have a stated "policy" about it? What should they say when a customer asks? And of course once they commit to one way, it might make someone unhappy if this is ever changed. And what if a business next to them has the opposite policy? Credit cards leave you no dilemmas during a transaction. I think the Fee Dilemma is a hurdle for adopting Dwolla.

I think no matter how YOU would resolve the dilemma, merchants would be happy about it. Whether the customer or the merchant eat the fee, it would be a consistent experience and no one has to ***think*** about it at every transaction.

My personal preference would be for merchants to eat the fee. It's consistent with credit cards' fee structures. It also encourages more regular people to get a Dwolla account if it's "free" in every sense. I can't imagine a business having a policy that the customer should eat the fee. So what's the use case for that? If it's for person-to-person transactions (such as paying back a debt without having the lender lose value), then how about limiting the option to person-to-person transactions? Dwolla already knows whether the recipient is a person or a merchant.

Thank you for reading.

Why SiriusXM satellite radio is not for me

For a long time I've flirted with getting SiriusXM. Satellite radio appeals to me, especially because I drive about an hour and a half a day. I've even had a subscription for about a year in 2005. But now I've definitively decided against it. I want to share with you my reasons, to save you research time.

1. Low sound quality and getting worse; SiriusXM keeps adding channels to the same bandwidth. These days it sounds worse than FM radio.
2. SiriusXM's channel lineup doesn't match my interests. There are about a hundred (no exaggeration) sport channels, two Christian channels and three channels dedicated to ONE band each, yet there are no foreign channels beyond Latin and Canadian. I wouldn't mind the hundred channels that I'll never listen to, except that their existence lowers the sound quality of other channels.
3. SiriusXM wants to keep everything proprietary, including the signal protocol, wiring and adapters. It's surprisingly difficult and expensive to integrate the radio (and especially the mini-tuner) into any setup. For example, to integrate with my car stereo I need this $51 piece of junk: <http://www.amazon.com/Audiovox-CNP2000UCA-Direct2-Main-Kit/dp/B003O86GZS>. Read its reviews. For home/office listening, AUX-IN is the standard interconnect, unless you get a $400+ receiver with built-in XM support. If you want a digital interconnect like Toslink, forget it. (Though with the low sound quality, why would you anyway?)
4. Like Sprint and Verizon, SiriusXM locks one's subscription to the hardware receiver. Switching to another receiver incurs a fee, and a "lifetime" subscription is not really for the lifetime of the customer -- SiriusXM will kindly let you move it to a new device about three times. Then you're SOL.
5. To make up for the above, SiriusXM has created a Mini-Tuner, equivalent to a SIM card for phones. It's a small block that pops into a receiver to authenticate you. This lets you have multiple receivers wired up at home and in car, with just one subscription. However, for some reason SiriusXM failed to capitalize on this idea -- I can't tell if it's because SiriusXM prefers for people to have multiple subscriptions, or due to pressure from MPAA, or general incompetence. Almost no receiver supports the mini-tuner. As a result, if you want the extravagance of having a receiver in your car and in your home or office, you need two separate paid subscriptions.

The future appears to be headed toward Internet streaming. I much prefer the satellite solution, since decoding a satellite signal doesn't clog up Internet pipes, but SiriusXM has firmly killed the satellite option for me.