Unfortunately the manufacturer is right here. Currently in the ARM world every printed circuit board (PCB) model requires its own kernel version - even if the SoC is the same. Even if the components in the board are exactly the same, a new kernel version is required if the components are just wired differently!

Why is this? Because in the ARM world there is no any universal bus like PCI is in the x86 world. Typically components are connected by using quite primitive buses like I2C or SPI, which has no bulletproof way to do a listing of connected components. Also ARM is heavily power optimized - also in the PCB-level. There are software controlled regulators powering different components ON when needed and OFF to save power. Because there is no any standard way to do this - every manufacturer is designing the powering differently. Power and the communication bus are not connected by any means - powering the component on/off might require using a totally different bus - not told to software by the communications bus. This knowledge is typically just put (hacked) into the kernel code.

In PC world most of the hardware is initialized by BIOS and all the peripherals are usually nicely listed by the PCI bus (try lspci -command in your x86 linux box). Drivers can be easily attached into peripherals by unique device IDs. The same driver works for all boards even if the PCI bus address is different.

No such luxury in the ARM world. Typically you can see multiple versions of drivers for the exacly same component in the Linux kernel source tree. Just because the ARM architecture has brought too many obstacles for developers to easily use the same driver for different boards. You can imagine - it is a total mess. Also typically those drivers do not enter into mainline kernel so there is again more work for phone makers to port drivers for the new kernel version. Also Android kernel has some differences to normal Linux kernel.

Correct me if I'am wrong, but in my understanding the Android HAL-interface is in the user space - not kernel space. The HAL-interface might change a lot between Android versions. But not only the interface has changed - also the kernel space interfaces - those on the top manufacturer have to implement the HAL-interfaces - have changed breaking the existing drivers the manufacturer has made.

But there is hope in the future. Developers of linaro.org have work in progress and already very good demonstrations of how this mess can be sorted out. But we are not there yet and the work is huge. It needs also some common standards and practices to be adopted by the ARM hardware makers.

See also: The Ugly State of ARM Support On Linux http://linux.slashdot.org/story/11/06/20/2039229/the-ugly-state-of-arm-support-on-linux

But this ARM-problem is not just related to Linux. Windows Phone 7 is currently working only on Qualcomm SoC, probably because Microsoft wants to keep things simple at this point. Apple has solved the problem by making its own hardware and SoC and probably standardized the hardware in house.

If you want an easy solution, Ubuntu certified hardware might be a good choice:

http://www.ubuntu.com/certification/

Thinkpads and Dells seem to be well supported.

We need a backup in the case H.264 patent owners start collecting some money when H.264 is spread everywhere. If I understood right, the current permission to use H.264 freely in free web content is just temporary and ending December 31 2010! Developing and optimizing these codecs take time, so better start working now. In fact we should hurry!

Also the situation is very similar to using OpenOffice-threat to blackmail discounts for Microsoft Office. So even if you happen to like H.264 more than Theora, this development is a win for you (unless you happen to be H.264 patent owner).

One phone is a good start. If you carefully read the introduction, it says that C64x DSP is quite common. The optimization just have to be taken into use. N900 just happens to be the most open phone right now so it is a natural first target.

Also well working and hardware optimized codec brings some pressure to hardware optimize also H.264 for common platforms.

iPhone nano coming out in June.

Have they considered all possibilities using the arm to help the situation in addition the showeling?

* Put the arm down to the ground and use it to move the rover at the same time when spinning the wheels
* has the arm enough power to lift or tilt the rover?
* use the arm to change the center of mass before spinning wheels
* use the arm to put rocks under the wheels

In Finland it is already quite common to track dogs by using GPS when hunting. There are at least two companies in Finland manufacturing these equipment: tracker.fi and pointer.fi. The package the dog is carrying has a cell phone HW in addition to GPS HW. Packet data (GPRS) is used to deliver the dog position to the owners smartphone. You can actually call your dog and listen how he is barking... :)

I was hoping to get a printer with similar requirements. I end up to buy Samsung CLP-350N, a color postscript laser having ethernet and USB and good Linux support both by free and Samsung provided drivers.

I was happy and I recommended it also to others, UNTIL the first black cartridge was finished. The first one does not contain any DRM chip so I did not know the printer has DRM at all. The printer keeps an internal counter how many pages are printed with the first cartridge and refuses to print anything after a certain limit unless the new cartridge contains a DRM chip. The chip coming with the unofficial cartridge claiming compatibility with CLP-350N did not work in via ethernet. Via USB it might have worked according to instructions given by cartridge seller but network functionality was required. So now I'am quite disappointed with this model.

I would go for HP now. Its popular so it is quite certain that toners are available after 10 years - either from the HP itself or from unofficial sources.