Ah, so it's a problem for the people with a specific business model that requires having precise control over both ends of the connection, making them fundamentally incompatible with openness and interoperability. Okay.

Myself, I'm not very sympathetic, as I actively want to see those business models fail and get abandoned. But now I have a better understanding of why someone might dislike the situation. Thanks!

IMHO, the ideal situation is, you define standard formats and protocols, and then you give everyone the freedom to use whatever technology they want to interoperate using those protocols.

Want to write your mail server in Java? Python? Prolog? I do not care as long as it speaks IMAP. Want to write your mail client in C#? Objective-C? Ruby? I do not care as long as it speaks IMAP.

Isn't this exactly how things should be?

For some people, there's no need for any disclosure beyond what they've already done 100% publicly. I'm pretty sure I could whip up an RMSbot over a long weekend, for example.

I find 2X Client RDP/Remote Desktop to work very well on the Android. It has full support for RDP in Windows. not sure about Mac, never had to use it.

RDP will not connect to MacOS. This should not be surprising -- it's the built-in protocol from Microsoft.

The remote display protocol that Apple built in is based on VNC, and can be configured to work with standard VNC clients. So my answer to the original user's question would be "use your favorite RDP client for the Windows boxes, and your favorite VNC client for the MacOS boxes".

On iOS, I use iSSH for both. It's an SSH client that has a built in RDP client, VNC client, and X11 server (remember that server and client are "reversed" for X11) and tunnels all three protocols over ssh. I do not know if there's a similar program for Android, but for iOS this one has been awesome.

"We had to destroy the village in order to save it."

This was one years before then, it used to be normal to be cross language. Ie, VMS was implemented in a variety of languages, Unix provided a common calling standard between languages, etc.

I remember things being very easy on Unix until the advent of C++. As long as you were careful, I recall no problems interfacing between C and FORTRAN and Pascal and such. (You had to be careful because, for example, FORTRAN didn't understand the concept of pointers and dereferencing, so C code that didn't respect that could confuse the bejezis out of FORTRAN's optimizers.)

My old startup company (mid to late 1990s) sold a product with a C API. We integrated it with Perl, Python, Java, TCL, and PHP.

TCL was glorious at this. Once h2xs came into being, Perl wasn't bad (at least back in the days when nobody expected to do OO Perl yet). Python (1.5) wasn't bad at all. Even PHP was doable with a little work (it got easier later).

But C++ stormed ahead with overloading, and without a care for ABI compatibility -- you couldn't even assume the products of two different C++ compilers, or even two different versions of the same compiler, could be linked with each other, and it's all gone downhill from there.

I was going to give my opinion on the best approach for dealing with this, but there isn't one. The problem is, the best approach for maintainability is bad for performance (and vice versa). But my preference when one can get away with it is basically to do "RPC" over an I/O channel instead of attempting direct linking.

Everybody's every move being tracked in the name of lower premiums or children safety is downright scary.

What's worse: safe, conservative drivers opting in to this in order to prove that they're safe and get lower rates, or forcing safe drivers to subsidize the insurance of reckless drivers because the insurer has no way to distinguish between the two?

(I think the answer depends on other factors, like privacy controls, consumer protection, and system security.)

This fellow needs to work on his self-esteem.

A thing that actually worked in our environment for a while was setting up a lounge with an XBox and "Rock Band" in it.

Very different people ended up playing together, at lunch time. There'd be offhand comments about what we did, and connections got made that remained useful for ages.

(Alas, new management thought it frivolous and discouraged this, and as a result, communications has been breaking down...)

Depends on where the heavy lifting is.

If you've got a JavaScript that implements web SQL and web GL, well, those are implemented in low-level languages and you're just going to call them from JavaScript. If that happens to be where the bulk of the work is for a given program, you might get better performance out of JavaScript than Java.

(The devil is in the details. I do not know the details in this specific case.)

The first time I saw this basic thing done, in a hacky way, was between the ham radio clubs of my university and our neighboring university, in... the late 1980s.

They took two helium-neon laser tubes (laser diodes not being as available to hackers yet), two photosensors, and two little shutter-like things that modulated light proportionally to some voltage. Then they took two acoustic modems. They hooked the sound-generation output to the thing that modulated the light and the sound input to the photosensors, lined up the beams, and got the modems talking to each other.

As I recall, they had a working 1200 baud connection from over a dozen blocks away. Didn't have any practical use, but it was kinda awesome.

(I think I've still got a box of old helium neon laser tubes in my basement somewhere.)

Sorry, that sort of acoustic coupling is bound to be loaded with errors. You might be lucky to get 16 BYTES per second, and even then, those speakers aren't powerful enough to transmit very far.

You know that ultrasonics are precisely how a modern Furby communicates with its companion iPhone app? (There's even perl code implementing it so you can hack them.)

How hard would it be to create a runtime environment for XP similar to WINE on Linux and MacOS that provides missing APIs and such so that things written to require newer versions of Windows could continue running on it?

Related point: is enough known about the OS that third parties could realistically provide their own security updates to it?

Did you try OnLive when it first came out?

Haven't had a chance to.

The point was simply that if you had tried it when it was new and also today, you could have observed that it's actually gotten better.

The theoretical bandwidth/latency problems are absolutely still there, sure. But the environment has been improving such that the practical real-world problems are shrinking on their own. (Not down to zero, of course. But more games are now more playable for more people. Which relates to why Sony is willing to bet on it.)

It's all going to become more viable over time, until at some future date the number of cases where it's a problem is small enough that most people ignore them.

That might work for turn-based games, but real-time games are far more sensitive to latency than the noninteractive movies and television series for which the Chromecast was designed. How much display latency does the Chromecast add?

Did you try OnLive when it first came out? Have you tried it recently? What exactly is Sony planning for backwards compatibility?

(We're talking about the future here. The problems you're talking about are getting better. At some point, they'll get better enough that for most people they won't be problems anymore. It may not be safe to bet on when that will happen, but it's safe to bet that it will happen.)