Gnome suitability for embedded devices

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

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

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

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.