Just received an unsolicited commercial email from them advertising this new site (what's that other term for these again?) It went to one of our support accounts...the kind that wouldn't be found unless one were to skim a web site for email addresses.

The unsubscribe link from this invitation to join requires that I first "log into my account". The email is an invitation to join.

From a technical perspective, I'm impressed by both platforms.

Be aware however that deployment of iOS applications to the general public may only be done with Apple's approval of your specific application. And unless you are targeting jailbroken phones, all revenue must pass through Apple. They may choose to reject an app for reasons stated in their developer agreement, or for unstated reasons: http://www.macworld.com/article/151680/2010/06/myframe_rejection.html

The Android market's terms are more lenient than Apple's, and the Android market does not have a formal approval process of any kind. Apps may however be removed for violations of the Android Market developer agreement.

But even then, Android phones allow the installation of apps from sources other than the Android market.

First, please beware that I barely qualify as a layman when it comes to knowledge of cellular networks and/or RF transmission.

If I recall correctly though, the transmitting power used by a cellular phone is inversely proportionate to the proximity of a tower. That is, if the tower is far away and more difficult to reach, the phone will use more transmitting power.

So from a radiation perspective, is it safer to have towers located far away at the expense of having our cell phones constantly running at maximum power mere inches from our reproductive organs or brains?

This is a very impressive evolution. Thinner, better display, more processing power, better battery life, better camera, new sensors, and more capabilities across the board, both hardware and software.

I'd love to develop for it.

I just wish there was some way I could know that if I spent thousands of hours creating software for it, that such software would continually be available for purchase via the App Store. I'd be okay with explaining in detail to Apple how the software was going to work before developing it. But it would be necessary to obtain an authoritative answer to inform as to whether the software would be accepted (if implemented to a proposed specification) and for what minimum duration the software would be allowed on the store.

There is a fundamental risk in developing new software: "Will customers buy this?" This risk can be calculated to a certain extent. My concern with developing for iOS is that an additional incalculable risk exists, and it is simply too much to bear.

I can't stand hearing everyone talk about multitasking on things like Android devices as though it works the same way as it does on their desktop PC. Nothing could be further from the truth.

The first form of multitasking on Android is that applications can elect to receive messages, e.g. "someone is calling", or "wifi state changed".

If you actually need to do constant work in the background (e.g., listening on a network port), you can do so as well, using a "service". And even services will be killed by the system if resources are needed.

No one is talking about running a Handbrake encode session, Firefox with a bunch of animated Flash ads, and a kernel compile at the same time on their phone.

Multitasking on a phone is being able to record breadcrumbs of a journey with a GPS app, listen to streaming internet radio, and receive notifications from an instant messaging client at the same time.

If I open Google Chrome and Mozilla Firefox, with a few tabs active in each on popular sites, the entirety of both cores of my Intel E7500 CPU will be consumed by Flash advertisements.

I'm on a Linux machine with a lot of memory, which makes for the worst case scenario: First, Flash is horrible on Linux. Second, I use virtual desktops and leave browsers open for days at a time. Memory is not a problem.

Flash ads tend to be poorly written by a creative designer who could give a rat's rear end about your system resources.

The ads interfere with my ability to work, which costs me money. They also cause my computer to consume significantly more power. So in effect, your Flash ads are even bad for the environment.

They're also of course quite annoying, and if given only the options of browsing the internet with Flash ads or not browsing the internet at all, I'll choose the latter.

How about you try this experiment: Turn off Flash ads. Post a banner at the top of your site that says, "Hey, we've turned off Flash ads. Please exclude this site from your ad blocker so we can make money."

Love the new UI, and really appreciate the option of another well done browser. But they still refuse to fix a trivial CSS bug which has horrible consequences for AJAX apps.

Just go to this page, and resize your browser with the vertical (not horizontal) handle.
http://echo.nextapp.com/content/test/operacss/

(This is very hard/impossible to do on a mac, as they don't really have one).

Unfortunately the bug is not limited to resizing with the vertical handle...it manifests itself in other ways. It seems the browser is incorrectly measuring/reporting the vertical size of elements, and sometimes uses this data internally (as in the case of this test).

Full thread is here:
http://my.opera.com/community/forums/topic.dml?id=250572

And one of the Ajax apps that experiences more serious failures as a result: http://demo.nextapp.com/

Yes, Android currently only lets you install application packages on internal memory. Application developers know this, so there's a major effort made to keep the application footprint small, and then have the applications download and store additional resources on the SD card, which has no such limitations. As an example, a game would store its levels/media on the SD card. Or in the case of an offline GPS app, the map data would be stored on the SD card.

With my Droid, I've yet to get anywhere close to this limitation, and I'm always on the hunt for neat apps on the market. I currently have 162MB free (I believe it originally had 250MB available).

Yes, it's not inconceivable that you'll run into this limitation, but at the same time, it doesn't come up all that often. Don't be concerned that your iPhone is using 3GB for app storage...on an Android device those apps would be putting 95% of their data on the SD card.

I made a webapp in early 2001 that used both AJAX (with a hidden frame for client-server communication, rather than an XHR) and a Java applet. It was used to create presentations from within a web browser. The Java applet was used for laying out a presentation slide, providing the user with the capability to create/position elements of the presentation (text, images, and so forth). The app was operational more than a year before the filing date of US7599985.

The application made use of Netscape's LiveConnect (an old Java/JavaScript communication API) to do this. LiveConnect was introduced in 1997, with Netscape 4. As far as I can see, LiveConnect was designed to enable what this patent claims to invent.

See http://en.wikipedia.org/wiki/LiveConnect and http://en.wikipedia.org/wiki/Netscape_Navigator

I reported this about a year ago. Create a simple page, with two absolute positioned DIVs, nested one inside the other. Resize the browser vertically (but not horizontally). Watch as the DIVs are no longer positioned according to your specification.

My example: http://echo.nextapp.com/content/test/operacss/

The consequences get a bit more catastrophic with applications with larger quantities of nested DIVs. Things really start to break when you start measuring using Element.offsetHeight.

Apologies for posting it here...again...but I'm tired of replying to users who ask "why does component X not render properly in Opera, it passes Acid3 thus something must be wrong with the component."

In Ubuntu 9.04 here, and I personally think the stock DejaVu fonts on Linux look quite nice. Actually prefer the traditional toolbar on Linux with Tango icons (tango.freedesktop.org) rather than the "enlarged back button" version found on Windows and OSX.

The only problem I see is the topic of this thread, i.e., performance. It's slow enough to feel slow, and the fact that most Linux distros run so well on old hardware makes the problem worse.

The bigger problem for the "Linux browsing experience" still seems to be Flash. Visiting a Flash-heavy site (like the horrible items produced by any given automaker) is a painful experience...it's bad enough that I'll typically crack open the MacBook. I find Flash sites consume an order of magnitude more CPU running natively in a Linux browser than they do running in a Windows XP VirtualBox instance hosted by the same Linux OS.

AdBlockPlus and FlashBlock are the only things that enable me to continue to use this computer for web browsing. It's somewhat of a sad state of affairs, given that it's more than quick enough to run multiple VirtualBox instances, Eclipse instances, and a GIMP instance with dozens of files open at the same time. But give it one web page with a few Flash advertisements, and you'll think you're on a Pentium 60.

It may be ACID3 compliant, but it still can't correctly render two nested DIVs:

http://my.opera.com/community/forums/topic.dml?id=250572

To see it fail, just go to this page in Opera 10: http://echo.nextapp.com/content/test/operacss/ , and resize your browser vertically (but NOT horizontally). It's been reported in the bugtracker, forums, forum PMs to developers, etc..

So please, when you file that bug report today that "Opera 10 doesn't render things correctly" to whatever your AJAX framework of choice happens to be, don't make a big deal out of the fact that it's "Acid3 compliant" and thus the AJAX framework developers must be in the wrong.

Good to hear it's still the case. This is what I've been told by other MS folks working on the problem. My concern is not about this bug, but rather the fact that IE8 RC1 had quite a few major flaws in it, yet there will be no RC2. With a product as influential as Internet Explorer, you need to wait until your release candidates are reasonably well accepted by the public before you fire the final.

As a software developer, I find that when you ship a really buggy alpha version (or beta/RC), all you're going to get as feedback are the truly GLARING bug reports. If you want to get the edge cases, you've got to release something that's polished enough for people to spend time using. IE8 hasn't done that yet.

The stock W7 IE8 build is unaffected. It's between beta2 and RC1 though.

As a developer of an AJAX-based web framework, I'm upset to see IE8 being thrown out the door so quickly. RC1 was nothing short of a disaster: it had a performance bug where nesting absolute-positioned DIVs would result in exponential performance decreases.

Test case here: http://echo.nextapp.com/content/test/ie8/

The 25-nested DIV test would require killing the browser. Nesting absolutely positioned DIVs is somewhat fundamental to delivering application-style user interface layouts in a web browser.

I reported this bug everywhere I could, and Microsoft actually did a great job in responding to it. They say they've found it and fixed it. But there is no way for us to test this. We must simply take their word for it and wait. They're going from RC1 to final, and begging and pleading for an interim build didn't warrant much of a response.

From reading forums (e.g. Ajaxian: http://ajaxian.com/archives/push-back-digital-tv-or-ie-8), my IE8 experience is not uncommon with other web frameworks as well. The average developer's opinion there suggests RC1 is nowhere near ready for a final release. Every build of IE8 (beta1, beta2, win 7's "beta2+", and the RC) have each had major unique problems not found in other releases.

I have developers asking me if their software will work in IE8 on day 1 and the only honest answer is "I have absolutely no idea." Anyone (without a final build) who tells you otherwise, even offerring a rough estimate, is a liar, IMHO.

I don't understand the point of putting out a "release candidate" and then not using feedback to determine whether the next release is a "candidate" or a "final". Our bug alone means that IE8 RC1 has never been publicly tested with many complex web-based applications.