Brainstorm: less functionality per device, more devices

Jonas Meyer Jonas.M.Meyer.01 at alum.dartmouth.org
Tue Jul 3 10:31:03 CEST 2007


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.

Disadvantages:

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
data.
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.

Jonas




More information about the community mailing list