and the GPU drivers have been mainlined in the Kernel for everyone to see for several months already.

Samsung: So big that it patent trolls itself.

That's right, we can send Bennett over to our friends at ISIS and he can give them annoyling irrelevant advice about the exact type of eco-aware synthetic materials that they should use in their head-chopping knife scabbards. If we're lucky, they'll chop their own heads off in sheer frustration after they're done with him, and we'll kill 2 birds with one stone.

The 5820K is packing 6 cores and an unlocked multiplier for less than $400. If you don't absolutely need the full 8-core 5960X, then the 5820K is going to be a very powerful part at a reasonable price for the level of performance it delivers.

[quote]Right now I'm running two copies of Eclipse from a VM, displaying on the host machine's desktop using X-forwarding. Under Wayland, that'll require either pushing megabytes of pixels every time I scroll a window, or using some god-awful VNC crap.[/quote]

Let me fix that for you:

Using X-forwarding *right freaking now* you are pushing megabytes of pixels every time you scroll a window because every single modern toolkit operates that way and you have obviously got problems distinguishing between a simple tutorial on the 1985 version of xterm vs. how real applications that are forwarded over sockets in the real world actually behave.

1. Not that often for my desktop systems, but quite a bit for all those mobile devices out there. P.S. --> anybody who brags about ** years of uptime on a server deserves to be shot for failing to apply updates.

2. I don't care if I only save 1 second: time savings are important.

TL;DR version: You spend around 20 years getting used to the old way of doing it and now you can't stand change.

My story: Been using Linux heavily since 2000. Arch adopted Systemd big-time in 2013 or so. I spent a little while learning the new commands, and now it's just as easy/hard/whatever as the old RC system was. Oh, but my boot times are way shorter than they used to be.

Nobody has been robbed.
TSX today works exactly as well as TSX worked yesterday, and considering that Haswell has been on the market for over 1 year, I assure you that anybody who has been chomping at the bit to use TSX has been using TSX.

If the TSX erratum were trivially easy to trigger, then this article would have been posted last spring before Haswell even launched.

Intel has done the responsible thing by acknowledging the bug (trust me son, AMD & Nvidia often don't bother with that part of the process) and giving developers the OPTION to either use TSX as-is or disable it to ensure that it cannot cause instability no matter what weird operating conditions can occur.

Tell ya what, why don't you take all your nerd-rage over to AMD or ARM where they won't rob you of all kinds of advanced features that they just don't bother to implement at all.

You can still "play with this instruction" all you want.

What happened here is that a third party developer managed to uncover a corner case where certain interactions with TSX can lead to instability. In order to be safe, Intel acknowledged the bug (a refreshing response) and is now giving you the OPTION to disable TSX if you feel that it could impinge the stability of a production load.

So basically: Go ahead and play with TSX all you want, but be aware of the errata and that it's theoretically possible to hang your machine in some corner cases.

Uh.. given that sort of standard, no Android application has ever been developed since the x86 PCs that are used to develop 100% of Android applications lack practically all features of the ARM SoCs that run those applications (the only exceptions being the newer Baytrail Android tablets that are also x86).

Also: There's a space of about a million miles between "TSX ALWAYS FAILS EVERY SINGLE TIME NO EXCEPTIONS AND CAN NEVER BE USED EVAR!!" with "Oh, we found through extensive testing that under certain conditions TSX can cause issues. Don't use it for your nuclear power plant control system, but it's perfectly fine for non-critical testing. Oh, and just to be safe, we've made a microcode update to disable it."

Articles like this have been around since the 1980s and have appeared on Slashdot before in regards to practically every stealth aircraft in existence including at least the F-117 and the B2.

Here's the kicker though: The long-wave radars that can sort of track stealth aircraft aren't able to track them with the precision needed to get a missile up there to shoot one down. If an adversary already knows that you are sending planes into a general geographic region, then the long-wave radar doesn't really tell them anything that they didn't know already.

Anyone in the military who has dealt with stealth technology will tell you that "stealth" is much more than a coating or wing shape that magically makes your airplane disappear. It's a whole strategy that uses technology + suitable tactics to make stealth work in practical situations. Stealth aircraft are not completely invisible and do not have to be completely invisible to be effective.

Sorry, but I'm not going to get my panties in a bind that the NSA is spying on other countries' governments considering:
      1. That's the NSA's freakin' job.
      2. Anybody who thinks that the only country in the world that spies is the U.S. is either an idiot or a liar.

Uh... as somebody who knows a LOT more about patents than you do... what you just said is a complete (and likely intentionally disingenous) misreading of a relatively simple part of the statute that is merely there to prevent a substantial loss of patent term due to the bureaucracy at the USPTO taking too long to do their jobs (which they often do, being government bureaucrats).

Fascinating, so what part of patents having a fixed maximum 20 year lifetime is not "limited time" to you?

Are you still stuck with Windows 95 where anything beyond 49.5 days is considered infinity because the computer crashes?