Testing Ubuntu 10.04 Lucid Lynx Alpha 1

The latest version of the popular Ubuntu Linux distro, known as Lucid Lynx, was just released the other day and, though it is an early alpha release, I wanted to give it a shot in a virtual machine. Installation in VirtualBox was smooth and polished, but I ran into some problems with installing VBox's Guest Additions, which allow for higher resolutions and, more importantly, mouse pointer integration (the magic that lets you move your cursor from host to guest OSs without mucking around with capturing the mouse pointer).

Here is a simple fix for the mouse pointer integration:

Fire up a terminal and type:

sudo gedit /etc/X11/xorg.conf

This file used to be how Ubuntu managed devices attached to your computer, but they're trying to move away from it. Now, the system will accept such a file, but it tries to figure things out on-the-fly as much as it can, hence the currently-empty file.

So, into this empty file, copy/paste:

Section "InputDevice"
Identifier "VBoxMouse"
Driver "vboxmouse"
Option "CorePointer"
EndSection

All this is doing is telling your virtual machine to look for the vboxmouse driver and use it. Now, when you reboot, you should have proper mouse integration.

However, if this somehow causes problems and you want to undo it, just type into a terminal:

sudo rm /etc/X11/xorg.conf

and then reboot your system.

To fix the small resolution, you just need to add another section to your xorg.conf, so type into a terminal:

sudo gedit /etc/X11/xorg.conf

and below the mouse section, paste in:

Section "Screen"

DefaultDepth 24

SubSection "Display"

Depth 15

Modes "1920x1440" "1920x1200" "1900x1200" "1920x1080" "1600x1200" "1680x1050" "1600x1024" "1600x1000" "1400x1050" "1280x1024" "1440x900" "1280x960" "1366x768" "1280x800" "1152x864" "1280x768" "1280x720" "1024x768" "1280x600" "1024x600" "800x600" "768x576" "640x480"

EndSubSection

SubSection "Display"

Depth 16

Modes "1920x1440" "1920x1200" "1900x1200" "1920x1080" "1600x1200" "1680x1050" "1600x1024" "1600x1000" "1400x1050" "1280x1024" "1440x900" "1280x960" "1366x768" "1280x800" "1152x864" "1280x768" "1280x720" "1024x768" "1280x600" "1024x600" "800x600" "768x576" "640x480"

EndSubSection

SubSection "Display"

Depth 24

Modes "1920x1440" "1920x1200" "1900x1200" "1920x1080" "1600x1200" "1680x1050" "1600x1024" "1600x1000" "1400x1050" "1280x1024" "1440x900" "1280x960" "1366x768" "1280x800" "1152x864" "1280x768" "1280x720" "1024x768" "1280x600" "1024x600" "800x600" "768x576" "640x480"

EndSubSection

SubSection "Display"

Depth 8

Modes "1920x1440" "1920x1200" "1900x1200" "1920x1080" "1600x1200" "1680x1050" "1600x1024" "1600x1000" "1400x1050" "1280x1024" "1440x900" "1280x960" "1366x768" "1280x800" "1152x864" "1280x768" "1280x720" "1024x768" "1280x600" "1024x600" "800x600" "768x576" "640x480"

EndSubSection

Device "Device[0]"

Identifier "Screen[0]"

Monitor "Monitor[0]"

EndSection

Important: Each of the lines that start with "Modes" should have all of the resolutions following it on the same line, and they should only include resolutions that your monitor can actually produce, so you might have to delete some of them (e.g., my monitor is a 20" that only goes up to 1680x1050, so I deleted all of the resolutions that were greater than this).

Again, if this causes any problems, you can either delete the section of the xorg.conf file or delete the xorg.conf file entirely and then reboot to get things back to the way they were.

Shared folders between the guest and host also appear to be broken at the moment, but I don't know what to do about it. Other than that, things have gone well for me. Compiz works fine and I have a fancy composite desktop with wobbly windows and true transparency.

Using Gizmo5 with Google Voice to call landline and mobile phones

I, like many others, pay a lot for home phone service, which is becoming increasingly obsolete with the ubiquity of cellular phones. In an effort to cut out this mostly needless expense, I decided to try and combine two free services, Google Voice and Gizmo5, to make and receive free calls with actual landlines and cell phones via my existing internet connection.

The concept works like this: when you sign up for a Gizmo5 account, they assign to you a free SIP number, which you can basically think of as an IP-based phone number. This is already pretty cool, but the catch is that only other IP-based phones can call this number, and that's where Google Voice comes in. Through this free service, Google will connect any number--physical or SIP--with any other number--again, physical or SIP. Once the initial connection is made (the hard part for Gizmo), Google steps out and you're left with a working SIP-to-landline call without a phone line and without paying a dime.

To get this sweet deal going, you have to have an account with both services, which could be the biggest stumbling block: Google Voice is currently in an invite-only, privite beta stage and Gizmo5 has stopped accepting new registrations after it was recently acquired by Google (existing accounts still work, though).

If you've managed to snag some accounts, though, and they are all set up (you've chosen a local phone number for Google Voice, Gizmo has assigned a SIP number, etc.) you're ready to get started.

First, open your Gizmo5 account in your favorite web browser and find your SIP number (it will have an area code of 747):

Next, open your Google Voice account and click on 'Settings.' Under the 'Phones' tab, click 'add another phone' to forward your calls to:

Name it something recognizable (I called it 'Gizmo'), type in your Gizmo SIP number into the second blank, and then select 'Gizmo' from the pull-down menu:

Next, we'll want to install the Gizmo5 client on our computer (you can also use the gizmocall web-based interface, but it is made in flash and feels a little kludgy). Go to Gizmo's download page and download the client program for your operating system. If you're using Linux (like me), you'll notice that this is a bit of a problem, as the links are all missing. Luckily, you can still download the deb installer file for Debian-based distros, such as Ubuntu, from a direct link. UPDATE: the Linux download page is back!

Once the client is installed and running, you can enter your Gizmo account information and login. You can also choose to configure the client to manage your IM accounts, but I chose not to.

From now on, calls made to your Google Voice number--which is accessible to normal phones, either landline or cellular--will cause your Gizmo5 client to 'ring.' That means we can now receive calls from normal phones on our computer! We can also make calls to normal phones, but the trick is to use Google Voice instead of Gizmo's built-in (for-pay) calling feature:

When you click 'connect,' Google will call your Gizmo client (you answer it when it rings) and then call the number you have entered, merge the two calls, and then step out, just like your own personal secretary:


Conclusions

This method is not a perfect replacement for a home telephone. It only works when you have internet access (the silver lining of which is that you can use it at Starbucks, your hotel room, etc.; anywhere with a broadband connection). More importantly, it doesn't provide emergency 911 access, so if your house catches on fire, you'll just have to watch it burn because the fire department won't be able to look up your information via your phone number.

Furthermore, this method may not work forever. Google has just purchased Gizmo, so things are sort of up in the air until they figure out what they want to do about the way the services interact. Hopefully, if anything changes, it will be for our--the users'--benefit.

There has also been speculation that Google is planning to fully integrate these services together and then make them run on a wifi-enabled mobile device (Android-based, of course). This will essentially create a mobile phone that only works within wifi, but that can make and receive calls to/from any other phone without the need for a carrier (no carrier means no contract, no fees, etc.). That is, a fully ad-supported phone powered entirely by Google services and software.

Google, if you're reading this with your all-seeing robot eyes, please make it happen as soon as possible.

HandBrake Nightlies for Windows

Update (4/26/10): I will no longer provide these packages because the HandBrake devs are now providing real-deal official nightlies: http://build.handbrake.fr/

**These are UNSUPPORTED, BLEEDING EDGE builds of HandBrake. DO NOT ask for help in the HandBrake forums if you run into any issues with them. If you have a problem, ask it here and I will try to help. Otherwise, YOU ARE ON YOUR OWN.**

Additionally, these are not true nightlies because I won't be building them quite that often, but I plan to compile a new version each time a substantial update (such as an x264 bump) is checked into the SVN repository.

The CLI binaries are cross-compiled on my Linux box and the GUI is built natively in Windows.

HandBrake 0.9.4-3154svn (CLI and GUI)

Cross-compiling HandBrake for Windows on an Ubuntu Linux Host

I wanted to use an up-to-date build of HandBrake on my Windows machines, but I am not comfortable building from source in Windows. Thankfully, the HandBrake devs recently switched over to a cross-compile-compatible build chain using MinGW, so it's possible to build Windows executables from my Ubuntu box.

To start, we'll download the standard HandBrake dependencies, which you would already have installed if you've built it on a Linux system before:

sudo aptitude install subversion build-essential m4 wget autotools-dev yasm autoconf intltool libtool libbz2-dev zlib1g-dev

Next, we'll download the MinGW packages, which will install a Windows-compatible build chain on top of your Linux system:

sudo aptitude install mingw32

Then, we'll pull down the latest code from the SVN repository:

svn co svn://svn.handbrake.fr/HandBrake/trunk HandBrake

Switch to the newly downloaded code:

cd HandBrake

Then get the build started:

./configure --launch-jobs=0 --cross=i586-mingw32msvc --launch

Things will chug along fine until the build script reaches the LAME library, at which point it will fail during the configure script with an error:

"configure: error: CHECK_TYPE_uint32_t - please report to lame-dev @ lists.sourceforge.net"

To correct this, we'll need to open the configure script in a text editor:

gedit build/contrib/lame/lame/configure

and then do a 'find and replace' to change all instances of this:

FILE *f = fopen ("conftest.val", "w")

to this:

FILE *f = fopen ("conftest.val", "wb")

After that, just go into your build directory and restart the build script (it will automatically remember that we're compiling for Windows):

cd build ; make

You'll have to do the same thing for libogg when it fails. Apparently, this problem is somehow related to autoconf... Once the script finishes, you should be left with a shiny new binary named HandBrakeCLI.exe!

Beginner's Guide to SF4 Model Editing

Model editing is still being perfected, but it's currently possible with a few caveats.

First, download piecemontee's SF4 Assets Explorer. This is the cornerstone of model editing: http://sf4mods.pbworks.com/Utilities#piecemonteesSF4AssetsExplorer

Next, you'll need a 3D modeling program. I use the open source Misfit Model 3D because it preserves some coordinates and whatnot that seem to get dropped from other, more capable programs, such as 3D Studio Max (from what I hear from other modders; I have no experience with 3DS): http://www.misfitcode.com/misfitmodel3d/download.html

Once you have your tools, open the SF4 Asset Explorer and click 'Load file...'

Now, navigate to the costume file you wish to edit:

Click on the plus signs next to the path and the first entry marked "#EMB ([***]_01.obj.emo):

If you click on a model element, it will isolate it from the overall character model, like so:

Now, right-click on the element's name and select "Extract file...":

Name it something informative and give it the extension ".obj":

Next, open the file using Misfit Model 3D:

From here, you can move around vertices as much as you want, but you CANNOT add new ones or remove any. The number must stay EXACTLY THE SAME or you cannot re-inject it back into the model:

After you're finished editing, save the file and uncheck the option to "Save normals" (actually, I don't think this matters):

Now, back in the SF4 Assets Explorer, select and right click on the element you edited and choose "Inject file...":

Select your edited model and click "Open":

Now, when you refresh the model in the Asset Viewer, you will see your edits have taken effect:

The program will automatically create backups whenever you inject models, which is nice, but you should still be careful about overwriting because there is no "Undo." This edited model should now be ready to drop into your C:\Program Files\CAPCOM\STREETFIGHTERIV\Battle\Chara\*** folder to replace your old costume file.

Test Drive of UbuntuOne Private Beta

I signed up for Canonical's UbuntuOne private beta last week and just got my invite today. The service lets you upload files to Canonical's servers where you can seamlessly sync directories and files across any number of computers. This is generally known as 'cloud storage.'

When you sign up, you are directed to add their UbuntuOne repository and download/install a small gtk applet (only compatible with Jaunty and higher) that will integrate the service with your Ubuntu installation. On my Karmic alpha system, the applet had already been installed, which is what led me to seek out the service in the first place.

There are two main ways to access your cloud data: via the aforementioned system integration or through a fancy AJAXy Web interface:

The Web interface gives you a lot of management options, including file and folder management:

as well as options to add more users to share your files:

The GNOME integration is also super-swanky, with a notification bar applet that lets you connect/disconnect to the cloud:

and a folder that appears in Nautilus with a handy button that handles connecting:

I haven't run into any bugs/issues yet, but I'll update this post as things arise.

Compiz Fusion works in Virtual Machine running Ubuntu Karmic Koala

Something new about Ubuntu 9.10 Karmic Koala that hasn't really been advertised as far as I've seen is that desktop compositing via Compiz Fusion is possible from inside of a virtual machine. I believe this is due to recent changes in the way the kernel handles video memory, though I'm not sure. I don't think it is particularly caused by the version of VirtualBox that I'm using because my Intrepid VM is still confined to a flat, ho-hum desktop. Regardless, it's big news for me because I am forced to work in Windows for the most part at my job, but I always have Ubuntu running in a VM for most of my Web browsing (no viruses).

All of the plugins I have tried have worked, though ones that require fading in and out can be slow. Static transparency seems to work fine, though, as is demonstrated by the terminal window in my video. Also, wobbly windows and the desktop cube work swimmingly.

If you have any input on why Compiz suddenly works within the VM, please let me know.