Indeed. Even the supposedly quickly updated Moto X did not receive a patch yet two weeks after the fact [1]. I feel sorry for all those people who are still stuck on Kit Kat or even worse Jelly Bean.
I feel for people whose providers won't upgrade them and I think they've got a good complaint, but if you choose to get off the upgrade path I think it's reasonable to assert that you're assuming responsibility for your own choices and security. I expect it can be backported to 4.x via custom ROMs for folks in that spot.
It's not an apples-to-apples comparison, but Android has been around since 2007, and they're up to API level 22 right now. In that same time period, Microsoft has had the following releases of Windows (excluding Mobile/Phone and Server):
Vista, which actually came out in 2006 in the OEM edition
Windows 7
Windows 8
Windows 8.1
Windows 10
Windows has had a much slower release cadence than Android. It's a much, much bigger burden on Google to continue to support older Android versions with bugfixes and security patches than it is Windows. Now, you can counter that Google decided on this release cadence, but still, I don't think it's reasonable to expect Google to support Android versions as long as Microsoft does Windows versions, as some here are stumping for.
(That said, every time I read an article about Android these days I get the urge to buy a Windows Phone.)
I have a Lumia 635, which is nice "for the price" I agree but not nice enough to switch to full-time. I'm hopeful that the new high-end phones provide a real choice.
But there is quite a difference between the 635 and the 640: non-HD vs. HD, possibly 512 MB RAM (depending on the version) vs. 1 GB RAM, 5MP vs. 8MP camera.
I agree that new flagships would be nice though. Especially with Continuum.
The fact that Google created a huge maintenance burden for themselves shouldn't absolve them of responsibility to provide that maintenance.
Microsoft supports Windows versions for ten years, and I agree that's crazy for Android. However, three years I feel is a bare minimum expectation. Devices tend to remain on the market for about a year, and the standard phone contract is two years. So three years from a version release should cover the vast majority of users for the life of their device, should they choose not to take "system upgrades" which may slow their device or change it in an unwanted manner.
I agree that DEVICES should be covered for n years, where n is somewhere between 3 and 5 and we can quibble about the specifics later. I don't think that backporting fixes should be the way we gauge this if newer versions are available instead.
The problem is that newer and better are not synonymous. And most Android users have probably learned by now that their devices getting slower with each update, not faster.
Here's the problem: It's a DROID Turbo. It's locked down by Verizon/Motorola, and neither root nor bootloader unlock has been achieved. So it's not even an option.
The problem is that the "upgrade path" and the "security fix" path need to be separate things. People should not be forced to have their device changed in an unacceptable manner (I did not buy a device with 'material design' for a reason, and being forced to get it to get a security fix is an unacceptable situation.)
I think, honestly, the only real answer is "don't buy locked devices if you want to make those choices." Google doesn't control those devices, and that part of Android is open source. You can make those decisions, but you're earning the consequences with them.
This, as it happens, is why I buy phones with unlockable bootloaders. My current phone uses the OEM build, but I like having that choice.
Google :does: control those devices. They're MADA agreement devices, which means Google approves every device that goes to sale, and Google approves every software update they release.
Unfortunately, as a Verizon customer, I don't have a wide variety of options with unlockable bootloaders. And the battery life on the Turbo was simply, the only feature that mattered. Usually there's an unlock within a few months, but there still isn't one at this point for the Turbo, I guess.
Obviously it wasn't the only feature that mattered, though? I mean, you're complaining about another feature right now. =) Like, I'm sympathetic, but this is a solvable problem with the information at hand. Buy phones with unlocked bootloaders. (As it happens, this is why I steer clear of Verizon...)
It's not just a providers. I've got a couple of el-cheapo $80 Androids just a month ago to use while traveling. They're running 4.4, Android 5 is not at all being offered for them, and probably never will. I guess I can throw them in the trash if I care about owning them myself.
Being el-cheapos, they aren't even supported by cyanogenmod. Anyone has an idea for how to use them (somewhat) securely?
You can check out the mx settings for the domain using one of the free online tools.
Except that people who are on regular GMail will probably use e-mail forwarding provided by their domain registrar. Especially since the free Google Apps for domains is gone.
Also the cusomised ad advertising is an option you can opt out of, so once again I'm not understanding the issue here beyond grabbing some headlines for mistakes that were avoidable on many levels.
As far as I understood from previous coverage and reading the privacy policy, the point is that e-mails are mined even if ads are turned of for the domain. The resulting profiles are then used for showing contextual advertisements in services that are not in Google Apps (e.g. Google search and Google+). Google's lawyers have also admitted that this is true. IANAL, but reading the privacy policy and the ToS for Business accounts, it seems to be the same there.
Of course, you can completely opt out of interest-based ads, both on Google services as on Google ads across the web. But I assume that profiles are still built, if not used.
A related problem is that persons sending e-mail to a GMail address (which could be hidden behind a non-gmail domain) never consented to the ToS and their e-mails are profiled. To which Google's reaction was: "all users of email must necessarily expect that their emails will be subject to automated processing." [1] IMO there is a difference between scanning e-mail for spam and viruses, and using the content to build a profile of the sender or receiver.
- Yes, initial payload size matters. But where's the true comparison about what each app is loading? How are the features and the UX? Would a power user be satisfied with Fastmail (e.g. search, filters, etc.)? (It looks nice, but none of this was discussed at all).
My experience with Fastmail's webmail (coming from GApps) is that it has all the features a power user needs, minus the annoying Google+ and Google Drive integration. Heck, it even uses GMail-style keyboard shortcuts.
The primary downside is that you lose labels (and get folders instead).
- Switching is never as simple as described, and forwarding is a fairly messy solution (and will only get messy as the author creates new login accounts and further forks his usage).
For me, the automatic IMAP migration in Fastmail just worked, ~21000 e-mails.
Why wouldn't you just use imap in an email client?
I agree, unfortunately, GMail has a non-standard IMAP implementation. As a result, it doesn't work well with Mail.app (while Fastmail's pristine IMAP does) and plugins such as MailTags.
https://www.reddit.com/r/MotoX/comments/3gugxa/anyone_got_th...