azim

One of the major fears every company faces today is patent trolls. Regardless of whether you are in the right or not, a patent infringement lawsuit will be an immense cost to fight. Opening up internal source code or having public record of which tools/libraries you use by contributing back to them significantly increases the attack surface for patent trolls. Many companies, like Netflix, are willing to take on that risk. Many other companies are not willing to take on that risk.

(Also not a lawyer)

I don't know anything about AOL specifically, but I've worked for a handful of BigCo's. All have required signing some sort of agreement at the start of employment which explicitly forbids leaking confidential information. So it's very likely that this person was under an NDA. What may be surprising to people who haven't worked at a BigCo is that due to legal implications, often times companies actually have guidelines about what should be discussed in recorded formats versus in person/phone.

Windows internals are very different than Linux and 32bit DLL files are not SO files. 32bit DLLs are typically relocatable (as opposed to .so files being position independent), which means they are compiled with a with a preferred load address they must be loaded at. If that address is not available at link time, the code must be moved to a different address and jumps must be fixed up to compensate. Because of that, in practice, loaded libraries are often not able to be shared between processes in memory. The reason for this decision is that pic code requires an indirect jump through an offset table which adds extra processing overhead. 64bit Windows is implemented closer to Linux style .so files due to the addition of new pointer relative addressing.

I read the article. Out of 4 images shown, one was of the live demo and 3 were suspected doctored photos from Nokia's promotional materials. The article doesn't clarify whether the live image taken with the Nokia phone was taken in front of the reporter or if it was taken ahead of time. Without that knowing that, it's difficult to gauge whether the conditions were truly similar and if this was a fair apples to apples comparison.

The acquisition was made 5 years ago. It's an old article.

I like the way you've phrased this, so let me give a contrived but quasi-realistic example: I have a network of nodes which calculates and returns some floating point value. I then accumulate those in the arbitrary order in which they come back from in the network. (According to Google) 1111.0000000000001 * 2 * 1111.00000000000001 = 2468642 BUT 1111.0000000000001 * 1111.00000000000001 * .2 = 246864.2. By using floating point we've already decided it's OK to give up some precision, however by applying the commutative property of multiplication now we've also given up determinism.

What's likely going on is fairly complicated to delve in to in a comment thread like this. However one possibility is that Linux just has a terribly hard time scheduling with that many cores. Processes attempt to maintain locality up to a point, but tend to move around between cpus when another has more free time. Moving results in a cold cache needing refreshing, and that significantly slows down work.

FTA: "It's actually a hybrid that is largely built on Harmattan, the legacy Maemo 6 code base that Nokia shuttered when it committed to MeeGo. It seems sort of dubious on the surface to call the software MeeGo when it's really still Maemo, but the hybrid is apparently designed in such a way that it has full API compatibility with MeeGo 1.2."

What's interesting is that in theory, assuming an appropriate scaling factor to divide the input by, the time and space complexity for Sleep sort are O(1). This is basically like hashing numbers, then iterating the buckets -- except that the iteration is done over time. Given that, one could envision degenerative cases for which Sleep sort could in theory outperform a standard algorithms like quicksort.

In some cases, yes depending on the state. If you buy an item in state Y and pay y% sales tax on it, then when you return to state X, sometimes you are required to pay the difference x%-y% in tax.

I am not a tax expert, but here are some examples I know of: A buddy of mine recently purchased a car while living in Texas, then moved to California a few months later and was required to pay the difference in sales tax on it before registering it.

New Hampshire doesn't have sales tax. The state of Massachusetts assumes people who reside in border towns will be purchasing goods there and automatically bills a yearly flat rate.

Part of the issue, a bit tangent to your point, is that when dealing with thick client software, once a version is released you can typically expect it to be in the field for quite some time. Many customers are upgrade-averse and simply won't upgrade a piece of software that is working suitably for them. Software developers have a bad habbit of fixing one bug and introducing another. With a web-based application you essentially control the release platform and can change things behind the scenes.

Discontinuing a support for a product developers don't use isn't really telling at all. Most Itanium development is done using compilers from the operating system vendor, not with ICC. Intel still provides the code generators for those compilers.

I did software development for NonStop Kernel on Itanium for a few years. 5 years ago, Itanium was FAST. Our software was twice as fast as competitors who used twice as many processing cores. Problem was that, unlike x86, Intel's Itanium roadmap moves slow and continually plagued by problems. About 2-3 years ago, with cost reduction in mind, we began porting software over to Linux on x86. Initially we needed 2.5x as many x86 cores to reach the performance of the 1.6Ghz Itanium 2. By the time Intel began shipping Westmere-EP processors early in 2010, each core was nearly 1:1 with Itanium, and at half the cost and 3x the density.