Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?
DEAL: For $25 - Add A Second Phone Number To Your Smartphone for life! Use promo code SLASHDOT25. Also, Slashdot's Facebook page has a chat bot now. Message it for stories and more. Check out the new SourceForge HTML5 internet speed test! ×

Comment Re:Owning vs Renting (Score 1) 353

Well, to be fair, once a company is in the MS user pool, it is very hard to get out as MS Office is the norm in business. Now, the rent vs own is an interesting take on it. Most large businesses would rather not "own" software as it is often an asset that they have to track, amortize, and depreciate. Renting, or more ideally, annual licensing fits the fiscal year budgeting process much better. So having this as an option really fits the customer's business models better. However, for many companies, having your internet connection go down and losing the ability to function is far too much risk, so "owning" is the more prudent option. So long as MS offers both options, then they are addressing probably 90% of the market. Not really a big deal that they lost subscribers if people are still within the MS Office pool, but if it is a zero sum game (likely saturation) of Google docs vs Office 365 vs OpenOffice vs Other, then it becomes more of a question of whether "3rd party" office programs are slowly climbing their way to corporate acceptability. Having what I consider very few improvements, if any, since Office 2010, competition would be welcome to churn real innovation.

Comment Re:reproducibility (Score 1) 395

Scientific programming using Monte Carlo methods requires reproducibility based on some initial seed so that an analysis can be reconstructed. A good example of this is benchmarking a code for changes in compiler options. If the code is widely distributed, then a large set of random numbers is not as easily distributed as a Twister or other method. Also there would be problems with acceptability of the results of such a code if a developer were to distribute the code with a specific input and set of random numbers. The temptation to cherry pick results would be too high. For security purposes, where a one-time-pad approach is ideal, a truly random number is fine.

I don't particularly buy the authors approach though, because semiconductor physics is full of things that seem random at the moment, but then turn out to be entirely predictable once a suitable model is found. Sun Microsystems found this out years ago when they tried to base a random number generator based on the rate of soft failures from memory chips. They were using Boron as a dopant, which has a high probability of absorbing neutrons and decays with an alpha particle (He +2 atom), causing a hardware error. They claimed they had a perfect random number generator until they saw that the randomness was dependent on the location of the chips. Denver has more cosmic radiation than Miami, thus the randomness was actually Poisson (as are most things nuclear). The method was thus vulnerable to an attack based on the mean number of failures, which could be determined by knowing the physical location of the device.

Slashdot Top Deals

U X e dUdX, e dX, cosine, secant, tangent, sine, 3.14159...