I really wish a bank supported me giving them a public cert to encrypt use for all communications to me — and published a public cert that I could use to validate all communications from them.

They all handle SSL in the browser and they all support some kind of email-based notifications.

Then, ideally, I could configure my mail client to binfile anything from their domain that isn’t signed with the right key and encrypted to me.

On the other hand, it may be dangerous to stop training people that clicking on a link in email is never a good idea.

A clear improvement, however. I particularly dig the new search. Once I figured out I could configure the Archive function to put archives from all my accounts into my local Linux box’s IMAP server I also liked the new Archive function. It nearly matches the system I maintained by hand anyway (manually periodically moving a bunch of mail into suitably named folders on my local Linux box).

Also nice is the “smart” Inbox — a feature I’ve liked in Mail.app and kind of missed in Thunderbird.

I’m not yet sure if I like the rest of the UI changes but I’m going to try them out for a bit before trying to reconfigure them back from whence they came.

Suppose further that you have purchased Cineform Neoscene to transcode that video into a nice-to-edit format.

Further suppose that this workflow was working fine on your old Vista 64-bit machine.

Now, you’ve installed CS4, Cineform, and transcoded some video. Then you import it into Adobe Premiere Pro CS4 and prepare to edit!

And PPro crashes. With an error referring to Timecode.cpp. Around line 930.

You are sad. You scour the entire internet in tens of milliseconds and find several posts talking about crashes in that location, but they have nothing to do with importing files created by NeoScene.

You try to play the files in Windows Media Player and they do not crash but they also are not playing at the right speed. Ah ha! That does rather smell timecode related.

Cutting this story short, install Quicktime 7. This workflow requires Quicktime to be installed or crazy broken things will happen. The requirements page for NeoScene does not talk about needing Quicktime on Windows.

With Quicktime installed, you re-run NeoScene and birds burst into song. Or rather, the output files are right and can play back in Quicktime and WMP. They can also be imported into PPro without mysterious crashing.

The day is saved.

I decide to do a clean install. The Windows 7 installer works great right up until it won’t accept the product key that came in the package. The “Upgrade” Win7 cannot install to a clean disk and then take the Vista product key to satisfy the upgrade. It’s not even clear how to get a clean install of Win7 now, since it seems the ONLY valid path is to have a copy of Vista installed already. Furthermore, it puzzles me why Win7 Pro Upgrade can’t tell me this instead of offering to do a clean install and then failing 45 minutes in.

It does work with a clean, unactivated Vista install immediately followed by a Win7 Pro upgrade. This was a needlessly frustrating introduction to Windows 7.

Once it is installed Win7 seems nice enough — an incremental upgrade from Vista. It’s not at all clear why Microsoft decided to inconvenience such a small population of people. The vast majority of users will get Win 7 with a new machine purchase. Very few, relatively, will buy Win 7 as an upgrade, but those are exactly the users Microsoft can least afford to make frustrated. These are the users most likely to be the people advising their friends and family about what to buy.

I wonder if this letter is entirely legitimate since it seems pretty desperate to convince me to sign up for a “free credit monitoring” period — but that doesn’t seem like a useful response to a single card number being compromised. Furthermore, I’d expect that the credit card issuer was also notified and their usual response to this kind of thing is “cancel all the cards and issue new ones” and that didn’t happen. Though maybe they didn’t bother because that card had already expired by the time “Network Solutions LLC” reported the breach.

Nevertheless I’m looking over statements since that date more carefully than usual to see if there’s any fishy transactions.

It’s not the same card as the one a credit card provider recently replaced mysteriously due to “a security breach with a merchant” that they naturally didn’t explain. That is the kind of behavior I expect from a bank.

I suspect that credit card companies aren’t interested in increasing the security of cards because paying for the fraud is cheaper than the lost sales due to lower convenience.

Of course, every time I get a new card number I would have to go change the umpty-jillion places that have the card number for automatic billing if most of those places didn’t have single-merchant numbers. This is a case where the issuer with the capability to issue single-merchant card numbers wins. I’ll probably switch the rest of them over next time the card number from the company that doesn’t support single-merchant numbers gets compromised.

The upgrades from Ubuntu v.older to 9.04 went quite smoothly on every machine including the ones where I had to do several stepped upgrades since on various machines I skipped one or more upgrades prior to 9.04.

Rather than return to my old ways of just hosing packages (and, worse, “setup.py develop” symlinks) into /usr/local I’ve decided to use python-virtualenv to create some non-root-owned Python environments to work on my various Python-y apps. The main difference to me is being able to keep things I’m working on separate from one another.

We’ll see how it goes.

I’m afraid all these years of using package-managed software has made me soft — now a piece of software not having a nice package means I need to think a bit harder about if it’s worth dealing with the hassle of having that software outside of the package manager. (That applies to when I’d like to be using a more recent version of the package, too, though generally on Ubuntu I run into that a lot less frequently than I did on Debian.) I have mixed feelings about setuptools and easy_install.

I am pleased that now mod_wsgi is in a package so I can switch to that version rather than the one I installed by hand. mod_wsgi was worth it to install by hand to use until there was a nice package available. It’s Just Better than my previous mechanisms for running WSGI apps in, under, or behind Apache.

Prior to today every time I took the time to try and update the source tree on Sourceforge I ran into a snag such as “Sourceforge CVS is unavailable.” Months ago, when I tried to migrate from CVS to SVN on Sourceforge I ran into errors. I didn’t even try to investigate what went awry as I was low on patience and time.

As a result, my own tree (first in Perforce and now in Subversion) has gotten pretty out of sync from that tree. I decided to try GitHub and try using Git for something “real” — so I’m going to move Singleshot’s source to GitHub and then push all my changes to there.

I followed (mostly) the steps from How to export revision history from mercurial or git to cvs which describes how to use the git cvsimport command to pull Singleshot’s revision history from its Sourceforge CVS repository, testing making a tiny change to a README, and pushing that change back to the Sourceforge CVS tree.

(After backing up the source tree on Sourceforge using rsync.)

% export CVS_RSH=ssh
% git cvsimport -d :ext:xythian@singleshot.cvs.sourceforge.net:/cvsroot/singleshot -C test1 \
    -r cvs -k -A /home/fox/src/singleshot-import/authors.txt  singleshot
Initialized empty Git repository in /home/fox/src/singleshot-import/test1/.git/
[longish pause]
Counting objects: 561, done.
Compressing objects: 100% (502/502), done.
Writing objects: 100% (561/561), done.
Total 561 (delta 317), reused 0 (delta 0)

(Some poking around to see if things look reasonable, making a small change to the README, commiting it first to the git repository and then back to Sourceforge using git cvsexportcommit.)

Then I pushed the whole thing to a GitHub tree:

http://github.com/xythian/singleshot/tree/master

% git remote add origin git@github.com:xythian/singleshot.git
% git push origin master

That was pretty straightforward and appears to have worked.

My plan is to merge my changes into the out of date tree and then push the new code to GitHub. If it all works out I’ll probably indicate that the Sourceforge project is defunct there and host the code on GitHub henceforth.

It rapidly became clear that I was going to want a layer on top of the library to make interacting with it from Python more palatable.   I switched to Pyrex, since I wanted to write that wrapper in Python (or something Python-like) rather than building a straight-C wrapper so using SWIG would continue to make sense.   SWIG’s big benefit in my mind over Pyrex is easy support for more languages and better tools for defining straight wrappers.  I wasn’t going to get "free" use in other languages and it wasn’t going to be a straight wrapper now but rather a module that exposed the functionality of libyahoo2 to Python.

I kept the callbacks.c I had defined but started migrating the definitions to the Pyrex file as I implemented.  This way my library would continue to link without complaint about functions I didn’t have yet.

Following the usual pattern for Python bindings to libraries that need wrappers to be more Pythonic, I planned to have a ‘yahoo2′ module in Python and a ‘_yahoo2.so’ extension module.  The _yahoo2 module is written in Pyrex.

libyahoo2 appears not to adhere to the documentation it defines.  It’ll call ext_yahoo_remove_handler with a tag that was never returned by ext_yahoo_add_handler… (0).  It looks like an undocumented (that I found) part of the charter of ext_yahoo_add_handler is not to add a given handler more than once.

This also made defining the callbacks the way libyahoo2 expected easier.

D’oh, I got it far enough along to get this:

libyahoo2.c:620: debug: Key: 4 Value: Yahoo_Messenger
libyahoo2.c:620: debug: Key: 5 Value: hodorbot
libyahoo2.c:620: debug: Key: 14 Value: This version of Messenger expired on April 2, 2008. Please upgrade now to the latest supported version: http://messenger.yahoo.com Learn more: http://messenger.yahoo.com/eol
libyahoo2.c:620: debug: Key: 15 Value: 1225167367
libyahoo2.c:620: debug: Key: 97 Value: 1

I’ve learned what I wanted to, so instead of seeing if a more recent libyahoo2 than what’s in Ubuntu works (> 0.7.5+dfsg-3), I’m just going to call it here.  I’ll post it in case someone can learn something useful from it.

You can pull a working repository with a command like:

git clone http://notes.xythian.net/media/2008/10/pythonlibyahoo2.git/ mydirectory

There’s three files that do anything:

• yahoo2.py – wraps some of the lower level details from the Pyrex layer, including exposing the IO bits as an asyncore dispatcher
• _yahoo2.pyx – is the binding
• callbacks.c – exists to have empty functions defined to satisfy the linker until those have implementations in the Python binding

Not much works, really; there’s implementations of connect and async_connect, but only async_connect is called by libyahoo2 before it gets far enough along to not log in with the error message above. There’s a wrapper for setting the log level (which was key to discovering the above fact…).

This is a typical definition of one of the library callbacks:

cdef public int ext_yahoo_connect_async(int id, char *host, int port, \
  yahoo_connect_callback callback, void *callback_data):
   cdef ConnectionHandle handle
   handle = ConnectionHandle(id, host, port)
   handle.connect_callback = callback
   handle.connect_data = callback_data
   handle.async_connect(callback, callback_data)
   HANDLER_MAP[id].connections.append(handle)
   MANAGER.add(handle)
   return handle.fileno()

ConnectionHandle is an extension class which wraps a Python socket object and can make the callbacks the libyahoo2 IO layer expect.   MANAGER is the connection manager, which is implemented in the higher level layer (yahoo2.py) so it could be replaced with something that interacted with a GUI event loop.

I’m probably done with this for the forseeable future and hope publishing it along with a git repoistory may allow someone to build on or learn from what I’ve done.   I stumbled upon Cython while working on this, but didn’t want to derail any progress to something working by playing with it.

So what did I learn?

• Write toy bots against open protocols with existing libraries in your language of choice, such as XMPP, lest your project get hijacked working on a binding rather than the toy.
• Pyrex is pretty nice for building wrappers that have more meat than a typical SWIG binding.
• Cython is probably worth checking out.
• git is worth playing with more

VirtualBox 2.0.0 is as smooth to install on WIndows as the 1.x build I tried on the Mac was (I’ll try 2.0.0 on the Mac soon) and either adds a bunch of cool features or I noticed some features that were in 1.0 the first time with 2.0. I know seamless mode is new in 2.0, but I don’t know if the “headless mode” (= run as a daemon and display only as an RDP server; not interesting on my Windows box but quite interesting for Linux) is new or not.

“Seamless mode” is not as seamless as Unity mode: the tab order (and task bar) do not show the virtual machine’s apps as first class windows. Instead, the entire VM appears to be a single app to Windows not unlike running in full screen mode. It’s essentially as if the desktop background of the VM was replaced with an transparent texture, so I can see all the windows apps wherever the desktop would been visible. It’s handy but a little confusing. Also the system menu bar is considered a window and thus shows up at the top of the Windows desktop machine (compared to Unity mode, where it can be turned off entirely and replaced with Fusion-provided navigation functions). It’s not quite fair to compare Fusion running Windows to VirtualBox on Windows running Linux since it may be that “seamless mode” is more seamless with Windows guests (and, of course, VirtualBox is free for personal use and Fusion isn’t, but Fusion is cheap enough to be essentially free for the sake of a tool I use as much as virtualization).

It looks like Fusion 2.0 is nearing release (as well as VMWare Workstation 6.5, which finally adds support for Ubuntu 8.04 guests — this lack in Workstation 6.0.4 is how I ended up playing with VirtualBox in the first place).

I suspect VMWare is going to remain the virtualization tool I reach for “in anger” (especially once Fusion 2.0 and Workstation 6.5 and Server 2.0 finally all ship, which will give me good solutions for running the same virtual machine images on any machine I might desire).

On the other hand, maybe not, because I’m not sure I really want to know where that time just went. It would be a pretty branching tree, though. I should know better than to click through links to Wikipedia — it really doesn’t matter where the link goes. They’re all dangerous. Howstuffworks, too. And if any of the Wikipedia articles link TO Howstuffworks (or visa versa) then it really is hopeless.

And THEN, you get a LOT of people to install it (or Wikipedia to run it on their access logs) and let people surf through the trees starting from some arbitrary page. That would be cool.