My goal was to tail a logfile on a remote server and display it on my desktop. GeekTool supports three types of “Geeklet”: File, Image, and Shell. File displays the content of a file, Image displays an image, and Shell displays the output of a shell command (good thing I’m here to clarify!) Each of them has various options, which the GeekTool website documents in further detail.

The shell geeklet is implemented as a (probably recurring) shell command that gets run, with the output being shown on completion. Unfortunately, this rules out the simple approach of `ssh user@server “tail -f /var/log/yourlog”`. By running an ssh process to tail the log and piping the output into a local file, we can happily have our “log tail” without continuous ssh connects and disconnects: `ssh -f user@server “tail -f /var/log/yourlog” > /tmp/server_log_yourlog`.

Throw in a file geeklet, and you’re done. I happened to want the newest text on top, so I used a shell geeklet of `tail -r -100 /tmp/server_log_yourlog`. Enjoy your upside-down live server logs on your desktop!

The only easy way seems to be using a java tool called not-yet-commons-ssl which will do this for you. So download their latest jar and use it (update as necessary for your version of not-yet-commons):

java -cp not-yet-commons-ssl-0.3.11.jar org.apache.commons.ssl.KeyStoreBuilder your-new-keystore-password-here yourdomain.tld.key yourdomain.tld.crt

This will leave you with a yourdomain.tld.jks file, which you can then go ahead and sign your applet with:

jarsigner -keystore yourdomain.tld.jks -keypass your-new-keystore-password-here applet.to.sign.jar yourdomain.tld

Let’s start by installing all the dependencies for debian’s ffmpeg package:
aptitude build-dep ffmpeg


We need to add the debian-multimedia repository. Edit your sources.list:
vi /etc/apt/sources.list


Add in these lines for the debian-multimedia repository:
deb http://www.debian-multimedia.org squeeze main non-free
deb-src http://www.debian-multimedia.org squeeze main non-free


Then add the repository key so dpkg doesn’t complain (you’ll need install wget):
aptitude install wget
wget http://www.debian-multimedia.org/pool/main/d/debian-multimedia-keyring/debian-multimedia-keyring_2008.10.16_all.deb
dpkg -i debian-multimedia-keyring_2008.10.16_all.deb


Then update:
aptitude update


Now we’ll install some packages to flesh out ffmpeg’s format support:
aptitude install libmp3lame-dev libxvidcore4-dev libfaad-dev libfaac-dev liba52-0.7.4-dev


And we’ll need subversion and git to grab sources for ffmpeg and x264, respectively:
aptitude install subversion git


Now, let’s go ahead and check out the summer of code branch of ffmpeg
svn co svn://svn.ffmpeg.org/soc
cd soc/libavfilter/
./checkout.sh
cd ffmpeg/
./configure --enable-libmp3lame --enable-libtheora --enable-libx264 --enable-libgsm --enable-postproc --enable-libxvid --enable-pthreads --enable-libvorbis --enable-gpl --enable-x11grab --enable-nonfree --enable-filter=movie --enable-avfilter --enable-libfaac


At this point, the configure script will complain that “ERROR: libx264 not found”. So now it’s time to install x264:
cd ../../..
git clone git://git.videolan.org/x264.git
cd x264
./configure
make
checkinstall --fstrans=no --install=yes --pkgname=x264 --pkgversion "1:0.svn`date +%Y%m%d`-0.0squeeze1" --default


Now, back to ffmpeg:
cd ../soc/libavfilter/ffmpeg/
./configure --enable-libmp3lame --enable-libtheora --enable-libx264 --enable-libgsm --enable-postproc --enable-libxvid --enable-pthreads --enable-libvorbis --enable-gpl --enable-x11grab --enable-nonfree --enable-filter=movie --enable-avfilter --enable-libfaac
make
checkinstall --pkgname=ffmpeg --pkgversion "4:0.7+svn`date +%Y%m%d`" --backup=no --default


And that’s it! You now have ffmpeg on your debian squeeze system (should work fine with lenny if you change the debian-multimedia sources.list entries).
Update: Added libfaac.

Needless to say, I took personal exception. So I wrote a script to download all the photos out of a PrintRoom album. It required a perl interpreter, the LWP::Simple module, and wget installed on your system. If you don’t know what this means, the script is not for you. If you have a compatible system and are stuck with printroom, then download the script.

Whew! When it takes a whole paragraph to list essentially identical applications, maybe it’s time to stop making more of them. In any case, the scripts can be downloaded from the FaceBook battle apps page as usual. Have a great trip upwards through the ranks!

• Both can only format in the FAT filesystem. Since their primary virtue over encrypted DMGs is cross-platform portability, this probably isn’t too big of a deal.
• You can use the disk utility to reformat a mounted encrypted volume if you want another filesystem.
• With TrueCrypt volumes, you can’t eject from finder, with OSXCrypt you can eject from finder but need to complete from command-line anyway.
• OSXCrypt is MUCH faster than the official TrueCrypt release. I didn’t do benchmarking, but the difference is easily noticeable.
• You can’t copy large files into a TrueCrypt volume unless you use Disk Utility to reformat to another filesystem.
• OSXCrypt doesn’t yet do full-disk encryption, and seems to be unable to create an encrypted disk larger than 1GB.
• TrueCrypt has a GUI, but it doesn’t really feel like it was designed for mac. OSXCrypt has no GUI, but it’s pretty self-explanitory usage (I had an easier time figuring out OSXCrypt than TrueCrypt).
• It seems that OSXCrypt won’t mount images that don’t have a .img suffix (due to their usage of hdiutil).
• From what I’ve seen around the internet, OSXCrypt is currently more reliable than TrueCrypt.

While it seems neither is quite ready for day-to-day use, I’ll be sticking with OSXCrypt and/or sparseimage files for now. I’m certainly looking forward to support of full-disk encryption, however.

Now, to keep the record straight, TrueCrypt and OSXCrypt have different goals. TrueCrypt allows for steganography, encrypted disk images (something OSX has not been lacking), and full disk encryption. OSXCrypt, on the other hand, is not an encryption solution in and of itself. Instead, they provide a framework for various encryption solutions.

Personally, I don’t see anything lacking in TrueCrypt‘s feature list, and a 5.0 tag is a little more reassuring to me than 6.2A. I’m going to be installing TrueCrypt shortly, but I’m wondering if anyone has had experience with OSXCrypt and recommend it.

Some quick updates that may be of interest to those considering installing one or the other:

• TrueCrypt‘s OSX implementation is based on MacFUSE.
• MacFUSE comes bundled with other filesystems (NTFS, WebDav, ZFS, FTP, etc)
• OSXCrypt is probably a lighter-weight install.
• OSXCrypt has no GUI, whereas TrueCrypt does.