1) There was a guy living around that time who did some preaching and had a following.
2) This guy performed miracles and such.
You're arguing that because #2 is highly unlikely and has no evidence for it that means that #1 is also highly unlikely and has no evidence for it. That's a logical fallacy. You may want to read http://armariummagnus.blogspot.com/2011/05/nailed-ten-christian-myths-that-show.html for a slightly longer discussion of the subject, but the short story is that Occam's razor suggests #1 is probably true, while #2 is probably false.
Key to this argument is the "flat" part of the roof description. If your roof is peaked, then your angle of incidence for sunlight can be quite different from that 30 degrees (it can be up to "30 + the roof angle", depending on the orientation of the roof).
"flat" describes most large building roofs, but not most residential roofs. Of course he latter are what most of the commenters on this thread are talking about.... but not what Mr. Clinton is talking about.
There's nothing to say about the others, since there are release builds of 64-bit for Linux starting with Firefox 4 and since Mac defaults to 64-bit starting with Firefox 4 on Mac OS X 10.6 and later.
So Windows is the only one of the three that _doesn't_ have supported 64-bit builds yet.
Not all of them. For example, it doesn't have the plug-in issues, because it's a fat binary with both 32-bit and 64-bit executables, and the plug-ins are loaded into a 32-bit process.
Your second point doesn't make that much sense....
32-bit Firefox already uses 64-bit values (basically a union of a double and an unsigned long long) to store its JS values. Going to 64-bit actually makes this _harder_ because your pointers might not be distinguishable from a double. That's dealt with on x86-64 by exploiting the fact that it's really a 47-bit address space, but that causes some additional complexity and masking slowdown, so the JS folks have been considering moving to 128-bit values when running on x86-64. This would incidentally also work on 64-bit architectures with a 64-bit address space (e.g. sparc64).
The whole reason for nspluginwrapper is that you're using a 64-bit build but your plug-ins are 32-bit.
That is _exactly_ one of the reasons that Firefox is not shipping 64-bit on Windows yet (what the article is about).
So no, the only way to get rid of nspluginwrapper is to either use a 32-bit browser or not use 32-bit plug-ins. Well, or do something like Firefox on Mac, which involves shipping two copies of the code so the plugin-container process can be 32-bit...
You get faster code if your code is under a lot of register pressure because you're doing computations with a bunch of reusable intermediate results, etc.
You get slower code if your code is memory-bound, especially if pointer-chasing is involved (because you blow out your caches more easily and end up having to actually talk to RAM more).
Which one matters more for a web browser is a tough question. For example, most operations on the DOM are of the pointer-chasing variety.
One major problem with moving to 64 bit is that NPAPI plug-ins (e.g. Flash) are just dynamically linked libraries. Which means they need to be compiled for the same architecture as the process they're loaded into. Which means that process needs to be a 32-bit process if you want to use the plug-ins that are out there now. That's changing, albeit slowly.
Firefox solves this on Mac by in fact shipping a fat binary with both the 32-bit and 64-bit builds in it and using the 32-bit one as the plugin container process. But Windows doesn't have native fat binary support like that, and doubling the size of the Windows install package has its own share of issues. It's all doable, of course, but there are definitely drawbacks to switching to 64-bit so far. The question is whether the costs outweigh them.
Man. "Phone company can't properly apply a payment to an account" was definitely in the "reasons beyond me" bucket... and I'm sorry you had to deal with it.:(
1) This whole article is in fact about the fact that it's a fraud. That's what makes them "mysterious" and "illegitimate": they're bills for services that were never provided.
2) A typical US phone bill that does not have any of these charges on it (so just a normal bill) has a dozen or more line items with names designed to be as obscure as possible. Not only that, but in many cases these change from month to month (both the total bill amount and the exact itemization). As a result, it's actually easy to miss a $1 charge that shouldn't be there unless you're _very_ carefully reading the bill every month. Which most people don't.
3) For reasons that are beyond me, many people have their phone bills set up to auto-pay (basically have the phone company just withdraw the money from the user's bank account). So in that case there is no cheque being written. The payment just happens; you get sent a bill (or an e-mail that you can look at the bill online, if the phone company's incessant attempts to get you to go paperless succeeded).
So the deck is stacked against people noticing the problem. If they _do_ notice it, they have to decide whether they want to spend several hours on the phone trying to get rid of the charge or just pay it and move on. I bet in many cases people do the latter.
Because I'm also not using an @gmail.com address, of course. I can do that with a non-webmail client. But there's no way to do that with webmail, obviously.
The 32/64-bit situation for Mozilla right now is the following:
Linux: both 32-bit and 64-bit builds are available and supported starting with Firefox 4. Default download is probably 32-bit.
Mac: On 10.6+, the browser runs 64-bit by default and the plug-in process runs 32-bit. On 10.5, both run 32-bit due to OS-level bugs in 64-bit support.
Windows: Only 32-bit builds are supported. 64-bit builds exist, but are somewhat buggy. Shipping them involves fixing those bugs and addressing the issue about not being able to run 32-bit plug-ins in a 64-bit browser. On Mac, if you noticed, the solution is to use the built-in support for fat binaries and just ship both sets of code, using the 32-bit code for the plug-in process and 64-bit for the rest of the browser. Windows doesn't have such built-in support, so a similar solution would require some nontrivial work (and would of course about double the download size, unless the plug-in process stops being a copy of all of Gecko).
So long story short, 64-bit on Windows will happen, but it's not as simple as "flip the compiler switch".
Actually, Quartz might end up getting used as a backend for the Gecko-internal Azure API on Mac at least for a bit (just like Direct2D will be on Windows). See http://blog.mozilla.com/joe/2011/04/26/introducing-the-azure-project/ for some discussion of the tradeoffs here. There's some discussion about why it might be preferable to use a GL backend instead of Quartz on Mac (long story short, a GL backend is needed anyway for Linux and Android, and at that point it might make more sense to use it on Mac too so you don't have to maintain separate Quartz code).
> that a piece of native runtime plugin code can do > as well
Because in some environments you can't drop in native runtime plugin code.
Or put another way, where's that 64-bit Flash for Linux? Or heck, for that new architecture that people will come up with tomorrow?
Whereas this way porting a web browser (a must for a new consumer-facing architecture anyway) will get you a PDF renderer for free.
> 'Plugin' is just a word, it doesn't need to be > insecure, alien, buggy
A PDF-renderer plug-in can be secure and non-buggy if you spend enough resources on it. No one has done that yet. This project aims to get "secure and non-buggy" with less developer time invested.
> If anything, Pdf.js will be suitable where and when > energy and resource conservation isn't a factor.
Or where reducing the security exposure is important.
> As for me, I prefer to avoid all the extra layers of > abstractions
Within reason, yes? Or do you hand-code everything in assembly (or directly implement on FPGAs, even)?
The only question is _where_ the tradeoff lies.
> what is this gold that is Pdf.js
Think "a way to render PDFs in a browser without adding any new security bugs and without spending a few man-decades developing it".
> Sorry but browser graphical acceleration must end.
You can have two of the following three:
1) Scrolling that doesn't feel like molasses. 2) Box blur and shadow effects of various sorts. 3) Sofware rendering backends.
You're presumably voting for #1 and #3, but web designers are voting with the figers for #2, so a browser's options at that point are limited to either not supporting those and reaping the web-developer hate consequences (c.f IE6) or dropping either #1 or #3. Which one do you think they're more likely to drop?
> because the major problems have been solved years ago.
That's the point. They haven't been. For example, the major problem of web sites not having a good way to describe non-document layouts is _still_ not solved.
gmail's offline capabilities are still pretty poor, for one thing. Support for S/MIME isn't quite there yet (though there are browser extensions that try to do it). Latencies are way higher than a local mail client, at least for me. The "conversation" model it uses is not something everyone likes.
Gmail doesn't have NNTP support. Gmail doesn't try to remind you when you forget an to attach an attachment that you mention in the mail. Gmail sticks you with a crappy editing widget for your mail (granted, Thunderbird's is not much better).
Most importantly, not using gmail means Google doesn't have access to your mail. This is something some people actually care about, even if you don't. And not just for "office" mails.
Slashdot Mirror
There are two distinct claims in the Jesus story:
1) There was a guy living around that time who did some preaching and had a following.
2) This guy performed miracles and such.
You're arguing that because #2 is highly unlikely and has no evidence for it that means that #1 is also highly unlikely and has no evidence for it. That's a logical fallacy. You may want to read http://armariummagnus.blogspot.com/2011/05/nailed-ten-christian-myths-that-show.html for a slightly longer discussion of the subject, but the short story is that Occam's razor suggests #1 is probably true, while #2 is probably false.
Key to this argument is the "flat" part of the roof description. If your roof is peaked, then your angle of incidence for sunlight can be quite different from that 30 degrees (it can be up to "30 + the roof angle", depending on the orientation of the roof).
"flat" describes most large building roofs, but not most residential roofs. Of course he latter are what most of the commenters on this thread are talking about.... but not what Mr. Clinton is talking about.
The article is talking about doing that on Windows.
On Linux, distros could do that right now if they wanted to. But they don't choose to...
This is about 64-bit Windows builds.
There's nothing to say about the others, since there are release builds of 64-bit for Linux starting with Firefox 4 and since Mac defaults to 64-bit starting with Firefox 4 on Mac OS X 10.6 and later.
So Windows is the only one of the three that _doesn't_ have supported 64-bit builds yet.
Not all of them. For example, it doesn't have the plug-in issues, because it's a fat binary with both 32-bit and 64-bit executables, and the plug-ins are loaded into a 32-bit process.
Your second point doesn't make that much sense....
32-bit Firefox already uses 64-bit values (basically a union of a double and an unsigned long long) to store its JS values. Going to 64-bit actually makes this _harder_ because your pointers might not be distinguishable from a double. That's dealt with on x86-64 by exploiting the fact that it's really a 47-bit address space, but that causes some additional complexity and masking slowdown, so the JS folks have been considering moving to 128-bit values when running on x86-64. This would incidentally also work on 64-bit architectures with a 64-bit address space (e.g. sparc64).
The whole reason for nspluginwrapper is that you're using a 64-bit build but your plug-ins are 32-bit.
That is _exactly_ one of the reasons that Firefox is not shipping 64-bit on Windows yet (what the article is about).
So no, the only way to get rid of nspluginwrapper is to either use a 32-bit browser or not use 32-bit plug-ins. Well, or do something like Firefox on Mac, which involves shipping two copies of the code so the plugin-container process can be 32-bit...
You get faster code if your code is under a lot of register pressure because you're doing computations with a bunch of reusable intermediate results, etc.
You get slower code if your code is memory-bound, especially if pointer-chasing is involved (because you blow out your caches more easily and end up having to actually talk to RAM more).
Which one matters more for a web browser is a tough question. For example, most operations on the DOM are of the pointer-chasing variety.
See also https://twitter.com/#!/bz_moz/status/73784940755566592
One major problem with moving to 64 bit is that NPAPI plug-ins (e.g. Flash) are just dynamically linked libraries. Which means they need to be compiled for the same architecture as the process they're loaded into. Which means that process needs to be a 32-bit process if you want to use the plug-ins that are out there now. That's changing, albeit slowly.
Firefox solves this on Mac by in fact shipping a fat binary with both the 32-bit and 64-bit builds in it and using the 32-bit one as the plugin container process. But Windows doesn't have native fat binary support like that, and doubling the size of the Windows install package has its own share of issues. It's all doable, of course, but there are definitely drawbacks to switching to 64-bit so far. The question is whether the costs outweigh them.
http://releases.mozilla.org/pub/mozilla.org/firefox/releases/5.0/linux-x86_64/ for the current Linux 64-bit release builds.
Man. "Phone company can't properly apply a payment to an account" was definitely in the "reasons beyond me" bucket... and I'm sorry you had to deal with it. :(
1) This whole article is in fact about the fact that it's a fraud. That's what makes them "mysterious" and "illegitimate": they're bills for services that were never provided.
2) A typical US phone bill that does not have any of these charges on it (so just a normal bill) has a dozen or more line items with names designed to be as obscure as possible. Not only that, but in many cases these change from month to month (both the total bill amount and the exact itemization). As a result, it's actually easy to miss a $1 charge that shouldn't be there unless you're _very_ carefully reading the bill every month. Which most people don't.
3) For reasons that are beyond me, many people have their phone bills set up to auto-pay (basically have the phone company just withdraw the money from the user's bank account). So in that case there is no cheque being written. The payment just happens; you get sent a bill (or an e-mail that you can look at the bill online, if the phone company's incessant attempts to get you to go paperless succeeded).
So the deck is stacked against people noticing the problem. If they _do_ notice it, they have to decide whether they want to spend several hours on the phone trying to get rid of the charge or just pay it and move on. I bet in many cases people do the latter.
Because I'm also not using an @gmail.com address, of course. I can do that with a non-webmail client. But there's no way to do that with webmail, obviously.
> Sitting in on the development of a standard and then
> patenting those components is dirty pool.
You may be interested in reading http://lists.xiph.org/pipermail/theora/2010-April/003769.html in this context...
But in general, what Apple is presumably doing here is making use of http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-exclusion-with
What's bad exactly?
Generally speaking, the goal is to not change the way things look, just draw it faster...
The 32/64-bit situation for Mozilla right now is the following:
Linux: both 32-bit and 64-bit builds are available and supported starting with Firefox 4. Default download is probably 32-bit.
Mac: On 10.6+, the browser runs 64-bit by default and the plug-in process runs 32-bit. On 10.5, both run 32-bit due to OS-level bugs in 64-bit support.
Windows: Only 32-bit builds are supported. 64-bit builds exist, but are somewhat buggy. Shipping them involves fixing those bugs and addressing the issue about not being able to run 32-bit plug-ins in a 64-bit browser. On Mac, if you noticed, the solution is to use the built-in support for fat binaries and just ship both sets of code, using the 32-bit code for the plug-in process and 64-bit for the rest of the browser. Windows doesn't have such built-in support, so a similar solution would require some nontrivial work (and would of course about double the download size, unless the plug-in process stops being a copy of all of Gecko).
So long story short, 64-bit on Windows will happen, but it's not as simple as "flip the compiler switch".
Actually, Quartz might end up getting used as a backend for the Gecko-internal Azure API on Mac at least for a bit (just like Direct2D will be on Windows). See http://blog.mozilla.com/joe/2011/04/26/introducing-the-azure-project/ for some discussion of the tradeoffs here. There's some discussion about why it might be preferable to use a GL backend instead of Quartz on Mac (long story short, a GL backend is needed anyway for Linux and Android, and at that point it might make more sense to use it on Mac too so you don't have to maintain separate Quartz code).
Closing shipping lanes is generally considered an act of war, yes. See http://en.wikipedia.org/wiki/Blockade#Act_of_war
> Who started the 6-day war? Israel.
The granparent addressed this, actually. The war started with the first act of war, which was the attacks on Israeli ships in the Gulf of Aquaba.
Unless you have some really weird definition of "started" here...
> that a piece of native runtime plugin code can do
> as well
Because in some environments you can't drop in native runtime plugin code.
Or put another way, where's that 64-bit Flash for Linux? Or heck, for that new architecture that people will come up with tomorrow?
Whereas this way porting a web browser (a must for a new consumer-facing architecture anyway) will get you a PDF renderer for free.
> 'Plugin' is just a word, it doesn't need to be
> insecure, alien, buggy
A PDF-renderer plug-in can be secure and non-buggy if you spend enough resources on it. No one has done that yet. This project aims to get "secure and non-buggy" with less developer time invested.
> If anything, Pdf.js will be suitable where and when
> energy and resource conservation isn't a factor.
Or where reducing the security exposure is important.
> As for me, I prefer to avoid all the extra layers of
> abstractions
Within reason, yes? Or do you hand-code everything in assembly (or directly implement on FPGAs, even)?
The only question is _where_ the tradeoff lies.
> what is this gold that is Pdf.js
Think "a way to render PDFs in a browser without adding any new security bugs and without spending a few man-decades developing it".
> Sorry but browser graphical acceleration must end.
You can have two of the following three:
1) Scrolling that doesn't feel like molasses.
2) Box blur and shadow effects of various sorts.
3) Sofware rendering backends.
You're presumably voting for #1 and #3, but web designers are voting with the figers for #2, so a browser's options at that point are limited to either not supporting those and reaping the web-developer hate consequences (c.f IE6) or dropping either #1 or #3. Which one do you think they're more likely to drop?
Last I checked, adblock for chrome prevented _showing_ the add, but not fetching it from the server. Which means the ad impression gets counted.
> because the major problems have been solved years ago.
That's the point. They haven't been. For example, the major problem of web sites not having a good way to describe non-document layouts is _still_ not solved.
Ah, interesting. Indeed, it does. Good to see people stealing feature ideas from each other. ;)
gmail's offline capabilities are still pretty poor, for one thing. Support for S/MIME isn't quite there yet (though there are browser extensions that try to do it). Latencies are way higher than a local mail client, at least for me. The "conversation" model it uses is not something everyone likes.
Gmail doesn't have NNTP support. Gmail doesn't try to remind you when you forget an to attach an attachment that you mention in the mail. Gmail sticks you with a crappy editing widget for your mail (granted, Thunderbird's is not much better).
Most importantly, not using gmail means Google doesn't have access to your mail. This is something some people actually care about, even if you don't. And not just for "office" mails.