Update on turning off 64-bit Windows builds

6733 views
Skip to first unread message

Benjamin Smedberg

unread,
Dec 21, 2012, 4:43:25 PM12/21/12
to dev-apps-firefox List, mozilla.dev.planning group
After I announced my decision to disable 64-bit Windows nightlies, there
was significant negative feedback. After reviewing that feedback, and
consulting with Release Engineering, I believe that we can keep a set of
users happy by making a modification to the original plan.

Most importantly, it seems that there are users who regularly run into
the 4GB memory limits of 32-bit builds. These users often have hundreds
or even thousands of tabs. These users are using the 64-bit nightlies
not primarily to be part of our testing community, but because those
builds are the best product available.

At this point, the Mozilla project does not have the resources to
actively support this use case. Making these builds, however, is not a
significant burden on our Release Engineering group. Therefore I have
modified my original plan in the following way:

* Migrate all existing users of win64 nightly channel builds to the
win32 nightly channel builds via automatic update.
* Continue to build win64 Nightly builds and updates on the nightly
channel. Users who need the 64-bit builds will have to download it after
the migration point (date TBD).
** Change the default first-run and update page for win64 builds to
explain to users that they are not supported.
** Disable the crash reporter for win64 builds
** Enable click-to-play plugins by default in the win64 builds.
* Discontinue the win64 tests and on-checkin builds to reduce release
engineering load. By default, do not generate win64 builds on try.
* win64 builds will be considered a �tier 3� build configuration. [1]

We will continue to test the win32 builds and make sure that they work
well on both 32-bit and 64-bit versions of Windows. Specifically, all of
our testing on Windows 8 is planned to be done on the 64-bit version of
Windows 8.

I do hope that the projects and developers who are interested in win64
will work together to maintain this build configuration. I am interested
in hearing from volunteers who want to become the 64-bit build
maintainer. I will also set up a discussion list specifically for win64
issues, if that would be valuable.

--BDS

Please post followups to to mozilla.dev.apps.firefox

[1] https://developer.mozilla.org/en-US/docs/Supported_build_configurations



Yuhong Bao

unread,
Dec 21, 2012, 8:10:45 PM12/21/12
to
On Dec 21, 1:43 pm, Benjamin Smedberg <benja...@smedbergs.us> wrote:
> * win64 builds will be considered a �tier 3� build configuration. [1]
Something is broken here.
Yuhong Bao

Chris Ilias

unread,
Dec 21, 2012, 8:15:25 PM12/21/12
to
On 12-12-21 8:10 PM, Yuhong Bao wrote:
> On Dec 21, 1:43 pm, Benjamin Smedberg <benja...@smedbergs.us> wrote:
>> * win64 builds will be considered a �tier 3� build configuration. [1]
> Something is broken here.

It says win64 builds will be considered a "tier 3" build configuration.

realit...@gmail.com

unread,
Dec 22, 2012, 3:26:11 PM12/22/12
to dev-apps-firefox List, mozilla.dev.planning group
Couldn't you just make the migration optional? Forcing users to download a 32-bit version they obviously don't want given the feedback seems a little... bandwidth unfriendly, to say the least.

byte...@gmail.com

unread,
Dec 22, 2012, 3:41:34 PM12/22/12
to dev-apps-firefox List, mozilla.dev.planning group
On Saturday, December 22, 2012 3:26:11 PM UTC-5, realit...@gmail.com wrote:
> Couldn't you just make the migration optional? Forcing users to download a 32-bit version they obviously don't want given the feedback seems a little... bandwidth unfriendly, to say the least.

Agreed. It seems to be a little heavy handed to turn everybody running 64-bit code to 32-bit code, only to allow us to have to go through and download it again.

spec...@gmx.de

unread,
Dec 22, 2012, 3:42:02 PM12/22/12
to dev-apps-firefox List, mozilla.dev.planning group
Am Freitag, 21. Dezember 2012 22:43:25 UTC+1 schrieb Benjamin Smedberg:
>
> ** Disable the crash reporter for win64 builds
>
Why not fix this bug?
https://bugzilla.mozilla.org/show_bug.cgi?id=811051

Matthew Turnbull

unread,
Dec 22, 2012, 6:05:55 PM12/22/12
to dev-apps...@lists.mozilla.org
Well, if you can think of a way to facilitate that process, that doesn't
involve significant changes to the update system, then by all means
please speak-up.

The goal is to get people off of the win64 builds because they are
unsupported. I'm guessing the percentage of win64 users who regularity
exceed 4GB is on the smaller side, so I doubt this will hurt Mozilla in
the bandwidth department.

If you're concerned about your own bandwidth, then by all means turn off
updates. Download a new win64 build after the migration happens.
> _______________________________________________
> dev-apps-firefox mailing list
> dev-apps...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-apps-firefox
>

--
Bluefang-Logic Networks:

Scaled for your pleasure.

Robert Kaiser

unread,
Dec 22, 2012, 7:31:13 PM12/22/12
to
spec...@gmx.de schrieb:
1) Because it's the wrong thing to do, IMHO.
2) Because we don't have the resources for that.

Robert Kaiser

Robert Kaiser

unread,
Dec 22, 2012, 7:34:43 PM12/22/12
to
Benjamin Smedberg schrieb:
> ** Disable the crash reporter for win64 builds

One possible alternative to that would be to put the build onto a
nightly-* channel (e.g. "nightly-win64") and not plain "nightly" - as
then Socorro will just ignore those in the stats while we'd still have
reports around for those who want to investigate them.

Robert Kaiser

realit...@gmail.com

unread,
Dec 22, 2012, 3:26:11 PM12/22/12
to mozilla.dev....@googlegroups.com, mozilla.dev.planning group, dev-apps-firefox List

byte...@gmail.com

unread,
Dec 22, 2012, 3:41:34 PM12/22/12
to mozilla.dev....@googlegroups.com, mozilla.dev.planning group, dev-apps-firefox List
On Saturday, December 22, 2012 3:26:11 PM UTC-5, realit...@gmail.com wrote:
> Couldn't you just make the migration optional? Forcing users to download a 32-bit version they obviously don't want given the feedback seems a little... bandwidth unfriendly, to say the least.

WaltS

unread,
Dec 23, 2012, 6:43:12 PM12/23/12
to
On 12/22/2012 03:41 PM, byte...@gmail.com wrote:
So you think *everybody* is going to download the 64-bit version again?

I sure wouldn't want to do my banking, credit card transactions, or any
other sensitive transactions on an experimental, non-supported test
build, be it a 64-bit or 32-bit build.

Unfortunately I get the idea that some are using it for production purposes.

--
Fedora 17 (64-bit) KDE 4.9.4
Thunderbird Release

chris.m...@bigpond.com

unread,
Dec 23, 2012, 10:14:36 PM12/23/12
to dev-apps-firefox List, mozilla.dev.planning group
I don't think that you have taken a rational approach to the decision of dropping Firefox64 at all. I will outline my reasons for this below....

1) 64 bit code is the future of computing - Mozilla should be dropping support for the 32 bit version as it is 'dead code', has the least longevity and is a drain on resources - 32 bit code is on its last legs and will be gone in the next few years. Why is Mozilla wasting time and resources on this? It is a more 'viable' option to put those resources into the development of Firefox64.
2) Security - 64 bit code brings better security. Running 32 bit code in a 64 bit OS causes a gaping security hole while it is running in compatibility mode - not even Microsoft recommend this approach because 'native code is far more secure'. In this case that means 64 bit code should be used not 32 bit.
3) Mozilla is further wasting resources with FirefoxOS - even if a miracle was to occur and it reached 0.1% it would still be a wasted effort - seriously what do you think FirefoxOS will achieve in the long run? I will tell you - NOTHING!
4) Those that think 64 bit is 'only for memory usage' or that '32 bit is good enough' have the wrong attitude for I.T and should be shown the door as they are only dragging you down. Mozilla needs to continue moving forward not embracing the past.
5) There is simply no valid reason given by Mozilla to drop support for the 64 bit version - all the reasons given (that I have read) would only make sense if they applied to dropping the 32 bit version.

I use Firefox64 simply because it is 64 bit, has better security, renders pages faster and crashes less often (for me the crashes are less). I have no issues with 64 bit plug-ins not being available as all the plug-ins I use are 64 bit already and have been for a few years now. Even game makes are porting their engines to 64 bit as they too can see the end in sight for 32 bit code.

Wayne

unread,
Dec 24, 2012, 9:20:54 AM12/24/12
to
> * win64 builds will be considered a “tier 3” build configuration. [1]
>
> We will continue to test the win32 builds and make sure that they work
> well on both 32-bit and 64-bit versions of Windows. Specifically, all of
> our testing on Windows 8 is planned to be done on the 64-bit version of
> Windows 8.
>
> I do hope that the projects and developers who are interested in win64
> will work together to maintain this build configuration. I am interested
> in hearing from volunteers who want to become the 64-bit build
> maintainer. I will also set up a discussion list specifically for win64
> issues, if that would be valuable.
>
> --BDS
>
> Please post followups to to mozilla.dev.apps.firefox
>
> [1] https://developer.mozilla.org/en-US/docs/Supported_build_configurations

This sounds appropriate and well reasoned. Thank you.

chris.m...@bigpond.com

unread,
Dec 23, 2012, 10:14:36 PM12/23/12
to mozilla.dev....@googlegroups.com, mozilla.dev.planning group, dev-apps-firefox List

kylet...@gmail.com

unread,
Dec 26, 2012, 8:16:31 AM12/26/12
to dev-apps-firefox List, mozilla.dev.planning group
I have to agree with Chris M, most major software makers, especially graphics and modelling, are starting to drop support for 32bit software. I don't even think they are many 32bit hardware systems even being built any more. Most new systems and operating systems are 64bit.

It's seems like a strange decision to stick with 32bit in light with current prevailing practices.

Just my two cents worth..

kyle...@gmail.com

unread,
Dec 26, 2012, 9:45:29 AM12/26/12
to dev-apps-firefox List, mozilla.dev.planning group
This is the type of heavy-handed decision making that caused me to abandon the official project for the Waterfox project over a year ago.

kylet...@gmail.com

unread,
Dec 26, 2012, 8:16:31 AM12/26/12
to mozilla.dev....@googlegroups.com, mozilla.dev.planning group, dev-apps-firefox List
On Monday, December 24, 2012 4:14:36 AM UTC+1, chris.m...@bigpond.com wrote:

kyle...@gmail.com

unread,
Dec 26, 2012, 9:45:29 AM12/26/12
to mozilla.dev....@googlegroups.com, mozilla.dev.planning group, dev-apps-firefox List
This is the type of heavy-handed decision making that caused me to abandon the official project for the Waterfox project over a year ago.

On Friday, December 21, 2012 4:43:25 PM UTC-5, Benjamin Smedberg wrote:

Gavin Sharp

unread,
Dec 26, 2012, 12:11:15 PM12/26/12
to kylet...@gmail.com, mozilla.dev.planning group, dev-apps-firefox
This discussion and proposal is really not about changing our development
focus (though a lot of people have tried to make it about that). This is
now very specifically about making our Nightly test audience focus on the
existing development focus (32 bit Windows builds), because testing builds
that aren't being worked on has proven to be a poor use of those resources.

Graphics and modelling software have different memory use constraints than
web browsing software in the common case, so it's not unexpected that they
would make different decisions about where to focus their development
efforts. The prevalence of 64bit hardware is just one factor, and its
really not a significant one given its compatibility with 32bit software.
https://groups.google.com/d/msg/mozilla.dev.planning/aeTXSZ_WFAs/BZITJLjhrAEJgoes
into more detail about the various factors that we've evaluated.

This decision does not mean that we're "sticking with 32bit" or "abandoning
64bit builds" long term; those characterizations represent an overly
simplistic view of a more complicated issue. Communicating these nuances
broadly is challenging, and so unfortunately (but perhaps not
unexpectedly), confusion and misunderstandings have pervaded this thread.

Gavin

Robert Kaiser

unread,
Dec 28, 2012, 10:15:51 AM12/28/12
to
realit...@gmail.com schrieb:
> Couldn't you just make the migration optional? Forcing users to download a 32-bit version they obviously don't want given the feedback seems a little... bandwidth unfriendly, to say the least.

Using Nightly in the first place is already bandwidth-unfriendly as it
gets updates daily and those also should be downloaded and installed daily.
And making it optional would be 1) way more work and 2) not effective at
our strategy of getting the vast majority of Nightly users back to
32bit, which is supported, and only have those on 64bit who realize it's
experimental and mostly unsupported (or not yet supported if you will).

Robert Kaiser

alex_mayorga

unread,
Dec 29, 2012, 11:20:29 PM12/29/12
to dev-apps-firefox List
Mr. Smedberg,

Personally I started using Nightly for win64 the moment my work OS was upgraded to be 64-bit a couple years ago.

I have never hit the 4GB memory limitation, but I stuck to those builds hopping I was somehow helping mozilla fix https://bugzilla.mozilla.org/show_bug.cgi?id=558448

The only plug-in I use is Flash, in general I believe plug-ins are bad for the open web so I try to stay away from them.

Now I commend you on reconsidering this and in the hopes of being constructive I'd like to volunteer to be the maintainer for the build if no one more fitting steps in. I use win64 because it is forced onto me at work, I'm a GNU/Linux kind of guy and mostly build things on UNIX like OSes (RHEL, Solaris, AIX) using shell scripts, Ant and Maven to pay the bills so I might need a lot of hand holding at 1st.

Regards,
Alex

alex_mayorga

unread,
Dec 29, 2012, 11:20:29 PM12/29/12
to mozilla.dev....@googlegroups.com, dev-apps-firefox List
On Friday, December 21, 2012 3:43:25 PM UTC-6, Benjamin Smedberg wrote:

realit...@gmail.com

unread,
Jan 5, 2013, 1:54:41 PM1/5/13
to
And that is user-unfriendly. As I said, the bandwidth usage is "the least". Effectively choosing such an option for the user counter to their deliberate choice to download a 64-bit variant which is already labeled unstable everywhere goes against every developer-bone in my body. It would be like SumatraPDF bundling Adobe Reader with its installer: it's giving the user a product they specifically did not choose. I can't condone such a move, regardless of the technical requirements of attempting to shift the userbase.

realit...@gmail.com

unread,
Jan 6, 2013, 2:37:42 PM1/6/13
to
Bandwidth usage does warrant its own response, though it may be a simple one - There is a giant difference between using and wasting bandwidth, as anyone on a limit like mine (12 GB per 30 days, a standard ratio of allowance on ANY satellite internet, and often much less due to incompetent usage tracking software and overzealous limit-enabling.) will attest. I choose to use my bandwidth downloading nightly variants of Firefox x64 because I think it's worth the usage. I would never choose to WASTE my bandwidth on a 32-bit version which in my personal use, is about as pointless as 16-bit, thanks to the amount of memory I regularly use in my own development work. The vital difference between me choosing to use up my bandwidth and it being wasted in an update I would never ask for is the same as the difference between me choosing to load anything over anything else - it's my bandwidth, my decision, my money, my time, and my computer. That you should have any say in the matter is beyond reproach.

jande...@gmail.com

unread,
Jan 23, 2013, 10:25:05 PM1/23/13
to dev-apps-firefox List, mozilla.dev.planning group
I have just started learning your source code, and the reason is that your browser is the only browser for Windows we can get a 64 bit version of Webgl working.
In our company, we produce some very large models in Webgl, and regularly exceed 6GB in Memory. To help our customers, we have decided on pushing FireFox into these corporations for the future use of our software (which is what produces these large models)

So yes, there are people out in the world that are starting to expect that these kind of memory limits are available, especially in the world of Cad/engineering graphics.

Because of the firefox being 64 bit available, we dropped Chrome in favour of FireFox when the models started breaking this kind of boundary.

Just thought I would let you guys know how someone else in the world is using your great software.

Cheers
Jason Anderssen

jande...@gmail.com

unread,
Jan 23, 2013, 10:25:05 PM1/23/13
to mozilla.dev....@googlegroups.com, mozilla.dev.planning group, dev-apps-firefox List

kron...@gmail.com

unread,
Jan 25, 2013, 10:00:23 AM1/25/13
to dev-apps-firefox List, mozilla.dev.planning group
it appears that x64 nightly builds have been stopped since 09JAN13 by neglect. a bug filed for the failure has been commented that someone who cares should fix it. the comments then go on to suggest that it should not be fixed because of the initial decision here to kill them & doesn't mention this thread where that decision was changed. looks like they prefer the propaganda that 'x64 was not killed, it just broke and we'll fix it some date in the future when we get around to it' to 'we killed x64 because we don't think anyone needs it.' the break doesn't affect the x86 32-bit builds so no one is bothered.

Benjamin Smedberg

unread,
Jan 25, 2013, 11:26:32 AM1/25/13
to kron...@gmail.com, dev-apps-firefox List
On 1/25/2013 10:00 AM, kron...@gmail.com wrote:
> it appears that x64 nightly builds have been stopped since 09JAN13 by neglect. a bug filed for the failure has been commented that someone who cares should fix it.
Can you provide the bug number?

I don't know the exact situation, so I can't comment specifically.

As noted in my original email Win64 is now considered a tier-3 build
configuration. This means that module owners are not required to fix or
back out changes which break the win64 build: this is the responsibility
of the port maintainer or other people from the community who want to
provide patches. Modules owners *should* accept patches which fix win64.

--BDS

kron...@gmail.com

unread,
Jan 25, 2013, 10:00:23 AM1/25/13
to mozilla.dev....@googlegroups.com, mozilla.dev.planning group, dev-apps-firefox List

alex_mayorga

unread,
Jan 25, 2013, 5:16:10 PM1/25/13
to kron...@gmail.com, dev-apps-firefox List
On Friday, January 25, 2013 10:26:32 AM UTC-6, Benjamin Smedberg wrote:
Mr Smedberg,

The bug I followed for the missing Nightly win64 updates is https://bugzilla.mozilla.org/show_bug.cgi?id=829738

The root cause and fix is apparently https://bugzilla.mozilla.org/show_bug.cgi?id=830676

Regards,
Alex

alex_mayorga

unread,
Jan 25, 2013, 5:16:10 PM1/25/13
to mozilla.dev....@googlegroups.com, kron...@gmail.com, dev-apps-firefox List
On Friday, January 25, 2013 10:26:32 AM UTC-6, Benjamin Smedberg wrote:

kron...@gmail.com

unread,
Jan 26, 2013, 3:12:52 AM1/26/13
to kron...@gmail.com, dev-apps-firefox List
it's OK - someone got around to fixing it. nightly x64 is again in amongst the x86s again. fixing the pgo also fixed the nightlys. i was a bit frustrated at some of the comments in the bug implying lack of concern & the two-week plus time. now moot. thanx for the reply.

kron...@gmail.com

unread,
Jan 26, 2013, 3:12:52 AM1/26/13
to mozilla.dev....@googlegroups.com, kron...@gmail.com, dev-apps-firefox List
On Friday, 25 January 2013 16:26:32 UTC, Benjamin Smedberg wrote:

Al

unread,
Feb 5, 2013, 5:22:53 AM2/5/13
to dev-apps-firefox List, mozilla.dev.planning group
I modified your plan for better security:

> * Migrate all existing users of win32 nightly channel builds to the
> win64 nightly channel builds via automatic update.
>
> * Discontinue to build win32 Nightly builds and updates on the nightly
> channel. Users who need the 32-bit builds will have to build it after
> the migration point (date TBD).
>
> ** Change the default first-run and update page for win32 builds to
> explain to users that they are insecure and thus not supported.
>
> ** Enable click-to-play plugins by default in all builds.
>
> * Discontinue the win32 tests and on-checkin builds to reduce release
> engineering load. By default, do not generate win32 builds on try.
>
> * win32 builds will be considered a "tier 9" build configuration. [1]

I'm not kidding. ASLR is easy to defeat in a 32-bit process.
You simply don't have enough bits to do a half-way decent job.
Heap spraying is trivial in a 32-bit process, especially when
the OS has more physical RAM than the process has virtual memory.

Al

unread,
Feb 5, 2013, 5:22:53 AM2/5/13
to mozilla.dev....@googlegroups.com, mozilla.dev.planning group, dev-apps-firefox List

arm...@gmail.com

unread,
Apr 2, 2013, 11:00:19 AM4/2/13