Decommissioned mobile devices as cheap energy-efficient compute nodes
usenix.org
usenix.org
The paper also suggests running a hypervisor on these, but I suspect you'd find that firmware/boot rom locks you out of EL2 (hypervisor mode) on most hardware.
Interesting data points. Have any of these folks written a blog article on the subject?
These sit between the "smartphone" and the untrusted, e.g., public, wifi router, acting as a user-controlled gateway.
The user makes a one-time change to the settings on their smartphone to use the user-controlled gateway. This enables blocking ads and other unwanted outgoing connections without having to be physically at home or work, i.e. in a location where the user can "trust" the network.
The pocket-sized router runs open source software chosen and installed by the user. Users have a generous choice of operating systems, from Plan9 to BSD to Linux, as they do for the RPi. Baseband is either absent or physically disabled.
The main advantage I see to leveraging old "phones" for this is the power supply.
While I have seen small form factor routers made for travel, they are generally not rechargeable.
How are you powering your mAP when out and about?
To power it I use a microUSB cable to my laptop, or a phone charger, or a battery pack with the microUSB cable.
;)
One point that they article doesn't mention is that mobile devices don't have ECC RAM. I'm not very familiarized with the server space, but I thought that was pretty much a standard requirement? e.g. If you're providing IaaS, isn't the risk of falling prey to rowhammer attacks a serious concern?
What I'd love to see is something similar but for home users. Instead of continuing to push stuff into third-party services, you can hook up a mix of devices to run services and applications from home. Bring back the distributed internet dream! Most home services don't need tons of power or high availability. The biggest risk is probably with handling data backups, which you can easily solve by encrypting assets and pushing em up to some cloud provider.
Just don't share devices. They probably don't have worthwhile virtualization anyways.
A bigger problem is that the hardware is shit. Both from a reliability perspective, and from a performance perspective. I just don't think there's a market for this.
https://play.google.com/store/apps/details?id=champion.gnuro...
It's not even that hard to set up, go grab the kernel (some of qualcomm's kernels have these super crappy buildscripts that need python 2.x), build it, throw in busybox and dropbear, fastboot the image and you're good to go.
Since there are probably millions of these, why not recycle into cheap servers given the benefits of their low power use (and the possible ability to draw power to charge during cheap periods and run off battery during expensive ones).
On the other hand, if enough devices of the same type become available for this purpose it might make sense for a business to do this at scale.
The only reason that's true is because groups have catered to the device and have ready-to-go instructions. Were the same effort put into making Samsung S2/S3/S4 etc phones easily converted, I'm not sure the time difference would be all that much at all.
This could then be used as a basis for phone recycling programs: manufacturers could run the collection (and e.g. hand out gift cards for its own new products to encourage the users to turn them in while also profiting from it), and then sell the collected phones in bulk to datacenters.
Becoming a node on a botnet to save $5 is not very attractive.
That said, RPi still has one or two binary blob driver holdouts as well, but I agree there is a world of difference between them in this respect.
The slides are light on details, but if I were doing this, the phones would not be running Android in any case, so while security is an important consideration, you can't just say "but security!" and toss out the baby and the bath water.
Gambiting mentioned elsewhere in the comments that you can install GNURoot from the Play store and run Linux along side Android.
I imagine there is, or soon will be, specific projects to pare down AOSP to the minimum required to run a server without all the extra stuff (that is, the Android part on top of Linux).
1: http://plugable.com/2015/01/22/new-plugable-usb-fast-etherne...
Terminal IDE (on old phones) or termux on new ones should have enough packages to do whatever you want.
You can also grab any rootfs with the right arch and chroot into it if you have root. You can even static link busybox/dropbear and have most of the things you would use on a small server.
Converting abundant power into computation.
https://play.google.com/store/apps/details?id=com.esminis.se...
Based on that I'm pretty sure that the biggest issue with managing the cluster would be the extremely high failure rate.
That's not to say that this won't work because I haven't done the maths, but it kid a unique challenge.
In third world countries, this could be a different story. I would be happy to send my old phones to Africa to be used at schools.
The paper completely ignores the lack of ECC, hardware reliability and lack of software support. Especially if you consider that the majority of mobile gpus don't stupport opencl or don't even have drivers available for modern kernels. You will need to support your software for each device type or rewrite your software as an android app. But since developer and sysadmin time is far more valuable you're better of just buying an x86 server.
You can read it here: http://www.rudyrucker.com/transrealbooks/completestories/#_T...
(warning: Rudy's stories are... zany)
Is a good one too.
You can usually find a rootable phone in Walmart for about $15.