Last week, The Mozilla Foundation manager of browser engineering announced on Bugzilla that work was being put on hold to move the world’s second most used browser -- Firefox -- to 64-bit. The decision comes almost a year after Mozilla terminated another key development path: the Electrolysis Project to improve multi-processing.
Cumulatively, these two choices threaten to seriously undermine Mozilla’s legitimacy as a browser maker capable of producing a browser robust enough for business users.
Currently, Mozilla is doing a reasonably good job when it comes to memory management. However, the 2GB cap on processes (or 4GB with compilation for extended address space) is a notable limitation, considering that Mozilla’s key rendering logic is stored in a single process (firefox.exe). Electrolysis could have fixed that by splitting each tab into its own lightweight process (à la Chrome). Cumulatively, the two decisions leave Mozilla offering a browser that has memory limitations that may affect power users.
Consumers can take comfort in that there are freely available fan-modified Firefox browsers, such as Waterfox, which support 64-bit execution. However, these projects are too far from the core stable source for enterprise users to consider them viable alternatives.
While many enterprise users may see minimal impact from the memory limitations of Mozilla being stuck in the 32-bit lane, a more serious concern is security risks. Both Oracle (maker of Java) and Adobe Systems (maker of Flash) have turned their focus to 64-bit plug-ins. While 32-bit plug-ins are still distributed and maintained, as the pickup of 64-bit Windows has eclipsed that of its 32-bit counterpart, development resources at these crucial Internet giants is expected to shift towards 64-bit development.
I would, therefore, expect you will see a slightly slower delivery time for patches and updates to the 32-bit plug-ins as they fall out of use. In that regard, just as using Internet Explorer 7 presents a certain degree of fundamental security risk, using increasingly dated 32-bit plugins looks to become risky as time passes.
Mozilla’s justification for halting 64-bit development is that many plug-ins are incompatible with the larger memory address width. But there are two glaring flaws in this logic. First, the most used plug-ins -- Flash and Java -- are compatible with 64-bit; in fact, the 64-bit versions are fast becoming the preferred choice. Second, when it comes to more obscure plug-ins, Mozilla is essentially creating a self-fulfilling prophecy. By not forcing plug-in makers to go 64-bit, it is essentially ensuring that its plug-ins will not be 64-bit ready in the near future.
Enterprise adoption of Firefox continues to lag behind consumer adoption, but it does have some key backers. IBM named Firefox its default internal browser back in 2010. And a number of small software firms (particularly Linux-centric firms) use Firefox as their go-to browser. But with Chrome positioned to go 64-bit in the near future and with Internet Explorer and Opera already 64-bit, Mozilla appears to be the odd man out.
That’s bad news for Mozilla’s mainstream enterprise adoption efforts, at a time when serious questions already loom about its multi-processing development direction (or lack thereof) and its switch to a rapid release schedule (which some argue is bad for business users).
I think at the end of the day the pure psychological impact may hurt Mozilla more than anything else. After all, assuming Chrome tacks on 64-bit support as planned, ask yourself: Would any CIO want to move his firm onto a platform that’s the only major player in its market not to support the industry’s best-practice standard?
— Jason Mick is senior news editor at the independent tech news site DailyTech.