• 0 Posts
  • 335 Comments
Joined 2 years ago
cake
Cake day: June 21st, 2023

help-circle


  • Awesome, so pointless manifest revisions to manipulate store reviews and falsify user engagement will update even faster? (Which are most “Bug fixes and quality improvements!” updates these days.)

    Really can’t wait for this terrible “app” update concept to go away. The market manipulation aspect drove shipping shittier code out the gate and generalized FOMO.

    Or better, apps can go away entirely, lets go back to everything lives in the browser, it’s generally safer, and most “apps” are just browser containers that only exist to harvest device telemetry.


  • Google could, and probably would become more malicious on deprecating and obsoleting old hardware, but that’d be a huge revenue loss for them. They tend to actively support the app layer on older Android OS versions (here’s an arbitrary breakdown from some web search: https://composables.com/android-distribution-chart ) for a very long time, as older Android is used in many embedded devices, inexpensive devices, purpose-built devices, and other places.

    Keeping the Play Services and Play Store up to date on older phones means they can continue a metadata-gathering and app-sale revenue stream on older phones for many years after they “age out”.

    Couple that with the fact that most “reasonable” vendors now try to support 3, 5, or more years on a piece of hardware, you should at least be able to get almost half a decade out of a phone before it no longer receives primary OS updates, and likely then another 5 or so years until they stop updating for that API level.

    The ELI5-ish version of it is Android is composed of a few layers. The stuff that makes the hardware work, the stuff that makes the OS work (drawing on screen, install/remove programs, texting, calls), and the stuff that makes the software (apps, etc.) work. The part they stop updating is the stuff that makes the hardware work, and the stuff that makes the OS work. However, it’s already working, soo… Over the years, Google spent a lot of time migrating as much of Android as they could so that the apps, some bits of OS, and other things like app security could be updated even on very old versions of Android. You could turn on a phone from 2015 like the BlackBerry Priv right now, and install current apps and most things would run without issue.

    Yes, there could be a slight risk that some malware comes out targeting older phones with older OSes and older hardware support, but that’s generally a smaller audience than targeting the latest and greatest phones that are way more “popular” - so not really worth it to malware peeps. The hack targets would most frequently be at the app layer to cast as wide a net as possible. Since Google continues updating Play Services and the Play Store software at the app layer, this would mostly keep people safe from the majority of attack vectors. The diversity of phone hardware really helps here.

    Mostly though, mobile marketing just tries as hard as they can to create FOMO that you might be missing out on something by using an older phone.








  • Changing your workflow is work, but those apps, and Paypal, Stripe, Plaid, and bank account linking services all really exist to harvest all your personal transaction data under the guise of making your life “easier”. There are banking regulations governing (somewhat) how older style payment methods can be tracked. These apps circumvent those regs. Those services are best used with throwaway money accounts not bound to your normal accounts, and at the end of a very long pole, but mostly not at all.

    However, even credit card companies like MasterCard and American Express are in on it as well, further limiting options. AmEx is an interesting one, as they marketed themselves as a more premium card, housing most services in-house, and keeping transaction data in-house…only to turn around and profit off of it just the same.

    Might as well go back to cash and paper checks at this point. Although a realistic lesser perspective is just to minimize which of these services one uses, and be sure that when paying on a web site to not check the “remember you for next time” checkbox that gathers further information to cross-link your purchases. Can’t block it all, but starve them of what one can.




  • The problem comes in so many directions in real life though. Say your company has a very large database. Replicating it across regions means you’re paying for data ingress/egress and more than one region’s copy of that already sharded and/or duplicated database. It even applies when transferring data across AZs in a given region. Backing it up to S3 is expensive, backing it up to Glacier is cheaper, until you ever have to do a restore, and then you have to lay off half the staff to pay for it.

    Other issues can arise, possibly through the fault of yourself, sometimes at the fault of Amazon, if data traffic routing has a glitch and data is routing to the wrong place. The onus either way is on your company to show Amazon the receipts if you expect to get credits for the overage. At larger scale, this could be hundreds of thousands of dollars in overage. Easy to torpedo smaller companies with one mistake.

    They didn’t used to nickel and dime as hard as they do now, which doesn’t help, but outside of history, they set up AWS to be the biggest slippery slope of wallet-deletion, as almost every move you make costs money. Entire companies exist to manage your AWS costs (for more money, of course) and other companies’ products you may use that are hosted in your infra may accidentally delete your wallet if you don’t constantly monitor them.

    Using AWS cost-efficiently is only accomplished by ostensibly day-trading your cloud resources like a high frequency stock trader, capitalizing on unpopular/weird system types, and keeping your code as portable as possible.

    …but if one didn’t care about cost, one would probably get pretty good reliability out of them, sure.