[RetroTechie]

Obviously you'd have to replace the OS with an up-to-date one to use the phone as a cluster node.

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.

[d3Xt3r]

Replacing the OS is only one part of the equation, it doesn't mean you're replacing the low-level firmware blobs provided by various chipset vendors (like Qualcomm).

For phones before the Project Treble era (~2018), the OS, the kernel, and the vendor blobs were all deeply intertwined with each other. Because you can't get newer blobs from the hardware vendors, it's generally not possible to run a newer OS on those devices. Community-made custom ROMs (like CM/LOS) had to rely on hacky workarounds to get newer Android versions to run on older kernels, which lead to stability issues and the famous "what works/what doesn't work" meme.

For Treble-supported phones, the OS framework is decoupled from the vendor implementation. This means that you can run the latest OS (using a Generic System Image) on top of the older vendor blobs. BUT you are usually still stuck with an older kernel, as those proprietary blobs still rely on the vendor's specific kernel drivers, although it's a bit more stable compared to pre-Treble due to the decoupling and the standardised vendor interface.

In either case (pre/post Treble) the main problem is that your low-level firmware remains permanently out-of-date, which puts your device at risk. An up-to-date OS can mitigate application-level risks, but not all of it. For eg, it cannot protect against attacks targeted towards the baseband modem, the Wi-Fi or Bluetooth controllers. If a vulnerability is found in the cellular modem firmware (like the infamous Broadpwn or Kr00k exploits), no custom ROM or other OS (PostmarketOS etc) can patch it because only the chipset OEM has the source code to update that specific chip.

So unless all the various chipset OEMs come to the party and either release the sources or provide updated blobs, these devices can never be trusted for use in a production environment.

[saagarjha]

Firmware blobs for…what? It doesn’t matter if the camera or fingerprint sensor is working if you’ve harvested the motherboard.

[d3Xt3r]

Please re-read my comment, I already gave specific examples.

[bigiain]

Baseband, Wi-Fi, and Bluetooth seem like things that should not work in this context (either as a cluster in a data center, or for an old device I want to repurpose in my home lab).

Is there anything that typically _requires_ vendor blobs to let a phone run as a usb ethernet connected linux-ish node? So no camera, screen/touchscreen, wifi/bt/cellular radios, gps, nfc/rfid, or stuff like that?

I know RasPi relies or (or perhaps used to rely on?) some Broadcomm blog to boot - from memory something to do with getting the GPU to boot/configure before booting the cpu(s). I could easily see Samsung or Huawei intentionally building something like that - or ending up like that because the rushed and half assed the design and engineering.

[numpad0]

Backlights, battery, anything. Modern high performance CPUs need an external debug adapter to set up the board before they can be powered on(old supercomputers did too). Blobs running on a less-modern CPU handles that. The less modern CPU in RasPi is its GPU, but it can be other devices; it can be the modem, or a "security" sub-CPU.

IMO it's possible that the bigger issue is no one knows what's going on inside these devices. Maybe some of blobs aren't needed, or they can be readily replaced, etc., but no one has time to deal with it. This is probably a field that cheap brain-hours that LLMs just created could actually revolutionize.

[jurgenburgen]

If you read the linked article they throw away everything except the motherboard from the phones.

[d3Xt3r]

My comment was in context of GP's comment, not in the context of TFA. GP said:

> 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?

In this instance, Baseband/WiFi/Bluetooth is very much relevant.

[saagarjha]

None of those matter for compute

[d3Xt3r]

Please re-read the parent comment to whom my repy was directed at. They said:

> 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?

My response was to this, not the cluster-use case as mentioned in TFA.

[djfergus]

The lack of open, replaceable software is the main blocker. The article talks about only keeping the motherboard anyway.

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.

[llsf]

The OS that would be put on those old phones, would be a bare minimal, stripped down OS. No need for managing screen, audio, radio/GSM/EDGE/3-4-5G.

Not sure about the IO interface, could reuse the USB, but maybe there is some internal (and standard enough) bus to reuse too...

[vitally3643]

> why would a consumer not be given the same option for their phones?

Because it's more profitable to force customers to buy new phones every n years, and nobody is interested in stopping this behavior. There is no other reason that is grounded in any type of fact.