A few weeks ago, I took the leap and left my old Symbian phone in the drawer to buy a Samsung Galaxy S (the famous i9000). On a hardware level, it's an absolute beast: that 1 GHz Hummingbird processor and the 4-inch Super AMOLED screen leave you speechless. But of course, on a software level, I soon discovered why the XDA Developers forums are blowing up.

The phone came with Android 2.1 (Eclair), which isn't bad, but Samsung's custom skin, TouchWiz, suffers from infuriating "lag". You can be navigating smoothly and suddenly the interface freezes for three seconds when opening contacts. As a good IT guy, this wouldn't let me sleep, so I decided to get my hands dirty.

The underlying problem: The infamous RFS file system

Digging around the forums, I discovered that the bottleneck wasn't the RAM or the CPU, but the internal memory. Samsung decided to use a proprietary file system called RFS (Robust File System), which is supposedly optimized for flash memory, but in practice has horrific write latencies for small, concurrent operations.

The community, led by a French developer nicknamed Supercurio, came up with something called "Voodoo Lagfix". The technical idea is brilliant: replace the Android kernel with a modified one that automatically formats the data partition from RFS to Linux's classic and robust ext4 during boot time.

Getting to work: Compiling the Kernel

I could have just downloaded the pre-compiled kernel in a .tar file and flashed it with Odin, but I wanted to understand what happens under the hood and do it myself. After all, Android is Linux.

I downloaded the kernel source code that Samsung is forced to release under the GPL license, set up my environment, and prepared to cross my fingers.

# Export environment variables to use the ARM compiler
export ARCH=arm
export CROSS_COMPILE=/opt/toolchains/arm-eabi-4.4.0/bin/arm-eabi-

# Enter the source code directory and clean up previous junk
cd /home/user/dev/android/kernel_samsung/
make clean && make mrproper

# Configure the kernel using the i9000's base config file
make c1_defconfig

# This is where the magic happens. We open the visual config menu
make menuconfig

In the configuration menu, I enabled full support for ext4 file systems, disabled some useless Samsung debugging modules to lighten the load, and saved the configuration.

# Compile the kernel image (zImage) using 4 threads
make -j4

After a few minutes of fans blowing at full speed, there it was: my zImage file. I packaged it, put the phone in "Download Mode" (pressing volume down + home + power), and injected it via USB.

The reboot that lasted an eternity

The first boot after flashing took almost ten minutes. The screen showed a robotic voice and lines of text indicating it was copying all my temporary data, formatting the /data partition to ext4, and restoring it all back. I thought I had bricked it...

But no, when the desktop finally loaded... the difference was night and day! The lag was completely gone. The device flies, apps open instantly, and the Quadrant benchmark scores have doubled.

Reflection on the Android ecosystem

This experience leaves me with a bittersweet feeling. On one hand, Android is an absolute paradise for a technical profile. The fact that I can download the OS kernel of my phone, modify the C code, recompile it, and fix a manufacturer's design flaw is something that must sound like science fiction to iPhone users.

On the other hand, I'm very worried about future fragmentation. A regular user, your dad or your grandma, shouldn't have to compile a Linux kernel and use ext4 so their high-end phone runs without stuttering. If manufacturers (HTC, Samsung, Motorola) keep modifying Android on a whim and throwing in shoddy overlays, I fear the platform will become unstable and chaotic. Hopefully, Google will take the reins and start demanding stricter quality standards for the codebase, because technical freedom is great, but usability rules the consumer market.