4 ms·

That is a frighteningly sensationalist and misleading title; there's no evidence in this thread that Gecko is too big or development is stalled. The fact is tha

That is a frighteningly sensationalist and misleading title; there's no evidence in this thread that Gecko is too big or development is stalled. The fact is that many large projects now hit 32-bit ceilings when compiling on Windows. For example, Chrome has had to repeatedly split and restructure VS projects to stay under the memory caps.

nonane 15y ago
What prevents these projects from building on a 64bit OS with a 64bit compiler? Isn't that the simplest solution to getting rid of the ceilings rather than to continually restructure?
- zobzu 15y ago
  I'm guessing they have to switch the build toolchain, and its automated, so they have to make a decision before asking IT to do so. (again, its a guess)
- khuey 15y ago
  There is no x64->x86 cross compiler with MSVC, so if you want to produce i386 binaries you have to fit under 4GB of memory no matter what.
  - yuhong 15y ago
    True, but you may be able to compile with the x86 compiler and link with the 64-bit linker.
zobzu 15y ago
That's why its sent from a "random" "new user". Has no posts, no submissions. I'm guessing HN should downrank by default submissions from people with no posts. Regardless, the topic is interesting, even if the title is indeed, horrible "quick firefox is dead meme!". Heck if some Googlers are behind that stuff, that's sad.
- justinschuh 15y ago
  The funny thing is that the defense of Mozilla here is coming from a Googler who works on Chrome. So, the fact-free vitriol you generally spew is even less appropriate in this case.
farzul 15y ago
I disagree that there is no evidence in the thread that Gecko is too big. The "Gecko is too big" in the title is directly from the thread, started by a Mozilla developer. The evidence that development has stalled is the fact that the tree for landing code changes has closed. SPDY, recently announced here, has been, or is being considered for, removal to relieve code size.
- holygoat 15y ago
  (I'm a Mozillian.) These are slightly sensationalist ways of phrasing the following facts: * libxul hit linker limits on 32-bit Windows builds with profile guided optimization enabled, as it did a couple of years ago. PGO uses a lot of memory, but it's how we deliver on Windows, so it's important. * mozilla-central and mozilla-inbound were temporarily closed to avoid further build failures whilst the issue was explored. Other trees (try, services-central, etc. etc. etc.) remained open. * some recent large changes to libxul were backed out in order to relieve pressure on linking. * mozilla-central is now open for landings that aren't libxul-related, apart from those to trim it down. JavaScript and other landings continue unabated. See Bugzilla for the full scoop.
  - farzul 15y ago
    So what you're saying is that Gecko (libxul) has gotten too big, and that development of libxul stuff (Gecko) has stalled until it has fixed. How is my title sensationalist? For those wondering, the bug where this is discussed is: https://bugzilla.mozilla.org/show_bug.cgi?id=709193 https://bugzilla.mozilla.org/show_bug.cgi?id=709193
    - khuey 15y ago
      To be clear, the only thing that's "stalled" is integrating large pieces of code into our nightly builds. People are certainly still working on developing their bug fixes/features/etc.
      - farzul 15y ago

nonane 15y ago

What prevents these projects from building on a 64bit OS with a 64bit compiler? Isn't that the simplest solution to getting rid of the ceilings rather than to continually restructure?

zobzu 15y ago
I'm guessing they have to switch the build toolchain, and its automated, so they have to make a decision before asking IT to do so. (again, its a guess)
khuey 15y ago
There is no x64->x86 cross compiler with MSVC, so if you want to produce i386 binaries you have to fit under 4GB of memory no matter what.
- yuhong 15y ago
  True, but you may be able to compile with the x86 compiler and link with the 64-bit linker.

zobzu 15y ago

That's why its sent from a "random" "new user". Has no posts, no submissions. I'm guessing HN should downrank by default submissions from people with no posts. Regardless, the topic is interesting, even if the title is indeed, horrible "quick firefox is dead meme!". Heck if some Googlers are behind that stuff, that's sad.

justinschuh 15y ago
The funny thing is that the defense of Mozilla here is coming from a Googler who works on Chrome. So, the fact-free vitriol you generally spew is even less appropriate in this case.

farzul 15y ago

I disagree that there is no evidence in the thread that Gecko is too big. The "Gecko is too big" in the title is directly from the thread, started by a Mozilla developer. The evidence that development has stalled is the fact that the tree for landing code changes has closed. SPDY, recently announced here, has been, or is being considered for, removal to relieve code size.

holygoat 15y ago
(I'm a Mozillian.) These are slightly sensationalist ways of phrasing the following facts: * libxul hit linker limits on 32-bit Windows builds with profile guided optimization enabled, as it did a couple of years ago. PGO uses a lot of memory, but it's how we deliver on Windows, so it's important. * mozilla-central and mozilla-inbound were temporarily closed to avoid further build failures whilst the issue was explored. Other trees (try, services-central, etc. etc. etc.) remained open. * some recent large changes to libxul were backed out in order to relieve pressure on linking. * mozilla-central is now open for landings that aren't libxul-related, apart from those to trim it down. JavaScript and other landings continue unabated. See Bugzilla for the full scoop.
- farzul 15y ago
  So what you're saying is that Gecko (libxul) has gotten too big, and that development of libxul stuff (Gecko) has stalled until it has fixed. How is my title sensationalist? For those wondering, the bug where this is discussed is: https://bugzilla.mozilla.org/show_bug.cgi?id=709193 https://bugzilla.mozilla.org/show_bug.cgi?id=709193
  - khuey 15y ago
    To be clear, the only thing that's "stalled" is integrating large pieces of code into our nightly builds. People are certainly still working on developing their bug fixes/features/etc.
    - farzul 15y ago