0-60 in 4.0 seconds and a top speed of 194MPH and some sweet technology poured into this machine:

That engine rests on magnetorheological engine mounts, meaning the mounts can go from heavy dampers to keep things smooth in the cabin to solid bricks with no flex, transmitting every ounce of power to the wheels. That power gets routed through a suspension designed with stiffer springs and anti-roll bars while ride comfort is supposedly unaffected. That suspension does another trick too, by utilizing an onboard compressor, and what we assume is an airbag system, the car can raise itself 1.18 inches to make it easier to get over speedbumps and up ramps.

More details: Link


US spending on healthcare IT lags behind much of the world at $0.43 per capita here in the US compared to $193 per capita in the UK.  $20 billion of the government’s proposed stimulus bill is geared at funding healthcare IT.  A recent study in the Archives of Internal Medicine reported:

Researchers at the Johns Hopkins University School of Medicine, in Baltimore, rated clinical information technologies at 41 hospitals in Texas and compared those results with discharge information for more than 160,000 patients. Technologies recorded included electronic note taking, treatment records, test results, drugs orders, and decision-support systems that offer information concerning treatment options and drug interactions. The researchers found that hospitals that rated highly on automated note taking had a 15 percent decrease in the odds that a patient would die while hospitalized. Hospitals with highly rated decision-support systems also had 20 percent lower complication rates. Researchers found that electronic systems reduced costs by about $100 to $500 per admission.

Check out the link for more details: Link


Cobb SRI w/ Amsoil dry filter on a Mazdaspeed 3  

Cobb SRI w/ Amsoil dry filter on a Mazdaspeed 3

I finally got a Cobb Short Ram Intake after convincing my wife that the Mazdaspeed 3 “isn’t fast enough…er…could get better gas mileage with some slight modification”.  The install was very straightforward and took less than an hour.  Cobb Tuning claims that this intake adds 11 hp. and 16 lb.-ft. to the stock setup and if looking at the stock airbox wasn’t enough to prove it, their dyno testing shows the power curves before and after.  

The intake comes with an oiled filter which can get messy to clean, so I ordered a dry filter from Amsoil (part # EaAU4560) that’s made from dry nanofiber synthetic media.  In addition to being easier to clean (simply vacuum), the filter has a larger surface area allowing for more airflow through the filter.  I’ve been driving with the intake and filter installed for almost a month now and I’m very pleased with this combination.

Cobb Oiled Filter vs. Amsoil EaAU4560 (Mazda Forums)

Cobb Oiled Filter vs. Amsoil EaAU4560 (source: Mazda Forums)

Pros:

  • Performance: The car is noticeably faster
  • Price: $175 deliverd (that’s $16 per hp!!!)
  • Sound: I can now hear the stock bypass valve which sounds pretty nice
  • Gas Mileage: I’ve noticed ~2 MPG improvement
  • Filter Replacement: The Amsoil Ea filter is guaranteed for 100,000 miles or 4 years and require cleaning every 25,000 miles or once a year

Cons:

  • Increased wheel hop
  • Lose traction in 1st and 2nd gear at WOT

It’s nice having the extra power but the next step is to replace the rear engine mount with one made of stiffer material to reduce wheel hop as well as stickier tires that will grip better in 1st and 2nd.


What’s New?

15Jan09

img_1572

It’s been a long time since I updated, a year and a half to be exact!  Since my last update I’ve gotten married and graduated from ASU and am now working towards my PhD in Bioengineering at UC Berkeley and UCSF.  I hope to post more often now but will probably stay away from the long tutorials that I posted in the past.


WPA

(Time required = 30 minutes) Scroll down to Setting up Automatic Activation to see the process if you are not interested in the background.

Background

When I first setup my VMware Server to run an existing Windows Install from a physical partition, I was asked to reactivate Windows XP before I could use it as a guest OS. All this required was to enter the product key, request verification and within a couple seconds everything ran fine. I received a lot of complaints from people saying that they were then again asked to reactivate Windows again once they booted back into Windows natively, and then again under VMware and so on every time the OS was booted in a different environment. I wasn’t sure what to tell readers and a web search brought up an endless number of forums with the same problem but no answers. My favorite answer had to be this one from a Microsoft tech saying “Running a virtual machine counts as running two copies of Windows”. Really? Maybe he should have read the user’s question more carefully. Regardless, I couldn’t really help since I couldn’t reproduce the problem.; that was until I upgraded my hard drive this week.

I found myself experiencing the same problem others had mentioned; I would boot natively and be asked to reactivate, it would work fine until I booted the VM and was again asked to reactivate. Remember that WPA (Windows Product Activation) typically allows you to reactivate twice through the internet and after that it requires you to call in. This meant that I was calling up MS every time I wanted to boot in a different environment; hardly practical considering it takes 10 minutes each time activating over the phone.

Reading up on WPA I learned that there are two files used to store the hardware info along with WPA data, WPA.dbl and WPA.bak (These files reside in C:\Windows\System32). If you go through the activation process in Windows natively as well as under VMware you will notice that the file size changes each time you reactivate. This means that if you replace the WPA files prior to booting based on whether you’re using VMware or booting natively you won’t have to reactivate. You will have WPA files for your native hardware and WPA files for your virtual hardware, just swap prior to boot.

I set out to write a script in Linux to perform this but ran into a much simpler solution that a Mac user developed. Linux users can follow the steps below to achieve the same results.

Setting up Automatic Activation

Step 1:

Boot into Windows XP natively. You will be prompted to activate your copy of Windows (if already activated, skip activation and just copy the files). Go ahead and reactivate your copy, this can be as simple as doing it through the web or going through a 10 minute phone call with Microsoft’s automated machine. Once Windows is activated:

-Navigate to C:\Windows\System32

-Create a new folder and name it “nativeboot”

-Copy and paste wpa.dbl and wpa.bak from C:\Windows\System32 into the new “nativeboot” folder

Step 2:

Boot into Linux. Run VMware and boot into Windows XP. You will be prompted to activate your copy of Windows. Go ahead and reactivate your copy, this can be as simple as doing it through the web or going through a 10 minute phone call with Microsoft’s automated machine. Once Windows is activated:

-Navigate to C:\Windows\System32

-Create a new folder and name it “vmware”

-Copy and paste wpa.dbl and wpa.bak from C:\Windows\System32 into the new “vmware” folder

Step 3:

You now have a copy of the WPA info for both your physical and virtual hardware! The next step is to guide Windows to use the right set of files when booting. The easiest way to do this is to setup a script that will be run when Windows boots:

-Open Notepad

-Copy and paste the following code:

@echo off

ipconfig /all | find "VMware" > network.tmp
for /F "tokens=14" %%x in (network.tmp) do set vmware=%x
del network.tmp

if defined vmware (
  echo VMware
  copy C:\\Windows\\System32\\vmware\\wpa.* C:\\Windows\\System32
) else (
  echo Native Boot
  copy C:\\Windows\\System32\\nativeboot\\wpa.* C:\\Windows\\System32
)

-Save the file as “activation.bat” in C:\

-Go Start>>Run>>gpedit.msc>>[enter]>>Computer Configuration>>Windows Settings>>Scripts>>Startup>>Add

-Choose “activation.bat” as the script to add.

Done!

Windows should now automatically choose the right WPA files and not require activation as you restart or change from physical to virtual hardware.

Additional Thoughts

Nevertheless, the fact that users need to go through this process to get their systems working is beyond stupid. WPA has in no way eliminated piracy and problems like this many times lead users to ditch legal software and go the route of pirated software which isn’t infested and crippled with WPA. It’s clear that Microsoft did not foresee these problems and still fails to address them. The fact that a call to MS tech support will result in them telling you that you will need two copies of Windows when virtualizing shows a lack of understanding as well as a lack of a clear solution. Even if you were to pay MS an additional $300 you would still be where you started if you are trying to virtualize a physical partition, you would just be out $300. This is because each copy of Windows can only handle one WPA file and can only be installed on one PC. When you switch environments, WPA thinks you are completely changing computers and requires reactivation. MS will try to tell you that virtualization requires two copies of Windows and that you are violating the EULA by virtualizing the same copy. THIS IS NOT TRUE. You only installed Windows once, it’s all the same set of files, and you’re still technically running it on the same original hardware since you are using the same CPU, Mobo, HDD, RAM, NIC, etc. What you are doing is not in violation of the EULA and don’t let Microsoft’s limitations in software design limit your options and your computer’s functionality.


rdesktop

I saw a post this morning showing you can run Windows applications from a virtual Windows install on your Linux Desktop. Although this may seem like it’s not that big of a deal, anyone who virtualizes another OS such as Windows from within VMware knows it can sometimes be a hassle to switch between your Linux desktop and the Windows one since you only have access to application windows within each OS and your Guest OS is limited to running within the VMware window. The advantage of integrating the guest OS into your existing desktop allows you to easily switch between different applications and use applications side by side regardless of what OS they are on. As you can see in the pic above (click to enlarge), this method gives you access to the StartMenu from your Linux desktop as well as placing guest OS applications in the Gnome panel. The original website provided a method that needed some modification to work for me. Additionally, the following guide will show you how to safely set this up on an existing Windows partition.

  • If you already have a dual boot machine with an existing install of Windows XP, follow the guide here on how to run it in VMware.
  • Once you have VMware setup properly, boot into Windows from VMware and go in and create a new user for Windows in Control Panel>>Users. I assigned the username “Linux” for this user. Make sure you also assign a password for security purposes. The reason you should create a new user is that you will be disabling the desktop for this user rather than the user that you normally log into Windows with.
  • Now go to Start>>Control Panel>>System>>Remote Tab and enable “Allow users to connect remotely to this computer”.
  • Now go to Start>>Run and type”regedit” to bring up the registry editor. Navigate to HKEY_CURRENT_USER/Software/Microsoft/Windows/Current Version/Policies/Explorer and right click to create a new DWORD value. Name the DWORD value NoDesktop and give it a value of 1.
  • Download SeamlessRDP and extract it to C:\seamlessrdp.
  • Go to Start>>Run and type in in “cmd”. In the command prompt, type ipconfig and note the first IP it reports, this is the IP of your virtual machine.
  • Now you can log out of Windows.
  • Whenever you want to run the virtual machine and enable Windows applications on your desktop, you will need to type the following command in the terminal:

rdesktop -A -s "c:\seamlessrdp\seamlessrdpshell.exe c:\windows\explorer.exe" IPAddress -u username -p password

Remember to replace IPAddress with the virtual machine’s IP and the username and password with the username and password of the new Windows user you just created. Note that VMware must be running and the virtual machine needs to be booted and at the Windows login screen when you run this command.

That’s all you need to get it working. You will see the start menu at the bottom of the screen. Right click and deselect “Lock the Taskbar” and move it somewhere else (i.e. left of screen).

***OPTIONAL***

To make the process easier, you can create the following script and place an icon in the gnome panel or your desktop instead of typing out the command each time:

  • Paste the following code in a text editor (change IPAddress & username but not password, for obvious security reasons) and save it as rdesktop.sh:

#!/bin/bash
read -s -p "Enter Password: " mypassword
rdesktop -A -s "c:\seamlessrdp\seamlessrdpshell.exe c:\windows\explorer.exe" IPAddress -u username -p $mypassword

  • Make the script executable by typing the following code in the terminal:

chmod -x rdesktop.sh

  • Run VMware and boot Windows. Once you are at the login screen, run this script and you will be prompted for the password. You should now see the Windows start menu.

Clock

If you’re like most users, you have some form of power management installed in Linux, especially if you are using a laptop. These power management applications typically scale down the processor speed resulting in your guest OS’s clock running faster than your host’s clock (source).

If you have VMware Tools installed, you can go into the options tab and enable “Time synchronization between the virtual machine and host operating system”. Unfortunately, this doesn’t keep the clock synchronized at all times for some users but rather synchronizes it at intervals. One solution to fix this time problem is to specify the maximum CPU speed in VMware’s configuration file. To do this you need to edit the configuration file:

sudo gedit /etc/vmware/config

With the configuration file open, look for the following lines:

host.cpukHz = 1830000
host.noTSC = TRUE
ptsc.noTSC = TRUE

If they do not exist go ahead and add them. Change the 1830000 number to match the frequency of your CPU. For example 1830000 = 1.83GHz. Once you have done this, restart VMware and boot into your guest OS, your clock should now stay in sync with your host OS.