The article itself mentions that many of these machines belong to businesses, where Linux has a higher share. And while servers are more difficult to attack in general (well, they don't have Adobe Flash or Reader...) they make better targets, and servers are where Linux is the higher profile target. Its heterogeneity and timely security updates save it a lot there. We can expect more effort given to attacking Linux over time, but for sure it will *take* more effort.

Paging Dr. Freud...

How did you think the "management" worked? Either you trap each pointer access manually (and maintain all of that state and overhead), or you use a memory management unit to do it for you (and accept the cost of traps and context switches).

The very best that a VM runtime can do is infer that a class of access is impossible and thus exclude traps for it. This only works in extremely limited circumstances, and still requires code to be correct. It in fact makes profiling really difficult - and performance is the whole problem in the first place.

You have a very strange definition of "core". Do you mean that any ASIC or FPGA is automatically a core? More ambiguously, what about an FPU or GPU? If a mobile phone has "half a dozen cores" then a PC has hundreds.

You can close (and minimise, maximise, etc) windows by right clicking on the title bar or even the task bar's button corresponding to that window. This is consistent in KDE and several other window managers.

When you ask, Bruce Schneier receives.

Bruce Schneier is the general solution.

You really need to subscribe to the mailing list. The rate of development is only growing -- it's just now moved on to a lot of smaller features and improvements, now that most of the work is already done.

I disagree - user-mode code, whether it's separated into threads or processes, still relies very heavily on kernel scheduling decisions. It may sound simple enough, but if you study the decisions the kernel has to make (such as which thread to wake first, from a set of 8 all waiting on the same semaphore), you can find lots of ways to get it wrong. We now take it for granted because thousands of man-years have been spent on solutions.

Leave both in a vacuum and see which one lasts longer. There's a very clear definition of atomic stability that is markedly different from chemical reactivity.

Ok, what? It definitely works as a daemon. But even if it didn't, what's the issue? If you have a dedicated headless MPD server, you gain nothing by using Pulse. If you have plenty of desktop applications that all want sound input/output, Pulse solves basically everything.

Microsoft has put billions of dollars into developing the most effective and efficient security vulnerabilities to date. I can only watch in awe and wonder.

If you're creating a serial queue anyway, you no longer have parallelism. If you have multiple serial queues, you may as well have had multiple threads with no interlocking between them. This is just yet another API to do what competent parallel system programmers have been doing since the first thread.

I said the best students *I* know; I'm in software engineering.

I agree. The best students I know don't even buy the books, let alone write in them, because they're actually using the material in practice (hobby, job, overkilling lab work, etc.) and internalise it better than note-taking and highlighting ever could. They look lazy until you see what they can actually do.