Walled gardens like AOL and CompuServe failed because they had to compete with everyone else. In the early '90s, there was a lot of content that was exclusive to AOL or CompuServe. There were a load of small BBS that had their own unique content. And then there was the Internet. Anyone could put something on the Internet and when web browsers started to be easy to install anyone could put up a web page. Individuals would put things up on their ISPs' web space or somewhere like Geocities, big companies would buy their own servers. Small individual ISPs started to spring up, because the cost of entry was low: a rack of modems, a leased line, and a load of phone lines and you could be an ISP. Local ISPs competed by differentiating themselves in various ways (free email, free web space, static IPs, whatever).

Meanwhile, AOL and CompuServe (OSPs - Online Service Providers) were trying to sell access but also be responsible for all of the content. The parallel with Facebook isn't quite there, because they're only selling the content. The problem is that, while there is some content on Facebook, anyone who can access Facebook can also access the whole of the web. They need to somehow justify putting content on Facebook (where only Facebook users can see it) rather than just putting it on a web site. Their argument for this is that they can collect lots of data about potential customers if you do, but it's not clear that this is a good long-term alternative.

That was more true a year ago than it is now. Modern smartphones and data plans mean that email is becoming as easy as SMS for a lot of people who would previously only check it when they actively went to their computer. This is also true of the older generation, who previously might have turned on the computer once every day or two for email, but now increasingly have tablets that can do email, thanks to companies like Amazon selling appliances that are mainly there for videos and ebooks..

The useful gadget to sell would be something cheap (under $50) that has a small array of microphones and listens to a predefined set of tones, then produces calibration data telling your audio source what it needs to do to compensate for the poor acoustics and speaker placement in the owner's living room.

Ummm... Oh, yes. It has a plethora.

If you think Morse sent over a Ham radio connection is equivalent to a telegram, then you're missing the point. It's only equivalent if someone prints it off at the far end and couriers it to the recipient.

You'd probably use a short sequence for each of the brushstrokes and compose Kanji like from them. There's an input method (Cangee? Something like that) that works like this with a QWERTY keyboard. From 26 brush strokes, it can compose any Kanji and is apparently the fastest way of entering Kanji on a computer, although it takes a while to learn.

A plethora.

A little over a decade ago was when Apple announced that laptop sales had passed desktop sales for them. This wasn't surprising, because their desktops were far less competitive than their laptops (and no one bought an Apple desktop to save money). The rest of the industry followed about two years later. We've been in a world where more laptops are sold than desktops for almost a decade. Even accounting for the fact that laptops are replaced rather than upgraded, there are now more people who use laptops as their only computer than there are desktop users.

It launched for me after doing that, but didn't actually work. It ran in FireFox, using about 50% of one core of a 2.2GHz i7 (Haswell). The same game runs very happily on a 1GHz ARM core, but I don't know what percentage of the CPU it's using there. Aside from being slow, the UI really sucks (I managed to zoom in, but not to zoom out). On a touchscreen device, I really liked the Auralux UI.

DirectX came with some advantages as well though. Like OpenGL, you ended up with a slower game than writing specialised code for a specific graphics accelerator, but the trade was that you got to support all shipping accelerators (and ones that hadn't shipped yet) by allowing them to write the code once and get a speedup everywhere. With Direct2D, you got things like accelerated sprite drawing from hundreds of graphics cards that all had different interfaces for bit blits. This meant that your Direct2D game would often be faster than a DOS version that was talking to the VGA hardware (or SGVA via VESA) and doing the same thing entirely in software.

An abstraction layer that has a small cost but buys you acceleration support in exchange is worthwhile, because the net result is faster (and simpler) code. An abstraction layer that has a big cost and doesn't give you faster code much harder to justify.

If it's nondeterministic, yes. If it's 'you can change the stack pointer in this way with this sequence of instructions' then it may be easier.

Beyond a certain point, I agree. There's a world of difference in readability between code written by people who are comfortable typing and people who type very slowly. If typing is a chore, there's always a temptation to use very short variable and function names and avoid comments. If typing a comment is something you can do while you're thinking about what the next bit of code should do, then you end up with much more readable code because the tendency is to write a description of what the code should do (and, importantly, why) in a comment, and then write the code.

The 10 lines of code a day comes from an IBM report. Note that it's not just 10 lines written, it's 10 lines of bug-free code complete with documentation and tests, averaged over large projects. For each day that you're churning out thousands of lines of code, how many days are you (or someone else) finding and fixing bugs in that code?

It depends a lot on the data structures. There were a number of papers using TSX at EuroSys this year. The main conclusion was that TSX lets you get similar performance from simple approaches as you can get already from complex approaches. For example, you can protect a long linked list in a single lock and use HLE to get a big speedup with lots of concurrent insertions and accesses, but you can achieve similar performance with a fine-grained locking scheme. There was a nice paper about Cuckoo hashing where they initially found that TSX gave them a performance win, but then were able to get a similar speedup without it.

The big win with TSX is that it's pretty easy to reason about coarse-grained locking and much harder to reason about fine-grained locking. If you can make coarse-grained locking almost as fast as fine-grained, then that's a huge saving on testing and debugging time.