Brainstorm: less functionality per device, more devices

[ewanm89]

On Tue, 03 Jul 2007 04:31:03 -0400
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.
> 
> 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
> 
> _______________________________________________
> OpenMoko community mailing list
> community at lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community

Get on it then ;)

Seriously though, I'm working on an opensource radio amateur project
(http://hpsdr.org) and we are taking this sort of approach with it, it
is still wired together through a backplane.

-- 
Ewan Marshall (ewanm89)

Geek by nature, Linux by choice.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.openmoko.org/pipermail/community/attachments/20070703/1ed3f857/attachment.pgp