Past Space Resource Papers

These old papers and abstracts came up in conversation, and I thought I'd surface them here from Google Scholar for easy blog reference.

The contents are decades old, but lunar matters are much the same. The major difference these days is that the ‘non-renewable resource' of scientific ignorance has diminished a bit.

So we've got that going for us, which is nice.

This list is in chronological order, and nowhere near complete. Three full lunar/asteroidal development papers for the Journal of the British Interplanetary Society seem to be tucked elsewhere, and there is a ridiculously extensive collection of presentations made through the years that are very slightly bending a shelf to my right.

If you'd like copies, just ask over a coffee or pint.

Commercial activities resulting from a lunar base - Charles D. O'Dale (1994)
British Interplanetary Society, Journal (ISSN 0007-094X)
vol. 47, no. 12, p. 549-554

Policy Considerations for Lunar Development - Charles D. O'Dale (1995)
Thirty Second Space Congress, Paper Session II-C (1995)

The International Lunar Base as a Foundation for Commercial Industry - Charles D. O'Dale (2000)
Proceedings of the Fourth International Conference on Exploration and Utilisation of the Moon: ICEUM 4

Public and Private Sector Coordination for Effective Lunar Resource Use - Charles D. O'Dale (2005)
Proceedings of the International Lunar Conference, 2005

Lessons from Earth: Experiences Which can Guide Lunar and Asteroidal Development - Charles D. O'Dale (2004)
Space Resources Roundtable VI

Using Secondary Objectives to Guide the Development of Lunar Industry - Charles D. O'Dale (2005)
Lunar Exploration Analysis Group (LEAG) (2005)

How To Stop Windows 10 Notepad From Saving Find Settings

Windows Notepad is a simple workhorse text editor. It's nothing fancy. It just gives the bare basics, with a clean session each time it's opened.

At least it did.

Get Windows 10 Notepad to start with a clean session each time it is opened.

In 2019, Microsoft decided to have Windows 10 Notepad remember its last used settings. That change isn't a big deal for most people, but when I open Notepad I'm not looking to tweak settings before getting to work. I just want to open Notepad, enter a snippet to find with 'ctrl-f', hit 'enter', and confirm the text is present (or not) before moving on. But now, I have to step out of my workflow to first confirm text search is clear, set its direction, and then perform my search.

Again, not a big deal for most people. But if you are as annoyed by that change as I am, you understand why it's a pain.

It would be fantastic if Microsoft provided a 'do not remember last settings' option in Windows 10 Notepad along with that extra functionality to remember find settings, but they didn't. So, now we have to work a little magic with the registry editor to fix that and get Windows 10 Notepad to start with a clean session each time it is opened.

Like it used to.

Quick Side-Note:

The changes made here use the Windows registry edit tool.

If you are already familiar with the registry editor, you know how to tweak registry settings and are aware of how dangerous those changes can be.

If you are not familiar with the Windows registry editor, please familiarize yourself with the ins-and-outs of that tool and back up your full windows registry before proceeding.

These instructions have been left deliberately vague and may be confusing to anyone not familiar with the Windows 10 registry editor. If these instructions are not perfectly clear to you, please take a bit of time to familiarize yourself with your Windows registry editor.

Disclaimer and Warning:

Changes made in your Windows registry editor can destroy your computer. That is not an exaggeration. Be certain you have a full registry backup and know what you are doing before proceeding with any windows registry edits.

To Prevent Windows 10 Notepad From Saving Its Find Settings:

First, perform a search in Windows 10 Notepad to place your settings in your preferred default search direction ("Direction (*) Down", right?) then close Notepad.

Next, open your editor to the branch:

Select the key:

and clear its contents.

At this point, you have Windows 10 Notepad set to its traditional defaults. Now, we are going to lock those defaults in place:

Click the registry branch:

then right-click on that item and choose the "Permissions..." pop-up menu item. The "Permissions for Notepad" dialog box will be opened, with its "Security" tab displayed.

In the displayed list of "Group or user names:", select the user account you would like to fix Notepad for (that will almost always be the user account you have signed in with). With that user account selected, toggle on the "Deny" checkboxes for the "Full Control" and "Read" permissions (the "Allow" checkbox items are read-only and cannot be changed; setting those items to "Deny" will serve to disable them).

With "Deny" toggled on, click "Apply".

A security dialog will appear, warning that you are going to deny a permissions entry (yes, that is exactly what we are wanting to do). Click the "Yes" button on that warning dialog to apply your change, then click "Ok" on the "Permissions for Notepad" dialog to close that box.

You're done. You can now close your registry editor and go about your business, with Notepad now clearing its find preferences after every session.

What a pain.

Microsoft, please don't mess with Notepad. If I want a text editor with text editor functionality, I'll use one. Windows 10 Notepad is a notepad for quick scratch notes and text reference, please keep it that way.

Creating a Self-Signed SSL Certificate to Secure Java WebSockets on Windows

Update - August 8th, 2021

Please note:

Some day soon, web browsers will block self-signed certificates from securing WebSockets.

Although the instructions on this page will still work for creating a self-signed certificate, I would recommend jumping right to using a certificate signed by a registered authority, rather than risk web browser security headaches when developing Java WebSockets with a self-signed cert.

You have a Java jar running on a Windows computer, that Java jar creates a TCP WebSocket, and you want to secure that WebSocket with a self-signed SSL certificate.

So, here's the situation you're facing:

You have a Java-based server program running on a Windows computer. The computer is not a web server -- it's just a regular Windows machine -- and you want to secure its WebSocket with a self-signed SSL certificate.

Maybe you're wanting to connect in to that Java server program through an HTTPS web page. Maybe you're wanting a bit of extra security for occasional connections over the public internet. Maybe (like me) you need an SSL certificate to allow a bit of HTTPS testing in-house on a few isolated Windows PCs. Regardless, you have a Java jar running on a Windows computer, that Java jar creates a TCP WebSocket, and you want to secure that WebSocket with a self-signed SSL certificate.

What to do?

Setting a Network Name

Before starting, you will want to have a network name by which your Windows computer is known. That can be handled by either having a proper DNS name for your computer or, in a pinch, you can edit the hosts file to direct a name to the IP address of that computer. That hosts file edit is the quick hack we'll run through here.

Your hosts file can be found on your Windows computer at:


to edit that file, open up Notepad in Administrator mode (admin rights will be needed to save your changes) and add an entry for the IP address of interest.

For example, if you wanted to reference a computer at the local IP address of with the DNS name mytestserver, adding the following line for that in your hosts file would direct that name to the computer:

# Copyright (c) 1993-2009 Microsoft Corp.
# This is a sample HOSTS file used by Microsoft TCP/IP for Windows.
# This file contains the mappings of IP addresses to host names. Each
# entry should be kept on an individual line. The IP address should
# be placed in the first column followed by the corresponding host name.
# The IP address and the host name should be separated by at least one
# space.
# Additionally, comments (such as these) may be inserted on individual
# lines or following the machine name denoted by a '#' symbol.
# For example:
#          # source server
#              # x client host

# localhost name resolution is handled within DNS itself.
#       localhost
#	::1             localhost     mytestserver

After making that entry, a ping test from your MS DOS command prompt to that mytestserver DNS name should show you a reply from your identified IP address (if not, check that you've chosen the correct IP address for your hosts entry -- a ping will bounce off a computer running at that address).

The rest of this example assumes use of the mytestserver DNS name we hacked up in the hosts file above. For all of the following examples, where you see 'mytestserver' in a listed command, substitute in your own Windows computer's DNS name instead.

Creating a Self-Signed SSL Certificate on Windows

Now to the root of things: Creating a self-signed SSL certificate on the Windows computer itself. That can be done using the Windows Powershell utility running in Administrator mode.

The New-SelfSignedCertificate Windows Powershell command will create a self-signed SSL certificate

The easiest way to start your Powershell is to open your Cortana search (keyboard shortcut: windows-key S), enter 'powershell' in the search prompt, and then right-click and select 'Run as administrator' on the Windows Powershell desktop app which appears in your search results.

The New-SelfSignedCertificate Windows Powershell command will create a self-signed SSL certificate and add it to your Windows certificates list.

For example, this Windows Powershell command (which is broken out on multiple lines here for clarity, but which must be entered in your Powershell on one line):

New-SelfSignedCertificate -CertStoreLocation Cert:\LocalMachine\My
 -DnsName "mytestserver"
 -FriendlyName "MyLocalTestCert"
 -NotAfter (Get-Date).AddYears(25)

Would create a new self-signed certificate for the example DNS name we're using of "mytestserver" and provide it with a human-readable name of "MyLocalTestCert". You should use your own computer's DNS name and the certificate name you would like as appropriate. That certificate would have a lifetime of 25 years (something you could safely forget about for purposes of your testing) and is ready to add to the trusted root certification authorities.

Your Windows Powershell window can be closed now -- we're done with that tool.

Making a Self-Signed SSL Certificate Trusted

With the self-signed SSL certificate created, we can now access it in the Windows Manage Computer Certificates utility. As with Windows Powershell, the easiest way to access that tool on Windows 10 is to bring up Cortana search, enter 'certificate' in the search box, and select the 'manage computer certificates' option from the list of search results.

With your Windows Certificates Manager open, open the folder branch:

"Certificates - Local Computer -> Personal -> Certificates"

You will see the MyLocalTestCert certificate you created listed in that folder.

Now, we'll want to copy that certificate to the list of trusted certificates. That can be done with a simple copy-and-paste of your certificate from the certificates manager folder:

"Certificates - Local Computer -> Personal -> Certificates"

to the folder:

"Certificates - Local Computer -> Trusted Root Certification Authorities -> Certificates"

That serves to register your created SSL certificate as one which your Windows computer will trust for SSL socket creation.

Creating a Java-Ready SSL Certificate

At this point, we have a self-signed SSL certificate created and registered as trusted on Windows. So, how do we create a Java-ready keystore?

The solution for that is the Java keytool utility, which should already be available on your computer thanks to your Java development. But before we can use the keytool, we need to export a copy of the self-signed certificate we've created.

Returning to the Windows Certificates Manager, select the certificate you imported into your Trusted Root Certification Authorities and right-click the cert to select "All Tasks -> Export...". From there, it's just a matter of following the certificate export Wizard.

In the certificate export wizard, you will want to export the private key (that key will be used in your Java keystore), use the Export File Format of "Personal Information Exchange PKCS #12 (.PFX)" and for the file export options, you will want to choose:

- Include all certificates in the certification path if possible
- Enable certificate privacy

Be sure to make note of the password you choose for your certificate -- you will be using that password later.

With your certificate data exported to file (we're using the filename myexportedcert.pfx for the example that follows), you're ready to create your Java keystore.

To provide a simple staging area for the creation of your keystore, create a temporary directory on your hard drive (say, d:\temp_work\ ) and copy your exported myexportedcert.pfx file to that directory.

With your myexportedcert.pfx file in place, open an MS DOS prompt window, change the path to your temporary directory and enter (on a single line) the keytool command:

keytool -importkeystore -srckeystore myexportedcert.pfx -srcstoretype pkcs12
-destkeystore myKeystore.jks -deststoretype JKS

and then follow the on-screen prompts to enter the password you used for the creation of your certificate.

Once all prompts have been finished, you will find a new file, myKeystore.jks, in your temporary directory. That myKeystore.jks file provides all of the detail you require to load and use your self-signed SSL certificate to secure your Java program's WebSocket.

Using Your Self-Signed SSL Certificate on Other Computers

What we'll be wanting to do next is allow your self-signed SSL certificate to be used from other computers.

Since your SSL certificate is self-signed, it will not be recognized outside of your server computer (having copied your certificate to your "Trusted Root Certificate Authorities" provided all of the authorization you needed for that system), but you can export your certificate to different computers to allow use of the self-signed SSL certificate elsewhere.

The exported certificate file in this case will not contain your private certificate information and will be safe to pass around to other computers for your testing. To create it, open up your Windows Certificates Manager, select the self-signed SSL certificate you placed in your Trusted Root Certification Authorities earlier, and right-click the certificate to open up your certificate export wizard.

This time, you will not want to export the private key for the certificate, and you will select the export file format of "DER encoded binary X.509 (.CER)". Once you have completed the certificate export wizard and have exported a new .cer file, that file can be added to the trusted keys of any other computer you would like to access your SSL socket from.

To import your .cer file on another Windows computer, just open the Windows Certificates Manager on your other computer, open the folder:

"Certificates - Local Computer -> Trusted Root Certification Authorities -> Certificates"

and import your created .cer file. From there, you will be able to connect to your test computer's SSL socket.

Don't forget: If you do not have a DNS name specified for the computer hosting your Java SSL socket server program, you will need to add an entry to that computer's hosts file so that it will recognize the hostname tied to your SSL certificate (for example, the mytestserver DNS name we used earlier in our quick hosts file hack).

That's it! You have created a self-signed SSL certificate which can be used to secure a Java TCP socket for testing, and you can now access that certificate from whichever computer you would find helpful.

For a permanent solution, you will want to purchase a certificate signed by an external certificate authority

This is a rather niche case for SSL certificates and, for a permanent solution, you will want to purchase a certificate signed by an external certificate authority rather than work with a self-signed cert on your systems. But these particular steps were helpful for my own testing, and I hope the details outlined here will help save time in your own troubleshooting and development.

C++ "Hello World!" for Oculus Rift CV1 / DK2 SDK 1.3.0

As promised, here's a sequel post for creating a simple 'Hello World' console app in C++ for your Oculus Rift, this time covering the final production 1.3.0/1.3.2 Oculus SDK for CV1 and DK2 devices.

If you enjoyed developing software on the Oculus DK2, I have some bad news for you.

If you've not yet set up your environment for C++ development, the earlier Oculus Hello World post for the v0.5.0 runtime will give you the steps you're wanting to follow for that.

The latest Oculus SDK can be retrieved from here:

With the Oculus v1.3.2 runtime provided through the general Oculus setup program, here:

For the code itself, this simple program:

#include <iostream>
#include <iomanip>
#include <OVR_CAPI.h>
#include <thread>

#define COLW setw(15)

using namespace std;

int main()
{   // Initialize our session with the Oculus HMD.
    if (ovr_Initialize(nullptr) == ovrSuccess)
        ovrSession session = nullptr;
        ovrGraphicsLuid luid;
        ovrResult result = ovr_Create(&session, &luid);

        if (result == ovrSuccess)
        {   // Then we're connected to an HMD!

            // Let's take a look at some orientation data.
            ovrTrackingState ts;

            while (true)
                ts = ovr_GetTrackingState(session, 0, true);

                ovrPoseStatef tempHeadPose = ts.HeadPose;
                ovrPosef tempPose = tempHeadPose.ThePose;
                ovrQuatf tempOrient = tempPose.Orientation;

                cout << "Orientation (x,y,z):  " << COLW << tempOrient.x << ","
                     << COLW << tempOrient.y << "," << COLW << tempOrient.z
                     << endl;

                // Wait a bit to let us actually read stuff.


        // If we've fallen through to this point, the HMD is no longer
        // connected.

    return 0;

Will connect to your Oculus HMD (Head Mounted Display) using the Oculus 1.3.2 runtime, read the device's orientation and output that data to console, with the code structure essentially the same as for the previous v0.5.0 SDK example

The earlier Oculus 'Hello World' example connected directly to the device's raw sensor data, but that option is no longer being provided under the Oculus 1.3.2 SDK. Unfortunately, that's not the only limitation presented by the Production Oculus SDK.

If you enjoyed writing C++ programs for the Oculus DK2, I have some bad news for you.

The Bad News for C++ Development on Oculus

When starting the simple "Hello World" example provided above on your Oculus CV1 or DK2, you'll notice two things.

First, the Oculus Store opens:


Yes, that happens every time you connect to the Oculus, no matter how trivial your program is.

No, you cannot do anything to turn that off.

It's not an exaggeration to call this horrible: It's as if Logitech or Microsoft had set up a store to be shown on your screen whenever you plugged in your mouse and provided no means at all to be able to dismiss it.

It gets worse.

The second thing you'll notice is that your HMD displays a Health and Safety warning which occupies your Oculus screen until dismissed. You can dismiss that either by positioning a cursor on-screen for a few moments or clicking the "A" button on your Oculus XBox controller.

If you're developing software, that rhythm gets really old, really fast and, no, Oculus provides no mechanism for bypassing it.

Finally, after dismissing that warning, your HMD will display a "Please Wait..." message and, if you're looking to develop a simple console app to run alongside your Oculus, that's where things stop.

The Really Bad News for C++ Development on Oculus

...general C++ hacking with the Oculus Rift seems to have come to an end

Unfortunately, it appears the Oculus v1.3.2 runtime no longer allows console applications to run in parallel with apps on the HMD.

Even the trivial program shown above cannot run at the same time as an Oculus game or movie: If you start a console exe which connects to your Oculus HMD, any other active Oculus app will freeze and your HMD will be held at the "Please Wait..." screen until your exe is halted.

That might change in the future, with the blocking of external console apps hopefully being a temporary bug in the system rather than an obstruction put in place by Oculus by design but, for now at least, general C++ hacking with the Oculus Rift seems to have come to an end.

That's perfectly fine if you just want to play games and watch movies on your HMD but, if you're a developer who likes to play with their computer equipment and dream up options for parallel programs running alongside your apps, casual development on Oculus has now been stopped in its tracks.

Oculus No Longer a Developer-Friendly Tool

Unlike the DK2 we enjoyed hacking around with under the beta SDKs, the Oculus CV1 no long provides a nifty bundle of sensors we can interact with. Oculus now seems set to become a locked-down 'social experience' which exists to sell you stuff and track how you interact with your friends.

The terms of service for the Oculus are notoriously creepy with no promises that user data and activity history will be kept from targeted advertising in the future.

It's a little sleazy.

Not a comforting image, is it?
Not a comforting image, is it? Photo: Facebook

And more than a little disappointing.

The Oculus DK2 was fun and satisfying to develop with, but the production Oculus toolkit just isn't for me.

If you're wanting to build an app for Oculus, I would recommend sticking with a game development environment like Unity3D or Unreal Engine, as hacking around in C++ with the sensors and other nifty hardware bits seems likely to bring you frustration and pain with the current Oculus development tools.

For fun hacking around of that sort, it seems like it's time to turn to the HTC Vive and Open VR.

Setting Qt To Ignore Windows DPI Text Size Personalization

So, you have a C++ program with a Qt interface for Windows that you're releasing as a quick 'Version One'.

All is well and you're ready to ship... until you discover that DPI scaling in Windows resizes all label text by 125%, 150% or 200% while leaving buttons and labels at their set dimensions. The result with that scaling is an interface which is messy at best and unreadable at worst.

"Hey, no problem," you're thinking. "I'll just set Qt to ignore the Windows DPI setting and have the app drawn as we created it.

"Sure, the text will be smaller if the user is running Windows with a font scaled at 125% or 150% above normal, but everything will remain legible and laid out correctly in our app. We can revisit the GUI to do everything correctly later."

If this is a familiar tale for you, you already know there is no flag for setting Qt to ignore the Windows DPI setting.

What? Seriously?

Isn't there a way to tell Qt "Don't scale text to accommodate high-DPI displays"?

You've seen the forum posts chiding that a proper Qt GUI should use a scalable layout. You've read the smarmy comments claiming that slapping together a new GUI with layouts should be easy for an experienced Qt developer to do. So easy, in fact, that the lack of documentation on the subject and complete absence of examples should be no deterrent to a Qt developer looking to create a layout capable of automatic scaling with Windows fonts.

Gee, thanks.

Give Me a Qt Quick Fix for High-DPI Displays Already!

Sure, rewriting that 'Version One' Qt GUI with scalable layouts would be awesome and all, but I'm new to Qt, have a hard release deadline, no time, and the number of users currently affected by the issue can be counted on one badly mutilated hand.

A full GUI re-write for an app which might end up discarded is the least responsible thing to do right now. Isn't there a way to tell Qt "Don't scale text to accommodate high-DPI displays"?

Why, yes there is! You can explicitly set the size of fonts in your Qt app with font.setPixelSize.

For example, this:

QApplication a(argc, argv);

QFont font = qApp->font();

Will size all GUI fonts at 11 pixels in size regardless of the DPI settings on Windows.

It's simple, it's an imperfect solution, and it works.

Done. Ship it.

We can look at a proper font scaling solution and rebuild the GUI with Qt's DPI scalable layout magic after we've confirmed the app's Version One satisfies a genuine need.

Selecting a JavaScript Minifier (Spoiler: Microsoft Ajax Minifier Wins)

When I started writing JavaScript for production use, the final step in the process was selecting a minifier to wrap the code up to a tidy, ready-to-deploy bundle. Back in the day, the go-to for that was YUICompressor, but times have changed.

Goodbye YUICompressor

I've been using the YUICompressor JavaScript minifier for ages and it was time to update to a more current version of the tool.

Checking out the options, it turns out that YUICompressor (along with all other YUI tools) is no longer being supported by Yahoo as of August 2014. Not a good sign, but it seems the tool is still being supported by a third party so it should be good to go.

Giving the latest YUICompressor 2.4.8 a try, I was immediately presented with an error indicating that the tool could not find the source file to compress. A bit of searching showed me that this particular YUICompressor error in finding the input file's path has been outstanding since 2013 and appears unlikely to be addressed soon.

Hey, we all accidentally deploy bugs every now and then, but when something basic/essential like the input file path for a command line tool remains broken for over three years... Well, nature always finds a way to let us know when software is no longer being supported, and red flags like this are one of those little hints.

With that, it's time to say goodbye to YUICompressor and find another minifier.

So... Uglify?

An online search will quickly show that the go-to JavaScript minifier these days is Uglify.

To be pedantic it's 'Uglify2' (support for the original Uglify has been dropped) but everyone refers to the tool without the appended version number. Web searches for questions about 'Uglify' will usually direct you appropriately, but you'll want to watch out for confusion between 'Uglify' and 'Uglify2' when downloading: The original (abandoned) Uglify is still listed on GitHub.

Uglify works with NodeJS so, if you're like me and had not previously touched NodeJS, a quick detour is required to first install Node and get familiar with the basics before proceeding. This StackOverflow post will provide you with a bit of extra guidance on that if you're as new to NodeJS as I was.

Once NodeJS has been installed, the latest uglify-js package has been retrieved, and your computer has been rebooted to ensure all path variables are set for NodeJS, a run on the Windows command line:

uglifyjs -o destfile.js sourcefile.js

will provide you with a basic minification, with spaces, comments and carriage returns snipped out of the code. Function and variable names remain unminified.

I could not find the magic invocation syntax on Uglify which would bring about full code minification

The 'mangle' option in Uglify will apparently handle the minification of variable and function names, but I could not get that working for the life of me.

That seems to be a pretty common issue with Uglify, and some developers have been able to resolve those Uglify function/variable name minification difficulties, but I wasn't one of them. Try as I might, I could not find the magic invocation syntax on Uglify which would bring about full code minification, and the complete lack of use-case examples or even error output at the command line brought me nothing but frustration.

So, even though Uglify seems to be awesome for almost everyone else out there, it just wasn't the tool for me. Time to look elsewhere.

Chosen Solution: Microsoft Ajax Minifier

The next option on my list of candidates was the Microsoft Ajax Minifier (ajaxmin).

Ajaxmin remains under reasonably active development and numerous blog posts show it has been actively dogfooded through internal use at Microsoft for years.

The tool is a simple stand-alone exe command line utility and installation was a breeze: Just run the downloaded .msi file and everything is put place.

The ajaxmin 'getting started' documentation shows exactly what needs to be done to run the tool, and a quick command line entry of:

ajaxmin sourcefile.js -out destfile.js

Fully minifies the code.


Less than five minutes after I had started with this tool, not only were all comments, spaces and carriage returns snipped out of the production JavaScript, all function and variable names were minified as well. All of it done right from the basic command line option and without requiring third-party libraries, platforms, wrappers or a trip down the StackOverflow rabbit hole to find an obscure command to bring that functionality about.

No extra installs. No detours to minify JavaScript variables and function names.

It just works.

But wait! There's more!

A review of the superb documentation for the ajaxmin command line switches shows a number of analysis and testing options are provided with the tool as well.

Let's try the code analysis.

Using an example where the source, destination and analysis output are all retrieved from and output to the e:\ directory, this command:

ajaxmin.exe -analyze:out e:\analysis_output.txt e:\sourcefile.js -out e:\destfile.js

Provides a listing of all actions performed on sourcefile.js to create your minified destfile.js, with that output placed in the text file analysis_output.txt

If you've ever wondered how your minifier is mapping the minified names to your functions and variables, that analysis_output.txt will give all the answers you'll need.

Any undefined global references in your code will also be flagged by that analysis, so you'll want to clean up your output by excluding any external libraries you're referencing in the code. That can be done with the -global flag, as with this example for excluding references to the jQuery library:

ajaxmin.exe -global:jQuery,$ -analyze:out e:\analysis_output.txt e:\sourcefile.js
 -out e:\destfile.js

With that done, a scroll down to the bottom of your generated analysis_output.txt will point out any undeclared global references which may have escaped your earlier code reviews. It's a fantastically handy QA check.

The basic, bare-bones out-of-the box command line run of ajaxmin may provide all of the code minification you're needing.

If you need an even more extensive review of your code (and who doesn't?) you can also analyze your code with the "use strict" directive to point out any JavaScript which does not conform to the ECMA-5 standard. The -strict flag will handle that for you.

There are many other options available for further code obfuscation, such as explicit variable and property renaming, and those can be found through the ajaxmin command line switch documentation, or with use of the -? ajaxmin command line flag to display the available options. That flexibility is really nice to have, but you might not even need those more advanced options: The basic, bare-bones out-of-the box command line run of ajaxmin may provide all of the code minification you're needing.

In summary, the Microsoft Ajax Minifier provides absolutely everything needed for JavaScript code minification in a compact, clearly documented package. I cannot recommend the tool highly enough.

Upgrading Linux? Watch out for changes to the Java JSVC / Commons Daemon.

If you're using JSVC to run your Java daemon processes on Linux, watch out for the change in command options which come with upgrading your Linux distribution.

Shifting from Ubuntu 10.04 to 12.04 / 14.04 (which you should be doing now, as Ubuntu 10.04 reached end of life as of May 1st, 2015) is a simple enough process, but your Java daemons will likely refuse to start after your Linux upgrade completes.

There are two things to watch out for:

First off, if you're using OpenJDK, the Java path has changed between Linux distributions. Where the path was once at:


It is now set to be CPU-specific. For example, if running Ubuntu 12.04 / 14.04 on a Linode, you'll find your OpenJDK path is now at:


Any scripts you might have which referenced that old path for Java home will need to be updated, or else you'll be presented with a "Cannot locate Java Home" error when attempting to start your Java programs.

The second set of pitfalls relate to JSVC itself.

When calling JSVC, you may be presented with the error "JSVC re-exec requires execution with an absolute or relative path" when attempting to start your Java daemon. As described in that error message, it turns out the full path to JSVC now needs to be specified for the binary on daemon start. So, a command-line call to JSVC should use the full file-and-path of:


rather than just a call to the jsvc binary by itself.

For one final, sneaky change which might trip you up, the working directory for your Java jar also needs to be defined in the JSVC call's options.

For previous versions of JSVC, simply changing to the desired working directory prior to running JSVC was sufficient to define the working directory for the daemon, but that is no longer the case. The working directory must now be explicitly set using the -cwd option of the JSVC command.

it appears the -cwd option was mistakenly left out of the JSVC man pages

That might be a surprise to you if you've been reading the JSVC man page in an attempt to identify what has been going wrong with your JSVC-run Java jar, as it appears the -cwd option was mistakenly left out of the JSVC man pages. Until that JSVC man page omission has been corrected, I'd recommend a read of the command as documented at JSVC's page if you're looking for a full overview of the new JSVC / Commons Daemon functionality. You can find that page at:

Through that page, you'll discover that JSVC will set your Java jar's working directory to be "/" if the -cwd option is missing (thanks to Arkain on StackOverflow for pointing that out!), which will likely mess up any file i/o in your daemon.

To summarize all of the above with an example of the changes you might need to make to your JSVC call:

If you had a script on Ubuntu 10.04 to start via JSVC a Java jar myJavaProgram.jar using the daemon interface startJSVCDaemonProcess with working directory myWorkingDirectory, running as user myUser and writing out a PID at, your script might previously have read:

cd /srv/myWorkingDirectory

jsvc -user myUser -home /usr/lib/jvm/java-6-openjdk
-pidfile /srv/myWorkingDirectory/
-cp /srv/myWorkingDirectory/myJavaProgram.jar

To have the same functionality using the current JSVC / Commons Daemon under Ubuntu 12.04 / 14.04, you would need to change that script to read:

/usr/bin/jsvc -cwd /srv/myWorkingDirectory
-cp /srv/myWorkingDirectory/myJavaProgram.jar
-java-home /usr/lib/jvm/java-6-openjdk-i386
-user myUser -pidfile /srv/myWorkingDirectory/

By making those changes you will have:

- Called the jsvc binary using the full file-and-path;
- Edited the OpenJDK path for Java Home; and
- Added in the -cwd option to set the daemon's working directory.

You should then find your Java .jar daemon process running as before, but be sure to run your unit tests to confirm the environment change all the same.

First Project For Oculus Rift: An Audio VR Clock

With an Oculus in-hand, the first step was to see if I could somehow make an app which solved an actual problem for users of VR Headsets.

One of the first things I noticed was how easy it was to lose track of time in Oculus games, experiences and movies. Since a video overlay app didn't seem a good fit, using audio jumped out as a solution which wouldn't interfere with a person's VR experience.

The result? The Senomix VR Clock: A simple tool which responds to a user's headset taps and motions to announce time, sound/snooze alarms, and manage stopwatch and countdown timers.

Being audio, the app doesn't lend itself well to action shots, so this banner will have to do:

VR Clock banner

The app is just a beta release for now and is 100% free during the beta testing period. Cleanup of the initial audio recording and inevitable bugs will follow in the coming weeks (this is a true v0.1.0 beta release, rough bits and all) but, if you have an Oculus, I hope you'll give it a try and let me know what you think!

Tons of Empty HTTP POST Requests to Your Web Server? It's the Pushdo Botnet.

You're checking your Apache logs one morning and you're finding WebLogExpert taking a bit longer than usual to create your activity report.

That's strange. Maybe the log file was corrupted?

Checking your day's log, you find the file is over a dozen times larger than usual. Multiple megabytes over the usual size. After opening the file in your text editor, you find it full of nonsensical blank entries. Tens of thousands of lines of this:

[IP Address Removed] - - [21/Sep/2013:00:01:08 +0000] "POST / HTTP/1.1" 301 499 "-"
 "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)"
[IP Address Removed] - - [21/Sep/2013:00:01:08 +0000] "POST / HTTP/1.1" 301 499 "-"
 "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)"
[IP Address Removed] - - [21/Sep/2013:00:01:09 +0000] "POST / HTTP/1.1" 301 499 "-"
 "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)"
[IP Address Removed] - - [21/Sep/2013:00:01:10 +0000] "POST / HTTP/1.1" 301 499 "-"
 "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)"
[IP Address Removed] - - [21/Sep/2013:00:01:10 +0000] "POST / HTTP/1.1" 301 499 "-"
 "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)"
[IP Address Removed] - - [21/Sep/2013:00:01:11 +0000] "POST / HTTP/1.1" 301 499 "-"
 "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)"
[IP Address Removed] - - [21/Sep/2013:00:01:12 +0000] "POST / HTTP/1.1" 301 499 "-"
 "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)"

Uh, oh. For some reason, out of nowhere, a huge amount of garbage traffic has been arriving at your web site. Each an empty POST request, with the requests arriving from hundreds of different IP addresses.

Checking your web server's status through your control panel, you see a spike in CPU activity showed up along with those empty POST requests, making your report look something like this:

pushdo cpu activity

And your web server's disk i/o has also spiked:

pushdo disk io activity

It's not noticeably slowing your web site down yet, but it looks like that spike in activity is going to continue growing and it will soon affect your web site's performance. One way or another, seeing your web server spike in activity for absolutely no reason can't be good.

Is someone attacking? Is this the start of a denial of service? A prelude to some kind of cyber-extortion?

Congratulations. You've just found yourself the latest 'winner' of the Pushdo lottery.

Huh? Pushdo?

Before we start explaining how to fix things, let's take a look at the problem's cause.

You've probably heard of botnets: Networks of 'zombie' computers taken control of by viruses and joined together to do a variety of nasty things, from sending spam email to attacking web sites and taking them offline with huge bursts of traffic. The traffic you're seeing on your web site now is coming from one of those botnets. This one's referred to as Pushdo.

As explained through that link, the Pushdo botnet is an infrastructure of sorts to handle various computer crime tasks and, to hide its activity, it constantly blasts out traffic to make it difficult to spot the center of command for its work. Your web server is now receiving one of those bursts of network traffic.

For one analogy, you can think of Pushdo acting like a thief who has zombified the population of a small town to help hide his crimes. Using his zombie powers, the thief sets up thousands of people to constantly walk a city's streets and stumble into its buildings and houses. The zombies continue to stumble along, day and night, so that whenever the thief wants to rob a bank, he can just stumble off and quickly blend in with the crowd. Sure, the city streets would grind to a halt as those thousands of zombies milled about 24 hours a day, but it would be reasonably easy for the thief to perform whatever crime he'd like and then slip away in the crowds, stumbling along with the rest of the zombies.

That 'needle in a haystack' situation is similar to what you're experiencing with Pushdo. Your web server has become a house filled with zombies, with Pushdo stuffing it full of web site traffic arriving from thousands of computers to hide its activity from anyone who might try to figure out which computer was sending meaningful criminal information to the other.

Pushdo isn't attacking your web site directly, and your web server (probably) isn't infected with Pushdo itself. Your site is just an innocent bystander being used to hide activity.

So, why was your site chosen? Simple bad luck, really. Your site was one of hundreds picked at random from the world's DNS records, and now you're the target of traffic from thousands of botnet computers.

How Do I Stop This Surge in Zombie Traffic?

The bad news is, you can't stop the surge itself and it's probably going to continue hammering your web site for the next few months -- possibly the next few years. Pushdo will continue to hide its activity by using your web site as a random target and it will only stop once your site rotates off the list of zombie destinations used for camouflage.

While you can't stop the traffic at its source, you can configure your web server to ignore the traffic as it arrives

However, while you can't stop the traffic at its source, you can configure your web server to ignore the traffic as it arrives. The tens of thousands of zombie messages will still come knocking at your web site every day, but you can set your computer to block those messages the moment they arrive on your network and keep them from reaching your web server.

To do this, you'll need to set up a firewall rule to block all traffic which fits the Pushdo message signature.

Using iptables to Block Pushdo

We're assuming here that you're running your own web server on Linux, either as a stand-alone computer or through a hosted VPS package with Linode, Slicehost or another provider. If your web site is instead being managed by a full-service hosting provider, your best action would be to contact your server support team and have them apply the appropriate traffic-blocking actions for you.

Continuing with the assumption that you're running your own web server on Linux and have full control over that computer, here's an overview of how to fix your Pushdo problem:

To block the zombie network traffic bombarding your web server, you're going to use iptables. The iptables utility is a network packet filter which you can use to regulate internet traffic. Linode provides an excellent overview of the package in their documentation, and the raw help text for the tool can also be reviewed direct through the "man iptables" command on your server computer.

Watch out! Since a mis-configuration of iptables can also block legitimate traffic (even your own login), you will want to review the documents linked above to gain a better understanding of exactly how the utility works before applying the examples given here. It's really easy to accidentally set iptables to block all network traffic arriving on your web server and, since such a mistake would block any attempts you might make to fix things, that could lead to irreparable disaster. Trust me: It's worth the extra bit of effort to look over the documentation and understand at least the basics before proceeding.

Have you read those guides over? Good. Let's put them to work.

In reviewing those documents, we can see that it's very easy to configure iptables to block individual IP addresses. That's really helpful if there's a particular nuisance source of traffic you'd like to block but, in this case, the Pushdo traffic is arriving from many thousands of different IP addresses and it would be extremely tedious to enter a blocking rule for each of them every time a new address showed up.

What we're going to do instead is block the arriving traffic based upon its contents. As you might have noticed when examining your Apache logs, all of the Pushdo traffic has the same general signature of:

[IP Address Removed] - - [21/Sep/2013:00:01:08 +0000] "POST / HTTP/1.1" 301 499 "-"
 "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)"

For all of the messages received, there's a consistent POST command of either:

'POST / HTTP/1.1'
'POST / HTTP/1.0'

So, if we can detect that particular bit of text in a received packet, and that text is not used in any legitimate traffic accepted by your web server, we can safely set up a rule to block anyone sending a message which contains that particular blurb of text.

Ah! But your own web site might have legitimate traffic with that same signature! Before implementing this particular fix (which worked for us, as there were no legitimate POST requests on our own web server which were blank), you will want to search through your past Apache logs to confirm the text being scanned for is not used by legitimate visitors to your site. If it is, you would best select additional criteria to examine for blocking the message (for example, adding in the 'MSIE 6.0; Windows NT 5.1; SV1' bit, since blocking users of IE 6 who send along POST requests is probably not going to nab legitimate traffic).

The iptables Commands to Use For Blocking Pushdo

To block the two snippets of text identified above, you will want to apply the following iptables rules as root (preferably, using sudo):

iptables -I INPUT -d [your web server IP address] -p tcp --dport 80 -m string --string
 'POST / HTTP/1.1' --algo bm -j DROP
iptables -I INPUT -d [your web server IP address] -p tcp --dport 80 -m string --string
 'POST / HTTP/1.0' --algo bm -j DROP

Where [your web server IP address] is the IP address of the web server computer on which iptables is running.

Taking a look at the contents of that command, this is what it is doing:

iptables : running iptables
-I : inserting a rule
INPUT : for packets going to local sockets
-d [your web server IP address] : heading to the computer with this IP address
-p : now, here comes the rule:
tcp -dport 80 : for tcp traffic arriving on port 80
-m string : use the string module
-string 'POST / HTTP/1.1' : so that any traffic matching the string 'POST / HTTP/1.1'
-algo bm : which we're identifying using the Boyer-Moore (bm) string-matching algorithm
-j DROP : will immediately jump to the DROP rule the moment it's spotted.

After applying those rules to iptables, any network activity spotted which contains the text 'POST / HTTP/1.1' will be dropped immediately, closing your web site's door to those zombies.

So, What Next?

With the iptables rules applied, you're done. Pushdo traffic will still come knocking at your web server with zombie traffic, but iptables will prevent that traffic from entering your web site. You can confirm that by checking your web server's log files a few minutes after applying those rules: You should see the blank POST entries suddenly stop.

Your computer will still show higher CPU and disk I/O usage than usual, it just won't be as bad as it could have been and (with luck) won't noticeably affect the performance of your web site. For one example, the charts shown in the earlier part of this article display the result of applying those iptables rules the day Pushdo traffic first arrived on our site. In our case, there was an initial dip in CPU usage as the first round of Pushdo traffic was handled, followed by a surge as the real torrent of zombies arrived. Our iptables utility was kept pretty busy that month, but website performance was not affected.

Remember: Your iptables rules will be cleared out after every reboot of your web server, so you must be sure to apply those rules after every reboot. If you don't yet have a checklist of steps to follow whenever rebooting your web server, now would be a good time to create one.

Your iptables rules will need to remain in place until Pushdo moves on from your web site, and that will probably be quite some time. I'd recommend adding a note to your server reboot checklist reminding you to leave out your Pushdo iptables rules every three months to see if that unwanted traffic has disappeared. After rebooting your web server with those rules removed, you can then check your Apache logs after an hour to see if those telltale blank POST messages are still appearing.

You should find that the Pushdo traffic drops off in intensity after about six months but still remains in place for a bit over a year after its first appearance. However, one day it will disappear completely and, when that day comes, you can stop applying those iptables rules to your web server.

Be patient. Being a target of Pushdo is a pain, but there's nothing that can be done about it but to batten down your web server's ports and leave iptables to do its filtering job.

Oculus Rift Virtual Reality Initial Impressions

Here are my impressions after having the Oculus Development Kit (DK2) in-hand for a bit over two weeks now:

The Technology Behind Oculus

The hardware itself will be familiar to anyone who has developed software for a touch screen phone. Described generally, the head-mounted display is a cell phone screen placed in a headset mount. A gyroscope, magnetometer and accelerometer provide instrumentation, with an accompanying camera used to identify the position of the wearer's head. In all, the DK2 seems a perfect example of innovation, where the device introduces no new technologies but is instead a recombination of existing parts to create something wholly new.

oculus dk2
A remarkable innovation of existing technology

That doesn't in any way diminish how much of a marvel the device is, but it does suggest that, as with cell phones, VR headsets are likely to drop in price when created in volume and may be expected to improve in quality at a rapid pace.

Oculus Immersion

The screen's low resolution does produce a bit of a 'screen door' effect, with the LCD pixels very easy to see. The sensation is a bit like sitting too close to an old CRT television set. Since the DK2 is a prototype development kit (and not the final product) that lower image quality wasn't surprising, and I found the immersive experience of the headset allowed me to very quickly dismiss quibbles about resolution.

The sense of presence is very effective. Even with the 'seated at a desk' test display, I found myself reaching out to confirm that what I saw on the desk before me wasn't actually there . It's clear that the environment one is looking at is a set of video game graphics, but one's mind is easily convinced that what is being seen is actually real.

ocean rift
Feel like you're swimming in the ocean while seated at your desk

Along with that immersion, an awareness of my actual surroundings disappeared almost entirely at times, and I sometimes found myself startled to feel my hands touch a desk or chair when my eyes saw open air around me. I'm not sure if I would trust myself walking with a VR headset, and it will be interesting to see how Steam VR overcomes that sense of displacement from reality with their own plans for a headset which encourages standing, mobile user operation.

In the virtual environment, I felt a sense of apprehension whenever deliberately putting myself in danger. For one example, when swimming about in the Ocean Rift demo, I was reluctant to descend into the depths where the giant shark (which you're warned about) was waiting to attack. Even though I was obviously not really swimming beneath the waves and diving deep into a dark ocean trench, it was a spookily genuine experience all the same. Given my uneasiness with something so tame and G-rated, there is no way in hell I'd play a horror game like Alien Isolation in VR.

It will be interesting to see if that sense of dread diminishes once my brain becomes accustomed to the VR environment and learns about a new thing it can safely ignore. I remember telling my friends about the sense of total immersion I felt playing a pixelated 3D Quake, 640x480, on a 14 inch monitor, and I can't help but wonder if my initial Oculus experiences will sound just as exaggeratedly real when looking back on this technology in the future.

So real! It's like you're there! (It felt like that in 1995. Honest!)

Surprisingly, the various roller coaster demos (which famously freak people out) did very little for me. I'm the type of heights-dreading person who feels apprehension just watching a parkour video and ends up with sweaty palms after playing a game like Mirror's Edge on a regular monitor, but I found the Oculus roller coasters to be a bit underwhelming. I suspect that will change once issues of judder and resolution are resolved.

Oculus Nausea

The nausea experienced when first using the DK2 was surprisingly intense. Just a few minutes of wandering around the low-intensity Tuscany Villa demo had me feeling queasy, and about 10 seconds flying in the AirDrift demo almost made me vomit. Regardless of the settings or passiveness of the environment, for the first few days it was not possible for me to use the DK2 for more than a few minutes at a time. An extended period of use would see me wearing the device for no more than 10 minutes, and only with tremendous effort.

Tuscany Villa
Quiet, peaceful, and more nausea-inducing than an economy-class flight through a thunderstorm

The nausea was of a surprisingly intense and persistent sort. Whenever I've experienced motion sickness when playing games, the sensation tended to grow gradually and quickly diminished once I'd left the computer screen. However, VR sickness seemed to onset immediately and persisted for a bit over two hours after I'd left the device behind. A sense of dizziness and unsteadiness remained after taking off the DK2, and I'd recommend anyone looking to try a VR headset ensure they're not needing to operate machinery or a vehicle for a few hours after their first attempt -- I'd never have trusted myself in a car or on a bike at that point.

The nausea and dizziness was so intense at first that I was concerned I would not be able to use VR at all. Fortunately, this has turned out not to be the case.

One quickly learns not to change position too quickly while wearing the VR headset. The sensation when swiftly turning my virtual body's view about was as if blood were being pressed to the side of my brain to cushion it from a sudden shock. Whether that was an illusion or an actual reaction from my nervous system is something I'll leave to the biologists and physicians, but the unpleasantness of the experience was very real.

I gained my 'VR legs' rather quickly and the discomfort was considerably reduced after a week of occasional use. Nausea diminished with each session using the DK2, and use of it for extended periods (30+ minutes) after about 10 days barely registered any sense of discomfort at all. It then became possible to skip through the various Oculus demonstration apps with ease and play games for an hour or so at a time without any difficulty. Flying in AirDrift became a breeze. Use of the device soon began to feel so natural that I would have likely misremembered my earlier nausea as being considerably less intense if I'd not made notes about it at the time.

Give it a few days, and even flying through the air starts to feel natural

It's unclear to me whether my diminishing nausea was due to my senses growing accustomed to the VR environment, or my having optimized my computer's drivers and configuration to ensure the DK2 was being used in the best possible fashion. Others who have tried the DK2 device on my computer after I had finished its configuration and video driver optimization experienced no nausea issue whatsoever. So, either I should have spent more time configuring my system's drivers and DK2 configuration before starting to use the device, or I was just an unlucky outlier who was particularly susceptible to VR motion sickness.

Gaming With Oculus

The Direct to Rift mode for the DK2 worked flawlessly, with all games and tech demos suited for that mode running without issue. However, setting up Extend Desktop mode on my own computer to use Steam was a difficult experience which reminded me of the 'DLL hell' presented when installing a video card on Windows 3.1. That difficulty is no fault of Oculus or any other hardware/software vendor: The DK2 is beta development hardware, and my difficulties could have come from a variety of sources, from video card drivers to my monitor setup under Windows. I only mention these issues as a reminder that the DK2 is not consumer hardware: Everything might work for you right out of the box at this point, but anyone who purchases a DK2 should be prepared to spend a good amount of time configuring their system to ensure it works correctly.

Half-Life 2 Headcrab
It turns out these guys are actually kinda big

Once Extend Desktop mode was enabled for my DK2, I tried out Half-Life 2 using Steam's beta VR client and found the game a new experience entirely. The screen door effect is still there, with pixels visible when you're looking for them, but the sensation of actually feeling 'inside' the game allowed me to quickly set that roughness aside. Even though the game was familiar to me, the VR immersion allowed me to pick out scenery details I'd not seen before, and I gained a sense of scale of my surroundings which had previously been missing -- I had no idea head crabs were so big!

Video With Oculus

Virtual movie theaters and home entertainment setups seem to be one of the most popular initial applications of VR displays, and I believe video will end up becoming the most popular use of the Oculus and similar devices in the future. Even early in my use of the device, I did not feel nausea when using the DK2 to passively view video and that use seems likely to be the gateway through which wider adoption of VR headsets will occur.

A personal, isolated virtual movie theatre

The ability to set whatever environment one would like for movie viewing (whether in a living room, your choice of theater and row, or just a floating screen), combined with the full sense of immersion and lack of interruption from the outside world delivered by the headset provides the possibility of a perfect movie experience. A VR display delivers the option of viewing regular two-dimensional or fully 3D video in whatever format one would like, whether an IMAX-sized screen, a fully surrounding 3D environment, or a small corner television set, all while remaining seated or reclined in a favourite chair, couch or bed. The low resolution of the DK2 still delivers the feeling of sitting a bit too close to an old CRT television, but the higher resolution to be expected from the consumer Oculus device will likely resolve that distraction entirely in time.

There is also the possibility of interactive movies, or fully 360' degree movie experiences which put you in the role of a character of your choice. The Birdy King Land Oculus demo gives a really good example of that -- you're a character IN the movie. However, as fun as interactivity and gaming is with the Oculus, easily delivered passive entertainment seems likely to become the 'killer app' for head-mounted VR displays. Often, people just want to lie back and relax, and a personal, isolated virtual movie theatre has the potential to perfectly deliver that experience on-demand.

Oculus Tips From Experience

If I could go back in time to the moment I started using the DK2, I'd give myself these bits of advice:

You should use the Rift configuration tools to set your Inter-Pupillary Distance (IPD) rather than using the value measured for your glasses. IPD for the Rift (and presumably other VR headsets) should match the value used when your eyes are focused to infinity (informally confirmed here by Oculus Founder Palmer Luckey), which is what the configuration tool provides. Using the IPD value set for your glasses will probably be incorrect.

Ensure your video drivers are up to date. If using an NVidia card, install and use the NVidia 'GeForce Experience' tool to simplify the upgrade of your video drivers. It saves a lot of hassle when identifying and applying the correct driver version.

Contact lenses are helpful but not necessary if you can see well without glasses. With natural eyesight, I would be incapable of reading a cell-phone held at Oculus distance from my eyes, but the corrective optics of the device's lenses extend that distance to remove any difficulty with viewing. VR resolution isn't sharp enough yet to justify concerns with fine visual detail, but that will probably change with consumer versions of the device.

Be sure to move slowly in the VR environment. If you're used to flicking the mouse around for a quick change in orientation in first-person shooter games, using the same gesture to move about in VR will probably feel uncomfortable at first and lead to nausea.

If you're taller than average, set the Player Height value in the Oculus settings to be lower. The people creating Oculus games and experience demos are likely to be of average height, and the environments will often feel uncomfortably cramped (as if you're about to hit your head on the ceiling) if they are set to take into account player height. Just set your configuration height at 5'5" and you're good.

Should I Buy An Oculus Rift DK2?

If you're looking to develop VR software right now then, yes, you should buy an Oculus DK2. You should be prepared to fiddle with system settings, drivers, incomplete documentation and the other hassles which come with being on the 'bleeding edge' of a technology, but the device is good to go for development.

If you're considering the development of VR software, are curious about the experience or just want to play games with the system, you should wait. The consumer versions of the Oculus Rift are going to be superior to the development kits in pretty much every way, and might even be less expensive at first. It will be worth the anticipation to wait a few more months for those to arrive since, once consumer versions of VR headsets are available, the early implementations now available with the Oculus DK1 and DK2 are probably going to be set aside to gather dust.

To Main Page
Back To Top
To Blog Archive