Some people still think that video games are only for kids, regardless of the content of the game. Getting past this idea would help a lot.
We are well past the point where many parents themselves were once kids listening to music with explicit lyrics and playing violent video games.
Some still play non-casual games. The last stats I saw had two big spikes in the age histogram, one around 15 and the other around 35.
Most notice a lack of ill effects on themselves and their childhood friends. Some recall the hysteria of Al Gore and his wife Tipper regarding music decades ago and take today's hysteria no more seriously than the hysteria of their childhood.
That's an enforcement detail that easily changed in the future. Come on.
Changing the definition of personally identifiable information (PII) is not a small detail. Doing so would have massive consequences on domestic data processing as well. Businesses would undertake a massive effort to "educate and inform" politicians should they think about doing so.
More importantly, it attributes real value to personal data. That makes sense today, since it's sold as a currency already.
These laws are about protecting domestic jobs not about protecting your personal privacy. Its an attempt to keep the processing of information in the EU. The problem is it is applicable only to personal data, businesses already work around this by anonymizing data. Names, addresses, social security numbers / national ID numbers and other personally identifiable information (PII) are replaced with codes only the domestic organization knows. Thus the data transferred outside the EU has no PII. When the processed information is returned to the EU the codes are replaced with the PII.
There's nothing interesting or revolutionary about the iPhone 5.
The 5 is discontinued, its the 5S that is of interest now. Personally I find the mobility coprocessor interesting. Instead of frequently getting a GPS fix the 5S can get a fix less frequently and determine intermediary positions by the motion it senses via the motion processor while the CPU and GPS circuits are powered down. It could greatly reduce battery usage during some activities.
Also as a developer I think the A7 CPU is interesting, opening up some new possibilities for apps. I used to do some work in computer vision, it may be more practical to do such stuff on the A7.
People forget when Microsoft injected cash in Apple when it was going nowhere.
That was when Apple was a computer company. Apple is now a phone, tablet and music device company, its in a different market. In the old computer market Apple had a lot of 800-lb gorillas as competitors, in the new devices market Apple is one of the 800-lb gorillas.
Yes Apple still sells computer but that is not their focus. The revenue largely comes from the devices side. Apple has even changed its name to remove "Computer".
I'd love to know who is still buying Apple devices when Android gizmos do pretty much the same thing for a fraction of the cost.
Because the "fraction of the cost" argument doesn't apply to most people in the U.S. Its not the cost of the unsubsidized no-contract phone that most people see, its the cost of the subsidized phone with a contract. To most people an iPhone 5S is $200, a 5C is $100 and a 4S is free. Much like they see a Samsung Galaxy S4 for $200 rather than $600, and a Galaxy S III for free rather than $400.
Given the subsidy iOS and Android are basically equivalent in cost. What helps Apple is the app ecosystem. Apple gets more attention from developers, 4x the revenue per app download (over $0.08 on average vs under $0.02), less fragmentation to deal with (dev time and test time),...
Recently I found a copy of PostgresSQL Essential Reference (2002) and Programming Perl (1996). Would you have left them to RIP?
When I replace a book with a newer edition I set aside the older edition. Sooner or later a relative, friend, co-worker, someone will express an interest in learning to program or learning some new area. My old K&R The C Programming Language, Foley and van Dam Fundamentals of Interactive Computer Graphics, etc all found new homes this way. Why toss out a book that someone curious might want to take a look at?
I downgraded my iPad back to 6.1.3.... It's perfectly doable.
You must have an iPad 1. It is impossible to downgrade any iOS device after the iPhone 4S/iPad 2. You cannot do anything meaningful with the SHSH blobs. So its perfectly doable for you, and a handful of people on older hardware. But it is not perfectly doable in general.
The first generation iPad won't upgrade past iOS 5.1.1.
Downgrades are generally possible for a very brief time period when a new version is introduced. Apple does not seem to disable installation of the old version immediately upon release of the new version, it will happen, but there is a delay.
I downgraded my iPad back to 6.1.3.... It's perfectly doable.
Its temporary. When new iOS versions are introduced there is generally a brief window of time where Apple's servers approve both versions for installation. After a little while the previous version will be removed from the approved list and only the new version will be approved from that point forward.
The fact that many developers don't see it [Linux] is irrelevant,
Not to my point because that was my point all along, Thank you for finally acknowledging that app developers don't see Linux. As I stated in my first post: "End users and nearly all **developers** don't see it [Linux]."
Android apps rely on some native libraries, those native libraries are implemented on Linux (and some of it is linux-specific, like Bionic and SurfaceFlinger for example) so it is tied to Linux...
You are referring to libraries not exposed in the Android API. Bionic is a libc variant available via the NDK, just like the Linux kernel itself. SurfaceFlinger uses OpenGL and the GPU. These are part of the internal Android implementation not the Android API, in other words hosting code.
... you could - in theory - re-write and re-compile the native dependencies for another platform...
Thank you for finally acknowledging that Android could probably be ported to another platform, as I stated in my first post: "The Linux kernel could probably be swapped out with a BSD kernel and few would notice. Even for those using the NDK and writing some C code they are probably making POSIX calls not calls to anything Linux specific."
We agree that developers don't see Linux and that Android could probably be ported to another hosting environment without impacting most developers (including those using the NDK for libc and posix).
Where we disagree is whether being hosted on Linux makes Android Linux. You think so. I think not, I think it is the API that makes Android Linux or not Linux. As we agree that most apps/developers would not be impacted by porting Android from Linux to BSD I think I have a strong argument.
I get that they might be sad when a robot they were using somehow gets lost or destroyed, but I really can't see that influencing how likely they are to use that robot for dangerous situations unless the soldier had somehow personally invested time and energy into making the robot do or act the way that it does, and in particular such that it would require some substantial personal investment (monetary, timewise, workwise, or simply having to wait a while) to replace it.
I get that they might be sad when a robot they were using somehow gets lost or destroyed,...
The soldier gets sad when the robot is destroyed because next time the solder has to go downrange instead of the robot.
... but I really can't see that influencing how likely they are to use that robot for dangerous situations unless the soldier had somehow personally invested time and energy into making the robot do or act the way that it does, and in particular such that it would require some substantial personal investment (monetary, timewise, workwise, or simply having to wait a while) to replace it.
I think this is nothing new. Consider a sailor and his ship. Sailors invest a lot of time and effort working on their ship, maintaining it, improving it. Its their home. Its a place of safety in a very hostile environment (the sea). They often get to love their ship yet they risk it in battle. They do so because they love something else even more, getting home. Similarly the soldier will risk the robot so he gets home.
No, the app and app developer perspective has been my argument since my first post in the thread.
Wrong, you explicitly said Android is a Java environment...
Wrong. My fist post: "No, its not. End users and nearly all **developers** don't see it. The Linux kernel could probably be swapped out with a BSD kernel and few would notice. Even for those using the NDK and writing some C code they are probably making POSIX calls not calls to anything Linux specific."
... which is clearly not the case because it requires platform specific libraries in order to operate
You use the word, "operate", you are discussing hosting Android. I am not.
What Linux specific call appears in the Android API? This is what I have been discussing.
You're presuming that $1Bln put into FreeBSD work is going to EVER be contributed back. That's NOT a foregone conclusion, perpenso.
Like Google's modifications to Linux that are not contributed back because they are only used internally, not shipped to others, and are considered a trade secret by Google?
You keep discussing things related to hosting and or porting Android itself. I am discussing writing apps that run on Android. These are two different things.
You changed your argument because you failed early on in the discussion regarding the portability of Android, now you've changed to talk about apps that run on Android
No, the app and app developer perspective has been my argument since my first post in the thread. You simply misunderstood, perhaps that was my fault initially. However at this point you have no excuse.
Android is made up of Java and native libraries, the Java libraries are portable, the native ones are not.
No. Android's JNI wrapped C libraries are not Linux specific, they are cross platform: libc, opengl, sqlite, webkit, etc.
The way I read the release is that IBM is going to hire people in France to support linux, while laying off people in the US doing AIX and Linux work.
There is also the gov't policy angle. The US gov't wants to tax foreign profits. So companies like Apple and IBM have a lot of money overseas that they don't know what to do with. Spending what they earn overseas in an overseas development effort avoids these additional taxes.
The US gov't basically seems to be encouraging IBM to shut down US development and move it overseas. Sure its an unintended consequence but many gov't failings stem from the unintended consequences of good intentioned policy.
As long as no one can just take their ball and go home BSD style...
Wrong. With BSD you can go but you have to leave your ball, you are free to get a new ball and keep it to yourself though. Nothing already contributed can be taken away, you just stop contributing. The BSD community does not lose a single line of code.
As I said yesterday in comments regarding the article about Linus falling out of the top 100 code contributors list...
Linux is primarily developed by corporations or government entities, directly or through subsidies, and not the more romantic hobbyist developer contributing his/her personal time.
You are fundamentally misunderstanding what I am saying. The Android APIs are portable by design, host agnostic by design. Android ***apps*** do not require Linux, even many NDK based ***apps*** do not require Linux since they just call libc or posix. Android ***app developers*** do not see Linux unless they make a special effort to do so by adding new JNI wrapped C libraries that extend Android.
You keep discussing things related to hosting and or porting Android itself. I am discussing writing apps that run on Android. These are two different things.
The iPhone 5C is not really a new phone. It seems to be an iPhone 5 that went through a cost reduction process.
Hence the existing iPhone 5 being discontinued rather than demoted to a lower price tier.
Not only does this help preserve Apple's profit margins at the midrange price tier but by making this phone "less attractive" to those who can afford an iPhone 5S Apple reduces cannibalization. If the original iPhone 5 were still available too many people may have opted for it over the 5S. This will happen to a lesser degree with the 5C.
What is being claimed is that the Android development environment is a java based environment where the underlying host OS is abstracted away and irrelevant to the java app.
Then show me it running on another host.
You are arguing a tangential point that no one is disagreeing with. Android is hosted on Linux. That does not change the fact that stock Android completely abstracts away the OS from the app's and the developer's perspectives. There are Android devices where you do not even have the option to use the NDK to add a JNI wrapped C library that can access Linux, for example Google TV.
a Java application that calls out to a native library is no longer just a Java application.
Untrue. Java itself is partially implemented with native libraries. These libraries, like the Android libraries, are wrapped appropriately and from the apps perspective a Java implemented class is indistinguishable from a C implemented class. Whether a class is implemented in Java or JNI wrapped C is irrelevant, its an implementation detail the app knows nothing about.
Some libc functions are implemented in assembly language. Calling those from your C or C++ app does not make these apps any less C or C++.
Its probably not a swipe. Just acknowledging that Linux is primarily developed via corporate/governmental subsidies and not the more romantic hobbyist developer contributing his/her personal time.
The support libraries are Android's extension of the Java environment.
Yes they are native Android libraries - that do not sit atop Java - that access the functionality of the underlying operating system.
And parts of Java are also implemented in native code. Its irrelevant. The host OS is abstracted away, the java app never sees it.
The android app sees Java classes not the underlying C implementation.
But the C implementation is executed natively, not within the Java environment, because it does not sit atop Java, it executes at the native level.
Again, that is irrelevant. The java app does not know or care. Its a hidden implementation detail.
Are you thinking that someone is claiming that Java is purely implemented in Java? No one is claiming that. What is being claimed is that the Android development environment is a java based environment where the underlying host OS is abstracted away and irrelevant to the java app. That Android is a java based environment, not a Linux based environment, that Linux is just a host OS that Android apps are unaware of. Most apps on the Google Play store are pure Java. For the minority that use the NDK to extend Android and access the host OS through a custom library, many of these are not even Linux based. They are generally accessing c runtime libraries and possibly posix functionality, rarely something Linux specific. Linux is just a host OS. Its not required by stock Android. Its not even required by most NDK based apps.
For example with respect to OpenGL: GLSurfaceView, android.opengl.GLES20. The environment is still Java language based and the underlying host OS still irrelevant.
Wrong, when I call native code from Java that code is not executed in the Java environment even if you think there is some magic that makes it do so.
No magic. Just you fundamentally misunderstanding what I am saying. As the author that is my fault not yours.
I originally referred to developing desktop/server/embedded apps. C developers working on these apps have access to the kernel headers and APIs. I do not think we are referring to the same thing with respect to desktop development.
Its a tangent anyway. The focus of my comment was Android, which is sort of its own operating system and environment where the underlying host OS is not available to the Java developers. If you want to discuss the NDK where an Android developer can extend the Android environment with a custom library implemented in C that has access to the kernel, well there is already a thread on that.
The support libraries are Android's extension of the Java environment. The android app sees Java classes not the underlying C implementation. For example with respect to OpenGL: GLSurfaceView, android.opengl.GLES20. The environment is still Java language based and the underlying host OS still irrelevant.
The point is that in desktop/server/embedded Linux environment the developers sees the kernel API. Under Android they do not. Android is a Java environment not a *nix environment.
Bollocks, if I write a desktop app in Java (Eclipse for example...) all I see is Java API, but that doesn't mean Eclipse is not running on Linux.
The Java app is not running on Linux, it is running on a Java virtual machine. That is one of the benefits of Java, it isolates you from the host operating system so that your app is portable. What that Java virtual machine is running on is irrelevant to your app. Would you claim that a Windows app is Linux based because MS Windows is running on a virtual machine hosted on a Linux box?
I give up, you really are quite mad.
Perhaps you are failing to see that you are arguing that Android "runs on Linux" and I am arguing that Android "is a Java environment". These are two different things. No one is claiming that the Dalvik VM is not being hosted on Linux in Android, my claim is merely that whatever OS is currently hosting the Dalvik VM is irrelevant to the app and its developer. Much as a MS Windows app and its developer don't care if it is running on native hardware or a VM, and in the later case doen't care what OS is hosting the VM.
In other words. If you are virtualized the host OS is irrelevant.
Slashdot Mirror
Some people still think that video games are only for kids, regardless of the content of the game. Getting past this idea would help a lot.
We are well past the point where many parents themselves were once kids listening to music with explicit lyrics and playing violent video games.
Some still play non-casual games. The last stats I saw had two big spikes in the age histogram, one around 15 and the other around 35.
Most notice a lack of ill effects on themselves and their childhood friends. Some recall the hysteria of Al Gore and his wife Tipper regarding music decades ago and take today's hysteria no more seriously than the hysteria of their childhood.
That's an enforcement detail that easily changed in the future. Come on.
Changing the definition of personally identifiable information (PII) is not a small detail. Doing so would have massive consequences on domestic data processing as well. Businesses would undertake a massive effort to "educate and inform" politicians should they think about doing so.
More importantly, it attributes real value to personal data. That makes sense today, since it's sold as a currency already.
These laws are about protecting domestic jobs not about protecting your personal privacy. Its an attempt to keep the processing of information in the EU. The problem is it is applicable only to personal data, businesses already work around this by anonymizing data. Names, addresses, social security numbers / national ID numbers and other personally identifiable information (PII) are replaced with codes only the domestic organization knows. Thus the data transferred outside the EU has no PII. When the processed information is returned to the EU the codes are replaced with the PII.
There's nothing interesting or revolutionary about the iPhone 5.
The 5 is discontinued, its the 5S that is of interest now. Personally I find the mobility coprocessor interesting. Instead of frequently getting a GPS fix the 5S can get a fix less frequently and determine intermediary positions by the motion it senses via the motion processor while the CPU and GPS circuits are powered down. It could greatly reduce battery usage during some activities.
Also as a developer I think the A7 CPU is interesting, opening up some new possibilities for apps. I used to do some work in computer vision, it may be more practical to do such stuff on the A7.
People forget when Microsoft injected cash in Apple when it was going nowhere.
That was when Apple was a computer company. Apple is now a phone, tablet and music device company, its in a different market. In the old computer market Apple had a lot of 800-lb gorillas as competitors, in the new devices market Apple is one of the 800-lb gorillas.
Yes Apple still sells computer but that is not their focus. The revenue largely comes from the devices side. Apple has even changed its name to remove "Computer".
I'd love to know who is still buying Apple devices when Android gizmos do pretty much the same thing for a fraction of the cost.
Because the "fraction of the cost" argument doesn't apply to most people in the U.S. Its not the cost of the unsubsidized no-contract phone that most people see, its the cost of the subsidized phone with a contract. To most people an iPhone 5S is $200, a 5C is $100 and a 4S is free. Much like they see a Samsung Galaxy S4 for $200 rather than $600, and a Galaxy S III for free rather than $400.
...
Given the subsidy iOS and Android are basically equivalent in cost. What helps Apple is the app ecosystem. Apple gets more attention from developers, 4x the revenue per app download (over $0.08 on average vs under $0.02), less fragmentation to deal with (dev time and test time),
Recently I found a copy of PostgresSQL Essential Reference (2002) and Programming Perl (1996). Would you have left them to RIP?
When I replace a book with a newer edition I set aside the older edition. Sooner or later a relative, friend, co-worker, someone will express an interest in learning to program or learning some new area. My old K&R The C Programming Language, Foley and van Dam Fundamentals of Interactive Computer Graphics, etc all found new homes this way. Why toss out a book that someone curious might want to take a look at?
I downgraded my iPad back to 6.1.3.... It's perfectly doable.
You must have an iPad 1. It is impossible to downgrade any iOS device after the iPhone 4S/iPad 2. You cannot do anything meaningful with the SHSH blobs. So its perfectly doable for you, and a handful of people on older hardware. But it is not perfectly doable in general.
The first generation iPad won't upgrade past iOS 5.1.1.
Downgrades are generally possible for a very brief time period when a new version is introduced. Apple does not seem to disable installation of the old version immediately upon release of the new version, it will happen, but there is a delay.
I downgraded my iPad back to 6.1.3.... It's perfectly doable.
Its temporary. When new iOS versions are introduced there is generally a brief window of time where Apple's servers approve both versions for installation. After a little while the previous version will be removed from the approved list and only the new version will be approved from that point forward.
If you with reinstall iOS 6 do not delay.
The fact that many developers don't see it [Linux] is irrelevant,
Not to my point because that was my point all along, Thank you for finally acknowledging that app developers don't see Linux. As I stated in my first post: "End users and nearly all **developers** don't see it [Linux]."
Android apps rely on some native libraries, those native libraries are implemented on Linux (and some of it is linux-specific, like Bionic and SurfaceFlinger for example) so it is tied to Linux ...
You are referring to libraries not exposed in the Android API. Bionic is a libc variant available via the NDK, just like the Linux kernel itself. SurfaceFlinger uses OpenGL and the GPU. These are part of the internal Android implementation not the Android API, in other words hosting code.
... you could - in theory - re-write and re-compile the native dependencies for another platform ...
Thank you for finally acknowledging that Android could probably be ported to another platform, as I stated in my first post: "The Linux kernel could probably be swapped out with a BSD kernel and few would notice. Even for those using the NDK and writing some C code they are probably making POSIX calls not calls to anything Linux specific."
We agree that developers don't see Linux and that Android could probably be ported to another hosting environment without impacting most developers (including those using the NDK for libc and posix). Where we disagree is whether being hosted on Linux makes Android Linux. You think so. I think not, I think it is the API that makes Android Linux or not Linux. As we agree that most apps/developers would not be impacted by porting Android from Linux to BSD I think I have a strong argument.
Just... no.
I get that they might be sad when a robot they were using somehow gets lost or destroyed, but I really can't see that influencing how likely they are to use that robot for dangerous situations unless the soldier had somehow personally invested time and energy into making the robot do or act the way that it does, and in particular such that it would require some substantial personal investment (monetary, timewise, workwise, or simply having to wait a while) to replace it.
I get that they might be sad when a robot they were using somehow gets lost or destroyed, ...
The soldier gets sad when the robot is destroyed because next time the solder has to go downrange instead of the robot.
... but I really can't see that influencing how likely they are to use that robot for dangerous situations unless the soldier had somehow personally invested time and energy into making the robot do or act the way that it does, and in particular such that it would require some substantial personal investment (monetary, timewise, workwise, or simply having to wait a while) to replace it.
I think this is nothing new. Consider a sailor and his ship. Sailors invest a lot of time and effort working on their ship, maintaining it, improving it. Its their home. Its a place of safety in a very hostile environment (the sea). They often get to love their ship yet they risk it in battle. They do so because they love something else even more, getting home. Similarly the soldier will risk the robot so he gets home.
No, the app and app developer perspective has been my argument since my first post in the thread.
Wrong, you explicitly said Android is a Java environment ...
Wrong. My fist post: "No, its not. End users and nearly all **developers** don't see it. The Linux kernel could probably be swapped out with a BSD kernel and few would notice. Even for those using the NDK and writing some C code they are probably making POSIX calls not calls to anything Linux specific."
You use the word, "operate", you are discussing hosting Android. I am not.
What Linux specific call appears in the Android API? This is what I have been discussing.
You're presuming that $1Bln put into FreeBSD work is going to EVER be contributed back. That's NOT a foregone conclusion, perpenso.
Like Google's modifications to Linux that are not contributed back because they are only used internally, not shipped to others, and are considered a trade secret by Google?
You keep discussing things related to hosting and or porting Android itself. I am discussing writing apps that run on Android. These are two different things.
You changed your argument because you failed early on in the discussion regarding the portability of Android, now you've changed to talk about apps that run on Android
No, the app and app developer perspective has been my argument since my first post in the thread. You simply misunderstood, perhaps that was my fault initially. However at this point you have no excuse.
Android is made up of Java and native libraries, the Java libraries are portable, the native ones are not.
No. Android's JNI wrapped C libraries are not Linux specific, they are cross platform: libc, opengl, sqlite, webkit, etc.
Linux is a convenient host, nothing more.
The way I read the release is that IBM is going to hire people in France to support linux, while laying off people in the US doing AIX and Linux work.
There is also the gov't policy angle. The US gov't wants to tax foreign profits. So companies like Apple and IBM have a lot of money overseas that they don't know what to do with. Spending what they earn overseas in an overseas development effort avoids these additional taxes.
The US gov't basically seems to be encouraging IBM to shut down US development and move it overseas. Sure its an unintended consequence but many gov't failings stem from the unintended consequences of good intentioned policy.
As long as no one can just take their ball and go home BSD style ...
Wrong. With BSD you can go but you have to leave your ball, you are free to get a new ball and keep it to yourself though. Nothing already contributed can be taken away, you just stop contributing. The BSD community does not lose a single line of code.
As I said yesterday in comments regarding the article about Linus falling out of the top 100 code contributors list ...
Linux is primarily developed by corporations or government entities, directly or through subsidies, and not the more romantic hobbyist developer contributing his/her personal time.
You are fundamentally misunderstanding what I am saying. The Android APIs are portable by design, host agnostic by design. Android ***apps*** do not require Linux, even many NDK based ***apps*** do not require Linux since they just call libc or posix. Android ***app developers*** do not see Linux unless they make a special effort to do so by adding new JNI wrapped C libraries that extend Android.
You keep discussing things related to hosting and or porting Android itself. I am discussing writing apps that run on Android. These are two different things.
The iPhone 5C is not really a new phone. It seems to be an iPhone 5 that went through a cost reduction process.
Hence the existing iPhone 5 being discontinued rather than demoted to a lower price tier.
Not only does this help preserve Apple's profit margins at the midrange price tier but by making this phone "less attractive" to those who can afford an iPhone 5S Apple reduces cannibalization. If the original iPhone 5 were still available too many people may have opted for it over the 5S. This will happen to a lesser degree with the 5C.
What is being claimed is that the Android development environment is a java based environment where the underlying host OS is abstracted away and irrelevant to the java app.
Then show me it running on another host.
You are arguing a tangential point that no one is disagreeing with. Android is hosted on Linux. That does not change the fact that stock Android completely abstracts away the OS from the app's and the developer's perspectives. There are Android devices where you do not even have the option to use the NDK to add a JNI wrapped C library that can access Linux, for example Google TV.
a Java application that calls out to a native library is no longer just a Java application.
Untrue. Java itself is partially implemented with native libraries. These libraries, like the Android libraries, are wrapped appropriately and from the apps perspective a Java implemented class is indistinguishable from a C implemented class. Whether a class is implemented in Java or JNI wrapped C is irrelevant, its an implementation detail the app knows nothing about.
Some libc functions are implemented in assembly language. Calling those from your C or C++ app does not make these apps any less C or C++.
Its probably not a swipe. Just acknowledging that Linux is primarily developed via corporate/governmental subsidies and not the more romantic hobbyist developer contributing his/her personal time.
The support libraries are Android's extension of the Java environment.
Yes they are native Android libraries - that do not sit atop Java - that access the functionality of the underlying operating system.
And parts of Java are also implemented in native code. Its irrelevant. The host OS is abstracted away, the java app never sees it.
The android app sees Java classes not the underlying C implementation.
But the C implementation is executed natively, not within the Java environment, because it does not sit atop Java, it executes at the native level.
Again, that is irrelevant. The java app does not know or care. Its a hidden implementation detail.
Are you thinking that someone is claiming that Java is purely implemented in Java? No one is claiming that. What is being claimed is that the Android development environment is a java based environment where the underlying host OS is abstracted away and irrelevant to the java app. That Android is a java based environment, not a Linux based environment, that Linux is just a host OS that Android apps are unaware of. Most apps on the Google Play store are pure Java. For the minority that use the NDK to extend Android and access the host OS through a custom library, many of these are not even Linux based. They are generally accessing c runtime libraries and possibly posix functionality, rarely something Linux specific. Linux is just a host OS. Its not required by stock Android. Its not even required by most NDK based apps.
For example with respect to OpenGL: GLSurfaceView, android.opengl.GLES20. The environment is still Java language based and the underlying host OS still irrelevant.
Wrong, when I call native code from Java that code is not executed in the Java environment even if you think there is some magic that makes it do so.
No magic. Just you fundamentally misunderstanding what I am saying. As the author that is my fault not yours.
I originally referred to developing desktop/server/embedded apps. C developers working on these apps have access to the kernel headers and APIs. I do not think we are referring to the same thing with respect to desktop development.
Its a tangent anyway. The focus of my comment was Android, which is sort of its own operating system and environment where the underlying host OS is not available to the Java developers. If you want to discuss the NDK where an Android developer can extend the Android environment with a custom library implemented in C that has access to the kernel, well there is already a thread on that.
The support libraries are Android's extension of the Java environment. The android app sees Java classes not the underlying C implementation. For example with respect to OpenGL: GLSurfaceView, android.opengl.GLES20. The environment is still Java language based and the underlying host OS still irrelevant.
Linux is the kernel. Other stuff is other stuff.
The point is that in desktop/server/embedded Linux environment the developers sees the kernel API. Under Android they do not. Android is a Java environment not a *nix environment.
Bollocks, if I write a desktop app in Java (Eclipse for example...) all I see is Java API, but that doesn't mean Eclipse is not running on Linux.
The Java app is not running on Linux, it is running on a Java virtual machine. That is one of the benefits of Java, it isolates you from the host operating system so that your app is portable. What that Java virtual machine is running on is irrelevant to your app. Would you claim that a Windows app is Linux based because MS Windows is running on a virtual machine hosted on a Linux box?
I give up, you really are quite mad.
Perhaps you are failing to see that you are arguing that Android "runs on Linux" and I am arguing that Android "is a Java environment". These are two different things. No one is claiming that the Dalvik VM is not being hosted on Linux in Android, my claim is merely that whatever OS is currently hosting the Dalvik VM is irrelevant to the app and its developer. Much as a MS Windows app and its developer don't care if it is running on native hardware or a VM, and in the later case doen't care what OS is hosting the VM.
In other words. If you are virtualized the host OS is irrelevant.