Installation of simyo Huawei E220 under MacOSX

I recently subscribed to simyo's mobile internet service. I was considering also Orange, as explained in a previous post (es), but simyo's offer is better.

I am writing how to make the modem simyo provides (the commonplace Huawei E220) on MacOSX first, because apparently the PIN has to be deactivated for the modem to work in Linux. I have to admit that in MacOSX installation was a breeze.

Software installation

Start MacOS, then plug the USB modem. A window will open automatically, with two objects inside: "MobileConnect" and "User Manual". The former is the installer binary, and the latter is a folder with the manuals in PDF format (for me, they were in English and Spanish).

Clicking on the "MobileConnect" icon the installer will start, and after being asked to accept an EULA, then introduce the admin password, then choosing a location for placing the files (actually just a hard disk, not a concrete dir), the installer does its thing.

Profile setting

After that, we only need to configure a connection in the "Mobile Connect" window that opens automatically after installation. For that, click on "Setting..." and create a new profile. If you read the manual (see above), it is easy to fill in the blanks. In short:

  • Profile name: whatever you want
  • Access Point Name: this is the APN value that simyo tells you in some paper (
  • Telephone number: *99#
  • Account name: irrelevant
  • Password: irrelevant

Save the above, then choose the profile you just created in the drop-down list in "Profile name", then hit the "Connect" button. If after saying "Dialing up, please wait", it tells you "Connection succesfull!", then everything is fine!

PIN deactivation

Apparently using the modem under Linux requires that the PIN is deactivated. Doing that under MacOSX is easy: when the "Mobile Connect" window is active, go to the "Manage PIN" drop-down menu in the top bar. There you can find "Activate", "Deactivate" and "Modify". Self-explanatory, ain't it?

LWD - September

Ups! August passed, my holidays finished, second work week... and I haven't written much lately. I will partially fix that by updating my Linux World Domination project (you can read this May 2008 post for an intro).

As usual D2D means "days to domination" (the expected time for Windows/Linux shares to cross, counting from Feb 3, 2008), and DD2D means difference (increase/decrease) in D2D, with respect to last report. CLP means "current Linux Percent", as given by last logged data.

Project D2D DD2D CLP Confidence %
Einstein 310.2 +62.3 34.94 43.0
MalariaControl 621.2 -374.9 12.20 35.0
POEM never - 9.76 -
QMC 2873.2 +356.5 7.88 7.2
Rosetta 24647.0 +20189.5 7.80 0.5
SETI 4668.7 +1666.2 7.83 4.3
Spinhenge 12226.0 - 3.01 0.8

MacOSX ate my pics

OK, so the 2GB SD card I use in my camera has its problems. Apparently, only 1GB of it are recognized by the OS (Linux) and/or the card readers I own. The problem seems to be common, as you can see by googling about it. More info, from the Wikipedia article for SD cards:

Devices that use SD cards identify the card by requesting a 128-bit identification string from the card. For standard-capacity SD cards, 12 of the bits are used to identify the number of memory clusters (ranging from 1 to 4096) and 3 of the bits are used to identify the number of blocks per cluster (which decode to 4, 8, 16, 32, 64, 128, 256 or 512 blocks per cluster).

In older 1.x implementations the standard capacity block was exactly 512 bytes. This gives 4096 x 512 x 512 = 1 gigabyte of storage memory. A later revision of the 1.x standard allowed a 4-bit field to indicate 1024 or 2048 bytes per block instead, yielding more than 1 gigabyte of memory storage. Devices designed before this change may incorrectly identify such cards. Usually by misidentify a card with lower capacity than is the case by assuming 512 bytes per block rather than 1024 or 2048.

For the new SDHC high capacity card (2.0) implementation, 22 bits of the identification string are used to indicate the memory size in increments of 512 KBytes. Currently 16 of the 22 bits are allowed to be used, giving a maximum size of 32 GB. All SDHC 4-GB and larger cards must be 2.0 implementations. Two bits that were previously reserved and fixed at 0 are now used for identifying the type of card, 0=standard, 1=HC, 2=reserved, 3=reserved. Non-HC devices are not programmed to read this code and therefore cannot correctly read the identification of the card.

All SDHC readers work with standard SD cards.[ref]

Many older devices will not accept the 2 or 4 GB size even though it is in the revised standard. The following statement is from the SD association specification:

"To make 2 GByte card, the Maximum Block Length (READ_BL_LEN=WRITE_BL_LEN) shall be set to 1024 bytes. However, the Block Length, set by CMD16, shall be up to 512 bytes to keep consistency with 512 bytes Maximum Block Length cards (Less than and equal 2 Gbyte cards[ref]."

I have had problems in the past with this issue, and could only retrieve the photos exceeding the "first GB" of the card with a tedious operation: copy some photos from the card to the internal memory of the camera (28MB), remove the card from camera, connect camera to computer, download the photos in the internal memory (and empty it), unplug and repeat. 1GB/28MB = boring as hell.

However yesterday I realized that I had a shinny MacBook with its MacOSX intact. I read somewhere that Windows would sometimes read 2GB cards that Linux couldn't, by the simple method of happily ignoring the f*cked up file system in them. Maybe MacOSX could, too.

Well, it turns out it couldn't. When I attached the card in the card reader (I didn't try with the camera directly), MacOSX found the device and mounted it, giving me a nice icon in the Mac version of "My PC". However, the directory the icon led to was empty. I thought "Tough luck, Mac reads nothing in the card", unmounted it and unplug it. Then I placed it in the camera again, turned it on and... there was no photo in the darned thing! MacOSX had erased them!

There is still the (likely) possibility that I made some deep mistake, but the explanation for now seems that MacOSX ate my pics. Sad.

LWD - July

After another boring month, I have little to write about, besides my LWD project data update. You can read this May 2008 post for an intro.

As usual D2D means "days to domination" (the expected time for Windows/Linux shares to cross, counting from Feb 3, 2008), and DD2D means difference (increase/decrease) in D2D, with respect to last report (around a month ago).

Project D2D DD2D Confidence %
Einstein 247.9 +62.8 30.4
MalariaControl 996.1 +166.2 15.7
POEM 478.5 - 8.6
QMC 2516.7 +555.0 5.9
Rosetta 4457.5 +3155.8 1.8
SETI 3002.5 -1194.0 4.9
Spinhenge never - -

Except for SETI@home, all the D2Ds have gone up, showing that maybe the predictions so far were too optimistic. On the bright side (for FLOSS), SETI is, by far, the project with most users, so its results are the most reliable.

Recall that confidence percents are below 10%, except in two cases, which means logged data extent is small, compared to prediction time. This periodic report, thus, will get more and more accurate as months pass by.

Making iSight camera work in Ubuntu

As I said in a previous post, I bought a MacBook, and I am making all bits work correctly. Out-of-the-box support from Ubuntu (the only GNU/Linux I tried on the MacBook so far) is excellent, but some things (camera, WiFi...) need proprietary drivers, so some more tweaks are needed.

I have followed the instructions in the Ubuntu community site, as with the procedures detailed in the previous post.

Basically, it all boils down to:

Fetch the Apple drivers for the camera

As root (if, unlike me, you like sudo, then run the following as user, but prepended with sudo), mount the Mac OSX partition (you didn't delete it, right?) and copy the relevant file somewhere else (the cp command should be all in one line):

# cd
# mkdir /mnt/macosx
# mount /dev/sda2 /mnt/macosx
# cp /mnt/macosx/System/Library/Extensions/
     Contents/MacOS/AppleUSBVideoSupport .
# umount /mnt/macosx

You might have noticed that the Mac OSX partition is not sda1, but sda2. Don't ask me. It turns out like this after following my own installation instructions. Apple must have decided to install the OS in the second partition for some reason.

Install the required packages

We need a package called isight-firmware-tools. Unfortunately it is not present in the Hardy repos at the moment (it was in the Gutsy ones, I think). You can add a Launchpad repo, editing /etc/apt/sources.list to add:

deb hardy main
deb-src hardy main

Then, as root:

# aptitude update
# aptitude install isight-firmware-tools

You will be prompted for a path to the driver you copied before. You can press Enter without paying much attention, then execute (assuming you copied the driver to your root home):

# cd
# ift-extract -a ./AppleUSBVideoSupport

To activate the driver, restart HAL:

# /etc/init.d/hal restart

Test it with Ekiga

As explained in the Ubuntu community site, you can run Ekiga as user (after installing the ekiga package). Choose V4L2 as video plugin, and Built-in iSight should appear among the Input device list. If it does, the process worked.

Installing Ubuntu Hardy Heron on a MacBook

Yes, dear reader, I committed the heresy of purchasing an Apple MacBook. I obviously didn't do it for MacOS X, for which I couldn't care less, but for the hardware, which is quite good. I was looking for a laptop as small as possible, keeping price low (it cost 799 eur), and screen not too small (this one has a 13" one. Maybe even 12" is acceptable. 13" sure is).

You can see some pictures of it at my MacBook gallery.

If you, like me, are used to PCs, then there are a few things to note:

  • It has a different layout in the keyboard. Most prominently, some keys are missing: Del, PgUp, PgDn, Home, End. Some others (Win key, AltGr) have substitutes that can be mapped. Also the equivalent to AltGr and right Ctrl are kind of swapped: the key closest to the SpaceBar is right "cmd" (could be right Ctrl), and the farthest one is left "alt" (could be AltGr)
  • The touchpad has a single button, and tapping on it won't click. There is no zone on it to use as vertical scroll, either. Luckily the latter can be fixed via software, so that in Ubuntu the touchpad does behave correctly: you can tap-click, and you can scroll with a smooth movement of a finger. The single-button issue is not present in USB mice: they work "normally".

I would like to outline here the process of installing Ubuntu (Hardy Heron) in this machine. For that, I recommend reading (as I did), the following links:

Repartition of the hard disk

My Mac came with 120 GB (109 real) of HD, all of it devoted to OS X. Unfortunately, the Ubuntu installer can not cope with resizing of HFS+ partitions. Fortunately, OS X itself can. You can make use of Boot Camp as follows: go to Go->Utilities->Boot Camp Assistant. There you can (should) reduce the existing HFS+ partition to the bare minimum (in my machine it was 22GB, because OSX already uses 17GB, and it won't accept less than 5GB of free disk). Leave the rest unassigned, and quit.

Installation of multi-boot system

The first hurdle in our Linux installation is that the Mac machines do not have a "normal" BIOS. The BIOS is important for Linux/Windows installations, so this is a drawback. Macs come with a thingie called Extensible Firmware Interface (EFI), instead. However, there is a nice little tool called rEFIt that can help us with it.

To install rEFIt, you can follow the instructions at its Sourceforge site. I followed the Automatic Installation with the Installer Package instructions. Basically I downloaded the Mac disk image from the download page, opened in the Mac OSX file browser, double-clicked it to open it, then double-clicked on the rEFIt.mpkg file inside, and followed the instructions.

This will make the rEFIt menu appear in the next reboot, but only if you hold some key while booting (I think it's "C"). If you want the menu to always appear, do the following in a terminal, inside Mac OSX:

% cd /efi/refit
% ./

Installation of Linux OS

After doing the above, you should reboot with an Ubuntu installation CD inserted. If the EFI installation was correct, you will be presented with the rEFIt menu, in which you will have two big icons (OSX and the Linux CD), and five small ones below ("Start EFI Shell", "Start Partitioning Tool", "About rEFIt", "Shut down computer" and "Restart computer").

Use the left-rigth arrow keys to select the Ubuntu CD, and press Enter. At that moment, or after installing Ubuntu (I don't recall), the computer could complain saying: "No bootable device -- insert boot disk and press any key". If so, reboot and, in the aforementioned rEFIt menu, choose the second small icon, "Start Partitioning Tool". This tool will prompt you to update the MBR. Accept, and let it do its magic.

When booting with the CD, you will have the option to make an absolutely normal Ubuntu installation. The Ubuntu MacBook page says that Boot Camp will complain if you make more than two partitions in total. It will, but for me this is ridiculous, since OSX is already eating up one. There's no way I will install any Linux in a single partition (withouth even swap!). If you do not care about opening Boot Camp ever again (I don't), do a totally normal install. I created two 8.5GB partitions for / (one for Ubuntu, another one unused for the future), a 750MB swap partition, and the rest (73GB) as /home (potentially shared among the two Linux I could install).

After the installation, reboot and you will find the aforementioned rEFIt menu. Choosing the penguin icon on the right side will take you to the GRUB screen you probably are accustomed to. What this means is that you have to go through two boot menus when booting, but that's a minor issue, I think. The first menu is an EFI menu, in which you choose OSX or GRUB. The second one is the GRUB menu that lets you choose among different installed kernels.

And I think that's it...

I will keep on writing when I have time, at least about how to make WiFi work, and also how to configure Compiz Fusion. Yes, the X3100 graphics chip that the MacBooks carry is blacklisted, as not working with CF. But, believe me, it does work!

LWD update

This is a (in principle, monthly) update to my "Linux World Domination" project. You can read the intro in this May 2008 post.

The data presented is different from the one in the aforementioned post:

  • Mac is dropped from it
  • Predictor@home is also dropped
  • Two projects have been added: POEM and Spinhenge
  • D2D means "days to domination". The expected time for Windows/Linux shares to cross, counting from Feb 3, 2008.
  • DD2D means difference (increase/decrease) in D2D, with respect to last report (a month ago)
Project D2D DD2D Confidence %
Einstein 185.1 - 21.8
MalariaControl 829.9 -1.1 15.5
POEM never - -
QMC 1961.7 +122.7 6.1
Rosetta 1301.7 - 3.8
SETI 4196.5 -370.5 2.9
Spinhenge - - -

Except for QMC@home, all the projects have reduced the D2D. Rosetta and Einstein were expected to never lead to LWD, and now they are.

See you next month!

How much left for GNU/Linux World domination?

Remember Project BHS? It is an effort I am making to log the evolution of Windows/Linux/Mac/Other market share, via the respective contributions to BOINC projects.

I have taken a further (and very crude) step towards the estimation of when will the Beast from Redmond fall, by extrapolating the "Number of hosts vs. time" curves to the points of crossing. For that I have fitted the data so far to (very crude, I know) second order polynomials (with Xmgrace), and calculated the crossing points (with GNU Octave).

The results can be:

  1. Windows seems to go upwards and Linux/Mac downwards (will never cross)
  2. The crossing point is above 100% or below 0% market share: the extrapolation is unfit (will never cross)
  3. There is a crossing point and lies within 0-100% market share: that's the World Domintion date!!

I will be posting data for different projects, along with a "confidence" percent. This value corresponds to the fraction of the total time required for Linux/Mac to overcome Windows (according to the present tendency) that is represented in the collected data. If 10-day data suggests that Linux will overcome Windows in 1000 days, then the result is not really very trustable. OTOH, 999-day data suggesting the same is compelling.

An important notice: expected times are not measured from "now", but from the moment I started collecting data, on Feb 3, 2008 (3 months ago).

The following table illustrates the aforementioned data for some selected projects, with time in days and confidence percent in parenthesis.

Project Linux (%) Mac (%)
Rosetta never never
MalariaControl 831 (11.4) 1142 (8.3)
SETI 4579 (1.9) 3094 (2.8)
Einstein never never
QMC 1839 (4.64) -
Predictor 1095 (1.03) never

As an example, the curve fits and corresponding crossing points are given in the following figure, for the case of SETI@Home. You can infer the limited trustability of the predictions from the tiny time extent of the data points used to extrapolate the curves. As time goes by, curves will be more and more trustable, so expect updates to this "project".


SETI@Home data (click to enlarge)

The software used to process the data is BHS, and can be found at my home page.