That is true and it's something that's still somewhat crucial in the mobile/embedded sector, however therein lies a significant difference - in 1995, we didn't have the incredibly efficient ARM chips that we have now. Where power draw is crucial, we have a solution for that, too - low-power Chips. When you have serious number crunching to do, power draw and the environment probably isn't a major concern.
No programmer - and I mean not a single one - knows absolutely every API and programming trick they're ever going to use. What makes a good programmer good is being able to adapt and quickly learn what he needs to use (as well as when he needs to use it) - ok, there's plenty of things that define what a "good" programmer is, but that one is crucial.
That practice happens a lot less because it's needed a lot less. Hand editing ASM and knowing how the compiler works is brilliant for efficiency and optimising work, but it can easily hamper your ability to write clean and maintainable code - which these days is far more important than saving a few clock cycles. I dare say if you took a decent programmer from 1995 and put him into a development house from today, he'd struggle to keep up with some of even the more novice programmers simply because things are done differently these days.
I sincerely hope that you're being sarcastic, or at the very least, trolling. Back in 1995, there were plenty of "lazy", inexperienced and just downright poor programmers. However, aside from a few cases here and there, the objective was always the same then as it is now - get the job done in a reasonable time. In 1995, we had to invest a lot of time optimising and hand coding ASM to meet that objective due to the mentioned limitations in PC's. These days, hardware is so fast and plentiful, we can get on with doing other things and spend less time optimising. It doesn't matter how much memory the program is using or how many CPU cycles are being wasted when the job gets done in 2s versus 1.4s.
Sure, you might see it as wasteful or even lazy, but all you're really doing is substituting one form of inefficiency with another - the inefficiency of the program with the inefficiency of the programmer's time. Hardware is cheap, good programmers are not. If a company is spending £40,000 a year on a single programmer, they'll get far more value spending an extra £1000 on a faster Processor or more RAM than they will out of having him spend weeks hand-coding and debugging ASM ops for every application/routine he writes.
Yes, there will always be the exception and "throwing hardware at the problem" isn't the right solution, either, but saving time is saving money and that's why we have "inefficient" programs.
Alternatively, any time the program calls a dongle function, just inline the code from the dongle in its place. Such systems have been tried before and such systems have been cracked in various interesting ways.
I think Google can get away with the "open but not really open" approach simply because the rest of the Mobile ecosystem (Particularly when Android first appeared) was very, very closed. You basically had Blackberry OS (closed), Windows Mobile (closed), iOS (closed) and Symbian (more or less closed - less-so now, but it's still a bit long in the tooth). All Google had to do was open the door a little bit and they'd be 10x more open than the competition. In the end, Google reaps the benefits of both worlds - it's working well for them so far.
Interesting. Still, although it mentions that GAPPS and Market are licensed separately, it doesn't specifically say that GAPPS requires a fee. It does say that Market access is free, though. Interestingly, all the GAPPS are also available via the market, so where would the incentive be for Manufacturers to pay an additional charge just for the sake of having it "out of the box"?
I was always under the impression that GAPPS access (ok, Market access) was dependent on meeting certain requirements, rather than having to pay a certain fee. This is the first I've heard of that fee, however I'm not discounting that it's a possibility.
At what point did I say that the OS being open was a benefit to the users? If anything, I said it was a benefit to Google. Whatever perceived benefit the user has is merely a bonus. Even if another manufacturer uses AndroidOS and doesn't go for the full Google experience, Google will still benefit. People will still write apps for their OS, people will still use Google Search and just about everything revolves around the Google ecosystem. About the only people who have ever come close to supplanting Google entirely is Amazon, but even then elements of Google filter through.
And just because Google has no experience internally of building phones, that doesn't mean it couldn't be done. You don't have to buy out a company to do what it does, merely hire a few of the best and the brightest - or even buy out a smaller company, like HTC circa 2008/2009, to do it.
Google doesn't make money from Android OS itself, Google makes money from the sheer volume of Android devices out there. Be it app purchases, targeted ads, search or whatever, the revenue Android brings in comes from everything except the OS. It wouldn't make sense for Google to close source it.
Google is a massive company and if they wanted to make their own phones with their own closed OS, they'd have done it by now.
It's my understanding* that Lightsquared's equipment was never the issue, but rather the GPS equipment that got interference were just poorly designed. If the GPS equipment was held to the standards it should have been, Lightsquared's equipment wouldn't have interfered. Yet Lightsquared are the ones being shafted, simply because GPS is "too important". Really, the FCC and/or the GPS equipment manufacturer should be the ones being penalised. FCC beucase it's their job to look after this sort of thing and the manufacturers for producing shoddy equipment.
*However note that I may be wrong, being an imperfect being and all that.
This is actually news to me - thanks! That's how it should be, I do wonder though what the reasons are behind the move - are Microsoft just protecting their own backs for future Windows OS installs (wheras the ARM versions certainly won't be upgraded without new hardware).
The problem, which is what separates the ARM and x86/64 side of things, is that Microsoft allows the x86/64 vendors to do whatever they want as long as certain defaults are met, i.e. UEFI secure boot is enabled by default, but they don't say anything about disabling it or giving the user the option to. In that instance, you very much get a full working PC and if the OEM is nice enough, you'll be able to do whatever you like to the UEFI system - including disabling Secure Boot and inserting your own keys.
However, when it comes to ARM Microsoft is very specific in that they make sure manufacturers do not allow any way to disable Secure Boot. This presumably also includes the ability to insert your own keys and such. The reason this will stay enforced is because the OEM has absolutely no way of servicing their tablet other than via Microsoft's own Windows Update. Even driver updates come through here now, so if an OEM decides to give customers the key to the UEFI lock, Microsoft will disable all support options for that OEM. It's an entirely closed ecosystem with Microsoft completely in control.
Since Microsoft wrote it, themselves. Try reading TFA -
Once we had the tools, we could start porting the Windows boot environment and developing system firmware specifications. We even prototyped the firmware ourselves.
UEFI firmware is the lowest layer of a WOA system and provides consistent services for loading the OS. For WOA, we created firmware to bootstrap the system that we handed off to our partners. WOA systems also include a firmware-based TPM for trusted boot and storage encryption. Using the TPM, for example, we’ve implemented trusted boot which verifies that the system hasn’t been tampered with by malware.
Truth be told, I expected this to happen. And to be fair to Microsoft, it's not very different to what happens on most other ARM based machines - including Android. The difference is that the Android community, at least, has pushed many manufacturers to at least offer the option of unlocking the devices for tinkering. Microsoft's mandate means that this will never be an option. We may see some Android tablets converted to run Windows ARM, but it'll skirt around too many grey areas of the law to be encouraged. What a damn shame that is, too.
Whenever the first tidbits of the UEFI secure boot cropped up that many people immediately cried foul over, I was one of the people who stood up and said "Not so fast, everyone - it's mandated that it be enabled by default, but there's nothing to say you can't customise it or disable it". Many people were quick to jump on MS, stating that it's just to stop Linux adoption and such and still I persisted in saying that MS wasn't the bad guy, if you didn't have an option to disable UEFI secure boot, it was the OEM or motherboard manufacturer at fault, not MS. I got into many heated debates about this point.
However, that was regarding Windows 8 x86/64.
Windows on ARM will demand that UEFI secure boot be enabled and that there is no way to disable it. Any Windows ARM tablets or PCs that come out will not be capable of running anything other than Windows - not Linux, not Android, nothing. Since Windows ARM won't be sold directly, it means there will be absolutely no way to buy a Windows ARM machine that runs other OS's - not even if you built one yourself.
It is with this that I retract any previous objections to people crying foul over the UEFI Secure boot malarkey. Even though Windows 8 x86/64 is still "fine", the issue of the ARM version is too great to ignore. So by all means, commence flaming.
I doubt they'll "call it off". Google dropping support doesn't mean no OS updates, it just means reduced developer support for flashing AOSP built ROMs and Kernels. Google will still keep the device up to date themselves.
You can still develop android apps on literally any Android phone out there that has adb support (which is 99% of them - in fact, I only say 99% of them because I can't be 100% sure they all support it), the point of the CDMA thing is that Google can't release enough of the source code (due to proprietary bits) that'll allow you to safely build and install your own Kernel or OS. So when the very latest AOSP code drops, yes the developer in a CDMA-only area is kind of screwed if he wants to test the latest APIs on an actual device, but there's not a lot Google can do about this - you've still got the emulators, you've still got the option of trying them on a device that simply won't get reception in that area, but there you go.
You can still build the OS and Kernel, but you might not get a device that works as well as it did before - that's why Google is dropping "support" for it, because it's simply not advisable.
Google isn't "Dropping" CDMA support. CDMA Android phones aren't going anywhere any time soon - they're just not supporting them as DEVELOPER devices. Due to issues with Custom ROMs not working as best they could (due to the proprietary components required), Google is basically saying that the CDMA Nexus phones are no better than any other non-nexus device when it comes to "official" developer support. They'll still exist, they'll still be sold, updated, etc. but they won't be classed as "Developer devices". That's it.
This isn't anything new, it was the same case with the Nexus S 4G and even the Xoom.
Slashdot Mirror
That is true and it's something that's still somewhat crucial in the mobile/embedded sector, however therein lies a significant difference - in 1995, we didn't have the incredibly efficient ARM chips that we have now. Where power draw is crucial, we have a solution for that, too - low-power Chips. When you have serious number crunching to do, power draw and the environment probably isn't a major concern.
No programmer - and I mean not a single one - knows absolutely every API and programming trick they're ever going to use. What makes a good programmer good is being able to adapt and quickly learn what he needs to use (as well as when he needs to use it) - ok, there's plenty of things that define what a "good" programmer is, but that one is crucial.
That practice happens a lot less because it's needed a lot less. Hand editing ASM and knowing how the compiler works is brilliant for efficiency and optimising work, but it can easily hamper your ability to write clean and maintainable code - which these days is far more important than saving a few clock cycles. I dare say if you took a decent programmer from 1995 and put him into a development house from today, he'd struggle to keep up with some of even the more novice programmers simply because things are done differently these days.
I sincerely hope that you're being sarcastic, or at the very least, trolling.
Back in 1995, there were plenty of "lazy", inexperienced and just downright poor programmers. However, aside from a few cases here and there, the objective was always the same then as it is now - get the job done in a reasonable time. In 1995, we had to invest a lot of time optimising and hand coding ASM to meet that objective due to the mentioned limitations in PC's. These days, hardware is so fast and plentiful, we can get on with doing other things and spend less time optimising. It doesn't matter how much memory the program is using or how many CPU cycles are being wasted when the job gets done in 2s versus 1.4s.
Sure, you might see it as wasteful or even lazy, but all you're really doing is substituting one form of inefficiency with another - the inefficiency of the program with the inefficiency of the programmer's time. Hardware is cheap, good programmers are not. If a company is spending £40,000 a year on a single programmer, they'll get far more value spending an extra £1000 on a faster Processor or more RAM than they will out of having him spend weeks hand-coding and debugging ASM ops for every application/routine he writes.
Yes, there will always be the exception and "throwing hardware at the problem" isn't the right solution, either, but saving time is saving money and that's why we have "inefficient" programs.
Why block GPS? What do criminals gain from it? Genuine Queston.
Alternatively, any time the program calls a dongle function, just inline the code from the dongle in its place. Such systems have been tried before and such systems have been cracked in various interesting ways.
if(!Cell->IsCancerous)
{
Cell->kill;
}
Even at the implied reduced growth rate, they're still the fastest growing Mobile OS out there.
I think Google can get away with the "open but not really open" approach simply because the rest of the Mobile ecosystem (Particularly when Android first appeared) was very, very closed. You basically had Blackberry OS (closed), Windows Mobile (closed), iOS (closed) and Symbian (more or less closed - less-so now, but it's still a bit long in the tooth). All Google had to do was open the door a little bit and they'd be 10x more open than the competition. In the end, Google reaps the benefits of both worlds - it's working well for them so far.
Interesting. Still, although it mentions that GAPPS and Market are licensed separately, it doesn't specifically say that GAPPS requires a fee. It does say that Market access is free, though. Interestingly, all the GAPPS are also available via the market, so where would the incentive be for Manufacturers to pay an additional charge just for the sake of having it "out of the box"?
Do you have a source for that?
I was always under the impression that GAPPS access (ok, Market access) was dependent on meeting certain requirements, rather than having to pay a certain fee. This is the first I've heard of that fee, however I'm not discounting that it's a possibility.
At what point did I say that the OS being open was a benefit to the users? If anything, I said it was a benefit to Google. Whatever perceived benefit the user has is merely a bonus. Even if another manufacturer uses AndroidOS and doesn't go for the full Google experience, Google will still benefit. People will still write apps for their OS, people will still use Google Search and just about everything revolves around the Google ecosystem. About the only people who have ever come close to supplanting Google entirely is Amazon, but even then elements of Google filter through.
And just because Google has no experience internally of building phones, that doesn't mean it couldn't be done. You don't have to buy out a company to do what it does, merely hire a few of the best and the brightest - or even buy out a smaller company, like HTC circa 2008/2009, to do it.
Google doesn't make money from Android OS itself, Google makes money from the sheer volume of Android devices out there. Be it app purchases, targeted ads, search or whatever, the revenue Android brings in comes from everything except the OS. It wouldn't make sense for Google to close source it.
Google is a massive company and if they wanted to make their own phones with their own closed OS, they'd have done it by now.
Based on the additional comments, I stand very much corrected. Looks like this was a LS blunder after all.
It's my understanding* that Lightsquared's equipment was never the issue, but rather the GPS equipment that got interference were just poorly designed. If the GPS equipment was held to the standards it should have been, Lightsquared's equipment wouldn't have interfered. Yet Lightsquared are the ones being shafted, simply because GPS is "too important". Really, the FCC and/or the GPS equipment manufacturer should be the ones being penalised. FCC beucase it's their job to look after this sort of thing and the manufacturers for producing shoddy equipment.
*However note that I may be wrong, being an imperfect being and all that.
If you disagree with me, you must be a dick. Oh wait, that's probably true.
I'm sure you'll be able to pay an additional charge and have to wait in an additional line to pass your liquids through.
What, you think in the future the US still won't have adapted to a modern electronic card payment system, like EMV or even Contactless EMV?
This is actually news to me - thanks! That's how it should be, I do wonder though what the reasons are behind the move - are Microsoft just protecting their own backs for future Windows OS installs (wheras the ARM versions certainly won't be upgraded without new hardware).
The problem, which is what separates the ARM and x86/64 side of things, is that Microsoft allows the x86/64 vendors to do whatever they want as long as certain defaults are met, i.e. UEFI secure boot is enabled by default, but they don't say anything about disabling it or giving the user the option to. In that instance, you very much get a full working PC and if the OEM is nice enough, you'll be able to do whatever you like to the UEFI system - including disabling Secure Boot and inserting your own keys.
However, when it comes to ARM Microsoft is very specific in that they make sure manufacturers do not allow any way to disable Secure Boot. This presumably also includes the ability to insert your own keys and such. The reason this will stay enforced is because the OEM has absolutely no way of servicing their tablet other than via Microsoft's own Windows Update. Even driver updates come through here now, so if an OEM decides to give customers the key to the UEFI lock, Microsoft will disable all support options for that OEM. It's an entirely closed ecosystem with Microsoft completely in control.
Since Microsoft wrote it, themselves. Try reading TFA -
Truth be told, I expected this to happen. And to be fair to Microsoft, it's not very different to what happens on most other ARM based machines - including Android. The difference is that the Android community, at least, has pushed many manufacturers to at least offer the option of unlocking the devices for tinkering. Microsoft's mandate means that this will never be an option. We may see some Android tablets converted to run Windows ARM, but it'll skirt around too many grey areas of the law to be encouraged. What a damn shame that is, too.
Whenever the first tidbits of the UEFI secure boot cropped up that many people immediately cried foul over, I was one of the people who stood up and said "Not so fast, everyone - it's mandated that it be enabled by default, but there's nothing to say you can't customise it or disable it". Many people were quick to jump on MS, stating that it's just to stop Linux adoption and such and still I persisted in saying that MS wasn't the bad guy, if you didn't have an option to disable UEFI secure boot, it was the OEM or motherboard manufacturer at fault, not MS. I got into many heated debates about this point.
However, that was regarding Windows 8 x86/64.
Windows on ARM will demand that UEFI secure boot be enabled and that there is no way to disable it. Any Windows ARM tablets or PCs that come out will not be capable of running anything other than Windows - not Linux, not Android, nothing. Since Windows ARM won't be sold directly, it means there will be absolutely no way to buy a Windows ARM machine that runs other OS's - not even if you built one yourself.
It is with this that I retract any previous objections to people crying foul over the UEFI Secure boot malarkey. Even though Windows 8 x86/64 is still "fine", the issue of the ARM version is too great to ignore. So by all means, commence flaming.
I doubt they'll "call it off". Google dropping support doesn't mean no OS updates, it just means reduced developer support for flashing AOSP built ROMs and Kernels. Google will still keep the device up to date themselves.
You can still develop android apps on literally any Android phone out there that has adb support (which is 99% of them - in fact, I only say 99% of them because I can't be 100% sure they all support it), the point of the CDMA thing is that Google can't release enough of the source code (due to proprietary bits) that'll allow you to safely build and install your own Kernel or OS. So when the very latest AOSP code drops, yes the developer in a CDMA-only area is kind of screwed if he wants to test the latest APIs on an actual device, but there's not a lot Google can do about this - you've still got the emulators, you've still got the option of trying them on a device that simply won't get reception in that area, but there you go.
You can still build the OS and Kernel, but you might not get a device that works as well as it did before - that's why Google is dropping "support" for it, because it's simply not advisable.
Google isn't "Dropping" CDMA support. CDMA Android phones aren't going anywhere any time soon - they're just not supporting them as DEVELOPER devices. Due to issues with Custom ROMs not working as best they could (due to the proprietary components required), Google is basically saying that the CDMA Nexus phones are no better than any other non-nexus device when it comes to "official" developer support. They'll still exist, they'll still be sold, updated, etc. but they won't be classed as "Developer devices". That's it.
This isn't anything new, it was the same case with the Nexus S 4G and even the Xoom.