Don't Keep It!

Windows:
If you're like me, you download quite a bit of software.  Most of that software is probably a one-time install, to do something useful for you, or just to try out.  With Google, you can find something to do almost anything your heart desires.

Where do you store that software?  Do you just download it to a local directory and forget about it once its installed?  Disk space is cheap, so why not leave it where it is?  That's what I used to do.  The trouble arises during clean-up however.  Some time goes by and you decide to go through that trove and maybe keep a few things that were interesting.  Wait...what was interesting again?  OK, just check what you currently have installed.  Oh, but wait again, didn't you re-install a bunch of stuff after a hard drive crash about 2 months ago?   Well, you can probably always find the interesting stuff (or new interesting stuff) on the 'net again.  Do you really want to continually go through this cycle of binge and purge?

NO!  You don't need to keep it.  There are many simple solutions, but I take a cue from Linux (and its precursors).  Linux has a directory called /tmp where you can put anything you don't need to keep around for too long.  This directory is purged with extreme prejudice (read indiscriminately) after a reboot or according to a schedule.  Windows has a temp directory as well, usually as a subdirectory in the user's home or in C:\temp.  But unless you take special measures, this directory is almost never purged.

My solution has been to set up a (relatively) small RAM disk.  A RAM disk uses some of your computer's (very fast) memory to create a virtual disk that acts just like a hard drive.  For our purposes it has two great advantages:  it's fast and it's temporary.  A RAM disk makes installs very quick because the installation program doesn't have to access the slow hard drive.  Also, because it's in memory, as soon as the power goes off, the disk and everything stored on it ceases to exist.  You can choose to have its contents saved back to a real hard drive upon shutdown, but that defeats our purpose.

So do yourself a favor.  When you find a piece of software that you like, bookmark its location or keep track of it in a simple list.  Download it to and install it from your RAM disk, then forget about the installable.  You can always find it again...

Working around absurd copyright restrictions

Some parts of copyright law are just downright stupid. For example, if I make a video of my baby reacting to TV or music playing on the radio, I may not be able to make that video/audio available online (on, e.g., YouTube) due to potential copyright infringement.  This could be a problem for many parents and others.

Thus I propose the following:  build a browser plugin that will take the potentially infringing audio stream (or any stream for that matter) and scramble it via encryption or any other method prior to upload.  This should make infringement detection very difficult if not impossible.  Then, the plugin will decrypt the audio stream as the video is played back.  Sharing can be accomplished in a way that allows the decryption key to be safely passed between plugin users.

Regain control of a rogue XCP Server

In the past year, I have constructed a small private cloud from four Core-i7 machines and Xen Cloud Provider.  Recently, one of my servers suffered filesystem corruption such that somehow its root password was mangled.  If you are lucky enough to have physical access to the machine, then you can try this procedure, which I must note is not much different than that for any normal Linux box, except in the specifics of the bootloader.

1. Boot your server as usual, but you need to get to the SYSLINUX prompt by pressing the <shift> key after BIOS POST.


2. You will then see the Syslinux boot: prompt which is asking you for which kernel it should boot.   You need to then type menu.c32 <enter>.  Be warned that a hidden boot timer is ticking at this prompt, but it's reset every time you type a key.


3. You will be presented with a menu for booting into e.g., regular XCP, safe mode, etc.  Select the first entry (xe) with the cursor keys (it should start on that entry anyway), then press <Tab> to edit the boot parameters.


4. You should see something like the following:
   
   append /boot/xen.gz dom0_mem=752M lowmem_emergency_pool=1M crashkernel=64M@32M console= vga=mode-0x0311 --- /boot/vmlinuz-2.6-xen root=LABEL=root-mlbdhhzz ro xencons=hvc console=hvc0 console=tty0 quiet vga=785 splash --- /boot/initrd-2.6-xen.img


5. You want to insert the single keyword for the dom0 kernel like so:
   
   append /boot/xen.gz dom0_mem=752M lowmem_emergency_pool=1M crashkernel=64M@32M console= vga=mode-0x0311 --- /boot/vmlinuz-2.6-xen single root=LABEL=root-mlbdhhzz ro xencons=hvc console=hvc0 console=tty0 quiet vga=785 splash --- /boot/initrd-2.6-xen.img
   
   
   I also removed the quiet and splash options so that I can see if anything strange is happening during the boot process.

This should drop you at a single-user root prompt from which to do your analysis and repair.

YMMV!

Roaming in Eilat

I have been traveling in Europe and Israel recently, and I decided to bring my Pantech Crux from Verizon, mostly to use as an alarm clock!  In Paris, Greece, Tel Aviv, and Jerusalem, I could not get any kind of signal.  I expect that this is because these places use GSM, which operates on a different frequency than CDMA in the States.  In addition, I was not aware of any relationship between Verizon and local international providers.

The Crux is a CDMA-only phone.  The designers did not think that the phone would be used outside of the US (since it basically does not work), thus they didn't provide an option to change the date and time manually!  The date/time is changed according to the US timezone in which coverage is being provided. For the first few weeks of my trip, I was setting the alarm 6 or 7 hours behind, because the phone was stuck on EDT.  When I arrived in Eilat, one of my alarms triggered and I didn't understand why... until I noticed that the time had changed and I was getting a roaming signal!  I dared not dial anyone for fear of a $1.99/min fee.

It turns out that Verizon does have CDMA towers in over 40 countries, Israel being one of them.  They claim that they provide service in Tel Aviv and Jerusalem, but that did not happen in my experience.

Anyway, if you own a CDMA phone from Verizon, at least you can rest easy... Just get to a CDMA tower in the closest country to you, and reset your alarms!

Web Link Auto-Updating

Every so often, people will come across outdated links on a web page. It seems to me that this situation is mostly avoidable, or at the very least, we have the capability to resolve it to most people's satisfaction. Why not have a server-side script that checks, on a regular basis, the availability of the links in your web pages? If a link is unavailable for a predefined length of time, it will be made to point to a recently cached copy, and the webmaster (maybe you) will be notified. We could customize the script to go to Google's cache, archive.org, or if there is space on our server, a local cache.

One difficulty with this scheme is deciding when to replace the "cached" link with the original again. If we do this automatically based on the original link becoming available, we run the risk of that link pointing to a page that is significantly different than the one that was cached. We could decide on a metric of difference, and maintain the link to cached content if the metric exceeds a threshold. This would still require human intervention at some point, but would give webmasters some breathing room.

Doing this manually for sites of moderate to large size might be feasible if we observe that the population of link targets do not change significantly or go dark more than x days per year.

Optimization in R

I recently performed this computation in R:

stats.irreg <- mclapply(firsts.irreg, function(x) list(means=sapply(cd(x), mean), meds=sapply(cd(x), median), sds=sapply(cd(x), sd), cvs=sapply(cd(x), cv)), mc.cores=2)

This iterates over a list of sublists of vectors (firsts.irreg), each vector being a time series. For each sublist a list is returned with the means, medians, stddevs, and c.o.v.s of the vectors in the sublist. I claim that R is doing much more computation than necessary. In this case, the code that reads 'means=' is computing means of each vector and 'sds= 'is computing standard deviations of each vector. The code that reads 'cvs=' is computing the coefficient of variation of each vector, which is the standard deviation divided by the mean. Thus, R will compute the mean and stddev of each vector twice. Is it possible or even desirable to have a language/interpreter/compiler recognize this and optimize it, or should it always be left to the programmer?

Auto EPS Conversion in pdflatex

I recently decided to start using PDF figures in my thesis instead of EPS and compiling my TeX code directly to PDF. This requires that you have the perl script 'epstopdf' installed on your system, as well as ghostscript and the associated machinery. The TeX package "epstopdf", combined with usepackage[pdftex]{graphicx} will auto convert any EPS figures used in your document to PDF. The actual conversion works wonderfully. There is a snag however, as described by the author of the package: even with TEXINPUTS set correctly, the 'epstopdf' script cannot find figures located in nested subdirectories.

A solution upon which I settled was to modify the script and put it in my local path before the real epstopdf (which is usually in /usr/bin). The trick is to use kpsewhich to scan all the associated TeX directories, including those recursively specified in TEXINPUTS. The fix is as follows:

Make a copy of 'epstopdf', and find the following lines in your new copy:
@ARGV &gt; 0 or die errorUsage "Input filename missing";
@ARGV &lt; 2 or die errorUsage "Unknown option or too many input files";
$InputFilename = $ARGV[0];
and change the last line to

chomp($InputFilename = `kpsewhich $ARGV[0]`);

This will prepend the correct path to InputFilename as found by kpsewhich.

So far this works like a charm on all my linux distros (RHEL and Ubuntu). YMMV!