RE: atomic clock / radio-receiver chip

[Tim Newsom]

I have one (or something equivalent) in my watch (Casio Pathfinder Wave
Ceptor). It synchronizes the time of my watch every night at midnight.
/shrug

--Tim

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of cdr
Sent: Sunday, June 01, 2008 11:26 AM
To: community@lists.openmoko.org
Subject: atomic clock / radio-receiver chip

> And portable thermonuclear bomb. Just in case. (Well, phone is already
> hand interface to several orbital atomic clocks, isn't it?)

the atomic clock(s) arent orbiting the earth,

to receive the one in Colorado (or Hawaii, 3330 in Canada..), youd need some
chip like Si4735

http://www.silabs.com/public/documents/marcom_doc/mcoll/Broadcast/Radio_Tune
rs/en/Si473x_Presentation.pdf


their doc shows ipods, phones, and handheld PCs.

has anyone besides the DSP-Rado people actually put this in _any_ product,
let alone a phone?


___
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: .Mac like service

[Tim Newsom]

-Original Message-
From: Robin Paulson <[EMAIL PROTECTED]>
Sent: Tuesday, April 29, 2008 6:29 PM
To: List for Openmoko community discussion 
Subject: Re: .Mac like service

/snip

>alternatively, an application to sit 
>on my pc and do all this stuff
>locally would be very useful

To add to this, giving the application the ability to log into the service and 
sync locally, or update the service with more up-to-date info would be useful.

--Tim.


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

RE: Loosing your moko

[Tim Newsom]

-Original Message-
From: David Pottage <[EMAIL PROTECTED]>
Sent: Wednesday, April 09, 2008 8:15 AM
To: List for Openmoko community discussion 
Subject: Re: Loosing your moko

On Wed, April 9, 2008 2:39 pm, Sebastian Billaudelle wrote:

> Yes, i think a "normal" hijacker has no skills to flash the image -
> it is unusual with normal phones. I think nearly all of them don't
> know about a function like the one we are discussing here. But i
> think there is another problem: I don't know if it legal to track the
> position of a person without his/her permission - even if he/she has
> stolen my phone... Will the cops be allowed to use this information?
> There are lots of crazy laws... Is a lawyer here on this list?

Yes, i think a "normal" hijacker has no skills to flash the image - it
is unusual with normal phones. I think nearly all of them don't know
about a function like the one we are discussing here. But i think there
is another problem: I don't know if it legal to track the position of a
person without his/her permission - even if he/she has stolen my
phone... Will the cops be allowed to use this information? There are
lots of crazy laws... Is a lawyer here on this list?

I am not a lawyer, this is my amateur analysis:

As I see it, there are three issues to contend with:

1. Is it legal or ethical for openmoko to keep a database of where
   users are and have been without their explicit consent?

2. In what circumstances should law enforcement be granted access to
   the database of where users are?

3. In what circumstances should the owner of a phone be able to tell
   where it is?

The first issue is about big scary companies keeping big brother like
databases on all their users. We all tend to think of openmoko as a
friendly community effort with no ill intent, but pretend for a moment,
that the phone comes from someone big and scary like Microsoft or
Verzon. Would you be happy about them tracking you by default? Over the
years some tech publications like www.theregister.co.uk have published
scandals and trade conspiracies to reduce consumer choice, invade
privacy and create vendor lock in. I dare say they would have bad
things to say about this plan unless strong safegards are built in, and
we find a way to make this off by default (but still trap anyone who
re-flashes the phone).

My solution to the privacy problem is this: In the box with a new phone
is a card explaining how to create an account with the location DB. The
user would normally setup an account with that DB. If they are paranoid
about privacy, they can throw away the card without doing anything. In
normal operation, the phone contacts the location DB from time to time
with it’s serial number and current position, however if the phone’s
owner has not registered, the DB informs the phone that it is not
registered. The phone will store that setting in non volatile memory,
and will never contact the location DB again. That way, for users who
are concerned about their privacy, or who just don’t read the
instructions, Only one location will ever be released. If the user
later changes their mind the DB registration site will have
instructions on how to manually flip the “send locations” parameter
back to true, via a deeply hidden menu or config file. If someone
re-flashes the phone, then the parameter will be automatically reset.
If it is stolen the rightful owner would have to quickly register with
the DB before the phone is re-flashed.

The second issue is about law enforcement access to the database. If a
bad guy such as a drug dealer is using an openmoko equipped phone, then
the police might legitimately want access to the database to find out
where they have been. Likewise if there has been a serous crime such as
a murder, then the police would want to know who was at the crime scene
during the crime. I think that most community members would agree that
a request for information in these circumstances should be granted. On
the other hand, many people are concerned about warantless wiretaps in
the United States at the moment, and worry that the police might make
big dragnet like requests to invade privacy. For example issuing
speeding tickets automatically if the DB showed that you where moving
faster than the posted limit. In some circumstances the owner of the
phone might want access to the database to prove their innocence for
example to establish an alibi, or to prove that they where not
speeding.

I would suggest that a good compromise would be for the DB admin to
give out to the police information about the movements of any specific
user, or all users who where in a specified area for a specified period
of time, if the request is made by the registered owner or suitably
senor police officer or judge. There is a problem that some law
enforcement agencies might try to bypass any privacy rules we setup,
and try to get a court order for the entire database. To prevent this
we should setup the database in a country with stron

RE: Loosing your moko

[Tim Newsom]

All of this also pre-supposes that the phone is somewhere that gps can actually 
function.  You might also consider using cell tower location (i can't remember 
what its called) to at least get a general area. I saw a demo of this concept 
in the moble google maps application.

Another way to prevent your secret data from being stolen off the phone would 
be to implement something like a web services based storage provider. The os 
could use it like a relatively slow file sytem, over an encrypted link and 
cache it locally and temporarily. Have it sync periodically and auto wipe if 
the wrong password is entered at boot or waking up from sleep / etc. No loss of 
data except what may have been changed since the last sync before you lost it. 
Shouldn't be that hard to implement. Obviously its not for everyone, lack of a 
flat rate or 'unlimited' plan would make it unsuitable. There is probably no 
universal solution.

--Tim

-Original Message-
From: Sean Anderson <[EMAIL PROTECTED]>
Sent: Friday, April 04, 2008 7:45 AM
To: List for Openmoko community discussion 
Subject: Re: Loosing your moko

It's certainly prudent to realise that this is far from a full-proof
phone theft prevention system. I realise it's a little redundant to say
"aaw, but no security is airtight anyway!", but it's worth pointing out
nonetheless.

Encrypted data, a device that phones home... these are all flawed but
noticeable barriers for the potential thief. It is also worth noting
that the data stored on a phone like the Moko (emails, passwords, ssh
keys) is significantly more valuable than the type of data stored on
ordinary cellphones at the moment ("hey, how r u? <3" x 500, some
pictures of people being hit by bins) so it is more important that the
owners of the devices, and the developers, think more seriously about
how to protect the valuable data that is being stored.

The Moko has the hardware and the flexibility, so I doubt it would be a
great deal of trouble to implement a little GPS app that phones home
when it gets lost. 

My main point: the system may also be useful if the user has simply
misplaced the phone and would like to find out if they've left it at a
friend's house or at the pub. GPS is getting accurate enough to
determine which area of the house it is in. It could eliminate the
possibility of it being stolen if it turns up in a familiar location.
How is the Moko user going to tell if they have dropped their phone on
the train and it is sitting unclaimed at the lost & found depot of the
train station? GPS, of course :)

Sean.

On Fri, 2008-04-04 at 12:43 +0200, Alexey Feldgendler wrote:
> On Fri, 04 Apr 2008 07:35:17 +0200, Michele Renda  
> <[EMAIL PROTECTED]> wrote:
> 
> > When I steal the phone, the first thing that I will do is to turn off  
> > the phone. Then because I am afraid to be detected by cell I will change  
> > the internal sim, before to turn on it.
> 
> This is also what happens in Russia. The majority of cell phones are  
> stolen or robbed of people by junkies. They immediately turn the phone off  
> and throw away the SIM card. Without turning the phone on, they bring  
> several phones they've collected during the night to a buyer-up who pays  
> them maybe a tenth of what the phone is worth, and that's enough for them  
> to get their needle.
> 
> The bulk of stolen phones then goes to some phone repair workshops who run  
> an underground business of preparing them to be sold. They reflash the  
> phone or reset it to a clean state because nobody wants to sell a phone  
> with someone's data on it that would be crying out loud “I'm a stolen  
> phone”. They also unlock it if it's locked to an operator, and change the  
> IMEI in those models where it's possible. The next stop for a stolen phone  
> is a second hand mobile phone shop whose owner allegedly has no idea that  
> the phones that strange people bring, a whole box of them at a time, are  
> in fact stolen.
> 
> Because rampant mobile phone theft brings them to the second hand market  
> where they are priced for less than half of what they're worth, it makes  
> them affordable to people who would otherwise not be able to buy a phone.  
> Of course, this happens at the expense of those people from whom the  
> phones are stolen, and who usually buy themselves a new one. Because of  
> this situation, the cell operators in Russia are reluctant to use the IMEI  
> (which is often impossible to change) to track down or at least deny  
> service to phones reported as stolen -- that would shrink their own market.


___
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: Near-field comms (was Re: need someone to develop this....)

[Tim Newsom]

On Nov 30, 2007 4:59 PM, Shawn Rutledge <[EMAIL PROTECTED]> wrote:

> On Nov 30, 2007 1:34 PM, Michael Shiloh <[EMAIL PROTECTED]> wrote:
> > If Bob (or Alice) hands his (or her) phone to the other, then if both
> > phones are shaken in the same hand, the acceleration pattern might
> > provide an extremely unique yet similar signature, not unlike exchanging
> > an encryption key.
> >
> > So if you want to establish a trusted relationship with another Neo
> > user, the two phones are shaken together until the software indicates
> > that you have generated a complex enough pattern that has been
> > recognized on the other.
> 
>

All of this shake shake shake hand waving reminds me of some kind of tribal
dance.
Imagine having your phone in your pocket... you go to a dance club, out on
the floor having a great time and when you get home you discover that you
have accidentally exchanged phone numbers with 2 very attractive women, 1
not so attractive woman and 4 men
All who just happened to be dancing close enough and in the right rhythm
(within tolerances).

I am sure it would be interesting for them too

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

RE: Neo1973/OpenMoko as a laptop replacement

[Tim Newsom]

Since everyone is dreaming of future things, why not add wireless usb to the 
phone in a next generation device?  Then you don't actually need a physical 
connection to drive the display or keyboard/mouse/accessories.
Add to the 'laptop' package the ability to power/charge the phone via one of 
the new wireless methods and you won't need cables at all. Just a 'pocket' or 
slot to hold the phone for charging/etc But other than that, the phone 
could still be in your pocket while using the 'laptop' interface.

--Tim


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

Re: No Camera???

[Tim Newsom]

On Sat, 6 Oct 2007 10:50, Mikkel Meyer Andersen wrote:

Hi,

/snip


 Actually I think a knife would be more usable than a camera :-p

Regards,
Mikkel


Yeah.. But then you wouldn't be able to take it on a plane trip.  And 
people would be making horrible jokes like 'that's not a phone/whips 
out cellphone with knife . THAT'S a cellphone!!!"

--Tim

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

Re: Qtopia coming for Neo1973

[Tim Newsom]

On Wed, 26 Sep 2007 8:57, [EMAIL PROTECTED] wrote:


As far as I'm concerned, this should have ended last week. The original 
question asked was "why continue with OpenMoko development when Qtopia 
is available, faster, more complete and stable?". It was debated and 
some pretty conclusive reasons came out (as posted last Thursday)



1) Redundency is good, if Qtopia fails for some reason, there's an 
alternative.
2) A greater number existing applications can be ported easily to an X 
based framework. There is also precedent in the Maemo >project of 
where this has been very useful.


I'd like to add a 3rd: Competition breeds innovation. :-)


I guess a 4th reason that's come out now is "some people just prefer 
the GTK+ api" and maybe a 5th reason "some people prefer the LGPL over 
the GPL".


So there you go, there's the 5 reasons why OpenMoko development will 
continue.Agree or disagree those are the reasons. Perhaps these could 
be added to the wiki to avoid future debates running over the same 
ground?



Cheers,

Tom

PS: The "faster, more complete and stable" bit refers to the _current_ 
state of OpenMoko and not to what OpenMoko will obviously become.


I guess my only comment is that while I don't really care which 
interface people use on their phones, it seems like the data interfaces 
should be the same... If I open up qtopia phone edition and look at my 
contacts or maybe even edit them and then close it down and open up my 
OM interface and look at them, they should be the same.  All edit are 
visible.. No double entry.


In general, I think that all of that should be possible regardless of 
which interface you use to view/interact with the phone.  Gives a little 
more isolation of the interface from the implementation of where 
everything is, and it gives people the option to switch at any time 
without fear that they need to copy / backup-restore their data when 
switching.  Especially with the relevation about being able to run them 
both at the same time. (Qt has x11 libraries/bindings right?)   So you 
could write qt apps which interact with GTK+ apps through the common 
data infrastructure.

--Tim

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

Re: Yet another finger keybord (gui mock-up).

[Tim Newsom]

On Sun, 26 Aug 2007 11:35, "Andraž 'ruskie' Levstik" wrote:

On 20:15:37 2007-08-26 "Edwin Lock" <[EMAIL PROTECTED]> wrote:
 So you have to get used to it every time again? doesn't seem like a 
very

 good idea.
 My experience is that people like to get used to things and do them
 like the got used to, not change..

 - Edwin



A dynamic input... I like it... But let's put it this way... it 
shouldn't

be to hard to add an option to either use a dynamic input or a
pre-defined/custom
static one. Give the user the final choice. But then that's just me... 
I

like the user having as much choice as possible.

--
Andraž "ruskie" Levstik


Ok, I didn't actually mean after each and every keystroke. I was trying 
to float the idea. The actual implementation would obviously be up to 
some kind of experimentation.


I can't see how removing the unused characters and adding more used 
characters could be a bad thing. Granted you let the user decide to 
switch and always have the ability to go back to default.. But each user 
will have a different vocabulary and thus a different optimization 
specifically for them.


as a bad example take someone who always talks in leet speek when 
messaging.  That will be a very different layout than someone who does 
short hand or abbreviated messaging. If the program could figure out, 
say each night or when the user chooses or what not, which letters or 
symbols they use most and build an appropriate step heirarchy then you 
could optimize the path for fewest drag type operations and more click 
operations. Or at least that's how it seems to me.  Then once the 
sequences are determined, let the user position them on the grid in a 
manner that feels right to them. For each user that might be different.


Anyway, some will like it and some will disable it in favor of the 
default or non-assisted but customly defined layout.  Personally, I 
would not mind having the least used letters changed out for more used 
letters based on my usage patters in a semi automatic way, if I could 
anchor my most used letters to positions where they feel comfortable.

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

Re: Yet another finger keybord (gui mock-up).

[Tim Newsom]

On Sun, 26 Aug 2007 9:36, Lars Hallberg wrote:

Josef Wolf skrev:

[ I warm-up this old thread again... ]
On Mon, Mar 05, 2007 at 12:02:31AM +0200, Lars Hallberg wrote:
a mock-up on a 90-key by one stroke finger keyboard. Think this might 
be an usable and pretty efficient input method.


   http://www.micropp.se/openmoko/
This looks very promising.  I like this idea.  The only issue I see is 
that
the least used characters (numbers) are the easiest to enter.  IMHO, 
the

mostly used characters should be accessible without dragging.


I think it's a good default as it reuses the users knowledges from t9 
systems. It's important to be easy to pick up. But an alternative 
layout optimised for text input is good, as is a possibility for power 
users to define there own layout, or even special layout for different 
programs/tasks.

/snip

/LaH



What about a continuously variable system which starts with the most 
commonly used letters and then adjusts itself based on user input.  It 
could learn which letters a specific person uses to type and make them 
more prominent. Then, depending on modes the programming or web 
searching or other keyboards would automatically adapt to the best 
layout based on the users individual behavior.

--Tim

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

Re: whee!

[Tim Newsom]

On Thu, 26 Jul 2007 19:06, Mark Eichin wrote:


Ok, now I feel stupid.  Guess you get to call me a muppet after all :-}

The batteries and cards were all wrapped together in one of the foam
cutouts.  I don't know how I missed it this morning, when I got home I
went through every compartment to double check and they were right
there.  (I think I saw "white, shiny" and thought "must be
documentation".  Or maybe I just hadn't had my coffee yet.)

Apologies to all involved!



Actually... They tracked down your shipment by tracing the gps location 
as reported by your phone back to the mothership. They just added those 
components while you were out to make you look like a muppet. /grin.


Joking.. Of course.. Good to see you found them.
--Tim

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

Re: Data Link Disable Capability?

[Tim Newsom]

On Thu, 26 Jul 2007 12:32, Giles Jones wrote:

Anything and everything is possible.


Obviously, you mean this withing the realm of programming openmoko.  
Otherwise, its a very broad and bold statement.  /grin

--Tim

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

Re: another linux platform platform

[Tim Newsom]

Err... That was supposed to br linux phone platform...

On Thu, 26 Jul 2007 8:35, Tim Newsom wrote:

I just noticed this:
http://www.linuxdevices.com/news/NS5539544742.html

They claim to have many of the features we have talked about on the 
list... however, I am wondering about the "pending patent" related to 
placing security in the bootloader for signature checking of a boot 
image.  Does anyone know if this is available GPL or if they have 
somehow managed to get around all of that?


--
-- Tim

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

another linux platform platform

[Tim Newsom]

I just noticed this:
http://www.linuxdevices.com/news/NS5539544742.html

They claim to have many of the features we have talked about on the list...
however, I am wondering about the "pending patent" related to placing
security in the bootloader for signature checking of a boot image.  Does
anyone know if this is available GPL or if they have somehow managed to get
around all of that?

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

Re: Camera on GTA02

[Tim Newsom]

On Mon, 23 Jul 2007 10:27, coomac wrote:


Rather than alienate one group over the other, why not have something 
for both? A non camera version for those who don't need the feature as 
well as a camera version with the exact same specs for those who can't 
live without it? I mean, why have a chip with camera support if there 
are no plans to use if fully? Tag on a $50 difference or something. 
Problem solved. It won't be feasible in the near future if it involves 
a major holdup or deviation from the current product, but if it's 
doable, why not?


Guys & Gals...
There have been talks of add on packs that let people increase thickness 
of the case and do things that were not really intended originally.  
Since we have a pretty strong idea that the GTA02 will not include a 
camera.. We can add it as a wishlist item for GTA03.. And no need to 
argue over it.


BUT there is the chance that some kind of addon pack could be made for 
the GTA02 after its sold.
In this case, a production molded back plate could be included so no 
drilling would be required.
If its planned out right, these addon packs could be simply "unscrew 
backplate, snap new addon pack down, screw on backplate, install new 
software".


Now I will also be the first to say that it won't be this easy in the 
beginning... But it *could* eventually.


For Instance, forget about connecting with the camera pins if they are 
not exposed and use something else, we have (maybe not optimal) I2C,
Spi?.. But how about an option that doesn't require wires?.. Say 
bluetooth, wifi... Maybe use I2C to control the device and bluetooth to 
transfer the data..


The point is, that for now its not going to happen.. But think a little 
outside of the box for ways to make it happen as an option.

--Tim

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

Re: Marketing...

[Tim Newsom]

On Fri, 20 Jul 2007 17:47, [EMAIL PROTECTED] wrote:
/snip
user friendly to move between the 2..  Videos need atleast a converter 
app

to run on windows to resample to something the neo can handle with the
simple push of 1 button..



/quietly patents 1-Click converting
--Tim

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

Re: ringtones?

[Tim Newsom]

On Wed, 18 Jul 2007 17:02, Jeff Andros wrote:
I haven't used a mac other than casually (checking email) since os9... 
so I'm not so up on growl.  I'd like basically arbitrary code 
execution, but with some (read LOTS) of protection on how that gets 
registered (can't let Sean's dad install malware that fire off every 
time the phone rings, can we?).   I'm also still liking a shell script 
that gets fired off, yeah, it's got a bit of overhead, but if you get 
into binary programs as fast as possible, and just use the script to 
link up the purpose built programs ( I.E. the whole reason shell 
scripts exist) it might not be too bad... something to investigate I 
guess




Why not use something like a sandbox?
I found a something on sourceforge something like 
sandboxing.sourceforge.net... But basically it just prevents 
applications in the sandbox from doing things without permission.  And 
it can be set to either send an error or block and send an event to some 
queue for other action...


Seems like we can set it up so that:
The installer is trusted...
Signed applications (with approved cert) can be auto full trusted
User can choose to give trust levels if desired...
Etc..

If its flexible enough, might this (or something like it) provide some 
or most of the unauthorized program access protection we want?


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

Re: projects of interest? - mebot

[Tim Newsom]

On Wed, 18 Jul 2007 12:10, Mark Rossman wrote:

First off I think the largest amount of time would be to calculate the
distance between each possible combination of points, and I think most
people wouldn't really have that many points anyway.  Now if UPS
decides to offload their routing onto the cell phones of their drivers
it would take forever, but most people don't really go that many
places.

Also if you set up the software to solve the TSP problem as an IP,
then used the LP relaxation as your actual problem you would greatly
reduce computation time, and get a list of possible next stops ordered
based on their weight, most of the time it would give you a near
optimal solution.



I think you said that much better than I did.
--Tim

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

Re: projects of interest? - mebot

[Tim Newsom]

On Wed, 18 Jul 2007 12:51, Brad Pitcher wrote:

Actually, I was thinking of offloading that work to a mashup like
interface.. Say google maps or what not and just displaying the result.


But google maps doesn't reorder destinations to create the optimal path 
does it?


No idea.  That's why I said "or what not" /grin.
I know you can build maplets.. But I have never done it and I don't know 
what possible there. I am going to assume that you have the ability to 
enter a starting point... (Maybe where you are right now).
Then if the mapplets are just plotting functions the best you can do is 
find a route.  However, there are functions to find the shortest 
distance, shortest time etc.. A test would need to be provided to see if 
you could enter a set of gps coords as "waypoints" or whatever you call 
them and then say map by shortest distance.  Maybe it only works in the 
order you provide the points.
In that case, (I think mapplets are only Javascript but I don't know) 
assuming there is a programming interface you could upload to the 
mapplet a set of points and the starting point... Then it could iterate 
through the remaining possibilities till it finds the route...


I.e. What the distance from start to each point...
Find the shortest and then find the distance from that one to the ones 
remaining.. Continue until completed. That gives you the order for the 
points.
Really, you could guess the order based on distance between gps coords, 
but that won't take into consideration road length... I.e. From the top 
of a mountain to the bottom might be 3 miles based on gps coords, but 
due to the winding roads its more like 10 or 15... Kinda big error 
there.


Anyway, if you include an external server and sufficient software the 
rendering could be pretty quick. And I am guessing most people won't 
have more than 20 or 30 places to go in a day... But even at 100, the 
sorting time could be pretty small.


I grant you, its not the most efficient algorithm.. But it should do the 
trick.


You could add additional features such as end where you started... So it 
could balance the travel with the last few stops closest to where you 
began, etc. Many ways to do that.


Or another variation on this theme, assuming you have access to a 
directory listing, traffic and weather data and you know the category of 
some tasks (groceries, gas, books) or maybe the category of locations 
(grocery store, gas station, book store) or how about a specific one in 
case you have a preference (76, chevron, barns and noble, safeway or 
albertsons) - btw, I am in the USA so exchange with names in your 
country -


Then once the tasks in your lists are categorized have the mapped route 
take you to the closest places based on those and sort in the shortest 
time or distance and take into account traffic and weather conditions.


Anyway, its just an idea built upon an idea.

--Tim

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

Re: projects of interest? - mebot

[Tim Newsom]

On Wed, 18 Jul 2007 11:27, Jeff Andros wrote:

On 7/18/07, Tim Newsom <[EMAIL PROTECTED]> wrote:



You could expand this a little and possibly select items from multiple
location lists and then select
"Find the shortest route to complete all tasks"




--Tim


just don't expect it to do so very fast... and make sure it runs as a 
REALLY low priority


http://en.wikipedia.org/wiki/Traveling_salesman_problem
http://en.wikipedia.org/wiki/NP-hard

--
Jeff
O|||O


Actually, I was thinking of offloading that work to a mashup like 
interface.. Say google maps or what not and just displaying the result.


--Tim

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

Re: projects of interest? - mebot

[Tim Newsom]

On Wed, 18 Jul 2007 7:40, Marc Verwerft wrote:

On 7/18/07, Emre Turkay <[EMAIL PROTECTED]> wrote:

I'm planning to use it to implement a GTD[1] utility.


Yes!


Consider there is a simple market-list application, in which I note
the stuff I need to buy from market, time to time. When I approach to
the market moko starts an audio alert and tells me to stop by the
market to buy stuff. When I enter the market automatically pops up my
market list.


My wife would love this :-)



I'm thinking about a plug-in architecture so you can extend this idea
as far as it goes, bugzilla integration, mail client integration, web
browser integration, integration with an outliner/mindmapper, project
planner, tomboy, etc. Every new plug-in will open a door to another
cool idea.

Started to write it a couple weeks ago, got a sourceforge account[2].
There is a very trivial demonstration application on subversion and as
a tarball download.

If there is anybody interested I would love to discuss.

I'm sure willing to test it ...



[1] http://en.wikipedia.org/wiki/Gtd
[2] http://mebot.sourceforge.net

emre



You could expand this a little and possibly select items from multiple 
location lists and then select

"Find the shortest route to complete all tasks"
And have it map the entire selected list of waypoints in some order.. 
Possibly even order by the number of tasks/items in any one location to 
optimize the amount of work completed.


--Tim

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

Re: Not "the free phone" (was: Re: Again: Advertising thoughts

[Tim Newsom]

OK.. Great minds think alike... Or maybe not. /grin

On Mon, 16 Jul 2007 12:11, Shawn Rutledge wrote:

How about simply the youPhone, or uPhone?

On 7/16/07, Ian Darwin <[EMAIL PROTECTED]> wrote:


 I completely agree. My idea is to make two advertisment campains: 
one on

 "maisntream media": maybe tv, maybe radio, flyre, poster, newspapers,
 wathever.  This ads would be something like: "The free phone, 
OpenMoko.

 The only one with " "The OpenMoko: now with builtin navigator" and
 so on. Don't even THINK of using "based on Linux Kernel 2.6.xx" or 
"With

 powerful ssh acess"


Calling it "the free(d) phone" to consumers (as opposed to developers)
is going to engender an enormous amount of confusion and ill-will.

Why? Because (at least in North America) the major carriers have spent
years, and billions of dollars, totally subverting the meaning of the
phrase "free phone" to mean "we give you the cheapest phone we can find
and don't charge you for this piece of junk when you lock into a two- 
or
three-year plan at some exorbitant rate that obviously includes the 
cost

of the phone amortized."

Seriously, ask consumers what a "free phone" means. at least 11 out of
10 will give you the definition above, at least the parts they 
understand.


A consumer ad campaign is NOT the place to push the "free as in beer vs
free as in speech" argument. The phrase "free phone" already means the
opposite of what we want it to mean. It's done, finished, over. Move 
on.


Call it something else in the consumer market. The Flexible Phone. The
Does-what-you-want-not-what the big corporations want. I don't know.

___
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

--Tim

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

Re: Fwd: Not "the free phone"

[Tim Newsom]

On Mon, 16 Jul 2007 11:28, Daniel Bartholomew wrote:


Well, since Apple has gone iThis and iThat with everything and dropped
their use of PowerThis and PowerThat, why not co-opt that?

How would you like a PowerPhone?

--
Daniel Bartholomew


Well, in a similar vein (throwing in my own silly thoughts..) Why not 
call it the UPhone...


UPhone.. Make it what you want it to be...
UPhone.. Its your phone, do what you want with it..
UPhone.. What do U want on it?

Lol.. Ok, very silly.
--Tim

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

Re: Charging the NEO1973

[Tim Newsom]

On Thu, 12 Jul 2007 9:42, [EMAIL PROTECTED] wrote:


Or hack a USB socket onto one of the many discarded 5V chargers you 
have lying
around. If your house is like mine, they seem to show up out of 
nowhere.


Michael



So that's what happens to all of the 5v chargers I place in the drying 
machine!! Now if I could only find out where the socks go

--Tim

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

Re: NTT-NoGoMoKo in Japan, plus falling back

[Tim Newsom]

You misunderstand... What I meant was " Is 3G backward compatible for 
data with previous formats." Plus, i thought that only the US had any 
kind of cell company which uses cdma. I am quite surprised by that as I 
thought most if not all other countries used GSM. /shrug.



On Sun, 8 Jul 2007 12:55, Mikko Rauhala wrote:

su, 2007-07-08 kello 12:00 -0700, Tim Newsom kirjoitti:

 Um... Japan does have GSM service...  I am positive as I recently had
 guests in my house from japan. They brought their cell phones and I
 showed them how to make them work in the US.


Means nothing. Their phones may be GSM-capable spesifically to work
overseas. All of my info says that there's no GSM in Japan, but I
haven't rechecked recently


 Does EDGE fall back to gprs?  Does 3G fall back to EDGE or GPRS if the
 phone doesn't support it?


Given a phone that supports all of the following, HSDPA will fall back
to plain old UMTS will fall back to EDGE will fall back to GPRS,
according to network availability. Japan, on the other hand, uses their
own types of (W)CDMA networks.

"3G" falling back to EDGE or GPRS if the _phone_ doesn't support it is
rather nonsensical notion. If a phone is a GSM phone, it will work in a
GSM network. It will not work in a 3G network, so there's nothing to
fall back _from_.

--
Mikko Rauhala   - [EMAIL PROTECTED] - http://www.iki.fi/mjr/>
Transhumanist   - WTA member - http://www.transhumanism.org/>
Singularitarian - SIAI supporter - http://www.singinst.org/>


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

--Tim

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

Re: Linux

[Tim Newsom]

Um... Japan does have GSM service...  I am positive as I recently had 
guests in my house from japan.
They brought their cell phones and I showed them how to make them work 
in the US.


As far as I know... Granted, making them work in the us meant dropping 
the 3g and switching to GSM service... But since the option was 
available in a japanese phone it would seem to indicate that they can 
use it.  PLUS so called world phones or quad band phones include GSM 
service frequencies for other places and I am pretty sure one of those 
is Japan.


I could be wrong... But I don't think I am.
It just might not use the 3G mode but only GSM and it might mean that 
the extra internet capability might not work.


Does EDGE fall back to gprs?  Does 3G fall back to EDGE or GPRS if the 
phone doesn't support it?

I think those are the right questions.

--Tim
On Sun, 8 Jul 2007 11:13, David Pottage wrote:

On Saturday 07 July 2007, Vicente Alcañiz Buceta wrote:


 I just want to have a Linux mobile phone but maybe is not going to be
 release in Japan???


As Jason Elwell says, the Linux mobile phone is released today, so you 
can buy
at the unsubsidised price. Unfortunately you won't be able to use it in 
Japan

(or Korea) as it is GSM only.

I guess if you are realy keen, you could buy one as a Linux PDA, or to 
develop
software, but otherwise, you will have to wait and hope that FIC 
produce a 3G
model with W-CDMA support some time next year, that you will be able to 
use

on the Softbank (formerly Vodaphone) network.

--
David Pottage

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

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

Re: Location Privacy Protocols, was Re: GPS trail - crazy idea

[Tim Newsom]

On Fri, 6 Jul 2007 12:25, Wolfgang S. Rupprecht wrote:

Another good reason from an open-source product.  Maybe there is a
vast untapped market for selling open-source phones to the governments
of the world (to protect them from the other governments of the
word. ;-))

-wolfgang


Except that as far as I know (someone please correct me if I am wrong ) 
the GSM part is the side which the telcos can tap into for their 
readings and its closed to us. We can be open everywhere else and unless 
we have the firmware to the GSM piece we could not prevent the telcos 
from tracking us.  Its possible that the government has specially 
designed phones but I don't really know. It may not even be in the GSM 
piece, but at the tower and control center that they track you.. In 
which case there is nothing you can do even if the firmware were open.


Again, that's just guessing.
--Tim

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

Re: Custom case designs... (the business perspective)

[Tim Newsom]

Note...

I did ask about permission and we were told to wait on discussing with 
official personel till phase 2 of the phone.  So scanning the actual 
case and building a knockoff would (in my opinion and until I am 
corrected by FIC / Sean or other person with some authority) be a 
violation of their IP.


However, it is hardly a violation of their IP to build new designs from 
our own imagination and make them open / sell them by our own means.


I just can't see how we could possibly be upsetting them by adding 
accessories for their devices which will in some way improve customer 
experience or at the very least satisfy some vanity impulse.

--Tim

On Tue, 3 Jul 2007 14:32, Robin Paulson wrote:

Is it legal to sell these cases? The design may be based in no small
part on work done by FIC, who will not be impressed by us stamping on
their IP. We don't want to take the piss - they are helping us a lot.

Making a few one-offs for ourselves, with no profit is ok, but as soon
as we start marketing them, things may change.

When he's not so busy, this would be one for sean to enquire about.

On 7/4/07, Dr. H. Nikolaus Schaller <[EMAIL PROTECTED]> wrote:

 So... the question is...
   a) is it possible to convince Nathan or Gordon to sell these
 things through their websites for $65 - $147?


I can sell it through my website: http://www.handheld-linux.com
although I currently focus on the European markets only (due to tax
and duty complexity).

   b) is there actually a demand for 10 or 100 of these 
after-market

 cases?


Depends on the number of total units of the OpenMoko being sold. I
would assume 1% after sales as a first rough guess.


   c) is there a "one size fits all" design that will satisfy
 everyone who wants an after-market case?


Probably not. I remember that we did have approx. 50 - 100 different
custom designs at Siemens mobile phones.

  Nikolaus Schaller


The Handheld-Linux Shop
http://www.handheld-linux.com

operated by
Golden Delicious Computers GmbH&Co. KG
Buchenstr. 3
D-82041 Oberhaching
http://www.goldelico.com

Make the customer come back and not the product




___
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

--Tim

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

Re: Custom case designs... (the business perspective)

[Tim Newsom]

On Tue, 3 Jul 2007 12:56, Matthew S. Hamrick wrote:
Also.. to follow up on what Adrian recently said.. The tech shop also  
has a CNC milling machine. I'm no expert, but I believe that the idea  
is that you put a CAD file in one side and take out a completed part  
out the other. So... if you have the CAD files for a case, you could  
feed them into the CNC milling machine instead of the 3D printer and  
viola! aluminum case.


Jim Newton at the TechShop also mentioned he's looking into getting  an 
injection molding machine. I've seen a couple of these sorta 1  shot 
injection molders. You use the CNC machine to create your mold,  then 
you pour plastic pellets in the top, press a button and an  electric 
motor turns the screw that forces the semi-molten pellets  into the 
mold. So.. you could have any number of different cases made  for your 
Neo.


My "back of the envelope" calculations for the cost are:

Fixed Costs:
Mold Design Time5h  $0
Mold Milling Time   3h  $75

Variable Costs: (per production run)
Mold setup  1h  $10

Variable Costs: (per case)
Plastic Pellets (1/10)h $3

So assuming a CAD file for the NEO case were to magically fall out of  
the sky, perhaps as part of a program to seed a third party ecosystem  
(*hint*hint* Sean, are you going to be in the bay area soon?  
*wink*wink*) The cost per case for a production run of 10 and 100  
identical cases would be:


10 cases: 9h, $115
100 cases: 18h, $385

Let's say that I'm terribly impressed with myself and I want to pay  
myself $65 / hr. for my time, the price goes up to:


10 cases: $700
100 cases: $1555

But I'm not going to sell them myself. I'd rather sell them through  
SparkFun or even GumStix.com (but I don't know if either of these  guys 
would be interested.) So, I'm going to add a little bit of  margin. 
This is a risky business, so I'm adding 35%.


10 cases: $945
100 cases: $2100

Nathan and/or Gordon are going to want a margin as well, but I'm  
thinking I'm going to offer them a low-risk proposition: "just put  the 
SKU on your website and I'll handle the fulfillment." So I'm  going to 
argue them down to 7% margin. So in other words, I'm going  to pay them 
a commission for every case they sell. That fee would be:


10 cases: $65
100 cases: $147

We're not talking about a lot of coin, here. From a business  
perspective, the reward of $147 for selling 100 isn't that great.  It's 
probably not going to pay for Nathan or Gordon's time to setup  the SKU 
in their system. But there's always eBay...


Let's say sales taxes are an additional 8.5%:
10 cases: $86
100 cases: $191

Shipping and handling:
10 cases: $90
100 cases: $900

End Price:
10 cases: $1186 ( $118.60 per case )
100 cases: $3338 ( $33.38 per case )

So... the question is...
	a) is it possible to convince Nathan or Gordon to sell these things  
through their websites for $65 - $147?
	b) is there actually a demand for 10 or 100 of these after-market  
cases?
	c) is there a "one size fits all" design that will satisfy everyone  
who wants an after-market case?


So, I'm not saying I want to get into the business of making after- 
market Neo cases, but someone who was thinking about getting into  this 
market would do an analysis just like this. So... if there was a  solid 
demand for 100 cases, it's possible the price could be brought  down to 
about $35-$40.




This is definitely an interesting analysis of a set of costs associated 
with this kind of business.


I think the costs could be a bit cheaper for the end user depending on 
material and costs to build the molds.   But then again, I have not 
actually sat down and worked it out yet. /grin


I do think there is a market here though..
--Tim

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

Re: Custom case designs...

[Tim Newsom]

On Tue, 3 Jul 2007 12:07, Matthew S. Hamrick wrote:
Oh... but doesn't PETN have some issues with long-term durability  when 
exposed to UV?


On Jul 3, 2007, at 11:04 AM, Jeffrey Thomas wrote:


Clear soda bottles are fairly strong and not nearly as brittle as  some
other clear plastics.


True enough, and i stand corrected.  Their flexibility may even be  a 
benefit -- i drop my current phone often enough and it survives;  i 
would hope for something similar on my Neo when I get it.  Maybe  some 
of the extra space (and a flexible plastic) could help to  cushion the 
device during impact from a fall.


Exactly how long term are you talking about?
Normal usage probably won't have the case constantly exposed. Plus, 
assuming the case does get some kind of issue after some year of 
exposure.  You have probably dropped it, scratched it up in some way and 
if its cheap enough, get a new one.. Recycle the old or what not.


Personally, I have never tested what happens after a soda bottle is 
exposed to sunlight for very long periods of time. I have had experience 
where they have been exposed to sunlight for days and I do not remember 
any change in durability or coloration etc.


Maybe someone with real knowledge can tell us the limits of exposure / 
usage for it?

--Tim

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

Re: Come see OpenMoko at Ubuntu Live

[Tim Newsom]

On Tue, 3 Jul 2007 11:24, Sean Moss-Pultz wrote:

Dear Community,

Michael Shiloh has volunteered to setup a booth at Ubuntu Live
(http://www.ubuntulive.com) July 22 to 24 in Portland, Oregon. He'll be
demoing and talking about both the platform and the Neo. If you're in
town, please stop by!

Thanks so much for the help Michael!

-Sean


I am in portland so I will definitely stop by and take a look.  I will 
try very hard not to drool all over the phone too. Lol.


--Tim

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

Re: Custom case designs...

[Tim Newsom]

Or how about this... Cases from recycled materials..

Neo1973.. Free your phone, open your horizons, save the world...
Good for you, great for the environment.
--Tim

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

Re: Custom case designs...

[Tim Newsom]

That's not necessarily true.. Look at plastic bottles.
Clear soda bottles are fairly strong and not nearly as brittle as some 
other clear plastics.  Plus, that plastic is useful as injection 
material.


Plus, if it were cheap enough to get new cases, most people would not 
care if they dropped or scratched one for a while as it would be easily 
replaced.


--Tim

On Tue, 3 Jul 2007 10:37, Jeffrey Thomas wrote:

 Maybe we should have like transparent ("see-through") casing.
Ah, but transparent plastic is always more brittle than coloured 
plastics...  I would hate my Neo cracking as easily as a CD case...



On Tuesday 03 July 2007 11:35:57 Shakthi Kannan wrote:

 Hi,

 On 7/3/07, Ben Burdette <[EMAIL PROTECTED]> wrote:
 > Case modding for phones, cool.

 Maybe we should have like transparent ("see-through") casing. Why do
 we need closed cases for open hardware and software?

 SK




--
Jeffrey Thomas
  Sierra Bravo
  952.948.1211 x1046
  952.567.6346 Direct

  www.sierra-bravo.com
  9201 East Bloomington Freeway
  Suite CC
  Bloomington MN 55420


--Tim

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

Re: Custom case designs...

[Tim Newsom]

There are several types of clear plastic which could be used to fulfill 
this idea..  Both as plastic injection and liquid casting material.


--Tim
On Tue, 3 Jul 2007 9:50, Shakthi Kannan wrote:

Hi,

On 7/3/07, Ben Burdette <[EMAIL PROTECTED]> wrote:

Case modding for phones, cool.


Maybe we should have like transparent ("see-through") casing. Why do
we need closed cases for open hardware and software?

SK

--
Shakthi Kannan
http://www.shakthimaan.com


--Tim

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

Re: community Digest, Vol 34, Issue 17

[Tim Newsom]

On Tue, 3 Jul 2007 9:50, Michael Sersen wrote:

About custom case design for the Neo and beyond;  I am very interested
in this idea.  I have a cnc router at my disposal and can make custom
parts from materials such as Corian and exotic hardwoods and some soft
metals.  I'd love to see some spec's, maybe .dwg's or .dxf files of
the current case, for measurments of stand-offs and such.

~ MAS


This makes 2 of us.. Are there others with similar equip?
I was working on the idea that it may be possible to use custom plastic 
injection or some other forms of liquid plastics to build custom 
shells.
In addition, it may also be possible (assuming someone wanted to pay for 
it ) to cast in stirling silver or various gold alloys (careful about 
scratches) etc..

Just some ideas anyway..
--Tim

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

Re: Custom case designs...

[Tim Newsom]

On Tue, 3 Jul 2007 8:59, no_use wrote:
these are exactly the reactions i got from my friends.. specially as 
the

mainbord seems rectangular, i wouldn't like to see it with this rounded
top and bottom..

..and all i want is 3G.. :(



So add case design ideas to the wiki where previously noted.

I guess we will see what's possible once we get them in our hands and 
all that.

--Tim

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

Custom case designs...

[Tim Newsom]

I have been thinking a little more about this and I struck upon an 
idea... What if you could buy a custom case with a custom message on 
it.


I am not talking about painted messages but letters and shapes cast into 
the plastic shell.

Raised, sunk, custom fonts etc.

Naturally we can't just replicate the exact neo1973 shell without 
permission, but maybe something like it and removing the FIC logo 
(unless we get permission to use it) or the like.


This is more of a vanity thing than a functional thing.. But what do 
people think of it?

--Tim

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

Re: An alternative gaming top case

[Tim Newsom]

On Tue, 3 Jul 2007 4:01, Robin Paulson wrote:


excuse my ignorance, but do you mean a 3d scanner as in a device for
measuring a 3d object?

http://en.wikipedia.org/wiki/3D_scanner

if you do, and have a Neo, that would be awesome. any chance of using
it to produce an electronic model of the case that you could share
with us?

as for formats - i presume you mean file formats. something open like
.blend would be good, or more commonly, .stl:
http://en.wikipedia.org/wiki/STL_(file_format), those are accepted by
pretty much every 3d modeller out there


Yep. But unfortunately I do not yet have a neo1973.
.stl I gathered but I had not thought of .blend

Basically all a 3d scanner does is build up a point cloud for the 
contours of an object and then kinda wrap it in a skin. If the 
resolution of the point cloud is high enough you can make out some 
pretty fine detail.

In this case (no pun intended) I believe it will work pretty well.
--Tim

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

Re: An alternative gaming top case

[Tim Newsom]

On Mon, 2 Jul 2007 17:39, Robin Paulson wrote:

I have added a sub-section to the Neo1973 hardware section of the
wiki, concerning alternate cases. there are a few ideas as starters,
including one with a d-pad and a steampunk design. Anyone with any
other ideas/more info to flesh out what i've put there, head over to

http://wiki.openmoko.org/wiki/Category:Neo1973_Hardware#Alternate_cases

If FIC do not have the resourcs at the moment/will not ever supply
schematics, then we need someone to measure their phone and upload
some drawings

I have a 3d scanner that I am planning to employ for building models if 
no one gets to it before I do.
I would be interested in finding out which formats people think should 
be used for the models.. Also, assuming I can get things together what 
is the interest level for case kits and other accessories?


--Tim

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

Re: An alternative gaming top case

[Tim Newsom]

Sean,

Supposing some company decided to provide alternate case designs or add 
on products for the neo1973, who do they need to talk to about branding 
/ authorization to sell them to the public?


OR

Is it possible that FIC or the OpenMoko company will have a section on 
their sales page supporting 3rd party add-ons, etc?


--Tim
On Sun, 1 Jul 2007 18:10, Robin Paulson wrote:

well, i'm definitely interested in someone doing something like this -
and my background is in CAD/engineering/materials with a bit of CAM,
so i might as well start things off.

i can't see any schematics/CAD drawings up on the wiki - can someone
point me in the direction of accurate, precise drawings of the
internals and the case?

if not, then to sean:
will FIC be releasing good engineering drawings of the component(s) or
will we be going down the route of measuring hardware and drawing our
own? if we are going the reverse-engineering route, is someone willing
to whip out their micrometer and a decent (open-source) CAD package
and make some up for us?

On 7/2/07, Jeff Andros <[EMAIL PROTECTED]> wrote:



On 7/1/07, Robin Paulson <[EMAIL PROTECTED]> wrote:

 
 want a case made from brass with diamonds inset, and a 200mm joystick
 - go for for it.
 
The real question is, how long before we see a really good steampunk 
case?
anyone out there want to show off your 3D Cam skills and start putting 
them
up for sale... I'd buy ( rapidobject.com was previously mentioned if 
you

need a place to do the work)

--
Jeff
O|||O


--Tim

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

Re: Graphics Accelerator needs matching joystick and keys

[Tim Newsom]

Hehe, I know that.. I was mentioning it for the benefit of the previous 
person who was asking about joysticks.


--Tim
On Fri, 29 Jun 2007 19:22, Steven ** wrote:
Someone has already mentioned on this list about using the Wii 
Nunchuck.  Apparently it will connect to the I2C fairly easily.  Search 
the archives.


-Steven


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

Re:Graphics Accelerator needs matching joystick and keys

[Tim Newsom]

There's also the possibility of adding some kind of attachment to a 
specially designed battery or backpack which could add this ability by 
interfacing with the I2C or SPI ports available.


--Tim
On Fri, 29 Jun 2007 16:43, Joe Pfeiffer wrote:

Kenshin writes:


I think there is a huge benefict in addind a joystick and keypad to
the OpenMoko. This would allow users to play old classics in
emulators; run new (java) games and assign keyboard shortcuts.

I don't think that adding a joystick and a keypad is a big
technological endeauvour :-)
Is there any reason for not having them?


Space.  Not everybody wants them (I don't, for instance), and they
take up room.  Hopefully FIC will move in that direction with some of
their future devices -- but hopefully they won't abandon those of us
who don't want it.


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

Re: An introduction

[Tim Newsom]

Plus, since moonlight is technically language agnostic, those who want 
to write in c# could, those who like c or c++ could.. With IronPython or 
IronRuby or even Javascript there are a number of options for scripting 
and having user interfaces that work seamlessly together.. Regardless of 
the technology used to build the application code underneath.  From my 
understanding.. We could even mix with different UI elements interacting 
with different types of applications ... By that I mean portions of the 
same UI could be sending events to scripts or C# or c/c++ code. Is that 
right?


And XAML can be created dynamically giving the ability to not just 
theme/skin but completely alter the UI at runtime.  By that I mean you 
don't have to have a static interface with a skin file and theme but the 
interface could be radically changed as new code is added and new xaml 
nodes are created.. Does that make any sense?

--Tim

On Wed, 27 Jun 2007 5:49, Vladimir Giszpenc wrote:

On 6/27/07, Tim Newsom wrote:

This could provide the xaml parser for use in an interface design some
of us have spoken about.
Separating the interface from the actual code that processes the
events... Or that's how I understand it.
Its a truely awesome development.


Yes it certainly could and would provide a XAML parser.  Read this
http://jacksonito.blogspot.com/2007/06/mono-developers-guide-to-writing-xaml.html
for some more details.  They are planning for tools written in
MoonLight so that you could develop on Linux or even a Mac (though I
sense no love lost on Apple products on this list :).

On 6/27/07, Hans De Croix wrote:

Under what license exactly is silverlight/moonlight?


The Mono part of Moonlight uses the DLR. So...

"Microsoft's DLR is a layer on top of their Common Language Runtime
(CLR), which provides support for dynamically typed languages such as
Python, Ruby and JavaScript. The great news is that the DLR is
released under Microsoft's Permissive License—their way of saying 
open

source. Microsoft's .NET/DLR implementations of Python and Ruby, named
IronPython and IronRuby respectively, are both covered by the same
Permissive License as DLR."

Mono as a whole has this answer to the license question:
" What license or licenses are you using for the Mono Project?

We use three open source licenses:

   * The C# Compiler and tools are released under the terms of the
GNU General Public License
(http://www.opensource.org/licenses/gpl-license.html) (GPL).

   * The runtime libraries are under the GNU Library GPL 2.0
(http://www.gnu.org/copyleft/library.html#TOC1) (LGPL 2.0).

   * The class libraries are released under the terms of the MIT X11
(http://www.opensource.org/licenses/mit-license.html) license.

Both the Mono runtime and the Mono C# Compiler are also available
under a proprietary license for those who can not use the LGPL and the
GPL in their code.

For licensing details, contact [EMAIL PROTECTED]"


Specifically Moonlight...

"Novell will be requiring copyright assignments or contributions to be
made under the MIT X11 license to Moonlight to ensure that we can ship
this plugin with proprietary drivers if necessary (and also to
relicense Moonlight for embedded system users)."

I imagine the OpenMoko embedded system is a special case since it is
open but the license is definitely open source.


On 6/27/07, Florent THIERY wrote:

I'd be surprised if no hardware acceleration was needed...


It is not needed though it is used if available.  They got help from
their Xgl+Compiz+Glitz guy David Reveman.

Here is Miguel de Icaza describing the development decisions some 
more...


"The other consideration to move away from C# to C at the time had to
do with the early conversations with David Reveman who wanted to
hardware accelerate this. The idea was to turn the Silverlight
high-level operations into a scene description that we could transfer
from the client applications directly onto the compositing manager (On
modern X installations this is what actually puts the bits on the
screen and what has enabled all those spicy effects like the rotating
cube).

The idea here is that the Silverlight client could detect if it was
running under a compositing manager that offered rendering on the
server and it would off-load all the rendering to the layer that can
talk directly to the OpenGL hardware. "

Vlad

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

Re: An introduction

[Tim Newsom]

This could provide the xaml parser for use in an interface design some 
of us have spoken about.
Separating the interface from the actual code that processes the 
events... Or that's how I understand it.

Its a truely awesome development.
--Tim
On Tue, 26 Jun 2007 19:58, Vladimir Giszpenc wrote:

Hello OpenMoko community,

OpenMoko is very exciting.  I and many Mono developers like myself
would like to get involved.  The Mono team has developed Moonlight --
a port of Microsoft's SilverLight to Linux.  Here are some of the
things it can do http://www.youtube.com/watch?v=qRSO7p0HAIw

It is Open Source, small, fast and works well with others.  The Mono
team has made it easy for .Net developers to access this technology
but it is not limited to them.  You don't need Mono to use MoonLight.

The Mono team would help you create hype give you access to millions
of C#, VisualBasic, JavaScript, IronPython and Ruby developers because
it not only has ported the .Net CLR but they made Microsoft's DLR work
on Linux as well.  The DLR is licensed with a BSD type license.

How do we get involved?

Thanks,

Vlad



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

Re: Let's play...

[Tim Newsom]

Oh... And the neo1973 will probably be sold at some FIC site ... I 
mean... OpenMoko is not just for the neo1973 and they are only related 
because OpenMoko can run on the neo1973.
Indeed, suns new java phone os and probably windows mobile will also run 
on the device.


Plus, since its an FIC phone, it just makes sense. The phone isn't 
called The OpenMoko phone after all...


--Tim
On Tue, 19 Jun 2007 18:07, [EMAIL PROTECTED] wrote:


...Guess the OpenMoko Web Store URL!

Sooner or later, they have to start selling.  But from where?

webstore.openmoko.org??
store.openmoko.com??
Perhaps an Fic site??

Lots of possibilities.  If anyone finds the store under construction,
should that info be shared??

Alan



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

Re: Let's play...

[Tim Newsom]

OR... They could have it being developed on an internal developer 
machine and not go live till they are ready.



On Tue, 19 Jun 2007 18:07, [EMAIL PROTECTED] wrote:


...Guess the OpenMoko Web Store URL!

Sooner or later, they have to start selling.  But from where?

webstore.openmoko.org??
store.openmoko.com??
Perhaps an Fic site??

Lots of possibilities.  If anyone finds the store under construction,
should that info be shared??

Alan


mail2web.com – Enhanced email for the mobile individual based on 
Microsoft®

Exchange - http://link.mail2web.com/Personal/EnhancedEmail



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

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

Re: Open Moko Themes

[Tim Newsom]

On Wed, 13 Jun 2007 11:15, John Seghers wrote:

Tim Newsom wrote

 As I understand it, you would not even need to build a different svg
 file.  You could use the same one and it could automatically scale
 because the engine would scale it..  It should be possible (in my 
mind)

 to take a layout for 320 x 240 and draw it perfectly at 648 x 480..


Scaling up vector graphics is certainly less likely to cause problems 
than
scaling down. However, when you start talking about QVGA or smaller, 
every
pixel counts and hand-tuned graphics are going to give a better 
presentation

than generated graphics.

However, even staying at the same DPI... what about a landscape vs. 
portrait

orientation?  Moving from 640 wide x 480 high to 480 wide x 640 high is
going to need more than scaling.  You are going to want to use the 
display

differently.

So yes, a different SVG file would likely be needed.

- John


If you will check the snipped out portion of my email, you should notice 
that I mention the assumption you are in the same orientation..
I will grant you that every pixel counts, but if each portion of the 
display is drawn with vector graphics and unless you are going way 
beyond the capabilities of the display... Within reasonable bounds the 
display should scale correctly.  As for different orientation, sure, 
make 2 files for the alternate layout.. But that's incredibly more 
efficient than making 30 bitmaps (images or whaterever you call them) 
for each resolution setup and orientation combination.


Granted, its my opinion.  Granted, rendering a vectored image takes more 
processing than blitting an image from memory to the screen.. But from 
what I heard last time, at least the first public version of the neo 
will have a hardware graphics processor to handle most of that work.  
And anyway, I don't have a good feeling for the amount of time it would 
take to render a screen (skin which is theme plus layout) for something 
like the neo but without graphics processor.  I am simply stating my own 
opinion and I expect others to do the same.  /grin that's what the 
community is all about right?


Someone with some extensive svg experience in this realm can give real 
hard core information.

--Tim

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

Re: Open Moko Themes

[Tim Newsom]

On Wed, 13 Jun 2007 7:08, Emre Turkay wrote:

On 6/13/07, Peter A Trotter <[EMAIL PROTECTED]> wrote:
If the application is then used on a different form factor device you 
can
simply produce a new SVG file. All the UI script and images are linked 
to

the SVG.

This also gives us a nice separation of people who are good at making 
things
look good and those of us who know the loop preconditions / 
postconditions

without even thinking.

If openmoko is to deal with multiple different devices/resolutions 
this will

be a key feature.


I totally agree that openmoko graphics should be in a vector graphics
format. Generate the bitmaps bigger for neo and maybe smaller for
iphone, etc. Storing the generated bitmaps in .png or .svg files does
really don't much matter. If .svg provides embedding bitmaps, why not.

emre



As I understand it, you would not even need to build a different svg 
file.  You could use the same one and it could automatically scale 
because the engine would scale it..  It should be possible (in my mind) 
to take a layout for 320 x 240 and draw it perfectly at 648 x 480.. Any 
image bitmaps would be out of sync unless you changed them but if its 
all done in svg it would render perfeclt.  Same the other way.. All 
ratios would be the same (assuming a smaller display in the same 
orientation and proportional dimensions) so the exact same skin and 
theme would not need translation at all (except any embedded bitmaps).


Again, that's how I understand it currently.
--Tim

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

Re: Open Moko Themes

[Tim Newsom]

On Wed, 13 Jun 2007 4:52, Buddy wrote:

On 6/13/07, Emre Turkay <[EMAIL PROTECTED]> wrote:

On 6/12/07, Tim Newsom <[EMAIL PROTECTED]> wrote:

 This is where XAML or XUL are particularly suited.
 The idea is that the UI will be mostly svg commands or in some cases
 images.. But rendered completely by the engine.  Look up what you get


Loading the burden of SVG rendering to the run-time, for a very static
environment like a mobile platform (you don't plug a screen with a
different resolution to your cell phone generally) IMHO not a very
good idea. They may be vector graphics at the development phase but
they should be compiled (translated into bitmap) before deployed onto
the real device.

My motivation is, why should we decrease the performance to get the
same effects, both for UI eye-candy and usefulness?

emre



SVG can be used for scaling with same resolution and the average
filesize will be very small



Exactly what I was going to say.  Ok.. So imagine that you have this 
wonderful 640 x 480 screen.  Text is very readable to the average user.. 
However, the skin / theme is too small for some visually impared people 
in some circumstances
Svg allows you to "magnify" with perfect clarity to any size without 
distortion.  Ok, but the text is a raster font (is that the right word?) 
not some vectorized font right? Does it have to be? Why not handle 
translation of rasterized to vectorized fonts for the magnified area? Is 
that possible? I don't know but I imagine it should be.  Or use 
vectorized fonts everywhere.


Going another way, with svg, you can "draw" perfect thumbnails of the 
current state of any application in a task manager context by rendering 
the view of that frame in a scaled "window".  You could even allow those 
windows to be interactive so that 2 applications could be operated side 
by side.


Without drawing and rendering each available scale of static image 
(which would be very huge in size) how else can you get the same 
functionality?


The ability to skin an application, move the buttons around and test out 
a new layout without altering a single line of application code is huge 
in my mind.  Also, the ability to "mashup" (to overuse an overused word) 
application functionality is huge too.


Example:
You have an ftp program but you don't necessarily like the file manager 
program... However, you have a file manager program you do like but you 
don't like the layout as much.. It would seem to me that if we build 
this correctly we should be able to combine which ever file manager and 
ftp program we want into a new (again...) "Mashup" and have something we 
like and never touch the application behind.  Why is this possible? 
Because drag and drop exist at the os level maybe... Or because the UI 
glue code can handle any correctly defined and used interface on the app 
code... Or because all file managers and ftp apps follow specific 
guidelines which allow combining them in new ways.


/shrug..

Ok.. Now do that with a static interface.
--Tim

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

Re: Open Moko Themes

[Tim Newsom]

This is where XAML or XUL are particularly suited.
The idea is that the UI will be mostly svg commands or in some cases 
images.. But rendered completely by the engine.  Look up what you get 
for using it and you will see what I am talking about.  There is work to 
be done getting XAML to function on linux.. But it would be worth the 
effort, IMHO.


BTW, mono has started a project called moonlight which aims to bring 
silverlight applications to mono. Maybe we can help accelerate some of 
that work?


--Tim


On Tue, 12 Jun 2007 4:29, Peter A Trotter wrote:
UI for these different screen resolutions and potentially form factors 
is going to be more then a case of image resizing. It will be whole 
different layouts. I am quickly coming round to the idea of a near 
complete separation of GUI from application. It is the only way to 
really present the same apps on the different Openmoko hardware 
platforms.


At the same time I am not convince that html is the way to go. What are 
the options here?


-Pete

On 12/06/07, Frank Coenen < [EMAIL PROTECTED]> wrote:

Making your icons/panels/butons in svg-format and make a shell-script 
that (using imagemagick for example) converts all of them to the 
requered resolution in png.
It shouldn't be the worry of the designer in what resolution use 
intend to use OpenMoko.The program/GTK should take care of that.


On 6/12/07, Luit van Drongelen < [EMAIL PROTECTED]> wrote:


I think the first theme concern should be different resolutions.
Currently there's just a VGA theme, but QVGA and WQVGA (i guess...
480x272 anyways) for future phones, and non-FIC phones. (most phones
and PDAs are QVGA).

At least I'd like to see that come soon.

--
LuitvD

On 6/12/07, Jon Phillips <[EMAIL PROTECTED] > wrote:

 On Mon, 2007-06-11 at 19:19 -0500, Tim Shannon wrote:
 > I know that there are going to be themes for the OpenMoko interface,
 > but I'm just wondering if there is anyone who has started working on
 > alternate themes?  I think I'd like to take a crack at it, and I was
 > curious if anyone has had any start yet.
 > ___
 > OpenMoko community mailing list
 > community@lists.openmoko.org
 > http://lists.openmoko.org/mailman/listinfo/community

 I haven't, but OpenMoko team and I have discussed how the main 
theme is
 going to be CC BY-SA licensed. It would be great to get other 
interfaces

 licensed under CC BY or BY-SA tooo!

 Jon

 --
 Jon Phillips

 San Francisco, CA
 USA PH 510.499.0894
 [EMAIL PROTECTED]
 http://www.rejon.org

 MSN, AIM, Yahoo Chat: kidproto
 Jabber Chat: [EMAIL PROTECTED]
 IRC: [EMAIL PROTECTED]


 ___
 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




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

Re: Web-based GUI technology for OpenMoko

[Tim Newsom]

Interesting... Web services... I wonder if that makes it possible to 
export the web service off the phone
To a program running somewhere else... Or if its limited to some local 
channel.


And, anyway.. That only means you would have to wrap it in another, 
fully exportable, web service for such integration.


--Tim
On Mon, 11 Jun 2007 20:51, Matthew S. Hamrick wrote:

Wow. once again Apple justifies our lead.

On Jun 11, 2007, at 5:54 PM, adrian cockcroft wrote:

Also, Apple's announcement today about iPhone development using AJAX 
and exposing internal phone functions as web services to the iPhone's 
safari browser is tipping everything in the same direction.


Cheers Adrian

On 6/11/07, Matthew S. Hamrick <[EMAIL PROTECTED]> wrote:


Yeah... we're thinking that we were going to totally separate the
model and domain processing from the view/controller part of the
application. That way we could have a couple different HTML
interfaces as well as a SVG/ECMAScript interface. I'm not terribly
familiar with XAML or XUL, but I understand that most (if not all) of
the Firefox / Mozilla / Navigator interface was written in XUL.

This is one of the benefits to this approach, IMHO. Separating the
interface allows us to experiment with a number of different
interface technologies. And the only thing the experimenters need to
know is the semantics and syntax of the XML interface.

-Cheers!
-Matt H.

On Jun 11, 2007, at 9:18 AM, Tim Newsom wrote:


 If we are heading in the direction of web interfaces, I think we
 should look at XAML or XUL or something similar.  From what I can
 tell, they will be adding silverlight support to mono, so using
 XAML will be possible.  This also separates the code for
 functionality from the interface and can allow skinning of the
 entire application interface set.

 This will abstract you from every widget set.  Each action could be
 exported and called from the UI without needing to worry about all
 that.

 At least, that's my take on it currently.

 --Tim
 On Mon, 11 Jun 2007 8:44, Florent THIERY wrote:

 Here's a little look-and-feel example that could be done with an
 opensource AJAX framework [javascript required]:

 http://demo.qooxdoo.org/current/showcase

 This may allow easier separation between apps and GUIs. Of course, as
 usual we have no idea how well such an app would perform (little &
 gratuitous prediction: very bad), benchmarking is needed but ... who
 knows ?

 This is going along with the ongoings gdk webkit port and gsmd
 XmlHttpRequest interface (was topic: embedded webserver).

 What do you think ? Is it REALLY unrealistic ? Could anybody try the
 url on it's Nokia N770 (lots of happy owners here, right?) and rough
 feedback the responsiveness ?

 Cheers

 Florent


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

Re: standard API for linux phones?

[Tim Newsom]

From what I read, the LIPS group is creating an 'open' standard.  The 
impression I got from that was the other phone standards group was 
'closed' whatever that means.


If we are going to back a group, maybe FIC should join it and help in 
the development process of the standard. None of the members are small 
(as far as I can tell), and it does at least have the backing of some 
operators..


Either way, we will need to either submit a standard at some point or 
follow one so that others can interop with us.. Right?


--Tim
On Mon, 11 Jun 2007 16:55, Dean Collins wrote:
Long overdue and if it is a standard then lets all jump onboard and 
work with it from inside rather than throwing rocks from the outside.


Cheers,

Dean


 -Original Message-



 From: [EMAIL PROTECTED] [mailto:community-



 [EMAIL PROTECTED] On Behalf Of Robin Paulson



 Sent: Monday, 11 June 2007 7:16 PM



 To: community



 Subject: standard API for linux phones?







 the register has a piece about a draft of a standard API for linux



 phones, concerning basics such as interaction with the address book,



 texting, ui and voice-calling. future revisons to increase the



 coverage







 http://www.theregister.co.uk/2007/06/11/lips_mobile_linux/







 and from TFA







 http://www.lipsforum.org/







 does anyone here have any further knowledge about this, beyond the



 blurb on the site? is it worth adhering to, or a thinly-veiled



 atttempt for one company (it's backed by orange) to foist



 propietary/their own standards on everyone else? does it compare at



 all to what the linux mobile group (backed by samsung, motorola and



 others) are trying to achieve? and of course, has it been considered



 for openmoko/the neo?




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

Re: Web-based GUI technology for OpenMoko

[Tim Newsom]

If we are heading in the direction of web interfaces, I think we should 
look at XAML or XUL or something similar.  From what I can tell, they 
will be adding silverlight support to mono, so using XAML will be 
possible.  This also separates the code for functionality from the 
interface and can allow skinning of the entire application interface 
set.


This will abstract you from every widget set.  Each action could be 
exported and called from the UI without needing to worry about all 
that.


At least, that's my take on it currently.

--Tim
On Mon, 11 Jun 2007 8:44, Florent THIERY wrote:

Here's a little look-and-feel example that could be done with an
opensource AJAX framework [javascript required]:

http://demo.qooxdoo.org/current/showcase

This may allow easier separation between apps and GUIs. Of course, as
usual we have no idea how well such an app would perform (little &
gratuitous prediction: very bad), benchmarking is needed but ... who
knows ?

This is going along with the ongoings gdk webkit port and gsmd
XmlHttpRequest interface (was topic: embedded webserver).

What do you think ? Is it REALLY unrealistic ? Could anybody try the
url on it's Nokia N770 (lots of happy owners here, right?) and rough
feedback the responsiveness ?

Cheers

Florent



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

Design idea....

[Tim Newsom]

Ok.. before you take my head.. here is an interesting design idea i found
online.  Idea only.. and yes I realize that this version runs a windows
operating system.

http://www.windowsfordevices.com/news/NS3731349953.html

Most of us are looking for multi-functional devices and will probably carry
keyboards or such in order to have the ability to type rapidly rather than
using the screen interface.  As an alternative, this device has a fold out
keyboard attached to the case and unfolds to use it.  Combined with a mini
pointing device (ala mini trackball), yes I know you can use the screen..
but that means taking your hand away from the keyboard entirely... It could
hold alot of promise.  Even without pointing device.. but I digress..

I would be very interested in such a converged device where the keyboard is
not "mini" and folds out from the device (maybe on a swivel) to perform its
function when there is room. It also means that you don't have to carry
multiple devices  with multiple power supply demands etc.. it could be a
very 'low tech' keyboard interfaced with the phone physically.  Maybe via a
connector which also allows it to be completely detached.

Anyway.. just posing ideas for the future.
--
-- Tim
___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Yet another contender in the market?

[Tim Newsom]

You and *I* feel that way... But the general public will be taking stock 
of the appearance and ease of use etc...


Besides.. I mentioned it so that we can take a look at the view some 
general person my have of a new device and see how we can improve upon 
any weaknesses.  There will be no shortage of devices competing for the 
top spot... And against the iphone.
Many, Many all touchscreen devices will be out there.. And we are not 
going to be first... So we can at least acknowledge the competition and 
work to improve what we can.


--Tim

On Thu, 7 Jun 2007 11:18, Thomas Gstädtner wrote:
There already was Samsung phones with HSDPA support which was slower 
than normal UMTS phones of other manufacturers.
Also flash lite might be good looking, but it is definately no 
smartphone platform. At least you cannot use the UI for additional apps 
(must be an overlay).

The display resolution is very poor for a such big screen.

For me this devices is pretty uninteresting, and even if it'd be able 
to run openmoko that wouldn't matter for me.
Why should I give my money to a company that doesn't support opensource 
only to use their hardware with hacks and openmoko?
Let's hope OpenMoko and the FIC Neo1973 will be successful and FIC 
produces more open phones in future.


2007/6/7, Tim Newsom <[EMAIL PROTECTED] >:


Hmm... I thought it listed wifi and bluetooth on samsungs website...
--Tim
On Thu, 7 Jun 2007 8:57, Mark McClellan wrote:

 nice. very nice.
 i really hope this is close to the Moko v2 hardware. it's what i'm
 waiting for

 Mark

 On 6/7/07, Eric Heinemann < [EMAIL PROTECTED]> wrote:


 If I remember correctly, the F700 is using a Flash lite interface.
 Even though it does not have WiFi, it does have 7.2M HSDPA :) I am
 pretty sure it does have bluetooth though. Look here:

 http://www.gsmarena.com/samsung_f700-1849.php

 or here:

 http://www.phonearena.com/htmls/Samsung-SGH-F700-phone-p_1941.html

 -Eric

 - Original Message 
 From: Steven ** <[EMAIL PROTECTED]>
 To: Openmoko < community@lists.openmoko.org>
 Sent: Thursday, June 7, 2007 9:44:30 AM
 Subject: Re: Yet another contender in the market?

 The wallpaper on the F700 from the first Google result (
 
http://gizmodo.com/gadgets/cellphones/apple-iphone-vs-samsung-f700-which-is-touchscreenier-235112.php
 ) is a total rip-off of the Ubuntu default theme. I doubt that
 they're actually running Ubuntu (although I think Ubuntu is getting
 into the mobile market).

 The features don't really seem comparable. No wifi and no bluetooth.
 And the screen is even smaller and lower resolution than the iPhone.

 -Steven

 On 6/7/07, Tim Newsom < [EMAIL PROTECTED] > wrote:


 Has anyone else seen the samsung F700?
 Its features are pretty nice... No idea on the OS but I would 
definitly

 take one over an IPhone... If it performs anything like it looks...
 Hehe.

 Its got very good specs.
 --Tim


 ___

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

 

 Never miss an email again!
 Yahoo! Toolbar alerts you the instant new Mail arrives. Check it out.

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


 --

 Dangling carrots usually contain a hook.

 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0

--Tim
___
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: Yet another contender in the market?

[Tim Newsom]

Hmm... I thought it listed wifi and bluetooth on samsungs website...
--Tim
On Thu, 7 Jun 2007 8:57, Mark McClellan wrote:

nice. very nice.
i really hope this is close to the Moko v2 hardware. it's what i'm 
waiting for


Mark

On 6/7/07, Eric Heinemann < [EMAIL PROTECTED]> wrote:

If I remember correctly, the F700 is using a Flash lite interface.  
Even though it does not have WiFi, it does have 7.2M HSDPA :)  I am 
pretty sure it does have bluetooth though.  Look here:


http://www.gsmarena.com/samsung_f700-1849.php

or here:

http://www.phonearena.com/htmls/Samsung-SGH-F700-phone-p_1941.html

-Eric

- Original Message 
From: Steven ** <[EMAIL PROTECTED]>
To: Openmoko < community@lists.openmoko.org>
Sent: Thursday, June 7, 2007 9:44:30 AM
Subject: Re: Yet another contender in the market?

The wallpaper on the F700 from the first Google result ( 
http://gizmodo.com/gadgets/cellphones/apple-iphone-vs-samsung-f700-which-is-touchscreenier-235112.php 
) is a total rip-off of the Ubuntu default theme.  I doubt that 
they're actually running Ubuntu (although I think Ubuntu is getting 
into the mobile market).


The features don't really seem comparable.  No wifi and no bluetooth.  
And the screen is even smaller and lower resolution than the iPhone.


-Steven

On 6/7/07, Tim Newsom < [EMAIL PROTECTED]> wrote:


Has anyone else seen the samsung F700?
Its features are pretty nice... No idea on the OS but I would definitly
take one over an IPhone... If it performs anything like it looks...
Hehe.

Its got very good specs.
--Tim


___

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



Never miss an email again!
Yahoo! Toolbar alerts you the instant new Mail arrives. Check it out.

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


--

Dangling carrots usually contain a hook.

09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0

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

Yet another contender in the market?

[Tim Newsom]

Has anyone else seen the samsung F700?
Its features are pretty nice... No idea on the OS but I would definitly 
take one over an IPhone... If it performs anything like it looks... 
Hehe.


Its got very good specs.
--Tim

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

Re: Publicity

[Tim Newsom]

Plus.. With all of the harassment we (the interested techies) are 
providing about slipping dates... Imagine what the public backlash could 
do?


Maybe too much publicity too early can be harmful?

--Tim

On Wed, 6 Jun 2007 17:15, Tehn Yit Chin wrote:
There is PR for the geeks and then there is PR for the masses. It would 
be nice to generate PR for the masses, but at this stage of the Neo1973 
product life, I don't think that it is PR ready for the masses.


On 6/7/07, Andrew Turner <[EMAIL PROTECTED]> wrote:


On 6/6/07, el jefe delito <[EMAIL PROTECTED]> wrote:

 I hardly think that my parents, or anyone else who may have a passing
 interest in a sweet phone, reads Slashdot.  My friends don't read 
it.  Even
 those who do read Slashdot seem to know little about the phone (read 
the

 comments in the article).


Be honest here - your parents, or anyone else with a passing interest,
is not going to be using the Neo1973 anytime soon either. The
article's audience hits squarely with the first-user audience.

If you talk with other hardware companies, you'll realize that they
usually get one chance with new hardware to really be successful. They
don't have the time or money to have a 'flop'. And getting widespread
coverage too soon would result in a flop because the device (or
lineup) isn't ready yet. So they'll look at it, think "not for me" and
never give it a chance again.

So while publicity is good, it seems prudent at this point for you to
hold off on widespread coverage until the entire hardware and software
base becomes solid and realized.

Andrew

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


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

Re: Iphone 3rd party development allowed...

[Tim Newsom]

AhI see. /shrug.

--Tim

On 6/5/07, David Schlesinger <[EMAIL PROTECTED]> wrote:


>I am sure Jobs and company are not blind to
>the strength of open source software and the
>boon it would provide if they made a freely
>available dev kit for the phone.

As someone who worked at Apple for ten years, I can assure you that, for
the most part, "Jobs and company" haven't got the slightest interest in
open source software, other than a minimal amount of stuff available
under a BSD-like license, allowing them to take it, do what they want
with it, and then keep it to themselves.


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

Re: Iphone 3rd party development allowed...

[Tim Newsom]

OK.. We can't have it both ways guys Half the time we are talking 
about getting to the point where openmoko and neo1973 can get the phone 
companies to take notice and possibly bundle the phone with their 
service.. And the other half we're talking about how Apple could not 
have done the same thing.  The fact is we don't know other than some 
vague comments at the moment.


On the one hand, supposedly the iphone is based on osx (true or false?) 
which is based on BSD (true or false?).  BSD is a unix flavor right? So 
are they porting BSD to the phone similar to linux with openmoko?  If 
so... Why can't they just use a similar development environment to 
openmoko... I.e. Gcc for BSD?  Which flavor of BSD is it based on?


I am sure Jobs and company are not blind to the strength of open source 
software and the boon it would provide if they made a freely available 
dev kit for the phone.


Maybe its time to start thinking about other things that differentiate 
us from them... If they are open now (I.e. Not talking about being able 
to replace the os with a customized version though that may be one 
thing...), then it will be content, variety, availability and ease of 
use which drive consumer adoption... (From my point of view anyway).


--Tim

On Tue, 5 Jun 2007 17:35, kenneth marken wrote:

Todd W wrote:

From: "Tim Newsom" <[EMAIL PROTECTED]>

So apparently Jobs decided to allow 3rd party software on the phone 
after all... Interesting development.

Yes, but how are they going to _support_ it?



or for that matter, how many hoops do you have to jump thru to get your 
app onto the phone? i belive jobs at one time used the word "simple" to 
talk about the kind of apps one would be allowed to make (or move from 
osx to the phone iirc). so for all we know they are planing to make one 
able to create something similar to dashboard widgets but not much 
else.


i just cant shake the feeling that the iphone will be a highly 
controlled environment, with apple as the guardian.


hell, they have partnered up with AT&T. and isnt mobile operators in 
the US notorious for locking down what phones can or cant do? i recall 
reading about bluetooth file transfer being removed and similar so that 
one had to use their network to transfer data to and from the phone and 
similar.


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

Iphone 3rd party development allowed...

[Tim Newsom]

So apparently Jobs decided to allow 3rd party software on the phone 
after all... Interesting development.

--Tim

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

Re: Neo1973 Update!

[Tim Newsom]

On Tue, 5 Jun 2007 7:52, Mauro Iazzi wrote:

On 05/06/07, Tim Newsom <[EMAIL PROTECTED]> wrote:
If your tracking movement with 2 3D accelerometers... What would 
another

one provide.
As far as I can tell (I am not an expert...)
Tracking all 6 vectors will tell you absolute movement in space.  I.e,
when 2 vectors point in the same direction with the same magnitude at
approximately the same acceleration as gravity.. Its probably laying or
positioned flat on that side.


"Probably" is the key here. with two 3d (linear) accelerometers you
cannot sense rotation around the axis between the two in an inertial
frame of reference.
Moreover you cannot distinguish if the Neo is laying face down or
pushed downwards with 2mg force. This example is somewhat artificial,
but means that you can probably find more realistic (though
complicated) movements that are not distinguishable with only two
accelerometers.

You must then consider the errors which sum up, if you try to track. A
rough mental estimate gives that you can sum up as much as 1 meter of
error in ten seconds if you have a precision of 10^-3g over
acceleration measure. (it does not mean that you are 1 meter away from
the real position, it means that you can only be sure that you are at
most 1 meter away from that).

Most of the time you will need good assumptions to get any information
from raw data:

http://www.wiili.org/index.php/Motion_analysis

can be of some help. No linear accel, no rotation, no tilt, are
assumptions which can give some meaning to the data and can be done
for single application, where you can assume the user will have some
particular behaviour (or you require it).

Still absolute tracking won't probably be anyhow realizable.

--mauro


So are you saying that 3 3d accelerometers in a line with 2 on the end 
and 1 in the middle will allow you to distinguish between rotation 
around the center axis, etc?


It would seem to me that there are some realistic assumptions which can 
be made to reduce error under normal usage.  In addition, in a 
navigation sense it would seem that you can use gps to provide error 
correction and thus be at least as precise (or maybe not far from it) as 
the gps between times when you are out of gps signal (I.e. Tunnel) etc.


Other than a navigation use, accelerometers will be useful for 
manipulating applications, but without a compass module, pointing or 
other types of "external" information apps might not be possible 
anyway.  If that's true, then each program will have some assumptions 
built in for normal usage.
Errors can be mostly ignored since what will usually matter will be the 
differences between vectors in very short timeframes OR the difference 
between the start vectors and the current vectors.  If the phone is 
suddenly dropped or thrown that's probably detectable as an extreme 
motion and maybe ignorable. /shrug

--Tim

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

Re: Neo1973 Update!

[Tim Newsom]

If your tracking movement with 2 3D accelerometers... What would another 
one provide.

As far as I can tell (I am not an expert...)
Tracking all 6 vectors will tell you absolute movement in space.  I.e, 
when 2 vectors point in the same direction with the same magnitude at 
approximately the same acceleration as gravity.. Its probably laying or 
positioned flat on that side.
If they vary and you have 4 vectors.. (Necessary when its tilted beyond 
the error amount...) You can figure out its orientation and angle.  If 
its spinning around its center (and assuming that the accelerometers are 
on opposite ends...) Then at least 4 vectors will point away from each 
other at approximately the same magnitude as its opposite but matched 
vector. (The other 2 may point down or up depending on if its spun flat 
or thrown or dropped. But they should be the same for a flat spin..)  
All vectors should be able to tell you the moment of movement and the 
phones basic translation in space... Especially if you keep track of the 
last known states... Right?


I mean  if we know the rest orientation and then suddenly get pointed at 
something it would seem like the 3d vectors will show a specific values 
and directions for the 2 ends of the phone depending on the center of 
the arc or movement that acted on the phone.


I would say that we can get yaw, pitch and roll just fine.. But again, I 
am no expert.


--Tim

On Mon, 4 Jun 2007 18:38, kkr wrote:
If I well understand, three accelerometers are necessary to fully 
define

all phone's movements. Isn't it?
 http://lists.openmoko.org/pipermail/community/2007-May/005216.html


So, what's the reason to have only two, and not three 3D 
accelerometers?

- the cost?... 3 $US (But I don't know if it's a 2D or 3D chip).
  
http://lists.openmoko.org/pipermail/community/2007-January/002085.html

- the lack of free space?
- ...

Is-it a 3D or a 2D chip?


Regards,





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

Re: First impressions of Neo1973

[Tim Newsom]

Thanks, that helps quite a bit.
But if that's accurate, the neo is not that big.  The sidekick 3 is 
slightly smaller and thinner than a sidekick 2 (my current phone) and 
the neo is considerably smaller than that...


Maybe its large to someone who uses a flip phone or set616 type phone.  
To me, it seems perfect.


In comparison, the Ipod phone is only about 2/3 or 3/4 the thickness 
(yeah, that a large gap.. But hey its eyeballed) and only a tiny 
fraction shorter.	 The widths are pretty much the same.


--Tim
On Wed, 16 May 2007 2:38, Peter A Trotter wrote:

Nice Jose,

I added the Sidekick3 dimensions...
http://www.sizeasy.com/page/comp/1842

-Pete

On 16/05/07, Jose Manrique Lopez de la Fuente <[EMAIL PROTECTED]> 
wrote:



Hello,

I've just done a fast "sizeasy" comparison:
http://www.sizeasy.com/page/comp/1840

And, yes, the Neo1973 is big!

2007/5/16, Tim Newsom < [EMAIL PROTECTED]>:


 On Tue, 15 May 2007 22:15, [EMAIL PROTECTED] wrote:
 >
 >
 >
 > On Tue, 15 May 2007, Tigran Zakoyan wrote:
 >
 >> Jason Elwell wrote:
 >>>  I dont know whats more sad... You creating a paperdoll of an
 >>> OpenMoko, or
 >>>  the fact that I downloaded it and made one for myself!  LOL!
 >>
 >> Me too :) BTW, can't agree 1973 is too big. It just fits the size 
of
 >> my QTEKs110, which size's been really handy for me two years I 
use it.

 >> Not to mention the difference in functionality :)
 >
 > Me three. Next to my Sidekick, the Neo is petite.
 >
 > It's all relative.
 >
 > M

 Could you, or someone who just happens to have both, post a picture
 containing them side by side and edge on for comparison?

 I figured it would be about the same dimensionally (HxWxD) as the
 sidekick.  Is it smaller? Thinner? Wider? Shorter?
 --Tim

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



--
J. Manrique López de la Fuente
http://www.jsmanrique.net
msn: [EMAIL PROTECTED]
jabber: [EMAIL PROTECTED]

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


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

Re: First impressions of Neo1973

[Tim Newsom]

On Tue, 15 May 2007 22:15, [EMAIL PROTECTED] wrote:




On Tue, 15 May 2007, Tigran Zakoyan wrote:


Jason Elwell wrote:
 I dont know whats more sad... You creating a paperdoll of an 
OpenMoko, or

 the fact that I downloaded it and made one for myself!  LOL!


Me too :) BTW, can't agree 1973 is too big. It just fits the size of 
my QTEKs110, which size's been really handy for me two years I use it. 
Not to mention the difference in functionality :)


Me three. Next to my Sidekick, the Neo is petite.

It's all relative.

M


Could you, or someone who just happens to have both, post a picture 
containing them side by side and edge on for comparison?


I figured it would be about the same dimensionally (HxWxD) as the 
sidekick.  Is it smaller? Thinner? Wider? Shorter?

--Tim

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

Re: Durability of the Neo1973?

[Tim Newsom]

No problem.. It was more of a rhetorical(sp?) question anyway.  I was 
just trying to point out that the situation was a bit different.


--Tim
On Tue, 15 May 2007 18:41, Robin Paulson wrote:

ahh, damn gmail shitesorry tim

from trolltech.com

"Q. Did Trolltech design the phone? Are there other models to choose 
from?


A. Trolltech worked very closely with one of our Qtopia-licensed ODM
partners in China, Yuhua Teltech, to make this first, open platform
Greenphone a reality. Trolltech envisions a continuing collaboration
with Yuhua for future models based on different hardware
configurations."

odm = original design manufacturer. so trolltech probably didn't make 
it


regardless, both look awesome phones - i can't wait to get my hands on
OM. a few weeks late won't put me off




 Smaller than Nokia/Sony, sure. But they are well over 20 times the 
size

 of Trolltech, who launched the greenphone.


Ahh.. But who manufactured the hardware for the greenphone
Trolltech?... Probably not.


___
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: Durability of the Neo1973?

[Tim Newsom]

On Tue, 15 May 2007 18:16, Ian Stirling wrote:


FIC is not a small company.  http://www.fic.com.tw/about.htm Over 5000 
employees isn't small.


Smaller than Nokia/Sony, sure. But they are well over 20 times the size 
of Trolltech, who launched the greenphone.


Ahh.. But who manufactured the hardware for the greenphone 
Trolltech?... Probably not.


--Tim

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

Re: Anti Iphone (Was Re: Some light ahead...)

[Tim Newsom]

On Mon, 30 Apr 2007 11:56, Steven ** wrote:
/snip

I don't understand.  Of course I'll want MythTV on my phone (iPhone or
Neo).  I'm not going to buy Apple TV because I already have MythTV
setup and doing everything I want and more.  I intend, at the very
least, to use my Neo as a remote control for my Myth Box.  I'd also
like to get a simple Myth frontend so that I stream video to the Neo.
That will be harder, but awesome.

-Steven


Can you imagine... Think of you tube but with channels of shared tv 
broadcast to phones... Maybe like public tv but where users or 
individuals could select the content... Does that exist?  I am not 
talking rebroadcasting (copyright issues) but new content owned by 
individuals who would like to share it and give the rights for that.


--Tim

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

Re: OpenMoko light web server

[Tim Newsom]

On Tue, 24 Apr 2007 13:58, Matthew S. Hamrick wrote:

BTW... I tried this out, it seems to work fine.

It still feels "wrong" to intentionally leave an HTTP connection open  
like this, but it seems to work okay when I test it.


I'm building some new javascript for the jowles interface that uses  
async requests, along with an XML service interface and will publish  
the code to the hbmobile project ( http://code.google.com/p/ hbmobile/ 
) "any day now." I'm starting to document this stuff at the  Jowles 
wiki page.


Tim... thanks for the idea of using async requests, it should have  
been obvious, but it wasn't, so thanks for pointing it out.




I am glad it worked out for you.
It may not be perfect, but whatever works till something better comes 
along.


Out of curiousity, do you have all requests operating in the same page 
or do you have some off loaded into a seperate page via iframe or 
something similar to get multiple threads operating?  (I am just 
guessing that an iframe or other similar mechanism will create a 
different thread for the javascript in that page)


--Tim

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

Re: OpenMoko light web server

[Tim Newsom]

On Tue, 17 Apr 2007 8:25, Peter A Trotter wrote:

Hopefully not wading in half cocked here but...

AFAIK non of the major web browsers implement threading for their 
javascript engines, or at least not within a single window. Hence when 
your asynchronous call returns it does not get executed until the 
current javascript thread terminates. Obviously this is unacceptable on 
the desktop but in terms of web apps it seems the right thing to do. 
That said javascript should only be used to enable the interface - we 
shouldn't be using it for any long execution stuff.


-Pete


I think the real question is if each page has its own thread... I think 
it must.  In which case an iframe or other construct could be used to 
get around the single thread issue on any specific page.


Seems odd to have only a single thread when creating async requests.. It 
seems like it would create a new thread for the connection and let it 
wait while moving on.  In that case, the event handler would be called 
by the second thread so it should all work out.  If they really only 
have one thread and never switch context then it would not matter though 
I guess.

--Tim

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

Re: OpenMoko light web server

[Tim Newsom]

On Tue, 17 Apr 2007 3:54, Alexander E Genaud wrote:

Tim,

I believe Microsoft created the non-standard XMLHttpRequest object
through Active X around IE 5 but it has become something of a standard
implemented by Firefox, Safari/Konquerer, Opera, and perhaps others.
I've been using a nice wrapper, Sarissa, successfully for a few years
in many environments.

http://dev.abiss.gr/sarissa/

I believe the asynchronous flag is implemented in those major
browsers. Alternatively, you can create an HttpConnection "class" with
it's own timeout, abort, polling (4K), threading, etc. While the
details are different across browsers, it seems that threads never
context switches unless explicitly asked to do so (such as Timeouts
and alert dialogs). In other words, a "ring" might come in, but if you
are calculating the Fibonacci numbers to the umpteenth power, the
"ring" thread probably won't alert you in good time. I believe that is
true regardless of the async flag.

Alex


Alex,

Hmm, that's interesting... It seems like a poor implementation if you 
can't guarantee that the event will fire asynchronously.  Why offer it 
at all?  Strange.


--Tim

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

Re: OpenMoko light web server

[Tim Newsom]

On Mon, 16 Apr 2007 13:58, Matthew S. Hamrick wrote:

Okay.. a few points:




Q. javascript? on a phone? Isn't that going to suck down the power?

A. in a word, yes. But I think the main problem will not be the added 
overhead of using javascript, it's going to be the frequent request / 
response. In the old days when we bundled ORBs with browsers, we could 
execute java (and presumably have a javascript interface) that would 
receive asynchronous messages from the server. Why is this important? 
Because the phone (on the other side of the http interface) is going to 
ring or receive an sms message or the signal is going to go up or down. 
And these are things that occur outside the context of a client 
request. So, if you want to see if the phone just rang, you have to 
keep pinging the web server every second or so, and if it responds with 
"I'm ringing," you fire off the javascript that draws the "I'm ringing" 
icon on the interface. All in all this is pretty substandard.




Ok.. Well this is probably somewhat browser specific, but in the 
XMLHttpRequest methods there is a synchronous or asynchronous flag.  
Synchronously will behave in the normal request response method and wait 
for a return before continuing to execute... Async will allow the code 
to continue executing and then fire the response once it sees it.  I 
don't know if there are timeouts or not and I have not played around 
with it much, but it seems like you could build several request 
objects... One might be dedicated to the ringing function.. Then place a 
timer on it and if there is no response by the timeout you could reset.  
All the request would do is ask if the phone rang and wait.. Then your 
cgi code could sit for the period of the timeout waiting for either a 
request (to cover the situation of the phone ringing between requests) 
or responding when the phone rings...


This should be more like the subscription model where you ask to be 
notified and at any point it could happen.  But, like I said, it may be 
browser specific. /shrug

Just something to look into maybe.
--Tim

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

Re: [News] Dash, the internet-connected gps

[Tim Newsom]

On Tue, 10 Apr 2007 6:12, Dean Collins wrote:

Yep, coding easy to do however issues are-

Mapping of roads and associated speed limits, almost non existent in 
the

commercial space let alone in the open source space.



Regards,

Dean Collins
Cognation Pty Ltd
[EMAIL PROTECTED]
+1-212-203-4357 Ph
+1-917-207-3420 Mb
+61-2-9016-5642 (Sydney in-dial).



The last navigation system I had was able to predict how long it would 
take for me to get where I was going over many different 
roads..(highway,streets.. Etc) and then adjust it based on my actual 
speed and the distance remaining.  I think the speed limits are in there 
also for that purpose.

--Tim

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

Re: Blacklist/whitelists

[Tim Newsom]

On a related note to all of this sms talk... Can you send an sms with 
delivery receipt to a range of addresses and get back notification for 
all phone numbers which actually exist? (Obviously it will be one at a 
time, not boradcast)


Or does it just return success once it changed network providers and it 
doesn't matter?


Basically, could you use this to find out the network that owns a bunch 
of numbers or to find out which network a number belonged to in some 
way?

--Tim

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

Re: Blacklist/whitelists

[Tim Newsom]

On Fri, 6 Apr 2007 11:22, Jonathon Suggs wrote:
Ok, I'll be honest that I have no proof that this is how it actually 
works, but I don't think it works the way you are saying it does.  
Again, not 100% positive, but the "receipt" that you receive is only a 
message that it has been successfully transfered to the carrier.  The 
carrier will then try to push the SMS to the recipient whenever they 
become available.  So there are two discreet actions.  1) Transfer from 
sender to carrier 2) Transfer from carrier to destination.


Rather than get all worried about big brother, just do a simple test.  
Turn off a phone and send a text message to it.  See if you get a 
receipt.  If you do, then I'm right.  If you don't get a receipt until 
the phone you sent a text message to is turned back on THEN commence 
the meetings of the tin foil hat club.


-Jonathon


Ahh. You obviously mis-understand my comments.
Besides, what is the point of a delivery message to send to the carrier? 
It doesn't provide any value to the user over the message on the phone 
saying 'your message was sent'.  That would be confirmation to me that 
the carrier got the message. In fact, on my sidekick 2, if the message 
could not be sent for some reason then I get a message saying it could 
not be sent, I.E.  The carrier didn't get it.


In either case, I always turn off any kind of receipt regardless of 
program.

--Tim

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

Re: Blacklist/whitelists

[Tim Newsom]

On Fri, 6 Apr 2007 9:41, Martin Raißle wrote:

Is it possible to turn delivery reports off?
--Tim


I think it's not .. at least not for the receiver of a message ...
martin


That seems weird... Even in email you can turn off read receipts... It 
seems like an invasion of sort (though a minor one) to not allow 
disabling of delivery reports for the receiving party.


If the sending party can enable it and the receivers phone automatically 
responds, then you can always know when someones phone is turned 
on/available.


Does the sms message system work while the phone is in call mode? Does 
that require multiplex code also like the gprs while on a call does?
If it doesn't work while calling, you can always find out when someone 
is done talking on the phone / is available to talk (assuming they are 
at the phone) by sending an sms with delivery report first... Right?


Seems like there should be some kind of control message that could be 
sent over the serial port via 'AT' commands which would enable and 
disable this.

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

Re: Blacklist/whitelists

[Tim Newsom]

On Fri, 6 Apr 2007 8:35, Andreas Kostyrka wrote:

You cannot block them. But you can make the phone completly ignore it.
OTOH, that's not the same thing because combined with a delivery
report, somebody else can see when you turn your phone on :(

Andreas


Is it possible to turn delivery reports off?
--Tim

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

Re: Proposal: Personal Data Encryption (maybe SoC?)

[Tim Newsom]

On Fri, 23 Mar 2007 7:38, Gabriel Ambuehl wrote:

On Friday 23 March 2007 15:25:24 Tim Newsom wrote:

KISS and just encrypt whole files or keep whole files in plaintext. So 
either

that note application saves its file into the unencrypted tree or the
encrypted one but mixing data inside files seems way more complex than 
really
needed. It's not like notes are so big that the penalty of encrypting a 
few

more than required would be that huge.


Granted, for notes it would not be. It was just an example.

I guess I am thinking of something like a proxy for all file 
operations.. Including sockets.  But one where the applications don't 
really need to know what's happening to the information.


They make a call to read on a file handle and the proxy picks it up and 
as joe said it "Does The Right Thing".  I include sockets because I can 
foresee a time when someone (me maybe) might want to turn on encryption 
for an application that communicates over the net but isn't smart enough 
or wasn't built with any kind of encryption.


Having one system handle all of these the same way would simplify 
implementation and unify administration (it seems to me anyway).

--Tim

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

Re: Proposal: Personal Data Encryption (maybe SoC?)

[Tim Newsom]

On Fri, 23 Mar 2007 2:13, Gabriel Ambuehl wrote:

I'm not entirely sure why one would need a new FUSE driver then.

Can't you just use encfs (I gather you don't want LUKS because it needs
setting Filesystem size in advance and I can see why one would want to 
avoid
that [1]) and tell the apps to either use the encrypted tree or not? 
Then any
app can be made to use the encryption features by virtue of providing 
it with

proper paths.


One important thing eventually will need to be the ability to encrypt 
data written from applications which don't know about the encryption 
system.
If I am in a notes application and I write a note, ideally you would 
have some kind of db holding all of that information.. The 
implementation of the db is not important to my discussion at this point 
and for all I care it could be some daemon on top of an xml file or 
sqlight (sp?) or what have you.. When you encrypt it, it should be 
secured.  Now in a db you kinda have to be careful because people will 
want to fill up the column space with normal characters.  When we 
encrypt, that might (probably) increase the actual datasize right? 
Encrypting "the cow is blue" which contains 15 characters may require a 
pad to 16 and then block encrypted may be larger then 16, right?  That 
all depends on the method of encryption I guess.. Maybe some will be 
exactly 16 or if its not a block encryption algorithm maybe it can just 
encrypt the 15 bytes into 15 other bytes?  Anyway, the method would need 
to be independent of the application somehow.


I like the idea of having 2 storage paths... One encrypted and one not.  
From my very quick and non-authoritative glance at unionfs we could make 
2 trees, one encrypted and one not and have it make them look like one 
path.  Its not clear to me how we make sure we write to the encrypted 
one on demand however..


I have not looked at pefs but if it does like joe indicated then it 
handles the encryption/authentication stuff..  So all we need to do is 
somehow mirror and join the db calls or filesystem reads/writes between 
the encrypted and non-encrypted filesystems and voila.. You have it all 
working and for the most part, transparent.  The transparent piece 
requires the interception of low level api though... In order to capture 
the read or write before it hits the filesystem unencrypted.


I grant you, all of the above is a huge oversimplification of the 
process. (Grin)




Things like unmounting on inactivity etc can easily be handled by a 
small user
space daemon running besides FUSE then. And if you want to provide 
different

levels of security, simply add more trees...



How would this work from a db perspective? If a notes application does 
not know about encryption and just knows to save data... And it uses 
some kind of a db file to do it, how do you secure that partially?  One 
note secure and one not?  If it used files for each note that would be 
easier, but in a db?  It seems like you would have to mirror the db file 
itself and somehow join them together before the read in order to get it 
working and that seems way too complex.  At the moment I don't see a way 
without encryption the entire db.  The application probably won't be 
expecting 2 dbs and won't know how to handle it. /shrug

--Tim

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

Re: Proposal: Personal Data Encryption (maybe SoC?)

[Tim Newsom]

On Thu, 22 Mar 2007 12:13, Tim Newsom wrote:


On Thu, 22 Mar 2007 10:17, Joe Pfeiffer wrote:

Thoughts?


From what I remember of the discussions so far, that seems to meet the 
majority of requirements for encrypted file storage and also manages 
many of the things related to authentication that we have been 
discussing.


In a semi related note, how would we enable this ability for things like 
the contacts database? Or any other application database for that 
matter?


Any ideas?
--Tim

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

Re: Proposal: Personal Data Encryption (maybe SoC?)

[Tim Newsom]

On Thu, 22 Mar 2007 10:17, Joe Pfeiffer wrote:

Thoughts?


From what I remember of the discussions so far, that seems to meet the 
majority of requirements for encrypted file storage and also manages 
many of the things related to authentication that we have been 
discussing.  Now, if we can specify the manner in which the password is 
entered (gesture, pin, etc.) then maybe its just this 'easy' ?  Lol. 
Easy being relative because its already built.


IMHO that would work pretty well.  At least for what I am interested 
in.

--Tim

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

Re: Proposal: Personal Data Encryption (maybe SoC?)

[Tim Newsom]

On Wed, 21 Mar 2007 14:59, Henryk Plötz wrote:

Moin,
Plus: If you really want per-file encryption that would only need some
minimal modifications to the existing solutions. Or use unionfs.


That's very interesting and opens up lots of potential.

Your right, key management along with many other topics have not been 
discussed in any detail.

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

Re: Proposal: Personal Data Encryption (maybe SoC?)

[Tim Newsom]

On Wed, 21 Mar 2007 14:35, Joe Pfeiffer wrote:

But it has the "encryption jail" drawback.


So maybe one way to deal with these issues is to build out the framework 
by constructing a new api for reading and writing data based on this 
provider concept.. Including the authentication.  Then deal with and 
flesh out the issues we encounter along the way.  At the same time or 
sometime later, another task can be started to hook into the os level 
read/write calls and make it work for every application the same.  Maybe 
as some kind of layered filesystem driver or something, I don't know.


Anyway, the point is that there are many many tasks to deal with related 
to the entire framework for this to work at all, right?  And in the 
short run, all OM applications have a specific api anyway to make them 
work with the gui etc.


The risk to security of doing it this way is minimal as using a program 
without the encryption hook just means that the program sees an 
encrypted file.  Sure, it could damage the file if it wanted but for the 
most part the information will remain secure once encrypted with 
whatever mechanism.


Later once the framework is up and some demo plugins are in place to 
show encryption providers and authentication providers and data 
readers/writers for various filesystem/database flavors, maybe we can 
deal with the issues related to 'all other applications'.  That is, 
unless someone just happens to know off the top of their heads that its 
about x lines of code to do this by hooking into the os read/write 
routines with x being some number less than infinity?( ok, that was 
meant as a little joke)

--Tim

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

Re: Compressed SMS (and other text messages)

[Tim Newsom]

On Wed, 21 Mar 2007 14:35, Jonathon Suggs wrote:
My challenge is just to think bigger.  Think how this could be 
incorporated to work with *any* phone.  Then you can have a much larger 
group of people to brainstorm, test, and bugfix.  We have enough 
protocols and standards to support.  Creating yet another one isn't 
really going to help that much.  Also, I don't know anyone else that is 
planning on getting a OpenMoko device, so its pretty pointless for me 
at this point.  I know you've got to start somewhere, but starting out 
a battle fighting uphill isn't the best of ideas.


Sorry if I completely missed the point.


So one approach might be to investigate the java implementation on other 
phones and see if you can gain access to sms for receiving and sending 
messages.  Then you could write it to test the waters on openmoko.. Then 
build a java version for other phones that done have openmoko 
installed.


/shrug
Its an idea anyway.. But its only worth 1 cent since I didn't take the 
time to see if java can do that with any of the midp/whatever version 
that's common now.

--Tim

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

Re: Proposal: Personal Data Encryption (maybe SoC?)

[Tim Newsom]

On Wed, 21 Mar 2007 13:03, Joe Pfeiffer wrote:

Hope my notes above are helpful...


Hehe that's great. At least I am certain that you and I are on the same 
page now.  I thought from my very quick glance at truecrypt that it 
could encrypt individual files also but I have not had a hard look and 
so no definite answer there from me.


I know there are many many solutions to encryption and it would be nice 
to have a mechanism to install and use whatever the user wanted to setup 
and configure.


Say gpg provider where you specify your keyring..
Or Encryptfs, truecrypt, LUKS, name your encryption method, whatever and 
handle the technical issues only once at install/config time maybe with 
recommended parameters based on the device and expected use or 
something. /shrug.


Your ahead of me on looking at the code.
--Tim

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

Re: Proposal: Personal Data Encryption (maybe SoC?)

[Tim Newsom]

On Wed, 21 Mar 2007 9:34, Joe Pfeiffer wrote:

Tobias Gruetzmacher writes:

Right -- these look like good approaches, but to a different problem.


/please excuse my direct manner.. Its just how I write (smile)

What do you mean by different problem? Maybe I don't fully understand.  
The way I see it you have a few interoperating components...  Dbus can 
be the primary transport mechanism, some reader plugin which abstracts 
the actual source of the data.. Be it the filesystem or a file which 
sits on the filesystem that has its own filesystem.. Or a dbfile system 
(I have not heard much about that recently)... A writer plugin which 
does pretty much the same thing, but for writing and not reading.. Maybe 
they are even the same plugin.. /shrug


Then you have some authenticating system which allows various methods of 
authenticating a user.. Be it fingerprint reader or pincode or whatever 
based on the currently selected provider/plugin... And you have the 
application.


At the lowest level is the encryption/decryption system.. Right above 
the filesystem somewhere.


Now, when the phone is idle long enough or locked and a user tries to do 
something, the currently configured login / unlock / whatever you want 
to call it authentication plugin is activated and asks for the required 
information / gesture / whatever.


Once obtained the user is granted whatever rights they configured for 
that action.. By default it can be nothing or a pincode and the default 
level can also be set to wide open, no encryption and full access.  
That's the state of almost every phone on the market right?


Ok.. So an advanced users phone may have 3 or 4 levels of authentication 
and access / encryption.. Maybe even different algorithms are used.  Who 
knows?  When they log in they probably set it to the lowest level of 
access.. The notes application can read plain text with no problems and 
any unsecured data is visible.. Including contacts, notes, pictures, 
music, whatever.


Now suppose this individual decides to read an encrypted file or runs an 
application configured to access an encrypted file or file system.. The 
authentication system would then ask for additional authentication and 
once granted handle the key pass to the decryption system / whatever to 
read the file.


Now I don't have any experience with truecrypt or LUKS yet.. But they 
were mentioned along with encryptfs etc as a means of handling the 
encryption part.


Maybe you can help me with where I missed out on the problem so that I 
can get my head around it? (Grin) I would love to make sure I fully 
understand what you are saying.

--Tim

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

Re: Regarding encryption on openmoko...

[Tim Newsom]

On Wed, 21 Mar 2007 1:33, Gabriel Ambuehl wrote:
I don't really see why one would want to use Truecrypt when there's 
been LUKS

in the Linux kernel for years now...


Well, for one I had never heard of LUKS till earlier yesterday.  Now I 
will have to go check it out. (Grin)

--Tim

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

Regarding encryption on openmoko...

[Tim Newsom]

After reading about truecrypt on slashdot I think that could pose as a 
suitable start to the encryption solution... At least as a starting 
place to build a framework on and test out some ideas.

--Tim

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

Re: Proposal: Personal Data Encryption (maybe SoC?)

[Tim Newsom]

On Tue, 20 Mar 2007 8:12, Jim McDonald wrote:

Tim Newsom wrote:

[Encryption options]

Yep I understand that there are lots of possibilities and options, I 
just think that if something ships by default it should provide end 
users with a very simple dialog that is basically an on/off switch for 
'protection of personal data' (or something else that doesn't even 
mention encryption) and the additional levels of configuration can be 
made available through plugins or whatever.


Perhaps I've spent too long battling with ugly interfaces, but I think 
that if OpenMoko is going to have a broader audience than the people on 
this list and their kindred-in-geekness then a large amount of the 
effort will be deciding how to keep the interface as simple and 
streamlined as possible rather than loading the default build with 
every option imaginable...



--Tim


Cheers,
Jim.


I completely agree.
--Tim

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

Re: Proposal: Personal Data Encryption (maybe SoC?)

[Tim Newsom]

On Tue, 20 Mar 2007 2:08, Jim McDonald wrote:

Tim Newsom wrote:
The best part is that if you don't want it, you don't use it.  And 
those that do want it, can use it and its all completley transparent 
to the applications.
But not at all transparent to the end user.  Again assuming that there 
is some sort of key caching going on, what is the real consumer benefit 
to having multiple ways of categorising data to different levels of 
security versus having a simple "protect my data against unauthorised 
access" checkbox somewhere that blanket-enables encryption?


(Alternatively there could be some way in which these configuration 
settings are pluggable and people with the more complex requirements 
could download the advanced settings plugin and leave normal users with 
a simple yes/no choice.)

--Tim


Cheers,
Jim.



I don't think you want security which is transparent to the user.. If 
the user does not know it exists then they won't know they are using 
it.. And then they might do something which causes problems later on.  
The user should have full knowledge of what they are doing.  That 
doesn't mean it has to be difficult or have 200 commands at the prompt 
to set up.  It can be easy and guided.. And possibly just an advanced 
menu somewhere which contains the necessary jump points into the 
security configs.


Remember, most users (the average mom and dad) will not use the security 
features anyway.  Some because they don't know how, some because they 
don't think of it and some because they just can't be bothered to set it 
up.


Now, the ones that don't know how may at some point try to learn, so it 
needs to be able to help them through it.  More advanced configs don't 
have to be set up by the average person either.  Its the flexibility 
that is desired.  Maybe it ships with password / gesture providers by 
default and someone can 'load new security providers' where it connects 
to a trusted source for signed openmoko security engin plugins 
(providers being easier to say).


Once connected they could read descriptions of available providers, 
install them and during the install it asks some questions about how 
they want it initially configured.  If they have not set up any security 
before, maybe it asks them the 'first time questions'...


It can educate them on potential dangers without spreading FUD and open 
their eyes to the awesome potential that is the openmoko platform.


Lets also not forget that openmoko is not just for phones.. But also 
other devices.  This scheme could be used by anything... From a laptop 
with someones fingerprint reader and using a fingerprint security 
provider or some not thought of security mechanism to the next hand held 
multimedia player device (though why you would want security on it is 
your guess... Maybe security camera videos of a sensitive nature?)..


Lets think universal and try to apply what we are creating to a larger 
set of devices.


--Tim

--Tim

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

Re: Proposal: Personal Data Encryption (maybe SoC?)

[Tim Newsom]

On Mon, 19 Mar 2007 22:09, Joe Pfeiffer wrote:

I like this -- except it doesn't quite match my sample-of-one user
study.  My degree-of-security-wanted is by data, not by application.
The same app is used for things like VINs and tire sizes and oil
filters for cars (no security) and for student presentation grades.

It's also not clear to me that more than two levels of security
(open/password protected) are needed -- where password protected means
encrypted using whatever scheme we've got.



See that's where the 'ask me' setting comes in.. If an application can 
store encrypted vs not then its an 'ask me' then on a per data basis you 
can set it.


The multi level security might not be necessary, but this scheme can 
handle it just in case.  The best part is that if you don't want it, you 
don't use it.  And those that do want it, can use it and its all 
completley transparent to the applications.

--Tim

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

Re: Proposal: Personal Data Encryption (maybe SoC?)

[Tim Newsom]

On Mon, 19 Mar 2007 18:25, Jim McDonald wrote:

Clare Johnstone wrote:

On 3/20/07, Jim McDonald <[EMAIL PROTECTED]> wrote:


continually asking the user to decide which data is to be encrypted and
which not.



There is the concept of "folders" which could be used :)
clare
True, but that's just another choice to be made when storing the data 
plus of course you have filesystem folders, arbitrary categorisation 
through tags, automatic classification depending on the type of data 
etc. so there are lots of concepts that can be used, and each one is a 
potential set of confusion ("I tagged the data as 'sensitive' but the 
system didn't encrypt it because I accidentally put it in the 'public' 
folder).


I just think that this is a good example where having an all-or-nothing 
approach is preferable to fine-grained control, as the benefits are 
minimal compared to the complexity for development and day-to-day 
effort for end-users that have to use such a system.


Cheers,
Jim.


Ok.. Lets assume for a moment that there is an encryption / security 
engine.. And its hooked through dbus somehow..  Lets also assume there 
is a mechanism that handles all requests to save data from any 
application... Will just call it the save data mechanism.. (Grin)...


So on the encryption / security engine it seems like there should be the 
ability to define user selectable levels of encryption / security.. Such 
as no encryption but password required.. Light encryption password 
required... Heavy encryption picture/gesture required (and maybe a 
certainty level for fuzzy matching like 90% /shrug).. or no password and 
no encryption.. Etc.


Ok. There should be some kind of configuration for the save data 
mechanism which says select the published security levels (I.e. Those 
the user created in the security config) and then select which 
applications follow those rules.. So notes could be no security/no 
password or it could be 'ask me each time'... Calendar could be the 
same.. File browser could be heavy encryption with picture.. Etc.. Then 
each application does not need to know anything about the security 
levels at all. It just calls the save information api (whatever that is) 
and hands dbus the data to save.  The save mechanism looks at the 
request and notes the application its coming from and then hands it off 
to the security engine to encrypt appropriately.. And then it hands it 
back at which point the save data mechanism can write it to the file 
system..


Reading is the same.. Except the read data mechanism looks at the 
application making the request and in the case of ask me data looks at 
the data to see if its encrypted/secured.. If so it tells the security 
mechanism which asks the user for the appropriate level of password 
information and then decrypts or authenticates the read action and the 
user gets to read the data.


Combined with the sudo idea about a configurable amount of time for 
authorized idleness... And add to it the ability elevate permission 
levels..  So that once you have authorized to read highly sensitive 
information you can also just read password protected but not encrypted 
info.. And then I think it might meet everyones needs.


By default no security is provided and none required..  Once configured 
it could handle almost any level of detail for encryption assuming 
someone wanted to go through the trouble of making it happen that way.


And you could build new security mechanisms that plug into the 
architecture and allow for some people gesture authentication and for 
others hand writing codes or voice codes or numeric codes or anything.


Um... Yeah.. Ok so that might be 10 cents worth.
--Tim

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

Re: Proposal: Personal Data Encryption (maybe SoC?)

[Tim Newsom]

On Sun, 18 Mar 2007 18:05, Henryk Plötz wrote:

Moin,



/snip


Some feedback will be necessary so the user can see that the gesture
was correctly detected before sending the PIN to the SIM. I propose 
some

sort of bubblebabble-digest.

--
Henryk Plötz
Grüße aus Berlin
~ Help Microsoft fight software piracy: Give Linux to a friend today! ~


Can't you just draw the lines that correspond to the locations touched? 
A gesture can be 1 symbol drawn over the entire screen without picking 
up the pin/fingertip... Or it could be a 5 second drawing of kanji or 
some other symbol.. In addition, since it has to be fuzzy, the gesture 
needs to be ralative to the start position of the drawing and should 
give a configurable amount of time to enter the entire picture/gesture.


Then someone could draw whatever they like in 5 seconds or 10 or 
whatever.. Or they could do something simple with their finger tip or 
they could actually write words on the screen, etc.  Plus, if you are 
going to have a 3x3 grid, you might want to make that configurable 
also.. To add a lot of variability in the supposed gesture / key.


Just a few thoughts... Flame away. /grin
--Tim
___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Fw: Re: Possible security hole for Dialers/troyan horses

[Tim Newsom]

Sorry, got caught in the reply to issue.

-Original Message-
From: Tim Newsom <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Re: Possible security hole for Dialers/troyan horses
Date: Mon, 5 Mar 2007 7:02:58 -0800


On Mon, 5 Mar 2007 0:05, Evgeny wrote:

On Fri, 2007-03-02 at 07:35 -0800, Tim Newsom wrote:

 On Fri, 2 Mar 2007 6:09, Evgeny wrote:
 >
 > It still Linux based phone — there is absolutely no real-life 
viruses

 > for Linux at this time, trojans are possible treat, but user have to
 > install them by himself.

 That's a pretty strong statement.. Are you absolutely sure there are 
no

 viruses for linux in the wild?

Nope.
If you find one, let me know I'll get, compile $ run "the beast" a
little (In virtual machine of course).
Well if & then you speak about trojans, the cure is "DO NOT INSTALL
THEM". Security holes may exist, but patching them is simple then you
know about them, and in OpenMoko it will be automated by "ipkg".
Read trough  http://tldp.org/HOWTO/Security-HOWTO/ it contains some
basics of security in Linux.
When we will speak  the same language.
There is no Norton Internet security, that can protect you from unknown
treats. When you know about trojan or something, you simple don't use
(it if you don't wont to).
--
Sincerely Evgeny


I realize nothing can protect you from every possible manner of attack, 
but I do know there are vulnerabilities that exist in linux.  If not, 
SELinux would not have been necessary.  If you say there are no viruses, 
I would say that's either because no one has written them or they are 
just not popular right now because windows is a much easier target to 
hit.  My statement was that something like Norton Internet Security 
combined with the ability to run programs in isolated memory should 
provide a lot of protection.  The isolated memory would prevent the 
infected programs from accessing the memory of other running programs 
(something that's possible on windows for sure) and the anti-malware 
program could do like someone previously suggested and check a hash of 
the program to see if it is a known and accepted version with allowed 
rights, etc.  Maybe check the hash and a signature so show 
authenticity?


While you can't detect unknown threats automatically (though I thought 
an anti-virus company said they could do that recently) you can block 
the unexpected behaviors automatically and recommed to the user certain 
actions.


Remember, there are rootkits out there too. Maybe it would be nice to 
have a startup mode where the system goes into rootkit detection mode 
and scans the physical memory of the device and filesystem or 
something.


Regardless, I think its better to have a pound of caution when a half 
pound would do...

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

Re: Possible security hole for Dialers/troyan horses

[Tim Newsom]

On Fri, 2 Mar 2007 6:09, Evgeny wrote:


It still Linux based phone — there is absolutely no real-life viruses
for Linux at this time, trojans are possible treat, but user have to
install them by himself.


That's a pretty strong statement.. Are you absolutely sure there are no 
viruses for linux in the wild?


It would seem to me that the time to think about protection is before 
you have a problem. Granted, you will never catch everything up front. 
However, thinking about and dealing with the trojan, virus , issue is 
not too different from the steps we were taking to notify about 
unintended actions of programs. I.e. Getting a notification and deciding 
on how the action should be handled, etc.  I think Norton Internet 
security does an excellent job on windows.. It knows about many, many 
applications and versions of them, can tell you if it was modified or 
contains known threats including trojans, lets you know when a program 
does something it was not explicitly allowed to do and does it pretty 
well without making my laptop crawl.  Combined with a rootkit detection 
system of some kind it would be great, but I am sure there are still 
holes in it I don't see.  Right?

I would use it on my phone if it existed for that platform.
--Tim
___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Possible security hole for Dialers/troyan horses

[Tim Newsom]

On Thu, 1 Mar 2007 14:42, Tomasz Zielinski wrote:

2007/3/1, mathew davis <[EMAIL PROTECTED]>:

then give it a rating of some sort 1 - being safe/trusted program and 
10 -
being known bad binary/ don't use at any cost unless you really want 
bad

things to happen.


Well, nobody will recognize difference between rating 2 and 3 or 6 and
7. I think set of three values is sufficient: 1 - allow network/GSM
activity, 2 - ask every time app is trying to open connection/send
SMS/make voice call, 3 - ban without asking.

I wonder if OpenMoko system/library calls can be overriden or catch at
layer which will be able to show dialog popup for setting 2.

--
Tomek Z.
[EMAIL PROTECTED]


What about a mobile virus/trojan/malware protection system.. Say like 
norton antivirus or  designed to help 
identify and protect the user from known threats...
Having that installed you could scan it when it was saved and alert on 
the threat, protect against unknown activity when it starts or while its 
been running and kill it/quarantine it if necessary.  Combined with its 
own protected memory area so that it can't harm or investigate running 
programs it would seem to provide the best of all worlds..


Is something like that available? What do you think it would take to 
convert a currently available linux based program similar to the above 
to do this?


--Tim

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

Re: Platforms for Engineering school labs (Was: Re: RFC: Public targets having a big potential: Engineering schools)

[Tim Newsom]

On Sat, 24 Feb 2007 23:45, Richard Bennett wrote:

On Sunday 25 February 2007 01:59, [EMAIL PROTECTED] wrote:

 Students will have access to the hardware via JTAG, and more via the
 lunchbox.


Yesterday photos were shown of the lunchbox. Sean said they were 
thinking of

changing the name to something like 'OpenMoko Bombsquad' as 'lunchbox'
carries too many negative connotations of school bullies and stolen 
lunch

money ;o)
It also *looks* like something out of Ghostbusters (as does the car-kit 
BTW,
definitely high geek-appeal), I'm sure any science class could double 
its
attendance just because people wanted to get their hands on the 
Bombsquad

carrying case...


How do we get to the pictures to see them?  Are they posted anywhere?
--Tim

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

Re: lets be nice

[Tim Newsom]

On Mon, 19 Feb 2007 21:35, ryan lerch wrote:

hi all,

just a friendly reminder that we are getting a lot of people
subscribing to and posting to this community list that may not know
all the mailing list etiquette that you do.

So please be nice to these new-comers, and be patient with them;

* if a topic is raised that has been discussed and resolved before -
point them to the mailing list archives or where they can read about
the answer.

Even better, find a place to summarise and document the discussion on
the wiki - a formatted wiki page is 100 times easier to read than
digging through months of mailing list archives... :P

* if they ask, what is in your eyes a "stupid question" remember that
at one stage you knew little or nothing about the openmoko project:
they are just interested in getting an opensource mobile device (just
like the rest of us..  :P )

* i have also noticed that many newcomers obviously have not been
members of online communities or online development communities
before; if you come across one of these people, be nice and show them
the ropes.



Is it possible to have the 'welcome' email point them to those locations 
automatically?  Then they could have the information right from the 
start.. Plus maybe some general guidelines for posting... Might be good 
also.


Just a thought.
--Tim

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

Other uses for the gsm/gprs hardware....

[Tim Newsom]

While the phone is not on a call, can we use the gsm audio codec or 
other hardware/software to do useful work?  For instance, decoding of 
some audio file or something like that.


I know we don't have access to the bare metal of the chip, but its 
probably at least an arm processor with some dsp or something right? I 
would think it could be useful in some way other than just phone 
calls/data transfer.

--Tim

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

Re: Encrypting voice comunications..

[Tim Newsom]

So, though possibly inefficient, we could not some how take the analog 
audio stream, do some predictable and reversible encoding/encrypting 
then convert into sounds again.. Like doing base64 encoding for binary 
data..


In that way we are still sending audio information and letting it get 
encoded by the gsm module.


Having access to send audio over gsm could be useful in another way.. 
Say call your phone and when it answers have it read its location to you 
via text to speech or something.  We must have the ability to do 
something like that, or how would asterix (sp?) work on the phone?


On Fri, 2 Feb 2007 9:29, Mikko J Rauhala wrote:

On pe, 2007-02-02 at 09:06 -0800, Tim Newsom wrote:

 If we have access to the mic and speakers while a call is in process,
 and we have the ability to record conversations etc...  Where does the
 processor sit in that chain?  Can we consume the voice, encrypt it and
 feed an encrypted datastream back out to the gsm module which would
 transmit it and another neo1973 user could receive the stream, process
 through decryption and play out?


No. The GSM processor does its own audio de- and encoding, and its
connection to the audio i/o is analog, as reported by LaF0rge on irc a
while back (any misunderstanding is probably mine if present, though).
We can get at the audio via the a/d converters, but not do anything
really fancy directly.

Thus, I refer you to my last mail; make a GSM data call (phone-to-phone
if possible, if not, both dial out and arrange the call via some
server), transmit encrypted Speex stream. There would still be a bit of
latency, but you would get reserved bandwidth at least.

This of course costs extra. Probably one of the principal reasons why
GSM chips don't like you sending your own digital data over voice
calls. :]

--
Mikko J Rauhala <[EMAIL PROTECTED]>
University of Helsinki


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

--Tim

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