Mozilla 1.5 Beta Released
asa writes "Today mozilla.org released Mozilla 1.5 Beta, available for Linux,
Mac OS X, and Windows. This beta release features lots of bugfixes, the inclusion of a spellchecker for Messenger and Composer, and lots of minor feature improvements to Navigator, Messenger, Composer and Chatzilla. More information is available at the Mozilla Release Notes."
Version 0.2 was just released for windows today. here's a story on it
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4b) Gecko/20030516 Mozilla Firebird/0.6
/proc/cpuinfo
...
$ cat
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 5
model name : Pentium II (Deschutes)
stepping : 2
cpu MHz : 348.491
Startup time < 5s
They are colored in Composer. (The tool for creating webpages) So, you are in fact stupid. =) j.k.
Here is a neat mozilla trick.
1) Set google as your default search.
2) Highlight any word on a page and right click.
3) Choose web search for "Word I Just Highlighted"
Voila a google search.
BTW moz1.5 has a spell checker and 1.4 users can install one here
Mozilla has so many ways to have fun there is never any need to use IE. Have you played around with profiles yet?
War is necrophilia.
browser.enable_automatic_image_resizing = false
viola.
bananas like monkeys.
MSIE actually does break TCP/IP. Here's some links from an old slashdot story.
... Sometimes
It's not "HTTP - Keep-Alive" which is similar. The difference is that Keep-Alive doesn't close a connection between files which is fine. IE on the other hand make a request without creating a connection (Like UDP) and at the end doesn't close it. This makes IIS faster (less overhead) but other servers slower as the broswer times out before it gets the page and the server has to time out before it closes the connection.
Why IE Is So Fast
Article it linked to
Summary:
this isn't the same deal. based on the TCP specs, here is what a server (or client, for that matter) is supposed to do when it wants to close the connection: 1) send FIN 2) wait for ACK 3) wait for FIN 4) send an ACK if the server never receives the FIN in step 3, it assumes that the client wants to keep the connection open for some reason. this is _correct behaviour_ with regards to the TCP spec. if this article is correct, MS is merely exploiting the TCP spec to its advantage. yes, it's dirty and wastes resources, but it works. the thing that bothers me tho, is this is what should be happening on the server end (a non-IIS server, that is): 1) send FIN 2) wait for ACK 3) ok, got ACK, now wait for FIN 4) (after timeout) hmm, no FIN, must have been lost, so we'll resend our FIN 5) client ACKs that FIN, but doesn't send its FIN 6) server thinks the response FIN is lost again, so probably resends its FIN