HN user

mckilljoy

233 karma
Posts16
Comments68
View on HN
Asana 10 years ago

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.

Fitbit for Dogs 13 years ago

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.

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.

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.

I don't use GoDaddy, nor do I particularly like them, so this doesn't really affect me or my business directly.

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.

Karma is Real 14 years ago

Those 'single transactions' start to be a lot more important the closer you get to your bill deadlines! People tend to be a lot more generous after the 1st of the month has past :-)

I'd disagree, I think it is a lot easier to create a virus that wantonly destroys life than it is to create a cure that puts everything back together. I could email out a script that just executes "sudo rm -rf /" on everyone's computer, and it would probably ruin a lot of people's lives.

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.

I like how this summarized the state of the industry, but I feel like "the cloud" angle was a bit forced for a lot of those companies. Most of these companies had nothing to do with the internet / cloud.