Or the Linux version.

It was ported to Linux 2 years ago(right after the windows release) but it was never released.

Asus tried it already and it failed.

Failed?
They sold a shitload of them.

It's had an x86 build target on scratchbox since at least 2006, maybe even day one.

What do they plan to do to grant pixel-level access?

You can do this today with dojox.gfx and it's completely open source. You can use simple calls that are implemented differently on different browsers. On firefox and others your drawings are rendered in SVG, in IE its VML, on others its HTML5's Canvas.
Canva's event model isn't as nicely integrated with the DOM as SVG and VML, but you can pretty much draw things cross platform.

Pure javascript, no plugins required.

Sure. "yum install wine" or "apt-get install wine" or "google's pointy and clicky installer to fetch wine"

Personally I hope they just pick rpm OR deb and the other distros just drop the unused one. Two package formats is a case where competition isn't helping linux.

From my 3 days experience with it, it looks exactly the same. The android plugin from the update site is 0.91. It may just be that 3.5 is backward compatible enough to run the same plugin.

Javascript libraries for things like browser abstraction and animations are really nice, but they're getting kinda of bulky.
Content delivery networks like AOL and Google are hosting them for free, so it makes sense for websites to just include them and use the big guys' bandwith.

You can do cross site scripting right now using JSONP. Basically include a script with a callback function name and run an eval on the response. The object you really want as a response is placed in as the parameter to your callback.
It's extremely useful when you are able to trust the other host.

However, if you don't trust the other host, you shouldn't be including their script in the first place. Because that script may contain something like a javascript function to send the cookies of the first domain to someone else.

It's pretty straightforward on how to secure the stuff, but we'd be a lot better of if browsers had a native evalJSON() function instead of just an eval(). That way we'd know we're just sending back objects instead of executing arbitrary code.

It's Java + Eclipse, which is notoriously slow when compared to XCode and the iPhone Simulator

Eclipse isn't required for development, though it is extremely useful. And you don't like Java, there's a Native SDK now: http://developer.android.com/sdk/ndk/1.5_r1/index.html

UI design is done in very verbose XML, as opposed to Apple's Interface Builder, which lets you easily drag things where you want them

The GUI is described in XML, but you don't have to use a text editor to build or edit it. There are in fact tools in Eclipse to drag and drop components into the GUI. Heck, there's even an applet I've seen that will do some point and clicky GUI creation and spit out XML.
Would you rather that there was only a closed source proprietary IDE that spit out binary data to build your GUI for Android?

Since Android is a platform and not tied to a single device, you have to design in "device independent pixels" which is much different than the iPhones set-in-stone 320x480 resolution

You say that like it's a bad thing. So if apple decided to put out an in-dash car PC using the iphone OS, you'd like the fact that the existing iphone apps look like shit in it? Or would you want the in-dash screen to run at an obscenely low resolution?
How about programming GUIs in way that allows them to play nicely in multiple screen resolutions?

Core Animation... 'nuff said

No, not enough. Please elaborate on why that makes iphone such a great platform to develop on.

I'm actually running JF 1.5, rooting was easy :)

The browser pinch zoom is cool, but I'd really like it in the maps application.

Would be nice to see this stuff official though.

I have a g1 and a ipod touch. The differences are really multi-touch and apple's stuff is more round and bubbly.

Estanislao was trolling.

The online Android installation instructions are much more useful, because they also include the latest version of Eclipse, 3.4.

Actually 3.5 (Galileo) is out now. There aren't explicit instructions for it on developer.android.com, but it's still works the same way. Add the update site, and install the plugin.

dojo.gfx does this as well.

IMHO the watershed moment in Java was 1.5, courtesy of generics which made the collections at least somewhat usable without constant swearing.

Was casting that big of a deal?
The newer syntactical sugar is nice, but the lack of it was never a showstopper.

Wrong. Wrong on every point.

Java isn't really open source, that's why it's a huge pain in the ass under Linux.

It's in the standard repos on most distros now. It's not any different than installing python or perl or any other language/platform.

Yes, Sun released a version of Java under the GPL. It's the "next" version of Java, Java 7 or 1.7 or whatever they're deciding to call it.

They released the 1.6 JVM and libraries that it was legally allowed to.

The current version of Java, the one that everyone uses, is most definitely not open source. It's free, sure, but it's licensed in such a way that Linux distributions can't package it. (Easily - some have worked around it, but the bottom line is that installing Java 6 on Linux involves an interactive process. It can't be automated.)

Everyone should be using 1.6 because 1.7 isn't released yet. 1.6 is GPL and open source.
That "interactive" process was clicking on the EULA before it was open sourced. Not that big of a deal then, but it's not even an issue anymore.

The "open source" version of Java is missing large chunks of Java and is basically not at all ready.

Big chunks? The JVM and libs were almost complete. The small parts that couldn't be released were 3rd library implementations that Sun didn't have rights to release as GPL. The GNU Classpath project filled in the gaps almost from day.

So, Java isn't "really" open source. It's "going to be" at some point in the future - or at least it was. With Oracle in control, who knows.

It is open source. Really.

(Sure, Oracle can't un-open source what was released - but since that isn't enough for a full version of Java anyway, it's not like it really matters.)

No, it does matter. Billions of IT dollars are still being spent on projects using the java platform.
I'm sure Oracle would have rather had Sun's implemenation all to themselves, but then they should have bought Sun a couple of years ago.