What the AFP claims is a total lie.

"He was a low-level support tech who was on a three-month probation,” Wurth said. “He had no access to any type of customer data apart from support tickets"

So essentially a script kidding working a low level tech support job. Not exactly a criminal mastermind.

Actually running high end games on a Xeon isn't that bad of an idea these days. For some bizarre reason they are always cheaper than equivalent i7 CPUs.

eg, the E3-1275 has an tray price of of $339. It runs faster both in turbo and non-turbo mode than the i7-3840QM which has a tray price of $568.

The E3-1225 at $215 is faster in both turbo and non-turbo speeds than the i7-3610QM at $378.
The E3-1245 at $266 is faster in both turbo and non-turbo speeds than the i7-3820QM at $568.

All CPUs listed are pretty much the same. Same architecture, same generation, same internal graphics card (the P4000 is the HD4000). Yet for some reason there's a huge discount if you buy Xeon rather than i7. There's not that much difference in the motherboard prices either. And the ECC RAM is optional, not required. So bizarrely these days it's worth buying Xeon if you want a huge discount on the desktop CPU prices.

No, he wants better air flow. It's ridiculous that Laptops pretty much ubiquitously have a 10 square centimeter air vent and nothing more. It simply ends up trapping the heat.

Well you can't say Java has flaws and then detail one particular set of flaws in one product. Even then your claims that the flaw is in the JVM is doubtful. I can right now load up a Java program in Oracles JVM and delete my files off my hard drive. I can also straight up spin up 100000 busy threads and bring my machine to a crawl. Are these flaws? Of course not. I can do the same thing in C++.

The flaw is allowing the browser plug-in to do things it shouldn't. The JVM itself is supposed to allow you full functionality including the ability to shoot yourself in the foot. The flaw is the fact you've exposed the JVM to the outside world. The Applet Plug-in tries to limit this functionality but fails. That is not the fault of the JVM.

No Java itself is used in so many places. Your phone probably uses it for a start. From the cheapest old fashion Nokia candybars to the latest Android smartphones to a whole host of embedded systems around the place and various webservers. They all use Java extensively and they never have an issue with the language.

Unfortunately there's a particular Java plugin from Oracles version of the Java VM that insists on running every Java program your browser comes across. You wouldn't run a plugin that runs every compiled executable you come across would you? Well Oracles Java plugin tries to run every Java applet it comes across. That's where these security flaws you hear about come from.

So Java as a whole is having its name tainted by one particular plugin.

That screenshot doesn't show just how bad windows management in Metro is. There's actually no way to display two apps side by side. You know how you sometimes like to read a PDF on one half of the screen and an editor in the other? You can't do that. Metro application have two modes. Fullscreen or snapped into a 320px narrow margin.

It's quite telling that the Windows Blue preview advertises "you can run two apps side-by-side for better multitasking". Metro is so bad at Window management even the newest version will be nowhere near the abilities of Windows 1.0. You can't arbitrarily size programs. That might be acceptable for a phone but it's just ridiculous on a PC.

Well i'm a fool. Looked it up and it turns out the Polynesians did have dogs (the Kuri). No beer though.

Here's a simple way to rule out things that didn't give us civilization. Were there civilizations without those things?

If so that would indicate that item is not required for civilization. The Maui of New Zealand and other polynesians for example did not have dogs or beer but certainly met the requirements of a civilization. Dogs and beer are therefore not a requirement of civilization.

Another possible meaning is that it's purely dataloggers monitoring every device he describes. So there's no way to control anything, just a way to monitor it.

Not these days. Manufacturers have released the RISC CPU at the same time as the x86 CPU before as two separate products but it's generally been a flop. See the AM29000 which was the same as a AMD K5 minus the x86 instruction decoder. The problem is, there's no advantage to the non-x86 version. x86 code is extremely space efficient. You can fit more x86 instructions into a given region of cache than you can AM29000 instructions. So that even with the overhead of the instruction decoder the AMD K5 would often beat the AM29000 at the same task.

Which is why debates like these always irritate people in-the-know. There is no x86 in an x86 CPU except for an instruction decoder. There is no real overhead for all the odd things an x86 can do. That's dealt with by the instruction decoder and puts no overhead on the core functionality of the CPU. In fact unless someone comes up with a more space efficient instruction set, x86 is one of the best ways to pump instructions into a RISC core.

How can possibly argue various x86 CPUs aren't RISC when they are literally RISC CPUs with an instruction decoder bolted on?

The AMD Am29000 was a RISC processor. AMD added an instruction decoder to this CPU that allowed it to run x86 code. They called it the AMD K5. One of the fastest x86 processors of its time. If you crack open an AMD K5 you can absolutely see the core of the AM29000 within.

What you're describing is called privilege rings. They allow you to separate user, kernel and driver memory spaces. However you seem to be confused. The x86 system is the pioneer of privilege rings. If any CPU can be praised for allowing such separation of driver memory it's the x86!

The actual correct usage of these privilege rings is more problematic. A lot of systems run drivers in kernel space when they could just as easy run at a lower level. This shouldn't be seen as a win for Alpha over x86. Both CPUs have similar mechanisms. What you are describing is a software issue.

Every system I've seen has some form of IPV6 tunneling that allows you to call out to an IPV6 server. The only time it fails is if you're trying to host an IPV6 server which will fail due to NAT but connecting to an IPV6 always works. The fact that you've got an IPV6 server means you're set. Run Teredo/Miredo on your clients and connect away.

Go setup teredo/miredo and connect away.

You seem to be unaware of the definition of gravitation.

The effects of the warping of space-time by mass is called gravitation. Your "OMG it's not gravitational pull it's the warping of space-time" line of argument makes no sense considering that gravitation is simply the name we give the warping of space time by mass.

Yeah but a radio transmitter capable of overpowering the weak GPS signal in a massive radius costs hundreds. A HARM missile designed to destroy that transmitter costs close to a million.