The issue is not so much that 64-bit is dropped or deemed unimportant; the issue is that Mozilla as a corporation has limited resources to devote to 64-bit Windows builds.

Basically, the main blockers are:

- Plugins. 64-bit plugins on Windows are still not 100% and there currently isn't a way of loading 32-bit plugins in a 64-bit Firefox. Yes, ideally Firefox would have this, but again - resources.
- Testing. It'd add another column onto the test matrix which is a non-negligible cost overhead to the release engineering guys (who are already massively overworked as it is). For a feature that Mozilla as a corporation isn't prioritising, this burden on releng is unacceptable.
- Benefits. The benefits from switching to 64-bit code aren't actually as plentiful as you might think. Basically, the major one is that Firefox would be able to address more memory instead of limiting at 4GB. However, project memshrink (https://areweslimyet.com/) has been working pretty hard on reducing the memory footprint of Firefox, which is the correct fix in this case *except* in the case of those people who are using hundreds of tabs amongst several browser windows. Unfortunately, they're in a small enough niche that, again, Mozilla can't dedicate resources towards a black hole to accommodate them (yet).

The myths that building the browser in 64-bit results in somehow faster code, or more efficient execution are just that - myths. In fact, in a lot of cases, code that was written for x86 that's been recompiled in x86_64 results in slower code because your pointer sizes are twice as big and you start smashing through your CPU cache more quickly.

For a more detailed description on the cost supporting these has incurred, Ben Hearsum wrote a very good post on dev-platform: https://groups.google.com/forum/#!msg/mozilla.dev.platform/UOn1iQetA5w/-DNzeCOMdrcJ

TL;DR - it's not a question of whether Mozilla wants to do this (they do); it's a question of whether the resource/benefit tradeoff makes sense at this time.

I would also like to remind people that software engineers aren't just assets that can be moved arbitrarily from project to project, so all those people saying "stop working on X feature and concentrate on 64-bit instead" - stop thinking like that. That's how bad managers are made.

It seems to me that he's not so much condemning the marketing term Apple has applied to it, but rather condemning the fact that PC manufacturers are so far behind Apple in terms of screen resolution that Apple is /able/ to market it as some sort of superior display (in this case, a "Retina" display). Basically he's saying that it shouldn't be marketed as a high-end option called "Retina", but that it should be the norm for all laptops.

Posted here in full:

"Low level APIs will allow the Sony NGP to perform about a generation beyond smart phones with comparable specs."

Carmack isn't saying that the hardware in the NGP is a generation ahead of smart phones. He's saying that because of the APIs available to developers they'll be able to utilise that hardware more effectively (specifically that a developer will be able to squeeze an extra generation's worth of performance out of hardware with approx. the same specifications), which makes sense once you consider that the games are pretty much running on the bare metal, and that the entire system is optimised for gaming.