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.
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.
Before we get out the pitchforks, Google is still supporting the current Microsoft formats (.docx, .xlxs, .pptx). If you're still running Office 2003 or older, you can install a compatibility pack from Microsoft to support the current file formats. (http://support.microsoft.com/kb/924074)
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.
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.
My Fall 2009 model overheats and locks up and crashes when playing games like Starcraft 2 or Left 4 Dead 2. That's not to say every notebook from 2009 had cooling problems, but some certainly do.
Senderbase has some interesting spam statistics which are reported from Cisco/IronPort security appliances around the world. After today is over and the stats are calculated, there might be some interesting data.
It's unlikely AT&T is doing anything fancy at this point, but there's potentially much more to detection than TTL. NAT devices make an attempt to be transparent at layer 4 and try not to interfere with it. Host OS fingerprinting can rely on a combination of options at that layer as well including but not limited to windowing scaling MSS. If AT&T cared to go the distance, it would be very difficult to get around detection without interfering with the TCP/IP stack.
Installing Linux in favor of Windows won't make computers cheaper. Microsoft sells OEM distributors their Windows 7 Home license for around $50. Then, the reason off the shelf computers come bundled with so much bloatware from the likes of McAffee, Symantec, and 100 free hours of AOL is because those companies pay for it. In many cases, pc manufacturers actually return a net positive on installed software.
Wikipedia also quotes the 78% number, citing Coca-Cola Co's 2005 SEC filing [1]. However, a cursory read of their SEC filing reveals this: "In 2005, concentrates and syrups for beverages bearing the trademark "Coca-Cola" or including the trademark "Coke" ("Coca-Cola Trademark Beverages") accounted for approximately 55 percent of the Company's total gallon sales." [2] It's possible the 78% number the Wikipedia article is drawing from is based on a newer SEC report which isn't cited correctly.
Edit: I Looked up their 10-k from Feb 2010 and found this:
"Trademark Coca-Cola Beverages accounted for approximately 51 percent, 51 percent and 53 percent of our worldwide unit case volume for 2009, 2008 and 2007, respectively." [3] So it looks like Wikipedia may have incorrect information!
(Disclaimer: my assertions apply only to Linux, I'm not familiar with the vmm in other systems).
I think you may be misunderstanding how the vmm works. When you allocate memory by calling mmap(), sbrk() etc., that amount of memory is committed whether or not you actually use it. Because many processes will allocate more than what they actually use, for example excess stack space, the vmm allows you to overcommit by a certain percentage, defaulting to 50%. This will allow processes to allocate 50% more memory than the system actually has. If that is exceeded, however, Linux has an Out Of Memory Killer which will start killing processes.
One constraint I believe you may have missed is that an idle thread does actually consume a significant amount of memory. While most resources a thread consumes are fairly small, the stack is actually quite large and is allocated up front. The usual default ulimit stack size for Linux is 8192Kb. This means for every thread created, 8 megabytes is allocated whether or not it's used. On Linux the OOM killer will start to kick in, by default, once you've overcommited your virtual memory by 50%. You can adjust the ulimit stack size and overcommit ratio, of course, but either way you're playing with fire.
Try Eclim for your java work. It's a set of vim plugins which run and communicate with a headless Eclipse instance in the background. This allows you use Vim as your editor and pull many of Eclipse's fancy features forward.
In reality the model is a bit more complicated than that. The "market price" authored by an exchange is actually more of a mark-to-model calculation as a function of recent trades. Remember that a market exchange doesn't function like a store with customers buying product from a vendor at a fixed price. In oversimplified terms: In reality it's people selling at some price they want to sell at, and others buying at some price which they want to buy at. Orders are fulfilled by the best available match at the time.
I tried breaking this captcha. Here are some experimental results and mathematics:
By applying the mathematics from the Birthday Attack (http://en.wikipedia.org/wiki/Birthday_attack), If an attacker is able to solve 15.8 million of the 180 million captchas, there will be a 50% probability that the attacker can beat the captcha.
I tried refreshing the page 10 times, generating a total of 100 captchas. Out of those, I observed 8 arithmetic problems which I entered into and solved using Wolfram Alpha. That gives roughly the 15.8m/180m necessary to break the captcha with 50% probability.
At 50% probability, again going back to the Birthday Attack mathematics, an attacker would need roughly 16.8 thousand tries before expecting a collision with one they could break.
This probability will increase if an attacker is able to successfully reverse-engineer more patterns.
Edit: thinking about this more after MichaelGG's comment, I think my math is incorrect. Either way, point still stands that Wolfram Alpha can successfully solve 8% of the captchas and other patterns should be solvable by other means too.
It seems to me like the problems you're having, like intellisense not working correctly and the debugger being broken, are problems with the SDK tools and not with Eclipse itself. Writing your own tools I fear you will run in to many of the same problems. While I feel that you're right in saying developing Windows C++ apps under VS is a superior experience as compared to developing Linux C++ apps under Eclipse, Visual Studio cross-target development kits I've used in the past tended to be sub-par compared to either. Many degenerate in to rather dumb text editors with project management. From a technical standpoint, integrating with intellisense and the graphical debugger is much more difficult under Visual Studio. Either way, good luck and keep us posted!