Booting a VM from USB

Recently I started up my Linux VM for the first time in some months. It has Ubuntu installed on it. It had version 9.10 on it, known as Karmic Koala. I found out pretty quickly that this version is rather dated, and that support for it ended in April 2011. I decided to upgrade but was unsure whether to go for 10.04 LTS (Lucid Lynx), 10.10 (Maverick Meerkat) or 11.04 (Natty Narwhal) but didn’t want to fully install each one just to see what it was like.

Popping along to the Ubuntu download page I found that they offered the 10.04 Long Term Support (LTS) version or the current 11.04 version for download as a CD .ISO image and was reminded of the fact that the CD has the option of running as a ‘Live CD’, meaning you don;t have to install it – you can boot off the CD and run it directly from there. That’s great – I can pull the .ISO files down, connect my VM’s CD drive to the .ISO imge (as VMWare Workstation allows you to do, and I’m sure the other VM software, Virtual PC and Virtual Box do also).

Then I noticed the suggestion that you can burn the ISO to a bootable USB device and boot off that. This sounded interesting. When I decide on a suitable Ubuntu version, I can burn it to a spare USB memory stick and free the PC of the .ISO file, potentially allowing me to boot pretty much any PC into Ubuntu if the need or desire arises.

Well, I figured I’d better test this by booting my VM off the USB device. The first problem was how to make a bootable USB device from the .ISO, but this one is easily solved. The Ubuntu download page has a link to the Universal USB Installer from PendriveLinux.com. This makes the whole process trivial and even allows any spare space on the USB stick to be used as persistent storage for the installed Linux OS.

Having got a bootable USB device with Ubuntu on it I need to prove that one of my virtual machines can successfully boot from it. And this is where things got sticky. It seems the VMWare BIOS does not support booting from USB devices, which seemed to rain on my parade, somewhat. Until I did a little searching and came across a free boot manager called, simply, Plop. You can read up all about Plop on their Boot Manager info page.

In short though, if you download the current Plop Boot Manager .zip archive and unzip it you’ll find 2 key files in it: plpbt.img (currently 1,474,560 bytes) and plpbt.iso (currently 327,680 bytes). The .img file is a bootable floppy disk image, hence being 1,440 kB (floppies used to be described as having a capacity of 720 kB or double that, which was referred to as 1.44 MB). The tiny .iso is a bootable CD image. If you connect one of these to the virtual floppy drive (if present, though there should be an option to add it if not) or the virtual CD drive in a VM (and ensure the BIOS is set to boot off the legacy floppy device or the CD-ROM drive before the hard drive) then Plop will be invoked.

Plop’s job is to present you with all the available bootable devices to boot from, including USB, and in that it works just great and allows the VM to boot successfully from a USB device.

Of course what you don’t see in the screenshot above is that all those dots are actually a very smooth star field you’re heading through.

Ok, so there we go – I now have a bootable USB device and I can boot any reasonably modern computer from it and can also boot a VM from it. One final thing I thought would be useful was to set up a dedicated dummy VM that could be used to boot from CD or USB devices, if desired, to avoid occupying one o the regular ‘real’ VMs. I wanted this dummy VM to take up as little space as possible and so, preferably, not have to chew up physical disk space by allocating a virtual hard drive, which after all won’t be used.

I went through the steps of creating a new VMWare VM, decided to tell VMWare that it would be a Linux guest OS that would be installed, but that it would be installed later and found there was no way of specifying no hard disk in the VM. I opted to use an existing virtual disk from another VM, but wasn’t too happy about making this dummy VM dependant on another one that my get moved to another physical drive at some point. So when the VM setup was complete I took a look in the new VM’s .vmx file, which contains all its main settings.

Near the top I saw these values:

scsi0:0.present = "TRUE"
scsi0:0.fileName = <path_to_some_VMs_vmdk_virtual_disk_file>

The last piece of the puzzle was to simply set the scsi0:0.present value to "FALSE". Now I have a trivial VM with no hard disk whose sole purpose is to boot an OS from either a CD, via a connected .ISO file, or from a USB device, which can be done by connecting the Plop floppy image or CD image to the VM.

Native Android development for Delphi programmers

As you may know, and indeed as I have written about, Mono for Android has taken a bit of a hiatus. While it is still expected to be a viable development tool, and still a very convenient option for .NET developers, I thought it would be prudent to look up other options and ensure I covered various angles.
Naturally I considered regular Java development, using wither Eclipse or IntelliJ. However getting to grips with distinguishing the idiosyncrasies of one C-based language from another (Java vs. C#') wasn’t enormously high on my agenda.
It turns out there is another option looming on the horizon, which should be of high interest to Delphi developers.

“Diane, I'm holding in my hands a small box of chocolate bunnies.”

If you’re in the Delphi world you should already be aware of RemObjects Oxygene compiler for .NET, sold as Delphi Prism by Embarcadero. Oxygene for .NET is a native compiler that generates .NET executables. It encompasses all the latest aspects of the .NET framework and makes them available in a Delphi-like Pascal-based syntax, but doesn’t trouble itself with supporting decades of legacy DOS and Win16/Win32 specifics that have no purpose in the managed .NET world. This gives a smooth, fast .NET compiler that works very nicely from within the Visual Studio development environment.

“Diane, never drink coffee that has been anywhere near a fish.”

Coming later this year from the same stable is Project Cooper. This is the same Oxygene compiler offering the same Delphi-like language but generating code for the Java VM. It is in early stages of development as yet, but is already showing great promise. You can see a video of an early build here.

“Oh Diane, I almost forgot. Got to find out what kind of trees these are. They're really something.”

Of course, targeting the Java VM means it is ideally suited for developing native Android applications, and already does so even at this early point. I’m currently testing out Project Cooper, getting to know how to use the Android SDK more directly (i.e. not through the Mono for Android layer), and planning on what to put in a couple of talks I have planned on the product.

“Diane, I am now upside-down.”

On 14th June I’ll be talking to the Developers Group about Project Cooper in London. Then on 17th June I’ll be in The Netherlands talking about it at an SDN event.
I’m also hoping to write about the product as it develops its way towards release, showing how to accomplish various things that Android apps commonly need to do using Project Cooper.

“Harry, I have no idea where this will lead us, but I have a definite feeling it will be a place both wonderful and strange.”

Before signing off this time, I have to say that, given the lack of space on my Android phone I’m really enjoying the native app sizes you get from Project Cooper. And being a Delphi developer since 1994 (yes, I know it came out in 1995) the language fits like a favourite glove. So, right now I’m rather pleased Mono for Android has a 4 month break so that I can enjoy getting to know Project Cooper.

“Damn fine coffee! And hot!”

Oh. And in case you are wondering, Project Cooper is named after FBI Special Agent Dale Cooper from the classic series Twin Peaks by David Lynch.

---

Update 1: Project “Cooper” was released at the end of November 2011 by RemObjects under the name Oxygene for Java and can be purchased from the RemObjects store.

Update 2: I've started writing some articles on Project “Cooper”, or Oxygene for Java as it is now called. If interested, you can find them on my web site here, and of course you can see all my Oxygene for Java blog posts by clicking on the Oxygene for Java filter link just below.

Mono for Android and MonoTouch status change

Anyone who keeps an ear to the Mono world will have doubtless heard of the recent corporate changes that have impacted the Mono product line. For some while Novell have owned Mono, having previously absorbed the original developer, Miguel de Icaza, and his company, Ximian. Recently, Attachmate completed their acquisition of Novell and there have been the usual consequential streamlining processes occurring.

One of the casualties of this process is the Mono team, who were all released. This means that formal development of the commercial tools MonoTouch for iPhone development and Mono for Android for Android development have now halted. There’s been little noise on this subject from Attachmate, but the current thinking is that people who’ve already bought these products are still entitled to support. How supportive this support turns out to be is, perhaps, questionable. Certainly the store mechanisms that allow purchasing of MonoTouch and Mono for Android licenses have been disabled.

I should just add at this point that these events should not affect Mono itself, which is and always has been an open source platform. It’s the commercial tools for iOS and Android that are primarily affected.
For those who have been taking advantage of the homely feel of .NET development for iOS and Android devices, this news has set the cat among the pigeons, or thrown a spanner in the works, or whatever your preferred cliché may be. However, all is not lost.
As soon as Miguel and his team were let go, they immediately set up Xamarin. Xamarin is already working on producing API-compatible tools, similar to MonoTouch and Mono for Android, currently named .NET for iOS and .NET for Android respectively. The projected time for these tools is 3-4 months with the iOS product coming first.
Clearly this 4 month gap may prove logistically troublesome for some, but if you have already bought one of the Novell tools you can carry on working with it with an eye to switching to the Xamarin equivalent towards the Autumn.
If this time window is too much, well, you can always spend some time picking up native Objective-C skills or learning Java and use the normal development process in Xcode or AppCode for iOS, or Eclipse or IntelliJ IDEA for Android.
It seems that interest in the Mono-based tools continues. Various scheduled conference talks around the world on the topics are still going ahead rather than being cancelled. Personally, I will still be talking on Mono for Android at a Dutch User group (SDN) event in June.
That said, the timing of this unsettling news is not great for me as I’d started work on a series of tutorials for Mono for Android. I’ll probably put them on hold until the Xamarin products show some life, but since I’d finished the first one, I’ve put it on my web site. It’s looks at how you get going with Mono for Android and looks at the way Android applications operate, to get you started in the Android world, from a Mono for Android perspective. You can find the tutorial here on my web site.

---

Update: In case you came here and weren't aware of news happening in between when this was written and now, Mono for Android and MonoTouch came back and are flourishing away now.
Update: The introductory article mentioned is somewhat out of date now, but I have recently updated it to work with the current Mono for Android v4.

Alternative to Eclipse for Java development

If you find Eclipse a little clunky for Java development, then you might take a look at JetBrains IntelliJ IDEA Community Edition, which is intended to offer a smoother experience developing Java apps, with support for Java 7, JUnit and TestNG, Maven and Ant, Groovy, Scala, Clojure, Subversion, Git, Mercurial and CVS, as well as Swing UI design.

It also supports Android app development, including the latest Android SDK.

Alternative to Xcode for Mac development

Whilst on the subject of what JetBrains is up to, I recently learned that they are working on an alternative to Apple’s Xcode for Mac programmers who are building OS X and iOS applications in Objective-C.

AppCode is still under development, and an EAP (Early Access Program) is available. AppCode being pushed as an alternative to the Apple IDE, with various refactorings and active code analysis and intelligent Code Completion, as well as a debugger.

This will likely appeal to developers who have used JetBrains ReSharper in Microsoft Visual Studio but are expanding over to the Mac world to develop Mac or iPhone applications.

Alternative to Reflector available

Tools vendor JetBrains have announced development of an alternative to Reflector.

You’ll recall that Reflector was originally developed and maintained by Microsoft’s Lutz Roeder and for many years was a free tool. Not so long ago it was taken over by Redgate Software and remained free for a while, but then got a price tag attached to it (you can have a 14-day trial but after that it will cost you $35 or £20.

JetBrains have announced dotPeek, which is to do similar things to Reflector and will be free forever. An Early Access Program (EAP) is now open and you can download an early build and have a play.

Like Reflector, it supports navigating to types, symbols and members, will decompile to C#, support searching, support source servers, locate derived symbols, use syntax highlighting and so on.

Oxfam Trailwalker 2011 Training Update

Earlier this month I posted about my participation in a team of 4 in the Oxfam Trailwalker 2011 endurance walk challenge on July 16th and 17th. My team, Blood Sweat & Beers will be attempting to walk 100 km (or approximately 62 miles) in under 30 hours (hopefully closer to 24) and are raising funds for Oxfam’s poverty relief work and to support ex-Gurkas.

This post is really just an update so you can see how our training is coming along as we work towards this test of stamina and self-belief.

Despite appearing to be ‘just a long walk’ you should be aware that walks of several hours are very demanding on legs, feet, and joints, and when you stretch this over a 24 hour period and 100 kilometres, this is going to be really tough. Each of us is likely to burn approximately 10,000 kCals, which is about what the average man should consume over a 4 day period.

On the walking front we have had a number of team training walks, which varying combinations of team members have taken part in. We are also doing our own training walks when we can fit them in, as we don’t all live in very close proximity.

The first team walk was in late January, with a modest 5 miles (8 km) around some hilly woods near Henley-on-Thames. That took us 1:53 to complete, including occasional stops here and there.

The second team walk was in early February and was just shy of 11 miles (just under 18 km) around the Ashridge Estate. This walk had a number of testing hills in and took 3:47, including the odd stop for a breather. My heart-rate monitor told me I burnt 1,480 kCals on this walk.

I wasn’t able to attend the third team training walk, but the fourth was in early March and covered the first 10% of the Trailwalker course, just south of Petersfield (6.5 miles or 10.5 km). This took just over 2 hours including stops and I burnt around 800 kCals during this time.

We’re working towards our next team walk, but in the mean time we have been putting in a lot of time walking wherever possible. I’ve done a couple of lengthier walks myself in the mean time. The first one was 14.6 (23.5 km) miles, around the hills south of Wendover, and took me 4:37 to complete, of which 4:06 I spent walking, the rest was stopping for a breather, or checking the map, or climbing over stiles. This walk cost me 2,340 kCals.

The most recent training walk, to the east of Princes Risborough, was a little more substantial at 18.3 miles (29.5 km). This took 5:54, of which 5:12 was spent walking, during which I burnt around 3,400 kCals.

>

I’ve already plotted out a number of additional routes around my local county area of between 15 and 20 miles and I’ll be walking these over the coming weeks to keep developing my walking strength. I’ll be sure to keep you posted on how it’s all going at a later point.

My training walks without the team have a reasonable pace going, but that’s just to exercise myself on what is a considerably shorter walk than the real event in July. The pace I am setting on these walks is certainly not maintainable by me on longer walks.

Whilst doing these training walks the team have been testing out various things that will be necessary on the Trailwalker. For example, finding which walking socks are comfortable over long distances and don’t appear to be likely to cause blisters. Also working out the size of backpack or rucksack to take the necessary supplies.

Supplies on a walk like this are quite numerous. Granted, there are a number of checkpoints on the main walk, providing toilet facilities, water and occasionally some light food, but for all those miles we need to carry many things along. Obvious things include the route maps/instructions, first aid necessities, blister plasters, sun screen, a compass, water bottles, a phone, a pocket camera, a rain jacket. But also, given the number of calories being burnt off, quite a lot of food is needed to be nibbled and grazed on throughout the hours. Several spare pairs of walking socks are also pretty vital, to give your feet a break every few hours. Also, since half the walk will be at night, a head torch is required. Warmer clothes are also needed, though they can be left in the support vehicle during the day and swapped into at one of the checkpoints.

There’s a lot to take into account with this kind of endurance event over and above just getting to a position where you are able to handle continuous exertion for 24 hours or so.

Last but by no means least is the business of fundraising. The whole purpose behind this challenge event is to raise funds for Oxfam and the ex-Gurkas. The team is entirely reliant on our generous friends and the donations they can make to encourage us to train all the harder and be confident of making it to the finishing line. We’ve already started to receive donations but we have a long way to go before we reach our fundraising target. We’ll really appreciate any amount you can sponsor us with.

Thank you!