Re: Myth Busting FTW

2007-09-28 Thread Richard Franks
On 8/31/07, Mike Hodson [EMAIL PROTECTED] wrote:

 * Where on any official blogs/websites have you seen the OpenMoko team
 or FIC say that they were making an iPhone killer or anti-iPhone?

It looks like Apple have beaten FIC to the punch anyway:
http://newsvote.bbc.co.uk/2/hi/technology/7017660.stm

Give me a phone that isn't actively fighting against me, anyday!
Richard

___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: Myth Busting FTW

2007-08-28 Thread Richard Franks
Heh! It's an Apple fan site, so you can't expect any attempt at
objectivity - as the forum following up the article shows:

http://roughlydrafted.com/forum/comments.php?DiscussionID=290page=1#Item_0

Given that Apple fans already have the phone of their dreams, it is
quite the compliment that they should feel the need to devote such
time, energy and FUD to attack their perceived 'rival'. As when
Microsoft compared Linux with Communism - the more rabid the attack,
the more insecurity lies beneath.

Oh, and attacking the ideas wiki rather humourously misses the point ;-)

Nuthin' to see here iThink...

Richard


On 8/28/07, Nkoli [EMAIL PROTECTED] wrote:
 Somebody really has their knickers in a bunch.
 http://www.roughlydrafted.com/RD/RDM.Tech.Q3.07/B10AE668-EAD3-46DC-A042-5EF3461D63EF.html
 All that FUD is making me woozy @_@

 ___
 OpenMoko community mailing list
 community@lists.openmoko.org
 http://lists.openmoko.org/mailman/listinfo/community



___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: Neologics

2007-03-07 Thread Richard Franks

On 3/7/07, Jon Phillips [EMAIL PROTECTED] wrote:

This is interesting to see the larger ambitions of the project. It might
also help to expand upon what types of devices could be constructed with
this logic, in addition to neo1973. I'm thinking remotes, media players,
watches, etc...


What if you mated Elite with Yahoo Pipes - instead of RSS feeds, you
have extensible data streams.. and instead of planets you have
conceptual nodes. Instead of trade routes, by clicking on a node you
can see and edit which data streams it imports and exports, and can be
anything from a simple wrapper to the GPS device, to a user, an
application or represent a physical device such as your desktop or
Neo.

Here's an early demo picture, although the lack of structure makes it
look rather too complex at the moment:
http://www.flickr.com/photos/[EMAIL PROTECTED]/413592619/

Instead of adding a security layer later, each node could have its own
private/public key combo from birth, and would (by default) be
authenticated by the node representing the physical device layer. The
user node may use a third-party to authenticate themselves, which
would allow them to travel between devices, or may choose to operate
in a reduced security domain which allows local authentication -
simply drag a new node from your 'parent' user-node, un-check the
security domains you don't want it to access, and allow password
authentication for that 'child' node.

To set up communication between nodes, the device authentication layer
would handle the swapping of public keys - transparently if requested
between multiple physical devices, but the utility arises from this
ability to dynamically create overlapping security domains (e.g. my
work, friends, family, spouse, etc).

I think I've failed in the description somewhat, as I'm still in the
early-prototype stages - but I think it could provide access to
conceptual and physical resources as simple building blocks, which is
fundamental for emergence to flourish.

Richard

___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: Neologics

2007-03-06 Thread Richard Franks

I found the section on emergence/Neoforms _very_ interesting - I've
recently been expanding upon this (
http://www.linuxtogo.org/gowiki/OpenMoko/Ideas/ConceptualFramework )
from which I've going down similar lines of thought - do you have more
ideas about Neoforms?

Richard


On 3/1/07, Sean Moss-Pultz [EMAIL PROTECTED] wrote:

Dear Community,

For those of you who couldn't make it FOSDEM or Etel, I've posted our
presentation here:

http://www.openmoko.com/files/OpenMoko_Neologics.pdf

Happy reading!

-Sean


___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community



___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: Wiki is open

2007-02-14 Thread Richard Franks

On 2/14/07, Tomasz Zielinski [EMAIL PROTECTED] wrote:

It looks like http://wiki.openmoko.org is open to public :-)


Neat!

http://bugzilla.openmoko.org/

is now open too - should be enough info to chew upon for a while :-)

Richard

___
OpenMoko community mailing list
community@lists.openmoko.org
https://lists.openmoko.org/mailman/listinfo/community


Re: Wiki is open

2007-02-14 Thread Richard Franks

On 2/14/07, Piotr Duda [EMAIL PROTECTED] wrote:

and so bugzilla:
http://bugzilla.openmoko.org/


and also:

svn co http://svn.openmoko.org/trunk trunk

:-)

Richard

___
OpenMoko community mailing list
community@lists.openmoko.org
https://lists.openmoko.org/mailman/listinfo/community


Re: OpenMoko / FIC Neo1973

2007-02-05 Thread Richard Franks

On 2/5/07, denis [EMAIL PROTECTED] wrote:

Hello!

Yeah I know that. But don't you think it would be useful to offer interested
users, that heart from others something about the phone, more easy to access
content?


Most of the official knowledge/content is already on the openmoko
website and the wiki - the mailing list sometimes gets tidbits of
information leaked onto it a bit earlier, however these are usually
very-specific technical developer-orientated details. We may discuss
ideas and possibilities on this mailing list, but it shouldn't be
confused with concrete information which holds utility for the
'average' user/

As far as 'official' knowledge/content goes - that the 'average'
consumer could use -the fact that there aren't spectacular/vaporware
promises being made at this stage is somewhat encouraging to me :-)

Richard

___
OpenMoko community mailing list
community@lists.openmoko.org
https://lists.openmoko.org/mailman/listinfo/community


Re: Hint for all webmail-user Re: Hint for gmail-users: How to mute a conversation

2007-01-28 Thread Richard Franks

I do not think that we should encourage or advocate considerate
subscribers to leave, due to the actions of inconsiderate users.

Richard


On 1/28/07, Declan Naughton [EMAIL PROTECTED] wrote:

You can also unsubscribe from the list @
https://lists.openmoko.org/mailman/listinfo/community :)

Other lists: https://lists.openmoko.org/mailman/listinfo/

On 1/28/07, Robert Michel [EMAIL PROTECTED] wrote:
 Salve Sencer,*!


 First I thought your tipp would be to avoid 100 lines of quote by
 using a webmailer



 To avoid that non gmail-users thing that mailing with gmail is more
 comfortable/better than with a normal emailclient my tipp:

 On Sun, 28 Jan 2007, Sencer wrote:

  Hello fellow openmoko users,
 
  For all gmail-users there is an easy way to deal with the threads that
  just won't die.

 Well when you use a normal (good) MUA (Mail user agent) it will thread
 your mails. When you have a filter, that all mails from this mailinglist
 came into jut one openmoko-community mailinglist it feels not like mail-
 flood anymore.

 So with such a
 - separate mailbox
 - MUA (mail client) that organize mail as threads
 I've no problem with thread that just won't die.

 And when you want to access the mails of this list flexible - I use
 the non-GUI MUA mutt, together with GNU-Tool screen and ssh on a
 virtual server I rent for 3 Euro/month (1GB space, 1 Domain, unlimited 
traffic)
 Feel free to ask me in PM (private mail) about this - I dislike
 spreading popularity of big companies services like skype,
 hotmail/gmail (doing money with analysing mails and personal networks)

 Greetings,
 rob

 ___
 OpenMoko community mailing list
 community@lists.openmoko.org
 https://lists.openmoko.org/mailman/listinfo/community



--
Declan Naughton

___
OpenMoko community mailing list
community@lists.openmoko.org
https://lists.openmoko.org/mailman/listinfo/community



___
OpenMoko community mailing list
community@lists.openmoko.org
https://lists.openmoko.org/mailman/listinfo/community


Re: OMG wiki license

2007-01-27 Thread Richard Franks

I think this is all a bit overkill. I don't see any license other than
the description this mailing list is for open discussion and
feedback, for this mailing list.. yet these potentially copyrightable
messages are mirrored by openmoko.com, gmane, etc.

Why isn't everyone being sued?

In our case, the source was either:
a) An intentional email sent without copyright notice, to a
membership-unknown public mailing list, with full knowledge that it
would be stored and made freely available.
b) An intentional edit made to a freely accessible public wiki.

I don't see a legal case being made out of this.

However, if a legal case could be made then linuxtogo are already
liable as they have already published copyrighted material?

http://en.wikipedia.org/wiki/Wikipedia:Copyrights#Using_copyrighted_work_from_others

Note that copyright law governs the creative expression of ideas, not
the ideas or information themselves. Therefore, it is legal to read an
encyclopedia article or other work, reformulate the concepts in your
own words, and submit it to Wikipedia. However, it would still be
unethical (but not illegal) to do so without citing the original as a
reference.

Why don't we take a snapshot of the current wiki, and reword the
content into a new licensed wiki? It's less work than doing everything
all over again, we lose no contributions, and it's an opportunity to
reorganise a bit.

I'll volunteer to do a chunk of that work if we go that route.

Richard


On 1/27/07, David Schlesinger [EMAIL PROTECTED] wrote:



On 1/27/07 3:26 AM, Jon Phillips [EMAIL PROTECTED] wrote:

 On Thu, 2007-01-25 at 16:21 +0100, Harald Welte wrote:
 On Thu, Jan 25, 2007 at 07:29:47AM -0500, Richard Franks wrote:
 then there is no copyright issue as the contributors have implicitly
 put their words into the public domain?

 This is not true and for sure in the US, where the instant someone
 contributes, their contribution is governed under copyright.

Correct. You can't implicitly put anything into the public domain under US
copyright law: you'd have to make a specific and concrete declaration to do
so, or (more usually) simply wait for the copyright on it to expire...

If you're interesting in folding all the Wiki content under the FDL, and you
want to avoid running afoul of potential copyright entanglements, you're
going to have to start over from scratch, I believe.

You're also going to need to have each participant explicitly agree
(probably when their account is created) to get explicit agreement that they
abandon any interests they hold in any content they create on the site and
assign copyright to such content to The OpenMoko Project or whatever. You
might well also want a statement to the effect that any content they submit
must not be derivative of material held under copyright elsewhere and be
free of other encumbrances, etc., etc...

This could get complicated, see...?





___
OpenMoko community mailing list
community@lists.openmoko.org
https://lists.openmoko.org/mailman/listinfo/community


Re: GNU discussion

2007-01-27 Thread Richard Franks

On 1/27/07, David Schlesinger [EMAIL PROTECTED] wrote:

More importantly (and very relevantly to this list) you can't compete for
consumers on a basis of Not as good, but _more free_. If completely open
phones are going to achieve any sort of dominance, then the same kind of
work will have to go into project to support the capabilities that consumers
want.


Exactly - the one bonus that OpenMoko receives, in addition to the
number of developers, is that we're not tied to any Corporate
restrictions in design, contract or politically restricted technology
- new software features 'saved up' for the next marketing phase.



More likely, this will prompt other phone manufacturers to try to find ways
to compete with the iPhone in as reasonable a time as possible. Some of
those ways will likely be based on Linux, and will likely wind up being a
mix of proprietary and open source software, but the net outcome will be
that there will be a larger amount of more capable open source software
available in the product space, and more open source software being used in
more devices like the NEO.


In evolutionary terms, this is a favourable environment for open vs
closed software models. All free software written on open or
selectively open hardware platforms, strengthens free software.

Richard

___
OpenMoko community mailing list
community@lists.openmoko.org
https://lists.openmoko.org/mailman/listinfo/community


Re: GNU discussion

2007-01-27 Thread Richard Franks

On 1/28/07, Corey [EMAIL PROTECTED] wrote:

BSDL contains an inherent self-destruct gene, GPL contains a built-in
propagation gene.


And Non-Free Software contains a built-in propagation gene which
cannot evolve its medium (technology) as quickly as the license-gene
for Free Software can.

But evolution requires competition, and this is why I think the
relationship between free and non-free software is becoming
increasingly sybiotic - when private companies do something which
benefit themselves and improve the quality of Free Software - it's a
win/win for Freedom and Technology.

Richard

___
OpenMoko community mailing list
community@lists.openmoko.org
https://lists.openmoko.org/mailman/listinfo/community


Re: OMG wiki license

2007-01-27 Thread Richard Franks

On 1/27/07, Jon Phillips [EMAIL PROTECTED] wrote:


 I don't see a legal case being made out of this.

Right, but better to protect ourselves. Also, companies, like
FIC/OpenMoko have to take every precaution. So, if we want our content
included, we need to be cautious as well.


Agreed - but I think the risk here is so minimal, that we can decide
upon a license and push the deadline back one week, which would give
contributors a chance to add the new license to their own pages.

Pros:
* We may get revised/improved/edited content by increasing the number
of people involved.
* Intent or nuance will not be accidentally changed.



I also thought about going through and deleting a page, putting a GNU
FDL 1.2 statement at the top of the page, and then summarizing/redoing
the old content. This way, any future contributions are protected.

Cool? Yet again, I propose we do this at 11:59 PM PST SAT JAN 27 so we
can knock this out.

What do you think?


Unless we have any parties - FIC, individual contributors or editors -
who feel that extending that deadline by one week would be putting
them under additional risk, then I'd say +1 week is an appropriate
response to a pragmatic estimate of the extreme unlikelihood of the
occurrence or significance of the threat.

Richard

___
OpenMoko community mailing list
community@lists.openmoko.org
https://lists.openmoko.org/mailman/listinfo/community


Re: Unified Profile Management

2007-01-26 Thread Richard Franks
 Example.  Instead of a calendar app just muting the phone when in a
 meeting (nice feature) it would activate a profile (maybe silent or
 meeting).  Other apps could also use those profiles.  For instance a
 GPS location aware app could know to use the same silent or meeting
 profile when you were at movies, church (or anywhere you wouldn't want
 your phone to ring).

We have the opportunity to re-think 'profiles', they do have their limitations!


 Not only will this make for a MUCH better user experience (less
 redundant work).  It will GREATLY speed up application development (no
 complex interface for what to do just a single simple dropdown what
 profile for this action/trigger).

I'm thinking of something mostly transparent to the end-user, which has
the same benefits you list.. I may finally make some time to get this
off the drawing board this weekend :-)

http://www.linuxtogo.org/gowiki/OpenMoko/Ideas/ConceptualFramework

Richard


___
OpenMoko community mailing list
community@lists.openmoko.org
https://lists.openmoko.org/mailman/listinfo/community


Re: OMG wiki license

2007-01-25 Thread Richard Franks

IANAL (or a hobby lawyer!) but I think if someone has contributed to
the unofficial wiki without checking for a license, and without
specifying their own license... then there is no copyright issue as
the contributors have implicitly put their words into the public
domain?

At least, I think it would be very hard to make a problematic legal
case from this.

Richard


On 1/25/07, Aloril [EMAIL PROTECTED] wrote:

As subject implies I have proposal I fear might lead to long flamewar. I
hope I'm wrong.

Given these assumptions/facts:

1) We want to copy stuff from unofficial wiki to official wiki when it
becomes available.

2) Unofficial wiki doesn't have any copyright statement

1) looks legally problematic given 2)

Proposal:

1) Anybody who has contributed more than few lines to unofficial wiki
gives permission to copy their contribution to official wiki no matter
what license official wiki will use.

2) Statement like You allow your contribution to be copied to official
wiki under license official wiki will be using. is added to unofficial
wiki when user is editing page.

--
Aloril [EMAIL PROTECTED]

___
OpenMoko community mailing list
community@lists.openmoko.org
https://lists.openmoko.org/mailman/listinfo/community



___
OpenMoko community mailing list
community@lists.openmoko.org
https://lists.openmoko.org/mailman/listinfo/community


When Good Agendas Turn Bad - Linux/GNU, etc

2007-01-24 Thread Richard Franks
On 1/24/07 6:11 AM, Dave Crossland dave at lab6.com wrote:

 Hi Sean,
 
 On 23/01/07, David Ford david at blue-labs.org wrote:
 You must be reading a different link.  Sean's email most clearly states
 in the form of a user's manual that will give credit to GNU. He also
 clearly stated We'll just call it OpenMoko.
 
 Could you confirm that if FIC writes that OpenMoko is based on a
 popular free software operating system, that will be described as
 GNU/Linux instead of Linux?

Well come now, you made enough noise and then forced a direct response
out of possibly the busiest person involved in this project.. and
because someone else yanks your chain, you hit back with an even bigger
demand.

Cripes.

There are three sides to this discussion:

1) The side who care about their personal Agenda foremost, and will take
any and every opportunity to present their personal Agenda. Even if it
means misunderstanding or twisting nuance - because, very simply.. the
more we talk about it.. the more free advertising the Agenda gets.

2) The side which thinks that logic or reasoning or well-thought out
debate will change anything - it won't - your words will be mangled into
something which gives side #1 another opportunity to repeat EXACTLY THE
SAME THING AGAIN AND AGAIN (their Agenda), without risking accusations
of spamming blatantly.

3) The side which thinks that this bickering and ill-feeling generated
risks fragmenting our community, makes it harder for genuine questions
to be answered, associates OpenMoko with school-yard politics, and
altogether sets a rather bleak precedent. Sides #1 and #2 are equally
responsible in this scenario.

How about we let our Agenda be the cool technology and innovation
instead?

Richard


___
OpenMoko community mailing list
community@lists.openmoko.org
https://lists.openmoko.org/mailman/listinfo/community


Neo1973: Mobile Phone or Mobile Computer?

2007-01-24 Thread Richard Franks
The distinction may become more relevant if you get hit with a cease and
desist - YouTube has blocked a small company from making YouTube videos
available on mobile phones:

http://www.theregister.co.uk/2007/01/23/youtube_blocks_mobile_video_encoder/

If we have a browser with Flash support capable of displaying YouTube
video, and then run it on the Neo.. are we suddenly going to have to
worry about litigation such as this company did?

We were informed by YT their action was largely due to pressure from
their new mobile partner, Verizon.

Richard


___
OpenMoko community mailing list
community@lists.openmoko.org
https://lists.openmoko.org/mailman/listinfo/community


Re: Idea for OpenMoko: Kid Mode

2007-01-24 Thread Richard Franks
On Wed, 2007-01-24 at 11:33 -0600, Paul Jimenez wrote:
 How about a locked-down 'kid version' of the UI with touchable pictures for 
 'mommy', 'daddy', etc ?  Maybe not even labelled, but just the pictures?

Nice idea - I see where you're going with this, not making it too
complex.. for slightly older kids though, you could also have an add
friend button too, perhaps triggering auto-detection via bluetooth.

Or games which only work at scheduled breaks during the school day.

Most calculator applications I've seen on mobiles really suck.. but that
could be an area of improvement too.

Also, the back-end would not have to be locked down - parents could
still connect to their kids Neo and get whatever information they feel
they need. I'm not sure I'd want to write code to allow parents to
eavesdrop on their kids, but it'd be easy to do once we start networking
our Neo's to home/work machines and that infrastructure is solid.

Schools themselves may find it appealing to be able to restrict
cell-phone use during class, and with bluetooth, there's another option
to distribute homework other than email or paper.. and with the stylus
the kid could do their homework (whilst showing the working), on the bus
ride home.

Richard


___
OpenMoko community mailing list
community@lists.openmoko.org
https://lists.openmoko.org/mailman/listinfo/community


Re: Neo1973: Mobile Phone or Mobile Computer?

2007-01-24 Thread Richard Franks
On Wed, 2007-01-24 at 18:16 +, Al Johnson wrote:
 Getting a flash-capable browser will be another problem entirely...

I wondered about that before posting, but I found this link, so it looks
like options may be available.. although I gather the standard approach
is to have the manufacturer negotiate the license with Macromedia:
http://board.flashkit.com/board/archive/index.php/f-62.html

But I think the bigger issue may be if mobile phones are subjected to
different legislation than your regular PC - I can see the major phone
manufacturers lobbying this point of view to protect and lock-in their
market shares.

Richard


___
OpenMoko community mailing list
community@lists.openmoko.org
https://lists.openmoko.org/mailman/listinfo/community


Re: When Good Agendas Turn Bad - Linux/GNU, etc

2007-01-24 Thread Richard Franks
On Wed, 2007-01-24 at 18:19 +, Declan Naughton wrote:
 On 1/24/07, Richard Franks [EMAIL PROTECTED] wrote:
  How about we let our Agenda be the cool technology and innovation
  instead?
 
 So freedom has nothing to do with it?
 
 I wouldn't be too surprised. I read some nice stuff from Sean alright,
 but IF you just wrote an apt description of our Agenda, it would
 seem, as isn't unusual, that freedom is offered only such that it
 helps towards cool technology and innovation. At that, naturally,
 this wouldn't be a great place to suggest using GNU/Linux instead of
 Linux (and I for one wouldn't be too slow to drop it :) .

I have my own opinions about freedom, which I'd be more than happy to
engage in via personal email.

But I didn't join this list to talk about freedom, I joined this list to
talk about interesting technology and innovation.

Your Agenda is as relevant in this context, as a discussion about gay
marriage, religion or abortion.

Signal or Noise - it's your choice.

If this were a community designed for debating Freedom according to the
FSF, then all would be good.. but I see this continual Agenda pushing
as destructive to the community.

The Free Your Phone post was perhaps the most interesting announcement
we've had yet - Sean thinks we're going to be building the foundation
for Ubiquitous Computing - I think he's right, but this positive message
was completely overshadowed by an external Agenda and childish
bickering.

Richard


___
OpenMoko community mailing list
community@lists.openmoko.org
https://lists.openmoko.org/mailman/listinfo/community


Re: How to get involved (HELP!!!)

2007-01-24 Thread Richard Franks
On Wed, 2007-01-24 at 22:58 +0100, Marc Verwerft wrote:
 Jonathan,
 
 Probably, you're on your own right now. If I were you, I wouldn't make
 a sourceforge project yet as in the announcement of Sean he mentioned
 this:
 * http://projects.openmoko.org/ -- for user-contributed projects  --- 
 That's what you want, I guess.

I don't think it would cause any harm - repositories are easy to move,
especially for the limited scope of pre-hardware apps.

I'd certainly be interested in taking a look at any project, and I would
have put something on sourceforge already if my project ideas had any
functionality yet ;-)

Richard



___
OpenMoko community mailing list
community@lists.openmoko.org
https://lists.openmoko.org/mailman/listinfo/community


Re: Ready For Prime Time?

2007-01-24 Thread Richard Franks

On 1/24/07, Duncan Hudson [EMAIL PROTECTED] wrote:

What about the multi-point touch screen?  It's wonderful, but
doesn't Apple have a patent on that?


I would have thought that whoever owns copyrights for Star Trek should
win prior art for multitouch - the software UI for the transporter
console had that back in the 60s!

Richard

___
OpenMoko community mailing list
community@lists.openmoko.org
https://lists.openmoko.org/mailman/listinfo/community


Buttons

2007-01-23 Thread Richard Franks

There seems to be a bit of confusion about the references to 2
additional buttons, and how they may be used.

1) Are they simple microswitches, or something else?
2) Will they have hard-wired functionality?
3) Does OpenMoko have standardised usage models for them - e.g.
power/profile selection?
4) Where are they positioned upon the phone?

These factors seem to affect whether applications or games can
use/remap one or both of these buttons for their own purposes!

Richard

___
OpenMoko community mailing list
community@lists.openmoko.org
https://lists.openmoko.org/mailman/listinfo/community


Re: an idea: GPS blog?

2007-01-23 Thread Richard Franks

On 1/23/07, Dean Collins [EMAIL PROTECTED] wrote:


The big problem with a lot of these applications being suggested is it will
require back end servers to store the data.

I'm yet to see anyone suggest SAAS pricing models for FIC applications on
a monthly/annual basis or is everyone on this list still thinking that open
source means free.


I'm not discounting this, but I'll be opening up a port or two on my
firewall first - most home-use router/gateway boxes support port
forwarding quite easily now - and with something like xampp, even most
windows-based folks can set up a database server on their home machine
quite easily too.

To connect the 'home-servers' together, you could use dynamic dns or a
centralised server which takes a known OpenMoko-ID and spits back the
current IP/Port and/or operational status.

Richard

___
OpenMoko community mailing list
community@lists.openmoko.org
https://lists.openmoko.org/mailman/listinfo/community


OpenMoko-ID

2007-01-23 Thread Richard Franks

Will we have something like this? Do we want something like this?

It could be useful for contact-sharing, authentication, access to
services on the OpenMoko site, keeping track of gaming friends,
referencing file/data resources on the users home 'or otherwise'
machine etc.

Richard

___
OpenMoko community mailing list
community@lists.openmoko.org
https://lists.openmoko.org/mailman/listinfo/community


Idea: Desktop wakeup on user proximity

2007-01-23 Thread Richard Franks

So when I walk into my office in the morning my computer wakes the
monitor and logs in, opens up a browser with slashdot, etc.

So when I walk towards my house at night, my computer is already cuing
up some music for me.

Detection could be via GPS/data connection, but in many workplaces,
bluetooth detection could be sufficient, plus your Neo only needs to
start up bluetooth when it already knows that it is close to an
activation spot.

Richard

___
OpenMoko community mailing list
community@lists.openmoko.org
https://lists.openmoko.org/mailman/listinfo/community


Re: Idea: Desktop wakeup on user proximity

2007-01-23 Thread Richard Franks

On 1/23/07, David Ford [EMAIL PROTECTED] wrote:

Actually this idea is already in use.  Set up your Bluetooth to
lock/unlock your desktop when you are in the vicinity of it etc.

:)


Ha! I thought it sounded a bit too obvious. We get to enchance the
idea with GPS though.. hmm - two new uses:
1) GPS location looks like I'm a few minutes from the office on a
workday - start coffee machine through a relay.
2) Need Insurance $$$ - start coffee machine through a relay, repeat

Richard



Richard Franks wrote:
 So when I walk into my office in the morning my computer wakes the
 monitor and logs in, opens up a browser with slashdot, etc.

 So when I walk towards my house at night, my computer is already cuing
 up some music for me.

 Detection could be via GPS/data connection, but in many workplaces,
 bluetooth detection could be sufficient, plus your Neo only needs to
 start up bluetooth when it already knows that it is close to an
 activation spot.

 Richard

 ___
 OpenMoko community mailing list
 community@lists.openmoko.org
 https://lists.openmoko.org/mailman/listinfo/community


___
OpenMoko community mailing list
community@lists.openmoko.org
https://lists.openmoko.org/mailman/listinfo/community



___
OpenMoko community mailing list
community@lists.openmoko.org
https://lists.openmoko.org/mailman/listinfo/community


Re: GNU discussion (was re:Free your phone)

2007-01-22 Thread Richard Franks

On 1/22/07, David Schlesinger [EMAIL PROTECTED] wrote:

It simply never ends, does it?


One can hope :-)

Next time I get another argument on this subject in my inbox, I'm
going to simply email this back-to-sender, not the entire list:

http://www.linuxtogo.org/gowiki/OpenMoko/Debate-GNU-Linux

Thus hopefully, we can get back to the fun and interesting stuff!

Of course, it may be vandalised, or 'improved' upon, but I'm also not
going to touch that page again, so go ahead!

Richard

___
OpenMoko community mailing list
community@lists.openmoko.org
https://lists.openmoko.org/mailman/listinfo/community


Re: built-in scripting languages

2007-01-22 Thread Richard Franks

On 1/22/07, Derek Pressnall [EMAIL PROTECTED] wrote:

On a different (but related) track, I've always wanted to have a web
browser that was capable of executing local cgi scripts without the
need for client-side http server.


Pah! Internet Explorer has had that for *ages*.

But for non-windows, this might come a closer depending upon your need:
http://code.google.com/webtoolkit/

As your server-side java classes can be shared with a client-side java app.

Richard

___
OpenMoko community mailing list
community@lists.openmoko.org
https://lists.openmoko.org/mailman/listinfo/community


Re: WiFi

2007-01-21 Thread Richard Franks

On 1/21/07, David Schlesinger [EMAIL PROTECTED] wrote:

What is the rationale behind the exclusion of WiFi?

The long and short of it is that there's no sufficiently low-power WiFi chip
available which has an open driver, or at least there wasn't when the
hardware design got nailed down. It's too late in the process to add one
now, but maybe in some future version of the hardware.

(Whereby we illustrate the need for an FAQ, if only to answer this specific
question...=D)


Done:
http://www.linuxtogo.org/gowiki/OpenMoko/QuestionsAndAnswers

Richard

___
OpenMoko community mailing list
community@lists.openmoko.org
https://lists.openmoko.org/mailman/listinfo/community


Re: Free Your Phone

2007-01-20 Thread Richard Franks

On 1/20/07, Dave Crossland [EMAIL PROTECTED] wrote:

I was requesting that FIC's full title for the system replaces Linux
with GNU/Linux for the good and clear reasons that we are familiar
with, if it includes that name at all.


Linux as a marketing phrase is very well-established, GNU/Linux
may be the 'correct' term, but it's not as marketable by a *very* long
shot:

http://www.google.com/trends?q=linux,+gnu+linux,+gnu/linuxdate=allgeo=allctab=0sa=N

Changing the system title to include GNU/Linux, would increase public
awareness of GNU, but I don't see how it would directly improve the
technology or how it would sell more Neo's, and thus it feels more
like agenda-pushing.

Richard

PS. Are there people who actually say GNU/Linux in conversation and/or
correct themselves if they forget the GNU part?

___
OpenMoko community mailing list
community@lists.openmoko.org
https://lists.openmoko.org/mailman/listinfo/community


Re: Free Your Phone

2007-01-20 Thread Richard Franks

On 1/20/07, Renaissance Man [EMAIL PROTECTED] wrote:


And the more people who are aware of Free Software (as opposed to simply
open source software) and its significance, the more likely Free Software
will prevail and people will continue to benefit from it.


I agree, and I agree that this would generally be A Good Thing. But I
think it that it would make the Neo just a little bit harder to market
- if a potential customer is asking themselves What does a GNU do?
rather than reading the feature-list, then this is A Bad Thing.

I care about the technology first, the more popular the platform - the
quicker Open Source technology progresses. My reasoning is that
simple. Although I support the goals of the FSF, I hold progress ahead
of my political philosophy.

Richard

___
OpenMoko community mailing list
community@lists.openmoko.org
https://lists.openmoko.org/mailman/listinfo/community


Re: what is the difference between openMoko and windows mobile based phones

2007-01-18 Thread Richard Franks

On 1/18/07, hank williams [EMAIL PROTECTED] wrote:

Now I am not saying open source isnt great. But from your *average* users
perspective I would love to hear the advantages of the open source for these
devices. Is this just a geek issue? It seems like most of the apps described
on this list could be done with any of the windows mobile phones. I'd just
love, for my own edification, to hear why this is wrong.


I don't think it's simple enough to categorise neatly right now.. but
think of it in terms of computer evolution - warehouse sized
computers, mainframes, desktop, laptop.. the next stage of that
evolution is a computer you can carry around in your pocket that does
everything you want/need it to. Mobile phones have flirted with that
category for a while now, but their closed nature - artificial limits
placed upon development and software functionality - seriously impede
their potential.

So what I'm banking upon is that mysterious future potential that
comes from fully realising the next stage of computer evolution, and
being a small part of that coming revolution.

You are right in that technically a windows mobile phone could run the
same applications - the source will be open, after all... but that is
then a game of catch-up and if some of the wacky ideas we've collected
so far turns out to be extremely useful and more difficult for large
companies to negotiate, administer and incorporate into their business
models.. then Open platforms will gain market lead purely due to their
agility.

So right now it is a geek issue, which in my opinion will become a
user issue when we start seeing the next generation of mobile
applications.

Richard

___
OpenMoko community mailing list
community@lists.openmoko.org
https://lists.openmoko.org/mailman/listinfo/community


Re: Wish for 2nd generation Neo: USB 2.0

2007-01-18 Thread Richard Franks

On 1/18/07, Sven Neuhaus [EMAIL PROTECTED] wrote:

While you're at it, please include some kind of hardware graphics
acceleration to speed up video playback and maybe allow cooler games...


I quite like the idea of the display being in system memory for games
- quick pixel read times allow for cpu cycles and memory to be spent
on more 'fun' endeavours. For certain types of game you waste more
time trying to approach the read-speed of system-memory graphics.

That said, if we're talking V2, upgraded memory/CPU+hardware graphics
acceleration would please everyone!

Richard

___
OpenMoko community mailing list
community@lists.openmoko.org
https://lists.openmoko.org/mailman/listinfo/community


Re: Neither iPhone or OpenMoko are revolutionary

2007-01-18 Thread Richard Franks

On 1/18/07, Renaissance Man [EMAIL PROTECTED] wrote:

 P.S.: Thanks for finally realising that it is better if you drop
 the debate about including wifi in the first generation device. Be
 it whether the fundamental point people having been trying to make
 to you, got through, or because you decided to move on to
 cheerleading and trolling for some other revolutionary product.

Hey, no problem. Sorry for being so inconvenient as to have a
different view to start with. I know how awful it can be for people
like you if others don't think the same way as you to begin with.


You've won my vote for troll, too.

On the upside though, I'm definitely interested in the possibilities
of using VoIP with bluetooth for home/office, which I wasn't before
this thread started - handy? Yes. Cost-effective? Yes. Revolutionary?
Debatable, but let's not -- I'm upset that the Neo won't come with a
bunch of magical time pixies who transmogrifiy new paradigms into
productivity quanta.. but since I'll have to wait until v2.0 at least
for that, there's no point complaining endlessly about the magical
pixie-less v1.0!

Richard

___
OpenMoko community mailing list
community@lists.openmoko.org
https://lists.openmoko.org/mailman/listinfo/community


Re: is google.com down?

2007-01-18 Thread Richard Franks

On 1/18/07, Bryan Fink [EMAIL PROTECTED] wrote:

 The community archives online are not easily searchable and not the
 best way to get a definite answer.

Gmane to the rescue!
http://dir.gmane.org/gmane.comp.hardware.openmoko.general


Nice! Thanks for the link!

Richard

___
OpenMoko community mailing list
community@lists.openmoko.org
https://lists.openmoko.org/mailman/listinfo/community


Re: Neither iPhone or OpenMoko are revolutionary

2007-01-17 Thread Richard Franks

On 1/17/07, Renaissance Man [EMAIL PROTECTED] wrote:

The reason is neither of them have VoIP via WiFi.

Who do I talk to ask them to include WiFi connectivity with the
OpenMoko? I'll sell my body parts to get hold of such a device.

Why does no organisation (even Apple) seem to get it that the mobile
communications revolution is through VoIP via WiFi. This is the
killer app.


I disagree - VoIP via WiFi is an obvious evolution rather than
revolutionary. I don't think it's a 'killer app' either - in the terms
of the phone manufacturer who is more likely to benefit from getting
6-12months lead and market share in an unexploited but growing market
(Open Source Mobile Phones).

I think that market is going to be revolutionary, and we'll see the
innovation occur upon the Neo1973 first simply because it's going to
be the first of these new toys to play with.

Look at the way that Linux patches come out faster and more
efficiently than Windows patches do - this market situation will
become increasingly bleak for the existing large phone manufacturers
as their old business model won't be able to create and distribute new
features or applications or games as quickly to their proprietary
handsets.

Think about how many geeks ever wanted to own and program their own
Tricorder ;-)

Wifi is going to be great, but the revolution will have already
started upon an Open Source foundation by the time it comes.

Richard

___
OpenMoko community mailing list
community@lists.openmoko.org
https://lists.openmoko.org/mailman/listinfo/community


Re: Gaming oportunities

2007-01-16 Thread Richard Franks

On 1/16/07, Gabriel Ambuehl [EMAIL PROTECTED] wrote:

Unless your game can be controlled with a touchscreen, you won't like it as
gaming device.


I've got a mockup I did for a Gravity Power port I've been putting off
for too long:
http://www.flickr.com/photos/[EMAIL PROTECTED]/359950380/

With a bigger input wheel for the stylus, I think this could work
quite nicely. The darker coloured direction arc's are the deadzone,
one phone button = fire- and I'd imagine it'll be relatively simple to
make this resizeable/transparent/movable/skinnable.

It's physically analagous to the old up/down/left/right/fire joysticks
- in that you can't do up+down at the same time, but you can do
up+right, etc.

Richard

___
OpenMoko community mailing list
community@lists.openmoko.org
https://lists.openmoko.org/mailman/listinfo/community


Re: Non-gprs Internet access options without wifi (cel-dialup)

2007-01-15 Thread Richard Franks

On 1/13/07, Rob [EMAIL PROTECTED] wrote:


Anyhow, I've been thinking about it, and at 9600 baud or whatever it
wouldn't be worth bothering with.  I think what I'll do is build a
little pocket sized battery powered usb hub with an attached usb
802.11 dongle.  While I'm at it, I'll probably put an sd card reader
and an extra usb port or two on it as well.  It could be kept pretty
small by custom building it in an altoids case or something.


You're in Toronto too? I'd buy one!

With regards the home dialup/modem/proxy idea.. I thought it should be
possible to strip+optimise content (e.g. images sent rescaled) and
thus reduce required bandwidth.

Richard

___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: Apple iPhone

2007-01-11 Thread Richard Franks

On 1/10/07, Dave Crossland [EMAIL PROTECTED] wrote:

On 10/01/07, Attila Csipa [EMAIL PROTECTED] wrote:
 Conceptually very similar to the FIC1973, with of course the
 added Apple candy and design team efforts.

I wonder how the FIC1973's graphics capabilities will compare - all
the slick XGL style swooshing around and zooming in makes the
multitouch interface really 'wow!'


Think of it this way though - we get the best of both worlds - a
stable UI foundation means that we can prototype and build whatever
swooshing interfaces we want in specific applications we want (e.g.
one for mapping, a different one for IM), whilst still using more
traditional widely understood metaphors for the day-to-day stuff like
dialing.

Things like 'point  click', 'copy  paste', 'trashcan', 'drag  drop'
are now so obvious to us, that it's easy to forget how revolutionary
these computing metaphors ever were -- the point is that the optimal
metaphors do build upon their 'simple' ancestors.. and that isn't so
much a property of your design team, but emergence/evolution.

With OpenMoko, I believe we'll be able to leverage from these emergent
forces precisely because it is (will be!) open and the UI does not
lock us into highly speculative UI design pattern, which always have
more potential to become an evolutionary dead end.

In a year after release we will probably have two things:
1) Tried and tested new UI paradigms/metaphors.
2) A Neo (released or in the works) which can provide all the 'eye
candy' decoration to those paradigms which we would ever need -
assuming we run into graphical limitations in the first place.

Richard

___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: suggested development toolkit for games?

2007-01-11 Thread Richard Franks

On 1/10/07, Sven Neuhaus [EMAIL PROTECTED] wrote:

Richard Franks wrote:
 In terms of retro gaming though, it's the perfect platform for 2d games:

Unfortunately, in the last 4 years of using a Sony Ericsson P800 phone I've
learned that there're only a handful of decent games (genres) that can be
played well without 5+ hardware buttons (two aren't enough).


Unless it's because a hardware limitation on the touchscreen
interface, I'd have to disagree.

When I say retro, I'm thinking of all the Spectrum/Commodore 64/Amiga
games which worked beautifully with five inputs -
up/down/left/right/fire with a non-analogue joystick.

A 64x64 (resizeable/semi-transparent?) directional input square (on
bottom right or bottom left corner) should be big enough with a stylus
to provide directional input, and fits into the joystick/joypad
physical limitations. This also leaves the option of interpreting
input as analogue, although the platforms mentioned above provided
over a decade of excellent games with just those simple digital
inputs.

In fact, digital inputs makes multiplayer a *lot* easier - each game
round can map the player input into only 5 bits.. which can be reduced
with a 3 bit time-offset if the game allows for retroactive
application of 'world transmittable' events - in most cases ~1/5 of a
second is an acceptable maximum lag. If bandwidth is less of an issue
then you can trade that off for more CPU cycles. Either way, there is
a lot of development flexibility with only 5 digital inputs.

I haven't looked into Bluetooth networking too much, but if it could
be used for multiplayer games, then you've got a *very* attractive
platform for gamers - upload games to friends for free + start
playing.

Fun still beats out the 'wow factor' - case in point: GTA on the PSP.

If the digital input/stylus idea doesn't work, then there are still options:
http://www.gamasutra.com/features/20050602/green_01.shtml
http://www.rav.efbnet.com/1w1b2/results.html

Richard

___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: Apple iPhone

2007-01-11 Thread Richard Franks

On 1/11/07, el jefe delito [EMAIL PROTECTED] wrote:

On 1/11/07, Richard Franks [EMAIL PROTECTED] wrote:
 In a year after release we will probably have two things:
 2) A Neo (released or in the works) which can provide all the 'eye
 candy' decoration to those paradigms which we would ever need -

So we shouldn't expect this hardware to be able to do the fun stuff?


The qualifier was assuming we run into graphical limitations in the
first place. :-)

The user manual does have some interesting clues as to what the
performance *should* be:
http://www.samsung.com/Products/Semiconductor/MobileSoC/ApplicationProcessor/ARM9Series/S3C2410/2410UserManual.pdf

Although the S3C2410 is at the core of the Neo1973, until we start
experimenting with the SoC and integrated components in hardware, I
think we are in speculation land, based upon the premise In theory
there is no difference between theory and reality - in reality, there
is.

But I did a lot of optimisation for 8bit/16bit games as a kid, and as
the Neo1973 is far more powerful than those platforms, I am confident
we can find ways to exceed expectations which may arise from a simple
comparison between the phone specs and modern desktop systems!

Richard

___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: suggested development toolkit for games?

2007-01-08 Thread Richard Franks

On 1/7/07, Andreas Jellinghaus [EMAIL PROTECTED] wrote:

I wrote a game in turbo pascal a decade or two ago.
if I wanted to rewrite it for openmoko, which toolkit
etc. would I use for the graphics and sound effects?


I'd use SDL if/when available, if not.. then there are plenty of
sound/image libraries to take away the pain of gfx/sfx IO. I'd be
surprised if the OpenMoko API did not have its own wrappers for this
anyway, as it's a common function for many applications.

In terms of retro gaming though, it's the perfect platform for 2d games:

* Hardware smooth scrolling support for vertical/horizontal..
* Screen memory held in main memory - very fast pixel read times :-)))
* extra DMA channels to play with
* multiple screen resolutions
* possibility of hacking display driver to optimise speed or create
interesting effects
* you can do a lot with only 4 directional + 1 fire button - lack of
keys not a killer issue

I'm thinking of it in terms as a rather powerful Commodore Amiga
(7.5Mhz vs 266Mhz) and ('blitter' chip vs 4 dma channels).

OpenWorkBench anyone? ;-)

Richard

___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: Killer Application

2006-12-18 Thread Richard Franks

I think it's vital to be able to fiddle with a system, but especially
in Windows applications, the UI design often seems to represent the
features which the developer wants to show off the most, rather than
being directed by how a user interacts with a system.

There is a misconception that you develop a UI for either Geeks or
Grandmothers, but not both at the same time. But reformulated, does
this not simply state that UI design is still an infant science?

Think of it like the VHS vs Betamax 'war', and how many people care
about this now we have downloads and dvds? Yet we have the opportunity
to take the best UI design elements from *anywhere*, we're not stuck
upon one format... Usability and Configurability won't be mutually
exclusive concepts forever -- the Neo1973 is looking like a great
platform to start solving this problem with.

Richard


On 12/18/06, Terrence Barr - Evangelist, Java Mobile  Embedded
Community [EMAIL PROTECTED] wrote:

Gabriel,

Sorry, but I can't leave this undisputed. I agree there is definitely
a line at which a UI is so dumbed-down that it is inflexible and doesn't
accommodate anything but the most basic operations. That is the case
for many consumer applications (including some of the Apple i* apps).
The audience for those applications is very specific and if one needs
more feature-richs apps you can simply install something better.

However, the case of stubborn, lowest common denominator can certainly
*not* be made for OS X. Have you actually ever used OS X? I am a computer
engineer and I do *everything* on my Mac, including hard-core engineering
work. Over the last 15 years I've used most versions Windows, various
flavors of UNIX, and various embedded OSes. I find that OS X gives me
by far the greatest productivity of all systems pretty much regardless
of the task. And at the end of the day that is what counts for me, not
the degree to which I can *fiddle* with a system.

Just wanted to set that straight (and get that flame-war started ;-)

-- Terrence

Gabriel Ambuehl wrote:
 On Friday 15 December 2006 19:53, Richard Franks wrote:
 Apple doesn't have 'killer applications' as such, but each application
 which comes close draws upon a consistent coherent interface - the
 'just works' philosophy. I'd say this is even more crucial for a
 mobile phone as you have less opportunity to 'fix' things without
 ready access to a keyboard.

 Not meaning to start a flamewar, but if your idea of just works is the same as
 the one on OSX, i.e only the lowest common denominator features with a GUI
 that allows one way to do it and one only (i.e. very stubborn) then I'll
 gladly pass on OpenMoko. The one reason I'm not using OSX is exactly the fact
 that it wont allow me to chose how I want to work...

 We have enough dumb phones (even most so called smart phones), why not make a
 smart one for a change...


 

 ___
 OpenMoko community mailing list
 community@lists.openmoko.org
 http://lists.openmoko.org/mailman/listinfo/community


___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community






___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: capacitor to call the police without battery and SIM card *g* Re: Fun with Stolen/Lost Phones..

2006-12-18 Thread Richard Franks

On 12/15/06, Robert Michel [EMAIL PROTECTED] wrote:

Did I alread mentioned the idea to have a capacitor parallel
to the battery? So the Neo1973 cold call the police even without
battery and the simcard and transmitt the coordinates of the phone.
***g*** (of course with black screen...)


Well.. you could implement a virtual battery - say at 5% of the total
battery charge, which could be reserved for 'emergency' type tasks. If
the user chooses to explicitly override this (the option need not be
obscured), then it's with the knowledge of the risks which entail.

The more I think about the anti-theft ideas, the more I start to think
that you can do certain things, like implement locks when the battery
has been removed.. but for the serious thief, or one with access to
the internet, if the battery is removable then there isn't much you
can do.

Now, if there was something like this guy:
http://www.maxim-ic.com/getds.cfm?qv_pk=2917

Whereby, in hardware, the device would require activation for each
uniquely coded battery - possible to do via USB/PC Client... then you
might have the basis for an open security system, as the options boil
down to:
1) Steal phone, keep battery in, no control over what the phone is
doing, who it is talking to.
2) Steal phone, remove battery, unable to get over hardware lock upon
reinsertion of even the same battery.. as the volitile ram holding the
bootstrap code has not been filled via the USB authentication yet.

Along with encrypted filesystems, this could become a very secure
device, as in your handset may be stolen, but your private data can't.
I don't think we can do any better, short of keeping the handset
locked up in a safe.

Richard

___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: Idea: Optimal noisy vibrator

2006-12-16 Thread Richard Franks

If it's anything like this:
http://www.mpja.com/category/DC__Motors/6mm_CELL_PHONE_VIBRATOR_MOTOR_16053_MD.asp

then it could be possible to monitor any current generated from the DC
motor as a result of the phone being moved (along certain axis').

Richard

___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: Something like a Wiki

2006-12-15 Thread Richard Franks

On 12/14/06, Alessandro Iurlano [EMAIL PROTECTED] wrote:

I was just thinking about the lack of a wiki at the actual moment and the
waste of thoughts and energy that will go lost because nobody will probably look
at all the archived mails in the list again.


On the other hand, the list as it is forms the perfect evolutionary
ground for ideas - only those ideas with obvious fitness will keep
getting talked about.. the weaker ideas fall into obscurity where they
belong. If a good idea appears weak, then it's up to the individual to
reshape it until it quacks and walks like a good idea. If the
individual can't reshape it until it looks good, then it probably
isn't a great idea anyway.

As FIC have someone scouring the list for ideas, the chances are even
slimmer that geniunely good ideas with bad presentation will be lost.

A wiki would be nice just now, but as the community knows very few
details for certain, we'd probably fill it with facts which aren't
completely correct.. which in of itself defeats the point of a wiki,
and increases the workload for FIC wrt corrections.

I do have the suspicion that FIC didn't expect the level of community
interaction it received ~two months before release, if that's true,
then they've done a great job with the limited time available!

Richard

___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: GPLv3 and Mobile Phones

2006-12-15 Thread Richard Franks

On 12/15/06, Koen Kooi [EMAIL PROTECTED] wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Oleg Gusev schreef:

 I think any reasonable person understands that wifi/BT was left out

Bluetooth left out? That's not what I heard.


Really!? Cool! Where did you not hear it?

Richard

___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: GPLv3 and Mobile Phones

2006-12-15 Thread Richard Franks

On 12/15/06, Koen Kooi [EMAIL PROTECTED] wrote:

This mailinglist and #openmoko, but I was protesting against presenting
things as actual facts, when things aren't sure.


Dragging this back on-topic, you bring up an interesting example.
Creating an ethic such as information should be free, and then
following it to the letter, isn't always the most positive course of
action. Like giving someone a Christmas present, but telling them what
it is before they unwrap ;-)

But ethics are easier to follow than  thoughtfully considering each
circumstance individually, which is my main beef with the arguments
way above.

Richard

___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: Idea: datatransmission using ultrasound

2006-12-15 Thread Richard Franks
On Fri, 2006-12-15 at 16:08 +, Ole Tange wrote:
 Apparently the Neo may be capable of transmitting ultrasound (20 KHz -
 around 45 KHz). If the Neo is also capable of receiving this (using
 the microphone) then we should be able to transmit data that way. This
 may be useful for close range network (e.g. transmit business card).
 
 The protocol will be similar to wireless ethernet. The range will be
 similar to Bluetooth.

It's definitely a neat idea :-)

My concern though, is that the exact frequency coming out of the Neo is
determined by the physical properties of the individual handset - e.g.
if the speakers are positioned slightly differently as an artifact of
the manufacturing process.. this could affect the range/pitch which is
measurable externally.

It's possible that a Neo could calibrate itself by simultaneously
sampling the pitch it is outputting.. but then you have to factor in
other unknowns like internal resonance, or whether the microphone will
register the pitch at different levels depending on the source
orientation.

I don't know enough about audio engineering to say whether these are
relevant factors or not.. but until we are able to start testing these
things out with production models or an audiologist chimes in.. I'm more
cautious than excited about this possibility.

Even if we did have bluetooth, I still think there would be room for
this idea if it works.

Richard

___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: GPLv3 and Mobile Phones

2006-12-15 Thread Richard Franks

On 12/15/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:


For dessert I'd like the apple pie with no whipped cream

I'm sorry sir, we're all out of whipped cream

Very well. I'll have it without ice cream


[ Error whilst processing directive: 000816 ]

___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: capacitor to call the police without battery and SIM card *g* Re: Fun with Stolen/Lost Phones..

2006-12-15 Thread Richard Franks
On Fri, 2006-12-15 at 21:00 +0100, Koen Kooi wrote:

 A phone that sends an sms to itself every week, how is that going to stop a 
 thief that has
 my phone + simcard?

Hmm. You are absolutely correct - security through obscurity + sneaky
tricks aren't going to work medium-long term. Imagine you wanted to
steal my Neo, how could I stop you from using it?

Does the bootloader reside in SDRam or flash or somewhere else? In other
words, how hard would it be for someone who knows what they are doing to
use a backdoor, to bypass all our userspace security fun?

Richard

___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Global Locate Ephemeris Data

2006-12-13 Thread Richard Franks

Would we be violating the license by redistributing this data, or
additional data based entirely upon that data source to other Neo1973
units?

I'm wondering about the possibility of leveraging off the fact that
all Neo1973 units should have a very unified idea of the current time
to increase the fix accuracy.

For example, if you have three Neo1973s in a rough geographic
triangle, such that:
Neo 1 - has LOS to satellites a,b,c,d
Neo 2 - has LOS to satellites c,d,e,f
Neo 3 - has LOS to satellites a,c,d,f

Each unit computes a positional fix with 5m accuracy as normal, but
all at the same coordinated time.

Scaling this up to a downtown city environment, where you could have
100 Neo1973's with a 5 mile radius... if they all took positional
fixes at the same time, would it be possible to use all of this
coordinated data, plus the ephemeris info, to increase the fix
accuracy?

Richard

___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: GSM security question, mic directly connected to the GSM chip? Re: GPLv3 and Mobile Phones

2006-12-12 Thread Richard Franks

Hurrah Robert!

I'm not an audio engineerologist, however a quick read of the
datasheet shows input/output rates of up to 96kHz.. so the theoretical
highest frequency at that level would be 48kHz.. meaning there may be
room in the non-audible spectrum for comms depending upon the
sensitivity of the mic/speaker components.

Is anyone else excited about having a 96Khz ADC with programmatic
access in their pocket?

I'm still a bit fuzzy regarding whether there is a physical wire
connecting the microphone to the GSM (has its own ADC?), or whether
the 2401 provides the GSM with the converted digtal stream?

Richard

On 12/12/06, Sean Moss-Pultz [EMAIL PROTECTED] wrote:

On 12/12/06 9:43 PM, Robert Michel [EMAIL PROTECTED] wrote:

 BTW: Do you have some more info for us about the audio/soundcard?  ;))
 stereo(?) audio out, 2,5mm jack, frequency 20(?)-2(?)Hz
 stereo(?) audio in(?), 2,5mm jack(?), frequency 20(?)-2(?)Hz

Only because it's you who asked ;-)

http://www.wolfson.co.uk/products/WM8753/

-Sean


___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community



___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Fun with Stolen/Lost Phones..

2006-12-12 Thread Richard Franks

http://en.wikipedia.org/wiki/Teen_Buzz

If the speaker can produce 17.4kHz then it could be sufficiently
annoying to any potential 'teenage hooligan' running off with your
phone.

Add in some remote-access features, such as lock-down, sync/wipe local
data, gps/voice recording+uploading.. if everything worked together,
you could get enough info, then print a message on the screen:

Thank you for borrowing my phone, there is a McDonalds approx 100m
north of your current location.. leave it on a table there and I will
not prosecute. Your voice and locations have been recorded and
uploaded to the internet (see map of your travels below). This means
that destroying this phone, although fun, will not make it harder to
identify you. [i agree] [i disagree]

Upon choosing the latter option, the poor thief would be berated by
whatever messages you like through the speaker:
* I think the Government is Hip!
* Help! I'm being stolen by a silly person!
* I wish to be stolen by someone less inept!
etc, etc

I guess the first stage of lockdown would be cutting off all private
data access, whilst tracking and recording take place.. so that any
outgoing calls could also be monitored and recorded. It would be very
nice to do this monitoring from a web-interface too..

Richard

___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: The audio IC Wolfson WM8753 is cool :)))))

2006-12-12 Thread Richard Franks
On Tue, 2006-12-12 at 17:56 +0100, Koen Kooi wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 Robert Michel schreef:
 
  PS: Again, it seems that an FPGA between the I/O connectors
  and the other chips would encrease the power of the Neo1973,
  e.g. the FPGA could switch the second audio jack to mono output.
 
 As can a GPIO. Stop with the fpga nonsense and get a devboard to play with

That's a little bit harsh, dude. I agree that an FPGA is not a panacea,
but all we have is ideas just now, so there's no harm playing with them!

Richard

___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: The audio IC Wolfson WM8753 is cool :)))))

2006-12-12 Thread Richard Franks
Salve Rob!

On Tue, 2006-12-12 at 18:51 +0100, Robert Michel wrote:
 Sorry, I'm not a electral engineer (student). So how hardware things are
 solved will never be my excellence

Please don't feel the need to disclaim your experience - those of us who
went to university were all students once too ;-) In fact, those people
I met in uni who found the technology fun and enjoyable, were
significantly better off just 2-3 years down the line, than those who
were just there for something to do.. or not to do (UK students seem to
suffer from the latter)!

I've found many of your posts filled with nuggets of inspirational
ideas, and I'd hate to think that yourself, or anyone else would not
post an idea or question because they were afraid to look stupid or
inexperienced due to aggressive 'policing' of the list.

OpenMoko = Open. Whether it's for ethical or pragmatic reasons, whether
you can solder your own circuit boards with your teeth, or whether you
have to get out a manual to figure out how to hold the TV remote
properly.. I welcome all input - please post, people.

Richard

___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: Hurra Richard! Wofson WM8753 ; ) doing distance messuring with ultrasonic?

2006-12-12 Thread Richard Franks

On 12/12/06, Robert Michel [EMAIL PROTECTED] wrote:

Doing distance messuring with ultrasonic?
;))
40kHz example:
http://www.parallax.com/dl/docs/prod/audiovis/Distance28015.pdf


Interesting article... 3.3m ping is not insignificant, especially in
dark/smoke-filled environments. I remember doing something similar
with LegOS (using the infrared port) with the original LEGO
Mindstorms.

I wonder if you could also defend against bears or dogs by playing
with these frequencies.. mind you, 6m away from a grizzly, that UI
better be clean and fast. No pressure ;-)

Richard

___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Neo1973 + PSP == wifi proxy?

2006-12-11 Thread Richard Franks

I dropped the original idea below because of its limited utility, and
this follow-up has even less utility.. however, since there is some
javascript support in the PSP browser.. and the PSP would export its
file-system to the Neo.. it should be technically possible. I wouldn't
like to guess at the approximate bandwidth though ;-)

Richard


On 11/29/06, Richard Franks [EMAIL PROTECTED] wrote:

On 11/29/06, Richard Franks [EMAIL PROTECTED] wrote:
 Oh wait. You mean hosting the HTML file(s) on the Neo? By pointing the
 PC browser to the HTML file on the Neo's memory, you could in effect
 set up a meta-refresh every second or so, or use AJAX to read files
 (requests) from the Neo's memory, and pass them on to the external
 Server as subsequent requests.

 GWT has a nice feature whereby it regards return requests as asyncronous 
events.

 All it would require is javascript support.

Hey! This is the first project idea which we (the community) could
start today and complete even before the first Neo1973 ships, without
access to the SDK or any other data. Booya.

There would be three components:

1) A small utility (cpp? Preferences?) which:
* Runs on the Neo and opens up a localhost port - the Neo would connect to this.
* Sets up a ring-buffer (implemented by files: request1.html 
request10.html)
* Forwards results it receives back from the server (via the browser)
to the localhost client

2) The AJAX part which handles the PC end of the bridge

3) The server utility which speaks to the PC and understands the
Neo1973 requests it receives... or just passes it on in the case of an
SSH tunnel.

There is actually a disconnect on the AJAX-Neo side - not sure of the
best way to get the return data from the browser back onto the Neo's
filesystem for dissemination, without invoking the file-download
dialog. Streaming is one way, but would require kernel hacking to
implement a file as a ring-buffer? If it's not a ring-buffer then you
run out of storage space.

Oh wait, the file the PC browser writes to on the USB stick, can be
implemented as a symlink by the Neo.. to a device instantiated by the
app (1).

Ok, good - did I miss anything? Who wants to help develop this?

Richard



___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: audio link Re: Peer Discovery

2006-12-11 Thread Richard Franks

On 12/11/06, Robert Michel [EMAIL PROTECTED] wrote:

  10 bonus points if it sounds like R2D2.
efficient data transmission via audio mustn't sound well
for the user - DTMF for transmitting your phonenumber
would be acceptable, but the other modulations?


Heh! That idea was intended just for handshaking/swapping business
cards - very small amounts of data. Hands up who wouldn't sacrifice a
little speed, for a phone that shared business cards with a fellow
Neo1973 with cute 'threeps' and 'twerps'?



To beem your virtual business card via audio it would be
nice when the data transmission would be encoded into
a non uggly modification of a voice output:
I'm beaming you now my virtual buseness card - complete


Or multiplexing a higher frequency data signal, if the hardware supports it?



Such a solution could be also run on other smartphones with
java - send and receive business cards and more without
Bluetooth or IRDA nor cable nor online connections.


I wonder if it's possible to support the basic modem signalling
protocol in software? I haven't touched anything like that, but if for
the price of a local phonecall and an old PCI modem, I could call a PC
and encrypt whatever I liked through that connection.. it could end up
being a cheaper, secure, alternative than GPRS?

Richard

___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Blackberry Wishlists

2006-12-08 Thread Richard Franks

I haven't misposted again. No, really.

Inspired by Christopher Heinys thrust, I started wondering about what
actual 'average' consumers want. It's my impression that the
BlackBerry currently holds the crown for the if I wanted a phone that
could also do XYZ:

http://www.google.com/trends?q=blackberry%2C+nokia%2C+motorola%2C+pda%2C+palmctab=0geo=alldate=all

Whilst the number of people searching google for pda remains
relatively constant, over the course of ~3 years, the number of people
searching for blackberry has grown to match the number of people
searching for pda.

Not that this is conclusive in any way - it's just a trend, not an
explanation of such.

So why not look up [product] wishlist on google, to see which areas
can be improved? Interestingly, a lot of end-user gripes seem to focus
exclusively on the closed-source applications - based upon my
five-minute research, I'd say the very act of providing a simple way
for end-users to change/manage their applications for free, is a
massive step forward.

That said, those applications have to grant the wishes out there..
i'll start off with this one:
http://blackberryforums.pinstack.com/1389-blackberry_wish_list.html

Amusingly, note the special significance of Post #2 on this thread.

Richard

___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/cgi-bin/mailman/listinfo/community


32bit/64bit datatype issues

2006-12-08 Thread Richard Franks

We had some major headaches with this - mostly because legacy code
written for 32bit architectures tends to make silly assumptions that
pointers can be cast to integers. But there also a number of tricky
cases where it wasn't immediately obvious that the datatype
discrepancy was the root cause.

As it becomes harder to find 32bit desktop processors, this is going
to become increasingly significant, especially for services or
applications which communicate between the Neo1973 and a 64bit
home/work PC.

I noticed that the GIMP project has its own typedefs (guint, guint8,
gint16, etc).. so I was wondering if OpenMoko will be supplying its
own definitions too? Going into the future, it would mean that there
is a level of protection against having to go back through reams and
reams of code and finding obscure errors that could have been avoided
very easily.

On a more present-day note, if it had native conversions for big/small
endianness, that would be really really nice, too.

Richard

___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/cgi-bin/mailman/listinfo/community


Re: Conceptual/Data Framework

2006-12-07 Thread Richard Franks

On 12/5/06, Jeff Andros [EMAIL PROTECTED] wrote:

On 12/5/06, Richard Franks [EMAIL PROTECTED] wrote:
 I started coding this beast last night. Not much to see, but if it
 garners any interest I'll chuck up on Sourceforge. There are still
 plenty of things to be decided, so if you'd like to contribute code or
 ideas, please do :-)

 Cheers,
 Richard

 P.S. Rereading that first sentence makes me think that Beast is a
 better name than not having a name, but it's all open.


yeah, if you want to put it up somewhere I'd like to give you a hand


Awesome! I've been debating over the last few days whether the scope
is valid. On one hand, it would be very nice to stream data from my
home pc, with a simple call such as:

dataFlow *myVideoFlow =
transformManager-subscribe(homepc:/sharedmedia/video1.avi,
scale:160x120, period:~);

However, I can think up many more uses for abstracted concepts, than
data-streams and there are many more applications which would derive
immediate benefit from a unified source for concepts than
data-streams.

Say you want to do a little post-processing upon the GPS location, to
take account of velocity and acceleration vectors to produce a
prediction of location +5 seconds:

dataFlow *myGPSFlow = transformManager-subscribe(projected GPS
location, delta:5s);

Is that an abstracted concept, or a data-stream?
 dataBlock *myGPSDataBlock = myGPSFlow()-getNextDataBlock();
 float lat = myGPSDataBlock-getValue(lat);

vs the video example earlier:
 dataBlock *myVideoDataBlock = myVideoFlow-getNextDataBlock();
 char *myVideoFrame = myVideoDataBlock-getValue(frame buffer);
 uint32 frameSize = myVideoDataBlock-getValue(frame buffer size);

or availability:
 dataFlow *myAvailabilityFlow =
transformManager-subscribe(workpc:availability);
 dataBlock *myAvailabilityDataBlock = myAvailabilityFlow-getNextDataBlock();
 uint8 myAvailabilityNumber =
MyAvailabilityDataBlock-getValue(numeric availability);
 char *myAvailabilityText =
MyAvailabilityDataBlock-getValue(textual availability);

My point is that conceptual states and conventional data-steams have
many similarities, indeed, the distinction can only be made by the
application which subscribes to it.

However, time-sensitive data-streams - such as audio processing are
going to be tough to handle because they need to have very small
data-blocks to 'simulate' asynchronous processing.. which is where
questions of efficiency start to raise their head with the increased
context switching.

So, I'm considering leveraging from the API similarities for concepts
and data-streams, by focusing on tuning the transformManager for
concepts only -- this means that, if required, low-latency data-stream
support could be integrated fully into the transformManager at a later
date, but the initial release would not be overly cumbersome and would
perform one task fantastically, rather than both tasks less
fantastically.

In that case, a data-stream transform could be written to perform any
task anyway.. but the system would not be optimised for low-latency
high-bandwidth streams initially.

What do you think?

Richard

___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/cgi-bin/mailman/listinfo/community


Re: ideas with SMS

2006-12-07 Thread Richard Franks

Salve Rob!

On 12/7/06, Robert Michel [EMAIL PROTECTED] wrote:

?cologne
I will go to cologne by train on 10.12.2006 14:12h from Aachen central 
trainstaion.


?cologne.*
Have affair at 19:00, don't tell wife or bishop.

The issues I see are:
1) The feasibility of entering all of your day-to-day info in such detail
2) How to logically secure access to that information once it is present

This goes a bit beyond the medium (SMS) and into the mechanism (???).

The latter interests me more as assuming you have this information
available to SMS, you have it available for any other application too?

A computer you carry in your pocket is a very different beast than one
you go to work or university to meet. It knows you more intimately
(location/recent contacts) for a start. Although I suppose that
difference - the ease-of-access to that information is a function of
the reduced complexity of the platform, which is endangered by the
steady advance of OpenMoko. When there's only one of every type of
application - it's easier to integrate.

But I wonder if there are general-knowledge schema's which would
actually benefit the user and aid in collating information?

For example, you enter trip to cologne in your calender, an
unintrusive UI element changes in relation to this - e.g. the phrase
is highlighted. So you follow that link:

* Obtain return date
* Disambiguation - trip to Cologne, Germany vs trip to Cologne
Museum, Stinkville, USA
* Query whether user wishes to enter info about:
- accomodation (if yes - who with? Add contact list entry?)
- business or personal (or, as in this example, both)
- meetings (contact info, specific location details, time etc)
- attractions
* Access info
- notifications?

etc, etc.
But then, assuming this information is available system-wide.. another
utility could independently compare GPS locations with commitments -
one button press to email apology with estimated time of arrival.

Do knowledge based schemas like that exist anywhere in the public
domain? Is it worth the trouble of implementing them?

Richard

___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/cgi-bin/mailman/listinfo/community


Re: Is it portable? [scanned]

2006-12-05 Thread Richard Franks
Will the OpenMoko repository contain drivers for all supported
platforms, or will the drivers be distributed and bundled by the
hardware vendor into a specific SDK - in this case FIC for the Neo1973?

Or is that still to be decided?

Richard

___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/cgi-bin/mailman/listinfo/community


Re: Is it portable? [scanned]

2006-12-05 Thread Richard Franks
On Tue, 2006-12-05 at 19:37 +0100, Robert Michel wrote:

 Explain me - what would be the long term benefit to run OpenMoko on a
 THC device in the next month?

I'm not a corporate marketing-ologist, but surely the more hardware
platforms OpenMoko runs on, the more credibility it will receive.


 Do you just like to have a toy for yourself or do you like to 
 revolutionise? What will be your aim?

I want a sexy toy which I can whip out of my pocket in the street, show
off, and do wonderful revolutionary things with.

Oh wait, wrong list.

The distinction I make is suggesting the lack of distinction between toy
and and revolution - in that the revolution will be 'playing' with small
application components (toys), to create flexible component networks
dynamically without fear of 'breaking' anything.

Sure - LEGO comes with instructions and guides, but the fun is the
unlimited potential - because the hard work was already done by the LEGO
designers to abstract the nuts and bolts of a car into reusable
components.. you can make a car or a plane or a...? You're only limited
by your imagination.

There doesn't exist a platform today which you could just play rather
than work with, in the same way.


 Why wasting time with reverse engineering - when we now have a hardware
 producer we can talk with *directly*?¹

Does FIC produce hardware components, or package them together/send to
manufacturing? I assumed the latter, although, you are right - corporate
weight behind a friendly ear to the communities desires.. a good thing.


 So hacking OpenMoko solutions to a HTC device would be a cool hack,
 but *not* smart it would *not* power up OpenMoko - it would weaken 
 OpenMoko/FIC
 and delay or risk a next Neo version with Wi-Fi and camera.

It's a strong statement to make - I recall reading somewhere that a goal
of OpenMoko was to encourage many different vendors to implement it on
their hardware? Certainly, that was one of the positive points which
drew me to the project, having never before heard of FIC.

I think maybe it's unwise to spend too much time second guessing FICs
business strategy - we have an open communication channel with FIC now,
and it can work both ways if required.

Richard

___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/cgi-bin/mailman/listinfo/community


Re: Small evaluation, city: 4 Internet Cafes, 3 Copy Shops, 2 Photo services; university: 1 library , 1 computer room

2006-11-30 Thread Richard Franks
On Thu, 2006-11-30 at 20:20 +0100, Koen Kooi wrote:

any spare(ish) cycles you have I'd vote for using them to put up a
  basic community wiki - makes it easier for project ideas to get off the
  ground when there's a common source for information, not least with
  relation to the ability to upload design diagrams + status tracking.
  
  Yup - it could become an incoherent jumble, but as a stop-gap until the
  repositories/tracking are in place, it would be ideal.
 
 You could use the http://www.linuxtogo.org/gowiki/ wiki for that till the 
 official wiki
 goes live in 2007.

I see this as an issue of centralisation vs. fragmentation. I'd prefer
to have one source to go to for all things Moko. :-)

Cheers,
Richard

___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/cgi-bin/mailman/listinfo/community


Re: Light sensor

2006-11-30 Thread Richard Franks
On Thu, 2006-11-30 at 11:51 -0700, Jeff Andros wrote:

 It almost sounds like we should make a plugin framework for
 availability detection, with plugins for the light sensor, PIM
 calendar, microphone (can we set an interrupt if the ADC receives a
 level greater than X?) and so on and so forth as people figure out
 other ways to detect it

I'd prefer something a little more generic.. how about considering it as
a network of transforms? Where each transform is a simple plugin, of the
sink/process/source variety?

For example, the physical hardware would be a series of available
datasources, I'll start with the simplest:

(microphone voltage sample)

So a voice recording utility could subscribe to the (microphone voltage
sample) for a duration of its choosing - and it now has a recording.

Except, you may want to filter out snaps and crackles.. so you load the
filtering transform:

(microphone voltage sample) - (snap and crackle filter) - (processed
microphone sample)

The application above can now subscribe to the (processed microphone
sample) instead of the raw voltage sample, if it chooses.

Now say we want to know what the average volume is over one second. We
load another transform (average amplitude), and pass it the parameter
duration:1000ms:

(microphone voltage sample) -  (average amplitude) - (average
amplitude:1000ms)

You could have another application which wants to know what the average
is over two seconds.. so now the (average amplitude) transform is
servicing two datasources:
(average amplitude)
  - (average amplitude:1000ms)
  - (average amplitude:2000ms)

So in the end, the (activity-monitoring) transform would be built from:

(microphone voltage sample) - (average amplitude) - (input1)
(light sensor value) - (average amplitude) - (input2)
(time of day) - (schedule comparison) - (input3)
(time since last user activity) - (input4)
etc etc..

But in the end, you have system-wide consensus with regards whether the
user is active, and each application which cares just has to subscribe
to the (activity-monitoring) data-source to find out.

There's a *lot* of implementation details I've skipped over, but in
essence I think such a system gives the power to grant conceptual
abstraction and system-wide consistency, with simplified and less
redundant development.

Er, in other words, I can't think of another way in which we could avoid
the scenario whereby you have two similar applications which come to
separate conclusions based upon the same inputs - one concludes the user
is awake, the other concludes that the user is not.

Richard

___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/cgi-bin/mailman/listinfo/community


Re: Light sensor

2006-11-30 Thread Richard Franks

On 11/30/06, Tim Newsom [EMAIL PROTECTED] wrote:

 the problem with doing it this way, is you'd need some way to notify
 each application of all the sensors available at runtime, or you
 re-compile each availability sensitive app for every combination of
 sensors (having that many versions of software is sure to turn off
 Sean's dad) there's definately more to think about on this one

Are you thinking of not only notifying each application on the number of
sensors.. (That would be easy enough in the api) but also to let them
have access to the setup/configure api for each one?


Yes - each transform (raw audio, touch screen state, last user
activity time, user availabity,etc) can decide on its own how to
handle subscription requests -- e.g. for when 1 application makes a
request to the same datasource.

Also, another bonus is that you don't need to recompile anything
whenever the transform-network changes - it would change quite often.

When a transform handles its last 'unsubscription', it could unload
itself -- this way resources are saved, and the dead branches of the
network are pruned. When an application tries to subscribe to that
transform next time, the transform-factory which handles the request
can instantiate it - that way you have:
1) User opens 'voice recorder'
2) Application loads, and request is made for (filtered audio:44k)
3) transform-manager creates (filtered audio) with given parameters
4) (filtered audio) makes a request for (raw audio:44k)
5) transform-manager creates (raw audio) with given parameters -
direct hardware interface
6) Another Application makes a request for (raw audio:22k)
7) Transform-manager passes request onto existing (raw audio) with parameters
8) The (raw audio) interface can be written to multiplex its output to
both Applications or create another instance of (raw audio) with the
22k parameter



Enumerating over each sensor that is active would be fairly easy using
the plugin mechanism previously described...  If every plugin had the
same output ranges... Say 0 to 255 or whatever and using the probability
scenario he talked about the application would only need to know one
interface, I.e. Availability.   As I understand the proposal, and I
might be wrong, it would end up a heirarchy.  Lower level plugins could
be accessed at any level but the common usage would be to build
behaviors going up from the sensors and applications would interface
with that... Is that right?


Yup - and because 1 application can share the same logical
processing, you save CPU cycles too.



With that in mind, each plugin would register with some service which
handles the interface to applications.  Each behavior created would do
the same and gain access to the sensors available.  Then a control panel
could be created to enable/disable some but not all plugins at the will
of the user, though that would modify the behaviors, they would then act
on the information currently available.


The flexibility and security of the network both become especially
crucial when you start referencing external nodes:

homepc:(user availability)
bobsneo:(user availability)
tomsneo:(microphone audio)

Upon a subscription to the last one, a dialog would be displayed upon
Toms neo1973 asking whether he accepted that level of security access.
It would then appear in that control panel if it was a brand new
connection.

The higher-risk security vulnerabilities should be a compile-out
option for the cautious ;-)

Although, that would make it very simple to write a little program to
make a walkie-talkie over GPRS.



Seems like a fairly interesting concept.  Do I understand the concepts
or am I missing something?


I think you did a better job than me of describing the idea :-)

Richard

___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/cgi-bin/mailman/listinfo/community


Re: multicolour multi-touch screen Re: OpenMoko/Neo1973 is pure (r)evolution :))) - do you recognized the power of multi-touch gesture recognition

2006-11-29 Thread Richard Franks

Skip all that, and go straight to monitoring EEG brain signals - one
sensor (array), all input handled. Fashion it into a nice hat.

Actually, no.. all I really want to do with the Neo1973 is get a
ring-tone to do the beep beep boop bop from CTU/24.

Now I think of it though.. AGPS/GPRS... urban Counter-Strike! Whenever
you hear the designated call-chime, you can answer and hear
pre-recorded 'mission' data. To which you can respond loudly: What!?
The British Agent is about to have a cup of tea and scones at a cafe
down the road?! I'll take him out.

etc

Richard


On 11/29/06, Robert Michel [EMAIL PROTECTED] wrote:

Salve!

Robert Michel schrieb am Mittwoch, den 29. November 2006 um 20:02h:

 Or for the power user, paint different color points on your finger
 tips (multiple (different) coloured points on one or more of your

Ok nerds would paint their finger tips with colour, but who else?
What about light frequency outside of our cognition?
Or black-light and special colour to use the multi-touch sensor
with multi colour?

Or let us work with the pattern of our fingermarks

The colour finger tips could be an intermediate step
for nerds and developer ;)

rob


___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/cgi-bin/mailman/listinfo/community



___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/cgi-bin/mailman/listinfo/community


Re: Small evaluation,city: 4 Internet Cafes, 3 Copy Shops, 2 Photo services; university: 1 library , 1 computer room

2006-11-29 Thread Richard Franks

On 11/29/06, Robert Michel [EMAIL PROTECTED] wrote:

*IDEA*
  Wait, because these systems support USB mass storage device - couldn't
  we use a normal browser and on download to a FIFO file and an upload to
  a   FIFO  to FIFOs on our server? So no local installation, nor Java
  support (I would have doubts that Java will be allowed to access the
  USB mass storage device, especialy not a USB network device...)
  So with this trick we could run an SSH tunnel via the FIFOs and would
  have Internet connection on our NEO at all these locations :))

  This would avoid the need for and USB eterneth adapter and the best:
  - Our device would be charged during visiting the internet cafe
  - no softwareinstallation on the workstation neccesary
  - no network configuration
  - AND it would work with other people PC/Laptop as well - beeing on
the campus / caffe / airport lounge where other use Wlan - just
ask them to plug in your USB cable and use a ssh tunnel over
bidirectional webbrower to USB mass storage device routing

  I thing this hack would need some keep alive packed from time
  to time ;)


A possible problem with the FIFO-file for networking idea is that it's
a bit trickier to determine exactly when the PC side will send data to
the Neo, instead of caching the file locally. Or maybe I don't
understand the implementation of your idea?

How would the browser 'know' how to automatically use a FIFO-file?  If
I'm in a web-cafe, I hook my Neo into the USB, point the PC browser to
my trusted server.. there's a link missing:
Neo/USB/?FIFO?/browser/server

Now.. you could hack the PC-side to write-immediately to the USB
device, but files are not FIFO in the ring-buffer sense.. that could
be hacked on the Neo end.. hmm.. I guess the results stream could be
just that - the equivalent of downloading a file of unknown size. To
upload (Neo-Server) requests.. that may be more tricky.. because you
want to upload without continuously hitting the 'file upload' dialogue
-- a fetch will (IIRC) see a file of X bytes, and upload just those X
bytes.

Still not sure about the Neo-PC-Server communication path, although
the Server-PC-Neo path is easier but with some hacking.

Oh wait. You mean hosting the HTML file(s) on the Neo? By pointing the
PC browser to the HTML file on the Neo's memory, you could in effect
set up a meta-refresh every second or so, or use AJAX to read files
(requests) from the Neo's memory, and pass them on to the external
Server as subsequent requests.

GWT has a nice feature whereby it regards return requests as asyncronous events.

All it would require is javascript support.

Neat!

Richard

___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/cgi-bin/mailman/listinfo/community


Re: Small evaluation,city: 4 Internet Cafes, 3 Copy Shops, 2 Photo services; university: 1 library , 1 computer room

2006-11-29 Thread Richard Franks

On 11/29/06, Richard Franks [EMAIL PROTECTED] wrote:

Oh wait. You mean hosting the HTML file(s) on the Neo? By pointing the
PC browser to the HTML file on the Neo's memory, you could in effect
set up a meta-refresh every second or so, or use AJAX to read files
(requests) from the Neo's memory, and pass them on to the external
Server as subsequent requests.

GWT has a nice feature whereby it regards return requests as asyncronous events.

All it would require is javascript support.


Hey! This is the first project idea which we (the community) could
start today and complete even before the first Neo1973 ships, without
access to the SDK or any other data. Booya.

There would be three components:

1) A small utility (cpp? Preferences?) which:
* Runs on the Neo and opens up a localhost port - the Neo would connect to this.
* Sets up a ring-buffer (implemented by files: request1.html 
request10.html)
* Forwards results it receives back from the server (via the browser)
to the localhost client

2) The AJAX part which handles the PC end of the bridge

3) The server utility which speaks to the PC and understands the
Neo1973 requests it receives... or just passes it on in the case of an
SSH tunnel.

There is actually a disconnect on the AJAX-Neo side - not sure of the
best way to get the return data from the browser back onto the Neo's
filesystem for dissemination, without invoking the file-download
dialog. Streaming is one way, but would require kernel hacking to
implement a file as a ring-buffer? If it's not a ring-buffer then you
run out of storage space.

Oh wait, the file the PC browser writes to on the USB stick, can be
implemented as a symlink by the Neo.. to a device instantiated by the
app (1).

Ok, good - did I miss anything? Who wants to help develop this?

Richard

___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/cgi-bin/mailman/listinfo/community


Small evaluation, city: 4 Internet Cafes, 3 Copy Shops, 2 Photo services; university: 1 library , 1 computer room

2006-11-29 Thread Richard Franks
On 11/29/06, Koen Kooi [EMAIL PROTECTED] wrote:
  Hey! This is the first project idea which we (the community) could
  start today and complete even before the first Neo1973 ships,
without
  access to the SDK or any other data. Booya.
 
 That isn't true. You can start coding a a pure gtk+ app right now, and
it will run on the
 neo quite well.

You just sank my Booya.

Without access to the SDK/API, or an understanding of the hooks or
capabilities or feature-support in the API, or what screen
resolutions/depths/modes will be natively supported by the first
release, I don't imagine we'll see many *useful* GTK+ apps which take
advantage of the Neos features until then. Yes it is possible, just
terribly unlikely.

So okay - it's the first community project idea I've read which could be
developed, *fully tested*, and be ready to go on day #1 of the release
of the Neo1973, without ever seeing the hardware or requiring more
information than we already know.

Unless it already exists, I'll do some research tonight.. anyone
interested in joining the coding/design effort?

Richard

___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/cgi-bin/mailman/listinfo/community


Re: [Spam?] Re: google earth - [was: Re: Another simple GPS+GPRSidea]

2006-11-28 Thread Richard Franks

On 11/28/06, Sam Kome [EMAIL PROTECTED] wrote:

I _love_ the idea of openstreetmap, but truly doubt that it will retain
enough dedicated participants over time.  Initial capture is not enough;
eternal vigilance is needed to recapture the data everytime a bulldozer
appears or a planning committee renumbers the addresses.


I disagree, I'm not a GIS-ologist, but my assumptions is that
OpenStreetmap, or a similar project, will continue to grow slowly
until:
a) GPS devices become ubiquitous, as does the technology to streamline
and facilitate the acquisition and syncronisation of 'tagging' info.
b) Some corporate or governmental agency acquires the rights to place
such streetmap data into the public domain. Likely a result of
widespread GPS adoption (a).

You are right in that if you look at who is creating these uploads, it
is mostly a small subset of devotees.. however for all the towns and
cities I've lived in, the actual street layouts and names don't change
terribly often.

One thing the Neo1973 should be able to do easily, which would
differentiate it somewhat, is that it could time its GPS acquisitions
to fill in the missing datapoints, by comparing existing datapoints -
if a road takes a sharp bend, the extent of which is not picked up by
the first pass:

[EMAIL PROTECTED]
|
@
|

Then the Neo could compare its own vectors, and the timestamps for the
first pass.. and flesh out the missing corner, add a few more passes
and you've boosted your accuracy.

Dedicated participants, as you say, are only required at the
early-adoption stage because they are the ones who end up creating the
mechanisms which the masses end up using?

Richard

___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/cgi-bin/mailman/listinfo/community


Re: [Spam?] Re: google earth - [was: Re: Another simple GPS+GPRSidea]

2006-11-28 Thread Richard Franks

On 11/28/06, Richard Franks [EMAIL PROTECTED] wrote:

however for all the towns and
cities I've lived in, the actual street layouts and names don't change
terribly often.


Let me qualify this rather anecdotal statement.. I don't think
street-layout/renumberings change often enough to be show-stopper
problem for a project like OpenStreetmap.

If you work a lot with streetmap data, then you probably deal with
renumbering/layout changes on a daily basis. But what percentage of
roads require such changes per year? What percentage of the total
streetmap mileage is affected? Does this occur more frequently in
urban, suburban, or rural areas? I think you'd need to take account of
at least these variables to determine the extent of the problem, and
the ease of the fix.

I'm also thinking in terms of highway maintainance -- if one section
is under maintainance, and traffic from both directions are forced to
share one side of the highway.. then temporary traffic information
could be mined quite easily if the highway is wide enough to draw
conclusions from the offset in expected GPS vectors.

Likewise for accidents, or temporarily blocked roads. All it requires
is a few more programmable GPS devices on the roads who share data,
and you have the basis for an automonous dynamic nagivation system,
which has the potential to report back issues rather quickly.

Richard

___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/cgi-bin/mailman/listinfo/community


Re: Airplane Mode

2006-11-27 Thread Richard Franks

On 11/27/06, Robert Michel [EMAIL PROTECTED] wrote:


Or for those of us who are talking for hours... a voice
message for the owner or both could annouce
dead spots 5 minutes ahead - good connection starts in 30 minutes


I really really like this idea.

Psuedo Implementation:
1) Neo takes a few GPS (Not AGPS) fixes if possible when 'dead spot'
is detected. TTFF not so important here.

2) Neo takes another few AGPS fixes when cell-signal returns. Use simple
heuristics to determine whether more fixes are required to reduce
margin of error to an acceptable level.

You now have one or more vectors - each vector gives you some
indication of the geographic nature of the 'dead-spot' - (position,
speed, heading).

3) Your phone uploads this data, in addition to the time interval for
which no signal was detected, to add to a database of similar vectors.

4) Dead-spots are then calcuated by probability. Of course, some
filtering is required.. but with the time interval, it's easier to
discard the occasions where someone lingers in the 'dead spot'.

Or is dead-spot info already in the public domain?

I think this could also be handy in buildings and on street-level -
where coverage is determined by factors more complex than cell-tower
location.

Richard

___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/cgi-bin/mailman/listinfo/community


Re: A bit more video information

2006-11-27 Thread Richard Franks

On 11/27/06, Sean Moss-Pultz [EMAIL PROTECTED] wrote:

I asked one of our hardware engineers to provide a bit more information
about the video prospects. Here is what he said:

Certainly it can show some fps video. However, the LCD refresh bus
bandwidth will be determined by LCD display size, bit per pixel, memory bus
width, memory type ... and so on. For example, for 640x480,8bpp,60
frame/sec, 16-bit data bus, sdram HCLK = 60MHz:
The LCD data rate = 8x640x480x30/8 = 18.432 Mbyte/s
LCD DMA burst count = 18.432/16 = 1.152M/s
Pdma = (Trp+Trcd+CL+(2x4)+1)x(1/60Mhz) = 0.25(ms)
LCD system load = 1.152x250=0.288
So under such conditions, the neo1973 system bus occupation rate by LCD =
(0.288/1)x100=28.8%


Ah, thanks! You know, I guess I should have started with the
user-manual link on the same page ages ago (well worth a look for
those with a thirst for info):
http://www.samsung.com/Products/Semiconductor/MobileSoC/ApplicationProcessor/ARM9Series/S3C2410/2410UserManual.pdf

The figures above are optimal, but assuming I have roughly the
equivalent of a p100 or so left to play with.. plus hardware
scrolling.. expect a port of the best amiga game of all time..

http://www.lysator.liu.se/~jensa/gf2/
http://sourceforge.net/projects/gp2

It's not currently in any decent language, natch.. but I suspect that
if I create a mini-framework to dev-test in SDL and wrap any SDL
commands cleanly..  it should be a simple(ish) final port.

Hmm.. there's a lot of fun games which could be written upon this
platform.. any old-school game-writers out there?

Cheers,
Richard

___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/cgi-bin/mailman/listinfo/community


Application suggestions - a compilation

2006-11-25 Thread Richard Franks

On 11/24/06, Ben F-W [EMAIL PROTECTED] wrote:

Please note that this list deliberately didn't include promotional ideas
('limited offer' discount etc) or hardware/technical suggestions,
although this line was sometimes hard to draw. My rough definition was
whether it was something I'd expect to explain to an end user without
getting a blank look.


Great work - not a fun task, but much appreciated!

I think your list could be filtered by three main categories (for wiki
purposes):

1) Neo1973 Application Ideas - anything which can run on the
out-of-box device according to the preliminary spec.
* Geolocation based services
* Encryption/Privacy/Security
* Contact Management
* PC Connectivity (home/office)
* Sound
* Video

2) Neo1973 Hardware Hacking - ideas which would require physical
modification or adaptation (including USB devices) to the Neo1973.

3) Neo - Wishlist Ideas - software/hardware ideas requiring
features potentially available in a future model (wifi, bluetooth,
accelerometers, three buttons, etc).

I'm most interested in what I can do with the first category. There is
some cross-over between #2+#3, but the rule of thumb would be - if you
have no idea about the technical details, stick it in wishlist
instead.

Once the categories have been decided upon, and the wiki set up.. I
have a bunch of time this weekend I could volunteer towards migrating
Bens list to the wiki.

Cheers,
Richard

___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/cgi-bin/mailman/listinfo/community


Re: Please go on ;) Re: GPS App idea

2006-11-23 Thread Richard Franks

On 11/23/06, Tapani Pälli [EMAIL PROTECTED] wrote:

 [location tagging]

I think these kinds of things would be doable if user could 'tag'
locations based on available bluetooth or wifi hotspot data. Then later
on device can make assumptions : I can see this wifi now so I must be
at/near location A, I can see paired bt-device which is car's wireless
headset so I must be near users car. System could also store last gps
location when car's headset (or whatever user has customized) was visible.


I'm not sure I understand why transient sources (bluetooth + wifi
hotspots) would be more useful for mapping the locatity than AGPS?  I
mean, even if the Neo1973 did have support for bluetooth+wifi, you
would lose your reference points if someone else turns off their
bluetooth device, or spills coffee over their wireless hub?



 If you park in a public garage you don't have gps, so your app wouldn't
 work.


(see above, could 'fix' this problem!)


Hmm.. the global locate site appears to be down just now, and I don't
know the exact chip used, but the company do boast 'indoorGPS' as one
of their chipset features IIRC. Or it may refer to a specific chipset.

Either way, as you mentioned, there is still a great deal of utility
to be gained from the last-known AGPS location, and unlike
wifi/bluetooth, it's guaranteed to be available to the Neo1973.

Cheers,
Richard

___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/cgi-bin/mailman/listinfo/community


What will you do with yours?

2006-11-17 Thread Richard Franks
In the sense of, which application area interests you the most - if you
intend to develop some software for this thing, how would you categorise
it?

I'm split between syncronising data/content between the Neo1973 and all
my other machines - so I have a single computer system constructed
transparently from multiple disparate hardware nodes, and the innovative
uses which GPS allows for.  e.g. dynamically altering security levels if
my home machine detects that the phone has wandered away from my usual
weekday routine. Or sending me uplifting music if it notices what I'm at
work late.

Or is it still too early for people to start thinking about development
projects without an SDK to peek at?

I'm thinking in terms of all the architecture which is independent of
the Neo1973 - PC-client side apps (e.g. facilitating streaming, remote
access, personal query-servers). Certainly there is no need to reinvent
the wheel, but some thoughts on how to integrate third-party development
could be positive?

Specifically, I'm itching for details on the 'Software Manager' app, and
what is meant by 'software feeds'. Does it extend beyond the scope of
the Neo1973 platform with PC-client side (or web-based) configuration?
If not, could it without breaking the design? :-)

Does anyone else want to share their project ideas?

Cheers,
Richard

___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/cgi-bin/mailman/listinfo/community


Re: Multiplexing SDIO? Re: How to connect Wifi to Samsung's S3C2410? Re: Congratulations to you and FIC

2006-11-16 Thread Richard Franks
 First sorry if my thoughts on this list starts confusion
 (again I'm not a hardware expert) but I like to encourage
 the Neo1973 team to find a desin of the Neo1973 that
 - has much memory
 - has the potential to upgrade the number of memory
 - has the chance for Wifi
 - and no bottle neck for Wifi or memory access

The way I see it, the memory issue is mitigated somewhat by wifi access
-- affordable city-wide wifi (e.g. Toronto) would mean that for most of
my usage, I'd be happy to stream media or data as-required, from my home
machine. In fact, in many cases, it would be preferable to stream/cache
data rather than rely on the download-then-remember-to-delete paradigm.

Yup - that would require additional development to deploy for the
masses, but it could be simplified - assuming one end has a routable IP
and a friendly server to negotiate the initial connection.

Cheers,
Richard


___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/cgi-bin/mailman/listinfo/community