Science and more

Plasma Active Two and Pandaboard

2012-02-12T22:35:00.000-08:00

I saw this argurably-bad news a couple of days ago and tried to reach kubuntu team for further information about Kubuntu and, esp. Plasma Active on Kubuntu (a.k.a Kubuntu Active). I was ever trying to create PA PPA by myself since Kubuntu Active PPA isn't active for a well. But I don't have permission to update this PPA and nor does launchpad.net support ARM PPA, I decided to try out PA2 on Pandaboard following old build-from-source way while I am waiting for this PPA to be updated.

However, KDE and Kubuntu code has changed quite a few and I don't have to build everything from source, instead, I can just assume all KDE SC 4.8.0 pkgs in Kubuntu preecise (12.04) are all good enough to run PA2, then only followings are necessary to build:
- share-like-connect- contour
- plasma-active
- startactive

This time I didn't start from Linaro images because it hasn't moved to Precise yet, but I most likely will lose Open GL ES acceleration for X. Furthermore, I started from armhf image which seems to be very promising performance wise.

1) Prepare image
- Download precise-preinstalled-desktop-armhf+omap4.img.gz from http://cdimage.ubuntu.com/kubuntu/daily-preinstalled/current/
- Plug in SD card (assume at /dev/mmcblk0p0 from dmesg)
- Run
sudo sh -c 'zcat ./precise-preinstalled-desktop-armhf+omap4.img.gz |dd bs=4M of=/dev/mmcblk0p0 ; sync'
- Plug into Pandaboard and boot. A standard KDE desktop will be shown

Note:
- I actually did a little trick to have all rootfs in a USB drive and modified boot.scr to use that. But due to slower USB drive I have, it is slower than SD card :-(
- This Precise image has a big problem: no OEM setup procedure for first run, which left a unaccessible system stuck at KDM. I had to mount the rootfs at PC and chroot into it to setup a new user.

2) Get the source
Refer to http://ezjd.blogspot.com/2011/10/building-plasma-active.html for share-like, share-like-connect and plasma-active code. Note that Active/Two branch should be used.

For startactive:

cd ~/kde/src

git clone git clone git://anongit.kde.org/startactive

git checkout Active/Two

3) Install build dependencies

sudo apt-get install debhelper cmake pkg-kde-tools kdelibs5-dev libkactivities-dev shared-desktop-ontologies kde-runtime kde-runtime-data kde-workspace-dev qtmobility-dev shared-desktop-ontologies kdelibs5-experimental-dev libqt4-opengl-dev libqtwebkit-dev kde-workspace-dev libxrender-dev

Note: qtmobility pkg is in universe repo which is not enabled by default

FindQtMobility.cmake is missing in installation and I used one provided by Seba from KDE team.

4) Build
Do the followings for all 4 modules:

mkdir ~/build

cd build

mkdir 

cd

cmake ~/kdesrc/ -DCMAKE_INSTALL_PREFIX=/usr

make

sudo make install

Note: the default install prefix is /usr/local, which is inconsistent with default KDE installation.

5) Run
This time I managed to have a less hacky way to start PA thanks to startactive.

- In /usr/share/xsessions, add a new one plasma-active.desktop with:

[Desktop Entry]
Encoding=UTF-8
Type=XSession
Exec=/usr/bin/startactive
TryExec=/usr/bin/startactive
Name=KDE Plasma Active Contour Workspace
Comment=The mobile desktop made by KDE

- Don't forget to move /usr/share/autostart/plasma-desktop.desktop to somewhere else for backup

- ln -s /usr/bin/kwin /usr/bin/kwin_gles

- Create an empty setup-contour-intro.sh in /usr/bin

#!/bin/bash

echo "Fake contour intro"

- When next time booting, select "KDE Plasma Active Contour Workspace" session in KDM.

See, running PA2 is much easier on Precise but I still have following Problems to solve:
* No mouse cursor
Right now, I have to do workaround:
    - Alt-F2 start krunner and konsole
    - sudo systemsettings
    - use keyboard to select different mouse cursor theme in "Workspace Apperance" -> "Cursor Theme" than plasma active one.
* Enable touchsreen (well, do nothing to KDE :-))
* Missing status icons in panel.
* startkde doesn't live well with startactive
* Open GL ES, of course.

DEB vs RPM : the distribution for mobile device

2012-01-09T22:59:00.001-08:00

Before talking about what distro fits in Mobile or Embedded world, let us revisit the idea: what is embedded device and what is mobile device.

Embedded system was referring to a sub-system physically embedded into another system, nowadays, an embedded device generally means a computer system with very limited resource like RAM, ROM/Flash, power, esp. with a much less powerful CPU than, for example X86. However, it is actually a very subjective thing, for example, some may refer to an micro controller with <10MHz CPU and <1MB RAM, while others are talking about a mobile device with 500MHz CPU with 32MB RAM, even for the same person, the definition changes over time. In general, a typical embedded system is much powerful than one 5 years ago and could be as powerful as a desktop system 10 years ago.

Mobile device refers to a device can be easily carried, normally on battery, but generally laptop is an exception. It was almost the same thing as embedded system 10 years ago because technically they are the same powerful. With that quad-core tablet is coming to market, it is actually as powerful as a PC now. Cell phone as a typical mobile device, was just 200MHz ARM9 + 8MB RAM when I was developing a 3G model a decade ago, but nowadays a cell phone with 1GHz Cortex-A9 + 512MB RAM can barely be a high end smart phone.

Putting the history aside, what is typical spec of an embedded device or mobile device now? It is quite reasonable to assume an embedded device has > 300MHz ARM9 + >16 MB RAM and flash, and a mobile device has >700MHz ARM11(+VFP) + >128MB RAM and flash (Raspberry Pi at $25, for example), while considering a fancy UI, it isn't difficult and expensive to have a mobile device with 1.5GHz Cortex-A8 (VFP+NEON) + 1GB RAM and flash (Allwinner A10, CPU board at $75 and most likely will reach $15 soon). (Actually a dual core Cortex-A9 1GHz + 1GB DDR2 + 8GB eMMC tablet at < $250 can be expected in 2012)

Go back to the topic at the beginning, the question becomes "do we really need a heavily tailored Linux distribution for embedded device and mobile device?", and I would say, yes and no. For low end embedded device like micro controller, any popular Linux distro is too big, however, I doubt such distro will even be considered because this kind of device are for very specific and simple task simply not worth to make general-purpose Linux distro on it, instead a RTOS is our good old friend. At the same time, taking example of an typical mobile device, any slightly modified distro will work well, and for high end ones, no modification is really needed.

Here are some data:
Stock ICS (Android 4.0) running on Pandaboard, tablet mode, home screen, res. 640X480
Flash: 75MB RAM:210MB

Kubuntu 11.10 running on Pandaboard, home screen, res. 640X400
Flash: 2.7GB RAM:295MB
-- Linaro nano: ~100MB flash
-- Linaro alip (X+xfce): ~900MB flash
-- Ubuntu + KDE minimal: ~1.6GB

There are other consideration about speed on mobile device too, which might lead to customised pkgs. However, given the powerful CPU we can have now, this doesn't seem to be the place we have to put a lot of effort either.

Some embedded distributions tend to use RPM instead of DEB partially because the maintainers want the freedom to strip down stuffs "too much" for embedded/mobile system, which has been the tradition in embedded world, even though DEB based distro can be customized and totally independent to Debian. Given the fact that customization is minimized or not necessary, the well-built and thoroughly tested Debian packages for different architectures show the unmatchable strength on simplifying the development and shortening the time to market.

Debian as a general purpose distribution provides more open source packages than any other distributions, but its policy prevents proprietary software from inclusion directly. This is a big obstacle in mobile world because most of GPU drivers are closed. However, derived distro like Ubuntu and Linux Mint always accept proprietary packages for real world usage and can be an easy work-for-me approach.

One last thing to mention is that DEB package database has a lot of text files which was viewed as performance overhead for running in embedded system due to relatively slow storage. But I haven't seen any delay with DEB than RPM on eMMC based system, instead, to me, DEB always performs faster on desktop, laptop and embedded/mobile devices. Some developers also mentioned that binary RPM database is hard to repair.

BTW, noticed today that Tizen released the first batch of code and SDK in developer.tizen.org, which is just SLP from Samsung (and DEB based !), thus, MeeGo is just gone completely.

[Update Jan 29, 2012] Update and add reference to HW spec and minor changes.

2011: Linux Mint the winner? Debian wins!

2012-01-02T20:15:00.000-08:00

In the second day of 2012, I checked distrowatch as usual and noticed another official opinion about the famous "Linux Mint takes over Ubuntu" since this came from distrowatch's statics. It has been a few weeks since Mint climbed to the No. 1 in distrowatch's list based on H.P.D. (hit per day) and Mint fans has been celebrating while others expressed different ideas. Basically the truth is that H.P.D. can't reflect neither the popularity nor the installation base. However, it is worth to look into. Therefore, I killed a couple of hours of my New Year holiday to dig something out of it.

I started from the historic data from distrawatch since 2002, the first time I started checking distrowatch regularly and it happened to be oldest data available from the web site. After downloading the average H.P.D. for the top 30 distros in the list of each year, I put them into spreadsheet (btw, using Kspread) then converted the H.P.D. of each distro into percentage of all the H.P.D. of that year. Given that the nature of Ubuntu or Debian derived distros are very close, I categorised the data of each years to the following 4:
-- Linux Mint
-- Ubuntu
-- xUbuntu (kubuntu, xbuntu and lubuntu)
-- Other Debian/Ubuntu based distros

I carefully selected these 4 because they are exclusive and very interesting to draw into line graph. After that, I met a problem with my Kspread and it can't launch kchart. Fortunately the data is not too much so that I manually imported them into a Google spreadsheet and drew the graph as following:

-- As I said before, it is not about distro market share but where people's interest goes, while in turn, it may affect the market share to a noticeable extent.
-- It is worth to note that the total H.P.D. in 2002 and 2003 was quite low at ~4000 and ~6000. And the data started increasing at ~12000 in 2004 and ~20000 after 2007.
-- Debian derived distros (including Ubuntu and variants) now take majority of public interest at ~40% since 2007. I did briefly looked at other home-grown distro and variants like Fedora, OpenSUSE, Gentoo, etc. but they are at 10% level, thus, I didn't spend more time.
-- Even though Ubuntu is losing interest probably because of Unity, all official Ubuntu variants still attracted similar hits since 2007. I personally don't care about Unity since I am a Qt/ KDE guy even after learned that Unity 2D demonstrated how Qt benefits the UI development.

Since this is just beginning of 2012, I'd like to share something I had in mind:
-- Even though Android replaces most of existing GNU(and other open source) user space components and seems to be successful, I still hope tradition Linux disto can get a breakthrough soon simply because I believe in open source and "not reinvent the wheels". Also I bet on Debian or one of its derived distro.
-- Debian is the only distro supporting quite a few architectures including the present and future of mobile device -- ARM while other important distos like Fedora and OpenSUSE just started the official ARM porting. BTW, 2012 is the key year for Intel to show its capability and possibility of success in mobile world, which we haven't seen a sign.
-- Debian is working on 2 key things: multiarch and armhf. The former will give all the architecture the equal position in distro and ease the cross architecture development and the latter will be the default compiling configuration for new ARM chip in the future. Multiarch is really ambitious and may need years of community effort but this is the advantage of open source and the benefit is already seen in latest Ubuntu. armhf porting is joint effort of Debian community, Canonical and Linaro, and it is a quite different cooperation and vertically in ARM ecosystem.
-- Right now, Debian is still yet to be proved that it can succeed in business/commercial world as well as UI system. Companies needs the assurance behind a distro, i,e., sufficient support from a reliable company and Redhat, the billion-dollar-revenue open source company proves that it is not only possible but very much profitable. But Redhat failed at desktop/UI system side. Canonical targets to fill both the gaps with Debian derived Ubuntu. However, Unity isn't there and I suspect it won't either. This year will be a very tough year for Ubuntu and Canonical. But whether Unity fails or not, I don't think Debian or Ubuntu will fail the world.

Best wished to Debian in 2012!

Update: Find this article Debian is now the most popular Linux distribution on web servers and following graph

Clearly Debian + Ubuntu takes close to 50% of linux server market share in 2011 and more than CentOS + Redhat's share.

DEB vs RPM : building pkg

2011-12-15T22:11:00.000-08:00

Package building system is much more important to developer than normal user but it actually is the major reason for one to chose RPM over DEB or the other way around.

The key to build RPM package is .spec file. Developer basically are free to do whatever he/she wants in .spec file for package building tasks such as configure/make/install/etc. even though some checking with pkg's original makefile or build system are in place, like whether "make install" installs same set of files as .spec install rule. This adds a kind of redundancy because, for example, developer has to add make/install rules in spec file, even if it is just a couple of lines because original pkg's makefile already handles it pretty well. Another down side is macro usages in spec file. Using macro improves the efficiency of packaging but the complete list and document of macros available to a specific RPM based distro are often missing, therefore, it takes some time for new developer to create .spec file efficiently.

rpmbuild is the tool to generate binary and source RPM using spec file. Note that it doesn't automatically install build dependencies of a package.

Instead of a single .spec file, DEB uses a set of files to accomplish packaging, which stays in debian dir. dh_make is the tool to generate default files (a.k.a templates) for DEB packaging. For reuse and share purpose, most common way to build a package is to use dh_xxx scripts for general tasks like untar, patch, configure, make and install. Moreover, most of time it is not really necessary to add explicit calls to these scripts in rules file than just "%: dh $@", which in turn can be automatically generated by dh_make tool along with other files for packaging. Of course, for complex pkg and pkg using special build system, developer will likely have to manually modify rules and other file
(Details please see Debian New maintainers' guide). One interest thing about DEB build files is that rules is actually a normal shell script and can directly launch the building or do incremental build.

dpkg-buildpackage and debuild are the basic tools to generate DEB and deb source package. Once source pkg is generated even before the real building (by "dpkg-source -b"), "apt-get builddeps" can install build dependencies easily. Note that .dsc file for deb source pkg is generated too.

To ensure pkg specifying dependencies properly so that it can be built in different environment, pbuilder is the easy way to verify DEB pkg building in a chroot environment as a sandbox. buildd is the tool to do server building for DEB, but setting up DEB build server is not easy as documentation is not easy to find.

Distribution choosing RPM can freely do the package definition, on the contrary, Debian has more influence on derived distribution than just package format because its strict packaging policy, which in fact leads to more distro compatibility among derived distro and meanwhile we can easily tell one pkg's RPM for Fedora is quite different from its RPM from OpenSUSE.

Open Build Service (OBS) was created by OpenSUSE as an attempt to unify tools for GNU/Linux packaging, and it is really successful, though more for RPM based distro like OpenSUSE, MeeGo and Mer. It provides web UI, command line tools and back-end server setup for building packages targeting different distro. This is really great that it provides packaging project management, web interface and public server for major distros and also fills the gap for RPM packaging because there are no good and popular equivalence to Debian's pbuilder, buildd, or sbuild in RPM world.

However, OBS doesn't really improve DEB packaging, particularly because it introduces different procedure like manual .dsc file modification, not trying to follow recent changes in Debian packaging and generally deb packaging issues take more time to resolve. I view these as the major reasons OBS doesn't get much attention from Debian world.

DEB vs RPM : the tools

2011-12-15T21:34:00.000-08:00

Next thing to package format is the associated packaging tools, and more differences show up:

- RPM comes with rpm, yum and zypper, while dpkg, apt/aptitude for DEB.
- rpm and dpkg is the tools at lowest level, and actually people don't use them a lot except experienced user and developer.
- yum and apt are most popular tools, but I never saw yum's speed is close to apt-get, partially because yum does repo update for every command.
- zypper (or ZYPP) is the default tools in SuSE and MeeGo and aptitude is supposed to replace apt. zypper is better than yum while it isn't faster than apt. aptitute has more functionalities in one tool instead of a set of apt-xxx and it even has text based menu UI, but I notice that it runs slower when cold launch on ARM mostly because python loading is slow on less powerful ARM CPU and slower NAND or SD/eMMC generally used on ARM platform. aptitude uses apt tools while zypper only uses rpm.

I don't have updated information of RPM based GUI tools as I moved away from Fedora for more than 5 years, which gave me a negative impression that it was very slow, and in fact, that was the major reason I moved to Debian based system. There are quite a few GUI package tools available for DEB such as synaptic, kpackagekit and Muon. packagekit is worth noting too as it can work with both (and more) format and usually provides an unified API for GUI frontend.

Till now, all these are about normal user instead of developer, and you may find that despite some might-out-of-date information, normal user won't really care too much about RPM or DEB and they are mostly transparent in latest distribution, i.e. normal user just manages pkgs through distro provided tools w/o caring about what is used behind the scene.

DEB vs RPM : the format

2011-12-15T21:21:00.000-08:00

Even though I limited my spare time into running accelerated Plasma Active on Pandaboard, I still frequently run into questions about what distribution is the best and eventually thought about RPM and DEB since MeeGo started and both at home and work. I have my own preference already but it is not a clear win in many respects, which leads to this serial of posts so that I can write down the facts and thoughts and hopefully move on w/o thinking about it again :-)

First of all, RPM and DEB are the two major package formats of Linux distributions, in case you don't know, however, arguments/fightings/flame wars over more than 15 years never ended in format itself, I won't just stop at format either while from format point's view, I can clearly say that none of them is really superior to the other with a few details to come:

- They are both kind of archive of binary files of a component + config file and script for setting up. The more important part of both is dependence description, i.e., what other components are necessary to run and install it.
- DEB uses tar, gzip and ar while rpm uses cpio for archiving, which makes me slightly lean towards DEB because the tools are arguably more popular and standard, just like Linux init ramdisk uses tar/gzip instead of initrd's cpio.
- It is said that DEB can define dependencies in finer way by "conflict" or "break" but I suspect latest RPM supports these too.
- RPM can define dependencies on file instead of pkgs, which is viewed as one RPM advantage. It actually makes it a little complicated when fixing dependence issues, though DEB can define finer dependencies in different way.
- Previously, the major advantage of rpm was the mandatory signing of a package, which is also supported and forced by Debian now.
- Source package wise, they uses different approaches as SRC-RPM is similar to RPM but packaging source code, while DEB doesn't have "source DEB" format. In Debian, source package is original source tarball + debian patch tarball + DSC file. This makes DEB system a little more complicated packaging wise, but it is easier to update. I will talk about it later.

[Update on Jan 29, 2012]

Running Plasma Active on Pandaboard with OpenGL ES

2011-12-12T22:58:00.000-08:00

It has been a while since I wrote down the build details of PA for Pandaboard. What I didn't mention was the procedure to run PA with software rendering because I didn't find a good way to start PA(actually plasma-device) properly. By default, plasma-desktop is launched and I couldn't replace it with plasma-device. I managed to get it running manually but didn't want to share the hacks :-)

Now, I am still having similar issues but changed my focus to running accelerated PA and finally see it running much more smooth than software rendering, which makes me write down this for anyone interested.

I'd like to say firstly that major work was done by linaro team and kwin/KDE developers, many thx!

Also there was a little distraction that when libqt4-opengl-dev is installed in Ubuntu/Linaro, it actually brought in libgl-mesa-dev and led to auto-removal of Pandaboard's OpenGL ES lib (SGX libs). I found a quick workaround to move on. Details can be seen in bug #847901 and Bug #897429.

OK, now the procedure.

0) Install proper OpenGL ES development pkgs
sudo apt-get install libgles2-sgx-omap4-dev libegl1-sgx-omap4-dev

1)Follow my previous blog to build KDE/PA components until kde-workspace

2) Build kde-workspace
The only deference is the build command:
cmake ~/kdesrc/kde-workspace -DKWIN_BUILD_WITH_OPENGLES=ON
Note: w/o this, an kwin_gles could be built but it didn't work well maybe due to incorrect gles/egl dev lib was installed.

3) Finish the building

Last thing is running. My simplest trick is to run plasma-device directly in KDE desktop. Yes, I know it is ugly :-) I will figure out the proper way after I upgrade to PA2, hopefully during holiday.

Building Plasma Active

2011-10-24T20:34:00.000-07:00

Let us move to the real building journey.

First of all, congratulations to Active One release. I started building PA for Pandaboard before this release but didn't get it done partially because some components was being actively developed and some breaks occurred as expected.

Secondly, building instructions are available from Plasma Active, but unfortunately the developers haven't updated it for a while and some pieces are missing, esp. like instructions for distro other than OpenSuse or MeeGo. As a result I contacted 2 key developers ( Sebastian Kügler and Marco Martin) by email and got lots of help, many thanks!

Last, the details.

What is the first to build? As KDE moved to git and modulization continues, a few big SVN repo were split into quite a few small git repos, therefore dependencies become a little more complicated give the fact that is not well documented.

I decided to reuse as many available external depencies as possible, hence, had to move to Ubuntu Oneiric, which will cause a little issue later on because linaro hasn't have official release based on Oneiric and yet to provide necessary OpenGL ES binary blobs for Pandaboard either. Fortunately, KDE and PA (and Qt 4.7) still support framebuffer based software rendering.

After all, basically all external dependencies of PA can be retrieved from Ubuntu repo and it saved quite a lot of time for building and possibly runtime issues.

Then, building KDE components one by one:
1) kdelibs
-- Dependencies
sudo apt-get install debhelper cmake pkg-kde-tools shared-mime-info dpkg-dev libphonon-dev libqt4-dev libqt4-opengl-dev libqtwebkit-dev libpng12-dev libssl-dev libsm-dev flex bison libsoprano-dev libstreamanalyzer-dev libxml2-dev libxml2-utils libxslt1-dev libgif-dev libavahi-common-dev libbz2-dev libenchant-dev libjasper-dev libopenexr-dev libpcre3-dev zlib1g-dev libjpeg62-dev hspell libacl1-dev automoc libutempter-dev liblzma-dev libattica-dev shared-desktop-ontologies libpolkit-qt-1-dev libxss-dev libqca2-dev libdbusmenu-qt-dev docbook-xml docbook-xsl libxrender-dev libkrb5-dev libudev-dev libgrantlee-dev libxml-parser-perl

-- Retrieve source code
cd ~/kdesrc/
git clone git://anongit.kde.org/kdelibs
git checkout KDE/4.7

-- build
cd ~/build/kdelibs
cmake ~/kdesrc/kdelibs
time make -j2
sudo make install

Notes:
    * -j2 effectively shortened the build time on Pandaboard.
* FindQtMobility.cmake is missing from kdelibs repo. In fact, it has to be installed to /usr//local/share/apps/cmake/modules/. I got one from Sebas fixing this problem.
    * It took ~3 hours

2) kactivities
-- Dependencies
No additional dependencies

-- Retrieve source code
cd ~/kdesrc/
git clone git://anongit.kde.org/kactivities
git checkout master

-- build
cd ~/build/kactivities
cmake ~/kdesrc/kactivities
time make -j2
sudo make install

Notes:
* It only took minnutes
    * kactivities was in kdelibs repo so that it has to be built and install after kde-runtime to overwrite old copy. Hopefully it is already fixed in Active 1.0 release

3) kde-runtime
-- Dependencies
sudo apt-get install libsmbclient-dev libstrigiqtdbusclient-dev libxcursor-dev libasound2-dev libxine-dev libslp-dev libssh-dev libexiv2-dev shared-desktop-ontologies libntrack-qt4-dev libpulse-dev libcanberra-dev libnm-util-dev network-manager-dev quilt

-- Retrieve source code
cd ~/kdesrc/
git clone git://anongit.kde.org/kde-runtime
git checkout KDE/4.7

-- build

cd ~/build/kde-runtime
cmake ~/kdesrc/kde-runtime
time make -j2
sudo make install

Notes:
* It took ~100mins

4) kdepimlibs (optional)
-- Dependencies
sudo apt-get install libgpgme11-dev libldap2-dev libsasl2-dev libboost-graph1.46-dev libical-dev libsoprano-dev xsltproc uuid-dev

-- Retrieve source code
cd ~/kdesrc/
git clone git://anongit.kde.org/kdepimlibs
git checkout KDE/4.7

-- build
cd ~/build/kdepimlibs
cmake ~/kdesrc/kdepimlibs
time make -j2
sudo make install

Notes:
* It took ~ 1 hour
    * This is first time I ever got kdepimlibs built :-)

5) kde-workspace
-- Dependencies
sudo apt-get install libdlrestrictions-dev libqimageblitz-dev libfontconfig1-dev libglu1-mesa-dev python-dev libpam0g-dev libraw1394-dev libusb-dev libpci-dev libakonadi-dev libboost1.46-dev libgps-dev libck-connector-dev libsensors4-dev libxkbfile-dev libxrandr-dev libxcomposite-dev libxft-dev libxtst-dev libxinerama-dev libxi-dev libqalculate-dev python-sip python-qt4 libdmtx-dev libprison-dev phonon-backend-gstreamer

sudo ln -s /lib/libpci.so /usr/lib/libpci.so

-- Retrieve source code
cd ~/kdesrc/
git clone git://anongit.kde.org/kde-workspace
git checkout KDE/4.7

-- build
cd ~/build/kde-workspace
cmake ~/kdesrc/kde-workspace
time make -j2
sudo make install

Notes:
* It took ~3.5 hours
    * It is not mentioned as dependencies of plasma-mobile, but it is necessary.
    * I referred to Ubuntu KDE pkgs for dependencies, but didn't install python-kde4, python-sip and python-qt4 because they brought in the stock version of KDE components from Ubuntu. However, python support is missing in my build.

6) share-like-connect
-- Dependencies
No additional dependencies

-- Retrieve source code
cd ~/kdesrc/
git clone git://anongit.kde.org/contour
git checkout master

-- build
cd ~/build/share-like-connect
cmake~/kdesrc/share-like-connecttime
make -j2
sudo make install

Notes:
* It took minutes
    * Actually Active/1.0 branch is available now, but I didn't try.

7) contour
-- Dependencies
No additional dependencies

-- Retrieve source code
cd ~/kdesrc/
git clone git://anongit.kde.org/contour
git checkout master

-- build
cd ~/build/contour
cmake~/kdesrc/contourtime
make -j2
sudo make install

Notes:
* It took ~ 3min
    * Actually Active/1.0 branch is available now, but I didn't try since contour actually is disable by default in Active 1.0

8) plasma-mobile
-- Dependencies
No additional dependencies

-- Retrieve source code
cd ~/kdesrc/
git clone git://anongit.kde.org/plasma-mobile
git checkout master

-- build
cd ~/build/plasma-mobile
cmake~/kdesrc/plasma-mobiletime
make -j2
sudo make install

Notes:
* It took ~ 30 min
* This is the core component for Plasma Active mobile and tablet UI.
    * Actually Active/1.0 branch is available now, but I didn't try.

9) kde-baseapps (optional)
-- Dependencies
No additional dependencies

-- Retrieve source code
cd ~/kdesrc/
git clone git://anongit.kde.org/kde-baseapps
git checkout KDE/4.7

-- build
cd ~/build/kde-baseapps
cmake ~/kdesrc/kde-baseapps
time make -j2
sudo make install

Notes:
* It took ~30Mins

10) konsole (optional)
-- Dependencies
No additional dependencies

-- Retrieve source code
cd ~/kdesrc/
git clone git://anongit.kde.org/konsole
git checkout KDE/4.7

-- build
cd ~/build/konsole
cmake ~/kdesrc/konsole
time make -j2
sudo make install

Notes:
* It took ~ 5min

11) bangarang (optional)
-- Dependencies
sudo apt-get install libtag1-dev

-- Retrieve source code
cd ~/kdesrc/
git clone git://gitorious.org/bangarang/bangarang.git
git checkout KDE/4.7

-- build
cd ~/build/bangarang
cmake ~/kdesrc/bangarang
time make -j2
sudo make install

Notes:
* It took ~15min
    * It actually is developed outside of KDE projects

Build Plasma Active: environment

2011-09-17T21:44:00.000-07:00

I have been strugling with KDE Plasma Active building for months, even though I can only contribute less than 8 hours per week :-)

Due to lack of usable building document, building KDE is always like a mistery. Even with kdesrc-build's help, it only becomes easier, for x86 platform only. As I am trying to use my Panda board, it makes it more difficult. Also it is now a little more restricted that Plasma Active requires Open GL or GL ES (unfortunately), therefore, I have to use Ubuntu/Linaro since it has fairly latest OMAP4 support including GUI like OpenGL ES 2.0. Well, I haven't really run Plasma Active on Panda board, but it is good time to record what I learned.

BTW, seems KDE team prefers OpenSUSE, which doesn't have an official ARM port or MeeGo, which is dying. Even for MeeGo ARM port, I don't know how well Plasma Active runs since it only supports N900, unofficially.

I started with Linaro 11.08 release. It is based on Ubuntu Natty and Linux 3.0 and runs pretty well on Panda board. First question is which KDE components I should build. According to Plasma Active wiki, I only need kdelibs and kde-runtime befor building plasma-mobile.

Then, fun journey started.

All old instruction for building kdelibs is much harder to find and they are supposed to be replaced by current incomplete wiki pages. This led me to try out kdesrc-build (was kdesvn-build last time I tried). However, it couldn't help me to install necessary dependencies. Eventually, I found kde4libs' deb source and .dsc files in Ubuntu package and used it to install necessary packages, and to my surprise, I successfully built kdelibs for ARM w/o changing anything. But building kde-runtime failed due to one dependency is too old in Natty. Even though I hacked the system to make building continuing, I knew that it won't run afterwards. Thus, I have to move to Oneiric.

Another interesting thing I found is that qemued ARM building on X86 didn't run properly on my own desktop while seems OK on another PC. So all successful build I did is on real ARM chip-OMAP4 and it is much faster :-)

But for Oneiric, things changed a lot. Firstly, no working linaro snapshot based on Oneiric is working now, secondly, Ubuntu Oneiric beta and daily image have several other problems. Even though I finally got Kubuntu one working on Panda board, I then messed up the installation by installing lightDM :-(. At last, I couldn't get chroot working either, whether I did it natively (x86 or ARM) or using NFS.

However, I found netboot image for ARM is available so that I download related files and copy to SD card. Finally I am able to install a minimal Ubuntu on Panda board and able to install other DE like Lubuntu desktop the same way as I did with x86 desktop! With a little tweak with u-boot boot script, I am able to install and run rootfs on a USB drive instead, which I planned long ago and is proved to be faster than SD card as expected!

Here are details:

* Download u-boot, kernel and initrd from http://ports.ubuntu.com/ubuntu-ports/dists/oneiric/main/installer-armel/current/images/omap4/netboot/

-- u-boot.bin, uImage and uInitrd

-- I used boot.scr-fb to enable console on screen (framebuffer)

* Install Ubuntu

-- OpenSSH server and Lubuntu core was selected as extra components.

-- Use USB stick instead of SD card to install.

-- Grub installation failed as expected, but ignore this and finish installation.

-- Create a SD card using http://cdimage.ubuntu.com/daily-preinstalled/current/oneiric-preinstalled-desktop-armel+omap4.img.gz then use this SD or copy the first FAT patition to anther SD card for booting.

-- Create a script file - boot.sh from boot.scr by stripping u-boot header.

-- Modify "root=xxxx" to "root=/dev/sda1" (Device name can get from kernel boot log).

-- Generate boot.scr by "mkimage -A arm -T script -C none -n "Ubuntu boot script" -d boot.sh boot.scr"

-- Now, USB stick rootfs can boot with this SD card.

-- Lubuntu core doesn't install DM so install GDM after booting

(To be continued)

Developing using Panda Board - distribution

2011-02-05T11:49:00.000-08:00

When I got Pandaboard, I just hoped I just could use existing Ubuntu and Android instruction for PandaBoard. Unfortunately, both are not working for me.

-- Only Ubuntu 10.10 runs smoothly even though with a hot OMAP chip, i.e., CPU scaling and power saving isn't working. And I wasn't unable to easily use lastest KDE SC techniques such as Plasma Mobile and KWin over OpenGL ES, etc.

-- Pandroid stays at Android 2.2 and it is always less important to me as you may already know :-)

Then, I started to think doing things cleanly from scratch:

First thing first -- Picking a Linux distribution

Requirements:

-- Full feature distribution instead of an "embedded" one

Normally embedded linux distro is

a) Small foot print (RAM <= 16MB and rootfs <= 16MB), in another word, very few modules available.

b) Heavily stripped down (very limited UI stack)

c) Some components are really old, like kernel

d) Some pkgs are not commonly used in desktop distro like busybox

e) Normally doesn't support package system and run-time update/upgrade

f) Normally building in 'embedded' way, like building image together and assuming downloading/flashing to device, i.e., less flexible

g) But now mobile device is NOT traditional embedded device any more!

-- A modern distribution well maintained by community

Debian, Ubuntu, Gentoo, MeeGo

Debian: well maintained ARM port but rather old pkgs

Ubuntu: with Linaro effort, it is really ARM friendly and most up-to-date

Gentoo: Highly customizable but no pre-built offical binary pkgs and smaller community

MeeGo: Defined as mobile distribution and suppose to be ARM friendly but not seems to be and much less mature than Ubuntu, and more close and less friendly to community. (Update: as Nokia effectively left MeeGo which leaves the future of ARM port in the air, and unfortunately, no other ARM vendor joined so far)

-- A Qt friendly distribution

MeeGo is the only Qt based distribution.

Ubuntu is not based on Qt but community is actively bring in latest Qt to Ubuntu. And one thing is really atracting me attention is that Linaro provides a Plasma-Mobile based image. (Update: Linara Plasma -mobile image is dead, but Plasma-Active started! Even though it is not ARM friendly so far)

-- KDE friendly

Unfortunately none of them uses KDE by default. Only (K)ubuntu is a little bit closer.

-- Pandaboard friendly

Only Ubuntu provides official omap4 kernel and image.

So I don't really have second choice other than Ubuntu/Linaro.

New Panda and New Year

2011-02-05T10:43:00.000-08:00

I've been quiet for a while because every year I am always busy for a couple of months before year end and one major reason is that CES is always just after New Year.

But 2010 is a little different due to PandaBoard was deput in October 2010. And after a whole month waiting, I received it in the end of November. I did complaint about the waiting but I realize now that I was lucky as the backorder takes more than 3 months now :-) and I recieved one of the first 1500 boards.

I did have a big plan for it:

-- Benchmark Cortex-A9 and comparing with Intel Core i3

-- Try out Plasma mobile

-- Build a solid development envoriment for future.

-- Etc.

You may already notice the last "Dev Env" one should be the highest priority, which I learned in the previous months ...

KDE and Mobile - Build KDE in Kubuntu 10.04

2010-06-26T10:23:00.000-07:00

As MeeGo has actually mixed GTK and Qt framework, i.e. much less integrated at application framework level than claimed and expected, I was thinking to find some thing more ideal to me, a pure Qt based UI/App framework.

Actually there is only one choice: KDE. While along with KDE4 is maturing, it extends its arena from desktop to netbook., originally, I thought few people in KDE community would be interested in mobile device world (see this).

Fortunately, Marc Martin sent an email to MeeGo dev maillist caught my attention (though seems only mine) and I realized that KDE community is still thinking about mobile devices, and the first step is KDE platform profiles, which, in my opinion, is modular KDE libraries and infrastructure. Soon after that, this was created to show the related tasks and progress.

Seems things changed besides the name now is KDE mobile and KDE people probably focus more on specific application like Kontact on mobile device instead of KDE framework. Because I didn't involve in KDE development or even closely tracking KDE maillist, I don't know if it is direction change or just limited resource wanted to focus on smaller tasks.

But what interest me is the idea of KDE platform profiles because it is a necessary step for KDE to become a unified platform to various targets, in another word, scalability is what KDE needs even if mobile devices are its second-level target.

KDE has a relatively bad reputation about resource usage because base KDE framework seems taking more disk space and RAM than GNOME. I don't have real data to compare because I don't have GNOME installed on any of my PCs, at work or at home, however, I have minimal Ubuntu + kde-minimal installed with 1.4 GB disk and ~150MB RAM after boot up so that I suspect it is just perception from biased experience because I think, for example, KDE runing KOffice will take less resource than GNOME + OpenOffice. But it doesn't matter whether KDE is more bloated than GNOME or not, instead, whether KDE has a good enough modular infrastructure matters. To be fair, KDE team did great job to do modular-wise improvement since KDE 4.3, however, I am not sure if I can fit KDE with necessary applications in 1GB flash(uncompressed) and 512MB RAM along with other necessary components for a distribution (Actually I was thinking of 512MB flash but I don't see it worths the effort to do that).

Due to fail to get clear idea of KDE resource usage by googling, I decided to do it by myself -- build KDE and profiles from scratch.

What surprised me is that as a long time KDE user and a software developer for more than a decade, it was really a challenge to me partially because information in techbase.kde.org is out of dated, esp. for Debian/Ubuntu part and partially I chose a wrong way to do it: installing necessary packages from distribution (Kubuntu) and build KDE itself.

Eventually I found kdesvn-build script though the web site is down for a while. Thanks to the maintainer Michael Pyne's help I download this script from kdesdk SVN repository and it works perfectly! Here is the steps. Note that I choose to use chroot so not to mess up with my desktop which I use daily and right now it is for x86 only.

1) Use pbuilder to create base rootfs (ref1, ref2)

sudo apt-get install pbuilder debootstrap devscripts

sudo pbuilder create --components main restricted universe multiverse

2) Enter new rootfs after pbuilder creation is done

cd ~; mkdir dev-rootfs; cd dev-rootfs

tar xf /var/cache/pbuilder/base.tgz

sudo mount /proc /home/ezjd/KDE/dev-rootfs/proc/ -o bind

sudo mount /dev/pts /home/ezjd/KDE/dev-rootfs/dev/pts -o bind

chroot ~/dev-rootfs

#add new user for KDE build instead of root

adduser builder

3) Install minimal set of packages (ref)

aptitude install build-essential subversion git-core xorg-dev cdbs debhelper cmake \

kdesdk-scripts subversion ssh xserver-xephyr doxygen dbus-x11 \

libxml2-dev libxslt1-dev shared-mime-info libical-dev libgif-dev libssl-dev \

libboost-dev libgpgme11-dev libxine-dev \

libqimageblitz-dev libbz2-dev libdbus-1-dev libpam0g-dev libpcre3-dev \

libkrb5-dev libsm-dev libclucene0ldbl libclucene-dev libjpeg62-dev \

libxtst-dev xsltproc libxrender-dev libfontconfig1-dev automoc librdf0-dev \

libdbusmenu-qt-dev docbook-xsl docbook-xml \

libglib2.0-dev libboost-program-options1.40-dev libsasl2-dev libxml2-utils libboost-graph1.40-dev

4) Get kdesvn-build

su builder

export SVN_ROOT=svn://anonsvn.kde.org/home/kde

svn cat $SVN_ROOT/trunk/KDE/kdesdk/scripts/kdesvn-build > kdesvn-build

svn cat $SVN_ROOT/trunk/KDE/kdesdk/scripts/kdesvn-buildrc-sample > ~/.kdesvn-buildrc

chmod +x kdesvn-build

5) build

./kdesvn-build

Totally it took > 4 hours on my AMD Atholon64X2 2GHz desktop.

Next step I will try different profile and ARM build.

Right after MeeGo 1.0

2010-05-29T13:48:00.000-07:00

Finally MeeGo v1.0 released as expected, did things changed?

It is been 3 months with MeeGo, and time to summarize.

Contribution to MeeGo: Not too much except 1) answered a few questions to help people who are not very familiar with Linux or embedded Linux 2) clarified some wrong understanding of MeeGo though a little misleading in Qt part :-(

Since I don't want to be a paid contributor of MeeGo because I want to think and talk following my own expertises, what I wanted to contribute inevitably became arguing with people:

-- OpenGL

Started in IRC and Maemo talk, I asked why QtGLWidget is used for Handheld compositor, which implies that HW OpenGL support is necessary to run MeeGo. I got that this is intention that MeeGo will ONLY run on platform with HW 3D acceleration. I wrote 3 arguments for that:

a) Even though OpenGL seems to be default HW in the future, a lot of targeted devices doesn't or will not have it for cost reason at least.

b) Developing GL driver for X isn't easy and normally it will be proprietary, so that developer needs the capability to run the software before it is ready.

c) Qt graphic system has the capability to switch renderer between GL based and SW painter based with almost no code change. (Actually that is one of Qt cross platform advantages).

I didn't get direct answers to them, instead, was told that it is a "done deal" because MeeGo is for the future.

Interestingly, I read an article recently and it indicates that LLVMpipe might be a solution to my concerns though it is based on Gallium3D which Intel seems want to stay away from.

-- Intel CPU and SSSE3

This was started by another developer who figured out that MeeGo day 1 release doesn't work on old Intel CPU, then Intel engineers said that MeeGo requires SSE3 (which eventually turned to SSSE3). Even though I can still run this release on my AMD PC, I expressed my concern about implied CPU requirement. I discussed with another Intel engineer about whether AMD CPU supports SSSE3 or not, but no AMD CPU with SSSE3 was found.

I don't have time and hardware to really test the benefit of SSSE3 so that I only discussed it in another angle: barrier to MeeGo adoption though not many people cared about it in the mail list.

-- MeeGo adoption

Along with IDF in Beijing, MeeGo announced a list of supporters. There was a topic people cheering about we have so many supporters already. I smiled it firstly but couldn't help to write down my opinion:

MeeGo lacks of supports from ARM companies, other x86 CPU companies, mobile carriers, and major cell phone companies (except Nokia :-) ), and implied that it was too early to celebrate.

On the contrary, Android almost have all of these as supporter even though it has its own issues, which MeeGo hasn't got chance to face.

This definitely upset people though no arguing actually happened.

-- Qt as primary UI toolkit

This happened just after 1.0 released. A developer talked about Qt's position in the release. Intel engineers finally said that Netbook UX will stay with GTK applications. I was confused and asked in email about the decision. Firstly I was confirmed with my original understanding that Qt will be primary UI toolkit for MeeGo then I called for more community effort to help porting existing GTK app. Unfortunately, this touched the bottom line of many engineers who had more internal information than me. People rushed in to explain why GTK apps are kept and why they should in the future and even implied me that Handheld UX will be totally Qt based and that is what I care about.

But that wasn't my point. I only worried about whether MeeGo will have an unified framework and questioned about how decision was made.

Now actually I found I should realize this long ago when I was wondering why nobody discussed Qt transition in the first place: Qt transition is not gonna happen with GTK people.

-- MeeGo based on Fedora

In forum, one member asked what distribution MeeGo is based on, and people started again to explain that MeeGo is an independent distribution. This already happened in mail list a few weeks ago.

I simply listed what I found, which proved that MeeGo is actually Fedora based distribution and MeeGo should credit Fedora for any existing good infrastructure it established.

I am not a Fedora fan, but I believe this is common sense in open source world that when something is reused in own project, one should show respect to the author.

-- Push to openness

Openness, openness, openness, people periodically talked about it in mail list :-) All the efforts happened were just asking for more patient in community and wait. At the same time, companies talked loudly in public that MeeGo's major advantage is openness.

Along with less and less people talked about it again and the silence cycle is extending, I suspect people won't really care about it in the future because people will get used to the "open" way of MeeGo development.

BTW, it is rare but did have one case people agreed with me: we need a local OBS build environment though no follow-up.

What is the future of MeeGo? Will it be DOA or beat Android, iPhone OS, webOS, bada, even Symbian technically and commercial wise?

Let us wait and see ...

Android or MeeGo?

2010-04-24T13:33:00.000-07:00

Recently, I read an article: is Android evil? I was surprised that somebody else did summarize the close nature of Android. Seem the author has more internal information than average open source community member like myself. But since this blog would attract a lot of eyeballs, as least I feel, I was shocked that it wasn't widely quoted so that I just happened to find it.

As I was thinking about openness of MeeGo, IDF Beijing held a few technical seminars about MeeGo following by LF collaboration summit, which also presented a few talks about MeeGo. In IDF presentations, MeeGo was referred several times as "MeeGo = Moblin + best of Maemo", and thus I couldn't help to thinking MeeGo as "Moblin NG", which I used in a post in MeeGo forum. On the contrary, in all the information I can get from LF summit, MeeGo was never been defined like this, and unfortunately, few slides or documents was published (or even created?) for LF summit. This week, MeeGo TSG meeting was back, but few things were changes except everyone *agreed* openness is important.

Then I found this talking about Android "fork" of kernel again, and from comments, I also found this. So what level of openness Android and MeeGo are at now? I'd say pretty much same -- "Available" though MeeGo has more code unavailable so far.

What is the advantage of openness MeeGo has over Android?

MeeGo: Day Zero to Day One

2010-04-09T15:56:00.000-07:00

WARNING: I don't have a role in MeeGo nor am I paid to contribute to MeeGo (well, I haven't contributed much) so that I only represent myself.

I defined MeeGo Day Zero (Feb 15th, 2010) when MeeGo project was announced and www.meego.com went alive. And MeeGo Day One, Mar. 30, 2010 was officially announced on Mar 3rd, 2010.

I was excited about MeeGo from Day Zero and joined MeeGo immediately. But people may notice that Day One was publicly announced 2 weeks later. Between these 2 weeks, people kept talking, asking even debating on the mail list and IRC channel simply because MeeGo started with very limited public information about whole architecture and even time frame.

As matter of fact, meego.com did clearly say that rpm is the packaging format and OBS is the building system. There wasn't too many questions around OBS since it even isn't available after Day One, but for rpm decision, I can even say that a flame war has been a while because obviously, Maemo people already got used to deb and tools and I believe that is also a major reason some people really love Maemo like me. Although people are silence about it now, probably because they realized that it's not gonna change, the community didn't really get the technical reason(s) why rpm was chosen. It happened before in Moblin when it moved to fedora based distribution because of rpm, but no compelling reason was given about rpm advantage except for some vague license information "problems" with deb. I personally don't care about rpm and deb, but regarding tools to support package management, I strongly prefer the Debian ones. Anyway I can live with rpm decision, which turned out that zypper is the comparable tool to apt/aptitude in MeeGo.

Another big thing clearly stated from Day Zero was that Qt is preferred App/UI framework for MeeGo. I was very happy with it but I did expect even bigger flame war regarding Qt vs GTK was gonna happen because I think Moblin community should have a lot to say just like so many flame wars about GNOME vs KDE. I was wrong because I didn't even see much discussion in MeeGo mail list or IRC, as a result, I suspected that Moblin community runs very different from Maemo's, and I feel the latter is more like any other open source community.

These are very good examples about closed development as decision is made behind closed-door and in this case, I am still curious about how Intel and Nokia did the negotiation :-) Did these drive away some developers? I'm afraid so though I stayed when more reality in mind.

(Another big discussion was about whether N900 will have MeeGo support or not but I didn't follow because N900 is too expensive to me :-( )

I'd like to express my appreciation to people standing out during these weeks to build/merge community because I can tell they were doing the job for the good of MeeGo not Nokia or Intel (not directly :-) ) even when most of them are paid by them. And they are still doing the same thing now and I do hope these will continue forever.

After Day One was announced, I could image people were eager to see what would go public, just like me. But I did have unrealistic expectation while waiting as I wanted to see an open MeeGo development would be there within ~6 weeks. It turned out that such thing will never happen for any company-found project in such short time period.

On Day One we basically got a lot of code and nothing else. (To be fair, we got git repository, package repository, bugzilla, more details in MeeGo architecture, etc. along with the code, but what else?) Someone described this the same as "Android codedump" which really said it. Even though, people including me still were enthusiastic to ask questions, help others and try to start as much as discussion in mail list after that.

Another interesting thing I noticed later is that Novell started involvement in MeeGo in early days, but it wasn't very visible to me at least.

Before MeeGo

2010-04-02T16:15:00.000-07:00

As all my career is on embedded system, now embedded linux, I have been looking for a open source linux distribution for embedded system. Note that this "embedded" system isn't about traditional embedded system with very limited hardware resource and simple UI or even no GUI at all. Well, I should use the term "mobile device", for example iPhone, but right now most of Linux system for mobile device developing follows the same way traditional embedded linux is doing: cross compiling, image flashing, and so on.

I have alway been thinking of a different way to develop mobile device: the DESKTOP way.

-- Package based rootfs management so that it is not necessary to re-flash the whole image when only some portion of image is changed, and it provides the flexibility and capability of runtime upgrade as well. More important, no need to build whole software stack when you really just change a component.

-- Native compiling to ease the burden to patch components which doesn't support cross-compiling well. Yes, to develop ARM on x86 will need some kind of cross compiling, but thanks to qemu and binfmt, it can be done just like native compiling and it can even been accelerated by crosscompling with some tricks. Furthermore, OpenSUSE build service provides a cloud-like build farm to accomplish that.

-- Rich GUI. UI is even more important than before, maybe just because iPhone makes cell phone makers realize they are far behind. However, does Linux for mobile have to replace whole UI stack to catch up iPhone? Seems the answer is YES to Google Android but it is really NO to me. I have the faith in X11 because it is still the most matured UI system on Linux though I dislike the complicated driver model and other legacy stuffs. Actually, most of criticism around X11 like being bloated and inefficiency are just vague argument and untrue on today's powerful hardware.

-- UI framework and UI toolkit. The major benefit with a well designed UI framework is to largely simplify the GUI application development. A UI framework is tightly coupled with underlying UI toolkit and my preference is Qt. I know that someone still say that GTK is better. But nowadays, GTK isn't at the same level as Qt anymore, just as Nokia names Qt an application and UI framework instead of an UI toolkit and GTK lacks the portability as Qt has too.

-- Application. Designing application was very similar with designing middle-ware because they both employed C or C++. Java was trying to take over what C/C++ dominated but far from succeeding. Some scripting languages like python and even "web language" JavaScript went one step further to ease the developer but basically they has same principle in blood: developer has to think in programmers' way, even though people need much less training and experience to write a pretty good application with them. However, it seems no better way to do application than these now. QML is a very interesting attempt to totally change application development. Yes it uses JavaScript but it isn't necessary to write much JavaScript code and it (with Qt) tries to create a new approach to design UI based on canvas(graphic view) instead of traditional widget/layout. Let us see where it will lead to in the future.

-- Web application or native application? I expect there will be a mix for a long time. Fortunately Qt provides integration at application framework level.

But I was disappointed that most of effort to make a desktop Linux distribution for mobile device failed or are still struggling because of, I think, a few of business reasons. For example, Ubuntu started a mobile project but nothing excited about it and obviously Ubuntu/Canonical is focusing on netbook only now.

Debian is a little different as Embedded Debian has been there for quite a while and Grip was created to provide package compatibility with desktop Debian. Frankly, Grip is really good though it hasn't reached product quality yet. But I suspect it will land on many mobile device as a pure open source distribution by community only.

A few year ago, Google bought Android and started this "open source" OS for mobile phone. I was really excited then because Google's money and influence are really what a Linux mobile distribution need and hard to find. Unfortunately, a few years later, even though Android is picking up traction now, I realized Android is just another commercial mobile phone OS, which "happened" to use Linux kernel and has source code available to public.

-- Android was designed for mobile phone only. Interestingly, although companies are keen to port Android to other mobile devices, it shows lack of flexibility to be adapted to different screen and different user interaction model, furthermore, it still lacks of support from big cell phone market players.

-- Android is being designed in a closed way just like RIM or Apple. Now everyone can feel the absolute control from Google on Android. I even suspect that some technical decisions are made just because of this so that Google can control the non-standard API and components to ensure software written for Android has to be what Google wants it to be. It seems that most of source code is available so that everyone can do whatever they want with it but no Android fork will be able to compete with Google Android because they will never have the money and manpower Google has. Also Google is very sensitive with deploying their proprietary applications because it is for its good only.

As matter of fact, I am not qualified to analyze Android in detail from technical perspective because I haven't read Android code for more than a year, but I doubt it is quite different from the 1.0/1.5 code I ever read.

Maemo is similar with Android except it is based on normal Linux software stack and operated in a much more open manner. But because it had a few proprietary components and some information was hidden, I wasn't able to really spend much time on it until Mer was started.

Mer met the expectation I like for a mobile linux distribution except for its lack of commercial supporter.

When I was waiting for Mer to move to Qt following Maemo, surprisingly MeeGo was announced. At first glance, it is exactly the Linux distribution what I was dreaming for (well except for rpm decision).

Virtualization is "less" important to me

2010-04-02T16:05:00.000-07:00

I haven't updated my blog for quite few months and won't see I will have much time on VBox in near future. It doesn't say that I won't use VBox, on the contrary, I use it everyday, esp. after I found it performs much better on my new i3 laptop with 3.1.x releases. I just want to be more focus on other things like some open source embedded open source projects.

Unfortunately, I didn't write a single line of code for VBox though I did help people and report problems on forum.

But I will keep an eye on KVM for desktop virtualization and VirtualBox in the future because they are really good tools to do developing :-)

Kubuntu 9.10 wireless

2009-10-25T14:21:00.000-07:00

Following Kubuntu development issue s, the wireless is the most notable issue. I had the same experience sine Kubuntu 8.10 and it almost drove me away from Kubuntu. I had to do some walk-around to make the wireless working but none of them are KDE native solution.

I quite understand that it was KDE network management issue most of time, but I was just curious why nobody in KDE or Kubuntu can fix it. Until recently, I got to know it is actually the integration issue between kde network manager and kwallet, and I think it is really something Kubuntu team can improve, though I was disappointed and didn't expect it will be fixed soon.

What surprised me is Kubuntu 9.10 RC (well, a few updates after RC) changes the network icon when wired network is connected as it won't show unplugged cable when connected. It really made me thinking if wireless gets improved.

After a couple of minutes, I find wireless IS working, and here is my steps:
-- sudo iwconfig eth1 essid
-- Wait until my network is shown in the list
-- Click it and add a new wireless connection with keys, etc., and check " automatically connecting".
-- When it asks "If allow KNetworkManager to access KWallet", select "Allow always"
-- Then I can connect to my wireless router.
-- After reboot, it will ask for KWallet password, and finally wireless gets connected automatically.

It seems to me that "Allow always" does the trick, but maybe there are other fixs I can't see directly.

Now I am wondering if fresh installed Kubuntu will do all the setup smoothly.

Update: As in Kubuntu 9.10 release notes, this is still a problem, and it suddenly doesn't work any more. I almost switched to GNOME nm-applet then I found kwallet daemon wasn't running. After I added kwalletd into auto start list, and repeated all the steps, everything works fine now.

KVM isn't ready for Desktop virtualization

2009-10-18T12:56:00.000-07:00

Given the bad experience of VIrtualBox 3.0.6 and 3.0.8 , I decided to give another shot on KVM.

I used Kubuntu 9.10 beta, and installed qemu-kvm, which is pretty much latest with version 0.11, then following this instruction to convert my windows VDI to KVM's qcow. And by "kvm -m 512 -soundhw all -hda win.qcow", it boots up without any problem (well, a little problem is that windows splash screen was rendered slowly). And all the virtual hardware like audio, hard drive, ethernet, keyboard, mouse, etc. worked out of box except video card.

Video card was working but not in good shape: it is slow. Actually, it is hard to notice in normal operations until I did some media playback, which is barely usable. So I looked into kvm help and googled and tried for a few hour, I couldn't make it better with the default -vga curris. (-vga std only provides 16bit color and 800X600 resolution, while -vga vmware and -vga xenfb simply don't work in Windows geust)

After more searching, I finally gave up as I realized that video problem is a known issue for KVM (I guess for QEMU and Xen as well). And it seems these vitualization solution won't do much thing on this issue soon. So I have to go back to the good "old" VirtualBox and wish I can get a more usable and stable 3.X release (3.1?) soon.

VirtualBox vs VirtualBox

2009-08-17T14:38:00.000-07:00

No, you aren't looking at wrong title :-)

I am comparing VBox to VBox and more precisely, one CPU to 2 virtual CPUs.

I heard a lot about bad performance of more than 2 virtual CPUs with VMWare. As VBox just supports multipl virtual CPUs in 3.0 release, no too many information but many are reporting instability issue with it in virtualbox.org, however most of issues are Windows guest related. I'd say dual virtual CPUs works OK with Linux guest.

Does multi-virtual-CPU improve performance? Here are the data:

In apache test, dual CPUs got ~10% improvement. And I noticed that both cores weren't in full load as one core was used 100% when single CPU test.

Unfortunately, IO performance dropped for ~50% with dual CPUs. Sounds like multiple virtaul CPU adding more overhead.

With dual CPUs, compiling time reduces by ~25%. Again, not a lot IO/disk operation found during test. These 2 tests show that dual CPU helps building but considering IO performance drop, I doubt it gets improved in real world building.

Performance got noticable improvement with these tests but still behind native.

Dual CPUs didn't help during these test, if not dropped a little bit.

I would stay with my good old single CPU configuration for most of my VBox guest as it is reliable. And sometimes using all physical cores in guest will slow down host and even makes it no response if heavy load task is running in guest.

To wrap up the whole benchmark thing, I did a few test with HW virtualization turned off. I did remember that VMWare engieer worte an essay saying software virtualization is faster than HW peer and it was backed by help document in previous VBox releases. Now, it is NOT the case as test result shows their performance are comparable if not the same, so I won't upload the diagrams to save space :-)

VirtualBox vs VMware server (vs KVM)

2009-08-14T14:07:00.000-07:00

Running the benchmark became a very tedious job as it took hours to finish. Furthermore, KVM isn't stable enough to finish Linux installation and benchmarking! Although I managed to installed Ubuntu as guest OS in KVM, I am unable to get a full set of performance data.
BTW, I hate that PTS doesn't store any date until the whole test suite is finished which make it ever harder in KVM case.

After all, I got something, well, only vmware server vs VBox. I have some concept about KVM in a few tests, which I will talk about in the comparison.

###################################################
Hardware:
Processor: AMD Athlon 64 X2 Dual Core 4000+ @ 2.10GHz (Total Cores: 2)
Motherboard: Dell Inspiron 531s
Chipset: nVidia MCP61
System Memory: 1859MB
Disk: 160GB WDC WD1600AAJS-7
Graphics: GeForce 6150SE nForce 430 512MB (425/666MHz) (512MB?! I don't have it. The only thing I have is 256MB shared memory)

This isn't an amazing computer neither does it have modern configuration. But it is the best computer I have, which is good enough for my development.

Software:
Host: Ubuntu 9.04 64-bit with xfce instead of gnome
Guest: Ubuntu 9.04 32-bit w/o GUI running on single CPU, no guest-addon installed. HW virtualization turned on.

Virtualization software:
VirtualBox 3.0.4 64-bit for Linux
VMWare server 2.0.1 64-bit for Linux
KVM 84 (coming with Ubuntu 9.04)

Benchmark software:
Phoronix Test Suite 2.0
Test suite: based on linux-system but a few "duplicated" tests removed to save time

###################################################
Note: Native banchmarking is just for reference because it has 2 cores available.

Clearly, VMWare guest is 2 times faster. Actually, KVM is faster than VWare.

VBox guest threaded IO write is slower than VMware one but read is much faster than VMWare guest in thread IO read.

Vbox guest doesn't do well in compiling comparing to VMWare, the most important thing I care about. However, they both suck comparing to native. This explains that I saw big performance drop when building in guest OS at work.
I managed to get KVM finishing this test for a couple of times. The performance is comparable and seems KVM is the fastest one though still slower than native.
I am not sure if parallel building involved in these tests. I will figure out later.

In previous 6 tests, VBox is sightly faster than VMWare and both of them are behind native probably because of dual core.

In the rest tests, VBox keeps a close leading over VMWare and they are both close to native performance.

Overall, Guests OS under VirtualBox and VMWare have similar performance with exceptions of apache and compiling, which VBox really need improvment.
Both need to improve IO performance too.
Another thing need to point out is that I noticed that VBox NAT performance is worse the VMWare but both of them are behind KVM which has near-native network throughput when installation.

VirtualBox vs VMware server vs KVM -- Background

2009-08-11T12:42:00.000-07:00

I have been doing Linux development for quite a few years and starting from my current job, I work on Linux platform full-time. But ironically, I have to use Windows PC at work while all of my development are linux related (Frankly all I need for Windows is just outlook. Some other tools provided by company are windows only while I barely touch them).

The same thing happens to every colleagues of mine. Then virtual machine was introduced. Just like RedHat/Fedora is mostly used at work because of its previous popularity, vmware is used widely too, first vmware player then vmware server. I don't like vmware player as it is too limited, such as no VM creation is allowed (though workaround exists). And vmware server was the only one I used a few years ago, until I knew VirtualBox.

At that time, I immediately left vmware and went for VBox for its simplicity, performance, and open source. I didn't bother to benchmark VBox 1.x and vmware server 1.0 then since vmware was way far slower. And this was the reason I introduced VBox to my colleagues at my current job.

It's been while since then and now we have KVM and VBox grows to 3.0. Given the fact that some of my friends are still using vmware server 2.0 now, I have been curious how they run now so that I decided to do benchmark and comparison. And finally I find some time.

I am not going to do unbiased comparison as I will stick to VBox whatever result I get from this and possibly move to KVM on Linux host because Oracle-SUN acquisition brings uncertainty to VBox's future. Vmware server 2.0 is much faster as I can tell right now and much more bloated as well. I really don't get how it becomes ~500MB installation tarball, ~700MB installation and uses more resource to just provide a web server and web interface. Every time I try to install and run vmware server, what I am thinking at the same time is how soon I can get rid of it. Furthermore, it won't run on slower(Pentium 4) and less RAM(1GB) PC anymore.

In another hand, it won't be a fair comparison anyway as target of each are different: VBox for desktop virtualization, vmware server for server and KVM is kinda for server.

The benchmark tools I am going to use is Phoronix Test Suite 2.0. And It isn't a perfect tool either. It is hard to reach scientific conclusion from the result as the tests ain't organized well and some critical tests are missing such as network benchmark. However it can still give an overview of how a Linux system runs.

OK. Let's cut the crap and press the start button ...

Linux usage (part 1) - CLI basics

2009-07-18T21:06:00.000-07:00

Command line interface as the primary interface to Linux is still important though GUI tools can do more and more and seems it is going to replace command line like Windows. Ironically, Microsoft noticeably emphasizes command line tools since Vista, which in turn proves that command line interface can not be totally replaced.

One advantage of CLI is remote accessing. You will found ssh/telnet/ftp is more usable in narrow band connection than other GUI tools especially remote desktop.

However, CLI can't do everything effectively. One example is web browsing. By using Lynx, you will never actually browse internet as you need and nowadays people can not live with internet connection without browsing web pages.

The first thing to understand CLI is the shell you are actually interacting with. BASH as default shell for Linux will be covered below while a lot of others is out there.

http://free-electrons.com/doc/command_memento.odt is the best summary of commands I ever found. And it can be used as a reference card too.

Notes to it:
-- Get all environment settings:
env
-- Set an environment variable
export =
example: export LD_LABRARY_PATH=$LD_LABRARY_PATH:/local/bin
-- Symbolic link (called as soft link too)
It is best way to used symbolic link to make a copy of a file in different directories and keep them synchronized all the time.
More word: making a symbolic link doesn't make a copy of source. Somewhat it is like shortcut in Windows but it is much more powerful than shortcut because of the good of Linux file system.
-- rm -fr
Be very carefule of rm -fr because it deletes everything under the directory specified without mercy and possibility to restore!
-- filtering
Linux command supporting pipe by using "|".So we can do filtering like "ls -a | grep Vb" to show the line with Vb only.
-- Mount
You can even mount an ISO file.
For example: mount -o loop -t iso9660 file.iso /mnt/test
-- /mnt/test has to be created before
-- /mnt is usually used as base directory of all mounted file system. In new Linux distribution, /media is used as base to mount auto-mounted file system and removable media file system like USB key.
-- /etc/fstab is used to define auto-mounted file systems
-- Do umount before removing a key physically. However, some distribution supports GUI tool to "safely remove" it just like Windows.
-- Access CLI/Terminal
In GUI desktop:
GNOME -- Application->Accessories->Terminal
KDE -- K->System->Terminal
From anywhere:
Ctrl+Alt+Fn (Fn is F1 ~ F6 depending on how many terminals are enabled at startup)
You can go to X windows(GUI) by Ctrl+Alt+F7
Note that in this way, the terminal is realone than terminal in GUI desktop. For example, when a driver prints some message, it won't go directly to terminal in desktop, but it does here.