johnp_

Why not just keep the testes?

https://www.parsemus.org/projects/calcium-chloride/

Two intratesticular or intraepididymal shots are far cheaper and so much less invasive than two surgeries.

Or it looks like avl, depending on the font...

> * for those settings where it makes sense to sync.

What makes sense for one person may not make sense for the next. That's why it's configurable: https://developer.mozilla.org/en-US/docs/Archive/Mozilla/Fir...

If `extensions.pocket.enabled` doesn't sync (I don't know if it does by default), consider adding `services.sync.prefs.sync.extensions.pocket.enabled`, then it will synchronize across devices.

Bookmark sync is currently getting a complete overhaul to fix the various shortcomings: https://docs.google.com/document/d/1WoM7JEatr_QJ1CrGk2rwoSDy...

FWIW, this recently landed in Firefox Nightly:

security.insecure_connection_icon.enabled

security.insecure_connection_icon.pbmode.enabled

Though it's still disabled by default (currently the insecure connection icon is only shown if a password field is present on a http page / the form action url is http).

Landed ~5 days ago:

https://hg.mozilla.org/mozilla-central/rev/db56323cd08f

Profiles: Every configuration change or extension has to be added in every profile to keep in sync manually across different Firefox instances.

Containers: Use the same configuration and extensions across different containers in one running Firefox instance.

Both retain configuration and extensions between traditional browser sessions (start/stop). Containers additionally "retain" configuration and extensions across contextual sessions/identities.

It was apparently a live-document (like etherpad) and the intention was get feedback directly in-line if I understood correctly. Not an unusual way of doing things for an engineer.

As far as I have been able to put things together as a non-Googler he went to an unrecorded "diversity summit" about a month and 1/2 ago, where, according to his statements in the Jordan Peterson interview, practices where put forward that he considered to be potentially illegal. He then wrote the document in his free time and posted it to a forum dedicated for feedback to the summit (? or more general diversity related). After engagement has been nothing to low he also posted the memo to an internal Google Group called "Skeptics" because he wanted to be proven wrong. Shortly after that the memo was leaked to the public (either without citations or the citations were then removed by the respective media), indicating that someone from this community did so.

I'd appreciate if someone could confirm/deny or add anything to this timeline.

Definitely unreasonable reading. Could you explain how you got from the two quoted propositions to your interpretation?

The first bullet point exemplified: Let's say there's a job that requires trait openness / empathy to a certain degree (e.g. early education). Now, some given statistics show that e.g. 40% of the female population and 20% of the male population have this manifestation of the trait to the required degree. Would you still expect a 50/50 male/female representation in the field? The author makes the argument that, if the statistics he found are correct, he wouldn't expect a 50/50 split.

The second bullet point just says that discrimination for the sole sake of said equal representation is bad for business, because given the above it would have to be necessarily unmeritocratic. I would contest this point in a sense that individual merit is not the sole factor at which to look, because it is only a single factor in group success, where the availability of diverse ways of thinking and social compatibility also play major roles.

Linux users have a lower priority and there are some hard to debug issues with graphics drivers and sometimes it causes horrible performance and freezes.

https://bugzilla.mozilla.org/show_bug.cgi?id=ogl-linux-beta

Where do you get the impression of e10s not working with the current code base? It works pretty great for me with 10+ processes and ~20 add-ons and is already enabled for ~50% of the Firefox population (though with more conservative defaults with the other half mainly blocked on add-on compatibility). There's no maintaining Firefox as it is and integrating Servo (which btw already works quite good on Nightly and webrender is also making great strides). The Rust language actually does help immensely because it makes developing Servo and other rust components way easier. Implementing servo in C++ would have likely taken longer and would definitely have been a maintenance nightmare.

Why not switch to Firefox Beta to get those improvements immediately? With the removal of the aurora channel, Mozilla is trying to get more people on the beta train, that now is the only stabilization phase between Nightly and Release. As a die-hard Nightly user I usually install the Beta (x64) version for other users and, depending on the add-on compatibility, enable e10s or some other features (e.g. TCP Fast Open) that may already be in A/B testing. Right now it makes an amazing difference in user satisfaction.

DKIM solves authenticity and integrity, but not privacy.

Recently all toolbar icons in Firefox have been converted to SVGs [1] and in the process several performance problems were found and fixed or are in the process of being fixed [2]. You may want to try out a recent Nightly build.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1347543 [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1054016

c) Support for direct debit instead of having to use PayPal when one doesn't own a credit card

> It only takes a single incident like Heartbleed, Shellshock, Backblaze or whatever to render a formerly assumed secured component or protocol insecure.

Yes, just as your firmware verification and update mechanism and every other interface your device provides to the outside world. That's just a general argument against feature creep.

> [...] so what value does HTTPS provide in those cases?

Defense in Depth.

> [...] provide a security risk in itself [...]

Just like any other component. I'd argue that a slimmed down , globally deployed implementation of a several decades battle-tested protocol has a lower security risk than some vendor specific, device specific, single-developer self-designed integrity and authenticity scheme.

Overall, if your IoT device handles any potentially confidential user data at all you already need a TLS stack, so enabling it for the firmware update mechanism doesn't add any more of an attack surface.

If you only ever need authenticity and integrity HTTP is already more complex than necessary and you'd be better served with a simpler protocol. (e.g. CoAP)

There's a TLS 1.2 Long Term Support draft in the works, specifically for those devices with "multi-year or even decade-long update cycles":

https://tools.ietf.org/html/draft-gutmann-tls-lts-07

Martin Stránský (Red Hat) is working on native Wayland support for Firefox and the build time option should land soon (already r+'d), allowing his other patches to be integrated.

https://github.com/stransky/gecko-dev https://bugzilla.mozilla.org/show_bug.cgi?id=635134

IIRC LibreOffice should already be running natively on Wayland. (also a Red Hat effort in mid-2015)

https://caolanm.blogspot.com/2015/07/libreoffice-on-wayland....

Many good answers already, but I want to mention RISC-V Boom (superscalar, out-of-order), which seems to, in theory, beat ARM Cortex A9 quite nicely:

https://www.youtube.com/watch?v=HVPSlS2v1F0

The whole toolchain they are working with looks quite awesome tbh.

Commercially, the Freedom U500 platform seems to be really interesting:

https://dev.sifive.com/documentation/freedom-u500-platform-b...

The logic gate's primary function seemed to be in limiting the paddle to not move outside of the playing field.

Otoh, in a visual programming language it'd feel more natural to make the upper and lower edges of the playing field collidable (I'm sure there's a better word for that), so that moving the paddle is inherently limited by collision with the edges.

It should be noted that some of those features can be disabled via environment variables:

https://developer.mozilla.org/docs/Mozilla/Benchmarking

Specifically, I use those environment variables:

JS_OPTION_USE_UNBOXED_ARRAYS=1

JSGC_DISABLE_POISONING=1

There's at least one other thing (async stack) that I'm aware of that may be tunable:

https://bugzilla.mozilla.org/show_bug.cgi?id=1280819

edit: just figured out that that's "javascript.options.asyncstack", so I set it to disabled on nightly too.

Fwiw, the unboxed objects bug is: https://bugzilla.mozilla.org/show_bug.cgi?id=1153266

edit: typedobj performance improvements visible at the bottom of https://arewefastyet.com/#machine=28&view=breakdown&suite=mi...

edit: removed MOZ_QUIET=1, as a source inspection reveals that it is only compiled #ifdef DEBUG.

Firefox originally had a preference for that, but they moved it to CSS, so you can modify it via an addon or with userchrome.css:

http://kb.mozillazine.org/Browser.tabs.tabMinWidth

Shameless plug of `loc`, a rust implementation of `cloc` that is 100+ times faster:

https://github.com/cgag/loc

Still possible:

security.tls.version.min security.tls.version.max

security.ssl3.<cipher_suite>

You might like LeechBlock:

https://addons.mozilla.org/en-US/firefox/addon/leechblock/

I really like it, I just haven't come around to configuring it yet...

Could you please refer to the actual Issue? I can neither find anything related to the CA/B-Forum voting fraud nor to the yet unresolved Qihoo relationship.

Thank you, though the Qihoo relationship is not what I was referring to.

I actually meant executing two votes in the CA/B Forum. As the connection between WoSign and StartCom was only incidentally found while investigating the other issues, I am questioning if there may be more dark sheep in the herd of CAs... we may just haven't looked hard enough. Do the Audit Requirements include checking for such relationships?

I remember that there was some talk about double voting (WoSign and StartCom not being separate entities, but voting with two votes) in the mailing list. Is there a reason as to why this event hasn't been included in the document?

edit: https://groups.google.com/forum/#!topic/mozilla.dev.security...

> "In no case were these the deciding votes."

PSA: The Firebug you know (version 2) is incompatible to e10s and there will be no e10s-compatible Firebug 3. Instead, Firebug.next is built-into Firefox(!):

https://blog.getfirebug.com/2016/06/07/unifying-firebug-fire...