Open source talk

Wayland

2011-03-21T11:24:00.002+02:00

Recently Wayland have become a hot topic. Canonical has announced that Ubuntu will go to Wayland. Also MeeGo has great interest on it.

Qt has had (experimental) Wayland client support for some time now.

A very new thing is support for Qt as Wayland server. With that one can easily make own Qt based Wayland compositor. This is huge. Since this the only working Wayland compositor has been under wayland-demos. Using Qt for this opens many opportunities.

My vision is that Wayland is the future. And the future might be there sooner than you think...

MeeGo status

2011-02-24T13:06:00.003+02:00

Our CEO started a blog: http://cannedbypasi.blogspot.com/

He wrote first entry about MeeGo and Qt status.

Shortly: MeeGo is alive and kicking.

Encrypted rootfs on MeeGo 1.1 netbook

2010-11-26T23:21:00.004+02:00

I promised my scripts to encrypt the rootfs on my Lenovo Ideapad running MeeGo 1.1. It's currently just a dirty hack but thought it could be nice to share it with you.

My scripts uses cryptoloop. Unfortunately MeeGo 1.1 netbook stock kernel didn't support md_crypt so that was a no go. Of course I could compile the module myself but I wanted out-of-the box solution.

Basic idea is to create custom initrd and use it. My solution needs Live USB stick to boot and do the magic. Also another USB drive is needed to get the current root filesystem in safe while encrypting the partition. I don't know if it's possible to encrypt "in place" meaning to use two loopback devices. However this is the safe solution.

For the busy ones, just boot the MeeGo 1.1 Live USB and grab these files:

http://kaaos.huutonauru.net/meego/netbook_rootfs_crypt/crypt_hd.sh
http://kaaos.huutonauru.net/meego/netbook_rootfs_crypt/mkcryptrd.sh

Then:

chmod a+x crypt_hd.sh mkcryptrd.sh
su
./crypt_hd.sh

And follow the instructions.

The ones who have more time and want to double check everything, please follow instructions at: http://kaaos.huutonauru.net/meego/netbook_rootfs_crypt/README

This solution has at least one drawback. Once the kernel updates you have to recreate the initrd. For that purposes I created a tiny script than can be run after kernel update:

http://kaaos.huutonauru.net/meego/netbook_rootfs_crypt/update_initrd.sh

That script also needs the mkcryptrd.sh script above.

Of course that may break your system at any time, so be warned.

For my Lenovo Ideapad S10-3t and MeeGo 1.1 netbook it worked fine. My test case was to make very fresh installation first from the Live/installation USB. Boot again and setup the cryptoloop from Live USB. After that I could easily boot my crypted MeeGo 1.1. It asks password in very early phase of boot process. After it's written correctly the MeeGo 1.1 system should boot up normally.

This worked for me, and I give no guarantee that this works for you. However you're welcome to send patches and improvements.

UPDATE 29.11.2010:
Some people have reported problems when they have different kernel version than on Live USB. The're unable to boot back to their system. I try to figure out solution for this issue.

My presentation at MeeGo Conference 2010

2010-11-25T14:58:00.001+02:00

Finally they uploaded videos of MeeGo Conference 2010 presentations. Here's my presentation, enjoy:
http://conference2010.meego.com/session/meego-system-integration-hardware

Also please note the slides as PDF.

MeeGo on Lenovo Ideapad S10-3t

2010-11-24T19:36:00.005+02:00

I was one of the lucky people that received Lenovo Ideapad S10-3t in MeeGo Conference 2010 at Dublin. Of course I'm using MeeGo on that and now I have been playing with it a while.

Unfortunately I needed to reinstall the MeeGo 1.1 and I used the image available at http://meego.com/downloads/releases/1.1/meego-v1.1-netbooks

After some time and multiple reboots the WLAN and Bluetooth stopped working. Little googling revealed that there's something wrong with BIOS/settings. This helped a lot: http://forum.meego.com/showthread.php?t=2011

So just go to BIOS (F2 at boot), reset factory default and save.

Thought that this could be nice machine to take with me when traveling. So In order to use it more productive way I installed LibreOffice.

Actually I downloaded the GNU/Linux 32 bit tar.gz and found RPM:s under that. I was a bit adventurous and created a repository for them.
So did:

tar xzvf LibO_3.3.0_Linux_x86-64_install-rpm_en-US.tar.gz
sudo mkdir -p /usr/local/repos/libreoffice
sudo cp -r LibO_3.3.0beta3_20101115_Linux_x86_install-rpm_en-US/RPMS/* /usr/local/repos/libreoffice
cd /usr/local/repos/libreoffice
sudo zypper install createrepo
sudo createrepo .

After that set up zypper repository for that. Created file /etc/zypp/repos.d/libreoffice.repo:

[libreoffice]
name=libreoffice
enabled=1
autorefresh=0
baseurl=file:///usr/local/repos/libreoffice
type=rpm-md
gpgcheck=0

After that just:

sudo zypper refresh
sudo zypper install libreoffice3-* libreoffice3.3-freedesktop-menus

So this far it has been quite nice to play around with this Ideapad and MeeGo. Another idea was to have the whole rootfs encrypted to protect my data in case I lost the machine. I actually accomplished that and will post scripts and instructions soon!

Inner Qt

2010-03-24T11:38:00.002+02:00

Lately I have played a lot with Qt. Generally it's nice and I think it's easy to adapt and get things done. Also the development of Qt have been blazingly fast, new features are implemented and it's going into good direction.

I have taken a closer look to the inner design of Qt. First note was that Qt is just one big collection of code. Of course it's divided into modules like QtCore, QtGui, QtNetwork, QtOpenGL, etc. But when you look the sources you'll see one big drawback: you really can't compile one module without compiling first almost all other modules. Also compiling only few classes or widgets is not possible.

The main reason for Qt being just a big pile of code is heavy usage of private members. In generally private members and classes are good. But somebody has led this into very wrong direction. Totally separated Qt classes uses each others private members/classes directly. That achieved by making the private members protected and listing other classes as friend classes. This leads to degeneration of the code. An extreme example is that QWidget, the very basic class in Qt. Let's see it's sources: qwidget.h. Total number of friend statements in qwidget.h is about 50. However not all of them are really used, but 50? Are you kidding? Then it hits me, what the heck does implementation of QPixmap::fill in qwidget.cpp ?

Another thing that does not fit in my mind is use of QApplicationPrivate. There's lot of use of it in qwidget.cpp. And I really don't get the point why? Why are these not public functions and members in QApplication or QCoreApplication? Of course there's some aspects which supports this kind of approach, but this was just an example. Such usages of private classes and members can be found all over the Qt. For example there's clean cases where private is used even if there's public member which does the same thing.

My point was that Qt is great, but could be even better if the inner design is reviewed and proper modifications made. I mean: using public members, avoiding usage of privates and friend classes and cleaning off all the stupidity. A good test could be: if you take a source files of a widget and compile it outside Qt source tree (compile with public API), does it compile without modifications? For most widgets and classes this should be true. Currently most of the classes fails this test. Of course using privates is ok when it's really needed. But I see no reason using privates so heavily as Qt currently uses.

Drafting a browser

2008-09-22T15:55:00.002+03:00

After my latest post about Google Chrome, I was pondering how to use the process separating system on other projects or making a own browser with the same idea. Fortunately I found that there's GtkSocket and GtkPlug. With them you can easily embed other processes on a main process.

So we need a main application, which creates tabs and takes care of handling them. Quite easy job to do. When creating a new tab showing a new GtkSocket inside it. Socket id is passed to a new process, for example by launching a new process with exec and passing socket id (numeric value) as a command line agument. That's about the minimal required functionality for the main process. It just handles tabs and launches other processes.

The client application reads the numeric socket id from it's command line arguments, creates a new GtkPlug with gtk_plug_new (socket id as a parameter). Now it can just draw any Gtk+ widgets on that GtkPlug widget and show them. So now we can draw, let's say, a URL bar and for example WebKit/Gtk on that GtkPlug widget. And let's define some signals that when typing URL on the URL bar the URL will be opened on the WebKit/GTK. Now the client app is ready.

And what do we have now? A main app, which opens tabs, launches a client app and passes GtkSocket id for it. Client shows URL bar and WebKit. The contents of client app is shown inside the main app's tab view. Isn't that now a simple web browser, where every tab is running it's own, separate process? Somebody could now catch the idea and continue working on this kind of approach. And that's not just browsers. The GtkSocket is normat Gtk+ widget, which can be used like any other widget. One could make very interesting apps where one main app embeds other processes inside it and showing their content. Now anybody got some ideas? At least I do...

Google Chrome

2008-09-03T13:40:00.002+03:00

Recently Google announced their web browser project called Chrome. They also released beta version for Windows. It seems to be a interesting project. Especially when they say that it's released as open source.

The main renderer of Chrome is based on Webkit. Webkit is quite good browser engine used for example by Apple Safari, Nokia S60 web browser and Google Android. On top of that Google has made it's own JavaScript engine, which seems to be faster than any other JavaScript engine on the market.

One good idea on Chrome is that every tab is it's own process. Also JavaScript runs on it's own thread making the web experience more better. Since traditional browser runs all tasks in queue it means that when one task is taking a long time, others must wait for it.

My first impressions about Google Chrome is that it includes great innovations and ideas, but I have also my doubts. There been also criticism about the EULA. What I'm waiting is that other browsers adapts ideas from Google Chrome and so everybody would benefit even if they don't want to use the Google's browser. I'm sure that Mozilla Firefox project will react soon. Better browsing times are about to come...

Ubuntu on Asus EeePC

2008-08-22T09:58:00.003+03:00

I installed Ubuntu Eee on my Asus EeePC 900 some time ago and have been using it since then. I really like it. Screen resolution is ok, all my favourite apps are working and I can perform all the task I usually do.

The install process itself was painless, I made a bootable live USB stick from the Ubuntu Eee image, booted from it and installed it. After reboot Ubuntu started, and for example WLAN was working out of the box. First thing I noticed was that the touchpad was unconfigurable. I was unable to run gsynaptics. So I installed array.org kernel and enabled the elantech synaptics driver. Also xorg.conf needed some tweak in order to make gsynaptics to run. Shutdown had also a problem but unloading snd-hda-intel module on halt fix this problem.

Another thing was the sound volume buttons but fortunately there was good instructions on Eee User wiki. Another annoying problem was evolution launching every time when power cord was plugged in. Resolution was to remove /etc/acpi/events/asus-mail. After that there was one more problem: webcam. Resolution was to use ucview and to make some module tweaking.

Now I'm quite satisfied with my configuration. This is way more better than the default distibution. The performance is quite good, and there's enough memory for my use. I didn't even set up a swap partition, however it could be useful in for more powerful use. For light net surfing and desktop use I'll be just fine without swap. I doubt if I'll try another system since I'm too happy now for the Ubuntu.

Asus Eee PC

2008-07-25T14:10:00.004+03:00

Recently I visited London. The trip was nice and I enjoyed the atmosphere, nice people and the feel of a big city. However I was lucky enough to get one Asus Eee PC 900 with 8.9" display, 900 MHz CPU, 1 GB memory and 20 GB SSD hard drive. It didn't cost too much, and got even extra warranty. It's UK version so no finnish key layout, and the power plug is also UK so got to purchase also a converter to make it work on european standard outlet.

Now I'm using the default Xandros distribution, got terminal (ctrl+alt+t) and I'm able to use apt-get. Nice system but I think I want more. Next thing is to try Eeebuntu and see if I like it better.

But I'll report more when I know better. Have a great summer...

Some tricks with N810

2008-07-07T21:04:00.002+03:00

Recently I got Nokia N810. Of course I installed Handhelds Mojo "grumpy" on it. The installation process was not painless. Some struggling around and it booted to the login prompt. I was wise enought to set up a normal user and a password for it so I was able to login (N810 includes a keyboard, nice).

But that was just not enough. I wanted X. Easiest way seemed to be to compile Xomap package for the grumpy system. For my surprise it was quite easy job, some tweaking of course, but I got X running quite easily.

I got even touchscreen working, but HW keys just didn't want to work. There is quite a same situation, but unfortunately didn't find solution for that. Also mailed a question to the author of the post but got no reply from him.

However I'm quite glad to get this all working (grumpy + Xomap) on N810. It just proves that the Handhelds Mojo project is a piece of great work

Mojo on N800

2008-05-07T19:11:00.003+03:00

Recently a port of Ubuntu for ARM processors was released. The project is named Mojo, and currently they've released distributions called Frisky (Feisty based) and Grumpy (Gutsy based). The first thought I had was to make it work on a real hardware. This time I chose my Nokia N800 tablet.

At the beginning I made a simple system with debootstrap. I was using a qemu based ARM system to install debootstrap to create the system for a specific directory. For simplicity I put resulted contents from the directory to a MMC card. I just made one EXT3 partition and copied (or really I used tar) everything there. I put the MMC card inside my N800 and used flasher to select boot from MMC. Booted and nothing seems to happen. Weird.

First I thought there's some problem with my system. After a thought find out that my system might boot but it won't show anything on the screen. The solution was to follow instructions how to disable boot splash screen and enable console on framebuffer. Now I was able to boot the device, startup messages from kernel begun to run, and finally the system from the MMC booted and show it's login prompt. Fortunately there was no keyboard available so I was just pressing the enter key to see that system really reacts for something.

Next I'd like to try to make real system working on the device. Meaning X and some apps running. Also want to try this process on my FIC Neo1973. But the greatest thing is that now I can use Ubuntu as my system on the ARM. Previously I was using Debian, but Ubuntu brings some benefit. I will certainly continue to play with these repositories and probably get something nice working...

Uptime weirdness

2008-03-09T17:16:00.004+02:00

Got unusual situation today. I was checking my server uptime because it was going to break 500 days and wanted to celebrate it. One day it was just fine saying:

10:05:53 up 487 days, 23:55, 5 users, load average: 0.08, 0.02, 0.01

I just remembered that the box should have been breaked the record and checked the uptime again and it was saying:

17:02:24 up 10 days, 4:24, 5 users, load average: 0.16, 0.03, 0.01

So what happened? The box have not certainly been rebooted or anything. I've been happily running processes on it daily.

I'm still running old 2.4 kernel series on a faithful Debian sarge installation. A closer investigation showed that those old kernels have a bug which resets uptime after 497 days. It has been luckily fixed on 2.6 series kernels but it won't help me.

P.S. Luckily a couple days ago I got a new computer for development and test purposes. It's not the newest and shiniest one, nor cutting edge, but certainly faster and better than any of my laptops or other computers. It got a fairly ok graphics card (nVidia, and it's proprietary drivers sucks but it's still ok). Mainly I needed support for OpenGL shaders and framebuffer object extension and the nVidia card supports both of them. For now the box is running Ubuntu 7.10 because it's just the best choise at the moment, but will certainly test other distros when I get some time and I don't need it any more as a stable development environment. But I'm again excited to get a new toy, I have been using only laptops for quite a while and a desktop machine is really refreshing extra!

Rooting my NAS

2008-02-29T22:19:00.004+02:00

I purchased a Buffalo Linkstation Live NAS. It was at first a nice toy. Then I figured it was running Linux. The adventure begins.

Little search at Google showed that it's possible to gain telnet and root access to the box. I was totally excited to get the root shell prompt on my terminal. This seems to be too good to be true, but suprisingly it was. I was able to get uname and statistics via procfs. Setuped the SSH and was able to login to the box.

Next I installed ipkg system on it using these instructions. I was able to install packages! Installed screen and irssi and in several minutes I was using IRC on the box.

There's a lot of packages available to the device and just can't even imagine what to do next. I have a NAS box, which can be extended to a real server with any applications I want to run. It has a quite a big amount of disc space (500 GB), and it didn't even cost a much. I'm impressed. For people looking a quiet, small and handy server, I can recommend purchasing one of these. I will continue playing with this and will report if there will be some more findings.

FOSDEM 2008

2008-02-27T19:42:00.007+02:00

So the FOSDEM 2008 is now over. Writing down some experiences about it. First of all, there seemed to be a lot of people in there. Their broschyr said there will be 4000+ geeks at the place. But nobody was counting, so the number is just an estimation. However the place was crowded, some lectures was too full, people was just standing like sardines in can. There was space in some places too, but the most popular events was just nightmare.

Janson lecture room

Picked some interesting lectures, such as Clutter, integrating the Web into GTK+ with WebKit, Mozilla Mobile, tangoGPS lighting talk, among other full lectures and lightning talks (15 minutes time limit) which I was watching.

Also spent some time watching the stands. There was many Asus Eee PC's and OLPC (One Laptop Per Child) computers, as well as different embedded devices running free software, for example OpenEmbedded stand was interesting.

Eee PC

OLPC

It was not only strict business but also fun time, spending nice time at Friday Beer Event at Delirium cafe and GNOME Beer Party on Saturday. Had a change to talk to people in a relaxed environment. Somebody said that the real conference starts when people gets some beer.

But after all met some good people and changed thoughts, talked about different open source related stuff. And I was able to show my demo with FIC Neo1973. The demo itself was not impressive, it was just a Debian etch booting with working X, touch screen and Matchbox window manager. But what makes it great, is the time spent on that: only a single day. I'd probably talk more closely about it and about the progress in this blog.

But I was nice to be there! Thanks to the organizers, all speakers and people I met.

Going to Fosdem 2008

2008-02-06T17:40:00.000+02:00

As said I will be at FOSDEM 2008 in Brussels, Belgium. I'm going there with a co-worker, and our employer, Nomovok, is kindly paying the trip.

I'm quite excited to see other people working on open source projects and talk to them about all kind of open source related things. If you're going to FOSDEM as well and are intrested to talk with me, please contact me beforehand with a email (you're able to see the email in my profile) and let see if we can arrange a meeting.

I probably have my FIC Neo1973 with me so that I can show it for curious people. Also my Nokia N800 will be there. I can also tell about some personal intrests of mine in area of open source. So don't hesitate to contact me. See you at the FOSDEM.

Running ARM Debian in qemu

2008-01-24T20:03:00.000+02:00

I wanted a whole running ARM Linux system, but considered my real ARM devices (for example FIC Neo 1973) too slow and limited for the most tasks I wanted to perform. So had an idea of fully emulated ARM system, running on qemu. Best option for the installable system seemed to be Debian since it had a prebuilt packages and quite easy install system. And of course, I like Debian.

Fortunately I found a good guide for my adventure: http://www.aurel32.net/info/debian_arm_qemu.php. First started by getting the latest qemu, and built it for my system. Fine, then installed it and everything seemed good. So continued with the next step: installing Debian to the qemu system. Installer started fine. The installation went fine. Then the first boot and the first problem. For some reason the boot process hanged every time when the system was checking the disc image. The check was forced in first place because the clock of the qemu system was reseted to zero on every boot (back to 1970's) and the system thought that we have been too long without performing the check. Just spent a day trying to solve the issue and googled for solution. The main problem seemed to be qemu but even the newest CVS version didn't help. Finally made a dirty but a working solution: changed disc image parameters with tune2fs so that the image won't be checked any more. Success.

Finally logged to the Debian system and was able to operate as in any other system. I was able to install new packages, build packages and perform other operations. Then I downloaded a third party ARM Linux application which just didn't work. I was unable to execute it. Then figured out something. The kernel which was provided by the tutorial didn't support EABI. I wanted EABI. So I thought that building a own kernel would be nice and easy. Thought wrong.

First I needed cross compiling toolchain for ARM EABI, it was fortunately found from http://www.codesourcery.com/gnu_toolchains/arm/download.html. Then I downloaded newest kernel, set up cross compiling and chosen the default versatile kernel configure. And changed it to support EABI. Then built it. Success. Try to boot - and fail. The default versatile configure was not the right one. Since the tutorial didn't bother to provide kernel configuration to build the kernel, I was forced to figure it out myself. Gone through hundreds of different configuration and finally found one which worked almost. It just didn't found my hard disk or the disk image where my Debian installation was. I thought I had everything: PCI (took also some time to figure out that I need support for it) and SCSI disc support, but something just was missing. Hit my head against the wall until figured it out: SCSI low level driver. I had to check it from qemu home page, selected it from the configure and built. Finally a success!

Now everything was working again on my qemu ARM system. The lesson learned: you should always know the platform for which you're building the kernel for. To know all the devices, chips and drivers possibly needed. And the kernel configuration seems to hide some options, making unable to select or even see them, if they depend on other configuration option. Next time I will double check all the device drivers that I really need and study the platform better. No guesses any more. Only cold facts.

Some recent FIC Neo 1973 experiences

2007-11-19T10:53:00.000+02:00

I have been playing with my Neo 1973 phone for some time. I tested Qtopia and it looked nice and got phone calls working for the first time. However it's not designed mainly for Neo 1973 and the experience was not too nice. It lacks something.

Recently there was a new OpenMoko image released, and of course I had to flash it to my device. The look was upgraded and the phone calls was finally working! Had some bugs, but it was working. I was able to make and receive calls.

Also tried to compile my own test application, and had some success. I was able to get "Hello world" on the console. Waiting to get something more working, for example a GTK+ app would be nice to get running. But until that I keep on playing with this thing and will report as soon I get some results...

Got my FIC Neo1973

2007-10-15T12:37:00.000+03:00

Today I finally got my FIC Neo1973, a OpenMoko based mobile phone. Man from the packet service called and woke me up telling that he'll bring the packet in five minutes. I was ready in a minute and counting seconds until the doorbell rang.

It was like a Christmas when I opened the package revealing it's contents:

The phone on the left, stylus package, battery, wires and all other stuff on the right side of the package.

Finally I took the phone on my hand:

Great. It's a little bit bigger than I thought. But it fits to my hand and isn't too heavy. There's a handy pouch included in which you can carry the stylus and Neo1973 with you without a fear to scratch the screen. Memory card slot is under SIM slot and both of them are under the battery so changing a memory card is not a easy task. Here's picture about the interiors:

The phone was shipped without rootfs installed, only uboot and kernel. As a first thing I flashed new kernel and newest devlopment rootfs. Got the device booting:

And here's finally the UI up and running:

First impressions is that the boot process takes quite a long time. It's not like forever, but have to be patient. The software is not quite ready yet and they have a lot to do, some apps simply does not work or works only partially. I faced also problems with GSM calls, the GSM just doesn't seem to work. Find out that this bug might cause the problems since doing things on the command line as they told in the comments made it power up the GSM and to make it able to call (with AT commands).

However I keep on testing the device and will definately report more impressions about the device and the software.

About Clutter

2007-09-28T10:15:00.000+03:00

I've been playing around with Clutter lately and find it intresting project. So shortly it's a library to create fast, visually rich and animated graphical user interfaces. It uses OpenGL or OpenGL ES for rendering, but hides their complex API.

It uses GObject as base of it's classes and people who has been coding with GTK or glib are very home with Clutter. Additional libraries provides features like GStreamer playback support, Cairo rendering and embedding into GTK.

Building an simple application seems to be easy following the documentation. There seems to be lot of features, and basic operations works nicely. I made a test app utilizing clutter-gtk for GTK embedding, an it run smoothly on my desktop. However when I tried same application using OpenGL ES backend I faced problems. Clutter was missing XEMBED support for ES backed. I found this support in normal OpenGL version and find out making support for ES was quite easy job. I made a patch and posted it into Clutter's Bugzilla. Now I got a response and they seems to be excited about this patch.

It seems that Clutter is a nice project and the project team members are doign a good work. The library could be used more widely to make some nice, smooth UI's. However I'm not a graphic so didn't manage to create too smooth UI, but maybe somebody else success more better than me.

A word about Ubuntu Mobile and Embedded

2007-09-03T18:59:00.000+03:00

The most popular Linux distribution (according DistroWatch.com) on desktop, Ubuntu, is aiming on the embedded market. They aim their embedded distribution mainly on devices which are called "Internet tablets" or "mobile Internet devices".

Currently the target is on Intel platform called MID (Mobile Internet Device) and available devices such as Samsung Q1 Ultra, HTC Shift and Elektrobit EB MIMD. The distro will aim on Intel based system leaving for example ARM based devices like Nokia N800 out of the scope.

About the project itself. It tries to use existing software as it's base, but is not afraid to implement it's own applications when suitable one not available. It's intresting that the project took Hildon as it's UI framework. Hildon is originally developed by Nokia for it's maemo platform. However, Hildon is open source and such thing is possible to do and kind of open source spirit, and in the line with the policy to use existing components if availble.

They're targeting to release first version with Ubuntu 7.10, meaning very soon from now. As I see these Intel based devices are yet to come to the markets and we'll not see this in use in this year but in a year or two those devices with Ubuntu's embedded version might be a everyday. Only the time will show...

Poky Linux

2007-08-11T10:15:00.000+03:00

Recently Opened Hand announced Poky Linux for embedded devices. Currently the system runs on various Sharp Zaurus devices and there is also experimental support for Nokia N800 and OpenMoko Neo1973 devices. I tried the Poky system on qemu and also installed it on my Nokia N800.

The system contains UI component called Sato, which is corresponding component to the Hildon widget set. The system is fully open, and contains currently basic applications such as web browser and video player, a PIM suite called pimlico and some games.

Here's a capture of Poky Linux running in qemu:

And the system running on Nokia N800:

Seems that network is not supported yet on N800 so I was not able to test the browser any better. But currently the Poky Linux seems a promising option.

Lost in Berlin

2007-08-06T19:21:00.001+03:00

On last week I was visiting Berlin. I took my Nokia N800 and a GPS receiver with me. I have installed Maemo Mapper on the device and loaded Berlin maps beforehand on it. Navigating was working nice, but I still had to buy a paper map. There's something that a digital map can't replace.

Another reason for taking the N800 with me was the WLAN connection. I succesfully connected to the hotel's WLAN. Also it was handy on the airport where I had to spend several hours. However the WLAN spots were not free so it cost some money but I can manage a few euro's cost.

I also finally ordered the Neo1973 (OpenMoko) device. I'll be waiting for it, and I will surely report first impressions on this blog. But until that I'm testing the development tools and tell more about them later...

OpenMoko finally here

2007-07-12T11:21:00.000+03:00

So they really got first developer versions of OpenMoko device Neo1973 for sale. I'm about to purchase one of these very soon.

After reading specs and documentation I found this device even more better. The developer version of Neo1973 will include:

Neo1973 (GTA01B_v4)
Battery
Stylus
Headset
AC Charger
Phone Pouch
Lanyard
SanDisk 512MB MicroSD Card
Mini USB Connectivity Cable

There's also available advanced package but I'm not currently intrested about it. But the final (sales) version of Neo1973 sounds even more better, it'll will have WiFi, Graphics accelerator and 2 accelometers. I think I must buy it as well when it will be available.

While waiting for the device I've been playing with OpenMoko system in QEMU. It seems quite slowish but can't yet say anything about the speed on the device. Here's a little video capture (sorry about the wrong aspect ratio):

So now waiting for getting the device on my hands to be able to tell more about it...

P.S. Nokia N800 got updated software and is running now Skype. Works fine but unfortunately it's closed software. However nice move...

GPL version 3

2007-07-07T19:32:00.001+03:00

Recently Free Software Foundation released the final GNU General Public License version 3. What that does really mean?

First of all many software says it uses version 2 or NEWER. The key word is the later one because user may choose which version to use. Is there going to be two branches of one software, one for version 2 and one for the 3rd one? Ok, that might be a problem. However there's still some software which insist to use version 2 only. On of these are the Linux kernel. It will be version 2 unless something else is decided...

Also version 3 defines that some vendors can't any more lock their devices to use only the official binary provided by them. Vendors must now allow customized code to be flashed or uploaded to the device and not to lock it on any way. Sounds fair.

Secondly software patents are not allowed. This prevents deals which Microsoft has made lately with some Linux providers. It will be interesting to see the real affect. For now on we must only speculate.

Generally the GPL version 3 is good thing, but people should take a little bit careful with it at first. The future will tell what comes.

P.S. First developer versions of OpenMoko based phone Neo1973 will be available since 9th of July. I'll be waiting for it...

Long time indeed

2007-05-17T10:50:00.000+03:00

First I must apologize for not writing for a long time, but have been busy and doing everything more important. And it's been silent lately.

Fortunately now the phase 1 of OpenMoko based phone Neo1973 is near. It's means that some devices will be available for developers to order. I try to be one of those lycky ones, but let's see first how many of these devices they're able to get for sale. Hopefully enough.

Meanwhile I got Nokia N800 (for the discounted price, thanks goes for Nokia) and had some time to play with it. It's quite impressive and a real improvement from 770. Now there's enough memory and CPU seems fast enough. It makes a really good tool with GPS receiver and Maemo mapper. Used it a few times to navigate while being at a car. And the media player is also a good piece of software, for example I tried playing music over UPnP from a friend's Windows XP Media center edition and it did a nice job. But again I have had a very little time to play with it more and implementing my own stuff for it.

Hopefully I have more time in future to update this blog but until then it's a bye.

The new mobile devices

2007-01-13T13:39:00.000+02:00

Recently Apple announced the brand new iPhone. It sounds good: music device, phone and internet in same package. But wait a minute, isn't it just another phone? It has only a nice user interface and there's a new way to control the phone. And one thing I miss: iPhone is just an ordinary GSM phone. I'd like to browse the internet with high speed 3G connection, but no. And why to integrate big music player on it? I have already iPod, and my current phone has 1 GB memory card, audio player and internet access, and it supports 3G. Listening music with phone is not anything new. So the iPhone is just about a new UI design and controls? The worst part is that Apple don't want 3rd party applications for it. Yes, I can't develop any applications on it, and no way to get my favourite applications on it. It just is not open.

But lets take a look for a open phone. There's an option called OpenMoko. It's quite open, it has finger controllable touch screen, it also includes stylus for more accurate control, and the user interface looks also nice. It's based on Linux and open source software. It includes the basic operations (call, send & receive message) and allows installation of 3rd party applications. The first model, Neo1973, has quite nice touch screen (2.8"), built-in GPS and USB. However it's still GSM phone, no 3G. But sounds very nice. Unfortunately there's very little information about the platform. Is it based on Qt or GTK+ or is there some other widget set in use? Sounds like it's Debian-based, the provided presentation used apt-get. The phone is about to be on sale soon. Then we'll know better. But at least I'm excited.

Also Nokia published new internet tablet, N800, which is follower for the 770 tablet. It has improvements such like more memory, better CPU and camera. Sounds nice. It has active developer community and provides maemo platform and SDK for developing applications for the tablets. It has intenet (video) calls via VOIP (Google Talk). However it has no GSM phone at all. You still have to carry around a ordinary phone, preferably with bluetooh and fast 3G. It's kind of benefit also. You can update your phone from GSM to 3G and the internet tablet has also the speed benefit. However, the N800 is a good improvement - and it's open, at least on some level.

Playing around with a embedded box

2006-12-21T20:28:00.000+02:00

Sorry, it's time since I last updated this blog but I've been busy with work projects. However I have had some time to play around with a nice embedded device on my spare time. I needed a wireless router so I bought a Linksys WRT54GL. It's originally a WLAN router with 200 MHz mips CPU, 16 MB RAM and 4 MB flash, with Linux based firmware.

There's lot of projects to replace the firmware, such as DD-WRT, OpenWRT and HyperWRT. I choosed to flash the DD-WRT to my box. Flashing went fine. After the flash I was able to access the router by telnet and HTTP. It was easy to set up SSH running from the web interface. So I had a Linux system running with SSH access on a embedded box. The next step was to install own software on it. I set up JFFS on the box and Samba share on a bigger server which was mounted by DD-WRT.

Next step was to install some packages with ipkg. I took the prebuilt packages from OpenWRT repositories. There was some problems installing some libraries because a Samba share does not support symbolic links. Solution is to make the proper links on the server side. It required some tweak to make the applications to run, such as set LD_LIBRARY_PATH to proper location. Some applications required some extra parameters to work properly. Generally the Samba share provided virtually unlimited amount of storage for applications. The only limitation is the box itself.

I'd like to set up a compiler environment for my desktop environment to build applications for mips and to run them on my WRT box. I have some ideas to make it run different kind of applications. However first I'd like to set up a web server on it and make my primary router to forward them to the WRT box. Which one would hit first, the power or the memory limit? How about to set up a swap over the Samba share? To be seen...

Mobile calendar and synchronization

2006-11-04T12:47:00.000+02:00

At home I use OS X iCal application on my Mac to mark up important events and meetings. Then I have Nokia 9500 Communicator with me all the time and mark events to it also. I have also Nokia 770 hanging round sometimes. To make things even more wicked I carry a laptop along me on my trips. This works usually but one night it became a real nightmare.

Communicator has a table stand which connects via USB to computer. It has sync button on it. However I have never managed to get it working with OS X. With my Linux laptop it works ok, but never successed to synchronize calendar events. Fortunately my Mac has bluetooth and so has the communicator. The next problem after pairing these two devices was that iSync didn't want to work properly. After googling a while I found instructions how to set up iSync for 9500 and how to install 9500 plug-in to iSync. Surprisingly everything was working fine. I got my contacts backuped and calendar marks in sync.

Oh, now I have nice working synchronization. But wait a minute. It's completely manual, needs starting iSync and pressing some buttons on both devices. One night I took my laptop and communicator and gone working to a distant location for a couple of weeks. I remembered that I had a meeting on one of these weeks but no idea on which day and what time. Took a look to my communicator and found... nothing. I forgot to sync my devices. Ok, no problem I have SSH access to my Mac. Unfortunately Apple has decided to make some modifications to iCal version 2 and the calendars are not available as files any more in my home folder. Quick search did not result anything. Now I got a problem.

You know it's not nice at all to call people and ask "when did we actually had the meeting"? It gives a stupid image of you. The lesson learned: always sync your mobile calendars. Also got an idea. Why not sync everything automatically, on multiple places and easily accessible remotely? I would like to see a command line interface for iCal or the calendars as easily readable files. How about automatical synchronization when my phone is available via bluetooth? Yes, I can still press the "accept connection" button in my phone if it for example beeps once when it's needed. Synchronize to my laptop - it has bluetooth as well. Unfortunately it lacks a good calendar. Also 770 lacks a calendar completely and it has bluetooth as well. So could somebody make a good open source calendar which works on my laptop, 770, other possible Linux based systems and synchronizes well with 9500 and Mac via bluetooth or USB? Automatically, if possible? Anybody?

Serving your embedded

2006-09-28T15:20:00.000+03:00

Usually people think embedded devices are clients for some services such as voice calls, video streaming, short messages and internet. But how about serving with your embedded device.

For example Nokia has a mobile web server for Symbian. It's modified Apache and is available as open source. They say that main target running a web server in your mobile phone is to make your personal mobile website. So what kind of are these personal mobile websites? Some information about you? It can't be anything that spends resources, it it just showing some simple pages. Isn't there any lighter way to show some information about you? I suppose nobody wants to surf to my mobile phone which might not be alwys available. I also thing that nobody wants to make this kind of page available as primary home pages since it's too easy and cheap to set up the pages to a real server.

But wait a minute, how about a whole, fully working web server serving some pages on the Internet. I found a Nokia 770 and Apache intresting combination. 770 has WLAN so it can be set up with wireless access point and get it visible to the Internet. Apache serving some personal web pages, portal or anything you like. How about setting up a server cluster? Multiple embedded devices serving on same address. Easy and cheap redunancy. Let's take a normal 770, it costs about 370 euros. Cheaper than a computer or a real web server.

How reasonable this is? Embedded devices are not any realiable, so anything can go wrong at any time. They does not automatically recover from error situations. You simply should not trust them. But at least serving web pages with your embedded device is really geeky and increases your masculine power. For power users only.

Embedded language

2006-09-11T21:45:00.000+03:00

What's your embedded language? Which suits best for embedded use. Let's spend a few minutes thinking about it.

What are the options we have? Shortly there are four good candidates. First we have old and traditional C. There are lots of C applications available, it's well known, well supported, effective, Linux kernel is written with it, most system libraries are written with it, everything is good except one thing: it's not a modern laguage. It's missing object oriented features, it has memory leak problems among other problems. However they are all known but badly handled.

Let's make a step better language C++. It has object oriented features, but it's not a object oriented programming language. It's compatible with C, which has lots of benefits but inherits all misadvantages of C. It still leaks memory, no carbage collector, no proper class library, except STL which is a good try and for example Symbian does not have STL at all. And one little thing in Linux: every release of C++ libraries brakes binary compatibly. It's a really problem. Binary ABI for GNU libraries is very unstable. They may change it from a version to another. Have you ever tried to transfer an C++ application binary from machine to another and run it? Also compiling C++ applications takes a lot of more time than similair C application, more complex object oriented applications take even more time. You might say that nowadays computers are fast. They are, but wait until you compile your first big and complicated C++ application. It's not fast at all.

How about the newcomers, let's take Java first. Sun's "build once, run everywhere" ideology is nice! It really works. Java is really object oriented, carbage collector works nicely. Some problems however. Lets ingnore most of them, but take some in the spotlight. First Java versions. There three different versions: micro edition (J2ME) for embedded and resource limited devices, standard edition (J2SE) and enterprise edition (J2EE) for mainframe. Have you ever tried to port for example an application from J2SE to J2ME? It's impossible, or at least very difficult. Mobile phones has J2SE, however every manufacturer has their extensions to J2ME, it really breaks the "build once, run everywhere" ideology. This is however going to change in future versions of J2ME, but still waiting for the day. Should embedded Linux devices use J2SE or J2ME? For example Nokia solution on 770: surprise, no Java support at all! Second big thing is that Java is closed source. You have to have license and solve some issues to get Java for your device. Fortunately Sun has promised to release Java (only parts of J2SE in first phase) as open source. But what's the license, will the whole Java system become eventually free (as speech) and what are the terms and conditions. That will be seen.

Python. A programming language named after Monty Python can't be bad. And it's not. It has quite nice syntax, works well, is object oriented, etc. There's also Python available for example for Nokia 770 (Maemo) and Series 60. It's really suitable for anything, applications runs everywhere without recompiling, just like in Java. The biggest disadvantage: Python is interpreted language. Interpretion is slow, running is slow. Unofortunately I don't have speed measurements, but it's definetly slow on embedded devices. It suits for small applications which does not require a lot of resources or fast calculations. For slight use only as we could say.

So what's the best? I thing system should rely on C, while applications can be C or C++. And light applications can be implemented quickly and easily with Python. Java has problems, you have to choose your way and follow it blindly. It could be the killer, but it's not. Let's see what the future offers for us.

Mobile Phone Linux

2006-08-28T16:00:00.000+03:00

What would be nicer than a mobile phone with Linux system? Well there are available some phones with Linux but they're certainly not mainstream. New Mobile Linux Iniative (MLI) and Linux Mobile Standards Forum (LiPS) are going to change this. We're about to see the first mainstream Linux phone in near future.

For example MLI is focusing technically on fast booting, small memory footprint, power management, security and multimedia. Sound nice, but what are really the technical details? Does it say what components to use or does it allow manufacturer to choose the components? Does it require compability between the devices, are they building a new platform or just best practices? I tried also find out more about LiPS, but got nothing but high level non-technical talk. They mentions LiPS API and SDKs but nothing more about them. Let's assume they're allowing the basic solutions to be changeable and their API extended with POSIX and other standards provides a common platform. Sounds reasonable, doesn't it?

As I don't know any details about LiPS API we can assume it has some multimedia and phone APIs included. You could make an application which calls some function to send a SMS message and it works on another phone just by recompiling it. Nice. But wait a minute, how about the user interface? Can we standardize it or does they say you must use for example GTK+ or Qt to build your UI. Id like to see GTK+ based phones, some other prefers Qt. Unfortunately I'm sure they must choose between these two if they want easily portable applications. Or do they want it? Something makes me think they do.

From my point of view GTK+ is a better choice than Qt. There's many things that makes me think like that. First of all: licensing. GTK+ has LGPL which allows linking against closed source. Qt is GPL and requires that application which uses Qt must be also licensed under GPL (known as the viral effect). If you want closed source Qt application, you must buy a license from Trolltech. Secondly one little thing: Qt is C++ and can't be easily used on C apps without a wrapper. GTK+ is C and can be used in C++, there's also gtkmm which is interface for C++. Third: there's lot of GTK applications ready to be ported on GTK phone, see Maemo for a good example. Unfortunately I'm not the one who makes the decicions, but you might be one so choose wisely.

Building iPaq kernel

2006-08-17T20:53:00.000+03:00

I have advanced with the iPaq project and successfully compiled the kernel. For the build process I used cross compiling on my desktop system. The cross compiling itself is quite simple operation, but there's some little thing to take in acccount. We need only binutils, Kernel headers, compiler and glibc. So let's start.

Compiling binutils is easy, just "./configure --target=arm-linux", make and make install. It install required tools under /usr/local/ and creates directory arm-linux under it. Next we need kernel headers. Just make directory /usr/local/arm-linux/include and copy include/asm-arm from the Linux sources as asm to under it, include/asm-generic and include/linux as well. Then symbolic link from /usr/local/arm-linux/include to sys-linux.

Glibc I took from Debian repository, downloaded proper deb-packages, opened it (ar x package.deb), untarred the data tarball to temporary directory and copied the lib and usr/lib directories contents to /usr/local/arm-linux/lib. Another option is to compile glibc yourself from the sources but since I wanted to use Debian prebuilt binaries as much as possible and keep this as Debian based solution so this is the better way.

Then we need a cross compiler. We need gcc sources and compile it for arm using "./configure --target=arm-linux --disable-threads --enable-languages=c" and traditional make and make install. However I got problem with libc.so.6 and had to change contents of /usr/local/arm-linux/lib/libc.so (it's text file) to point to files under /usr/local/arm-linux/lib/ instead of /usr/lib/ (or wherever they point to). After that compiling was successfull out of the box. Now testing with the Hello World example (arm-linux-gcc hello.c -o hello) and see what file tool said about it. It should show that resulted binary is for ARM.

Finally the kernel. You must remember that we're cross compiling so we need to give some arguments for the make. First configuring the kernel "make menuconfig ARCH=arm CROSS_COMPILE=arm-linux-", making proper choices (SA-1110 and iPaq 36xx most important) and optimizing for embedded device. Saving the configuration, and finally "make ARCH=arm CROSS_COMPILE=arm-linux-". Never forget those parameters ARCH and CROSS_COMPILE. I did. I had to make some recovery (untar the kernel arcive again) to get back to proper architecure. I got the kernel compiled finally properly. The final result was 1.6 megabyte sized kernel plus the modules. But wait a minute, we have option to pack the kernel, so "make zImage ARCH=arm CROSS_COMPILE=arm-linux-" and (drums please) we got 760 kilobytes sized kernel. That's under a megabyte which was the target.

Next I'll try to build some system and make some minimal system image ready to be flashed to the device. It'll take some time, but what's the horry? Be seeing you.

Backups

2006-08-10T21:48:00.000+03:00

Keeping your files in safe is very important. I have lost some files because hard drive failure. How about to lost your embedded device? You also lost your files, notes and everything on the device. Backuping data should be done on daily basis. Why it's done so hard, could it be easier?

What should be backuped. Notes, music, documents, images & photos, movies, game records, preferences and everything on the device which does not come by default. However there's no point to backup installed applications but their settings should be. So is it enought to backup users home folder? It should be a safe start. Good system and applications should save their data and settings to the user's home folder, but there might be also a memory card which should probably be backuped as well.

The backup device. Usually you want to backup your embedded devices to the desktop machine. Fine, let's do so this time as well. However some clever people might have USB port on their devices and might want USB storage devices to be backup target, but let's forget it. We need a software on the desktop machine side. It should probably support different backup versions, easy restore and storing backups to external media such as CD, DVD and tapes. Files would be nice to be accessed on the desktop machine as well.

The backup progress I'd like to see is: attach the embedded device to the desktop, press a couple of buttons, backup done. What are the candidates? I think there's not really any ready to ship software for backuping Linux based embedded device. Simpliest we could have a script which copies home directory to predefined desktop machine path with date information. Restore would be copying data back to the embedded device. More sophisticated solution would be preferred, since we could have different operating systems for desktop machine and single script would not work. Client-server type would be nice, having server on desktop machine, embedded device would simply contact to the server, transfer files and ask for restore. Server would handle archiving data, choosing correct backup to be restored, store files to external media, show files and all kind of stuff. Server for multiple operating systems, standard protocol for clients to talk. And why not to backup desktop machines as well. There would be a nice project for somebody, anybody?

iPaq in action

2006-08-03T23:56:00.000+03:00

Looking through my old stuff and found my Compaq iPaq 3660. I have installed Familiar Linux to it some time ago, version is 0.7.something. The system is nice, featuring GPE and Linux kernel 2.4.19. Indeed it's better than the default Pocket PC system. But could we get better system running on it?

The device itself is featuring 206 MHz StrongARM CPU, 64 MB RAM memory, 16 MB ROM, touch screen, great connectivity by USB, serial and infrared. So the starting situation is quite challenging. What I'm planning is to set a new kernel (2.6 series), Debian based system and minimal X with Matchbox window manager, featuring GTK+. And of course some test application. Am I able to fit this all to 64 MB? And if possible some extra free space would be nice for extensions and extra applications.

First starting from the kernel. Taking latest 2.6 series stable kernel, optimizing it for handheld use, removing futile drivers, etc. I want as minimal kernel as possible. Under a megabyte would be nice, just dreaming of it? Debian and basic libraries, uClibc would be nice, let's replace traditional libc with it. Saved some preciciuous megabytes. Other required libraries. X takes some megabytes, Matchbox is slight enough, but GTK+ taking again some more memory. Still speculating, only theorical level. The next step: implementing all this.

The best way to compile for ARM target is to use Scratchbox. We have qemu emulator support or we may use the ARM device with sbrsh to compile for ARM. For most compiling operations qemu is sufficient. Scratchbox has proper debian devkits and all required tools to make everything to work. Everything is set up, next I'll start compiling things. Debian provides precompiled ARM binary packages, so I'll just get the kernel and missing packages compiled, build image and flash my device. It'll take some time. Until that, please report your devices running Linux, and what kind of Debian based solution you would like to see on it?

Gnome suitability for embedded devices

2006-07-25T14:49:00.000+03:00

First thing coming to my mind about the Gnome is resource consuming desktop environment with fancy features and loads of bloat. Fitting Gnome to a embedded Linux device - impossible? Maybe not.

The Gimp Tool Kit (GTK+) has proven it's suitability for embedded devices, also some other parts from Gnome, such as GnomeVFS, GConf, etc. But how about the whole desktop environment? First of all some storage space is needed. At least storage space from 128 MB to 256 MB is required. Then some main memory, let's say 128 MB at least. And last quite powerful CPU, high speed ARM processor could be enough for normal operation, but more powerful x86 processor would be good bet but then we got some power and battery issues. If no problems with the power, choose x86 architechture, otherwise ARM is a better (but slower) bet.

Building up the Linux system and libraries, setting up X server, window manager and finally Gnome desktop. Gnome is quite scalable, it can fit different sized screens but too small is too small. If you're luck enough you'll get Gnome up and running with proper speed and load times. If not, you need optimizations. Everything futile must be removed. And trust me there's lot of things to remove. Starting from applications in the panel, background images, fancy window decorations, etc. and continuing to different components and packages. Test how slight configuration you can get. Then add features back if they're needed.

Now we have only one question left. Why? Gnome is quite usable desktop environment and nice on a desktop computer but how about embedded devices? First of all it's an easy start. You don't have to fight to get usable GUI to the device, no need to reinventing the wheel by implementing your own desktop enviroment. Of course there's other desktops available as well, but Gnome is well known and there's lots of applications for it. You could list a lot of benefits. But there disadvantages as well - Gnome is not designed for embedded use, it uses quite much resources and it's designed to be used with a mouse and a keyboard.

I would not recommend to use Gnome as is. It's possible to use some parts of Gnome in embedded devices or you could use some other GTK+ based desktop system such as XFce. If you still want to use Gnome or want to have quickly an desktop for the device, it's possible to utilize Gnome. It requires some time, resources and care, but can provide some benefits quicker than using a customized solution.

About GPS

2006-07-17T18:06:00.000+03:00

Currently I'm on Dublin having a vacation. Thought that navigating through the city could be made easy. Having a Nokia 770 and GPS receiver at the home. The problem: they're at home, I'm in Ireland.

I have been testing GpsDrive and Maemo Mapper with 770. Both of them seems nice, however GpsDrive works better for me. Maemo Mapper has it's benefits and disadvantages. It uses Google maps which are nice, it's designed for mobile use and is lighter but it does not work as well with the GPS receiver and does not have as much features as the GpsDrive.

GpsDrive works well, but is far away from lightweigth and usable mobile application and the current version for maemo is just a dirty hack. It's loosing connection to the GPS receiver after some amount of time and the only thing that helps is to reboot the 770. I'd like to see improved version from both of them. It could be a real killer app. Some preconfured map sets would help end users to utilize them. Caching maps from the Internet - it should be easy as navigating through the map with a cross controller.

As a summary I'd like to use my 770 to locate myself and to see where to go, but didn't remember to take the device with me and secondly didn't wanted to because the software is not too usable yet. I have some ideas to improve the software but unfortunately running out of time. Would be nice from you people to help me out, please improve maemo GPS apps.

EXT4

2006-07-13T19:11:00.000+03:00

On the Linux kernel mailing list people has been discussing about forthcoming ext4 filesystem. Some proposed checksums but the idea was abandoned. Not any really good ideas are introduced except from delayed allocation, higher resolution timestamps and support for larger volumes and file sizes, so I thought how about embedded point of view? We have special requirements for example for flash memory. Performance, battery life and such crucial things for embedded devices. For example flash memory has limited amount of write operations for specific section and after that it's died. Is there any needs for filesystem to support safe write/read operations. If your flash memory section dies, you should be able to use the filesystem still. You might get errors and lost some data. Recovery of lost data? Marking bad sectors a better way? Predicting these situations? How would you improve the filesystem? The conversation is ongoing on the Linux kernel mailing list, it needs your contribution.

Thought from the other side, how about desktop and server systems? Is there any special requirements for them, what do you need. Is ext3 perfect? Probably not, so how to improve it? All ideas are welcome.

The grand opening

2006-07-13T13:04:00.000+03:00

Greeting, I'm opening a brand new blog about open source software, specially concentrating on Linux from embedded point of view.

A bit of myself. I'm twentysomething Finnish boy, computer activist, had a computer since 1989, intrested about open source, specially Linux, used it for a several years in home and work, working for a company named Nomovok which provides open source based solutions. I'm studying computer science at the university planned to graduate at some point. However computers are not my whole life, I still have a contact to the reality. But that's enough of me, lets get to the business.

About the blog. I'm following Linux kernel mailing list and will pick up some interesting things from it, also intrested about GTK+ and Gnome, discussing about other projects as well, commenting embedded Linux solutions like Nokia 770 and Maemo, gathering infomation also from Slashdot and other news sources.

Hopefully you find this blog interesting. Happy hacking.