If you aren’t familiar with the browser, I would encourage you to visit Deb Richardson’s brilliant Field Guide to Firefox 3 which describes a number of key Firefox 3 features in a very accessible manner.

One thing I would like to mention is that Firefox 3 has improved connection parallelism. The default limit for concurrent connections per hostname has been increased from 2 to 6 which is similar to IE8. Details can be found in this bug report here and for the technically inclined these are the new defaults

pref(“network.http.max-connections”, 30);
pref(“network.http.max-connections-per-server”, 15);
pref(“network.http.max-persistent-connections-per-server”, 6);
pref(“network.http.max-persistent-connections-per-proxy”, 8);

Whilst the improved connection parallelism is one factor in improved page load performance, web server administrators who are currently serving content via Apache need to factor in increased concurrent connections from Firefox 3 and tweak their MaxClients setting appropiately.

If they are using Apache to serve static content, maybe they should consider switching to lighttpd and nginx for serving such content.

Google’s Steve Souder has a great roundup on Parallel Connections in this blog entry.

Terry was a big fan of Firefox from the early days and he took the time to join the SpreadFirefox community. He sported a Firefox button on his page
One of his blog post on the spreadfirefoxsite encourages people to think of 100 million download goal.

He also sent a newsletter to over 150K Hewlett Packard employees where he extolled the virtues of Firefox. In spite of his seniority in the trade press, he took the time and sent me a copy of the PDF he sent to HP employees

Ben’s also written about his upcoming work on making the Extension Manager more robust.

So, the question is ? Is Google working on GForms ?, their secret sauce to the world of AJAX . Would this mythical GForms be close enough to Web Forms 2.0 . Maybe it would be delivered as an easy to install extension.

Google seems to see the value in having a better doorway for their end-users to view their products and I am not sure how Yahoo will react to this. Microsoft ofcourse has IE as its doorway into the future and the upcoming XAML /Avalon to hook the developer base.

They found some improvement in performance (reduction in L1 cache and instruction TLB misses)

The report is available here

The Gnat Nipping at Microsoft
Mozilla may be a tiny nonprofit, but its Firefox browser is grabbing market share

I faxed over a copy of the article to the Mozilla Foundation offices. Ali Ebrahim pointed me to the fax number which isn’t mentioned on the contact page but instead is only available on the CVS contributor form .

Speaking of wireless, in the current Linux 2.6.x kernel (as of 2.6.9), there are now 3 congestion control algorithms available.

• TCP Vegas
• TCP Westwood
• BIC TCP (default as of 2.6.9)

My understanding of TCP Westwood is that it is a sender-side modification of the TCP congestion window algorithm that improves upon the performance of TCP Reno in wired as well as wireless networks.

From the abstract of the ACM-Mobicom 2001 paper I gathered this.

Unlike TCP Reno, it doesn’t blindly halve the congestion window after receiving three duplicate ACK’s. Instead it uses the current effective bandwidth (TCPW continuously measures the TCP source rate) to set a slow start threshold. In wireless links, one could have sporadic losses due to radio problems and TCP Reno would interpret this as congesion which would lead to unneccasary window reduction.

So with a lot of cellphone manufacturers looking at Linux on the cell-phone, will they tune the stack for TCP Westwood. Not sure if other OS’s like Solaris 10 support different congestion control algorithms. Can one set congestion algorithms on a per-route basis ?

Looks like this will be available if Seamonkey/Firefox is compiled with the gcc packaged in Fedora Core 3. Since Solaris 10 build 73 will also come with gcc 3.4.x, I am not sure if it has the same patches which bryner mentions as being required. I’ll try to ping some Sun engineers about this. It could be that Sun’s native compiler (Sun Studio 10) may be doing the right thing

Found this page which describes a bit more about the effect of the symbol visibility patch in GCC.

Thanks to Sun’s crypto team for donating an optimised AMD-64 assembly implementation for the bignum library. Bug 272327 has the details.