Fair enough, yes percentages do have meaning on their own, what I should have said is that they don't have significant meaning on their own to draw the conclusions that you were, for that you need to also at least take into account market growth/shrinkage and market segmentation (since the devices in the market category can run multiple operating systems and some can run operating systems that others can't or - in a practical sense - don't), of course there are other niche factors (that could potentially have an impact) that you mention as well.
Yes, look at the posts in this thread, the suggestion that you should buy a card from either manufacturer is met with 'Company XYZ's cards have all these driver problems' and 'All my Company XYZ cards have failed buy my Company ZYX cards are fine' with links to forum posts and anecdotal evidence eachway all over the place. I certainly wouldn't blame a gamer (not a gearhead) for avoiding PC gaming, asking what video card you should buy just creates a massive flamewar.
OTOH, the only video card hardware failure I've had was also Nvidia.
With video card failures, be they AMD/ATi or nVidia, you have to realize that the only part those companies make is the actual GPU, they don't make the actual card so the cooling system, caps, RAM and all the other components are made by others and assembled by an OEM so there are many points of failure that are completely unrelated to AMD/ATi and nVidia.
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 which is clearly not the case because it requires platform specific libraries in order to operate, Android includes Java APIs but where those APIs call native code the implementation is only on Linux. So for the god-only-knows-how-many-th time stop your idiocy and weasel words and actually prove it.
No. Android's JNI wrapped C libraries are not Linux specific, they are cross platform: libc, opengl, sqlite, webkit, etc.
You only listed the cross-platform ones either because you are ignorant or because you're trying to be deliberately deceptive, go try and build surfaceflinger or bionic on a platform other than Linux...go on...prove it, oh right you can't.
Linux is a convenient host, nothing more.
Then prove it, you obviously don't understand Android enough to know that this isn't possible so the only way to convince you is for you to actually try to prove that you are right but you fail time and time again to even try.
Desktop Windows declined by 3% over the last 12 months
3% of what?
The total percentage of XP + Win8 only declined by 0.3% over the same period, so most XP users seem to be migrating to Win8
That might be valid if the thing that it is a percentage of was static over that time period but i'm guessing its size increased too with different categories of devices as well.
Total Windows + iOS only declined by 1.4% (1.7% if you include MacOSX) so currently the leakage of users to Linux-based systems (including Android) is rather insignificant on a yearly basis, but does seem significant on longer time scales like decades or generations.
Again how can you determine that the increase in one area came purely from an increase in another? If I buy an Android tablet in addition to my existing devices Android's usage numbers increase as does its marketshare percentage, the other devices' marketshare percentage will decrease but their usage numbers won't. Percentages mean nothing on their own particularly when the market consists of different categories of devices running different operating systems.
The Android APIs are portable by design, host agnostic by design.
That doesn't matter, the implementation of the non-Java functionality is platform-specific, you can wrap native code in a portable interface but that doesn't make the code portable, which is why you cannot prove your false assertion because it is tied to Linux.
Android ***apps*** do not require Linux
Apps aren't the issue, we're talking about Android and it isn't implemented on any other operating system which is why Android is tied to Linux and thus so are the applications. Until somebody ports Android to another operating system Android - and its applications - will be Linux only.
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.
Android is made up of Java and native libraries, the Java libraries are portable, the native ones are not.
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, which even then aren't necessarily platform agnostic so you fail even at this.
So again, just prove it, prove that it doesn't rely on Linux by either your original argument about the host being irrelevant for Android or your new argument about the host being irrelevant for Android applications. All your weasel words won't help you so just provide some proof.
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.
No I'm saying if the host OS is irrelevant then show me it running on a non-Linux host.
a Java application that calls out to a native library is no longer just a Java application.
Untrue.
Then you show me how to run a Java application that calls out to non-VM native code without having that native code.
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.
And since Android requires these native libraries that are not implemented in Java it is not platform agnostic and is not built solely on top of Java. It's very simple to understand, go and actually try to run it on another host.
Whether a class is implemented in Java or JNI wrapped C is irrelevant
Again, bullshit. If it's Java it will run on top of Java and only the Java VM is required to be implemented, if it is native C then it requires a platform-specific binary that is not portable across operating systems hence the host os is not irrelevant. But I've explained this and it seems the only way for you to understand is for you to try to run it on another host OS so you discover this yourself but you still won't do 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.
Then show me it running on another host.
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.
Then show me it running on another host, you'll quickly discover how wrong you are.
Its not required by stock Android. Its not even required by most NDK based apps.
Again, prove it, stop arguing with your weasel words and actually show me some factual proof.
No magic. Just you fundamentally misunderstanding what I am saying. As the author that is my fault not yours.
If i write a C++ application that calls a.Net assembly the application is no longer just a C++ application, it really isn't that hard to understand, just as a Java application that calls out to a native library is no longer just a Java application.
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.
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.
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.
For all practical purposes Java is its own operating system and environment. Its virtual machine (VM) can merely be hosted on Linux or various other platforms, Java apps don't know or care what is hosting the VM.
Except in the cases where the functionality is not provided by the VM but by native Android support libraries.
Android is built upon Java
Whilst much of Android is built on Java you even pointed out that "Android also comes with a set of support libraries implemented in C" and these libraries, while accessible by Dalvik applications through the JNI are not restricted only to Dalvik applications through the JNI and if you were to run Dalvik on another non-Linux host operating system you would be missing these native support libraries that are a part of Android and applications would not run. But it's more than that, Android includes its own window manager, it's own libc (Bionic), it's own Java VM (Dalvik), it's own native libraries and is not limited to just the bit that built on top of Java.
Android also comes with a set of support libraries implemented in C and wrapped with the Java Native Interface (JNI) letting an Android app call these libraries.
Yes and these are a part of Android and are not built upon Java even though they can be accessed by Java code through the JNI.
This does not somehow turn Android into a Linux distribution.
How exactly is it that you believe an installation of Android differs from say an installation of Ubuntu in terms of being a "linux distribution"? And what distribution of linux is Android?
Android is a Java environment not a Linux environment. Nearly all apps are pure byte code executing on a VM, they never see the Linux kernel.
Android is a Linux distribution just like any other Linux distribution which can include different userland, desktop environment and application toolkits (which can be - but are not limited to - Java), applications can - but do not have to - use these provided toolkits and may or may not directly interact with the kernel.
Unlike desktop Linux UI's where the apps may interact with the kernel.
You just said If you think this is a UI argument you are mistaken and then compared applications running on Android to applications running on desktop Linux UI's. Are you quite sure you understand what you're trying to say? Because you are directly contradicting yourself, or perhaps just confusing terms.
I was talking about the rationale to create the GPL, that implies when it was first created and not the state that exists today.
I understand, my point was that the reason users don't really care about open source is because most users aren't programmers and to a non-programmer user it really makes no difference, sure they could pay somebody to add features for them but the reality is that most of the time it's only businesses that do that. Open source needs to provide a tangible benefit to non-programmer users for them to care about it.
It means that users are informed and encouraged to learn about the technology they use and hack and adjust it to their like, rather than being forced to use a weird blackbox with paid upgrades every few months.
That's a disingenuous comparison, in fact I can't think of any software at all for which I've done paid upgrades 'every few months' so what specifically are you referring to?
Even with open source applications like GIMP I would still rather use my copy of Photoshop CS2 than go to all the work to make GIMP a viable replacement. On the other hand Blender actually is in some real cases a viable replacements for its closed-source competitors. To win over users free software has to be better, not just cheaper and you have to remember that software is just a tool to get a job done and most users would rather replace a tool that doesn't work right than learn how to modify it and then do the work to make it work differently.
X ran just fine in under 32MB back in the day, though I haven't had such a machine in a while.
So you believe between 1998 - when PCs with 32MB were common - and 2008 - when the first Android phone came out - there were no significant changes to X that could have impacted performance?
Well, it's probably because of something like this which makes it look like Red Hat possibly trying to influence a partner to put a competitor at a disadvantage:
It seems more like Intel don't want to maintain Mir and would rather just maintain Wayland, which makes sense from their perspective, you can't expect them to maintain support for every display server and the fact that their drivers are open source means the display server author can maintain their own patches for the driver putting the onus on them instead.
I still don't understand how they intend it to work with AMD and nVidia, are those companies offering to maintain Mir support in their drivers?
No, you clearly don't understand the concept of argumentum ad absurdum. Comparing the ability to have widgets to pre-loaded spyware bloat means you're either a complete moron or being intentionally stupid.
It could be that he's limiting his view to North America to try and get statistics that support his argument...which, FWIW, they do if he wanted to be intentionally disingenuous.
The classic mistake that premium is the same thing as the biggest numbers on tech specs.
Well they certainly were throwing around the CPU and GPU performance improvement particularly 64bit. But it's true that the important thing isn't specs, it's about what features it provides the user, in this case a better camera and fingerprint unlock...which seems a bit light on and I suppose you do need to consider they are really appealing to 4S (rather than 5) users to upgrade but there's nothing particularly 'must have' and hasn't been for a while - not saying their competitors necessarily have either - it seems like progress is starting to stagnate a bit.
Apple's 5C is an aggressive move into Android's market, not a defensive move.
It's strategically no different to what they've always done: take the previous model and sell it at a lower price. The only change is that this time they've re-packaged it in plastic.
What I'm interested to know is why are they making such a big song and dance about intel not carrying their patches? They can carry their own out of tree patches (just like anybody who wants their own modifications to the driver) and the fact that intel has released their driver as open source is what allows them to do this at all. So the question is how are they adding this support for nVidia or the closed-source AMD drivers?
All the ad money and snarky campaigns didn't move them much over 10% market share.
What I find funny is that all the snarky remarks around Windows Vista copying OSX seem to have dropped off now that it's going the other way. The way the icons fall onto the home screen is very much like the way the tiles fall on to the start screen in Windows 8, the multi-coloured plastic designs are reminiscent of the flagship Lumia WP products and the wallpaper adapting to the phone's physical color is just like what the Surface does with its touch covers. All of these companies copy eachother so its pretty funny when the company that makes the biggest deal when it's done to them decides to go and do it themselves.
Slashdot Mirror
Fair enough, yes percentages do have meaning on their own, what I should have said is that they don't have significant meaning on their own to draw the conclusions that you were, for that you need to also at least take into account market growth/shrinkage and market segmentation (since the devices in the market category can run multiple operating systems and some can run operating systems that others can't or - in a practical sense - don't), of course there are other niche factors (that could potentially have an impact) that you mention as well.
Driver nightmares?
Yes, look at the posts in this thread, the suggestion that you should buy a card from either manufacturer is met with 'Company XYZ's cards have all these driver problems' and 'All my Company XYZ cards have failed buy my Company ZYX cards are fine' with links to forum posts and anecdotal evidence eachway all over the place. I certainly wouldn't blame a gamer (not a gearhead) for avoiding PC gaming, asking what video card you should buy just creates a massive flamewar.
The Geforce 6 is nearly 10 years old, that hardly qualifies for 'these days'.
OTOH, the only video card hardware failure I've had was also Nvidia.
With video card failures, be they AMD/ATi or nVidia, you have to realize that the only part those companies make is the actual GPU, they don't make the actual card so the cooling system, caps, RAM and all the other components are made by others and assembled by an OEM so there are many points of failure that are completely unrelated to AMD/ATi and nVidia.
It's not that it's getting worse it's that it's getting more complex.
How does that help us with the problems with AMD cards?
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 which is clearly not the case because it requires platform specific libraries in order to operate, Android includes Java APIs but where those APIs call native code the implementation is only on Linux. So for the god-only-knows-how-many-th time stop your idiocy and weasel words and actually prove it.
No. Android's JNI wrapped C libraries are not Linux specific, they are cross platform: libc, opengl, sqlite, webkit, etc.
You only listed the cross-platform ones either because you are ignorant or because you're trying to be deliberately deceptive, go try and build surfaceflinger or bionic on a platform other than Linux...go on...prove it, oh right you can't.
Linux is a convenient host, nothing more.
Then prove it, you obviously don't understand Android enough to know that this isn't possible so the only way to convince you is for you to actually try to prove that you are right but you fail time and time again to even try.
Desktop Windows declined by 3% over the last 12 months
3% of what?
The total percentage of XP + Win8 only declined by 0.3% over the same period, so most XP users seem to be migrating to Win8
That might be valid if the thing that it is a percentage of was static over that time period but i'm guessing its size increased too with different categories of devices as well.
Total Windows + iOS only declined by 1.4% (1.7% if you include MacOSX) so currently the leakage of users to Linux-based systems (including Android) is rather insignificant on a yearly basis, but does seem significant on longer time scales like decades or generations.
Again how can you determine that the increase in one area came purely from an increase in another? If I buy an Android tablet in addition to my existing devices Android's usage numbers increase as does its marketshare percentage, the other devices' marketshare percentage will decrease but their usage numbers won't. Percentages mean nothing on their own particularly when the market consists of different categories of devices running different operating systems.
The Android APIs are portable by design, host agnostic by design.
That doesn't matter, the implementation of the non-Java functionality is platform-specific, you can wrap native code in a portable interface but that doesn't make the code portable, which is why you cannot prove your false assertion because it is tied to Linux.
Android ***apps*** do not require Linux
Apps aren't the issue, we're talking about Android and it isn't implemented on any other operating system which is why Android is tied to Linux and thus so are the applications. Until somebody ports Android to another operating system Android - and its applications - will be Linux only.
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.
Android is made up of Java and native libraries, the Java libraries are portable, the native ones are not.
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, which even then aren't necessarily platform agnostic so you fail even at this.
So again, just prove it, prove that it doesn't rely on Linux by either your original argument about the host being irrelevant for Android or your new argument about the host being irrelevant for Android applications. All your weasel words won't help you so just provide some proof.
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.
No I'm saying if the host OS is irrelevant then show me it running on a non-Linux host.
a Java application that calls out to a native library is no longer just a Java application.
Untrue.
Then you show me how to run a Java application that calls out to non-VM native code without having that native code.
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.
And since Android requires these native libraries that are not implemented in Java it is not platform agnostic and is not built solely on top of Java. It's very simple to understand, go and actually try to run it on another host.
Whether a class is implemented in Java or JNI wrapped C is irrelevant
Again, bullshit. If it's Java it will run on top of Java and only the Java VM is required to be implemented, if it is native C then it requires a platform-specific binary that is not portable across operating systems hence the host os is not irrelevant. But I've explained this and it seems the only way for you to understand is for you to try to run it on another host OS so you discover this yourself but you still won't do that.
You even said of Linux that Its not required by stock Android, so prove it, stop this nonsense and actually prove it.
The agumentum ad absurdum is just as relevant for physical features as software ones
Yes it is, and for some reason you can't make your argument without resorting to that logical fallacy.
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.
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.
Then show me it running on another host, you'll quickly discover how wrong you are.
Its not required by stock Android. Its not even required by most NDK based apps.
Again, prove it, stop arguing with your weasel words and actually show me some factual proof.
No magic. Just you fundamentally misunderstanding what I am saying. As the author that is my fault not yours.
If i write a C++ application that calls a .Net assembly the application is no longer just a C++ application, it really isn't that hard to understand, just as a Java application that calls out to a native library is no longer just a Java application.
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.
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.
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.
For all practical purposes Java is its own operating system and environment. Its virtual machine (VM) can merely be hosted on Linux or various other platforms, Java apps don't know or care what is hosting the VM.
Except in the cases where the functionality is not provided by the VM but by native Android support libraries.
Android is built upon Java
Whilst much of Android is built on Java you even pointed out that "Android also comes with a set of support libraries implemented in C" and these libraries, while accessible by Dalvik applications through the JNI are not restricted only to Dalvik applications through the JNI and if you were to run Dalvik on another non-Linux host operating system you would be missing these native support libraries that are a part of Android and applications would not run. But it's more than that, Android includes its own window manager, it's own libc (Bionic), it's own Java VM (Dalvik), it's own native libraries and is not limited to just the bit that built on top of Java.
Android also comes with a set of support libraries implemented in C and wrapped with the Java Native Interface (JNI) letting an Android app call these libraries.
Yes and these are a part of Android and are not built upon Java even though they can be accessed by Java code through the JNI.
This does not somehow turn Android into a Linux distribution.
How exactly is it that you believe an installation of Android differs from say an installation of Ubuntu in terms of being a "linux distribution"? And what distribution of linux is Android?
Android is a Java environment not a Linux environment. Nearly all apps are pure byte code executing on a VM, they never see the Linux kernel.
Android is a Linux distribution just like any other Linux distribution which can include different userland, desktop environment and application toolkits (which can be - but are not limited to - Java), applications can - but do not have to - use these provided toolkits and may or may not directly interact with the kernel.
Unlike desktop Linux UI's where the apps may interact with the kernel.
You just said If you think this is a UI argument you are mistaken and then compared applications running on Android to applications running on desktop Linux UI's. Are you quite sure you understand what you're trying to say? Because you are directly contradicting yourself, or perhaps just confusing terms.
I was talking about the rationale to create the GPL, that implies when it was first created and not the state that exists today.
I understand, my point was that the reason users don't really care about open source is because most users aren't programmers and to a non-programmer user it really makes no difference, sure they could pay somebody to add features for them but the reality is that most of the time it's only businesses that do that. Open source needs to provide a tangible benefit to non-programmer users for them to care about it.
The whole rational behind the GPL is to preserve the right of the user to modify the code, thus the user is also a programmer.
But in the incredibly vast majority of cases the user is not - and doesn't want to be - a programmer.
It means that users are informed and encouraged to learn about the technology they use and hack and adjust it to their like, rather than being forced to use a weird blackbox with paid upgrades every few months.
That's a disingenuous comparison, in fact I can't think of any software at all for which I've done paid upgrades 'every few months' so what specifically are you referring to?
Even with open source applications like GIMP I would still rather use my copy of Photoshop CS2 than go to all the work to make GIMP a viable replacement. On the other hand Blender actually is in some real cases a viable replacements for its closed-source competitors. To win over users free software has to be better, not just cheaper and you have to remember that software is just a tool to get a job done and most users would rather replace a tool that doesn't work right than learn how to modify it and then do the work to make it work differently.
X ran just fine in under 32MB back in the day, though I haven't had such a machine in a while.
So you believe between 1998 - when PCs with 32MB were common - and 2008 - when the first Android phone came out - there were no significant changes to X that could have impacted performance?
Well, it's probably because of something like this which makes it look like Red Hat possibly trying to influence a partner to put a competitor at a disadvantage:
http://www.muktware.com/5872/intel-red-hat-working-enabling-wayland-support-gnome
It seems more like Intel don't want to maintain Mir and would rather just maintain Wayland, which makes sense from their perspective, you can't expect them to maintain support for every display server and the fact that their drivers are open source means the display server author can maintain their own patches for the driver putting the onus on them instead.
I still don't understand how they intend it to work with AMD and nVidia, are those companies offering to maintain Mir support in their drivers?
No, you clearly don't understand the concept of argumentum ad absurdum. Comparing the ability to have widgets to pre-loaded spyware bloat means you're either a complete moron or being intentionally stupid.
It could be that he's limiting his view to North America to try and get statistics that support his argument...which, FWIW, they do if he wanted to be intentionally disingenuous.
The classic mistake that premium is the same thing as the biggest numbers on tech specs.
Well they certainly were throwing around the CPU and GPU performance improvement particularly 64bit. But it's true that the important thing isn't specs, it's about what features it provides the user, in this case a better camera and fingerprint unlock...which seems a bit light on and I suppose you do need to consider they are really appealing to 4S (rather than 5) users to upgrade but there's nothing particularly 'must have' and hasn't been for a while - not saying their competitors necessarily have either - it seems like progress is starting to stagnate a bit.
Apple's 5C is an aggressive move into Android's market, not a defensive move.
It's strategically no different to what they've always done: take the previous model and sell it at a lower price. The only change is that this time they've re-packaged it in plastic.
What I'm interested to know is why are they making such a big song and dance about intel not carrying their patches? They can carry their own out of tree patches (just like anybody who wants their own modifications to the driver) and the fact that intel has released their driver as open source is what allows them to do this at all. So the question is how are they adding this support for nVidia or the closed-source AMD drivers?
All the ad money and snarky campaigns didn't move them much over 10% market share.
What I find funny is that all the snarky remarks around Windows Vista copying OSX seem to have dropped off now that it's going the other way. The way the icons fall onto the home screen is very much like the way the tiles fall on to the start screen in Windows 8, the multi-coloured plastic designs are reminiscent of the flagship Lumia WP products and the wallpaper adapting to the phone's physical color is just like what the Surface does with its touch covers. All of these companies copy eachother so its pretty funny when the company that makes the biggest deal when it's done to them decides to go and do it themselves.