Update: I have also successfully tested these instructions with node.js 0.6.17 on Ubuntu 12.04.

• Download the Node.js source, e.g. wget http://nodejs.org/dist/v0.6.15/node-v0.6.15.tar.gz

• Extract the files: tar -xvf node-v0.6.15.tar.gz

• cd into the newly extracted node.js folder: cd node-v0.6.15

• If you don’t have the essential build tools install then you’ll need to install them. As root run apt-get install build-essential

• We’ll also need to build in SSL support, so let’s install the openssl libs: as root run apt-get install libssl-dev

At this point we can run ./configure and proceed with the node.js build. You’ll see that configure will report that openssl is not found, but the build will still work. This is because configure uses pks-config to check for openssl. If the this bothers you then run (as root) apt-get install pkg-config and ./configure will then find openssl.

Right, that’s the pre-compile stuff done, lets get on and compile node.js! From this point it’s all standard Linux build commands: ./configure, make and make install. So…

• run ./configure (can be either root or a regular user)

• Then make (again, either as root or a regular user)

• and finally, as root run make install to install node into the system folders.

All done, so lets just check Node.js has been successfully installed. Type node --version

Now all you need to do is start writing some event driven JavaScript code… Over to you!

The problem was that I couldn’t find any way of converting an ssl public key to an ssh public key. It seems that although ssl and ssh private keys are compatible, the public keys are not.

No problem I thought, I’ll just generate the ssh key from the private key held within the java keystore (jks file). Hmm, it seems that the keytool utility does not have such ability, nor will it allow you to extract the private key.

Okay, so a quick google search later I discover a couple of freeware tools that can extract the private key from a java keystore. Great! I thought… until I found that our company wasn’t too keen on using freeware tools to support a production process… Bah!

It took me a fair amount of head scratching and experimentation to figure out a method that uses only the keytool utility and ssh-keygen. Both ship with most Linux distros (keytool also ships with Java), so no-one should object to using them, should they?

Anyway, here are the commands I used to generate an ssh public key from a private ssl key held within a java keystore.

Convert keystore from jks to pkcs12 format:
keytool -v -importkeystore -srckeystore keystore.jks -srcalias MYKEY -srcstorepass MY_STORE_PASSWORD -srckeypass MY_KEY_PASSWORD -destkeystore keystore.p12 -destalias MYKEY -deststorepass MY_STORE_PASSWORD -destkeypass MY_KEY_PASSWORD -deststoretype PKCS12

Extract private key from pkcs12 keystore:
openssl pkcs12 -in keystore.p12 -out key.pem -passin pass:MY_STORE_PASSWORD -passout pass:MY_STORE_PASSWORD

Set permissions so ssh-keygen won’t balk:
chmod 600 key.pem

Extract public key in ssh format:
ssh-keygen -P MY_STORE_PASSWORD -y -f key.pem > sshkey.pub

Check the public key!
cat sshkey.pub

It took a while to figure out how to re-create the root@localhost user, so here’s how I did it.

1. Shut down mysql server
2. Start the msql server up with skip-grant-tables option
3. Log in to mysql
4. Change to the mysql database
5. Create the root user
6. Re-start mysql server

For those that like a cut n paste approach, these are the commands:

1. service mysqld stop
2. mysqld_safe --skip-grant-tables &
3. mysql
4. use mysql
5. create user root@localhost;
6. GRANT ALL PRIVILEGES ON *.* TO 'root'@'localhost' with grant option;
7. commit;
8. FLUSH PRIVILEGES;
9. exit
10. service mysqld restart

You can confirm that the root account has been created (or is indeed missing!) by listing entries on the user table:
use mysql;
select Host,User from user;

Good luck!
Kev.

Looking at the output of dmesg revealed that the disk was having trouble reading the encrypted disk:
[235.097347] sr 5:0:0:0: [sr0] Add. Sense: Read of scrambled sector without authentication

It was at this point I realised that I had not yet installed the restricted media packages (also needed to play DVD films). So…
sudo apt-get update && sudo apt-get install libdvdread4
sudo /usr/share/doc/libdvdread4/install-css.sh

“That should do it” I thought! But no luck, it still didn’t work. I searched synaptic and installed some other packages that looked like they should help but still nothing… The disk would not play or back-up.

In the end deleted the contents of ~/.dvdcss and amazingly, it worked!

So if you’ve followed the Ubuntu instructions and still can’t play or back up a movie DVD then you might want to give this a try. I’m posting it here because it’s not an obvious solution and I’m sure I wont remember it next time I re-install my system.

However, the most significant change to those that use Xen will be the new XL toolstack which replaces XM/XEND and will ultimately replace xcp’s xapi and libvirt.

There’s no need to panic just yet though because XM is still included in Xen 4.1 and sits alongside XL.

Further details can be found in the Xen 4.1 release notes:
http://blog.xen.org/index.php/2011/03/25/xen-4-1-releases/

It’s good to see Xen moving forward and continuing to converge with Linux mainline kernel. What I’d really like to see though, is a pre-built up to date Xen Distro and a decent web based management front end. Now that would cause sleepless nights over at VMware HQ…

It appears that ffmpeg had selected the wrong audio stream. For some reason, it had had selected the second audio stream instead of the first. The fix is simple enough, you can manually set the streams to use with the -map option. The command below works well for UK freeview.

ffmpeg -i "input.mpg" -y -target pal-dvd -map 0.0:0.0 -map 0.1:0.1 -ac 2 -aspect 16:9 output.mpg

You’ll notice there are two -map parameters. The first one, -map 0.0:0.0 is for the video stream (almost always the fist stream). The second one,  -map 0.1:0.1 maps the second stream (the first audio stream, remember the first stream is the video) to the second stream (1st audio stream) of the output file. This fixes the audio problem… well almost!

The next problem I found was that the audio was in mono. This is fixed by telling ffmpeg there are two audio channels wit the parameter -ac 2.

How do you know which audio channel to set? The easiest way is to run ffmpeg without the -map option and note the streams it gives in the summary before it starts displaying it’s progress. You can then ctrl-c to quit. Example output shown below:

Duration: 02:03:57.24, start: 89212.169567, bitrate: 2944 kb/s
Program 1
Stream #0.0[0x200]: Video: mpeg2video, yuv420p, 704×576 [PAR 16:11 DAR 16:9], 15000 kb/s, 25 fps, 25 tbr, 90k tbn, 50 tbc
Stream #0.1[0x28a](eng): Audio: mp2, 48000 Hz, 2 channels, s16, 192 kb/s
Stream #0.2[0x294](eng): Audio: mp2, 48000 Hz, 1 channels, s16, 64 kb/s
Stream #0.3[0x401](eng): Subtitle: dvbsub
Stream #0.4[0x87b]: Data: 0x000b
Stream #0.5[0x943]: Data: 0x000b

So it you were to see that the stereo audio is stream 0.3 for example, you’d then use -map 0.0:0.0 -map 0.3:0.1 to map it to stream 0.1 of the output file. The first -map is still needed to specify the video, you’ll get an error without it.

Okay, so it’s only basic support at this stage, but it does represent a significant milestone in the hypervisors history.

DOM0 is the first domain (virtual machine) started by the XEN hypervisor and has privileged access to the computer hardware and drivers.

DOMU support was added to mainline kernel some time ago through the PARAVIRT_OPS API. However until now the DOM0 had to use a specially modified version of the Linux kernel.

So what? I hear you ask… Well the hope is that with DOM0 support available in the stock kernel, Linux distributions will start adding XEN virtualization as an option to along side KVM etc. Combined with all the advantages of having the latest kernel in DOM0, such as disk mirroring, really could deliver enterprise class computing in a cheap, open and community driven package. Now there’s a thought…

The official T-Mobile Android 2.1 ROM was removed from T-Mobiles website because it had a few bugs, the worst of which meant that you’d lose the odd text message. However the latest ‘custom’ ROMS appear to have fixed these problems.

I upgraded my phone using the FLB 1.7 ROM and various guides over at the Modaco forums (www.modaco.com). This is a simple step by step guide of how I upgraded my phone. You might want to also check with the forums for additional information, especially this thread.

First off, some background information.

• As far as I know this guide will only work with the original pulse; the Huawei U8220. Take the battery out to check the model number of your phone.
• The Pulse has a limited amount of memory which is not enough to run Android 2.1 (this was part of the problem with the official t-mobile release). To fix this you need to run a swap partition on your SD memory card.
• A class 6 SD card is recommended, however I have this working with a class 4 card.
• I have an 8GB class 4 card in my phone, but you can get away with using a 1GB card, just make sure its a class 4 or higher for it to be fast enough to run swap.

BIG FAT WARNING
Installing a custom ROM on your phone will almost certainly invalidate your warranty.
It is also possible that you could brick your phone.
The instructions below are simply a blog of what I did to my phone. There are no guarantees that they will work on your phone. So if you follow these instructions and bad things happen to your phone, don’t blame me!
Remember, the risk of making your phone completely useless is yours not mine.
END OF BIG FAT WARNING

The basic stages we’re going to perform for upgrading are:

1. Install the official T-Mobile 2.1 ROM. This is needed because this upgrade modifies the phones internal partition sizes. The custom ROM won’t work with the original Android 1.5 sizes.
2. Install a custom recovery boot image
3. Install the custom Android 2.1 ROM
4. Configure the ROM to use SWAP and run apps from the SD card.

First off, download the software needed onto your PC.
Official T-Mobile Android 2.1 update
Recovery boot image
FLB 1.7 Custom ROM (aka custom Android 2.1)
Fixed terminal emulator

Back up anything you need to keep from your phone. e.g. sync your contacts with google etc. Copy anything you need to keep from your SD card to your PC because your card will be wiped during the upgrade.

Note: If you have been running a custom 1.5 ROM with A2SD, it’s best to re-partition your SD card back to a single FAT32 partition before you start the upgrade. The easiest way to do this is to put your SD card into a card reader and use Gparted.

Right, now you’ve backed up everything you need, lets start the upgrade…

Stage1, apply the t-mobile official 2.1 update.

1. Unzip the Official 2.1 ROM and copy the DLOAD folder onto the root of your SD card. By root I mean don’t put it in any sub-folder on the SD card.
2. With the SD card back in the phone and the phone powered off, hold down the buttons ‘red end call’ + ‘volume up’ + ‘power’ and wait for the preparing update message.
3. Confirm that you want to update and then wait for the update to complete. At the end of the update you’ll get a message saying the phone will restart. For me the phone just hung. If this happens simply remove and re-insert the the battery
4. Confirm that the 2.1 update has worked, but don’t go mad and install apps etc because you’ll be wiping the phone again in a moment.

Stage 2 – Install recovery boot image.

1. Unzip the recovery image onto you PC and navigate to the folder. Make the file install-recovery-linux.sh executable (i.e. chmod +x install-recovery-linux.sh)
2. With your phone powered off hold down the buttons ‘red end call’ + ‘volume down’ + ‘power’. The screen should go blue.
3. Connect the USB cable to the phone and PC
4. On the PC as root run install-recovery-linux.sh (e.g. in ubuntu cd to the folder containing the superboot files and type sudo ./install-recovery-linux.sh). When you get the successful message you can reboot the phone (i.e. remove/re-insert the battery. You’ll probably have to remove the USB cable too).

Stage3 – Install the custom FLB Android 2.1 ROM

1. Boot into the recovery menu by holding down the buttons ‘red end call’ + ‘menu’ + ‘power’ and wait until the recovery menu appears (after 10 seconds or so).
2. Plug the USB cable into the phone and PC.
3. Using the track-ball scroll down to the option ‘USB toggle’ and press the track-ball to select.
4. The SD card should now mount on your Linux PC. Copy the custom rom zip file (flbmod_v1.7.zip) to the root of the sd card. Don’t unzip it, just copy the zip file.
5. Once the zip file has been copied, press the green button to toggle the USB back to off.
6. Use the track-ball and select the ‘Wipe’ option. Choose the First option (Factory reset) and confirm. Once the wipe has completed return to the main menu (with the ‘home’ button).
   
7. Now select ‘Flash ZIP from SD card’. Select the custom rom you wish to flash, confirm and then wait for the installation to complete.
8. Return to the main menu and select ‘Partition SD card’.
9. Using the ‘volume up/down’ buttons to change the sizes and ‘green’ to confirm set the swap to either 32 or 64mb. I went for 64mb (don’t go any bigger because it will slow the phone down). Then a suitable size for the ext2 partition. The ext2 partition is where the apps will be installed. 512mb is OK, 1024 is better if you have a big enough SD card!
10. Return to the main menu end select the ‘reboot’ option.
11. Be patient! it takes ages for the phone to start up on the first reboot!

Stage 4 – Configure the ROM to use the SD card for apps.

Although there are apps to SD (a2sd) options in the recovery menu, you should not use them. They are for an older version of a2sd and will cause problems if used on the version included in the Android 2.1 ROM.

1. Open the terminal emulator app. When I did this the app crashed with a force close. If this happens to you then you’ll need to install the fixed version you downloaded earlier. Copy the file to the FAT32 (data) partition of your SD card (this can be done from the USB option in the recovery menu or in the usual Android fashion)  and navigate to it using es file explorer from the installed apps menu. You can unzip and then navigate to …fixterm/system/app and tap on Term.apk and install it.
2. In the terminal emulator app type su - to switch to the root user.
3. Now type a2sd check to list all the current settings. If you scroll through the output you should see that swap is running, but the apps and dalvik cache are on the internal storage.
4. To move the apps to the SD card type a2sd reinstall. Your phone will then reboot to apply the settings (again, the first boot takes a while)
5. To move the dalvik cache to the SD card type a2sd cachesd. Again, your phone will restart to apply the settings. Please note that unless you have a very fast SD card (class 6+) you should leave the cache on the internal memory. If you have the cache on the SD card and need to move it back to the internal storage type a2sd nocache. Warning: There is another setting, a2sd cachepart. DO NOT USE THIS SETTING! it will stop your phone from booting and you’ll have to wipe your phone and start again.
6. That’s it. You should now be able to enjoy Android 2.1 on your Pulse. I recommend that you now boot into the recovery menu and make a nandroid backup of your phone before…

Extra.

After using the above upgrade for a short while I noticed my phone would slow down after about 10-15 minutes of heavy use. This appears to be because pages are being moved to/from swap in high volume. To fix this I reduced the swappiness from the default of 60% down to 20% with the command a2sd swappy20 (as root in terminal emulator app) I also set the memory ‘task killer’ setting to moderate with the command a2sd lowmem-moderate. Then manually restarted the phone.

Tip: to check the current value of swappiness type cat /proc/sys/vm/swappiness

One answer to the problem is to reduce the size of the mp3 files themselves. Be warned though that this is not without a down side. Shrinking the mp3 will reduce it’s sound quality. This is less likely to be a problem for audio books, but you might not want to do this for music.

The program lame is good for this sort of thing. You give it an mp3 file, specify a new (lower) bitrate and an output file and you get a new, smaller mp3.

lame --mp3input -b 80 input.mp3 output.mp3

But what if you have a folder full of files? You could type the above command for each file, but that’s going to be a pain. The simple command below fill loop through a folder of mp3 files converting each one and placing it into a sub folder named converted. To use the command ‘as is’ you’ll need to create the sub folder first and run the command from within the folder that contains your mp3′s.

for file in *.mp3 ; do lame --mp3input -b 80 "$file" ./converted/"$file" ; done

The -b option specifies the bit rate. The smaller the number the smaller the file (and lower quality). An average music track tends to be encoded at between 128 and 256, when audio books are generally lower. Obviously you should check what rate the mp3 is before deciding on a new bit rate. In gnome (Ubuntu) this is easy by right clicking the file and selecting ‘properties’, and then the ‘audio’ tab.

Although this may sound more professional it really isn’t. I don’t know why it winds me up, but I do have to bite my tongue to stop myself from correcting people and sounding like the office nerd (which, now I think about it I probably am!).

So, to settle the matter one and for all, here is a clip of Linus Torvalds pronouncing Linux just as it should be, with a short ‘i’…