Welcome to the Jungle (Redux)

My friend Diego Mariño has announced in his blog that they have succesfully connected a printer to a computing grid. Think in Grid is a startup from Barcelona with an innovative Grid computing framework. They claim to be able to integrate all kind of devices in a computing grid, just like this printer:

Coming from the M2M busines I know that the Holy Grail of this business is not only the transparent connectivity of heterogenous devices through non-reliable (wireless) networks, but the capability to split and perform complex operations remotely just like if they were performed locally.

Obviously, it sounds promising.

Sometimes you only need to wait to understand why things happen. When Steve Jobs said 'Java is not worth building in. Nobody uses Java anymore. It's this big heavyweight ball and chain', we were surprised and disappointed because like me a lot of people think that there is still room for Java in the mobile platforms. Of course we have J2ME, but we can do very few things with it. What we need is a full J2SE stack for mobiles. And the iPhone could do it... if Mr. Jobs wants. But he does not want because Java has become the flag of Google to do developers to follow them. He chose to keep Java out of the iPhone to keep a strict control of the platform, to keep Google out of his business.
I have just reviewed what Google Android is, it's architecture and the SDK and I think it's much more than a smart mobile platform: it's a philosophy. Think of what SWT is to the Java User Interfaces and apply it to the Android Architecture. The access to the physical layer has been developed in C/C++ on top the Linux OS, and on top of it there is a pseudo-Java Virtual Machine called Dalvik virtual machine. As they say, "Dalvik has been written so that a device can run multiple VMs efficiently. The Dalvik VM executes files in the Dalvik Executable (.dex) format which is optimized for minimal memory footprint. The VM is register-based, and runs classes compiled by a Java language compiler that have been transformed into the .dex format by the included "dx" tool."
J2ME is very similar in the approach, but what looks new is the tight integration with the OS and the use of Java 5 extensions of the language. J2ME is almost JDK 1.0, but if you read the source code of the samples, you can recognize some coding practices of Java 5. I still don't know if the Dalvik VM can do reflection or annotations, I will need some time to test it.
The access to the physical elements of the mobile device are performed thanks to the set of android.* packages. So, it will be a task of the device manufacturer to migrate the C/C++ libraries layer for their devices. I have tried to find some information about how to certificate that the libraries has been migrated correctly. This was one of the key elements for the success of J2ME on the mobile phones, and should be done the same way.
The Java applications are what they call 'Third party applications'. It's not possible yet to develop or modify the underlying Linux OS and the C/C++ libraries. Again, Java runs in a sandbox -sounds familiar, eh?-.
I will continue playing with it. Just some random thoughts, will Sun Microsystems get some money for the licensing of Dalvik VM? How much? Will J2ME be replaced by the Dalvik VM?

I was astonished when I read that Palm cancels Foleo just before starting to ship it. The reason sounds like an excuse: '...it has become clear that the right path for Palm is to offer a single, consistent user experience around this new platform[WindRiver] design and a single focus for our platform development efforts.'
There were rumours of delays because buggy software. The product was announced for shipping this summer, but the season was running out and there was not date for the product.
What have happened? Who knows... The Foleo device were going to face a very hard competition with the new low-end laptops. It sounds like they are rethinking the product. Meanwhile, this cancellation has cost to Palm 10 million dollars.

I have just read this post in Engadget about rumours of the Google Phone. I will highlight this: '...the phone will run on a Linux variant (which is nothing new), and will be Java Virtual Machine-capable. Additionally, the OS of the phone will be Java-based (as well as the all phone apps itself), and performance is said to be "very responsive."'
It seems the GPhone will look like a Palm Treo or Blackberry with a screen smaller than the IPhone.
If these rumours are true, Google will become a big supporter of Java for interactive devices something the device market needs desperately to set free of the Windows Mobile and CF.NET slavery.

The day Steve Jobs said 'Java’s not worth building in. Nobody uses Java anymore. It’s this big heavyweight ball and chain' . Being a Java Zealot as I am, I should find easily a fist full of arguments, but may be he is right.

I have been working in the embedded and mobile world for almost four years in Amplia, and I can tell you that Java is far from being the best option for mobile and embedded development. Even for complex mobile applications I think it's not even an option. There is not a decent implementation of the J2SE for ARM microprocessors, on Linux or Windows CE. There are some implementations out there, but believe me, they are far from the quality standards that Java developers expect. Sun Microsystems realized long time ago that building a J2SE for ARM and embedded OS was hard and expensive and they gave up, abandoning the project.

Of course J2ME it's there. But J2ME was designed for devices with a lot of limitations in term of resources. Devices like mobile phones and embedded hardware. But not for PDAs and the new Smartphones with big screens. Try to build an application with a rich UI with J2ME. It's a nightmare compared to CF.NET for example. J2ME has been very successful for games and simple apps for mobile phones which can gain access to the hardware layer, but nothing else.

But Steve Jobs was not talking about the heavyweight ball and chain of Java because his big memory footprint, slow start up and all that techie stuffs. It's a ball and chain because means a marriage with Sun Microsystems. Steve Jobs would love to have a J2ME virtual machine for the iPhone... if it was for free. But it's not. All devices running J2ME must pay a fee to Sun, no matter if they use it or not. And that's a lot of money. For example, the IBM J9 J2ME implementation for ARM costs $6 per license. Why should Apple pay for it? They have the OS for free -a Symbian license costs between $2.5 and $5-, they have the browser for free -I don't know the license costs of Opera-. So probably Apple can save around $15 per device just using their own dog food. So they said:
1) is it possible to build web applications with HTML and Javascript on Safari? Yes, we just need to allow developers to test easily on Safari. Voila! Safari for Windows!
2) Can we migrate Flash to the iPhone? Yes, and it is easier to port it than a full J2ME stack. Games, Video Streaming and Rich UI apps can be done in Flash too.
3) How many applications today need offline behaviour? Not too much, but less than a few years ago with a rise in the trend. And the device have been designed to be 'always on and connected' to the GSM network and WiFi. The 'offline' behaviour is not so important.

And they decided not to include Java because gave nothing to the business model behind iPhone.

But Mr. Jobs forgot something:
1) Mobile devices (and iPhone too) needs to have access to the hardware to control the low level resources like Bluetooth, GPRS modem, SMS messaging, Wifi connection, Serial ports. A web application cannot access the hardware layer.
2) May be the offline behaviour is not so important, but wireless networks are not as reliable as fixed networks. Offline behaviour from the browser is not mature at all.

So Mr. Jobs and the iPhone needs a piece of software to complete his Masterplan. They need an Embedded Application Server. What? Are you crazy? An application server? In a device? I will explain myself. When we think of an application server, we imagine a J2EE implementation with a plethora of functionality. But this app server is different. Here goes a list of what I think it should implement:
- A small web server to deliver content to the local Safari web browser.
- A scripting language to write server side code. Of course this dynamic content should only be served to the local Safari web browser.
- Massive Multithreading is not a must (it's all local).
- A permanent storage in the device for offline operation.
- Management of the low level resources of the device.
- Some kind of queuing system for asynchronous operations between the device and the remote elements.
- A synchronization service between local storage and remote storage.

This embedded application server should implement a scripting language. Why scripting? Because the logic to implement in a device must be simple by definition. The really complex stuff is the management of the hardware layer, and that's should be implemented in C/C++ and be very restrictive regarding the access of applications to this layer.

There are already some solutions out there in the embedded world but most of them focus on the Synchronization service when the really hard stuff is to control the hardware layer.

Looking for information on how to configure the Chillispot in my Soekris net4521 with Voyage Linux, the people from Poblete Wireless has blogged about a device that looks very similar to 'La Fonera', POBLETEWIRELESS: �Es esto el posible Fon Liberator?.

The device has been developed by Accton, and you can check the specs here.

I have been tracking FON for two years, and I'm a 'fonero' since last summer. Recently I read about the 'FON Liberator' project, and it seems that finally the mystery of FON is over. If you analyze seriously the business model of this company and you have some basic knowledge about wireless networks, you easily find that something does not match. The original FON business model (and I say original, because now it has changed) was 'share your bandwidth and you will have access to the enormous WiFi network of FON'. Once the network is deployed, then the company can bill non-Fon users to use the network. Mr. Varsavsky is really a smart guy, isn't it?

But this business model has serious technical restrictions:
1) The coverage of a standard WiFi hotspot is about 100m. So even in metropolitan areas, you need a FON member in every block!
2) Why people is going to share their network? People does not use WiFi hotspots every where, only really geek people and executives (and they use 3G connection because they can afford it).

FON trusted in WiMax to fix the first technical restriction: coverage. But WiMax is far from being available as the wireless connectivity for the masses, and may be the WiMax assumptions regarding coverage and deployment that I read in documents they published in FON web site about 18 months ago are not going to be implemented before 2009 or 2010.

So they need a short path to continue with the massive deployment of 802.11b/g hotspots: they need to motivate users to share their bandwidth. How?

80% of the Internet traffic in Europe comes from P2P networks. It means that a lot of people have a computer up and running 24 hours a day seven days a week sharing files with 'colleagues' all around the world. Whether this practice is legal or not it's not my business. It means that people have their personal computer stressed running this P2P software (Emule, Bittorrent, Azureus, MLDonkey...). What IF you have a specific device that can manage your shares in your P2P networks? You just plug in your 500Gb external USB 2.0 disk drive and voila! No more disturbing noise from fans, no more fear of fire, no more broken computers because of abnormal stress! FON will sell this device below their manufacturing price for 70€. The trade off? You will have to share your bandwidth with the FON community, of course. I guess this solution can be the killer app for the success of FON.

But is this something new? No, not at all. Basically, FON is going to sell a SBC (System Board Computer) router with a WiFi card and enough RAM memory to run a Linux (may be an embedded version of Debian) and some Flash for the OS and bootstrap. 64Megs of RAM and 64Megs Flash should be enough. And there are some commercial devices that have been modified to run something closer to the Fon Liberator. Here goes a list:

• Linksys NSLU2
• the Synology DS101
• the Iomega NAS100d
• the D-Link DSMG600
• the Buffalo Linkstation
  

You can find some cool stuff on how to flash custom built Linux distributions on these devices in http://www.nslu2-linux.org/ and http://www.linkstationwiki.net.

In my spare time (if you run a company and you have a one year old baby that's really short) I have built my own FON Liberator with the following hardware:

• A Soekris net4521 board, purchased to the European distributor.
• A Gigabyte GN-WIAG01, a cheap Atheros miniPCI card.
• A Conceptronic CSP480C2 PCMCIA 2 Ports USB 2.0 card.
• A Kingtson 512Mb Compact Flash.
• An external USB 80GB hard disk.
  

The total cost of this hardware is about 240€ (excluding the hard disk). Obviously, the FON Liberator will be cheaper!

I decided to use the Voyage Linux distribution because it's perfect for small systems, and it has a version for Soekris boards. It's based on Debian Etch, so it's very close to the official release. I have added the following software:

• Samba Server and SWAT console. So I can access my files from computers running windows.
• UShare as a UPnP media server. I can broadcast my media to my home devices.

I have also tried to install MLDonkey, an implementation of the Donkey protocol for Linux and it works. I just installed it for the purpose of study, later on I switched it off. This software is much better than any other P2P software on Linux, because it implements half a dozen P2P networks (bittorrent, overnet, kademlia and others).

I must admit that it works smoothly, but I have two problems:
1) I had to create a SWAP partition in the external drive to run ushare, samba and mldonkey.
2) Sometimes, when transferring files at maximum speed the system crashes. I don't know what the problem is, but seems to be a problem of the Conceptronic card.

And here goes a photo of the system...



And my Nokia 770 running Canola playing content as a UPnP client...



Once I have fixed the problem with the crash, I will buy a DLink DSM-320,



to play all my media files on my TV screen.

Cool, isn't it?