Re: Google announces Chrome builds for Win64
Hi folks. I should introduce myself first. I'm a new product manager working on Firefox for Desktop. I've been working on an assessment of launching 64 bit for about 6 weeks. In that time, I've had conversations with representatives from every engineering and QA team whose work would be required to launch and support 64 bit, as well as strategy and marketing team members. We have a good understanding of the work required. The development work, as you might suspect, is largely done. We still produce 64 bit builds. The notable areas remaining are: - completing test coverage - working on plugin/add-on compatibility - writing/updating the installer - automating/augmenting/reallocating QA resources to support the additional QA needs on an ongoing basis, and - some open product questions around how we roll it out, how we announce and promote it, etc. That's just the work, it is known and straightforward, though not trivial. Choosing to advance 64 means putting something else on hold. Therefore, we are also looking at the reasons to launch 64 bit. There are user reasons to do this, and there are Mozilla innovation reasons to do this. We have also been watching industry estimates of 64 bit Windows adoption, because we need to understand how many users would benefit from 64 bit. The overwhelming majority of Internet users could neither tell you what 64 bit means, nor will they have seen Google's announcement. Still Chris, you're absolutely correct. Many of the Mozilla faithful and industry watchers may think we're reacting to Google. The bug is here: https://bugzilla.mozilla.org/show_bug.cgi?id=1007726. We actually began informal conversations a few weeks before I entered the bug. The Mozilla community and press will hopefully take that into consideration in judging our intent, but it's important for us to get our timing right than to try to win at the PR race. Remaining on par with other browsers is a big consideration in launching 64 bit, but as I mentioned above, the primary drivers must be because it's better for users, because it allows Mozilla to advance the browser innovations we've already been working on, and above all that the user base is willing and able to take advantage of it. Above all, I want to reassure you we are being methodical about the timing and planning of 64 bit. We don't have the resources other companies have, and a decision to advance one area means putting another on hold. Lastly, 64 bit is exciting. I'm glad we're having these conversations, and Ive been thrilled to be able to work on it. I will update that bug ticket above in the near future, and we'll keep the community notified when things start moving. Thanks, Javaun Moradi On Tuesday, June 3, 2014 3:51:36 PM UTC-4, Ehsan Akhgari wrote: > On 2014-06-03, 2:37 PM, Chris Peterson wrote: > > > http://blog.chromium.org/2014/06/try-out-new-64-bit-windows-canary-and.html > > > > > > What is the status of Firefox builds for Win64? When Mozilla releases > > > Win64 builds (again), we'll be seen as reacting to Google when we've > > > actually been working on it for a while. :\ > > > > I believe dmajor is either working on this, or is aware of the plans. > > > > Cheers, > > Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Google announces Chrome builds for Win64
Great point Brian, I should've mentioned the relation to E10S and sandboxing because as you suggest, it's complicated. - E10S and sandboxing help 32 bit users as well as 64 and arguably offer the most immediate relief to the most users experiencing stability issues. Most of the folks I spoke with recommended tackling both of those before 64 if it comes to that. - E10S and sandboxing are also more complicated and have a much longer time horizon to launch. Launching 64 bit first may be a stability bandaid for users who have 64 bit and adequate memory. It's also security boost for 64 bit users. - Plugin work, as BDS says, is "hard and weird". E10S and 64 compete for the same engineers here. - Add-ons are going to break in both projects. We need to take the developer community's pain into consideration. Those are some big considerations to weigh in resource planning, product, developer community, and especially in engineering. This feels like the start of that conversation... On Wednesday, June 4, 2014 1:32:48 PM UTC-4, Brian Smith wrote: > On Tue, Jun 3, 2014 at 11:37 AM, Chris Peterson > > wrote: > > > > > http://blog.chromium.org/2014/06/try-out-new-64-bit-windows- > > > canary-and.html > > > > > > What is the status of Firefox builds for Win64? When Mozilla releases > > > Win64 builds (again), we'll be seen as reacting to Google when we've > > > actually been working on it for a while. :\ > > > > > > > Does it make sense to ship 64-bit Firefox before shipping > > mutli-process/sandboxed Firefox? I worry that 64-bit Firefox will be more > > memory hungry than 32-bit Firefox and if it lands first then it will be > > harder to land multi-process Firefox which is also likely to use more > > memory. I think having multi-process sooner is more important than having > > 64-bit sooner, if there is such a choice to make. IMO, it would be good to > > make explicit choices instead of just shipping whichever is done first. > > > > Cheers, > > Brian ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Google announces Chrome builds for Win64
These are two good questions Robert. Both points are nuanced and merit more discussion. 1. Re: 64 bit as a bandaid for OOM. This is an alternate viewpoint that a few folks advanced for discussion. I assumed this meant (at the least) PCs with > 4GB physical memory. I'm not sure if this applies to virtual memory. In addition to understanding the exact scenarios this might mitigate, ideally we'd have crashstats data to help us understand how big each of those scenarios is. 2. Re: Security. As Ryan said, it's about high-entropy ASLR in Windows 64 bit. I have a neophyte's understanding of JIT Sprays, this helped: http://blog.cdleary.com/2011/08/understanding-jit-spray/. Again, it would be nice to understand the magnitude of this particular threat. On Thursday, June 5, 2014 11:34:21 AM UTC-4, J. Ryan Stinnett wrote: > On Thu, Jun 5, 2014 at 10:03 AM, Robert Kaiser wrote: > > >> It's also security boost for 64 bit users. > > > > > > > > > Could someone please explain why you and Google claim 64bit to be more > > > secure? This is a new argument to me and I wonder what's behind it. > > > > As stated in Google's announcement[1], the main security improvement > > is (better) address space layout randomization. Even though that > > exists in 32 bit too, it's more effective with 64 bit since the VM > > space is so much larger. Looks like Windows has a specific "high > > entropy"[2] version that's 64 bit only. > > > > [1]: > http://blog.chromium.org/2014/06/try-out-new-64-bit-windows-canary-and.html > > [2]: > http://blogs.technet.com/b/srd/archive/2013/12/11/software-defense-mitigating-common-exploitation-techniques.aspx > > > > - Ryan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: BzAPI Compatibility API has been rolled out to production BMO
This is terrific! The docs make mention of POST under bz_rest_options. Do you now (or will you at some point) support bug creation via API? Would you do full CRUD at some point? I'm excited to tinker with this. I'd guess REST support will eventually lead to more creative interfaces on top of Bugzilla. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
