Brainstorm: less functionality per device, more devices
k-marken at online.no
Fri Jul 6 00:52:21 CEST 2007
On Tuesday 03 July 2007 10:31:03 Jonas Meyer 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.
sorry for the late reply (been away from a computer for about a week now) but
i belive a similar concept was proposed by motorola when bluetooth was first
launched by ericsson. they even got a mockup going by frog design:
never did happen as the bluetooth hype crested, just like the internet bubble
of the 90's...
More information about the community