An adventure with Chef
I hear a lot of people talking about automated deployment with Chef (and its competitor Puppet, which I haven’t had the chance to try yet), so I thought I’d spend some time seeing how it would fit in with our image management platform Server3.
Don’t stray from the PATH
To get familiar with Chef, I dove straight into the online quick start guide, and ended up making a couple of trying too hard errors:
- I began by installing Chef onto an Ubuntu VM, but when it came to the bits of the quick start that used Vagrant it became clear that I needed something that could poke and prod VirtualBox from its host environment (Windows). I went back to square one and installed Chef (and Vagrant) onto the base OS.
- My second mistake was installing onto non-default directories. I find it pretty offensive when stuff wants to go into c:\, and the tidy freak in me likes to put stuff that doesn’t go straight into c:\program files (or c:\program files (x86)) into subdirectories like c:\dev or c:\temp (depending on how long I expect to keep stuff). Chef did not like being in c:\dev\chef – none of the scripts worked. When I looked closely all of the scripts were hard coded to c:\chef – an automated installation system that can’t even install itself cleanly – hardly confidence inspiring. I ended up switching to a different machine, started from scratch, and accepted the defaults.
When I kept to the PATH the quick start worked. I had a VM that had been summoned up out of nowhere that would converge onto some recipes. The time had come to get under the hood, figure out how this thing really worked, and apply it to something of my own creation.
Architecture expectations – ruined
The published architecture for Chef is pretty much what I expected, and consists of three core components:

- Server – a place where configuration (expressed as recipes and roles) is stored.
- Nodes – machines that connect to a server to retrieve a configuration.
- Workstation – a machine that’s used to create and manage configurations kept of the server (using a tool called Knife)
Conceptually this is all well and good. Some configuration is created from a workstation, placed on a server, and nodes come along later and converge on their given config. Unfortunately there are a couple of holes in the story:
- Chef installation on a node. The best documented method for doing this is using the Knife tool (which essentially logs into the node via SSH and runs some install scripts), in which case we have (real time) connectivity between the workstation and node before the node ever connects to a server.
It is possible to do things differently, and there are downloadable install scripts plus descriptions of using OS packaging mechanisms and alternative approaches to getting the Chef Ruby Gem installed, but it feels like this is all off the well trodden path. - Bootstrapping a node. A node needs more than just the base Chef client install. It needs to know which Chef server to connect to, have some credentials to authenticate itself and know which role(s) and or recipe(s) to configure against.Once again the usual approach seems to be to use Knife from a workstation to create the appropriate files and SCP them into place on the Node. It is of course possible to get the files in place by other means.
The dependence on a real time relationship between the Chef workstation and a node before it even connects to a server leads me to believe that Chef is mostly being used in dev/test environments that are being driven by humans. If that’s what DevOps is then it seems like we need another name for fully automated deployment an configuration management in a production setting.
Bundling into Server3
Firstly I should explain what I was trying to achieve here… The idea was to create a VM image that would converge on a Chef role as soon as it was launched. There’s a longer term goal here of doing convergence within the Server3 image factory (but we’re not quite ready yet with the underlying metavirtualisation required for that).
I ended up creating two packages:
- An archive to go into /etc/chef containing my validation.pem, a client.rb pointing to my Chef server and a first_boot.json with a run_list pointing at a role configured on the Chef server.
- A run on first boot script with the Chef install.sh with the like chef_client –j /etc/chef/first_boot.json appended to the end so that Chef would run once installed and converge onto the defined role.
With those two packages in a bundle I was able to add that to a VM recipe and deploy straight to a cloud (AWS) for testing. It was nice to be able to connect to a VM after launch and find it converged and ready to run.
Next – Inception
Convergence on launch is nice, but it would be better still to launch a pre converged machine – after all if you’re adding machines to grow capacity then it’s probably needed now rather than in however long it takes to install Chef and converge on a role or recipes. This capability should be coming soon to Server 3, and we’re using the label ‘inception’ to define what happens inside the image factory – planting dreams inside the VM’s head.
Conclusion
Chef can be made to work like I expected it to, which makes it possible to have an image that converges when first launched without any human intervention. Going by the weight of documentation this doesn’t seem to be how most people use Chef though – DevOps appears to involve having an actual developer involved in their operations. We need another name for fully automated production operations.
This is cross posted from the original on the CohesiveFT blog.
Filed under: cloud, CohesiveFT, technology | Leave a Comment
Tags: aws, Chef, development, DevOps, image automation, image management, Inception, Puppet, Server3
A lack of discretion
There’s been a lot of Monday morning quarterbacking over last week’s shutdown of Boston during the pursuit of terror suspects. I have my own opinions about what went on, but don’t feel this is the time or place to get into that.
The point of this post is to examine whether if many (or even any) of the people involved really had that much discretion. If there was a common sense path to be taken, then was it even permissible to take that path? I’ll illustrate with a personal anecdote of a terrorist attack that never was.
My last appointment in the Royal Navy was as a section officer at HMS Collingwood, which at the time was the RN school of Communications and Weapon Engineering (it is now much more besides). My day job was to manage all of the training relating to Type 22 Frigates, but one of the delights of military service is additional ‘duties’. The main duty I was expected to perform at Collingwood was Officer of the Day (OOD) – the officer responsible for the safety and discipline of everybody at the base (in the absence of the usual chain of command when everybody else packed up for the day at 4pm and headed home).
A typical day for an OOD was mostly ceremonial – Rounds (making sure that the new trainees were keeping good order), Sunset (saluting whilst somebody pulled a flag down), and Colours (saluting some more whilst somebody pulled the flag back up). The safety and security stuff was mostly taken care of my a sizeable contingent of (armed) Ministry of Defence (MoD) guards and MoD policemen who would patrol the perimeter and interior of the base and inspect the identities and vehicles of those passing in and out.
Late one night I got a call. A routine perimeter patrol had turned up something the policemen weren’t happy with. In a field next to the base (not too far from the perimeter fence) was a large flat bed truck with a huge electrical transformer on it. My presence was demanded to evaluate what was going on.
The truck was clearly out of place, off a proper road. It also had foreign plates. Attempts were made to contact the trucker who might be sleeping inside, no answer[1]. Attempts were made to call the trucking company, no answer (though it was no surprise that nobody was answering the phone somewhere in Spain during the early hours of their morning). The civilian police were contacted to see if they could scare up any information about the truck, but that was going to take hours. It soon became clear that the truck wasn’t going anywhere quick, and we weren’t learning any more about it any time soon.
The policemen were concerned that the transformer could be a disguised mortar launcher. I was certain it wasn’t. My analysis was thus:
- As a frontline engineering officer my team was responsible for all manner of electrical conversion equipment. I knew what the real thing looked like.
- The tubes at the centre of the transformer (that the policemen were most bothered about) were pointed straight up. Mortars have to be pointed at something.
The transformer was much larger than this, but this cutaway gives a good illustration of how a big transformer might have large pipes running through the middle
I had a decision to make. I could either:
- Play it ‘safe’, treat this situation as a terrorist attack in progress, and evacuate the base[2].
or - Use judgement based on over half a decade of training (and latterly teaching) in areas of weapon system design (manufactured and improvised), explosives and (battle) damage control to determine that I wasn’t looking at a weapon system for some terrorist plot, tell everybody to stand down, and go back to bed.
I chose to stand down. The MoD policemen kept a close eye on the truck through the night.
Nothing happened.
I think the trucker might have had a talking to when he finally emerged at first light from the back of his cab and tried to figure out where he was supposed to be going[3].
I got more than a talking to when the Base Security Officer (BSO) grabbed me after the morning Colours (pulling up the flag) ceremony. The message was clear – how dare I use my discretion and professional judgement when there was an element of risk involved. I should have evacuated the base and kicked off a major police and military operation. The cost and inconvenience were as irrelevant as my opinions. I should have erred on the side of caution.
The BSO then let me into a little secret. He was privy to some intelligence reports from a few years back (which had never been used to brief front line officers like myself) relating to an IRA plot to bomb electricity substations around London in an attempt to disrupt the capital. Aha. It was all clear then – if a terror group once tried to blow up some transformers, then we should be extra scarred of transformers blowing up. How could I argue with logic like that? I thanked him for his trust and insight and returned (bewildered and late) to my desk and business as usual. A few thousand other people were already getting on with their day as usual because I’d made the wrong call.
Conclusion
I used my common sense, my judgement, my discretion and I got in trouble for it[4] – even though that type of decision was exactly why we had an Officer of the Day in the first place. I’m sure many of my colleagues would have called it differently – particularly those lacking front line experience or easily bullied by the gun toting security types. I’m also sure I made the right call based on what I saw in front of me, and what I knew. The trouble is that every incident like this becomes a lesson not just for one person on duty, but whole groups of them – discretion will get you into trouble, don’t take any risks, play it safe; and progressively we eliminate discretion – even from the hands of those that do know better.
Notes
[1] If I was a lost trucker parked in the middle of nowhere I’d probably ignore any commotion outside and hope it went away.
[2] It should be noted that this was back in the early days of the Northern Ireland peace process. After almost a decade in service I was finally allowed to wear my uniform in public without fear of being bombed or shot at, but the old habits and attitudes died hard (on both sides), and dissident terror groups were still active. Mortar launched bombs had been a frequent tool of choice for attacks against military and police bases in Northern Ireland, but had never been used on the mainland.
[3] One of my other considerations was my own recollection of my first visit to Collingwood – driving around in the dark along unlit peninsular roads with farmland on either side (in the days before mobile phones and consumer GPS) – it was all too easy to go from motorway to completely lost.
[4] I’ll never know if this episode was a ‘career limiting move’. I was already serving out my (substantial) notice period with an eye on a future life in IT management. It was therefore hard to get too bothered about a chewing out from a retired officer who chose to still wear his old uniform to work each day (even if he did happen to send his concerns up the chain of command).
Filed under: security, wibble | 2 Comments
Tags: bomb, common sense, discretion, Navy, terror, transformer
More memory, better performance
Since I was so happy with the HP 650 business laptop that I got for my wife, my father in law decided to get one too.
I was surprised to find that the Windows Experience Index (WEI) was so much slower than I’d seen on my wife’s machine:
It’s no surprise that the memory benchmark is down, as I expect that a second DIMM improves overall system bandwidth, but it seems that 2D graphics are also affected. I suggested that he got another 4GB PC12800 SODIMM. It worked:
So it looks like even if you’re not using memory intensive apps then overall system performance can be improved by adding extra RAM.
I wonder if performance would be the same with 2x2GB, and whether this applies to all systems with Intel integrated graphics?
Filed under: technology | Leave a Comment
Tags: bandwidth, benchmark, Core, DIMM, experience index, GPU, HD3000, i3, Intel, performance, RAM, SODIMM, WEI, Windows
Sous Vide Roast Beef redux
Last week I cooked tri-tip with my Raspberry Pi controlled water bath. This week I used a much more ordinary cut, some topside from my local Co-Op supermarket that had cost me just over £5 for 1.6kg. Some time ago I stopped buying this kind of meat because if you cook it per the instructions on the packet it comes out like shoe leather. I wanted to see if high end cooking could make up for low cost meat. TL;DR – it does.
I got some Raspberry Pi boxes over the last few weeks, and cut a hole in the lid of one to allow for the 434MHz transmitter and DS18D20 connector to stick out:
I woke up early (6.30) and put the meat on then, so it got almost 7.5hrs in the water bath at 60C. There were no issues with temperature stability this time (and it looks like the catch for power off I put into my code was needed perhaps once this time). There’s still a bit of oscillation, but as things are coming out nicely I’m not inclined to spend too much time on tuning:
The beef looked great whilst in the pan searing:
and it looked great as I cut slices for serving:
and it tasted good too (with nice soft texture). Another sous vide success :)
Filed under: cooking, Raspberry Pi | Leave a Comment
Tags: beef, Raspberry Pi, Raspi, RPi, Sous vide, water bath
Best roast beef ever
I cooked tri-tip with my Raspberry Pi controlled sous vide water bath today. It came out brilliantly – on a par with the best Chateaubriand I’ve had (which for the record was at Casa Ferlin in Zurich – well worth a visit if you’re ever in that neck of the woods).
The meat
I got my tri-tip from Donald Russell, where they call it Tafelspitz (though Wikipedia tells me that Tafelspitz is actually a dish made with this cut of meat).
The cooking
The temperature control went a little awry. I’m guessing that at some stage the system sent an off signal to the remote controlled socket that wasn’t received, and so the temperature went up much higher than my 56C target. Luckily everything came out well. Here’s the temperature profile (over around 5.5hrs):
I will add a check to the code to make sure that off commands are sent every loop so this doesn’t happen again. Next time I cook tri-tip I’ll set a target temperature of 60C, so that things should come out the same.
The result
The title for this post probably gave it away, but the result was outstanding. The meat texture was like best quality fillet steak, the taste was rich and beefy; even the fat tasted great. I’m looking forward to more tri-tip in the future, and trying out some other cuts in the water bath.
Filed under: cooking, Raspberry Pi | 1 Comment
Tags: beef, Raspberry Pi, Raspi, RPi, Sous vide, tafelspitz, tri-tip, tritip, water bath
HP 650 Business Laptop – review
Since the screen failed on my wife’s Lenovo s10e netbook (and I turned it into a TV attached media player) she’s been using my old s10e, but that’s been on its last legs for a while too. The time had come for something new, with a full sized keyboard and screen.
I’ve been looking around for value laptops recently for my father in law, so I already had an idea on what would fit the bill, so I ordered an Asus X401A (in Pink) from Argos, which seemed a bargain at £259.99.
Before it could be delivered to the local store I came across what looked like a better offer. ServersPlus emailed me to say that HP was offering £100 cashback on their 650 Business Laptop – in a deal similar to their MicroServer (so it would work out at £268.28). The laptop on offer was a Core i3 processor, could take 8GB of RAM and Windows 8 Pro (the Asus was only a Pentium B970, max 4GB and Windows 7 Home Premium).

Sadly the next day delivery turned into most of a week to wait – a combination of the long Easter weekend, and DPD deciding not to bother delivering even though it arrived at the depot on time, and they had a van driving past my house that day :(
Disk dilemma
I had a Samsung 830 128GB SSD that had found its way to the s10e, so I planned on dropping that straight into the 650 and installing a fresh build of Windows 8 Pro. That plan did not work.
I’d had no trouble at all putting a clean SSD into my Lenovo X230, but the HP 650 threw a few spanners into the works. When I put the SSD into the 650 it threw up a warning screen about SMART errors (it was fine in the last PC), worse it wouldn’t boot off my Windows 8 install USB.
I checked that the UEFI stuff was in the right place – all looked well.
I disabled secure boot – it didn’t help.
I tried to copy the HDD it came with using Partition Manager – it wouldn’t do GPT partitons. I copied it with another partition tool that did do GPT, and got boot errors.
In the end I proceeded with the original HDD, made a recovery USB and then swapped in the SSD and went through recovery. It was worth the trouble – subjective performance with the spinning disk was pretty miserable (no doubt not helped by Norton AV crapware). Subjective performance with the SSD is great, and worth every penny of the £72.99 I paid for it. It’s such a shame that SSD is still sold at such a premium for original machines.
The good bits
As I already mentioned, performance is very decent – particularly for a machine at this price point. For everyday productivity tasks it doesn’t seem much different from my X230 (which has a WEI of 5.8).
Although the battery seems small compared to the overall unit size endurance is good too, at about 5.5 hours.
The not so good bits
Perhaps I’ve been spoiled by the excellent screen and keyboard on my X230, but both of these aspects seem weak(er) on the HP. The 15.6″ screen seems like it should have a higher resolution (than 1366×768) given its size, and colours seem washed out. The HP keyboard is a good size, but somehow doesn’t seem very precise and accurate.
Windows 8 – at least it’s the Pro version, so the option is there for Hyper-V (though I’m preferring VirtualBox for its versatility). I’ve put Start8 on for a proper desktop experience, which is well worth the $4.99 (though it still stuns me that Microsoft have chosen to inflict Metro on their customers – this ‘feature’ could be free).
At 2.5kg it’s not throw in the bag light (though HP do throw in a nice enough laptop bag).
Conclusion
This is a lot of laptop for the money. There are certainly aspects that reflect the budget price, but it seems built to last, and the performance is great. Maybe not quite as much of an amazing bargain as the MicroServer was[1], but still another great deal from HP.
Notes
[1] There’s a new MicroServer out – the N54L with a 2.2GHz processor. HP are doing cashback again, but it’s only £50 this time.
Filed under: review, technology | 1 Comment
Tags: 650, business, EFI, HP, laptop, review, ssd, Start8, UEFI, WEI
Sous vide steak
After making my Raspberry Pi controlled hot water bath over the weekend I’ve been itching to try it out. I got my chance this evening when cooking some steak for dinner.
I get my steaks mail order from Donald Russell, so they come shock frozen and vacuum packed – so the ‘sous vide’ part is already taken care of:
After getting the slow cooker and Raspberry Pi back from the kids’ play room where I’d been testing it I couldn’t connect via SSH. it turned out that the SD Card had got corrupted. After sorting out a fresh build of Raspbian I was ready to go once more:
The SD card crisis meant that I only had time for 45 minutes in the water bath at 55C, but they came out looking good, and went into a hot pan for a quick sear:
Once out of the pan I sliced with my ceramic knife. The rump steak tasted every bit as good as it looks:
Sadly my ribeye was just a little on the chewy side. I think it could have done with a bit more time in the water bath. The verdict on the rump from my wife and son was ‘softer, but less flavour’. I tend to agree, those rumps are usually bursting with beefy flavour – though I’m prepared to treat this as a one off (and my creamy pink peppercorn sauce had flavour to spare).
So… first time out I think counts as a qualified success. I’ll give the steaks longer next time. Next up (perhaps this weekend) – tri-tip.
Filed under: cooking, making, Raspberry Pi | 3 Comments
Tags: Raspberry Pi, RPi, Sous vide, steak, water bath
Temperature control for a sous vide water bath is a popular application for hobbyist microcontroller kits, with lots of well documented projects out there. My favourite is the Sous Vader – if only for the attention to detail in the decal on the box.
I’ve been planning my own for a little while, and got some DS18B20 temperature probes a little while ago. The long Easter weekend break finally brought me some time to progress the project.
Danger – High Voltage
I have an old slow cooker that’s perfectly good for doing pot roast. It’s been falling to bits for some time, and I’ve patched it up with a Sugru sample I got at Monkigras. I had thoughts of hacking it directly (and perhaps even building in a Raspberry Pi), but common sense took hold and I decided on a route that didn’t involve directly manipulating mains electricity.
To turn the slow cooker on and off I got hold of a radio controlled mains socket from Maplin – they’re available without the controller (which I didn’t need) for £7.99.

I found a library to control the remote socket on github – Raspberry Strogonanoff (thanks Duncan McGregor, and a clever choice of project name). This uses a Sparkfun 434MHz RF Link Transmitter (which as suggested by Duncan I got from Protopic).
Getting Raspberry Strogonanoff working was the easier part of the whole set up. Having looked at the socket to establish that it was set to channel 4 button 1 I simply ran this line to turn it on:
sudo ./strogonanoff_sender.py --channel 4 --button 1 --gpio 0 on
and this to turn it off again:
sudo ./strogonanoff_sender.py --channel 4 --button 1 --gpio 0 off
Getting control
A water bath is a good example of a control system. The water and pot collectively have quite a high specific heat capacity, and there’s quite a bit of latency between turning off power and the rise in temperature stopping. The standard way of dealing with this is to use a PID Controller (see this explanation for a BBQ application for something more straightforward than the Wikipedia article). The Sous Vader seems to have worked with just a PI controller (effectively D=0), so I tried that first. There is a python implementation of a PID controller, which I didn’t spend the time to integrate.
Tuning the control loop
This is the tricky and time consuming part. In theory there should be a nice library out there that figures out correct settings for P, I and D based on observed data, but in practice it seems that most people resort to manual tuning.
The hardware
I started out with things on a breadboard using my usual home made Pi Cobbler, but as I want to use this in the kitchen I’ve created a more permanent setup using a Ciseco Slice of Pi, which at £3.90 is a very inexpensive small project board. I used one of the header strips in the Slice of Pi kit as a place to plug in the 434MHz transceiver and the temperature probes (so it would be easy to use parts in other projects). It was then simply a case of soldering some connecting wires to the appropriate power (5v for the transceiver and 3.3v for the DS18B20), GPIO (0 for the transceiver and 7 for the DS18B20) and GND:
The system pictured above has an Edimax WiFi dongle so that I can control and monitor the whole thing when it’s in the kitchen.
The software
Update 14 Apr 2013 – the code (slightly improved over what’s below) is now available on GitHub along with (hopefully comprehensive) installation instructions.
It’s not especially pretty, but seems to be doing the job:
import os
from subprocess import Popen, PIPE, call
from optparse import OptionParser
from time import sleep
def tempdata():
# Replace 28-000003ae0350 with the address of your DS18B20
pipe = Popen(["cat","/sys/bus/w1/devices/w1_bus_master1/28-000003ea0350/w1_slave"], stdout=PIPE)
result = pipe.communicate()[0]
result_list = result.split("=")
temp_mC = int(result_list[-1]) # temp in milliCelcius
return temp_mC
def setup_1wire():
os.system("sudo modprobe w1-gpio && sudo modprobe w1-therm")
def turn_on():
os.system("sudo ./strogonanoff_sender.py --channel 4 --button 1 --gpio 0 on")
def turn_off():
os.system("sudo ./strogonanoff_sender.py --channel 4 --button 1 --gpio 0 off")
#Get command line options
parser = OptionParser()
parser.add_option("-t", "--target", type = int, default = 55)
parser.add_option("-p", "--prop", type = int, default = 8)
parser.add_option("-i", "--integral", type = int, default = 2)
(options, args) = parser.parse_args()
target = options.target * 1000
print ('Target temp is %d' % (options.target))
P = options.prop
I = options.integral
# Initialise some variables for the control loop
interror = 0
pwr_cnt=1
pwr_tot=0
# Setup 1Wire for DS18B20
setup_1wire()
# Turn on for initial ramp up
state="on"
turn_on()
temperature=tempdata()
print("Initial temperature ramp up")
while (target - temperature > 3000):
sleep(15)
temperature=tempdata()
print(temperature)
print("Entering control loop")
while True:
temperature=tempdata()
print(temperature)
error = target - temperature
interror = interror + error
power = ((P * error) + ((I * interror)/100))/100
print power
if (power > 0):
pwr_tot = pwr_tot + power
pwr_ave = pwr_tot / pwr_cnt
pwr_cnt = pwr_cnt + 1
print pwr_ave
# Long duration pulse width modulation
for x in range (1, 100):
if (power > x):
if (state=="off"):
state="on"
print("On")
turn_on()
else:
if (state=="on"):
state="off"
print("Off")
turn_off()
sleep(1)
Conclusion
I’ve not had the chance to use the water bath for cooking yet, but I’m very much looking forward to trying out a few steaks and maybe some Sunday roasts. I’ll report back on the results.
Filed under: code, making, Raspberry Pi | 24 Comments
Tags: 434MHz, control system, DS18B20, mains, PI, PID, python, Raspberry Pi, remote control, RPi, Sous vide, water bath
OpenELEC 3.0 Released
OpenELEC 3.0.0 has been released, which means that this popular distribution for XBMC is now in a stable version on Raspberry Pi. Raspberry Pi downloads for an SD card image file (.img.zip) and a copy of the release bundle (.tar.bz2) are on the Pi Chimney resources site.
I’ve done some tidying up on the site, so all the old official images and dev builds are now tucked out of the way.
As previously posted I’m going to stop doing images for regular dev builds now. Anybody that wants to just use OpenELEC should be using the stable release, and anybody that wants to tinker should have the wherewithal to do their own image file (or can use the upgrade process from a stable image).
I’d like to thank the dev team over at OpenELEC.tv for all their hard work in pulling this together.
Filed under: Raspberry Pi | 25 Comments
Tags: 3.0, 3.0.0, download, image, openelec, Raspberry Pi, Raspi, release, RPi, stable, XBMC
Review – Lenovo X230
Shortly after starting my new job it became apparent that I’d need a new laptop. As most of the other CohesiveFT team use Macs (and iWork) I was very tempted by the 11″ Macbook Air, but its limited memory and need for dongles to connect to things like VGA and network dissuaded me. I may come to regret this (due to iWork related issues), but I instead went for a Lenovo X230 – it’s roughly the same travel weight as the MBA, can take 16GB RAM, and has proper ports on it.

Buying
For reasons I can’t fathom the X230 is loads cheaper in the US than the UK. I very nearly bought one last year in the Black Friday sale as it was pretty much half the price of an equivalent UK model. When I went looking again there was no sale, so I took to eBay and found a bargain i5-3320M based model that came with an Ultrabase.
Upgrades
Before I even started using it I upgraded to an SSD (a Samsung 840) and 16GB RAM, which ensures spectacular performance – the worst part is the built in HD4000 GPU (though even that isn’t too bad):
I then installed Windows 8 Pro so that I could use Hyper-V for Linux VMs.
Awesome keyboard
Having used an X220 for much of last year I was a bit skeptical about the new chiclet keyboard on the X230 (which I expected to be like the one on my son’s X121e). I shouldn’t have worried – the X230 keyboard is the best I’ve ever used on a laptop. It might even be quite simply the best keyboard I’ve ever used (and I’m usually quite fussy about my keyboards – mostly using nice old HP ones).
Not a tablet
I’ve hardly been using the tablet features of my previous Lenovo X201 Tablet, which is why I went for the straight X230 rather than the tablet version. I know that Windows 8 is designed for touch, but the X230 Tablet isn’t a touch screen anyway, and I’m using Start8 to make Windows 8 behave like a proper desktop operating system.
Battery life
My machine came with the 6 cell 44+, which seems good for 5 hours of real world use – not enough for a day on the road without a charger, but still pretty respectable. For serious endurance there’s a 9 cell battery (the 44++) and an Ultrabase style battery slice (the 19+).
Ultrabase
I like being able to connect to my large monitor, home network and KVM switch with minimum fuss, so it was cool that the machine came with an Ultrabase. I doubt I’ll ever much use the DVD writer it came with, but it’s there if need be. The new Ultrabase seems more plasticy than earlier models, but it gets the job done.

Unlike earlier Ultrabases I get the impression that this one is just for desktop docking, and isn’t really intended to be carried around – it’s not heavy, but there’s just too much bulk.
Screen
The screen is lovely and bright, and with a matt finish that keeps reflection down.
Minor annoyances
I kept touching the trackpad with my hand when using the trackpoint, so I installed the Synaptics drivers and disabled it (it’s also possible to turn it off in the BIOS).
I also found that the standard Windows drivers wouldn’t let me output audio through the Ultrabase, which was fixed with the Lenovo drivers.
Conclusion
The X230 is the best laptop I’ve ever used. It’s light, has good endurance, and spectacular performance. If I could run an OS-X VM in Hyper-V to get iWork then it would be perfect.
Filed under: review, technology | 9 Comments
Tags: lenovo, review, ssd, X230






