Re: Moving XP to ESR?

Hi Am 18.04.2016 um 20:02 schrieb Chris Peterson: > On 4/18/16 6:46 AM, Thomas Zimmermann wrote: >> Am 18.04.2016 um 15:18 schrieb Kyle Huey: >>> > 12% of our users are on Windows XP. >> And XP still runs on ~10% of all desktops. That's an opportunity to >> con

Re: Moving XP to ESR?

Am 18.04.2016 um 15:18 schrieb Kyle Huey: > 12% of our users are on Windows XP. And XP still runs on ~10% of all desktops. That's an opportunity to convert some of the users to Firefox. Best regards Thomas > > - Kyle > > On Mon, Apr 18, 2016 at 6:04 AM, Henri Sivonen

Re: SharedArrayBuffer and Atomics will ride the trains behind a pref

Hi, I saw the lightning talk you gave in Orlando in this topic. I was wondering if you considered implementing Transactional Memory for SharedArrayBuffer. JS seems like the perfect environment for TM. Are there reasons for 'only' providing atomic ops? Just asking out of curiosity... Best regards

Re: SharedArrayBuffer and Atomics will ride the trains behind a pref

Thanks! Am 14.01.2016 um 15:08 schrieb Lars Hansen: > On Thu, Jan 14, 2016 at 2:49 PM, Thomas Zimmermann <tzimmerm...@mozilla.com> > wrote: > >> Hi, >> >> I saw the lightning talk you gave in Orlando in this topic. I was >> wondering if you consi

Re: Dan Stillman's concerns about Extension Signing

Hi Am 27.11.2015 um 16:50 schrieb Gavin Sharp: > On Fri, Nov 27, 2015 at 7:16 AM, Gervase Markham wrote: >> But the thing is, members of our security group are now piling into the >> bug pointing out that trying to find malicious JS code by static code >> review is literally

Re: Dan Stillman's concerns about Extension Signing

u get. Best regards Thomas > > Gavin > > On Mon, Nov 30, 2015 at 10:30 AM, Thomas Zimmermann <tzimmerm...@mozilla.com >> wrote: >> Hi >> >> Am 27.11.2015 um 16:50 schrieb Gavin Sharp: >>> On Fri, Nov 27, 2015 at 7:16 AM, Gervase Markham <g...@mozill

Re: Dan Stillman's concerns about Extension Signing

Hi Am 26.11.2015 um 18:13 schrieb Mike Hoye: > Stillman wrote some new code and put it through a process meant to > catch problems in old code, and it passed. That's unfortunate, but > does it really surprise anyone that security is an evolving process? > That it might be be full of hard

Re: Dan Stillman's concerns about Extension Signing

Am 26.11.2015 um 18:14 schrieb WaltS48: > Perhaps you missed. > > Add-ons/Extension Signing - MozillaWiki - > > > I've noticed a couple new items there about how an extension developer > can get their extension signed if it isn't hosted on

Re: Dan Stillman's concerns about Extension Signing

Am 25.11.2015 um 20:16 schrieb Jeff Gilbert: > On Wed, Nov 25, 2015 at 3:16 AM, Till Schneidereit > wrote: >> FWIW, I received questions about this via private email and phone calls >> from two people working on extensions that support their products. Their >>

Re: Dan Stillman's concerns about Extension Signing

Hi Am 26.11.2015 um 13:56 schrieb Till Schneidereit: > I read the blog post, too, and if that were the final, uncontested word on > the matter, I think I would agree. As it is, this assessment strikes me as > awfully harsh: many people have put a lot of thought and effort into this, > so calling

Re: Dan Stillman's concerns about Extension Signing

Hi, I haven't followed the overall discussion closely, but I'm very concerned about this change and that we're driving away extension developers. I hope that some of the relevant people read this thread, as I'd like to propose a different strategy for extension signing. 1) As dburns mentioned in

Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++

Hi Am 16.07.2015 um 00:47 schrieb Jeff Gilbert: On Tue, Jul 14, 2015 at 7:55 AM, Thomas Zimmermann tzimmerm...@mozilla.com mailto:tzimmerm...@mozilla.com wrote: The discussion has a number of good points in favor of using 'a', but I missed convincing arguments in favor

Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++

Hi Am 14.07.2015 um 16:19 schrieb Joshua Cranmer : On 7/14/2015 1:39 AM, Thomas Zimmermann wrote: When writing code, I consider it good style to not write into anything that starts with an 'a' prefix, except result arguments. You should never write into something with an 'a' prefix except

Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++

Hi Am 13.07.2015 um 21:07 schrieb Jeff Gilbert: On Sun, Jul 12, 2015 at 6:45 PM, Thomas Zimmermann tzimmerm...@mozilla.com mailto:tzimmerm...@mozilla.com wrote: Am 08.07.2015 um 16:36 schrieb smaug: Do you actually have any data how many % of Gecko devs would prefer not using

Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++

Am 08.07.2015 um 16:36 schrieb smaug: Do you actually have any data how many % of Gecko devs would prefer not using aFoo? I strongly prefer 'aFoo' over 'foo' for the extra context that it gives to the variable. If we want to change anything we should rather introduce a separate prefix for

Re: prebuilt libraries?

Hi Gregory Please read http://www.conifersystems.com/whitepapers/gnu-make/. That is one of my go to articles for explaining why make sucks. I would not point people to this article as it is flawed. I won't go through the points it mentions. Some are relevant, others aren't, and some probably

Re: prebuilt libraries?

Hi Michael, Thank you for providing more information on the topic. [1] http://gittup.org/tup/build_system_rules_and_algorithms.pdf That was an interesting read and the numbers are quite impressive. However I'm skeptical of the overall approach, as it seems to require a considerable amount of

Re: The worst piece of Mozilla code

Hi, this mail made me laugh, because I can tell very similar stories with different examples. (Not sure if :) or :( ) On the positive side, I think we got a lot better since then by both, fixing broken designs and code, and also applying learned lessons to new sub-systems. Best regards Thomas

Re: Oculus VR support somehwat-non-free code in the tree

Hi 1. Check in the LibOVR sources as-is, in other-licenses/oculus. Add a configure flag, maybe --disable-non-free, that disables building it. Build and ship it as normal in our builds. '--with-non-free' But actually I'd support the option of keeping the SDK separated and dlopen'ing the

Re: B2G emulator issues

Hi That is what the emulator is already doing. If we start emulating HW down to individual CPU cycles, it'll only get slower. :( I think this is wrong in some way. Otherwise I wouldn't see this: 1) running on TBPL (AWS) the internal timings reported show the specific test going from 30

Re: B2G emulator issues

Hi, Thanks for bringing up this issue. One option (very, very painful, and even slower) would be a proper device simulator which simulates both the CPU and the system hardware (of *some* B2G phone). This would produce the most realistic result with an emulator. That is what the emulator

Re: Booting to the Web

Hi, There is nothing special about FFOS thread scheduling that I'm aware of. Threads are implemented by the underlying Linux kernel and are scheduled by the kernel itself. We use an Android kernel, so thread scheduling on FFOS is affected by wake locks. I don't know if we use cgroups* or nice

Re: Rethinking build defaults

On 16.08.2013 16:23, Andrew McCreight wrote: - Original Message - I think the key argument against this approach is that system components are never truly isolated. Sure, some of them can be compiled out and still produce a working system. That doesn't mean that testing without those

Intent to implement: nsIDOMMozIccManager.getCardLockRetryCount

Hi, I intent to implement an extension to nsIDOMMozICCManager. When unlocking a SIM card, there is a maximum number of remaining tries. The new interface 'getCardLockRetryCount' will allow for reading the number of remaining tries for a specific lock. During the unlock process, an app can