HE Nokia 770, which I have mentioned before its arrival, is an Internet tablet that is based on Open Source and the Debian Linux distribution. It has proven to be very popular among gadgeteers from either side of the world. In fact, high demand rendered it “understocked”.

A new development environment has recently been introduced to the public. Its intent is to encourage involvement from the Open Source community. Many Open Source projects will sooner or later be ported to run on the Nokia 770 with its high performance hardware and high-resolution screen. As for size, the dimensions of the device are comparable with that of a typical Palm handheld.

The world’s largest mobile manufacturer Nokia looks to have scored a major hit with a new wireless device that doesn’t have any phone functionality. The Finnish firm announced on Wednesday that, against its expectations, it is to increase production of its 770 Internet Tablet handheld after achieving huge online sales since its launch in early November. In fact, demand for the product in Europe and the US is so great that the company has currently run out of stock and customers are facing a minimum two-week wait for the device.

As I said half a dozen times before, I am tempted to ditch Palm after many years. The Nokia unit suits my needs, as well as ‘development mantra’.

I may be an exception and perhaps even an oddity. I lost interest in PDA applications that differ from the most fundamental PIM set. Alas, I sometimes wonder if anything beyond a reliable simplicity is truly necessary. I suspect not.

I bought a Tungsten over a year ago, but I need never do anything that I could not do on the M130, which is a low-end PDA I once owned. It now sits idly and serves no-one even though it works. It has a few minor defects, but workarounds can compensate for all of them. What was its contribution to the subsequent device in the ‘upgrade cycle’? A 32 MB memory card was inherited from the M130, among a few other peripherals. A larger SD card (quarter of a gigabyte) is now available, but it rarely, if ever, gets used. Same programs are used and the capacity required is similar. So what does it all come down to?

Palm rarely ever failed me where it mattered the most: data integrity. After over 3 years of regular use of the Palm I can only vividly recall two incidents of data loss which were a nuisance. Both incidents were not at all severe and they both date back to 2003:

• Incident #1: I was editing a large memo for approximately half an hour without applying the changes. A very rare crash of Memo Pad led to the loss of all changes. A lesson was learned following this loss. As I compose this item on my Palm at the moment, I do not neglect to periodically save it.
• Incident #2: Half a day of changes were lost after restoration from desktop-side backup. Fortunately, all that was lost included a few calender entries, which I could quickly restore from fresh memory

I have had an SD Card-based backup program for over a year, but never had the chance (reason) to use it. Well done, Palm, for preserving my data and preventing me from ever pulling my hair in frustration over data disasters.

Side note: I truly hope that Palm can deliver innovation shortly. They begin to lag far behind their competitors and I am tempted to swap vendors and move to Nokia’s Linux-based tablet.

ALM have intended, for quite some time in fact, to ditch Palm OS in favour of the Linux kernel.Then again, there are independent efforts by individuals to boot and run Linux on Palm devices, regardless of Palm’s mainstream initiatives.

Two new examples:

• The Palm LifeDrive
• The Palm Tungsten T3

Related (older) items: Linux on the Tungsten E

When your data is only readable to a program

EVERAL weeks back, I came across concerned Palm users in the forums. They were uncertain and confused with regards to their Palm data formats. Some were wishing to migrate their data, while some just wanted to rest assured that they were not susceptible to vendor lock-ins or needed to jump through hoops to make a transition, shall it ever be required.

Palm’s software certainly offers data export facilities, yet these are not flexible enough. The range of supported formats simply does not cut it. It appears to adhere to legacy formats from the previous decade, which is probably the cause for many other limitations, which make older Palm models compatible with some of the latest.

On the other hand, Palm’s compact formats make data access and writing quick, which is crucial for low-end mobile devices with weak CPU‘s. The formats are rather compact, although not easily compressible. As always, there is a trade-off between openness and performance. OpenOffice and Microsoft Office are just one example of that. At present, Palm appear to have learned nothing from the former. Until they learn that lesson, the observations below are worth making.

Looking more closely at a variety of PIM data files, I quickly discovered that they could be classified as “proprietary”. They were rather opaque too. These files comprised a mishmash of binary and text, which means that knowledge as to how to interpret such files laid in closed source code from Palm. It was not easily recoverable, although programs like JPilot and KPilot are able to import all data apart from the calendar (DateBook), which is the most complex among all. Likewise, there are Palm to HTML convertors that run under Windows, but they can only handle AddressBook and MemoPad data, in line with relevant, unofficial documentation.

I could not help feeling disappointed by that discovery, which means that personal information is cumbersome to access. As the Web guru Jeff Veen recently said, “Give me my data” is the quote that immediately sprung to mind. Therein Jeff talks about heart rate monitors, but here we speak of calendaring data, including extensive archives and PIM, which puts a barrier in front of its actual owner. Palm should have stuck with a more canonical form such as “vCalendar/iCalendar, which is already mutually supported across multiple platforms. This type of Move to iCal or vCal (vCalendar, iCalendar), or even comma-sparated list was discussed many years ago.

Alternatively, why not use something standardised and generic such as XML, which can be easily parsed and manipulated? Is it not a foreseeable option, especially to Palm who combat a king of proprietary, thus misunderstood formats? As I continue to look at my Palm archives on my computer, I am filled with despair. I relveal that my records are interpretable to no calendaring software other than that which comes from Palm themselves. I would definitely recommend that Palm consider re-working their formats as it can become a major selling point.

Nowadays, More and more people (and even governments) come to discover that their old mail is often meaningless and inaccessible due to formats that are vendor-specific. Berlin, Paris and Massachusetts are only few among the loud protesters against undisclosed data formats and mockery of standards. It is only today that we hear of promises (as of yet doubtful) from Microsoft, according to which Office formats will become open.

Microsoft will on Tuesday announce it is opening up access to its Office file formats to competitors, as part of a move to ensure the software giant does not lose lucrative government markets for its Office software.

Let us wait until those fine prints become legible.

Cited by: PalmAddict

CLI anywhere, at any time

CCESS to particular computers can be crucial, especially while travelling. There are a variety of ways for achieving full remote access, though simple, text-based shell access is supported by even weaker devices and light-weight software.

I recently read about someone who thought of handling Web servers from a Palm Treo, using E-mail, which is supposedly a universal API. I consider E-mail to be the wrong tool for a simple task, even if one uses cron jobs and collects the output via E-mail (similar to a hack I once mentioned. Alternatively, shell access can be obtained in one of the following ways:

• Cellular telephones: using CUTs
• Web-based: MindTerm, e.g. from Duke University
• Windows: PuTTy
• Windows mobile: I have seen an SSH client in action and it looked quite clean
• UNIX variants and derivatives: Built-in functionality
• Palm O/S: pssh, free and apparently based on PuTTy, though it is hard to tell for sure
• Blackberry: For that, one might have to pay nearly $100. That’s the chance one takes when steering away from Open Source. Palm may not be Open Source-oriented, but its users’ ideaology differs.

OR several years I have retained one spreadsheet on my Palm handheld. This was, in fact, a crude timesheet which was needed for work. Several months ago I decided to migrate everything to OpenOffice and access that spreadsheet using SSH from virtually any connected Linux box. This sounded reasonable at first, but frequent updates made this rather impractical and cumbersome.

Later on, I decided to export all data from OpenOffice as plain HTML tables and then repeatedly modify the HTML files on my Web server. This was rather time-consuming, so I sought alternatives which I knew existed.

I wound up using a Web-based spreadsheet application that is very light and retains all data as comma-separated values (thus no database needed). That powerful tool was Open Source, as always.

phpWebSheet has powerful and advanced (from a Web-based point-of-view) features such as tabular copy-and-paste, Wiki-styled formatting, and support for formulas/functions. In my perception, it is yet another winning application for PHP. There are many similar free applications at freshmeat.net, but I only investigated two which appeared better-suited for the purpose and rather mature too.

Spreadsheets are of course password-protected, but can still be accessed rapidly from everywhere at any time. All in all, the transition was a rewarding one. I sometimes wonder if I should have just stuck to the Palm PDA rather than make a progressive 3-step transition (as outlined above).

Spreadsheets have been on my Palm for years, virtually seconds away at pocket’s distance. Nonetheless, Being a Web technologies fanatic, I am always enthusiastic about ‘Webward’ transitions. On that same batch of installations, I set up phpshell which enables me to obtain shell access to my shared Web server. I can even see what the administrators are up to. This does not require a cron job hack as I once described.

Access to so many free packages (roughly a dozen of them on my domain already) is why I love Linux and the GNU ideaology.

KPilot screenshot
version 4.3 on SuSE 8.2 (not the version reviewed below)

INUX Palm synchronisation is a scarcely-explored territory to many. I currently own a Tungsten and I have 3 machines, all of which run Linux. In practice, I refuse to use my Palm for much beyond basic PIM, at least on a daily and thus realistic basis. Even MP3 playback capabilities have lost their appeal, so what I require is a rather rudimentary, but nonetheless user-friendly and reliable Palm-PC interaction suite.

Introduction and Disclaimer

I am fortunate to have had an opportunity to put both KPllot and JPilot on GNOME (gnome-pilot or gpilot) to the test. It seems as if they all trace back to a similar codebase, which includes pilot-link at the very core. My experience with the JPilot front-end is limited, so in my short review I will attempt to focus on default KDE and GNOME conduits — particularly the ones that come ‘out of the box’.

Admittedly, I only used GPilot for several weeks before looking into what KPilot (Version 4.5: “Baby”) had to offer, having glanced at it briefly last year. On equally-modern distributions, namely the GNOME-based Ubuntu Warty Warthog and the (largely) KDE-oriented SuSE 9.3 I have been putting Palm synchronisations to the test. Experimentation was a prolonged one and it covered some crash testing (hard-resets with data loss) and in-depth GUI exploration. This came after 3 years of using Palm Desktop under a Windows 98 laptop and a Windows 2000 desktop, I might add. All in all, there was good basis for inter-platform benchmarks, so critique should not have been a narrow-minded one.

Conclusions and Opinions

My first impression is that KPilot is more comprehensive than others, much like the entire desktop environment is resides in. I personally favour KDE although I use GNOME several times a week and almost every day. Overall, my opinion is not likely to have that ‘desktop environment bias’.

KPilot integrates rather well with its underlying/surrounding environment (e.g. mail client and calendaring software) whereas the GNOME equivalent is rather stripped-down and raw. The latter does what I require it to do and it even attempts to synchronise with Evolution (Outlook-type suite), which has been said to be slightly buggy. Nonetheless, it fails quite miserably at matching that ease-of-use of KDE’s equivalent. Firstly, setup in GNOME requires some hand-tweaking, at least in accordance with my own experience. This can end up consuming plenty of time. I also found the wizards in GNOME to be less helpful, more verbose, and more confusing.

Returning to KPilot, the front-end interface is a more natural one to its user. During synchronisation, all files are ordered with a sensible file structure under ./kde/share/apps/kpilot (or equivalents). gpilot, on the other hand, adheres to a flat hierarchy that provides little context, if any. Moreover, KPilot is largely intuitive, highly-customisable and comes with cleaner and apparently more comprehensive documentation.

Lastly, to those with strong sentiments of disagreement, I must clarify that everything was tested under Ubuntu and SuSE. All of the above observations can be attributed to distributions rather than the Palm conduits and packages. Nonetheless I would choose to go with KPilot as I presently do although I used gpilot at the start. It seems as though KPilot is simply more mature.

Your Palm and That Linux Migration

If you dread the day when you must synchronise your Palm with a new Linux box or a fresh installation, have a look at the very self-contained HOWTO.

Cited by: PalmAddict