Mozilla quietly kills Firefox 64-bit for Windows
thenextweb.com
thenextweb.com
From their website: "A custom-built and optimized Firefox-based browser for Windows"
I have been using PaleMoon builds and from what I gather the source tree is not being tombstoned, just the nightly builds. [0]
The reasons given for crashes (driver/component out-of-tree bugs) make sense but I'm not really involved in the development or testing so I'm sure others will have better input.
If you have no need for more than 3gb of memory per process then 32 bit is a great choice. The pointers being half size is a non-trivial memory saving.
I'd be happy if windows would let you use something like the x32 build target that linux got recently for extra registers though.
I thought the limit was 2GB, which Firefox is getting dangerously close to. 4GB gives a lot more wiggle room, but I wonder how long it will last...
"Microsoft Windows XP Professional x64 Edition released on April 25, 2005" http://en.wikipedia.org/wiki/Windows_XP_Professional_x64_Edi...
7 years.
Go to a store, see what kind of Windows is being shipped, if it's 32 or 64bits.
If there's one version that has to be discontinued that version is the 32-bit version.
Linux as well suffers with lack of 64-bit versions, it seems Mozilla started shipping them the other day (and is not very promoted)
Computers already ship with more than 4GB memory.
Leave 32-bit, it's been enough time already.
Only in commercial or prop software
Also, see the limitations of MongoDB and Go for example, in 32-bit systems, they are very relevant.
I'm not interested in MongoDB in the slightest, and while Go looks pretty cool, I'll wait for it to mature.
So if memory is an issue in 64-bits, most likely it will be an issue as well in 32-bit. In some cases it may make a difference, but they're not that common.
Even EC2 Micro supports 64-bits now
Sure, 64-bit uses more memory, like 32-bit use more memory than 16-bit, or like programs in ARM (and maybe Thumb) take more space than programs in x86
The Firefox version numbering debacle, including the constant problems it caused for extensions, was just plain silly.
Then there's Firefox Mobile. I've always found it very inferior to the other commonly-available mobile browsers. Aside from trying it out briefly, there was no reason to continue using it. This is probably the same for others, and likely why its uptake basically hasn't happened at all.
Earlier this year they seem to have withdrawn their interest in Thunderbird, which is by far one of their better offerings.
More recently, there's been a lot said about Firefox OS. There's a very good chance that this will become an unused, uninspiring, generally-ignored product, much like Firefox Mobile.
And now there's this decision.
Redirecting effort away from applications that are actually used, like Firefox and Thunderbird, toward things that clearly have little to no future, like Firefox Mobile or Firefox OS, just doesn't make sense.
Firefox OS has to be the most exciting thing they're doing. Why does it not have a future?
It isn't officially released yet, so of course it's not going to be as popular as a released product. Android wasn't popular until acquired and pushed by Google.
The Firefox versioning change was naive. It was rushed and a lot of work that should've taken place prior to the change was done afterwards and it remains to be seen just whether or not they'll ever truly pick up all the pieces from that. The negative word of mouth about extensions breaking is out there.
There is no excuse for the demise of Thunderbird. It remains to be a short sighted decision. But in that regard, Mozilla never really had the same ambitions as Opera. Mozilla should've been approaching the likes of HTC and Samsung and offering to provide the browser and mail experience rather than Google.
As for Firefox OS/B2G, I'd say it's highly probable that it'll fall by the wayside. Despite the resources thrown behind it. It's just not going to be a viable competitor. When you think about the sheer amount of money and effort thrown behind the likes of Android, iOS and Windows Phone, what exactly are Mozilla hoping for? It's only served to slow down development of features and other products that could serve the greater Mozilla community.
Posted from Opera.
It's a good question and it probably comes down to programmers and habit. Multi core processing and async/multithreading are finally starting to take hold but optimizing for a 64 bit bus still seems like an afterthought.
I am asking seriously because I don't have a definitive answer, but why is it just not catching on?
The only way things advance are when walls are finally hit. With 16-bit, this was trivial: the limitations were crippling. It'll get there with 32-bit, as applications begin to crash with the ~2GB per process memory limitations on Windows, and PCs continually appear with far more than 8GB of RAM available. But I'd say we are probably 5-10 years off from a point where we could consider deploying a 64-bit only application without losing users.
A much bigger issue is that migrating a massive 32-bits application to 64-bits requires too much effort, because unfortunately the C and C++ specifications have left a ton of flexibility and room for platform-specific behavior.
For instance it's beyond me why those specs haven't mentioned details like concrete sizes for really basic datatypes, like Ints and Chars, especially since development in C and C++ tends to get into really low-level details and optimizations, which means you end up relying on Ints being 4 bytes in size (how could you not do that?). The truth really is that even seemingly unimportant details such as the size of Ints can mean the difference between a rock-solid 32-bits app and a 64-bits app that's broken almost beyond hope of ever being fixed.
If anything, this should be the number one reason for why we must stop using C and C++ for new application developments and even in systems/embedded programming we could do a lot better, as these languages are unsuitable for continued improvements due to Moore's law, impeding progress.
Can you see how this creates a vicious circle btw? So we can have affordable consumer workstations with more than 10 GB of RAM right now with multiple cores and all that, which makes client-side development in garbage-collected functional programming languages feasible, but we can't really go there because the 32-bits legacy is holding us back. That's funny and goes to show that sometimes Worse is Not Better.
As for C and C++, the bugs that prevent a program going from 32-bit to 64-bit is making assumptions about the sizes of datatypes, and these days is usually seen as bad programming. They are just tools though, and have their uses, even in a multi-threaded world.
I've seen this repeatedly told again and again, however people saying that don't really know what they are talking about - it's extremely easy to make assumptions without even realizing you're making one, even if you could recite the whole spec of C and C++.
Even more, in C and C++ it is inevitable to make assumptions, even with eternal vigilance. I want you to point to a single reasonably big application that doesn't make such assumptions. And please don't point to one that works on both 32-bits and 64-bits, as in those cases the assumption about Ints simply evolved to: either 4 bytes or 8 bytes, with some awful code out in the wild that only works because of conditional compilation ... sometimes I wonder how software I rely upon works at all.
As for making assumptions, this is only natural, and programmers should be aware of the basic differences so they can correct their assumptions.
But 64-bit has none of these big advantages in practice. Battery life on OS X was worse right after the switch.[1] I have downloaded Podcasts a year before iTunes ran in 64-bit mode and they stopped working with the switch (nothing obscure - early Railscasts episodes). Many perfectly fine machines have been marked obsolete by Apple because their processors or graphics drivers weren't 64bit. - Windows has been a mess for me too: the 64-bit ODBC control panel is in system32 and the 32-bit ODBC control panel is in WoW64.[2] Because there are no fat binaries, casual users suddenly need to know which version of a Windows program to download. - So there is a lot of friction that needs to be outweighed. For what? - If Firefox wants to escape the 2GB barrier, the wiser choice might be to use one process per tab, as other browsers do.
If you look at the first and last sentence of your posting, you are basically accusing people of apathy because they keep using their 32-bit computers.
[1] http://forums.appleinsider.com/t/104687/64-bit-safari-reduce... (might also be caused by API changes that Apple has tied to the 64-bit platform) [2] http://robertoschiabel.wordpress.com/2008/02/28/windows-x64-...
The other advantage is being able to utilize more than 2GB of memory per process. The reason to favor pure 64-bit is to get rid of all that extra 32-bit compatibility code. WoW64, in this case, or ia32libs on Linux.
Whether you're pragmatic about it or not, 32-bit will eventually go away. I'd prefer to see it sooner rather than for it to drag on for decades like IPv6.
And yeah, WoW64 is a clusterfuck. Basically, Microsoft wanted to make porting 32-bit applications as easy as possible. Since some applications may have been hardcoded to System32, they stuck the 64-bit libraries there, and put the 32-bit ones in WoW64. They also cloned the registry so you actually have 32-bit and 64-bit keys (see KEY_WOW64_32KEY flag.) What can I say? Microsoft's always had a thing for rigid backward compatibility at the expense of common sense design. But they are still the market leader, so I guess they know a thing or two :/
I don't care for your Firefox example. What if one single tab needs >2GB, like say a really high-end WebGL game? What about other applications? People found similar tricks for getting more memory in 16-bit processes too (far pointers), but we aren't still using Win16.
I'm accusing people of apathy because they resist change simply because it's change. I get being pragmatic, but at some point we have to cut ties with the past. Even Microsoft understands this, as you can no longer run 16-bit applications on the latest versions of Windows.
How do you know that people hate change? Has anyone ever said "no, I don't want to run a 64-bit program, I've always been a 32-bit person"? People have to endure the crap in my grandparent post and that is what they hate and resist, especially if there is no tangible benefit to it. SSDs have entered the mainstream market much later and I have seen nothing but praise for them. SSDs are change too, often a painful one for a running system, but they solve an obvious problem.
Intel didn't put out an x86-64 chip until 2004, and their first desktop chip wasn't until early 2005 (IIRC). AMD's first 64-bit chip (Opteron) wasn't until 2003. Neither of these were mass market for quite a few years; it wasn't until 2006 that you really started seeing them in mass-market desktops. Now, there were exceptions of course, most notably the iMac and PowerMac G5, but 64-bit machines really weren't in the hands of general users until 2006-2007.
Just the convenience factor of not having to restart my browser frequently is enough to make me want to embrace x64. My blocker is that my corporate IT policy is to have 32 bit OS.
I suppose the obvious response is “Why should it?”
It makes a lot of sense to have a 64-bit operating system if we have, for example, more than 4GB of memory to work with. However, unless a single process needs access to the same scale of resources all on its own, there isn’t necessarily any advantage to writing things like application code the same way.
Moreover, moving to 64-bit pointers means more memory is required for data structures and for assembly level instructions that use indirection. In both cases, there is the potential for a significant performance hit, for example if less information fits into a cache.
OK, what about using 64-bit instructions that let us calculate with larger values? Again, that might be useful in some contexts, but on PC processors we’ve had specialist instructions for things like double-precision floating point calculations or operating over multiple bundled values simultaneously for a long time, so there are only limited benefits to be had.
Of course, set against all of these ambiguous benefits is the fact that porting to 64-bit can take a lot of work if the original code, data structures, file formats and so on were not designed with portability in mind. And once you’ve ported, if you’re also running a 32-bit version, now you have more testing to do, any related software might have to speak two protocols/APIs to remain compatible with both, etc. (This seems to be one of the main underlying points in the cited article.)
Looking at the astronomical memory requirements for something like browsers opening multiple tabs these days, perhaps in the case of Firefox there really is an argument for supporting more than 4GB of RAM. On the other hand, even modern web pages full of large images and multimedia wizardry usually only come in at ~100kB or maybe ~1MB, so even with dozens of tabs open, you need to be doing an awful lot behind the scenes to be in any danger of hitting a 4GB limit. Presumably the Mozilla folks don’t expect this to be a problem.
Gamers tend to have tons of tabs in their browsers. Couple this with tons of game resources and we have a serious memory hog.