Not much about Roy Trubshaw the original inventor of MUD but then again I used to work with Roy and had no idea he'd done such a thing in his student days. Lovely guy but not exactly a self publicist!

ADVENT was a great game, am pondering porting David Platt's A-Code to our rules engine...

And if you keep reading that thread you will find a post from the real Andrew Lamb which is so utterly different in tone that it is clear that the AC post is a troll by some sad bastard.

Hurrah - it's been weeks since the last new programming language!

Love the way Americans call it a jump rope so as not to sound too girly :)

Segmented stacks is an implementation issue. Java on z/OS has had segmented stacks from the very beginning because it runs on LE (the z/OS Unix layer) and that's what LE does. You still have a problem with thousands of threads though because you have to choose an initial stack segment size. Too big and you still consume loads of memory, too small and there is an overhead associated with crossing the segment boundary (e.g. page fault).

First of all, research has shown again and again that harsh penalties simply do not work as a deterrent to other offenders.

Citation please and without it, why has this been modded up to 5? The sentence has created huge publicity here in the UK and that if nothing else should make the looter cretins think twice before posting similar incitements to riot.

And yes, it's quite possible that another riot is around the corner. NOBODY expected what happened last Monday and who's to say it won't happen again.

Likewise this is typical smart-ass Slashdot BS along the usual lines of "nothing to see here, move along please". By not even bothering to read or think about the article (no time, so many feeds to keep up with!) you're kind of making his point for him.

Don't quite understand this. The implication is that the time spent processing the message in the TCP/IP stack (and not the network latency itself) is a significant percentage of the overall transaction time. Which seems unlikely. Also they have (say) 1000 front-ends connecting to 100 matching engines. So why not simply add extra cores to the front-ends and do the matching there? Just cut out the network latency altogether. I know they say the traders can't connect directly to the matching engines but that's just semantics - there's no difference between having the separation physically and within the same machine.

Linkedin is the only other "social media" account I have and I will never have a Facebook account and shunned MySpace when it was introduced. For me, the lack of any social decency that stems from anonymity is simply not worth it.

Unless you have some very strange friends you should give Facebook a try. Everyone I know (and as far as I can tell everyone that they know) uses their own real name.

The perfect storm is coming, Wall Street CEOs have been dumping their own stock holdings at unheard of ratios, they know what is going to be happening.

Citation please. When I tried googling for evidence it appears to be a recurring story over the past few years.

Internally, the user-facing side of Facebook is in PHP. But the front end machines don't talk directly to the databases. They use an RPC system to talk to other machines that do the "business logic" parts of the system. Building a Facebook reply page may involve a hundred machines. There's heavy caching all over the system, of course, so the databases aren't hit for most read requests.

The RPC system isn't HTML, JSON, or SOAP. It's a binary system that doesn't require text parsing. Otherwise, RPC would be the bottleneck.

Um, if a single reply page involves a hundred machines, I don't think the RPC mechanism is the root cause of their problem.

There was a similar article yesterday.

Changes in major air currents year over year (things like El Nino, for instance) can change the length of the day by close to a millisecond: hundreds of times more than this little earthquake.

Or when a couple of little buildings get knocked over by planes.

If not, you need to *first* load it on one mode of transport (typically some kind of car) -then- drive to the nearest "station" where the goods are repackaged, then near the destination, repeat.

This is pretty much what happens with the postal service. Large lorries are used for the large distances, depot to depot, and small vans take the parcels from depot to final destination. All we are suggesting is replacing the depot to depot part.