If Google had designed (? or something?) Android so that updating the base OS was something that could be pushed direct from Google instead of from each manufacturer's bollixed version of the system, there'd be no problem for any of us.
That may seem obvious now, but it's far from clear that Android would have succeeded the way it has if OEMs hadn't been allowed to differentiate their versions. That was (and is) something that's important to them, and they may well have decided that they wanted to do their own thing instead if Google hadn't given them the degree of control they wanted. Or maybe they'd have adopted Windows, since while it wouldn't allow them to customize it would have had the advantage of being from the then-biggest OS maker around.
It seems very likely that the ability of OEMs to customize was a core component of what made the Android ecosystem successful.
Also, keep in mind that the only way Google could really have kept OEMs from modifying Android however they like would have been to keep it closed. Personally, I'm glad that Google made the choices it did, not because I'm a Google employee working on Android (though I am), but because I've been an open source and free software advocate since before Google even existed. Android is far from perfect, and devices aren't as open as I would like, but I think the mobile software world is much better than it would have been without a F/LOSS mobile OS.
I still think that two years of updates is outrageous forced obsolescence that is prematurely adding electronic garbage to landfills.
FWIW, it's actually two years of upgrades and three years of security updates on Nexus devices.
I'm seriously considering going back to an iPhone on my next phone upgrade, despite all the concerns I have about them too. They at least support their hardware for around 5 years.
At least they have done so in the past. Note that they've never made any commitment to that, so they could stop.
Unless you bought a device with an unlockable bootloader, any way that you can get root is a bug, not a feature. It may useful to you, but it would be equally useful to an attacker.
From my experience, every update removes useful power user features.
It may be abuse, it may be a stupid patent, but it's not patent trolling. The point is that is a specific form of nastiness that describes company with literally *no* product but a patent portfolio and only makes money through litigation.
The point being a 'patent troll' is defined as some entity holding patents, but not actually *making* anything. Bad for both being a leech, but also challenging as the potential to fight back to pursue cross-licensing is impossible since the attack doesn't do anything.
Now if you think the patents are stupid and not worthy of being patent, that's something else and I'm particularly inclined to agree about the VFAT patent. But 'patent troll' is a specific phenomenon, and Microsoft is not (yet) in that role.
The central banks of the world are conjuring money out of thin air and using it to buy stocks
Cite? I'm not aware of any central bank buying stocks. The "quantitative easing" they're doing -- AFAIK -- is all bond purchasing, which means they're not buying ownership in real businesses, they're lending money to real businesses.
Concurrently, interest rates are artificially low
That's debatable. Without the actions of the central banks, we would likely be in a deflationary cycle. Assuming interest rates naturally adjusted accordingly, they should go very low, or even negative. Some of the central banks have gone to slightly negative interest rates, but they won't go nearly as negative as would naturally occur in a deflationary cycle. Instead, they're pumping money into the economy (via QE) to avoid deflation.
You are confusing contributing with leading the project.
Determining what code is written, what new features are developed, is leading the project. Not merging the contributions after ensuring the code is well written.
Linus leads from behind. After a feature is developed, he decides whether it will be allowed into the kernel. It's the same sort of decisionmaking process as in most development workflows, it just front-ends most of the work.
In most development processes, someone will decide "the product should do X", and they'll make some slides and pitch the ideas and the leaders will decide whether or not to pursue it. If they decide to pursue it then the developers will build it, debug it, test it, etc. The process is optimized around conserving a scarce resource, developer time.
In the Linux process, someone decides "Linux should do X", and so they build it, write all the code, debug it, test it... and then they'll send it to Linus, who decides whether or not to merge it. Same process, the difference is that the leader decides on the basis of fully-implemented code, rather than slideware. In the Linux model, developer time is not scarce and the process does not optimize for conserving it.
I don't know and there's no point in baseless speculation. I would guess it would be something like a security chip in the Nexus 5 isn't compatible with the new secure boot mechanism, but again, I have no idea.
No, it's nothing like that. There are some security-related features that are improved on the new devices, but those in and of themselves wouldn't block upgrades.
It's actually pretty simple. Google has committed to supporting devices for three years, and the Nexus 5 is more than three years old. If you really want to run Nougat on a Nexus 5, though, you can do it. Just unlock the bootloader and flash it yourself.
Though one of the chiefly cited daemons (pulseaudio) is in the same ballpark with the same set of developers available to work it.
The problem with your logic is that at some point pulseaudio and the like could in turn decides it wants to declare itself as 'really wanting to persist' using the systemd mechanism, and again be running stray. Then systemd could add yet another layer of 'really *really* mean to persist. It's an arms race of crappy software. The question is 'why does the daemon *think* it needs to persist?' not 'how can we invent a way to ignore their request to persist and hope they don't update to the new scheme'.
The point being that it's what systemd upstream decided would be a good default behavior. This speaks to the mindset of the architects and how it factors to their general design.
Yes when they offer choices, distros can opt out. However they are inventing new paradigms where existing ones already serve.
I think there is a lot of room for improvement for reasonable defaults and auto-sensing correct behavior.
However I take issue with the 'highly intuitive graphical interface for changing the way it works' *always* being available. The GUI should really focus on the most frequently fiddled with things. In Microsoft, you can very rapidly need to drop to do things via powershell commandlets or registry edits to modify some hopelessly obscure thing. Similar in OSX. It's a rare circumstance and frankly the ability for a user to 'intuitively' figure out such an action is needed is just beyond reach.
GUIs that try to encompass *everything* are confused messes. Some KDE dialogs are dizzying, and they still aren't all encompassing. So be very careful suggesting that everything should have an intuitive GUI, because that really isn't the case for any general purpose platform (mobile OSes come closest, but mostly by virtue of not being at all configurable).
Well the point is the humble beginnings were Linus sharing a hobbyist project without much ambition. At the time, GNU was a big effort to produce a full Unix system, but licensed under GPL. Proceeding very carefully/slowly for things. Making sure they had the right plan in mind before going and executing to that plan pretty thoroughly. This worked fine for a lot of the system, but kernel wise there was a big gap.
So along comes Torvalds, with an appropriate amount of uncertainty, sharing his quick and dirty stab at a kernel. Ultimately his more pragmatic approach would lead to a usable system long before GNU could deliver one. As such despite not originally seen as a 'serious' attempt, n practice it is the backbone of a great deal of professional work, as well as the target of a lot of code developed professionally.
what benefit will that give when most of the energy is consumed for the display?
That depends on your usage model, and on your display settings (most importantly, how long the screen stays on when you're not using it).
For most people the display is the biggest single consumer of power, but the combined radios (cellular & Wifi) are almost as big, and radio + CPU power consumption is considerably larger than display consumption. Doze mode conserves radio and CPU power, and for most people does provide a big increase in battery life.
This isn't the case if, for example, you spend a lot of time playing (CPU-light) games or reading books or other uses that keep the screen on for hours but don't use a lot of CPU or data. In that case, Doze mode won't do you much good because you're keeping the screen turned on all the time.
you'd still only see a 25% battery time increase at best.
A 25% increase is huge. The way batteries are sized in phones, most users get around 12 hours or so. Say, 6AM to 6PM. If you increase that by 25% you now get 15 hours which is very close to a full day. Make it 30% and you have a device that only needs to charge while the user is sleeping, in most cases. Given that most smartphone users have already arranged to plug their phones in at various points in the day (while commuting, etc.), even a 20% increase in many cases is enough so users find that their phone always has plenty of battery.
This restaurant was advertising breakfast any time. So I ordered french toast in the renaissance. - Steven Wright, comedian