A lot of people on reddit seemed to ignore the part where it was clearly stated the activation was done by mistake and corrected.
Google activated battery saving mode on multiple phones, then rolled it back
151–160 of 202 posts
Re: Google activated battery saving mode on multiple phones, then rolled it back
#152I'm taken aback by how many, even in this tech forum, seem surprised to learn that automatic os updates means settings can be updated automatically. Bugs are bad and all but I don't understand the "how could Google do this?!" questions. Am I missing something?
This happens in ubuntu linux actually. Every now and then, an update changes my configuration of systemd without asking.
That is a combination of different problems. Updates are hard in general, to which there aren't too many mainstream solutions. Emerging ones seem to be in nixos, rpmostree etc. However, ubuntu/debian has a more pedestrian problem, which is that they do a bunch of junk in the post install scripts (like automatically starting and enabling the systemd service for the package). Systemd being a fragile flake will break. That's not the worst that can happen. More likely is that some poor sap will pull in some random server (mail server, database server, http server etc.) as a dependency, and it will get enabled. And ubuntu in their wisdom, don't enable the firewall in desktop variants. So you may be running an open server unknowingly.
Re: Google activated battery saving mode on multiple phones, then rolled it back
#153Earlier quoted context omitted.
But your bank probably has a web portal right? You could have used that, probably. I actually did that alot from my phone actually.
Yes, but it is slower, and doesn't allow me to make small payments without the security token. Also, even checking the balance requires the security token with the web portal. Further, I'm sure that many banks don't have their web portal optimized for phone screens (because on a phone you are supposed to use their app). But yes, it's a matter of convenience mostly.
Once upon a time, your bank probably didn't have an app either -- that isn't a strike against mobile platforms. In that same vein, having a bad web portal isn't a strike against the web as a platform, it just means your bank isn't taking full advantage (yet).
The only strike against FFOS as a platform that you mentioned was speed, and I acknowledge that web-based apps do render slower than native ones 99% of the time. The parser/execution system that handles HTML/CSS/JS is almost guaranteed to be slower than one that can handle a more limited subset (there's just less to do).
That said, speed seems like a red herring though -- just how fast do you need your banking application to be? Is the half-second you had to wait longer to see your balance really the mission-critical feature? I get that rendering speed is important, but there are lots of bloated native apps that don't render as fast as possible either.
Re: Google activated battery saving mode on multiple phones, then rolled it back
#154Earlier quoted context omitted.
It's your phone, and you voluntarily allowed Google to control it. I didn't want Google to control my phone, so I installed LineageOS.
I'm also a happy LineageOS user, but it's not like they don't have a track record of this kind of thing either: https://www.androidpolice.com/2018/04/05/dont-freak-lineageo...
1. Wasn't remotely initiated.
2. Was announced beforehand, not snuck in.
3. Is open-source.
Re: Google activated battery saving mode on multiple phones, then rolled it back
#155Earlier quoted context omitted.
There's a difference between fast-software updates and turning on/off certain features without the user's consent.
> turning on/off certain features without the user's consent. I think that in practice, that applies to only the privacy sensitive features. Would you be upset if suddenly they rolled out a feature that reduced battery consumption by 10%? This particular case was obviously a bug, but I suppose every software manufacturer is continuously doing A/B testing, and 99% of time the user would not even notice. I would be sur…
> I would be surprised if Google was not doing A/B testing
On live (not beta), unsuspecting users, without their consent?
Re: Google activated battery saving mode on multiple phones, then rolled it back
#156Earlier quoted context omitted.
This happens in ubuntu linux actually. Every now and then, an update changes my configuration of systemd without asking.
That is a combination of different problems. Updates are hard in general, to which there aren't too many mainstream solutions. Emerging ones seem to be in nixos, rpmostree etc. However, ubuntu/debian has a more pedestrian problem, which is that they do a bunch of junk in the post install scripts (like automatically starting and enabling the systemd service for the package). Systemd being a fragile flake will break. T…
I have had some files deleted due to this, to my despair
My whole /tmp/ directory was silently deleted by some "cleanup" systemd shit, hours after an update that changed my configuration.
Re: Google activated battery saving mode on multiple phones, then rolled it back
#157We need more transparency from companies, this time it was a 'bug' that was visible to the end user (hey! who turned on power saving?). Would Google go public if they also develop a 'bug' that is not visible easily by the user or if it was not discovered by anybody but them? Like a 'bug' that changes certs temporarily to intercept your encrypted traffic or uploads random data elsewhere, etc?
> We need more transparency from companies Yes. Best way to achieve it is to get Linux running on smartphones, finally, so we can manage our own updates. (By the way, I'm not looking forward to an era of selfdriving cars which are updated remotely behind the back of the user.)
The self-driving thing is unavoidable. You won't get regulatory approval for any car that has an unlockable bootloader.
Re: Google activated battery saving mode on multiple phones, then rolled it back
#158Earlier quoted context omitted.
Which is hilariously dumb because now 3rd party retailers are the go to source if you want to buy a Xiaomi with unlocked bootloader rather than waiting a month . It's creating more business for the people they are supposedly trying to stop. Also none of the stock Android phones they sell have a wait time for bootloader unlocking, it's only the ones with their own os MIUI
Xiaomi doesn't give a shit about the bootloader itself. What it cares about, is people receiving a modified version of MIUI which it has no control over: "The retailers would buy Xiaomi devices in bulk, unlock the bootloader, change the software themselves or flash a custom ROM like Xiaomi.eu (unofficial ROMs based on MIUI China but with more languages and features), and then sell the device. Most consumers would hav…
>Most consumers would have no way of knowing they’re running unofficial/modified software
It's right there on the boot screen. They can make it more explicit if they want with a red skull or whatever. That reason doesn't fly. Also, what changes in 30 days ?
Re: Google activated battery saving mode on multiple phones, then rolled it back
#159We need more transparency from companies, this time it was a 'bug' that was visible to the end user (hey! who turned on power saving?). Would Google go public if they also develop a 'bug' that is not visible easily by the user or if it was not discovered by anybody but them? Like a 'bug' that changes certs temporarily to intercept your encrypted traffic or uploads random data elsewhere, etc?
> We need more transparency from companies Yes. Best way to achieve it is to get Linux running on smartphones, finally, so we can manage our own updates. (By the way, I'm not looking forward to an era of selfdriving cars which are updated remotely behind the back of the user.)
You don't need Linux for that, AOSP would do the thing.
Re: Google activated battery saving mode on multiple phones, then rolled it back
#160A plug for something that you may find useful: https://github.com/dan-v/rattlesnakeos-stack
Backstory: It was created after the death of copperheadOS to fill in the gap. It builds stock AOSP (without any google play blobs), and signs it with your own keys for verified boot. This project is still pretty new, and has some limitations. It builds on aws, whereas I would like to do local builds. Still, a pretty neat and useful project.