One of the things that differentiates me from many of my analyst colleagues is that I don’t generally delve into business stuff: I’m a technology guy. So normal boardroom shenanigans and so forth aren’t “my beat.” So let me see if I have this straight: the chairwoman of HP hired people to … let’s just put the whole “pretexting” thing aside — she hired people to install keyloggers on other people’s systems? And the debate isn’t how long she’s spending in prison, but kind of whether it was “ok” or not?
Am I missing something here? Is this not clearly illegal?
Patrick Logan refers to Ted Leung observing that quad-core and octo-core MacPros don’t show anything like linear speedup. This accords with my own fanaticism about the manycore future. A question I don’t know the answer to: Do the CLR & JVM have characteristics that dramatically help or dramatically hinder their suitability for manycore hardware?
The CLR & JVM are based on abstract hardware. The virtual machines have some things which immediately jump out as, let’s say, “tough” for parallelizability — both have a model whereby separate threads are responsible for coordinating their own access to shared memory (i.e., fields in objects). On the other hand, they have at least one thing which jumps out as potentially a “very good” thing for parallelizability — their stacks are conceptually separate from main memory, which may make the threading models easier to evolve (in a world without pointers, data in the stack is inherently local to the current thread.) The “inherently parallelizable” aspect of functional languages arises from their exclusive use of the stack for volatile state, but with the way the stack is generally conceived (as, y’know, a stack) requiring pushing and popping and copying variables from one to another, problems arise when copying large datastructures; thus my thought that maybe the abstraction of the stack could be a “win.”