Malware/phishing protection in Firefox has been essentially unchanged since Firefox 2 received code to do this from Google using their SafeBrowsing service, and Firefox 3.5, 4, 5, 6, 7 and 8 will behave identical, the performance being determined by the Google service.
I don't know of any active efforts inside Mozilla or by the community at large to improve it.
1) The false positive rate of IE is very high. It should be obvious that if you give a lot of false warnings, users will disable or ignore the feature, making it worthless. IE already warns if you download something uncommon, for crying out loud.
2) This "cloud based protection", tracking, among other things, popular downloads, means that info about visited URLs gets sent to Microsoft. There are privacy issues with such a system.
The protocol for doing so has been extended to include malware downloads at some point, and Chrome implements this, but this part of the protocol is not documented, so Firefox (and Safari) don't.
Community driven browsers (without corporate backing) seem to be doing great, eh? The internet is big cutthroat business, these aren't the Phoenix days any more.
I also can't recall any instance of Google being found guilty of abusing a monopoly.
Google has a bunch of lawsuits running against them for antitrust violations in the EU. I think it's silly to think that Google doesn't have a monopoly on search. Whether they're abusing that is another matter. If you surf with IE on Google, I think it continuously slams Chrome ads down your throat. Too much of that behavior can get them in trouble.
As pointed out in several other posts, the Kindle Reader is actually broken because Safari's WebKit lags behind in STANDARDs implementation instead of vendor-specific extensions.
think it's a complete waste of time of Firefox to come out with a mobile browser that only works in like two different handsets!
Defining source code as the standard description tends to backfire incredibly hard if bugs are found. That's why no standardization body accepts it, and generally requires 2 independent implementations of the standard to iron things out.
Furthermore, if you already had a database backend that isn't SQLite (prolly the case for IE, not the case for Firefox) then it's just stupid duplication.
Lastly, I suspect there was no reason to stick with arbitrary current SQLite quirks for a standard that is hoped to endure.
You can scratch the "yet" part. The problem is that they use WebSQL (http://www.w3.org/TR/webdatabase/). Note the big warning "will not be developed further" in the spec.
They should have used IndexedDB (http://caniuse.com/indexeddb), but Safari doesn't support the features it needs yet.
Firefox runs HTML5 just fine. The Kindle app uses Web SQL (never fully standardized, deprecated) instead of IndexedDB (standardized) so it won't work on standards-compliant browsers.
Safari doesn't support the IndexedDB standard, which is why they didn't use that, so your question should be addressed at Safari instead.
I work at a company that has used Git professionally. My team isn't dumb people, but they have fucked up with Git dozens of times. What I quoted is an okay argument at a personal level. However, there is something to be said as an organization that having an easy-to-use tools is better.
Note that I made the argument that git is easier to USE than mercurial, but mercurial is easier to LEARN than git.
I agree with you that tools which are easier to use are to be preferred.
I use both extensively, but getting the equivalent functionality of git in Mercurial means using several extensions, most of which aren't as good as their git originals.
There are three or four branching extensions for mercurial, and none matches what basic git branches do with the same ease of use. It's as if the developers didn't want to admit that git got it right, and so they stopped short of also making something that works.
I believe git is more popular simply because it's *better*. Mercurial's most touted advantage is that it's easier to learn, but this is a joke. If you develop, you interact with the version control system all day. A tiny advantage in learning it faster is nothing compared to not being able what you want to do afterwards, or having to redo something because the version control works against you instead of with you.
The very first lines of the post you're criticizing describe the use case:
I think all they mean is that dram isn't really all that cost effective as a data cache. For data that one intends to export out the network.
Matt's point explained succinctly: SSD speeds are faster than network speeds. SSD cost per Gb is less than RAM cost per Gb. Ergo, SSD are a more cost-effective cache, because the extra speed from RAM is useless.
A firewall clearly doesn't fit the "data that one intends to export out the network" use case.
A pair of mirrored 7200 RPM disk drives with 32 GB of RAM and a warm cache runs circles around your setup. It would also be more reliable, cheaper and provide 10x the storage capacity.
Depends entirely on the workload. The HD drives will lose if:
a) The working set exceeds 32GB. If the accesses are random, they will lose by 2-3 orders of magnitude. b) Whenever there is a need to commit or sync the writes to disk. On a normal system, that will happen every few seconds. If you disable that, your reliability argument is gone.
You have to ask the makers of the devices, but if I have to guess: the flash cells are designed by the top engineers of each fab+their partners and go through very extensive testing and validation cycles. The controllers are a complicated electronic designed for maximum speed by the lowest bidder and rushed to the market, and which additionally has to interact with similarly designed devices.
Human failure will kill the devices way before low-level physics will.
Slashdot Mirror
Malware/phishing protection in Firefox has been essentially unchanged since Firefox 2 received code to do this from Google using their SafeBrowsing service, and Firefox 3.5, 4, 5, 6, 7 and 8 will behave identical, the performance being determined by the Google service.
I don't know of any active efforts inside Mozilla or by the community at large to improve it.
1) The false positive rate of IE is very high. It should be obvious that if you give a lot of false warnings, users will disable or ignore the feature, making it worthless. IE already warns if you download something uncommon, for crying out loud.
2) This "cloud based protection", tracking, among other things, popular downloads, means that info about visited URLs gets sent to Microsoft. There are privacy issues with such a system.
The protocol for doing so has been extended to include malware downloads at some point, and Chrome implements this, but this part of the protocol is not documented, so Firefox (and Safari) don't.
I'm not sure if you realize this, but if you install Adobe Flash nowadays it will also install Chrome and set it as the default.
Without Chrome javascript would still be slow
Jeez, Google's advertising campaigns sure do work. JavaScript performance wars were pretty hot years before Chrome appeared.
http://en.wikipedia.org/wiki/Usage_share_of_web_browsers
Community driven browsers (without corporate backing) seem to be doing great, eh? The internet is big cutthroat business, these aren't the Phoenix days any more.
I also can't recall any instance of Google being found guilty of abusing a monopoly.
Google has a bunch of lawsuits running against them for antitrust violations in the EU. I think it's silly to think that Google doesn't have a monopoly on search. Whether they're abusing that is another matter. If you surf with IE on Google, I think it continuously slams Chrome ads down your throat. Too much of that behavior can get them in trouble.
If we're at the point where the internet is "whatever Webkit renders", we've done something wrong.
Microsoft isn't going to give them a dime
Bing is in the list of default search engines in Firefox, and somehow, I don't think Mozilla puts them there for free.
To assume that all Firefox users would meekly follow Mozilla's direction to use Bing is absurd.
Yes, it's absurd, which is exactly why the line you quote does *not* make that assumption.
The article explains why.
But now it just lags behind Webkit.
As pointed out in several other posts, the Kindle Reader is actually broken because Safari's WebKit lags behind in STANDARDs implementation instead of vendor-specific extensions.
think it's a complete waste of time of Firefox to come out with a mobile browser that only works in like two different handsets!
This is more than 2:
http://www.mozilla.com/en-US/mobile/platforms/
Defining source code as the standard description tends to backfire incredibly hard if bugs are found. That's why no standardization body accepts it, and generally requires 2 independent implementations of the standard to iron things out.
Furthermore, if you already had a database backend that isn't SQLite (prolly the case for IE, not the case for Firefox) then it's just stupid duplication.
Lastly, I suspect there was no reason to stick with arbitrary current SQLite quirks for a standard that is hoped to endure.
You can scratch the "yet" part. The problem is that they use WebSQL (http://www.w3.org/TR/webdatabase/). Note the big warning "will not be developed further" in the spec.
They should have used IndexedDB (http://caniuse.com/indexeddb), but Safari doesn't support the features it needs yet.
Firefox runs HTML5 just fine. The Kindle app uses Web SQL (never fully standardized, deprecated) instead of IndexedDB (standardized) so it won't work on standards-compliant browsers.
Safari doesn't support the IndexedDB standard, which is why they didn't use that, so your question should be addressed at Safari instead.
stolen idea after idea from Opera. Tabs
Tabs were first in Firefox (through an extension). Opera copied the idea from the extension. Pot. Kettle.
I work at a company that has used Git professionally. My team isn't dumb people, but they have fucked up with Git dozens of times. What I quoted is an okay argument at a personal level. However, there is something to be said as an organization that having an easy-to-use tools is better.
Note that I made the argument that git is easier to USE than mercurial, but mercurial is easier to LEARN than git.
I agree with you that tools which are easier to use are to be preferred.
In what way is Mercurial better than git?
I use both extensively, but getting the equivalent functionality of git in Mercurial means using several extensions, most of which aren't as good as their git originals.
There are three or four branching extensions for mercurial, and none matches what basic git branches do with the same ease of use. It's as if the developers didn't want to admit that git got it right, and so they stopped short of also making something that works.
I believe git is more popular simply because it's *better*. Mercurial's most touted advantage is that it's easier to learn, but this is a joke. If you develop, you interact with the version control system all day. A tiny advantage in learning it faster is nothing compared to not being able what you want to do afterwards, or having to redo something because the version control works against you instead of with you.
ReadyBoost has nothing to do with paging.
Woosh!
Hits the sweet spot for what?
The very first lines of the post you're criticizing describe the use case:
I think all they mean is that dram isn't really all that cost effective as a data cache. For data that one intends to export out the network.
Matt's point explained succinctly: SSD speeds are faster than network speeds. SSD cost per Gb is less than RAM cost per Gb. Ergo, SSD are a more cost-effective cache, because the extra speed from RAM is useless.
A firewall clearly doesn't fit the "data that one intends to export out the network" use case.
A pair of mirrored 7200 RPM disk drives with 32 GB of RAM and a warm cache runs circles around your setup. It would also be more reliable, cheaper and provide 10x the storage capacity.
Depends entirely on the workload. The HD drives will lose if:
a) The working set exceeds 32GB. If the accesses are random, they will lose by 2-3 orders of magnitude.
b) Whenever there is a need to commit or sync the writes to disk. On a normal system, that will happen every few seconds. If you disable that, your reliability argument is gone.
You have to ask the makers of the devices, but if I have to guess: the flash cells are designed by the top engineers of each fab+their partners and go through very extensive testing and validation cycles. The controllers are a complicated electronic designed for maximum speed by the lowest bidder and rushed to the market, and which additionally has to interact with similarly designed devices.
Human failure will kill the devices way before low-level physics will.
Sounds like you're saying first-generation NAND controllers are obsolete. Woohoo. Doesn't say much for the technology in general.
People are using Windows on SSD's just fine. Windows 7 actually disables the behavior you speak of on an SSD, anyway.
Most SSD's seem to die from controller failure way before the actual flash cells are dead.
Mod parent up.