mckilljoy

I just started reading this book, maybe half way through, it's very interesting!

Some of the technical analogies are a little weak, but all the quotes and anecdotes are great.

Redex runs at compile time, not at install time.

25-30% is a pretty solid improvement.

I just skimmed through some of those Glassdoor reviews. They were all quite positive, but I find it interesting that the vast majority were posted Feb-Mar 2016.

Yea that's fair. I was actually thinking of timer coalescing on the server OS for improved power efficiency/performance -- I'm sure IIS, MSSQL, etc. all opt-in to coalescing responsibly.

It sounds like the OSX version is more of a "forced timer coalescing" feature.

As others are saying, Microsoft is a very large company with a great deal of variance in the quality and maturity of teams. I wouldn't consider this description representative.

Azure is still a comparably new team, so I'm not surprised if it is still sorting out its processes. I've hear similar descriptions of Bing teams, and other "startup" divisions in the company.

But there are definitely some brutally effective teams there that far outshine any other non-Microsoft team I've ever seen.

That was my first thought too -- Windows has had timer coalescing since at least 2008, if not longer.

This looks like the kind of product that will do well in San Francisco -- SF is where the venn diagram of "dog owners" and "gadget owners" overlap.

At first I thought was going in a bad direction, but it actually ended up pretty cute.

Basically they asked women if they thought they were beautiful, and if they said "Yes!" they got their meal for free -- it was actually rewarding self-confidence rather than perceived physical beauty.

I like reading these analyses, although I'm afraid headlines like this oversimplify things and give off the wrong impression. There isn't anything inherently wrong with NUMA, it just isn't useful in this situation.

No technology is a 'silver bullet'. Every workload has a different set of considerations that require a different set of technology to optimize.

I agree for this one integer, they obviously should have been using 64-bit. I just take issue with the implication that Blizzard is somehow at fault or unusual for (presumably) not running a 64-bit stack.

They made a mistake for sure, but 32-bit vs. 64-bit architectures should not be on trial.

At the time the original code was written, it wasn't possible for a 32-bit integer to overflow, which is presumably why they didn't use 64-bit. That possibility was only introduced in the patch, and no one caught the bug that came with it.

Running 64-bit would have "prevented" this bug simply by virtual of that fact that the default datatype would have been big enough to avoid overflow, but it isn't really a solution. I just find 32-bit vs. 64-bit to be inconsequential to the real mistake, which was an improper software development process.

A x64 CPU will take a single instruction to operate on a both a 64-bit and 32-bit integer, and the CPU registers are all 64-bit, so in that context you are right that it doesn't matter that much between the datatypes.

However, the physical size of the integer as stored in the CPU cache, RAM, and HDD is still going to be 2x as big for a 64-bit integer. In a hypothetical worst case, you are cutting your CPU cache and memory bandwidth in half, which is tragic.

Additionally, while most physical servers are x64, the OS, server software, and virtualization layer is still often 32-bit -- maybe for legacy, maybe for performance, maybe for a lot of reasons. Upgrading that whole stack up to 64-bits just for the luxury of having default 64-bit integers seems misguided.

Depends on the situation.

I assume this was probably a server side bug, since all the accounting would never be trusted to the client side.

If you are writing highly-performant server code, the actually memory size is extremely important. You cannot (should not) abstract away the machine specifics of the datatype if you want to write optimized code.

In some cases where the underlying datatype isn't a concern (e.g. Javascript), I agree with you. But ultimately, this isn't a failure of technology, it is a failure of the software development process.

I don't find it that odd. 32-bit applications are still very common, if not the standard. Most processes don't need more than 4GB.

More importantly, blindly increasing all of your 32-bit integers to 64-bit is going to double your memory usage, and ultimately just mask the real issue (i.e. improper bounds checking).

I can say from personal experience that the customers are probably a bit of both. Engineers walk through looking for parts for their prototypes, and then once the prototypes are complete, come back and set up a contract for 1,000's more of the exact same part for the production run.

To me, that is the real benefit. In America, you can make your prototypes with parts from Digikey or Fry's, but if you actually wanted to make a production run, you have to source all your parts from scratch.

Selling debt to buy back their stock looks like a pretty safe bet. Most of the debt is starting off below ~2.5% interest -- using that to buyback the stock paying ~3% dividends is immediately saving themselves money, in addition to reducing dilution and propping up the stock price.

I'd agree, most of these numbers are "fuzzy" and based on analyst estimates; I'd almost be more surprised if they DID perfectly add up to 100%. :-)

It seems pretty reasonable to me. If Msft makes $1 billion on 20% of the market, and Amzn makes $3.8 billion (high-end analyst estimate) with 71% of the market, the math roughly matches.

That looks pretty significant. Amazon Web Services are somewhere between $2 and $3.8 billion (depending on which analyst you believe), so Microsoft is potentially within striking distance of taking the crown.

Weird, I always thought they were one of the popular sites.

Obviously everyone's health situation differs, but my health insurance experiences have been similar to MMM's. For an 'average' person/family, health insurance shouldn't be breaking the bank (e.g. $200-300 per month).

I've heard of some realistic pre-existing health conditions that required $600+/month for specialty meds, but if that $7000+ per year is enough to make the difference in your 'retirement', it wouldn't be too bad to get a part time job to cover your cost.

'In my opinion, the most important question on the Y Combinator application, is this one: “Please tell us about the time you most successfully hacked some (non-computer) system to your advantage.”'

Not a criticism per se, but pg recently said that is actually one of their LEAST ("not in the top 10") important questions.