dm_mongodb

this in no way effects whether one is trusted for payments.

i can imagine reasons why apple would want or need to be able to update secure enclave firmware without the correct pin entered first. #2-3 are highly speculative:

1) fear of a bug. just the right firmware bug and you have 100 million phones lose data, and perhaps bricked too. unlikely, but consider the cost. i would be worried about this if i were in charge of the iphone project and the secure enclave feature were newish. we can imagine pretty good solutions to this one though, with work and time.

2) out of 100+ countries where they sell phones, over time, some will give them a confidential court order saying they must retain this capability. if a foreign court order, they could refuse to comply, but then would have to exit that market -- infeasible if multiple countries. and a different 'version' for just those countries would be noticed over time by security researchers?

3) they might already have an order as such from the U.S., for foreign intelligence purposes. as mentioned a different international version if noticed is a PR disaster for apple. so the easiest way to comply is just do it that way for all phones.

perhaps they push back on the fbi request because that's the one they can talk about, yet it templates the whole issue.

I don't understand. Can someone please clarify for me. They physically have the phone right? Could they not just read the whole flash, try a pin, write back the whole flash, repeat? (i.e. take the phone apart)

(given it is a 5C with no secure enclave)

please tell me most people aren't this silly when they interview folks.

have the carpenter build something (of trivial scope) while you watch. somewhat analogous to coding on the whiteboard in the interview.

come to think of it, it might be darn hard to interview carpenters. but if you watch them work for 2 hours you know everything.

SSL support is in the free distribution but you must built it yourself. One reason would be export controls; another is that creates a dependency on the SSL library for those who don't use SSL, which we found awkward (especially if doing all platforms; the subscriber build just does the popular ones).

So it's available; albeit there is an intent to have a subscriber build with some extra features that are heavily enterprise biased in their usefulness.

re #2: looking at the source code I don't see this behavior. Perhaps in a version from the past? Anyway, please advise or point me to a jira...

In src/mongo/db/db.cpp I see:

    void _initAndListen(int listenPort ) {
        ...
        dur::startup(); // <- this i believe preallocs journal files
        ...
        listen(listenPort); // after journal prealloc i think

p.s. this blog post is a very interesting article overall i think, without commenting on all the specifics...

can you create a Jira ticket for #2 if that is happening it should be easy to fix. jira.mongodb.org

it seems to me that the exchange adding a small random delay (say 1ms) on message reception would dampen the benefits of speed and then there would be less work invested in saving a few microseconds here and there. you still have program trading but a little bit of silly dynamics is dampened.

Goal 1 of the financing was funds to accelerate r&d, to hire engineers to do things like the ones you mention above; in addition more r&d just pushing hard to maximize overall product quality, stability, etc. not sure if those exact things will get done and exactly when yet. I'd definitely like to see the solaris build get some attention. dwight/10gen

i think so yes

obviously there will be a new ceo at some point. time passes.

it will not be schmidt.

it's new.

I imagine Knuth's first version of Tex was pretty darn fast even without 'optimizing'.