Slashdot Mirror
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."
The roadmap has previously stated that 1.5 would mark the begining of the switch to Firebird. Doesn't look like we're going to get it until 1.6 at the earliest.
Netscape/AOL is no longer supporting Mozilla, but Mozilla still exists.
The Mozilla Foundation has been set up to manage the project. It's a non profit organisation so you can make a donation to them if you wish.
Also a lot of the developers who worked for Netscape and on the Mozilla project are continuing to work on mozilla still.
Thunderbird 0.2 RC1 is available now (for Windows, other builds should follow shortly). It's had a good size reduction and speed increase.
As opposed to Windows, where downloading a new version of Internet Explorer (6.0) broke every single plugin because Microsoft decided to do so to force people to use ActiveX?
GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
On a related note companion for mozilla has been released in version 0.3.5a. It allows Yahoo bookmarks to be used in mozilla. It is still a little spotty and is best used by eliminating all your yahoo bookmarks and adding them one at a time. Do not add folders more than 3 levels deep.
This is the last bit most of my coworkers need to switch from IE to Mozilla. Next I try to move them to Linux.
More of my thoughts
"To help launch the new organization, America Online has pledged $2 million in cash to the Mozilla Foundation over the next two years. AOL will also contribute additional resources through equipment, domain names and trademarks, and related intellectual property, as well as providing some transitional assistance for key personnel as they move into the new organization."
Looks like AOL is still supporting Mozilla quite a bit. In my eyes this is a good thing for the whole Mozilla project (Firebird, Thunderbird, etc.) as it gives the team more freedom to operate. I can't live without Mozilla Firebird anymore ;)
How about this google bar?
http://googlebar.mozdev.org/
My other car is first.
Version 0.2 was just released for windows today. here's a story on it
"Along that line, are there any good places to look for mozilla/mozilla firebird's CSS2 compliance?"
Very good.. if you don't realize already, IE is terrible with CSS2. Nothing (yet) beats gecko's (mozilla renderer) CSS 1/2 compliance.
The most complete list I'm currently aware of is at macedition check it out here
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.
Version 0.2 was just released for windows today
Actually, it was a release candidate for 0.2. Anyhow, 0.2 is certainly close.
And the last time I used Konqueror, it sucked major ass and couldn't render basic CSS correctly. Ooooh! What does that say about Konq now? NOTHING!
Opera's Javascript implementation has been good for years. The problem is more with doing actual scripting in JavaScript. Internet Explorer and Mozilla both have very different "API"s for DOM scripting. Opera 6 was pretty poor in that regard - didn't render much. Opera 7 renders about 90%, maybe more, of either Mozilla or Internet Explorer's JavaScript, depending on which browser string you send (identify as Internet Explorer and pretty much every IE-specific pages render perfectly)
When identifying as Opera, usually only the most IE-centric pages won't render.
Karma: Could be worse (could be raining)
Actually, if you use both Firebird and Thunderbird, you're increasing the bloat. They both include their own seperate copies of the Gecko core libraries.
If you only use Mozilla for the browser, or only for email, then there isn't a significant difference in memory usage between Mozilla and *bird. *bird will use a little less memory though due to all the features removed from the UI. If you use Mozilla for both browsing and email, then you're actually going to get a large increase in memory usage by using *bird, as you will have seperate copies of the Gecko core for each app.
Firebird starts a little faster than Mozilla, but not as fast as Mozilla with preload turned on. Thunderbird starts noticably slower than Mozilla. Once the apps are started, they all run
The big difference between Mozilla and *bird is the design of the interface. The Mozilla UI is modeled after the Netscape 4.x interface. *bird is modeled after Internet Explorer and Outlook Express. You're also going to need to install a lot of extensions to get all the functionality out of *bird as you can out of Mozilla.
MSIE isn't violating the TCP standard. It's using a feature of HTTP called Keep-Alive. The connections really do exist, even if you're using Apache or any other halfway decent http server.
Mozilla does it too. Check Edit -> Preferences -> Advanced -> HTTP Networking. There's a checkbox for keepalive there.
The sad, sad news is that Firebird and Thunderbird will not made it into 1.5 :-(
In the new roadmap they clearly specified that Firebird in Thunderbird must have been included in 1.5, but then, they patched the roadmap to say that 1.5 will be the standard AppSuite.
I was having high hopes on 1.5, but now, is just another release for me. Meantime, I using Firebird every day and will start using Thunderbird too soon. Since MailNews is my primary mailreader, I want it more support in Thunderbird from mozilla developers before I switch.
Get my e-mail after a captcha test in: http://tinymailt
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.
I think everyone here should know about the most voted for bug in Bugzilla.
In the 1.4 release of Mozilla, the previously complete support for the open MNG image format was removed in order to shave a 100-300 kilobytes from the Mozilla download.
MNG is an extension to PNG, a W3C-backed standard, that adds animation capabilities equal or superior to those in GIF. For example, the Phoenix MNG throbber was about 30 kilobytes smaller and looked far better than any GIF alternative due to alpha transparency and 24-bit colour.
Despite a great reduction in size and optimization of the main library, the authorities have only agreed to put in the MNG-VLC subset back into the 1.5 release.
MNG-VLC is basically useless because it doesn't even support offsets. Putting it back in does not help any of the early MNG adopters at all because their images won't display.
I highly encourage Mozilla maintainers to put the full MNG back in. The code is being actively supported and the feature is something that cutting-edge web developers are eyeing with great enthusiam for eventual adoption.
Note: Further discussion of that particular bug in Bugzilla is discouraged, but every vote helps.;)
Is this a sigs-optional kind of place? 'Cause I am totally down with that if you know what I mean.
You completely misrepresent the facts. MNG support was TEMPORARILY removed from Mozilla because it had been without a maintainer for a long span of time, was terribly buggy, and extremely bloated (300KB just for MNG support). The code was no longer viable. The project now has a new maintainer, and will be remerged when repair work has been completed.
For those that really care, the old code is still available for use in the form of an extension.
No, it's not.
Everything does HTTP keepalives. IE+IIS does something dodgier at the TCP layer where it doesn't send the FIN-ACK to tear down the connection, and can thus skip the SYN at the beginning of the next connection.
Yes, but the linker only does this if they are the EXACT same file; ie, it's based on the inode number. Last I checked, there's no independeantly distributable libgecko.so which moz, thunderbird and firebird can all share, so they all include their own seperate versions, which will NOT be shared at run-time.
I do seem to remember that a splitting out libgecko was part of the 1.0 plan...does anyone know what happened to this (or if my memory is just completely faulty)?
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