The 'view spec' thing is idiocy in its purest form. Consider the following case:

-You create a branch and a view that shows files in the branch on top of the trunk.
-You edit file A.
-Some other guy edits files A and B so that B won't work without the changes in A.
-Your branched version blocks the other guy's changes in A so you have broken source code until you merge.

The same thing happens even if you are both on same branch. In that case, the explicitly checked out file blocks any changes to tip or tagged revision.

Now think what this becomes when there are lots of files and several branches / tags in the mix. Yes, ClearCase tracks every single file separately and does not have any atomic operations, which makes things very interesting.

  With dynamic views, you see everyone else's changes immediately, which opens opportunities to all kinds of messes. Heck, if your software takes a while to compile, the source code can change a few times during the compile (remember, no atomic operations, so changes happen one file at a time). The dynamic view also needs constant access to server. The latest and greatest version I had to use just froze when the connection lost and crashed completely if the machine came back to net with different IP address.

Interesting. At my university (TKK) used textbooks have been traded on the local news server at least since early 1990s. My first reaction was "Why would anybody pay to use a service that already has a better free alternative?". I guess the news are not part of internet.

An ex-coworker of mine went to work for a similar startup. I'm not sure if it was this company, but very similar. Anyway, I made the exactly same questions about latency and bandwidth everyone here makes. The answer was interesting.

This service was not even meant to compete with consoles and PCs. Instead, the real competition were those TV game shows where you play with text messages or calling the station and controlling the game with phone number keys. I, or no one of you, would never play one of those but there sure are a lot of people who do.

If they manage to stay in business until technology advances to the point where real games over internet are possible, they should be ahead of possible competition. The overall quality will still be well below local dedicated hardware, but tolerable enough for really casual gamers.

I'm still not sure this will fly, though.

Well, it is also the way you read it and pretty straight forward to convert to and from Arabic numbers. On the other hand, European languages reading numbers tend to be more complex:

In English, that's "two hundred thirty four". "[2][100][3*][4] in your notation, pretty straight forward except for the "thirty". The literal translation from German is "two hundred one and thirty" or "[2][100][4][3*]", which is already a bit weird. And then there are all Latin derived languages that use some variation of the Roman system.

In Finnish, the reading of numbers has actually changed to resemble the way you described as Asian. The archaic way would translate to "two hundred four of the fourth". The old reading still remains for numbers 11-19, which are also exceptions in every other language I know.

Java has final references. Just set one in the constructor, and it is guaranteed to never change.

It is annoying, though, that every small member object carries its own memory allocation and garbage collection overhead.

The cool thing about RISC is that you do well without scoreboarding and, depending on the architecture, probably without branch prediction.

In typical RISC setups (i'm talking from experience with C55x and C64x DSPs, AFAIK ARM is pretty similar to the latter) the pipeline is well documented. It is the compiler's job to check for conflicts. No scoreboarding. Since the compiler optimizes code to this particular pipeline, there is no need for out of order execution either.

This also puts an interesting twist on branches: If the condition for branch can be calculated before the actual branching point, there may be code after the branch instruction that still gets executed before the actual branch takes place. This allows explicitly writing code that fully utilizes the pipeline even at branch.

C64x and ARM can have a predicate for every instruction. This means that every instruction may have a binary flag that tells if the instruction is to be actually executed. The value of the flag is checked after instruction decoding and other steps, exactly when the instruction is executed. So, a lot of branches for only few instructions can be replaced with predicated instructions.

Of course, these tricks need a lot of compiler support. Lack of it was one thing that killed the Itanium, but the TI DSPs and ARM seem to be doing well.

Things like PlayStation 3, XBOX 360 and such are running on RISC processors. I would guess that if CISC was really that superior to RISC, they would not have gone the RISC way when designing those custom processors. Actually, they could have just taken off-the-shelf x86 processors and enjoy all the research that has gone to them over the decades.

Actually, ATMs around here let you pull out the card during transaction. Unlike with voting machines, you can easily tell that the transaction failed by the fact that you have no cash.