A little while ago I bought Adobe Creative Suite CS4 Design Standard so that I could use Photoshop and Acrobat Pro on my Windows 7 machine (which I use for photo editing and organizing). Installing, registering, and activating the 64-bit version was painless, except for one problem: whenever I launched Acrobat, it would work fine for a few seconds until I was interrupted by an annoying dialog box which stated: “Adobe Acrobat was installed as part of a suite. To enable Adobe Acrobat, please start another component of this suite (such as Adobe Photoshop).” After clicking “Ok” Acrobat would shutdown.
Needless to say, this made the Acrobat part of my installation useless. Strangely, the dialog persisted even if I was already running Photoshop when I started Acrobat. I tried deactivating and reactivating, reinstalling, and so forth — all to no avail.
Google didn’t seem to have any advice on the matter, so I gave in and tried calling technical support. Though the representative was nice, he unfortunately didn’t have an immediate solution to the problem. I kept playing around with my installation and stumbled across something that worked — instead of running the 64-bit version of Photoshop, I ran the ordinary version (it is installed in your start menu alongside the 64-bit version). Ever since then Acrobat has worked fine (even when it is the only Adobe product running)!
It seems like the 64-bit version of Photoshop doesn’t properly communicate the activation details to Acrobat — a pretty bizarre (and annoying) bug for an Adobe product (which I am usually very fond of). Thankfully, the workaround is pretty simple — just run the regular version of Photoshop (presumably running Illustrator or any of the other programs in the suite would also do the trick).
David Underhill Software Acrobat, Adobe, bug, workaround
I’ve revamped the front page to list current projects instead of past ones. I’ve also updated the Projects page to include some more recent projects including jToolbar, a minimum spanning tree algorithm library, and the ENVI network visualization and control framework. I also updated ltprotocol to provide additional and more symmetric (between the client and server) callbacks.
David Underhill Coding, Software project, update
I recently decided I was fed up with maintaining the files on my web host’s server via FTP. It is just a very unnatural and inconvenient way to update remote files – especially when making lots of small tweaks. What I really wanted was the normal file system abstraction. It seemed like mounting the remote file system as a folder in my local filesystem over SSH/SFTP would be ideal. Luckily, Miklos Szeredi (the author of FUSE) already did the hard work of implementing a little program called sshfs which does just that.
It was a piece of cake to install on my Linux box, and it looks like Mac’s have an implementation of FUSE available too. Once you have installed the tool you can mount a remote file system just like this:
format: sshfs username@host: folder_to_mount_in
example: sshfs dound@myhost.com: wwwdound
I now use sshfs to mount folders from a variety of remote machines on my local machine — it is much better-suited to many tasks than FTP, and for some tasks it beats SSH too. It is also handy when I want to grep remote files on a server I only have FTP access to. The only downside is that while you are in a terminal whose current working directory is within the remotely mounted directory all commands experience a slowdown – while I expected file-related commands like to run slower, I did not expect commands like clear to experience a noticeable latency. It is not clear to me whether this is an issue with sshfs, FUSE, or mounted file systems on Linux in general, but maybe I will look into it later. Regardless, I highly recommend sshfs — it is a very handy utility and much better than the alternatives.
David Underhill Linux, Software file system, fuse, Linux, remote, Software, ssh, sshfs