Darwin's Theories - Software Industry category

Islands in the Stream

Thu, 28 Jan 2010 20:00:00 GMT

Some will say that Apple's iPad is the be-all and the end-all of portable computing. I say nay.

Don't get me wrong, I'm a big fan of Apple. But look at the history. Datapads are not a new idea - Alan Kay's DynaBook and Mark Weiser's ideas of Ubiquitous Computing - both from the 1980's, with Weiser explicitly using the term Pad - predate the iPad by almost three decades. As much as I generally dislike Microsoft, their push for the "Tablet PC" probably led to some advances in hardware. Amazon's Kindle and Sony's reader both pushed hardware makers to build better screens and raised the bar on users' expectations.

And one important thing that Weiser advocated in the 1980's is still missing (full disclosure: I admit to being in the field long enough to have read his papers when they were originally published). In Weiser's world you could just slide a task you were working on from a handheld pad to a wall-sized whiteboard or to a wristwatch-sized device for storage, and things like active TCP/IP connections would automatically move onto the new computing platform. While you may be able to drag a project from a Mac OS application to a USB stick for storage, this is a far cry from having running applications movable from one computing device to another. People are indeed working on this problem, but a general solution is not yet at hand, as far as I know. It's not something you can buy today from Redmond or from Cupertino, at any rate.

Until this happens, our computers will remain isolated islands in the stream. Even if they are iPads.

JavaOne without Moscone Center?

Wed, 27 Jan 2010 16:50:00 GMT

After a very long and uncomfortable silence, Oracle, having passed the last(?) regulatory hurdle to their acquisition of Sun Microsystems, today announced that the JavaOne conference will in fact go ahead - this year. It will be co-located, but not merged, with Oracle OpenWorld; this year's dates are September 19-23 in San Francisco. That means there is still time for the refereed-paper approach that has been used in past JavaOnes. Partly since Moscone cannot hold all the attendees who would take part in both programs, and partly to reinforce the fact that it's not merged, JavaOne will be held in three hotels near Moscone (the huge keynotes will however be held in Moscone). I was heartened to hear Justin Kestylin of Oracle say that they want to "maintain the soul of JavaOne." We shall of course be watching to see how well they do at that.

JavaOne will also be going on the road: the "Sun Tech Days" program will be replaced by regional JavaOne conferences; the initial locations over the next year will be China, India, Russia and Brazil.

There is an FAQ coming within the next day on Oracle Developer Network. The following programs will be preserved: java.net, java.sun.com, Java Community Process, and others.

Watch otn.oracle.com for the FAQ - I'll update this with the link once it's available.

Another Top 10

Mon, 25 Jan 2010 17:29:00 GMT

Here we go again:

OpenMoko and Android

Tue, 21 Apr 2009 17:35:00 GMT

A few people have asked me at various times for a comparison of the OpenMoko and Android cell phone projects. Given that I advocate for the former, and also for Java which is (and is not) the base language of the latter, I am expected to be able to say something intelligible by way of comparison. So here goes.

Android is a project spearheaded by Google to make an open-source phone. It uses Linux and its own Dalvik virtual machine, and applications are written in Java against the Android API and compiled down to Dalvik bytecode. Android does not expose the rest of the Linux services and does not support other programming languages. Android phones are available from a few carriers.

Openmoko, funded by Openmoko.com, is at the other end of the spectrum: it also uses Linux, but exposes all of it to the developer. The "main" stack of phone apps has been re-written several times, using various X-based toolkits. The "official" OM2009 stack is in large part written in Python. C/C++, Java and Perl are all available. Openmoko phones are available from Openmoko.com. However, because it is all open source:

you can run Android on Openmoko hardware;
you could (people have) run Openmoko software on other devices, including Palm PDAs, other Linux phones, and software emulators;
you can probably run Openmoko software on Android hardware;
you can run QTopia on Openmoko hardware;
you can run one of half a dozen Linux distributions on your Openmoko hardware;
you can (eventually) run other OSes such as OpenBSD on Openmoko hardware;
etc.

From one point of view, they are not enemies. Both support the open source model. But as Openmoko developers have pointed out some time back, Android sits on top of Linux, abandoning most of the open source world and reinventing its own universe. Openmoko embraces all existing open source projects and any new open source comers. As a single example, communicating to your Openmoko phone from a desktop/laptop computer consists merly of running the industry-standard ssh and scp programs, included with every *Nix and readily available for those other OSes that need them. Talking to your Android phone requires finding, installing, and figuring out how to use an ad-hoc program called "adb" (at least the third use of this name, after Unix' Algol/Another DeBugger and Apple's Desktop Bus).

From another point of view, of course, they are competing. Competing for market share (neither has made much inroads in the consumer space). Competing for developer mindshare. Android tends to get a lot more press, partly because of the "big G" lineage.

People sometimes ask if I think Openmoko should just fold up and go on to something different, given how far ahead Android has moved? I've never been a fan of quitting while you're behind. Imagine if Linus Torvalds had quit while Unix was ahead; his then-little school project would never have seen the light of day, and we'd all be running BSD and System V. Nothing wrong with those - BSD was already on its way to becoming a full open source *Nix, as represented today by OpenBSD, FreeBSD and NetBSD - but things would be rather different in what is now the Linux community, to say the least. Or if Bill Gates had quit while IBM was ahead. Or if Steve Jobs had quit while MS-Windows was ahead. Or if the U.S. had quit the space race when the Russians launched Sputnik. You get the idea. Don't quit while you're behind, nor when you're ahead. As Nathaniel Branden once put it, "a beating heart is a living heart" - so keep on pumping!

And, at any rate, the "real" release of Openmoko software, OM.2009, is almost upon us; I am running a beta of it on my Freerunner (GTA02), and it's actually usable as a cell phone. Butt-ugly compared to some of the earlier releases, but it "just works". Formal release is expected this summer.

Microsoft Bites Me Again

Tue, 17 Mar 2009 20:37:00 GMT

I just created a Java application that is needed on several platforms, one of which, alas, is the ubituitous and ill-designed Microsoft Windows XP. In the project there are some classes that are auxilliary to the main program. Naturally enough I created a package for these called "aux". In Java a package name is also used as a directory name when the files are stored outside of archives, as they are during development. Hmmm. "aux". I know that Apple Computer long ago had a UNIX version called A/UX, but I didn't know anybody else had dibs on the name. But it seems Bill Gates was after Apple even back when MS-DOS was being cloned from CP/M-86. For it turns out that "aux" is a reserved filename, not just in MS-DOS, but even today in Windows XP (for all I know and don't care so please don't tell me, Vista too). It's because "aux:" is a device name, and the system is too scatterbrained to tell whether you mean that, or a file, if you just type "aux". The result is that WinZip was unable to restore all the files in this package; so I had to waste about half an hour adapting to this (including copying these files again, changing their package name, changing all the files that refer to them, making sure the changes made it back to my real OS (no extra points if you can guess which one it is) and get committed into my source repo so that I don't have to put up with this "hideous botch" ever again. Until next time we meet some screw loose in the M$ universe, that is.