1. Don’t assume that SSD’s won’t/can’t fail.
2. When buying an SSD, check what controller it uses and then get on Google to see how many data recovery providers claim to support that controller; if you find one or less, buy something else.
3. Or even better, RAID and/or back up SSD’s just like you would HDD’s.
4. In the event of failure, an idle, unpowered SSD can retain its contents for a year or so at least with no degradation (YMMV/don’t test this on any data you care about!).
5. People will eventually figure out how to recover your data, if you give them enough money.
6. Making a filesystem dump of an old Windows install bootable again is probably easier now than it’s ever been.
7. Making an old Windows install (or installer) work with USB3.x and NVMe is nigh impossible.
8. With enough old hardware, several rounds of “musical SSD”, Windows 10 installation media, and sufficient masochism, it can be done.
9. Manually bootstrapping a GPT partition is also possible.
10. Not everyone is courteous enough to warn you when they suggest running commands that will immediately and irreversibly remove all partitions from a disk.
11. Windows no longer seems to care how many times you swap your install between completely different computers.
12. When USPS says “7-10 business days” what they really mean is “3-4 weeks, if you’re lucky”.

Anyhow, major props to ACE Data Recovery for figuring out how to restore data from dead Sandforce drives. And also to Recovery Force, for pointing me in their direction.

Normally scheduled programming of “mostly nothing much” should be resuming shortly.

But suffice to say, if you want to install the Adobe AIR runtime on an emulated Android device for testing or development purposes without having to wade through a ton of fuss and nonsense, you have two basic options. The first is described briefly here, and basically involves installing the latest Flash/Flex/AIR SDK from the official website and then grabbing the AIR runtime package from ‘<AIR_SDK_ROOT>/runtimes/air/android/emulator/Runtime.apk‘. This file is the AIR runtime that must be installed on the emulator for any apps built with Adobe AIR to function. And this method works fine if you don’t mind downloading and installing the entire AIR SDK (90 MB) just to grab this one file.

You other option is to use this direct link to download just the AIR runtime package (6.1 MB). Note that this is version 2.7 of the AIR runtime, and has been tested with an emulator running Android 3.1 only. I cannot vouch for it working with any other configurations.

In either case, once you have gotten a hold of the the runtime .apk file, installing it on your emulator is a relatively simple process. All you need is the ‘adb‘ utility that is included in the “Android SDK Platform Tools” package (note that this package is not the same as the similarly named “Android SDK Tools” package). If you don’t have this package installed yet, then use your Android configuration manager to install it. Then simply navigate to ‘<ANDROID_SDK_ROOT>/platform-tools‘ and run the following command (while your Android emulator is running):

adb install /path/to/your/AIR/runtime.apk

This will install the AIR runtime on your emulated device, and you can now install and run AIR-based Android apps on your emulator. Quite simple, really. Which only doubles my confusion with respect to why this simple process seems to be so poorly documented online.

Sadly, apart from being difficult to navigate, some of the information on the official ‘UrlRewriteFilter‘ website pertaining to setup and usage of the filter is also incorrect/out of date. This is really quite a shame, because ‘UrlRewriteFilter‘ is an excellent little utility and I’m quite tired of seeing people needlessly running multi-server configurations (typically Apache httpd for static content, and something like Tomcat, Resin, Jetty, etc. for dynamic content) out of a desire to use this-or-that particular module that only works with httpd or (even worse) out of the outdated and no-longer-relevant notion that servlet containers cannot efficiently serve static content. So in an effort to save ‘UrlRewriteFilter‘ from obscurity and an undeserved death at the hands of poor documentation and a shoddy distribution site, here is a complete set of instructions for getting the filter to work in your webapp.

First, you will need to ensure that the ‘UrlRewriteFilter‘ JAR file is on your web-application’s classpath. How you do this will depend upon your build process/how you are constructing your webapp(s), but long story short placing the JAR file in your webapp under ‘/WEB-INF/lib’ will do the trick, and if you’ve spent any time at all working with webapps you probably already have a preferred way of doing this. Alternately, you may want to install the JAR file in your servlet container’s ‘/lib’ folder, particularly if you are deploying multiple webapps on your server and you want to have ‘UrlRewriteFilter‘ available to any/all of them automatically.

In any case, once you have the ‘UrlRewriteFilter‘ JAR on your webapp’s classpath, the real setup can begin. Open your application’s ‘web.xml‘ file, and add the following filter configuration to your webapp:

<!-- URL rewriting -->
<filter>
    	<filter-name>UrlRewriteFilter</filter-name>
      	<filter-class>org.tuckey.web.filters.urlrewrite.UrlRewriteFilter</filter-class>
      	<init-param>
        	<param-name>logLevel</param-name>
        	<param-value>WARN</param-value>
        </init-param>
</filter>
<filter-mapping>
    	<filter-name>UrlRewriteFilter</filter-name>
    	<url-pattern>/*</url-pattern>
</filter-mapping>

This instructs the servlet container to route every request that the server receives through the ‘UrlRewriteFilter‘. Note that although it is not discussed on the official site, that ‘logLevel‘ parameter is absolutely essential. If you omit it, the filter will fail to initialize properly and yield some very bizarre behavior.

Anyways, once your ‘web.xml‘ has been updated, the final step is to add a ‘urlrewrite.xml‘ file in the same directory as your ‘web.xml‘ file, and configure it to your liking. Here is an example ‘urlrewrite.xml‘ file with a couple basic rewrite rules:

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE urlrewrite PUBLIC "-//tuckey.org//DTD UrlRewrite 3.2//EN"
        "http://tuckey.org/res/dtds/urlrewrite3.2.dtd">
<urlrewrite>
    <!-- user-account activation link -->
    <rule>
    	<from>/activate/([a-f0-9]+)?(.*)</from>
     	<to>/userController?action=activateUser&amp;token=$1&amp;$2</to>
    </rule>

    <!-- default rules included with urlrewrite -->
    <rule>
        <note>
            The rule means that requests to /test/status/ will be redirected to /rewrite-status
            the url will be rewritten.
        </note>
        <from>/test/status/</from>
        <to type="redirect">%{context-path}/rewrite-status</to>
    </rule>
    <outbound-rule>
        <note>
            The outbound-rule specifies that when response.encodeURL is called (if you are using JSTL c:url)
            the url /rewrite-status will be rewritten to /test/status/.

            The above rule and this outbound-rule means that end users should never see the
            url /rewrite-status only /test/status/ both in thier location bar and in hyperlinks
            in your pages.
        </note>
        <from>/rewrite-status</from>
        <to>/test/status/</to>
    </outbound-rule> 
</urlrewrite>

This defines two rules. The first simply rewrites URL’s of the form ‘/activate/######?[params]‘ to something like ‘/userController?action=activateUser&token=######&[params]‘, and the second is the default example rule that comes with ‘UrlRewriteFilter‘ and allows you to see a basic diagnostic page by pointing your browser at ‘[your server]/test/status‘.

And there you have it. Quite simple, really, and now there’s one less reason to continue running two distinct server instances where one would do just as well.

• Intel BOXD510MO Motherboard with Integrated Atom D510 CPU
• 4 GB Kingston DDR2-800 Memory
• Corsair 60GB SSD
• Aywun MW-101 Case

Here’s a shot of everything unboxed and ready to be assembled:

And here’s one of the build with everything installed and ready to be shut away inside of the case:

All told the total cost of this build was just slightly under AU$400, including GST and shipping fees. Nearly half of this was allocated to the Corsair SSD, so a comparable build may be attainable for closer to $300 if you’re willing to settle for a traditional HDD. As this system was intended to do duty as a server box, however, I felt that the performance benefit provided by the SSD was more than worth the extra cost.

Anyways, the system being replaced by the Atom build is a retail Hewlett-Packard box that was purchased way back in 2001. It has the following specs:

• 1.3 GHz Intel Pentium 4 (no HyperThreading)
• 256 MB PC-800 (400MHz) RDRAM
• 40 GB Western Digital HDD (IDE)
• Stock motherboard, case, audio, etc.

This system is all but worthless today, but back in 2001 it retailed for close to $1100 (with bundled monitor and printer). In its defense this old P4 box delivered a solid decade’s worth of performance and proved itself to be entirely capable of running a number of different servers, albeit under very light workloads. But all things must come to an end, and it’s time for this dinosaur to be replaced.

So how does the Atom processor stack up against this 10-year-old beast? Here’s a screenshot from Super PI comparing the two (the Atom is on the left, and the P4 is on the right):

Now it’s worth noting that this is not and cannot be an apples-to-apples comparison between the two CPU’s, as all the other variables (RAM capacity and speed, disk architecture, etc.) have been changed as well. But I think Super PI probably does a fairly good job of isolating the CPU, and at the 1M setting the task should be small enough that the difference in RAM capacity between the two systems doesn’t come into play.

Assuming that to be the case, the Atom D510 makes a fairly strong showing for itself. It comes in at roughly 3 times faster than the 1.3 GHz P4, and since the Atom D510 is a dual-core CPU one should expect it to be up to 6 times faster under a well-threaded (i.e. server) workload. That’s quite an improvement over the old system, although it’s worth noting that my desktop system (an Intel Core 2 Quad based machine clocked at 3.5 GHz) can breeze through the same benchmark in just under 15 seconds. So by modern standards the Atom CPU is quite slow.

But sheer performance is only part of the story. The other reason why I opted for the Atom based server is the Atom platform’s low power consumption. If I wanted the fastest server possible I could simply use my desktop for the task, and leave it running 24/7. And then I would cringe every time my utility bill was due. With the Atom my goal was to attain reasonable performance using as little power as possible, and after looking at the numbers I can only conclude that it delivers as advertised.

Using a Kill-A-Watt device I measured the power consumption of each system at the wall, and worked out that the 10-year-old P4 system draws 90 watts of power while sitting idle, and around 110 watts under full CPU load. The Atom system, on the other hand, weighs in at 17 watts while idle, and a massive 21 watts under full CPU load.

So 6 times the performance, for less than 1/5th the power consumption (and before I forget, the Atom system is virtually silent as well). With those numbers the Atom system starts to look like 100% win. I can run one box and get much better performance than the old system could deliver at a fraction of the energy consumption, or I could use the same amount of power to run a cluster of 5 Atom servers for 30 times the performance.

But in any case, that’s my Atom server build, and overall I’m quite pleased with the results. The Atom D510 provides a nice bump in speed over the (admittedly decrepit) server box that it replaced, while also using much less power. If you need a cheap, basic, quiet server box for low-volume workloads then an Atom-based solution is an option worth considering.

No other news to report at the moment, I just wanted to publicly show my support for this excellent WordPress plugin.

Update: Much as I still love this plugin, it did introduce a pretty severe layout bug in Internet Explorer (any post with a code block in it would be stretched beyond the width specified in the theme layout, causing the posts to overlap with the right-nav section). I fixed this by adding the following to my IE stylesheet:

.entry-content {
	width: 100%;
}

And while we’re on the subject, the image lightbox plugin also did not work correctly in Internet Explorer by default (the background overlay was solid black instead of translucent). I had to add the following CSS to get it working (again in the IE-only stylesheet):

#stimuli_overlay {
    display: none;
}

Note that this completely removes the background overlay. I could probably get the alpha set correctly without too much more fuss, but I think this works well enough for now.

To my fellow web-developers, I can only say the following: I know it’s fun to dump on IE for its lack of standards compliance, poor performance, and other failings, but at the end of the day IE is still the most used browser in the world, so it behooves us to always test our work in Internet Explorer when authoring online content or when authoring any code that will be used to generate online content.

Homegroups allow for much simplified sharing of multimedia and other content between computers on a network. There is very little explicit configuration needed, and when an application integrates with the Homegroup properly there is really no noticeable difference between a local resource and one that’s being streamed from some other computer on the Homegroup. This makes for a very cool experience when it all works, and in Windows Media Player it works seemlessly. My media library can be distributed across several systems, and yet from each one I can access the entire volume as if it is all local to that particular machine. And it just works, flawlessly, with no onerous setup or manual cajoling needed on my part. This is what good software is supposed to do; merge invisibly into the background so that the user can accomplish a complex task as if by magic, and currently only Windows Media Player does it.

I’m sure that situation will change in the near future, but at the moment its seamless Homegroup integration makes Windows Media Player the only media player that I am interested in using. And that means that some of its other shortcomings, such as a complete lack of support for a variety of free and open codecs and file formats, need to be dealt with. Now there are a number of tutorials on this subject already, but many of them give inaccurate or incomplete information. In the interest of having a complete set of instructions that actually work, if you want to enable FLAC/Vorbis/etc. support in Windows Media Player, do the following:

1. Install the DirectShow filters/codecs.
2. Install the Tag Support plugin.
3. OPTIONAL: If, like me, you included your FLAC folders/files in your library before installing the above packages, then you also need to rebuild your Windows Media Player library. Make sure you close Windows Media Player and shut down its network sharing service either by stopping it under ‘Control Panel -> Administrative Tools -> Services‘ or by killing the ‘wmpnetwk.exe‘ process in the Task Manager before attempting to delete or rename its configuration folder.

And that’s really all there is to it. You may or may not end up with the ability to seek within and/or see the duration of FLAC files. I’ve seen it happen both ways on occasion, it seems like it either works or not depending upon the mood that Windows Media Player happens to be in when these plugins are installed. But the important bit is that all the previously unsupported files will now show up correctly in your library, and also (of course) that they are now playable.

And in other news, the rebuilding continues, slowly.

Now back in the day, I would use a nifty little SourceForge project called phptriad to handle all of the little installation and configuration nonsensicalities for me.  Phptriad was quick, easy, and generally worked straight away.  There’s just one major problem with it; the project hasn’t seen any updates since September 9th of the year 2000.  Using it nowadays consigns one to hopelessly outdated versions of Apache and PHP (and also MySQL). Versions that are so hopelessly outdated that they do not meet the minimum requirements for running WordPress.

So I decided that this time around I would do things the correct way, and install the latest version of Apache, the latest version of PHP, and then configure them to talk with each other.  “How hard can it be”, I recall myself saying.  The PHP installer even had an Apache configuration step that seemed like it would handle the entire process automatically.  But sadly that was not the case; the automatic configurator did nothing useful, and while the configuration process was not hard it was exceedingly poorly documented and circuitous, turning what should have been a 2-minute task into a nearly 2-hour endeavor.

Now, do a quick Google search for Apache and PHP configuration issues and you will find countless posts suggesting adding minor variations of the following directives to Apache’s httpd.conf file:

AddHandler application/x-httpd-php .php .phtml
AddType application/x-httpd-php .php

Seems like a simple enough fix, but none of the myriad variations of these two directives did the trick. It makes sense when you think about it, considering that all these directives do is associate .php files with a MIME type. Left wide open is the question of how Apache is supposed to know what that MIME type actually means, how it should be handled, and where to find the handler. Yes, the php5_apache22 module is being loaded as well, but the module isn’t magic; Apache still needs to know when and how it should use it. So essentially what’s missing is a mapping to tell Apache “for MIME type ‘x’, use program ‘y'”. After far too much searching, I found a page that also mentioned adding the following directive:

Action application/x-httpd-php "/path/to/your/php.exe"

And finally there was the missing piece. The AddType (or if you prefer, AddHandler) directive associates .php files with a particular MIME type, and the Action directive maps that MIME type to a concrete resource that Apache can use to process items of that type. Apache now knows both what a .php file is, and how to process it, and like magic the server behaves as it should. All told far too much digging was needed to uncover that one critical line.

For reference, the complete PHP configuration section in my httpd.conf file looks like so:

PHPIniDir "~/apache/php"
LoadModule php5_module "~/apache/php/php5apache2_2.dll"
AddType application/x-httpd-php .php
Action application/x-httpd-php "~/apache/php/php.exe"

I suspect that the actual MIME type assigned to .php files matters very little here, so long as the type is consistent between the ‘AddType’ directive and the ‘Action’ directive.