NateC

Discounting the device itself is fine and happens all the time to push particular products for various reasons. But they're not doing that. They're discounting the cellular service which has nothing to do with the device.

You're absolutely right that it's a market and we have choices. My question is really aimed at seeing how Sprint can justify (both to themselves and customers) how this is acceptable. I'm not saying they're doing anything illegal here; and they are completely within their right to charge whatever they want. They don't *have* to justify anything technically. But that doesn't make it a good idea.

Here's a silly analogy to illustrate my point: Let's say Wal-Mart started a new promotion along the lines of "For a limited time, Republicans get 20% off their purchases." Would you guys still be making the following arguments? It's perfectly fine. It's not a fee for Democrats, it's a discount for Republicans. Look at the phrasing! It's not punishing Democrats, it's simply different prices for different political parties. This is justified because it will bring in more Republican customers to Wal-Mart. Wal-Mart can make a lot of money with this! This is fine because it's a limited time only. Republicans are more loyal to their retail stores, so this makes sense We're not talking about a military veteran or student discount here. It's iPhone vs. Android.

.. I would accept this as reasonable if it weren't for the fact that the $50 price applies to non-subsidized, non-leased rates. For someone using EasyPay and keeping the device at the end, they pay the same retail price of $650 and still maintained the $50/month rate.

"Discount for one" vs. "Penalty for the other" is a matter of perspective. As an Android user who sees no reasonable explanation for the discrepancy, it's a penalty.

But it's not so simple. From my perspective it's penalizing Android users, punishing 50% of Sprint customers with a 20% "Android tax", even though the device should be completely decoupled from the service in a fair world.

Serious question: How has Sprint justified the 20% pricing discrepancy between iPhone and non-iPhone individual unlimited plans ($50 vs. $60, respectively)?

Whether it's more expensive is really dependent upon your use case. For me, I'd only want a device like this for occasional usage when traveling, and I don't use a ton of data. 1 GB would probably last me 6 months. In this case, the Verizon Jetpack would be significantly more expensive than the Karma Go. Compare the 6 month cost: Verizon Jetpack: 250 MB/month plan ($15) + $20/month access fee = $35/month * 6 months = $210 Karma Go: 1 GB = $14 And with Verizon, I'd be limited to 250 MB/month. Verizon doesn't come close. The bottom line is it's really hard to compare monthly against pay-as-you-go plans.

That's certainly debatable. According to Anandtech's review of the 2014 Moto X: Nexus 5 screen is significantly brighter Nexus 5 screen has superior grayscale accuracy Nexus 5 screen has significantly better saturation accuracy Nexus 5 screen has better GMB accuracy The only thing that was rated in the Moto X's favor was white color temperature accuracy, and it was an extremely negligible difference (they are practically identical). As far as the camera is concerned, the Moto X 2014 camera was also very unimpressive in Anandtech's review. They didn't compare against the Nexus 5 directly though. In any case, I don't think you can really say it's definitively better than the Nexus 5 camera from what we currently know.

There's definitely more to this story. This is baffling.

You cannot trust a statement from a CSR.

From what I can tell, the new feature with T-Mobile's WiFi calling is that they're implementing seamless handovers between VoLTE and WiFi calls.

Ah. I noticed the Bell/Rogers band 7 support, but I figured maybe they just included that in there for roaming/compatibility purposes. I also didn't think they'd do the Canadian version before Sprint/Verizon/T-Mobile, but I don't really know.

And now today the IHDT56QA2 variant was spotted. LTE bands supported: 2 (1900 MHz), 4 (1700 MHz), 7 (2600 MHz), 13 (700 MHz) CDMA, GSM, and UMTS: 850 MHz and 1900 MHz This one could be for Verizon?

If that's the case for you, that's especially evil of Sprint. The only ways I can think of to workaround that would be to use something like OpenDNS which serves on port 5353 in addition to 53. Then you'd use a local caching nameserver on 127.0.0.1 or use a similar iptables rule to redirect outgoing port 53 traffic to OpenDNS on 5353. It's a shame that DNS hijacking has become so common.

You are correct on the first point, but incorrect on the second. For the first point, I must have been sloppy and missed that, since I was sure I rebooted to test. Thanks! For the second point, as mentioned before, Sprint is definitely not redirecting DNS requests in my area. See adb shell log below: (this was while connected to Sprint 4G LTE with WiFi disabled; using a different cell site than the previous test even) root@jewel:/ # nslookup alksjdfklj.com Server: 68.28.68.132 Address 1: 68.28.68.132 ngns1a.chcgibr05.spcsdns.net Name: alksjdfklj.com Address 1: 2620:118:7008::1064 Address 2: 2620:118:7002::1064 Address 3: 198.105.244.64 Address 4: 198.105.254.64 root@jewel:/ # nslookup alksjdfklj.com 8.8.4.4 Server: 8.8.4.4 Address 1: 8.8.4.4 google-public-dns-b.google.com nslookup: can't resolve 'alksjdfklj.com': hostname nor servname provided, or not known Maybe Sprint's DNS redirection behavior varies by region.

That seems reasonable to me. Either way it's confusing since the diagram doesn't show rounded corners: And you are right that the device certainly won't have completely straight corners. But it's still weird that they'd draw the dimension that way going sharp corner to sharp corner. I think the conclusion is that we can't read too much into that diagram either way. Whatever it is, it's much bigger than the original Moto X.

Yeah, I considered that possibility as well. It's really confusing though, because if it's *not* the display diagonal dimension, then what is it? It can't be the chassis dimensions, because sqrt(72.6^2 + 140^2) != 149^2. If we consider reasonable bezel sizes, it would in fact suggest that 149 mm is not the diagonal screen size. If we consider mathematical truths, then H=140mm, W=72.6mm can't have a diagonal of 149mm, suggesting they are not chassis sizes. So what is it?

I'm disappointed to see that it doesn't support AT&T/T-Mobile/Sprint bands all in one device like the Nexus 5 did. I was really hoping that would become the norm. Also, the other reason I hope this isn't the basis for the new Nexus is because it's too damn big. The Nexus 5 is already too big in my opinion, and this device is even *larger*.

Just spotted on the FCC website. http://www.phonescoop.com/phones/fcc_query.php?gc=IHD&pc=T56QA1 (just using phonescoop.com to redirect to the appropriate FCC page) This appears to be a flagship-level device since it supports LTE, NFC, WiFi on 2.4 and 5 GHz, etc. This variant is intended for AT&T/T-Mobile based on the supported bands. Device dimensions: Height: 140 mm (5.51") Width: 72.6 mm (2.86") Screen diagonal: 149 mm (5.87") Based on that, it's probably the rumored Moto "Shamu"?

Yeah, I'm not big on rooting phones to flash fancy ROMs or anything, since in my experience they tend to have unpredictable quality with respect to device drivers and stability. But I do use rooted stock ROMs so I can have control over things like this. And it does not appear that Sprint redirects port 53 requests in my area at least (Wisconsin). I verified that bogus domain names still returned NXDOMAIN while on 4G LTE after applying my hack.

Since I have root on my HTC EVO LTE, I worked around this problem with the following steps: 1. "adb shell" from my computer (requires android SDK installation and USB connection to PC) 2. mount -o remount,rw / 3. Edit /init.rc (I used vi) 4. Find the end of the "on init" section. For me it was right after the "#htc sensorhub" lines. Add the following lines to the end: # Hack to force use of google DNS to fix domain/NXDOMAIN hijacking by Sprint /system/bin/iptables -t nat -I OUTPUT -p tcp --dport 53 -j DNAT --to-destination 8.8.4.4:53 /system/bin/iptables -t nat -I OUTPUT -p udp --dport 53 -j DNAT --to-destination 8.8.4.4:53 5. Save and remount / as read-only: mount -o remount,ro /

Breaking NXDOMAIN is evil. I just verified the same behavior over here. I use 'adb shell' to connect to my phone and try the following: When on WiFi (correct behavior): root@jewel:/ # nslookup klasjdfkljasdf.com Server: 192.168.0.1 Address 1: 192.168.0.1 nslookup: can't resolve 'klasjdfkljasdf.com': hostname nor servname provided, or not known After turning off WiFi, on Sprint 4G LTE (broken behavior): root@jewel:/ # nslookup klasjdfkljasdf.com Server: 68.28.68.132 Address 1: 68.28.68.132 ngns1a.chcgibr05.spcsdns.net Name: klasjdfkljasdf.com Address 1: 2620:118:7008::1064 Address 2: 2620:118:7002::1064 Address 3: 198.105.254.64 Address 4: 198.105.244.64 And mozamcrew is right: although tolerable for the web browser, it can easily break other applications.

Interesting. Thanks for the info!

For the original Moto X and Moto G, Motorola submitted to the FCC about 80 days before the official public announcement/unveiling. The Moto E showed up on the FCC's website sooner, just 33 days before it was announced. Now here we are, knowing with near certainty that Motorola's event scheduled for September 4th, 2014 will announce a new Moto X (among other things). That's just 13 days from today, and there's still no sign of the new Moto X on the FCC's website. The previously promised release date (which may be different from the announcement on 9/4) was "the final days of summer", which would be before 9/22. My question is: How unusual is this? It seems like it's really pushing it based on the recent history of Motorola for the X/G/E, but I haven't really looked to see what companies typically do aside from those 3 instances.