Furthermore, how much more efficient would HTTP2 binary be over pipelined, gzip-9 content? If headers are that big of an overhad, why not just a standard compression on headers?
With pipelining, the server still has to return the responses in the order they were requested, which can mean a larger/slower resource holds everything else up. More importantly, pipelining doesn't work well in the real world. Various servers and proxies claim to support HTTP 1.1 but actually don't. So then browsers have to detect if the server they are talking to is broken, or if they are connecting through a broken proxy, and fall back to not pipelining if necessary. Failing to pipeline and falling back is slow, so browsers did things like creating blacklists to avoid trying pipelined connections unsuccessfully. And a browser on a laptop might be behind a broken proxy only some of the time. That is why pipelining-by-default didn't make it out of beta on either Chrome or Firefox, despite some efforts in the past couple of years.
Browsers should be able to be pretty sure that HTTP 2 connections will actually support HTTP 2, and there is no need to workaround, or fix, millions of broken servers and proxies. And they can do things like multiplexing and header compression while they're at it.
"(luckily they've stayed away from horoscopes for now)"
Actually, the Google UK default personalised home page (the link may end up taking you somewhere different if you're not in the UK, I'm not sure) features a horoscope from tarot.com.
"The anti-phishing feature is a primary reason many will be upgrading. If there are problems with it, they may wish to delay their upgrades until a better version has been released."
There seem to be 2 concerns. First is that it may not identify all phishing sites - 1.5 doesn't identify any anyway. I guess you may take the view that if the user has some protection, they may assume they are now safe from phishing and be more trusting than they would be otherwise, but for people that didn't understand it before, any protection is better than none.
The other concern is about URLs being sent to Google - that doesn't happen unless you go in and change the options (and agree to a privacy warning about it).
I don't see that either is a reason to upgrade - if you really don't like it, you can turn it off completely.
It's not that 100% of the computers in universities are running Windows. The statistic is that 100% of universities have at least some computers running Windows.
Given that it's included in most Linux distros, it's maybe surprising that 32% of universities have no computers with Firefox.
"It's not an hourly build, it's a release candidate."
Actually I think Mozilla only described it as a "beta candidate", and that was just in a message on the developer mailing list, and in the ftp server directory name (just Mozilla's server, not the mirror network, hence why they don't the whole world downloading it).
In the really real world, that means that someone thought this version might be ready for release
They thought that this build might be ready to be a beta. The idea being that it would get a bit more "internal" (hard to define what internal is when everything is available to the public all the time) testing before they put it up on the website as a beta.
What should a build that might be released as a beta be called? Or should they just release a random nightly build as a beta without testing a particular build more thoroughly first?
There are hourly builds from the 1.5 branch, the 2.0 branch, and the trunk which will become 3.0, and they are all released to the public in the sense of being available on the ftp server. The source code is available publically all the time from CVS. The defining factor is when they actually announce a "release" as released, and that hasn't happened yet.
Well, it might not be a memory leak, but I'd argue that it is a bug. If I leave my FireFox pointing at a auto-refreshing page for a couple of days it *will* OOM my machine.
That sounds like it is a bug, and a memory leak as well. Next question is whether it's a bug in Firefox, or in a plugin or an extension. If you can do enough diagnosis work to allow a developer to reproduce it or figure out where the code is wrong, then it might actually get fixed.
The fact that you can avoid it by closing the browser occasionally doesn't mean it's not a bug, but it does mean that it's likely to affect less people seriously, and therefore that it's less like to be seen as a priority by many of the core developers. But it is open source, so it could be fixed by someone else...
A change hasn't been implemented in Firefox, and indications were that there wouldn't need to be one.
The founder of Eolas said in eweek (in September 2003): "We have from the beginning had a general policy of providing non-commercial users royalty-free licenses. We expect to be paid for the commercial use of our technologies....We released our browser back in 1995 to the world free for non-commercial use, so that should be an indicator to people that the open-source community shouldn't have anything to fear from us. The extent that those products are used commercially by others or resold commercially, sure we expect to be talking to people who are making money through the use of that technology."
I don't recall seeing anything about Mozilla obtaining a license. I don't know if they have, but maybe if Eolas hasn't pursued them about the patent, they haven't seen a need to do so.
Depends what you mean by successful. Gerv of the Mozilla Foundation looked at last year's projects a few months later, and found that they had died off as soon as the SoC ended. Hopefully this time around the Mozilla folks will be more careful about setting up projects.
I don't think Firefox has had a "silent install" vulnerability yet."
It has had several. The vulnerabilities highlighted in pink on the security advisory page are those that allow remote code execution (some, but not all, of them are only potential remote execution issues that haven't actually been shown to allow execution). For example: Privilege escalation using crypto.generateCRMFRequest.
The fact that Mozilla was "ahead of the game" with some other stuff gave Safari/Opera a headstart on Acid2. There aren't the resources to be ahead of everyone on everything all the time...
There's reason for some people to use it - otherwise who is going to find and fix the bugs, or make the extensions compatible?
But for most users, there is no good reason for them to switch. This will be (it's not actually released yet) a release aimed at developers. In particular, for developers who want to try out the new bookmarks/history back-end stuff.
I certainly can't think of a good reason for posting on slashdot about an alpha release that's not even released yet...
Mozilla Suite and Netscape 7.x did that. The trouble is that the amount of frozen stuff in the libraries isn't enough to build a useful application, so the versions change all the time (in fact they use a date as the version number). Unless your different apps are built from the shared code on pretty much the same day, they'll need different library versions. The advantages of doing it that way then don't outweigh the disadvantages (at least not at the moment - this is being worked on for the future, but it's not the priority you apparently think it should be).
But if you have one big law that prohibits spamming, then everyone (including senders) can be clear about what's allowed and what isn't. If you have laws which apply for particular groups of people (children), or in particular states, or whatever, then you reinforce the message that it's ok to spam people not in those groups (in particular I'd be concerned about the population of the rest of the world who are unlikely to be covered by any specific laws), and you make it far more awkward and expensive for legitimate bulk email senders who would have to comply with a whole collection of various "small" laws rather than one big one.
Identifying people's ages and locations from email addresses requires more effort for the sender and the recipient.
No. There was an issue with some links to things in the British version. That issue has now been resolved, and it's just waiting for the build to get through the rest of the release process - should be out in the next day or two.
Given that the Mozilla folks (the release is managed by the Corporation rather than the Foundation now) are based in the USA, and so will probably be on holiday themselves, I would hope that they've factored that in.
Given their history of optimistic scheduling, and the propensity for last minute problems to pop up when releasing any software, there's certainly a fair chance that the release will be early December rather than late November. Anyway, it'll happen when it happens... anyone in a hurry can use the RC.
They haven't officially announced a date, but they are expecting to release 1.5 final by the end of this month. But of course it depends on feedback from testing RC3, sorting out the publicity stuff, localisations, etc etc.
"half at one co-lo and the other half at another co-lo"
Then they'd either need multi-gigabit bandwidth between the two co-los (which would probably cost for a week what they make per year), or they'd have to make separate, semi-independent communities. Google's servers don't stay in sync - you get different results according to which servers you hit, which isn't something you can do with "live" journals.
Same applies - any donors whose name doesn't appear correctly or doesn't appear at all can get a refund of their donation, and you'll get a free, signed copy of a corrected poster version of the ad.
You need to let them know today though, otherwise your name won't be correct on the "2nd edition" poster either!
Details are on the spread firefox site in this blog post
Slashdot Mirror
Furthermore, how much more efficient would HTTP2 binary be over pipelined, gzip-9 content? If headers are that big of an overhad, why not just a standard compression on headers?
With pipelining, the server still has to return the responses in the order they were requested, which can mean a larger/slower resource holds everything else up. More importantly, pipelining doesn't work well in the real world. Various servers and proxies claim to support HTTP 1.1 but actually don't. So then browsers have to detect if the server they are talking to is broken, or if they are connecting through a broken proxy, and fall back to not pipelining if necessary. Failing to pipeline and falling back is slow, so browsers did things like creating blacklists to avoid trying pipelined connections unsuccessfully. And a browser on a laptop might be behind a broken proxy only some of the time. That is why pipelining-by-default didn't make it out of beta on either Chrome or Firefox, despite some efforts in the past couple of years.
Browsers should be able to be pretty sure that HTTP 2 connections will actually support HTTP 2, and there is no need to workaround, or fix, millions of broken servers and proxies. And they can do things like multiplexing and header compression while they're at it.
"(luckily they've stayed away from horoscopes for now)"
Actually, the Google UK default personalised home page (the link may end up taking you somewhere different if you're not in the UK, I'm not sure) features a horoscope from tarot.com.
"The anti-phishing feature is a primary reason many will be upgrading. If there are problems with it, they may wish to delay their upgrades until a better version has been released."
There seem to be 2 concerns. First is that it may not identify all phishing sites - 1.5 doesn't identify any anyway. I guess you may take the view that if the user has some protection, they may assume they are now safe from phishing and be more trusting than they would be otherwise, but for people that didn't understand it before, any protection is better than none.
The other concern is about URLs being sent to Google - that doesn't happen unless you go in and change the options (and agree to a privacy warning about it).
I don't see that either is a reason to upgrade - if you really don't like it, you can turn it off completely.
You're right, but given that the 2.0 final is actually the exact same build as RC3, it really doesn't matter.
I read somewhere that the plan was for 1700 PDT.
It's not that 100% of the computers in universities are running Windows. The statistic is that 100% of universities have at least some computers running Windows.
Given that it's included in most Linux distros, it's maybe surprising that 32% of universities have no computers with Firefox.
"It's not an hourly build, it's a release candidate."
Actually I think Mozilla only described it as a "beta candidate", and that was just in a message on the developer mailing list, and in the ftp server directory name (just Mozilla's server, not the mirror network, hence why they don't the whole world downloading it).
In the really real world, that means that someone thought this version might be ready for release
They thought that this build might be ready to be a beta. The idea being that it would get a bit more "internal" (hard to define what internal is when everything is available to the public all the time) testing before they put it up on the website as a beta.
What should a build that might be released as a beta be called? Or should they just release a random nightly build as a beta without testing a particular build more thoroughly first?
There are hourly builds from the 1.5 branch, the 2.0 branch, and the trunk which will become 3.0, and they are all released to the public in the sense of being available on the ftp server. The source code is available publically all the time from CVS. The defining factor is when they actually announce a "release" as released, and that hasn't happened yet.
Well, it might not be a memory leak, but I'd argue that it is a bug. If I leave my FireFox pointing at a auto-refreshing page for a couple of days it *will* OOM my machine.
That sounds like it is a bug, and a memory leak as well. Next question is whether it's a bug in Firefox, or in a plugin or an extension. If you can do enough diagnosis work to allow a developer to reproduce it or figure out where the code is wrong, then it might actually get fixed.
The fact that you can avoid it by closing the browser occasionally doesn't mean it's not a bug, but it does mean that it's likely to affect less people seriously, and therefore that it's less like to be seen as a priority by many of the core developers. But it is open source, so it could be fixed by someone else...
Doesn't seem unlikely given that they entered into an agreement with them last year, as reported on Slashdot and elsewhere. The news release about that is on the MySQL site.
A change hasn't been implemented in Firefox, and indications were that there wouldn't need to be one.
The founder of Eolas said in eweek (in September 2003):
"We have from the beginning had a general policy of providing non-commercial users royalty-free licenses. We expect to be paid for the commercial use of our technologies....We released our browser back in 1995 to the world free for non-commercial use, so that should be an indicator to people that the open-source community shouldn't have anything to fear from us. The extent that those products are used commercially by others or resold commercially, sure we expect to be talking to people who are making money through the use of that technology."
I don't recall seeing anything about Mozilla obtaining a license. I don't know if they have, but maybe if Eolas hasn't pursued them about the patent, they haven't seen a need to do so.
Because the downloaded file contains the differences between the binaries, and the updater leaves the rest of the binary file as it was.
See http://wiki.mozilla.org/Software_Update:MAR and http://www.daemonology.net/bsdiff/ for more.
That's being changed. See Ben Goodger's document about Firefox 2.0 and also bug 334767 in bugzilla.mozilla.org.
Depends what you mean by successful. Gerv of the Mozilla Foundation looked at last year's projects a few months later, and found that they had died off as soon as the SoC ended. Hopefully this time around the Mozilla folks will be more careful about setting up projects.
It has had several. The vulnerabilities highlighted in pink on the security advisory page are those that allow remote code execution (some, but not all, of them are only potential remote execution issues that haven't actually been shown to allow execution). For example: Privilege escalation using crypto.generateCRMFRequest.
None. Passing the Acid2 test needs some major reworking of things, which is going to take some time.
The fact that Mozilla was "ahead of the game" with some other stuff gave Safari/Opera a headstart on Acid2. There aren't the resources to be ahead of everyone on everything all the time...
There's reason for some people to use it - otherwise who is going to find and fix the bugs, or make the extensions compatible?
But for most users, there is no good reason for them to switch. This will be (it's not actually released yet) a release aimed at developers. In particular, for developers who want to try out the new bookmarks/history back-end stuff.
I certainly can't think of a good reason for posting on slashdot about an alpha release that's not even released yet...
Mozilla Suite and Netscape 7.x did that. The trouble is that the amount of frozen stuff in the libraries isn't enough to build a useful application, so the versions change all the time (in fact they use a date as the version number). Unless your different apps are built from the shared code on pretty much the same day, they'll need different library versions. The advantages of doing it that way then don't outweigh the disadvantages (at least not at the moment - this is being worked on for the future, but it's not the priority you apparently think it should be).
But if you have one big law that prohibits spamming, then everyone (including senders) can be clear about what's allowed and what isn't. If you have laws which apply for particular groups of people (children), or in particular states, or whatever, then you reinforce the message that it's ok to spam people not in those groups (in particular I'd be concerned about the population of the rest of the world who are unlikely to be covered by any specific laws), and you make it far more awkward and expensive for legitimate bulk email senders who would have to comply with a whole collection of various "small" laws rather than one big one.
Identifying people's ages and locations from email addresses requires more effort for the sender and the recipient.
Really want which build date? The build date on 1.5 is the same as on RC2 - 20051201. It's the same build.
No. There was an issue with some links to things in the British version. That issue has now been resolved, and it's just waiting for the build to get through the rest of the release process - should be out in the next day or two.
Given that the Mozilla folks (the release is managed by the Corporation rather than the Foundation now) are based in the USA, and so will probably be on holiday themselves, I would hope that they've factored that in.
Given their history of optimistic scheduling, and the propensity for last minute problems to pop up when releasing any software, there's certainly a fair chance that the release will be early December rather than late November. Anyway, it'll happen when it happens... anyone in a hurry can use the RC.
They haven't officially announced a date, but they are expecting to release 1.5 final by the end of this month. But of course it depends on feedback from testing RC3, sorting out the publicity stuff, localisations, etc etc.
"half at one co-lo and the other half at another co-lo"
Then they'd either need multi-gigabit bandwidth between the two co-los (which would probably cost for a week what they make per year), or they'd have to make separate, semi-independent communities. Google's servers don't stay in sync - you get different results according to which servers you hit, which isn't something you can do with "live" journals.
Same applies - any donors whose name doesn't appear correctly or doesn't appear at all can get a refund of their donation, and you'll get a free, signed copy of a corrected poster version of the ad.
You need to let them know today though, otherwise your name won't be correct on the "2nd edition" poster either!
Details are on the spread firefox site in this blog post