Brainstorm: less functionality per device, more devices

Jonas Berlin xkr47 at outerspace.dyndns.org
Tue Jul 3 11:22:44 CEST 2007


Quoting Jonas Meyer on 07/03/2007 08:31 AM UTC:
> 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.

Yeah!

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

Don't know about cpus but certainly storage and other "snapgets" that (already) work through usb or bluetooth today are interesting.

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

I carry a backpack with me almost all the time. It would be nice to have batteries, gsm, wlan, gps and whatnot stuff in the backpack while having a lightweight display + keyboard and a headset for communication... Otoh the display would require quite a lot of bandwidth.. unless of course the X server ran on the display :D

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

Interesting, although I probably would end up either wasting a lot of time collecting the parts I want or forgetting to switch parts when I go..

> 4) Interoperability.  By opening the standard up to many manufacturers,
> a more robust ecosystem is created, and the entire platform improves.

I think the best would be to use already existing interfaces like usb and extension slots (like iPaq had for example). There could just be some moko-specific "snap-on" places on the back of the phone..

> Disadvantages:
> 
> 1) More items to lose.  Perhaps they could snap together, like legos, or
> be carried in some sort of bag all together?

Yeah, something like that..

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

I would maybe rather have the bandwidth and information sensitive devices to be built in or connected by wired connectors.

> 5) Harder to write the software.  Obviously, this makes your OS about
> 1000% more complicated.

The OS already has HAL and whatnot hotplug stuff. I guess you mean the GUI.. to which I agree, but don't know about 1000% :)

> Anyway, it seems like it COULD be an interesting sort of thing to try.

Heh, a Lego mindstorms snapget would be nice, you could have a lego robot with a computer walking around the house :)

-- 
- xkr47




More information about the community mailing list