Yup - I have no argument at all with your statement.

As if the user-agent string wouldn't land you on the watchlist. That wasn't a joke by the way. And as far as the results you receive, you probably shouldn't trust those either. But let's set aside your awesome new indy band name Loli: President Bomb and focus on the real issue here: The gullibility of free software consumers. They are exactly as gullible as Windows and Macintosh users, it would seem: They're trusting an abstract organization that is continuing to collect personally-identifiable information, simply because said organization upon being caught doing so, has said "oops! Our bad. We'll anonymize the data now." And these people should know better than to believe such claims.

Perhaps it is a sign of how far Linux has come into the mainstream then: It's become the microbrew of the IT world. All these new distributions, the promise of being trendy, geeky, and cool... and yet, suspiciously lacking in all of the things that made "Free as in freedom, not free as in beer" so appealing to the much smaller community of non-hipsters that was here before. Linux has finally made it to the big time: It's become "hip". And no surprise...Ubuntu, like many other major distributions, sees the chance at monetization and is taking it. Oh, I know... I'll get modbombed again for suggesting that the pure and noble Linux isn't like all the other operating systems out there... but then, wasn't that the goal all along? To create an alternative to closed source? Mission: Accomplished. Too bad success isn't what they thought it would look like.

After thumbing through the dense tomb that you posted, which was moderated +4, Informative, I find no mention of any intercontinental ballistic missiles. It is also three years older than my link, which wasn't in PDF form, and indicated they only had regional launch capability. The document you provided indicated they had only managed to create missiles with a 500 or so mile range. Barely enough to get the nuclear ordinance they've developed far enough up-wind to not eat the radioactive fallout after. China is a big country.

Perhaps a more careful investigation of documentation in the future would be helpful? But given how many times my factual statements have been moderated down in this thread in favor of bullshit exaggeration... it's not surprising. I expect the moderation on this one will serve to further confirm that Slashdot has become the Fox News of the IT world...

Which is really the reminder BB doesn't need right now that their fancy secret sauce layer (while essential back when they were cramming actually-workable email into dumbphone specs, and still arguably superior to other vendors' fancy secret sauce layers), is just another thing to pay a monthly fee for, forever, and occasionally incur outages because of.

In a world where your phone can just talk to the mail/XMPP/whatever server like the real computer that it is, having a fancy extra transmogrification layer isn't necessarily a virtue. There's still a strong argument to be made if you need to integrate a bunch of Android/iOS handsets into a legacy BES system, or if the client adds some of the lockdown knobs that people feel safer being able to twiddle (though, on iOS, Apple tightly controls what knobs 3rd party vendors can touch, so all management systems are more and lessy sucky interfaces on top of the same set of options. Android is much less predictable; but if you demand the right rights at install time you could offer a genuinely differentiated management product); but otherwise it's a much harder sell.

I think the NSA believed it was okay to weaken cryptography because they assumed they would be the only one who knew about what they'd done and specifically how they'd weakened it.

So really, what I believe is they were very clever and, at the same time, very naive... Or perhaps sophomoric and arrogant would be a better fit.

From the article:

You need how much compute power to read mail?

Most users just don't need that much power. Once everybody could play streaming HDTV, the couch potato market was covered. Rendering in gaming could still improve, and NPC behavior could get smarter, but really, GTA V pretty much has that nailed and it runs on last-generation consoles.

There are people who need more power, but they're running fluid dynamics simulations or rendering movies or simulating new ICs or something like that. I've run Autodesk Inventor on 24-CPU workstations. That's one of the few interactive programs that can usefully use a 24-CPU workstation. It's not a mass market product.

The applications that need vast amounts of additional compute power are there, but they're not high-volume applications. Nor are they "enthusiast" applications. There's not enough volume there to justify heavy investment in faster CPUs.

This may change as we have better robots or something like that. But speeding up existing desktop apps, no. (Program load times are still ridiculous long, but mostly because of stupidity like phoning home for updates, waiting for the license server, fetching ads, or using virtual memory in a world where memory is cheap.)

An interesting scenario just came to mind...

1) RSA intentionally weakens their crypto at the behest of the NSA (this is fairly certain)
2) Chinese hack RSA - the only question is just how thoroughly (a known fact)

Now comes the speculation.

3) China analyzes what they got from RSA and discover the crypto is weaker than expected.
4) Quietly, China also begins to take advantage of this breakable crypto the NSA foisted on US companies and citizens.
5) China deduces why it was done and starts looking for weaknesses in other US crypto products - possibly succeeding, given they have a decent idea what to look for.

Followed by

6) China successfully and quietly penetrates most US defense contractors and financial institutions.

This refers to members of the US military doing cryptographic duty who died in the line of duty. Here's the list. Most died during the Cold War or in Vietnam. In recent years, in Afghanistan or Iraq. Only one civilian, Alan M. Blue, who was on the USS Liberty when the Israelis attacked it.

GI in Japan after surrender of Japan in WWII, picked up gut bacteria and whenever he ate carbs he got drunk.

That may be the one my parents told me about, back in the '60s or so (but as a war story which probably puts it in WWII.

In the one I heard about the GI was thrown in the brig and put on bread and water - which of course made him even more intoxicated. Then they mounted an investigation to see how he was getting the booze smuggled in. That finally showed it was a medical problem.

Turns out he had diverticulosis - one or more failures in the intestinall muscle wall where the gut membrane bubbles out into a little appendix-like pocket and is prone to infections - and one of these became home to a culture of brewer's yeast.

Not only does it cost a LOT to port this stuff and risk errors in doing so, but the cruftier it is the harder (and more expensive and error-prone) it is to port it.

If, instead, you can get the new machines to run the old code, why port it? Decades of Moore's Law made the performance improve by orders of magnitude, and the behavior is otherwise unchanged.

If you have an application where most of the work is done in a library that is largely parallelizable, and with a few tiny tweaks you can plug in a modern multiprocessor-capable library and run it on a cluster, you get another factor of almost as-many-processors-as-I-decide-to-throw-at-it, with small effort and negligible chance of breaking the legacy code.

What a deal!

And it's one less reason to touch the tarbaby of the rest of the working legacy code.

Let the COMPUTER do the work. People are for setting it up - with as little effort as practical - and moving on to something else that is important and can't yet be automated.

Eventually somebody will teach the computers to convert the Fortran to a readable and easily understandable modern language - while both keeping the behavior identical and highlighting likely bugs and opportunities for refactoring. Until then, keeping such applications in the legacy language (unless there's a really good reason to pay to port them) is often the better approach - both for economy and reliability.

Says the guy living in the country with the highest incarceration rate on Earth source

We're defending something, sure, but I don't think it's freedom.

Uhh, try 200-300. And they presently lack an effective delivery mechanism. They're testing one now. They are not a significant threat to the United States at this time. Russia is.

That's too bad. I've met many of their people. They were doing good work.

"Suitable Technologies" is just another company producing those annoying "remote presence" robots with a video phone on top. There are four or five manufacturers of those things. They can't do anything; they have no manipulation capability. They just talk.

"Remote presence" is only useful if the person running it is someone who gets sucked up to. Like doctors. A number of health care vendors are trying the things.

A few years ago, I was involved in the conversion of the Stanford AI lab tape archive to modern media. This involved reading thousands of reels of 1/2" magnetic tape. It was a slow process. Volunteers were loading a tape onto a tape drive every 15 minutes for weeks. After each tape was loaded, its contents were sent over an Internet connection in under a minute. It took much longer to wind through the tapes than to transmit the data.

The data went to a server farm at IBM Almaden Research, where the file systems were reassembled (these were incremental dump tapes) and text files were converted from the Stanford AI lab's unique character set to Unicode.

The result was the SAIL DART archive. See the source code for EMACS, the early years.

I think I speak for many geeks when I say....

KHHHAAAAAAAAAAAAAANNNNNN!!!!

That is all.