Anything but a full blown holodeck isn't going to appeal to the masses.
Besides, you talk about 2 years for a Pixel... I talk about over 4 years supported. So, liar? More like realistic vision on longevity of devices.
cheaper premium smartphones
It's not a premium smartphone, if you don't get updates... So, let me fix that for you: cheaper smartphones. That's it, explains it all...
Even Google and Samsung suck at keeping updates going for longer than six months, which is why the user who expects longevity and supports shells out for Apple. Sad to say, but I expect my smartphones to last four years. Two, new as my wifes phone on a subsidized contract (with flat everything), and then two more years as a hand-me-down for me with a much cheaper plan.
Your comment brings a smile to my face
I'm currently trying out a new behavior trait: "going back to the way it was before." Sounds exciting, huh. Color me Facebook-less since 1.5 months and frankly, this is the first time since I feel the need to actually share something.
A lot of times, bad MTU settings are the problem with a sat link. The problem is simply stated: GRE tunnels are common on such links, and a GRE tunnel will encapsulate each packet and add a 16 byte header. Since the modems usually only permit a 1500 byte MTU, this means the maximum packet size you can get through the GRE tunnel will be 1484 bytes long, inclusive of header. If someone sends out a packet that is maximum size for a 1500 byte MTU, and sets the DF (Don't Fragment) bit, when the packet hits this GRE tunnel it will be dropped. This happens frequently with bad SSL implementations.
This is only one version of MTU problems with sat links. There are others.
The problem with a satellite connection is not precisely related to latency but rather to jitter, the large differences in latency from one packet to the next. This happens as a result of rain fade, or a poorly engineered link to your transponder on the bird, or a variety of other more infrequent issues.
You can (and should) up your TCP timeout values from the default 3 seconds on a satellite connection, and adjust the http keep-alive timeout, etc, but a lot of times this just means you wait longer to be told when the connection fails.
The solution is a combination of caching, compression, and a performance enhancing proxy or PEP. The PEP does TCP spoofing, basically faking the acknowledgements to speed up the transmission of packets. Compression is similar to the MNP5/v.42bis stuff from modem days applied to a satellite connection. Caching is basically Squid. A lot of PEPs combine all three functions into one - Riverbed is a really good example, though i've worked with pretty much every vendor and they all do the same stuff, with differences in ease of use and efficency.
Implement the timeout fixes, implement a good PEP with all three of the ingredients noted, and make sure the connection is dialed in well with a good shot (line of sight) without physical impediments like trees, buildings, and most importantly microwave interference, and you should have a fairly reliable internet connection. You will still take hits, but you can look at the front of the satellite modem and see that is happening if it's an iDirect or something similar.
Bottom line though is that unless you are taking hits, you should be able to set up downloads of a lot of images and never see a timeout.
- someone who has spent a lot of time doing this (and living off sat connections) in awful places in the world
Unless downloading means something else to marketing people than it means to me...
You know you've been spending too much time on the computer when your friend misdates a check, and you suggest adding a "++" to fix it.