Kudos to Google for doing this but this could be even more effective if Google committed to say, 15 years of security updates or something along those lines.
A bit extreme but I empathize your position. I’m okay with the PalmOS phones from 2005 not working anymore. Their 2G/EDGE data doesn’t work and the Wi-Fi standard they used aren’t compatible with anything anymore either.
Not to mention they were incredibly slow and unwieldy even when they were new.
On the other hand, my desktop is from 2011 and it works fine and Linux happily supports it; 15 years isn't that impractical any more. As time goes on, the pace of change slows and longer life is reasonable; early Android devices may well have been genuinely obsolete inside a year, but current devices aren't even that slow after 4-5 years.
For current phones I think 5 years is a good support window, the batteries don't last much longer than that. But if replaceable batteries make a comeback (and I hope they do with the push from the EU), then I definitely agree that more like 10 years should be demanded as reasonable.
Especially for something like Android where if you compare a flagship from 5-7 years ago with a brand new Android Go phone the level of performance & feature set is not really that different. So it's not like the OS gets to actually start expecting things like a high end Vulkan capable GPU & neural net accelerators or anything. It still has to work with what is essentially old hardware anyway just in a brand new body.
I gave my tween kid a Galaxy S8 (released 2017) recently and it suites her needs fine. I'd prefer if I don't have to upgrade her phone for another 2-3 years.
I'm having trouble finding an Android Go phone released this year, the most recent I can find are from 2020, like the Nokia 1.3. Compared with the Galaxy S8, the Nokia has a lower rez camera, less RAM, lower quality build, lower quality display, lower spec SoC, no biometrics, and no fast charge. Perhaps there are higher spec'd Android Go phones, but at least a 3-year-gap is not enough to overcome the premium-vs-entry-phone tier difference.
Batteries and flash storage too wears off on modern day phones imo.
So anything beyond 5 years is asking for a lot on a typical smartphone where people share lots of memes and videos everyday.
I’ve had a shop replace the battery in my iPhone 6S three times, for ~$50 each time. The batteries aren’t user replaceable, but they are absolutely replaceable.
More accurately, the batteries are replaceable, it's just that Apple designed the phone and battery in such a way that replacing it for a regular consumer is too much. You can still replace it yourself, but then you can void your warranty.
I don't know if security support horizons are going to expand as CPU manufacturers clean up their hardware, but the rear view mirror is a support permutation nightmare.
Hasnt that been mitigated with firmware updates and OS patches?
I know I isntalled both specifically for Spectre mitigation and it slowed down certain things that I thankfully do not use much. My CPU and Mobo are from 2014
I... promise it does. I mean yeah, it can't run untrusted programs at the same speed as before, but it's still perfectly serviceable. And since it can run mainline Linux, it will continue to get those security mitigations with or without the manufacturer helping.
Spectre is a serious concern for virtualization hosts. For a single user desktop, if you're running hostile code that's going to carry out a spectre attack, you are already pwned, so spectre vulnerability is just frosting.
The desktop computer was a much more mature piece of tech by 2011.
If you were in 2011 you couldn’t really say the same about a desktop computer from 2000. You’d be comparing a 2/4/6/8 core 64-bit processor to a NetBurst Pentium 4.
I think it’s reasonable that relatively young phones aren’t usable at this point in time. But maybe in 2030 I might expect to be able to keep using a phone from 2020, assuming I’ve replaced the battery.
It depends what happens to the hardware when they offload it. I'm 100% on board with companies rotating their machines out every few years and selling them to the second-hand market (because that's how I get good hardware at great prices:D). So long as everyone just sells old stuff off, by the time a machine actually gets thrown out for good it can have had a decade+ of life across owners, and everyone along the way got it for cheap.
Few tech manufacturers support reuse in any meaningful way, and I seldom see it in practice. While I'm glad you've managed to include it in your own life, my comment was about the bigger picture. I think we can and should do a lot better as a society.
Consider what consumer technology might look like if products were designed with this sort of time horizon in the first place. I'd expect hardware to be more generally upgradeable/repairable extending its service life and at the very least I would not expect to see products assembled by drowning them in glue.
It feels to me like the generational difference in hardware products has been flattening out so 15 years may not be an outrageous practical service life, really.
I would be fine with Google dropping support, but they should at least let us run a mainline Linux kernel or something on them so that if people want to keep providing support after Google drops them we can.
That behavior is the only reason that 15+ year old machines can still run current Linux. There's at least someone out there interested in keeping them working.
This sounds extreme at first but if you had to support 15 years of security updates, how would you do it? What is the necessary human resources and structure to pull this off?
Aggressive upstreaming and commoditization, mostly. When you build a device, you build it out of existing components where possible, and where it isn't you write drivers and immediately push to get them pulled up to the upstream Linux tree. You ship devices that always run run mainline kernels and little-to-no divergence from AOSP, that share as much code as possible (hence reusing components -> reusing drivers), you maintain a single ROM image with only the smallest changes per-device that you can possibly manage. And you staff a team that can maintain your software, but since you're sharing everything across devices - and with other vendors, since your drivers are tiny compared to the whole kernel+AOSP - you can maintain dozens of devices with only a little more effort than one or two.
Oh, and I'd actually be on board with some sort of paid update program and/or crowdfunding after some point. Say 5 years of bug and security patches included in the price of the phone, and after that a small monthly fee that you use to keep up with the marginal cost of maintaining that device's unique drivers and code.
Abstract the hardware platform from the OS and applications. You know, like pretty much every operating system except linux on arm. Everyone complains about having to install drivers on windows, but having a driver ABI is largely how one can expect 10+ years of OS updates without any particular engineering work. The OS and applications get updated and as long as they maintain the driver API the graphics drivers, network drivers, etc all continue to work. Once in a while you have to go back and revisit this stuff, but drivers themselves are rarely sources of exploits because they exist below all the userspace interaction shielded by the kernel, and on the HW side tend to be little more than shims to forward data/packets/etc from the HW to the OS.
But that's the easy non-answer. Abstractions can't add features. Like Windows 11 dropped support for old hardware not because the right abstractions weren't in place, but because you can't add things like a TPM in software. It needs full stack support. Similarly if it turns out a device driver had a bug in its implementation of the interface, you're kinda stuck with that. And the workaround may or may not be reasonable to put up with, if a workaround exists at all.
One doesn't need new features to "support" and older platform. You simply assure that code paths have fall back logic to deal with missing GPU functionality/etc and as you mention emulate it. The fact that this has worked for decades on lots of other OS's is proof of this. Iphone6's don't have facial recognition cameras but you can still unlock your phone/etc.
Oh, and btw there are soft TPMs, which are the defaults on most new machines, and is probably part of the reason MS made it a requirement. But as others have shown by getting win11 to run without a TPM, it is entirely artificial, like when they decide not to ship IE/directX/whatever on an older OS. If a random hacker type can get it to work in a reasonable timeframe, there isn't really an excuse for MS not to just add the functionality with a little "your machine doesn't have a TPM so your not secure as you could be" notice somewhere.
That missing feature set bleeds into the developer experience and results in cries of "fragmentation." It's not "laziness" it has a real cost to 3p developers.
And no, your claims of "just emulate it" is not accurate, nor is that how any other OS works. If you're missing a GPU feature on your Linux system (or, more likely, if your driver is even if your hardware supports it) it's up to everything that uses the GPU to not hit that path. Nothing is emulating it or in any way pretending to have a feature it doesn't "natively" have.
Well of course, for somethings it becomes a least common denominator, but even for GPU's in the past the idea was that it was possible to use something like Mesa as the baseline and then accelerate the important/critical functionality in hardware. The original DX API was also designed like this. Its only once the market became basically a duopoly that the expectations shifted.
Frankly, having a solid software reference model/fallback path likely makes peoples jobs easier because its easier to track down bugs by doing a/b testing.
Oh, and BTW, you can likely boot your linux machine without your graphics card driver, and it will still be able to run your desktop/etc and simple openGL/etc applications like glxgears. How is that, because linux can and does fallback to software emulation, using... mesa.
No, that's not how that works. You can have an entirely software emulation or stub of a device, but that's not the same as more like a polyfill. Mesa will not emulate just the gap between your hardware and the latest feature set. You either get hardware with whatever it has, or only software emulated.
It's complete unacceptable for everyone if an os update suddenly means your GPU is entirely unused because it doesn't support some new extension or feature, so now you're stuck with only CPU emulation. That's not a viable solution.
"The Draw module provides point/line/polygon rendering services such as vertex transformation, polygon culling and clipping. It will be used by drivers for hardware which lacks vertex transformation (such as the i915/i945). It may also be instantiated and used directly by the state tracker to implement some API functionality that doesn't map well to hardware capabilities. "
And on and on... This doesn't mean that all the extensions exist for any piece of hardware, only that there is a pretty solid baseline. Its why I can run a gforce 7600 (which I was messing with a few days back) with a fairly recent rolling linux distro and it continues to work, and provide some level of acceleration.
That doesn't attempt to add for example compute shader support to GPUs that don't support it. Or FP16 support. Or geometry shaders. Or VBOs.
And for example from that Gallium page:
> The new driver interface will assume the presence of programmable vertex/fragment shaders and flexible memory objects.
It essentially was a hardware HAL rev, and did not attempt to support hardware that couldn't be updated to the new HAL.
Which is actually the Linux way for most all hardware. Either the driver stays up to date, or the hardware is abandoned and no longer supported. The push there is to upstream the driver so that the community can maintain it, but the end result is more or less the same. It either gets updated, or it's no longer supported. Linux has never had and actively rejects attempts to introduce any form of a driver API/ABI. In terms of policy then Linux basically provides 0 days of support for anything that isn't open source & upstreamed. Even 2 years would be an unfathomably long support window.
But even ignoring all that, GPUs are above average in flexibility for hardware drivers. Compare to something like a camera ISP. A huge complaint of fragmentation for app devs on Android is around the camera, because it turns out you just can't layer a lower level, more flexible API on top of a higher level, more restricted HAL. That's the Camera1 vs. Camera2 API mess on Android in a nutshell.
Well, i wasn't going to respond, because again IMHO your mostly wrong.
I suggest you look at llvmpipe (for shader emulation). Because abstractions can be extended both to higher level concepts as well as lower. The whole concept of shaders were bolted onto the GL specs.
The fact that a certain ecosystem is unable to extend their abstractions, as you mention with the camera situation, is less about abstractions and more about the mindset of that ecosystem. I'm fairly sure that I can design an API that provides much of what one gets with camera2 in a way that allows most apps to continue to behave like nothing changed, while allowing newer apps that need that functionality to request it of the existing API, while also maintaining ABI compatibility with older drivers, and allowing newer drivers to provide said extensions either via an extension mechanism, or alternatively a shim that layers the older API on top of a newer driver API (and therefor providing two driver ABIs one for older drivers and a newer one for newer drivers). The vulcan/GL situation is informative here. Having SW or HW that supports one or the other doesn't preclude the opposite.
And things like FP16, which are used mostly to provide higher perf/efficiency machine learning, already usually have some kind of abstraction in place to just use FP32 in places where FP16 isn't available.
The point being that the "success" of the android/arm disposable software/HW model shouldn't imply its not possible to build abstraction, and extend them.
The thing you're still stuck on is the idea that you can update the driver. That's the part that's frozen in time. Whatever abstraction/API you happened to use for it, that's what you're stuck with. You (often) can't then bolt on newer features onto that old driver without changing the driver.
The API that apps use, that's irrelevant. That's "trivially" kept stable. It's the API that hardware uses, and adding features to it retroactively that's extremely difficult if possible at all.
In the cases where it is possible to do layering, it's almost always in the reverse direction. Such as ANGLE implementing WebGL/GLES onto things more powerful & flexible than GLES is.
> And things like FP16, which are used mostly to provide higher perf/efficiency machine learning
I wasn't clear on this but I was referring to FP16 FBOs, which was something GLES 3 added that GLES 2 didn't have (instead of 8888 FBOs)
No, thats my point, its possible to shim say 3d sound into a driver/HW stack that doesn't support it via software. In the cases that you truly need a new HW feature, you assure the userspace API your providing to applications doesn't fail when that feature doesn't exist. AKA you don't make your entire software stack dependent on that feature, you provide fallbacks.
That way the old HW/driver that doesn't have the new feature continues to work.
AKA, like I said its a mindset, its hard to come up with a HW feature that has been invented in the last 40 years that is absolutely required to keep an OS/Application stack working. Sure your OS now has support for 3d headsets, that doesn't mean that it should fail to continue playing games when the user doesn't have that hardware, it just means they don't get that experience, or the games that only work in that environment aren't compatible.
Its not actually that hard, windows/linux on x86 prove that its possible to run newer OSs and frequently applications on old hardware, and in the case of windows frequently without upgrading drivers for decades because the underlying driver API/ABI is extended rather than replaced.
EX, there is hardly a game in place that requires the ray tracing features of the newer RTX/etc series GPUS, but there are plenty of games that support that feature at the same time they work without it.
> AKA, like I said its a mindset, its hard to come up with a HW feature that has been invented in the last 40 years that is absolutely required to keep an OS/Application stack working.
No no no, that's not the problem. The problem is that optional things are fragmentation, and that has a real impact to the application ecosystem.
Here's an extremely simple example (that also happened in the real world). Go back 20 years and make your camera driver abstraction layer. Let's say your API ends up being:
Image takePicture(bool useFlash)
Then a few years later suddenly flash light apps are all the rage, and someone realizes that hey the camera flash would make for a great LED light! So you update the API for apps to include:
void setFlashEnabled(bool enable)
But wait a sec, you can't possible implement that new API for apps on top of the old driver API! No amount of shimming can make it work. So now you have to also have:
so that the new application API can work on both old drivers that haven't updated and new drivers. Bam, fragmentation. Now you not only need to be on the latest OS release, but also on the latest driver stack. And not because of laziness or any other stupid bullshit excuses, but rather simple because of the inescapable fact that hardware abstractions remove flexibility and limit evolution, combined with that nobody can predict the future.
Of course it's "not hard" to make things optional - Android (and the web platform for that matter) are full of examples of that (this is in fact the adopted policy of Android's hardware abstraction layer with Treble - it's been something Android's been doing in practice for real for over 5 years now). The problem it it's fragmentation and is what Android (and web) devs constantly rant about vs. their iOS counterparts. Your argument is essentially that the answer to fragmentation is fragmentation. That's the part where I was saying far above that it's the easy non-answer. It doesn't address the actual complaint of fragmentation. It's something nobody has come up with a good solution to, but that doesn't make it an invalid complaint.
I've got a laptop from 2004 that still works fine. It has 1.5 GB of RAM and a spinning 60GB hard drive. It runs the latest Xubuntu, which is getting security updates.
Android should take a similar path. Mainline the kernel drivers, keep the minimum system requirements low (which you'll want to do anyway for 3rd world handsets), add developer modes to test apps with constrained RAM and throttled CPU, rank "eco-friendly" apps that have lower storage requirements higher on the play store.
As far as the human resources required, see Ubuntu or Redhat Enterprise, which manage to do ten year support cycles for servers. I think handsets could be easier if you keep upgrading the kernel and core components instead of only applying security updates to the existing software. If you can do that then there's no more security work than you would otherwise be doing, since your latest handsets would need those security updates too.
Cool it on the whole "everyone needs a new phone every couple of years" thing, maybe? That's not the solution in and of itself, but it'd sure help. Not only would there be fewer variables in the hardware you have to support, but you help reduce e-waste.
There's a big difference between 15 years and "couple of years", and on top of that, phones are particularly recyclable (and a good value to recycle, too! plenty of valuable metals in there).
My pixel 3 motherboard died suddenly last year. Unfortunately, I am too deep into google services/devices that I can't switch. But I don't think pixel phones are designed to last over 5 years. It's not matter of parts; they are just not designed for >5 years of use/abuse.
They've already pulled the plug on Pixel 3 security updates, so you wouldn't have wanted to keep using it anyway (without switching to LineageOS or similar at least).
They delivered three years of updates as promised and after that it's a security risk.
You know Google apps are available on iOS as well as other Android phone though, right?
I'm trying to imagine what I would have to be using my phone for such that I could not switch away from the Google brand of smartphones to an alternative.
I bought a pixel 4a last year, six months later, it stopped reading my sim. Got it replaced, but had to mail it to Google and was out of a phone for 10 days...
Probably should note that it gets updates outside of its normal product lifecycle in the same way Pixel phones get updates, from and by other vendors. It does not get firmware/bios updates, will not be microcode patched for spectre/meltdown. An unsupported Pixel phone will not get modem or sensor/wifi firmware updates after support gets dropped. Maybe it will not be a problem, maybe a problem like the sib24[1] issue from a year or so ago will be there.
> unsupported Pixel phone will not get modem or sensor/wifi firmware updates
That's a good point. The removal of 2g/3g made the modems in a lot of phones non-functional. Even without cell support a phone would still be useful as a small wifi tablet if it could run up-to-date software.
Yes, yes, BIOS is supported by third-party vendor. Still leaves the microcode problem.
>That's a good point. The removal of 2g/3g made the modems in a lot of phones non-functional. Even without cell support a phone would still be useful as a small wifi tablet if it could run up-to-date software.
That's not what I'm talking about. Some phones required a modem update to work around a bug caused by broadcasting a different LTE signalling message they couldn't handle. It would crash the phone's baseband. Similarly some security group like Google Project Zero could figure out vulnerabilities in the modem (maybe unprivileged code execution using specially crafted status messages or something of the like). This is the sort of thing you will not get updates for, and the updates you've received til now won't detail much because SoC vendors have all that shit under NDA.
The OS you've installed gets security updates, but you're not getting any security updates from any of the software provided by the manufacturer. You're usually lucky if any of the drivers/firmware on any PC laptop's support page get updated more than a few months after release.
PCs are the proof that manufacturers don’t have to push security updates for decades. But in the phone world, they would have to because they don’t want to open the platform. So the user is dependent on the manufacturer for updates. But it don’t have to be like that.
While the Linux answer is also accurate, ThinkPads in particular also have good coreboot/libreboot support such that much of the firmware can also be kept up to date.
Please go into detail, if you can. As the Linux kernel champions backwards compatibility it should not break userspace. And updates to userspace I imagine to be similar to Linux distros, just needing to update system/userspace libs and apps.
The only time I see problems, is when the system-level software requires new hardware features that older models do not have.
Are there any operating system vendors who support their releases for 15 years? I think RedHat is like 10 years? There is CIP that is longer term though.
So not launching anything after all. This, Samsung announcement (overpriced half a clamshell with integrated LCD for only two flagship models, no batteries at all) and Apple pathetic IRP (cant buy anything, only parts exchange 1:1, spying on your company books for a couple of years etc) is a sign manufacturers already see that Right to Repair legislation is coming no matter how much money they keep throwing at lobbyists, and are desperately trying to limit its scope by claiming they already offer everything advocates want (spare parts) while offering almost nothing (screens only at the price of fully working unit at a second hand market).
If I say "I am having a 50th birthday party" that means I'm talking about an event that's happening in the future. It doesn't mean I'm having it immediately. It's a statement that's in the "future perfect" tense. Besides, people would be very confused. I'm 45.
If Google say they are launching something, the same thing applies. It means they're launching it at some point. That doesn't have to be right now. They're using the future perfect tense.
Everything I'm seeing regarding future perfect tense seems to indicate both 'will' and 'have' are required.
Saying "I am having a 50th birthday party" is not talking about an event that's happening in the future. You can say that and be referring to a party which is presently happening.
Why not hold off the announcement until actual launch day? Big bang, lots of publicity, lots of sales.
I've got a Pixel 3a XL with a cracked screen. I'm coping with it cracked, but if I'd seen this announcement and was able to order, I probably would have ordered right now. As it is I just see "coming soon", and will probably forget about it by the time it's actually live.
What you say makes perfect sense from an engineering perspective. From a marketing and legal perspective, this is a feature to advertise for perspective buyers and ammunition for their anti-R2R lobbying so best to announce it as soon as possible.
The real reason I liked the pinephone so much was not the price tag, but the replacement parts [1]. I didn't go for the librem cause it's an overexpensive bet with no sight of any repair parts.
Before that I only bought android phones where I knew that I can find either scrapped parts or replacement parts on ebay.
The pessimist in me is inclined to believe that this is just another empty gesture to ward off the specter of right-to-repair legislation that's looming over tech giants. Louis Rossmann made a grate video about why these programs are almost useless (samsung) to downright harmful (apple).
I think the only reason Google and their friends are doing this is to remain in control (how, when, if). They don't want to end up like the car industry.
I read it the exact opposite way. Google sees the writing on the wall that this is coming sooner rather than later to the US so with a “bit” more work they can have their common components of the phone be manufactured as OEM parts essentially & provide that direct line to iFixIt.
They give great pricing to iFixIt and there you go, the margin they may lose on the phones through this is off-set to an extent via the common parts they’re now supplying.
They also know if they don’t provide the parts, which is to say they need to produce the top 5-10 components in a single fashion instead of an assembly line, someone else will so they seem to be getting ahead of the game.
They are actually modeling the car industry because folks are insanely specific about wanting OEM parts to the extent you have to specify in many contracts you can use OEM or equal quality 3rd party parts.
There are even some warranties (which cost more) that specify they will only use OEM parts so Google probably also sees they can charge a premium for “OEM” similar to the auto industry.
I watch Louis regularly and this seems different from what Samsung and Apple are doing, in a good way. First of all it seems to include more parts - they’ve mentioned batteries, camera modules, etc. Second - they provide it to a range of devices, starting with Pixel 2 so that’s great. And third - they are also providing software for calibrating the fingerprint reader after replacing it. Seems like a pretty good start to me.
Of course we need to be skeptical of programs that are just designed to look like they promote repair while being useless. But we also should give credit where credits is due.
This looks like a PR stunt for the Right to Repair. Google phones are very difficult to fix and they break easily when fixing. Screens and parts easily break when open. I have failed twice with Pixel phones and the cost to replace those are quite expensive.
iPhones on the other hand are easier to open and replace parts even though Apple mostly doesn't allow 3rd party parts.
This is simply silicon valley companies trying to get a foothold in the "right to repair" market - they want to dominate and control what is good intentions by society to extend the lives of older devices.
Of course Google wants to get their grubby hands in the pie by getting these systems/programs in place so they can tell legislators "See, you don't need to have that pesky right to repair stuff, we supply the parts for the users!" - while completely ignoring the actual reasons and benefits of RtR. I hope we don't see Google pulling an Apple and using the US government as an enforcement arm to make sure "bootleg" screens don't make it into the hands of people trying to save a buck in this economy.
Don't mistake this as a sign of altruism by Google: they can see that the Right To Repair movement is getting stronger, more organized, more funded, and is hiring legislative consultants to draft, submit, and pass legislation. While the main thrust for now is the right to repair agricultural tractors and cars, as this gains momentum it will eventually apply to iPhones and MacBook Pros as well. Google is just getting ahead of what is coming -- and trying to flex for PR points as well, because why not?
Definitely not altruistic. The Pixel phone was always a defensive position, not Google's profit center.
From the position of Apple, the Google Pixel was always a poison in the profit pool so that the monopoly would be held in a different part of the value chain (the Search versus the Hardware). In this regard, Apple's loss is the consumers' gain.
By making the Pixel really repairable and parts exchangeable, the Pixel can be shown as a shining beacon of right-to-repair. Techies will applaud how great it is, and have an object to contrast the iPhone with.
However, if the iPhone is forced to go the same path via right-to-repair laws (or due to consumer sentiment), their profits will be a lot lower. People won't need to replace iPhones as much. They couldn't price discriminate using different size SSD drives as much, etc.
And that's the whole game to Google -- again to reduce the hardware part of the profit chain, and to increase the search part of the profit chain. It's basic MBA stuff / Michael Porter's 5 Forces.
> right-to-repair laws [snip] their profits will be a lot lower. People won't need to replace iPhones as much.
I suspect Apple could tweak other factors to adjust e.g. software lifetime more like Google, or changing styles more frequently. Also it really depends on the cost of parts — especially the screen: if a screen is truely expensive then consumers will prefer to upgrade than fix. I have usually had to replace my Android phones due to breaking the screen (also USB connectors - fucking unreliable things).
What % of Apple's revenue is on phone repair?
How less frequent would people upgrade their phones?
This is about Steve Job's obsessive need to control everything and no-one at Apple wants to challenge a dead prophet.
Google of 2022 is run by more MBA's than ever... Everything is now a profit center. They don't do anything big 'just because it's cool/useful/good for society'.
> They don't do anything big 'just because it's cool/useful/good for society'
Their published AI research over past 10 years has been hugely beneficial to the field and society. While true they probably wouldn't be spending so much on this R&D (100B last 5 years, 31B last year) if they didn't expect a future profit, it's hard to deny the value of the research.
Every time a company does something perceived as good, there is always some commenter reminding people that it's not altruism. Similarly, every time someone posts a link to a postmortem from a large tech company, there are always some commenters who say that it's being done for PR reasons. So what?
Just be happy companies are doing things you want. Don't expect it to be done for altruistic reasons on top of that. It's unreasonable to expect a business to do things for non-business reasons.
Market demand and/or legislation are the main reasons changes like this happen, and that's the way market economies are supposed to work, and that's fine.
