Very interesting loophole. For those too lazy to read TFA, basically this attack allows someone running as root (or in some cases as a local user) to run code at a level that even hypervisors cant deal with. To put this into perspective, if you are running some big iron hardware with a dozen virtualized servers. With a local privilege escalation exploit on one VM, an attacker could use this attack to take over the whole system, even the secured VMs. Worst problem is that it would be undetectable. No VM, and no hypervisor would be able to see it. Any AV call can be intercepted as the SMM has the highest priority in the system.

The solution on the other hand seems pretty simple. Make the chipset block writes to the TSEG for the SMRAM in hardware (by disabling those lines) and use some extra hardware to prevent those lines from being loaded into cache. Finally, make every bios SMRAM update contain a parity and create tools that allow SMRAM parity check.

The best thing to do would be to ensure your entire system was self sufficient to some degree (i.e. display, OS, input devices were fixed). A netbook would be the perfect low cost solution. Just get an eeePc with a 4/8G hard disk, set up with some slideshow to start on boot and store that. To ensure you dont wind up with the problem of bad flash hard disks, either make a few copies on SD cards, or get a ROM based hdd, burned with a system image. That way when people open it up, there wont be issues of how to connect it to a working monitor/keyboard etc. Just plug in battery and press power button.

I think Linus is right on this one. I have been using KDE based linux desktops on my primary computer for ~7 years now. KDE 4 is a huge step back. The even bigger problem is that linux distros (Kubuntu and OpenSuse) are happily pushing KDE4.1 as the default KDE desktop. In fact with Kubuntu 8.10, there is no option. For KDE 3.5 you have to use 8.04. KDE 4 takes the GNOME approach to desktops (i.e. user's IQ is equivalent to a mostly dead rodent of unusually small size and any options would confuse poor afore mentioned user and therefore options are bad). Before the GNOME loving flames begin, yes I know there exist external tools to start fiddling with options, but the amount of flexibility is not the same as KDE 3.5.10.

KDE 4 unfortunately takes the GNOME approach, and removes flexibility. Worse still, all the developer time for KDE 4 is now going into polishing the interface (which while shiny is no better or more intuitive than KDE 3.5) while not bothering fixing apps people actually use. For example, on KDE 4.2, if you add a webdav calendar from a https source which has a self signed cert, you will be prompted every time it reloads, whether you want to accept the cert or not. Yes thats right, even if you click accept cert permanently, the DE is incapable of understanding it. This has been outstanding for a while, but all recent activity seems to be towards fixing desktop effects or making the kicker work. Its ridiculous.

/rant

I have never been a "windows fanboi"( In fact this is being posted from a linux computer) and I am no defender of Microsoft's business practices. However without doing code analysis, it is impossible to say that this slowdown is because of DRM. Nowhere in the article does it suggest that they were able to do a profile analysis of the kernel codes and compare what modules on the path were causing the delays. So while it is theoretically possible(and likely) that the source of the delay was DRM related, one cannot be sure. If you possess knowledge otherwise, please feel free to cite it and correct me.

XP is still faster by a large margin(20% to 40% depending on load scenario). FTFA

It is interesting that WinXP is still better in terms of performance than either. The article suggests that Win7 and Vista would be better on systems that hypothetically had 16+ cores.

But nowadays, especially in tech savvy crowds like on /., the most popular thing to do is run VMs with virtual instances of Windows, which reduces all the hassles associated with dealing with win cruft. Got a worm? restore machine. Drivers made system unstable? restore machine. The vms are typically only given 1-2 cores, the exact use case where WinXP does way better than its successors.

So even if we move to a world with 16+ core processors, if Win7 cannot do better than a 10 year old OS, in common scenarios, how can that be called progress?

I suggest C/C++ and Tcl/Tk. Together, they are quite powerful and Tk GUIs also work in Windows. I know Python tends to be the scripting language of choice here on /. but Tcl is quite widely used and if you are working in a field which has Tcl legacy systems (like EDA tools) then learning Tcl will give you a huge boost. Other than that, Perl for command line scripting might also be handy.