But... if Google can do so if handed a random pile of old phones, then why would a consumer not be given the same option for their phones? If it works only for phones sold by Google once, same question holds. And applies to other vendors.
As you said: the "phone becomes useless just because OEM drops support" cycle needs to be broken. Well.. that and ability for end-users to replace batteries, screen, fix connectors etc.
Also it's unclear how data would move in & out of these old-phone-compute-nodes. USB-C? Article is a bit light on details there.
End users don’t need to replace screens, ports and batteries if there is reasonable cost parts and skilled labour available.
I’m happy with a trade off where a device has extreme miniaturisation and water resistance but needs someone with some surface mount soldering skill and the right tools to work on it.
Regardless, many (most?) phones hardware will last longer than the software running on it.
I would think the main factor against such clusters is cost. Even if the four year old phones are free, they have to be dismantled, tested, and supporting hardware/software has to be developed. All of that would have to be done on an ongoing basis. While Google may have the volume to be able to build uniform clusters with a given generation of hardware, generations are measured in months. Using four year old hardware also trims four years off the expected life expectancy of the components, and that is comparing like to like (not consumer grade hardware to server grade hardware). I've got to wonder how all of that extra work affects the carbon-footprint they are trying to reduce. It would probably be more effective to increase the use life of the phone as a phone.
All of that is fine for a research project or, on smaller scales, hobby projects. It would be extraordinarily difficult to make it commercially viable.
Approximately nobody is throwing away phones because the OEM stopped providing security patches. They're doing it for more practical reasons, like the phone getting slow, the battery wearing out, or wanting a better camera.
Moreover being able to replace firmware blobs/kernels/whatever doesn't mean such updates will actually materialize. For lineageos, many phones are stuck on 22.2 (android 15) because android 16 requires linux 5.4 and above, which means phones with earlier kernels are out of luck. Prior to this, there were phones from as early as 2016 (eg. the original Pixel) that could be upgraded to the latest Android. This isn't a "firmware blobs" or "locked down systems" problem. The kernel sources are available, and the kernel can be replaced, but nobody is going to bother upgrading the kernel for a 10 year old phone.
https://lineageos.org/Changelog-30/#legacy-devices
>You should not be connecting these old devices to an internet accessible network.
This depends on the use case. If you're using this as some sort of NAS or compute cluster running trusted workloads, you should be fine as long as there isn't some sort of RCE in the kernel.
I thought that, but a surprising number of people think that no support means that their device becomes vulnerable on the very next day. Not all of them act upon it but that seems to be the understanding of people who know what a security update is (not my grandma, but my mom for example) but aren't real techies or just not in this area. And it's not like these people are installing non-OEM patches! Nice as that would be...
Some time before and during covid, I feel like security update awareness became a lot more mainstream. Maybe because there's not much else to talk about in smartphones anymore anyway, so you shift from "ooh this fancy new one has a fingerprint reader in the power button and its notification LED on the back!" to "I don't want a new one; which one can I use for the most amount of years to avoid this hassle"
Probably also a culture thing. I guess most people in low- and middle-income countries have other worries; I'm speaking from a northwestern european viewpoint
This becomes a practical reason more quickly than you think. If a company only provides 4 years of security updates and they only provide 2 android MV releases, you quickly become out of date. I had a BlackBerry Key2 that I bought in 2018, I had to replace it in 2024 and I was really holding onto it despite a lot of practical problems - Slack dropped support for the version of Android a year earlier, it was only when I tried to install Google Wallet and could not that I finally decided despite the hardware and software functioning fine it really wasn't practical to use a device that was stuck on such an old version of Android. (I would've tried to figure out the kernel myself if the bootloader wasn't locked.)
Apple just shipped iOS 27, which has support for 2019's iPhone 11. So we are around 7 years there. It's probably fine for many people's use!
For a task like openclaw or hermes, or even something more aggressively graphical & GUI, it's not hard to imagine an 8 year old phone doing fine.
Relative to ever rising hw requirements of apps they obviously get slower. That is why I personally buy new phones.
The big obvious central smoking gun that you'll get to in computer science 200 level classes is Amdahl's Law, which states:
> the overall performance improvement gained by optimizing a single part of a system is limited by the fraction of time that the improved part is actually used
You queue up some work for an agent. The LLM is going to do a bunch of work over time, and spend 20 minutes crunching on a task. Let's generously say it takes your PC 2 minute of it's CPU time for it to do the tool calls, to run the build, to run tests. If we expand this to 10 minutes to run it on a phone, that's indeed starting to be a big enough difference to notice. But in 99.9999% of cases, I don't think the harness consumes that much CPU and I don't think the growth factor is 5x to move to phone, and even if it did, it's still only an increase from 22 to 30 minutes: it's an async job either way, and the time budget is not dominated by the phone or PC running the harness.
Ideally yes, there's some intelligence to see: oh, we are about do to a build. Send the build to the build server, that's a 384 core 1U with terabytes of memory bandwidth and let it do that. But most work is not like running builds and tests. The harness doesn't need that. We need some small local computers cheap that we can have lots of running.
Model performance might radically improve in time, and that might change the Amdahl's Law calculations here. If you're paying for Turbo or Plaid or whatever, yeah, you maybe have the money to spend on a better harness too. I'd say that ideally these workloads become live migrate-able, that we can CRIU checkpoint/restore them across systems, ideally, anytime, so that we can give performance people performance when it actually counts, like the build concern above, when the agent is fast. LLM's built for speed like LFM2.5-8B-A1B (DiffuseGemini feels unlikely as it's fast, but low concurrency, but perhaps?), double the speed of many models, so that 20 minutes could become significantly less. But right now it feels like we need a lot of cheap not-performance critical harnesses that can sit around running, and that performance for them is not critical. https://www.liquid.ai/blog/lfm2-5-8b-a1b
If folks aren't aware, I also suggest taking a peak at Google Ax and Google Scion, two agent runtimes designed for scaling out, that are both kind of neat. https://github.com/google/ax https://github.com/googlecloudplatform/scion https://news.ycombinator.com/item?id=47675213
The article seems to refer to a 2023 Pixel Fold as one of their candidates - I guess a good opportunity if those fragile screens get damaged but not a cheap used device otherwise.
Even normal slab pixel devices have limited support for true android replacements like PostmarketOS let alone cheaper 3rd party devices usually running Mediatek/Exnos SOC that have zero open docs or support.
Does anyone in the industry know why so much firmware is proprietary?
It's also a huge pain in the ass for them to release software as open source. They would need to track all the different forks and modifications in an organized manner (they often do a lot of copy paste and one-off nonsense). They run pretty light staffing on a lot of these components and doing all of that is just another chore for their overworked devs.
Lastly, I've heard they sometimes use other commercial, closed-source software components which they can't easily relicense.
Is this all bullshit? Yes absolutely. I'm not defending them but these are the excuses they give.
So, OEM just have to let us unlock the bootloader, just let us unlock it after they stop selling it, and it would reduce so much waste.
They are just so greedy
They might not understand the paranoia is real.
Remember people running 20 virus scanners and 3 firewalls on their win xp machine? Then it finds 12 suspicious cookies?
Couldn't Google somehow fix this? Since they control the substrate (Android) and they would be doing it for their convenience
They're actively working on closing the ecosystem even more (no more sideloading), DRM features, etc.
Maybe they'd do it for themselves, but they clearly don't want you, the customer, to do whatever you want with the device you bought and paid for.
caused by the very same Google...