The Lenovo W530 with Optimus Technology and Linux

Recently my 2008 Mabook Pro died.  Although I ended up fixing it as documented in this HOWTO I had been searching for a new laptop anyway and this was just the catalyst I needed to make a move.  After some searching I came across the Lenovo W line.  The machines appeared to be built tough, pack plenty of power, just light enough to carry around on occasion and support Linux fairly well.  I settled on the W530 with mostly stock specs and an upgraded full HD screen.

Out of the box the machine runs really well.  I’ve played with Arch, Archbang, and Ubuntu and everything is (of course) quite snappy.  The only real issue with this machine is its graphics card, which runs Optimus technology; a poorly named feature that means: “optimal use of graphics card considering battery life”.  Essentially software will decide when to turn on the power hungry NVIDIA discrete graphics card.  I spent many hours trying to figure out how best to setup Linux to use the graphics card in this machine.  Hopefully my thoughts will save you some time or aid in your decision to purchase or not purchase this machine.

On the W530, you may select whether you wish to use the discrete, integrated, or optimus graphics in the BIOS.  This is a great feature of this machine, and although you might expect that its availability is ubiquitous among laptops, some of the forum postings I have read lead me to believe that this is not the case.  Anyway on the W530 we can avoid configuring and installing anything related to Optimus simply by selecting either the NVIDIA “discrete” graphics card or the Intel “integrated” graphics.

If Optimus technology is desired, there is an open source project called Bumblebee that will allow you to start applications so that they use the discrete graphics card (in this case you would select Optimus in the BIOS).  Installation instructions are available for most major Linux distributions.  On Ubuntu I was easily able to start Minecraft in this manner.

Now for the quirks:

1.  The Nouveau open source graphics card driver does not offer OpenCL support (and will fall back to software rendering) for the NVIDIA series code named “Kepler” which includes the K1000M and K2000M, one of which is included in the W530.  See the Feature Matrix.

2.  The NVIDIA proprietary drivers work quite well (and include OpenCL support) unless you are running Kernel 3.10.  This is not an issue for many distributions but is causing a serious headache for Arch Linux and other users on bleeding edge Linux distributions.  See the Arch Linux forum post and the NVIDIA forum post.  NVIDIA claims this issue will be resolved on the next driver release.

3.  The VGA output is wired into the discrete graphics card, which means you must be running this card to use multiple monitors.

The last quirk I never got to the bottom of.  I observed that when I ran the graphics in Optimus mode under Ubuntu I *could* use an external monitor, but the screen settings were hard to nail down and the cursor left a trail behind it.  In any case it felt clumsy so I didn’t investigate further.

Given these quirks, what is the result?  For my use case, I will never need to use an external monitor without a power source, so selecting discrete graphics at start up is fine.  When I am out I can use Bumblebee, although I have not found a real need as I rarely employ graphics intensive applications.  I use Ubuntu and Arch, and for now will be booting Arch with the integrated graphics.  Sooner or later either NVIDIA will fix the issue or Nouveau will support OpenCL.

All in all this is an amazing machine.  I am most impressed by the build, as nice specs are not hard to come by.  Its screen is beautiful, Its keyboard has a great feel and has 3 back-light settings, and the laptop as a whole is highly upgradeable.  If you can deal with a few graphics card quirks this is a stellar Linux laptop.


Serving up geospatial data from the Ec2 cloud

Ec2 Free Tier

Recently I’ve been building a Debian Squeeze image on Amazon’s ec2 cloud for free (  The purpose (aside from messing around) is to develop a nice POC (proof of concept) platform on which to stage geospatial web services (viewing, analysis, hosting, etc).  Theoretically, whatever I build can be extended and expanded in terms of power and space so time well spent.

Ec2 has come a ways since I first started playing with it a few years ago.  Aside from offering a dizzying array of services, the AWS management portal has become full featured and very useful.  Needless to say I didn’t bother to install the ec2 API this time around.  The goal here is to get up and running, plenty of time to automate the client end of this down the road.

Getting Connected

Getting up and running was pretty straightforward.  Sign up for an account, navigate to the ‘quickstart’ guide buried in ‘Documentation’, alter the instructions slightly (I prefer to use a Debian image rather than the guide’s default image), and log in.  The only issue I ran into was permissions on my machine when using the public key to access the remote server (ssh -i key.pem <server>).  Without knowing it my public key was not being read by ssh, so the server was asking me for a password (which nobody has) and I was fairly confused.  The solution:

sudo ssh -i key.pem <server>

I’m not exactly sure why this works ('vim key.pem' reads the file).  Maybe its a Mac thing.

Installing your software

Now that we’re logged in, we can begin installing and customizing our image (best practice is to create a user and sudo your way to glory).  We’re going to use GeoServer to serve up our GIS data, so we’ll need Java.  Depending on your linux distro you’ll have access to different packaging tools.  I’m a big fan of apt (Debian, Ubuntu, etc.):

apt-get install sun-java6-sdk

If you have a permissions problem ‘sudo’ before the previous code.  Now that we have Java up and running, let’s get GeoServer ( up.  Grab the universal binary from the downloads section:


This will plop it in whatever directory you ran the command from.  Geoserver is self contained in this form.  Unzip it:

apt-get install unzip
unzip geoserver_plus_version

Move into the directory and check out the README.  Long story short, you need to go into bin/ and run the startup script.  before you do so you’ll have to deal with JAVA_HOME.  The quick and dirty way:

export JAVA_HOME

Best to stick that somewhere that runs on startup, but that’s out of the scope of this article.  Also note the path to Java above works on Debian Squeeze with Sun’s JDK.  If you deviated from the instructions you’ll have to find it yourself.

Ok!  Assuming all went well navigate your way into geoserver_plus_version/bin and:


You should see GeoServer setting itself up.  Head back to the AWS management console and navigate to ‘Security Groups’, ‘your group name’ (could be ‘default’) and edit your security rules so that all ips can access port 8080 (  Make sure to click the ‘Apply Rule Changes’ button or your changes will not take effect.  Type into your web browser:


Where <server> is the address you used to connect to the server via ssh.  If all went well you should see GeoServer’s default startup screen!  Impress your friends by going to ‘layer preview’ and clicking on an ‘OpenLayers’ link and pasting the ridiculously long URL into Skype or gChat!

What Now?

That’s really up to you.  I installed PostgreSQL 9 and PostGIS for GeoServer.  For me this is a sandbox / development machine I will use to show friends what I’m up to.  There’s no reason why a dynamic DNS server script couldn’t be installed and a web presence maintained (although there are some security issues to work out prior).  A final tip:

The default EBS storage space is 1 Gig.  I was able to get GeoServer up and running without issue.  However once I started installing PostgreSQL I ran out of space rather quickly.  To increase your space use the AWS management console and navigate to ‘EBS Volumes’.  Take a snapshot of your volume (while the instance is running) and use it to make a new EBS volume (free tier will allow 10 Gig).  Stop (don’t terminate) your instance, detach the 1 Gig volume and attack the 10 Gig volume to ‘sda1’.  Startup the instance, log in, and enter the command:

resize2fs /dev/xvda1

This assumes your device is name ‘xvda1’.  You can check with:

df -h

Essentially you are telling the operating system to check the size of the hard drive, as it has changed.

Have fun!