A compositing display server saves a lot of CPU, by just doing the rendering and rasterisation of windows once and then alpha blending the resulting windows. You don't need to redraw for expose events, you just composite the results. This saves even having to bring the background applications into the cache (or into RAM if they're swapped out). Within an application, you can get the same benefit, caching the rendered results of (for example) a complex data-driven view and not having to do a load of queries of a model object because an overlapping view needs redrawing.

The down side of this is that you end up doing a lot of compositing. Sure, you can do this on the CPU (and a modern CPU is fast enough to do it on the vector unit reasonably fast), but that consumes a lot more power than doing it on the GPU.

I've hacked on GPU drivers. These days the command submission part is pretty simple, most of the driver is the compiler that generates optimised code for a processor that's highly optimised for a fairly narrow set of workloads. The firmware, on the other hand, is an entirely different thing. This is closer to CPU microcode than a driver. It's likely written to a one-off architecture and is likely to be completely rewritten for the next revision.

Seriously? A site for geeks can't expect people to know the professional association for computer scientists? Would you also want IEEE expanded?

Steve Jobs made anti-DRM statements very early on. At the time, the music industry was insisting on DRM for everything. They eventually learned that it gave more power to the distributors than to them and allowed Amazon to sell DRM-free music (but didn't allow Apple the same deal for a while, to allow Amazon to become a viable competitor). For some reason, the movie studios are intent on making the same mistake and insisting that Amazon and Netfilx take complete control of their supply chain, when the best thing for their business is a healthy competitive ecosystem driving each others margins.

If they had any sense, the music and movie studios would insist that distributors sell without DRM.

I'm fine with you doing all of these, as long as you're willing to take responsibility for every message sent on your service. Bomb threats, death threats, trade secrets, copyright infringement, all become your liability - if you're policing the content then you're responsible for it.

The NSA or GCHQ (or any similar intelligence agency) almost certainly could insert a backdoor into MS software. Doing the same any other piece of proprietary software developed by people that they could easily blackmail would also be easy. There are a number of approaches that would work for open source too - there was a recent story about a lot of contributors to prominent projects hosted on GitHub having weak SSH keys, so compromising one of these from someone who hasn't committed in a long time and putting in a bug fix along with an obfuscated backdoor would be easy.

The danger of doing this is that there's a lot of potential fallout if they're caught. This kind of active intervention raises the stakes and also weakens their defences (it's very hard to create a backdoor that isn't a security vulnerability). Given that almost no software is formally verified and most is very complex and not aggressively tested against hostile input, if you've got enough resources to throw at it then you can probably find an exploitable bug already and not have to bother. This is much more deniable, because no one can be completely sure that you were the ones exploiting the vulnerability.

Hmm, that looks familiar. It was either that or an extended tech report version of the same thing that I was thinking of. Thanks!

In Smalltalk, there are two integer types that can be used pretty much interchangeably. SmallInt objects are stored inside a pointer, so they are typically 31 or 61 bits, with the low bits used to distinguish pointers from small objects (on 64-bit platforms, some float values can be safely stored in a pointer too). If a SmallInt operation overflows, then the result is a BigInt object. BigInt objects are real (immutable) objects that encapsulate an arbitrary-precision integer. They're much slower to use than SmallInts, but you generally don't think about which you're using, you just use an integer type and let the language / libraries handle making it efficient. Floating point values are handled similarly, though they don't grow precision (I don't remember what the Smalltalk-80 spec mandates, but some implementations provide high-precision floating point classes that you can use instead of the efficient hardware-sized floating point).

In contrast, JavaScript provides an IEEE double and nothing else. Implementations try very hard to avoid actually using doubles to implement them for values that are actually integers, because floating point operations are a lot slower than integer ones on modern CPUs. Because operators are special in JavaScript (anyone know what object + array is?), you can't provide any kind of number with increased precision. Try dealing with any data that comes with 64-bit values (e.g. file offsets on a modern FS) in JavaScript and you'll see the pain.

The JavaScript implementation from Cadence that's used for scripting various IC design systems avoids this by providing the full Smalltalk set of number types (it's actually implemented in NewSpeak, which is implemented in Smalltalk, for extra fun).

It's also useful for providing an API that other tools can use. Lots of things can parse RSS feeds, not just readers, and it's a good way of providing activity indicators on other sites.

And, especially, the maps where I most want this are embedded (e.g. in a hotel side where I want to see how far the hotel is from the places I actually want to go) and so don't provide access to the directions bar.

I read a paper copy of it almost 10 years ago, so unfortunately I don't have one to hand, unfortunately.

There's a nice paper from the developers of the Apple Newton, which argues that class-based OO maps very well to model objects (where you have lots of objects that are mostly the same), whereas prototype-based OO is a better fit for views, where you want a bit of customisation for almost every instance. JavaScript is a language that is designed for UIs, with the back end being written in some other language, so it's hardly a surprise that it chose prototypes.

My biggest complaint about JavaScript is that, even with Smalltalk and Self as examples of languages that did it right that the developers were intimately familiar with, they still managed to get numbers wrong.

This would have been more funny 10 years ago when people still said 'Java applet' without laughing and both statements could have been applied to either language. I rather like the top answer though: 'Java and Javascript are similar like Car and Carpet are similar'.

It depends on the threat model that you care about. On the one hand, it is bad if there are intentionally and maliciously injected trojans. On the other hand, the Snowden disclosures have shown that this is rarely done - it's high risk and there are enough vulnerabilities in code that the NSA can exploit without needing to do anything active to the supply chain. Being able to find these and get MS to fix them is probably quite important.

My main objection to this is that I don't like to see tax money being used to improve a single company's product.

i second the 'huh?' from the other poster. Apple did grant the USB consortium some patents, but they were not involved with the design of the USB C connector at all. It was developed by a committee, with some fairly major contributions from Google.