>I'm guessing it did that because you submitted incorrect HTML
But I didn't submit the comment as HTML, I submitted it as "Plain Old Text", and I put the URLs in as plaintext (no A tags around them). It was Slashdot that linkified the URLs for me, and I would expect Slashdot to escape all <, >, and & in my text--rather than interpreting it--if I submit a comment as plaintext. Otherwise what's the point of having both "Plain Old Text" and "HTML Formatted" options?
Just because ftp.mozilla.org is a roundrobin with several servers doesn't mean it should be able to handle the load. It has roughly 1Gb of capacity, so it can handle about that much load and no more. releases.mozilla.org has 7-9Gb of capacity, so it can handle much more load. And our redirector has 15-19Gb of capacity, so it can handle the most load of all.
Firefox 1.5 has now been officially released, so the best thing to do is go to http://www.mozilla.com/ and download it from there. That'll use the redirector, so you have the best chance of getting it fast without overloading the download servers.
Hmm, it looks like Slashdot stripped the &lang from these URLs. The correct URLs (in HTML mode this time with me escaping the ampersands) to get Firefox 1.5 from our redirector (which has the most bandwidth and thus is the most likely to get you the file fast) are:
But the version in RC3 is the same as the version in final. If you don't believe me, check it yourself. I have both, and Help -> About Mozilla Firefox on either one pops up a dialog box that calls it "Firefox version 1.5" and has the User Agent string "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20051111 Firefox/1.5".
That's right, we didn't even change the version string. Why? Because had we changed the version string, we would have run the risk of making some mistake in the process of making the change that creates a problem in the final that wasn't there in the RC. By not making any changes, we ensure that the final version all users get is exactly the same as the RC our testers tested.
Note that Firefox 1.5 RC3 is the exact same as Firefox 1.5 down to every last bit. So if you already have RC3, you already have the final release. You don't need to download it again.
Why? Well, because RC3 was the last release candidate, and having the last release candidate be exactly the same as the final release is the best way to ensure that all the testing the release candidate gets definitely applies to the final. Otherwise we would have run the risk of any change, no matter how minor, introducing a problem that we didn't foresee.
So they're the same. Right down to the user agent string, the version number, etc. Do an md5sum on both files, and you'll get the same values. You get my drift.
Or, if you need a different language, get it from releases.mozilla.org, which doesn't have as much bandwidth as the redirector but still has *much* more than ftp.mozilla.org:
I think an organization that almost always does the right thing, owns up to errors, and makes changes to ensure those errors never recur is competent, yes. I'd much rather trust an organization like that than one which claims to be perfect.
You should trust the foundation's competency because they almost always stay up-to-date with the latest security updates to all installed software and because they are revising their security plan and procedures to make ensure that this lapse in the application of security updates does not recur.
That's correct, the intruders can have acquired only MD5 hashed passwords; they cannot have acquired plaintext passwords, so users who used strong passwords are safer than users who used weak passwords.
(I am a foundation employee, but I am now speaking for myself, not for the foundation.)
You should trust our competency because we almost always stay up-to-date with the latest security updates to all installed software and because we're revising our security plan and procedures to seal up the cracks that this particular software update fell through.
Actually, it is the case. Drupal, the CMS that Spread Firefox uses, stores passwords in MD5 hashed format. Nevertheless, hashing a password is not 100% safe, since weak hashed passwords are susceptible to brute force attacks, so we thought it wise to notify users and recommend they change their passwords.
I'm a foundation employee and the guy who wrote the message we sent to Spread Firefox users. A few notes:
Spread Firefox does not store plaintext passwords; it hashes them using MD5. So if the attackers have obtained the passwords, they cannot easily use them to gain access to user accounts. Nevertheless, since weak hashed passwords are susceptible to brute force attacks, there is some risk from the exposure, and that is why we recommended users change their passwords.
Lately i've been seeing a lot of such offers that say "or buy one at regular price," although admittedly not in grocery stores (I tend not to shop at the ones that require cards).
The primary issue with the proprietary platform-specific toolkits is that they would have required rewriting the application for each one, but the secondary issue is that they just didn't support the necessary extensibility. Even if they had, however, Mozilla probably wouldn't have used them, since many of its engineers had had years of experience with the problems of that approach from the Netscape days and wanted to avoid them.
Mozilla chose to create XUL because it was the fastest, easiest way at the time (early 1998) to get a cross-platform, open-source toolkit with all the functionality necessary to support the emerging CSS standards. Although Mozilla took a long time to complete, and there were undoubtably mistakes made along the way that prolonged that period of time, since its completion it has been hailed as the best browser suite on any platform, and we now have a fundamentally sound architecture on which to build the next generation of browsers and network-aware applications. The future is bright, and it's getting brighter.
>We've implemented the stylability in Qt. I don't see that doing so in other toolkits would be a problem.
It is a problem for proprietary toolkits like those on Windows and Mac, and at the time Mozilla made the decision there were no appropriate cross-platform toolkits available.
>The key word in your comment is 'browser' that is what the mozilla project seemed to set out to write.
Actually, as far as I know the Mozilla project always intended to release a full application suite including web browser, email client and web page editor. The project started, after all, with the release of source code from Netscape, which was at that time focused on such a suite.
>I suspect that if the project had reused existing toolkits etc. it could have got there much more quickly.
Maybe, but Mozilla needed a toolkit anyway for web forms/content since existing toolkits didn't support the stylability required by the W3C standards. The engineers who built that new toolkit decided to use it to build the application itself to save the time of rewriting Mozilla for each OS. Given the necessity of creating the toolkit anyway, that decision ended up saving more time than it cost.
Mozilla has received numerous awards and critical acclaim since releasing its first stable version last year. We've had Infoworld and PC World give us Best of 2003 awards; eWeek say "Mozilla is the best browser on the market"; and just got an editor's choice award from LinuxJournal magazine. All of these are clear indications that the Mozilla project is doing something very right.
The Mozilla project didn't just build a browser. It also developed a powerful mail client, a web page composer, and a platform for innovative application development that includes an GUI toolkit, a comprehensive set of APIs including world-class networking for innovative networked applications, and multi-OS support (Windows, Mac, and many flavors of *nix). This platform has been used to build IDEs, weblog readers, and even entire desktop environments.
I believe their mailing lists/newsgroups were having problems because of a DOS attack. From what I hear, they are being set back up. More info is available in the project owners mailing list archives.
Slashdot Mirror
Unfortunately, I had to touch too much of the core Thunderbird code that it would be quite hard to make the patch into an extension.
If you have RC3, then yes, I am trying to tell you that you have the exact same version as the new version.
>I'm guessing it did that because you submitted incorrect HTML
But I didn't submit the comment as HTML, I submitted it as "Plain Old Text", and I put the URLs in as plaintext (no A tags around them). It was Slashdot that linkified the URLs for me, and I would expect Slashdot to escape all <, >, and & in my text--rather than interpreting it--if I submit a comment as plaintext. Otherwise what's the point of having both "Plain Old Text" and "HTML Formatted" options?
Just because ftp.mozilla.org is a roundrobin with several servers doesn't mean it should be able to handle the load. It has roughly 1Gb of capacity, so it can handle about that much load and no more. releases.mozilla.org has 7-9Gb of capacity, so it can handle much more load. And our redirector has 15-19Gb of capacity, so it can handle the most load of all.
Firefox 1.5 has now been officially released, so the best thing to do is go to http://www.mozilla.com/ and download it from there. That'll use the redirector, so you have the best chance of getting it fast without overloading the download servers.
Yeah, the links got screwed up. See this comment for the correct links:
1 42440
http://slashdot.org/comments.pl?sid=169676&cid=14
Hmm, it looks like Slashdot stripped the &lang from these URLs. The correct URLs (in HTML mode this time with me escaping the ampersands) to get Firefox 1.5 from our redirector (which has the most bandwidth and thus is the most likely to get you the file fast) are:
WindowsMac OS X
Linux
But the version in RC3 is the same as the version in final. If you don't believe me, check it yourself. I have both, and Help -> About Mozilla Firefox on either one pops up a dialog box that calls it "Firefox version 1.5" and has the User Agent string "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20051111 Firefox/1.5".
That's right, we didn't even change the version string. Why? Because had we changed the version string, we would have run the risk of making some mistake in the process of making the change that creates a problem in the final that wasn't there in the RC. By not making any changes, we ensure that the final version all users get is exactly the same as the RC our testers tested.
Note that Firefox 1.5 RC3 is the exact same as Firefox 1.5 down to every last bit. So if you already have RC3, you already have the final release. You don't need to download it again.
Why? Well, because RC3 was the last release candidate, and having the last release candidate be exactly the same as the final release is the best way to ensure that all the testing the release candidate gets definitely applies to the final. Otherwise we would have run the risk of any change, no matter how minor, introducing a problem that we didn't foresee.
So they're the same. Right down to the user agent string, the version number, etc. Do an md5sum on both files, and you'll get the same values. You get my drift.
Please do *NOT* download it from ftp.mozilla.org. Please instead use our redirector, which has a lot more bandwidth:
o s=win&lang=en-USo s=osx&lang=en-USo s=linux&lang=en-US
o x/releases/1.5/
Windows: http://download.mozilla.org/?product=firefox-1.5&
Mac OS X: http://download.mozilla.org/?product=firefox-1.5&
Linux: http://download.mozilla.org/?product=firefox-1.5&
Or, if you need a different language, get it from releases.mozilla.org, which doesn't have as much bandwidth as the redirector but still has *much* more than ftp.mozilla.org:
http://releases.mozilla.org/pub/mozilla.org/firef
I think an organization that almost always does the right thing, owns up to errors, and makes changes to ensure those errors never recur is competent, yes. I'd much rather trust an organization like that than one which claims to be perfect.
You should trust the foundation's competency because they almost always stay up-to-date with the latest security updates to all installed software and because they are revising their security plan and procedures to make ensure that this lapse in the application of security updates does not recur.
That's correct, the intruders can have acquired only MD5 hashed passwords; they cannot have acquired plaintext passwords, so users who used strong passwords are safer than users who used weak passwords.
(I am a foundation employee, but I am now speaking for myself, not for the foundation.)
You should trust our competency because we almost always stay up-to-date with the latest security updates to all installed software and because we're revising our security plan and procedures to seal up the cracks that this particular software update fell through.
Actually, it is the case. Drupal, the CMS that Spread Firefox uses, stores passwords in MD5 hashed format. Nevertheless, hashing a password is not 100% safe, since weak hashed passwords are susceptible to brute force attacks, so we thought it wise to notify users and recommend they change their passwords.
That's right, the site stores passwords as MD5 hashes. It does not store them as plaintext.
I'm a foundation employee and the guy who wrote the message we sent to Spread Firefox users. A few notes:
Lately i've been seeing a lot of such offers that say "or buy one at regular price," although admittedly not in grocery stores (I tend not to shop at the ones that require cards).
... since you often ending buying more (buy 12, get 12 free!) and then throwing it away because it goes bad or you're just sick of eating it.
The primary issue with the proprietary platform-specific toolkits is that they would have required rewriting the application for each one, but the secondary issue is that they just didn't support the necessary extensibility. Even if they had, however, Mozilla probably wouldn't have used them, since many of its engineers had had years of experience with the problems of that approach from the Netscape days and wanted to avoid them.
Mozilla chose to create XUL because it was the fastest, easiest way at the time (early 1998) to get a cross-platform, open-source toolkit with all the functionality necessary to support the emerging CSS standards. Although Mozilla took a long time to complete, and there were undoubtably mistakes made along the way that prolonged that period of time, since its completion it has been hailed as the best browser suite on any platform, and we now have a fundamentally sound architecture on which to build the next generation of browsers and network-aware applications. The future is bright, and it's getting brighter.
>We've implemented the stylability in Qt. I don't see that doing so in other toolkits would be a problem.
It is a problem for proprietary toolkits like those on Windows and Mac, and at the time Mozilla made the decision there were no appropriate cross-platform toolkits available.
>The key word in your comment is 'browser' that is what the mozilla project seemed to set out to write.
Actually, as far as I know the Mozilla project always intended to release a full application suite including web browser, email client and web page editor. The project started, after all, with the release of source code from Netscape, which was at that time focused on such a suite.
>I suspect that if the project had reused existing toolkits etc. it could have got there much more quickly.
Maybe, but Mozilla needed a toolkit anyway for web forms/content since existing toolkits didn't support the stylability required by the W3C standards. The engineers who built that new toolkit decided to use it to build the application itself to save the time of rewriting Mozilla for each OS. Given the necessity of creating the toolkit anyway, that decision ended up saving more time than it cost.
Mozilla has received numerous awards and critical acclaim since releasing its first stable version last year. We've had Infoworld and PC World give us Best of 2003 awards; eWeek say "Mozilla is the best browser on the market"; and just got an editor's choice award from LinuxJournal magazine. All of these are clear indications that the Mozilla project is doing something very right.
The Mozilla project didn't just build a browser. It also developed a powerful mail client, a web page composer, and a platform for innovative application development that includes an GUI toolkit, a comprehensive set of APIs including world-class networking for innovative networked applications, and multi-OS support (Windows, Mac, and many flavors of *nix). This platform has been used to build IDEs, weblog readers, and even entire desktop environments.
I believe their mailing lists/newsgroups were having problems because of a DOS attack. From what I hear, they are being set back up. More info is available in the project owners mailing list archives.