Nothing prevents Cogent from purchasing access to Verizon network
Verizon already got paid, by their customers, the ones who are requesting to stream from Netflix.
it does not make sense to provide free access and it is fair to expect on of the parties to pay
Verizon already got paid, by their customers, the ones who are requesting to stream from Netflix.
And now Cogent expects Verizon to invest in their network so that they can act as an extension of the Cogent network, through a "peering" agreement.
More importantly, Verizon's paying customers -- the ones who are requesting to stream from Netflix -- are expecting Verizon to invest in their network so that they can deliver the contracted-for services. The fact that Netflix uses Cogent versus Billy Bob's Bass Boat, Bait Barn, and Content Distribution Network does not really play a role here.
A dedicated keyboard allows multi-key commands (Ctrl-Shift-= for superscript, etc) that a tablet cannot do.
A tablet with a keyboard can, whether that keyboard is a dedicated attachment (e.g., ASUS Transformers and their keyboard slices), via Bluetooth, etc. Over time, developers with apps needing complex input like this will support such keyboards, just as they do with desktop (and, to some extent, Web-based) app counterparts.
A mouse allows for nested menus with thousands of options. That's a no-go for tablets.
Ignoring the fact that "nested menus with thousands of options" is an awful UI on any platform, this is equally possible with a touch interface.
It happened to me, and I have the six-inch scar from the incision to repair my left elbow as testament. It happened to my brother, and he has the scars on his ear from the plastic surgery to reattach it as testament. The fact that it has not happened to you does not mean that it does not happen.
or they ride into a suddenly opened car door, that sort of thing and the helmet doesn't do shit
Sure it does. In my case, my helmet stopped me from having my head cracked open the way my helmet cracked when I hit the asphalt in a slow-speed accident. In my brother's case, he was not wearing a helmet and suffered the consequences -- his ear would not have been nearly torn off otherwise. The fact that it has not happened to you does not mean that it does not happen.
A bike helmet does not stop all possible injuries (e.g., to elbows) any more than an (American) football helmet stops all possible injuries (e.g., to knees). It is certainly worthwhile debating whether the frequency of such injuries is worth legislation to mandate such safety equipment. But slow-speed accidents do happen and helmets can help in these cases, whether you like it or not.
Article 9 allows a state to demand that an "the head of the mission or any member of the diplomatic staff of the mission" is "persona non grata" and force that person to be recalled. That is an individual, not the entire embassy/mission. And that's about it, short of breaking off of diplomatic relations, which is not exactly a trivial act.
And, without the ability to "dissolve the embassy", the UK claims to "take actions in order to arrest Mr Assange in the current premises of the embassy" implies "storm the embassy by force", if Ecuadoran staff resists.
This library is essential for Android application development, therefore it would become legally impossible to develop a closed-source Android app.
By that argument, it would be legally impossible to develop a closed-source Linux app. Yet there are many closed-source Linux apps. Do not confuse "linking with a GPLv2 library" and "writing for an OS that contains GPLv2 libraries".
If you actually get to the Boy Genius Report post, you will see that this statement has already been corrected, at least somewhat:
The version of Honeycomb we’ve shown is optimized for tablet form factors. All of the UI changes are the future of Android. Yesterday’s event focused on tablet form factors, which is where you’ll first see Honeycomb.
Mostly because they do not have email addresses of everyone. They have Google accounts, but not everybody who has a Google account for the purposes of Android uses GMail.
The fact that the modding community can turn on OS around in a few weeks and push it back out to the device is testament to how easy it is to put these newer versions of software on the phone, and it just the manufacturers trying to add their own crap back on that is the issue.
It is not that simple.
As just one example, ROM modders are willing to put up with "brick rates" that would result in class action suits if a device manufacturer and carrier tried the same thing. A 99% success rate -- which a ROM modder would probably consider to be pretty good -- would still mean in excess of 10,000 bricked G1s, 10,000 bricked Magics, etc. ROM modders simply are willing to use techniques (e.g., re-partitioning flash) that device manufacturers deem too risky. Hence, device manufacturers and carriers elect to be more conservative, so they do not wind up with millions of dollars in extra support costs.
Applying HTC Sense and MOTOBLUR and such to new Android releases does indeed involve work, and that definitely has an impact on upgrade availability. But it's not the whole story. Some of the reasons are good for consumers (e.g., minimizing bricked phones), and some of the reasons are bad for consumers (e.g., emphasizing new products at the expense of old).
Keep in mind that for most nationally published authors, the royalty is on cover price in all but a few very carefully worded exceptions that do not usually apply.
That may be true for the YA market. For technology books, and AFAIK non-fiction in general, royalty rates in contracts are on net (after reseller discounts), rather than on gross. That certainly was the case for the two I signed, and I did a fair amount of research to determine that this was, indeed, the norm. Reseller discounts can run as high as 55%, though ~40% is more typical.
And, of course, that's a good part of the reason why I started my own publishing firm.
Techdirt did a nice deconstruction of the 24/7 Wall Street analysis. In a nutshell, 24/7 Wall Street applied the Drake Equation to iPhone apps, piling on layers of hand-waving to come up with their figure.
I wish this functionality was built into the OS, rather than having to do it manually (for example, a way to disallow internet access during installation)
I'm sure you know this, but for other readers of your post -- just as there is a permission to read contacts and such, there is a permission apps have to request to gain access to the Internet. So, at install time, you can read through the list of requested permissions and take appropriate action. For example, I rarely install ones that ask for my contacts and for the Internet, even presumably reputable apps like the Evernote client.
What you can't do is later change your mind (other than to uninstall the app) or selectively grant permissions. Your iptables trick lets you change your mind on the Internet permission, in effect.
It's only open source until Google decides that they don't want someone else using the "Open Source" code and files a court injunction as was done last week.
And your proof of this claim is...what, exactly?
Perhaps you are referring to an incident from about 2-3 weeks ago, when a ROM modder was sent a cease-and-desist letter by Google for including closed-source applications in his Android ROMs. The consensus opinion is that Google was legally right but clumsy in how they handled this incident. However, misrepresenting what happened helps nobody.
If you are going to bash, bash evenly.
Better yet, bash factually.
In the interest of full disclosure, per my sig, I'm involved in the Android development community.
The difference with Android, versus the other two options, is that the hardware manufacturer and the OS implementer are decoupled.
Android supports root just fine. However, device manufacturers offer no official means to get to root and no official means to flash root-enabled system images. This is no different than Linux supporting root but TiVo not exactly enabling it on their DVRs.
What Android needs is some manufacturer to step up and offer root-capable devices, with limited muss or fuss.
every one of these technologies degrades over time, as well as when heated.
And your proof of this assertion is...what, exactly?
Their power production curves are mostly the "fall to near-zero instantly" type, with very little warning that they're running out of juice.
And your proof of this assertion is...what, exactly?
They tool along, thinking they are doing fine, only 218 miles... 219.... THUNK. Car stops or drops to a crawl, barely enough power to operate the new "energy saving" drive-by-wire steering (if that much) to pull off the road.
Or, the engineers that designed the car had half a brain, and built in a reserve with a governor. Once the main cells are depleted, a reserve set of cells kicks in, with a governor that limits speed to, say, 25mph. This would be sufficient to keep the car moving (e.g., breakdown lane) to get it to a safe spot. The governor also pretty much blocks the behavior of the folk you so eloquently refer to as "boobs", since the reserve doesn't give the same performance as the regular batteries.
So now where are we? We have a dead car on the side of the road. Motorist assistance drops by, they're out of juice. Whoops, can't just give them a gallon or so of gas and point them down the road to the gas station 8 miles down... nope, have to get a hauler out there and have them towed.
Or, the engineers that designed the car built it so the battery packs are replaceable on the fly. Like, say, Better Place is calling for. So long as there are decent standards (and for Better Place to fly, there'd have to be such standards), all you need is a motorist service vehicle with spare cells to swap in, enough to get you to a regular charging or battery replacement depot.
there's no sign yet of a phone that is completely hackable by the end user
If you're referring to the ability to replace the firmware, that is definitely a disappointment. However, that's between HTC and T-Mobile. With Android published under the Apache License 2.0, there's not much anyone can do to force HTC and T-Mobile to allow self-signed firmware. My hope, though, is that some of these non-carrier devices, like the one cited in the OP, will allow replacement firmware. Only time will tell.
The docs are out there, such as The Busy Coder's Guide to Android Development.
Thanks for the shout-out!
so we could see a utopia of community-driven apps, but it seems like Google is uninterested in the end user's extendibility of the platform, which was supposedly it's raison d'etre.
On the apps front, I suspect part of the hang-up is that the Android Market — the closest counterpart to the iPhone App Store — is only supporting free apps right now. Vendors interested in turning a buck (or yen or euro or whatever) either need to use one of the other markets or wait for the Android Market to start supporting paid-for apps. That's reputedly coming in Q1.
Even given that, the Android Market has a fair number of apps there. I don't remember the release rates for the iPhone apps when its SDK was released, but I'd be a bit surprised if Android is dramatically off the pace. Yes, many of the apps are trivial (umpteen tip calculators, flashlights, etc.), but it's not like every iPhone or WinMo app is a blockbuster. Considering hardware has been available for 5-6 weeks, I'm relatively pleased with the response to date, for what my opinion is worth.
As my sig notes, I'm somewhat biased on this topic, but I still think you're taking a narrow, short-term view of what the iPhone is.
Yup. Android still has the same problems that drove my company away from mobile development for years.
iPhone will have most of those same problems too. Just a bit more slowly.
Sure there's only one Android phone now, but a year from now...
Sure, there's only two iPhones now, plus an iPod Touch or two, but a year from now...
Do you honestly expect Apple will forevermore keep the same resolution, aspect ratio, RAM, CPU speed, system events, input methods, and whatnot that they have today? I think Apple is going to keep innovating, and that means new devices with new characteristics, characteristics that will differ from the current iPhone and will need to be taken into account by developers.
If Apple changes specs with future iPhone models, you will need to either support only a subset of iPhone models, or you will need to make sure your applications work well across all relevant iPhone models. No different from the scenarios you were just kvetching about.
Android will have a far wider range of device characteristics far sooner, because there are several manufacturers and carriers involved, let alone the possibility of more homebrew efforts like porting it to existing devices. But it's not like iPhone will be immune from this. If it is, then iPhone is toast in a decade.
vs, say, J2ME, which has a huge install base that shows no signs of collapsing.
Well, now, I wouldn't say that.
Looking at the smartphone platforms, iPhone doesn't support J2ME. Android doesn't natively support J2ME, though some folk are working on a J2ME compatibility layer. Windows Mobile supports J2ME, I think, but you have to believe that Microsoft would really rather you build apps using.NET. Only Blackberry and Symbian might consider J2ME strategic, and who knows what Symbian will do after their overhaul.
J2ME is in somewhat better shape on feature phones (things wimpier than smartphones), insofar as there is no aggressive competitor...yet. I predict Android will head to feature phones.
So, J2ME is a widespread option, but there are definitely chinks in the armor.
If you don't trust the Android Market's kill switch, buy your Android applications through another market (SlideME, AndAppStore, Handango, etc.). There is no real equivalent on the iPhone short of hacking the device.
People go on and on about how Android is Linux based and Open Source, but it's not.
And your proof of this assertion is...what, exactly?
As counter, I offer links to the Git repository and the kernel and other GPL/LGPL bits. That's already more than any other major platform has done, and they aren't through yet.
The Linux backend is all but invisible
What? You want it to pop up with a bash prompt?
and likely just as locked down as the Linux installs on other embedded devices
And your proof of this assertion is...what, exactly?
The decision on whether a device is firmware-flashable is made by the device manufacturer. The T-Mobile G1, the first Android device, is being made by HTC, which has a history of making firmware-flashable devices.
You are not going to be able to easily replace it, assuming you can even get close enough to the system to have a hope of doing so. Tivo, all over again.
And your proof of this assertion is...what, exactly?
Google is doing everything in the Java environment precisely to put you in a sandbox they (and the cell networks) can control.
Popularity of Java in mobile device development, of course, would have nothing to do with it, since that wouldn't fit your conspiracy theory. Neither would security (no direct memory access), for that matter.
Sure the developer agreement is not quite as onerous as the one Apple uses, but it's certainly just as controlling when necessary.
And your proof of this assertion is...what, exactly?
I mean, seriously. If you have problems with their developer agreement, cite passages and specific issues.
And, sadly, so long as the cell carriers are seen as the customers of these phones
Carriers will, undoubtedly, be the "customers" of many Android devices. At the same time, I've received emails from manufacturers whose devices will not be sold through carriers. If your carrier allows standards-compliant devices (e.g., GSM), you should have your choice, albeit not on day one, as Android devices make it through various manufacturing and development processes.
Slashdot Mirror
Verizon already got paid, by their customers, the ones who are requesting to stream from Netflix.
Verizon already got paid, by their customers, the ones who are requesting to stream from Netflix.
More importantly, Verizon's paying customers -- the ones who are requesting to stream from Netflix -- are expecting Verizon to invest in their network so that they can deliver the contracted-for services. The fact that Netflix uses Cogent versus Billy Bob's Bass Boat, Bait Barn, and Content Distribution Network does not really play a role here.
A tablet with a keyboard can, whether that keyboard is a dedicated attachment (e.g., ASUS Transformers and their keyboard slices), via Bluetooth, etc. Over time, developers with apps needing complex input like this will support such keyboards, just as they do with desktop (and, to some extent, Web-based) app counterparts.
Ignoring the fact that "nested menus with thousands of options" is an awful UI on any platform, this is equally possible with a touch interface.
It happened to me, and I have the six-inch scar from the incision to repair my left elbow as testament. It happened to my brother, and he has the scars on his ear from the plastic surgery to reattach it as testament. The fact that it has not happened to you does not mean that it does not happen.
Sure it does. In my case, my helmet stopped me from having my head cracked open the way my helmet cracked when I hit the asphalt in a slow-speed accident. In my brother's case, he was not wearing a helmet and suffered the consequences -- his ear would not have been nearly torn off otherwise. The fact that it has not happened to you does not mean that it does not happen.
A bike helmet does not stop all possible injuries (e.g., to elbows) any more than an (American) football helmet stops all possible injuries (e.g., to knees). It is certainly worthwhile debating whether the frequency of such injuries is worth legislation to mandate such safety equipment. But slow-speed accidents do happen and helmets can help in these cases, whether you like it or not.
"It doesn't violate the Vienna convention to dissolve the embassy" -- you are welcome to provide evidence of this claim. Here is the actual Vienna Convention on Diplomatic Relations.
Article 9 allows a state to demand that an "the head of the mission or any member of the diplomatic staff of the mission" is "persona non grata" and force that person to be recalled. That is an individual, not the entire embassy/mission. And that's about it, short of breaking off of diplomatic relations, which is not exactly a trivial act.
And, without the ability to "dissolve the embassy", the UK claims to "take actions in order to arrest Mr Assange in the current premises of the embassy" implies "storm the embassy by force", if Ecuadoran staff resists.
No, but I am! :-)
(and thanks for the kind words!)
By that argument, it would be legally impossible to develop a closed-source Linux app. Yet there are many closed-source Linux apps. Do not confuse "linking with a GPLv2 library" and "writing for an OS that contains GPLv2 libraries".
They asked you in the Terms of Service you agreed to when you used the Android Market for the first time.
You do not have to get your apps through the Android Market. Anything you install outside of the Market is your responsibility.
Mostly because they do not have email addresses of everyone. They have Google accounts, but not everybody who has a Google account for the purposes of Android uses GMail.
There is no "properly" in some cases, for an upgrade to be sufficiently reliable.
It is not that simple.
As just one example, ROM modders are willing to put up with "brick rates" that would result in class action suits if a device manufacturer and carrier tried the same thing. A 99% success rate -- which a ROM modder would probably consider to be pretty good -- would still mean in excess of 10,000 bricked G1s, 10,000 bricked Magics, etc. ROM modders simply are willing to use techniques (e.g., re-partitioning flash) that device manufacturers deem too risky. Hence, device manufacturers and carriers elect to be more conservative, so they do not wind up with millions of dollars in extra support costs.
Applying HTC Sense and MOTOBLUR and such to new Android releases does indeed involve work, and that definitely has an impact on upgrade availability. But it's not the whole story. Some of the reasons are good for consumers (e.g., minimizing bricked phones), and some of the reasons are bad for consumers (e.g., emphasizing new products at the expense of old).
That may be true for the YA market. For technology books, and AFAIK non-fiction in general, royalty rates in contracts are on net (after reseller discounts), rather than on gross. That certainly was the case for the two I signed, and I did a fair amount of research to determine that this was, indeed, the norm. Reseller discounts can run as high as 55%, though ~40% is more typical.
And, of course, that's a good part of the reason why I started my own publishing firm.
Techdirt did a nice deconstruction of the 24/7 Wall Street analysis. In a nutshell, 24/7 Wall Street applied the Drake Equation to iPhone apps, piling on layers of hand-waving to come up with their figure.
And, to show off his geek cred, Techdirt's Mike Masnick included the xkcd Drake Equation comic.
I'm sure you know this, but for other readers of your post -- just as there is a permission to read contacts and such, there is a permission apps have to request to gain access to the Internet. So, at install time, you can read through the list of requested permissions and take appropriate action. For example, I rarely install ones that ask for my contacts and for the Internet, even presumably reputable apps like the Evernote client.
What you can't do is later change your mind (other than to uninstall the app) or selectively grant permissions. Your iptables trick lets you change your mind on the Internet permission, in effect.
And your proof of this claim is...what, exactly?
Perhaps you are referring to an incident from about 2-3 weeks ago, when a ROM modder was sent a cease-and-desist letter by Google for including closed-source applications in his Android ROMs. The consensus opinion is that Google was legally right but clumsy in how they handled this incident. However, misrepresenting what happened helps nobody.
Better yet, bash factually.
In the interest of full disclosure, per my sig, I'm involved in the Android development community.
The difference with Android, versus the other two options, is that the hardware manufacturer and the OS implementer are decoupled.
Android supports root just fine. However, device manufacturers offer no official means to get to root and no official means to flash root-enabled system images. This is no different than Linux supporting root but TiVo not exactly enabling it on their DVRs.
What Android needs is some manufacturer to step up and offer root-capable devices, with limited muss or fuss.
And your proof of this assertion is...what, exactly?
And your proof of this assertion is...what, exactly?
Or, the engineers that designed the car had half a brain, and built in a reserve with a governor. Once the main cells are depleted, a reserve set of cells kicks in, with a governor that limits speed to, say, 25mph. This would be sufficient to keep the car moving (e.g., breakdown lane) to get it to a safe spot. The governor also pretty much blocks the behavior of the folk you so eloquently refer to as "boobs", since the reserve doesn't give the same performance as the regular batteries.
Or, the engineers that designed the car built it so the battery packs are replaceable on the fly. Like, say, Better Place is calling for. So long as there are decent standards (and for Better Place to fly, there'd have to be such standards), all you need is a motorist service vehicle with spare cells to swap in, enough to get you to a regular charging or battery replacement depot.
FWIW, the word is that the "shipping" charge also includes customs duties and taxes.
If you're referring to the ability to replace the firmware, that is definitely a disappointment. However, that's between HTC and T-Mobile. With Android published under the Apache License 2.0, there's not much anyone can do to force HTC and T-Mobile to allow self-signed firmware. My hope, though, is that some of these non-carrier devices, like the one cited in the OP, will allow replacement firmware. Only time will tell.
Thanks for the shout-out!
On the apps front, I suspect part of the hang-up is that the Android Market — the closest counterpart to the iPhone App Store — is only supporting free apps right now. Vendors interested in turning a buck (or yen or euro or whatever) either need to use one of the other markets or wait for the Android Market to start supporting paid-for apps. That's reputedly coming in Q1.
Even given that, the Android Market has a fair number of apps there. I don't remember the release rates for the iPhone apps when its SDK was released, but I'd be a bit surprised if Android is dramatically off the pace. Yes, many of the apps are trivial (umpteen tip calculators, flashlights, etc.), but it's not like every iPhone or WinMo app is a blockbuster. Considering hardware has been available for 5-6 weeks, I'm relatively pleased with the response to date, for what my opinion is worth.
As my sig notes, I'm somewhat biased on this topic, but I still think you're taking a narrow, short-term view of what the iPhone is.
iPhone will have most of those same problems too. Just a bit more slowly.
Sure, there's only two iPhones now, plus an iPod Touch or two, but a year from now...
Do you honestly expect Apple will forevermore keep the same resolution, aspect ratio, RAM, CPU speed, system events, input methods, and whatnot that they have today? I think Apple is going to keep innovating, and that means new devices with new characteristics, characteristics that will differ from the current iPhone and will need to be taken into account by developers.
If Apple changes specs with future iPhone models, you will need to either support only a subset of iPhone models, or you will need to make sure your applications work well across all relevant iPhone models. No different from the scenarios you were just kvetching about.
Android will have a far wider range of device characteristics far sooner, because there are several manufacturers and carriers involved, let alone the possibility of more homebrew efforts like porting it to existing devices. But it's not like iPhone will be immune from this. If it is, then iPhone is toast in a decade.
Well, now, I wouldn't say that.
Looking at the smartphone platforms, iPhone doesn't support J2ME. Android doesn't natively support J2ME, though some folk are working on a J2ME compatibility layer. Windows Mobile supports J2ME, I think, but you have to believe that Microsoft would really rather you build apps using .NET. Only Blackberry and Symbian might consider J2ME strategic, and who knows what Symbian will do after their overhaul.
J2ME is in somewhat better shape on feature phones (things wimpier than smartphones), insofar as there is no aggressive competitor...yet. I predict Android will head to feature phones.
So, J2ME is a widespread option, but there are definitely chinks in the armor.
If you don't trust the Android Market's kill switch, buy your Android applications through another market (SlideME, AndAppStore, Handango, etc.). There is no real equivalent on the iPhone short of hacking the device.
If you don't trust the Android Market's kill switch, buy your Android applications through other markets (SlideME, AndAppStore, Handango, etc.).
I'll admit to being biased, but...
And your proof of this assertion is...what, exactly?
As counter, I offer links to the Git repository and the kernel and other GPL/LGPL bits. That's already more than any other major platform has done, and they aren't through yet.
What? You want it to pop up with a bash prompt?
And your proof of this assertion is...what, exactly?
The decision on whether a device is firmware-flashable is made by the device manufacturer. The T-Mobile G1, the first Android device, is being made by HTC, which has a history of making firmware-flashable devices.
And your proof of this assertion is...what, exactly?
Popularity of Java in mobile device development, of course, would have nothing to do with it, since that wouldn't fit your conspiracy theory. Neither would security (no direct memory access), for that matter.
And your proof of this assertion is...what, exactly?
I mean, seriously. If you have problems with their developer agreement, cite passages and specific issues.
Carriers will, undoubtedly, be the "customers" of many Android devices. At the same time, I've received emails from manufacturers whose devices will not be sold through carriers. If your carrier allows standards-compliant devices (e.g., GSM), you should have your choice, albeit not on day one, as Android devices make it through various manufacturing and development processes.