This is ignoring the fact that the main reason retired phones are e-waste is proprietary firmware blobs and locked-down systems preventing users from maintaining their phone with security updates, and very limited support length from OEM's leads to VERY insecure devices after they drop out of support.
You should not be connecting these old devices to an internet accessible network.
Google notably does well here with 7 years of support, but others such as Sony are 4 years, and Xiaomi on non-flagship devices are similar, or Samsung on their lowest budget models...
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.
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.
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.
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.
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.
> 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.
>This is ignoring the fact that the main reason retired phones are e-waste is proprietary firmware blobs and locked-down systems preventing users from maintaining their phone with security updates, and very limited support length from OEM's leads to VERY insecure devices after they drop out of support.
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.
>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.
> Approximately nobody is throwing away phones because the OEM stopped providing security patches.
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.)
But that's feature updates, not security updates? If the manufacturer kept providing security patches for your old Android version, it wouldn't have helped you install Slack and Wallet.
Phones don't actually get slower, or, they shouldn't, if they are reasonably well maintained. A battery swap might be necessary to preserve battery life under load. A NAND might start going bad.
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.
I think you're right, if you're referring to the hardware.
But there are also ever rising hardware requires for the built in apps and the rest of the operating system.
An iPad which we bought around 5 years ago, which was still on sale just over 2 years ago, is now painfully slow compared to when purchased (thanks to iOS 26) when using the the Settings app, the App Store, Safari, etc.
This is very important for devices with only one choice for operating system, like Apple iPads and iPhones.
It's true that the device only feels slower because the apps are have had feature updates, but there isn't a way to only choose security updates (except sometimes briefly after Apple release a really bloated new iOS version).
A similar situation applies for Android devices. While you can usually install something like LineageOS or GrapheneOS , if you also switch to a newer Android version to keep receiving security patches, the phone will feel considerably slower. If you stay on an older version, the OS will stop receiving updates sooner.*
*I haven't kept up with this lately, so I'd be happy to find out this isn't the case. If, for example, you could stay on a version of LineageOS or GrapheneOS based on Android 13, and still receive security updates.
If you are trying to run lots of Pi or Hermes or whatever corporate whatever agent junk you have, to make a bunch of always on efficient agentic systems available to people, en masse, with low start-up costs, and high efficiency, there's a host of reasons that doesn't matter.
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
> Approximately nobody is throwing away phones because the OEM stopped providing security patches.
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
Phones don't get "slow" on their own. It's usually due to bloatware from upgrades. Many phone cameras are already quite good. The only remaining reason to upgrade is possible security vulnerabilities, but even that doesn't require heavy software. Supporting larger apps is the main reason the system requirements continue to increase, since Niklaus Wirth wrote, "A Plea For Lean Software" in 1995.
But even if people could trade in their phones for a small deposit, how many actually do (and not because they would use it- typically storing it in their drawer is safer than and less time consuming than figuring out how to run a factory reset before giving it to a datacenter.
I've thought about a program where people could drop it off in their mailbox and have a delivery service pick it up (possibly the USPS, but I think they wouldn't want to be burdened with handling lots of lithium batteries).
20 years from now phones will be powerful enough that they can run on capacitors, thinner than a credit card, and deconverged from the multimedia omnibus systems that they are today. Sure it is convenient, but I think the feature adds will plateau.
Of course, you and I know that. But most people just listen to the marketing material.
My mother's most used feature on her phone is the camera.
She asked me about getting a new phone when she has a perfectly working Samsung flagship phone from 3 years ago. The marketing says "The S26 camera is _SOOOO_ much better". But, really, it's exactly the same sensors as the S23.
> 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.
I did this just last year because my Pixel 4a stopped getting security updates and some app I needed to use for work (I think Duo?) refused to install or run because of it. The phone was otherwise running perfectly fine and I had no reason to change it. I'm on a Pixel 8 now which is supposed to have 7 years of security updates, and I don't see myself replacing it until then.
The article seems to be fairly clear about this: it is Google focusing on Google phones (so unlocking the bootloader should not be an issue) and they did mention that the kernel would have to be replaced (albeit for other reasons).
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.
I pretty much agree with everything you said. But I think there is a chance for this to be commercially viable if it is offered in a different way. I,e not just raw cloud computing maybe you can run games on these clusters and jack the price a little. This is highly dependant on the virtual age of these clusters if they survive 10 of continuos work maybe there is a chance
I wonder if this is a research project about mitigating the risk of not being able to procure compute hardware if the AI industry soaks up all available hardware manufacturing capacity and raw materials?
I wonder if someone's trying to work out if they can keep GCP alive when there's no ram or cpu to be bought at any price because the AI companies (including the AI division in Google) and Nvidea have completely broken commodity compute hardware supply chains?
i don't think that the ai hype will destroy compute procurment for normal cloud opertaions but you can be sure that it'll be used as an excuse to jack the prices a lot.
Exactly this. Few phones allow bootloader unlock let alone open drivers that can be brought forward to a mainline kernel.
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.
I'm using a OnePlus 7, as my daily driver. Because it was bootloader unlockable, and LineageOS exists, I still can use it. And it performs respectfully, and serves my purpose. Except, my banking software, and digital payment applications, all works
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.
I've worked with manufacturers who shipped us binary blobs for their hardware. They are often willing to customize the software for you, but they want to own the modifications, which they can use for other customers. A big part of many contracts is a services component where they provide features or advanced functionality, and this lets them mark up their bill substantially. They're existentially scared of their hardware being cloned or their customers building in-house solutions, so they have to stay competitive on that front.
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.
Unfortunately it is a bit more complicated than that. All these phones run firmware, bootloaders, libraries under license from SoC providers, who package components from other vendors under a license themselves. Opening up the bootloader can be done, but two things have to happen: either the phone is crippled of various functionalities or the manufacturer is in breach of license because all the binary blobs become open and can be reverse engineered. No one wants to go through all of this for a few hundred people who are interested in running their home assistant on an exotic device.
I haven't ever heard of an SoC supplier demanding that the device's bootloader must be locked. Are you sure that this is happening? I've only ever seen devices delete first-party blobs, presumably of the manufacturer's own volition.
They're literally doing the opposite, right now you can't install a custom operating system, but in the near future you won't be able to install custom apps either: https://keepandroidopen.org/
Agreed. All parts of a device that we buy must be user replaceable. Phones can have decades of life. After their initial use as a first phone, they become a hand me down for their children, and they can become further hand me downs for people in third world countries or continue to live on as computers that can take on a variety of other roles.
The OS must be user replaceable so we can run what we like. If this is not possible, we should at least be allowed to a run a VM on the phone (we can assume <5% loss of performance).
Silicon lives matter. We must make sure our device has many afterlives until its eventual death (5 decades later).
People get scam emails all the time and most dont know the weird ui to display the sender adress and/or dont know what an untrustworthy mail address looks like.
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?
Some fraction of the ones that use the phone for password storage and banking. The latter seems to be nearly everyone, the former is very likely if there's a techy in their lives but since maybe 5-7 years it also seems to be becoming quite mainstream
I would love to see regulation that required making bootloaders unlockable to enable this sort of thing. People have been making clusters of consumer hardware for decades: I’m sure people remember the PS3 supercomputers of the mid 2000s.
I personally have lots of batch jobs like CFD simulations that could easily run on a fleet of phones with no real reliability issues, and I’d love to reuse old hardware and give it a second life. I’m already considering running old servers from e.g ETB but the cycles per watt on a phone are probably much better.
Isn't the story that some gaming consoles were sold at or under cost price and the markup was on the game sales? I don't know if it's fair to require that needs to be unlocked
Yet I 100% agree on a generic computing device and they're not really that different in the end. Maybe that it needs to be unlockable after it has been on the market for 4 years or so (all units, no matter when they were sold, no matter if support ended)
Or maybe undercutting the competition like this to make it back later on games is not a profit model we should want? And that everything should just be unlockable insofar as it has X amount of memory, CPU power, capable of doing IP traffic... something like that. (Seems silly to require a firmware unlock on your toaster)
> Isn't the story that some gaming consoles were sold at or under cost price and the markup was on the game sales?
Yes, but I'm confident Android smartphones aren't. Maybe Google is an exception here, but all the other manufacturers profit mostly from the hardware and not from the Apps. Samsung has its own app store, but I think only a tiny minority of users spend money there.
Also for microwaves and dishwashers? That's more the problem I struggle to solve: how to differentiate things that you want to run your own OS on from the things that it would be historically silly to have to provide connectivity and unlocking interfaces for
(On the other hand, our stupid 2026 dishwasher has no flushing program and leaves a ton of residue on the dishes. The 2001 model we inherited from the landlord was perfect, barely used any more power or water but the dishes were actually dry at the end and you could eat from them without ingesting detergent. I wouldn't mind inserting a little rinse cycle in the eco program if there were some documented way of talking to the chip, then for drying we can just let them sit in the opened machine for the remaining 20 hours of the day. Alas. Maybe I should want open source everything!)
Also, what's EOL? When it goes out of warranty after 2 years?
There are countries that require published material to be submitted to a national archive[0]. A similar system could be done for software source code and made public on expiry.
You factor in the expense of having your code releases escrowed by a third party (where part of the escrow contract itself is: "must be buildable from sources as provided"), and have a post-release pipeline that automatically uploads the new version. At the end of the term, the escrow holder releases all the versions.
This is a fairly common arrangement in high finance. If you want to supply services to a bank/insurer/etc. they will typically require an escrow arrangement as a contingency plan against you as a vendor going away. And yes, they pay the escrow costs.
So if I have software on my website and you pay for it and you’re in some European country that has this law then you (who?) can sue me for not uploading all my builds to what? some s3 endpoint?
No, it's not that way around. And it's not a law.[ß] If you and a high-finance institution agree to a separate (lawyer-negotiated!) contract where you provide essential/important software to the institution, they quite often require code escrow arrangements as part of the deal.
There are a few such services around, usually owned by a giant global consulting house.
The idea is that if you as a vendor go out of business or otherwise become unable to maintain the software, the finance institution gets access to the software via the escrow. Importantly, they also gain the contractual and legal rights to further maintain (read: modify) the software.
Under such contract the vendor has an obligation to upload periodic code releases to the escrow service, and the escrow service validates that the release builds. (And passes the bnudled test suite.) Rather surprisingly these services don't even cost that much... at least in the grand scheme of things. The requirement usually comes up only when the underlying supplier deal is at least six figures annually.
ß: well, contract law is still law but not in the sense the parent appears to be thinking
This is neat.
This group’s approach of treating the devices as many weaker servers (basically a raspberry pi cluster) sounds like the most realistic way to reuse phone hardware at scale, especially with the backing of the actual hardware vendor.
It’s a genuine shame how locked down iPhones are compared to even Android. Hypothetically you could run Linux inside UTM[0] but outside the EU Apple makes it intentionally difficult, and there’s still memory restrictions and performance penalties.
My group’s senior year project was a computing cluster on phones (specifically targetting LLM inference) [1]. Instead of installing a new OS we built separate apps per OS. Our devices were older, so the Android phones had worse hardware and the iPhones had more software restraints.
I doubt that many data centers or enterprises are interested in building phone clusters. I hope that this project will produce something that homelabs and self-hosters can build with 3D printers. That seems like the most probable end consumer.
The closest thing would be our showcase poster[0], at some point I might write about the thought/development process (both for my sake and whoever picks up the project in the future)
Sometimes I have weird fantasies about a post apocalyptic world where factories burned down and people have to live with the tech that’s available. No network, just off site solar power or generators, only local devices. I think it’s interesting to think about how far we could get with this.
Does anyone have recommendations for novels, movies or video games with that topic?
Pump 6 and Other Stories has a few in that vein, sort of. Eg there are no petrol engines, instead compression springs, treadle operated computers, etc. There are some pretty grim stories in there, some may find them distasteful.
Chiming in to second this, Pump Six and Other Stories left me with a deep, deep sense of dread after I finished reading it. Highly recommended, such an underrated collection.
There are many who indulge in such fantasies, but I would instead give a warning. The reason you have such fantasies is likely because you, yourself, are competent in the necessary skills. But from there it is only a hair-thin line that separates you from having feelings of actively wanting such a catastrophy to occur, because it would make you and your skills valuable. Beware of such self-indulgence.
It is self-indulgence, because we can see similar fantasies in people with other skills; people collecting guns often secretly long for a collapse of law and order, people who live in the countryside and have horses imagine themselves to be cowboys in a car-less world. People who like to tinker with old cars imagine Mad Max scenarios. Et cetera. None of these scenarios are especially likely to occur; they only persist in people’s imaginations because many secretly hope for them to come to pass.
Not exactly what you're describing, but https://en.wikipedia.org/wiki/One_Second_After kinda fits the vibe. Warning: it's really depressing, but a good read if you're in the right head space for it.
This is coming from the same Google that's recently restricted third-party AOSP source access to biannual releases, severely limited the scope of Pixel sources (basically just GPL now) and started concealing their change history, AND is currently pushing developer verification and Play Integrity on Android :D
Not sure if I should take this as a joke or a sign of an internal power struggle. If it's the former, there's still some catching up to do before you can match Samsung's "Upcycle", but you're on the right track.
It is ridiculous that I can pick up pretty much any average computer, install Linux on it and be on my way in an hour or so but have to go through so many hoops to do the same on Android and even then the results are mixed. We have been really shafted by the phone makers by the brainwashing that they are somehow extra special things. They are just computers with a radio in it. It is shameful.
Very weird that this is coming from Google, given that they made their phone platform specifically to not let you install your own operating system. And now, they're making it illegal to install custom apps too: https://keepandroidopen.org/
You say that as if Google is a single hive mind with every team and vertical perfectly aligned like the Borg.
The article is pretty clear in the opening lines that this is a Google Research grant to the University of California, not even primarily done by Google employees.
Besides the questionable use of "illegal" (what are they going to do, send you to jail?), that's not even accurate. You can still install apps after a 24 hour wait, or no wait at all if you use adb.
If they use anything that can be classified as a "digital lock" to enforce the policy, section 1201 of the DMCA comes into play. That includes potential criminal liability, resulting in fines and/or jail time as described by section 1204.
There is nothing about Android as a platform that forbids installation of your own OS. That's a phone oem choice and the fact Pixel phones can be unlocked proves as much. In fact this is the reason this project is even possible.
There isn't, but part of Google's requirements for using the trademark "Android" is iirc shipping a locked bootloader. If you also want to provide your users with the Play Store (many people will perceive the device as unusable without that), you also can't ship it with a su binary or something. It needs to come in a locked state where people only get user-level access, no permissions to read the data stored on there (outside of Downloads and DCIM and the like), no permissions to use TCP port 22, etc. Like the level of access many employers provide to non-tech personell as a device they don't own. As to why manufacturers are less and less often adding support for unlocking the hardware, I can only make assumptions
Google is requiring it be closed and leaving the unlock entirely optional. That's a choice
Right, because the android security model considers app developers independent entities with security privileges equal to those of the device owner (in that both parties need to authorize access for things to work, the device owner doesn't have more privileges than the application developer when it comes to the application). Those mechanisms are necessary for that security model to work. If you want to operate with a different security model that's fine, but you just need to use something other than Android. The bootloader situation being optional is Google not getting overly involved in the device maker's business outside of the scope they should have influence on. And they set the precedent via Pixel for how they think others should do it.
And who made the phones to retire? Google and other makers by closing firmware and bootloaders. And also by requiring more and more resources after each OS update and upgrade.
This "paper" doesn't really have anything in it, it's just a proposal with some unhelpful graphs. I wonder what they think is the novelty here. People with small budgets have been building compute clusters out of second-hand upcycled hardware for a long time.
I love the take about it. But nowhere is mentioned how have they installed Linux on those boards and which kind of distribution. I would also run Linux on retired phones, just I can't because some of them have a locked bootloader and the unlocking method doesn't work anymore, because the producer has retired the tool
A Pixel phone is a pretty neat computer. I tried a short project to turn one into a voice assistant node and then into a balcony camera to watch my plants etc. Realistically I should have rooted it and installed a full Linux etc. because you have to use the limited Google primitives through Termux to access Google’s very good voice model with its wake word detection. Stitching those things together is (was?) more annoying on a Termux session with open software.
And the balcony camera didn’t work out because I wanted it to be solar powered and the angles of sunshine available to me without active tracking don’t give me sufficient energy on a daily basis.
But the machine is still a good machine. I will perhaps return to one of these projects. It’s annoying how much power access dominates everything.
I've been using GNU/Linux as my phone OS for the last 18 years on several devices, enjoying "normal payloads of tools & scripts". Aside of a short time around 2017-2019 I never carried and relied on any other phone. It's not some wishful fantasy, it already exists and works.
I do see remote attestation as a grave threat not just to mobile phones, but to general purpose computing as a whole (well, aside of offline use cases perhaps). It creeps in slowly, but I'm hopeful we can still fight it off.
Computing platform with retired phones is not going to happen unless manufacturers add some budged for this to the motherboard design, expose high bandwidth interface similar to pci-e or usb4, we have now 80GB/s RAM phones with less than 1GB/s usb3 interfaces to the this beast computers, it is absurd.
I'm delighted to see at least someone is trying this. There are also millions of old laptops discarded every year, often with perfectly capable motherboards, but with minor issues outside of the compute (keyboards, screens, dead battery) which are just not economical to repair. Surely with the right software you can turn 10x 8GB i5 motherboards into something more than the sum of it's parts?
> Prior to deployment, smartphones must be processed to remove all but the motherboard
I wonder how long this takes per phone. Presumably it could be a pretty fast shucking process if you don't care about any of the other components. I can't see it making much economic sense if it takes more than 1 minute/phone.
> This is generally driven by people’s desire for a new device, including for the functionalities provided by new models.
So people are to blame, not the companies shoveling ads, offering promotions to buy new phones, and in general creating the huge demand that they later, "are forced to satisfy".
They cover this in the article, they’re just running motherboards removed from the other components specifically because no one wants exploding phone batteries in their data centre.
I wanted to do this for like forever. So much computing just being tossed whenever I visit e-waste facilities. I was thinking that maybe AI can help automate the creation of a stripped down Linux that can be tailored for many phones and break some of the propietary blobs. We really need networking(ethernet?) and the CPU. Audio, accelerated GPU, cell, bluetooth etc can just be tossed. I was envisioning AI developed carrier boards that you could attach a phone motherboard to and it would help break out I/O and power. At this point it remains to be seen if AI can assist with this.
Around 2015, I was working for a company that processed coupons for large retail stores. We had lots of performance issues, mostly due to our centralized database at the time.
I was dreaming at the time to ship a mobile phone at every large store (e.g. Target) to process the data in-situ. It could hold its own database (partitioned for the tenant), it would have its own UPS (battery), and have enough CPU power to serve the POS requests of one store, even the largest ones.
This is such a cool project. I run a Tor Snowflake node, so the of concept of enthusiasts contributing to a decentralised network interests me.
However it does worry me that I've never heard of acurast... I consider myself pretty well read on the subject of decentralised projects, has it just not taken off?
Well, I really don’t like Google, but if they make this a thing, I’d switch to Android and put Graphene on it or whatever just so I could tie into this. This is an excellent idea.
It’s counter intuitive to me that this is a net carbon win.
- Are these phone processors really as compute-pet-watt efficient as a regular data center processor?
- There’s so little embodied carbon in a phone motherboard - and presumably some embodied carbon in whatever custom racking hardware up is being used to house these. Is that really compute-power-per-embodied-carbon-footprint efficient than making a new server?
I don't have time for an elaborate sourced answer but in short, yes, the efficiency gains of modern devices is almost negligible compared to the CO2e of producing a new device at current device lifespans. I can't remember if you would have to use a device for 15 or 25 years before upgrading is better than continuing to use it, but I thought it was 25
Edit: yes, 25. Found my go-to reference for this quickly after all
> The report about the cost of planned obsolescence by the European Environmental Bureau [7] makes the scale of the problem very clear. For laptops and similar computers, manufacturing, distribution and disposal account for 52% of their Global Warming Potential (i.e. the amount of CO₂-equivalent emissions caused). For mobile phones, this is 72%. The report calculates that the lifetime of these devices should be at least 25 years to limit their Global Warming Potential. —https://wimvanderbauwhede.codeberg.page/articles/frugal-comp...
The carbon cost to produce or use a new phone isn’t relevant here.
The important question is whether repurposing an already-existing phone to act as a server (including physically adapting the phone and producing whatever extra hardware is required to do that) is less carbon-costly than producing and using a new designed-for-the-purpose server.
> Are these phone processors really as compute-pet-watt efficient as a regular data center processor?
I have no numbers to back up my argument, but smart phones are very power efficient by their nature are they not? I can play a 3d game, with impressive graphics, on a tiny device powered by a battery... With very little heat generated.
If your goal is to run LLM inference on a gpu in a power efficient manner, I bet a smart phone is a good place to start.
Do many people really have a stockpile of working old phones?
From my observations, phones get destroyed, used until the battery swells and breaks them, or handed down to kids or less careful users. No one I know has a bunch of old phones that are still useful but unused.
I have Nexus 5, Xiaomi A1, Redmi Note 7, Samsung S7, and a Kindle Fire HDX, all running either LineageOS (Kindle) or PostmarketOS (the rest). PmOS ones run some not very demanding containers (scrapers) on k3s.
I have a drawer full of old phones with broken screens, obsolete chipsets, etc. I usually buy phones rather than get them through a contact plan with trade-ins though.
They're not useful as phones, because the battery, screen, radio, etc. are damaged; but they may still have a working CPU inside, which would be sufficient for this project.
> On average, people replace their phone every four years. This is generally driven by people’s desire for a new device, including for the functionalities provided by new models.
This is so not true. I'm not replacing my phone because I want to. I'm replacing because your stupid updates break my phone and make it unusable. It's called Planned obsolescence
I've always wondered what that would be like. A fleet of 50 relatively modern flagship smartphones, wiped and retrofitted software wise to act as a homogeneous server, running ubuntu or centos or fedora, something like that.
EMMC in phones has a finite lifetime and dies after a few years of use. That it is not mentioned in the article tells me everything I need to know about its seriousness
A few years? I have a bunch of phones from 2009 around that are still fully working and I have never had eMMC fail on any of them, and they use it for swap among other things. In my experience screens, batteries and USB ports fail much more often.
Phone from 2009 uses SLC, or MLC with large SLC cache, thus capable of at least 10k FDW (full disk writes).
Modern phones typically use TLC or QLC within a inch of their physical limits (signal to noise ratio), thus qualified typically only up to 500 FDW, which translates into several years of use.
There are other mechanisms at play which further degrade this number, such as WAF (write amplification) and others
Only the very cheapest phones still have eMMC. I bought a Pixel phone second hand last year and it shows the wear level of the storage somewhere in the settings. I forgot the number but it was so low, extrapolation got me to something crazy like maybe 20 or 50 years of expected use at that rate
That consumer rate isn't datacentre use, but not every task is write-to-persistent-storage intensive. You can also replace the sdcard and write to that instead if this is a worry (that's what I've been doing on my phones since I use them quite intensively; maybe that's overkill nowadays idk)
hoped this would happen for a long time but knew it takes a Google sized momentum to make it happen. Formalizing the goal is great and brings it closer to reality
I guess the article is targeting regular people. However combining terms like "Linux distro" with other non technical explanations like "useless components such as screens, cameras, etc" sounded a bit weird to me.
Also;
For example, phones have a “low memory killer” daemon, which throttles memory-hungry applications.
I mean, this is also needed for server applications, more-so than personal use. Reason being in fact a runaway process would interrupt many users rather than a single user in server versus client use cases respectively...
Maps Camp Google 2007 -- to the assembled 400+ engineers and guests, at the podium. A calm and thoughtful pitch during the five minute talks "You at Google have a special responsibility, we all do, to make a closed loop industrial ecology with this hardware".. Later that month, bills unpaid, rent payments on credit, the blog EWasteInsights folds after two years.. Silicon Valley Bank has a another boozy party...
Imagine you could buy some serial extendable base station and click all of your old phones in it.
Applications could offload all kinds of tasks.
You dont even need to invent useful applications the community will do it for you. But if you insist, think all kinds of cheap smart devices that offload the smart part.
Carbon is fungible right up until you make something out of it, at which point it’s really not without a significant effort. We can’t just take a mobile phone and decompose it back to its component atoms for reuse as something else, recycling is to some degree a myth, and to a greater degree incredibly energy demanding in itself to get things broken down to a level they can be turned into something new.
This is ignoring the fact that the main reason retired phones are e-waste is proprietary firmware blobs and locked-down systems preventing users from maintaining their phone with security updates, and very limited support length from OEM's leads to VERY insecure devices after they drop out of support.
You should not be connecting these old devices to an internet accessible network.
Google notably does well here with 7 years of support, but others such as Sony are 4 years, and Xiaomi on non-flagship devices are similar, or Samsung on their lowest budget models...
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.
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.
[dead]
Firmware blobs for…what? It doesn’t matter if the camera or fingerprint sensor is working if you’ve harvested the motherboard.
Please re-read my comment, I already gave specific examples.
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.
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.
If you read the linked article they throw away everything except the motherboard from the phones.
Doesn't really matter.
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.
None of those matter for compute
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.
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.
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...
> 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.
>This is ignoring the fact that the main reason retired phones are e-waste is proprietary firmware blobs and locked-down systems preventing users from maintaining their phone with security updates, and very limited support length from OEM's leads to VERY insecure devices after they drop out of support.
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.
> Approximately nobody is throwing away phones because the OEM stopped providing security patches.
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.)
But that's feature updates, not security updates? If the manufacturer kept providing security patches for your old Android version, it wouldn't have helped you install Slack and Wallet.
Phones don't actually get slower, or, they shouldn't, if they are reasonably well maintained. A battery swap might be necessary to preserve battery life under load. A NAND might start going bad.
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.
> Phones don't actually get slower, or, they shouldn't, if they are reasonably well maintained.
Relative to ever rising hw requirements of apps they obviously get slower. That is why I personally buy new phones.
I think you're right, if you're referring to the hardware.
But there are also ever rising hardware requires for the built in apps and the rest of the operating system.
An iPad which we bought around 5 years ago, which was still on sale just over 2 years ago, is now painfully slow compared to when purchased (thanks to iOS 26) when using the the Settings app, the App Store, Safari, etc.
This is very important for devices with only one choice for operating system, like Apple iPads and iPhones.
It's true that the device only feels slower because the apps are have had feature updates, but there isn't a way to only choose security updates (except sometimes briefly after Apple release a really bloated new iOS version).
A similar situation applies for Android devices. While you can usually install something like LineageOS or GrapheneOS , if you also switch to a newer Android version to keep receiving security patches, the phone will feel considerably slower. If you stay on an older version, the OS will stop receiving updates sooner.*
*I haven't kept up with this lately, so I'd be happy to find out this isn't the case. If, for example, you could stay on a version of LineageOS or GrapheneOS based on Android 13, and still receive security updates.
If you are trying to run lots of Pi or Hermes or whatever corporate whatever agent junk you have, to make a bunch of always on efficient agentic systems available to people, en masse, with low start-up costs, and high efficiency, there's a host of reasons that doesn't matter.
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
Have you ever owned an older phone or older computer in general? Whether hardware or software caused, they get slower.
Only if the software gets slower. My 2015 MacBook Air is slow with the latest supported macOS but runs Linux super snappy for the same tasks.
Unless the thermal paste goes bad and the fans get clogged and you get thermally throttled.
Battery swaps usually don't work very well, unfortunately.
[dead]
> Approximately nobody is throwing away phones because the OEM stopped providing security patches.
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
I’ve got a Pixel 4a as a second phone just for work… it’s a perfectly fine phone
I’ve stopped using it because Google abandoned it after 18 months
There are plenty of Android phones out there that are usable but get abandoned by the makers
Phones don't get "slow" on their own. It's usually due to bloatware from upgrades. Many phone cameras are already quite good. The only remaining reason to upgrade is possible security vulnerabilities, but even that doesn't require heavy software. Supporting larger apps is the main reason the system requirements continue to increase, since Niklaus Wirth wrote, "A Plea For Lean Software" in 1995.
But even if people could trade in their phones for a small deposit, how many actually do (and not because they would use it- typically storing it in their drawer is safer than and less time consuming than figuring out how to run a factory reset before giving it to a datacenter.
I've thought about a program where people could drop it off in their mailbox and have a delivery service pick it up (possibly the USPS, but I think they wouldn't want to be burdened with handling lots of lithium batteries).
20 years from now phones will be powerful enough that they can run on capacitors, thinner than a credit card, and deconverged from the multimedia omnibus systems that they are today. Sure it is convenient, but I think the feature adds will plateau.
> Many phone cameras are already quite good.
Of course, you and I know that. But most people just listen to the marketing material.
My mother's most used feature on her phone is the camera.
She asked me about getting a new phone when she has a perfectly working Samsung flagship phone from 3 years ago. The marketing says "The S26 camera is _SOOOO_ much better". But, really, it's exactly the same sensors as the S23.
And unsurprisingly, the S23 camera is probably still better than most entry level phones being released today.
> 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.
I did this just last year because my Pixel 4a stopped getting security updates and some app I needed to use for work (I think Duo?) refused to install or run because of it. The phone was otherwise running perfectly fine and I had no reason to change it. I'm on a Pixel 8 now which is supposed to have 7 years of security updates, and I don't see myself replacing it until then.
The article seems to be fairly clear about this: it is Google focusing on Google phones (so unlocking the bootloader should not be an issue) and they did mention that the kernel would have to be replaced (albeit for other reasons).
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.
I pretty much agree with everything you said. But I think there is a chance for this to be commercially viable if it is offered in a different way. I,e not just raw cloud computing maybe you can run games on these clusters and jack the price a little. This is highly dependant on the virtual age of these clusters if they survive 10 of continuos work maybe there is a chance
I wonder if this is a research project about mitigating the risk of not being able to procure compute hardware if the AI industry soaks up all available hardware manufacturing capacity and raw materials?
I wonder if someone's trying to work out if they can keep GCP alive when there's no ram or cpu to be bought at any price because the AI companies (including the AI division in Google) and Nvidea have completely broken commodity compute hardware supply chains?
i don't think that the ai hype will destroy compute procurment for normal cloud opertaions but you can be sure that it'll be used as an excuse to jack the prices a lot.
Exactly this. Few phones allow bootloader unlock let alone open drivers that can be brought forward to a mainline kernel.
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.
I'm using a OnePlus 7, as my daily driver. Because it was bootloader unlockable, and LineageOS exists, I still can use it. And it performs respectfully, and serves my purpose. Except, my banking software, and digital payment applications, all works
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
Google has so much influence over the hardware manufacturers. They should do more.
Does anyone in the industry know why so much firmware is proprietary?
I've worked with manufacturers who shipped us binary blobs for their hardware. They are often willing to customize the software for you, but they want to own the modifications, which they can use for other customers. A big part of many contracts is a services component where they provide features or advanced functionality, and this lets them mark up their bill substantially. They're existentially scared of their hardware being cloned or their customers building in-house solutions, so they have to stay competitive on that front.
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.
> This is ignoring the fact that the main reason retired phones are e-waste is proprietary firmware blobs and locked-down systems
Couldn't Google somehow fix this? Since they control the substrate (Android) and they would be doing it for their convenience
Unfortunately it is a bit more complicated than that. All these phones run firmware, bootloaders, libraries under license from SoC providers, who package components from other vendors under a license themselves. Opening up the bootloader can be done, but two things have to happen: either the phone is crippled of various functionalities or the manufacturer is in breach of license because all the binary blobs become open and can be reverse engineered. No one wants to go through all of this for a few hundred people who are interested in running their home assistant on an exotic device.
I haven't ever heard of an SoC supplier demanding that the device's bootloader must be locked. Are you sure that this is happening? I've only ever seen devices delete first-party blobs, presumably of the manufacturer's own volition.
Unisoc mandates locked bootloaders, but it's true, the majority doesn't care, they just want to sell the SOC
They're literally doing the opposite, right now you can't install a custom operating system, but in the near future you won't be able to install custom apps either: https://keepandroidopen.org/
You can install a custom operating system on (a non-carrier-locked model of) every phone Google has ever made.
What do you mean you can't install a custom operating system? The bootloader is unlocked on google phones, isn't it?
This website is full of false FUD.
Why would they?
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.
Agreed. All parts of a device that we buy must be user replaceable. Phones can have decades of life. After their initial use as a first phone, they become a hand me down for their children, and they can become further hand me downs for people in third world countries or continue to live on as computers that can take on a variety of other roles.
The OS must be user replaceable so we can run what we like. If this is not possible, we should at least be allowed to a run a VM on the phone (we can assume <5% loss of performance).
Silicon lives matter. We must make sure our device has many afterlives until its eventual death (5 decades later).
Back before I got used to Google cancelling all of their projects, I was immensely excited, then disappointed by this:
https://en.wikipedia.org/wiki/Project_Ara
Which consumer ever cares about "security" updates on phones?
People get scam emails all the time and most dont know the weird ui to display the sender adress and/or dont know what an untrustworthy mail address looks like.
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?
Some fraction of the ones that use the phone for password storage and banking. The latter seems to be nearly everyone, the former is very likely if there's a techy in their lives but since maybe 5-7 years it also seems to be becoming quite mainstream
> proprietary firmware blobs and locked-down systems
caused by the very same Google...
Just ask Mythos to jailbreak the phone OS for you ;-)
I would love to see regulation that required making bootloaders unlockable to enable this sort of thing. People have been making clusters of consumer hardware for decades: I’m sure people remember the PS3 supercomputers of the mid 2000s.
I personally have lots of batch jobs like CFD simulations that could easily run on a fleet of phones with no real reliability issues, and I’d love to reuse old hardware and give it a second life. I’m already considering running old servers from e.g ETB but the cycles per watt on a phone are probably much better.
Isn't the story that some gaming consoles were sold at or under cost price and the markup was on the game sales? I don't know if it's fair to require that needs to be unlocked
Yet I 100% agree on a generic computing device and they're not really that different in the end. Maybe that it needs to be unlockable after it has been on the market for 4 years or so (all units, no matter when they were sold, no matter if support ended)
Or maybe undercutting the competition like this to make it back later on games is not a profit model we should want? And that everything should just be unlockable insofar as it has X amount of memory, CPU power, capable of doing IP traffic... something like that. (Seems silly to require a firmware unlock on your toaster)
> I don't know if it's fair to require that needs to be unlocked
Sure it’s fair, and manufacturers could price accordingly. Legally enforceable is another story.
> Isn't the story that some gaming consoles were sold at or under cost price and the markup was on the game sales?
Yes, but I'm confident Android smartphones aren't. Maybe Google is an exception here, but all the other manufacturers profit mostly from the hardware and not from the Apps. Samsung has its own app store, but I think only a tiny minority of users spend money there.
True, though any regulation would (at least ideally) be generic about computing devices
> were sold at or under cost price and the markup was on the game sales?
To be honest that has always had a smell to me akin to dumping.
Differences between dumping and "loss leader"?
Consoles haven't been sold with a loss for generations, please stop repeating that to support DRM.
Didn't know that, thanks for the correction!
the requirement could be when the hardware reaches EOL unlock the bootloader
Also for microwaves and dishwashers? That's more the problem I struggle to solve: how to differentiate things that you want to run your own OS on from the things that it would be historically silly to have to provide connectivity and unlocking interfaces for
(On the other hand, our stupid 2026 dishwasher has no flushing program and leaves a ton of residue on the dishes. The 2001 model we inherited from the landlord was perfect, barely used any more power or water but the dishes were actually dry at the end and you could eat from them without ingesting detergent. I wouldn't mind inserting a little rinse cycle in the eco program if there were some documented way of talking to the chip, then for drying we can just let them sit in the opened machine for the remaining 20 hours of the day. Alas. Maybe I should want open source everything!)
Also, what's EOL? When it goes out of warranty after 2 years?
Make it a seven year rule: hardware vendors must release necessary source code for firmware, blobs, etc.
I think there should be a 20 year rule for all released commercial software to release the source code outside of national security concerns.
Seems like you may be interested in this petition: https://publiccode.eu
lol or what? How do you make people do a thing, anything, 20 years later?
There are countries that require published material to be submitted to a national archive[0]. A similar system could be done for software source code and made public on expiry.
[0] https://youtu.be/ZNVuIU6UUiM
Code escrow.
You factor in the expense of having your code releases escrowed by a third party (where part of the escrow contract itself is: "must be buildable from sources as provided"), and have a post-release pipeline that automatically uploads the new version. At the end of the term, the escrow holder releases all the versions.
This is a fairly common arrangement in high finance. If you want to supply services to a bank/insurer/etc. they will typically require an escrow arrangement as a contingency plan against you as a vendor going away. And yes, they pay the escrow costs.
So if I have software on my website and you pay for it and you’re in some European country that has this law then you (who?) can sue me for not uploading all my builds to what? some s3 endpoint?
No, it's not that way around. And it's not a law.[ß] If you and a high-finance institution agree to a separate (lawyer-negotiated!) contract where you provide essential/important software to the institution, they quite often require code escrow arrangements as part of the deal.
There are a few such services around, usually owned by a giant global consulting house.
The idea is that if you as a vendor go out of business or otherwise become unable to maintain the software, the finance institution gets access to the software via the escrow. Importantly, they also gain the contractual and legal rights to further maintain (read: modify) the software.
Under such contract the vendor has an obligation to upload periodic code releases to the escrow service, and the escrow service validates that the release builds. (And passes the bnudled test suite.) Rather surprisingly these services don't even cost that much... at least in the grand scheme of things. The requirement usually comes up only when the underlying supplier deal is at least six figures annually.
ß: well, contract law is still law but not in the sense the parent appears to be thinking
We get it, corporations are immortal, formless entities that cannot be compelled to follow law.
... except they need to make that transient, formless concept known as money, and governments CAN use that.
This is neat. This group’s approach of treating the devices as many weaker servers (basically a raspberry pi cluster) sounds like the most realistic way to reuse phone hardware at scale, especially with the backing of the actual hardware vendor.
It’s a genuine shame how locked down iPhones are compared to even Android. Hypothetically you could run Linux inside UTM[0] but outside the EU Apple makes it intentionally difficult, and there’s still memory restrictions and performance penalties.
My group’s senior year project was a computing cluster on phones (specifically targetting LLM inference) [1]. Instead of installing a new OS we built separate apps per OS. Our devices were older, so the Android phones had worse hardware and the iPhones had more software restraints.
[0] https://getutm.app/ [1] https://github.com/orgs/rmcluster/repositories
I doubt that many data centers or enterprises are interested in building phone clusters. I hope that this project will produce something that homelabs and self-hosters can build with 3D printers. That seems like the most probable end consumer.
Really interesting project. Do you have a link to a writeup/paper?
The closest thing would be our showcase poster[0], at some point I might write about the thought/development process (both for my sake and whoever picks up the project in the future)
[0] https://docs.google.com/presentation/d/1jsJ5euZ4VXcwL4fbgJKM...
Sometimes I have weird fantasies about a post apocalyptic world where factories burned down and people have to live with the tech that’s available. No network, just off site solar power or generators, only local devices. I think it’s interesting to think about how far we could get with this.
Does anyone have recommendations for novels, movies or video games with that topic?
Pump 6 and Other Stories has a few in that vein, sort of. Eg there are no petrol engines, instead compression springs, treadle operated computers, etc. There are some pretty grim stories in there, some may find them distasteful.
https://windupstories.com/books/pump-six-and-other-stories/
Also I guess Silo / WOOL by Hugh Howey is perhaps closer to what you wrote literally but probably not quite the vibe maybe.
Chiming in to second this, Pump Six and Other Stories left me with a deep, deep sense of dread after I finished reading it. Highly recommended, such an underrated collection.
There are many who indulge in such fantasies, but I would instead give a warning. The reason you have such fantasies is likely because you, yourself, are competent in the necessary skills. But from there it is only a hair-thin line that separates you from having feelings of actively wanting such a catastrophy to occur, because it would make you and your skills valuable. Beware of such self-indulgence.
It is self-indulgence, because we can see similar fantasies in people with other skills; people collecting guns often secretly long for a collapse of law and order, people who live in the countryside and have horses imagine themselves to be cowboys in a car-less world. People who like to tinker with old cars imagine Mad Max scenarios. Et cetera. None of these scenarios are especially likely to occur; they only persist in people’s imaginations because many secretly hope for them to come to pass.
Not fiction but you might find this interesting: https://collapseos.org/why.html
FWIW I think “total supply chain collapse by 2030” is highly unlikely, but this kind of constrained technical thinking is pretty cool.
I suspect it might be too ‘soft’ for a lot folks around here (sadly), but “Monk and Robot” is charming.
In general, you should look into the ‘solarpunk’ genre, especially post-apocalyptic solarpunk.
Not exactly what you're describing, but https://en.wikipedia.org/wiki/One_Second_After kinda fits the vibe. Warning: it's really depressing, but a good read if you're in the right head space for it.
Alas, Babylon by Pat Frank is another great book in a similar vein.
Besides published material, Cuba comes close. Kept frozen in time by eternal restrictive sanctions.
You don’t think the country is mismanaged?
Book of Eli has vibes along those lines
Are we still at the fantasy stage?
This is coming from the same Google that's recently restricted third-party AOSP source access to biannual releases, severely limited the scope of Pixel sources (basically just GPL now) and started concealing their change history, AND is currently pushing developer verification and Play Integrity on Android :D
Not sure if I should take this as a joke or a sign of an internal power struggle. If it's the former, there's still some catching up to do before you can match Samsung's "Upcycle", but you're on the right track.
It is ridiculous that I can pick up pretty much any average computer, install Linux on it and be on my way in an hour or so but have to go through so many hoops to do the same on Android and even then the results are mixed. We have been really shafted by the phone makers by the brainwashing that they are somehow extra special things. They are just computers with a radio in it. It is shameful.
Somewhat relevant: some of us have been using drawer-bound smartphones for web hosting.
https://far.computer
https://compost.party
Very weird that this is coming from Google, given that they made their phone platform specifically to not let you install your own operating system. And now, they're making it illegal to install custom apps too: https://keepandroidopen.org/
You say that as if Google is a single hive mind with every team and vertical perfectly aligned like the Borg.
The article is pretty clear in the opening lines that this is a Google Research grant to the University of California, not even primarily done by Google employees.
>given that they made their phone platform specifically to not let you install your own operating system.
???
You can still install alternate OSes (eg. grapheneos) on their latest phones.
>And now, they're making it illegal to install custom apps too: https://keepandroidopen.org/
Besides the questionable use of "illegal" (what are they going to do, send you to jail?), that's not even accurate. You can still install apps after a 24 hour wait, or no wait at all if you use adb.
If they use anything that can be classified as a "digital lock" to enforce the policy, section 1201 of the DMCA comes into play. That includes potential criminal liability, resulting in fines and/or jail time as described by section 1204.
There is nothing about Android as a platform that forbids installation of your own OS. That's a phone oem choice and the fact Pixel phones can be unlocked proves as much. In fact this is the reason this project is even possible.
There isn't, but part of Google's requirements for using the trademark "Android" is iirc shipping a locked bootloader. If you also want to provide your users with the Play Store (many people will perceive the device as unusable without that), you also can't ship it with a su binary or something. It needs to come in a locked state where people only get user-level access, no permissions to read the data stored on there (outside of Downloads and DCIM and the like), no permissions to use TCP port 22, etc. Like the level of access many employers provide to non-tech personell as a device they don't own. As to why manufacturers are less and less often adding support for unlocking the hardware, I can only make assumptions
Google is requiring it be closed and leaving the unlock entirely optional. That's a choice
Right, because the android security model considers app developers independent entities with security privileges equal to those of the device owner (in that both parties need to authorize access for things to work, the device owner doesn't have more privileges than the application developer when it comes to the application). Those mechanisms are necessary for that security model to work. If you want to operate with a different security model that's fine, but you just need to use something other than Android. The bootloader situation being optional is Google not getting overly involved in the device maker's business outside of the scope they should have influence on. And they set the precedent via Pixel for how they think others should do it.
Speaking as someone who has a cluster of four RPi Zero W’s mounted in an Ikea picture frame running as a Docker Swarm cluster, I LOVE this idea.
That’s cool, do you have a write up about it?
I never did. I probably should.
And who made the phones to retire? Google and other makers by closing firmware and bootloaders. And also by requiring more and more resources after each OS update and upgrade.
I liked Jennifer Switzer's junkyard computing paper and it's cool to see her still working this idea.
https://arxiv.org/abs/2110.06870
This "paper" doesn't really have anything in it, it's just a proposal with some unhelpful graphs. I wonder what they think is the novelty here. People with small budgets have been building compute clusters out of second-hand upcycled hardware for a long time.
I love the take about it. But nowhere is mentioned how have they installed Linux on those boards and which kind of distribution. I would also run Linux on retired phones, just I can't because some of them have a locked bootloader and the unlocking method doesn't work anymore, because the producer has retired the tool
A Pixel phone is a pretty neat computer. I tried a short project to turn one into a voice assistant node and then into a balcony camera to watch my plants etc. Realistically I should have rooted it and installed a full Linux etc. because you have to use the limited Google primitives through Termux to access Google’s very good voice model with its wake word detection. Stitching those things together is (was?) more annoying on a Termux session with open software.
And the balcony camera didn’t work out because I wanted it to be solar powered and the angles of sunshine available to me without active tracking don’t give me sufficient energy on a daily basis.
But the machine is still a good machine. I will perhaps return to one of these projects. It’s annoying how much power access dominates everything.
Anyway, this is a cool project!
Sounds like a marketing focused and less technical perspective of: https://blog.denv.it/posts/pmos-k3s-cluster/
If only the phones could run a real Linux, let us bring our normal payloads of tools & scripts!
I've been using GNU/Linux as my phone OS for the last 18 years on several devices, enjoying "normal payloads of tools & scripts". Aside of a short time around 2017-2019 I never carried and relied on any other phone. It's not some wishful fantasy, it already exists and works.
Me too, but surely you also notice they're slowly raising the temperature of the pot we're in?
I do see remote attestation as a grave threat not just to mobile phones, but to general purpose computing as a whole (well, aside of offline use cases perhaps). It creeps in slowly, but I'm hopeful we can still fight it off.
Computing platform with retired phones is not going to happen unless manufacturers add some budged for this to the motherboard design, expose high bandwidth interface similar to pci-e or usb4, we have now 80GB/s RAM phones with less than 1GB/s usb3 interfaces to the this beast computers, it is absurd.
I'm delighted to see at least someone is trying this. There are also millions of old laptops discarded every year, often with perfectly capable motherboards, but with minor issues outside of the compute (keyboards, screens, dead battery) which are just not economical to repair. Surely with the right software you can turn 10x 8GB i5 motherboards into something more than the sum of it's parts?
Yeah, I think the intention matters here. There might even be a whole business to be created from this.
Ctrl+F PostmarketOS. No? No, apparently.
https://news.ycombinator.com/item?id=48516656
This earlier comment referenced it :)
The termux community are masters of creating useful servers with old phones.
This also solves alot of the security issues as your in a sandbox.
> Prior to deployment, smartphones must be processed to remove all but the motherboard
I wonder how long this takes per phone. Presumably it could be a pretty fast shucking process if you don't care about any of the other components. I can't see it making much economic sense if it takes more than 1 minute/phone.
> This is generally driven by people’s desire for a new device, including for the functionalities provided by new models.
So people are to blame, not the companies shoveling ads, offering promotions to buy new phones, and in general creating the huge demand that they later, "are forced to satisfy".
Is be more enthusiastic about this if one could remove the batteries. Dealing with spicy pillows is a pain
They cover this in the article, they’re just running motherboards removed from the other components specifically because no one wants exploding phone batteries in their data centre.
Aside from bootloaders, this is the only thing stopping me from using old devices for cool stuff.
I wanted to do this for like forever. So much computing just being tossed whenever I visit e-waste facilities. I was thinking that maybe AI can help automate the creation of a stripped down Linux that can be tailored for many phones and break some of the propietary blobs. We really need networking(ethernet?) and the CPU. Audio, accelerated GPU, cell, bluetooth etc can just be tossed. I was envisioning AI developed carrier boards that you could attach a phone motherboard to and it would help break out I/O and power. At this point it remains to be seen if AI can assist with this.
This idea has been around for a long time. See https://www.usenix.org/conference/hotcloud17/program/present..., also https://www.sigops.org/s/conferences/sosp/2009/papers/anders...
Around 2015, I was working for a company that processed coupons for large retail stores. We had lots of performance issues, mostly due to our centralized database at the time.
I was dreaming at the time to ship a mobile phone at every large store (e.g. Target) to process the data in-situ. It could hold its own database (partitioned for the tenant), it would have its own UPS (battery), and have enough CPU power to serve the POS requests of one store, even the largest ones.
A mobile phone would be our on-prem server.
You guys should check acurast.com . This is decentralized compute network with over 200,000 retired devices connected.
You can already run any workloads on it at a fraction of a price of traditional cloud services.
This is such a cool project. I run a Tor Snowflake node, so the of concept of enthusiasts contributing to a decentralised network interests me.
However it does worry me that I've never heard of acurast... I consider myself pretty well read on the subject of decentralised projects, has it just not taken off?
Is it still easy and cheap to get old, unwanted corporate laptops by the dozens? That seems a better way to go than locked-down-firmware phones
Well, I really don’t like Google, but if they make this a thing, I’d switch to Android and put Graphene on it or whatever just so I could tie into this. This is an excellent idea.
in a weird way - this shows how much of a premium there's with cloud computing, while also showing how much computation power is in consumer devices.
Love to see it! Feels like the sort of give-a-damn that past Google was more about, versus challenging to do at present Google.
> With Google’s support, [researchers at the University of California San Diego] plan to deploy a datacenter built from 2,000 Pixel smartphones
Ah.. well maybe success here will give internal folks some ammo for enabling more reuse of the mountain of Android (and Chromebook) devices.
It’s counter intuitive to me that this is a net carbon win.
- Are these phone processors really as compute-pet-watt efficient as a regular data center processor?
- There’s so little embodied carbon in a phone motherboard - and presumably some embodied carbon in whatever custom racking hardware up is being used to house these. Is that really compute-power-per-embodied-carbon-footprint efficient than making a new server?
I don't have time for an elaborate sourced answer but in short, yes, the efficiency gains of modern devices is almost negligible compared to the CO2e of producing a new device at current device lifespans. I can't remember if you would have to use a device for 15 or 25 years before upgrading is better than continuing to use it, but I thought it was 25
Edit: yes, 25. Found my go-to reference for this quickly after all
> The report about the cost of planned obsolescence by the European Environmental Bureau [7] makes the scale of the problem very clear. For laptops and similar computers, manufacturing, distribution and disposal account for 52% of their Global Warming Potential (i.e. the amount of CO₂-equivalent emissions caused). For mobile phones, this is 72%. The report calculates that the lifetime of these devices should be at least 25 years to limit their Global Warming Potential. —https://wimvanderbauwhede.codeberg.page/articles/frugal-comp...
The carbon cost to produce or use a new phone isn’t relevant here.
The important question is whether repurposing an already-existing phone to act as a server (including physically adapting the phone and producing whatever extra hardware is required to do that) is less carbon-costly than producing and using a new designed-for-the-purpose server.
Producing phones emits a lot of CO2 (or equivalents). It takes more energy to produce, than the amount of energy a phone uses in its typical life.
But yeah, these are great questions which are not obvious at all and should be answered when proposing such a system.
> Are these phone processors really as compute-pet-watt efficient as a regular data center processor?
I have no numbers to back up my argument, but smart phones are very power efficient by their nature are they not? I can play a 3d game, with impressive graphics, on a tiny device powered by a battery... With very little heat generated.
If your goal is to run LLM inference on a gpu in a power efficient manner, I bet a smart phone is a good place to start.
Cool concept, I hope it becomes fully realized, scaled, copied. Created a play prediction question to track that https://manifold.markets/MikeLinksvayer/by-eoy-2030-what-wil...
This would already exist ages ago if mobile computing was more open source friendly.
Beowulf cluster time for old Pixels?
Do many people really have a stockpile of working old phones?
From my observations, phones get destroyed, used until the battery swells and breaks them, or handed down to kids or less careful users. No one I know has a bunch of old phones that are still useful but unused.
I have Nexus 5, Xiaomi A1, Redmi Note 7, Samsung S7, and a Kindle Fire HDX, all running either LineageOS (Kindle) or PostmarketOS (the rest). PmOS ones run some not very demanding containers (scrapers) on k3s.
I have a drawer full of old phones with broken screens, obsolete chipsets, etc. I usually buy phones rather than get them through a contact plan with trade-ins though.
There are recycling and trade-in programs that could collect compatible phones and pass them on in bulk.
They're not useful as phones, because the battery, screen, radio, etc. are damaged; but they may still have a working CPU inside, which would be sufficient for this project.
I have a large amount, some are occasionally useful when debugging.
I did before the switch to volte.
I recycled them wheb carriers decided to block a bunch of phones.
The article mentions the Pixel Fold. I suspect Google possesses every Pixel Fold ever made.
> On average, people replace their phone every four years. This is generally driven by people’s desire for a new device, including for the functionalities provided by new models.
This is so not true. I'm not replacing my phone because I want to. I'm replacing because your stupid updates break my phone and make it unusable. It's called Planned obsolescence
Google will do everything other than let you run stock Linux on a phone.
I've always wondered what that would be like. A fleet of 50 relatively modern flagship smartphones, wiped and retrofitted software wise to act as a homogeneous server, running ubuntu or centos or fedora, something like that.
EMMC in phones has a finite lifetime and dies after a few years of use. That it is not mentioned in the article tells me everything I need to know about its seriousness
A few years? I have a bunch of phones from 2009 around that are still fully working and I have never had eMMC fail on any of them, and they use it for swap among other things. In my experience screens, batteries and USB ports fail much more often.
Phone from 2009 uses SLC, or MLC with large SLC cache, thus capable of at least 10k FDW (full disk writes).
Modern phones typically use TLC or QLC within a inch of their physical limits (signal to noise ratio), thus qualified typically only up to 500 FDW, which translates into several years of use.
There are other mechanisms at play which further degrade this number, such as WAF (write amplification) and others
Just checked the datasheet of the eMMC 5.1 used in my 2020 phone that I use daily now and it's MLC. It also has optional pseudo-SLC mode.
Only the very cheapest phones still have eMMC. I bought a Pixel phone second hand last year and it shows the wear level of the storage somewhere in the settings. I forgot the number but it was so low, extrapolation got me to something crazy like maybe 20 or 50 years of expected use at that rate
That consumer rate isn't datacentre use, but not every task is write-to-persistent-storage intensive. You can also replace the sdcard and write to that instead if this is a worry (that's what I've been doing on my phones since I use them quite intensively; maybe that's overkill nowadays idk)
So did they just make a cloud out of computers that can't run a current kernel? That seems like a pretty big caveat
A google sponsored article mentioning t3.micro chef's kiss
hoped this would happen for a long time but knew it takes a Google sized momentum to make it happen. Formalizing the goal is great and brings it closer to reality
Greeneashing by Google.
I guess the article is targeting regular people. However combining terms like "Linux distro" with other non technical explanations like "useless components such as screens, cameras, etc" sounded a bit weird to me.
Also;
I mean, this is also needed for server applications, more-so than personal use. Reason being in fact a runaway process would interrupt many users rather than a single user in server versus client use cases respectively...> the mobile-oriented Android userspace must be replaced with a general-purpose Linux distro
c'mon Google, release that shit.
Maps Camp Google 2007 -- to the assembled 400+ engineers and guests, at the podium. A calm and thoughtful pitch during the five minute talks "You at Google have a special responsibility, we all do, to make a closed loop industrial ecology with this hardware".. Later that month, bills unpaid, rent payments on credit, the blog EWasteInsights folds after two years.. Silicon Valley Bank has a another boozy party...
Imagine you could buy some serial extendable base station and click all of your old phones in it.
Applications could offload all kinds of tasks.
You dont even need to invent useful applications the community will do it for you. But if you insist, think all kinds of cheap smart devices that offload the smart part.
SETI@phone
... carbon is fungible. Are they sure the effort of recycling them isn't higher than the effort of producing a single modern GPU?
Carbon is fungible right up until you make something out of it, at which point it’s really not without a significant effort. We can’t just take a mobile phone and decompose it back to its component atoms for reuse as something else, recycling is to some degree a myth, and to a greater degree incredibly energy demanding in itself to get things broken down to a level they can be turned into something new.
"lOw-CaRbOn"
[dead]
[flagged]