Loud ramblings of a Software Artisan

Saturday 1 November 2008

Do Androids dream of freedom? (take 2)

From this thread (Google will require you to login):

The G1 is aimed at end users, not system developers. For user security reasons the G1 will only accept properly signed system images. I'm not sure, in this case, who 'owns' the key, whether it is the carrier or the manufacturer, but one or both of them handle insuring system images are signed.

Cheers, Justin Android Team @ Google

Surprising? Not! Yet another chimera Google wanted people to believe in. And, people, don't point to the OpenMockup. The damn thing does not even do quad-band GSM, let alone 3G, non-withstanding the "port" is not done yet.

(Thanks to mako for the hint)

Monday 27 October 2008

Do Androids dream of freedom?

As I stated Android source code got released almost at the same time as the G1 HTC phone was released to "consumers". I welcomed it because the held their promises, even though, after looking a bit closely, it seems to contain binary blobs.

But the problem is still about Freedom.

One would have thought that Google would have thought differently, but they don't. First the phone availability: the phone is only available from a single carrier from a single country, with a 2 year contract attached. Also the phone is apparently not hackable: there don't seem to be a way to upload a custom firmware image. Not so open as other write.

Disclaimer: As you have understood now, I don't have such a phone. See reason above. Even if it was available through the monopolistic GSM carrier here I'd not have it as they'd surely require a 3-years contract which is a no go.

Also the phone require a Google ID. Not that it is hard to come by or that it is another money pit, but the requirement is awkward, seem unnecessary and raise some privacy concerns, or some red flag about tying feature of the phone to Google application hosting.

So what do we have left?

Nothing much. At least you can upload any application you wish, and you are not at the mercy of a vendor that decide life or death on your application... but there is still a kill-switch. Said application is also written with Android own toolkit in its own language and sandbox, making it hard to port anything from an existing application[1]. And that's it. Not a huge step for the Freedom to tinker.


[1] rumors said that it is compatible with the Java language

Tuesday 21 October 2008

Do Androids dream of...

I must admit I was suspicious of Google Android's openness and still considered it as a vaporware. But today they kept the promise and released Android source code. I was not the only one being skeptical. Kudos to Google and the Android team! I was wrong on that.

So far it is the most promising open platform for cellphones.

Now where do I get a handset in this third-world country? And without signing my life away to a state-sanctioned monopoly....

Thursday 20 December 2007

Media/Music player

Did anybody notice Turbo Linux Wizpy? It is a Linux based music/media player, and unlike some well known Linux based internet tablet, it seems to support Ogg playback (likely Vorbis encoded) for music files, out of the box. Not even sure how available it is outside Japan, its country of origin.

Wednesday 18 April 2007

Intel UMPC running Linux

I'm sure you didn't miss Intel MID, Intel's answer to the wave of UMPC and Internet Tablet. It features Linux, Matchbox and Hildon, all glued together with a distribution based on the Chinese RedFlag. But the more interesting thing is that the core chipset is based on a Pentium M and GMA945, which is much more horse power than, say, the Nokia 800.

Read more about it here, here, here

Now interesting challenge: while I'm sure it will be relatively easy to have AbiWord and Gnumeric running on it, like they already do on Maemo, but how about porting OpenOffice.org? Sure it will be contrived, but we have a 256MB of RAM, 500MB of storage and a 600-800MHz CPU based on a Pentium M (with half the cache on than the one found in laptops) which should be more than enough.

Wednesday 14 February 2007

Linux phone

The OpenMoko software platform has been released. OpenMoko is the the project initiated by FIC in Taiwan. Apparently the hardware is late, but they released the software still.

On the other hand, the Access Linux Platform has been released, and its openness looks much less appealing. ALP is the successor of PalmOS and is based on Linux.

They are both based on Gtk+ for their toolkit. That open more deployments for AbiWord.

Wednesday 24 January 2007

So long Zaurus, N800 vs Newton

Zaurus, one of the first Linux based PDA, the one where everything started is gonna disappear. Apparently Sharp announced that they'll discontinue the product. I think that one of the reason the Zaurus was not that successful is that it was not easy to buy: Japan, a selection of models in the US, and that's mostly all. And it was somewhat expensive.

Nokia 770 vs N800: I have had in hands for a few minutes on of my coworker's N800. All I can say is that the design is definitely an improvement over the Nokia 770. Two SD card slot, including one that is "inside" (next to the battery), that's is definitely good. To cut all the rumors, the screen is the same size on both. Sean Luke has written an easy about the N800 as seen from a Newton user and developer. Very interesting reading, and given the openness of the Maemo platform, it is doable by third parties. I'm still dreaming of a N800 with a "foldable" keyboard.

Update: according to this comment, the iPaq running Linux predated it.

Thursday 11 January 2007

CES season

It is "CES season", and it comes with a bunch of new devices.

First of all, the N800, successor of the Nokia 770, running Maemo 3.0 (code name bora) has be released. From the information gatherer, it bump from 64 to 128MB of RAM, get more chutzpah with a more powerful OMAP processor, get 2 MicroSD instead of a RS-MMC, and has an embedded orientable camera for video chat. Otherwise it share the same form factor, no keyboard. Maemo 3.0 does not run on the Nokia 770 but Ari Jaaski discuss about the options like what are the possibilities to provide a developer image for the 770 to test applications for the new Maemo.

Second, a Linux-based media player apparently sponsored by AOL (or one of it subsidiaries) that will sell music online. It does not play open format like Ogg-Vorbis, but MP3 and WMA (with Digital Restrictions Management). Since it runs Linux, it might be possible to provide other features through a custom firmware... SmartScreen, the "framework" used for the device firmware, seems to be more smartphone oriented. Unfortunately, it does not seem to be as open as Maemo. Interestingly its SDK appear to also be running on Linux although not everything... (the whitepaper from 2004 has old screenshots with Gnome 1.4)

This show how Linux on embedded device is really growing.

Oh, and one more thing. A lot of people have noticed iPhone announced by Apple at MacWorld. It does not run Linux (but MacOS X) and does not even seem to be open to third-party development. On the other hand, its user experience, still in a demo stage, sort of raise the bar[1] for future developments.

Update: it is actually SD card slots on the N800. That is very welcome.


[1] no pun, I swear!

Saturday 18 November 2006

Linux on phones

Linux on phones is spreading.

  • OpenMoko or the open source platform for cell-phone with a decent price. They claim to be exclusively open source. It is based on Linux and Gtk/X11 leveraging the OpenEmbedded platform. Some interesting point is that the phone module is separate and communicate with a serial connection.

Time to port AbiWord on GPE and OpenMoko? We already have a Maemo version.

Thursday 10 August 2006

I had a dream...

Sony just released announced the Mylo. The Mylo is a wifi enabled handeld, running Linux and Qtopia. At a similar price as the Nokia 770 ($350) it features in thumb keyboard (retractable) and a much smaller screen (320x240 unlike the 800x480 that the Nokia has).

If only the Nokia has that keyboard... I dreamt of such a thing: a retractable keyboard under the screen that you push up with the thumb when you want to type. I tried the on-screen keyboard in Maemo, and the problem is that it is on-screen: big thumb are not very compatible. The relief of the thumb keypad would make typing easy with a similar price.

Otherwise the ZipIt (see also) only cost $99... And it is hackable with Open Source alternative software.

Wednesday 21 December 2005

PIM Data synchronisation, part 3, the encoding

Something I forgot to talk about are the encoding for these iCalendar and vCard data. Why? Just because it is not clearly specified, or not in a way adapted to that use. I don't know what where the reason behind that, but something I'm sure is that it is a little bit shortsighted, as the RFC only address the use of that format as MIME content not providing any provision for a more versatile usage.

vCard: RFC 2426, section 5 state the difference between the vCard 2.1 format and the version 3.0 that the RFC specifies. It is written:

. The VCARD CHARSET type parameter has been eliminated. Character set can only be specified on the CHARSET parameter on the Content-Type MIME header field.

Previously we could specify CHARSET parameter for each field; now it is no longer allowed and requires that the outer MIME header specifies the encoding. This is quite restricting as we not necessarily have this in a MIME enveloppe. This leads to some weird behaviour with other software. For example, MacOS X Address Book application allows exporting addresses to vCard. If everything is in ASCII, then the vCard .vcf file is stored as an ASCII file. If it contains non ASCII data, like accents in French, the file is written in 16-bits Unicode, with a leading bom marker which is not without confusing other reader.

iCalendar: Section 4.1.4 for RFC 2445 state about encoding:

There is not a property parameter to declare the character set used in a property value. The default character set for an iCalendar object is UTF-8 as defined in RFC 2279.

Again, same as vCard, the charset specification is to be set by the MIME container. But this time, a default is specified: UTF-8. This is one point where vCard and iCalendar differ and where at least iCalendar has a sane default.

Now when the data comes from the device, sometime the developer has to figure out what charset it is. Even worse. Sometime it completely depend on the language the device is set in, and there might not be any way to know that, and assume that the user have the same language settings on both side. It is a problem as these encoding problem cause data loss of a various kind. Sometime it is just not the right char (but in that case that only cause differences), sometime it cause the string to be truncated because of a charset conversion failure.

This is something to be considered, and for the sync engine, I'd myself just go by using UTF-8 all the way.

Saturday 10 December 2005

PIM Data synchronisation, part 2, the data formats

You may want to read part 1 if you haven't already. I have explained why we might want to have synchronisation. Now I'll explain how we would do that.

First we need to understand how PIM data are or can be formatted. Actually there are various formats, more or less proprietary. And there are a couple of IETF format, vCard, vCalendar and iCalendar. iCalendar is the version 2.0 of vCalendar, and has been ratified as RFC 2445 by the IETF. It is the standard for storing calendaring information. vCard has been ratified as RFC 2426 and specifies a way to store and transmit contact information.

Both iCalendar and vCard have a common organisation, that is logical given the nature of the data. We have records that contain fields, with attributes. For example, a contact would be as follow:

FN:Homer Simpson
ORG:Springfield Nuclear Plant
ADR;TYPE=HOME:;;742 Evergreen Terrace

The vCard is a record, and each field is one of this lines that starts with a keyword followed by a ":", at least when it comes to the vCard format. iCalendar is quite similar, but allow embedding another record. No big deal. This is the logical organisation, and if you look closer, you'll realize that this is the design choice made for the Palm .pdb format where the data is just a bunch of records.

To be continued...

Tuesday 29 November 2005

PIM data synchronisation, part 1

Imagine you have a cell phone, a PDA and a PIM software on your computer. You expect to have the same set of contact and calendar events on each device, or a consistent subset. Currently PDA and phone are converging in term of functionalities as phone are having more than just a phone book and some PDA including cell-phone functionnalities. In fact you may just end up having one of these two, but still surely have a home PC.

So you need to synchronise your data from the PDA to the PC. This is something Palm popularised with their Palm Pilot back in 1995. You put the PDA on the craddle, you press the HotSync button and your data gets synchronised in between the two, carrying the changes made on one side to the other and vice-versa. But this was with one device, one PC software, problem was quite restricted 10 years ago. It slowly expanded to other PC software still using the same middleware. Not very different.

Add the cell-phone to the equation, and it does no longer work. PDA A has its software, cell-phone B has its software, and they are hardly interroperable together, even if sometime then end up being plugin of the same PIM software.

That is what iSync from Apple sort of tried to address: synchronising multiple devices, and it took time (2 OS release) before Apple provided the proper APIs for 3rd parties ISV to write drivers or support syncing in their applications.

Now let's see about Free Software solution. There have been several attempts to provide syncing tools, usually between one device to the PC. J-Pilot, Gnome-Pilot, KSync, KPilot, etc. are amongst them. Then came Multisync, whose goal was to provide synchronisation amongst multiple devices and your desktop PC. It was GNOME centric and for that reason got superceeded by OpenSync whose goal is to provide a general purpose synchronisation framework. fejj has been hacking on OpenSync lately, resulting in producing some patches to fix various issues and disappointements. We chated shortly about that on #gnome-hackers and I thought I would give some views on my ideas about thinking. After discovering some flaws in the design of MultiSync, I started thinking about it, but never got through finding the time to implement them, nor to put them down.

To be continued...

Thursday 25 August 2005

Palm woes

I was hunting for charger for a Palm Tungsten E, because:

  1. this device comes with a charger that only works in the region it is sold in, i.e. North America in my case, unlike my $50 Nokia cell-phone
  2. and I don't have that charger for various reasons

The Tungsten E does not have a craddle, it syncs with a mini-USB cable, and the one I have for the digital camera fits the bill. So I went to the stores that sell that kind of devices.

The first one didn't have the Travel Charger, a $45 + taxes kit that works worldwide with a variety of plugs, because it seems to be back ordered.

The other one did have the mobility kit, which is a USB cable that you plug to an adapter that you can use in your car. It advertises "charge it from any USB plug". So I got that for $40 + taxes. I go back to the office, plug it in to the MacMini USB port, nothing happens. *sigh* So I return it to the store, checking with the sales guy, and get a refund.

In fact it appears that in that case, nothing should happen, it is documented in the KB as Trickle Charge. It is just that it is charging slowly and the device will not tell about it. But the article is not really clear whether this apply to any USB cable or just that specific one sold for $40. So I mail the tech support and they tell within the next hour that it works with the USB cable that comes with the device (not the one I use, because I don't have it) for syncing. So it should work and I'll give it a shot. At least I know that it will not tell me anything when charging.

Bottom line: Palm, you would have written on your package how this work, that we are not expected to have feedback from the Palm when plugging this thing, you would have sold it to me, even if I don't need it.

And the fun part: In the second store, there was a LifeDrive with its web browser and wifi. I tried the browser and in a few minutes, when trying to load this blog, it ended up with an error like: "Sorry can't load, page is too big". I never got that with the Nokia 770.

Friday 27 May 2005


There is a wonderful app on Palm: Metro. Unfortunately it is only free beer, and apparently they intend to stay so as they explicitly say to not ask the source. Too bad. Anyone thinking reimplementing this as Open Source, eventually reusing their datafiles (I mean supporting their data format so that one can use them) ? The Nokia 770 would be a perfect target.

BTW, I installed Stuttgart metro file for tomorrow.