Yeah, doing it with OpenWRT and PBR is definately much simpler than this approach. However by using hard-coded IP addresses you are at risk of breakage if they change in the future.
Also fastly-hosted services are a bit awkard to configure IP ranges to cover whole blocks as they seem to not use normal CIDR-blocks for different customers.
But you use PBR's ntfset functionality to have your dns server automatically update a set whenever an DNS entry is resolved, then set the policy rules based on the set.
Anything with the MT7986B chipset is a good choice, they support Wifi6, have a 2.5G ethernet port, have decent amounts of RAM/flash and mostl importantly have a fast enough CPU to do high speed WAN to LAN routing and firewalling.
Not only that, since 2019 Google have required apps published on play store to have 64bit variants, this should not be a problem.
However I suspect that the Xiaomi has to contend with the Chinese app ecosystem which may not be as strictly controlled, so probably has a decent number of legacy 32bit apps floating about.
Software support is another big one. My 6.5 year old smartphone is still strong on battery, but it stopped receiving updates long ago. At some point, some stuff I needed would not work anymore. Fortunately I found a version of LineageOS for it, but it was a lucky accident - the vast majority of phones become waste at that point.
I really hope vendors get forced to open up their hardware for the user to install their own OS once they stop supporting a device with updates.
Why is this still so difficult? Android and Apple have moved a lot of apps out of the system image into the app store so they could be updated more easily.
I know the hardware on Android is fragmented but by now we should be able to handle this? PC are way more fragmented. Maybe drivers need to be open sourced?
Is it just too much competitive interest?
What manufacturer would want a phone that last more than 3 years when there is no downside and a possibility of someone buying another phone.
The only scenario where I see this change is by a law or phones become something you no longer own but rent. Then it would be in the interest of the manufacturer to keep the costs as low as possible and try to make you keep the same phone as long as possible.
Non-replaceable battery has got to be one of the most profitable examples of planned obsolescence. Your average consumer is going to notice that their phone is lagging more frequently and attribute that to their phone being old… when in reality it’s just that their battery has degraded [1]. So, what could’ve been a <$100 replacement becomes a $1000 upgrade.
Even in the age of easily swappable batteries I don't think many people actually did swap them. I had a Samsung S5 and when the battery started to go, I walked up to the samsung store for a new battery, and they told me they didn't sell them and I'd have to go online to get one.
As well as the fact that back then phones progressed much faster so by the time your battery gave out, the new phone was much much better.
Agreed. Back then switching to a new phone was justifiable since there would be a noticeable quality of life improvement between a couple generations. Now, I think we’ve reached that point where the new phone is not significantly better. Or at least, not worth the extra cost compared to a battery replacement.
Easily swappable batteries would be a big value add now for a lot of people.
Roughly, as you type the omnibox has various heuristics to prevent the order of results shuffling when you type each letter. In this case the search result for "sentry.i" has its position preserved instead of the intended "url-what-you-typed" taking priority over search.
No conspiracy needed here, just over complicated design that comes from trying to munge two different functionalities into one UI element.
I feel the exact opposite. I've recently been experimenting with ipv6 only via NAT64/DNS64 and run into the same problem (with steam trying to connect out to hard-coded ipv4 addresses).
I started to look into CLAT and really didn't want to have to go through the hassle of a whole new virtual interface with routes etc, when one single app can't just pass a couple different args to connect().
I actually had thought about trying to write something exactly like this myself.
Also fastly-hosted services are a bit awkard to configure IP ranges to cover whole blocks as they seem to not use normal CIDR-blocks for different customers.
But you use PBR's ntfset functionality to have your dns server automatically update a set whenever an DNS entry is resolved, then set the policy rules based on the set.