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.

Monday 12 November 2007

Open, the new buzzword

Dalibor comment on the Android SDK licensing. And Paul open questions about the announcement of Open Handset Alliance.

Happy to see that I'm not the only one thinking about that. I believe more in GMAE, and OpenMoko intents, as well as Nokia's, are much clearer.

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.

Thursday 16 February 2006

More Linux everywhere

The two biggest ISP in France providing broadband internet access via ADSL offers Linux based modem to their customers.

Free with the Freebox, for which I worked a few month, was the first to do that having a two-ended ADSL solution running Linux. Their Freebox modem and set-top box, that provides Internet access, VoIP and TV over DSL, and the DSLAM, the other end, that works over IP and Gigabit Ethernet (fiber optics) unlike what was on the market, at least in 2003, that are ATM based.

Now, France Telecom with the Livebox, provide a DSL Modem/router, with VoIP (yes, a telecom operator that compete with himself with VoIP services), TV (requires an external Ethernet connected decoder), wireless and other gizmos. This box, made by Inventel, runs Linux (the manufacturer advertise it as such).

But last news is more encouraging: Access Linux Platform by PalmSource. PalmSource has been acquired by a Japanse cell-phone company that wanted to go away from Symbian and WinCE with the plan to make PalmOS and Linux the base of their next generation OS. So they announced it. ALP has a Gtk based UI (they don't tell about X11, but apparently it uses X11) and use gstreamer, sqlite on top of a Linux 2.6.12 kernel. I wonder how much intersect with Nokia Maemo, but that would be their interest to team up to create a viable ecosystem of software. Maybe this time we could have AbiWord on PalmOS?

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...