I think Mozilla is misapplying its development time on stuff like social integration [1] and Firefox OS [2]. I would say these types of projects would be fine if they weren't ignoring their mainstay, by first canceling the process per tab project Electrolysis and now abandoning 64bit builds on Windows says to me that Mozilla seriously has its priorities screwed up.
The web browser has become the most important app on the PC, with more and more web pages demanding more and more resources, I really wish Mozilla would refocus on making the best web browser available.
A few weeks ago I tried to delete some of my history from Firefox, I opened the history window, hit Shift and selected about 6 months of history and hit delete, and it took Firefox about an hour to delete the history all the while the UI going from responding to not responding back and forth. Firefox has some serious performance problems.
Firefox OS is using the Electrolysis code, and since it is all the same core, Gecko, this means Firefox Desktop and Firefox Android are benefiting from engineers that were allocated to Firefox OS continuing to make Electrolysis better for all three targets.
There are plenty of engineers still working on Projects Snappy and MemShrink who are looking directly at the metrics related to the performance problems you describe.
The places database is known to have serious performance problems, as you discovered. It is difficult to reengineer but it is being worked on.
Finally, 64 bit windows builds are not being abandoned. They are being disabled for a time until the issues with marking bugs as 64 or 32 bit and other administrative details are ironed out.
These are my own perceptions and opinions about the situation.
Thank for enlightening us on the matter.
Well, maybe that would be worth a blog post ?
What about a quarterly "state of the union" to let people see the big picture instead of apparently unrelated and confusing press release ? Not that it's a due but it would certainly help your communication ;-)
Developers are not fungible. The social integration work was mostly HTML5 and JavaScript, and Firefox OS is partly kernel and OS work (B2G), and partly HTML5/JavaScript work (Gaia). 64-bit builds on Windows requires Windows developers, who are focusing on the Metro UI.
EDIT: I'm responding to your edit here:
> A few weeks ago I tried to delete some of my history from Firefox, I opened the history window, hit Shift and selected about 6 months of history and hit delete, and it took Firefox about an hour to delete the history all the while the UI going from responding to not responding back and forth.
I would imagine the Firefox developers spend their time optimizing the parts of their browser that users would most likely use. I suspect that they are not terribly worried about an action that users would take (at most) once every six months.
EDIT2: I guess I'll respond to this one too:
> The web browser has become the most important app on the PC, with more and more web pages demanding more and more resources, I really wish Mozilla would refocus on making the best web browser available.
Making the best web browser is not Mozilla's goal. Their goal is to "promote openness, innovation & opportunity on the Web" [1]. Integrating social features into the browser is part of that, in the sense that users will be able to control their social presence from their browser, rather than being locked-in to a specific social provider's web site. Mozilla's actions are not inconsistent with their stated mission. (Whether you agree with that mission is another argument entirely).
According to W3Schools[1] ~84% of web traffic comes from Windows users. In light of that wouldn't it make more sense to hire more Windows developers? If cuts have to be made it doesn't seem reasonable to make cuts to your main source of revenue.
edit: In response to your edit:
>Making the best web browser is not Mozilla's goal. Their goal is to "promote openness, innovation & opportunity on the Web"
If Mozilla's goal isn't to make the best web browser then no one will end up using their browser, and if no one uses their browser then they wont be able to "promote openness, innovation & opportunity on the Web", no market share = no voice. During the days of IE6's dominance Mozilla got its large user base because it was the best browser available. Mozilla is in danger of hemorrhaging users if it continues making these sort of decisions.
Us "hackers" got Mozilla its user base, we started using it first and convinced our family, friends, workmates/workplaces to switch. If the power users leave, the rest will be soon to follow.
This is off-topic, but you should know that there are a number of significant issues with W3Schools that prevent it from being a reputable source: http://w3fools.com/
No offense, but anyone who visits w3schools is probably clueless and lost. It's a terrible resource that needs to be destroyed, scrubbed from the search results like Stack Overflow did to Experts Exchange, all for the sake of humanity.
I'm surprised only 84% of the traffic is Windows users.
That is ridiculous. Sure it isn't the best resource available and on some things makes some out of date or wrong recommendations. I have gotten refreshed on basics plenty of times though from a wc3schools links. Does that make me less of a developer?
You are also implying that developers using windows are all second rate.
> I have gotten refreshed on basics plenty of times though from a wc3schools links
When even the basics are wrong you're not getting refreshed much. Especially when adding three letters ('mdn') to the query at the end gives you a much better resource by all metrics.
What I'm implying is that a lot of Windows developers don't have a choice. It's the standard issue computer they're given. Maybe they work for a gigantic company with a fossilized IT department. Maybe they work for the government. Either way those kinds of organizations are not running Linux or OS X or Chrome OS. There is a very strong bias towards Windows because of that.
If you subtract that quotient from the general pool of "Windows developers" it becomes much more of a fair comparison.
Yes, there's useful things on w3schools, but like picking through a trash heap full of rusted bicycles and used syringes, it's a dangerous expedition. You might pick up some awful bad habits along the way.
> I would imagine the Firefox developers spend their time optimizing the parts of their browser that users would most likely use. I suspect that they are not terribly worried about an action that users would take (at most) once every six months.
I stopped using Firefox years ago. Reading an apology on a tech site explaining why, in 2012, it's acceptable that deleting 6 months of history can take one hour (!) gives me confidence that I'll never ever go back to Firefox.
I only use Firefox for development now, mainly for Firebug (and related plugins) but now I am starting to use the Chrome dev tools much much more. The only plugin I am missing to fully ditch FF is Selenium IDE.
I stopped using FF when I left my previous job, synced up my bookmarks before I left but then was unable to retrieve them because I had not written down the access guid. I'll just sync with my Google account and be done with it!
> I would imagine the Firefox developers spend their time optimizing the parts of their browser that users would most likely use. I suspect that they are not terribly worried about an action that users would take (at most) once every six months.
I wish I could use that excuse at work, but it doesn't work like that.
In fairness, Chrome/Chromium have their own set of issues. I use both browsers and come across crashes, poor renderings, bad performance, etc. I still prefer Firefox for a few extensions I use, though.
I stopped using FF when I left my previous job, synced up my bookmarks before I left but then was unable to retrieve them because I had not written down the access guid. I'll just sync with my Google account and be done with it!
Having been a user and developer for almost any time, I would never have relied on that! A simple bookmark export, spot check for some URLs, USB drive/email/FTP to somewhere. I've always done that when leaving jobs (along with other personal things or notes/application settings).
Maybe I'm too cautious, but I've always ended up with a good copy of my data.
To be fair, I had a backup by doing a simple export, it was about a month old so I didn't lose anything important (and reason I did it this way) but the fact it worked that way did annoy me. I just like the way the Google products are much more synced with my life. I was a "work" email which syncs with work related stuff, and personal email with syncs with regular stuff.
I still use both for cross browser testing, and at the moment I still use FF & Firebug but I am weaning myself off it. My day to day browser for everything is Chrome, in much the same way we all ditched IE but still had to occasionally use it for those sites "optimized" for IE.
The Firefox sync is probably the nicest piece of technology they have.
The google account is pretty much the opposite of "secure". Grants access to all the things. And 2 factor auth doesn't exactly help when you computer is compromised.
FF Sync is separate and secure - but - I bet they'll change it for something more Google-like, as usual.
Mobile is very much the future. Windows desktop is both the past and present. The browser has already won the desktop, but its losing on mobile, which is why its so important to focus on Firefox OS, and not so important to focus on Windows desktop.
Isn't the Firefox browser, and through it the search engine traffic which they sell the rights to, the thing that keeps their company running?
You'd think they'd be focused on making a better browser, clawing more market share, and cementing their presence in the browser space.
I used to use Firefox almost exclusively, but lately Chrome and Safari have filled that need. Breaking compatibility with old plug-ins might have been necessary, but it made switching a no-brainer.
I entirely agree with you, but then again, I don't think Mozilla has always had their priorities straight. My favorite example is the 3D view in the inspector. At the end of 2012, you still can't live edit in Markup Panel in any meaningful way, and yet you have a 3D view. I would LOVE to use the inspect bar if it was usable, but now I'm stuck with it and 8 other items in the Web Developer submenu and Firebug. Firebug's been around forever and does everything the other 9 items can and cannot do. Just bundle it into Firefox already and move on to other things geez...
I could not agree with this more, Mozilla is making some strange strategic decisions these days which really make me worry about it's future, because I am a big supporter of Mozilla in general.
I just wish they would "stick to the knitting" and make the best browser they possibly can for multiple platforms.
Pretending this was a political decision (vs just being what the Windows hackers decided to use their time on)...
Let's tally the arguments so far for prioritizing 64-bit Windows development.
Pro: The Ars article lists some Win64-specific security-bug mitigation features, unclear how significant these are.
Con:
The Windows PC is a declining platform, and the current 32-bit product covers all of the platform currently. There's probably a shortage open source developers working on Windows-specifics. 32-bit is much more memory-efficient. 64-bit breaks compatibility with plugins. Address space shortage will likely be covered by the tab unloading feature mentioned in the article, before it becomes an issue in practice.
Overall sounds to me like You Ain't Gonna Need It.
I would have assumed it's declining in terms of market share (driven down by tablets/Mac/Linux) but there's a surprisingly large absolute drop coming as well:
I work for several very large telcos and I have been, so far, able to avoid both .NET and Java. Last time I wrote C# code was because Microsoft (then a client) demanded we run our application on a Windows server. I wrote a proxy that sat in front of the application (which ran on a Linux machine).
>Address space shortage will likely be covered by the tab unloading feature mentioned in the article, before it becomes an issue in practice.
before? I've seen Firefox run up against the 2gb limit[1] for years.
This 4GB space is evenly divided into two parts, with 2GB dedicated for kernel usage, and 2GB left for application usage. Each application gets its own 2GB, but all applications have to share the same 2GB kernel space.
32-bit Windows (with the 2GB limit) couldn't run the 64-bit Firefox in any case, so in the context of this discussion the 32-bit build is always getting 4GB of address space.
With moves like this is it any wonder why Chrome basically hit the ground running with market share as soon as it hit a stable release? I got tired of the Mozilla bureaucracy a long time ago when they failed to acknowledge there were some serious memory leak issues with addons and the browser itself slowly consuming hundreds and eventually gigs of memory the longer it was left open, it wasn't until later builds (this year) they released a version that fixed this by sand-boxing the addons or something to that effect.
I still remember the time Mozilla developers were fighting about removing front-facing version numbers from the browser, it's also at that point I realised there are some issues with the Firefox development team all while Chrome and even Opera gained more market share.
Remember where your loyalties lay, Mozilla. I think they're starting to spread themselves too thin with wasted development of a Firefox OS and social integration. Halting 64 bit versions of Firefox for Windows for the time being might seem like a small, trivial thing, but it's not and I think it's a bad move.
Remember where your loyalties lay, Mozilla. I think they're starting to spread themselves too thin with wasted development of a Firefox OS and social integration.
While you may have a point about spreading things too thin, I would hardly call Firefox OS wasted effort. Even as a die-hard Android-user I find it some of the most fascinating and promising development going on in the mobile-sector right now.
If there is one platform I want to succeed, it's not Apple's or Google's. It's the web.
Having you entire mobile experience powered by standardized HTML, JS and APIs would be wonderful. It would also make it dead easy to provide mobile "apps" for web-sites without the need to setup huge, dedicated app-development teams, one for each "supported" platform.
I don't see Firefox OS as wasted effort. The rest of the bunch (Apple, Google, Microsoft) are just doing a mobile/touch-oriented rehash of the desktop-regime, with an added proprietary app-store.
Firefox OS on the other hand, is not getting near the attention and recognition it deserves. It's the only revolutionary mobile-platform being developed right now. It's the only platform bringing forth some new ideas.
You mean the Chrome which can't even be arsed to provide 64b builds on platforms where it's easy (Linux) or trivial (OSX), let alone hard (Windows) ones?
It's almost as if Mozilla has been an open source project forever, and people who are contributing to open source projects in their spare time for free don't just do whatever you tell them to do.
And what's that supposed to mean? Are you suggesting that Google is using it's leverage over Mozilla to get them to not compete with Google's browser? That sounds sort of incredible to me, given that Chrome isn't a profit center for Google.
I'm not sure if Google used leverage or some kind of weirding way but Mozilla foundation's activities since 2008 or so tie in nicely with Google's priorities.
According to the Wikipedia page on Mozilla, Google gives Mozilla money considerably beyond search royalties ($5M in 2006 for example).
Every Chrome user is presumably someone using Google for search whom Google doesn't need to pay. (I doubt that makes Chrome profitable though.) I think Chrome and Android only make sense as defensive measures against Microsoft/Mozilla and Apple respectively.
And Google pays Mozilla for prime placement because Firefox has users(even Bing would). No users = no money.
So, this is not your typical volunteer FOSS project when you're pulling in upwards of 100 million dollars a year and the standard rebuttal to people asking for bug fixes and features does not apply.
Reminds me of the mouseover text bug that Randall Munroe was requesting to get fixed for Xkcd and was met with hostility. Did they expect him to fork Firefox to make his Firefox readers see the text? It took them 7 or 8 years to roll the fix into Firefox.
For comparison, Chrome is 32-bit on both Windows and Mac OS X. Chrome's multi-process architecture means memory limits are less critical, but Chrome doesn't benefit from any of the 64-bit security features mentioned in the Ars article. (Firefox is 64-bit on Mac OS X and Linux.)
Sometimes it saves a huge amount of effort to wait for things to mature otherwise before proceeding.
If your firefox is using more than 4gb of memory ( >2gb via LARGEADDRESSAWARE) you have other problems, and 32bit code is almost always faster than 64bit with current CPUs.
No, 32-bit code is not faster with current CPUs. x86 apps are more register-starved than they are cache-bound. I don't know who started this urban myth about x64 applications somehow being slower than equivalent ones running under WoW64, but it needs to either be backed up with specifics -- what apps are slower, and why? -- or stop being propagated.
(Source: extensive firsthand experience with performance-sensitive C/C++ development for Windows.)
64-bit Firefox is slower for some workloads because the JavaScript heap is dramatically larger (Due to the doubled pointer size). As it happens, large portions of Firefox are written in JavaScript...
I'm sure there are some use cases where it's faster, of course, but having your heap be 50-100% larger (yes, really that much, I've measured it) is pretty hard to overcome just by adding a few extra registers.
I expect this is why Java has support for using 32-bit object pointers in 64-bit mode. Features like that would probably help Firefox tremendously.
Heap growth moving from 32b to 64b is rarely on the order of 50-100% larger. 20-30% is much more common (100% would imply that your application stores no actual data, only pointers and sizes; I know that pointer-chasing is very much in style these days, but that's ridiculous. Even the 1:1 ratio implied by a 50% figure is an extreme outlier).
Further, raw heap size typically has marginal impact on performance; locality of reference and size of working set are far more important. It doesn't matter if your raw heap usage grows by 30% if the majority of your accesses are to the same working set of data either way.
At the same time, a well-crafted interpreter or JIT (which people seem to think is important in browsers) benefits heavily from increasing the size of the register set. Even in more typical use cases, even without aggressive optimization, speedups of 10-20% are common in moving from x86 to x86_64.
You can tell me what your think the behavior is actually like, but I can point you to a HTML5 game that uses 50-100% more JS heap and runs slower in 64-bit builds of Firefox :)
You say a larger heap has marginal impact on performance and that locality and working set size are what matter. If larger pointers make the heap bigger, then the working set is going to grow as well, and locality will be worse because the larger pointers mean less objects fit into a cache line.
I'm not saying 50-100% growth doesn't happen, I'm saying that it's an outlier (based on complete system data from multiple platforms).
If it's really a common issue with firefox's JS implementation for some reason, there's nothing to stop them from using a compressed pointer scheme for JS that uses 32b pointers and a known offset; it's a common technique. You give up one register to keep the offset around, but you've still netted 7 registers from the switch to the 64b ISA, and adding the offset is either a simple OR or can be folded into an LEA (nearly free or free).
Let's not confuse "they haven't had a chance to tune the 64b JS engine, and the 32b one has been worked on for years" with "x86_64 is slower than x86_32".
Is your "complete system data from multiple platforms" from JS apps?
Let's also not confuse "a sufficiently smart compiler..." with real-world observed performance :)
BTW data layout transformations like compressed fields would also be useful on 32-bit. The vast majority of object graphs would be happy with 16 or even 8-bit identifiers, not to mention JS numbers which are all 64-bit floats even on 32-bit platforms.
It might be that it's simply Firefox's JavaScript interpreter which hasn't been optimized for 64-bits. As far as I know other JavaScript interpreters don't suffer from this problem, and with LuaJIT, which should be fairly similar to a JavaScript JIT compiler, at least I have the numbers to back it up: http://luajit.org/performance_x86.html
LuaJIT doesn't have increased memory usage. 32 or 64 bit, it always packs pointers into the low bits of NaN doubles. Addresses fit because current 64 bit chips actually use 48 bit addresses.
(LuaJIT also uses a limited memory arena for allocations but it's not inherent to the design; it could be changed but the current garbage collector can't handle that much data)
Specifics: web browsers (and specifically Firefox, but it's true for WebKit-based browsers too) tend to be slower on most web workloads when running 64-bit.
There are several reasons for this.
First of all, web browsers are very pointer-chasing heavy because of the nature of web specs: the DOM is all about tree traversals, and so is CSS layout. Further, you have to share style, font, etc data across objects to get anything resembling sane memory usage, which means chasing pointers to all that data. Given that many of the algorithms involved require traversing large chunks of the DOM tree and various ancillary data structures, the upshot is that most of the really processing-intensive parts of a browser layout engine (possibly excluding graphics) are in fact more cache-bound than register-starved.
The second reason is a bit of a chicken-and-egg problem. Since most of the users are running the 32-bit builds, the 32-bit JIT has had more optimization work on it than the 64-bit one. The obvious solution is to improve the 64-bit JIT, of course.
The third reason is that even in JITTed code it turns out that cache locality matters a lot because JS objects share lots of their state across multiple objects so getting to it involves pointer-chasing. An actual JSObject in SpiderMonkey is 4 pointers and all the other things you want out of an object you reach through those 4 pointers. This reduces memory usage enormously compared to putting the data inline in the objects, and actually improves cache locality in general, but exacerbates the difference between 32-bit and 64-bit.
You're right that for heavily numeric JITted code x86-64 beats the pants off x86-32. Unfortunately most JS out there is object-heavy pointer-chasing, not numeric code...
> x86 apps are more register-starved than they are cache-bound.
Considering it has 16 general-purpose registers (twice as many as x86), I wouldn't consider amd64 register-rich. It's, at best, less starved than x86 but no match for the MIPS processors from 1981.
Actual modern x86 implementations have hundreds of registers; what they are starved for is register names. This puts enormous pressure on the register-rename and reordering logic of the processor, but Intel and AMD have turned out to be quite good at delivering there, to the point that (certain numerical algorithms aside) the relative lack of register names is usually a non-issue.
More precisely, it's the compiler (or luckless .asm hacker) that suffers from register starvation. Register renaming can avoid pipeline blockage but if the compiler thinks it's out of registers, it'll use... wait for it... memory accesses. Now you've entered the wonderful world of load/store penalties and the like, and at least some of those cache lines that the Mozilla folks wanted to preserve are going to get used anyway.
It's really a pretty terrible idea for Mozilla to favor 32-bit code over 64-bit code these days. Not so much because of any feature or perf differences, but because it signals that they don't really have a clue what they are doing.
As a lucky asm hacker and frequent advisor to compiler codgen engineers, in the past few years re-order engines have gotten to be wide enough that it's really not too bad. It simply requires a different mindset; instead of attempting to hand-schedule individual instructions, one instead schedules small blocks of instructions chosen to minimize state that must be preserved across block boundaries (to minimize register usage between blocks) and lets the rename/reorder do their work.
There are some (mostly numeric -- hand-tuned FFTs come to mind) codes for which the lack of names really does cause difficulty, but they are relatively few and far between.
All that aside, yes, 8 GPR names is just absurd, and targeting x86_32 is ridiculous when x86_64 is so widely supported.
Well, pointer size is a concern and pretty much every RISC architecture suffered a slowdown when moving to 64-bit pointers. It's just that x86-64 added so many good things that it made up for that disadvantage.
I fail to see how if "my Firefox" is using a certain amount of RAM, I have any problem at all. If I am using Firefox in a reasonable way (i.e., not 400 tabs open or something), why should my RAM usage even be a function of anything I am doing, at least to the point for it to utilize 4GB of RAM?
I certainly hope that memory is a function of how much content is loaded because one would expect a modern desktop application to keep all its non-persistent working data in memory, and not try to outsmart the OS when it comes to memory management. After all, RAM is cheap, your OS is perfectly capable of managing virtual memory, and addressable memory isn't a problem on 64 bit systems.
The irony is that one of the reasons why modern mobile OS often feel faster than desktop applications on much faster hardware is because their APIs force programmers to give up this kind of hubris. So basically, Mozilla is building FirefoxOS, which will enforce the reasonable behavior they aren't capable of themselves when in the role of an application developer.
I think RAM usage should be a function of work load. However, here I sit with 12 tabs open and Firefox using almost 1GB of RAM. I don't know when this became okay, but I could see Firefox using 4GB of RAM, easy. At this rate, that would be due to the ungodly workload of 48 tabs.
As the article mentions, the same security arguments apply to Chrome for Windows and OS X - especially on OS X, where 32-bit applications really get short shrift of hardening measures. Right now on my Mac, there's some argument to be made that Safari is the most secure browser, simply because it has sandboxing (unlike Firefox) and is 64-bit (unlike Chrome), despite Chrome's healthy obsession with sandboxing and good security record.
In light of this recent development that's what I just switched to.
I was using the 64-bit builds over at http://wiki.mozilla-x86-64.com/Firefox:Download when Adobe first kicked out a 64-bit beta of Flash. Later I switched to the official Nightly builds when they went 64-bit.
Unfortunately I'm not able to offer much insight into if it was better. Aside from a couple of short strings of bad builds that caused crashes I never had any issues with them.
I've been waiting ages for Mozilla to get their act together and make a 64 bit browser. I had never heard of this before. I just downloaded it and I'm trying it right now. So far it seems great. All my extensions seem to be working with no problems and it feels like it's faster. Thanks for the link!
It is great. Speed alone would be a reason to change but the best thing about it is that it is not banned on my companys PCs as FF or any other browser then IE are. I finaly experience speed and adfree browsing again.
Not too long ago, there were hardly any 64-bit hardware in the market for average users, until they flooded the market and now every other Ma and Pa owns a Windows running on 64-bit.
Desktop hardware has been 64-bit since the 2003 Athlon 64, 2004 Pentium 4 and 2003 PowerPC G5. Servers 10 years+ earlier(X). I guess 9+ years on the desktop is "not too long" if your beard is long enough :)
Software not so much though, 64b XP basically didn't exist, and for 7 I've no idea what the ratio is. And 64b on Windows is a complete fuck-up (even when running a 64b Windows), apple's "fat binaries" made the transition smooth as butter for most users (the only issue I ever had were a pair of kernel extensions), in 7 64b is still screwy and the vast majority of software available seem to remain 32b.
Obviously it's not representative of all users, but Steam breaks down its hardware survey by OS version. The 60% using Windows 7 64bit is a convincing majority.
64b on windows is a fuck-up? I haven't had a problem with 64/32-bit compatibility since windows 7 came out, other than devices that only have 32-bit drivers. And you'll have that problem anywhere - even Apple's marvel of engineering where you double the size of executables won't solve that.
Software shipping as 32-bit isn't a bad thing. It means it will run on more machines. Shipping a Windows application as 32-bit has NO negative consequences unless your application needs more than 2GB of available address space, with a couple rare exceptions like shipping device drivers or debugging tools.
Apple's "marvel of engineering" actually does. You can launch an app in 32-bit mode (while running in 64-bit mode) should you require interoperability with 32-bit components. All actually pretty neat. And given that most of an app isn't executable binaries (and hasnt been since forever) the size of executables isn't a big deal.
(A few years ago I had to run Safari in 32-bit mode to test unity web apps for the brief period where unity didn't offer a 64-bit plugin.)
> 64b XP basically didn't exist ... And 64b on Windows is a complete fuck-up
What do you base those statements on? I changed to 64 bit at Windows XP, never looked back and stayed there on multiple machines through Vista, Win7 and now win8.
Windows Server 2008 R2 and Server 2012 are both 64 bit only. There are no 32-bit builds of these OSs.
Most desktop PCs may have 64-bit processors, but do they ship with 64-bit Windows OS? Apple's "fat binaries" containing 32-bit and 64-bit (or even PowerPC or ARM) binaries greatly simplified the Mac's transition to a 64-bit world.
In my experience, a few years back, whenever I bought/built a machine I had to explicitly ask for 64bit (if that's what I wanted). Nowadays, it seems to be the default even for the cheapest builds available.
Consider this, most default builds (even the cheap ones) come with at least 4GB of RAM nowadays. The only machines I see with less RAM now are nettops, netbooks and other miniaturized builds. You need 64-bit Windows to fully take advantage of 4GB (with 32-bit Windows, you'll only see like 3.something), not to mention anything larger than 4GB is essentially worthless to a 32-bit OS. Dell isn't going to sell you a laptop advertised with 6GB RAM and then stick a 32-bit version of Windows on there that can only use <4GB.
(Now, this 4GB limit to 32-bit OS's isn't a problem with PAE. But why Windows has support for PAE but nobody seriously uses it is a story I don't know the details to.)
I remember going to an MS Dev event for 64 bit XP (still have the shirt!) and being pretty excited about it, but bugger all worked in XP64. As someone who spent many (10+) years writing for Windows and now uses a Mac it's hard not to compare Apple's 64 bit switch to Microsoft's
While Windows certainly did arrive late to the 64-bit party (not entirely true - NT ran on Alphas), 32-bit processors (and limited address space) are a distant memory to most Unix (and Linux) users.
I still run 32-bit Linux on both computers, despite having 64 bit processors. One has 2GB of RAM, the other 3GB, so I see no reason to switch. Computers bought 3 years ago are hardly 'a distant memory'.
I believe the idea is that there aren't enough Windows people to work on both 64-bit and the Metro UI for Firefox. Metro is a priority, so 64-bit is getting mothballed for the near future.
MFC, Windows Forms, WPF, Silverlight ... all of them still around, but all of them being obsolete by whatever Microsoft's du-jour UI framework happens to be.
Gnome 3 is not the same thing, as Gnome 3 is just a window manager, based on the same X, the same APIs and the same GTK, just as Unity and Gnome 2.
Not surprised at all, and IMO a good move. Mozilla needs to focus on its Firefox OS development. By the way, MS doesn't want 3rd party browser on its Windows RT, that could be a very discouraging factor.
The opposite is also true: "I just wanted to shut down and go home, and now is when you decide to stop and delay the user?"
This is an old problem. Chrome solved it the right way by stepping out of the startup/shutdown dichotomy and doing everything in background. Just one of the many areas where Google ran circles around Mozilla (with the benefit of moving from a clear slate, and probably also of staying away from the Gecko clusterf*ck).
Firefox needs to grow up, or be suspended altogether. IMHO, its horribly behind. Technically behind on WebKit, behind usability wise on almost any browser.
Yesterday I ran into a 5 year old bug in Firefox (https://bugzilla.mozilla.org/show_bug.cgi?id=405761) that required me to write Firefox-specific JavaScript workarounds. I used to accept that from IE, but from Firefox, never.
That's what I call irony... So it seems that Internet Explorer will be soon, at least on Windows, (again) the technological most advanced browser. Microsoft did their homework.
As long as Mozilla is 95% or so dependent on funding by Google, there's a conflict of interest present that will very likely not lead to Mozilla's Firefox being a competitive browser. If you think otherwise, you're a hopeless romantic...
As a conclusion, it is not surprising at all that Mozilla is focusing on developing products that do not compete with Google's browsers and other software.
You seem to believe that Google cares about Chrome more than their Firefox contract. I don't see this being likely. Chrome makes Google no money besides having Google as the default search. Firefox makes Google money in exactly the same way. Firefox is just as important to Google's revenue as Chrome is.
All Google needs is search results to show advertisements on and a browser capable of running their applications. Both Firefox and Chrome meet this requirement.
> Chrome makes Google no money besides having Google as the default search. Firefox makes Google money in exactly the same way. Firefox is just as important to Google's revenue as Chrome is.
You forget that Google pays Mozilla a lot of money for something they can get for free every time a Chrome installation replaces a Firefox installation. So the potential savings for Google is (currently) $300M/year once they have killed off Firefox completely.
The web browser has become the most important app on the PC, with more and more web pages demanding more and more resources, I really wish Mozilla would refocus on making the best web browser available.
A few weeks ago I tried to delete some of my history from Firefox, I opened the history window, hit Shift and selected about 6 months of history and hit delete, and it took Firefox about an hour to delete the history all the while the UI going from responding to not responding back and forth. Firefox has some serious performance problems.
[1]. https://blog.mozilla.org/blog/2012/11/20/firefox-introduces-...
[2]. http://www.mozilla.org/en-US/firefoxos/