Re: Bi-weekly OpenMoko community update
On 15/10/2007, Jay Vaughan [EMAIL PROTECTED] wrote: so no, we do want and require the source code to everything Change your government then. In the US for example, there are strict FCC-imposed regulations on how open certain portions of the carrier network can be, and this extends to the chip-level in consumer handsets. These regulations are enforced in the States, but also imposed internationally as well.. and yes, before you don the tin- foil hat, they're designed to protect the ability for law enforcement to protect the network, as well as intrude on it. A fully open carrier layer would impede this, and there is doctrine in many western governments to protect the sandbox. This carries down all the way to the individual implementors (chip mfr's), and at some point, you can expect a brick wall. Naivity is no excuse; government also. unfortunately, you chopped out the bit of my reply that said '(where legal)', which was specifically put in for the case you mention, i.e. the firmware for the gsm unit. on the other hand, we were specifically talking about the driver for the gps hardware, which is a receive only radio, and hence not covered by the same regulations as the gsm radio ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Bi-weekly OpenMoko community update
Robin Paulson skrev: on the other hand, we were specifically talking about the driver for the gps hardware, which is a receive only radio, and hence not covered by the same regulations as the gsm radio Yes. And I'm fully in suport for OpenMoko picking a new GPS unit with full os support. Butt... For the old GTA01, that have the old chip, and that will not be used in the future, it is completely sufficient with a binary driver accessible thru the same interface as the GTA02 phones (even if it needs to be some function limitations). That's what originally stated anyway. Not getting GPS functionality at all on GTA01 will make me a bit sad thou. /LaH ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Bi-weekly OpenMoko community update
On 10/14/07, Robin Paulson [EMAIL PROTECTED] wrote: hmm. this an open phone with open hardware and (where legal) open drivers. not having the source code to something would defeat the whole purpose of what sean et al are doing, and not attract any of the community that's here - the neo would be just another smartphone/pda and we'd be back to square one. I've got a personal system of prioritizing the items that I want source for, based on what the result of source availability / unavailability is. The primary purpose (for me) to have source to something is to make it more functional (either by me modifying the code, or someone else modifying it). To go along with that, source availability under a freedom license allows others to share their modifications with others (including me) which makes the code more functional to me. So from there I can make a determination on what I really want source for: 1) Binary blobs -- since thes are alternatives to having firmware already on an external chip, it makes no difference in functionality wheather a chip is used with a rom chip already loaded with the binary blob (which I can't modify), vs. pushing the unmodifyable binary blob to the chip at initialation time. If I don't have source for that binary blob, it doesn't bother me because it is something that runs outside of the main processor. 2) Kernel modules -- These are more important to have source for, since lack of source means that I loose the functionality of that device when I upgrade to a newer kernel. If I can be guaranteed that updated versions of the driver are provided in a timely manner for newer kernel versions, AND if the driver is already perfect enough that it won't need any functionality added, then I can almost accept using binary drivers. Of course, these two conditions are almost never met. 3) Binary apps / daemons -- If a binary app runs completely in user space (so that there is little chance of it destabilizing the system), AND if it has a well defined and fully implemented functionality (so that it is not likely that I would need to have improved versions of it), then I can accept it. If the gpsd falls into catagory 3 (and not 2), then for me that is ok, as long as it is bug free, will work with updated kernels, and has a defined api for talking to it from other apps. In that case, I can treat it as if I'm using a gps chip that spits out the protocal that the daemon is spitting out. (I assume that is what the daemon is for, to take the propriarity api on the chip and convert it to a standards-based api). Now a secondary purpose of having source availability is to study the code to improve my programming techniques. So having a closed gpsd doesn't help there. But it doesn't affect the primary purpose. (Of course, other people have different primary purposes than me, so this won't apply to them). ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Bi-weekly OpenMoko community update
Derek Pressnall wrote: If the gpsd falls into catagory 3 (and not 2), then for me that is ok, as long as it is bug free, will work with updated kernels, and has a defined api for talking to it from other apps. In that case, I can treat it as if I'm using a gps chip that spits out the protocal that the daemon is spitting out. (I assume that is what the daemon is for, to take the propriarity api on the chip and convert it to a standards-based api). gpsd does a bit more and a bit less than that - most chips already spit out NMEA 0183 sentences. gpsd wraps these and provides a shared interface to the gps, so that apps don't need to bind to a comm port and multiple apps can leverage gps data. gpsd will also run in some binary modes (SiRF and garmin, perhaps others) and will signal to switch between binary and NMEA modes. Otherwise, diagnostics , gpsfake, etc... more info (if you are interested) at http://gpsd.berlios.de The 'bug free' is the part that I would be most worried about - often the bugs are only discovered after extended use, because real users are capable of getting machines into states that testers couldn't dream of :) although not so much with gpsd, which seems to be pretty robust - I have had problems with older versions where it did not suspend properly (and was extremely difficult to kill), but I never really sorted whether that was gpsd or something else. Now a secondary purpose of having source availability is to study the code to improve my programming techniques. So having a closed gpsd doesn't help there. But it doesn't affect the primary purpose. (Of course, other people have different primary purposes than me, so this won't apply to them). The core of gpsd is totally open for code review, I think the closed binary only applies to the gllin piece, but I could be mistaken. Rgds, Joshua ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Bi-weekly OpenMoko community update
Butt... For the old GTA01, that have the old chip, and that will not be used in the future, it is completely sufficient with a binary driver accessible thru the same interface as the GTA02 phones (even if it needs to be some function limitations). That's what originally stated anyway. Not getting GPS functionality at all on GTA01 will make me a bit sad thou. As I think Harald mentioned, we are working on this. We do not intend to abandon GPS functionality for GTA01 owners. I will update you as I get news. Michael ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Bi-weekly OpenMoko community update
Absolutely agrree. GPS was one of my main points for buying the phone. I dont really care about the source for the driver as long as I can get the co-ordinates. Count me in the 'me too' crowd .. I'm really looking forward to having working GPS functionality on my GTA01, from the perspective of a user as well as that of a developer, who would like to integrate GPS into the game currently being worked on exclusively for OpenMoko .. j. ; -- Jay Vaughan ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Bi-weekly OpenMoko community update
On Mon, 15 Oct 2007 11:18:55 +0200, Jay Vaughan [EMAIL PROTECTED] wrote: so no, we do want and require the source code to everything Change your government then. Of course. This is but a small first step on the road to world domination ;o) ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Bi-weekly OpenMoko community update
On 10/14/07, Robin Paulson [EMAIL PROTECTED] wrote: On 15/10/2007, Pranav Desai [EMAIL PROTECTED] wrote: Absolutely agrree. GPS was one of my main points for buying the phone. I dont really care about the source for the driver as long as I can get the co-ordinates. hmm. this an open phone with open hardware and (where legal) open drivers. not having the source code to something would defeat the whole purpose of what sean et al are doing, and not attract any of the community that's here - the neo would be just another smartphone/pda and we'd be back to square one. so no, we do want and require the source code to everything Even I would love to get the source, but if not getting the src is causing the device to be non-functional, then I would prefer to get it without the source as long as I can get the device to work, since I have paid for it. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- -- http://pd.dnsalias.org ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Bi-weekly OpenMoko community update
On Sat, 2007-10-13 at 12:02 +0200, Pedro Aguilar wrote: Hi, It would be nice that the software development your're doing at the moment would be backwards compatible with GTA01 (at least the parts that are not hw dependent and are different between GTA01 and GTA02), otherwise the users of GTA01 would risk to remain without support for upgrades. This would be important for all the doc too. BTW, will the debug board and wires of GTA01 be compatible with GTA02? I would like to buy GTA02 and use the debug board and wires that I already have for GTA01. Yes, the debug board is generic. I have used my v2 debug board with GTA01 and GTA02. Regards, Thomas -- OpenedHand Ltd. Unit R Homesdale Business Center / 216-218 Homesdale Road / Bromley / BR1 2QZ / UK Tel: +44 (0)20 8819 6559 Expert Open Source For Consumer Devices - http://o-hand.com/ ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Bi-weekly OpenMoko community update
On Sat, 2007-10-13 at 18:17 +0200, Jan Dittmer wrote: Hello Michael, it would be nice to have some info about this white screen of death plus vibrator which is affecting some people. Especially if that is a hardware or software problem. It's pretty annoying and generally happens if you want to show someone the phone :-( I cannot remember any official statement on this issue - which is kind of sad I believe a white screen at boot normally means that the CPU is on, but the boot loader has not run. Where have other people mentioned this problem? Regards, Thomas -- OpenedHand Ltd. Unit R Homesdale Business Center / 216-218 Homesdale Road / Bromley / BR1 2QZ / UK Tel: +44 (0)20 8819 6559 Expert Open Source For Consumer Devices - http://o-hand.com/ ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Bi-weekly OpenMoko community update
On 10/13/07, Shawn Rutledge [EMAIL PROTECTED] wrote: On 10/12/07, Michael Shiloh [EMAIL PROTECTED] wrote: We're very happy with the u-blox/Atmel ATR0635 GPS Receiver, and thus have made the decision to use this chip. That sounds like good news. It's not open-source but sounds like it should be easier to interface with. However, FIC still needs to get us the gllin binaries for our GTA01's! I hope this isn't being forgotten just because you chose a new chip. It was advertised as a GPS phone and that was probably a big factor for many of us to purchase it. Personally I was looking forward very much to having this working, and the last update I remember seeing was a couple months ago when Sean said the license would all be worked out in a few more days! What's up with that? How many hundreds of phones are sitting around with idle GPS chips, hampering the development because of this licensing red tape! It's ridiculous that it has taken this long. Absolutely agrree. GPS was one of my main points for buying the phone. I dont really care about the source for the driver as long as I can get the co-ordinates. -- Pranav If the chip co. wants to charge a small fee I'd even pay it. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- -- http://pd.dnsalias.org ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Bi-weekly OpenMoko community update
On 15/10/2007, Pranav Desai [EMAIL PROTECTED] wrote: Absolutely agrree. GPS was one of my main points for buying the phone. I dont really care about the source for the driver as long as I can get the co-ordinates. hmm. this an open phone with open hardware and (where legal) open drivers. not having the source code to something would defeat the whole purpose of what sean et al are doing, and not attract any of the community that's here - the neo would be just another smartphone/pda and we'd be back to square one. so no, we do want and require the source code to everything ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Bi-weekly OpenMoko community update
I'd like to see a package of simply, fully working, high-quality example applications, including tutorials on cross-compiling and linking against different versions of the various OpenMoko libraries. It would provide an excellent starting point for developers such as myself who want to dive in but usually get bogged down in code that is written to do work, not to look pretty and demonstrate the principals of how the system is put together. Documentation is great, but if it's dense it will only benefit the more hardcore hackers. I hope to eventually become one of those more hardcore hackers, but I feel like I need an entry point. :-) On 10/13/07, Michael Shiloh [EMAIL PROTECTED] wrote: Hello everyone, I have some updates for you, and a question. First the updates: The GTA01 units that were shipped in the past two weeks have satisfied the back orders for GTA01. There continues to be demand for GTA01 so we are building some more. GTA02 Wifi hardware has been working for about a week, so work can proceed on the driver, which is currently in a pretty minimal state. We're very happy with the u-blox/Atmel ATR0635 GPS Receiver, and thus have made the decision to use this chip. GTA02v3, the third revision of GTA02, is still being verified and tested. This will take another couple of weeks, at which point we'll make GTA02v4. Now the question: We want to make it easier for developers to work with OpenMoko. We realize that many of our resources (e.g. wiki, website, development tools) are decidedly not user friendly at the moment and that other resources (e.g. documentation) are missing. I'm going to start putting a lot more energy into this, and I'd like to hear your thoughts in general and in particular what should be tackled first. You may reply either to the list or to me personally, as you wish. Sincerely, Michael ___ 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: Bi-weekly OpenMoko community update
Hi Ryan, That's a great idea. I too learn best from examples. I'll add this to the list. Thanks, Michael Ryan Prior wrote: I'd like to see a package of simply, fully working, high-quality example applications, including tutorials on cross-compiling and linking against different versions of the various OpenMoko libraries. It would provide an excellent starting point for developers such as myself who want to dive in but usually get bogged down in code that is written to do work, not to look pretty and demonstrate the principals of how the system is put together. Documentation is great, but if it's dense it will only benefit the more hardcore hackers. I hope to eventually become one of those more hardcore hackers, but I feel like I need an entry point. :-) On 10/13/07, *Michael Shiloh* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hello everyone, I have some updates for you, and a question. First the updates: The GTA01 units that were shipped in the past two weeks have satisfied the back orders for GTA01. There continues to be demand for GTA01 so we are building some more. GTA02 Wifi hardware has been working for about a week, so work can proceed on the driver, which is currently in a pretty minimal state. We're very happy with the u-blox/Atmel ATR0635 GPS Receiver, and thus have made the decision to use this chip. GTA02v3, the third revision of GTA02, is still being verified and tested. This will take another couple of weeks, at which point we'll make GTA02v4. Now the question: We want to make it easier for developers to work with OpenMoko. We realize that many of our resources (e.g. wiki, website, development tools) are decidedly not user friendly at the moment and that other resources ( e.g. documentation) are missing. I'm going to start putting a lot more energy into this, and I'd like to hear your thoughts in general and in particular what should be tackled first. You may reply either to the list or to me personally, as you wish. Sincerely, Michael ___ OpenMoko community mailing list community@lists.openmoko.org mailto: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: Bi-weekly OpenMoko community update
On 10/12/07, Michael Shiloh [EMAIL PROTECTED] wrote: We're very happy with the u-blox/Atmel ATR0635 GPS Receiver, and thus have made the decision to use this chip. That sounds like good news. It's not open-source but sounds like it should be easier to interface with. However, FIC still needs to get us the gllin binaries for our GTA01's! I hope this isn't being forgotten just because you chose a new chip. It was advertised as a GPS phone and that was probably a big factor for many of us to purchase it. Personally I was looking forward very much to having this working, and the last update I remember seeing was a couple months ago when Sean said the license would all be worked out in a few more days! What's up with that? How many hundreds of phones are sitting around with idle GPS chips, hampering the development because of this licensing red tape! It's ridiculous that it has taken this long. If the chip co. wants to charge a small fee I'd even pay it. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Bi-weekly OpenMoko community update
Shawn Rutledge wrote: On 10/12/07, Michael Shiloh [EMAIL PROTECTED] wrote: We're very happy with the u-blox/Atmel ATR0635 GPS Receiver, and thus have made the decision to use this chip. That sounds like good news. It's not open-source but sounds like it should be easier to interface with. However, FIC still needs to get us the gllin binaries for our GTA01's! I hope this isn't being forgotten just because you chose a new chip. It was advertised as a GPS phone and that was probably a big factor for many of us to purchase it. Personally I was looking forward very much to having this working, and the last update I remember seeing was a couple months ago when Sean said the license would all be worked out in a few more days! What's up with that? How many hundreds of phones are sitting around with idle GPS chips, hampering the development because of this licensing red tape! It's ridiculous that it has taken this long. I'll look into this. Michael ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Bi-weekly OpenMoko community update
On Saturday 13 October 2007 07:05:19 Michael Shiloh wrote: We're very happy with the u-blox/Atmel ATR0635 GPS Receiver, and thus have made the decision to use this chip. So does this mean we now have GPS hardware that outputs NMEA on a serial port (or something similar) without having to run a closed source daemon? signature.asc Description: This is a digitally signed message part. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Bi-weekly OpenMoko community update
Gabriel Ambuehl wrote: On Saturday 13 October 2007 07:05:19 Michael Shiloh wrote: We're very happy with the u-blox/Atmel ATR0635 GPS Receiver, and thus have made the decision to use this chip. So does this mean we now have GPS hardware that outputs NMEA on a serial port (or something similar) without having to run a closed source daemon? yes. it can also be switched to UBX protocol, but in default it speak NMEA and the regular gpsd can (and will be) used. so the last closed source component on the app-cpu is gone for gta02 -- Joachim Steiger ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Bi-weekly OpenMoko community update
We want to make it easier for developers to work with OpenMoko. We realize that many of our resources (e.g. wiki, website, development tools) are decidedly not user friendly at the moment and that other resources (e.g. documentation) are missing. I'm going to start putting a lot more energy into this, and I'd like to hear your thoughts in general and in particular what should be tackled first. You may reply either to the list or to me personally, as you wish. I would like to see a more 'official' or at least well-promoted weekly build of the distribution that we (developers) can all be testing our stuff against .. maybe with some of the more interesting stuff thats being done included. There is very little cohesion, it seems, with the different people working on different aspects of the OpenMoko distribution; if there was an 'official' maintainer who could gather the stuff together and provide regular 'official', working builds, this would be very helpful .. j. ; -- Jay Vaughan ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Bi-weekly OpenMoko community update
Hello Michael, it would be nice to have some info about this white screen of death plus vibrator which is affecting some people. Especially if that is a hardware or software problem. It's pretty annoying and generally happens if you want to show someone the phone :-( I cannot remember any official statement on this issue - which is kind of sad. Thanks, Jan Michael Shiloh wrote: Hello everyone, I have some updates for you, and a question. First the updates: The GTA01 units that were shipped in the past two weeks have satisfied the back orders for GTA01. There continues to be demand for GTA01 so we are building some more. GTA02 Wifi hardware has been working for about a week, so work can proceed on the driver, which is currently in a pretty minimal state. We're very happy with the u-blox/Atmel ATR0635 GPS Receiver, and thus have made the decision to use this chip. GTA02v3, the third revision of GTA02, is still being verified and tested. This will take another couple of weeks, at which point we'll make GTA02v4. Now the question: We want to make it easier for developers to work with OpenMoko. We realize that many of our resources (e.g. wiki, website, development tools) are decidedly not user friendly at the moment and that other resources (e.g. documentation) are missing. I'm going to start putting a lot more energy into this, and I'd like to hear your thoughts in general and in particular what should be tackled first. You may reply either to the list or to me personally, as you wish. Sincerely, Michael ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- Jan ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Bi-weekly OpenMoko community update
Hello, this means that gta02v3 has bugs? Greets Patrick Beck Am Freitag, den 12.10.2007, 22:05 -0700 schrieb Michael Shiloh: GTA02v3, the third revision of GTA02, is still being verified and tested. This will take another couple of weeks, at which point we'll make GTA02v4. 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: Bi-weekly OpenMoko community update
this means that gta02v3 has bugs? .. it means that the hardware is going through rigorous testing before it gets reproduced in large numbers. Certainly, hardware can have bugs .. the difference is that its very hard to fix these bugs 'at the user' once the hardware is shipped. I'm quite happy to hear that there are revisions of the GTA02 design already going through the validation and testing process. I've worked recently for a hardware manufacturer who believed they didn't need to make such stages (too expensive, too much hassle) and believe me: it was a nightmare. I'll be quite happy to wait an extra month for my GTA02 (for sure getting one) if its been through this much quality control and design review .. j. ; -- Jay Vaughan ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Bi-weekly OpenMoko community update
Hello, ok, than i am right = v3 has bugs and they musst be fix with v4. I dont think that this problem would be solved in one month. v4 has the same process like v3 = solve the bug problems = testing and validation. According to the wiki = they hoped that v3 is bug-free Greets Patrick Beck Am Samstag, den 13.10.2007, 19:46 +0200 schrieb Jay Vaughan: this means that gta02v3 has bugs? .. it means that the hardware is going through rigorous testing before it gets reproduced in large numbers. Certainly, hardware can have bugs .. the difference is that its very hard to fix these bugs 'at the user' once the hardware is shipped. I'm quite happy to hear that there are revisions of the GTA02 design already going through the validation and testing process. I've worked recently for a hardware manufacturer who believed they didn't need to make such stages (too expensive, too much hassle) and believe me: it was a nightmare. I'll be quite happy to wait an extra month for my GTA02 (for sure getting one) if its been through this much quality control and design review .. j. ; -- Jay Vaughan signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
