Brainstorm: less functionality per device, more devices
hank777 at gmail.com
Tue Jul 3 22:31:17 CEST 2007
A company called bugLabs is working on this concept.
They have not publicly announced the details of their product, but the
idea of modular (probably open source) pocket consumer electronics
seems to be their focus.
On 7/3/07, Jonas Meyer <Jonas.M.Meyer.01 at alum.dartmouth.org> wrote:
> I just recently got my first bluetooth headset. This is only relevant
> because it got me thinking.
> The typical cell phone (including the Neo) is built upon the idea of
> putting as much functionality as possible into one device. And
> manufacturers have gotten very good at this. What if one took the UNIX
> approach to hardware development. Instead of monolithic do-everything
> devices, create many single purpose devices that do their jobs very
> well, and can be chained together.
> This approach has some advantages:
> 1) Easier (and cheaper) to upgrade. Need more processing power? Add
> another or a smarter cpu pebble. Need gps? Add a gps pebble. Need
> storage, add a storage pebble. Need a camera, add a camera earring or
> watch or ring.
> 2) Cheaper initial investment. A basic phone could be a headset, a gsm
> transmitter, and little tablet UI device. 3 (or maybe you stick the gsm
> transmitter in the ui, so 2) little cheap devices that can be sold for
> tens, rather than hundreds of dollars. However, as a consumer desires
> more functionality, they buy more devices.
> 3) Carry only the functionality you need. Are you going clubbing?
> Probably won't need that gps unit, or the media player. Heading out to
> the woods? Ditch the second cpu, but grab an extra battery.
> 4) Interoperability. By opening the standard up to many manufacturers,
> a more robust ecosystem is created, and the entire platform improves.
> 1) More items to lose. Perhaps they could snap together, like legos, or
> be carried in some sort of bag all together?
> 2) Intra device bandwidth is at a premium. Bluetooth 3.0 is probably
> necessary if you want to keep your storage in a separate device from
> your cpu or your ui. This in turn creates extra demands on batteries.
> Again, perhaps a standard "snap together" interface can carry power and
> 3) Potential incompatibilities. Different devices might not speak the
> same protocol, even if they are supposed to. This can be disastrous
> when your cpu is not from the same company as your storage.
> 4) Potential security risks. Running all that data over the air means
> it is easier to read it, in the event that your encryption fails. And
> since encryption is likely to be run off a chip, rather than a more
> general purpose cpu, security holes are more difficult to fix.
> 5) Harder to write the software. Obviously, this makes your OS about
> 1000% more complicated.
> Anyway, it seems like it COULD be an interesting sort of thing to try.
> OpenMoko community mailing list
> community at lists.openmoko.org
More information about the community