While we're all anxiously awaiting the next wonderful app for our wonderful IT's, it is refreshing to see that we are WAY ahead of some folks.

Take, for example, the iPhone user... in my daily email blast from ZDNet the headline story is by Jason O'Grady talking about an iPhone software wishlist.

http://blogs.zdnet.com/Apple/?p=1377&tag=nl.e539

Highlighting, here are some of the apps on the list (with X's to mark added to show were we already have such s/w):

Airfoil for iPhone (I don't know what this is.... do we have it?)
X Blogging client
X Radio client
X RSS reader
X Remote control application
X IM client
X Password manager
X Mileage/MPG calculator
A better Stocks application
X A better Weather application (10-day forecasts, radar, alerts)
Flight tracker (with real-time data from FlightStats.com?)
Package tracker (supporting all major carriers, with alerts)

They want these things, but we already have them!!

I already love my little toy... now I'm feeling even better about choosing it over the slick-looking iPhone/iTouch.

Hooray for Nokia and HOORAY for the amazing developers/users in THIS GROUP.

Cheers,
DF

The iPhone and Touch both have some serious advantages as well, nothing insurmountable, but they are there. I find the browsing experience on those units surprisingly good for such a small screen. I've been tweaking with the prefs.js in my own n810 and have improved the browsing speed a bit, but there are still a few issues.

The main reason that I struggles with the Touch / NIT decision for a while is that it has a full PIM suite that integrates with my Mac. In the end I decided that the ability to tether was far better than any out of the box tools.

Can you share these tweaks? Anything to make browsing speedier on my n810 would be great to have.

This is a work in progress. You will need to apply them by hand/ssh to your own /home/user/.mozilla/microb/prefs.js

It's mostly about slowing down the rendering engine and improving the efficiency of the network connections on such a slow device. It seems quicker to me, but I don't have a large sample to use for comparison.

#changed
user_pref("browser.cache.memory.capacity", 8192);
#added
user_pref("browser.sessionhistory.max_entries", 4);
user_pref("nglayout.initialpaint.delay",2000);
user_pref("content.notify.interval", 1250000);
user_pref("content.notify.ontimer", true);
user_pref("network.http.pipelining", true);
user_pref("network.http.pipelining.maxrequests", 1000);
user_pref("network.http.max-connections", 4);
user_pref("network.http.max-connections-per-server", 4);
user_pref("network.http.max-persistent-connections-per-server", 1);

One thing your improvements do really help is with my Cradlepoint router configuration. It uses javascript to adjust the screen as it reads the configuration information, so the browser previously did a lot of work repainting the entire page for every alteration. It is now much faster (still slow, but not so annoying).

One of the problems with the application manager update parallels this - the apt-worker or something tries to open 16 or more connections (if you've added archives) for updates, and this causes a lot of thrashing, so instead of being faster, it runs several times slower.

The impedance match for a laptop or desktop is different since the CPU and video usually are waiting for the next TCP packet even on a fast link. For a tablet, the CPU won't be the bottleneck, but it will take a while to render any complex page, so doing it too often, especially when only a little more of the page has come down, is counterproductive.

(There are ways of tuning individual applications - my zmapper redraws every road in a 20 square mile area in less than 1/2 a second so can keep up with a 5hz GPS at slightly higher magnifications, but I optimized it like for the old 8 bit embedded processors, and many of the techniques were tuning the update v.s. rendering)

Thanks for the feedback. When I saw the defaults I immediately saw that it was a real mismatch for the unit especially since both network connections and rendering can swamp the CPU. I still think there is a lot that can be done, but many will have to be done at the OS level. I will start tackling the sysctl variables to see if we can get some more advantages there.

Enjoy that list while we still can, because the SDK is out now...