Performance

Overall, I deployed the successive KDE versions showing up during the Fedora 12 life-cycle on 4 computers. What struck me the most compared to Gnome is how diverse the experience was. Gnome + composition feels much the same on each machine, you don’t really notice a big difference in terms of performance if you have an integrated Intel chip or the latest ATI graphic card.

Due to KDE’s higher usage of composition features (and nobody wants to run KDE without composition), it was much more a hit or miss situation. On 2 of my computers with ATI Radeon HD 4550 + the open source driver, KDE was just unusable. Ironically, KDE feels the fastest on integrated Intel chips. Even there, the kickstart menu opening behaves strangely sometimes, it feels sluggish the first 3-4 times you open it; you can see it open “transparently”, then redraw the real menu content on top of it 0.5 seconds later.

I’m well aware that it’s probably a driver issue and not KDE’s fault, but what end-users see is simply a slow desktop…they don’t want to know why it’s slow. Installing ATI’s proprietary driver probably helps, but as ATI seems to only release new drivers following the Ubuntu release cycle, we are out of luck.

Usability and complexity

Usability is what I was the most concerned about. As with every new environment, you have to get used to the tools it provides. Here I have to thank the Fedora KDE SIG for quickly migrating to new KDE versions, I could really see a better user experience at each release. All my initial complaints were addressed, which speaks for itself regarding the huge work they (and upstream) do.

What is really nice compared to Gnome is to have only one task bar/panel (like in Windows). On modern 16/10 and even more on 16/9 displays, it gives you more space for your programs. It feels cleaner. After some weeks, I found replacement programs and usage tricks for everything I was doing in Gnome, no problems there.

All the features constantly integrated to KDE also make a huge difference once you learn how to use them. Take tabs merging in KDE 4.4 for example, it’s just genius. KDE is filled with these great little tricks, the only problem is to even know that they exist and learn how to use them.

Fortunately, they do a good marketing and information job, have a look at http://www.kde.org/announcements/4.4/ for example.

What I had the most problems adapting to is the file browser…renaming files is a pain for example. I just can’t get used to it; it breaks any convention set by any other desktop environment. It’s all nice and shiny in demos, but in a production environment I just wanted to shoot myself sometimes. I don’t know if I’m using it wrong, but damn…6 months. Ok, I agree that you don’t spend your whole day in the file browser.

On a lighter side, what I also don’t like are the tons of different programs installed by default with KDE, all of them having different icon artworks and styles. It feels bloated with a diverse patchwork of software from the beginning and I somehow have a psychological problem with that

What now?

I installed Fedora 13 with KDE and the file indexing feature is now enabled by default, which is nice. So, will I stay with KDE for Fedora 13? No. Let me explain why…

• First of all comes the performance problems mentioned above. It’s just not usable due to the drivers’ composition support. Working with a slow GUI is a no-go for me.
• Regressions. During all the different KDE updates I got, there was some kind of regression or big modification in the way a specific KDE feature works. It seems that this is the way KDE does its development, but I’m not sure I want these changes during a Fedora cycle.

Don’t get me wrong, KDE is very cool; it’s perfectly usable and nice on a machine which can give it good performance. I want to love it and will definitively give it a try at each new version; I’m pretty much convinced that at some point it will replace my Gnome desktop, just not yet. It’s just not as polished as Gnome right now.

What I could see during my 6 months with KDE is a very fast moving community which listens to their users, bringing innovative concepts to the desktop environment. I’m still convinced that the only way to give KDE a fair shot was to “force” myself to use it. I really tried to use it from a “naive” point of view without prejudices.

As I often use this feature, I wondered how to get it back…Anvil on #fedora-fr pointed me to the System > Preferences > Keyboard Shortcuts configuration window; it’s amazing how many shortcuts I wasn’t aware of exist in there.

This feature is simply available by pressing Ctrl+Alt+D.

For example, I want www.foo.com to respond on IP

• 192.168.1.20 from inside the company’s network
• 193.134.215.34 from the outside world

In fact, it turns out that it’s quite easy to implement with the Bind DNS server. A friend pointed me to the usage of “ACLs” and “views” in the Bind configuration. Here is a stripped-out basic example for a named.conf acting like we want:

//We define an ACL for the LAN

acl "lan" { localhost; 192.168.1.0/24; };

//We define a view for requests from the LAN

view "internal" {

  match-clients { lan; };

  zone "foo.com" IN {

    type master;

    allow-query { any; };

    file "foo.com.internal.hosts";

  };

};

//We define a view for external requests

view "external" {

   match-clients { any; };

   zone "foo.com" IN {

     type master;

     allow-query { any; };

     file "foo.com.hosts";

   };

   zone "bar.com" IN {

     type master;

     allow-query { any; };

     file "bar.com.hosts";

   };

};

You first start by defining an ACL (access control list) for your internal network. It’s just an alias and you can include multiple networks in it. The rest of the world already matches a built-in ACL called “any”.

Then you need to define “views” which will match an ACL. As Bind reads your configuration in order and stops on the first match, you need to create a view for your internal network first. In our example, any query coming to *.foo.com from our internal network gets a response from the data in the “foo.com.internal.hosts” file. If you come from the outside world, you will get a response from the data in the “foo.com.hosts” file.

Similarly, if you try to access *.bar.com from inside the network, the server won’t respond as it isn’t responsible for this domain. However, if you try to access *.bar.com from the outside world, you will get an answer from the data in “bar.com.hosts”.

Easy, isn’t it? Of yourse this is only a short example.

Some months ago, I wrote a post about “Configure the KDE Dashboard to behave like in OSX“; the options to configure this have now been moved to System Settings > Desktop > Workspace. Simply select “Show an Independent Widget Set” in the drop-down box and you are done in KDE 4.4.

Attention: The patch policy has silently been changed by Oracle quite severely. The new strategy, which is also documented in Software Update Entitlement Policy for Solaris, enforces the requirement of a support contract to download any patch.

Unlike before, even security patches are not available for free anymore.

Until recently, Solaris 10 was free to use and Sun provided security patches for free as well; if you wanted further support you had to pay. It’s a widely used economic model in the open source world and has the great advantage of “hooking” up small companies to your products by still making them usable in a production environment.

At the company I’m working at, that’s exactly what happened with MySQL: we could use it for free to see if it fitted our needs and when the time came for us to need support, we paid for support. Everyone wins.

Now Oracle has pretty much cut every small Solaris user from using it in a production environment, to me it looks like they don’t even want to care about them. Solaris is still used in a lot of big corporations who pay a lot of money for support, but I wonder how long this will last…Just for fun I’m pasting some phrases from Oracle’s documentation:

• A separate Sun support contract is required for every system to which you apply Solaris Software Updates, including test and development systems.
• If your support contract lapses, you loose the right to use most Solaris OS patches and you must remove them from all systems.

Remove patches from a system, is this a joke? Did the guys who decided that already work in IT? Yeah great Oracle, that’s REALLY a good way to treat your future customers. Now you can be sure that I will try to replace every Solaris I see with a Linux box.

It’s sad for Solaris, the technology behind the OS is good but due to bad management decisions it’s getting less and less market-share. I feel sorry for the few passionate people behind Open Solaris.

Some may argue that RHEL is also a paid OS, but at least it’s clear from the beginning and Red Hat donesn’t screw their customers with dodgy moves like that in the middle of a product life-cycle.  And you still have CentOS if you don’t want support. What Oracle just did is a hold-up against the small Solaris users and I’m really angry at them.

To have a better understanding of the whole platform, including GTK+ programming that we are not going to use, Nokia has a series of good videos:

• Get started with Maemo 5
• Introduction to the QT Mobile Platforms

Scratchbox

When we installed the SDK yesterday, I told you that a lot of files went into a /scratchbox repository. For the sake of clarity, it’s a good idea to explain what Scratchbox is. Directly stolen from Scratchbox’s website we can read that “Scratchbox is a cross-compilation toolkit designed to make embedded Linux application development easier. It also provides a full set of tools to integrate and cross-compile an entire Linux distribution.”

The N900 has an ARM Cortex-A8 processor and we are developing on x86, that’s why Scratchbox is used…cross-compile our code to the ARMEL target so it’s deployable on the real phone. In the SDK, Scratchbox is used as a completely autonomous Linux system living in /scratchbox; so all the packages that we are going to install in this OS won’t affect Fedora in any way.

Repositories management in Maemo 5

As Maemo 5 is “just” a modified Debian, so it is using the same tools to manage packages: apt and friends. As with any Linux OS based on packages you can add repositories to get software. In Maemo 5, the repository structure is exactly what we had before Fedora 5/6: a “base” repository managed by Nokia and “extra” repositories managed by the community.

So…repositories. By default only a couple of select repositories related to the SDK and Nokia’s proprietary binaries are enabled. What we want is to enable the community “extra” repositories so we can play with other applications. It’s managed exactly like in yum: edit a text file and update the repository list.

The first thing to do is to login to Scratchbox:

[Steven@x301 ~]$ /scratchbox/login
Welcome to Scratchbox, the cross-compilation toolkit!
Use ‘sb-menu’ to change your compilation target.
See /scratchbox/doc/ for documentation.

Now edit the repositories list, the links to the extra repos are available on http://repository.maemo.org. We are going to add extras only, add extras-testing and extras-devel at your own risk…. Note that “fremantle” is Maemo 5′s name:

[sbox-FREMANTLE_X86: ~] > vim /etc/apt/sources.list
#Extras
deb http://repository.maemo.org/extras/ fremantle free non-free
deb-src http://repository.maemo.org/extras/ fremantle free
#Extras Testing
#deb http://repository.maemo.org/extras-testing/ fremantle free non-free
#deb-src http://repository.maemo.org/extras-testing/ fremantle free
#Extras Devel
#deb http://repository.maemo.org/extras-devel/ fremantle free non-free
#deb-src http://repository.maemo.org/extras-devel/ fremantle free

Now update apt’s local cache:

[sbox-FREMANTLE_X86: ~] > fakeroot apt-get update

Install QT in Scratchbox

At the moment, QT 4.5 is the default version shipped with the 1.1 firmware, QT 4.6 will come with the 1.2 firmware release as far as I know and it contains many changes to be better on Maemo. If you want to play with QT 4.6, you can install it from extras-devel, we are going to stick with 4.5 at the moment. The installation is dead simple:

[sbox-FREMANTLE_X86: ~] > fakeroot apt-get install libqt4-gui libqt4-dev

Deploy your first QT application in the emulator

I’m not going to start a QT course here, but there is a lot of online material available for that including the first edition of the “C++ GUI Programming with Qt 4” book. I have ordered the second edition on Amazon and it’s really great.

So, let’s create our first QT application, compile it and run it on the emulator! You may have noticed that the SDK also installed an “sbhome” directory on your desktop. This is your user’s home directory in Scratchbox. So it’s a filesystem the Maemo 5 emulator has access to…that’s why it’s a good place to store your QT projects. Go to this directory and create a HelloWorld folder. Create a “HelloWorld.cpp” file with the following content in it:

#include <QApplication>
#include <QLabel>
int main(int argc, char *argv[])
{
QApplication app(argc, argv);
QLabel *label = new QLabel(“Hello World”);
label->show();
return app.exec();
}

Thanks to QT, these lines will magically generate a complete GUI application. Our source code is ready, now we need to create a QT project from it and compile it. For this, we need to be in Scratchbox:

[Steven@x301 ~]$ /scratchbox/login
[sbox-FREMANTLE_X86: ~] > cd HelloWorld/
[sbox-FREMANTLE_X86: ~/HelloWorld] > qmake -project
[sbox-FREMANTLE_X86: ~/HelloWorld] > ls
HelloWorld.cpp  HelloWorld.pro
[sbox-FREMANTLE_X86: ~/HelloWorld] > qmake
[sbox-FREMANTLE_X86: ~/HelloWorld] > ls
HelloWorld.cpp  HelloWorld.pro  Makefile
[sbox-FREMANTLE_X86: ~/HelloWorld] > make
g++ -c -pipe -O3 -g -Wall -W -D_REENTRANT -DQT_NO_DEBUG -DQT_GUI_LIB -DQT_CORE_LIB -DQT_SHARED -I/targets/FREMANTLE_X86/usr/share/qt4/mkspecs/linux-g++-opengl -I. -I/targets/FREMANTLE_X86/usr/include/qt4/QtCore -I/targets/FREMANTLE_X86/usr/include/qt4/QtGui -I/targets/FREMANTLE_X86/usr/include/qt4 -I. -I. -o HelloWorld.o HelloWorld.cpp
g++ -Wl,-O1 -o HelloWorld HelloWorld.o    -L/usr/lib -Wl,-rpath-link=/usr/lib -lQtGui -lQtCore -lpthread

Now run the emulator GUI from your desktop and run the program from Scratchbox:

[sbox-FREMANTLE_X86: ~/HelloWorld] > run-standalone.sh ./HelloWorld

It works! As you can see, QT has done quite some magic for us: the application already looks like a native Maemo 5 application and has a close button!

Next

In the next article, we are going to create a Debian package for the ARMEL target and deploy the application on the phone. Then we will have completed the development chain overview.

Currently, the applications are mainly written using the GTK+ toolkit but the phone also provides QT 4.5/4.6 support. As QT will be the default toolkit for Maemo 6 (and for a lot of other cool reasons), it makes sense to develop new applications directly in QT.

I had some C++ and QT courses at school some years ago, I thought that it would be fun to pick it up again and try to develop a little application for the N900. This is the first article of a series explaining how to set-up an entire QT development environment for the N900 on Fedora, program a little “Hello World” application in QT, generate packages for this application and finally run it on the real phone.

Installing the Nokia N900 SDK

Note: Some months ago, Gerard Braad already wrote an article about installing the beta SDK on Fedora, but things have changed since then and not everything explained on his page still works (Gerard, if you are reading this, the comments on your site are also broken), this is more or less an updated and extended version of his article with my own experiences.

For convenience, we assume that the SDK will be installed on a 32-Bit Fedora 12 system with SELinux disabled (it installs files all over the place). It is possible to run the SDK on 64-Bit systems with some tweaking but it’s absolutely unsupported.

So, let’s start by installing the N900 SDK provided by Nokia…It’s available directly from their website and corresponds to the current 1.1 firmware (version 2.2009.51-1). Nokia provides a nice GUI installer for the SDK in form of a Python script. Unfortunately it is targeted at Debian/Ubuntu systems and won’t directly install on Fedora.

We need to change 2 lines in the maemo-sdk-install-wizard_5.0.py script for it to install on Fedora:

Line 2449: cmd += sb_installer_fn + opt + “-s ” + SB_PATH
Line 2504: cmd += “%s -d -m %s -s %s” % (sdk_installer_fn, self.__sdk_inst_m_opt_arg, SB_PATH)

Alternatively, you can directly download a modified script from here if you trust me . We also need to install some packages with yum so satisfy dependences in the installer and later for development:

$ su -
# yum install kernel-(PAE if you have it)-devel gcc-c++ PyQt4 Xephyr
# chmod +x maemo-sdk-install-wizard_5.0.py
# ./maemo-sdk-install-wizard_5.0.py

The installer should start. Select a custom installation, then it’s a matter of clicking “next” a couple of times and wait for it to download and install all the required files…

When the installation ends, you will have a complete N900 emulator and compilation environment installed in /scratchbox and two icons on your desktop to launch the N900 emulator and access the online SDK documenttion. If you try to run the emulator now, it will fail…we have to do some further changes.

Edit /usr/local/bin/start_xephyr.sh and remove the “-kb” option from the Xephyr startup script, then run “/scratchbox/sbin/sbox_ctl start” as root or put this line in your /etc/rc.local file to have scratchbox startup automatically at boot time.

Now you should be able to run the N900 emulator by clicking the “Maemo 5 SDK” icon on your desktop…

At this point, you are pretty much up and running with a basic N900 emulator! In the next article, we are going to install QT 4.6 in the emulator, add some repositories and launch our first QT program!

Contrary to these other virtualization tools, there is nothing in VirtualBox’ GUI to do this. Fortunately, you can use 2 tools to achieve the same goal…

First, you need to download SDelete from Microsoft and run it in the VM:

sdelete -c

Now stop the VM and compact the disk:

VBoxManage modifyhd blah.vdi --compact

That’s it, your disk is now compacted and you have probably gained a couple of GB!

Today I received an e-mail telling me that my N900 would probably be delivered mid-February. That would be almost 3 months since I paid and of course you don’t get any money back on the price drop that occurs during this period…how screwed is that? It wasn’t even a pre-order, the N900 was “available”. Nokia, if you can’t deliver a product to your customers, fucking don’t sell it if you have no stock! I’m so fed up of these lousy business practices.

Nokia are not the only to blame, nVidia and ATI behave exactly the same when they launch new lines of graphic cards. Whose fault is it? The marketing guys? I honestly don’t see how generating hype on a product and not delivering it for months will help you. All you gain are angry customers who lost money on pre-orders and all the buzz effect is gone once the product really hits the streets. Great job!

On the other hand you have Apple, they have a sense on how to deliver products to the market. When a product is announced, it’s available. Guess what? They are doing fine.