Re: Better keyboard?

[Jim Morris]

Marco Trevisan (Treviño) wrote:
> 
> In Ubuntu I had to install libfakekey-dev to compile.
> However I've also ported and applied the thseiler's popup patch to this 
> version (I could attach it somewhere if you want, but it's still 
> incomplete since it's show only the clicked letter on a small pop-up 
> window).
> I'd like also to redesign it a little, to gain a bit more space while my 
> FR is coming... :P
> 

I got it to work under Ubuntu although it causes all my open windows to get 
squished.

What are you using to build it? the toolchain or mokomakefile? Because when I 
try to build it using 
the toolchain there are a bunch of missing x libraries, which are not in the 
toolchain.

Thanks
Jim

-- 
Jim Morris, http://blog.wolfman.com

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

Re: MokSec - The Security Framework

[Kalle Happonen]

Hello,
I've only had my freerunner for a week or so, so I'm not too into the 
security aspects yet. One thing I did notice was of course passwordless 
root login. Now over usb this can be acceptable, but if this is possible 
over wifi (I haven't actually tested), it needs the firewall / make it 
listen only to the usb.

In addition to that, a separate encrypted partition for /root (or /home 
if the account will changed to a non-privileged user) could be nice, but 
maybe too heavy and battery draining?

In addition to that, I'd say all linux security administration best 
practices should be at least considered, including automatic security 
updates.

After the basic security is in good shape, one could move on to fun 
things like phone lock/unlock/shutdown with an sms, personal data 
backups / remote removal... the possibilities! :)

Cheers,
Kalle

Yorick Moko wrote:
> This mail was posted on the devel list
> (http://lists.openmoko.org/pipermail/openmoko-devel/2008-July/003594.html).
> Thought it would interest a lot of people who are not subscribed to
> that list:
>
>
> Hi Guys,
>
> a few months ago we have planned to improve the security of our beloved
> Neo, after we have read about desires of the community regarding to the
> security issue.
>
> And here we are. Today I will present you our project MokSec.
>
> What is MokSec?
> ===
>
> MokSec is framework which target is to improve the security of the mobile
> devices which are based on OpenMoko (and other frameworks which are running on
> Neos)
>
> What is our main focus at the moment?
> =
>
> The main focus is the encryption over GSM. This is very complicated issue and
> for this we searching developer which are willing to work with us on this
> interesting project.
>
> What are the other components?
> ==
>
> At the moment we only working on a phone firewall, which will be
> blocking/accepting incoming calls. Later one we will add other projects or
> developer will be able to add their projects.
>
> Were you can find more informations?
> 
>
> http://moksec.networld.to : The main page
> http://moko.networld.to   : The git repositories
> http://networld.to/mailman/listinfo/moksec-public : The mailinglist
>
> We hope that a lot of people will work with us on the security issue.
>
> Happy programming
>
> Alex Oberhauser
>
> ___
> 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: [qtopia on freerunner] - What is the right place to discuss Qtopia on Openmoko?

[Lorn Potter]

Thomas B. wrote:
> Hi!
> 
> On Sat, Jul 12, 2008 at 06:48:41AM +1000, Lorn Potter wrote:
>> Kevin Dean wrote:
>>> Plugging a Freerunner up via USB to a Debian system while running this
>>> image doesn't appear to charge. Is this a purely visual thing, or is
>>> Qtopia unable to charge a Freerunner? I'm assuming that since the
>>> other software can, this is a Qtopia thing?
>> actually, it is an apm thing. apm battery status on the freerunner does
>> not work correctly.
>> I guess I need to back port a workaround from the 4.4. branch for at
>> least showing when it is charging.
> 
> I have a slightly different problem: The battery does get charged, but
> the screen doesn't dim or get switched off, although I told it to do
> that in the settings. That's a bit annoying, and it's probably not very
> healthy for the display, too.
> 
> Is this also an apm problem, and can it be worked around?

I haven't seen this problem. Although, because apm is broken, qtopia 
cannot tell if the power is plugged in or on battery.


> 
>> If anyone knows how to get a real battery status on the freerunner I can 
>> fix this up.
> 
> I only know of 
> /sys/devices/platform/bq27000-battery.0/power_supply/bat/status.
> Maybe that helps?

not on my devices:

[EMAIL PROTECTED]:~# cat 
/sys/devices/platform/bq27000-battery.0/power_supply/bat/status
cat: read error: Timer expired


-- 
Lorn 'ljp' Potter
Software Engineer, Systems Group, Trolltech, a Nokia company

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

Re: [qtopia on freerunner] - What is the right place to discuss Qtopia on Openmoko?

[Lorn Potter]

Thomas B. wrote:
> On Sun, Jul 13, 2008 at 10:16:01PM +0200, Thomas B. wrote:
>> I have a slightly different problem: The battery does get charged, but
>> the screen doesn't dim or get switched off, although I told it to do
>> that in the settings. That's a bit annoying, and it's probably not very
>> healthy for the display, too.
>>
>> Is this also an apm problem, and can it be worked around?
> 
> I just noticed that there is already a newer Qtopia snapshot available
> for download than the one I have installed (mine is from Friday). I'd
> love to try that one out, maybe it solves my problem quoted above.
> 
> Now my next question is: Is there a way to upgrade Qtopia to the new
> snapshot without losing my data (e.g. contacts and messages)? Backing up
> the data and writing it back after the upgrade would be fine, but I
> don't know where the data is stored.

it is stored in the databases:
~/Applications/Qtopia/qtopia_db.sqlite
~/Applications/qtmail/qtopia_db.sqlite

Settings are stored in ~/Settings

-- 
Lorn 'ljp' Potter
Software Engineer, Systems Group, Trolltech, a Nokia company

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

Re: MokSec - The Security Framework

[thomasg]

On 7/14/08, Kalle Happonen <[EMAIL PROTECTED]> wrote:
>
> Hello,
> I've only had my freerunner for a week or so, so I'm not too into the
> security aspects yet. One thing I did notice was of course passwordless
> root login. Now over usb this can be acceptable, but if this is possible
> over wifi (I haven't actually tested), it needs the firewall / make it
> listen only to the usb.


There's no need for a firewall at all (in fact it's probably the worst
idea).
Just set a root password (you're probably a win user, the command is simply
"passwd") and it'll be fine.


In addition to that, a separate encrypted partition for /root (or /home
> if the account will changed to a non-privileged user) could be nice, but
> maybe too heavy and battery draining?


Imho it's not needed to encrypt the whole system.
Would be the better choice to have some crypto-containers for the files that
really need to be secured (phonebook, messages, important documents). We had
some discussion in IRC a while ago and my idea would be to have that
containers and a daemon in background who handles encryption/decryption,
asks for passwords if needed and makes sure that applications who want
access to a encrypted container get it (e.g. dialer wants to look up a
number in the phonebook).
This way the containers can stay decrypted while the phone is on and access
is granted dynamically (as needed).
Yeah, it's a little much effort, but there is no security without it.
If you'd encrypt the whole rootfs you'd have it decrypted the whole time the
phone is on (otherwise nothing would work), what means, the security is
gone.
Well, that's only a part of a possible security framework, but this are only
some thoughts.


> In addition to that, I'd say all linux security administration best
> practices should be at least considered, including automatic security
> updates.


It's a standard linux system with a lightweight, but still standard, packet
management, so that's how it already is handeled (well, without the
automatic, but I don't like automatic updating anyway).

After the basic security is in good shape, one could move on to fun
> things like phone lock/unlock/shutdown with an sms, personal data
> backups / remote removal... the possibilities! :)


Possibly to be implemented in a (modular) "security-daemon", as mentioned
before.

Cheers,
> Kalle
>
> Yorick Moko wrote:
> > This mail was posted on the devel list
> > (
> http://lists.openmoko.org/pipermail/openmoko-devel/2008-July/003594.html).
> > Thought it would interest a lot of people who are not subscribed to
> > that list:
> >
> >
> > Hi Guys,
> >
> > a few months ago we have planned to improve the security of our beloved
> > Neo, after we have read about desires of the community regarding to the
> > security issue.
> >
> > And here we are. Today I will present you our project MokSec.
> >
> > What is MokSec?
> > ===
> >
> > MokSec is framework which target is to improve the security of the mobile
> > devices which are based on OpenMoko (and other frameworks which are
> running on
> > Neos)
> >
> > What is our main focus at the moment?
> > =
> >
> > The main focus is the encryption over GSM. This is very complicated issue
> and
> > for this we searching developer which are willing to work with us on this
> > interesting project.
> >
> > What are the other components?
> > ==
> >
> > At the moment we only working on a phone firewall, which will be
> > blocking/accepting incoming calls. Later one we will add other projects
> or
> > developer will be able to add their projects.
> >
> > Were you can find more informations?
> > 
> >
> > http://moksec.networld.to : The main page
> > http://moko.networld.to   : The git repositories
> > http://networld.to/mailman/listinfo/moksec-public : The mailinglist
> >
> > We hope that a lot of people will work with us on the security issue.
> >
> > Happy programming
> >
> > Alex Oberhauser
> >
> > ___
> > 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: GPS

[Timo Jyrinki]

2008/7/13 BlueStar88 <[EMAIL PROTECTED]>:
> Feeding assist data to compensate bad hardware based reception is no real
> solution, since there are some FRs, which seem not to have any problems to
> get a fast fix at all.

My personal current belief is that those FRs are generally no better
than eg. yours or mine. It's simply a matter of software used and
especially the place used (some countries have also better GPS
coverage than others), plus whether one really has a table or so where
the device can easily be mounted firmly. If you hold it in your hand,
still otherwise, it might not be steady enough to get the fix (or does
someone know otherwise, eg. what kind of movement might corrupt the
received bits?). Or are there some people who get a fix while moving
Neo around?

Since the software has zero GPS data saving features etc., it's no
wonder people easily think "it's broken". Especially, like in my case,
if people don't have previous GPS usage experience or don't know how
hard it's actually to "start from scratch" (scanning the whole sky)
without any eg. estimate on current whereabouts or any other help. And
also it doesn't help that if eg. people use AGPS UI which clears any
received data every time it's started. One reason I believe it's not
bad hardware reception is that when the fix is gotten, the fix stays
better than on many "real" GPS hardware.

Still, I've yet to experiment more on what would be best ways to get
the initial fix. Even if feeded initial data, it seems relatively
impossible to get the fix around my place. I'm not sure what could be
improved still for the first fix, since after the fix is gotten it
stays so well one would imagine the fix should also be possible to get
in an (relatively) open area with a clear sky.

-Timo

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

Re: GPS

[thomasg]

On 7/14/08, Timo Jyrinki <[EMAIL PROTECTED]> wrote:
>
> 2008/7/13 BlueStar88 <[EMAIL PROTECTED]>:
> > Feeding assist data to compensate bad hardware based reception is no real
> > solution, since there are some FRs, which seem not to have any problems
> to
> > get a fast fix at all.
>
> My personal current belief is that those FRs are generally no better
> than eg. yours or mine. It's simply a matter of software used and
> especially the place used (some countries have also better GPS
> coverage than others), plus whether one really has a table or so where
> the device can easily be mounted firmly. If you hold it in your hand,
> still otherwise, it might not be steady enough to get the fix (or does
> someone know otherwise, eg. what kind of movement might corrupt the
> received bits?). Or are there some people who get a fix while moving
> Neo around?
>
> Since the software has zero GPS data saving features etc., it's no
> wonder people easily think "it's broken". Especially, like in my case,
> if people don't have previous GPS usage experience or don't know how
> hard it's actually to "start from scratch" (scanning the whole sky)
> without any eg. estimate on current whereabouts or any other help. And
> also it doesn't help that if eg. people use AGPS UI which clears any
> received data every time it's started. One reason I believe it's not
> bad hardware reception is that when the fix is gotten, the fix stays
> better than on many "real" GPS hardware.
>
> Still, I've yet to experiment more on what would be best ways to get
> the initial fix. Even if feeded initial data, it seems relatively
> impossible to get the fix around my place. I'm not sure what could be
> improved still for the first fix, since after the fix is gotten it
> stays so well one would imagine the fix should also be possible to get
> in an (relatively) open area with a clear sky.
>
> -Timo
>
> ___
> Openmoko community mailing list
> community@lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community
>

This all are no arguments.
With my TomTom device I can do a full reset so that no GPS data is available
at all (also no time and so on) and still get a fix in < 3 minutes at 100
km/h.
Well, I know the freerunner is no specialized gps navigation device, but the
fact that the signals are so weak that it's barely possible to get a fix
under optimal condition (clear view to the sky, antenna on top, without
moving 1 mm) shows, that this is no simple software problem and has to be
fixed.
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Homezone Icon for O2 in Germany

[Joachim Breitner]

Hi,

Am Sonntag, den 13.07.2008, 20:05 +0200 schrieb smurfy - phil:
> Hey, i'm really new to the bitbaker stuff :) i also noticed, that after 
> some new build of the app it wants to download gtk+ and fails.
> 
> i really don't know why this happens.
> 
> if you do a removal of the gtk+-fastscaling and then a install of gtk+ 
> it works, also, gtk+ installs a new version of gtk+fastscaling.
> 
> so i realy don't know why it is doing that :)
> 
> maybe because on 12.jul, there was an update of the gtk+* packages.

Indeed, Forcibly installing the gtk+-package works, and, as I’m back in
my homezone now, I can confirm that it works nicely so far.

Obviously, you use O2 as well. Some other Freephone and O2 user had
observed regular wake-ups from the sleep mode, which obviously kills the
battery time, and we thought that the O2 cell broadcasts might cause
these wakeups. I haven’t had my phone long enough myself to really test
this.

Do you observe the same problem? And (now to anyone): Is there a way to
disable wake-up on Cell Broadcasts, if that turns out to be the problem?

Thanks,
Joachim

-- 
Joachim Breitner
  e-Mail: [EMAIL PROTECTED]
  Homepage: http://www.joachim-breitner.de
  ICQ#: 74513189
  Jabber-ID: [EMAIL PROTECTED]


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: GPS

[Kalle Kärkkäinen]

thomasg kirjoitti:
> This all are no arguments.
> With my TomTom device I can do a full reset so that no GPS data is 
> available at all (also no time and so on) and still get a fix in < 3 
> minutes at 100 km/h.

In my past life I developed a fleet management device that had GPS and 
GSM in it, able to send the fix data to server in intervals. we even 
implemented some location alerts (around the vicinity of, or near 
customer..).

Based on that experience, we used on of falcoms devices for it, it most 
probably did not have much of a cache for gps data (black box, tough to 
tell), but it needed a strong antenna for gps. For a GSM antenna you 
could use a hairpin, anything that had 10-15 cm of length was totally 
enough for good quality gsm connection. GPS required much more, in our 
case we supplied all the devices with external antennas.

My knowledge is based solely on this work experience, I'm no radio-geek 
so I cant really tell much about antennas and signal catching. What kind 
of GPS-antenna is there in FR? Embedded for sure, but could that be the 
problem?

I guess your TomTom comes with an external windshield antenna?

--
Kalle.

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

Re: Homezone Icon for O2 in Germany

[smurfy - phil]

Ok,

after some test, i guess i missed something, or my o2 buggs,
i receive no new cellbroadcast after leaving my homezone.

currently i only receive cellbroadcasts after reregiserting to the network.

so there must be another variable to use to detect the homezone. maybe 
the locationarea code.

Phil

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

Re: MokSec - The Security Framework

[arne anka]

> Personally, I'd be more interested in an encrypted filesystem so that I

what use is encryption if the user always is root and no password is  
required?

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

Re: Homezone Icon for O2 in Germany

[smurfy - phil]

>Do you observe the same problem? And (now to anyone): Is there a way to
>disable wake-up on Cell Broadcasts, if that turns out to be the problem?

i have the problem that i don't receive more than one cell broadcast after 
registering with the network.

homezoned sets cellboadcasts to ON, i don't know if you disable the deamon and 
send a manual cell broadcast off command (at command) if you stell get wakeups.

Phil


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

Re: GPS

[Kai Römer]

again: its not a software issue. This chip should work out of the box.
39 s to fix with good antenna is possible on my dev board, without any
agps or anything.

2008/7/14 Timo Jyrinki <[EMAIL PROTECTED]>:
> 2008/7/13 BlueStar88 <[EMAIL PROTECTED]>:
>> Feeding assist data to compensate bad hardware based reception is no real
>> solution, since there are some FRs, which seem not to have any problems to
>> get a fast fix at all.
>
> My personal current belief is that those FRs are generally no better
> than eg. yours or mine. It's simply a matter of software used and
> especially the place used (some countries have also better GPS
> coverage than others), plus whether one really has a table or so where
> the device can easily be mounted firmly. If you hold it in your hand,
> still otherwise, it might not be steady enough to get the fix (or does
> someone know otherwise, eg. what kind of movement might corrupt the
> received bits?). Or are there some people who get a fix while moving
> Neo around?

A good GPS reciever like some properly build SIRF3 systems and others
get a fix within 1 minute under "good conditions" (clear view to sky)
cold boot no matter how you hold your device. (proved here several
times) The openmoko does not get a fix in reliable time (<3 minutes).
If you plug in a external antenna and keep it away from the device it
works like with a good SIFR3 chip. So lets face it: IT IS NOT A
SOFTWARE ISSUE!

>
> Since the software has zero GPS data saving features etc., it's no
> wonder people easily think "it's broken". Especially, like in my case,
> if people don't have previous GPS usage experience or don't know how
> hard it's actually to "start from scratch" (scanning the whole sky)
> without any eg. estimate on current whereabouts or any other help. And
> also it doesn't help that if eg. people use AGPS UI which clears any
> received data every time it's started. One reason I believe it's not
> bad hardware reception is that when the fix is gotten, the fix stays
> better than on many "real" GPS hardware.

As you can see if you search for the thread "GPS External antenna
detect issue" it is a hardware issue.
And there are a lot of people on this list having experienced with gps
systems like me.
Reading the manual of the chip you can see, that it should work out of
the box without "software" support.
39 s is what this chip is able to. But of course not if the antenna
system is broken.

Some people expect it to be a combination of:
* broken antenna switch
* bad antenna
* antenna too near to device

>
> Still, I've yet to experiment more on what would be best ways to get
> the initial fix. Even if feeded initial data, it seems relatively
> impossible to get the fix around my place. I'm not sure what could be
> improved still for the first fix, since after the fix is gotten it
> stays so well one would imagine the fix should also be possible to get
> in an (relatively) open area with a clear sky.
>

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

Re: Jalimo fails to install on freerunner gta02

[Robert Schuster]

Hi,

Jim Morris schrieb:
> Robert Schuster wrote:
>> Hi,
>> yes this is a know issue with the packages in our repo. Sorry, I had no
>> time to fix this yet.
>>
>> Btw: cacao + classpath should be in the official repos as well. So there
>> is no need to add the Jalimo repos any more.
>>
> 
> Thanks, also in the docs on the site it says to do ipkg install swt-gtk 
> however this is not needed 
> as it seems to be installed with the opkg install cacao classpath
Will fix it.

> Also do you know if this release has any hooks into the phone API or any 
> other H/W on the 
> freerunner? (Dbus would be cool).
dbus-java is in OpenEmbedded. I am not sure if its being built and part
of the official repos tough. Try installing libdbus-java, javadoc and
general usage can be found here: http://dbus.freedesktop.org/doc/dbus-java/

Regards
Robert



signature.asc
Description: OpenPGP digital signature
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: [OpenMoko] qemu win32 emulator

[Robert Schuster]

Hi,
what you want is a binary of QEMU + OpenMoko's patches for it. If the
links do not work try to get in contact with the people who distributed
them first.

AFIU the OpenMoko project is mostly about doing things from source so it
should be possible to compile QEMU + patches under Windows and/or
cygwin, too.

Regards
Robert

Yocto schrieb:
> Hi,
> 
> Where can I find an openmoko win32 emulator ?
> 
> The links to the pre-build binaries of 
> openmoko-emulator-win32-bin-20070625.zip
> or its mirror are broken.
> 
> 
>>From the wiki at wiki.openmoko.org/wiki/OpenMoko_under_QEMU
> 
> mdk.linux.org.tw/~jserv/openmoko/openmoko-emulator-win32-bin-20070625.zip
> 
> snakesoftruth.com/openmoko-emulator-win32-bin-20070625.zip
> 
> 
> Thanks.
> // Yocto
> 
> ___
> Openmoko community mailing list
> community@lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community
> 




signature.asc
Description: OpenPGP digital signature
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Homezone Icon for O2 in Germany

[arne anka]

> Obviously, you use O2 as well. Some other Freephone and O2 user had
> observed regular wake-ups from the sleep mode, which obviously kills the
> battery time, and we thought that the O2 cell broadcasts might cause
> these wakeups. I haven’t had my phone long enough myself to really test
> this.

experienced that (no o2 user!) with power management set to "dim first,  
then lock". after switching to "dim only, don't lock" i didn't see it  
anymore -- but the fr still locks ...

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

Claws Mail

[Michael Kluge]

Hi all,

did anyone succeed in building this package? I only got libtinymail & 
tmut compiled & packed up to now.


Michael

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

Re: Claws Mail

[arne anka]

> did anyone succeed in building this package? I only got libtinymail &
> tmut compiled & packed up to now.

yupp. got it built and running.
will load it up to ginguppin.de tonight (note to self: learn how to create  
a feed)

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

Re: Claws Mail

[Joachim Steiger]

arne anka wrote:
>> did anyone succeed in building this package? I only got libtinymail &
>> tmut compiled & packed up to now.
> 
> yupp. got it built and running.
> will load it up to ginguppin.de tonight (note to self: learn how to create  
> a feed)
> 
> ___
> Openmoko community mailing list
> community@lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community

take a look at http://wiki.openmoko.org/wiki/CommunityRepository

by adding the ipkg to the download area of a project on
projects.openmoko.org it automatically gets into a 'to be reviewed'
files. then i want to see some testers saying 'yap' on the
community-repository mailinglist and we'll add it to the repository.


kind regards

ps: we're still needing more testers for the CommunityRepository project ;)

-- 

Joachim Steiger
Openmoko Central Services

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

Re: [OpenMoko] qemu win32 emulator

[Yocto]

Hi,

I did svn checkout the qemu-neo1973 and was following manual setup on the 
wiki.
But I bumped into the SDL requirement, etc...

Thanks to Yorick Moko who provided a link to his pre-built binaries.
I was able to get a quick first look & feel of the openmoko projet.

Even if that build was over a year old... I saw the potential...
Now, I can invest more of my spare time on this projet.

Thanks.
// Yocto

- Original Message - 
From: "Robert Schuster" <[EMAIL PROTECTED]>
To: "List for Openmoko community discussion" 
Sent: Monday, July 14, 2008 5:15 AM
Subject: Re: [OpenMoko] qemu win32 emulator


> ___
> 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: GPS issue

[Pawel Kowalak]

On Jul 13, 2008, at 11:32 AM, jonathan spooner wrote:
> Also there is a fair bit of drift on my position.  Using the plot
> feature in agps it looks like I'm walking all over my garden while the
> gta02 is sat on the table at times.

As far as I know, that drift is quite normal. If you leave GPS  
receiver in one place, there always will be some drift. It depends on  
chipset used in GPS. For example SiRF III has greater drift than  
older, less sensitive chipsets.

More important is precision while moving and the same SiRF III based  
receivers are much better than older receivers. That drift doesn't  
occur when moving. Also more important is keeping signal, and again,  
SiRF III rarely loose signal, even in bad conditions.

I don't know what chipset is used in FR, but I wouldn't worry about  
drifting ;)

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

Re: GPS

[BlueStar88]

Russell Sears schrieb:

That sounds like a different problem than I have.

People have reported many different failure modes:

  - Everything "works".  The phone gets a reliable fix in ~5-15 minutes 
if you baby it enough.  (This might be improved w/ better drivers...)


The GPS-module talks NMEA to the serial. I'm no GPS-expert, but where 
exactly should a 'driver' step in, to assist in basic technical procedures?


  - The software is somehow messed up, and there are never any fixes. 
(People report GPS breakage after installing some combination of the GPS 
packages...)  Reflashing the phone does not seem to help(!)


Ignore the software, just look at the NMEA output!

If you get a communication to the module established, all depends on the 
facts coming from the NMEA output. There should be no 
'misunderstandings' from any software involved.


This poor (?) signal is just not enough, to get any fix:

https://docs.openmoko.org/trac/attachment/ticket/1542/reception.jpg

  - Actual antenna troubles.  (See message "GPS issue related to GPS 
antenna selector ?")


Yepp, I assume this as the right (and only) direction it goes.


TangoGPS problems:

  - TangoGPS says "no gps found".  Run "opkg install gpsd".

  - The GPS device usually works, but sometimes tangoGPS sees zero 
satellites after > 5 minutes.  If you to power down the GPS device, then 
power it back up, it starts seeing satellites.


GPS UI 0.20 is used by me to do the diagnostics. Is there a cause not to 
trust it, even by looking at the pure NMEA output of it?



--

BlueStar88

PGPID: 0x36150C86
PGPFP: E9AE 667C 4A2E 3F46 9B69 9BB2 FC63 8933 3615 0C86



signature.asc
Description: OpenPGP digital signature
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Hampshire group buy

[Hugo Mills]

   All - 

   It seems that the 900MHz version of the phone won't be available
from the OM shop for at least a couple of weeks (see [1]).

   However, Pulster are now selling 10 packs for EUR 2990, including
taxes and shipping. This works out at about UKP 240 a phone --
probably a little more expensive than getting from the USA, *but* you
get the full 2-year warranty, and they're available right now.

   Also, I've only got 7 people (bcc'd) who've said they're interested
in the Hampshire group purchase. Unless we get 10 people, I can't do
anything, so this is a call for further people to sign up.

   Finally, I'm not actually buying mine in this transaction, as it's
coming through an alternative route (for various complicated reasons).
Therefore if anyone wants to take up the effort of organising this
group purchase, please let me know.

   Hugo.

[1] http://lists.openmoko.org/pipermail/community/2008-July/020981.html

-- 
=== Hugo Mills: [EMAIL PROTECTED] carfax.org.uk | darksatanic.net | lug.org.uk 
===
  PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
   --- Comic Sans goes into a bar,  and the barman says, "We don't ---   
 serve your type here."  


signature.asc
Description: Digital signature
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Hampshire group buy

[Joseph Reeves]

We have a number of FreeRunners in Oxford ready to be dispatched as
either group buys or individual purchases [1].  Unfortunately we don't
have a payment system arranged yet, but that should be coming in the
near future.

Initial pricing is £200 + VAT + Postage. The FreeRunner neoprene pouch
and headset are included for free.

Stocks are currently limited as many of our phones have either been
earmarked for project work, or have been pre-ordered.

In the near future we will be securing more stock and specialising our
sales to research groups, LUGs, and into developing custom solutions
based on the Openmoko platform.

Please email me; joseph dot reeves at thehumanjourney dot net for
further information.

Thanks,

Joseph

Oxford Archaeology
http://thehumanjourney.net

[1] http://blogs.thehumanjourney.net/finds/entry/20080710




2008/7/14 Hugo Mills <[EMAIL PROTECTED]>:
>   All -
>
>   It seems that the 900MHz version of the phone won't be available
> from the OM shop for at least a couple of weeks (see [1]).
>
>   However, Pulster are now selling 10 packs for EUR 2990, including
> taxes and shipping. This works out at about UKP 240 a phone --
> probably a little more expensive than getting from the USA, *but* you
> get the full 2-year warranty, and they're available right now.
>
>   Also, I've only got 7 people (bcc'd) who've said they're interested
> in the Hampshire group purchase. Unless we get 10 people, I can't do
> anything, so this is a call for further people to sign up.
>
>   Finally, I'm not actually buying mine in this transaction, as it's
> coming through an alternative route (for various complicated reasons).
> Therefore if anyone wants to take up the effort of organising this
> group purchase, please let me know.
>
>   Hugo.
>
> [1] http://lists.openmoko.org/pipermail/community/2008-July/020981.html
>
> --
> === Hugo Mills: [EMAIL PROTECTED] carfax.org.uk | darksatanic.net | 
> lug.org.uk ===
>  PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
>   --- Comic Sans goes into a bar,  and the barman says, "We don't ---
> serve your type here."
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFIezhVIKyzvlFcI40RAovbAJwPzqYM6/89sOQx6QzHevyBGUy0LgCgn2/O
> GXubiamGxl5Ojr28OJN+qB8=
> =xRZY
> -END PGP SIGNATURE-
>
> ___
> 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: Import Contacts

[Andreas Dalsgaard]

2008/7/12 Al Johnson <[EMAIL PROTECTED]>:
> On Friday 11 July 2008, Kalle Happonen wrote:
>> Hi,
>>
>> Brian C wrote:
>> > Brian C wrote:
>> > [a long error message because he didn't run the script from the OM
>> > terminal]
>> >
>> > Ok, so the script runs now that I realize it must be run from the OM
>> > terminal.
>
> It might work from an ssh session if you run:
>dbus-launch scriptname
> I haven't tried this though - just guessing based on similar behaviour from
> gconftool-2
>
>> > However, it appears to have entered all "null" contacts and
>> > so far none of them appear to have any actual contact info in them

If you do not want to delete all the "null" contacts by hand I've made
a script(attached as remove_all_contacts.py) based on Wurps script
which removes all contacts in your addressbook. It should be pretty
easy to modify so that it only deletes "null" contacts.

>>
>> I ran into the same problem, but I did get them in now with the script.
>> I had two issues actually. The easiest to try
>>  is to remove the empty lines between the entries in the vCard file, and
>> have them all in a long jumble. That solved my last problem.
>
> Blank line removal should be a one-liner - if only I were more familiar with
> python ;-)

Take a quick look at the attached import_contacts.py script, it is
based on Al Johnson modification to Wurps script.

>
>> I did have another problem when I played around with the contacts in
>> Evolution on the desktop. I started by exporting the contacts as vCard
>> from Wammu. Evolution refused to read those  v2.1 vCards. I then
>> exported it as ldif from wammu, and had to make a small change in the
>> entries so that evolution read them correctly (adding a cn or smth).
>> AFAIK the openmoko contacts is also based on evolution so there might be
>> similar problems.
>>
>> When I tried to import Wammu vCards,  they showed up as null entries on
>> openmoko. When I exported the contacts as vCard (3.0) from evolution,
>> and removed the empty lines in the vCard file, I could import them to
>> openmoko with the script. I'm not sure if the new vCard format helped any.
>
> Interesting...I remember having similar problems with OpenXchange a couple of
> years ago. It assumed v3 and didn't check the version in the vCard itself.
> You had to pick which interface to use depending on the vCard version. i
> wonder if Evolution Data Server is doing something similar?
>
> ___
> Openmoko community mailing list
> community@lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community
>
#!/usr/bin/python   

from __future__ import with_statement   

import dbus 
import sys, os  
import tempfile 
import re   

bus_name = 'org.gnome.evolution.dataserver.AddressBook' 
obj_name = "/org/gnome/evolution/dataserver/addressbook/file_3a__2f__2f__2f_home_2f_root_2f__2e_evolution_2f_addressbook_2f_local_2f_system"

addressBook = None  
def getAddressBook():   
  global addressBook
  if addressBook is None:   
sb = dbus.SessionBus()  
obj = sb.get_object(bus_name, obj_name) 
addressBook = dbus.Interface(obj, 'org.gnome.evolution.dataserver.addressbook.Book')
  return addressBook

names = os.listdir('.') 
for name in names:  
  print name
  vcard = ""
  f=open(name,'r')  
  for line in f:
   if line != "\r\n":
 vcard = vcard + line   

GPS

[Ken Young]

thomasg wrote:

> This all are no arguments.
> With my TomTom device I can do a full reset so that no GPS data is 
> available
> at all (also no time and so on) and still get a fix in < 3 minutes at 
> 100 km/h.
> Well, I know the freerunner is no specialized gps navigation device, but 
> the
> fact that the signals are so weak that it's barely possible to get a fix
> under optimal condition (clear view to the sky, antenna on top, without
> moving 1 mm) shows, that this is no simple software problem and has to 
> be fixed.

The GPS performance of my Freerunner is also much worse than
the GPS performance of my neo1973.   I've done side-by-side tests of the
two units many times.   My neo1973 gets a good fix in 2 to 3 minutes
after a completely cold start; it's very reliable.   My Freerunner 
initially was getting a fix after 7 or 8 minutes.   For the last few
days it has not been able to get a fix at all.

Ken Young


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

RE: MokSec - The Security Framework

[Crane, Matthew]

How would being root help somebody decrypt a filesystem?  Accessing an
encrypted filesystem should depend only on having the correct key.


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of arne anka
Sent: Monday, July 14, 2008 4:58 AM
To: List for Openmoko community discussion
Subject: Re: MokSec - The Security Framework


> Personally, I'd be more interested in an encrypted filesystem so that
I

what use is encryption if the user always is root and no password is  
required?

___
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: Import Contacts

[Kalle Happonen]

Andreas Dalsgaard wrote:
> 2008/7/12 Al Johnson <[EMAIL PROTECTED]>:
>   
>> On Friday 11 July 2008, Kalle Happonen wrote:
>> 
>>> Hi,
>>>
>>> Brian C wrote:
>>>   
 Brian C wrote:
 [a long error message because he didn't run the script from the OM
 terminal]

 Ok, so the script runs now that I realize it must be run from the OM
 terminal.
 
>> It might work from an ssh session if you run:
>>dbus-launch scriptname
>> I haven't tried this though - just guessing based on similar behaviour from
>> gconftool-2
>>
>> 
 However, it appears to have entered all "null" contacts and
 so far none of them appear to have any actual contact info in them
 
>
> If you do not want to delete all the "null" contacts by hand I've made
> a script(attached as remove_all_contacts.py) based on Wurps script
> which removes all contacts in your addressbook. It should be pretty
> easy to modify so that it only deletes "null" contacts.
>
>   
>>> I ran into the same problem, but I did get them in now with the script.
>>> I had two issues actually. The easiest to try
>>>  is to remove the empty lines between the entries in the vCard file, and
>>> have them all in a long jumble. That solved my last problem.
>>>   
>> Blank line removal should be a one-liner - if only I were more familiar with
>> python ;-)
>> 
>
> Take a quick look at the attached import_contacts.py script, it is
> based on Al Johnson modification to Wurps script.
>
>   
Hah, thanks for fixing the script. I almost feel ashamed for not 
spending a few minutes to fix it up, but just did vim magic on my 
contacts files :). And thanks for the contact remover too!
>>> I did have another problem when I played around with the contacts in
>>> Evolution on the desktop. I started by exporting the contacts as vCard
>>> from Wammu. Evolution refused to read those  v2.1 vCards. I then
>>> exported it as ldif from wammu, and had to make a small change in the
>>> entries so that evolution read them correctly (adding a cn or smth).
>>> AFAIK the openmoko contacts is also based on evolution so there might be
>>> similar problems.
>>>
>>> When I tried to import Wammu vCards,  they showed up as null entries on
>>> openmoko. When I exported the contacts as vCard (3.0) from evolution,
>>> and removed the empty lines in the vCard file, I could import them to
>>> openmoko with the script. I'm not sure if the new vCard format helped any.
>>>   
>> Interesting...I remember having similar problems with OpenXchange a couple of
>> years ago. It assumed v3 and didn't check the version in the vCard itself.
>> You had to pick which interface to use depending on the vCard version. i
>> wonder if Evolution Data Server is doing something similar?
>>
>> ___
>> 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: GPS

[Al Johnson]

On Monday 14 July 2008, BlueStar88 wrote:
> Russell Sears schrieb:
> > That sounds like a different problem than I have.
> >
> > People have reported many different failure modes:
> >
> >   - Everything "works".  The phone gets a reliable fix in ~5-15 minutes
> > if you baby it enough.  (This might be improved w/ better drivers...)
>
> The GPS-module talks NMEA to the serial. I'm no GPS-expert, but where
> exactly should a 'driver' step in, to assist in basic technical procedures?

The module talks NMEA but also a ublox binary format. Among other things this 
allows time and location estimates, ephemeris and almanac data to be fed to 
the module to give it an initial state, and should reduce time to first fix. 
Likewise it can be used to request this data from the module so it can be 
saved before shutdown. 'Driver' probably isn't the right word.

> >   - The software is somehow messed up, and there are never any fixes.
> > (People report GPS breakage after installing some combination of the GPS
> > packages...)  Reflashing the phone does not seem to help(!)
>
> Ignore the software, just look at the NMEA output!
>
> If you get a communication to the module established, all depends on the
> facts coming from the NMEA output. There should be no
> 'misunderstandings' from any software involved.
>
> This poor (?) signal is just not enough, to get any fix:
>
> https://docs.openmoko.org/trac/attachment/ticket/1542/reception.jpg
>
> >   - Actual antenna troubles.  (See message "GPS issue related to GPS
> > antenna selector ?")
>
> Yepp, I assume this as the right (and only) direction it goes.
>
> > TangoGPS problems:
> >
> >   - TangoGPS says "no gps found".  Run "opkg install gpsd".
> >
> >   - The GPS device usually works, but sometimes tangoGPS sees zero
> > satellites after > 5 minutes.  If you to power down the GPS device, then
> > power it back up, it starts seeing satellites.
>
> GPS UI 0.20 is used by me to do the diagnostics. Is there a cause not to
> trust it, even by looking at the pure NMEA output of it?



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

Re: Claws Mail

[Al Johnson]

On Monday 14 July 2008, Joachim Steiger wrote:
> arne anka wrote:
> >> did anyone succeed in building this package? I only got libtinymail &
> >> tmut compiled & packed up to now.
> >
> > yupp. got it built and running.
> > will load it up to ginguppin.de tonight (note to self: learn how to
> > create a feed)
> >
> > ___
> > Openmoko community mailing list
> > community@lists.openmoko.org
> > http://lists.openmoko.org/mailman/listinfo/community
>
> take a look at http://wiki.openmoko.org/wiki/CommunityRepository
>
> by adding the ipkg to the download area of a project on
> projects.openmoko.org it automatically gets into a 'to be reviewed'
> files. then i want to see some testers saying 'yap' on the
> community-repository mailinglist and we'll add it to the repository.
>
>
> kind regards
>
> ps: we're still needing more testers for the CommunityRepository project ;)

Many of the things people are asking about are already available in OE and 
build just fine using mokomakefile's 'make build-package-packagename'. These 
shouldn't need adding to projects.openmoko.org to make it into a repository.


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

Re: GPS

[thomasg]

On Mon, Jul 14, 2008 at 10:45 AM, Kalle Kärkkäinen <
[EMAIL PROTECTED]> wrote:
>
> In my past life I developed a fleet management device that had GPS and
> GSM in it, able to send the fix data to server in intervals. we even
> implemented some location alerts (around the vicinity of, or near
> customer..).
>
> Based on that experience, we used on of falcoms devices for it, it most
> probably did not have much of a cache for gps data (black box, tough to
> tell), but it needed a strong antenna for gps. For a GSM antenna you
> could use a hairpin, anything that had 10-15 cm of length was totally
> enough for good quality gsm connection. GPS required much more, in our
> case we supplied all the devices with external antennas.
>
> My knowledge is based solely on this work experience, I'm no radio-geek
> so I cant really tell much about antennas and signal catching. What kind
> of GPS-antenna is there in FR? Embedded for sure, but could that be the
> problem?
>
> I guess your TomTom comes with an external windshield antenna?
>
> --
> Kalle.


No, it has no external antenna, only a window-mount with antenna connector
but without one connected.
That GSM works better is sure, because mobile GSM devices can receive at
-110 dBm (usually ~ -70 to -90) while GPS chips receive at up to -160 dBm
(usually between -130 and -150 at the antenna).
I think the antenna in the freerunner is not that bad, it even has a preamp.
Ublox can receive at -158 dBm (according to the datasheet), what is pretty
good (and definitely not worse than every good navigation device), and
should get at least -130 dB (good enough for a cold boot fix) _after_ the
antenna (preamplified) I guess. It even has it's own additional amp on chip.
So the problem is imho only bad build quality (QA) at least in some of the
devices (might be a defect connector by 3rd party, don't know).
Short version: antenna good (I bet it's better than the antennas in most
other smartphones with GPS), chip very good -> bug.

And btw. - SIRF Star III are damn good chips and used in many navigation
devices and bluetooth gps devices, but the antaris is almost at the same
level.

It surely is no software issue, theoretically it could be a firmware issue
of the u-blox, but I don't think it is.
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Import Contacts

[Roland Mas]

Andreas Dalsgaard, 2008-07-14 14:01:07 +0200 :

[...]

> Take a quick look at the attached import_contacts.py script, it is
> based on Al Johnson modification to Wurps script.

Please pardon my intruding into a thread, I just subscribed to the
list.  I have also worked on contacts management, mostly to allow
myself to fix non-ASCII names in a real editor with a real keyboard.

  The result is the attached script, which improves on the previous
ones in the following ways:

- you can run it through SSH, and it looks for a DBUS session;
- you can dump all contacts to a file (a series of concatenated
  vcards);
- you an reload that file (after having altered it), and it'll update
  contacts when they already exist (based on UID) or create
  new contacts otherwise.

  So, basically:

$ scp manage-contacts.py openmoko:
$ ssh openmoko python manage-contacts.py dump > contacts.txt
$ emacs/vim/nano/gedit/whatever contacts.txt
$ ssh openmoko python manage-contacts.py load < contacts.txt

  As far as I'm concerned (look, I'm a Debian integrist, I'm
*supposed* to care about these things :-), my modifications to the
initial script are subject to the WTFPL.

Roland.
-- 
Roland Mas

Plus on en fout, plus y'en a du riz.
  -- Proverbe chinois.
#!/usr/bin/python
# coding=utf-8

from __future__ import with_statement

import dbus
import sys, os
import tempfile
import re, string, time

ps = os.popen ('ps auxe | grep -m 1 DBUS_SESSION_BUS_ADDRESS')
l = ps.read ()
r = re.compile ('DBUS_SESSION_BUS_ADDRESS=(\S+)')
m = r.search (l)
a = m.expand ('\\1')
os.environ ['DBUS_SESSION_BUS_ADDRESS'] = a

bus_name = 'org.gnome.evolution.dataserver.AddressBook'
obj_name = '/org/gnome/evolution/dataserver/addressbook/file_3a__2f__2f__2f_home_2f_root_2f__2e_evolution_2f_addressbook_2f_local_2f_system'

addressBook = None
def getAddressBook ():
  global addressBook
  if addressBook is None:
sb = dbus.SessionBus ()
obj = sb.get_object (bus_name, obj_name)
addressBook = dbus.Interface (obj, 'org.gnome.evolution.dataserver.addressbook.Book')
  return addressBook

if len (sys.argv) != 2:
  print ("Expects a single argument, 'dump' or 'load'")
  print ("With 'dump', dumps all contacts as vcards to STDOUT")
  print ("With 'load', loads vcards from STDIN")
  exit (1)

def dump_contacts ():
  # Note: this is a gross hack, but I didn't manage to get getContactList to work
  strings = os.popen ('strings /home/root/.evolution/addressbook/local/system/addressbook.db | grep ^pas-id- | sort -u').readlines ()
  for id in strings:
id = id.rstrip ()
try:
  print getAddressBook ().getContact (id) + "\r"
except:
  pass

def load_contacts ():
  contacts = parse_stdin ()
  ab = getAddressBook ()
  l = contacts.keys ()
  l.sort ()
  for k in contacts.keys ():
try:
  c = ab.getContact (k)
  print "Contact already exists, modifying"
  try:
ab.modifyContact (contacts [k])
  except:
print "Got error when modifying " + c
except:
  print "New contact"
  ab.addContact (contacts [k])

def parse_stdin ():
  lines = sys.stdin.readlines ()
  contacts = {}
  cur = []
  index = 0
  for l in lines:
line = l.rstrip ()
if line == '':
  continue
if line == 'END:VCARD':
  cur.append (line)
  seen = ''
  for record in cur:
if record.startswith ('UID:'):
  seen = record [4:]
  seen = seen.rstrip ()
  if seen == '':
seen = 'new-contact-' + str(index)
index += 1
  contacts [seen] = string.join (cur, '\r\n')
  cur = []
else:
  if line.startswith ('REV:'):
cur.append ('REV: ' + time.strftime ('%Y-%m-%dT%H:%M:%SZ', time.gmtime()))
  else:
cur.append (line)
  return contacts

if sys.argv [1] == 'load':
  load_contacts ()
else:
  dump_contacts ()
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Import Contacts

[Roland Mas]

Roland Mas, 2008-07-14 15:09:34 +0200 :

> - you can dump all contacts to a file (a series of concatenated
>   vcards);

Forgot to mention: that feature uses a gross hack, I'd be happy to see
it cleaned up.  I just didn't manage to find the query syntax for the
getContactList() method.

Roland.
-- 
Roland Mas

Le weblog entièrement nu -- http://roland.entierement.nu/
Le photoblog entièrement net -- http://roland.entierement.net/

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

Re: MokSec - The Security Framework

[arne anka]

> How would being root help somebody decrypt a filesystem?  Accessing an
> encrypted filesystem should depend only on having the correct key.

well, to be really usefull the fs should be mounted transparently (hacking  
in the passphrase on every access seems utterly tedious with that tiny  
keyboard -- and would probably add to the exposure risk).
or you need to store the passphrase somewhere on the fr and access it by  
some automatic.
in both cases somebody finding or stealing your fr would be able to read  
your encrypted data.

please, correct me, if i am wrong.

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

Re: Import Contacts

[smurfy - phil]

Please update

http://wiki.openmoko.org/wiki/Import_Vcf_Contacts

with your new versions, if you need space i could place it @my domain 
(like my first version :D)

Phil


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

Re: MokSec - The Security Framework

[Kalle Happonen]

thomasg wrote:
> On 7/14/08, *Kalle Happonen* <[EMAIL PROTECTED] 
> > wrote:
>
> Hello,
> I've only had my freerunner for a week or so, so I'm not too into the
> security aspects yet. One thing I did notice was of course
> passwordless
> root login. Now over usb this can be acceptable, but if this is
> possible
> over wifi (I haven't actually tested), it needs the firewall / make it
> listen only to the usb.
>
>  
> There's no need for a firewall at all (in fact it's probably the worst 
> idea).
> Just set a root password (you're probably a win user, the command is 
> simply "passwd") and it'll be fine.
>  
What an insult! *slap* :P. No I'm not a windows user. and I can set the 
root password on my device, but defaults matter. And they matter a lot 
if openmoko will become more mass-market. A firewall migth be a bit 
heavy, I agree, every watt and cycle should try to be saved, but making 
dropbear just listen to the usb interface would be a pretty good 
compromise, if that is possible.

However, later on an easily configurable firewall would be almost 
essential imho. Connecting to the phone (any port) over the wifi should 
(almost?)never be allowed as default. Even if the point with the phone 
is that users can do what they want, it doesn't mean that the apps they 
install shouldn't be protected. And a firewall is almost the only viable 
way. There's no easy way of making all the apps listen to just one 
interface, and while host.allow/deny is more lightweight than a 
firewall, those don't allow distinguishing of interface.

>
> In addition to that, a separate encrypted partition for /root (or
> /home
> if the account will changed to a non-privileged user) could be
> nice, but
> maybe too heavy and battery draining?
>
>  
> Imho it's not needed to encrypt the whole system.
> Would be the better choice to have some crypto-containers for the 
> files that really need to be secured (phonebook, messages, important 
> documents). We had some discussion in IRC a while ago and my idea would
No, not the whole system. But well the user homedir would be basically 
what we want to protect, and if it was on it's own partition, there is 
kernel support for it already.
> be to have that containers and a daemon in background who handles 
> encryption/decryption, asks for passwords if needed and makes sure 
> that applications who want access to a encrypted container get it 
> (e.g. dialer wants to look up a number in the phonebook).
> This way the containers can stay decrypted while the phone is on and 
> access is granted dynamically (as needed).
I think completely dynamic decryption would be too cumbersone to use. If 
you mean that it would need an unlock for every received sms (to get the 
contact behind the number) and phone call, it's just unfeasible. If you 
want to protect the en/decryption key, it needs a passphrase that is 
long enough to be of any benefit. The other option is a PKI enabled SIM, 
which would be cool. Hence it should be unlocked only once, at bootup. 
The sim pin could also be saved on the encrypted partition (maybe the 
pin itself again encrypted with the passphrase, so it's not accessible 
easily at runtime) so that the user only needs to authenticate once to 
use the phone. There could be then options to forget the encryption key 
either locally or via a "magic sms".
> Yeah, it's a little much effort, but there is no security without it.
> If you'd encrypt the whole rootfs you'd have it decrypted the whole 
> time the phone is on (otherwise nothing would work), what means, the 
> security is gone.
No it doesn't. Everything NEEDS to be decrypted automagically when the 
phone is on. Otherwise it's just unusable. The whole system shouldn't be 
encrypted, that's just waste.  But having a personal area decrypted at 
startup means that only you can access it at bootup, and one can add the 
option of remotely disabling access to it. That is very much security, 
way more than phones usually have nowadays, even more than 
laptops/desktops, but not too much to make it hard/annoying to use.
> Well, that's only a part of a possible security framework, but this 
> are only some thoughts.
>  
>
> In addition to that, I'd say all linux security administration best
> practices should be at least considered, including automatic security
> updates.
>
>  
> It's a standard linux system with a lightweight, but still standard, 
> packet management, so that's how it already is handeled (well, without 
> the automatic, but I don't like automatic updating anyway).
>
The fact that it has package management doesn't mean much in itself. I 
think current linux distributions have a pretty good model. A separate 
security updates repo, which just releases security patches, and since 
these are an security update of the recommended version, they don't 
(well shouldn't) break anything, so they can even be pretty safely 
applied automat

Re: GPS

[Yorick Moko]

two small questions:
1) is there ANYBODY who has a freerunner with a "normal" functioning GPS?
2) We must presume openmoko tested the GPS before starting the mass
production. The GPS of those devices must have worked, no?


On Mon, Jul 14, 2008 at 3:05 PM, thomasg <[EMAIL PROTECTED]> wrote:
> On Mon, Jul 14, 2008 at 10:45 AM, Kalle Kärkkäinen
> <[EMAIL PROTECTED]> wrote:
>>
>> In my past life I developed a fleet management device that had GPS and
>> GSM in it, able to send the fix data to server in intervals. we even
>> implemented some location alerts (around the vicinity of, or near
>> customer..).
>>
>> Based on that experience, we used on of falcoms devices for it, it most
>> probably did not have much of a cache for gps data (black box, tough to
>> tell), but it needed a strong antenna for gps. For a GSM antenna you
>> could use a hairpin, anything that had 10-15 cm of length was totally
>> enough for good quality gsm connection. GPS required much more, in our
>> case we supplied all the devices with external antennas.
>>
>> My knowledge is based solely on this work experience, I'm no radio-geek
>> so I cant really tell much about antennas and signal catching. What kind
>> of GPS-antenna is there in FR? Embedded for sure, but could that be the
>> problem?
>>
>> I guess your TomTom comes with an external windshield antenna?
>>
>> --
>> Kalle.
>
> No, it has no external antenna, only a window-mount with antenna connector
> but without one connected.
> That GSM works better is sure, because mobile GSM devices can receive at
> -110 dBm (usually ~ -70 to -90) while GPS chips receive at up to -160 dBm
> (usually between -130 and -150 at the antenna).
> I think the antenna in the freerunner is not that bad, it even has a preamp.
> Ublox can receive at -158 dBm (according to the datasheet), what is pretty
> good (and definitely not worse than every good navigation device), and
> should get at least -130 dB (good enough for a cold boot fix) _after_ the
> antenna (preamplified) I guess. It even has it's own additional amp on chip.
> So the problem is imho only bad build quality (QA) at least in some of the
> devices (might be a defect connector by 3rd party, don't know).
> Short version: antenna good (I bet it's better than the antennas in most
> other smartphones with GPS), chip very good -> bug.
>
> And btw. - SIRF Star III are damn good chips and used in many navigation
> devices and bluetooth gps devices, but the antaris is almost at the same
> level.
>
> It surely is no software issue, theoretically it could be a firmware issue
> of the u-blox, but I don't think it is.
>
> ___
> 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: MokSec - The Security Framework

[Kalle Happonen]

arne anka wrote:
>> How would being root help somebody decrypt a filesystem?  Accessing an
>> encrypted filesystem should depend only on having the correct key.
>> 
>
> well, to be really usefull the fs should be mounted transparently (hacking  
> in the passphrase on every access seems utterly tedious with that tiny  
> keyboard -- and would probably add to the exposure risk).
depends on what you mean "on every access". If it's once per startup, I 
wouldn't think it's too much. How often do you reboot the phone?


Cheers,
Kalle

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

Re: MokSec - The Security Framework

[arne anka]

> wouldn't think it's too much. How often do you reboot the phone?

with a battery uptime of about 8h -- at least once a day, because the fr  
usually silently shuts down.
on weekends more frequently because i play around and something crashes or  
so.

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

Re: Import Contacts

[Roland Mas]

smurfy - phil, 2008-07-14 15:30:22 +0200 :

> Please update
>
> http://wiki.openmoko.org/wiki/Import_Vcf_Contacts
>
> with your new versions, if you need space i could place it @my
> domain (like my first version :D)

Space isn't a problem (I uploaded the script to [1]), but I'm
reluctant to create yet another account on yet another website.  Could
you add the link (and maybe rephrase the text on the article to remove
the thing about running from a terminal rather than SSH)?

  Thanks,

Roland.

[1] http://www.placard.fr.eu.org/~roland/tmp/manage-contacts.py
-- 
Roland Mas

  ()Campagne du ruban ASCII :
  /\Contre les mails en HTML et les vcard !

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

RE: MokSec - The Security Framework

[Crane, Matthew]

Once the device is powered, and the correct key entered, I would expect
it would remain in memory until the phone is powered off.  Parnoid types
would of course disable network access.  

Nearly all phones have a secured access mode, where you enter a pin
every time you access the phone.  That's a must for some.

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of arne anka
Sent: Monday, July 14, 2008 9:26 AM
To: List for Openmoko community discussion
Subject: Re: MokSec - The Security Framework


> How would being root help somebody decrypt a filesystem?  Accessing an
> encrypted filesystem should depend only on having the correct key.

well, to be really usefull the fs should be mounted transparently
(hacking  
in the passphrase on every access seems utterly tedious with that tiny  
keyboard -- and would probably add to the exposure risk).
or you need to store the passphrase somewhere on the fr and access it by

some automatic.
in both cases somebody finding or stealing your fr would be able to read

your encrypted data.

please, correct me, if i am wrong.

___
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: MokSec - The Security Framework

[Kalle Happonen]

arne anka wrote:
>> wouldn't think it's too much. How often do you reboot the phone?
>> 
>
> with a battery uptime of about 8h -- at least once a day, because the fr  
> usually silently shuts down.
> on weekends more frequently because i play around and something crashes or  
> so.
>   
Well, this wasn't available now, was it? :). Since these are only plans, 
and afaik the powersave functionality will be vastly improved, that 
argument is hopefully invalid when the encryption is available.

Kalle

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

Re: MokSec - The Security Framework

[Tilman Baumann]

Paul Jimenez wrote:
> Alex Oberhauser wrote:
>> Bumbl wrote:
>>   
>>> It would be more important to not run everything as root I think
>>> 
>> This will be also a main focus. When we receive the Freerunners, we will see
>> how fast we can change this bad state.
>>
>>   
> 
> Personally, I'd be more interested in an encrypted filesystem so that I 
> can worry less about snoopy people getting access to my personal data if 
> I lose my phone or it's stolen.  How many 'main focuses' are you allowed 
> ? :)

Can we use the SIM-Card to decrypt stuff?
It's after all a smart card. :)

Would be cool if we could store a crypto key on the SIM, which it will 
only release if you provide the right SIM.

-- 
Drucken Sie diese Mail bitte nur auf Recyclingpapier aus.
Please print this mail only on recycled paper.

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

Re: MokSec - The Security Framework

[Tilman Baumann]

Kalle Happonen wrote:

> However, later on an easily configurable firewall would be almost 
> essential imho. Connecting to the phone (any port) over the wifi should 
> (almost?)never be allowed as default. Even if the point with the phone 
> is that users can do what they want, it doesn't mean that the apps they 
> install shouldn't be protected. And a firewall is almost the only viable 
> way. There's no easy way of making all the apps listen to just one 
> interface, and while host.allow/deny is more lightweight than a 
> firewall, those don't allow distinguishing of interface.

SELinux comes to mind. Or at least the capabilites framework.
This way i could choose to allow a app to open sockets. (Little bit like 
java sandboxes)
As far as i know we could even have a popup asking for permission.

And to give my 2 Eurocents to the everything as root discusion.
Running user apps as root must end, better soon.
If apps need things only root can do (not much comes to my mind) we 
could use sudo wrapper or SELinux rules.

-- 
Drucken Sie diese Mail bitte nur auf Recyclingpapier aus.
Please print this mail only on recycled paper.

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

Re: MokSec - The Security Framework

[Kalle Happonen]

Tilman Baumann wrote:
> Paul Jimenez wrote:
>   
>> Alex Oberhauser wrote:
>> 
>>> Bumbl wrote:
>>>   
>>>   
 It would be more important to not run everything as root I think
 
 
>>> This will be also a main focus. When we receive the Freerunners, we will see
>>> how fast we can change this bad state.
>>>
>>>   
>>>   
>> Personally, I'd be more interested in an encrypted filesystem so that I 
>> can worry less about snoopy people getting access to my personal data if 
>> I lose my phone or it's stolen.  How many 'main focuses' are you allowed 
>> ? :)
>> 
>
> Can we use the SIM-Card to decrypt stuff?
> It's after all a smart card. :)
>
> Would be cool if we could store a crypto key on the SIM, which it will 
> only release if you provide the right SIM.
>   
I don't think that's doable with normal SIMs. But there are places where 
you can get SIM cards with built in encyption/decryption keys, and a 
certificate (PKI). This is possible at least in Finland, but not widely 
used.  If you had the PKI enabled SIM, I'd say it wouldn't only be cool, 
it would be THE way to go, as far as security and ease of use goes. :)


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

RE: MokSec - The Security Framework

[Crane, Matthew]

I would think on a phone the primary concern is protecting the user
data.  

E.g. sms, contacts, history. 

If somebody was able to malicously install software on the phone, your
pretty much already [EMAIL PROTECTED]'ed.  Not letting it call out helps, but 
it's
already defeated.  I'm assuming we're not installing a lot of new
unknowns on a secure device, and anything trying to make network
connections is evol. 

I've been picturing running an encrypted rootfs image off an SD card.
There could be multiple encrypted rootfs images, only one would be the
real one, or they all could be used for different reasons.

Once the system boots it's up to the user to unlock the keys to the
encrypted image to be used and that gets booted from the already running
kernel. 



-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Tilman
Baumann
Sent: Monday, July 14, 2008 10:38 AM
To: List for Openmoko community discussion
Subject: Re: MokSec - The Security Framework


Kalle Happonen wrote:

> However, later on an easily configurable firewall would be almost 
> essential imho. Connecting to the phone (any port) over the wifi
should 
> (almost?)never be allowed as default. Even if the point with the phone

> is that users can do what they want, it doesn't mean that the apps
they 
> install shouldn't be protected. And a firewall is almost the only
viable 
> way. There's no easy way of making all the apps listen to just one 
> interface, and while host.allow/deny is more lightweight than a 
> firewall, those don't allow distinguishing of interface.

SELinux comes to mind. Or at least the capabilites framework.
This way i could choose to allow a app to open sockets. (Little bit like

java sandboxes)
As far as i know we could even have a popup asking for permission.

And to give my 2 Eurocents to the everything as root discusion.
Running user apps as root must end, better soon.
If apps need things only root can do (not much comes to my mind) we 
could use sudo wrapper or SELinux rules.

-- 
Drucken Sie diese Mail bitte nur auf Recyclingpapier aus.
Please print this mail only on recycled paper.

___
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: MokSec - The Security Framework

[arne anka]

> And to give my 2 Eurocents to the everything as root discusion.
> Running user apps as root must end, better soon.

what exactly speaks against creating a regular user? did anyone try it  
already?
and where exactly is "root" as default user stored?


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

Re: MokSec - The Security Framework

[Jan de Haan]

On Mon, Jul 14, 2008 at 4:50 PM, Kalle Happonen <[EMAIL PROTECTED]> wrote:
> But there are places where
> you can get SIM cards with built in encyption/decryption keys, and a
> certificate (PKI).

I agree. Would you care to elaborate (link)?

Sincerely,

Jan.

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

Re: MokSec - The Security Framework

[thomasg]

On Mon, Jul 14, 2008 at 3:35 PM, Kalle Happonen <[EMAIL PROTECTED]>
wrote:


> What an insult! *slap* :P. No I'm not a windows user. and I can set the
> root password on my device, but defaults matter. And they matter a lot
> if openmoko will become more mass-market. A firewall migth be a bit
> heavy, I agree, every watt and cycle should try to be saved, but making
> dropbear just listen to the usb interface would be a pretty good
> compromise, if that is possible.
>

Ok, sorry, that was a too mean joke :P
The situation with no root password set is of course not bearable, but I'm
pretty sure that this issue will be solved in a consumer-ready release.
What I'd imagine would be a kind of "first-run-guide", that "forces" (or
allows, however you want :) ) the user to do all the important settings at
the first run of the phone (could be used for backup purposes, too, e.g.
load an xml-file with the settings).
Would make the life way easier for newbies.

However, later on an easily configurable firewall would be almost
> essential imho. Connecting to the phone (any port) over the wifi should
> (almost?)never be allowed as default. Even if the point with the phone
> is that users can do what they want, it doesn't mean that the apps they
> install shouldn't be protected. And a firewall is almost the only viable
> way. There's no easy way of making all the apps listen to just one
> interface, and while host.allow/deny is more lightweight than a
> firewall, those don't allow distinguishing of interface.


A firewall is always a more or less big piece of software, always not the
best for performance, and always a security risk (if it's not dedicated). It
also is not possible to do a easy and _good_ configuration, so however it's
done, it's always suboptimal.
There are not too much services running, and all of them are open source
software, so that is imho not that a big deal.


> >
> > In addition to that, a separate encrypted partition for /root (or
> > /home
> > if the account will changed to a non-privileged user) could be
> > nice, but
> > maybe too heavy and battery draining?
> >
> >
> > Imho it's not needed to encrypt the whole system.
> > Would be the better choice to have some crypto-containers for the
> > files that really need to be secured (phonebook, messages, important
> > documents). We had some discussion in IRC a while ago and my idea would
> No, not the whole system. But well the user homedir would be basically
> what we want to protect, and if it was on it's own partition, there is
> kernel support for it already.
> > be to have that containers and a daemon in background who handles
> > encryption/decryption, asks for passwords if needed and makes sure
> > that applications who want access to a encrypted container get it
> > (e.g. dialer wants to look up a number in the phonebook).
> > This way the containers can stay decrypted while the phone is on and
> > access is granted dynamically (as needed).
> I think completely dynamic decryption would be too cumbersone to use. If
> you mean that it would need an unlock for every received sms (to get the
> contact behind the number) and phone call, it's just unfeasible. If you
> want to protect the en/decryption key, it needs a passphrase that is
> long enough to be of any benefit. The other option is a PKI enabled SIM,
> which would be cool. Hence it should be unlocked only once, at bootup.
> The sim pin could also be saved on the encrypted partition (maybe the
> pin itself again encrypted with the passphrase, so it's not accessible
> easily at runtime) so that the user only needs to authenticate once to
> use the phone. There could be then options to forget the encryption key
> either locally or via a "magic sms".
> > Yeah, it's a little much effort, but there is no security without it.
> > If you'd encrypt the whole rootfs you'd have it decrypted the whole
> > time the phone is on (otherwise nothing would work), what means, the
> > security is gone.
> No it doesn't. Everything NEEDS to be decrypted automagically when the
> phone is on. Otherwise it's just unusable. The whole system shouldn't be
> encrypted, that's just waste.  But having a personal area decrypted at
> startup means that only you can access it at bootup, and one can add the
> option of remotely disabling access to it. That is very much security,
> way more than phones usually have nowadays, even more than
> laptops/desktops, but not too much to make it hard/annoying to use.
> > Well, that's only a part of a possible security framework, but this
> > are only some thoughts.
> >
> >
> > In addition to that, I'd say all linux security administration best
> > practices should be at least considered, including automatic security
> > updates.
> >
> >
> > It's a standard linux system with a lightweight, but still standard,
> > packet management, so that's how it already is handeled (well, without
> > the automatic, but I don't like automatic updating anyway).
> >
> 

Re: MokSec - The Security Framework

[thomasg]

On Mon, Jul 14, 2008 at 5:08 PM, arne anka <[EMAIL PROTECTED]> wrote:

> > And to give my 2 Eurocents to the everything as root discusion.
> > Running user apps as root must end, better soon.
>
> what exactly speaks against creating a regular user? did anyone try it
> already?
> and where exactly is "root" as default user stored?


In /etc/passwd :)
Of course you can create another user, as you are used to on any unix
system.
It just doesn't ship with one because the distro comes in ready-to-deploy
images, not with a installer like the binary-distro-people are used to.
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: MokSec - The Security Framework

[Kalle Happonen]

Jan de Haan wrote:
> On Mon, Jul 14, 2008 at 4:50 PM, Kalle Happonen <[EMAIL PROTECTED]> wrote:
>   
>> But there are places where
>> you can get SIM cards with built in encyption/decryption keys, and a
>> certificate (PKI).
>> 
>
> I agree. Would you care to elaborate (link)?
>
> Sincerely,
>
>   
Sure, the only one I know about directly is this, it's coordinated by 
the Finninsh government, and naturally only available in finland.
http://www.vrk.fi/vrk/home.nsf/pages/FE039B4246B8FED9C22572450036E7E6?opendocument


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

Re: MokSec - The Security Framework

[arne anka]

> Of course you can create another user, as you are used to on any unix
> system.
> It just doesn't ship with one because the distro comes in ready-to-deploy
> images, not with a installer like the binary-distro-people are used to.

sure? i think it possible that some things won't work when non-root ...


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

Re: MokSec - The Security Framework

[thomasg]

On Mon, Jul 14, 2008 at 5:22 PM, arne anka <[EMAIL PROTECTED]> wrote:

> > Of course you can create another user, as you are used to on any unix
> > system.
> > It just doesn't ship with one because the distro comes in ready-to-deploy
> > images, not with a installer like the binary-distro-people are used to.
>
> sure? i think it possible that some things won't work when non-root ...


Of course some things won't work - if they would, there would be no need for
a special root account.
Basically all the tools someone would use without a terminal should work
(dialer, contacs, ...) no matter what stack is used.
The daemons that need root access run in background and can be controlled by
userspace-programs without root-access.

If of course would take a loginmanager or similar to use a user with
password at startup, because currently the user root is automatically logged
in. Should be easy to "fix".
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Anyone using FR as a phone?

[Yaroslav Halchenko]

Ah -- thanks for the clarification!

How does 'running' microwave/hair drier/coffee-grinder affects it? :-)
may be some obvious EM noise source like that could create an easily
reproducible and controllable environment for
troubleshooting/comparison to the reference phone at hands.

On Mon, 14 Jul 2008, Joerg Reisenweber wrote:
> It's not unit specific. This at least we already can say.
> Slight variations in severity, but I didn't get to reproduce it even 
> with "known bad" devices, here at my lab. This "known bad" FR performed 
> better than a Nokia6210 I used for reference. At my lab. :-/
> But it's basically a EMI-shielding issue, it seems. We're on it.

-- 
Yaroslav Halchenko
Research Assistant, Psychology Department, Rutgers-Newark
Student  Ph.D. @ CS Dept. NJIT
Office: (973) 353-5440x263 | FWD: 82823 | Fax: (973) 353-1171
101 Warren Str, Smith Hall, Rm 4-105, Newark NJ 07102
WWW: http://www.linkedin.com/in/yarik


signature.asc
Description: Digital signature
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: GPS

[Timo Jyrinki]

2008/7/14 thomasg <[EMAIL PROTECTED]>:
> This all are no arguments.
> With my TomTom device I can do a full reset so that no GPS data is available
> at all (also no time and so on) and still get a fix in < 3 minutes at 100
> km/h.

Ok, I don't claim my guess would be truth, I'm just guessing. Is it so
that when the fix has been gotten, it stays and works properly even
with (supposedly) very poor antenna like Neo's, even in places where
zero signal was seemingly being got before the fix was had
(elsewhere)?

The main interesting thing for me was that the map updated completely
fine inside a car and between tall buildings, after the fix was
finally gotten. Is this really possible if the problem is broken /
very poor antenna that cannot receive almost any signals? If such
finely working GPS function is not possible in the case antenna is so
poor that these fixes are so hard to get as it seems most of the time,
then it would more likely be this is the case of this (random)
internal/external switch problem instead of broken antenna otherwise.
Or if not that, then some other possibly software based problem
related to getting the fixes - again something in which I don't know
enough about GPS since I don't know if the software is supposed to do
something else besides telling the GPS chip to "get the fix, please".

-Timo

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

Re: Can't boot Freerunner without battery - Was: Re: unable to start up freerunner after batterie was full down

[Steven **]

The battery can delivery more power than the AC USB adapter?

-Steven

On Mon, Jul 14, 2008 at 1:18 AM, Joerg Reisenweber <[EMAIL PROTECTED]> wrote:
> Am Mo  14. Juli 2008 schrieb Steven **:
>> Perhaps it's been said before and I missed it...  But why can't the
>> Neo boot off USB power alone?
>
> Boils down to sth like powering up a whole town after blackout.
> All components drawing a spike of energy same moment, which USB can't
> deliver. ->next blackout.
> Werner's new U-boot extenuates this somewhat, but as much of this is inside
> PMU hardcoded, SW can't do much.
>
> /jOERG
>

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

Re: MokSec - The Security Framework

[Tilman Baumann]

Kalle Happonen wrote:
> Jan de Haan wrote:
>> On Mon, Jul 14, 2008 at 4:50 PM, Kalle Happonen <[EMAIL PROTECTED]> wrote:
>>   
>>> But there are places where
>>> you can get SIM cards with built in encyption/decryption keys, and a
>>> certificate (PKI).
>>> 
>> I agree. Would you care to elaborate (link)?
>>
>> Sincerely,
>>
>>   
> Sure, the only one I know about directly is this, it's coordinated by 
> the Finninsh government, and naturally only available in finland.
> http://www.vrk.fi/vrk/home.nsf/pages/FE039B4246B8FED9C22572450036E7E6?opendocument

I wish more governments would be so progressive. *g*
We in Germany are botching around on this idea for years with apparently 
no result. But at least our politicians have the will to implement 
anonymous signatures, which is rather cool.
Sometimes you just want to prove that you are real, and not who you 
actually are.

Well, off topic... Congrats Finland. ;)


-- 
Drucken Sie diese Mail bitte nur auf Recyclingpapier aus.
Please print this mail only on recycled paper.

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

Re: MokSec - The Security Framework

[Steven Kurylo]

On Mon, Jul 14, 2008 at 7:02 AM, Kalle Happonen <[EMAIL PROTECTED]> wrote:
> arne anka wrote:
>>> wouldn't think it's too much. How often do you reboot the phone?
>>>
>>
>> with a battery uptime of about 8h -- at least once a day, because the fr
>> usually silently shuts down.
>> on weekends more frequently because i play around and something crashes or
>> so.
>>
> Well, this wasn't available now, was it? :). Since these are only plans,
> and afaik the powersave functionality will be vastly improved, that
> argument is hopefully invalid when the encryption is available.

And if you're not willing to have the inconvenience of a long password
on boot up, use an easier one.  You're slightly less secure, but still
more secure than having no encryption.

-- 
Steven Kurylo

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

Re: MokSec - The Security Framework

[Kalle Happonen]

Tilman Baumann wrote:
> Kalle Happonen wrote:
>   
>> Jan de Haan wrote:
>> 
>>> On Mon, Jul 14, 2008 at 4:50 PM, Kalle Happonen <[EMAIL PROTECTED]> wrote:
>>>   
>>>   
 But there are places where
 you can get SIM cards with built in encyption/decryption keys, and a
 certificate (PKI).
 
 
>>> I agree. Would you care to elaborate (link)?
>>>
>>> Sincerely,
>>>
>>>   
>>>   
>> Sure, the only one I know about directly is this, it's coordinated by 
>> the Finninsh government, and naturally only available in finland.
>> http://www.vrk.fi/vrk/home.nsf/pages/FE039B4246B8FED9C22572450036E7E6?opendocument
>> 
>
> I wish more governments would be so progressive. *g*
> We in Germany are botching around on this idea for years with apparently 
> no result. But at least our politicians have the will to implement 
> anonymous signatures, which is rather cool.
> Sometimes you just want to prove that you are real, and not who you 
> actually are.
>
> Well, off topic... Congrats Finland. ;)
>
>   
Well it looks cool, but in practice... there's maybe 1 service that 
accepts these.. maybe. And the operators are clueless about it. I agree, 
it's great to have this infrastructure, but without services, it's just 
a virtual finnish penis




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

Re: Can't boot Freerunner without battery - Was: Re: unable to start up freerunner after batterie was full down

[Al Johnson]

The phone can't take >100mA from USB without asking, and the PMU enforces 
this. The AC PSU can supply more than this, as can most USB ports, but at 
this stage of the process the checks to see if this is available can't be 
done so we're limited to 100mA. When the old uBoot powered up the assorted 
chips the current would spike higher than 100mA which was fine with battery, 
but without battery the PMU would cut the power to stop violation of the USB 
100mA limit. The new uBoot changes the power up sequence to try to keep the 
current below 100mA at all times. That's a rough outline anyway - full 
discussion in the kernel list archive.

On Monday 14 July 2008, Steven ** wrote:
> The battery can delivery more power than the AC USB adapter?
>
> -Steven
>
> On Mon, Jul 14, 2008 at 1:18 AM, Joerg Reisenweber <[EMAIL PROTECTED]> 
wrote:
> > Am Mo  14. Juli 2008 schrieb Steven **:
> >> Perhaps it's been said before and I missed it...  But why can't the
> >> Neo boot off USB power alone?
> >
> > Boils down to sth like powering up a whole town after blackout.
> > All components drawing a spike of energy same moment, which USB can't
> > deliver. ->next blackout.
> > Werner's new U-boot extenuates this somewhat, but as much of this is
> > inside PMU hardcoded, SW can't do much.
> >
> > /jOERG
>
> ___
> 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: [qtopia on freerunner] - What is the right place to discuss Qtopia on Openmoko?

[Kai Stian Olstad]

On Mon, Jul 14, 2008 at 9:27 AM, Lorn Potter <[EMAIL PROTECTED]> wrote:
>>> If anyone knows how to get a real battery status on the freerunner I can
>>> fix this up.
>>
>> I only know of 
>> /sys/devices/platform/bq27000-battery.0/power_supply/bat/status.
>> Maybe that helps?
>
> not on my devices:
>
> [EMAIL PROTECTED]:~# cat
> /sys/devices/platform/bq27000-battery.0/power_supply/bat/status
> cat: read error: Timer expired

On my device:
[EMAIL PROTECTED]:~# cat
/sys/devices/platform/bq27000-battery.0/power_supply/bat/status
Charging

-
Kai Stian Olstad

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

Re: MokSec - The Security Framework

[Kalle Happonen]

thomasg wrote:
> On Mon, Jul 14, 2008 at 5:22 PM, arne anka <[EMAIL PROTECTED] 
> > wrote:
>
> > Of course you can create another user, as you are used to on any
> unix
> > system.
> > It just doesn't ship with one because the distro comes in
> ready-to-deploy
> > images, not with a installer like the binary-distro-people are
> used to.
>
> sure? i think it possible that some things won't work when
> non-root ...
>
>
> Of course some things won't work - if they would, there would be no 
> need for a special root account.
> Basically all the tools someone would use without a terminal should 
> work (dialer, contacs, ...) no matter what stack is used.
> The daemons that need root access run in background and can be 
> controlled by userspace-programs without root-access.
>
> If of course would take a loginmanager or similar to use a user with 
> password at startup, because currently the user root is automatically 
> logged in. Should be easy to "fix".
Even running only critical things as root, and most stuff on a 
no-password unprivileged account would be better. But an user account 
with a password a would of course be better. The I'd say that the PIN 
could almost be saved somewhere, to avoid the need for a double log-in.

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

Re: warranty issues

[Sean Moss-Pultz]

On 7/12/08 simarillion wrote:
> can somebody tell me if I will lose my warranty when I open my 
> Freerunner. 

Hehe...do you really think we could get away with that kind of policy?!

This is Openmoko. If you /don't/ open your Neo, you should probably have 
your warranty voided ;-)


   -Sean

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

Segmentation fault trying to use opkg update

[Juan Otero]

Hi i  don't know if the right place to post this.
well, i'm triying update neo and i get this:
[EMAIL PROTECTED]:~# opkg update
Downloading
http://www.angstrom-distribution.org/feeds/2007/ipk/glibc/armv4t/base/Packages.gz
100%
||
Inflating
http://www.angstrom-distribution.org/feeds/2007/ipk/glibc/armv4t/base/Packages.gz
Updated list of available packages in /var/lib/opkg/base
Downloading
http://www.angstrom-distribution.org/feeds/2007/ipk/glibc/armv4t/base/Packages.sig

Segmentation fault


i was looking for an answer in mailing list but not found nothing.

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

Re: GPS

[Jay Vaughan]

> The module talks NMEA but also a ublox binary format. Among other  
> things this
> allows time and location estimates, ephemeris and almanac data to be  
> fed to
> the module to give it an initial state, and should reduce time to  
> first fix.
> Likewise it can be used to request this data from the module so it  
> can be
> saved before shutdown. 'Driver' probably isn't the right word.


So we just need to wrap 'save' and 'restore' scripts around the gpsd  
script?

;
--
Jay Vaughan





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

Re: MokSec - The Security Framework

[Jay Vaughan]

> I've only had my freerunner for a week or so, so I'm not too into the
> security aspects yet. One thing I did notice was of course  
> passwordless
> root login. Now over usb this can be acceptable, but if this is  
> possible
> over wifi (I haven't actually tested), it needs the firewall / make it
> listen only to the usb.
>

Set your own root password.  Fixed.


;
--
Jay Vaughan





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

Re: MokSec - The Security Framework

[thomasg]

On Mon, Jul 14, 2008 at 6:13 PM, Kalle Happonen <[EMAIL PROTECTED]>
wrote:

> thomasg wrote:
> > On Mon, Jul 14, 2008 at 5:22 PM, arne anka <[EMAIL PROTECTED]
> > > wrote:
> >
> > > Of course you can create another user, as you are used to on any
> > unix
> > > system.
> > > It just doesn't ship with one because the distro comes in
> > ready-to-deploy
> > > images, not with a installer like the binary-distro-people are
> > used to.
> >
> > sure? i think it possible that some things won't work when
> > non-root ...
> >
> >
> > Of course some things won't work - if they would, there would be no
> > need for a special root account.
> > Basically all the tools someone would use without a terminal should
> > work (dialer, contacs, ...) no matter what stack is used.
> > The daemons that need root access run in background and can be
> > controlled by userspace-programs without root-access.
> >
> > If of course would take a loginmanager or similar to use a user with
> > password at startup, because currently the user root is automatically
> > logged in. Should be easy to "fix".
> Even running only critical things as root, and most stuff on a
> no-password unprivileged account would be better. But an user account
> with a password a would of course be better. The I'd say that the PIN
> could almost be saved somewhere, to avoid the need for a double log-in.


I had some thoughts about that, too.
Would be cool if it wasn't necessary to have a PIN at all - you enter the
PIN in the "first-run-wizard", that will store it.
After that you only have one password (of your choise) that does all - the
security daemon would lookup in a key/password-database and use your
password for all things, like decrypting the other containers (phonebook,
messages, e.g.), authing you on the network with the stored pin, unlocking
the phone screen, .
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: MokSec - The Security Framework

[Kalle Happonen]

thomasg wrote:
> On Mon, Jul 14, 2008 at 3:35 PM, Kalle Happonen <[EMAIL PROTECTED] 
> > wrote:
>  
>
> What an insult! *slap* :P. No I'm not a windows user. and I can
> set the
> root password on my device, but defaults matter. And they matter a lot
> if openmoko will become more mass-market. A firewall migth be a bit
> heavy, I agree, every watt and cycle should try to be saved, but
> making
> dropbear just listen to the usb interface would be a pretty good
> compromise, if that is possible.
>
>  
> Ok, sorry, that was a too mean joke :P
I forgive you :)
> The situation with no root password set is of course not bearable, but 
> I'm pretty sure that this issue will be solved in a consumer-ready 
> release.
> What I'd imagine would be a kind of "first-run-guide", that "forces" 
> (or allows, however you want :) ) the user to do all the important 
> settings at the first run of the phone (could be used for backup 
> purposes, too, e.g. load an xml-file with the settings).
> Would make the life way easier for newbies.
>
That would make sense yes. And since it's a pretty complex device, a 
first-run setup is almost needed anyway.
>
> However, later on an easily configurable firewall would be almost
> essential imho. Connecting to the phone (any port) over the wifi
> should
> (almost?)never be allowed as default. Even if the point with the phone
> is that users can do what they want, it doesn't mean that the apps
> they
> install shouldn't be protected. And a firewall is almost the only
> viable
> way. There's no easy way of making all the apps listen to just one
> interface, and while host.allow/deny is more lightweight than a
> firewall, those don't allow distinguishing of interface.
>
>  
> A firewall is always a more or less big piece of software, always not 
> the best for performance, and always a security risk (if it's not 
> dedicated). It also is not possible to do a easy and _good_ 
> configuration, so however it's done, it's always suboptimal.
> There are not too much services running, and all of them are open 
> source software, so that is imho not that a big deal.
>
iptables fits into a small kernel, that's not big software :). It might 
have some performance hits, but with these traffic amounts it shouldn't 
matter. The big but is of course the frontend to it. And open source 
software isn't immune to vulnerabilities :). Security patches help, but 
if possible, I'd still go for a firewall.
>
>
> >
> > In addition to that, a separate encrypted partition for
> /root (or
> > /home
> > if the account will changed to a non-privileged user) could be
> > nice, but
> > maybe too heavy and battery draining?
> >
> >
> > Imho it's not needed to encrypt the whole system.
> > Would be the better choice to have some crypto-containers for the
> > files that really need to be secured (phonebook, messages, important
> > documents). We had some discussion in IRC a while ago and my
> idea would
> No, not the whole system. But well the user homedir would be basically
> what we want to protect, and if it was on it's own partition, there is
> kernel support for it already.
> > be to have that containers and a daemon in background who handles
> > encryption/decryption, asks for passwords if needed and makes sure
> > that applications who want access to a encrypted container get it
> > (e.g. dialer wants to look up a number in the phonebook).
> > This way the containers can stay decrypted while the phone is on and
> > access is granted dynamically (as needed).
> I think completely dynamic decryption would be too cumbersone to
> use. If
> you mean that it would need an unlock for every received sms (to
> get the
> contact behind the number) and phone call, it's just unfeasible.
> If you
> want to protect the en/decryption key, it needs a passphrase that is
> long enough to be of any benefit. The other option is a PKI
> enabled SIM,
> which would be cool. Hence it should be unlocked only once, at bootup.
> The sim pin could also be saved on the encrypted partition (maybe the
> pin itself again encrypted with the passphrase, so it's not accessible
> easily at runtime) so that the user only needs to authenticate once to
> use the phone. There could be then options to forget the
> encryption key
> either locally or via a "magic sms".
> > Yeah, it's a little much effort, but there is no security
> without it.
> > If you'd encrypt the whole rootfs you'd have it decrypted the whole
> > time the phone is on (otherwise nothing would work), what means, the
> > security is gone.
> No it doesn't. Everything NEEDS to be decrypted automagically when the
> phone is on. Otherwise it's just unusable. The whole system
> shouldn't be

Re: GPS

[thomasg]

On Mon, Jul 14, 2008 at 4:23 PM, Jay Vaughan <[EMAIL PROTECTED]> wrote:

> > The module talks NMEA but also a ublox binary format. Among other
> > things this
> > allows time and location estimates, ephemeris and almanac data to be
> > fed to
> > the module to give it an initial state, and should reduce time to
> > first fix.
> > Likewise it can be used to request this data from the module so it
> > can be
> > saved before shutdown. 'Driver' probably isn't the right word.
>
>
> So we just need to wrap 'save' and 'restore' scripts around the gpsd
> script?


Basically yes, but this won't fix the problem. It's for later when the
problem is fixed, so you wouldn't have to wait a minute for the fix but 10
seconds.
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: GPS

[thomasg]

On Mon, Jul 14, 2008 at 2:12 PM, Ken Young <[EMAIL PROTECTED]> wrote:

> thomasg wrote:
>
> > This all are no arguments.
> > With my TomTom device I can do a full reset so that no GPS data is
> > available
> > at all (also no time and so on) and still get a fix in < 3 minutes at
> > 100 km/h.
> > Well, I know the freerunner is no specialized gps navigation device, but
> > the
> > fact that the signals are so weak that it's barely possible to get a fix
> > under optimal condition (clear view to the sky, antenna on top, without
> > moving 1 mm) shows, that this is no simple software problem and has to
> > be fixed.
>
> The GPS performance of my Freerunner is also much worse than
> the GPS performance of my neo1973.   I've done side-by-side tests of the
> two units many times.   My neo1973 gets a good fix in 2 to 3 minutes
> after a completely cold start; it's very reliable.   My Freerunner
> initially was getting a fix after 7 or 8 minutes.   For the last few
> days it has not been able to get a fix at all.
>
> Ken Young


I can confirm that, too.
The 1973 gets a cold start fix in less than 2 minutes.
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: GPS

[C R McClenaghan]

This will be my 3rd GPS device in ~5 years. The first two - a NAVMAN  
from New Zealand and a Garmin - always had exceedingly long cold  
starts (i.e. turn the device off, fly >1500 km, turn device on), on  
the order of 10 minutes.

I still have the Garmin in working condition, it is the Garmin 10, a  
bluetooth model. If some one could help me with the FR bluetooth, and  
the GSP applications, I could connect to FR "gps" stack to the Garmin  
to isolate them from the on board chip. This would, of course. assume  
that the bluetooth stack didn't cloud any issue.

Thoughts, how-tos?

Chris

On Jul 14, 2008, at 7:23 AM, Jay Vaughan wrote:

>> The module talks NMEA but also a ublox binary format. Among other
>> things this
>> allows time and location estimates, ephemeris and almanac data to be
>> fed to
>> the module to give it an initial state, and should reduce time to
>> first fix.
>> Likewise it can be used to request this data from the module so it
>> can be
>> saved before shutdown. 'Driver' probably isn't the right word.
>
>
> So we just need to wrap 'save' and 'restore' scripts around the gpsd
> script?
>
> ;
> --
> Jay Vaughan
>
>
>
>
>
> ___
> 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

When does it suspend?

[Joachim Breitner]

Hi,

Am Montag, den 14.07.2008, 11:20 +0200 schrieb arne anka:
> experienced that (no o2 user!) with power management set to "dim first,  
> then lock". after switching to "dim only, don't lock" i didn't see it  
> anymore -- but the fr still locks ...

speaking of suspend mode: When is the Freerunner supposed to suspend
automatically? After a certain time with the Lock Screen active, or
after a certain time with no user input? Note that the latter causes
problems when there is constant random „input“ (Freerunner in the
pocket).

And it’s not suspended when I can activate it by touching the screen,
right? And is there a way to manually put the Freerunner to screen?

Greetings and thanks,
Joachim


-- 
Joachim Breitner
  e-Mail: [EMAIL PROTECTED]
  Homepage: http://www.joachim-breitner.de
  ICQ#: 74513189
  Jabber-ID: [EMAIL PROTECTED]


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: GPS

[C R McClenaghan]

What is meant by "cold start"? Is this simply a power off and power  
back on? Or is it the power cycle and no previous fix data for current  
location? With other GPS devices, until that first location fix was  
achieved, nothing happened, but once achieved and no significant  
change in geography, then a fix could be achieved in less than a few  
minutes. Given that most of these devices are being received in a  
location different than where ever the device may have previously  
gotten a fix, my thought is part of the problem is getting that first  
current location fix.


Chris

On Jul 14, 2008, at 9:23 AM, thomasg wrote:

On Mon, Jul 14, 2008 at 2:12 PM, Ken Young <[EMAIL PROTECTED]>  
wrote:

thomasg wrote:

> This all are no arguments.
> With my TomTom device I can do a full reset so that no GPS data is
> available
> at all (also no time and so on) and still get a fix in < 3 minutes  
at

> 100 km/h.
> Well, I know the freerunner is no specialized gps navigation  
device, but

> the
> fact that the signals are so weak that it's barely possible to get  
a fix
> under optimal condition (clear view to the sky, antenna on top,  
without
> moving 1 mm) shows, that this is no simple software problem and  
has to

> be fixed.

The GPS performance of my Freerunner is also much worse than
the GPS performance of my neo1973.   I've done side-by-side tests of  
the

two units many times.   My neo1973 gets a good fix in 2 to 3 minutes
after a completely cold start; it's very reliable.   My Freerunner
initially was getting a fix after 7 or 8 minutes.   For the last few
days it has not been able to get a fix at all.

Ken Young

I can confirm that, too.
The 1973 gets a cold start fix in less than 2 minutes.

___
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: MokSec - The Security Framework

[Tilman Baumann]

Kalle Happonen wrote:
>> Well, off topic... Congrats Finland. ;)
>>
>>   
> Well it looks cool, but in practice... there's maybe 1 service that 
> accepts these.. maybe. And the operators are clueless about it. I agree, 
> it's great to have this infrastructure, but without services, it's just 
> a virtual finnish penis

Well, then congrats for the largest virtual penis.
Who needs real success in times of the internet where fame is 
everything. *g*
-- 
Drucken Sie diese Mail bitte nur auf Recyclingpapier aus.
Please print this mail only on recycled paper.

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

Re: GPS

[arne anka]

>> So we just need to wrap 'save' and 'restore' scripts around the gpsd
>> script?
>
>
> Basically yes, but this won't fix the problem. It's for later when the

what exactly is the gpsd for, anyway?
looking at my fr yesterday i noticed it is not installed anymore, if it  
ever was, that is, (and not available in the official feeds i got in my  
opkg-config).

with agpsui i got one fix once, putting the fr in my bag and cycling home  
-- after 2/3 in a park i looked and it got a fix and ttff 1400.
it was the only time i got one, so i wonder if the gpsd may somehow be  
involved ...

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

Re: GPS

[Yorick Moko]

with cold start they mean no previous data: no information about
satellites, location or time

since the GPS chip itself does not have any memory, currently a power
off -> power on always results in a cold start (there is however some
work being done to overcome this, but I don't know if it is already
working)

On Mon, Jul 14, 2008 at 6:33 PM, C R McClenaghan <[EMAIL PROTECTED]> wrote:
> What is meant by "cold start"? Is this simply a power off and power back on?
> Or is it the power cycle and no previous fix data for current location? With
> other GPS devices, until that first location fix was achieved, nothing
> happened, but once achieved and no significant change in geography, then a
> fix could be achieved in less than a few minutes. Given that most of these
> devices are being received in a location different than where ever the
> device may have previously gotten a fix, my thought is part of the problem
> is getting that first current location fix.
> Chris
>
> On Jul 14, 2008, at 9:23 AM, thomasg wrote:
>
> On Mon, Jul 14, 2008 at 2:12 PM, Ken Young <[EMAIL PROTECTED]> wrote:
>>
>> thomasg wrote:
>>
>> > This all are no arguments.
>> > With my TomTom device I can do a full reset so that no GPS data is
>> > available
>> > at all (also no time and so on) and still get a fix in < 3 minutes at
>> > 100 km/h.
>> > Well, I know the freerunner is no specialized gps navigation device, but
>> > the
>> > fact that the signals are so weak that it's barely possible to get a fix
>> > under optimal condition (clear view to the sky, antenna on top, without
>> > moving 1 mm) shows, that this is no simple software problem and has to
>> > be fixed.
>>
>> The GPS performance of my Freerunner is also much worse than
>> the GPS performance of my neo1973.   I've done side-by-side tests of the
>> two units many times.   My neo1973 gets a good fix in 2 to 3 minutes
>> after a completely cold start; it's very reliable.   My Freerunner
>> initially was getting a fix after 7 or 8 minutes.   For the last few
>> days it has not been able to get a fix at all.
>>
>> Ken Young
>
> I can confirm that, too.
> The 1973 gets a cold start fix in less than 2 minutes.
>
> ___
> 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: MokSec - The Security Framework

[Crane, Matthew]

 
There's apps that do this, like kdewallet. 
 
I was thinking of a picture pin entry.  You display a small set of
pictures with lots of detail, user must tap 1 or more points on each
pictures. 
 
Quick entry, good number of bits of encryption, easy to remeber.
 
Plus, when the phone comes up with a picture, to anybody else it just
looks like it's stuck booting or broken.




From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of thomasg
Sent: Monday, July 14, 2008 12:19 PM
To: List for Openmoko community discussion
Subject: Re: MokSec - The Security Framework


On Mon, Jul 14, 2008 at 6:13 PM, Kalle Happonen <[EMAIL PROTECTED]>
wrote:



I had some thoughts about that, too.
Would be cool if it wasn't necessary to have a PIN at all - you
enter the PIN in the "first-run-wizard", that will store it.
After that you only have one password (of your choise) that does
all - the security daemon would lookup in a key/password-database and
use your password for all things, like decrypting the other containers
(phonebook, messages, e.g.), authing you on the network with the stored
pin, unlocking the phone screen, .


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

Re: When does it suspend?

[arne anka]

> speaking of suspend mode: When is the Freerunner supposed to suspend
> automatically? After a certain time with the Lock Screen active, or
> after a certain time with no user input?

the latter, i think.

> Note that the latter causes
> problems when there is constant random „input“ (Freerunner in the
> pocket).

yepp -- it's rather annoying. i think a menu entry for the power or aux  
menu is needed, disabling the screen completely.
accepring a call could be done by hitting aux and the screen may  
(configurable) switch on while calling.

> And it’s not suspended when I can activate it by touching the screen,

depends probably on your definition of "suspend".

> right? And is there a way to manually put the Freerunner to screen?

"put to screen"?


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

Re: warranty issues

[ian douglas]

Sean Moss-Pultz wrote:
> This is Openmoko. If you /don't/ open your Neo, you should probably have 
> your warranty voided ;-)


Wow, second best quote I've ever seen on this list.

The first being back in early May...
Andy Powell wrote:
> Seriously, If everyone put as much effort into development as they do
> into bitching and whining this phone would be able to cure cancer by
> now.

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

Re: GPS

[Al Johnson]

On Monday 14 July 2008, arne anka wrote:
> >> So we just need to wrap 'save' and 'restore' scripts around the gpsd
> >> script?
> >
> > Basically yes, but this won't fix the problem. It's for later when the
>
> what exactly is the gpsd for, anyway?
> looking at my fr yesterday i noticed it is not installed anymore, if it
> ever was, that is, (and not available in the official feeds i got in my
> opkg-config).

gpsd is there so that more than one program can access the GPS device at the 
same time, making it available over a network interface. Some apps can access 
GPS data via gpsd but not directly from the device. I think tangogps is among 
them.

Gypsy does something similar but shares it using dbus, and claims to be more 
efficient. FSO will apparently be using gypsy instead of gpsd, but currently 
more apps can connect to gpsd than gypsy.

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

Re: GPS

[thomasg]

On Mon, Jul 14, 2008 at 6:42 PM, arne anka <[EMAIL PROTECTED]> wrote:

> >> So we just need to wrap 'save' and 'restore' scripts around the gpsd
> >> script?
> >
> >
> > Basically yes, but this won't fix the problem. It's for later when the
>
> what exactly is the gpsd for, anyway?
> looking at my fr yesterday i noticed it is not installed anymore, if it
> ever was, that is, (and not available in the official feeds i got in my
> opkg-config).
>
> with agpsui i got one fix once, putting the fr in my bag and cycling home
> -- after 2/3 in a park i looked and it got a fix and ttff 1400.
> it was the only time i got one, so i wonder if the gpsd may somehow be
> involved ...


Afaik gpsd is only used to make the NMEA data more accessible without having
every app to parse it and some other minor things that makes handling
easier.
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: When does it suspend?

[Joachim Breitner]

Hi,

Am Montag, den 14.07.2008, 18:47 +0200 schrieb arne anka:
> > speaking of suspend mode: When is the Freerunner supposed to suspend
> > automatically? After a certain time with the Lock Screen active, or
> > after a certain time with no user input?
> the latter, i think.
> 
> > Note that the latter causes
> > problems when there is constant random „input“ (Freerunner in the
> > pocket).
> 
> yepp -- it's rather annoying. i think a menu entry for the power or aux  
> menu is needed, disabling the screen completely.
> accepring a call could be done by hitting aux and the screen may  
> (configurable) switch on while calling.

I think it would be enough if it would not take input at the lock screen
into account for the suspend counter, so that the phone can still
suspend when carried around.

> > And it’s not suspended when I can activate it by touching the screen,
> 
> depends probably on your definition of "suspend".
> 
> > right? And is there a way to manually put the Freerunner to screen?
> "put to screen"?
sorry, put to sleep or put to suspend – too many s-words in my mind at
the same time  :-)

Also, when it’s in sleep mode, does the LED still work, e.g. tell me
about unread SMS or missed calls? If not, is that technically possible?

Greetings,
Joachim

-- 
Joachim Breitner
  e-Mail: [EMAIL PROTECTED]
  Homepage: http://www.joachim-breitner.de
  ICQ#: 74513189
  Jabber-ID: [EMAIL PROTECTED]


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: GPS

[Michael Kluge]

Today I powered up my gps the first time and got a fix after 80 seconds. 
I was on a hill in a small village outside in a garden under a apple 
tree and the Freerunner was standing upright. Then I rebooted it and got 
an other fix in 80 seconds again. I've been using agps-gui. Much better 
than I expected. The Freerunner did see 5 satellites the first time, 3 
the second time.

Michael

Ken Young schrieb:
> thomasg wrote:
> 
>> This all are no arguments.
>> With my TomTom device I can do a full reset so that no GPS data is 
>> available
>> at all (also no time and so on) and still get a fix in < 3 minutes at 
>> 100 km/h.
>> Well, I know the freerunner is no specialized gps navigation device, but 
>> the
>> fact that the signals are so weak that it's barely possible to get a fix
>> under optimal condition (clear view to the sky, antenna on top, without
>> moving 1 mm) shows, that this is no simple software problem and has to 
>> be fixed.
> 
> The GPS performance of my Freerunner is also much worse than
> the GPS performance of my neo1973.   I've done side-by-side tests of the
> two units many times.   My neo1973 gets a good fix in 2 to 3 minutes
> after a completely cold start; it's very reliable.   My Freerunner 
> initially was getting a fix after 7 or 8 minutes.   For the last few
> days it has not been able to get a fix at all.


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

Anyone in NYC with an extra Freerunner?

[Federico Lorenzi]

Hello,
So I missed my chance to get a Freerunner, and they won't take my
credit cards. But on my flight back to Cape Town Delta screwed up and
I missed my flight, so now I'm staying at my uncles place. Does anyone
near New York City or within 120km of Trumbull, CT have a Freerunner
that they would be willing to sell for $450?

Thanks!
Federico

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

Re: When does it suspend?

[arne anka]

>> > right? And is there a way to manually put the Freerunner to screen?
>> "put to screen"?
> sorry, put to sleep or put to suspend – too many s-words in my mind at
> the same time  :-)

power menu has a "lock display" entry -- might send the fr to bed.
else, maybe somewhere below /sys/ ...

> Also, when it’s in sleep mode, does the LED still work, e.g. tell me
> about unread SMS or missed calls? If not, is that technically possible?

well, with 2007.2 leds do not work at all, by fiddling with  
/sys/.../leds/.../trigger i was able to get a led after the fr was  
charged, but not while charging (despite the trigger's name  
charge-and-full or so).
regarding your muttons: i think technically it should be rather easy  
(other phones  can do, too), but that's mostly kernel land, imho.


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

Re: GPS

[arne anka]

> Today I powered up my gps the first time and got a fix after 80 seconds.
> I was on a hill in a small village outside in a garden under a apple
> tree and the Freerunner was standing upright. Then I rebooted it and got
> an other fix in 80 seconds again. I've been using agps-gui. Much better
> than I expected. The Freerunner did see 5 satellites the first time, 3
> the second time.

i am afraid, most people on this list will hate you now :-)

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

NVidia S-O-C

[Francesco Cat]

I found this System on a Chip by NVidia:
http://www.nvidia.com/object/tegra_600.html and
http://www.nvidia.com/object/apx_2500.html

It is something A-M-A-Z-I-N-G and I say I would love to see it on a GTA04 ;)

What do you think about? Will we have a chance to see it? Or it is
pure dreaming since it won't be open at all?
Nvidia seems to care about Linux and OpenSource, we might try a ride ;)

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

Re: GPS

[Yorick Moko]

maybe we just need more people testing it under an apple tree?
has Openmoko remembered to put in the magic GPS apple seeds?

seriously: somebody dissect the freerunner of michael :)

On Mon, Jul 14, 2008 at 7:22 PM, arne anka <[EMAIL PROTECTED]> wrote:
>> Today I powered up my gps the first time and got a fix after 80 seconds.
>> I was on a hill in a small village outside in a garden under a apple
>> tree and the Freerunner was standing upright. Then I rebooted it and got
>> an other fix in 80 seconds again. I've been using agps-gui. Much better
>> than I expected. The Freerunner did see 5 satellites the first time, 3
>> the second time.
>
> i am afraid, most people on this list will hate you now :-)
>
> ___
> 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: GPS

[Michael Kluge]

arne anka schrieb:
>> Today I powered up my gps the first time and got a fix after 80 seconds.
>> I was on a hill in a small village outside in a garden under a apple
>> tree and the Freerunner was standing upright. Then I rebooted it and got
>> an other fix in 80 seconds again. I've been using agps-gui. Much better
>> than I expected. The Freerunner did see 5 satellites the first time, 3
>> the second time.
> 
> i am afraid, most people on this list will hate you now :-)

Well, this test scenario on a hill within Europe without buildings 
around is probably the best case for GPS. I will try again tomorrow by 
powering it up and driving 15 minutes with the bicycle to work.


Michael

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

Re: NVidia S-O-C

[arne anka]

have a look at the archives -- there were some lengthy threads about that  
recently ...

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

Re: NVidia S-O-C

[Tim Schmidt]

On Mon, Jul 14, 2008 at 1:37 PM, Francesco Cat
<[EMAIL PROTECTED]> wrote:
> Nvidia seems to care about Linux and OpenSource

In what world have you been living for the last 10 years or so?

--tim

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

Re: GPS

[C R McClenaghan]

A refinement on the thought below - how to pipe the NMEA data to a  
bluetooth serial port so I can connect my Palm TX and run its mapping  
off the FR GPS chip data.

If anyone could provide pointers on setting up bluetooth serial  
connections to/from the FR I'd appreciate it.

Thanks,

Chris

On Jul 14, 2008, at 9:26 AM, C R McClenaghan wrote:

> This will be my 3rd GPS device in ~5 years. The first two - a NAVMAN  
> from New Zealand and a Garmin - always had exceedingly long cold  
> starts (i.e. turn the device off, fly >1500 km, turn device on), on  
> the order of 10 minutes.
>
> I still have the Garmin in working condition, it is the Garmin 10, a  
> bluetooth model. If some one could help me with the FR bluetooth,  
> and the GSP applications, I could connect to FR "gps" stack to the  
> Garmin to isolate them from the on board chip. This would, of  
> course. assume that the bluetooth stack didn't cloud any issue.
>
> Thoughts, how-tos?
>
> Chris
>
> On Jul 14, 2008, at 7:23 AM, Jay Vaughan wrote:
>
>>> The module talks NMEA but also a ublox binary format. Among other
>>> things this
>>> allows time and location estimates, ephemeris and almanac data to be
>>> fed to
>>> the module to give it an initial state, and should reduce time to
>>> first fix.
>>> Likewise it can be used to request this data from the module so it
>>> can be
>>> saved before shutdown. 'Driver' probably isn't the right word.
>>
>>
>> So we just need to wrap 'save' and 'restore' scripts around the gpsd
>> script?
>>
>> ;
>> --
>> Jay Vaughan
>>
>>
>>
>>
>>
>> ___
>> 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: NVidia S-O-C

[Álvaro Lopes]

Francesco Cat wrote:
> I found this System on a Chip by NVidia:
> http://www.nvidia.com/object/tegra_600.html and
> http://www.nvidia.com/object/apx_2500.html
> 
> It is something A-M-A-Z-I-N-G and I say I would love to see it on a GTA04 ;)
> 
> What do you think about? Will we have a chance to see it? Or it is
> pure dreaming since it won't be open at all?
> Nvidia seems to care about Linux and OpenSource, we might try a ride ;)

OpenSource ?

They care about Linux (good thing [?!?!]) cause they have a market opportunity 
there. I am not so sure they care about opensource at all.

I like nVidia graphics cause they have both performance and a nice driver. But, 
if I had a choice, I'd choose some other vendor.

Álvaro

> 
> ___
> 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: NVidia S-O-C

[Wolfgang Silbermayr]

Francesco Cat wrote:
> I found this System on a Chip by NVidia:
> http://www.nvidia.com/object/tegra_600.html and
> http://www.nvidia.com/object/apx_2500.html
> 
> It is something A-M-A-Z-I-N-G and I say I would love to see it on a GTA04 ;)
> 
> What do you think about? Will we have a chance to see it? Or it is
> pure dreaming since it won't be open at all?
> Nvidia seems to care about Linux and OpenSource, we might try a ride ;)

Where do you see any real care about Linux and OpenSource from nvidia?
If, then they only care a little bit about Linux, but they don't seem to
care about OpenSource at all - at least this is the case for their
graphics chips. I can't find any register specification or open drivers
for this SOC either.

Greetings, silwol.

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

Re: NVidia S-O-C

[thomasg]

On Mon, Jul 14, 2008 at 7:37 PM, Francesco Cat <[EMAIL PROTECTED]>
wrote:

> I found this System on a Chip by NVidia:
> http://www.nvidia.com/object/tegra_600.html and
> http://www.nvidia.com/object/apx_2500.html
>
> It is something A-M-A-Z-I-N-G and I say I would love to see it on a GTA04
> ;)
>
> What do you think about? Will we have a chance to see it? Or it is
> pure dreaming since it won't be open at all?
> Nvidia seems to care about Linux and OpenSource, we might try a ride ;)


Let's make it short: not gonna happen.
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: NVidia S-O-C

[Arne Zachlod]

on heise.de they wrote something about windows-support only.


Francesco Cat schrieb:
> I found this System on a Chip by NVidia:
> http://www.nvidia.com/object/tegra_600.html and
> http://www.nvidia.com/object/apx_2500.html
>
> It is something A-M-A-Z-I-N-G and I say I would love to see it on a GTA04 ;)
>
> What do you think about? Will we have a chance to see it? Or it is
> pure dreaming since it won't be open at all?
> Nvidia seems to care about Linux and OpenSource, we might try a ride ;)
>
> ___
> 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: NVidia S-O-C

[Francesco Cat]

Ok fine sorry for mistakes about OpenSource and whatever.

2008/7/14 thomasg <[EMAIL PROTECTED]>:
> On Mon, Jul 14, 2008 at 7:37 PM, Francesco Cat <[EMAIL PROTECTED]>
> wrote:
>>
>> I found this System on a Chip by NVidia:
>> http://www.nvidia.com/object/tegra_600.html and
>> http://www.nvidia.com/object/apx_2500.html
>>
>> It is something A-M-A-Z-I-N-G and I say I would love to see it on a GTA04
>> ;)
>>
>> What do you think about? Will we have a chance to see it? Or it is
>> pure dreaming since it won't be open at all?
>> Nvidia seems to care about Linux and OpenSource, we might try a ride ;)
>
> Let's make it short: not gonna happen.
>
>
> ___
> 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: GPS

[arne anka]

http://wiki.openmoko.org/wiki/GPS#GTA02

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

Re: NVidia S-O-C

[Tim Schmidt]

On Mon, Jul 14, 2008 at 1:51 PM, Francesco Cat
<[EMAIL PROTECTED]> wrote:
> Ehm... I don't get what you meant to say...

You said you thought they cared about Linux / Open Source.  In the
last 10 years, I haven't seen a single hint that they do.  One
possible (absurd) explanation is that we've been observing different
Nvidias from different worlds or dimensions.  Hence the question.

--tim

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

Re: Anyone in NYC with an extra Freerunner?

[Charles Pax]

On Mon, Jul 14, 2008 at 1:20 PM, Federico Lorenzi <[EMAIL PROTECTED]>
wrote:

> Hello,
> So I missed my chance to get a Freerunner, and they won't take my
> credit cards. But on my flight back to Cape Town Delta screwed up and
> I missed my flight, so now I'm staying at my uncles place. Does anyone
> near New York City or within 120km of Trumbull, CT have a Freerunner
> that they would be willing to sell for $450?
>

Have you considered joining the NYC purchasing group? I think there may be
two more slots in the second group. You can also pay using a credit card via
paypal.

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