If you don't support both 32bit and 64bit versions of a couple of Windows releases that's fine, but if you do you need to test on them. If you are doing any kind of graphics or GPGPU you do need to test on various kinds of GPUs because they have different capabilities, performance and implementations.
You seem to be taking this Android situation far too personally but it is the same on iOS when you are developing to support various handsets, it's just that there is less variation. For simple applications it doesn't matter, but for more complex ones it does. Maybe you develop applications that are only targeted at a broadly supported set of APIs with predictable performance and support, not everybody does that.
In Windows case you are supposing all applications use 3D graphics, 64 bits libraries and processor specific optimizations, which is false for more than 90% of them.
No I'm not, which is why I said 'to a degree' it is correct. I said nothing about 64bit libraries, so I don't know where you're getting that from. Where do you get your '90%' of them from? And no, you don't need processor-specific optimizations to see differences between processors. Obviously if you're writing hello world then you are probably safe testing on one old Android device and assuming it will run on everything. It isn't in all cases, but if you're writing anything significantly complex then it is.
In Android's case you are supposing applications need to give a damn about Android versions or specific hardware capabilities. Although that is true for some of them, the vast majority needs to bother very little with those details.
No I'm supposing those things have a significant impact on the performance and user experience, which they do.
You realize what you are saying is equivalent to saying a new windows app needs to be test on every version of windows, and on every machine combination, right?
Which to a degree is correct. You do have to test on all the different versions of the OS you plan to support (including 32 and 64bit) and the processors (which thankfully is Intel and AMD and they have good backwards compatibility), then if you are doing graphics or GPGPU intensive applications you have different GPUs (at a high level this means Intel, nVidia and AMD) of course you probably support baseline architectures across the 3 major vendors.
On the Android side you have the different major versions but you also have the different carrier customized-versions and the major custom distros (probably only one, cyanogenmod), you have more CPU types to test against since there are various customized ARM chips in use with different configurations, some of them have more cores with lower clocks or less cores with higher clocks, there's also big.LITTLE configurations too. You have all the different GPUs in use as well which come from a variety of vendors with different approaches wrt clockspeed, core numbers and VRAM.
I don't think one is better than the other in general, it really depends on what specific products you are working with and what the open source alternatives are. The closed source vendor may not support you and may not extensively document the software but by the same token the open source community may not support you and may not extensively document the software. Sure you in the latter case you can always look at the code but if it's anything of significant complexity that's going to take a fair chunk of time and that's assuming it's actually well-written and architected, which is far from a safe assumption to make.
These are all factors to take into account when choosing products.
What's would be the point of that? We can already do that with web applications if we want cross-platform support. Then for places where native code is more suitable we can develop native apps. Removing the ability to do native code and limiting it to only web applications is just restrictive silliness.
How is that in any way related to the discussion at hand? The point is the metro interface isn't designed for application development, in fact even much of microsoft's content creation suites - or anybody elses for that matter - arent suited to it, it's designed to be a content viewing interface, much like iOS is. Your suggestion that visual studio needs to be available on it demonstrates that you completely miss the point of it, much like XCode doesn't need to be available on iPads.
I find it a little odd that you're so hung up on the idea of updates, though, given that console games (even fairly complicated ones) did without them for decades, and still largely do.
I find it a little odd that you seem so ignorant of the fact that hardware and software has gotten significantly more complex and that on PCs there are millions of different configurations with varying drivers, operating system versions, operating system update levels, speeds of CPU, GPU, bus speeds, RAM amount, RAM speed, video memory amount, video memory speed, cache size, attached peripherals, etc... all of which can contribute to necessity for patches and mandatory driver updates where you just cannot know this in advance to ship with it all.
The Steam client can patch itself in about twenty seconds under Windows. That's not really much of a barrier.
Ignoring the fact that game-specific driver fixes are common and that people have different internet connections and that updates are different sizes.
The rest I think we've already talked about—just fucking test your games before shipping them, like console titles (used to) do.
Yeah because it's that easy, clearly you have no experience whatsoever. With a console you have one system configuration and you can apply a system update if necessary (and you only have to do it once), with PCs you have millions of different configurations and all sorts of different drivers for different components with different levels of system updates.
All that requires a significant investment for a shitty experience. You end up with one flash drive having updates and you then have to insert that one first to load the OS and updates into memory then swap it out for the actual game you want to play which then may or may not push the updates back to that flash drive otherwise you need to download them all again so it just ends up being a messy fuckaround for what is ultimately a shitty solution, nobody wants that so why invest any time in it.
It does not have to be exclusive... Just exclusive today. For example, a Valve Steam Box title. That means Linux... And have the Windows and MAC versions lag just a bit for marketing reasons.
Somebody has to bankroll that delay, no studio is going to forego a huge amount of their audience for the sake of trying to push a platform to succeed which has no benefit to them. Perhaps Valve could do it for HL3 but there is just as much chance it will backfire on them with HL fans and gamers just being pissed off that Valve is pushing their own agenda, making them install another operating system and reboot each time just to play it and that is assuming that SteamOS is actually any good.
Key word: behaves. Once you booted it up from the live CD and everything was in a RAM disk, you'd be able to swap to another game disc if you wanted, and all of Steam OS's features would stay resident.
Assuming it was the same version with the same features? What happens if you put in a newer game with a different version (or different contained driver version?) also how would this handle game and system patches? Having to download the patches everytime you play the game would be pretty damn irritating. This idea is a step in the complete wrong direction.
Let me know when Visual Studio is released as a Windows Store Application. Once the developers of developer tools have to eat their own proverbial dog food, then we'll know the environment formerly known as Metro has truly arrived.
It isn't designed for that, just like iOS isn't designed to run XCode and Android isn't designed to run Eclipse.
The first iPhone also wasn't competing against three other smartphone platforms.
Sure it was, Symbian, Windows Mobile, PalmOS and Blackberry (at least they were the major ones). iOS was a disruptive product and that's why it has succeeded, FFOS (and Ubuntu Phone, Windows Phone, Maemo, Meego, webOS, etc...) is not, it's only distinguishing feature is its supposed performance on lowend hardware.
Desktop linux distros made a similar play for the PC market and failed due to not being disruptive products and they even had more in their favor than just higher performance on lowend hardware, they were open and free (of cost), FFOS is as well but it is competing with the established Android which is also open and free (of cost), the closed parts of Android (device drivers and such) are all things FFOS shares with Android anyway.
That in itself doesn't disprove GP's post, however I have certainly seen the assertion a few times that FFOS outperforms Android on lowend devices yet not really seen any proof to back that up, and certainly not anything to prove that it outperforms it in any significant measurable way. Android seems to perform adequately on lowend devices - as your anecdote suggests - so unless FFOS is significantly faster and more efficient it isn't worth throwing away support for the entire Android app catalog.
Well, Firefox OS is the only one only using Web technologies.
How can you possibly pretend that limiting the application development to those specific technologies is a good thing?
With the other two, you might have been using one of the other options for any number of reasons, like for instance that C++ was faster, or your boss thought that JavaScript was a toy language, or that the API you actually needed for the app was missing in the web app version, and then that cut you out of reuse.
Like you said, you might have been using other options for any number of reasons and the ability to do that and not be restricted to a niche set of technologies is a good thing.
One advantage of a Nexus phone is that you are certain to get all the Android software updates, and get them in a timely manner.
Well that's debatable, the Nexus S for example was released at the late2010/early2011 and at the end of 2012 they announced it would not be getting the 4.2 update, it went out of support pretty quickly.
When the Nexus 4 came out, Google stopped doing carrier versions of the Nexus because that lack of software updates was damaging the brand.
I'm not going to suggest GP's explanation is ideal but when you are dealing with explaining the extremely confusing "Android programs are written in Java but Java programs don't run on Android" issue to people, being overly pedantic is probably for the best.
Slashdot Mirror
If you don't support both 32bit and 64bit versions of a couple of Windows releases that's fine, but if you do you need to test on them. If you are doing any kind of graphics or GPGPU you do need to test on various kinds of GPUs because they have different capabilities, performance and implementations.
You seem to be taking this Android situation far too personally but it is the same on iOS when you are developing to support various handsets, it's just that there is less variation. For simple applications it doesn't matter, but for more complex ones it does. Maybe you develop applications that are only targeted at a broadly supported set of APIs with predictable performance and support, not everybody does that.
In Windows case you are supposing all applications use 3D graphics, 64 bits libraries and processor specific optimizations, which is false for more than 90% of them.
No I'm not, which is why I said 'to a degree' it is correct. I said nothing about 64bit libraries, so I don't know where you're getting that from. Where do you get your '90%' of them from? And no, you don't need processor-specific optimizations to see differences between processors. Obviously if you're writing hello world then you are probably safe testing on one old Android device and assuming it will run on everything. It isn't in all cases, but if you're writing anything significantly complex then it is.
In Android's case you are supposing applications need to give a damn about Android versions or specific hardware capabilities. Although that is true for some of them, the vast majority needs to bother very little with those details.
No I'm supposing those things have a significant impact on the performance and user experience, which they do.
You realize what you are saying is equivalent to saying a new windows app needs to be test on every version of windows, and on every machine combination, right?
Which to a degree is correct. You do have to test on all the different versions of the OS you plan to support (including 32 and 64bit) and the processors (which thankfully is Intel and AMD and they have good backwards compatibility), then if you are doing graphics or GPGPU intensive applications you have different GPUs (at a high level this means Intel, nVidia and AMD) of course you probably support baseline architectures across the 3 major vendors.
On the Android side you have the different major versions but you also have the different carrier customized-versions and the major custom distros (probably only one, cyanogenmod), you have more CPU types to test against since there are various customized ARM chips in use with different configurations, some of them have more cores with lower clocks or less cores with higher clocks, there's also big.LITTLE configurations too. You have all the different GPUs in use as well which come from a variety of vendors with different approaches wrt clockspeed, core numbers and VRAM.
I don't think one is better than the other in general, it really depends on what specific products you are working with and what the open source alternatives are. The closed source vendor may not support you and may not extensively document the software but by the same token the open source community may not support you and may not extensively document the software. Sure you in the latter case you can always look at the code but if it's anything of significant complexity that's going to take a fair chunk of time and that's assuming it's actually well-written and architected, which is far from a safe assumption to make.
These are all factors to take into account when choosing products.
They're modded '1', the default moderation when posting from a registered account, the same as yours. Is that such a hard concept to grasp?
What's would be the point of that? We can already do that with web applications if we want cross-platform support. Then for places where native code is more suitable we can develop native apps. Removing the ability to do native code and limiting it to only web applications is just restrictive silliness.
How is that in any way related to the discussion at hand? The point is the metro interface isn't designed for application development, in fact even much of microsoft's content creation suites - or anybody elses for that matter - arent suited to it, it's designed to be a content viewing interface, much like iOS is. Your suggestion that visual studio needs to be available on it demonstrates that you completely miss the point of it, much like XCode doesn't need to be available on iPads.
When you say for the 'mobile platform' you mean for FirefoxOS?
I find it a little odd that you're so hung up on the idea of updates, though, given that console games (even fairly complicated ones) did without them for decades, and still largely do.
I find it a little odd that you seem so ignorant of the fact that hardware and software has gotten significantly more complex and that on PCs there are millions of different configurations with varying drivers, operating system versions, operating system update levels, speeds of CPU, GPU, bus speeds, RAM amount, RAM speed, video memory amount, video memory speed, cache size, attached peripherals, etc... all of which can contribute to necessity for patches and mandatory driver updates where you just cannot know this in advance to ship with it all.
The Steam client can patch itself in about twenty seconds under Windows. That's not really much of a barrier.
Ignoring the fact that game-specific driver fixes are common and that people have different internet connections and that updates are different sizes.
The rest I think we've already talked about—just fucking test your games before shipping them, like console titles (used to) do.
Yeah because it's that easy, clearly you have no experience whatsoever. With a console you have one system configuration and you can apply a system update if necessary (and you only have to do it once), with PCs you have millions of different configurations and all sorts of different drivers for different components with different levels of system updates.
All that requires a significant investment for a shitty experience. You end up with one flash drive having updates and you then have to insert that one first to load the OS and updates into memory then swap it out for the actual game you want to play which then may or may not push the updates back to that flash drive otherwise you need to download them all again so it just ends up being a messy fuckaround for what is ultimately a shitty solution, nobody wants that so why invest any time in it.
What's that got to do with anything?
It does not have to be exclusive... Just exclusive today. For example, a Valve Steam Box title. That means Linux... And have the Windows and MAC versions lag just a bit for marketing reasons.
Somebody has to bankroll that delay, no studio is going to forego a huge amount of their audience for the sake of trying to push a platform to succeed which has no benefit to them. Perhaps Valve could do it for HL3 but there is just as much chance it will backfire on them with HL fans and gamers just being pissed off that Valve is pushing their own agenda, making them install another operating system and reboot each time just to play it and that is assuming that SteamOS is actually any good.
Key word: behaves. Once you booted it up from the live CD and everything was in a RAM disk, you'd be able to swap to another game disc if you wanted, and all of Steam OS's features would stay resident.
Assuming it was the same version with the same features? What happens if you put in a newer game with a different version (or different contained driver version?) also how would this handle game and system patches? Having to download the patches everytime you play the game would be pretty damn irritating. This idea is a step in the complete wrong direction.
So it will contain out-of-date drivers for every piece of hardware? Doesn't sound like much of a bonus.
Let me know when Visual Studio is released as a Windows Store Application. Once the developers of developer tools have to eat their own proverbial dog food, then we'll know the environment formerly known as Metro has truly arrived.
It isn't designed for that, just like iOS isn't designed to run XCode and Android isn't designed to run Eclipse.
The GPP specifically said "G5 PowerBook."
So now you need to ask yourself, "do you know what a G5 Powerbook is?" based on your responses I'm guessing you don't.
In the PC space, there are still only two real players in the field. I'll be excited when someone can challenge the ATI/AMD-nVidia duopoly.
Doesn't seem like there is even enough margin/market for it to be worth starting up a competing business in the discrete PC graphics market.
Because that is the only way to forge a standard.
What 'standard'?
The first iPhone also wasn't competing against three other smartphone platforms.
Sure it was, Symbian, Windows Mobile, PalmOS and Blackberry (at least they were the major ones). iOS was a disruptive product and that's why it has succeeded, FFOS (and Ubuntu Phone, Windows Phone, Maemo, Meego, webOS, etc...) is not, it's only distinguishing feature is its supposed performance on lowend hardware.
Desktop linux distros made a similar play for the PC market and failed due to not being disruptive products and they even had more in their favor than just higher performance on lowend hardware, they were open and free (of cost), FFOS is as well but it is competing with the established Android which is also open and free (of cost), the closed parts of Android (device drivers and such) are all things FFOS shares with Android anyway.
That in itself doesn't disprove GP's post, however I have certainly seen the assertion a few times that FFOS outperforms Android on lowend devices yet not really seen any proof to back that up, and certainly not anything to prove that it outperforms it in any significant measurable way. Android seems to perform adequately on lowend devices - as your anecdote suggests - so unless FFOS is significantly faster and more efficient it isn't worth throwing away support for the entire Android app catalog.
Well, Firefox OS is the only one only using Web technologies.
How can you possibly pretend that limiting the application development to those specific technologies is a good thing?
With the other two, you might have been using one of the other options for any number of reasons, like for instance that C++ was faster, or your boss thought that JavaScript was a toy language, or that the API you actually needed for the app was missing in the web app version, and then that cut you out of reuse.
Like you said, you might have been using other options for any number of reasons and the ability to do that and not be restricted to a niche set of technologies is a good thing.
One advantage of a Nexus phone is that you are certain to get all the Android software updates, and get them in a timely manner.
Well that's debatable, the Nexus S for example was released at the late2010/early2011 and at the end of 2012 they announced it would not be getting the 4.2 update, it went out of support pretty quickly.
When the Nexus 4 came out, Google stopped doing carrier versions of the Nexus because that lack of software updates was damaging the brand.
Well that's a good thing.
I'm not going to suggest GP's explanation is ideal but when you are dealing with explaining the extremely confusing "Android programs are written in Java but Java programs don't run on Android" issue to people, being overly pedantic is probably for the best.
I want a nexus phone that doesn't feel like a big-screen-tv in my pocket.
Why do you need the nexus branding so badly? What's wrong with any of the plethora of other Android devices available?