Re: Why one cannot recommend the freerunner as a daily phone (was Re: Is a FreeRunner sufficient for me?)

[Vasco Nevoa]

Works for me too! :D

It is my only phone for almost a year now.
Yes, it needs A LOT of attention and tweaking for about 3 months until 
you get it "just right" for yourself, but after that it's "good enough" 
as a phone and GPS, and a pretty good PDA. And yes, the screen is not 
bright enough, and the earpiece not loud enough, and the vibrator not 
strong enough, and the audio/DSP is not perfectly tweaked yet (still 
some people complain in calls); but these are minor complaints when you 
think about all the freedom you get in installing anything you want, to 
use it in ways no other device lets you...

Things I still miss: working out-of-the-box bluetooth integration  
(headsets, PAN), a rock-solid GPRS and Wifi experience (still unstable 
with some kinds of network and encription), and above all, a rock-solid 
kernel.
Some people will, of course, dearly miss the 2D and 3D acceleration 
capabilities that the Glamo chip still does not have active (and 
apparently will never have). But I don't use the FR as a jukebox, so it 
doesn't affect me.

The kernel is, in my opinion, the area where OM (the company) has failed 
more spectacularly; I've never had a kernel that does everything well at 
the same time, and it certainly has passed enough development and 
testing time for that to happen. For example, it is common to have a 
kernel revision that does at least one of these things:
- crash (panic or silent lockup) on wakeup, making you lose calls - 
fortunately very sporadically, about once a month or less;
- ruin networking (drop GPRS or WIFI packets), making a connection stall 
mysteriously;
- corrupt the screen data (random noise in framebuffer) - also very 
sporadic, fortunately;
- make the FR incompatible with Windows boxes (some people need this at 
work, you know?);
- some minor hardware not working, like accelerometers;
Yes, I know that most of this stuff is hard to debug, but that's the 
kind of thing an embedded products company does: it secures the kernel 
quality first and foremost. It's all water under the bridge, now that 
the FR is strictly "community", but in my view this is what has 
prevented the device from being a world-class bedrock for VARs and 
tinkerers and inventors and anyone with and interest in FLOSS phones... 
I think that if the kernel was rock-solid and stable, people wouldn't 
care so much about "which distro works?" - the hardware would always 
"just work", and the distro would be just a matter of taste and "fitness 
for a purpose". Get the kernel right, and you have a winner.

jeremy jozwik escreveu:
> works for me too : )
>
> actually, i really like the thing. just with the screen was not 
> recessed into the shell.
> and ffalarms works great for me.
>
> On Sat, Jun 20, 2009 at 2:58 PM, Michal Brzozowski  > wrote:
>
> 2009/6/20 Joerg Lippmann  >
>
>
> OK, maybe I should explain.
>
> My mail should not be taken as FUD. I have a freerunner since
> it came out a
> year ago and - being a linux user since 1994 - I was prepared
> to get something
> rough and unfinished. But I hoped that it would one day be
> sufficient to replace
> first my phone, then my Palm Tungsten C and maybe my
> Etrex-GPS. It does neither
> in a satisfactory way.
>
>
> You're spreading a lot of misinformation. Since you might
> influence someone's decision about buying the FR, I'll address
> those points with which I completely disagree (about the rest I
> could argue). 
>  
>
>
> I used it for about year now, installed this and that distro
> and during that
> time I defended all the shortcomings as being a
> work-in-progress and a
> community effort. But all in all I cannot recommend it to
> anyone as a daily
> phone. Here's why:
>
> - The device wakes up too slowly, I lost some calls.
>
>
> The wake up time is about 2 to 2.5 seconds. Usually small enough
> for picking up the call quickly.
>  
>
>
> - The vibrator is too weak, I missed more calls.
> - The volume is way to low, You can really only use it indoors.
>
>
> Depends on a particular mixer setting. I could get one that's good
> enough for me (found a link on the wiki)
>  
>
>
> - The Display is too dark for sunny days, even in the shade.
> - I lost many SMS. I eventually receiced most of them after
> restarting the
> device
> - The battery lasts only a few hours, again, I lost many calls
> (this depends
> on the distro. But even with a »good« one, I had cases in
> which the device did
> not suspend due to something crashing)
>
>
> With most distros you get ~48h of suspend time with the GSM
> running. Whether the distro you choose crashes a lot or not
> depends on your luck and ability to chose the right

Re: [shr-testing] kernel with working g_ether to Windoze connection?

[Vasco Nevoa]

Paul Fertser escreveu:
> Vasco Névoa  writes:
>   
>> - GPRS stalls and doesn't allow opkg update, so forget upgrade
>> 
> Well, probably it'll be solved with the new abyss muxer.
>
>   
That's good to know.
>> SO GIMME THE WORKIN KERNEL ALREADY!!!  :D
>> 
>
> Why don't you just specify which kernel revision works and which
> doesn't? How any kernel dev is supposed to solve your problems if you
> even don't properly describe it? Why don't you use the kernel that
> worked on your FR in the meantime?
>
>   
If I knew, I wouldn't have a problem, would I? :)

When I saw the usb and GPRS problems were gone, I assumed they wouldn't 
come back, at least so soon. So there was no reason to make note of 
which kernel I had. It is not common to lose a patch immediately after 
it is integrated... Apparently I was obviously wrong.
I'm not here to make anyone angry, I just posed a simple question: does 
anyone know which versions work?

Thanks for the attention.



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

Re: [SHR] 4-16 shr-testing is pretty good!

[Vasco Nevoa]

I second that emotion! :) It is by far the best distro ever tested on my 
Neo.
Not only that, but they also got rid of a few nasty bugs: the GPRS link 
(now included out-of-the-box) no longer stalls, the USB networking with 
Windows boxes is restored, and the "messages" and "dialer" apps no 
longer crash randomly. And Raster's keyboard finally works the way it 
should (fast and clean). Very nice indeed.
Kudos to everyone, not just the SHR team for a great integration effort, 
but also to the kernel and application teams.

bburde...@comcast.net escreveu:
> I don't usually see an announcement on the community list when a new 
> SHR-testing is available, so here's my own.  The SHR team deserves some 
> kudos for a great job.
>
> Just reflashed my OM with the new shr-testing (4-16 version)
>
> 1 - GUI is much more responsive!
> 2 - Settings are restructured, better I think. See #1.  A lot of work
> has gone into the settings changes it seems.  I like the profile editor.
> 3 - new battery power indicator is cool.
> 4 - wifi works again for me with mofi (at home, with WPA).
>
> Its a worthy upgrade.  SHR-testing is very usable now, just a few things
> would really push it over the edge for me:
>
> - mofi can't connect me to any open wifi networks.
> - no volume control for earpiece volume.
> - no datetime for SMS messages.
>
>  From what I understand echo cancellation is in this version of SHR, so
> increasing earpiece volume should be echo free (using config files), I
> haven't tried that yet though.
>
> Ben B.
>
>
>
>
> ___
> 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

[OM2008.9][GTA02] a simple and quick GPS logger v0.1

[vasco . nevoa]

I wanted something simple, reliable, and fast to load and stop.
So I cooked up a couple of shell scripts and desktop shortcuts to  
allow me to just press a button and get the Neo to log the GPS track  
on a file.
The scripts take care of turning on the GPS receiver, avoiding  
suspension during logging, and putting the data in the right place.
Enjoy, cut up, mash up, and otherwise use at will. :)

Requirements: gpspipe (opkg install gps-utils)

*** Desktop file to turn on (/usr/share/applications/GpsLogOn.desktop):
[Desktop Entry]
Name=LogGps:1
Comment=Start GPS logging
Encoding=UTF-8
Version=1.0
Type=Application
Exec=/home/root/myScripts/log_gps_track.sh
Icon=fixme
Terminal=true
SingleInstance=true
StartupNotify=false

*** Turn-on script (~myScripts/log_gps_track.sh):
#!/bin/sh
. $HOME/myScripts/om_suspend_functions.sh
dir=$HOME/myData/Gps
name=`date +Log_%y%m%d_%H%M%S.nmea`
gps_power=/sys/devices/platform/s3c2440-i2c/i2c-adapter/i2c-0/0-0073/neo1973-pm-gps.0/pwron
# wake up GPS hardware:
echo 1 > $gps_power
# tell ompower to keep from suspending while logging:
request_power_state $name "keep_on"
# automatically allow suspending after exit (no need for switching off  
GPS, suspend does that):
cleanup() { echo "Stopped logging!"; sync; request_power_state $name  
"may_off"; exit 0; }
trap cleanup KILL
trap cleanup INT
trap cleanup EXIT
# start logging to file:
echo Logging into $name
gpspipe -r > $dir/$name
# end.

*** Helper function library for power management  
(~myScripts/om_suspend_functions.sh):
#!/bin/sh
request_power_state() {
requester=$1
state=$2
if [ $state == "keep_on" ]; then
  echo "$requester is preventing OM from sleeping."
  dbus-send --system --dest=org.openmoko.Power /  
org.openmoko.Power.Core.RequestResourceState string:cpu  
string:$requester string:on
elif [ $state == "may_off" ]; then
  echo "$requester is allowing OM to sleep."
  dbus-send --system --dest=org.openmoko.Power /  
org.openmoko.Power.Core.RemoveRequestedResourceState string:cpu  
string:$requester
elif [ $state == "go_off" ]; then
  echo "$requester is forcing OM to sleep."
  dbus-send --system --dest=org.openmoko.Power /  
org.openmoko.Power.Core.RequestResourceState string:cpu  
string:$requester string:off
else
  echo "Unknown power state requested ('$name', '$state'). Pick  
'keep_on', 'may_off', or 'go_off'."
fi
}

*** Desktop file to turn off:
[Desktop Entry]
Name=LogGps:0
Comment=Stop GPS logging
Encoding=UTF-8
Version=1.0
Type=Application
Exec=killall gpspipe
Icon=fixme
Terminal=true
SingleInstance=true
StartupNotify=false



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

Re: The Lost Openmoko Community

[vasco . nevoa]

To all, but especially OM.
I felt a little cheated when I saw the FR I had bought was not ready  
to be used as a daily phone. This had in fact been the publicity by OM  
at the time - GTA01 was for tinkerers, and GTA02 was for the public.  
Then people said "no, it was clear that GTA02 was also for tinkerers  
only"... well, whatever; I decided to ignore that, be positive, and  
contribute with bug reports while waiting for a decent basic distro  
that would control the device as expected and serve as a development  
platform.
But just like the others, I don't know what OM (the company) is doing.  
I know it is keeping FSO on track, which was always the real objective  
of OM (the project) and this is a Good Thing. But I don't understand  
why there are so many distros, and none of them works as a solid basic  
system.
OM (the company) should have only sold the GTA02 when the hardware and  
kernel and drivers where tested and ready. Or, if that was not  
possible due to time-to-market constraints, then it should have called  
for the community's help for doing just that: getting the device to  
work. Instead, it went ahead telling us "the Neo is a blank slate, a  
canvas to paint on"... and the people who have painted, have lost many  
of their paintings, and even the will to paint. At least, they won't  
paint with OM brushes. It is too frustrating and time-consuming.
Enough ranting.
Personally, I need a working device. Kernel, drivers, daemons, system  
scripts, all of this must be in place to allow the device's hardware  
to be controlled at the flick of a software switch. GPRS+GSM muxing  
must be included by default. WIFI must work correctly by default.  
Bluetooth must work as well as in any other distro by default. And for  
god's sake, AUDIO must work as intended by default (it IS a phone  
after all). Only after OM guarantees these minimum requirements can it  
ask the community to go ahead and innovate...  Don't waste your time  
on GUIs or eye-candy apps; give us a device with a rock solid  
subsystem and a command shell, and we will fill in the blanks and  
build from there.

Vasco.

Citando Michele Renda <[EMAIL PROTECTED]>:

> Risto H. Kurppa wrote:
>>
>> Other community members:
>>
>> * How do you feel about the current situation? How happy are you
>> with the community?
>> * Do you feel well informed? Do you know what's the direction
>> we're heading to?
>> * How would you like to contribute?
>
>
> Hello Risto
>
> Thank you for your post. I think you wrote something that a lot of
> person think.
>
> I can only add my personal point of view:
> I don't know what Openmoko is working for, for me their work is a dbus
> interface. It seem to be a very good work!
>
> For the rest I don't use 200*.* I am using Debian and I am happy with
> it. I use the programs from Debian and I am trying to supply what still
> not exist.
>
> According me we must to try to develop the missiong application for
> 200*.* to make it usable. I tryed and I saw that is not too much
> complicated, there are very usefull dbus interface.
>
> So... In the end, I don't considerate myself unrespected. There is only
> a lot of work to do, and who can must to try to help on the accessory
> part that trasform a normal phone, in a super phone.
>
> Best regards
> Michele Renda
>
> ___
> 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: Debian size and uSD

[vasco . nevoa]

I usually do "cp -ax ..." with success. I've cloned entire operating  
systems like this in the past without problems. Haven't tried with OM  
yet, but it worked with a couple of Ubuntu installations. Takes a long  
time, though... ;)
Obviously, you preferably do it with the filesystem offline... booting  
from somewhere else.

Citando arne anka <[EMAIL PROTECTED]>:

>> Another thing is I bought a 2G uSD and I want to move my debian system to
>> that card. If I manually partition it (8MB fat and rest ext2) and just
>> copy
>> contents of 512M, would it work? Or maybe i can copy an image using dd
>> and
>> then somehow resize the partition. Anyone tried migrating from one SD to
>> another?
>
> do not use plain cp -- it will most likely result in some corruption of
> special files.
> your best bet would be either tar or rsync, depending of your usecase.
>
> for rsync (and tar on-the-fly) you could copy the partitions with dd,
> mount the images with loop and transfer your data.
>
> ___
> 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: [2008.9] Wifi very unreliable

[vasco . nevoa]

Okay, I've filed bug #2043 about this. Go ahead and add info if you like.
https://docs.openmoko.org/trac/ticket/2043


Citando Daniel Hedblom <[EMAIL PROTECTED]>:

> Im also inclined to think its a hardware/driver problem and have
> nothing to do with wpa_supplicant or any other highlevel stuff. I
> fully understand if higher stuff is left to the community but i did
> expect the kernel and low level stuff to work a bit better than now
> when i bought the phone. It could ofcourse be just some phones thats
> broken and most works well because of some faulty batch.
>
> Does anyone know if work is happening on the kernel side of wifi or is
> it an orphan right now needing more people?
>
> //danielh
>
> 2008/9/30  <[EMAIL PROTECTED]>:
>> Hi all.
>> Now that you mention this, I think the problem is Hardware based.
>> I've bought an Asus Eee 901 :D, and now I have a means of comparison
>> in terms of WiFi reception.
>> My conclusion is that the Neo FR's wifi sucks.
>> Example1:
>> - my home AP has WPA; sitting 2 meters away from it, the FR show 50%
>> signal strength. Okay, you can say that's too close and they are
>> "shouting" at each other, causing signal corruption. Very well, I take
>> it 10 meters away, behind a couple of normal walls. The signal
>> strength drops all the way, right down to 5%, which is pretty
>> unusable. The Eee901 has 100% signal strength in the vicinity of the
>> AP, and behind those walls shows 30%.
>> Example2:
>> - at work, the Eee901 picks up 4 weak networks, the strongest one at
>> 35% strength and joins (no security) without problems. The FR picks up
>> only the stronger one at 8%, and it cannot join it.
>>
>> This has convinced me that either the wifi on the FR has serious
>> hardware problems, or the software is misguiding it. Anyway, it needs
>> serious attention.
>> Has anyone filed bugs on this wifi problem?
>>
>> Vasco.
>>
>> Citando Xavier Bestel <[EMAIL PROTECTED]>:
>>
>>> On Tue, 2008-09-30 at 11:06 +0200, Matthias Apitz wrote:
 Hello,

 I'm using the Wifi-method described in

 http://wiki.openmoko.org/wiki/Neo_FreeRunner_Wifi#Using_WPA_and_.2Fetc.2Fnetwork.2Finterfaces

 i.e. having a working config file /etc/wpa_supplicant/wpa_supplicant.conf
 for all my known access points (which is just a copy of that I'm using
 daily and stable in my two FreeBSD based laptops); and I'm trying to bring
 up the eth0 with

 # ifup eth0

 this works very unreliable; in (let's say) 8 of 10 cases it can't
 associate to the AP, even not after fresh re-boots and independently if
 the AP at my home works with WEP or in my office with WPA;
>>>
>>> I found that, for WEP networking, the only working way is to manually
>>> configure the interface:
>>> iwconfig eth0 key 
>>> iwconfig eth0 essid 
>>> udhcpc eth0
>>>
>>> And even then, it's not guaranteed to work, or if it works, it won't for
>>> long.
>>>
>>> HTH,
>>>   Xav
>>>
>>>
>>>
>>> ___
>>> Openmoko community mailing list
>>> community@lists.openmoko.org
>>> http://lists.openmoko.org/mailman/listinfo/community
>>>
>>
>>
>> ___
>> Openmoko community mailing list
>> community@lists.openmoko.org
>> http://lists.openmoko.org/mailman/listinfo/community
>>
>
> ___
> Openmoko community mailing list
> community@lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community
>


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

Re: [2008.9] Wifi very unreliable

[vasco . nevoa]

Hi all.
Now that you mention this, I think the problem is Hardware based.
I've bought an Asus Eee 901 :D, and now I have a means of comparison  
in terms of WiFi reception.
My conclusion is that the Neo FR's wifi sucks.
Example1:
- my home AP has WPA; sitting 2 meters away from it, the FR show 50%  
signal strength. Okay, you can say that's too close and they are  
"shouting" at each other, causing signal corruption. Very well, I take  
it 10 meters away, behind a couple of normal walls. The signal  
strength drops all the way, right down to 5%, which is pretty  
unusable. The Eee901 has 100% signal strength in the vicinity of the  
AP, and behind those walls shows 30%.
Example2:
- at work, the Eee901 picks up 4 weak networks, the strongest one at  
35% strength and joins (no security) without problems. The FR picks up  
only the stronger one at 8%, and it cannot join it.

This has convinced me that either the wifi on the FR has serious  
hardware problems, or the software is misguiding it. Anyway, it needs  
serious attention.
Has anyone filed bugs on this wifi problem?

Vasco.

Citando Xavier Bestel <[EMAIL PROTECTED]>:

> On Tue, 2008-09-30 at 11:06 +0200, Matthias Apitz wrote:
>> Hello,
>>
>> I'm using the Wifi-method described in
>>
>> http://wiki.openmoko.org/wiki/Neo_FreeRunner_Wifi#Using_WPA_and_.2Fetc.2Fnetwork.2Finterfaces
>>
>> i.e. having a working config file /etc/wpa_supplicant/wpa_supplicant.conf
>> for all my known access points (which is just a copy of that I'm using
>> daily and stable in my two FreeBSD based laptops); and I'm trying to bring
>> up the eth0 with
>>
>> # ifup eth0
>>
>> this works very unreliable; in (let's say) 8 of 10 cases it can't
>> associate to the AP, even not after fresh re-boots and independently if
>> the AP at my home works with WEP or in my office with WPA;
>
> I found that, for WEP networking, the only working way is to manually
> configure the interface:
> iwconfig eth0 key 
> iwconfig eth0 essid 
> udhcpc eth0
>
> And even then, it's not guaranteed to work, or if it works, it won't for
> long.
>
> HTH,
>   Xav
>
>
>
> ___
> 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: [2008.9] What, no updates?...

[vasco . nevoa]

Okay, okay, I get the hint... ;)
I'm switching to "testing" now.
I gave up on it a couple of weeks ago because it was very unstable,  
but since you say it rocks... :)

Citando Sarton O'Brien <[EMAIL PROTECTED]>:

> On Friday 26 September 2008 00:50:14 [EMAIL PROTECTED] wrote:
>> Hi.
>> It's been a long time since the last real update of packages for the
>> 2008.x feeds.
>> Everyday I do opkg update and opkg upgrade and all that comes down is
>> the angstrom version file.
>> Since there are still a lot of bugs to solve, I find this strange...
>> What's happening?... why aren't there any updates?
>> Is OM working on something else entirely, or taking a vacation? :)
>
> I get the impression updates are staged fairly well for stable. I use testing
> (and it runs fantatsic at the moment, can use as a daily phone) and updates
> are pushed pretty much every day.
>
> I guess it comes down to your avenue of participation :)
>
> Sarton
>
> ___
> 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: 2008.8 default dialer crash on # or *

[vasco . nevoa]

Very nice patch, Treviño. :)
Standards-compliance can be a little hairy sometimes.
I can see why a responsible, otherwise-occupied person would take a  
little while to publish. ;)
Thanks, and happy hacking!

Citando "Marco Trevisan (Treviño)" <[EMAIL PROTECTED]>:

> Vasco Névoa wrote:
>> Treviño, can you please attach whatever patch you have for this on the
>> Trac ticket (#1832, I think)?
>> There are at least 3 tickets open with relation to this problem, and
>> Holger is asking where is the patch... please put it up, even if it is
>> not finished. I'm sure he will know what to do. :)
>
> Done in #2038 [1]! Due to the UCS2 codec usage added in the past days I
> had to add a workaround, but in all my tests the code works as expected.
> So, now I'm just waiting for your improvements ;).
>
> Bye!
>
>
> [1] https://docs.openmoko.org/trac/ticket/2038
>
> --
> Treviño's World - Life and Linux
> http://www.3v1n0.net/
>
>
> ___
> 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

[2008.9] What, no updates?...

[vasco . nevoa]

Hi.
It's been a long time since the last real update of packages for the  
2008.x feeds.
Everyday I do opkg update and opkg upgrade and all that comes down is  
the angstrom version file.
Since there are still a lot of bugs to solve, I find this strange...
What's happening?... why aren't there any updates?
Is OM working on something else entirely, or taking a vacation? :)
Cheers,
Vasco.

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

Re: [2008.09] resolv.conf

[vasco . nevoa]

If resolvconf isn't doing what it should, then it is our  
responsibility as users to file enough bugs with enough pertinent info  
until it is corrected.
If you have a clear use case that fails, open a ticket.
I don't care which kind of connection management system is inside  
openmoko, as long as it works and is flexible to accommodate any  
networking scenario we may come up with (which pretty much narrows it  
down to resolvconf IMHO).
Let's make it work, ok? File the necessary bugs.

Citando [EMAIL PROTECTED]:
> OK, so this resolvconf thing is inherited from debian and has been
> implented obviously without much thought to general functionality. I say
> this in the context of normal (non-debian) services functioning as
> expected when not massaged by resolvconf.
>
> I understand the intention, don't get me wrong, and it is indeed a nice
> idea. But when all people want to do is gain connectivity with their
> chosen method, this resolvconf facility seems to be more of a hinderence
> and is unlike a lot of linux distros. Shouldn't this, at least
> currently, be optional?
>
> If something as fundamental as _core_ network services are going to be
> overlayed with something like this, it should really be working first,
> rather thaan people editing files left and right without understanding why.
>
> This is just what I think, take it as you will. In the end I am the
> master of my device ;)
>
> I've actually just done a bit of research before posting and it
> _appears_ this was implemented with good intention, just without the
> required software support. It seems to be very much of debian origins
> and a little bit of overkill for managing the facilities on the
> freerunner, but that's just my opinion. If I was currently using usb0,
> eth0 and a tun/tap interface simultaneously, that all flapped or had
> dynamic dns requirments (sounds more like a router) it would make sense
> to me. I imagine the end goal is to consolidate gprs and wifi dns but
> currently no resolvconf is going to teach people how to get that going.
>
> When om2008 is mature and these kind of connections can be made easily,
> without much knowledge, this utility would be a godsend ... as it stands
> you currently need basic linux knowledge to understand why things don't
> work and then you need to know how to manipulate resolvconf.
>
> Maybe it's my BSD upbringing, thanks for the clarification however. :)
>
> Sarton
>
> ___
> 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: FR as a USB-Key

[vasco . nevoa]

I'm using the "stable" OM2008.9, and so I can't even do "rmmod  
g_ether", because it is built-in. (or maybe it's "cdc_ether", but the  
problem is the same) .
So there is no chance for me. :(
I guess you have to use a custom kernel, or perhaps an FSO or Testing image...

Citando Christian Adams <[EMAIL PROTECTED]>:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> .. and when you are able to 'rmmod g_file_storage' i would be glad if
> you tell how you did ..
>
> Am 24.09.2008 um 17:03 schrieb [EMAIL PROTECTED]:
>
>>
>> The module "g_file_storage" is only available in the testing
>> repositories...
>>
>>
>> Citando martin <[EMAIL PROTECTED]>:
>>
>>> Thanks, it seems pretty strait forward. I will try this.
>>>
>>> 2008/9/24 <[EMAIL PROTECTED]>
>>> > Hi,
>>> >
>>> >   is it possible to make the FreeRunner act like a regular media
>>> storage
>>> > device ? The inherent question is how to specify which file or
>>> partition
>>> > would be mapped to this simulated device.
>>> I thought that no, but it seems the opposite:
>>>
>>> http://wiki.openmoko.org/wiki/Using_the_Neo_as_a_Mass_storage_device
>>>
>>> (there you find also how to configure the partition.
>>>
>>>
>>> ___
>>> 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
>
> - --
> - -BEGIN CONTACT BLOCK-
>eMail: [EMAIL PROTECTED]
>Jabber:[EMAIL PROTECTED]
> - --END CONTACT BLOCK--
>
> - -BEGIN GEEK CODE BLOCK-
> Version: 3.1
> GCS$/IT;d-;s:;a?;C++(+++)>;UL;P++(+++)>;
> L++(+++);E---;W++;N(+);o?;K?;!w;!O;!M+>;!V;PS(+);PE;
> Y+;PGP++;t+(++);5(+)>++;X(+);R*;tv->+;b++(+++);DI++;
> D++(+++)>;G(+)>++;e+>+++;h-()>++;r++;y++;
> - --END GEEK CODE BLOCK--
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.7 (Darwin)
>
> iD8DBQFI2mEkr81gVylJyzERAtv5AKCGZGp0FkLZHjkQGosn7MscM94OjQCglSFu
> sr7bYYr/I0EwkRLnmZBap5A=
> =GAOT
> -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: [2008.09] resolv.conf

[vasco . nevoa]

Nothing should be in there by default!!!
In openmoko, the file /etc/resolv.conf is managed dynamically by the  
program "resolvconf".
Editing it by hand is a hack (that must only be used when the DHCP  
server does not provide a nameserver IP, or when the interface is  
configured by hand).
See http://lists.debian.org/debian-devel/2003/07/msg00438.html

Citando Matthias Apitz <[EMAIL PROTECTED]>:
> El día Wednesday, September 24, 2008 a las 03:58:01PM +0100, Arigead  
> escribió:
>> Is /etc/resolv.conf still an issue with 2008.09?
>>
> what should be there per default?
>

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

Re: FR as a USB-Key

[vasco . nevoa]

The module "g_file_storage" is only available in the testing repositories...

Citando martin <[EMAIL PROTECTED]>: 

> Thanks, it seems pretty strait forward. I will try this.
> 
> 2008/9/24  <[EMAIL PROTECTED]>
>  > Hi,
> >
> >   is it possible to make the FreeRunner act like a regular media storage
> > device ? The inherent question is how to specify which file or partition
> > would be mapped to this simulated device.
>  I thought that no, but it seems the opposite:
> 
> http://wiki.openmoko.org/wiki/Using_the_Neo_as_a_Mass_storage_device
> 
> (there you find also how to configure the partition.
> 
> 
> ___
> Openmoko community mailing list
> [EMAIL PROTECTED]
> http://lists.openmoko.org/mailman/listinfo/community

  

Ligações:
-
[1] mailto:[EMAIL PROTECTED]
[2] mailto:community@lists.openmoko.org___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: [Om2008.9] low audio for called party (i.e. low capture)

[vasco . nevoa]

You can use Angus's software to do that. Look for a link in the wiki  
page Andreas is talking about.

Citando Andreas Fischer <[EMAIL PROTECTED]>:

> Hi Matthias,
>
> You have to change the preconfigured values in
> /usr/share/openmoko/scenarios/gsmhandset.state - see the mail sent
> earlier today by vasco.nevoa  ("[ALSA] wiki RFC")
>
> Regards,
> Andreas Fischer
>
> Matthias Apitz wrote:
>> Hello,
>>
>> All the parties I'm calling complain about very low audio signal from my
>> Openmoko; this was already before the today update to Om2008.9. I can
>> all hear well, maybe to laud, but it is OK; I've played around with
>> changing the settings with 'alsamixer' to higher the capture values, but
>> when the call gets established the values are pulled down to some
>> defaults; where could I change this?
>>
>> thx
>>
>>  matthias
>
>
> ___
> 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

[ALSA] wiki RFC

[vasco . nevoa]

Hi.

To anyone who actually knows the dark magic of ALSA state files and  
the way they are actually being used in the Freerunner, please go read  
the wiki page and let me know if it has anything wrong, and if it  
should have anything else.

http://wiki.openmoko.org/wiki/Neo_Freerunner_audio_subsystem

Thank you!

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

Re: New rotate for OpenMoko

[vasco . nevoa]

If you install it via the *.ipk package on the wiki page, you'll get  
an init script to launch the daemon. Then copy the latest binary  
version over the one installed by the package (it is much older).
 From there, all you have to do is to configure the daemon to launch  
at the chosen runlevel (can't remember the specific commands, sorry!).

Citando Robin Paulson <[EMAIL PROTECTED]>:
> could someone provide some hints for how to set this to autostart,
> either system-wide or for a specific user?
>
> for a specific user, would i place a link to it in ~/.xinitrc?
>
> cheers
>


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

Re: Startup/Xstart image replacement (How to remove the boots?!)

[vasco . nevoa]

Wasn't that info already in http://wiki.openmoko.org/wiki/Splash_screen ?

Citando Minh Ha Duong <[EMAIL PROTECTED]>:

> Le mardi 16 septembre 2008, [EMAIL PROTECTED] a écrit :
>>   That is the u-boot splash image that is on its own partition, not
>> the kernel's bootsplash or x-start-splash.
>
> True enough. I tried to clarify this on the wiki at:
> http://wiki.openmoko.org/wiki/Themes
>
> --
> Minh HA DUONG, Chargé de Recherche, CNRS
> CIRED, Centre International de Recherches sur l'Environnement et le
> Développement
> http://minh.haduong.com
>
> ___
> 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

Exciting Experience

[vasco . nevoa]

Well, as long as others are keen to share their positiveness, I  
thought I'd chime in as well. :P

The sudden death of my previous smartphone kicked me into using the  
freerunner everyday as main (and single) phone.
And I'm glad to say it has done a proper job for over a month, even  
though I flashed it every 2 or 3 days. :)
I have lost a few calls because of software issues, but these were  
exceptions (pun intended).

I tried the first 4 distros (OM2007.2, ASU, FSO, Qtopia) as soon as I  
got the phone (simultaneously in multiboot from the sd-card), and  
after a day I had thrown away Qtopia because it was too polished and  
not flexible enough (from an experimental point of view). :)
Then OM2007.2 got axed, so it went away too. But I couldn't yet wrap  
my mind around FSO's objectives, and I needed a working phone with a  
few extras, so FSO got the axe too. This left me with ASU (now  
officially OM2008.8), which I proceeded to torture almost daily with  
all the opkg feeds (including "testing") I could get my hands on. When  
OM reorganized the repositories, this caused a lot of confusion for  
me, but now I know what to expect from where.
I finally settled with the standard OM2008.8-update because it is the  
right balance between "stable" (as in "I won't lose calls and SMSs")  
and "experimental" (as in "I can try/develop all kinds of  
python-powered stuff and play with the geeky HW peripherals too").

The GPS works well (usually around 40 seconds to get a fix if the  
signal is any good - I did the capacitor hack as soon as I could,  
which was an interesting labor hour where I lost 3 capacitors because  
they are so damn small :S ).
The GSM is also ok, although I got once a couple of complaints of bad  
audio quality - this is now gone, it was probably a bad SW image.
SMS is also no problem.
The accelerometers have been fun to play with (duke3d, gestures,  
accelGame) and make for good "showing off" of openmoko.
Wifi mostly works - some APs better than others.
Bluetooth is a pain in the ass to configure and use. It is highly  
user-unfriendly, but if you persist, you can do anything (except GSM  
headset... has anyone got it working yet?). Heck, I don't use it  
anyway. ;)
Which brings me down to audio: the routing of this baby is pretty  
complex stuff (as is common in most embedded devices), so it's only  
natural that the more advanced functions are still a mystery. And you  
know what? the fact that there still isn't a GUI way to control the  
sound volume hasn't been a problem so far!!! I find that the  
mechanical design of the Neos is quite above average, and this shows  
off in the audio capabilities -  when the volume is cranked up to  
100%, the case does not resonate and there is no noticeable  
distortion. Very good mechanical and electrical design.

My only real complaint is power management. It just doesn't seem to  
stabilize. For each fs image I flash or opkg upgrade I do, a new  
non-intended behavior happens. But I do understand that, like audio,  
it is one of the most complex things to implement right - balancing  
the intricacies of each chip's power modes (and their spec violations)  
with the kernel's modeling as well as the X-server's old ways - it can  
be very challenging. So OK, I don't get mad if sometimes I have to  
call my Neo from another phone to get it to wake up so I can SSH into  
it. I have confidence in the OM team's competence and in the  
Community's effort and contributions. All we need is a little more  
time and care and everything will be fine.

Overall, it has been a good ride, and it is getting better by the  
week, especially now that FSO efforts are finally starting to get  
momentum - and I think all that D-BUS goodness will start to pay back  
very soon. I can't wait to see the framework integrated into the main  
distro (or vice-versa) - this will make its usefulness and interest  
explode! :D
But it looks like there are at least a few people out there who have  
other plans for it - not just HSR, but efforts like FDOM - and it is  
also exciting to see new distros/remixes pop up.

It is a brave new world we are creating - a big thank you to Sean  
Moss-Pultz for having the courage to push the dream into reality. You  
are the Mark Shuttleworth of the mobile world, and OM is on the  
fast-track to becoming it's Ubuntu (or more rigorously, it's Debian!).  
;)

Vasco Névoa

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

[qtopia][daily/testing] speed dial and addressbook keyboard

[vasco . nevoa]

I have 2 feature requests, as they seem to have been removed from om's qtopia:
1 - addressbook contacts list should have keyboard support. scrolling  
up and down to find a contact is time-consuming and user-unfriendly  
(especially when there is no graphic acceleration).
2 - addressbook contacts should be allowed to be added to speed  
dialing list. without this, we have to go into the contacts list or  
call register, which is also not user-friendly.

I'm posting them here for discussion; if nobody has anything against  
it, I'll create a ticket for it in a couple of days.

My SW is:
http://downloads.openmoko.org/daily/testing-om-gta02-20080906.rootfs.jffs2

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

Re: WLAN with WPA

[vasco . nevoa]

Citando Katrin Tomanek <[EMAIL PROTECTED]>:

>
> Hi,
>
> I finally managed to connect my FR via Wifi and WPA2.
>
> The following happened: after I started this thread 2 days ago, my FR (after
> rebooting) wouldn't let me connect via ssh (usb) any more -- I guess this
> was the result of extensive opkg upgrades, something must have gone wrong
> with the sshd. At least this is what I assume. Unfortunately, as also the
> keyboard somehow got lost during the upgrade session, the only thing I could
> do was flash my FR.
>
> So I took the latest OM image as of sept, 4th  (kernel as of sept, 3rd).
>
> I then used the following extremely simple wpa_supplicant.conf:
>
> --- snip ---
>
> ctrl_interface=/var/run/wpa_supplicant
> eapol_version=1
> ap_scan=1
>
> network={
> ssid="rutabaga"
> scan_ssid=1
> proto=RSN
> key_mgmt=WPA-PSK
> psk=d4a9459bf5f29c332fa56d5b2c6a8c80176f4da7647f42e2ae4309dbed4f80ec
> }
>
> -- snap ---
>
> After that, all I did was:
> wpa_supplicant -i usb0 -c /etc/wpa_supplicant/wpa_supplicant.conf -B
> and then
> udhcpc usb0
>
> That's it -- wifi works! Great.

You probably mean eth0 instead of usb0, right?

>
> I cannot say whether this is now because of the new image (when I tried
> before I had the original 2008.08 image of august), or because of the fact
> that I am running WPA2 whereas the day before yesterday I tried WPA.
>
> cheers,
> Katrin
>
> --
> View this message in context:  
> http://n2.nabble.com/WLAN-with-WPA-tp852256p1016251.html
> Sent from the Openmoko Community mailing list archive at Nabble.com.
>
>
> ___
> 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

[2008.8][testing][kernel] image and modules not in sync?

[vasco . nevoa]

I've followed the discussion about dual booting, kernel packaging, and  
kernel vs. distros, and the conclusion I reach is that the devs are  
inclined to use (mostly-)monolithic kernels, leaving just the "extras"  
out in the sysfs "modules" dir.
This is fine by me, but there seems to be a little mess here.
There are modules in the file system that are not loadable because  
they are already built in.
This is not a good thing, because it induces the user in error - I  
thought there was something wrong with the kernel or with the modules,  
when the problem is just a question of cleaning up the repository &  
filesystem images.
If the modules are built-in, they should not be present in the  
filesystem, IMHO.
If a user follows the wiki howtos about networking, she may be trying  
to modprobe bnep for example, and scratching her head because  
"bluetooth" and "l2cap" won't load (let alone "bnep"). Only after  
grepping /proc/kallsyms I understood these modules where already  
built-in. duh! total time loss.
So please clean up a little, ok? At least the fs images on the  
downloads server should be consistent with the given kernel. If an  
update breaks things, that another issue entirely.
Thank you! Keep up the good work.

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

Re: Please split this list!

[vasco . nevoa]

I agree that a single list is more conducive to synergies.
Unfortunately, the traffic has grown a lot, and it is virtualy impossible to 
filter on the client side (except by threading), because you cannot make up any 
resilient criteria. You can't build a filter without consistently classifying 
the messages, can you?
So yes, the ideal solution would be that everybody tags their messages with 
relevant keywords in the subject line.
Anyone has a suggestion for a list of good keywords, something we can start 
from (non-authoritative)? perhaps even a simple semantics?

Citando Nishit Dave <[EMAIL PROTECTED]>: 

> On Mon, Sep 1, 2008 at 7:42 PM, Tilman Baumann <[EMAIL PROTECTED]> wrote:
>  Thorben Krueger wrote:
> > Please consider splitting this mailinglist into sublists, i.e. each
> > handling its own distribution...
>  Does not help. More choice does not bring more order.
> 
> Especially if there is no system for order that reflects the need for
> communication. Subsystems are no system for bringing order, because you
> can not always bring your thoughts into this order.
> It's stupid, it is frustrating and borders and limitations are plainly
> not conducive to conversations.
> 
> 

 Ask people to write the subject lines more clearly, not "FR Problem" "cannot 
make a call" "where's the installer thingy" etc.

If they don't comply, harangue them so they fall in line or leave.

Oops. 

Ligações:
-
[1] mailto:[EMAIL PROTECTED]___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Please split this list!

[vasco . nevoa]

I second that idea.
Mainly because it is difficult to understand which context people are  
talking in... most people don't remember to say which distro they are  
using, and frankly I don't think they should have to...
And it does make a big difference.
Maybe keep this list as a distro-neutral list, and add new ones for  
OM2008.8, FSO, Debian, etc..?

Citando Thorben Krueger <[EMAIL PROTECTED]>:

> Please consider splitting this mailinglist into sublists, i.e. each
> handling its own distribution...
>
> All the best,
> Thorben
>
> PS: Yes I know how to handle filtering on the client side.
>
> ___
> 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: Pulsters outstanding orders

[vasco . nevoa]

I'm happy to anounce that the Portuguese group buy from Pulster has  
been correctly satisfied. We got the mega-package yesterday.
Now I'm waiting for the group leader to break it up and give us our  
phones. We'll make a mini-party, I'm sure.
Vasco.

Citando [EMAIL PROTECTED]:

> Hi all.
>
> I've also been anxiously waiting here in Lisbon for my FR to arrive
> from Pulster together with a 10+ group from Portugal and another 10+
> group from Spain. And of course, Pulster is delayed. Worse yet,
> they've just told us they probably switched the Spanish and Portuguese
> orders by mistake. 8)
>
> Now, Pulster himself has been satisfyingly accessible and honest with
> us (he even told us to refuse the packages and he would reship them
> correctly on his own cost), so we are going to cut him some slack (we
> will accept the packages and sort out the mess by ourselves); I
> believe, like David just so eloquently said, that the people at
> Pulster are working in overdrive to satisfy an overwhelming amount of
> orders for this phone, and I think the problem extends to all the
> other distributors and even the openmoko factory.
> It is a bit their fault, of course, for having created such high
> expectations for so long, in a synchronized release. But it couldn't
> be done any other way.
>
> So please, guys, take it easy. We'll all get our phones.
> We've waited over a year for this, we can wait a few more days/weeks.
> After all, there is no other phone like this in the whole history of
> mankind.  :)
> Keep in mind that getting the phone in our hands is not the goal; it
> is just the beginning of the revolution!
>
> Vasco.
>
> Citando David Samblas <[EMAIL PROTECTED]>:
>
>> Nicolas,
>> I can understad your anxious, and the nerves of the unknown status of
>> your desired order. But you must understand than Pulster has make an
>> great effort to mantain the Neo as affordable as posible, this has
>> translated to an overheading amount of  enstusiast impatience
>> mail-vervose geeks that in solitare or in numerous groups has decided to
>> buy to him(me included), I don't know the number of items had sell
>> before the "Neo madness" but I'm only a coordinator of a group and some
>> times it's hard to follow track about my 18 neo future(barely present)
>> owners, so cmagine hundreds of them (I can imagine Chris as Jim Carey in
>> this scence where he is God's sustitute and decide to drive all  plege
>> via mail.. It's  scary, isn't it?). We all are noobs, Openmoko
>> delivering from factory, Distributors estimating sales and shipping
>> resources, we as costumers are also noob becouse this kind of open
>> distribution chain has no precedent in a comercial product. So all of
>> you, waiting a neo from Pulster or  from any distributor , please have a
>> little empathy with your provider, an consider this fisrsts bacthes
>> deliveries as beta, they will surelly have bugs but you must be
>> confident that you neo will arrive, and in the near future the situation
>> will be more regular and soft. And as Pulster said you have all the
>> right to put on his nerves asking for the status of you Neo, but take in
>> account that any mail/phonecall you send is a little more weigth in the
>> load of your provider so please use it gently.
>> Regards
>> David Samblas
>> El mié, 06-08-2008 a las 00:16 +0200, Nicolas Pichon escribió:
>>> arne anka wrote:
>>> >  from where in europe are you ordering?
>>> > if you're inside emu when using iban your transfer is not allowed to cost
>>> > more than a national transfer.
>>> >
>>>
>>> I'm ordering from France (my bank is Société Générale), and they charged
>>> me 3,05€ (not 3,50€ as I said before, I've just re-checked), which is
>>> also the cost for a national transfer in my bank.
>>>
>>> ___
>>> Openmoko community mailing list
>>> community@lists.openmoko.org
>>> http://lists.openmoko.org/mailman/listinfo/community
>>
>>
>> ___
>> Openmoko community mailing list
>> community@lists.openmoko.org
>> http://lists.openmoko.org/mailman/listinfo/community
>>
>
>
> ___
> Openmoko community mailing list
> community@lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community
>


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

Re: FR at golem.de

[vasco . nevoa]

Citando Michele Renda <[EMAIL PROTECTED]>:

>
> So, I think, making pessure to the firm that produce Glamo, is the only
> possibility to get very open our hardware.
>

Given the legal situation, I agree. Let's pester them with a ton of emails! :)
Maybe we could get the FSF and GNU into this as well? We might as well  
use all the armies at once, for greater impact... ;)
Maybe we could collect information about good examples of HW firms who  
have opened their specs and are gaining market share because of this,  
and present that data to SMedia.
I'm just throwing up ideas, I don't have the time to actually execute  
them... but someone with GNU/FSF connections could.

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

Re: FR at golem.de

[vasco . nevoa]

>
> Agreed. Why does nobody seem to be addressing/acknowledging this issue
> (or am I just looking in the wrong places)? An April 2008 post on the
> mailing list suggests that SMedia want $15,000 to release the docs under
> NDA to anyone outside of Openmoko employees. If this is the case, and
> nobody is even prepared to address this issue in other ways let alone
> pay for it, then for the foreseeable future it seems that this chip will
> do nothing more than sit there consuming power and the Freerunner will
> be without any form of graphic acceleration.
>
> It is a crying shame.
>
> Aaron
>

Which prompts me to ask: when FIC/OM chose this chip, what was their  
plan? they knew that it had IP strings attached, and yet they chose it  
anyway. They must have had some kind of plan to make it compatible  
with "Open" philosophy. What is it?

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

Re: Pulsters outstanding orders

[vasco . nevoa]

Hi all.

I've also been anxiously waiting here in Lisbon for my FR to arrive  
from Pulster together with a 10+ group from Portugal and another 10+  
group from Spain. And of course, Pulster is delayed. Worse yet,  
they've just told us they probably switched the Spanish and Portuguese  
orders by mistake. 8)

Now, Pulster himself has been satisfyingly accessible and honest with  
us (he even told us to refuse the packages and he would reship them  
correctly on his own cost), so we are going to cut him some slack (we  
will accept the packages and sort out the mess by ourselves); I  
believe, like David just so eloquently said, that the people at  
Pulster are working in overdrive to satisfy an overwhelming amount of  
orders for this phone, and I think the problem extends to all the  
other distributors and even the openmoko factory.
It is a bit their fault, of course, for having created such high  
expectations for so long, in a synchronized release. But it couldn't  
be done any other way.

So please, guys, take it easy. We'll all get our phones.
We've waited over a year for this, we can wait a few more days/weeks.
After all, there is no other phone like this in the whole history of  
mankind.  :)
Keep in mind that getting the phone in our hands is not the goal; it  
is just the beginning of the revolution!

Vasco.

Citando David Samblas <[EMAIL PROTECTED]>:

> Nicolas,
> I can understad your anxious, and the nerves of the unknown status of
> your desired order. But you must understand than Pulster has make an
> great effort to mantain the Neo as affordable as posible, this has
> translated to an overheading amount of  enstusiast impatience
> mail-vervose geeks that in solitare or in numerous groups has decided to
> buy to him(me included), I don't know the number of items had sell
> before the "Neo madness" but I'm only a coordinator of a group and some
> times it's hard to follow track about my 18 neo future(barely present)
> owners, so cmagine hundreds of them (I can imagine Chris as Jim Carey in
> this scence where he is God's sustitute and decide to drive all  plege
> via mail.. It's  scary, isn't it?). We all are noobs, Openmoko
> delivering from factory, Distributors estimating sales and shipping
> resources, we as costumers are also noob becouse this kind of open
> distribution chain has no precedent in a comercial product. So all of
> you, waiting a neo from Pulster or  from any distributor , please have a
> little empathy with your provider, an consider this fisrsts bacthes
> deliveries as beta, they will surelly have bugs but you must be
> confident that you neo will arrive, and in the near future the situation
> will be more regular and soft. And as Pulster said you have all the
> right to put on his nerves asking for the status of you Neo, but take in
> account that any mail/phonecall you send is a little more weigth in the
> load of your provider so please use it gently.
> Regards
> David Samblas
> El mié, 06-08-2008 a las 00:16 +0200, Nicolas Pichon escribió:
>> arne anka wrote:
>> >  from where in europe are you ordering?
>> > if you're inside emu when using iban your transfer is not allowed to cost
>> > more than a national transfer.
>> >
>>
>> I'm ordering from France (my bank is Société Générale), and they charged
>> me 3,05€ (not 3,50€ as I said before, I've just re-checked), which is
>> also the cost for a national transfer in my bank.
>>
>> ___
>> 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