(k)ubuntu 8.10 - not ready for my home yet

(K)ubuntu is a very glamorous distro and I await its every new release with lot of enthusiasm. So after every release I burn the CD to upgrade my home desktop. And eventually I end up in the step where I realize why it didn't work last time and why it's not gonna work this time either.

There are two major reasons with installing ubuntu on my AMD 64 box - one my video card (NVidia 6800 GS) and other my fancy (read sophisticated ;) LVM layout. Actually it's the combination of these two reasons that it's almost not possible to install ubuntu right now. ("almost" because there is a busybox shell. I can theoretically install the whole distro in a complete gentoo-ish way; but that's for one-time learning experience, not for every upgrade.)

The two problems given separately can be resolved.

I have the same fancy LVM layout on my office box, but I can install ubuntu there, because the GUI of Ubuntu Live CD has support for LVMs (since past couple of releases). On that box Live CD installation is possible, which is not the case on my home machine because the nVidia driver is too high end for the generic video driver on Live CD to handle.

With Fedora GUI installer I have same problem with my graphics card. But Fedora's LVM management is an integral part of Fedora's text mode installer, so I can install the whole system and then boot into command line and install nvidia graphics driver from livna and get the GUI running.

Ubuntu has had very poor support for LVMs. Till 8.04, you had to manually load dm-mod and create custom initrd, etc... With 8.10 I can at least see (from busybox shell, not any installer screen) that the LVM volumes are automatically detected. The problem is, the text installer screens will only allow me to create new LVM volumes, they won't present me with existing volumes (even though the system has already detected them, as verified from shell). It is sooo close... Is there a hidden button somewhere that I missed, unfortunately not :(

I guess I will have to wait for Fedora 10 for my home box and enjoy Kubuntu on my office box only.

What appears bizzare to me is after all these years of linux distro evolution why do we still have to reboot the machine to install a new version of the OS. The new operating system should be installable while you are booted into the comfort of your old operating system. Not only is it easy to implement; it is already done in some forms. The wubi project of Ubuntu will install ubuntu linux as an app from a running Windows OS. Many people (including me) have tried doing a chroot installation of the new OS, I almost got it running with Fedora 8; but certain initrd errors stumped me. Live CD installation is halfway on that path; instead of the old OS it runs a minimal OS booted from CD.

An added advantage of this scheme is, one can undo the new OS installation equally easily. In case of a linux distro - the footprint of an OS on the file system is essentially made of two parts - root partition and some files in boot partition. If the root file system is located on a logical volume, then undoing the OS install is just to remove this volume and deleting some files from boot partition. I do this every time (that's why I have that fancy LVM layout); I just want it nicely integrated inside installer interface.

I hope the distros will have this facility some day...

Have fun with Ibex !!!

Update (Oct 31):

I got it running. The key is to run "modprobe dm-mod" and (more importantly) "vgchange -ay" before the text installer reaches the disk scanning screen. After than the installation happens as usual. After the installation was complete, of course I didn't have the GUI working.

Add "deb http://us.archive.ubuntu.com/ubuntu/ intrepid-updates main restricted" to /etc/apt/sources.list.

Run apt-get update

Run apt-get install nvidia-glx-173 nvidia-settings

Still the GUI won't start.

At this point you are expected to tweak /etc/X11/xorg.conf. But I never get it right. Luckily I could copy the file from my Fedora-9 installation and KDM loaded successfully upon reboot.

The KDE 4.1 GUI is awesome!!!! Try it!

Migrating to Google App Engine

Last year I wrote plugins for Gimp/Inkscape that allow image uploads to Flickr/Picasa from the Image editors. The plugin code talks the public APIs of Flickr/Picasa. Flickr tracks the API user's calls by means of an API key and a corresponding secret key. Typically the apps ship both the API and secret key with their application code. This creates problem if Yahoo disables your API key OR just the idea of sharing your secret key is not comfortable.

So in my app, I hosted the keys on an xmlrpcserver. The plugin would pull the keys from the server and sign the user's upload request. I had a website project running alongside, so I just put the xmlrpcserver on the same host that was serving the website. This host I rented for $15/month from a VPS vendor. Well... the website didn't fly and recently I found that there was no point anymore paying the $15 every month. But I had to take care of the xmlrpcserver hosting the keys.

One solution would have been to issue new version of the plugins and ship keys with them. But this would have not worked because the users who have already downloaded the plugins, won't come back to check an update when they get an obscure error.

The other alternative was to use Google's web app engine to host my xmlrpcserver. I had to spend some time in customizing the standalone xmlrpcserver to work with Google App engine. I have contributed the code in this recipe in App Engine's cookbook. I also had to modify my flickr API library a bit to use app engine's URLfetch API instead of urllib.

Finally I have successfully migrated my XMLRPC server to Google App engine. I liked GAE a lot. Like other Google apps, the GAE interface is rich with goodies - log viewer, traffic analyser, Database viewer, etc.

And it's free (read the EULA for limits).

With a free webserver like this, I can imagine so many things I can do. Moreover it supports my favorite language... what else can I ask?!

Android opened - first looks inside

Update (Nov 12 '08) Benno has got android running on Openmoko. Gr8 job!

News of the day! Android is open. First thing after returning from work was setting up the git download and build.

Follow the download and build instructions here.

Tip: If you are running x86_64 box, make sure you install *-devel.i386 packages as well. You will keep getting errors otherwise, that the libraries found in /usr/lib64 weren't deemed good candidates by the build system for linking.

For the description of each subdirectory of the project tree, check this.

The things of interest are the toolchain and location of bare-bones libraries. Toolchains are located inside the prebuilt directory.

mydroid $ prebuilt/linux-x86/toolchain/arm-eabi-4.2.1/arm-eabi/bin/gcc -v
Using built-in specs.
Target: arm-eabi
Configured with: ../../toolchain/android-toolchain/gcc-4.2.1/configure --prefix=/android/mathias/armdev/toolchain-eabi-4.2.1 --program-transform-name=s,^,arm-eabi-, --prefix=/android/mathias/armdev/toolchain-eabi-4.2.1 --target=arm-eabi --host=x86_64-unknown-linux-gnu --build=x86_64-unknown-linux-gnu --enable-languages=c,c++ --disable-libstdc__-v3 --disable-libssp --enable-threads --disable-nls --disable-libmudflap --with-float=soft --with-fpu=vfp --with-arch=armv5te --enable-target-optspace --with-abi=aapcs : (reconfigured) ../../toolchain/android-toolchain/gcc-4.2.1/configure --prefix=/android/mathias/armdev/toolchain-eabi-4.2.1 --program-transform-name=s,^,arm-eabi-, --prefix=/android/mathias/armdev/toolchain-eabi-4.2.1 --target=arm-eabi --host=x86_64-unknown-linux-gnu --build=x86_64-unknown-linux-gnu --enable-languages=c,c++ --disable-libstdc__-v3 --disable-libssp --enable-threads --disable-nls --disable-libmudflap --with-float=soft --with-fpu=vfp --with-arch=armv5te --enable-target-optspace --with-abi=aapcs
Thread model: single
gcc version 4.2.1

The basic libraries are available under bionic subdirectory:
bionic/
bionic/libthread_db
bionic/linker
bionic/libdl
bionic/libstdc++
bionic/.git
bionic/libm
bionic/libc

After your build is successful, the android binaries should be available under out/target/product/generic/obj/lib/

mydroid $ file out/target/product/generic/obj/lib/libc.so
out/target/product/generic/obj/lib/libc.so: ELF 32-bit LSB shared object, ARM, version 1 (SYSV), stripped

I tried to compile a simple helloworld.c, but no luck :(

mydroid $ PATH=./prebuilt/linux-x86/toolchain/arm-eabi-4.2.1/libexec/gcc/arm-eabi/4.2.1:prebuilt/linux-x86/toolchain/arm-eabi-4.2.1/arm-eabi/bin/gcc:$PATH prebuilt/linux-x86/toolchain/arm-eabi-4.2.1/arm-eabi/bin/gcc hellodroid.c
Assembler messages:
Fatal error: Invalid -march= option: `armv5te'

I can't wait until someone compiles python with this toolchain. I don't have enough time and know-how in how to arrange this toolchain in a manner so that Python's autotools can compile in it. Hopefully scratchbox or OpenEmbedded people will take up that task and we will soon have a Pydroid.

Has it started?

The recession!

Elon Musk's post on taking the Tesla Motors' chair

These are extraordinary times. The global financial system has gone through the worst crisis since the Great Depression, and the effects are only beginning to wind their way through every facet of the economy. It’s not an understatement to say that nearly every business will be impacted by what has unfolded in the past weeks, and this is true for Silicon Valley as well.

Mark Shuttleworth's post on the financial crisis

The term “credit crunch” is very misleading for the current crisis. It suggests that the problem is merely one of confidence, that calm will return if liquidity is introduced to the system.
My view, though, is that the real issue is one of solvency. This is the systemic bankruptcy of 2008.
Mortgages are just the beginning.

Paul Graham's post yesterday

The economic situation is apparently so grim that some experts fear we may be in for a stretch as bad as the mid seventies.
When Microsoft and Apple were founded.
As those examples suggest, a recession may not be such a bad time to start a startup......

Inkface v0.1

After spending about a month on bug fixes and writing python bindings, Inkface v0.1 is ready. Check out the video that demonstrates two applications written in Inkface framework. The video also shows how the GUI is designed in Inkscape and how to get the app running with few lines of python code.



If you want to try these applications yourself:

• Install the .deb packages (libaltsvg, inkface-python)
• Download python scripts and GUI SVG images: Keyboard (.py .svg) IRC (.py .svg)
  

# Install Inkface libraries
dpkg -i libaltsvg_0.1.0_armel.deb inkface-python_0.1.0_armel.deb

# Keyboard demo
python inkface-keyboard.py keyboard-entry.svg

# IRC demo
python inkface-irc.py irc.svg

Check out the project wiki for future plans of the project. It has some notes to get you started. A look into simple python scripts mentioned above will also help.

Here is my last month's post that discusses the idea behind the project.