Some of the technical analogies are a little weak, but all the quotes and anecdotes are great.
233 karma · joined October 10, 2008
Some of the technical analogies are a little weak, but all the quotes and anecdotes are great.
It sounds like the OSX version is more of a "forced timer coalescing" feature.
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.
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.
No technology is a 'silver bullet'. Every workload has a different set of considerations that require a different set of technology to optimize.
They made a mistake for sure, but 32-bit vs. 64-bit architectures should not be on trial.
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.
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.
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.
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).
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.
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.
Not a criticism per se, but pg recently said that is actually one of their LEAST ("not in the top 10") important questions.
Their software doesn't really look like a "competitor" to Alibaba though. It looks more like something you'd use in tandem with the Alibaba marketplace to better keep an eye on your supplier.
But I got a call earlier today from my less tech-savvy buddy who was freaking out because his GoDaddy website was down. Yea it is probably "his fault" for choosing them, and he probably "deserves it".
Still, not everyone is born a leet computer hacker, and sometimes this is the only way people will learn, so I'm trying not to be too hard on people for that.
Additionally, cures by their nature will always lag behind diseases, people won't invest resources curing a disease that doesn't exist. A non-trivial amount of damage would occur before society reacted to the threat.