Even if Android wins, they still have to persuade carriers to keep Google as the default search provider. Gogole has no leverage over carriers because they give away the OS for free.
Your customers are the people who give you money. It's the advertisers, not app developers, who are Google's customers.
That's why Google can say that app stores aren't the future (some way to treat your "customers!") and why paid apps struggle to get any traction on the Google app marketplace.
Carriers don't default to Google's search on Android because it's Android. They do it because they think it's what their customers want, and/or Google pays them the most money. That can change overnight, and Android and Chrome (being open source) could not even lean against that wind, let alone stop it entirely.
It would be a big mistake for a company like this to produce any products. These companies exist only to license out IP they buy or otherwise "invent," and to sue non-licensees for patent infringement. If they were to produce a product, they would make themselves vulnerable to a countersuit.
Android is going to make Google billions in licensing
I'm not sure what there is to be licensed. The software is open source, so there's no licensing fees to be had there. I suppose they could license out the mark "Android," but that's a weak brand if I ever saw one.
I think Android is a big money sink for Google and they'll try to pawn off its development to the "community" within a few years. It may still help them in the long run by jump-starting the mobile web as an advertising space, but Google does not need to pay someone to make that happen.
Imagine you have a 5 GB movie file that you snapshot. If you then try to delete the file, you will not recover the space, because the snapshot holds onto the file. Effectively, the snapshot is consuming 5 GB.
"Unsung" asks whether ZFS is smart about how it removes snapshots as space is needed. This is a reasonable question with a trivial answer: no, because ZFS never removes snapshots, even if space is needed. It is the user's responsibility to remove snapshots.
There are several things in the system that will make it difficult to scale up to higher resolution displays. One example is Android's use of integer pixel coordinates, instead of abstract floating point coordinates. By tying Android to pixels, Google ensures that application elements will appear smaller (and so less usable) on higher res displays.
If the iPhone were as open as Palm, Symbian, or Windows Mobile, every major carrier would be shipping it.
I'm not sure I follow. Are you saying that the carriers rejected the iPhone because they thought its closed nature would make it unsuccessful in the market? Or maybe they were making a moral stand for consumer openness?
A more likely explanation is that the iPhone took control from the carriers and gave it to Apple. Consumers, empirically, ended up somewhat better off.
I mean, people have been unlocking the iPhone and using it on other carriers. The carriers didn't complain, Apple did.
Carriers complained bitterly about unlocking. It took a class action lawsuit and a visit to the Supreme Court to end AT&T's policies against unlocking. If they've been quiet about iPhone unlocking, it's only because they've lost that battle.
Apple has to make a good faith effort to prevent unlocking as part of their contract with AT&T. To Apple, an unlocked phone is another sale, and they have no reason to care if you do so.
If replacing the home screen or dialer requires you to install an application to crack the digital protection on the OS, how is that better than the iPhone?
Android apps are written in Java. The features you describe would require changes to the system software. The system software is mostly open source, but changing it would require users to reinstall the OS, and that's not likely to happen, especially if the OS is forked for different vendors.
It's trivial to lock down. The carriers and handset makers are free to modify Android however they please, with no requirement that they release their changes, and no requirement that the open source version of Android even work on their phones.
What makes people think that the mobile network operators, who have resisted this sort of openness in their handsets before, will embrace it now? Nothing in the Android license requires them to do so.
Apple had to struggle to find a single carrier willing to allow the iPhone. Google showed up with six. You don't get six times as many carriers by promising them less control.
This is a statement about the Android software, not about the phones that run it. In other words, the real question is: replaced by whom?
Nothing in the Android license requires phone manufacturers or network operators to allow users to replace software. Google didn't get all those mobile operators on board by promising them a lack of control.
> When any OS transitions between 32-bit and 64-bit every single driver must be at the very least recompiled, if not modified.
I installed Leopard, and now I run 64 bit Xcode without needing to recompile or even reinstall USB Overdrive, my 32 bit 3rd party shareware mouse driver. It just works. That would not have been possible under Linux or Windows. My comment was correct.
> A 64-bit kernel cannot load 32-bit code.
Of course it can. Mac OS 9 ran 68k code in the same process as PowerPC code. It's just a matter of how seriously you take compatibility. Apple chose not to write a mixed mode manager for 32 bit code, but that was a judgement call, not a technical limitation.
> In terms of API legacy support, nobody beats Microsoft. I can run 20 year old 16-bit DOS software on my Windows Vista box seamlessly, with VESA graphics and SoundBlaster-16 support. Apple simply has nothing that compares.
Heh - you have better luck than me, then. I find that I need DOSBox to run software that old.
In any case, I said that Apple has stronger compatibility requirements than Microsoft in many ways, not every way. 64 bit is an example. Apple enabled it transparently, while Microsoft did not; that 16 bit software you mention does not run in 64 bit Vista.
You're right, I should have been more clear. I meant that Linux enabled 64 bit software in a way that broke binary compatibility with drivers. This is not an issue for drivers that get recompiled as part of the kernel, but it is an issue for drivers that are not.
> They aren't bound by compatibility like MS is, or even Linux.
Oh, how I wish that were true....but Mac OS X has very strong compatibility requirements, far stronger than Linux and in many ways stronger than Microsoft.
When Windows and Linux went 64 bit, they just broke all the drivers. Apple maintained compatibility with 32 bit drivers while enabling 64 bit software. When Apple migrated from PowerPC to Intel, they maintained binary compatibility with all the old software via a transparent emulator - something you don't find on Linux and that works only partially on the Xbox 360. The application frameworks - Carbon, Cocoa - are very much bound by backwards compatibility.
Linux, with its tradition of open source and recompiles, has it easy.
> What's to keep the virus from just using the underlying trap instruction for its system calls? This is a UNIX system, friends, you don't need to call printf(), you can call write().
How do you execute a system call? You need to have the processor jump into a buffer of your instructions. The usual approach is to somehow get your instructions into memory and then overwrite the return address on the stack with a pointer to that buffer.
But if the buffer is in a different location every time, there is no way to know ahead of time what value to put into the return address. And remember that you have to overwrite the return address before you can execute any instructions, so you can't compute it at runtime either.
Re:I commercially exploit a copyright, am not a th
on
Piracy Economics
·
· Score: 0, Troll
So I spent a week of my own time and fixed that. Had I not spent a week, that problem would remain unfixed, and the circa five thousand people who played a game of bingo this year that was printed from my software would be bingo-less
Are you sure you wouldn't have just written it anyways, because you had nothing better to do?
So, again, how am I stealing from anyone? Simple. You have a piece of software, information wants to be free, and therefore you have a moral obligation to give that piece of software to me. How you obtained it is irrelevant. The same goes for all the software you keep in that big programmer brain of yours, too. Get to writing it, slave. I grow impatient.
Re:copyrights are an illegitimate law
on
Piracy Economics
·
· Score: 1
copyrights, as an artificial, government-granted monopoly, has no place in a free market.
Land ownership is another artificial, government-granted monopoly - are you opposed to private ownership of land? Or the radio spectrum?
Besides, what makes you so sure that copyright isn't essentially an offshot of contracts - "I'll sell this to you if you contractually agree to not give it to someone else?" Even the most hard-core libertarians agree that enforcement of contracts a legitimate role of government.
I'm shocked by how many people answer this with an unqualified "Yes." That's not realistic at all.
Here's an example. An app asks for your password. That password gets written to memory for a period of time. During that time, the page containing the password may get swapped to disk. The system may then crash or lose power, leaving the password on disk. I could then boot into another OS, read the swap file, and recover your password. Unlikely, but possible.
There, I "found" a security hole. Want to patch it? You could try to make every app that uses a password store it in wired (not swappable) memory - but performance will suffer (and good luck doing that in every app). You could also dynamically encrypt all data that gets written to the swap file, and decrypt it when read, at the cost of performance again.
Are you willing to trade performance in every app to defend against this mostly theoretical vulnerability? Probably not. Security is about tradeoffs. Welcome to the realities of software development.
> But why not fix the small ones as you find them?
Because a fix isn't always obvious, or may be risky, or may impact a feature, etc. If the security problem is indeed "small," then the fix may not be worth it.
Slashdot Mirror
Even if Android wins, they still have to persuade carriers to keep Google as the default search provider. Gogole has no leverage over carriers because they give away the OS for free.
Your customers are the people who give you money. It's the advertisers, not app developers, who are Google's customers.
That's why Google can say that app stores aren't the future (some way to treat your "customers!") and why paid apps struggle to get any traction on the Google app marketplace.
Except the ones that do, by default, on the largest carrier in the USA.
Carriers don't default to Google's search on Android because it's Android. They do it because they think it's what their customers want, and/or Google pays them the most money. That can change overnight, and Android and Chrome (being open source) could not even lean against that wind, let alone stop it entirely.
It would be a big mistake for a company like this to produce any products. These companies exist only to license out IP they buy or otherwise "invent," and to sue non-licensees for patent infringement. If they were to produce a product, they would make themselves vulnerable to a countersuit.
Android is going to make Google billions in licensing
I'm not sure what there is to be licensed. The software is open source, so there's no licensing fees to be had there. I suppose they could license out the mark "Android," but that's a weak brand if I ever saw one.
I think Android is a big money sink for Google and they'll try to pawn off its development to the "community" within a few years. It may still help them in the long run by jump-starting the mobile web as an advertising space, but Google does not need to pay someone to make that happen.
Snapshots can take a lot of space!
Imagine you have a 5 GB movie file that you snapshot. If you then try to delete the file, you will not recover the space, because the snapshot holds onto the file. Effectively, the snapshot is consuming 5 GB.
"Unsung" asks whether ZFS is smart about how it removes snapshots as space is needed. This is a reasonable question with a trivial answer: no, because ZFS never removes snapshots, even if space is needed. It is the user's responsibility to remove snapshots.
Apple may make an effort to get their products on the screen, but they say they never actually pay for product placement.
It is rather doubtful that an Android phone will execute Java bytecode natively, given that Android doesn't use Java bytecode.
There are several things in the system that will make it difficult to scale up to higher resolution displays. One example is Android's use of integer pixel coordinates, instead of abstract floating point coordinates. By tying Android to pixels, Google ensures that application elements will appear smaller (and so less usable) on higher res displays.
That's because there's no information - in Google's own words, "We haven't yet announced the plans for application distribution."
(I'm not entirely convinced they've formulated them either. It took Apple a while to get there.)
If the iPhone were as open as Palm, Symbian, or Windows Mobile, every major carrier would be shipping it.
I'm not sure I follow. Are you saying that the carriers rejected the iPhone because they thought its closed nature would make it unsuccessful in the market? Or maybe they were making a moral stand for consumer openness?
A more likely explanation is that the iPhone took control from the carriers and gave it to Apple. Consumers, empirically, ended up somewhat better off.
I mean, people have been unlocking the iPhone and using it on other carriers. The carriers didn't complain, Apple did.
Carriers complained bitterly about unlocking. It took a class action lawsuit and a visit to the Supreme Court to end AT&T's policies against unlocking. If they've been quiet about iPhone unlocking, it's only because they've lost that battle.
Apple has to make a good faith effort to prevent unlocking as part of their contract with AT&T. To Apple, an unlocked phone is another sale, and they have no reason to care if you do so.
If replacing the home screen or dialer requires you to install an application to crack the digital protection on the OS, how is that better than the iPhone?
Android apps are written in Java. The features you describe would require changes to the system software. The system software is mostly open source, but changing it would require users to reinstall the OS, and that's not likely to happen, especially if the OS is forked for different vendors.
It's trivial to lock down. The carriers and handset makers are free to modify Android however they please, with no requirement that they release their changes, and no requirement that the open source version of Android even work on their phones.
What makes people think that the mobile network operators, who have resisted this sort of openness in their handsets before, will embrace it now? Nothing in the Android license requires them to do so.
Apple had to struggle to find a single carrier willing to allow the iPhone. Google showed up with six. You don't get six times as many carriers by promising them less control.
This is a statement about the Android software, not about the phones that run it. In other words, the real question is: replaced by whom?
Nothing in the Android license requires phone manufacturers or network operators to allow users to replace software. Google didn't get all those mobile operators on board by promising them a lack of control.
> When any OS transitions between 32-bit and 64-bit every single driver must be at the very least recompiled, if not modified.
I installed Leopard, and now I run 64 bit Xcode without needing to recompile or even reinstall USB Overdrive, my 32 bit 3rd party shareware mouse driver. It just works. That would not have been possible under Linux or Windows. My comment was correct.
> A 64-bit kernel cannot load 32-bit code.
Of course it can. Mac OS 9 ran 68k code in the same process as PowerPC code. It's just a matter of how seriously you take compatibility. Apple chose not to write a mixed mode manager for 32 bit code, but that was a judgement call, not a technical limitation.
> In terms of API legacy support, nobody beats Microsoft. I can run 20 year old 16-bit DOS software on my Windows Vista box seamlessly, with VESA graphics and SoundBlaster-16 support. Apple simply has nothing that compares.
Heh - you have better luck than me, then. I find that I need DOSBox to run software that old.
In any case, I said that Apple has stronger compatibility requirements than Microsoft in many ways, not every way. 64 bit is an example. Apple enabled it transparently, while Microsoft did not; that 16 bit software you mention does not run in 64 bit Vista.
You're right, I should have been more clear. I meant that Linux enabled 64 bit software in a way that broke binary compatibility with drivers. This is not an issue for drivers that get recompiled as part of the kernel, but it is an issue for drivers that are not.
> They aren't bound by compatibility like MS is, or even Linux.
Oh, how I wish that were true....but Mac OS X has very strong compatibility requirements, far stronger than Linux and in many ways stronger than Microsoft.
When Windows and Linux went 64 bit, they just broke all the drivers. Apple maintained compatibility with 32 bit drivers while enabling 64 bit software.
When Apple migrated from PowerPC to Intel, they maintained binary compatibility with all the old software via a transparent emulator - something you don't find on Linux and that works only partially on the Xbox 360.
The application frameworks - Carbon, Cocoa - are very much bound by backwards compatibility.
Linux, with its tradition of open source and recompiles, has it easy.
> What's to keep the virus from just using the underlying trap instruction for its system calls? This is a UNIX system, friends, you don't need to call printf(), you can call write().
How do you execute a system call? You need to have the processor jump into a buffer of your instructions. The usual approach is to somehow get your instructions into memory and then overwrite the return address on the stack with a pointer to that buffer.
But if the buffer is in a different location every time, there is no way to know ahead of time what value to put into the return address. And remember that you have to overwrite the return address before you can execute any instructions, so you can't compute it at runtime either.
Are you sure you wouldn't have just written it anyways, because you had nothing better to do?
So, again, how am I stealing from anyone? Simple. You have a piece of software, information wants to be free, and therefore you have a moral obligation to give that piece of software to me. How you obtained it is irrelevant. The same goes for all the software you keep in that big programmer brain of yours, too. Get to writing it, slave. I grow impatient.Land ownership is another artificial, government-granted monopoly - are you opposed to private ownership of land? Or the radio spectrum?
Besides, what makes you so sure that copyright isn't essentially an offshot of contracts - "I'll sell this to you if you contractually agree to not give it to someone else?" Even the most hard-core libertarians agree that enforcement of contracts a legitimate role of government.
I'm shocked by how many people answer this with an unqualified "Yes." That's not realistic at all.
Here's an example. An app asks for your password. That password gets written to memory for a period of time. During that time, the page containing the password may get swapped to disk. The system may then crash or lose power, leaving the password on disk. I could then boot into another OS, read the swap file, and recover your password. Unlikely, but possible.
There, I "found" a security hole. Want to patch it? You could try to make every app that uses a password store it in wired (not swappable) memory - but performance will suffer (and good luck doing that in every app). You could also dynamically encrypt all data that gets written to the swap file, and decrypt it when read, at the cost of performance again.
Are you willing to trade performance in every app to defend against this mostly theoretical vulnerability? Probably not. Security is about tradeoffs. Welcome to the realities of software development.
> But why not fix the small ones as you find them? Because a fix isn't always obvious, or may be risky, or may impact a feature, etc. If the security problem is indeed "small," then the fix may not be worth it.