The Android kernel is a Linux kernel. That part is true. But, a Linux kernel is far from sufficient for building an Android device or running Android apps.
Google is not placing these restrictions on that part. The use of the Linux kernel does not spread virus-like to random other components of the distribution, so has pretty much no bearing on the stuff under discussion.
In practice, Android is not very open right now, and is very deliberately becoming less open over time. (This has both advantages and disadvantages.)
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.
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.
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.)
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...)
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?
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.)
... in which case that still leaves room for a high-performance dedicated gaming rig to steal the show...
As Moore's Law gets to work on "casual" games, I'm not certain that in the long run there will always be a market for "a high-performance dedicated gaming rig" that's big enough for the console industry to cater to.
My experience has been, the more one is focused on "high-performance gaming", the more one is likely to tolerate the tradeoffs involved in gaming on a general purpose computer instead of a dedicated gaming appliance.
I also believe that some folks are "focused on high-performance gaming" only because they want a certain minimum level of performance that's not so easy to meet with the appliances. I'd say for a lot of people that threshold isn't as high as "60 fps at 1080p".
So, when incredibly cheap games on incredibly cheap gadgets are routinely able to do 1080p at 60fps, I think you'll have the cheapskates and the gearheads, and not an awful lot of room in between for today's AAA-focused console industry to survive in.
(I could easily be wrong. I expect to have fun watching the industry to find out.)
Sure. Remember that they were founded in 1889. They had a business before video games, and if necessary, they'll have a business after video games.
I think that's where some of their behavior actually comes from. There's a certain level of autonomy that I don't think they're willing to give up, even if that means their video game business tanks.
The PC didn't kill consoles for the same reason that smartphones won't - People don't want to screw around with variable configurations and unknown levels of performance and controller compatibility. They want a known-working machine such that they can buy a game, put it in, turn it on, and have it work exactly the same way as it did last time, as it does for everyone else, as the manufacturer intended it to work.
I am less certain than you seem to be that smartphone manufacturers will be unable to adequately address that problem.
Let's say you use a succession of Android phones, and your TV has a ChromeCast attached to it, and some particular bluetooth controller becomes a de-facto standard. The experience begins to approach that of a solid console. If it's also extremely cheap...
(Would I bet on this? No, not with my own money. But I wouldn't bet against it either.)
While it's not a complete answer, the degree to which a framework is open source is a significant factor.
If you use a proprietary framework, then it is possible that it won't get updated to support future platforms or that it'll be yanked out from under you entirely.
If you use an open source framework, it may become unpopular and difficult to support, or may even never get very wide support to begin with (cf. "GNUstep"), but the option to "keep it going" is there. Your future is more firmly in your own hands (or the hands of hired experts). It stops being "we have no practical choice and must stop using this" and instead becomes "the cost of using this is going up".
Does this mean "always pick open source"? I won't assert that it does. But, when all things are otherwise equal, some risks are certainly lower with open source.
Another factor is picking a runtime that's got demonstrated portability. You could be running open source all up and down in your own software, but if you were targeting Windows Phone 6 or Blackberry as your target platform, nothing would have saved you. But if you're running in an extremely portable interpreter (potentially including things like the JVM or CLR) that hides the underlying system from you, again, you have options you wouldn't otherwise. (Heck, a lot of Java code can even be portable between the JVM and Davlik.)
From my experience, the hardest thing for a programmer that because code may look weird or ugly is NOT a reason by itself to change it. The only reason to change it is if it is buggy, or does not meet the current requirements.
I don't really agree 100%.
Often, code looking weird or ugly is a hint that the code is less easy to maintain than it might be. Changing code so that it's more easy to maintain can be a very big win in the long run.
If it's going to be weird or ugly, and there's a good reason for that, document it.
For me, I think the hardest part is often "figuring out what to build in the first place". Sometimes that starts from a product idea. Sometimes it starts from an imperfect requirements document. (I have never seen a perfect requirements document.) Going from that to "what do I build?" is the hardest part.
If you are the sort of programmer who works on big projects and is handed a clear and unambiguous spec... then sorry, I have absolutely no idea what your hardest problem might be.
You are not going to write everything from scratch by yourself. You're just not. Not if you actually want to get anything done. You're going to reuse code.
So: figure out what code you're most likely to reuse, what frameworks are useful in the field you're interested in, and let that suggest the language.
If you don't know how to get started on that: asking the question of peers in the same scientific field will get you a more useful answer than asking the question on a wide-open generic technical forum.
Another angle: look at what network databases you want to integrate with (eg. protein databases at nih.gov), and look for sample code showing how to access 'em. That'll give you a clue what other practitioners are doing.
Slashdot Mirror
Not in the sense you probably mean, no.
The Android kernel is a Linux kernel. That part is true. But, a Linux kernel is far from sufficient for building an Android device or running Android apps.
Google is not placing these restrictions on that part. The use of the Linux kernel does not spread virus-like to random other components of the distribution, so has pretty much no bearing on the stuff under discussion.
In practice, Android is not very open right now, and is very deliberately becoming less open over time. (This has both advantages and disadvantages.)
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.
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."
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.
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.)
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?
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.
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.)
As Moore's Law gets to work on "casual" games, I'm not certain that in the long run there will always be a market for "a high-performance dedicated gaming rig" that's big enough for the console industry to cater to.
My experience has been, the more one is focused on "high-performance gaming", the more one is likely to tolerate the tradeoffs involved in gaming on a general purpose computer instead of a dedicated gaming appliance.
I also believe that some folks are "focused on high-performance gaming" only because they want a certain minimum level of performance that's not so easy to meet with the appliances. I'd say for a lot of people that threshold isn't as high as "60 fps at 1080p".
So, when incredibly cheap games on incredibly cheap gadgets are routinely able to do 1080p at 60fps, I think you'll have the cheapskates and the gearheads, and not an awful lot of room in between for today's AAA-focused console industry to survive in.
(I could easily be wrong. I expect to have fun watching the industry to find out.)
Will Nintendo survive?
Sure. Remember that they were founded in 1889. They had a business before video games, and if necessary, they'll have a business after video games.
I think that's where some of their behavior actually comes from. There's a certain level of autonomy that I don't think they're willing to give up, even if that means their video game business tanks.
I am less certain than you seem to be that smartphone manufacturers will be unable to adequately address that problem.
Let's say you use a succession of Android phones, and your TV has a ChromeCast attached to it, and some particular bluetooth controller becomes a de-facto standard. The experience begins to approach that of a solid console. If it's also extremely cheap...
(Would I bet on this? No, not with my own money. But I wouldn't bet against it either.)
While it's not a complete answer, the degree to which a framework is open source is a significant factor.
If you use a proprietary framework, then it is possible that it won't get updated to support future platforms or that it'll be yanked out from under you entirely.
If you use an open source framework, it may become unpopular and difficult to support, or may even never get very wide support to begin with (cf. "GNUstep"), but the option to "keep it going" is there. Your future is more firmly in your own hands (or the hands of hired experts). It stops being "we have no practical choice and must stop using this" and instead becomes "the cost of using this is going up".
Does this mean "always pick open source"? I won't assert that it does. But, when all things are otherwise equal, some risks are certainly lower with open source.
Another factor is picking a runtime that's got demonstrated portability. You could be running open source all up and down in your own software, but if you were targeting Windows Phone 6 or Blackberry as your target platform, nothing would have saved you. But if you're running in an extremely portable interpreter (potentially including things like the JVM or CLR) that hides the underlying system from you, again, you have options you wouldn't otherwise. (Heck, a lot of Java code can even be portable between the JVM and Davlik.)
I don't really agree 100%.
Often, code looking weird or ugly is a hint that the code is less easy to maintain than it might be. Changing code so that it's more easy to maintain can be a very big win in the long run.
If it's going to be weird or ugly, and there's a good reason for that, document it.
...I was hoping to avoid the 2038 bug.
For me, I think the hardest part is often "figuring out what to build in the first place". Sometimes that starts from a product idea. Sometimes it starts from an imperfect requirements document. (I have never seen a perfect requirements document.) Going from that to "what do I build?" is the hardest part.
If you are the sort of programmer who works on big projects and is handed a clear and unambiguous spec... then sorry, I have absolutely no idea what your hardest problem might be.
You are not going to write everything from scratch by yourself. You're just not. Not if you actually want to get anything done. You're going to reuse code.
So: figure out what code you're most likely to reuse, what frameworks are useful in the field you're interested in, and let that suggest the language.
If you don't know how to get started on that: asking the question of peers in the same scientific field will get you a more useful answer than asking the question on a wide-open generic technical forum.
Another angle: look at what network databases you want to integrate with (eg. protein databases at nih.gov), and look for sample code showing how to access 'em. That'll give you a clue what other practitioners are doing.
...that I do my best not to talk to gamers.