I have to admit I am still trying to understand that statement. In the interview you found with Dr. Ari Jaaksi [18], at around 9:55 he said that most of the work will come out if a developer wants to adapt the "Linux application" to the Maemo 5 UI. Is that what : "Debian ARM packages can be used if they are modified with the maemo-optify tool for example" means ? I am far from being an expert with Linux so I was just wondering.

Linux is the kernel but typically also happen to refer to all the tools that compose a full system. The GUI API in Maemo is a bit different and adapted to a tablet screen. Thus, normal Xorg application might look ugly and not conform to certain rules used in the Maemo window manager which may cause them to be not very practical to use.

I believe he was referring to reprogramming graphical elements to fit in with the platform more fluidly. If you don't care about modifying the GUI the porting process is supposed to be trivial. maemo-optify just moves all the files larger than 2KB into the /opt directory and puts symlinks where they were originally. This has to be done because of the uniqueness of the file structure of maemo 5 and the limited space available in /. The complexity of application compatibility is quite large in embedded linux and I just feel it's misleading to claim that it is Linux and will run Linux applications when there are a lot of qualifiers. Perhaps someone with embedded coding experience can offer some insight into what is and is not possible in porting applications especially in regards to the GUI.

Originally Posted by Mandor

@ mikkov

Thanks. Although I am quite surprise to see that as it seems not to be working for the moment.

http://www.youtube.com/watch?v=LRy5_Ov-6AI

At around 8:30 the guy ask the Nokia representative about that feature and tilt the phone but nothing happen ... ?

The built-in Bluetooth v2.1 supports supports wireless earpieces and headphones through the HSP profile. The Nokia N900 support hardware capable of stereo audio output with the A2DP profile. Built-in car hands-free kits are also support with the HFP profile. File transfer is supported (FTP) along with the OPP profile for data synchronisation. It is possible to remote control various supported electronic appliances with the AVRCP profile. The DUN profile which permit access to the Internet from a laptop by dialing up on a mobile phone wirelessly, the HID profile which provides support for devices such as Bluetooth mice and keyboards and PAN profile for networking using Bluetooth are unsupported but can be enabled.

OPP profile for data synchronisation

It is possible to remote control various supported electronic appliances with the AVRCP profile.

Originally Posted by lma

OPP is just for simple sending/receiving of objects, synchronisation would require the SYNCH profile.

I think it's the other way around, the N900 is the device being controlled (by eg a bluetooth headset).

his profile is designed to provide a standard interface to control TVs, Hi-fi equipment, etc. to allow a single remote control (or other device) to control all of the A/V equipment to which a user has access. It may be used in concert with A2DP or VDP.

It has the possibility for vendor-dependent extensions.

AVRCP has several versions with significantly increasing functionality:

* 1.0—Basic remote control commands (play/pause/stop, etc)
* 1.3—all of 1.0 plus metadata and media-player state support
o The status of the music source (playing, stopped, etc)
o Metadata information on the track itself (artist, track name, etc).
* 1.4—all of 1.0, 1.3, plus media browsing capabilities for multiple media players
o Browsing and manipulation of multiple players
o Browsing of media metadata per media player, including a "Now Playing" list
o Basic search capabilities