Re: Engineering Driven vs. Community Driven (was Re: Ugliness)
If this is primarily a developer platform, why are there so many intense opinions about such superficial things as color and marketing anyways? In today's world, there is *very* little daylight between marketing and engineering. They are of a piece. The product design, the feature set, and yes even the physical form factor are all both engineering issues as well as marketing issues. Apple is a prime example of this. The beauty of the design of their products is all about marketing, but could not be achieved without incredible engineering on the electrical, software, and mechanical engineering fronts. So I don't think, particularly for a phone, you can separate these issues. Hank -- blog: whydoeseverythingsuck.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Engineering Driven vs. Community Driven (was Re: Ugliness)
On Mon, Apr 28, 2008 at 3:57 PM, Crane, Matthew [EMAIL PROTECTED] wrote: There is nothing incredible about apple's electrical, software, or mechanical engineering. IMHO.. The marketing/buzz machine is incredible though. I presume that you have never worked on a team that has built a successful mainstream consumer product, because if you did, you certainly would not be able to dismiss their success in this manner. Making things that sell has very little to do with advertising. hype does not just come from nowhere, as if from the heavens. If crappy products could win based on good advertising, all that would be required was money and clearly that is not nearly enough (see Microsoft Vista). The bottom line is that best selling tech gadgets, software, and computers sell to primarily tech savvy people because they like them. They like them, because the designers and developers have figured out how to make broadly appealing products. That is hard. If you are suggesting otherwise without actually having a resume that suggests you have done so yourself, you really don't have much of an argument. Hank -- *From:* [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] *On Behalf Of *hank williams *Sent:* Monday, April 28, 2008 1:52 PM *To:* List for Openmoko community discussion *Subject:* Re: Engineering Driven vs. Community Driven (was Re: Ugliness) If this is primarily a developer platform, why are there so many intense opinions about such superficial things as color and marketing anyways? In today's world, there is *very* little daylight between marketing and engineering. They are of a piece. The product design, the feature set, and yes even the physical form factor are all both engineering issues as well as marketing issues. Apple is a prime example of this. The beauty of the design of their products is all about marketing, but could not be achieved without incredible engineering on the electrical, software, and mechanical engineering fronts. So I don't think, particularly for a phone, you can separate these issues. Hank -- blog: whydoeseverythingsuck.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- blog: whydoeseverythingsuck.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Engineering Driven vs. Community Driven (was Re: Ugliness)
On Mon, Apr 28, 2008 at 4:40 PM, Crane, Matthew [EMAIL PROTECTED] wrote: Clever design != feat of engineering. Matt again, unless you have engineered a clever design I don't think you have much credibility on this. Executing appealing products from an engineering perspective is incredibly hard. What experiences do you have on this front which would suggest otherwise. -- *From:* [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] *On Behalf Of *hank williams *Sent:* Monday, April 28, 2008 4:26 PM *To:* List for Openmoko community discussion *Subject:* Re: Engineering Driven vs. Community Driven (was Re: Ugliness) On Mon, Apr 28, 2008 at 3:57 PM, Crane, Matthew [EMAIL PROTECTED] wrote: There is nothing incredible about apple's electrical, software, or mechanical engineering. IMHO.. The marketing/buzz machine is incredible though. I presume that you have never worked on a team that has built a successful mainstream consumer product, because if you did, you certainly would not be able to dismiss their success in this manner. Making things that sell has very little to do with advertising. hype does not just come from nowhere, as if from the heavens. If crappy products could win based on good advertising, all that would be required was money and clearly that is not nearly enough (see Microsoft Vista). The bottom line is that best selling tech gadgets, software, and computers sell to primarily tech savvy people because they like them. They like them, because the designers and developers have figured out how to make broadly appealing products. That is hard. If you are suggesting otherwise without actually having a resume that suggests you have done so yourself, you really don't have much of an argument. Hank -- *From:* [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] *On Behalf Of *hank williams *Sent:* Monday, April 28, 2008 1:52 PM *To:* List for Openmoko community discussion *Subject:* Re: Engineering Driven vs. Community Driven (was Re: Ugliness) If this is primarily a developer platform, why are there so many intense opinions about such superficial things as color and marketing anyways? In today's world, there is *very* little daylight between marketing and engineering. They are of a piece. The product design, the feature set, and yes even the physical form factor are all both engineering issues as well as marketing issues. Apple is a prime example of this. The beauty of the design of their products is all about marketing, but could not be achieved without incredible engineering on the electrical, software, and mechanical engineering fronts. So I don't think, particularly for a phone, you can separate these issues. Hank -- blog: whydoeseverythingsuck.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- blog: whydoeseverythingsuck.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- blog: whydoeseverythingsuck.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Engineering Driven vs. Community Driven (was Re: Ugliness)
Your argument is similar to suggesting Nike has superior engineering because they have the coolest shoes. uhh... yes. The coolest shoes come from doing real *engineering*. Unless by cool you just mean pretty colors. An *incredible* amount of engineering goes into the creation of nike shoes. An **INCREDIBLE** amount. No doubt there is some engineering at Nike wrt shoes but it aint that special in the grand scheme of things. It's about selling a minimal product with high margins, like Apple. Hmm... this is just wrong. Nike (nor apple) wins because they designed the cheapest to manufacture product. In fact most of the time this is not true. If we take as a simplistic metric the number of inferences and resulting complexity produced from work at the company required to go from the drawing board to the product release, then the engineering that goes into an iPhone is not really any more then most of the McWindows phones out there. First of all I said Apple not iPhone. But to focus on the iphone for a sec, because Apple controls the software and the hardware of all of its products, even with the iPhone this statement is demonstrably false since McWindows phone manufacturers OEM their software and so do far less than half the work apple has to do. And certainly, at this point, apple has the most appealing software stack in the phone market. To suggest that there is no difference between the iphone software and the crash prone clunky windows mobile is to not have used either. A lot of design and art and marketing considerations mostly, but that is not really engineering, design *is* engineering, particularly as it relates to software and mechanical engineering. You cannot separate them. And by design I do not mean art work. It means how you make things work. Again your comments reflect not having actually worked on this stuff. Engineering good designs is hard. Its not about art, it is about execution. To suggest otherwise is really to reveal a lack of understanding of the process. -- blog: whydoeseverythingsuck.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GPS/Cell phone patent issue
On Jan 25, 2008 7:11 PM, joerg [EMAIL PROTECTED] wrote: In other words, like it or not, if this patent is valid (who knows) and its scope is what it looks like (I'm not a lawyer) it will have a significant impact on the *phone* world. In other words, *you* consider GTA to be a *phone*, nothing else and not beyond. You're kidding? Like it or not, the GTA/OpenMoko is a *computer* with built in GSM-modem, and i don't think many of the customers will opt for an off-board solution that fails when leaving GSM coverage area, Well, currently, there are *millions* of phones that ship *every month* in the configuration I am describing and *none* that ship in the configuration you are describing. So what customers are *currently* doing is the thing that you are saying people wont opt for. Better tell Apple and RIM (and probably others) to stop selling all those phones - Oh, excuse me... computers. lol. Hank -- - whydoeseverythingsuck.com ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GPS/Cell phone patent issue
I'm puzzled why you responded *twice* to the same email. And I'm sure somehow you missed the email that was actually a response to your first answer. Again, since you seem to have missed it. The thing that you say no one will opt for (over the air maps), is the way that millions of phones per month are shipped from Apple and RIM today. Therefore the configuration is highly relevant to the *current* phone market. Hank ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GPS/Cell phone patent issue
On Jan 25, 2008 8:14 PM, Shawn Rutledge [EMAIL PROTECTED] wrote: On Jan 25, 2008 5:42 PM, hank williams [EMAIL PROTECTED] wrote: Again, since you seem to have missed it. The thing that you say no one will opt for (over the air maps), is the way that millions of phones per month are shipped from Apple and RIM today. Therefore the configuration is highly relevant to the *current* phone market. The point that you are missing is that Openmoko doesn't have to do everything the same way Apple and RIM do them; Of course no one has to do anything the way Apple and RIM do it. I think you are missing *my* point. My initial post was that there is a patent that has an effect on the most common usage pattern for location based tools for mobile devices. The odd position, it seems to me, is to suggest that no one should be concerned about a very popular device usage pattern. Obviously there are lots of ways to design things, but to suggest that one very popular way (in fact the primary way) people are doing something is of *no concern* would seem to me to be a myopic attitude. My goal is to provide information. The idea of suggesting that that information doesn't matter which is what Joerg said, is really well... I wont say. I am not sure why providing information should be something that disturbs people so. If its not relevant to you, ignore it. Hank ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GPS/Cell phone patent issue
On Jan 25, 2008 7:47 PM, ian douglas [EMAIL PROTECTED] wrote: hank williams wrote: I don't think any phones are going to come with navigation data built in. To my knowldge, the Samsung Blackjack 2 from ATT includes maps from TeleNav. You have to pay an extra $10/month to use GPS with those maps of course, so I just use the Mobile Google Maps application which uses the GPS on the Blackjack 2 just fine. Hmm... ok, so it comes with it but you cant use it without paying? Thats kinda like not coming with isnt it? In any case so you are, as I suggest most will, using Google Maps. Which is indeed the point. The patent I am referring to relates to this over-the-air maps scenario, which is, as far as I can tell, the dominant scenario on cell phones. Hank. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GPS/Cell phone patent issue
On Jan 25, 2008 6:17 PM, joerg [EMAIL PROTECTED] wrote: Hmm... The patent purports to cover getting *any* information based on where you are, including maps. So unless all the map information or whatever information you need can fit on your phone you are not interested in it? I guess you better wait for some *really* big flash memory chips. :) The maps ARE on board for all common GPS car navis (really big 256MB-flash card e.g.). In *cars*, not phones. This is the *Openmoko* list. We're talking *phones* here. I don't think any phones are going to come with navigation data built in. For example Blackberrys have GPS but do not have the maps built in. That data comes from the network. Same with the new iPhone functionality, which uses Google Maps. And I presume no Openmoko phones are going to ship with location data. So while none of this may be relevant to you, this discussion is about (at least in my mind) the modern phone technology and how to apply it. Your personal feelings about how location data should be used don't really map to the way most expect to use phone + gps technology. In other words, like it or not, if this patent is valid (who knows) and its scope is what it looks like (I'm not a lawyer) it will have a significant impact on the *phone* world. Hank Hank -- - whydoeseverythingsuck.com ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
GPS/Cell phone patent issue
Today I blogged about a companyhttp://whydoeseverythingsuck.com/2008/01/are-apple-rim-and-google-all.htmlthat has a patent on what I would call the essence of putting a GPS in a cell phone. I provided some details on the patent in my blog, but the essence of the story is covered in this excerpt: It appears that, in essence, the patents cover a phone providing current location information to a remote database which returns to the phone a collection of location centric information. According to the patent application, this location centric information could include real estate information, such as homes, condominiums, etc, but also parks, restaurant menus, services offered, hotels, hotel availability, and on and on. This, it appears, is an incredibly broad patent with major implications. Hank -- - whydoeseverythingsuck.com ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GPS/Cell phone patent issue
On Jan 25, 2008 8:33 PM, joerg [EMAIL PROTECTED] wrote: http://www.tomtom.com/products/features.php?ID=280Category=2Lid=1 Now I guess I should post a link to an iPhone commercial. Hank ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GPS/Cell phone patent issue
On Jan 25, 2008 5:37 PM, joerg [EMAIL PROTECTED] wrote: Am Fr 25. Januar 2008 schrieb hank williams: [...] It appears that, in essence, the patents cover a phone providing current location information to a remote database which returns to the phone a collection of location centric information. According to the patent application, this location centric information could include real estate information, such as homes, condominiums, etc, but also parks, restaurant menus, services offered, hotels, hotel availability, and on and on. Whatever they might have (or think they have) with this patent, i don't mind. I *never* will give away GPS-data from my private cell phone to a centralized database, may it be google, TomTom, or whoever. I like my privacy, and even hate being traced by GSM-cell handover right now for 6 months storage of data in whole europe right since start of year. :-( And even less i need location centric info based on this DB. Hmm... The patent purports to cover getting *any* information based on where you are, including maps. So unless all the map information or whatever information you need can fit on your phone you are not interested in it? I guess you better wait for some *really* big flash memory chips. :) Hank - whydoeseverythingsuck.com ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Application idea: Bicycle computer
You can get receivers for Polar chest straps that signal beats with gpio-accessible pulses. If the Neo1973 isn't completely packed inside, it should be an easy add-on. I dont understand what you are saying here. Are you saying there is a wireless reciever on the market which can be purchased which is compatible with polar? If so, what is it? What is the signaling standard. Is gpio a wireless signaling standard? If so, I was not able to find it. It seems like a wired standard, and if it is a wired standard I am not clear how you can connect it to a polar strap since the strap broadcasts wireless signals. Thanks Hank ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Application idea: Bicycle computer
On Dec 4, 2007 7:11 AM, Neil Davey [EMAIL PROTECTED] wrote: Hi Hank, I think what he's saying is that you can get after market receivers for polar chest straps eg http://www.concept2.com/us/products/heart/default.asp, which I have used myself in projects.. ok, but what is the protocol. Is it ant? ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Application idea: Bicycle computer
On Dec 4, 2007 7:39 AM, Neil Davey [EMAIL PROTECTED] wrote: If you are referring to the signal from the Polar straps, it is not really a protocol... It is just a magnetic pules transmitted when the heart beat occurs.. so is there a receiver chip one could buy to detect these magnetic pulses? I'm not quite sure how one goes about capturing that. Hank ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Application idea: Bicycle computer
Not sure about the Polar units, but for things using ANT like the suunto cheststraps there are these: http://www.thisisant.com/index.php?section=31 Thanks, Yes I am familiar with ant, but was curious if polar was the same thing or some different broadcast system. Hank ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Application idea: Bicycle computer
- external sensors (cadence, heart rate) Many bicycle computers show cadence and heartrate, based on input from external sensors. Could something like that be done with the Neo? I am a cyclist and these inputs would be critical for me. All that stuff is wireless. I wonder if it would be possible to create a wireless interface for these things, or a bluetooth interface for a heartrate and cadence monitor. Actually, bluetooth heart rate and cadence devices would probably hurt polar (the leader in the field) since open source software for these things would be much better than what they produce, and at a far better price. Hank ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Gphone isn't open, linux dev not possible
On Nov 17, 2007 3:04 AM, Dietz Proepper [EMAIL PROTECTED] wrote: hank williams: On Nov 14, 2007 2:55 PM, William Voorhees [EMAIL PROTECTED] wrote: I wouldn't say I'm not concerned, but I'm hopeful. In one of the video's Sergy Brin says that it will be entirely open. I hope that google's Do No Evil slogan takes hold. -Will I do hope and expect android to be open. That said, lets be clear not open != evil. You got that backwards, buddy. Not open - evil holds to a much larger extent than the inversion (for you information, that would be open - not evil). I strongly suggest you shut off that PC, leave the building and head toward the caves, lest you be infected with too much evil. And do *not* bring your neo. Its not safe either. Hank ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Gphone isn't open, linux dev not possible
On Nov 14, 2007 2:55 PM, William Voorhees [EMAIL PROTECTED] wrote: I wouldn't say I'm not concerned, but I'm hopeful. In one of the video's Sergy Brin says that it will be entirely open. I hope that google's Do No Evil slogan takes hold. -Will I do hope and expect android to be open. That said, lets be clear not open != evil. Though I do know many in th open source community feel this way. I don't know if this was just a slip or if it reflected your real opinions, but if open is evil, then most every product, device, computer, phone, chip, etc that we use is evil, as are the people that make them. Time to go move to a cave. Hank ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Gphone isn't open, linux dev not possible
Yes absolutely I meant !open. And yes I agree with the rest of your statement. Hank On Nov 16, 2007 8:52 AM, Attila Csipa [EMAIL PROTECTED] wrote: On Friday 16 November 2007 13:29:50 hank williams wrote: Though I do know many in th open source community feel this way. I don't know if this was just a slip or if it reflected your real opinions, but if open is evil, then most every product, device, computer, phone, chip, etc that we use is evil, as are the people that make them. Time to go move to a cave. I presume you wanted to say !open above. It's a common case used in 'evil' rhetorics, when you establish that A is good (A = open in our case), and that B is not A (B = proprietary), and reason that this means B is bad. While it might sound correct, it's logically flawed (the good things in Open don't influence whether Proprietary is good or bad, it's good or bad based on it's own merits/flaws, not A's). ___ 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: Community update: GSM firmware and GPS driver
exactly accurate respose/analysis. Hank On Nov 14, 2007 4:18 AM, Shachar Shemesh [EMAIL PROTECTED] wrote: Ian Darwin wrote: Anything less will lead to this sort of frustration, over and over again. It is not always possible. The way I figured it out, the GSM module will always be closed. This is not due to the hardware specs being unknown, but due to the fact that the law requires a transmitter to be approved by the FCC, and it is impossible to get an approval for a transmitter that allows anyone to change the frequencies it transmits in. I understand what the FCC is worried about (though I do not, necessarily agree with it. Anyone can build an unauthorized transmitter, and writing code that says you have copyright permission to modify this code, but you will have to get it certified with FCC yourself before you are allowed to use it does not, in my eyes, reduce your freedom). In other words, you will NEVER get a truly 100% open source cell phone as long as the FCC rules are as they are. Regarding the GPS, please pay attention to the fact that the GTA-02 did not solve this problem. It merely moved the non open source component from the software to the firmware. This solves the supporting libraries problem, but does not allow openness. Here, at least, I suspect that the reasons have less to do with an external certification authority, and thus have more hopes for the future. Shachar ___ 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: OpenMoko phone comparisons
Yes, I'm quite aware that the GTA02 meets these requirements, as does the UTC universal. I wouldn't have posted here after all and named those two phones otherwise. The question is, do any _other_ phones also fall into this category? Of course, I do want to run OpenMoko, and will do the necessary work if really required to make it do so if it already runs linux. And a general note: Your tone is very agressive and demanding. This does nothing but annoy people. I'd recommend you try to be more friendly and tolerant of seemingly unnecessary comments and people will probably be more friendly to you. With respect, you seem to be a bit confused and your reasoning is backwards. The initial responses I got were clearly trolls (by definition _they_ unfriendly and annoying people). I made an effort to be clear about what I was asking and haven't demanded anything, and the first responders had made no effort to really read what I said. Save your criticism for them. Unfortunately, it just looks like to outsiders that people are getting overly defensive it if looks like I might be trying to criticize OpenMoko/Neo. Let's try and restrict our opinions to what I'm really asked. No, Peter, honestly, you do sound really mean and super aggressive. I am trying to say this in a way that does not further incite your testosterone, but the fact that several people on this generally respectful list are saying the same thing (and this doesn't come up often) should be an indicator. I have no reason to say this other than that your tone is distinctly different from the rest of the list. And by the way I am plenty critical of openmoko re 850mhz. This has nothing to do with being defensive. I am just calling it like I see it. Regards Hank ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Community update: The 850 MHz issue
Yeah, I am pretty amazed at this one. Its really hard to imagine a company building a phone that didnt think through what frequencies were needed. More interestingly, that it took a trip from Michael to Taiwan to get anyone to focus on it. If this substantially sets back the development effort, it really is a major blow to the project. Hank On 11/6/07, Jonathon Suggs [EMAIL PROTECTED] wrote: First, thanks to Michael for giving the update. It is never good to have to be the bearer of bad news. However, this is huge! My probability of purchasing just dropped from 95% to about ~5%. I'm getting ready to move and not knowing what my coverage will be like in those areas is definitely a deal killer. I occasionally do some international travel and also spend time in more rural areas so quad-band coverage is an absolute must have (not just something I want for the warm fuzzies). I'm not going to be overly critical, but how does this just slip through the cracks? Although somewhat marginal, quad-band chipsets do cost more than tri-band. It just seems really really weird that ensure you have all of the functionality working would be an absolute no brainer. When putting all of the components together for a *PHONE* you would think that you would test, re-test, check, double-check and then triple check the actual *PHONE* components. My mind is pretty much blown over this one... -Jonathon -Original Message- From: Jae Stutzman [EMAIL PROTECTED] Reply-To: List for OpenMoko community discussion community@lists.openmoko.org To: List for OpenMoko community discussion community@lists.openmoko.org Subject: Re: Community update: The 850 MHz issue Date: Tue, 06 Nov 2007 07:37:15 -0600 Man this royally sucks for me. We only get 100% coverage because of the 850 band where I live. 1900 is being added slowly, but not anywhere close to full coverage. Anybody want a neo? I sure wish this information would have been provided _before_ the purchase. Jae ___ 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: Community update: The 850 MHz issue
On 11/6/07, Jeffrey Thomas [EMAIL PROTECTED] wrote: Its really hard to imagine a company building a phone that didnt think through what frequencies were needed. More interestingly, that it took a trip from Michael to Taiwan to get anyone to focus on it. If this substantially sets back the development effort, it really is a major blow to the project. Isn't it possible that the FIC's main userbase, in Asia, doesn't have this band to worry about? I live in the US but it seems like all of these comments are focused on *our* coverage, like we're the center of the world... It really is hard to imagine them thinking that they were designing a phone for just outside the US. If that was their thinking, it certainly should have been clarified. Certainly a plurality of the first units sold, and perhaps a majority, have been sold in the US. Honestly, its hard to imagine an Open Source phone gaining much traction without US support. We're not, nor do we have nearly the largest possible sales base. It is not true to say that we dont *nearly* have the largest base. whatever the numbers are, particularly for smart phones, I would be shocked to hear the US was anything but one of the top markets. Only japan could compete as a potentially larger market in asia. Certainly they are not going to be selling tons of these in China. Hank ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Community update: The 850 MHz issue
On 11/6/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Its really hard to imagine a company building a phone that didnt think through what frequencies were needed. More interestingly, that it took a trip from Michael to Taiwan to get anyone to focus on it. If this substantially sets back the development effort, it really is a major blow to the project. In all fairness to OpenMoko, I think 850 Mhz is only used by the USA and Canada, which only account for ~10% of mobile phones in the world. That's according to statistics at http://www.itfacts.biz/index.php?id=P7222 United States: 201.6m + Canada: 16.6m = 218.2m World: 2.14bn Yes, but that does not take into account types of phones. The world is full of super cheap phones that sell for a few dollars, particularly in developing nations. But This is a smart phone. And I strongly suspect the smart phone sales percentages are much larger than 10% in the US. So the OpenMoko can still be used in 90% of the GSM world. Although, having said that, I feel people's pain. :-( Plus I guess you have to factor in that the number of potential OpenMoko users/developers/hackers in the USA is probably _way_ higher than 10%. :-) Indeed. Hank ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Community update: The 850 MHz issue
Common, take a look outside of your own borders. It's hard to inmagine an Open Source phone gaining any traction at all in the US, land of software patents, closed standards and telco control. There are quit a few OSS projects doing just fine despite being illegal in the US, an Open Source phone will do just fine without US support. And Nokia is not a US company, nor is Sony-Ericsson, both became major players in this market before there even was any form of GSM coverage in the US. 1. did I say it was not possible to exist as a company without the US? No. What I said was that a plurality of smart phones are sold in the US. It is a major market. And a huge amount of OS work is done in the US. To design a phone that specifically cant really be sold in the US is dumb. It cuts out a huge potential market. And given the high level of competition, loosing 20 - 30% of your market opportunity is potentially deadly. We're not, nor do we have nearly the largest possible sales base. It is not true to say that we dont *nearly* have the largest base. whatever the numbers are, particularly for smart phones, I would be shocked to hear the US was anything but one of the top markets. Only japan could compete as a potentially larger market in asia. Certainly they are not going to be selling tons of these in China. Yeah, because it's not like there are loads of smart phones being sold in Europe... loads. Is that a new unit of measure in europe? It's Asia first, then Europe and the the America's, largely because the US had an incompatible system of their own for years. And you may be suprised about china too, 1% of the chinese buying a phone is as just as good as 4% of the US buying your phone. And it's far easier to gain marketshare in China then in the hugely locked-up US market. Ok, so I guess this whole thing in your mind is really good biz dev strategy because they dont need the US. Lol. They need more strategists like you at FIC. Hank ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Community update: The 850 MHz issue
This article compares smart phone adoption among recent buyers as of the time of writing in different countries - US adoption was pretty abysmal back in 2006. While I'm sure it's increased since then, 20-30% is still a very far stretch. I think 8% would be more accurate. The problem is that a lot of the smartphone analysts differ in what a smart phone is. I have seen analyst statistics that say 20m smart phones were sold world wide in 06 and I have seen stats from other analysts saying 60m smart phones in the same time period. The 20m numbers include RIM, Windows Mobile, Palm, and only the high end Symbians. The reason for this is Nokia sells lots of Symbian phones that really have nothing to do with being smart, or substantively programmable, which is for me the real benchmark for smart phones. When you look at real smart phone sales - i.e. the 20m number, a very significant number of those are sold in the US. This is just based on the fact that most palms and blackberrys are sold in the US. The Neo is cutting edge and so really only comparable with the other high end phones. Bottom line is that Nokia uses statistics to try to claim a larger share of the smartphone market. But their symbian deployments are mainly in non-smartphones, and any numbers based on symbian as a real smartphone platform are deceptive. Hank ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Buglabs
I dont know what you mean by whether they have modules yet. Clearly they are not shipping yet. On the other hand I saw (and held) modules in person, albeit not plugged in and demonstrated. They said these were production modules. It sounds like hardware is frozen, or close to frozen. Moreover, If what they told me in person (and whats on their website) is true, they will be releasing four modules by the end of the year. But none of the modules they are publicly discussing is a cell module. Hank On 9/18/07, Dean Collins [EMAIL PROTECTED] wrote: Not sure if they really have any modules yet – from the discussion yesterday it's still very alpha days at the moment. Regards, Dean Collins Cognation Pty Ltd [EMAIL PROTECTED] +1-212-203-4357 Ph +61-2-9016-5642 (Sydney in-dial). -- *From:* [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] *On Behalf Of *hank williams *Sent:* Tuesday, 18 September 2007 9:54 AM *To:* List for OpenMoko community discussion *Subject:* Re: Buglabs On 9/17/07, *Lalo Martins* [EMAIL PROTECTED] wrote: Also spracht hank williams (Mon, 17 Sep 2007 16:17:51 -0400): I also think that using their stuff on openmoko would be incredibly cool. The other thing is they dont have a cell module yet - just wifi. Hank ___ 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: Buglabs
On 9/17/07, Lalo Martins [EMAIL PROTECTED] wrote: Also spracht hank williams (Mon, 17 Sep 2007 16:17:51 -0400): I also think that using their stuff on openmoko would be incredibly cool. I was kind of thinking in the opposite direction... running OpenMoko (the software platform) on their stuff :-) I think it could go both ways but their software stack is much more high level. Its java based and essentially each module looks like a webserver that knows how to talk to the hardware. Openmoko is essentially a linux distribution, and their stuff is really an API and communications model that sits on top of a linux. Yest they have to do their own low level stuff like openmoko, but they have an abstraction layer that openmoko doesnt. The other thing is they dont have a cell module yet - just wifi. Hank Maybe if Buglabs is successful, FIC/OpenMoko wants to make a GSM BugModule ;-) (or better, a connect module: GSM+BT+WiFi) best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. - personal:http://lalo.hystericalraisins.net/ technical:http://www.hystericalraisins.net/ GNU: never give up freedom http://www.gnu.org/ ___ 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: Buglabs
Like I said I'm actively looking to support these guys as I think it's a great concept but…..long way to go. Are you saying you think Q4 07 is a long way to go, or do you just think they are being overly optimistic. Hank Regards, Dean Collins Cognation Pty Ltd [EMAIL PROTECTED] +1-212-203-4357 Ph +61-2-9016-5642 (Sydney in-dial). -- *From:* [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] *On Behalf Of *hank williams *Sent:* Tuesday, 18 September 2007 10:30 AM *To:* List for OpenMoko community discussion *Subject:* Re: Buglabs I dont know what you mean by whether they have modules yet. Clearly they are not shipping yet. On the other hand I saw (and held) modules in person, albeit not plugged in and demonstrated. They said these were production modules. It sounds like hardware is frozen, or close to frozen. Moreover, If what they told me in person (and whats on their website) is true, they will be releasing four modules by the end of the year. But none of the modules they are publicly discussing is a cell module. Hank ___ 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: Buglabs
On 9/18/07, Dean Collins [EMAIL PROTECTED] wrote: Well Q4 07 is either 12 days away or 120+12-1 for December 30th depending on how you look at it J If they have just opened up the closed beta process this means they have some time to go before being available for retail. Acutally Q4 07 means they have until December 31. ie around 3 months. To me, that doesn't seem like a long way to go, but thats why I asked. Language to one person means one thing and may mean something else to someone else. Hank ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Buglabs
Yes, They are making some very cool stuff. Its a modular consumer electronics platform. I went to one of their mixers a few weeks ago. I think it is going to be a hit. I also think that using their stuff on openmoko would be incredibly cool. Hank On 9/17/07, Dean Collins [EMAIL PROTECTED] wrote: Anyone know about this company? http://www.buglabs.net/products There is a Yi-Tan conference call about them in 5 minutes but I've never heard of them. Regards, Dean Collins Cognation Pty Ltd [EMAIL PROTECTED] +1-212-203-4357 Ph +61-2-9016-5642 (Sydney in-dial). ___ 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: mailing list management
Harald, While I agree with your argument that no header is the standard for FOSS, this is not the case for the reply to issue, which you did not address. As I said earlier, the Apache groups (perhaps the largest FOSS umbrella) for example, and many (most?) others do not have the default reply-to going to the individual. Part of the reason for this is that it is bad user interface for the default behavior to be one that is used perhaps 1% of the time. Most people generally want to reply to group. Your default should be the most commonly accessed option which is why your design decision on this matter is not only not standard, but is, I believe, the minority design, even in the FOSS community. Regards, Hank On 8/19/07, Harald Welte [EMAIL PROTECTED] wrote: Hi! For the various reasons cited in the many mails on this subject, there is a general concensus in the FOSS community and among maybe the hacking community in general _not_ to add subject prefixes. Filtering can be done on List-ID header (or with other commonly-used list software on Mailing-List or even the Sender-header) The vast majority of all FOSS-related mailing lists that I've ever seen follow this policy. We see no reason why we should deviate from that. -- - Harald Welte [EMAIL PROTECTED] http://openmoko.org/ Software for the world's first truly open Free Software mobile phone ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: mailing list management
... why should all mailing lists change their standard? behaviour only cause some minority? (poll?) of email clients dont support these functions ? I will no longer discuss the merits of this issue, but I feel obliged to address two factually inaccurate statements. 1. Gmail is not a minority mail client. It may be closer to a majority client. 2. Most mail lists and mail list system do reply to list when hitting reply, not individuals. Specifically Yahoo Groups by far the largest such system on the net, but also super techie groups like apache.org's lists work this way. I am on the apache hadoop, lucene, and the axis list and I suspect all the apache lists work this way though I honestly haven't had time to try every single one. In any case clearly just based on yahoo and apache, you cannot say that reply to individual as a default is standard. I am on a wide range of lists that include social (meetup.com) Adobe flash/flex/video server development, web services, 3D technologies, linux tools related, etc. This is the *only* list which I am on which replies to individuals. What I do see is that the *hardcore* linux geeks (no offense intended) prefer this. Perhaps it is a badge of honor. But it is, just to be clear, not standard except perhaps in the most techie linux-internals-focused circles. Hank ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
mailing list management
Oops again. That reply to thing is a bitch. -- Forwarded message -- From: hank williams [EMAIL PROTECTED] Date: Aug 14, 2007 4:52 PM Subject: Re: mailing list management To: Daniel Mewes [EMAIL PROTECTED] I use pager notification for my e-mails and text paging in Germany has a very limited message length. Wow. now thats a great target design platform for a mailing list. lol. Hank ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Fwd: mailing list management
Do the people suggesting these changes think that they really know better about how this list should be set up? Yup. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Import Duty - I have refused my delivery.
Wow, what a classy thing - to start a flame and then admit error. Hats off to you. Regards, Hank On 8/4/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Sean: I've decided I'm just going to swallow the charge - applied by Customs to the value of the kit as declared on the waybill. It's not right for me to give you extra stress at this time, nor do I want extra stress arguing about it with everyone. Sorry for the blip! My shipment is to be redelivered Tuesday 07AUG. Thanks, David. From: Sean Moss-Pultz [mailto:[EMAIL PROTECTED] Sent: Fri 03/08/2007 14:29 To: David Prior Cc: [EMAIL PROTECTED]; community@lists.openmoko.org Subject: Re: Import Duty - I have refused my delivery. On 08/03/2007 [EMAIL PROTECTED] wrote: [snip] the US all the time, I do know what to expect when I import. Importation of computer devices and peripherals to the EU is indeed both VAT and import duty exempt - it appears that the description of the goods, compounded with the value statement, has led to this issue. It is indeed OpenMoko's error in not understanding the rules and I hold them responsible for not disclosing that fact. David, I'm sorry for your troubles. We are doing our best to get these devices to everyone as fast and (under the current circumstances) as cheap as we can. I can assure you that the harmonized code is correct on the invoice. Also, these are standard UPS Worldship invoices, so I'm really at a loss as to what we did wrong. Please let me know what exactly what our mistake was and I will personally make sure this is fixed. We're committed to getting these kind of issues resolved so phase 2 can be a really smooth experience for everyone. So I really need your help here. -Sean This email and any files attached are intended for the addressee and may contain information of a confidential nature. If you are not the intended recipient, be aware that this email was sent to you in error and you should not disclose, distribute, print, copy or make other use of this email or its attachments. Such actions, in fact, may be unlawful. In compliance with the various Regulations and Acts, General Dynamics United Kingdom Limited reserves the right to monitor (and examine for viruses) all emails and email attachments, both inbound and outbound. Email communications and their attachments may not be secure or error- or virus-free and the company does not accept liability or responsibility for such matters or the consequences thereof. General Dynamics United Kingdom Limited, Registered Office: 100 New Bridge Street, London EC4V 6JA. Registered in England and Wales No: 1911653. ___ 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: Brainstorm: less functionality per device, more devices
A company called bugLabs is working on this concept. http://www.buglabs.net/ They have not publicly announced the details of their product, but the idea of modular (probably open source) pocket consumer electronics seems to be their focus. Hank On 7/3/07, Jonas Meyer [EMAIL PROTECTED] wrote: I just recently got my first bluetooth headset. This is only relevant because it got me thinking. The typical cell phone (including the Neo) is built upon the idea of putting as much functionality as possible into one device. And manufacturers have gotten very good at this. What if one took the UNIX approach to hardware development. Instead of monolithic do-everything devices, create many single purpose devices that do their jobs very well, and can be chained together. This approach has some advantages: 1) Easier (and cheaper) to upgrade. Need more processing power? Add another or a smarter cpu pebble. Need gps? Add a gps pebble. Need storage, add a storage pebble. Need a camera, add a camera earring or watch or ring. 2) Cheaper initial investment. A basic phone could be a headset, a gsm transmitter, and little tablet UI device. 3 (or maybe you stick the gsm transmitter in the ui, so 2) little cheap devices that can be sold for tens, rather than hundreds of dollars. However, as a consumer desires more functionality, they buy more devices. 3) Carry only the functionality you need. Are you going clubbing? Probably won't need that gps unit, or the media player. Heading out to the woods? Ditch the second cpu, but grab an extra battery. 4) Interoperability. By opening the standard up to many manufacturers, a more robust ecosystem is created, and the entire platform improves. Disadvantages: 1) More items to lose. Perhaps they could snap together, like legos, or be carried in some sort of bag all together? 2) Intra device bandwidth is at a premium. Bluetooth 3.0 is probably necessary if you want to keep your storage in a separate device from your cpu or your ui. This in turn creates extra demands on batteries. Again, perhaps a standard snap together interface can carry power and data. 3) Potential incompatibilities. Different devices might not speak the same protocol, even if they are supposed to. This can be disastrous when your cpu is not from the same company as your storage. 4) Potential security risks. Running all that data over the air means it is easier to read it, in the event that your encryption fails. And since encryption is likely to be run off a chip, rather than a more general purpose cpu, security holes are more difficult to fix. 5) Harder to write the software. Obviously, this makes your OS about 1000% more complicated. Anyway, it seems like it COULD be an interesting sort of thing to try. Jonas ___ 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: Flash Player 9 on OpenMoko?
The flash situation is interesting. I spend a large part of my time doing flash development, and the pervasiveness and importance of the flash platform creates a really serious problem with the religious perspective about everything openmoko being open source. Flash is a critical element of the internet ecosystem and it is closed source. Gnash is *not* a solution. I can tell you this as someone who spends hours a day in the flash environment. Flash is moving far too fast to use only a platform that is **years** behind for the benefit of being purely open source. The flash development community, of which I am a part, is aggressively taking advantage of new features and the adoption of the latest version (flash 9) is faster than any previous version. As I see it, not having a real version of flash makes openmoko much less disruptively competitive than it might otherwise be. Developing apps with flash really allows for the creation of much more sophisticated software much more quickly. Of course flash 9 is currently not compiled for ARM, but that will come. I just think that it would be incredibly valuable to the platform to get flash 9 as soon as possible and not to worry about the open religion in this arena. If the internet can survive with some closed source apps, openmoko can too. Hank ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Flash Player 9 on OpenMoko?
On 3/22/07, Philippe De Swert [EMAIL PROTECTED] wrote: Hi, First of all I do not intend to flame you. So no hard feelings towards you. However there are some important points regarding flash that lots of people tend to ignore. So you admit being one of those evil people that make websites inaccessable. Ah yes, you don't mean to flame, but flash and I are evil. Well in any case you have just invalidated everything else that you say which follows. Not only for people who think flash is evil because it is closed, but also for those who think the flash licence is unacceptable (like me. No I do NOT want to grant Adobe access to my computer because I install their flash plugin.) or for the blind. Flash is a critical element of the internet ecosystem and it is closed source. Gnash is *not* a solution. I can tell you this as someone who spends hours a day in the flash environment. Flash is moving far too fast to use only a platform that is **years** behind for the benefit of being purely open source. Well gnash is improving, it is really slow though and eats lots of resources. But apart from the missing features due to lack of documentation, flash itself is unsuitable for embedded systems due to being a huge resource hog. The proprietary flash plugins on the Nokia 770 and n800 are so slow just because they don't have so much processing power to spend on it. Flash btw kills battery life on those devices, just as it does on my laptop and will on an OpenMoko phone. A quick glance at the system requirements (for Linux as they seem to be a bit lower for Windows). 800Mhz cpu (which means x86 based with floating point), 512Mb of ram and 128Mb of graphics memory. Lets look at the Neo. 200Mhz ARM WITHOUT floating point, 128Mb ram and no real graphics memory... Adobe produces a mobile version that is not yet flash 9 compatible. The resource requirements are different. As I said before flash 9 is not ready for mobile (ARM) devices. The flash development community, of which I am a part, is aggressively taking advantage of new features and the adoption of the latest version (flash 9) is faster than any previous version. Unless you work for Adobe you are part of the flash user community... How stupid. I am a developer. Meaning I write code in actionscript and flex. I am a part of the developer community because I have actively contributed to flash *developer* communities for the last 4 years. I do not consider myself a flash user any more than I consider myself a C++ user. I am a flash developer and a C++ developer, and I am part of the community of flash developers who talk every day about the tools (both open and closed source) and help each other solving technical and development issues. Perhaps this concept is foreign to you. As I see it, not having a real version of flash makes openmoko much less disruptively competitive than it might otherwise be. Which is partly true. However downloading flash over GPRS is not very interesting. And it would only be disruptive because unfortunately so many people are expecting people to install flash. What would be really disruptive is an standardized and open framework that allows the same things as flash which everybody could with relative ease make use of. Something that might be supported by default in a browser. Adobe has a stranglehold monopoly on this flash thing at the moment. Which makes them no better than Microsoft messing up the HTML standard with IE and Frontpage. Developing apps with flash really allows for the creation of much more sophisticated software much more quickly. It is true that flash has some nice features, however using something that is open and standardized has a lot more possibilities. Lots of things that can be done with flash could also be done with SVG etc... Many more things *cant* be done with SVG that can be done with flash. actionscript, video, audio, and incredible tools are all things that SVG cant compete with from a capability or productivity perspective. Of course flash 9 is currently not compiled for ARM, but that will come. I just think that it would be incredibly valuable to the platform to get flash 9 as soon as possible and not to worry about the open religion in this arena. As I pointed out there are also valid technical reasons like performance and battery life. Also licensing, access to the source code for optimisations and patents are an issue. Its clear you know nothing about flash, which in its current mobile version is implemented on 200 million devices currently world wide. But the religion about open licenses is in my view counterproductive since there is no open platform that comes anywhere near flash. Gnash is the closest and it is in the stone age. So optimizing something so old and out of date is hardly a good trade off. And I have no idea what patents have to do with this. You just seemed to throw it in to be open source religion compliant. If the internet can survive with
Re: Flash Player 9 on OpenMoko?
On 3/22/07, Henryk Plötz [EMAIL PROTECTED] wrote: Moin, Am Thu, 22 Mar 2007 12:31:03 -0400 schrieb hank williams: As I see it, not having a real version of flash makes openmoko much less disruptively competitive than it might otherwise be. Developing apps with flash really allows for the creation of much more sophisticated software much more quickly. Of course flash 9 is currently not compiled for ARM, but that will come. I think nobody would seriously object having an optional, downloadable, binary flash add-on. I think currently not compiled for ARM is a much bigger problem than it seems. Currently Adobe's Flash is not even available for x86_64. When I was wondering why nobody at Adobe seems to have 64bit compiler I was told that part of the problem is that they use a JIT compiler for Actionscript which happens to put out x86 opcodes. Good luck trying to get them port that to ARM. Actually, the new actionscript JIT complier/interpreter in flash 9 (the only one with a JIT - the older ones dont have it) is now open source and is available on the mozilla website. It is already designed to output ARM code as it was recognized that mobile was a critical part of their future. That said, I am sure there is lots of work yet to do to optimize and recompile the latest flash core for ARM. I am just saying the JIT compiler isnt where the problem is. Regards, Hank ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Sorry... Re: And please use a emailclients with working Reference Re: gmail users CC'ing
I just read the other email which started this discussion about gmail and think I understand the problem. The problem is with the list. I am on 15 tech mailing lists, and this is the only one which, if I in gmail say reply to replys to the sender and not to the list. I NEVER*** want to reply to the individual when responding to a post on the list. If I say reply to all it puts the senders address in the to field and the openmoko address in the cc field. I strongly suspect this is the cause of unwanted cc's. Again, out of 15 lists, this only happens for me on the openmoko list. Now I have read that some consider this a feature. And perhaps there are benefits I don't understand. but with 25-50% of the tech mailing list readers using gmail, having a list feature that causes this kind of a problem should probably be reconsidered. I do not believe this is something that can be worked around in gmail other than by manually fixing every send to this list (which I do). I would ask the openmoko team to consider fixing the mailing list parameters in order to fix this problem. Regards, Hank ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: Sorry... Re: And please use a emailclients with working Reference Re: gmail users CC'ing
On 2/13/07, Robert Michel [EMAIL PROTECTED] wrote: Salve hank! Thank you for your feedback ;) On Tue, 13 Feb 2007, hank williams wrote: You are misinformed if you believe that gmail does not handle threads properly. Maybe, it would be nice when other gmail users explain gmail users how to use gmail proper, instead of that I have to inform myself about gmail. That would assume there is some improper way that people are handling gmail. I disagree. In fact I think it is the best product on the market, free or otherwise, for handling threads. The problem which you are referring to has nothing to do with gmail, but with the fact that some people mistakenly delete the re: from the mail header when responding. This is only a backup for threading mails - threading by subjects. The better way is threading with working References in the header. hmm... guess those Google guys aren't smart enough to handle mail the better way. With your way, even if you change the subject it would be part of the same thread. That would make for a really easy time finding emails where you *meant* to change the subject and create a new thread. Q: Is gmail killing this reference line in the header when the Subject does not begin with re:? Realy? Can you test this? BTW, it seems that e.g. Ryan is using Apple Mail as MUA. (Mail user agent = email client) AFAIK Apple mail can set References in the header. So the question stil is, what make the References missing for Ryan by using gmail. Ahh... this is interesting - apple mail + gmail = problem I have no idea since I use the web client. Regards, Hank ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: This explains the CC'ing but what's about the missing references? Re: Sorry... Re: And please use a emailclients with working Reference Re: gmail users CC'ing
On 2/13/07, Robert Michel [EMAIL PROTECTED] wrote: Salve hank! This explains the CC'ing. On Tue, 13 Feb 2007, hank williams wrote: I just read the other email which started this discussion about gmail and think I understand the problem. The problem is with the list. I am on 15 tech mailing lists, and this is the only one which, if I in gmail say reply to replys to the sender and not to the list. I NEVER*** want to reply to the individual when responding to a post on the list. Never say never - I would not call it the problem is with the list I would call the problem is with the user not looking who they are sending an email. If you want the default behavior to be one that encourages the least likely intended result then you are right. In fact, perhaps the default should always be to send the email to George Bush, and then you can just change it to who you really intend! But seriously, the point is that default behavior matters. It should default to the most commonly needed situation, not an edge condition. This is the way *all* my other 14 mailing lists work. Back to the brocken threads - this is not explaining why some gmail users hasn't a proper emailheader with working Reference. Does you have an idea for this as well? As I said in the other thread, I cant speak to what might go wrong with some incorrect setting in apple mail combined with gmail. Regards, Hank ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: Sorry... Re: And please use a emailclients with working Reference Re: gmail users CC'ing
Thanks Richard. I have read this before, but forgot the official name of reply-to munging. I think your analysis is correct. The only thing I would say is that the non-standards compliant way of handling list administration is in fact, as far as I can tell, the standard way that at least the many high volume lists that I am on behave. Its kind of like being with a woman. You have to decide whether you would rather be happy, or be right. They are mutually exclusive! Regards, Hank On 2/13/07, Richard Bennett [EMAIL PROTECTED] wrote: On Tuesday 13 February 2007 15:28, hank williams wrote: Again, out of 15 lists, this only happens for me on the openmoko list. Now I have read that some consider this a feature. And perhaps there are benefits I don't understand. but with 25-50% of the tech mailing list readers using gmail, having a list feature that causes this kind of a problem should probably be reconsidered. I do not believe this is something that can be worked around in gmail other than by manually fixing every send to this list (which I do). I would ask the openmoko team to consider fixing the mailing list parameters in order to fix this problem. Hi, It's called 'reply-to munging', and it is as contentious as 'gnu-linux or linux', 'Allow proprietary binaries or only OS code', and many other things. Here's the details: http://www.unicom.com/pw/reply-to-harmful.html Basically all good email clients support mailinglists that abide by the protocols, with notable exception of Outlook and Gmail. So many list managers allow 'reply-to munging' to make life easier on those users, while all other users have to cope with the broken protocol as best they can, which they usually do pretty well. Sourceforge mailinglists especially push admins not to allow reply-to munging, to encourage to email software to support the protocol correctly, but I have seen many a sourceforge list dwindle to a trickle, because replies were not arriving at the list anymore, only to the original poster. It is difficult to promote working to standards, and then setup your email list in an non standard fashion, but in the same way we support MP3 as well as OGG, it might be better to be pragmatic about this issue, and allow reply-to munging, in the spirit of making the list as accessible and enjoyable to all its users, and to restrict arguments to important topics, not petty list issues. Cheers, Richard ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: Just a personal feedback - I'm just writing for me Re: And please use a emailclients with working Reference Re: gmail users CC'ing
Oh, and one more thing. You've been told this by others before, but you igore it so I will say it again. You keep changing the subject of your posts, and whether you like it or not you are screwing up gmail threading, and I suspect threading from other programs. That wouldnt be so bad if your new subjects made any sense. Which they dont. This is something that you can fix. And given the volume of your posts it makes the list much harder to follow. Of course I guess you would prefer that we gmail people just go away anyway, so why listen to us. Hank ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: Sorry... Re: And please use a emailclients with working Reference Re: gmail users CC'ing
Reid, Your test doesnt work when you are looking at messages that you yourself sent. Messages you send from a given thread are always in the same thread, but messages from someone else from the same thread with a different subject are not put in the same thread, and that is the problem on the list. Regards, Hank On 2/13/07, Reid Thompson [EMAIL PROTECTED] wrote: On Tue, 2007-02-13 at 12:00 -0500, hank williams wrote: On 2/13/07, Reid Thompson [EMAIL PROTECTED] wrote: On Tue, 2007-02-13 at 10:02 -0500, hank williams wrote: hmm... guess those Google guys aren't smart enough to handle mail the better way. With your way, even if you change the subject it would be part of the same thread. I believe that is proper -- to remain part of the same thread. To create a new thread, start with a new email -- do not reply to a current thread with an altered subject. Well, it depends on how you define proper. Again, to me this is about user interface, and what is expected behavior. I dont think your average (non-programmer) would think that a new message with a a new message no, which is what I said to do if you want to create a new thread -- but the conversation was about replying to a previous message and changing the subject expecting it to start a new thread -- which does not work. different subject would be in the same thread. My gmail account does this, so anyone using gmail should expect it after seeing it occur -- see below. Replies to emails with changed subject show in the same thread/conversation, not new or separate ones. More importantly, the interface revolution in gmail is the grouping of threads by subject. Not based on what I just did ( subject threading may be a fallback mechanism as mentioned earlier -- evolution has this 'option' also). This is one of the reasons that so many people love gmail. It makes what used to be a much more complicated thing much easier to follow. I think people are voting with their email accounts and by this measure people in mailing lists *love* the gmail design. The high percentage of gmail use vs aol or hotmail or outlook or whatever is no coincidence. Regards, Hank In my gmail account: create a message with subject Test Thread - body Test Thread. Send it. Reply to it from gmail account, Change the subject to Test Thread Two - body to test thread Two, Send it. Reply to Test Thread Two, Change subject to Test Thread three - body to Test Thread 3, Send it. View Test Thread Three,,, see that Google 'threaded' all three messages as one thread/conversation, not three separate ones. ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
what is the difference between openMoko and windows mobile based phones
What I mean by this is that it seems everyone is saying that the big difference is that you can get 3rd party *real apps* on the phone. And this is said as if windows mobile phones like moto q, blackjack and pocket PC phones wont allow this. Now I am not saying open source isnt great. But from your *average* users perspective I would love to hear the advantages of the open source for these devices. Is this just a geek issue? It seems like most of the apps described on this list could be done with any of the windows mobile phones. I'd just love, for my own edification, to hear why this is wrong. Hank ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: what is the difference between openMoko and windows mobile based phones
On 1/18/07, Andreas Kostyrka [EMAIL PROTECTED] wrote: * hank williams [EMAIL PROTECTED] [070118 14:01]: Beside the point that an *average* user doesn't see the potential of open source on a mobile - what are your experiances and demands on a smart phone? When you look at the devices that you know or use(d): - What does you miss most? - What does you hate most? - What does you like/used most? well honestly my biggest issue with phones in general is not features but execution. The iPhone is a good example of executing well on features that have been around for years. My one concern with open source is that it is great at delivering features, but historically not great at UI. This is because big open source projects are often done by teams where everyone can do what they want. This tends to mean there is no singular unified design vision. This is fine for features for the most part because we can That's technically speaking an out-of-date vision of opensource develepment. I wouldn't consider KDE inconsistent. actually, one might argue that KDE does better then Windows based environments on this score. uh... sure. I dont want to open a windows vs osx vs linux/kde debate here so i'll leave it at that. all more or less agree on how to implement wifi or an encryption scheme or whatever. Or if we disagree we can implement five different ways as APIs and let the market decide. But good UI doesn't work that way. I guess you haven't used the embedded Linux UIs. They are more consistent then some commercial phones. I dont know what this means. What are you talking about... TiVo? Linux UIs and open source UIs is not the same thing. Lots of people (like TiVo and hundreds of other companies) build proprietary apps/UIs on top of linux. That doesn't make them open source. And even if something is open source, if its not done by an open source committee it will generally be better. So the iPhone has a design czar - jobs - and that means that forward thinking design gets done in a unified way. This issue may not effect nope. You are assuming that it will be executed well. nobody has seen an iphone for long enough to fool around with it. From seeing the details, the iPhone is something that not even my wife will want to have, everything that I've seen till now suggests that it will be a nice (smart)phone, but not necessarily nicer than better existing phones, with an iPod embedded. Well, your mileage may vary, but obviously lots of people, press, analysts, etc think its pretty significant. Perhaps it will just be one of many - only time will tell. But somehow I doubt it. Slashdot has certainly gotten a lot of humorous mileage out of the prediction that the iPod wasn't going anywhere. And it will put the carriers interests in front of the users interests. OpenMoko, at least in the beginning, since a private company is doing the design. But when the design process becomes public, the features and design by committee thing might be an issue. It's the Linux-will-fork story all over. Empirical evidence suggests that your fear won't happen. Nope. I don't have any fears and wasn't talking about forking. I am just saying that often, too many cooks spoil the stew. But the bottom line is that my biggest problem with phones is that they are just not designed well. The pretty much all suck! Well, that's not helpful. Design a better, give hints, improvement ideas. It's hard to give you the perfect phone, because you don't specify what you want. I'm not trying to help. I am not intending to be a phone designer. I was asked a question, and so I am stating my honest opinion about phones. Ideally, what I want is a good UI. This is of course, subjective, and so there is no single answer. I can only say that the current phone marketplace has not focused on UI at all. Motorola's UI is inexcusable. Palm apps look the same as they did in 2000 - and still no multi-tasking. Windows mobile is ugly, and looks like they tried to transplant a desktop into a phone. For me to suggest specific fixes is a little like asking why I dont want to date a pot bellied pig. You know, what if we put a little lipstick on it. wouldnt it be good enough then? Phones need to be re-thought. Perhaps OpenMoko is a solution - haven't seen a demo so I don't know - which is why I asked my initial question. But since no one here other than Sean has seen it, perhaps I wont get anything other than generic linux fan responses. Hank ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: what is the difference between openMoko and windows mobile based phones
Thanks. Great, very helpful answer! Hank On 1/18/07, Sencer [EMAIL PROTECTED] wrote: On 1/18/07, hank williams [EMAIL PROTECTED] wrote: What I mean by this is that it seems everyone is saying that the big difference is that you can get 3rd party *real apps* on the phone. Actually I think most people are saying, that you have full access to a) the hardware and b) to the sources of all applications that run on it. And not only do you have access to the source, but the freedom to change and redistribute the changed application. That's the deciding factor. 3rd party apps in general have been a distinct feature of every smartphone so far, the only reason it's being discussed today at all, is because Apple is disallowing it. Now I am not saying open source isnt great. But from your *average* users perspective I would love to hear the advantages of the open source for these devices. By average user, I assume you mean those people that do not program or administer complex software. Well, let me try it with an analogy: What benefit does somebody have from freedom, when he is not interested in making use of it (i.e. working the same job all his life, voting the same party no matter what, etc.) because his main objectives - feeding his family, doing X or doing Y - are equally possible under a repressive regime and in a free country? It's simple, you'll likely still be better of in the free country, because the freedom enables improvements that you will eventually benefit from, even if you never specifically worked (in a hands-on way) towards those specific interests. Now that doesn't mean that as soon as there is freedom, you automatically and directly are better of if you don't make use of it; it's merely the beginning of a process. So today, and for the 1st generation devices that run openmoko, you may (as an average user) not reap immediate benefits, but you will help enable a success through freedom, in that the other people that do have the interest and/or skill necessary to turn that freedom into a benefit for everybody. Is this just a geek issue? It seems like most of the apps described on this list could be done with any of the windows mobile phones. I'd just love, for my own edification, to hear why this is wrong. For example the PIM/Messaging applications (which areguably are the core of a smaratphone) are not limited by what the device-makers are able and willing to develop. You could add sending SMS over HTTP, sending voice-mails via E-Mail, automatically sending notifications that you are delayed for appointments and for how long (by checking the calendar, the GPS coordinates, and the average speed of your movement). Now the point is not only, that it is possible to write these applications, but that the functionality can be seamlessly integrated into the existing base-applications, and everybody is able to benefit from it. With bluetooth and usb on board, there is a very real possibility of expanding the possibilites in a way that is simply not possible on windows mobile or symbian, because you simply cannot access certain aspects of the phone. As a simple example: Many older wifi-cards that can do WEP but can't do WPA are limited due to software, not hardware reasons. But given that you already paid for them there is no incentive to do that work. Similar with bluetooth functionality, many early phones (looks at nokia) only had a very limited support for certain bluetooth functionality (profiles), and that limitation was due to sotware reasons, not hardware reasons. And interested people that had the time and skill still couldn't do anything about it. People were simply stuck with a castrated phone. [Quoting from a later mail:] This is because big open source projects are often done by teams where everyone can do what they want. This tends to mean there is no singular unified design vision. That's not necessarily the case. In fact I know plenty of counter examples. Open source does not dictate _how_ the software is to be developed or designed. So when you say: But good UI doesn't work that way. that is correct, but it's not necessarily a statement about open source in general. But the bottom line is that my biggest problem with phones is that they are just not designed well. The pretty much all suck! Well, I do not think that open source is a huge enabled in that respect either. So while it doesn't necessarily have to be better or worse than closed source, the code-licence simply isn't a good indicator to judge the likely quality of the UI. Regards Sencer ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: what is the difference between openMoko and windows mobile based phones
It's the Linux-will-fork story all over. Empirical evidence suggests that your fear won't happen. Nope. I don't have any fears and wasn't talking about forking. I am just saying that often, too many cooks spoil the stew. Not really. What you are refering to is that not all software is UI-wise enduser ready. Yeah, these packages will be on the Neo too. But OTOH, I've seen many enduser friendly packages happening in the Linux space, so only time will show. You are entitled to your opinion but not mine. Please don't tell me what I was saying or should be saying. I was not referring to anything other than what I said. I believe too many cooks spoil the stew, which is often a problem in open source, in my opinion. Its also often also a problem inside corporate development efforts. When there is no clear and absolute leadership, product design suffers. This is of course my opinion, based on my 30 years of software development. It is, nevertheless an opinion. Your mileage may vary. Regards, Hank ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: what is the difference between openMoko and windows mobile based phones
I should clarify and say the issue that I am refering to specifically relates to UI/design. There are very few people that are good at it, so when those good people are not in absolute control and overly influnenced by committees, the design suffers. The good news about most open source products that have been successful is that they are more often API driven. Linux, the apache stuff, languages, etc, etc. Honestly, I havent yet seen an open source product whose UI I really like except firefox which is darned near commercial in the way that it is run. Graphics programs, Interface shells, video programs... I am not going to name names because then someone will either get upset or start misinterpreting. But I have yet to see something that I thought lived up to the best proprietary interface/UI designs. I cant say I have seen everything, but I have seen a lot. I think Open Source kills when it comes to creating high quality maintainable code. But I personally dont think the community process works as well for design and UI. I know people will disagree, and I really dont want to get into a back and forth with people getting upset and trying to prove me wrong. Its just my opinion. And of course there are always exceptions. Oh and by the way, I am not saying OpenMoko will have this problem. It specifically relates to the community process of development. But satisfying everyone's requests/demands in a UI is a sure sign of trouble and is much more prevalent in a more democratic process. Depending on how they manage the process and the form of the leadership it may not be an issue at all. They just have to be good designers themselves, and be willing to say no when warranted. Regards, Hank p.s. These are just my opinions. I have said it before, but many people have different perspectives on what it takes to make great products. I am not sure why anyone would care about my views on this subject. On 1/18/07, Richard Franks [EMAIL PROTECTED] wrote: On 1/18/07, hank williams [EMAIL PROTECTED] wrote: I believe too many cooks spoil the stew, which is often a problem in open source, in my opinion. Its also often also a problem inside corporate development efforts. When there is no clear and absolute leadership, product design suffers. This is of course my opinion, based on my 30 years of software development. It is, nevertheless an opinion. Your mileage may vary. I see this being true for monolithic projects such as a kernel, or an office productivity suite.. I would say that it's debatable whether the same holds true for the types of micro-application which are going to be created using the OpenMoko API (which as a foundation does appear to have clear leadership). Monolithic product design I believe arose from distribution and OS layer limitations - when you simply couldn't download weekly updates or patches, the product had to get it right the first time. It didn't always happen that way of course, but there was no real alternative as the network infrastructure hadn't been built up yet. Communication accelerates standardisation, and standardisation paves the way for smaller tighter applications. Given the diversity of interests shown on this list, I don't think we'll run into the too-many-cooks issue any time soon. Out of interest, which Open Source projects have fallen victim to the too-many-cooks problem? Richard ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: Neither iPhone or OpenMoko are revolutionary
On 1/17/07, Attila Csipa [EMAIL PROTECTED] wrote: On Thursday 18 January 2007 00:09, Renaissance Man wrote: Why does no organisation (even Apple) seem to get it that the mobile communications revolution is through VoIP via WiFi. This is the killer app. Could you share with us WHY do you think that is the killer app ? (for DATA applications, I understand, but specifically for VOICE) From what I see, VoIP via WiFi in phones/PDAs is the re-creation of GSM technology but without the phone-orientedness of GSM networks. Technology wise, you seem to have worse autonomy, worse coverage, extra HW cost, bluetooth interference, limited and country-specific list of channels, but hey you have the extra bandwidth you will never need for VoIP ! Pricewise, it's bust again. No carrier will subsidise such phones, thus they will be more expensive (defeating the purpose of being cheaper) and even if they would, with different dialplans and GSM gateways, the price difference becomes really slim. VoIP might come into play if you had 3G bandwidths, but again, price works against you except for the most expansive direct calls to the other side of the world. Of course, all of this from my local perspective, maybe in the UK it's different :) You are absolutely right. I just didnt have the energy to type all of that. Glad you did! Hank ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Is anyone on this list in NY
My company is developing a product and is looking for programmers to develop software for this and other mobile linux platforms and would love to talk to people - particularly in the new york area. Regards, Hank ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Shiny geek toy?
I think you are generally right, with some caveat. It's really a chicken/egg problem. Will the carriers come first, or the applications? It is possible that in 2007, linux based extensible phones will become the rage. We have greenphone, Access, and open moko. But if carriers feel that these platforms threaten their lock on the platform, they may not adopt. In that case it will require cheap phones and 3rd party software communities to make a killer app that drives carriers to adopt. If this is the case then this first version is really more a shiny geek toy that ultimately motivates some great applicaton(s) that then drive carrier adoption. Regards Hank On 12/6/06, Christopher Heiny [EMAIL PROTECTED] wrote: What exactly is it that we want OpenMoko to be? Do we really want a shiny geek toy? Something that is super cool and technologically advanced, but only nerds will want to hack on? Or should we be working toward a solid OpenSource platform that will encourage other phone manufacturers to build on it and in turn give their work back to the community? To take a recently discussed example: an FPGA is really super cool and flexible and you can do just about anything with one. But the downside is that it is HARD to do that stuff. Even if you, personally, find VHDL or Verilog to be easy to work with and understand, the average engineer working at someplace like Samsung or Nokia (or wherever) will not have the same skills you do. Additionally, it takes time (lots of time) even for skilled engineers to design, implement, and debug new features for FPGAs. Time to market is critical for most phone manufacturers, especially in countries such as Korea where product lifetimes are often measured in months. Yeah, we can trowel on all kinds of creamy technological goodness. Myself, I want a dozen A-to-D channels so that I can use the phone for data collection and analysis in my race car. Honest - that would absolutely rule! But it's not what the customer on the street wants, and it's not what the manufacturer trying to sell to that customer wants. To be a success, in the same way that OpenSource projects like OpenOffice, Apache, Firefox, and others are successes, OpenMoko will have to provide a compelling reason for phone manufacturers to choose it over closed source options such as WinCE, Rexx, and others. Five of the critical enablers to this are: - rock solid reliablity. Anything in the phone should just work, and it must do it every time. - complete functionality. There should never, ever, be a greyed out button in the GUI. Sure OpenMoko might support four different kinds of software radio, but if the manufacturer has to do their own I18N to pick up OpenMoko, they'll choose WinCE instead. - desirable functionality. Does the functionality provided by OpenMoko appeal to the typical human-on-the-street purchaser of this class of phone? Phone manufacturers are going to choose platforms that will help them sell the most phones, even for halo products. - easy to customize or extend. Not just by VHDL aces and Perl wizards, but by the average C/C++/Java programmer two years out of university. His boss is going to choose a platform that plays to his skills (or lack thereof). - support fast development. That young coder in the previous bullet is going to be under a LOT of time pressure. His boss is going to choose the platform that he feels will best help him meet schedule, and will see C++ and Java as enablers, VHDL and Perl as barriers. Shiny geek toys are cool, and I love them. But if we want to rule the world, they don't help that happen. Once we've achieved world domination, we can add all the sparkly bits to OpenMoko we want. Heck, people will probably be doing it for us. Chris ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/cgi-bin/mailman/listinfo/community ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
data speeds
Could someone tell me how fast the phone will be able to transmit data, and what type of networks will be able to deliver that speed? I am developing an internet based music service and part of my model is delivering music on mobile phones wirelessly. But phones have either had a sufficiently fast connection, or had enough storage for what I want to do. I am thinking this may be the first phone which will really work for my application. Regards Hank ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
