I don't see why Android or iOS couldn't enable location based DnD at certain locations. Of course make it optional, but they already have your location and know that the place you are at is an Opera house, theater, etc...
So, Android formerly offered geofenced "Rules" for DND, and even flexible "Modes". You could set a location, or a WiFi network, and a radius slider to set the distance from that location or network. But the geolocation features have been removed. The Modes functionality is still available, but you're only allowed to configure time-based schedules or calendar events for triggering them.
Just before they were removed, I decided to eliminate all of my Rules and Modes entirely, because they were turning out to be extremely unreliable, and there was a bug whereby the Pixel went back into DND mode after a restart, even when it had already been moved outside of the location. It was also quite unpredictable how any Mode would behave, when there were all kinds of settings for each one, and it was just too much to set up and keep track of.
Today, DND is even more onerous. In the Clock app's Alarms tab, if DND is enabled, the app prevents me from editing or deleting or modifying, in any way, the alarms as they are set. This is terrible. You see, Google really, really wants us to disable DND and keep it off forever. DND is very bad for Android. So they are making it as inconvenient as all-get-out to leave DND enabled. If it were up to me, I'd leave it defaulted to "on" until I wanted to be disturbed.
My experience with DnD has been that it pretty much just works how I want it to. DnD from 10 PM to 8 AM, only certain people can reach me via call or text, alarms break through it. Never had any buggy behior setting, editing, or deleting alarms.
No thanks. "I tried to reach you yesterday". "Oh sorry, I happened to walk by an opera house." PLEASE, less, not more automatisms. Everything has a tendency to produce false positives.
> "Oh sorry, I happened to walk by an opera house."
It would be unfortunate for them to phone you precisely in the small period where DND was turned on as you walked past the opera house (even a large one would be, what, under two minutes of walking?) and not try you again.
(Because if you have instant location-based DND, yes, it might turn on as you walk by an opera house but equally it would turn off when you were past the opera house. Normally, though, I'd expect location-based DND to only kick in after a certain period of time in the same location - say 10 minutes.)
Sure, the coffee shop might be a problem (since I'm guessing that'd be more than 10 minutes.) You could always turn it off (and a smart system wouldn't turn it back on 10 minutes later unless you leave and come back.)
Apple and Google know the geolocation of every WiFi network in the US at this point. They could use signal strength as an additional measure if GPS is not accurate enough (though I'm pretty sure it is).
SerpAPI is comically good at evading Google's scraping protections. If what you want to know is, precisely, what someone searching Google in Pakistan would see, this is the API for you.
It's a little more involved than just having proxies in Pakistan. I'm quite sure Google has some protections against bots and scraping and SerpAPI's team unfailingly seems to work around those restrictions.
They are comically good at scraping a lot of things on the internet (ie. LinkedIn profiles), they have a scraping service you can setup, literally, just point it at a url. I am talking about Brightdata.
If you've used source based distros, you've noticed certain problems over the years. Upgrading compilers or runtimes can bring up problems that need to be fixed (maybe by recompilation or dev work). Upgrading libraries with circular dependencies is more painful.
After a while, you just want things to be more modular, have well behaved dependencies and release practices that just work to isolate any failures. Overall, Gentoo has done very well improving in this regard.
Chrome and Android are large enough projects with enough resources that they can brute force through these issues which is harder for a small distro to do.
I've tried pawpaws and really liked them, if you had given me the flesh in bowl and told me it was custard I wouldn't have been able to say otherwise. It also seems to be quite nutritious[1] with fiber and vitamin c. Honestly, I could do with less passion fruits and more pawpaws at my local market.
Only if you find a way to create revenue beyond the time-of-purchase, to offset the cost of development and maintenance, aka service revenue.
So far only Apple achieved this by ensuring a walled garden around their ecosystem, securing additional revenue-share for every single 3rd party app and every transaction of the user.
All other vendors are structurally prevented to properly compete in services, and have to rely on Google paying some minor revenue-share on Services, while having only limited control over the user-experience to distinguish themselves...
This would be a bit convincing if there weren't other hardware and services providers like Fairphone, GrapheneOS and Google themselves, who do support and maintenance for longer.
The fact that you put "Google themselves" in this list makes the conversation moot, because Google is de-facto the service-revenue recipient of the entire Android device-ecosystem and the culprit of the problem.
1. Fairphone actually demonstrates that it's not a matter of "want" for sustainable/repairable/longevity, the market still doesn't reward sufficiently for it.
--> If the total potential is an increase in sales of 100k units at ~450 USD/device, there is no fiscal justification for a stock-trading company to actually build such a product. That's why e.g. the EU keeps mandating more and more of this, they "artificially" create the need for it because the market doesn't do it itself.
2. They don't have a comparable service revenue-ecosystem to Google, not even remotely.
Even in sum across their entire mobile ecosystem, the majority of service-revenue their products generate is actually Google's service revenue of the Android ecosystem, of which they get a miniscule revenue-share via Google's RSA program.
The only substantial revenue is still generated at the hardware time-of-sale only, which needs to finance the lifecycle maintenance of the product. So the objective becomes to sell a critical-mass of hardware to sustain the maintenance of the device.
And then, the next level: The market-pressure for in-time software-maintenance can only be fulfilled by not deviating too much from Google's baseline (minimizing the effort of upgrading to newer Android versions). Not deviating from Google's baseline means either contributing back any disruptive changes to Google for integration in the baseline or (more likely) to not disrupt the smartphone landscape on platform-level at all.
Disrupting with hardware innovation only works either on very-large scale or on small-scale, because either you can contract a component supplier for a huge volume of a component exclusive for you, or you pick a innovative component which cannot be supplied in huge quantity yet (and is therefore out of reach for larger brands)
As result, the established players on the smartphone market don't make any more innovative leaps, because the risk/benefit ratio for the ROI is just not there.
--> Vendors ship devices based on common hardware available at that time, combined with software available at that time.
Chinese vendors changed the game a bit by announcing devices with innovative hardware which then never reached the global market, because the components were not available at-scale yet (under-display camera, wrap-around displays, new battery composition, 5G,...) --> This was a game-changer because e.g. Samsung, Apple, Motorola, LG would not announce a device they knew they can't launch at-scale. Oppo, Xiaomi et al could do a limited run for a device-launch in China, with chinese component-suppliers shipping to assembly-factories in China with low ramp-up costs.
Fairphone is on their 6th generation now, and in the US on Amazon. Easy repairability is as much an engineering feat as adding a button or light bar. Their support window is as long as anyone else. I'll even mention Essential who did day-one updates for monthly android patches, and that was a startup.
Longer support windows are possible and would mean people wouldn't be left behind without updates for problems like this.
If bigger, better models aren't also leading to better safety, something is broken. Models seem to no longer argue with people, or output verbatim text, maybe the next step is cheating less.
I've learned to be wary of these cars in the bay area, they seem to cut it close often, and they get stuck because they're not L5. I hope municipalities know what they're getting.
reply