Re: How to bring forward the community?
> So what to use? Nothing to use... We should look for what comes after phones and tablets. What's next? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Gta04-owner] GTA04-Custom: EAGLE schematics and board file blueprint for developing expansion/adapter boards
> At least two years ago when I was trying to find software that can open > EAGLE files for Arduino boards I could not find any free software to do > that. Maybe all the major CAD tools are non-free? The two major professional and free EDA tools for PCBs are 1. KiCad http://kicad.sourceforge.net 2. gEDA http://www.geda-project.org There are many other related tools like Qucs (simulation), boom (sourcing), and so on. For a good overview I recommend the Fedora Electronic Lab, see http://spins.fedoraproject.org/fel/#portfolio Or join the Qi Hardware planet at http://en.qi-hardware.com/planet which has a focus on free tools. Cheers, Wolfgang ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko Community Survey 2011 – Results
> The cheapest UMTS Android 2.2 device I can currently get in > Germany is at 129 EUR (most likely from some overstock clearance). Android phones start around 20 USD at quantity 1000 in China, see HEDY as one example of many http://en.hedy.com.cn/product/mobile.htm Probably not with 3G for 25 USD, but that's just another detail and the costs of silicon are not the driver, so even with 3G expect it to be coming down into the sub-50 USD range fast, if it's not there yet (just call or email HEDY if you want to know, really. They have nice spreadsheets with their currently shipping products...). > http://www.businessinsider.com/apple-child-labor-2012-1 Apple is one of the few Western companies that truly care about worker conditions at their factories. The lobby-driven propaganda will go on because it works so well, but it's a flat out lie. Apple has the highest employee standards. Every worker at every Chinese IT industry factory would love to work on an "Apple line" or a product that eventually goes to Apple, because the standards are higher, deep into the supply chain. At least 20-30% higher pay, better dormitories, better food, better safety standards, and so on. Apple is the most humble and truly best company about all the good things they do every day, without wasting time on competing in the talk circus. If you worry about worker conditions, start everywhere non-Apple. Do you care whether this story is true, or whether it suits your needs? > 4. a final observation is that I have to conclude that some of us have > no realistic perception of the market prices. Many people seem to want to pay more for a good headphone nowadays than for a good phone. Maybe it is not clear to most what a 'good' phone should be? HTC bought Dr. Dre's Beats a few months ago to the reported tune of 300+ million USD http://www.engadget.com/2011/08/10/htc-to-buy-a-chunk-of-beats-electronics-keep-dr-dre-in-a-lab-w/ Keep up the good work, HTC! (and don't forget factory workers :-)) Cheers, Wolfgang ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: wiki spam - urgent
> We also need more people to be granted erase permissions, i think it is > clear from the logs who contributes and is eligible. I apologize, it's not clear to me but I will add erase or admin permissions if you give me a list of user names. I do not believe this solves the bigger problem though, even though the spam deletion efforts are truly amazing. Over on the Qi wiki, we have a much more recent MediaWiki 1.18 or so with visual math captcha etc. I think very soon the Openmoko community has to make a decision whether we want to upgrade the MediaWiki version and include the latest spam fighting extensions, or turn the entire wiki into a read-only resource. Thanks a lot for speaking up, and helping keep the Openmoko wiki clean... Cheers, Wolfgang ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [GTA04] When is the next and more powerful openmoko releasing
Ranjit, hey, thanks for noticing :-) > Happen to see the case of Milkymist one[1], it is a transparent > material and would prefer GTA04 embedded in case like that, with full > view of itsy bitsy circuits and chips, don't know how feasible is it. > [1] http://milkymist.org/mmone.html That case was designed and manufactured by fantastic Raumfahrtagentur in Berlin http://raumfahrtagentur.org/ roh from Raumfahrtagentur used QCad for design and laser cutting, the original .dxf files are freely licensed and published https://github.com/milkymist/extras-m1/blob/master/cad/protocase_v8_laser.dxf QCad: http://en.wikipedia.org/wiki/Qcad There are many details that still need improvement, mechanical work is labor intensive :-) Screws, spacers, feet, etc. In the later versions we used dichlormethane for gluing the buttons, the entire button design can probably be improved as well. Werner just milled some out of wood http://downloads.qi-hardware.com/people/werner/tmp/m1butwood.jpg We made a wood version of the Milkymist One case earlier, but wood bends over time, if we really wanted to use wood we would need to find out more about that. http://en.qi-hardware.com/w/images/4/42/Milkymist_One_wood_case.jpg The Milkymist logo is engraved into the inside of the top acrylic, it looks nice but as always there is room for improvement there as well. https://github.com/milkymist/extras-m1/blob/master/cad/milkymist_logo_engrave_v1.dxf http://en.qi-hardware.com/w/images/d/d3/Milkymist_engraved_logo_shot.jpg Bottom line: We learnt a lot, made a beautiful and functional acrylic case (often used for architecture models as well, btw). Many details can and will be improved, the process is all open and uses free tools. Kristian Paul used the same files to make his own Milkymist One case in Bogota, Colombia. In the future we may also investigate milling or lasering aluminum, maybe starting with the same .dxf design files we have right now... If anybody has questions about a mechanical design and manufacturing process using free tools, don't hesitate to join the Qi list at http://lists.en.qi-hardware.com/pipermail/discussion or the #qi-hardware IRC channel on Freenode, webchat http://en.qi-hardware.com/webchat Last but not least - Milkymist One sells for 499 USD plus shipping at https://sharism.cc/milkymist About 40 of 80 run3 units have already sold in the last 3 weeks :-) By buying one you support the entire free supply chain, including Raumfahrtagentur in Berlin. Cheers, Wolfgang ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: AT&T and my beloved Freerunner
> > AT&T has been calling and text'ing for the last 2 months. They have > > informed > > me that my phone will no longer be compatible with their network on Monday > > Aug 29-30, 2011. Has anyone else running into this issue? > > Yes. They eventually started *intercepting my calls* and redirecting > them to a call-centre where someone would insist that they had to > give me a new phone. This happened several times That is so very interesting. Means we have to speed up building our own networks :-) Cheers, Wolfgang ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: FOSS GSM security camera?
> there is also a project on qi-hardware.com: > http://projects.qi-hardware.com/index.php/p/xue/timeline/ The problem with that project is that it's just a plan now, not a single board has been produced. I'd say this is way out until it becomes a usable product (minimum 1 year). And we are not planning on integrating connectivity until even later. > There is a company with copyleft-hardware carmeras (I think some of them have > usb host or can connect to a gsm modem): > > http://www3.elphel.com/index.php Those cameras are awesome and if you are interested in openess, Elphel is the right choice. They are expensive though, for a full 353 camera you easily need 1000-1500 USD, and then you still don't have any GSM connectivity which is what you seem to be mostly after. So by the time you have built a GSM security camera, you will have a big box with lots of manually wired up gear, heavy, with high power consumption, etc. Elphel is about optical excellency (and openess), the founder is a Russian trained physicist and the coolest open hardware guy I know in the world :-) There is also the Frankencamera, a much hyped project at Stanford University with Nokia financing http://www-graphics.stanford.edu/papers/fcam/ But I'm not sure whether they sell anything - I think that leads you further away from what you want. It sounds like your best bet is to start with a phone/smartphone, and hack the camera functionality you need into it. You could even take a good old Freerunner and attach a cheap USB-host webcam to it? (need to solve the mains power problem then, I haven't thought about Freerunner hacking for a long time...) How about a Nokia N900? Cheers, Wolfgang ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: FOSDEM "Hackable Devices" stand
> Wim has asked me to forward that the "Hackable Devices" stand will be > located in Building AW. > > I will show the Openmoko Beagle Hybrid and the GTA04 engineering > sample. David will show the Nanonote. And the Milkymist One VJ station http://en.qi-hardware.com/wiki/Milkymist_One ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Leaving the Openmoko community, new wiki-admin needed
Marko, you did a fantastic job all these many months - under-appreciated - so a big THANK YOU is more than deserved! Good luck with your N900, keep in touch, Wolfgang ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: gta02-core (was Re: OM future)
> a) crack open closed phones by reverse engeneering ? > b) wait for a manufacturer to compromise its pot of gold by producing an open > phone ? > c) put our head in a bag and pretend an iphone or an android is open enough ? > d) aim at building one collectively despite all the unbelievers trying to > discourage >the effort ? d) And Mickey is right :-) Wolfgang On Sat, Feb 27, 2010 at 10:46:47AM +0100, ri...@happyleptic.org wrote: > You can't just separate software from hardware. The fact is you can't have > open software without hardware specs, so open soft and open hard comes close > together. Go try to rebuild a kernel on a nokia "open" phone for instance, > and see what part of the phone hardware still works. > > So what should we do ? > > a) crack open closed phones by reverse engeneering ? > b) wait for a manufacturer to compromise its pot of gold by producing an open > phone ? > c) put our head in a bag and pretend an iphone or an android is open enough ? > d) aim at building one collectively despite all the unbelievers trying to > discourage >the effort ? > > > ___ > 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: gta02-core (was Re: OM future)
raster, > may be waiting forever. if it does happen you'll find yourself comparing to > "iphone 4g" or "nexus 2" or whatever is now out in the 95% of the market. and > then crying why it sucks so much in comparison. that was already the case for > freerunner. like it or not there is an expectation of at least being in the > same ballpark - and as such the big-boys ballpark keeps drifting further away > from the "open" one. i think it's better to make the big ballpark have more I do think there is a 3rd way. The gigahertz/gigabyte race is not the only race in town. Let them have it. A product that just works very well always has a chance. Usability race. Put people and their real needs and real ability to understand and use products in the center. Don't give a damn if everybody around you goes from 2GHz to 3GHz. Again, no hard feelings, let them have it their way. But there is room for slow made (but still high-tech) products. Product cycles that are so long that they allow real feedback to trickle back from users to creators. What we have now is that most feedback is ignored because by the time it reaches the creators, they are already 2 generations ahead. Plus I have to say - the industry is turning into a produce trash throw-away trash industry so fast I couldn't even imagine. Even I gave in now: When I shop for a DVD player, I buy the cheapest. Absolutely the cheapest. No prisoners taken. Inevitably, some X months later, I run into the first (officially bought) DVD with latest-and-greatest DRM tricks on it that won't play. Now I throw away my player and get a new one (of course cheapest again). This system works quite well. But it's insane! The phone industry is cranking out 1+ billion phones a year. Very soon they need to increase the crappiness and "won't fix" features in their products so they have a chance to sell the billions more already in the pipeline. There definitely is another way. Must be. Business opportunity! Let's see how long people will be using their FreeRunners, and how long they will be using their N900... If the FreeRunner would be bug free, I'm sure people would still use them in 10+ years, easily. Way to go gta02-core, and way to go osmocom! Wolfgang On Thu, Feb 25, 2010 at 10:24:22PM +1100, Carsten Haitzler wrote: > On Thu, 25 Feb 2010 03:10:21 -0800 (PST) ghislain > said: > > > > > > > Carsten Haitzler (The Rasterman)-2 wrote: > > > > > > On Thu, 25 Feb 2010 02:36:22 -0800 (PST) ghislain > > > said: > > > > > >> > > >> What about the Ben NanoNote (http://en.qi-hardware.com/wiki/Main_Page). > > >> They showed how the process is done, from the beginning to the end (I > > >> don't > > >> know about the funding). > > > > > > i dont need yet another mini pda. i have a small army of them - that dont > > > replace the phone junk in my pocket. i - and i would say the vast majority > > > of > > > people, dont want multiple things in their pockets - why do u think pda's > > > are > > > dead? they want 1, and the phone trumped all of it for communications > > > reasons. > > > if you dont have a phone you instantly made your potential market a lot > > > smaller. if it doesnt fit in a pocket easily - you just shrunk your market > > > significantly. the more you move your product into a market niche, the > > > more > > > likely it is to fail due to just not making enough volume. open products > > > is > > > already a niche. > > nanonote is a fair bit simpler than a phone - much less RF, no complex fcc > testing (and every body on the planet) to get certification, no modem at all > so > skipping one of the big problem areas - its very simple. its not a bad little > toy - but its a far cry from a phone. ask wolfgang - he's behind nanonote - ex > openmoko. he didnt learn from nanonote - he learned from om to make nanonote. > why do u think its not a phone? because a phone is way more expensive - and > harder. > > > It was not an example of what you need, it was an example of how they did it > > and what we can learn of it. Also, it's not 'yet another mini pda', because > > of it's openness you can use it the way you want, just use your imagination > > and your programming skills :) > > sure - i can do that with my smartq5 too and my other myriad of toys. none of > them replace my phone - and making a phone is complex and expensive. > > > Your statement 'open products is already a niche' is the exact statement I > > heard 15-years ago about open-software. We are just at the beginning, just > > give it some time. :) > > and it *IS* a niche. by open products i mean the ones where you open up > everything - source and hardware and the target market DEMANDS open or you > wont > sell anything. that market will remain niche for a very long time - if ever. > the general "i dont care much as long as it has cool apps and makes calls and > does its job" market will be 95% (number pulled out of arse - meaning vast > majority) of the market. thats that's what the big boys cater to. an
Re: gta02-core (was Re: OM future)
Ghislain, > They showed how the process is done, from the beginning to the end (I don't > know about the funding). even that is open :-) (scroll down to second part) http://en.qi-hardware.com/pipermail/developer/2010-February/001918.html > Although it's not a phone, I do have a working ultra-portable now for a > reasonable price :) (It just needs some software-ports, but that is part of > the fun). Phone is super hard. I finally agree with rasterman on something and share most of what he said earlier in this thread about the economics of getting an 'open' hardware project going. It's tough. And the phone is the toughest of them all. OpenPandora took 4000 pre-orders and financed it that way, hopefully they will make it, they still have a long way to go, product wise and company wise. For the phone, what do you guys think about the osmocom project by Harald and friends? http://bb.osmocom.org >From what I understand so far, they will continue to hack their way to make a GPL GSM stack work with Calypso RF/DSP chips, and later maybe MTK chips. The RF chips themselves are way out of reach for any of us (to make our own open version), even way harder than the GPL'ed Milkymist SoC I think we will get eventually [1] [2]. So to build a phone around osmocom, we have to reuse MTK RF/DSP chips? Anybody interested in financing it? :-) raster - do you want to pre-order one osmocom phone for 1M USD as you said? You have OpenPandora experience already, this one could only be better. On steroids! What do you think? Wolfgang [1] http://www.milkymist.org [2] http://en.qi-hardware.com/wiki/Milkymist_One On Thu, Feb 25, 2010 at 02:36:22AM -0800, ghislain wrote: > > What about the Ben NanoNote (http://en.qi-hardware.com/wiki/Main_Page). > They showed how the process is done, from the beginning to the end (I don't > know about the funding). > Although it's not a phone, I do have a working ultra-portable now for a > reasonable price :) (It just needs some software-ports, but that is part of > the fun). > > Ghislain > http://www.basetrend.nl BaseTrend - http://www.openmobile.nl openmobile.nl > -- > View this message in context: > http://n2.nabble.com/gta02-core-was-Re-OM-future-tp4628177p4631684.html > Sent from the Openmoko Community mailing list archive at Nabble.com. > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Alternatives to FR
Timo, > I'd really hope for "FreeRunner with 3G and Glamo ripped off, possibly > newer CPU" some day. For example some company joining gta02-core > effort to semi-productize something new... Yeah definitely. There are a number of efforts going on to regroup, here's my perspective on the lower layers (everything up to Linux kernel): ---1 Just yesterday Harald announced a new GSM development board he will be working on with some others: http://laforge.gnumonks.org/weblog/2010/01/07/#20100107-gsm_devel_board-planning I think this is a very promising project, like Harald says right now he can only handle people with GSM experience and EE or DSP skills, but if you are one of them, maybe get in touch with Harald. ---2 gta02-core, which you already know, is mostly stuck right now waiting for components from Openmoko. I also see it as a project to learn more about the good and bad of KiCad. http://docs.openmoko.org/trac/log/trunk/gta02-core ---3 Ben NanoNote - the project I currently work on, a very simple zero-RF pocket computer, we are going in parallel with gta02-core in trying to verify a design process around KiCad. I think it's important that we figure out a complete design process using free tools. http://projects.qi-hardware.com/index.php/p/board-qi-avt2/timeline/ ---4 USRP - well known for a while coming at the RF problem from the GNU Radio angle http://en.wikipedia.org/wiki/USRP ---5 Milkymist (www.milkymist.org), the "fastest open source system-on-chip capable of running Linux". Somehow I'm dreaming but I think this may become the basis for GPL'ed application processors in the future, and we can integrate logic developed by USRP or Harald's new project. The Milkymist SoC uses a LatticeMico32 core, and can boot Linux today. Their latest move is the Milkymist One development board http://lekernel.net/blog/?p=803 All of these projects are on the lower layers, however, and I doubt this will lead to another free phone for another few years maybe. If anybody knows more projects please holler. Also I do know that these things are not really connected to each other, lots of disorder. But with some imagination you can see how important pieces of the puzzle are contributed in various places... For the upper layers, I agree with others that intermediate solutions are phones like the Palm Pre or Nokia N900, which allow to continue development of things like FSO or mobile apps while the lower layers are progressing. No reason to be demotivated, I think! 2010 should be a fun year, and hopefully the FreeRunner can continue to be a source of inspiration, more than frustration :-) Cheers, Wolfgang On Fri, Jan 08, 2010 at 08:35:02PM +0200, Timo Jyrinki wrote: > 2010/1/4 William Kenworthy : > > Nokia n900 - probably the best choice at this time. > > Probably, but to be more precise "not yet" instead of "at this time". > It's the only one that seems to have realistic possibility of some day > having a free distribution running with all features enabled. But it's > not today, and it remains to be seen how active the community around > it is. > > I'm personally thinking that in 1-2 years I could have a pure Debian > (maybe custom kernel) running on N900, with everything except probably > 3D working. That assumes some people will reverse-engineer the battery > loading etc. whatever is needed. > > But until then there is simply no choice besides Neo FreeRunner, > unless something new appears or community around Palm evolves to reach > the level of free distribution hackers around Maemo and the modem > stuff is reverse-engineered. > > And even with those, I would have to give up free hardware :S I'd > really hope for "FreeRunner with 3G and Glamo ripped off, possibly > newer CPU" some day. For example some company joining gta02-core > effort to semi-productize something new... > > -Timo > > ___ > 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: Alternatives to FR
Warren, > I've been using my FR for 1.5 years, as my primary phone for a lot of that > time(on QtEI and the more recently shr-u), and I must admit I'm getting more > and more frustrated with it - between the regular crashes and hangs, the > incredibly slow performance (so slow that I still occasionally miss a call > because I can't unlock the phone in time to answer it), the horrible GPRS > performance, and the various idiosyncracies (like the recent 'feature' to > progressively dim the screen while I'm trying to use it, inability to > connect to wifi much of the time, etc.)... > > There have been improvements, but it's been very slow, and IMO we're still a > *long* way from having a phone with even a half-decent user experience... > and there is nothing we can do can fix issues like the poor glamo bandwidth, > and the crappy GPRS performance. When I'm out of the house and need to look > something up on the web, I borrow my wife's Iphone - I can look up what I > need before the FR's browser finishes launching, let alone loading the > google homepage... Just want to say thanks for writing this up! It's tough, but I think you pretty much sum up the experience of a lof of people. It's the best that we could achieve (I worked for Openmoko before). > And to be blunt, I don't give a damn if the battery loading software isn't > open... As long as it's a linux stack, and it's easy to cross-compile the > app software I want for it, using the standard open source libs I'm familiar > with --- that's free enough... Sounds like a plan. We all want a 100% free phone, but we gain nothing from building on sand. So with the FreeRunner in the state it is, I think development will fragment for a while, until it comes together again in a new attempt at a 100% free phone one day. Until then, if the hardware is not stable you cannot do kernel development, if the kernel is not stable you cannot do middleware, if middleware is not stable you cannot do apps. Doing it all at the same time like with the FreeRunner lead to what you described above. For myself - I went back to an old Blackberry Pearl, I think I will buy a new Linux phone only if one exists that can do telephony when reflashed with an image built by OE/OWrt or so. Like you I would also accept some binary parts temporarily. As far as I understand that still doesn't work with the Palm Pre or N900, so I'm in wait-and-see mode. Wolfgang On Fri, Jan 08, 2010 at 05:28:34PM -0500, Warren Baird wrote: > On Fri, Jan 8, 2010 at 1:35 PM, Timo Jyrinki wrote: > > > 2010/1/4 William Kenworthy : > > > Nokia n900 - probably the best choice at this time. > > > > Probably, but to be more precise "not yet" instead of "at this time". > > It's the only one that seems to have realistic possibility of some day > > having a free distribution running with all features enabled. But it's > > not today, and it remains to be seen how active the community around > > it is. > > > > > Depends a bit on how you define 'free'... I interact with a phone mostly > as a user, and possibly as a app developer - so for me if I can run free > software on it, and I can develop free software for it using free tools, > it's 'free enough'...I really want a device that I can use as a phone, > and a hand-held linux box. The FR does the hand-held linux box part very > well, but not so much the phone part. > > I've been using my FR for 1.5 years, as my primary phone for a lot of that > time(on QtEI and the more recently shr-u), and I must admit I'm getting more > and more frustrated with it - between the regular crashes and hangs, the > incredibly slow performance (so slow that I still occasionally miss a call > because I can't unlock the phone in time to answer it), the horrible GPRS > performance, and the various idiosyncracies (like the recent 'feature' to > progressively dim the screen while I'm trying to use it, inability to > connect to wifi much of the time, etc.)... > > There have been improvements, but it's been very slow, and IMO we're still a > *long* way from having a phone with even a half-decent user experience... > and there is nothing we can do can fix issues like the poor glamo bandwidth, > and the crappy GPRS performance. When I'm out of the house and need to look > something up on the web, I borrow my wife's Iphone - I can look up what I > need before the FR's browser finishes launching, let alone loading the > google homepage... > > Unfortunately, I've been actively looking for a device lately to replace my > FR - I'm just too fed up with it. The N900 is currently my leading > contender. I had originally written it off, because it doesn't support the > 3G data frequencies currently available here in Montreal - but I realized > the other day that it's 'fallback' data support is EDGE, not GPRS. The > *fallback* on this phone is still 20x to 50x faster than the best data > tranfer rate I can get on the FR... > > And to be blunt, I don't give a damn if the battery loadin
Re: Maintain(er) OpenMokoProjects [was: Openmoko projects page down]
Michael, > Bringing me to my next question (all?) - what would be an adaquate location > for hosting application level projects for Openmoko? Any experience? -> I > really liked the idea and functionality (SVN, WIKI and docs, News, File > releases, Tracker) OpenMokoProjects provided - and in the end, you could > easily browse through a bunch of applications for the Freerunner / Openmoko. > > I can think of (but): ... When we started Qi Hardware we also looked around and eventually found a software called 'Indefero' (GPL licensed): http://www.indefero.net/ You can host projects there, and also download the whole thing for installation on your own server. http://projects.ceondo.com/p/indefero/downloads So far we are quite happy with it http://projects.qi-hardware.com/ Other than that, I had good experience with github.com and code.google. One idea behind the Openmoko projects server was to keep all Openmoko- related projects 'nearby', although some people thought that concept is a bit strange when the whole Internet is built around URLs. However, it seems the idea of keeping the 'family' together kind of worked, so I think the first priority should be to get the OpenMokoProjects server back on track. The server side software used there is more or less dead, so a more radical approach would be to update to something newer like Indefero. Which would be a big task though and break everybody's URLs... Wolfgang On Thu, Jan 07, 2010 at 08:47:25AM +0100, Michael Pilgermann wrote: > Dear all, > > the OpenMokoProjects page is back online - thanks to whoever did this. > > But in fact, I got a bit concerned about carrying on to host my projects > there. What is the status of this site - and who is the maintainer? > Could you please do any statement about the future of OpenMokoProjects? (if > it is unlikely to be continued, I would rather start migrating the content > from there) ... > > Bringing me to my next question (all?) - what would be an adaquate location > for hosting application level projects for Openmoko? Any experience? -> I > really liked the idea and functionality (SVN, WIKI and docs, News, File > releases, Tracker) OpenMokoProjects provided - and in the end, you could > easily browse through a bunch of applications for the Freerunner / Openmoko. > > I can think of (but): > - sourceforge.net (for my taste has become too much marketing touchy) > - google code (well; it's still Google) > - some corner on SHR web side?? > - github.com (I have no experience at all; but it looks like providing most > of the functionality I mentioned before > - feshmeat.net (would only be for the "front page" I guess) > > Writing all this; I remember discussions on these lists here about an > Openmoko application directory.? I can't remember the outcome of this > discussion - has anything evolved from it? > > Please, I would be thankful for any input ... thanks in advance; > > Best > Michael > > > Original-Nachricht > > Datum: Wed, 06 Jan 2010 19:25:11 +0100 > > Von: Michael Pilgermann > > An: community@lists.openmoko.org, shr-u...@lists.shr-project.org, > > shr-de...@lists.shr-project.org, de...@lists.openmoko.org > > Betreff: Openmoko projects page down > > > > > Dear all, > > > > I have experienced problems in accessing the Openmoko Projects web page > > (http://projects.openmoko.org/) for a couple of days now; always > > receiving the following error message: > > > > "OpenMokoProjects Could Not Connect to Database: " > > > > I am using this page for my development projects; any idea, whom to > > contact to getting this resolved? > > > > Thanks in advance; best regards > > Michael > > > > PS: I heart rumours, that the maintainer has disappeared.? Any more > > input on that? How could (instead) restart the web- and database servers? > > > > PPS: Do you know any other good place to host projects for the > > Freerunner / SHR? > > > > ___ > > Openmoko community mailing list > > community@lists.openmoko.org > > http://lists.openmoko.org/mailman/listinfo/community > > ___ > devel mailing list > de...@lists.openmoko.org > https://lists.openmoko.org/mailman/listinfo/devel ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Happy New Year from FSO
Mickey, congratulations for taking FSO this far and all the best and some good luck in 2010! Wolfgang On Sat, Jan 02, 2010 at 02:31:22PM +0100, Michael 'Mickey' Lauer wrote: > In the name of the FSO team, I wish all of you a Happy New Year! > > 2009 was a turbulent year for us, the year where Openmoko stopped > supporting us and we had to show our belief in the project by just > continuing with as much effort as possible. Thanks to all contributors > and users of our APIs. > > 2010 will be a very critical year for FSO, perhaps the most critical > ever -- since it's going to show whether we dive into oblivion being > overrun by the "big guys", or whether we can establish and strengthen > our niche. > > Middleware always has this problem of invisibility -- what people > recognize are applications, not so much the driving software layers > below. In order to be a bit more visible, I'd like all of you who are > using FSO to join Ohloh[1] and state that you are either a contributor > and/or using FSO. > > If all goes well, 2010 will be the year where we finally migrate all > remaining FSO services to C (or Vala, to be exact), hence delivering a > significant speedup for your FreeRunner (or whatever device you run FSO > on). > > Let me also remind you that we have a PayPal account for donations, and > are also available for contract work. Thanks for your support! > > (1) http://www.ohloh.net/p/fso > > -- > :M: > > > ___ > 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: future phones that you can hack. news.
raster, > I can officially leak this. We (over in Enlightenment land) are working with a > major electronics manufacturer Fantastic news, congratulations for getting this off the ground and I wish you a lot of success with it! Keep in touch, Wolfgang On Wed, Nov 18, 2009 at 12:07:09PM +1100, Carsten Haitzler wrote: > Just an FYI here. > > I can officially leak this. We (over in Enlightenment land) are working with a > major electronics manufacturer (one that happens to pump out 100's of millions > of phones every year of pretty top-notch hardware quality - and who also > happens to like making phones high-spec with nice screens, good SoC's and 3G. > If what we do is a phone, or a TV, or a game system, or a DVD player... who > knows!). What does this mean? Well - no guarantees, but they are now > sponsoring > us. That says something. If we are working on something you can guess the rest > I'd say. > > Who it is - will wait for future announcements. What, when and where will also > need to wait. How open it is, will also need to wait. But you can guess that > if > we are fiddling with it - it's already partly open. > > So... just dropping a "keep your eyes peeled". > > P.S. No glamos were hurt during this work. Actually they were not even > involved. :) > > -- > - Codito, ergo sum - "I code, therefore I am" -- > The Rasterman (Carsten Haitzler)ras...@rasterman.com > > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Tuxbrain first anniversary
David, same as the others, congratulations! I think we will hear a lot more from tuxbrain in coming years... :-) Wolfgang On Mon, Oct 26, 2009 at 12:26:52PM +0100, David Reyes Samblas Martinez wrote: > Dear all, > Is for me a pleasure and proud to announce this week Tuxbrain the > company that has born thanks to the inspiration of Openmoko is now one > year old :) > a good moment to thanks all that make us enjoy this first year of > live, those who has make us learn, and of course to all that had buy > something there :) > To celebrate it we have down the price of the Frerrunner A6+[1] > My only wish when I blow the candle is to enjoy next year as much as this > one. > A big Thank you and and a bigger hug to you all > > [1]http://www.tuxbrain.net/en/content/tuxbrain-first-anniversary > > David Reyes Samblas Martinez > http://www.tuxbrain.com > Open ultraportable & embedded solutions > Openmoko, Openpandora, Arduino > Hey, watch out!!! There's a linux in your pocket!!! > > ___ > 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: [Wikireader] Any news on Wikireader ?
Doug, YES! This is an excellent summary and technical introduction to the device... Before trying to add a few things, let me first express my deep personal thanks to a number of people that worked with me on the device until 5 months ago (there was not enough space on the official website to list them all there): Tim Ruetz and Daniel Mack (www.caiaq.de) for the electrical design and microkernel Joerg DocScrutinizer and Andy Green for hardware feedback and specs! Holger zecke Freyther for system software and a (failed) WebKit-based renderer John Lee, Matt Hsu and Marek Lindner for software improvements Yi Zhang for product management all the way to functioning prototype and our vendors like GoWorld and EPSON who provided significant engineering assistance You all worked far beyond what was to be expected, or even compensated for. It was a true pleasure to work with all of you, I learnt a lot - THANK YOU! Let's hope the WikiReader will reach many people, and have a great future. Now that that's done, some feedback: > It does not use a Linux kernel. It is an embedded device containing > only minimal amounts of software, just enough to be a WikiReader. The > WikiReader program itself is the kernel. We tried to keep the microkernel functions and the app separate. Chris has documented this nicely, the microkernel was originally called Mahatma. There is an interesting side story, in that at some point the plan was to run a Japanese ITRON microkernel on the device! http://en.wikipedia.org/wiki/TRON_Project This didn't work out as the ITRON implementation (free software: Toppers/JSP) turned out to be too big. So it got deleted from the source tree at some point. But if you dig in the history, you can still find it and it may be an interesting starting point for some ITRON hacking on the device. It was working at the time! > I don't think RMS would have any complaints about carrying one of > these around. Can you spend a bit of time to check the licenses? Chris Hall reviewed it so I'm sure it's all good, but since it is all statically linked together and GPL-licensed it means like you said every last bit of software needs to be at least GPL compatible. An independent review on this would be great. In addition to the microSD card, there is only a small bootloader in an EEPROM (to boot from the SD card), but I think it's free software and in the source tree as well. Reflashing that EEPROM is a bit tricky (though possible, needs documentation), but not sure who would need it. > If you hold the third button down while turning on, it starts up the > serial console (19200 8N1). Is it documented somewhere how to hook up a serial cable? Currently there are three simulators available (console, cocoa, Qt4), but when you want to do active development on the device, I think having a serial cable is the only way to get faster feedback cycles, log output, etc. > It has no connectivity, other than a serial port I haven't tried yet, > and SneakerNet (you take out the micro SD card and walk over to another > computer to update its contents). This lack of connectivity keeps the > internals simple and the cost down. The card and the serial port are in > the battery compartment. If I think about this device, the one thing that pops out again and again is BRUTAL SIMPLICITY. That is the real beauty of it. You can load some software into this device, then give it to anybody and not be worried they will get lost in a number of buttons and options. They will (have to) focus on what you are delivering in front of their eyes, and one thing where the WikiReader excels technically is the capacitive touch screen, which makes interacting with it a joy. Get more software on it! :-) Wolfgang On Thu, Oct 22, 2009 at 11:14:25AM -0700, Doug Jones wrote: > -= Apertum =- wrote: > > Hello, > > > > The (very interesting, IMHO) Wikireader product has been launched about > > 2 weeks ago, but still i don't see any information about hardware and > > software (IE we don't know if there is a Linux kernel in it, or not), > > and/or how it will be hackable by the community. > > > > It's there any news somewhere on the net, or when you at OpenMoko plan > > to discover these (important) informations? > > > > Thank you so much for your attention :-) > > > > > Look for the thread labeled [reader] on this list > > I have one, and have been spending some time looking at the code and > available docs. > > It does not use a Linux kernel. It is an embedded device containing > only minimal amounts of software, just enough to be a WikiReader. The > WikiReader program itself is the kernel. > > AFAICT the code on the device is entirely written in C and Forth, and is > 100% Free Software. Unlike the Freerunner and every other cellphone on > this planet, it does not contain any chunks of proprietary code (it > doesn't need to worry about what the cell providers or the FCC thinks). > I don't think RMS would have any complaints ab
Re: Freerunner Review
Nelson, > Something that I think and that also hear from others is that it's sad > to see that OM stopped sponsoring phone development too early (when > the FR was just starting to work) but we know that many companies Totally agree with you. But the good news is that Werner continues with gta02-core, which you are probably aware of. And Sean has promised a set of 20 components for their first run. So things are moving. Wolfgang On Thu, Oct 15, 2009 at 12:28:48PM -0500, Nelson Castillo wrote: > On Thu, Oct 15, 2009 at 11:38 AM, rakshat hooja wrote: > > I have been hearing a lot of good about the phone from our freerunner > > customers of late (change from earlier :) > > > > SO just sharing a recent review poster by a user > > > > http://guide2freerunner.blogspot.com/ > > It's very nice to see recent reviews and less hate email in the lists. > Something that I think and that also hear from others is that it's sad > to see that OM stopped sponsoring phone development too early (when > the FR was just starting to work) but we know that many companies > (also individuals and countries) are having hard years. > > ___ > 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: WikiReader
Sean, wow great, it's out! Congratulations and I wish you all the best with it! Wolfgang On Tue, Oct 13, 2009 at 01:51:42PM +0800, Sean Moss-Pultz wrote: > Dear Community! > > Today, with the greatest of pleasure, I am ready to share with you the > birth of our third product -- WikiReader. Three simple buttons put > three million Wikipedia articles in the palm of your hand. Accessible > immediately, anytime, anywhere without requiring an Internet > connection. No strings attached. With WikiReader you'll be prepared > for those unexpected moments when curiosity strikes. And once you have > it, you'll realize how often you ask yourself questions during the > day. > > WikiReader takes our original ideas of openness and accessibility to > an even greater realm. WikiReader is so amazingly simple. There really > is no interface. You turn it on and instantly become immersed in the > rich world of reading specific topics or the serendipitous pleasure of > discovering something by chance. It's perfect for all ages. > > From the "Aha!" moment when we held our first prototypes, to the last > few months as we worked around the clock to polish every last detail, > this product was a joy to make and even more fun to experience. We are > head-over-heels in love with WikiReader. Never have I found so much > fun in the little moments of curiosity life offers us. Try one and I'm > sure you'll agree that we've delivered the essence of reading > Wikipedia in an addictively simple form factor. > > Sales start today at http://thewikireader.com. Enjoy. Tell your > friends. And let us know what you think! > > > Sincerely > > Sean Moss-Pultz > > ___ > 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: Rod Whitby (MokoMakefile author) moves on to start WebOS Internals
Rod, wow, sad to see you go indeed. You are one of the true old-timers of Openmoko :-) Since hacking the Palm Pre is not that far from an 'open phone' perspective, maybe you can add a feed to the Openmoko planet and we can that way stay in touch with what you are doing? I will regularly check what's going on at webos-internals.org All the best! Good luck! Wolfgang On Tue, Oct 06, 2009 at 10:08:23PM +1030, Rod Whitby wrote: > http://www.rwhitby.net/blog/webos-internals/palm-pre-lands-in-australia.html > > It is with some sadness that I must say goodbye to the OpenMoko > community, and move on to new things. > > My dream of an OpenMoko phone with a hardware keyboard to replace my > aging Treo 650 was never realised, and you all know the rest of the > story on the software side of things. > > I've now started a new community (webos-internals.org) which does open > source Linux-based development for the Palm Pre. > > My hope is that freesmartphone.org may one day be the bridge between > the OpenMoko community I am now leaving, and the WebOS Internals > community which has recently started. > > I wish everyone continuing down the OpenMoko path the best of success > in the future. > > -- Rod > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Web site promoting open hardware?
Stefan, what would drive someone to this site/list and what are the criteria people are looking for? I think at some point I will start to work on a table of 'hackable' hardware, because at least technically it's relatively easy to pin down features: Reflashable, unbrickable, all drivers in source form or some in binary, toolchain open, schematics/datasheets/layout/BOM published or not, etc. But this is only interesting to hackers, not normal users. What if a company supports the free software scene covertly (quite a few do because the reason they fear openness are patents, not hackers)? Who should 'rank' or 'qualify' hardware makers for how 'open' they are? I think we first need to define why someone is looking for openness, and what they expect from it. Can you explain your motives? What makes you interested in Openmoko, Qi, OpenPandora, etc.? Thanks, Wolfgang On Thu, Sep 10, 2009 at 11:00:49AM -0400, Stefan Monnier wrote: > While looking for new hardware, I noticed that all the open hardware > I know, I discovered it by accident while reading some mailing-list. > > Is there a web site somewhere that kind of centralizes this info to try > and make it easier for openness-conscious consumers to find > appropriate hardware? Of course, there are various notions of "open > hardware", so there might be parts of the site for hardware-hackers, for > example, but I'm more interested in a web-site for end-users. Also it > might include hardware that is not itself open source, but where the > company states a clear commitment to Free Software principles. > > I.e. a site that links to things like Openmoko, Qi, AlwaysInnovating, > maybe Lemote, OpenPandora, ... > > Any hint? > > > Stefan > > > ___ > 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: Om2009 Maintainer
Angus, thanks a lot for your fantastic work on Om2009. It didn't go where we wanted it to go, but still covered a lot of ground. I guess I will switch to SHR too then (good instructions!) :-) Keep in touch, Wolfgang On Fri, Aug 28, 2009 at 01:09:49PM -0600, Angus Ainslie wrote: > Hi All, > > After some deliberation and input from the community I am going to stop > maintaining Om2009. I'm going work on getting paroli to co-exsist in SHR. > > If you want to try and run paroli in SHR unstable RFN. Flash the latest shr- > unstable image. > > http://shr.bearstech.com/shr-unstable/images/om-gta02/ > > the image from 08-08-09 has a minor problem with opkg. to fix it > > opkg-cl update > opkg-cl upgrade > > then install paroli > > opkg install paroli > > fix the conf files that the paroli installer messes with ( I hope to fix the > recipe in the next couple of days. ) > > cp /etc/old_frameworkd.conf /etc/frameworkd.conf > cp /etc/freesmartphone/oevents/old_rules.yaml > /etc/freesmartphone/oevents/rules.yaml > > now if you want to disable the shr phone apps without removing them comment > all of the lines out in > > /etc/X11/Xsession.d/89notifier and /etc/X11/Xsession.d/80ophonekitd > > if you want the bind-home to ease upgrades add this line to fstab. > > /media/card/bind-home /home/root nonebind 0 0 > > You should now have a functional paroli on SHR setup. Once you have a working > setup I would advise against doing opkg upgrades and only upgrade specific > packages when needed. > > Thanks > Angus > > ___ > 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: Hi
Roland, > Seeing that none of the distro's really do (seeing that they are > produced by hackers who are mostly hacking for their own enjoyment > it's not really surprising and you can't really blame the teams) I would agree, but what's your solution? The one idea I have is that maybe stable releases are the common denominator: Insist on stable interfaces, crystal clear distinction between stable, testing and unstable branches. That may be one way to bring the hackers and regular users together, since I believe at least a large part of hackers understands and agrees with the value of well maintained stable releases, well tested upgrade paths from one stable release to the next, a clear process of how stuff moves from unstable to testing to stable. It would still require some tough choices though, because there are some that don't care about stable releases (I'm not blaming them same as you - they do this for their own enjoyment). Maybe their stuff stays in unstable forever :-) What do you think? Best Regards, Wolfgang On Sat, Aug 22, 2009 at 06:16:47PM +0100, Roland Whitehead wrote: > I would recommend that you choose which ever distro keeps their "how > to make your Neo work as a phone for most of the time using this > distro as well as running other standard services reliably" wiki page > up to date and by up to date I mean referring to which ever is the > most useable bootloader, build, kernel currently available even if > that is the daily build. It should also assume that the reader is a > complete novice and is neither a hacker or a linux sysadmin. > > Seeing that none of the distro's really do (seeing that they are > produced by hackers who are mostly hacking for their own enjoyment > it's not really surprising and you can't really blame the teams) > you've got a wide choice. > > This remains one of the main requirements of Openmoko in my opinion > and could be a great way for the non-core-hackers to contribute. > > > Roland > -- > QURU Ltd, London > > > On 8/22/09, Risto H. Kurppa wrote: > >> Hi Soumik! > >> > >> Depends on what you want to work on, but if you have a freerunner, my > >> suggestion is to install om2009 unstable there (see > >> http://wiki.openmoko.org/wiki/Om2009 ) and contribute to Paroli for a > >> start (see http://wiki.openmoko.org/wiki/Paroli ). That'd be very > >> beneficial for many and you'd get easily in in the develpment for > >> Freerunner. > >> > >> You're welcome to join #paroli irc-channel for discussion. > >> > >> > >> (and I know, others will recommend you other distros like SHR or > >> Debian - but I was first :) > >> > >> r > >> > > > > On 22 Aug 2009, at 11:10, Sebastian Krzyszkowiak wrote > > > > Few arguments for SHR over Om2009: more people working on it, develops > > faster, most of decisions are done by community, nice way for sending > > and maintain patches, reachable people maintaining distro (so your app > > can even be added to default image), perspectives for future. IRC > > channel: #openmoko-cdevel > > > > Decision is up to you, but I prefer SHR. Fast, stable, usable - as > > Om2009, but it has also more things behind scenes which Om2009 don't > > have ;) > > > > -- > > Sebastian Krzyszkowiak > > dos > > > ___ > 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: [All] Status of the OM community
Risto,
> My wish also would be that the (former) OM employees still around
> could rewrite/update the parts that concern OM the company in the
> wiki.
Can you point me to some parts you would like to see updated?
I'm not with the company anymore for 2 months, but maybe there are
still some things I can help cleaning up.
I agree with you that the community should show more leadership, the
Community News are a great example!
To me the FreeRunner remains the most interesting cell phone to do
hacking on today, even though it's a technical minefield. Or maybe it
is interesting because it is a minefield ;-)
Wolfgang
On Sat, Aug 22, 2009 at 12:34:05PM +0300, Risto H. Kurppa wrote:
> Hi there!
>
> After OM announced the discontinuation of the OM software development,
> there was this discussion about starting a foundation to support the
> community.
>
> What's the status? Any action taken?
>
> I feel like suffering from the unorganized community: the wiki is a
> mess, apps around are outdated, no instructions available how to
> submit apps to repositories and how to create .bb recipes (I know SHR
> has it all better :), how to set up a development environment and so
> on. There's also a lack of communication about packages and
> dependencies: suddenly some library is updated and it breaks tens of
> apps without the author or packager knowing about it.
>
> -> Coordination and leadership is needed!
>
> I'm actually very happy that we ('the community') were able to start
> running Community Updates without anyone from OM to do it, see
> http://wiki.openmoko.org/wiki/Community_Updates
>
> Any ideas?
>
> My suggestion is to start with the cleanup of wiki: separate HW and
> SW, separate devel/user information, archive or delete outdated
> information, take good care of sites like
> http://wiki.openmoko.org/wiki/Openmoko:Community_Portal
> http://wiki.openmoko.org/wiki/Getting_Started_with_your_Neo_FreeRunner
> http://wiki.openmoko.org/wiki/Introduction
>
> My wish also would be that the (former) OM employees still around
> could rewrite/update the parts that concern OM the company in the
> wiki.
>
> r
>
> --
> | risto h. kurppa
> | risto at kurppa dot fi
> | http://risto.kurppa.fi
>
> ___
> 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: One second Openmoko boot?
Mickey, > Not really. Reloading (in the worst case) 128MB from an SD is not exactly > fast > either. > > The only sane way to substantially improve booting time is to stop booting > like a desktop PC, that is move away from starting all services just because > you can. Start them on demand and bring only the bare necessities up on boot > (filesystems, dbus, X). Not sure. What I have seen working usually required much more aggressize optimization, all the way into hardware. Two examples: 1. Blackberry (old model, at least 2 years old) Cold boot only happens when I take out the battery. Otherwise the 'power off' button will just do some form of suspend (probably suspend to flash). It takes about 8 seconds to 'turn on' (probably from flash), and the most amazing thing, it only takes another 3-4 seconds until the first new email arrives in the Inbox. They probably optimized for this case ALL THE WAY THROUGH the apps, OS design, HW design, maybe even GSM chipset. Interestingly, after the first mail it takes maybe 5 seconds or so for the following mails to arrive, so they optimized the case of 'just get the first new mail into the Inbox asap' and postpone some other vital system initialization until after the first mail got delivered. 2. old Palms, late 90's They kept the whole memory in a low-power self-refresh mode. If you took out the batteries, you had about 1 minute or so to put new batteries in (during that time an internal backup battery would keep the RAM alive). If you didn't do that, all your data on the device was lost (but would be restored during the next HotSync from your desktop). Other than that, if you turned the device off you actually didn't turn it off at all. You only sent the whole system into this super low power mode where it still would keep the memory alive. It could stay like this on the battery for about 2-3 weeks. Wolfgang On Thu, Aug 20, 2009 at 05:17:25PM +0200, Michael 'Mickey' Lauer wrote: > On Thursday 20 August 2009 10:02:45 Michal Brzozowski wrote: > > Any chance suspend to disk, or 'hibernate' would work on openmoko? > > Not really. Reloading (in the worst case) 128MB from an SD is not exactly > fast > either. > > The only sane way to substantially improve booting time is to stop booting > like a desktop PC, that is move away from starting all services just because > you can. Start them on demand and bring only the bare necessities up on boot > (filesystems, dbus, X). > > I plan to do some proof of concepts when my time allows... > > :M: > > ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Document with answers to most popular battery-related questions is ready
Rask, I guess it comes down to price. Most normal end users won't need the current measurement as they don't do development, so adding an extra chip to do the measurement either in the device or in every battery might not be worth it. Maybe in the device just run a wire to the 3rd battery pin, then sell it with a non-Coulomb counter battery normally, and offer the Coulomb-counting battery as an add-on for developers? Thanks a lot for your excellent feedback, we need to study this more... Wolfgang On Sun, Aug 09, 2009 at 01:37:00PM +0200, Rask Ingemann Lambertsen wrote: > On Mon, Aug 03, 2009 at 01:46:26AM +0800, Wolfgang Spraul wrote: > > How are people really using the Coulomb counter in gta02? > > Theoretically I would think that it provides far superior power measurement > > options for actual software development, just as you write. > > For example when playing with power saving codes, whether in the kernel, > > middleware or applications, I would think over the course of several hours > > or > > days the Coulomb counter data is the primary means for efficient > > development. > >To me: The clearly most useful part of the bq27000 is the current > measurement. You get what seems to be a reasonably accurate measure of the > current flow to/from the battery updated every 25 s or so. It's much more > practical than an external ammeter: No need to open the case and fiddle with > probes, you can measure battery current while in the train, at work or > wherever. Having it built in makes accurate current measurement available to > many more people in a lot more places. > >Here's a few examples where the current measurements have proven useful: > 1) Tracking down that current leak from the serial ports into the Calypso. > 2) Finding that 8 mA apmd current leak Debian used to have. > 3) Confirming the X.org server screen blanker current leak of 38 mA. > 4) Measuring the effectiveness of reducing CPU clock and core voltage. > >Hopefully it will also help to curb assorted forms of spyware because > they will be easier to detect with the power consumption figures readily > available. > >I don't think it is worth it to spend a coulomb counter on each battery. > The selling point would be to keep track of battery degradation, but I've > already seen it change its mind from 1067 mAh to 1148 mAh - that's an error > of two hours worth of idle time at 100 MHz. > >To get a charge level reading, add a voltmeter connected to the battery > terminals. As long as the charge and discharge rates are moderate, it will > be good enough. > > -- > Rask Ingemann Lambertsen > Danish law requires addresses in e-mail to be logged and stored for a year > > ___ > 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: Document with answers to most popular battery-related questions is ready
Paul, > It's possible with bq27k because it works autonomously. But if you do > something similar to gta01 there's no way to measure current in > suspend without an external equipment. Can't you measure current before and after suspend, and knowing how long you were in suspend calculate energy consumption during suspend? Wolfgang On Sun, Aug 02, 2009 at 11:46:06PM +0400, Paul Fertser wrote: > Wolfgang Spraul writes: > >> Yes, i think that's the case. The only state where integrated power > >> measurement > >> readings are unavailable is suspend and that's quite low level > >> already. > > > > You could measure the current when you wake up, couldn't you? > > It's possible with bq27k because it works autonomously. But if you do > something similar to gta01 there's no way to measure current in > suspend without an external equipment. > > >> bq27000 measures current accurately so it should be possible. I'm sure > >> there's some decent IC suitable for your task. > > > > bq27000 is a chip, right? You mean we should have that chip inside the > > device, > > instead of having it in every battery? > > It would be a possible solution but it doesn't make much sense because > bq27k assumes it's connected to the same battery all the time. I meant > that since bq27k manages to measure the current accurately, there > should exist some other more simple IC (properly shielded to be immune > to noise) to measure the current inside a device. Also the charger IC > must know the current too, it's just that PCF50633 doesn't allow to > read it for some reason :( > > There's also a possibility to use some other CC on device side, take > a look at http://focus.ti.com/docs/prod/folders/print/bq27510-g1.html > ( $1.6 ) > > > That would make the batteries cheaper as well, I believe the CC batteries > > cost 2 USD or so more than without CC :-( > > And also special batteries are always harder to source for > end-users. Especially if they're not located in EU or the USA. > > -- > Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! > mailto:fercer...@gmail.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Document with answers to most popular battery-related questions is ready
Paul, > And for me personally battery accessibility (i can go to the nearest shop > and buy a BL-6C in no time and for a fairly low price) is far more > important than accurate readings. Oh sure, totally agree with you. The question for me is only whether the device should support the 3rd pin on the battery connector. One could imagine that the device normally ships with regular (non-CC) batteries, but a SW developer interested in power consumption could use a CC battery. Hey, for the NanoNotes we wouldn't even need to make special batteries because the gat02 batteries fit, at least for development purposes (the battery cover doesn't really fit anymore as I said). So we could ship the device with the 3rd pin wired up, but without a CC battery in the package. The CC battery would be the tool of choice for power consumption work. Like you said, let's see whether someone else speaks up... Thanks for all your feedback so far, Wolfgang On Sun, Aug 02, 2009 at 11:30:45PM +0400, Paul Fertser wrote: > Wolfgang Spraul writes: > >> Wolfgang, please consider making current measurement in suspend > >> easy. :) > > > > Yeah - I thought that's what we were talking about :-) > > I'm not sure about your TP/DMM/EE advice. > > Hm, if the TPs are easily reachable i'd say that measuring voltage > over them is fairly easy. I don't think the guys working on suspend > consumption issues would need more. Also the kind of battery > receptable for BL-5C is very convenient to hook up an external PSU to > (even without soldering) so that's not really a problem as well. > > > Isn't the Coulomb counter the perfect way to make precise data available to > > everybody? That was the point I was trying to get to. > > The question is if in fact everybody needs precise data. Gta02 shows > that's not the case, at least that's how i see it. Both for end-users > and for app developer. And for me personally battery accessibility (i > can go to the nearest shop and buy a BL-6C in no time and for a fairly > low price) is far more important than accurate readings. > > So let's wait and see what other folks say. > > -- > Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! > mailto:fercer...@gmail.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Document with answers to most popular battery-related questions is ready
Paul, > Yes, i think that's the case. The only state where integrated power > measurement > readings are unavailable is suspend and that's quite low level > already. You could measure the current when you wake up, couldn't you? > bq27000 measures current accurately so it should be possible. I'm sure > there's some decent IC suitable for your task. bq27000 is a chip, right? You mean we should have that chip inside the device, instead of having it in every battery? That would make the batteries cheaper as well, I believe the CC batteries cost 2 USD or so more than without CC :-( Wolfgang On Sun, Aug 02, 2009 at 11:22:40PM +0400, Paul Fertser wrote: > Wolfgang Spraul writes: > >> To me it seems that CC readings are almost unused except for > >> presenting the user with a bit more accurate capacity data. And when > >> someone is developing something lowlevel he could as well connect and > >> external ampmeter, much more reliable and flexible approach. > > > > Now, if an accurate way to measure the current in the device solves 80% of > > that > > as well, then the (big) extra cost of supporting CC batteries is not worth > > it. > > Yes, i think that's the case. The only state where integrated power > measurement > readings are unavailable is suspend and that's quite low level > already. > > > So for me it all comes down to precision. Is it possible to build a cheap > > and > > accurate way to measure current in the device? > > bq27000 measures current accurately so it should be possible. I'm sure > there's some decent IC suitable for your task. > > -- > Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! > mailto:fercer...@gmail.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Document with answers to most popular battery-related questions is ready
Paul, > Wolfgang, please consider making current measurement in suspend > easy. :) Yeah - I thought that's what we were talking about :-) I'm not sure about your TP/DMM/EE advice. Isn't the Coulomb counter the perfect way to make precise data available to everybody? That was the point I was trying to get to. If not CC, what are the alternatives? Test points don't sound right to me. Precise current measurements maybe, but only if they are precise enough and can really serve the same purpose as the CC. Wolfgang On Sun, Aug 02, 2009 at 11:05:18PM +0400, Paul Fertser wrote: > Michal Brzozowski writes: > > 2009/8/2 Wolfgang Spraul > > > > Hmm, that's a pretty strong statement. > > At Openmoko we spent _a lot_ of money combined to get this CC thing to > > work. > > The theory was that you have it in most notebook batteries so it's 'a > > good > > thing to have'. > > But if it's not actually used, then it would be one of those many things > > we did that should have been better thought through. > > > > No, I think it was a very good decision. Not only low-level > > programmers need it, but also normal* users who want to know how > > long the battery lasts with certain configurations. I know for > > example that with gsm on it lasts about 50h in suspend, with gsm off > > about 100h > > Hm, there's probably something very wrong with your config, no? > > With GSM on in suspend it should last for 140 hrs and with off it > should be even more. > > Hm, so basically your point is that CC allows current measurement in > suspend. Ok, but if there're convenient TPs you can use your DMM to do > the same as well. Also you can do that by connecting the device via > DMM to a lab PSU or a pack of AA batteries. Moreover, there's quite a > limited number of usecases (wrt power-management) so those who has > some EE skills can do the measurements once and then share the info > for everybody. > > Wolfgang, please consider making current measurement in suspend > easy. :) > > -- > Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! > mailto:fercer...@gmail.com > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Document with answers to most popular battery-related questions is ready
Paul, one more thing... > To me it seems that CC readings are almost unused except for > presenting the user with a bit more accurate capacity data. And when > someone is developing something lowlevel he could as well connect and > external ampmeter, much more reliable and flexible approach. This is where I'm not so sure. Also see Michal Brzozowki's mail. I think real power consumption improvements in software can only be made if it's throughout the whole stack, from kernel to middleware to apps. I don't think you can optimize real system power consumption in the kernel alone, where the kernel knows or correctly predicts all sorts of middleware or app behavior. So of course you first want the kernel situation, and charging, to be robust and cover all cases. But then it should go on. And I don't think we should assume every software developer has an ampmeter. There are lots of application developers that could do valuable work if they would get speedy and accurate readings on how much energy was consumed in the last 5 minutes, 20 minutes, 2 hours, etc. Now, if an accurate way to measure the current in the device solves 80% of that as well, then the (big) extra cost of supporting CC batteries is not worth it. So for me it all comes down to precision. Is it possible to build a cheap and accurate way to measure current in the device? For the NanoNotes, I will look into this first. If it's possible, this may be all it needs to support application developers doing power consumption work. If it's not possible, I think CC is good - I don't want to make the assumption that you have to have an ampmeter to be able to do power consumption work. Feedback very appreciated. Wolfgang On Sun, Aug 02, 2009 at 10:02:42PM +0400, Paul Fertser wrote: > Wolfgang Spraul writes: > > this is an excellent document, obviously I cannot spot anything > > wrong! > > Thanks for you kind words. :) > > > I didn't know that some external chargers would not charge gta01 or gta02 > > batteries because of the thermistor check you are writing about. > > I'm not sure i saw any charger like that myself or seen reports > (except on our wiki). But i suspect the probability of that for nokia > brand charges is quite high. > > > All the cheap external chargers we bought in Taiwan or China for testing can > > charge both gta01 or gta02 batteries without a problem. > > Proves my point :D > > > I have a question for all: > > We will ship our first NanoNote with a BL-4C compatible battery, without > > Coulomb counter (middle pin unused) [1]. > > Hm, can BL-5C fit there? Because it'd be much nicer as modern 5Cs have > quite some capacity. > > > How are people really using the Coulomb counter in gta02? > > Theoretically I would think that it provides far superior power measurement > > options for actual software development, just as you write. > > For example when playing with power saving codes, whether in the kernel, > > middleware or applications, I would think over the course of several hours > > or > > days the Coulomb counter data is the primary means for efficient > > development. > > To me it seems that CC readings are almost unused except for > presenting the user with a bit more accurate capacity data. And when > someone is developing something lowlevel he could as well connect and > external ampmeter, much more reliable and flexible approach. > > > So we are considering shipping the next version of the NanoNote with Coulomb > > counter batteries same as the Neo FreeRunner. > > But if nobody is actually using the data from the Coulomb counter, then > > it's a > > wasted effort. > > I'm not sure you'll get much for using CC. > > The only problem so far with using a dumb battery on FR is that > there's no way to know the current from inside the device. On gta01 > there's a resistor shunt supposed to be used to measure the current > but readings are too noisy to be useable. So if you have a good way to > measure current already i'd not go for CC. > > -- > Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! > mailto:fercer...@gmail.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Document with answers to most popular battery-related questions is ready
Paul, > > We will ship our first NanoNote with a BL-4C compatible battery, without > > Coulomb counter (middle pin unused) [1]. > Hm, can BL-5C fit there? Because it'd be much nicer as modern 5Cs have > quite some capacity. It fits, but it's a bit too thick so it's hard to close the battery cover with a BL-5C (or gta02 battery) inside. Not recommended. > The only problem so far with using a dumb battery on FR is that > there's no way to know the current from inside the device. On gta01 > there's a resistor shunt supposed to be used to measure the current > but readings are too noisy to be useable. So if you have a good way to > measure current already i'd not go for CC. Hmm, that's a pretty strong statement. At Openmoko we spent _a lot_ of money combined to get this CC thing to work. The theory was that you have it in most notebook batteries so it's 'a good thing to have'. But if it's not actually used, then it would be one of those many things we did that should have been better thought through. I will check with Adam about precise current measurements for the NanoNote, and still I would appreciate any feedback from other people who are using the CC data for something other than proving that we have it :-) Any Coulomb fans out there? Wolfgang On Sun, Aug 02, 2009 at 10:02:42PM +0400, Paul Fertser wrote: > Wolfgang Spraul writes: > > this is an excellent document, obviously I cannot spot anything > > wrong! > > Thanks for you kind words. :) > > > I didn't know that some external chargers would not charge gta01 or gta02 > > batteries because of the thermistor check you are writing about. > > I'm not sure i saw any charger like that myself or seen reports > (except on our wiki). But i suspect the probability of that for nokia > brand charges is quite high. > > > All the cheap external chargers we bought in Taiwan or China for testing can > > charge both gta01 or gta02 batteries without a problem. > > Proves my point :D > > > I have a question for all: > > We will ship our first NanoNote with a BL-4C compatible battery, without > > Coulomb counter (middle pin unused) [1]. > > Hm, can BL-5C fit there? Because it'd be much nicer as modern 5Cs have > quite some capacity. > > > How are people really using the Coulomb counter in gta02? > > Theoretically I would think that it provides far superior power measurement > > options for actual software development, just as you write. > > For example when playing with power saving codes, whether in the kernel, > > middleware or applications, I would think over the course of several hours > > or > > days the Coulomb counter data is the primary means for efficient > > development. > > To me it seems that CC readings are almost unused except for > presenting the user with a bit more accurate capacity data. And when > someone is developing something lowlevel he could as well connect and > external ampmeter, much more reliable and flexible approach. > > > So we are considering shipping the next version of the NanoNote with Coulomb > > counter batteries same as the Neo FreeRunner. > > But if nobody is actually using the data from the Coulomb counter, then > > it's a > > wasted effort. > > I'm not sure you'll get much for using CC. > > The only problem so far with using a dumb battery on FR is that > there's no way to know the current from inside the device. On gta01 > there's a resistor shunt supposed to be used to measure the current > but readings are too noisy to be useable. So if you have a good way to > measure current already i'd not go for CC. > > -- > Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! > mailto:fercer...@gmail.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Document with answers to most popular battery-related questions is ready
Paul & Joerg, this is an excellent document, obviously I cannot spot anything wrong! I didn't know that some external chargers would not charge gta01 or gta02 batteries because of the thermistor check you are writing about. All the cheap external chargers we bought in Taiwan or China for testing can charge both gta01 or gta02 batteries without a problem. I have a question for all: We will ship our first NanoNote with a BL-4C compatible battery, without Coulomb counter (middle pin unused) [1]. How are people really using the Coulomb counter in gta02? Theoretically I would think that it provides far superior power measurement options for actual software development, just as you write. For example when playing with power saving codes, whether in the kernel, middleware or applications, I would think over the course of several hours or days the Coulomb counter data is the primary means for efficient development. So we are considering shipping the next version of the NanoNote with Coulomb counter batteries same as the Neo FreeRunner. But if nobody is actually using the data from the Coulomb counter, then it's a wasted effort. What do you think? Was the addition of the Coulomb counter in gta02 really a useful thing? Did FSO developers or kernel developers use the data for power optimizations? Thanks, Wolfgang [1] http://www.qi-hardware.com/products/ben-nanonote On Sun, Aug 02, 2009 at 09:07:39PM +0400, Paul Fertser wrote: > Hi, > > This is a text version of the wikipage [1], feel free to ask new questions > there on the talk page. Discussion on this ML is also appreciated (and > in fact i'm more comfortable with ML than the wiki). > > Openmoko devices > Battery questions and answers > > NB: Some of the described behaviour depends on the kernel, the > relevant code was pushed on 02 Aug to andy-tracking > > > Hardware capabilities > > Q: What batteries can be used with gta01 and gta02? > A: Original OM gta01, gta02, Nokia BL-5C, BL-6C and compatibles. > > Q: Do other BL-5/6C compatible batteries fit? > A: If the battery is thicker than BL-6C, you won't be able to close > the back cover. > > Q: What is the difference between all those types? > A: > > Capacity: > gta01, gta02 - 1200 mAh > BL-5C old (newer/new) - 850 (970/1050) mAh > BL-6C - 1150 mAh > > Temperature control: > gta01, BL-5C, BL-6C - thermistor > gta02 - bq27000 > > Special features: > gta02 - accurate and sophisticated reporting of capacity, > time_to_full, time_to_empty, temperature and battery current during > both charge and discharge thanks to bq27000 (aka Coloumb Counter) > > Q: What are hardware capabilities of gta01 and gta02 with regard to > battery management? > A: > > gta01: charging all battery types, measuring temperature with > battery-integrated thermistor (currently charging and measuring > temperature for non-gta01 batteries doesn't work due to the kernel > driver issues but it's software limitation), measuring battery output > voltage, very inaccurate and noisy measuring of battery current > > gta02: charging all battery types, measuring battery output voltage, > communicating with bq27000 > > Q: Can nokia phones use/charge gta01/gta02 batteries? > A: gta01 and gta02 batteries will fit wherever BL-6C fits but they > can't be charged in nokia phones unless you isolate the middle pin > from the battery and connect a resistor of ~50k (actual measured value > on a cold (25C) battery is 75k, on a slightly warm battery - 82k) from > it to the ground (to fake a thermistor presence). > > Q: Can third-party chargers charge gta01/gta02 batteries? > A: The "good" ones will most probably require the same trick needed > for nokia phones. More cheaper ones are more likely to ignore > thermistor absence. > > Q: I have several compatible batteries. What are the storage > requirements for them? > A: Keep in a dry cool place charged to no more than 75%. > > > Safety issues > > Q: Do OM devices control temperature to stop charging if the battery > gets too hot? > A: No (probably gta01 does, need to check). > > Q: Isn't it dangerous? > A: No, since all batteries (not raw cells!) have an integrated > protection circuits. > > Q: Can i use that fancy 2800 mAh BL-5C-compatible battery i saw on > ebay? > A: Unless you want an explosion in your pocket i wouldn't recommend > using any battery that is not produced by a reputable vendor and > widely tested. And even reputable vendors make mistakes, nokia once > had to recall 46 million batteries manufactured by Matsushita ( > http://batteryreplacement.nokia.com/batteryreplacement/en/advisory-2007.html > ). > > Q: You say that BL-5C is compatible with my gta02. Does that mean i > can use that BL-5C-compatible bat i bought for a buck from a bum? > A: You bet, go ahead. > > > Charging > > Q: My battery charges to 100% but then charging stops and the battery > keeps discharging, wtf? > A: LiIon batteries don't like to be kept fully charged,
Re: FSO core team founds BGB company
Mickey, Stefan, Daniel and Jan,
congratulations!
I wish you all the best, both from a free software and business perspective
it's so important to avoid the mobile Android monoculture :-)
Way to go FSO, we will do what we can to support you guys.
Wolfgang
On Wed, Jul 29, 2009 at 05:51:20PM +0200, Michael 'Mickey' Lauer wrote:
> Braunschweig, Germany, 2009-07-29. For immediate release.
>
> The freesmartphone.org core-team founds a BGB company to facilitate
> the further development of free and open source middleware for
> Linux-based mobile systems: "Lauer, Lübbe, Schmidt, Willmann,
> freesmartphone.org GbR".
>
> The core-team members of the freesmartphone.org project today announced
> the founding of a legal entity offering consulting, training, and
> implementation services around the freesmartphone.org middleware
> platform, also known as FSO[1].
>
> "We now have a single point of contact for both commercial and
> non-commercial parties who want to use our services to create compelling
> solutions. This is of interest for groups or individuals creating new
> devices or freeing existing devices ("anti-vendor-ports") and who
> decided to incorporate the FSO middleware", says Dr. Michael Lauer,
> founder of the FSO project. "If you care about the further development
> of this platform or if you need guidance for tailoring or customizing
> the FSO middleware, contact us via E-Mail at
> coret...@freesmartphone.org".
>
> With todays' smartphones evolving into ubiquituous companions, a gap has
> emerged between widely used FOSS components like the Linux kernel and
> core system libraries on one side, and end-user applications on the
> other side. The lack of a complete free mobile software stack hinders
> innovation and leads to reinventing proprietary solutions for services
> middleware.
>
> FSO's mission is to close this gap by designing and developing solid
> middleware for mobile systems in an open fashion; this refers to not
> only publishing source code under open source licenses, but also to
> sharing the whole design and development process with the community and
> giving both commercial and non-commercial entities a way to co-drive and
> steer the process.
>
> Built on top of the Linux kernel, FSO implements high level services for
> mobile application development, accessible via the DBus interprocess
> communication standard. Leveraging the FSO APIs allows the developer to
> concentrate on solving application domain problems, such as business
> logic and presentation of data, without having to worry about the device
> specifics and low level details, such as how to access resources,
> telephony, location awareness, data storage, etc.
>
> About freesmartphone.org:
> Previously funded by Openmoko Inc, freesmartphone.org is a collaboration
> platform for open source and open discussion software projects working
> on interoperability and shared technology for Linux-based smartphones.
> freesmartphone.org operates on the services layer (middleware) and
> offers APIs and reference implementations that support modern
> interconnected mobile devices. To provide reference solutions,
> freesmartphone.org works closely together with various device-specific
> communities such as the Openmoko, OpenEZX, and HTC-Linux groups. The FSO
> team honours and bases on specifications and software created by the
> freedesktop.org community.
>
> [1] http://www.freesmartphone.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: New Open Hardware company
Tony, just a few misconceptions - Qi is global, same as Openmoko. Headquarter in San Francisco, R&D in Taiwan, Germany, USA. Production in China. About patents - we care a lot. Qi Hardware is Copyleft Hardware. How could we think that this would work if we didn't respect intellectual property? We are not basing a business on risking lawsuits. Our general approach is - avoid patented technology whenever possible. Research carefully, help ourselves and our partners to accidentally step into a patent mine, maybe join a patent defense pool. After all, owning a patent still doesn't mean that you can force everybody to make use of your patent. It's not that bad yet! :-) Thanks for the heads up... Wolfgang On Fri, Jul 24, 2009 at 11:52:17AM +0200, Tony Berth wrote: > just few comments from a European! :) > > Its just FINE that you base your company in China. > China is worldwide a synonym of superior quality and most advanced > technology in terms of electronics and they are catching up extremely fast > with the rest of the industrial activities. > > I wouldn't care about Sisvel. Let them try to sue you in ... China :) What > Sisvel 'defines' is useless and they know that. How may chinese companies > were sued anyway? :) > > iPhone is WAY too expensive! A pure Mickey Mouse device. > > What I would like to see from your product would be a about 150EUR one where > I can install by myself the needed s/w (OpenMoko style!) and use it as a > portable multimedia player - for the beginning! :) > > In general is a NICE TRY and hope you'll release soon a ready to run device. > > Cheers > > Tony > > On Fri, Jul 24, 2009 at 10:41 AM, Christoph Pulster > wrote: > > > >> 2. you announce products which are not exitant for sales. > > > It is our intention to announce roadmaps in the most open way > > > > customers prefer to know less and creat rumours. > > > > >> 3. you got no MPEG-patent licences. > > > We don't need them. > > > > Nobody needs them, but you have to pay them anyway. > > (Sisvel definition: any piece of HW who can decode MPEG algorith) > > > > >> 2. you base on "made in China" (synonym for crap in Europe) > > > Iphone is made in China. > > > > I am mentioning a marketing problem. > > I am mentioning a quality problem. > > Besides, Iphone backside says "assambled in China". > > > > >> 3. the PDA clam-shell form factor is obsolete > > > Not a single one commented negatively about the clamshell. > > > > Psion Plc. invent the clamshell and set the top-level of usable keyboard > > verses form-factor with Series 3 twenty years ago. > > We are in the SMS/twitter age now. Some vitual keyboard with multi-touch > > usability is sufficient. People who want to write full sentences buy a > > pencil with white paper. > > > > > > In general, what advantage does the NanoNote have to an Iphone with > > Linux installed ? > > > > > > Christoph > > > ___ > 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: New Open Hardware company
Laszlo, excellent link to wildcat, thanks! Free mechanical tools are the weakest part (aside from free IC design tools), so this may take a while until it becomes a real production option but it's definitely on the radar. I will follow up on wildcat in a little bit. Best Regards, Wolfgang On Tue, Jul 21, 2009 at 05:44:06PM +0200, Laszlo KREKACS wrote: > On Tue, Jul 21, 2009 at 1:52 PM, Wolfgang > Spraul wrote: > > For mechanical design, it's even harder. Werner thinks HeeksCAD is the best > > candidate, so Qi is looking into that now. Our mechanical engineer Tully > > (ex-OM as well) has found some serious problems with HeeksCAD already, that > > he says prohibit him from doing effective work to prepare for plastic > > injection. Oh well... > > So on the mechanical tool, same thing, we want something free, and we will > > follow Werner's leadership or ask him for advice if we are ahead of > > gta02-core > > in some area. > > I tried out HeeksCAD too. For me the showstopper is the complete lack of > true boolean operation. It simply "group" the objects together, but dont > really > union them (in mathematical correct way). > > The best candidate (the most serious open source software) would be > wildcat: http://wildcat-cad.blogspot.com/ > http://code.google.com/p/wildcat-cad/source/list > > However its author stopped working on it (unknown reason) from this > january. > If I were Qi Hardware I would seriously consider to donate to this project > or even hire the developer (wildcat cad). Opensource 3D cad tool needs > a kick to get starting. > > HeeksCAD is a "simple" frontend to opencascade.org. (I dont want to > be negative here.) > > I definietly propose you to get touch with the wildcat developer. > What is his plan (he is a phd student?), how you could help him to > continue the development, and finish the basic showstopper features. > Please consider to get contact with him. > > I do hope the best for you. The longer you stay in business the more > improvements gets the free software engineering tools (cad, kicad, etc), > what is a wonderful thing. > > Best regards, > Laszlo > > ___ > 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: New Open Hardware company
Rafael, > > (ex-OM as well) has found some serious problems with HeeksCAD already, that > > he says prohibit him from doing effective work to prepare for plastic > > injection. Oh well... > This a surprise to me, as i didn't know this mechanical tool. Are you a mechanical engineer? Or do you know some that are interested in joining to work on a free design and/or can do some coding too? :-) There seems to be a lot of activity in HeeksCAD the last 6 months, so that's encouraging. It uses OpenCASCADE. Do you know other free 3D tools? Thanks, Wolfgang ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New Open Hardware company
maddog, thanks for your thoughtful reply! > Fortunately the mp3 issue (as a continued example) can be met other > ways. Since the designs are open, the addition of an mp3 codec by a VAR > (and payment of that royalty in jurisdictions where it is required) is > something that could be done even without any effort by the open > community or Qi. But the issue has to be communicated and understood, > the solution has to be planned. IMHO the creation of an add-on package > by Qi for mp3 and other royalty-bearing codecs would be something useful > for their customers, and would call attention to the fact that these > codecs are not free either as in Freedom nor as in Beer. Perfectly fine. Nothing is more important than clarity, and professional work. I do agree with some of Christoph's criticism in how Openmoko handled the MP3 situation back then. I too tried my best but wasn't satisfied with my results. It was a nasty experience being attacked by one of these critters. Having said that, both Openmoko and Qi have learnt from it (Christoph too I think), and hopefully we can be smarter going forward and focus our energies towards doing GOOD THINGS that make us happy. What you describe there maddog is something I can subscribe to immediately. If anybody wants an 'official' statement of Qi & patents or Qi & patented codecs, please ask Steve over in the Qi developer list. He will word something that can stand the test of time, which I cannot. Wolfgang On Tue, Jul 21, 2009 at 10:25:21AM -0400, Jon 'maddog' Hall wrote: > >#2 Not only do we 'announce' products that are not for sale, but in > >addition we have an open roadmap and design the products based on > >community feedback. > > A comment on this: > > Of course designing a product with as much input and feedback from your > community of customers is important. But when I say "customers" here, I > speak in the broadest possible terms: > > - developers > - end users > - Channels (VARs, Distributors, Resellers) > > Wolfgang has announced several goals of Qi, a main goal being that of > "openness" and the support of Ogg formats. This may be in conflict with > goals of his channels, to be able to support both Ogg and mp3, and > therefore reach a large enough marketplace to justify selling the > product. > > This may mean that the product sells in the tens of thousands instead of > the millions. That may be fine as long as it meets the other goals of > Qi and the people that invest time and money in Qi, including > manufacturers and distributors. > > Fortunately the mp3 issue (as a continued example) can be met other > ways. Since the designs are open, the addition of an mp3 codec by a VAR > (and payment of that royalty in jurisdictions where it is required) is > something that could be done even without any effort by the open > community or Qi. But the issue has to be communicated and understood, > the solution has to be planned. IMHO the creation of an add-on package > by Qi for mp3 and other royalty-bearing codecs would be something useful > for their customers, and would call attention to the fact that these > codecs are not free either as in Freedom nor as in Beer. > > I have seen lots of people communicate congratulations to the new > company and I too wish them success. Part of that congratulations > should be the honest appraisal of their plans so they meet their goals. > > Part of that is helping them get feedback from the community of their > true customers, whoever those true customers are. > > Warmest regards, > > maddog > > > > ___ > 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: New Open Hardware company
Christoph, wow I like your list! Old mistakes: #1 Believing in the community? No comment. #2 Not only do we 'announce' products that are not for sale, but in addition we have an open roadmap and design the products based on community feedback. #3 We don't need an MPEG-patent license because we don't want to play patent- encumbered data formats, and we will try everything to engineer around such patents. We want to have the best Ogg Theora experience out-of-the-box. The whole point of our project is to bring people together that believe in free software and free content. If you are not in that group no reason to be depressed :-) (I hope you spare us all another rant about Openmoko & Sisvel) #4 I'm not sure whether we 'aim VAR' or not. Maybe Steve does? New mistakes: #1 Dr. Schaller already called it 'vintage hardware'. I have to say I love this idea, even though the NanoNote hardly fits. We focus on freedom anyway, not technology. #2 made in China - don't you think the naming is genius? I love the Ben, Ya, Mu and Guo series. A little Chinese class for all of us :-) If you can only associate China with crap, that's unfortunate indeed. The truth is, same as the FreeRunner, production of our devices will be in China for the foreseeable future. R&D in Taiwan. #3 My Blackberry keyboard beats everything else. Not sure we get that good, but I take this as a valid point, we want to produce good quality. Thanks for your feedback! Wolfgang On Tue, Jul 21, 2009 at 02:44:00PM +0200, Christoph Pulster wrote: > Hi, > > my thoughts to Qi / NanoBook: > > Mistakes repeated from Openmoko times: > 1. you believe too much in the community. > 2. you announce products which are not exitant for sales. > 3. you got no MPEG-patent licences. > 4. you dont aim VAR. > > New mistakes: > > 1. you base on old-fashioned hardware > (Zaurus was state-of-the-art, a hugh community existed, although Sharp > did not give attention to it at all) > 2. you base on "made in China" (synonym for crap in Europe) > 3. the PDA clam-shell form factor is obsolete, there is no small AND >useable physical keyboard > > > Anyway I wish you best success with your effords, Steve, I really do. > > Christoph > > ___ > 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: New Open Hardware company
Werner, you can mark my words - I am becoming a real mutt fan now. Unless someone else is faster, I will port mutt over to the NanoNote and use it as my offline email device :-) Next time I come visit you in Buenos Aires this will work! Wolfgang On Tue, Jul 21, 2009 at 08:27:02AM -0300, Werner Almesberger wrote: > Dr. H. Nikolaus Schaller wrote: > > most FOSS. Unless we restrict the Non-G-UI to commandline and > > ncurses. > > I noticed that is has an escape key. So vi will be fine. What else > could one possibly wish for, except that more GUI designers would > draw their inspiration from the grace and style of vi ? :-) > > Historical note: once I had Linux run on my Psion S5 and took it to > a conference. The UI consisted of eight virtual consoles with a > shell each, with whatever I chose to run there - typically a vi, so > I could switch from taking notes on various topics just by changing > consoles. Despite the device's many shortcomings, the system felt > amazingly productive, almost on par with the HP-100LX. > > - Werner > > ___ > 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: New Open Hardware company
Shaz, (cross-posting to develo...@lists.qi-hardware.com, if you have more Qi-specific questions please ask me over there) > This is good news. Congrats and good luck. By the way how are you guys > planning to go along with OpenMoko efforts? Both Openmoko and Qi believe in free technology, so for all of us it's great if there are more players playing by the same rules. The same is true for gta02-core, the University of Sao Paolo, etc. I wish Openmoko success with Project B or any future projects that may be coming. Sean has reorganized the company, but I'm sure he will come back stronger and will have a few surprises for us! Also don't count out the FreeRunner yet, the development activity in this forum shows it. It remains the most interesting mobile Linux development device on the market right now, by far! Everybody - buy more of them and keep developing, the best pieces of what you are developing will find their way into free alternatives to the corporate consumer electronics giants we have around us right now. At the same time I hope Openmoko the company and community wish Qi Hardware well, because at the very least, even if we fail, we had some fun and contributed more bits and pieces to the pool of free technology. I think the breakthrough in this will happen for sure, only question is when. > Are the hardware efforts in parallel to openMoko community Openmoko published the schematics in PDF form, plus some parts of the electrical layout (netlist, footprints). gta02-core goes one step further and uses a free tool, KiCAD, for all electrical design. There are not many free EDA tools out there, so it was natural for Qi to follow Werner's leadership in selecting a tool. So Qi will use KiCAD as well, and our original KiCAD files will be live on the web from day 1 (they are already, www.github.com/adamwang). If Werner would change the tools he uses for gta02-core, Qi Hardware would seriously consider doing the same. We would not compromise on the degree of freedom, however (I doubt Werner would do that either :-)) I think the most important is that we stay close to each other in the tools and file formats we are using, contribute to a common pool of libraries (www.kicadlib.org), etc. There is _HUGE_ room for optimization in the hardware industry, the dregree of standardization is depressingly low for me. For mechanical design, it's even harder. Werner thinks HeeksCAD is the best candidate, so Qi is looking into that now. Our mechanical engineer Tully (ex-OM as well) has found some serious problems with HeeksCAD already, that he says prohibit him from doing effective work to prepare for plastic injection. Oh well... So on the mechanical tool, same thing, we want something free, and we will follow Werner's leadership or ask him for advice if we are ahead of gta02-core in some area. > OpenMoko community decided hardware will be taken care of by your company Definitely possible. That's one reason we are staying close to the free tools and file formats Werner has chosen for gta02-core. Making a smartphone is a terribly hard job. I just come from 2 years of round-the-clock work of doing it. So I really appreciate that for now Werner keeps the momentum, the University of Sao Paolo (and actually 1 or 2 others) have shown up to try to produce them. More power to them! But later on, definitely, it is imaginable that Qi Hardware will produce free gta02-core phones. Talk to Steve about the roadmap. > The software stacks are the same as much as I can comprehend from the thread. We try, but calling them 'the same' right now would not be correct. We will probably use u-boot, Linux kernel of course. For our own images, we will try to use OpenWrt initially, not OpenEmbedded. We try to get Debian running well, so basically we want to have Debian if you want full flexibility, and OpenWrt if you quickly want to cook up an image targeted at a particular use case or user. d-bus, Python. Above that it becomes less clear. One reason is that the first generation device has no RF. Once we have RF, I can tell you in general I prefer FSO over Android any time. More flexible, more maintainable, more modular. But that's just me and we have to find out over time what the people that are interested in our devices want. Wolfgang On Tue, Jul 21, 2009 at 04:41:34PM +0600, Shaz wrote: > On Mon, Jul 20, 2009 at 9:47 PM, steven mosher wrote: > > > A while back Wolfgang mentioned that he and I were starting a new > > venture.Drop > > by and say hello. > > > > This is good news. Congrats and good luck. By the way how are you guys > planning to go along with OpenMoko efforts?Are the hardware efforts in > parallel to openMoko community or OpenMoko community decided hardware will > be taken care of by your company. The software stacks are the same as much > as I can comprehend from the thread. > > > > > > http://www.qi-hardware.com/ > > > > Steve > > > > ___ > > Openmoko community mail
Leaving Openmoko and continuing with Openmoko
Hi everybody, today I wanted to make it official that I left my employed role at Openmoko Inc. two weeks ago. I worked as Sean's lead for all engineering activities for over 1.5 years, and have to say it was a hell of a ride! Thanks a lot to Sean and all former and current Openmoko employees, as well as our community and customers, for giving me such a challenging and also rewarding environment to work in. It was an honor to work with all of you! I will continue to work with Sean and Openmoko Inc. in an outsourcing role. In parallel, me and other ex-Openmoko employees are trying to regroup outside of the company to add new flavors to the Openmoko family. Stay tuned for news as this unfolds, we will need your support. The key breakthrough Openmoko achieved in my mind is to kickstart a collaborative way to develop consumer electronics. Sean is yet to thank enough for the groundbreaking and truly visionary entrepreneurial role he played in that. When I joined Openmoko, I had never heard about Creative Commons. Now I am meeting with semiconductor companies lobbying them to publish more documentation under CC licenses. And I am blown away by Werner's gta02-core project which has all schematics and layout files under a Creative Commons ShareAlike license from day 1, and is using only Free Software tools. If you look at today's best consumer products, they are the results of endless polishing by a tightly controlled group of people and companies. The results are amazing - Apple products come to my mind, Blackberry and others. Unfortunately as of today the end user experience of a Neo Freerunner is far away from that :-) But that doesn't mean that the visionary role Openmoko is playing leads in the wrong direction. It just needs more time. As consumer electronics become more complex, for example interact more over radio interfaces, it will increasingly become harder for a tightly setup and controlled group to make great end user products. It will be slow and expensive. Zoom forward and I can see how freely formed groups of companies and individuals collaborate in the Creative Commons ShareAlike way, on an equal playing field, to make products that are both better and cheaper for a particular user group than anything else out there. We have a long way to go on this path, Openmoko the company as well as the community and new offspring companies need to stay together and keep the faith. You can count me in. I am reachable and will stay active under my wolfg...@openmoko.org account, or my private account wspr...@q-ag.de. Feel free to contact me for anything Openmoko or Freerunner related, ideas for new collaboratively developed products, etc. Wolfgang ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Freerunner's Future
Dale, > The Freerunner had (has?) great potential, but we > couldn't realize that potential without basic reliable functionality. > If the concerted efforts of many talented (in some cases even paid) > engineers couldn't achieve that basic milestone, it seems unlikely > that it will be achieved by a loosely-organized group of unpaid (and > demoralized) volunteers. Thanks for your concern and (slight) impatience. Several efforts are underway to form really solid groups, both community and commercial, to continue with the open phone. I haven't noticed any demoralization, quite to the contrary. But I do believe the size of our community is stagnant or slowly shrinking. Which only makes sense given that there is not much visible progress right now. BTW here are some interesting statistics about our community: http://downloads.openmoko.org/stats/05/ And number of subscribers to our mailing lists: https://monitor.openmoko.org/munin/chandra/sita.openmoko.org-mailman_detail.html (openmoko-kernel is missing for some reason, we will fix this, I believe it has around 600 subscribers) As for the 'big picture' of open devices - on the technical level there are a number of categories that are merging over the next few years: phones, portable media players, electronic dictionaries, navigation devices. Other non-mobile categories are also not far behind (picture frames, set-top boxes, wifi routers, NAS). For these types of devices, there are a few 'open' options here and there, but by Openmoko's standards for the largest part it's all closed. Going forward we need to find more semiconductor partners that understand 'open' and know how they can create value with it. In today's consumer electronics industry, semiconductor companies are the ones writing the drivers, they do reference designs for manufacturers. Trying to do open devices without the help of semiconductor companies will just not work. The good news is that pretty much all semiconductors have a relaxed, and often friendly, attitude towards 'Linux' nowadays. They see the potential, and real size of the market today. Things like Android help tremendously! Bottom line - the path to a fully open phone as envisioned by Openmoko and our phantastic community is still long. Maybe even 5+ years. I'm not discouraged by that at all. gta02-core is on track, and Werner has as clear a long-term plan of why and where this will all go as everybody else. Realistically I am hoping that actual physical hardware will come out of it within 12 months or so. In other parts of the Openmoko landscape, work is going on on non-phone projects, whether they are called Project B or C or D. Even if those devices are not a phone initially, trust me they will all become phones :-) Thanks for staying with us, I hope you enjoy the ride with your 'pioneering' Neo (I'm a daily user myself). Best Regards, and keep your feedback coming! Wolfgang Dale Schumacher wrote: > On Fri, Jun 5, 2009 at 9:00 PM, Boris Wong wrote: > >> Steve Mosher wrote: >> >>> 1. Its a mobile Phone First, and a multi purpose platform secondarily >>> >>> >> I actually like the perspective of #1 very much and you should keep it >> as such. >> > ...snip... > >> Free the phone; we already have multi-purpose platform devices that run >> linux. >> > > I'm totally on-board with this message, vision and mission. The > problem is--after all this time, that vision remains unfulfilled. My > biggest disappointment has been the fact that my Openmoko Freerunner > (which I've had since helping form the Austin buying group) is still > not _nearly_ as reliable as any cheap simple handset I can get for 10% > of the cost. The Freerunner had (has?) great potential, but we > couldn't realize that potential without basic reliable functionality. > If the concerted efforts of many talented (in some cases even paid) > engineers couldn't achieve that basic milestone, it seems unlikely > that it will be achieved by a loosely-organized group of unpaid (and > demoralized) volunteers. > > I truly hope I'm wrong--and I applaud the efforts of those who > continue to strive for this goal. I also want to express my thanks > for the efforts of all those who have worked so long and hard trying > to achieve this vision. > > ___ > 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: MP3 patents (was: Freerunner's Future)
Christoph, Openmoko phones are MP3-free and thus do not infringe on any MP3 intellectual property. Wolfgang Christoph Pulster wrote: >> It's more than welcome to see Openmoko Inc. is still very much in >> support of the Freerunner/GTA02 and will provide the community with >> support in areas like the hosting infrastructure as well as the legal >> side (trademarks). >> > > Please remember the patent infridgements concerning MP3 (www.sisvel.it). > Openmoko Inc. did not solve this issue until today. > As a result, all sales inside EU are patent infridgments, all reseller > inside EU community have to live with the fact, that local customs seize > their Freerunner order anytime. > > Christoph > > ___ > 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: MP3 patents (was: Freerunner's Future)
David, > Once was said OM was in sue trying to resolve this but I have no more > info on that for a long time. You have a good memory! :-) Yes, we were working with the Software Freedom Law Center in New York on our patent strategy. There was a decision of the US Supreme Court that undid some of the ongoing work. Don't expect anything to come out fast, but it's still moving. Wolfgang David Reyes Samblas Martinez wrote: > pattens as are now a days is a real PITA, no matter if you don't have > the libraries installed in the device,if you are cached by those > pirate... sorry pattens agencies in customs they just have to say to > the court the device is suitable to play mp3 and you don't have > license, and your parcel will be retained for months/years, no matter > the court final decision, you as reseller are fucked because you have > payed for a material you cannot touch. So orl you arrive an agreement > with the agency (+money,-less time) or wait for the lottery of the > court and cross your fingers to have a judge a little bit more techy > than the average, because if not, your parcel will be returned by > default, and if the judge has a bad day you surely will pay a penalty. > > Once was said OM was in sue trying to resolve this but I have no more > info on that for a long time. > > 2009/6/5 Al Johnson : > >> On Friday 05 June 2009, Christoph Pulster wrote: >> It's more than welcome to see Openmoko Inc. is still very much in support of the Freerunner/GTA02 and will provide the community with support in areas like the hosting infrastructure as well as the legal side (trademarks). >>> Please remember the patent infridgements concerning MP3 (www.sisvel.it). >>> Openmoko Inc. did not solve this issue until today. >>> As a result, all sales inside EU are patent infridgments, all reseller >>> inside EU community have to live with the fact, that local customs seize >>> their Freerunner order anytime. >>> >> Openmoko removed the mp3 codecs from the images they supply, and from their >> repositories, causing frustration for many. I don't know what image they now >> ship with, but would be surprised if they haven't removed the mp3 codecs from >> that too. If it doesn't contain the codec it can't infringe the patent. What >> more do you expect them to do? >> >> >> >> >> ___ >> 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
New Life in Openmoko Phones
Hi everybody, (sorry for the cross-posting, I thought spreading the word about gta02-core and new stuff from Openmoko was worth it...) Today Openmoko released additional pieces of documentation about Freerunner hardware: board outline, footprints and netlist. Same as all other releases before - under Creative Commons Share-Alike license. Available at: http://downloads.openmoko.org/developer/schematics/GTA02/gta02_outline_footprints_netlist.tar.bz2 What is this and who is it for? Well, definitely not for end users, not for software developers, not even the typical kernel hacker. The release contains cryptic text files containing data points about our hardware - basically additional information complementing our PDF-formatted schematics release last year. The reason we released this is to support an exiting new project that has emerged over the last few weeks - gta02-core. http://wiki.openmoko.org/wiki/Gta02-core "gta02-core is a community project to create a new hardware revision of the gta02 hardware" They chose a 100% GPL layout tool, KiCAD (http://en.wikipedia.org/wiki/Kicad), which uses only text-based files hence they can be checked into typical revision control systems. Since they are text, they are also 'scriptable', i.e. scripts can extract and process data from the layout files. Werner and Dave Ball got it rolling, and are currently working on the re-layout of gta02 (http://docs.openmoko.org/trac/browser/trunk/gta02-core). The way I see gta02-core is that it opens up a path to new, fully open phone hardware. For the future of the software we are all working on right now - whether it's the kernel, FSO, Paroli/Ophonekit, etc., we either need to design new fully open hardware specifically for it, or we need to find ways to hack into phones that are 'closed' by default (either accidentally or on purpose). gta02-core focuses on the first option, and I hope will receive more attention from the community, and definitely from Openmoko the company. The path is long, even KiCAD itself may need improvements, but if a few more people get interested and join, we may have new fully open phone hardware in 6-12 months. No worries, in all this time of course the Freerunners will remain available (we have enough in stock and are ready for new production runs if necessary), and hopefully they continue to be an interesting development platform for mobile free software projects. Right now, if you want to join the revolution in open hardware development, read the gta02-core wiki page carefully (http://wiki.openmoko.org/wiki/Gta02-core), and join the mailing list (slightly confusingly named gta03 :-)) at http://lists.openmoko.org/mailman/listinfo/gta03 Then see where you can contribute - it's a wide open field with many possible tasks, no matter which background you are coming from. I'll see what I can do. Best Regards, Wolfgang ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Openmoko is hiring
Hi everybody, Monday was the first day after Chinese New Year, and the first day in our new office in Xindian, a bit outside of Taipei, in the vicinity of many other interesting tech companies. So far we find lots of good restaurants all around, very nice... Two pictures from the new office http://people.openmoko.org/wolfgang/xindian_office_view1.jpg http://people.openmoko.org/wolfgang/xindian_office_view2.jpg In the second one you can see Taipei 101 in the background (http://en.wikipedia.org/wiki/Taipei_101 ). If you want to stop by for a coffee, please feel free to do so. The address is 9F, No.276, Jiang-Guo Rd. Hsin-Tien City, Taipei County 231 Taiwan Now that we are in our new office, and in the new Chinese year, recruiting will become a much bigger focus for us. We have even hired a full-time recruiter, who worked for our parent company FIC before. She will start next week. The open positions are mostly hardware positions in Taipei, but even though the readers on these lists probably live outside of Taiwan, I wanted to share the information so you know what's going on in Taipei. Foreigners willing to move to Taipei are also welcome, we can help with work permits etc. Without going into too many details, some of the open positions in Taipei are Electrical Engineer, QA Engineer, QA Manager, RF Engineer, Production Engineer, Software Engineer (low-level / kernel). There is one open position right now we are looking to add anywhere in the world: *** Paroli Project Member *** For details, see http://www.paroli-project.org/ If you believe you can make a difference in Paroli, bring the power of Python to an embedded device, please get in touch with me. Best Regards, Wolfgang ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Questions about the usability of GTA02
Sarton, this is a great mail, spot on, thank you very much. Wolfgang On Feb 2, 2009, at 1:27 PM, roguem...@roguewrt.org wrote: > Gothnet wrote: >> >> >> Rask Ingemann Lambertsen wrote: >>> Why? What is it that you expect the Neo Freerunner to do that the >>> other >>> handheld devices out there won't? You will have noticed that >>> pretty much >>> all >>> the unhappy users are those expecting the Neo Freerunner to be just >>> another >>> well polished smartphone. If you buy a Neo Freerunner, do it for >>> the right >>> reasons so you avoid disappointment. >>> >>> >> >> I take issue with that a bit. > > Maybe it's better stated as "The people who expected reliable basic > functionality as a phone" were disappointed. You can surely obtain it, > but just don't expect it. > > I think the main point was to make sure it meets your extended needs > as > a mobile device, just not as a phone. The phone part seems to be > further > down the track for 'out-of-the-box' functionality. > > I don't think we should dance around the learning curve, especially > when > someone says they are relatively new to linux. We can all debate the > phone capabilities and reliability but in the end, some people are > going > to have as much success using the freerunner as a phone as they have > their desktop with comparable hardware. I think for now, we should > make > it blatantly obvious that this is first and foremost, at this point in > time, a portable linux computer and there is firmware yet to be > developed to take full advantage of the freerunner as a reliable phone > (TBA). Third party firmware should not be taken into consideration > when > pitching the device as a phone, that should be something the user > explores once OM can completely support their own device. > > Currently there are very few users, we are all QA/devs/coders/ > hobbyists. > I do become a user now an then between battery removals :) > > Saying anything less is a little deceptive with regards to sales. > Saying > anything more can get a little convoluted to the non-technical or > linux > newbie. > > Don't get me wrong, I love my freerunner ... I really wish I could > pimp > it as a phone rather than just exclaiming "look! it works!" ... when > quite often I realise I'm wrong ... after hitting answer 50 times and > yelling at it to shutup :) > > There really are some moments I can't help but giggle about ... but > that's me and I know I have a wierd sense of humour :) > > Sarton > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Questions about the usability of GTA02
Tschaka, > 4) GTA03? > Or would u rather advise me to wait for GTA03? No, definitely not. First of all GTA03 is still a long way out, at least 6 months, maybe 9, maybe more. But more importantly, at Openmoko you cannot assume that GTA03 = GTA02 + new hardware features. When Sean started the project, the reason he chose to use 100% FOSS software only is because it gave him full flexibility to make very unique and interesting devices. GTA03 is an independent new product, the continuity to GTA02 is foremost on the software side, hardware continuity only follows because if we have a great fully open driver for a particular chip, we are more likely to use that chip again. The software stack we are building together can be (roughly) described as: Qi + Linux kernel + FSO + Paroli. But for the hardware side, at this point you should not make any assumptions about GTA03 hardware features. They have not been finally decided yet, and in fact may be so different from GTA02 that we will continue to produce and ship GTA02 for a long time, even after GTA03 is released. That's why it's very important for us to continue to improve GTA02, both on the hardware and software side. Since GTA02 shipped about 6 months ago, the software side has taken off in ways we could have never imagined. It must be the world's largest software construction site by now :-) Om2008.12, FSO, SHR, FDOM, Qt Extended, Debian, Gentoo, Android, OpenWrt. Most of these distributions don't really work very well yet, compared to typical polished mass-market products. I think Om2008.12 or QtExtended come closest. But all of the distributions are definitely a lot of fun, and great seeds are being planted that will lead to better software in the future. > But shall i, at least, rather wait for a7, or a8 if i want a buzz > fix by > default? at the moment, this is, besides battery life, the issue that > concerns me most. On the hardware side, we went through several revisions - A5, A6, A7 coming up. There will be more, we will continue to improve quality whenever we see an opportunity. This creates a dilemma. The more we improve quality on the hardware side, the more we leave some customers 'behind' with old hardware revisions that cannot be easily upgraded. And our process is totally open. For example if you buy an A6 now, depending on which country you are in, and which network you are typically using, your chances of hearing the buzz are higher than with A7 (which is not shipping yet). Your best bet is to buy from a distributor that has a good return policy. We work with our distributors on finding efficient solutions for the situation we are in, where we come out with improved hardware revisions every few months, and all the defects that are being fixed are openly known and talked about. This creates a lot of work on all sides, but with a little understanding that we are all sitting in the same boat, I'm optimistic we can find a good way through this, with happy customers in the end, even if it's a bit chaotic. The FreeRunner is available and selling in 16 countries, and I'm very happy to see our community active in so many areas. The whole thing really seems to work :-) Thanks everybody, Best Regards, Wolfgang On Jan 31, 2009, at 10:11 PM, Tschaka wrote: > > So, again somebody is asking a question about usabilty. Please don't > get me > wrong, i actually browsed the mailing lists and wikis, but still > there are > some unsure things, and i'd like to have a bit more of a > summarization. > > I'm interested in buying an openmoko Neo Freerunner, but i'd like to > get to > know some things before i will. I'm a student, so 300 €(even 249 €, > Pulster > ;) ) is an amount of money i can't spend every month, or w/o any > effort. So > i don't want to end up getting a Neo now, being unsatisfied and > getting a > gta03/other brand later this or next year. > > I'm not that deep into Linux, but i'm running Ubuntu reasonably > well, so i'm > not totally unfamiliar with linux. i know what svn/git is, and > wouldnt be > totally unable to build somethings from sources - although it's not > an every > day task here. > > So, here's my list of questions, i hope somebody will answer and > clear them > up a bit :) > > > 1st) Battery Power > > sometimes i'm at university from 9am to 10pm 6 days a week. I'm often > browsing mobile news pages with my phone when going to university, > or having > a chat (XMPP of course!), approx 40 minutes a day. In the meantime i'm > listening to music. > I got no actual watch, so my phone is my watch, means i often > activate the > background light to get to know the time. > I'm sending like 1-5 messages a day, having a phone call now and then. > Now and then i would like to access the web via wifi. > > So, since i'm not able to plug the phone to a power source at > university, > would i be able to run it the whole day, without getting out
Re: Freerunner is running OpenWrt!
Michael, > That's the way buildroot works. > >> I'd say take it to the kernel list and ask Andy. > > No. We're not going to change the way openwrt works. OK understood (and I never asked for that, BTW, I was just curious to understand why you went this route). The good news is that the kernel is making incredible progress, so whenever you are ready to uptick to a more recent vanilla version, andy-tracking should already be there. Best Regards, Wolfgang On Feb 1, 2009, at 12:50 AM, Michael Buesch wrote: > On Saturday 31 January 2009 17:32:53 Wolfgang Spraul wrote: >> Michael, >> >>> No we take vanilla 2.6.28 and apply the diff between 2.6.28 and >>> andy- >>> tracking. >>> We can also apply additional patches, but we don't for now. >> >> hmm. Andy is the expert here, maybe you ask him over on the kernel >> list. >> Why pin it to an old andy-tracking version, and then manually base it >> on a kernel.org tree + manually generated diff? Sounds complicated to >> me... > > That's the way buildroot works. > >> I'd say take it to the kernel list and ask Andy. > > No. We're not going to change the way openwrt works. > > -- > Greetings, Michael. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Freerunner is running OpenWrt!
Michael, > No we take vanilla 2.6.28 and apply the diff between 2.6.28 and andy- > tracking. > We can also apply additional patches, but we don't for now. hmm. Andy is the expert here, maybe you ask him over on the kernel list. Why pin it to an old andy-tracking version, and then manually base it on a kernel.org tree + manually generated diff? Sounds complicated to me... As of today, I believe andy-tracking is already based on .29, and if you don't have local patches why don't you just build andy-tracking live as it is? I'd say take it to the kernel list and ask Andy. Best Regards, Wolfgang On Jan 31, 2009, at 7:40 PM, Michael Buesch wrote: > On Saturday 31 January 2009 04:41:46 Wolfgang Spraul wrote: >> Mirko and others that helped here, >> this is great stuff, congratulations! >> >>> - kernel (2.6.28) is building and booting (merging the Openmoko and >>> OpenWrt patchsets, whereof one (and that's not ours ;)) consists of >>> either over 620 little non-atomic patches or one 10MB patchblob >>> [kudos to git!], is no picnic (thanks to the work of Michael "mb" >>> Buesch at this point!) >> >> Can you extract the remaining diff between andy-tracking and what you >> have and send them as patches to the kernel list? > > We don't have additional kernel patches, yet. > We basically use andy-tracking from two weeks ago. > >> How does your kernel >> build work? You take andy-tracking, apply a patchset, then build? > > No we take vanilla 2.6.28 and apply the diff between 2.6.28 and andy- > tracking. > We can also apply additional patches, but we don't for now. > >> If you have OpenWrt-specific patches, where are they stored? > > In the openwrt tree under target/linux/s3***/patches-2.6.28/ > > -- > Greetings, Michael. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Freerunner is running OpenWrt!
Mirko and others that helped here, this is great stuff, congratulations! > - kernel (2.6.28) is building and booting (merging the Openmoko and > OpenWrt patchsets, whereof one (and that's not ours ;)) consists of > either over 620 little non-atomic patches or one 10MB patchblob > [kudos to git!], is no picnic (thanks to the work of Michael "mb" > Buesch at this point!) Can you extract the remaining diff between andy-tracking and what you have and send them as patches to the kernel list? How does your kernel build work? You take andy-tracking, apply a patchset, then build? For now, I think you should build andy-tracking, and since it is evolving quickly, it would be important to feed your patches back fast otherwise you might have to uplevel them again and again, or risk falling behind in your kernel version. If you have OpenWrt-specific patches, where are they stored? Best Regards, Wolfgang On Jan 31, 2009, at 2:58 AM, Mirko Vogt wrote: > Hey folks, > > I'm glad to announce that OpenWrt now has basic support for the > Openmoko GTA02 "Freerunner"! > > There's still lot's of work to do but let's see what's already > working for now: > > - kernel (2.6.28) is building and booting (merging the Openmoko and > OpenWrt patchsets, whereof one (and that's not ours ;)) consists of > either over 620 little non-atomic patches or one 10MB patchblob > [kudos to git!], is no picnic (thanks to the work of Michael "mb" > Buesch at this point!) > - D-Bus and the freesmartphone.org reference implementation (they > import the libc.so.6 via ctypes - I was really puzzled when python > told me it can't find my libc, because I was using the uclibc) > - Xglamo with acceleration (in the beginning Xglamo just crashed, > even JTAG wasn't available anymore; it took us weeks to figure out > that a compiler bug was the cause (thanks to Felix Fietkau, Holger > Freyther and Lars Clausen) - Lars btw. is currently making good > progress to get glamo acceleration working within Xorg) > - the EFL (enlightenment foundation libraries) and enlightenment > including illume (needs some more love to make it really fit into > the OpenWrt-environment - currently and are required > as pre-installed host tools) > - paroli phone application suite (in case it's working ;)) > > A few days ago we established the first OpenWrt<->OpenWrt phone call > which worked out of the box after flashing our devices - so we > thought that might be a good occasion for an announcement :) > > We're pleased for all of your feedback and any kind of help is > highly appreciated! > > Thanks a lot! > > mirko (the other one) > > -- > This email address is used for mailinglist purposes only. > Non-mailinglist emails will be dropped automatically. > If you want to get in contact with me personally, please mail to: > mirko.vogt nanl de > > ___ > 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: No more optimization team
Bernd, > i am sure there will still be optimization, but without a dedicated > team, so there won't be regular updates. Correct. From my perspective the updates weren't helpful anyway, I'd rather not talk and instead deliver. The latest image, including all optimizations from the optimization team are in http://downloads.openmoko.org/daily/testing/ (openmoko-testing-om) We were testing this image a bit, haven't seen the full test report yet. More or less it will be the same as Om2008.9, the most noticeable improvement will be boot time reduction to about 1 minute. Now the work in that branch (org.openmoko.dev) is finished, and instead we will bring those fixes upstream into org.openembedded.dev, benefitting many more users, first thing Mickey's FSO builds. Two more FSO milestones over the next 4 months, with optimizations of course continuing everywhere in that time, then a fork into another major release branch. ACTUALLY - speaking about all this - we are looking for a serious distribution maintainer. Someone who can do the exceptionally hard work of distribution integration, fixing bugs, small and large, from top to bottom of the stack, from UI to kernel, across many packages. Someone with a proven Free Software background. Any applications just email me. Best Regards, Wolfgang On Dec 10, 2008, at 5:58 PM, Bernd Prünster wrote: > the panic about where openmoko puts their efforts in... > panic for NO REASON. > sorry no offence but, i think it is because of the infacy of some > users, > which can't hande information and start running around in circles > screaming "fire, fire fire!". > i am sure there will still be optimization, but without a dedicated > team, so there won't be regular updates. > that was ALL what johne lee said. so calm down, inform yourself. > maybe i'm wrong, but i think i can put two and two together > >> Steve, Sean, anybody more appropriate please clarify this ASAP, no >> more resources in optimization?? crisis has arrive at least to >> Openmoko Inc.??? It not sounds any good :( :( >> >> 2008/12/10 John Lee <[EMAIL PROTECTED]>: >> >>> Dear community, >>> >>> I'm writing this to inform you that the optimization team is >>> dismissed, so there won't be weekly updates anymore. Further >>> details >>> and reasons behind this are inappropriate to be answered by me. >>> >>> >>> Regards, >>> John >>> >>> ___ >>> 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: No more optimization team
David, the optimization team finished their work a few weeks ago, most people were working on new tasks already. I knew before I had to take the blame for expectations that got unprofessionally raised to a level where we could not deliver, and here I am now taking the blame. Let me explain Openmoko's software strategy for the next 6 months: ---1 current stable image Our current stable image is called 'Om2008.9', available at http://downloads.openmoko.org/releases/Om2008.9/ We are sometimes cherry-picking fixes into it, but admittedly not as many as we would like. If someone wants to step up to become stable maintainer for this image and cherry-pick more fixes into it, please let me know. Alternatively, a number of other images are available, Debian, Qt Extended, Android, FDOM, SHR, etc. See http://wiki.openmoko.org/wiki/Distributions for a more comprehensive list. ---2 Mickey's framework milestones As many people know, the next big thing for Openmoko will be Mickey's FSO framework around d-bus and Python, and the Paroli telephony UI. See http://wiki.openmoko.org/wiki/OpenmokoFramework A few weeks ago, Mickey released milestone 4, available at http://downloads.freesmartphone.org/fso-stable/milestone4.1/ In late January, he plans to come out with milestone 5, in late March with milestone 6. See here for a more detailed roadmap: http://trac.freesmartphone.org/roadmap ---3 next major release, Om2009 After the next 2 FSO milestones, Openmoko will fork off a stable branch, and spend 2-3 months on testing and bug fixing. This will lead to our next major release, Om2009. The telephony UI will be Paroli, see http://code.google.com/p/paroli/ The way things are going right now, we will probably have this release mid-next year. That's about it. Lots of good stuff happening in that direction, most importantly I would mention the progress with our .28 kernel, improved wifi driver, some attempts at getting more out of the glamo chip, improved boot time, etc. Yes, the Optimization team is gone, as part of a bigger company reorganization. Some people were laid off. Some new ones are being hired. John did a great job, and I hope he stays around to continue his excellent work, for example to bring the optimization improvements up into dev.openembedded.org so that more people can see the progress. Best Regards, Wolfgang On Dec 10, 2008, at 5:17 PM, David Reyes Samblas Martinez wrote: > Steve, Sean, anybody more appropriate please clarify this ASAP, no > more resources in optimization?? crisis has arrive at least to > Openmoko Inc.??? It not sounds any good :( :( > > 2008/12/10 John Lee <[EMAIL PROTECTED]>: >> Dear community, >> >> I'm writing this to inform you that the optimization team is >> dismissed, so there won't be weekly updates anymore. Further details >> and reasons behind this are inappropriate to be answered by me. >> >> >> Regards, >> John >> >> ___ >> Openmoko community mailing list >> community@lists.openmoko.org >> http://lists.openmoko.org/mailman/listinfo/community >> > > > > -- > David Reyes Samblas Martinez > http://www.tuxbrain.com > Open ultraportable solutions > Openmoko, Openpandora, GP2X the Wiz, Letux 400 > Hey, watch out!!! There's a linux in your pocket!!! > > ___ > 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: Any progress on the Telit UC864 3.5G modem?
Justyn, lots of changes in our hardware team, we hired some great new engineers, Adam Wang (production engineer), Ivorin Chen (layout engineer), Tully Gehan (mechanical engineer), Eva Lin (project coordinator). Working on more... As for MokoForesight, Shawn Lin left a while ago, so the whole idea is 'suspended' right now. WSOD is fixed so I'm sure it will resume properly at some point ;-) Telit has some great modules, we are not pursuing this any further at this moment, but there is a good chance we will at some point. Hope this helps, Best Regards, Wolfgang On Dec 9, 2008, at 5:58 AM, Justyn Butler wrote: > Hi, > > It's been quite a while since the MokoForesight page was updated, so I > was wondering whether any more research went into the Telit UC864G > modem (3.5G with integrated GPS). > > On the MokoForesight page it says: > > "Detailed documentation on Web. Can get even more documentation from > reseller." > "First impression is good. UC864G includes all known bands and GPS > receiver (saves more space & complications)." > > Which all sounded quite promising. Did it turn out to be a dead end? > > Regards, Justyn. > > ___ > devel mailing list > [EMAIL PROTECTED] > https://lists.openmoko.org/mailman/listinfo/devel ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Expressing hope that the next-gen Openmoko hardware might support 3G/3.5G/HSDPA when it arrives
Justyn, > I do hope Openmoko are giving the connectivity of the phone the > weighting > it deserves. ... However, for an increasing portion of the market it > is becoming > expected in any new "smart" phone. ... > So this email is about making sure that it is known that there is a > market of people who have suspended their hope in OM for the time > being but will come rushing back once it can offer 3.5G Yes, we are fully aware of 3G, thanks for the reminder still. Luckily development is heating up, both internally we continue hiring and our community grows and buys more phones. The smarter we are in ramping this up the faster we get to 3G. Best Regards, Wolfgang ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Buzzing (was :The forbidden topic: Glamo OpenGL)
Timo, > You will find echo fixed in Openmoko's 2008.11 release, if you keep > using the Openmoko distro, and responsiveness and touch screen > usability will also improve with 2008.11 release. End call / accept You are right that people are working on these things and fixes appear. However, please don't expect a real Om 2008.11 'release' before the end of the month. There is simply too much progress in all areas right now, we need a bit more time for everything to settle before calling something another 'release'. Maybe a few months. Maybe we come out with snaphost in between, similar to FSO's milestone builds. If someone proves me wrong then great, I am just telling you please keep your Om 2008.11 release expectations low. Wolfgang On Nov 17, 2008, at 6:35 PM, Timo Jyrinki wrote: > 2008/11/14 Gothnet <[EMAIL PROTECTED]>: >> It really needs work on the basics. I mean, responsiveness is not >> there, >> interface is dodgy (the "end call" button being in the same spot as >> the >> "accept call" button, and being unresponsive, made me hang up s >> many >> calls). Echo on calls, battery life... > > These are all small issues as such, as they are all on the software > side and many have been either fixed or are different on different > distributions (you don't need to use Openmoko's distribution - you can > use Debian, Qt Extended, SHR, ...). > > You will find echo fixed in Openmoko's 2008.11 release, if you keep > using the Openmoko distro, and responsiveness and touch screen > usability will also improve with 2008.11 release. End call / accept > call stuff are just UI things, easy to fix, but maybe you should file > a bug report about it since otherwise no-one might notice. > > The buzzing issue is the only "real", serious issue. > >> Also, I know everyone loves X, but is it really the best choice for >> a low >> powered device that needs a responsive UI? > > Yes :) Any unresponsiveness in the UI is not because of the X. > >> I think maybe I had the wrong impression about the state of the >> software when >> I bought it. > > Probably. It's not a phone product yet, it's a phone in development. > From your point of view I can understand the frustration with the > other issues, but for me they are just a few things to work on / test > fixes. The buzzing / hw issue is really the only thing I'm worried > about, since it needs to be fixed and there is no known software fix > for it yet. > > -Timo > > ___ > 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: Calling interested Glamo OpenGL developers (was: The forbidden topic: Glamo OpenGL)
Lally, > how long is OM going to be using the Glamo? The glamo will be kept for the lifetime of gta02, i.e. every gta02 will have the glamo chip. For gta03, release date unknown, the decision is to not have a glamo, we use the acceleration of the SoC. > The GTA02's been on the brink of obsolescence since the day it was > introduced. Don't agree with you. In the long run everything is obsolete. GTA02 is a real pioneering device for Linux in mobile phones, and is still advancing the state of Free Software in mobile phones in many areas. We owe the community better hardware, and have made decisions internally to only focus on hardware and lower-level software. But that will not remove the pioneering status of GTA02, not even when GTA03 ships, again release date unknown at this point. > It can't even take most modern (3G) SIMs. Thanks to great work from Dieter, Joerg and Werner, this bug (trac #666) seems to be fixed now, GSM reflash utility and instructions are available, etc. Next they target trac #1024 (network re-registration). > If the Glamo (or something compatible) is going to be around for a > while, either in > a long production life of the GTA02, or in newer phones, Long production life of GTA02. > Hence, my earlier suggestion on just using the acceleration for some > Gtk operations. Small, effective changes. Get that done to make the > device feel responsive. If someone wants to do the big OpenGL > implementation later, fine, use this Gtk work as a sandbox for getting > a feel for the device. Very good idea. I always prefer breaking a large idea into smaller pieces. > $400 for a phone is a reasonable investment. But months of work in > one's spare time is much bigger. Before anyone commits to a > large-scale project, I think it's fair to ask OM what their plans are > with this chip. Absolutely. I have already answered many aspects in other mails, but let me summarize again: 1. We currently are disappointed about s-media. To be fair to them I do not want to quote from contracts we have with them, but let me tell you at the bottom line we feel there have been some broken promises with regards to opening documentation. 2. Because of this situation, we decided to not use s-media chips in future Openmoko products. 3. At the same time, we decided to not come out with GTA02 versions that had the glamo removed, because that would have been hard to do technically, and it would have created too much technical fragmentation. 4. Even with raster's bashing, the glamo chip is a really nice mobile graphics chip. I say this also considering when it was released. Openmoko's speed of progress still does not match industry speed. While the other (closed) chip vendors are already 2 generations ahead, we (Openmoko and the Free Software community) are still writing drivers for older chips. But we shouldn't let others distract us. Our software is 100% Free Software. We want to be able to install mainline kernel.org kernels one day. We want to be able to run many Linux distributions on the phone one day. We are coming from behind, but I'm sure with the help of the community we can even drag something like the glamo out into the open. 5. We will have the same problem with open 2D/3D acceleration again in the future, so breaking the glamo free could be considered a good 'exercise'. No matter whether you look at future Samsung, TI, Marvell chips. The 3D acceleration part is always closed. In other words needs to be opened by us. We might as well start with the glamo now, better than waiting for the 'perfect moment' which will never come... Best Regards, Wolfgang On Nov 17, 2008, at 3:40 PM, Lally Singh wrote: > Well then, > > Therein lies the question, how long is OM going to be using the > Glamo? There's apparently some real potential in the device, but > that's really measured as much by the chip's relevance as its > functionality. > > The GTA02's been on the brink of obsolescence since the day it was > introduced. It can't even take most modern (3G) SIMs. If the Glamo > (or something compatible) is going to be around for a while, either in > a long production life of the GTA02, or in newer phones, then all this > makes sound engineering sense to work on. > > Otherwise, I have real doubts about the longevity of a software > project aggressive enough to attempt major work (e.g. accellerated > OpenGL) on this chip. Lots of open source projects start off with a > bang of enthusiasm, and die with a whimper. If the chip's gone in a > few months, I don't think we'll see the project survive. > > Hence, my earlier suggestion on just using the acceleration for some > Gtk operations. Small, effective changes. Get that done to make the > device feel responsive. If someone wants to do the big OpenGL > implementation later, fine, use this Gtk work as a sandbox for getting > a feel for the device. > > $400 for a phone is a reasonable investme
Re: The forbidden topic: Glamo OpenGL
Rui & Nishit, > I might have to skip GTA03 since I have just spent a huge 300 Euros > for > a GTA02 :) > > I hope the software stack becomes less of a joke in time for GTA03 > or it'll > be hard to get much new customers... Wow, this is actually really complicated, let me tell you a bit how I see things. First of all thank you very much for buying a Freerunner! And posting so much good stuff to our mailing lists. The Freerunner is our breadwinner right now, Freerunner sales sustain Openmoko, and more importantly they grow the community around a 100% open mobile platform. You contribute in many ways. If you buy the Freerunner as a normal user for daily use (quite a few people use it as a daily phone), then your main contribution is that you buy the phone, give Openmoko some of your hard earned money to support further development. If you want to use it as a daily phone, but run into too many bugs or don't find a distribution that fits your needs, you contribute by writing up bug reports. Sending critical emails to our mailing lists or blogging about the shortcomings of the phone. Both our community and our internal people work tirelessly to address these bugs. Finally if you buy it as a mobile development platform right away, you won't mind the current bugs and shortcomings, but see them as an opportunity to grow Free Software into the mobile world. Also don't forget documentation. Documentation is super important to really make Free Software valuable. Every contribution to our wiki (wiki.openmoko.org) is a way to help Openmoko. The home page has been translated to 23 languages! We are really building a free mobile platform together. The source codes are 100% Free Software. The schematics are open under Creative Commons license (CC-BY-SA), so is the complete mechanical design. How does all this relate to GTA03? Well, on one hand internally we work around the clock as if we are trying to start mass production of GTA03 next month. Sean would certainly love to mass produce improved hardware _ANY TIME_ :-) Sean always pushes us to work faster and get things done. On the other hand it's such a huge task. A 100% free and open mobile platform. Thousands of details. And a very small internal engineering force. I have around 30 internal engineers. The typical mobile platform (Nokia/Symbian, WinMobile/HTC, Android/HTC, RIMM, Apple) has over 1000. Is Openmoko planning to hire the missing 970? No. We can only hire very carefully as the current sales of GTA02 allow us to do. Otherwise we would endanger the openness of the platform. The other 970 must come from our community, and increasingly they are. So by buying Freerunners, fixing or writing up bugs, helping to document more aspects of the phone, you help us all get to GTA03 faster. When will GTA03 come out? You tell me. You, and the rest of the community influence it more than you can imagine. We have decided to make changes to the hardware only incrementally, along product lines of our current chip vendors whenever possible, so that as much as possible of the software effort can carry over. We have decided to focus our internal software engineering on the low level, so that we leverage our insider knowledge about the hardware and schematics, while relying on the larger Free Software community to help with higher-level software. You say the current software is a 'joke', which is painful for me but I accept it. From where we all want to be it's a joke, yes. Agreed. So that also answers your question when GTA03 will come out. It's a long way, maybe another year. Let's continue to work, join if you haven't joined yet. Best Regards, Wolfgang On Nov 14, 2008, at 7:06 PM, Rui Miguel Silva Seabra wrote: > On Fri, Nov 14, 2008 at 06:11:30PM +0800, Wolfgang Spraul wrote: >> built with the Freerunner is awesome. Please continue to buy >> Freerunners and to develop for it, same is happening internally. The >> next phones will build on top of the free platform we have built >> together, the technology investment will carry over. > > I might have to skip GTA03 since I have just spent a huge 300 Euros > for > a GTA02 :) > > I hope the software stack becomes less of a joke in time for GTA03 > or it'll > be hard to get much new customers... > > Rui > > -- > Fnord. > Today is Pungenday, the 26th day of The Aftermath in the YOLD 3174 > + No matter how much you do, you never do enough -- unknown > + Whatever you do will be insignificant, > | but it is very important that you do it -- Gandhi > + So let's do it...? > > ___ > 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: The forbidden topic: Glamo OpenGL
Jacob, Glamo is not a forbidden topic. Openmoko actually has learnt a lot from this. First we have learnt to not trust high-level promises as much as before. In fact I would go as far as saying that going forward, we will not trust any promises about 'we will open this up later' anymore. Either it's open and documented at the time we make the decision to use those chips, or we look elsewhere. I believe that's what our customers want. We have a long way to go to come out with kick-ass open phone hardware, but if our community doesn't loose faith and continues to do development together with us, we'll get there. The momentum we have built with the Freerunner is awesome. Please continue to buy Freerunners and to develop for it, same is happening internally. The next phones will build on top of the free platform we have built together, the technology investment will carry over. Having said that, if someone wants to seriously develop for the glamo, please get in touch with me and we will find a legally correct way to extend the smedia documentation to you. In fact we have done that in a few cases before already, but I'm not sure how much actual codes have come out of that. I think very little ;-) So we need some really serious coders that don't mind a tough challenge. Best Regards, Wolfgang On Nov 14, 2008, at 6:48 AM, Jacob Peterson wrote: > Sorry to drag this old, over discussed topic up again. However, I > am concerned that if action is not taken soon then all GTA02 owners > will be left without any real chance to ever get anything in the way > of OpenGL support. So I ask the question, what is Openmoko's > position on writing an OpenGL driver for the Glamo chip or at least > aiding developers with some form of documentation? > > I have read speculation that it may be possible to do something such > as rewrite the documents to get around the NDA. Since it seems > rather clear that SMedia has no intention to release the documents > to anyone else under NDA, it is solely up to Openmoko to write the > driver or at least aid any community members with the ability to > write such a driver. > > Hopefully there is something that can be done, or better yet, > something is currently being done on this. > > Regards, > Jacob > ___ > 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: RESEND(Wrong Thread): IMAGE/MP3 licensing issue.
Tim, > The only threat a patent troll understands is a well funded group of > researchers and lawyers ready and willing to spend millions of dollars > and years of effort to invalidate their prized patent. > > Fortunately, such things _do_ exist. I suggest OpenMoko search for, > and solicit help from any they may find. Let me link back to one of my Weekly Engineering News (back when they were still weekly, ahem - I am working hard to get this good discipline back!) http://lists.openmoko.org/nabble.html#nabble-td837114 We looked at several options, OIN, patent-commons, peertopatent. In the end we decided to collaborate with the Software Freedom Law Center in New York. We believe this is most in line with the goals of the Openmoko project, and will have the best long-term results. I cannot speak about details yet, the SFLC and Sean are working on this. I think next year, with regards to patents the results from that will be one of the more important developments for Openmoko and maybe even the larger Free Software scene. Best Regards, Wolfgang On Nov 14, 2008, at 4:42 AM, Tim Schmidt wrote: > On Thu, Nov 13, 2008 at 3:25 PM, Chris Samuel <[EMAIL PROTECTED]> > wrote: >> I'd still rather a format that didn't risk (as much as anyone >> can know these days) such lawsuits in the first place.. > > _All_ software risks such lawsuits. > > Software patents are so over-broad, vaguely worded, impenetrably > incomprehensible to normal folk, and numerous that _no significant > work is safe._ > > _Of course_ we should prefer the Ogg formats - especially with > companies like Sisvel running around - but to believe they are > unassailable by patent trolls, or somehow more safe than other > software is delusional. > > A well stocked portfolio of patents is no thread to a troll - they > sell no products vulnerable to injunctions. > > The only threat a patent troll understands is a well funded group of > researchers and lawyers ready and willing to spend millions of dollars > and years of effort to invalidate their prized patent. > > Fortunately, such things _do_ exist. I suggest OpenMoko search for, > and solicit help from any they may find. > > --tim > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: RESEND(Wrong Thread): IMAGE/MP3 licensing issue.
Tom, > Erk... are you able to give any more details about the exact reasons? The short story is that we are in a protracted battle with some patent trolls. Google for Sisvel. In order to get ourselves in a stronger position, we want to make sure no copies/instances/whatever of patent-infested technologies like MP2 and MP3 exist on our servers. Our phones never shipped with end-user MP3 playback features, but we want to use this opportunity to make sure it's not even in some remote place somewhere. For us the important thing is to defend the freedom of our users rather than cripple our phones so that certain things become 'impossible'. So please bear with us, while we go through this house cleaning effort. Best Regards, Wolfgang On Nov 12, 2008, at 9:23 PM, Thomas White wrote: > On Wed, 12 Nov 2008 20:15:44 +0800 > Ray Chao <[EMAIL PROTECTED]> wrote: > >> We are sorry that currently we have to remove all the images on the >> download server of Openmoko. http://downloads.openmoko.org/release/ > > Erk... are you able to give any more details about the exact reasons? > > Tom > > -- > > Thomas White > Department of Materials Science and Metallurgy > Electron Microscopy Group (PhD Student) > University of Cambridge / Downing College > > ___ > 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: What should a community manager do?
Rod, > BTW, I can show you guys how to set up Trac so that you can issue all > the developers an SSL client certificate (which you can use in a lot > of > places instead of username and password) and it automatically logs > them > into trac using their email address so they automatically get emails > when the tickets change state ... Nice, thanks! I'm not sure roh or gismo are reading this, if not you may have to file a ticket in admin-trac :-) Wolfgang On Oct 12, 2008, at 8:03 PM, Rod Whitby wrote: > Wolfgang Spraul wrote: >> Rod, >> >>> It seems that access was granted sometime between then and now >> >> oh great, I'm happy to hear that. >> Maybe we don't talk about it enough publicly: We have an 'admin trac' >> issue tracker, that _EVERYBODY_ can use to send requests to the >> Openmoko admins. >> This is a public resource, same as pretty much everything else in the >> Openmoko project: >> >> http://admin-trac.openmoko.org/trac > > Ah, now I see what happened. I did raise a ticket in the admin-trac, > and since we use Trac a lot at my work and in the nslu2-linux > project, I > expected it to send me email on ticket state changes. It didn't, so I > assumed nothing had happened (my incorrect assumption). > > BTW, I can show you guys how to set up Trac so that you can issue all > the developers an SSL client certificate (which you can use in a lot > of > places instead of username and password) and it automatically logs > them > into trac using their email address so they automatically get emails > when the tickets change state ... > > -- Rod ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: 2/3: What people want Openmoko to do?
Rod, your questions touch marketing territory but I will still try to answer. > It would be very interesting to see the graph of mailing list member > numbers over time and whether it has just not grown very much since > the > launch or whether it grew significantly and has shrunk since. I think roh+gismo can give you more accurate information, because they look at this more often (it's not a secret, I wish we could all easily see live stats). I believe the announce list has stayed roughly the same over time. There has been a shift from the community list to devel+kernel. The bottom line answer to your question is that the numbers "have not grown very much", not "grew significantly then shrunk". To put things into perspective, I can tell you that we have sold more than 5000 units, but not many times more than that. Compared to the number of phones we sold, the community looks very healthy to me. Our main focus should be to get hardware and software quality up, better design, low price, 100% open. Wolfgang On Oct 12, 2008, at 6:22 PM, Rod Whitby wrote: > Wolfgang Spraul wrote: >>>> Openmoko — how many are subscribed to your email lists? >> >> announce: 11187 >> community: 2240 >> devel: 1218 > > I'm surprised that the community and devel numbers are so low > considering it is almost 2 years since launch (for a data point, the > nslu2-linux project grew to 9000 members on the community list in two > years after project start, peaked to 12000 after 3 years and still has > 1 after four years). One needs to wonder why the respectable > announce list numbers haven't been converted into respectable > community > and devel list numbers ... > > Surely you've sold many more than 5000 devices (supposedly mainly to > developers) - how come all those people are not on the mailing lists? > > It would be very interesting to see the graph of mailing list member > numbers over time and whether it has just not grown very much since > the > launch or whether it grew significantly and has shrunk since. > > -- Rod > > ___ > 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: What should a community manager do?
Rod, > It seems that access was granted sometime between then and now oh great, I'm happy to hear that. Maybe we don't talk about it enough publicly: We have an 'admin trac' issue tracker, that _EVERYBODY_ can use to send requests to the Openmoko admins. This is a public resource, same as pretty much everything else in the Openmoko project: http://admin-trac.openmoko.org/trac If you want read/write access to git.openmoko.org, or if you want to sign our NDA to get access to some NDA'd documents, please register an account there, then write up a request. Best Regards, Wolfgang On Oct 12, 2008, at 4:42 AM, Rod Whitby wrote: > Rod Whitby wrote: >> (Wolfgang told the Openmoko admins >> to give me svn and git access on the 22 Sept, and nothing has >> happened yet). > > I want to make a public retraction and apology on this point. It > seems > that access was granted sometime between then and now, but either I > wasn't informed of that or the notification got lost in transit. > > My apologies to Wolfgang and the Openmoko admins. > > -- Rod > > ___ > 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: 2/3: What people want Openmoko to do?
Risto, >> Openmoko — how many are subscribed to your email lists? announce: 11187 community: 2240 devel: 1218 openmoko-kernel: 640 We have some statistics at https://monitor.openmoko.org/munin/ The statistics there are very IT/tech focused, but I think roh & gismo will be open-minded to improve if there is interest. You can create tickets with requests for better statistics in our admin-trac, http://admin-trac.openmoko.org/ Maybe one day you can just direct your browser to monitor.openmoko.org (http, not only https :-)), and get a bunch of meaningful & live statistics. Filing specific requests into admin-trac helps. Thanks and Best Regards, Wolfgang On Oct 11, 2008, at 9:26 PM, Risto H. Kurppa wrote: > I just was able to release the second part of the posts. For full > version, see > http://risto.kurppa.fi/blog/discussion-23-what-people-want-openmoko-to-do/ > > > > This is the part two of the post series discussing the status of the > Openmoko community. The discussion is split in three posts to make it > easier to read. This first post discussed the status of the community > and the third will discuss one of the possible solutions to improve > communication. > > In this second part we will discuss the expectations people have for > the software or simply what people want Openmoko to do. > > What people want.. People always want something.. In this case there > are not much people can demand Openmoko does. Openmoko has their own > plans for the future and if they see that they can use community for > something, I hope they'll do it. If not then.. that's life. But here > are some expectations the community members have on Openmoko. > > The comments without the e-mail addresses are from community mailing > list, the rest from the comments of my previous post. Remember, these > are only parts from the messages so please check the original posts > for more details! > > > > > Having several (forked) distros around is okay if the fork developers > really want to take a completely new direction. If the devels feel a > need to fork because it's in one way or another difficult to > contribute (no SVN access or something), then I think there's > something wrong in the community and project management. I don't know > what's the case in Openmoko. From what I know, FDOM was created to add > all the community applications to the original Openmoko 2008.x so it > seems to make sense though I don't know if it has to be a distro and > not a add-on package or install script to 2008.x but that was not the > topic of this post… > >> October 7, 2008 at 7:47 am / mwester >> Well said. Openmoko sold a vision, and found an eager audience. > >> Unfortunately, they didn't seem to have any idea what to do with >> that shared vision — >> as a result, the community gradually dispersed and fragmented. > >> But all is not lost, by any means. As long as people complain >> about the situation, there >>is hope — they still care. Openmoko needs to look very closely >> at the data that only *they* can see: > >> Openmoko — how many are subscribed to your email lists? How many >> of them are active >> (i.e. have sent an email in the past 6 months)? Now, how many >> phones did you sell, Openmoko? > >> Openmoko — where are those thousands of missing phones? Are they >> in desk drawers? >> Cardboard shoe boxes in closets? Dust bins? More importantly, >> where are those thousands of >> potential contributors, potential ambassadors, your in-the-field >> sales force for selling both >> the vision and the phones? > >> The hardware and software problems are trivial in comparison to >> the loss of the community >> mindshare — and ultimately that goes beyond a vision and goes to >> the bottom line. >> Openmoko had better hire a community manager, not for the >> community's sake >>(although we'd certainly welcome such a person), but for their >> own business survival. > > Mwester said it better than I was able to. I might not be quite that > pessimistic but I think that the community would be able to do more > than it currently does if properly managed and empowered. This > includes both developers and users, there's no reason to make a > division here! > > Next post will discuss one of the possible solutions to the > communication problem. > > > > > to see the original post, see > http://risto.kurppa.fi/blog/discussion-23-what-people-want-openmoko-to-do/ > > > r > > -- > | risto h. kurppa > | risto at kurppa dot fi > | http://risto.kurppa.fi > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [2008.9] Wifi very unreliable
vale, > i think this should also be a high priority aspect to work on for > Openmoko. It is, and for Atheros too. We are working on improving the driver (there are several driver variants actually), we are working on getting all of this into mainline kernel.org, we are working with Atheros to open up more possibilities with regards to reflashing the chip, providing 'thin' firmwares that allow monitor/injection modes etc. Any help is appreciated, bug reports with clear reproduction steps are very helpful too. Best Regards, Wolfgang On Oct 2, 2008, at 9:19 PM, vale wrote: > > calm down, > > its a fact, that freerunners wlan is far away from optimum. > > try a wget shortly after doing ifup eth0 -> everything works > try wget some minutes later (no suspend/resume in between) from same > server > -> no download, even if ping still works > ifdown eth0, ifup eth0 -> wget works again > > same with opkg install, update, upgrade etc. > > under 2007.2, 2008.08, debian ... > > -> wlan drivers not working well > > i think this should also be a high priority aspect to work on for > Openmoko. > > bye > > vale > > Stroller-2 wrote: >> >> >> On 1 Oct 2008, at 12:28, Nishit Dave wrote: >>> >>> All this discussion does not help if you realize that even after >>> placing the FR *next* to the blooming router, you get reported a >>> signal strength of 65%. What does the hardware expect, building the >>> router *inside* the FR? >> >> Nishit, >> >> The company that sold you your Freerunner offered you refund, >> already. >> >> I assumed that you would take this, leave the list and STOP FUCKING >> WHINING. >> >> I guess this was too much for me to hope for, huh? >> >> Stroller. >> >> >> ___ >> Openmoko community mailing list >> community@lists.openmoko.org >> http://lists.openmoko.org/mailman/listinfo/community >> >> > > -- > View this message in context: > http://n2.nabble.com/-2008.9--Wifi-very-unreliable-tp1128409p1133869.html > Sent from the Openmoko Community mailing list archive at Nabble.com. > > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Mockup or what else?
Treviño, > However there's another question to Openmoko: another important > developer left openmoko; unfortunately he's not the first of the list. > Why this happens so often? In every message I've read about, it's > always > stated that there's no so much "openness" as it should be. This happens because Free Software is driven forward by highly motivated and opinionated individuals. 'pro-active' people rather than people waiting for orders. Openmoko is brave enough in hiring a whole bunch of them and trying to make them work together. I think I can say we are moderately successful at that, at least we are shipping actual phones and have actual software running on them. I know about the bugs... We are constantly looking for people who want to join, right now especially in graphics (with focus on 3D) and kernel work. As raster says on his blog, Openmoko was a "non-working thing" for him, and he is now a "free man" and can work "without interference". I think that's great! Openmoko cannot possibly fund all Free Software projects in the world. We can only use our very limited financial resources (which come from phone sales), to pay for certain things that are _MISSING_ in the Free Software world and we feel won't be created by themselves or by others. Going forward we want to have a much stronger focus on quality, bug fixing, kernel robustness, automated testing, production testing, etc. For the Openmoko factory images, everything stays the same with regards to Enlightenment, in fact we have only just started to use it more and more. Going forward, EFL and Edje will become central pieces in Openmoko's factory images. I think that's a pretty big commitment, and I hope raster will appreciate. It's because his software is good! Maybe one day we can convince him to "take one for the team" again and work for Openmoko. Maybe not. Our doors are open, for raster and others who think they can help Openmoko. Email us at [EMAIL PROTECTED] Best Regards, Wolfgang On Sep 16, 2008, at 12:06 PM, Marco Trevisan (Treviño) wrote: >> On Mon, 15 Sep 2008 20:13:39 +0200 Bumbl <[EMAIL PROTECTED]> >> babbled: >> >>> http://www.rasterman.com/files/illume-new-01.png >>> http://www.rasterman.com/files/illume-new-02.png >>> http://www.rasterman.com/files/illume-new-03.png >>> >>> Are these mockups or where can I obtain this theme. >>> >>> It looks amazingly good. >> >> i don't do mockups... :) they pollute! :) it's real. ignore the >> clock and its >> background - that's just a test app i wrote (called Ello). i'm in >> the middle of >> doing illume extensions to e17's nw default theme. > > Woow! That's really amazing... Rasterman you're always the only who > can > make us dreaming even more. > > Btw I didn't read before the bad news about leaving Openmoko [1]... > This > made me really so much sad. Reading your latest mail I figured that > your > relationship with Om was not going so well (didn't they leave you > enough > space of developing how and what you'd have liked?), but I really > hoped > that this wouldn't ever happen... :( > > Now that enlightenment is so important for Openmoko, what will be our > future? Since the main E developer isn't anymore part of Openmoko, its > development won't be anymore Om-focussed; then Rasterman in the near > future could be occupied in other things, so his interest for e- > embedded > could decrease and with it also the quality of the software that > we'll use. > > However there's another question to Openmoko: another important > developer left openmoko; unfortunately he's not the first of the list. > Why this happens so often? In every message I've read about, it's > always > stated that there's no so much "openness" as it should be. > This won't to be a flame, but we all know how people like Rasterman > are > important for the project. I can't really understand how we can throw > those opportunities away... > > > [1] http://www.rasterman.com/index.php?page=News > > -- > Treviño's World - Life and Linux > http://www.3v1n0.net/ > > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: 2008.8 update
Bill, > sms mode. The bug was closed with what to an English speaker means > "its working, so go away". This certainly teed me right off. In ... > Yes, I am still peeved by the way the bug was closed - why bother > raising bugs when it results in actions like this? Its all very well > saying its open, give them a chance etc, but eventually, something > will > have to change here. Sorry to hear that. Thank you very much for posting the bug! Can you post some URLs? Which bug are you referring to? Who closed it in a way that offended you? Please remember that Openmoko is a very global team. Sometimes it's just a language issue that the friendliness gets lost in translation... Thanks again for helping us with our project. The more (high quality) bugs you report the better for all of us since we are developing Free Software! Best Regards, Wolfgang On Aug 26, 2008, at 9:38 PM, William Kenworthy wrote: > The problem is OM are not responding in a way that reassures us that > 2008.8 is being shaped to our concerns. I raised a bug that the > default > 2008.8 keyboard was almost impossible to use in anything but an > english > sms mode. The bug was closed with what to an English speaker means > "its working, so go away". This certainly teed me right off. In > postings since, its been explained that this was actually because of > the > way the bug reporting system works with engineering, and it doesnt > work > like we are used to in most opensource projects where you can raise a > bug about ANY concern and it will be attended to/allocated as > required, > not closed because it doesnt neatly fit some engineers idea of a bug. > > So basicly yes, Yorick is speaking for very many of us. There is a > severe usability issue with 2008.8 and its being ignored. Saying > its up > to the community to fix is laughable - we have fixed it, so why is OM > not listening? > > Yes, I am still peeved by the way the bug was closed - why bother > raising bugs when it results in actions like this? Its all very well > saying its open, give them a chance etc, but eventually, something > will > have to change here. > > BillK > > On Tue, 2008-08-26 at 14:06 +0200, Michele Renda wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> Nishit, I realy hope that Yorick don't speak for a lot of US. >> >> There are way and way to make a comment of something is not right: a >> person can: >> >> A. make in a proposive way, opening tickets, and specificating the >> points that can be done in a different way, or, a person can just >> say: >> B. It doesn't run, It doesn't run, It doesn't run -> It is a f**king >> phone -> It is a f**king firm. >> >> You have the "fredom of arbitry", we can do all that we want with our >> phone: this is not necessarily a nice thing: the software is far to >> be >> mature, and a lot of things must to be done. It the price of the >> freedom. >> >> But if you choose the freedom, please don't use B. There are a lot of >> better thing to do. > > > ___ > 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: Intel Atom
Jeffery, can you add the Atom chip to our 'Chip Scouting' section at http://wiki.openmoko.org/wiki/MokoForesight ? Also in the future, any hardware related mails should go to [EMAIL PROTECTED] I am getting our Electrical Engineers to subscribe to that list, and we do take the Chip Scouting thing very serious. Just this morning we had 2 people from Telit visit us, after someone added the UC-864 module to the Chip Scouting section, and we were glad to hear that open documentation is part of Telit's business strategy. Talking about Intel, I think I can say publicly that we have a very good relationship with Intel, they gave us a Menlow development machine a while ago and we did some experiments with it. We would be delighted to work with Intel on upcoming phone models, especially if they continue with their 'open documentation' policy, which they seem to be serious about. One really cool thing about Intel is that they release some of their documentation under a Creative Commons license. Many vendors still don't do that. Even if their documentation is 'open', redistribution is forbidden. That means we cannot put these files onto our servers, we have to link to their servers. And if they take down the files some time later, people may be out of luck and we cannot offer help. That's what happened to the Samsung documentation for example. So whenever vendors are coming in and I meet them, I mention how happy we are about Intel releasing documentation under Creative Commons. More chip vendors should adopt this, and I hope Intel itself eventually will release all their documentation under a Creative Commons license, not turn back... Best Regards, thanks for your help in pointing us at interesting chips! Wolfgang On Aug 14, 2008, at 8:00 AM, Jeffery Davis wrote: > Is there any possibility a future model could incorporate the Intel > Atom? They're launching dual-core > models soon at around $43. Battery life would probably be somewhat > less > than it would continuing with ARM, though. > > ___ > 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: Om2008.8 comments and questions
Dear Helmut, your priorities are our priorities _BUT_ it will still take quite a while, yes. From what you write, you seem to be indeed the perfect customer we are focusing our efforts on. You have a Linux system on your desktop or notebook already, you are looking for a phone that works well with it. At the beginning, you want to use the phone only for 'basic' phone usage. How to get there? Well, I see a lot of development momentum building now, our ca. 20 internal software engineers don't actually make that big of a difference. Great low-level patches are coming already, we are now trying to straighten up the build system to something more like Debian with stable/testing/unstable. We are not developing a proprietary system and have no interest in doing so. Compatibility with Ubuntu and other distributions is very important. I understand your frustration about importing contacts and alarms, thanks for the reminder, and rest assured that these things are indeed very high on our priority list, right after making phone calls and SMS. Keep us honest if things don't improve fast enough! Best Regards, Wolfgang On Aug 13, 2008, at 1:55 AM, Helmut Tessarek wrote: > Hi Openmoko cummunity (and developmen team), > > I'm a little bit concerned about how priorities are set and handled > and would > like to read your opinion. > > 2 weeks ago I got my Neo Freerunner with Om2007. I was able to get > it up and > running, even importing my contacts from my old phone wasn't really > an issue. > WiFi worked ok too. > > Then I flashed my phone with Om2008.8. > > Call me oldfashioned, but I'm one of the guys who wants to use his > phone for the > reason it was actually built in the first place: making phone calls. > I expect only 3 things from a phone (which are the most basic things > a phone > should be able to accomplish): > > 1) making and receiving calls > 2) managing contacts > 3) alarm function > > I will go in more detail regarding these 3 points in a moment. I > know that the > phone has overwhelming features and I would like to see them in > action, but > first I should be able to use it as a phone. I don't care about GPS, > games or a > graphical installer right now. > > ad 2) I was not able to migrate my phonebook from om2007 to om2008. > I had a > backup from my home dir and I had the .vcf files on my sd card. > Well, entering > my 500 contacts is not an option. The keyboard is more or less > useless, since it > takes at least 'number of character' times 2 seconds to enter a > word, which > cannot be guessed by the keyboard 'logic'. > What about sending contacts via Bluetooth? What about importing vcf > files? > > ad 3) this does not work either. sometimes I can see an alarm icon, > but no alarm > tone. hmmm, not much of an alarm then. > > These are basic functions which do not work and people are talking > about GTA03, > cameras, GPS mapping functions. > I don't get it. First of all the phone should be able to do at least > things that > a 50$ phone can do. > > I bought the openmoko phone, because I'm using Linux and I thought > that it would > be easier to sync contact and calendar data with my workstation. > I was definitely wrong. The data is not even compatible between Om > releases. > Furthermore it seems to me that a propriatary system is developed > which makes it > even harder to communicate with standard Linux distros. > In that case I could have bought the iPhone as well. At least that > phone works. > > As long as the priorities are not focused on basic features as I > described > above, this phone will not be useable for quite a while. > > Regards, > Helmut > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: FR and debian, seems it's progressing
We are planning just that, give us a bit of time to sort things out after the Om 2008.8 release. Wolfgang On Aug 10, 2008, at 9:41 PM, Matt wrote: > I think Openmoko could take a leaf from the book of Debian. > Their Stable/Unstable/Testing approach allows users to pick the build > which suits their needs and allows the users, to manage their own > expectations. > > Admittedly, stable releases take years, but they tend to be rock > solid. > > > mj > > > Marcos Mezo wrote: >> Reading planet debian today I came across this post/blog [1] by >> Joachim >> Breiner where he says they are packaging fso in debian: >> >> --- citation --- >> Here at DebConf 8 in Argentinia, I’m working on getting Debian to >> work on the >> OpenMoko Freerunner Smartphone. We are progressing quite nicely, >> soon having >> the same features as the official freesmartphone.org image. See the >> pkg-fso >> wiki [2] page for more on that. >> ... >> --- >> >> [1] >> https://www.joachim-breitner.de/blog/archives/300-Xmonad-on-my-mobile-phone.html >> [2] http://wiki.debian.org/pkg-fso >> >> I'm looking forward to it, specially as my FR should be here any >> time... :-) >> >> Marcos >> >> ___ >> 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: Openmoko Om 2008.8 Release
Maybe I should add that the binary Om 2008.8 release is for GTA02 only right now. For GTA01, we have no big plan yet but we will look at it next. The biggest problem that stops us is that we are extremely low on GTA01 phones :-) I am only aware of 1 (ONE) functioning GTA01 in the Taipei office. A bit hard to do development and testing that way. Next week we will look at the Om 2008.8 on GTA01 situation: 1. how many people want this? 2. does anyone in the community step up and compile the distribution for GTA01? (there will be some work: size reduction, GPS chip, etc) 3. can we support or do that from Taipei, do we find enough working GTA01? 4. how much work is it and how fast can we do it? Also, the files on http://downloads.openmoko.org/releases/ are a bit confusing. There are 4 files there, but actually only 2. The other 2 are symlinks. The symlinks have no 'gta02' in the name giving you the impression it could be for GTA01 - but it isn't :-) So there are only 2 files, and they only work for GTA02: kernel: http://downloads.openmoko.org/releases/Om2008.8/Om2008.8-gta02-20080808.uImage.bin rootfs: http://downloads.openmoko.org/releases/Om2008.8/Om2008.8-gta02-20080808.rootfs.jffs2 Finally, don't ask me where an updated u-boot is. I think we will add it shortly. Best Regards, Wolfgang On Aug 8, 2008, at 7:03 PM, William Lai wrote: > Dear Community, > > We are proud to announce the release of Om 2008.8 for public > reviewing. > It represents our current state of development over the last 6 months. > We came a long way before achieving this milestone. > Here is what you can expect: > > - A stable and working phone stack realized by using Qtopia. > - A new and flexible window manager [Illume] that broadens our support > for the different graphic libraries, including GTK+ and more. > - The whole system software has been reworked which leads to a very > fast > and reliable suspend & resume, LED control and power management. > - A graphical frontend [Installer] for package management as > installing, > removing or updating applications via repositories. > - Also included is an application which combines GPS and SMS > [Locations] > for easy sharing of locations among friends. > > For detailed information about Om 2008.8 (including instructions, > references and currently known issues) check out our wiki at: > http://wiki.openmoko.org/wiki/Om_2008.8 > > Please consider this a next step towards an open end user ready mobile > platform. We are not there yet but we will continue working towards > that > direction. We invite you to install our latest release and give > feedback: > > http://downloads.openmoko.org/releases/Om2008.8/Om2008.8.rootfs.jffs2 > http://downloads.openmoko.org/releases/Om2008.8/Om2008.8.uImage.bin > > Soon after our release we will publish frequent snapshots of our > builds to give you the possibility to follow our development and > latest > fixes. You can join forces with our QA team by submitting bug reports > and/or patches to make the platform as robust as possible. > > We are excited about this release and look forward to moving together > towards upcoming milestones. > > Best Regards, > > Openmoko Team > > ___ > 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: Some commentary on the new Openmoko direction, and a review of FSO
> The is technically wrong. Trolltech had already done the 'porting to > X' > work as an experiment/internal demo. Correct. Lorn, let's not argue over who deserves more credit. Of course first of all Trolltech developed Qt, then Qtopia. Then you did the experimental port to X but did not finish it because there was no paying licensee asking for it. Which makes sense since most licensees only want one graphical toolkit so running on framebuffer makes perfect sense to them. We at Openmoko love the flexibility of X, we believe in the long run many interesting things will be possible because of X. Wolfgang On Aug 8, 2008, at 2:03 AM, Lorn Potter wrote: > Wolfgang Spraul wrote: >> Dear Kevin, >> thanks for writing your review, for us at Openmoko nothing is better >> than a genuine reality check from outside. >> Executive summary first: I understand that we have not done a very >> good job at communicating our software strategy, and I accept >> responsibility for that. >> >> In detail, let me go through some of your comments: >> >> ---1 >>> The ASU was a proof-of-concept image that combined Qtopia, >> Enlightenment and GTK >> >> I would say it's more than proof-of-concept. When Qtopia became fully >> GPL in November last year, we looked at it technically. Trolltech >> published great binary images for the Neo 1973 but we couldn't >> immediately use them because Qtopia ran on the framebuffer not on X, >> and we did not want to give up GTK+. By February, we had come to the >> conclusion that porting Qtopia onto X, retaining GTK+ support, would >> be technically feasible for Openmoko. > > The is technically wrong. Trolltech had already done the 'porting to > X' > work as an experiment/internal demo. > > > > -- > Lorn 'ljp' Potter > Software Engineer, Systems Group, Trolltech, a Nokia company > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Some commentary on the new Openmoko direction, and a review of FSO
Dear Kevin, thanks for writing your review, for us at Openmoko nothing is better than a genuine reality check from outside. Executive summary first: I understand that we have not done a very good job at communicating our software strategy, and I accept responsibility for that. In detail, let me go through some of your comments: ---1 > The ASU was a proof-of-concept image that combined Qtopia, Enlightenment and GTK I would say it's more than proof-of-concept. When Qtopia became fully GPL in November last year, we looked at it technically. Trolltech published great binary images for the Neo 1973 but we couldn't immediately use them because Qtopia ran on the framebuffer not on X, and we did not want to give up GTK+. By February, we had come to the conclusion that porting Qtopia onto X, retaining GTK+ support, would be technically feasible for Openmoko. Our initial estimate was 2-4 months. So we started. Qtopia is an addition to the Openmoko software stack. ---2 > "ASU" and 2008.8 are the same thing for the most part. Correct. ---3 > The GTK based 2007.02 line was obsoleted (or some might argue deprecated ... I would say neither obsoleted nor deprecated. Bringing Qtopia (and especially Enlightenment) in _TEMPORARILY_ broke GTK+, that's one reason why we didn't release more ASU builds earlier. Actually the real breakage of the GTK+ telephony apps came from Enlightenment, which forced us to replace matchbox. We also wrote a new launcher, Illume. Then we went back to fix the GTK+ part, adding the theme back in, making it easy to switch from what are now the default Qtopia telephony apps to the GTK+ telephony apps. That part is not yet entirely finished. When 2008.8 is released, you still will not be able to remove Qtopia with a few clicks, and switch back to GTK+. Neither can you have both installed at the same time. We are very interested that both of that works, if nobody in the community picks this up then we will. We are already on it actually, like I said fixing the GTK+ telephony apps that got broken by the introduction of Enlightenment and Qtopia is something we do for a while already. ---4 > The ASU and Framework were announced at roughly the same time. Please don't read anything into this. Openmoko is a real open source project. What you may feel are two 'announcements' 'at the same time' are in reality probably several emails from people in different parts of the world that are _NOT_ synchronized to the degree that you might see this from the typical company. In many companies, all you will hear is the marketing department. So they always speak with one voice. At Openmoko, even full-time, fully paid employees have no restrictions whatsoever to post private opinions, blogs, etc. In fact we encourage them! Please factor that in... ---5 > To the community is appeared as if Sean Moss-Pultz had pulled a decision out of his ass to abandon the software that people knew and go with Qtopia instead I agree some people felt like that, and it's not good. Again we have no unified marketing message, and we don't want to introduce any kind of 'gag order' for engineers (a lot of them would leave if we would try that anyway ;-)) I will try to do better going forward communicating our technical strategy. ---6 > The biggest unanswered question was "I want to develop an app for Freerunner, what should I start with?" Yes, big problem. Right now a lot of the new things we are doing are implemented in Python using Python-ETK bindings. Check out the sources here: http://projects.openmoko.org/plugins/scmsvn/viewcvs.php/trunk/?root=exposure Now, this is not the end of the story. You can also develop using GTK +, or Qtopia. We even have quite good Java support (Jalimo) on the Neo. And so on. We are fully aware that we need to provide an entry point that is AS EASY AS POSSIBLE to use. We are working towards that, but I think you need to give us a few more months until we have good tutorials, sample sources, development/installation methods, etc. At least you will be able to see it coming together alive, I hope it's not too stressful :-) ---7 > Mickey Lauer posted again, making it pretty clear that my assumptions [that ASU and Framework were complimentary projects] were wrong You must have misunderstood Mickey. ASU and Framework are absolutely complimentary. Behind the scenes it is all melting together. Luckily Linux is a multi- process environment :-) ASU means Enlightenment and Qtopia were brought into the Openmoko software stack. It will be released as Om 2008.8. FSO/Framework means many more dbus services will be brought into the Openmoko software stack, including applications using d-bus. It will be released later, maybe Om 2009? OpenEmbedded is holding all this together. ---8 > If the two [ASU and Frameowork] were to merge, it would be by community support. Not correct. Full-time Openmoko engin
Re: Qtopia questions
Lorn, > Qtopia development is fairly closed. We do take contributions, > depending > on our roadmap, but consider that we need to sell it however we like > (non GPL), we ask for copyright assignment, or a very liberal license > like BSD. This is mainly for large features. Small bug fixes cannot be > copyrighted (IMNAL) so we can take these from anyone. We have a copyright assignment in place, but if you ask Holger he will tell you that he has dozens of real Qtopia-only (not related to our X port) bug fixes that nobody at Trolltech (Australia) cares to look at or accept. It would be fantastic if this could improve, we would all benefit. Wolfgang On Jul 26, 2008, at 4:45 AM, Lorn Potter wrote: > Al Iasid wrote: >> Hi, I'm using Qtopia on my new Freerunner and enjoying the software >> and the hardware. Please excuse the noob questions below. They're >> sincere and aren't meant to incite debate. My apologies if these have >> been answered already. >> >> 1. Are there plans to maintain ongoing development/support of regular >> (non-X) Qtopia for the Freerunner? Or, will developers shift focus to >> work on the Qtopia-on-X (ASU?) distributions? > > Qtopia is developed by Trolltech/Nokia. WE are using it as our current > Qtopia SDK platform. > > >> 2. Will fixes move back and forth between regular Qtopia and Qtopia- >> on >> -X (ASU) in the future? > > Yes, depending what the 'fix' actually does. > >> 3. Can I realistically use Python to develop apps for Qtopia? (I see >> "Python...Yes" on the Distributions page, but I don't find much when >> using Google.) What I'm trying to ask is: Is Python used frequently >> and easily? >> 4. Is the model for Qtopia open-source, but managed by >> Trolltech-Nokia? That is, do outside developers submit changes to >> standard Qtopia? > > Qtopia development is fairly closed. We do take contributions, > depending > on our roadmap, but consider that we need to sell it however we like > (non GPL), we ask for copyright assignment, or a very liberal license > like BSD. This is mainly for large features. Small bug fixes cannot be > copyrighted (IMNAL) so we can take these from anyone. > > > > -- > Lorn 'ljp' Potter > Software Engineer, Systems Group, Trolltech, a Nokia company > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Reason for GPS problems found!
Marcus, > Why have you not used the phone yourselves? We are using it. > Why are you abusing the community in such a shameless way? We don't. We are just working as hard and smart as we can. A pretty awesome group of people actually, and obviously our community (including critical people like you) are included! If you think it's not good enough for you, please let us know what better place you find, we are very willing to learn. On the GPS bug, expect an update before the end of the week. Wolfgang On Jul 16, 2008, at 2:34 PM, Marcus Bauer wrote: > On Wed, 2008-07-16 at 09:22 +0800, Wolfgang Spraul wrote: >> Alejandro - >> >>> This issue does not look good. Is there someone in Openmoko or FIC >>> aware of it? >> >> Aware of it? You must be kidding. > > Dear Wolfgang, > > there remains one question that the community has to you and it is > even > more important than the question why this was not caught in factory > testing: > >> From all the Openmoko employees nobody has realized that the GPS is > broken. Why have you not used the phone yourselves? Why are you > abusing > the community in such a shameless way? > > > ___ > 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: Reason for GPS problems found!
Alejandro - > This issue does not look good. Is there someone in Openmoko or FIC > aware of it? Aware of it? You must be kidding. Pretty much everybody at Openmoko, including Sean our beloved leader, reads the mailing lists. All mailing lists. Then we have internal mailing lists, and if you could see what's going on there right now, rest assured there are 5-10 people working on tracking down the GPS bug, and other bugs, right now. Software fixes, hardware fixes. Shipped units, units currently in production, future production runs. All require different approaches and all of this is being addressed. The idea that the GPS problems might be related to SD card presence was a fantastic idea, and coming from our community! After the gta02 release dust settles, I will take another look at how we can make our internal communication more public. It's all too easy that good things are going on and people don't know about. Expect to see more in the coming days. Best Regards, Wolfgang On Jul 15, 2008, at 10:30 PM, Alejandro Enrique wrote: > This issue does not look good. Is there someone in Openmoko or FIC > aware of it? > > If it is something that has to be fixed in hardware it may have a big > impact in the project at this stage. > > I hope there will be some software workaround for this. > > 2008/7/15 Jay Vaughan <[EMAIL PROTECTED]>: >>> On the 1973?! >> >> Yup. >> >>> None of us can confirm this, our 1973 are mostly ok, only the >>> Freerunners make problems. >> >> >> I do not have a Freerunner yet. But for sure, without the SD card >> in, >> GPS seems to acquire faster. >> >> ; >> -- >> Jay Vaughan >> >> >> >> >> >> ___ >> Openmoko community mailing list >> community@lists.openmoko.org >> http://lists.openmoko.org/mailman/listinfo/community >> > > > > -- > Alejandro Enrique > > ___ > 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: T-Mobile with ASU on GTA01?
Dear Marcus, your mail touches many subjects and let me just pick out a few: First of all thanks for buying 4 phones from us! We are still an 'Open Source project' more than a company and people need to believe in the bigger picture to buy from us now. Believe it or not - we all eat our own dog food. You cannot believe how many mails Steve wrote to me complaining about his broken/buggy/ unchargeable/etc. Neo. I admit that I am carrying two phones around with me, a Blackberry and a Neo. Want to replace the Blackberry but we are not there yet. > dogfood, i.e. using the Neo as their daily phone, things like > oszillating GSM modems, non working GPS, SIM cards, deep discharge > batteries, noisy headsets would have been since long ironed out. Exactly our top priorities. I am amazed by how closely you are watching what's going on with Openmoko. Let me just clarify this: We are not (knowingly) shipping defective products. Our complete production testing software is under GPL now (http://git.openmoko.org/?p=system-test-suite.git;a=summary ) Every peripheral of every phone is tested in the factory. (BTW, we are trying to open this up more, with open factory statistics etc. But that's a long-term goal) So some people see bugs. All the things you list above. In certain situations, certain countries, with certain GSM base stations, certain SIM cards, etc. etc. And after months and months of improving the Neo, we decided to start shipping. Get more Neos out into real life, get more customer feedback. Because in the end that's the only thing that can really focus the whole company. Engineers are self-loving animals sometimes. Do not over-estimate the power Sean or me or Steve have over some of these guys. But when the mailing lists have people who paid money for their phones, everybody will listen. Openmoko is different, we do all this openly. If you want to return your two non-working phones, I'm sure we find a solution. We will absolutely make sure that you get two fully functioning phones in return. Hope this helps (a bit, I know you still have 2 phones with broken GSM as you say), keep us honest :-) Best Regards, Wolfgang On Jul 9, 2008, at 4:23 PM, Marcus Bauer wrote: > On Wed, 2008-07-09 at 09:25 +0200, thomasg wrote: >> ASU works basically, but getting telephony work with it is a matter >> of >> luck. >> Mostly it doesn't work at all, mostly the qtopia phoneserver eats 90% >> CPU.. > > You may have one of the broken GSM modems. From my four phones two > have > a broken GSM - that's 50%. > > They constantly reconnect to the cell tower and inbetween the can't > make > phone calls and loose the GPRS connection but without notifying the > pppd. > > This is the same with the mature OM2007.2 images as well as with the > professionally by Trolltech developed pure qtopia images, the ASU > images > the the new hyped FSO images. > > > This is another hardware problem which is shared with the Neo 1973 and > thus known since a year. The answer by Dr. Michael Lauer was "Guys, > this > is a Heisenbug. We pray that it does not occur too often in the > field.". > > That is a very interesting engineering approach... > > > The bug in question is: > http://docs.openmoko.org/trac/ticket/1024 > > > The big problem with Openmoko is this "not invented here" mentality. > The > OM2007.2 images were working well, GTK is a valid platform for mobile > gadgets (see Nokia N700, N800, N810), you can add "bling" (see > clutter) > and there is a huge developer base. The qtopia port to X adds a second > huge developer base. > > But instead of going on and having a base for testing the hardware, > there came this change to ASU and etk which probably 0.1% of Linux > developers use. And despite what Lauer & Co try to make us believe, > this > alienates GTK and qt developers. Just look on the planets of KDE and > GNOME - nearly no mentionings. The developer mailing list: a big void. > > But the real problem here is that basically due to this reinventing > the > wheel with ASU nobody inside Openmoko has ever really used the phones > thus plenty of things which could have come up simply got lost. If > Sean, > Wolfgang and Steve would have started to exclusivly eat their own > dogfood, i.e. using the Neo as their daily phone, things like > oszillating GSM modems, non working GPS, SIM cards, deep discharge > batteries, noisy headsets would have been since long ironed out. > > Before now all the fanbois jump onto me and accuse me of trolling: > in order to come to some lifestyle competitor of Apple the important > thing is that the basics work and that they work reliably. Accepting > brokeness as part of freedom is doing a disservice to the free > software > world. > > And it is even more unacceptable as there were 5000 people buying a > Neo > 1973 more or less for nothing. They all would have been more than > happy > to participate in advancing the Neo. > > The point being: the Neo *is*
Re: ancient hardware? - Software matters
thank you so much! You cannot believe how hard people at Openmoko work and getting a mail like yours rewards many of us for 12+ hours working days. It's a long way, lots of hardware and software bugs, we know it. I like your 'bad teeth' analogy :-) Wolfgang On Jul 7, 2008, at 6:57 PM, Tilman Baumann wrote: > I never had a phone for the last decade. > Mostly out of protest against the ridiculous data rates and prices on > GSM. And because all phones sucked. > I had sworn me, when UMTS would comes out and the prices are ok, i > will > buy a phone. > UMTS came, the prices where ok but the phones still sucked. And i did > not feel i would miss much. > > And most important of all, i completely lost hope for all mobile phone > software. There where no iterative improvements. Features came ant > went > with no regular pattern. Phones did not get better with time, they > just > stagnated. They did not even managed to put all features in which they > had in earlier models. > And bad software did never get fixed. The only way to overcome bad > software was to by a new phone. > It never felt right for me to give them money for theyr bad service. > > And all of them completely missed the point about having internet on a > mobile device. The franticly searched for the killer app for UMTS but > could not find any. But the killer app for phones was clearly IP (open > communication) and a open software stack. > > Opensource was clearly the answer for all that. > > Then things happended. Openmoko and the iPhone came. The iPhone > started > a big fire under the fat and lazy ass of phone manufacturers. They are > reminded that innovation is something that sells phones and makes > customers happy. But i'm sure those who will not burn to death will > not > manage to stand up for the next time. > Changes will happen slow. Its after all the mobile phones business. :) > > And there was Openmoko. There was never any doubt for me that this > will > be the right answer to a good and healthy software evolution and > constant improvement for mobile phone software. > > So i'm here. I broke my oath to never buy a GSM only phone (Neo > 1973). I > was not able to make stable phone calls for month with my rather > 1990ish > new phone. > But i was happy and i still am. > > Sure. The hardware could be better. But this is something the industry > managed to do all the time. > > We need to make software a important part of phone development. > This is where the industry (and subsequently the customer) needs help. > This is where a bunch of hackers can make a big difference. > > I'm sure Openmoko started something important. > The vastly successful way of software evolution and development which > opensource provides will greatly improve all phones to come... > > I'm happy that Fic gives us this stepping stone to change the world. I > gladly ignore some bad teeth of this horse. ;) > > Ajit Natarajan wrote: >> Hello, >> >> I've seen a number of remarks on this list that the hardware in the >> FR >> is ancient and this is the price of openness and freedom. >> >> I did a quick search for some of the parts: >> >> The Samsung 2442 SoC seems to date back to 2005. I got this from the >> revision history in the user manual [1]. >> >> The Antaris 4 GPS chip dates back to 2006. This is the from the 0635 >> datasheet revision history [2]. >> >> The Calypso GSM chip dates back to 2000. This is from the leaked >> hardware definition manual revision history [3]. >> >> The Accton 3236 WiFi chip dates back to 2006. This is from the >> ``2006.12'' at the end of the datasheet [4]. >> >> I haven't looked at the other chips. >> >> From the above, the GSM chip looks ancient. However, the other chips >> don't seem that old. And some recent devices are using these parts >> as >> well. For example, the RoverPC C6 introduced in December 2007 uses >> the >> Samsung 2442B at 300MHz. >> >> So, I don't understand the comments on ancient parts. What have we >> compromised on by choosing these parts? >> >> Thanks. >> >> Ajit >> >> >> [1] >> http://210.118.57.197/Products/Semiconductor/MobileSoC/ApplicationProcessor/ARM9Series/SC32442/um_s3c2442b_rev12.pdf >> [2] >> http://www.u-blox.com/products/Data_Sheets/ATR0630_35_SglChip_Data_Sheet(GPS.G4-X-06009).pdf >> [3] http://cryptome.org/ti-calypso2.pdf >> [4] http://www.accton.com/products/Datasheet/WM3236A.AQ.pdf >> >> ___ >> Openmoko community mailing list >> community@lists.openmoko.org >> http://lists.openmoko.org/mailman/listinfo/community > > > -- > Drucken Sie diese Mail bitte nur auf Recyclingpapier aus. > Please print this mail only on recycled paper. > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://list
Re: rationale for ASU (and change from GTK to Qt)
Ron - I think a lot of people hate QT so much that they don't even see anymore that GTK+ still lives and grows as before! Yes, we brought Qt/Qtopia into Openmoko, on top of X so it can co- exist with GTK+ and EFL. There never has been a 'GTK+ stack'. What is a 'GTK+ stack'? Hopefully the GTK+ telephony applications can be connected to Mickey's new framework, as roh suggested yesterday. Hopefully all the work raster does will lead to great new EFL-based applications. Edje looks very interesting. Qtopia provides everybody with another option to do telephony. Some people may dislike it, well they can ignore it and continue with GTK+ instead. OpenEmbedded is what holds Openmoko together, and there will always be lots of images. If anybody expects Openmoko to force a certain API upon its users, you are wrong! WinMobile may be forcing some APIs as 'default' APIs upon you, so does Symbian, iPhone, etc. Openmoko won't. GTK+ is not Openmoko's official/default graphical toolkit, never was and never will be. Openmoko's mission is not to teach the world how great GTK+ is. If GTK+ is good, great GTK+ applications will emerge, and usage of GTK+ will grow. This can be driven by YOU as much as by the few full-time Openmoko employees. Please help us improving our GTK + applications today! Right now there is a lot of momentum behind EFL/Edje at Openmoko, some of the new applications we are developing (Assassin, Exposure, Splinter) are based on that. If you think we are "switching to QT" - why are we then developing our new applications using EFL? Hope this provides some background information. Answering your questions: Can someone explain the rationale for the decision to switch from the original GTK based OpenMoko to QT based version known as April Software Update (ASU)? No switch. QTopia looked interesting because it gives us a fully functioning set of telephony applications, Trolltech GPL'ed it, and we didn't like the fact that the only way to get access to it was via the framebuffer- based builds Trolltech was distributing. We wanted to have QTopia functionality on top of X, so it could co-exist with GTK+ and EFL, i.e. so that GTK+ applications (tangoGPS and others) would _NOT_ be pushed aside by Qtopia. Our main direction is not QT, it's EFL. As an observer, it's my impression that ASU represents a significant architectural change that somehow, Wham! Bang! "just happened." Wrong. Qtopia on framebuffer, pushing all GTK+ work aside, would have been a major architectural change. Our change is very minor, we just port Qtopia on top of X so it becomes another option. Actually replacing matchbox with the Enlightenment window manager was a bigger architectural change, ask raster about that. I do admit that we have underestimated the degree of antipathy against Qtopia that led people to stop listening as soon as they heard the word 'Qtopia' or 'Trolltech'. :-) Best Regards, Wolfgang On Jun 27, 2008, at 8:01 PM, Ron K. Jeffries wrote: Can someone explain the rationale for the decision to switch from the original GTK based OpenMoko to QT based version known as April Software Update (ASU)? As an observer, it's my impression that ASU represents a significant architectural change that somehow, Wham! Bang! "just happened." Transparency is a virtue. Ron K. Jeffries http://www.retaggr.com/Card/rjeffries ___ 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: CAD file
Michael, both the GTA01 and GTA02 zip files have those .1 extensions inside. The files were created independently (GTA01 by me, GTA02 by Will). There is nothing duplicate in the zip file, everything has .1 extensions. I would be careful about renaming file extensions without checking in Pro/E whether the result still opens. Plus, why rename anything in the first place? This stuff works under Pro/E, it is the original file format Pro/E saves in, including the extension. I wouldn't touch it. Wolfgang On Apr 10, 2008, at 2:25 AM, Michael Shiloh wrote: It's a packaging problem. I think whoever created the original zip file must have had the files twice, so the second copy got the .1 extension. I'll fix that when I get a chance. Meanwhile, simply rename it to remove the .1 extension: mv gtc02-msh01.prt.1 gtc02-msh01.prt or whatever is suitable for the OS your using. Let me know if this doesn't solve your problem. Michael christooss wrote: I have downloaded SolidWorks package from the page. The problem I see is all files have .1 on the end of a name. Example gtc02-msh01.prt.1 Is this my problem or packaging problem? Tnx for anwser ___ 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: customized CPE - Android & Openmoko
Dear khang, Is OpenMoko CPE a good choice for niche or special applications or not ??? Any ideas ? If not , many of the developers will go for Android . That is not good . Let me use this opportunity to talk a bit about Openmoko and Android. First of all we really like Android! We don't see Android as competition, it is complementary to what we are doing and may help us in many ways. If you look at the Android software stack, you will notice that they basically only use the Linux kernel and a few traditional 'helper' libraries, written in C (jpg, png, etc). But the bulk of the system is written from scratch. They even have their own libc! Their own Java virtual machine, their own graphics system, etc. etc. I do believe all of this is very healthy. Fresh blood. Take the Dalvik virtual machine for example. Basically they kick Sun somewhere, but that may turn out to be a nice wake-up call for something like HotSpot and similar established Java projects. IcedTea, GNU Classpath, etc. At the same time they ignore pretty much everything the FOSS community built over the last 10-20 years. No X, no d-bus, no standard packaging system, ... It's a fundamentally different approach from Openmoko. From outside you first have to decide: Do you go with Android and step outside of 90% of what the FOSS community has built? Or do you go with Openmoko, which is a lot closer to something like Ubuntu? There are many things to learn from Android. I like their 'intent' system for example. Lots of great software will become available as Open Source, and will find its way into many places, one of them being Openmoko. Getting the complete Android to run side-by-side with GTK or Enlightenment will be a lot harder than it is with Qtopia for example. That's because even though Qtopia can be seen as one large monolithic code base, it is still relatively well connected to many other FOSS standards. Android is not connected at all, just sitting on top of the Linux kernel, and several times larger than Qtopia. Bottom line: We hope the Android sources will be releaesed soon. We think Android is a great piece of software, will become really successful, maybe even become the long-awaited 'Linux desktop' one day? The future looks good for Android. Openmoko will benefit in many ways, from Google pushing chip vendors to become more open to lots of high-quality Apache-licensed source codes being set free, allowing us to cherry-pick from Android into Openmoko. Additionally, you can either play with Android itself, or run Openmoko software on hardware that was opened up thanks to Android. Hope this helps, everything is moving so this is just a snapshot in time. Feedback very welcome, a lot of this is driven by what the community wants to do. Often people show us how things should be done, not the other way round ;-) Wolfgang On Apr 4, 2008, at 11:32 AM, khang wrote: Taiwan CPE developers of WiMax (etc..) are looking for a new OS/plateform , so their applications won't be limited . We are planning 1.City surveillance (live project) --- installing digital camera wirelessly sending " clear " image back to control center. 2.Remote medical care --- sending medical data / warning signals wirelessly to Hospital / doctors 3.Home security --- remote monitoring home status including old people and child safty using WiMax network ( mobile Internet ) . Is OpenMoko CPE a good choice for niche or special applications or not ??? Any ideas ? If not , many of the developers will go for Android . That is not good . ___ 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 strives for openness (smedia glamo)
Dear Hervé, here is my perspective: Most chip vendors see their business in selling chips. Documentation is just a necessary evil to them, they are trying to get away with the minimum amount of documentation that will still sell the chip. Unless in very few cases, chip vendors do not see good documentation as a strategic asset that will help sell their chips. Maybe down the road we are lucky and Intel becomes a vendor that sees documentation like this, but I will believe it when I see it. NXP also came around to us in a very nice way. We would like to publish documentation for the Toshiba ASIC in our LCM, very hard with Toshiba (I'm not complaining, it's a big company and we are a minuscule customer). Samsung seems to be going closed, even though they joined the Open Handset Alliance and are a big supporter of Android! Why that? Well, let's think from their perspective: Again - they are selling chips, not books or PDF files. In the case of Samsung, the legal department may look at a given PDF file (say 1000 pages long) and see LOTS OF RISKS! When their lawyers read this document (and they won't understand most of the technical stuff in there), they are very concerned that the document will provide grounds for lawsuits against Samsung later on. If they just sell the chips as-is, those risks are reduced. Plus they will say "why do we have to release THIS particular PDF?" Why not a much shorter version, say a 2-page high-level overview, which the legal department can carefully check word-by-word before release? And if it has to be this specific PDF, why not release even much more? Samsung certainly has another 100,000 pages documentation for each chip, internally. If you think about it from their perspective documentation is a very random thing. You cannot easily convince them that if they release a 1000-page PDF file about the say 6400 chip, they will sell this many more chips compared to just releasing a 2-page PDF file. So we at Openmoko need to be smart, and accept realities out there: ---1 The current model: We try to convince vendors to open up documentation to the public, ideally allowing us (or even better everyone else) to redistribute the documentation. Like Intel is doing with Creative Commons now. ---2 We can try to 'buy' chips+documentation, make the PDF file part of the purchase. We would then put the PDF file behind a click-through license, which says that the PDF behind the click-through license is just part of the Neo product, and does not guarantee product behavior. The legal effectiveness of such a click-through license is debatable, and we would still need the vendor to like the idea and agree to give us documents under these terms. ---3 We can sign traditional NDAs and alert our vendors that we are legally hiring respected FOSS engineers on a nominal basis (say 1 USD/month), in order to give them access to the documents we have under NDA and allow them to write FOSS software same as our traditional, fully-paid engineers can. Again we could only do this with vendors who understand what we are doing, trust us, and generally agree to the idea. We would not mass-hire thousands of people this way, say having a form on the web where you can 'hire' yourself, then download all docs. It all has to be reasonable and ideas and intentions must not be ridiculed. But I could imagine that this is doable, first with a few selected people, later maybe dozens or even hundreds of people? The bigger we make this the more our own legal department will get concerned :-) ---4 We can become much more aggressive in documenting our source codes. Most vendors would actually like that! Remember what I said above that the legal departments see documentation THEY publish as a risk! But if we publish something we wrote ourselves they usually don't care, in fact they like if someone does free work for them. We can say whatever we want about a vendor's chips, worst case we will get sued, not them :-) So maybe we should just go ahead and EXTENSIVELY document source codes, to the point that you basically have long lists of well- documented defines in header files, long commented-out texts describing certain chip behavior, more or less based on what we read in the documentation (just rewritten), etc. Same as always, we would only do this with vendors that understand & agree to this, but as with #2 and #3 there is actually a good chance many vendors would be supportive. There is no perfect solution to cover all cases. We need to work case by case (vendor by vendor) to open up documentation, so that we Free The Phone, as we have set out to do. I see a big tendency to write 'pseudo' open source codes, where it's nominally written say in C, but actually it's just long lists of writing magic 32-bit values into magic memory registers. This is not much different from having a binary driver outrigh
Re: Openmoko strives for openness (smedia glamo)
I like this idea, I think this is legally OK and if we are open and honest about it, may even become an accepted practice known to our vendors. Need to do some more checks on that... Wolfgang On Apr 3, 2008, at 9:44 PM, Harald Welte wrote: On Wed, Apr 02, 2008 at 09:32:31AM +0100, Tom Cooksey wrote: On Sunday 30 March 2008 13:42:23 Harald Welte wrote: Please note though, that being one of the persons who drafted the wording on the contract between Smedia and OpenMoko: The contract contains explicit provisions for OpenMoko preparing a set of documentation for the Glamo chip, not carbon-copying from the original NDA'd docs, and then cooperating with Smedia to jointly release that new manual. However, I doubt that given the current load and priority situation, there would be anyone doing paid work on that set of new documentation. As one (perhaps only one?) who volunteered to start work on a DRM driver for the glamo (the first step to 3D), I can confirm that the NDA OpenMoko has with SMedia prevents them from releasing any docs to 3rd parties, with or without an NDA. what if you become part of openmoko? Just sign some kind of work contract (like other freelancers had and still have with openmoko), but with only USD 1 in return for your work, adding a clause that you keep the copyright on your work? This way you are legally part of openmoko, have access to the docs, and can work on the code. -- - 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
Re: Price of the Freerunner spare parts
Steve, Right, they don't. Wolfgang On Mar 28, 2008, at 1:04 AM, steve wrote: I don’t believe the replacements have the columb counter. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joerg Sent: Tuesday, March 25, 2008 10:05 PM To: Clare Johnstone; List for Openmoko community discussion Subject: Re: Price of the Freerunner spare parts Am Mi 26. März 2008 schrieb clare: On Wed, 26 Mar 2008, Wolfgang Spraul wrote: This is pretty much finished on my end. Nokia BL-6C. Allen Lin did tests (we could only get BL-5C so far, also works). There are lots of clones of these Nokia batteries, we bought a few and can give you the names. But basically anything BL-4C, BL-5C, BL-6C compatible should work. Wolfgang on the GTA01v4 they work but will not charge. Is it different on FReeRunner? They *might* charge better in GTA02 (i guess not tested yet), and they won't deliver same telemetry you get from GTA02's smart-bat coloumb- counter (see wiki). jOERG ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Price of the Freerunner spare parts
Steve, local shop or over the web. So, I've asked Engineering to supply me with a list of replacement batteries that anybody can go out and buy from their local shop or the web. This is pretty much finished on my end. Nokia BL-6C. Allen Lin did tests (we could only get BL-5C so far, also works). There are lots of clones of these Nokia batteries, we bought a few and can give you the names. But basically anything BL-4C, BL-5C, BL-6C compatible should work. Wolfgang On Mar 26, 2008, at 10:07 AM, steve wrote: On Batteries. The battery should be a commodity. as easy to purchase as a AA at your local shop or over the web. So, I've asked Engineering to supply me with a list of replacement batteries that anybody can go out and buy from their local shop or the web. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Marcus Bauer Sent: Monday, March 24, 2008 8:40 PM To: List for Openmoko community discussion Subject: RE: Price of the Freerunner spare parts On Mon, 2008-03-24 at 16:00 -0700, steve wrote: I thought about spare parts a while back. The Issue is this. 1. WHAT do I stock ( which parts) batteries 2. How Many do I stock? thousands ;-) 3. How do I sell them to you? via the resellers 4. What will it cost? free as in beer :°) 5. how do you get them? by postal service :) I suppose I could Offer component kits for sale. That would be the quickest thing for me to do. Sell the whole bag of parts; fix it your self. or build a business around this service. Let me think about it. Throw rotten fruit at this idea if you like. ___ 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: network registration from NEO! please help!
cool. Should we create a wiki page to collect the results?
Wolfgang
On Mar 17, 2008, at 12:43 PM, Erin Yueh wrote:
Hi List,
We'd like to ask your kindly helps on network registration by using
your NEO devices. Particularly, the network from T-Mobile in UK,
AT&T in USA, and Vodafone in Germany, since we've heard some
problems about network registration. It's difficult to camp the
network by using some specific SIM cards. If you are willing to
update your network status with us, we really appreciate from your
works. Thanks a lot! :)
Our questions as below:
1. What NEO device you are using? GTA01 or GTA02
2. Where is your location and what is your network provider? eg. T-
Mobile, San Francisco in USA
3. When you boot the NEO, how long it takes to register the network?
eg. in normal case, it should be able to register to a network in
1~2 minutes immediately.
4. What is your GSM firmware version? you can get this number by an
AT command. Using SSH to your NEO, then type this command:
[EMAIL PROTECTED]:~# libgsmd-tool -m atcmd
libgsm-tool - (C) 2006-2007 by Harald Welte and OpenMoko, Inc.
This program is Free Software and has ABSOLUTELY NO WARRANTY
AT+CGMR
STR=`AT+CGMR'
RSTR=`+CGMR: "HW: GTA02BV5, GSM:
gsm_ac_gp_fd_pu_em_cph_ds_vc_cal35_ri_36_amd8_ts0-Moko6"'
5. What is your IMEI code? by this AT command like previous steps.
AT+CGSN
STR=`AT+CGSN'
RSTR=`+CGSN: 000'
6. if NEO takes over 3 minutes to register to the network or it just
re-register to the network again and again. Please attach your gsm
log file ('/tmp/gsm.log') to our bugzilla, we already created a bug
for this issue.
http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=1024
PS. Check our wiki site, if you have problems on these stuff.
How to use SSH on NEO:
http://wiki.openmoko.org/wiki/USB_Networking
How to use libgsmd-tool:
http://wiki.openmoko.org/wiki/Gsmd
Best Regards,
Erin
___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
RIP Joseph Weizenbaum
http://www.heise.de/newsticker/meldung/104672 Was always good to read his latest 'angry thoughts', and I'm sure many people in the Free Software scene in Germany will miss him. --- MIT The Tech, April 1985: I think the computer has from the beginning been a fundamentally conservative force. It has made possible the saving of institutions pretty much as they were, which otherwise might have had to be changed. For example, banking. Superficially, it looks as if banking has been revolutionized by the computer. But only very superficially. Consider that, say 20, 25 years ago, the banks were faced with the fact that the population was growing at a very rapid rate, many more checks would be written than before, and so on. Their response was to bring in the computer. By the way, I helped design the first computer banking system in the United States, for the Bank of America 25 years ago. Now if it had not been for the computer, if the computer had not been invented, what would the banks have had to do? They might have had to decentralize, or they might have had to regionalize in some way. In other words, it might have been necessary to introduce a social invention, as opposed to the technical invention. What the coming of the computer did, "just in time," was to make it unnecessary to create social inventions, to change the system in any way. So in that sense, the computer has acted as fundamentally a conservative force, a force which kept power or even solidified power where is already existed. --- Wolfgang ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: PMU user manual
Maybe we eventually will get the user manual too, with register description and all the good stuff ;-). Anyway, great job! We are working on that. Please note that the current PDF we uploaded says 'Company Confidential' on every page. NXP has specifically given us permission to publish this PDF on our website, so the 'Company Confidential' statement is not correct. We are trying to get a document without this banner, to avoid unnecessary questions. For the record - Openmoko is 100% precise when it comes to following contractual obligations, NDAs, copyright law, GPL, etc. And it's very important for us to be seen that way, or else our business partners would not be willing to release more documentation to us in the future, some of it under NDA. NXP said they would release an addendum to us in 2-3 weeks describing the registers as well. Hopefully by then we can also get rid of the 'Company Confidential' banners. Wolfgang On Mar 1, 2008, at 12:00 PM, joerg wrote: Am Fr 29. Februar 2008 schrieb Andy Green: For PCF50633(GTA02) there obviously never was a public datasheet/ user manual (at least i found 2 years old postings asking for it), only a broken/empty link on manufacturers site. :-( Please can anybody give a pointer to these docs, or even upload them to the wiki? All I can say is it is marked up "Company Confidential" so I can't put it anywhere without some authorization, otherwise you'd be welcome. I cc'd Wolfgang who is out and about at the moment in case he has some better knowledge about any agreement with NXP. Obviously it is okay to make enums and defines and comments in the sources... maybe if you have a specific question I can help, but I agree that sucks compared to printing out the datasheet. -Andy http://people.openmoko.org/tony_tu/GTA02/datasheet/PMU/PCF50633DS_02.pdf :-) Thanks Wolfgang, Andy and Tony! Maybe we eventually will get the user manual too, with register description and all the good stuff ;-). Anyway, great job! ___ 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: To everybody! Brenda -Full time editor on board
Alexey - you are right, something is wrong with 'Special:Allpages'. I went there and only saw 2 pages, as you said. But then I switched the 'Namespace' from (Main) to Talk, then OpenMoko (hit 'Go' each time), then back to (Main), and then all pages (I think all :-)) showed up. Weird, but at least a workaround to see all pages. Wolfgang On Feb 20, 2008, at 2:33 AM, Alexey Feldgendler wrote: On Tue, 19 Feb 2008 10:52:53 +0100, Brenda Wang <[EMAIL PROTECTED] > wrote: Firstly, I will create a page as an "Index". The page's name is "OPENMOKO WIKI Offical Index Page". It is like a book's Index; then you can find things easily. Please let me know if you have any suggestions or questions. http://wiki.openmoko.org/wiki/Special:Allpages is supposed to be an automatic index page in MediaWiki, but apparently it's broken, as it only shows two pages. I think it should be fixed. -- Alexey Feldgendler <[EMAIL PROTECTED]> [ICQ: 115226275] http://feldgendler.livejournal.com ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: proprietary firmware
Tony - ... and what's the quantities you want to buy. I think if we could buy their whole company, the openness should not be an issue anyway. But before that happens, ... FANTASTIC! Tony, your explanation settles this topic once and for all... Way to go! Wolfgang On Feb 16, 2008, at 12:42 PM, Neng-Yu Tu (Tony Tu) wrote: joerg ??: Am Fr 15. Februar 2008 schrieb Brandon Kruse: In that case it is not an open phone or platform. It's a philosophical question, where "open" has it's limits. E.g. you probably consider a plain vanilla x86 GNU/linux desktop system to be pretty much "true open". However i guess you have no idea at all of the firmware that's managing your harddisk in this system. That's for a simple reason: IDE interface is age old (and so all HD's (SATA, SCSII) inherited this way we are looking at these devices), it is "just working", and it's well documented. Virtually nobody cares about the firmware behind this interface, mainly because it doesn't have a chance to stop you from doing anything you like on the _main_system_. I'm almost certain there's a hacker somewhere out there, who likes to mod his HD so the head motors will produce funny sounds, and another one thinks he can tune transfer rates even another 10k/s. However i never seen FOSS HD firmware. When things down to that low level, it's not only firmware issue. It also about chip selection for specific design. For example, every HD has some write cache mechanism in firmware, but some of read/wirte acceleron also chipset related, some chip vender's read/write cache command for SDRAM just faster and stable than others. And you will need these details specification to do the hardware ans firmware design. Chip selection also is the balance of performance/usability/price/ marketing, especially for mass production products like hard disk, user won't even notice the changes on chips and cause of change chips. And transfer rate is a myth: means write into cache/or write on the disk and then verified it write correct. It has some many detais for a single bit from keyboard to your hard disk. If anyone could get 10% transfer faster algorithm for any hard disk, no vendor would refuse it :) It is well worth the investigation to go fully open somehow IMO. Sure. But it's a silly idea to try and force the subsystem manufacturers by refusing to support their closed source firmware updates. When Seagate comes with a DOS-only firmware updater to add some cool new features to their drives, OM says "No, it's not FOSS!". Seagate (or here, the chip fabs) don't care. But OM deprives NEO owners of any means to have a new firmware for these subsystems. If a user doesn't like to have closed source on his device, she is free delete or not install it. But OM will not achieve anything by refusing to provide closed source drivers. I think all they get is a huge number of returns, or less sales (at least for me). And OM(!) isn't willing or able to provide circuit diagrams, so any open drivers are extremely hard to develop. In my opinion they can't do both, refuse to support closed source updates *and* keep the hw specs closed. Not if they care about their customers. Not to mention, NEO will not be "open" at all as long as the hardware is a 'big mystery'. A laugh to start with closed firmware topic. Most function on GTA was exist in module format, and do a lot negotiation with vendor to open their document or firmware update utility. It is not OM say: We want this open. Then the vendor say: no problem, just open it. Usually comes with the answer that: Well, we need to ask our legal department first, and what's the quantities you want to buy. I think if we could buy their whole company, the openness should not be an issue anyway. But before that happens, we have to through long negotiation for each of the components for better hardware openness. I think GTA is not as complex as ps3 or close hardware as Aphone, you could almost ask any question in the kernel development mailing list for the details for hardware related except ask for full schematics directly :) I could not speak for OM, but open anything we did is the target, also the times we spent to talk with vendors, and we will keep persuade hardware vendor/industries anyway :) But I guess we could be like olpc and have a MOSTLY open platform (wifi chip is not, as you could have guessed) I'd like it more to see OM pushing manufacturers to provide a guaranteed API, which is specified by community, and not to care about _how_ the mfactrs achieve to fulfill this contract. Than to nag manufacturers to open the sources of firmware, "because we can do better, and do not want to use what we paid for". Maybe you imply a open standard for each hardware module access here :) Tony Tu ___ OpenMoko community mailing list community
Re: GTA02 Battery Capacity (Was: Re: More about the GTA02)
Andy - class to expose it so it is generic. (I don't know for sure if it will ship with such a battery since it is decided in .tw according to availability and so on, but I hope it will.) Yes, I think we can confirm that every GTA02 will ship with this new 'smart' battery. There are more steps to go through internally, related to certification, some sort of calibration. Tony, do you know more details? The cell's capacity will increase slightly to 1250 mAh (before was 1200 mAh). I am trying to release the schematics for the small PCB inside the smart battery as well, will be posted to the wiki. Wolfgang On Feb 15, 2008, at 12:43 AM, Andy Green wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Somebody in the thread at some point said: On Thursday, Feb 14, 2008, "Kyle Bassett" writes: There is talk about pushing startup power control of the internal devices (wifi, bt, gps, mmc, etc.) to user level, as every user may or may not want certain devices available at bootup/all the time (availability vs. duration). Indeed, this along with good realtime stats on power usage and current battery level would let people have reasonably accurate predictions of their battery life. It'd be interesting (to me at least) to turn on and off the various peripherals and watch my projected battery life go up and down accordingly. GTA02 is capable to dialogue with a "smart battery" that will allow you to see the battery actual voltage and current flow (together: actual power) in uA down /sys in realtime, it uses the linux "Power Supply" class to expose it so it is generic. (I don't know for sure if it will ship with such a battery since it is decided in .tw according to availability and so on, but I hope it will.) The battery itself learns its cell performance over load and also makes available its "time to full/empty" estimate down /sys as well in seconds. You can see what data is available here: http://www.ti.com/lit/gpn/bq27000 You can see stuff like this for i in capacity charge_full current_now present status technology temp time_to_empty_now time_to_full_now type voltage_now ; do echo -n "$i " ; cat /sys/devices/platform/bq27000-battery.0/power_supply/bat/ $i ; done capacity0 charge_full1215585 current_now183375 present1 statusDischarging technologyLi-ion temp276 time_to_empty_now0 time_to_full_now3932100 typeBattery voltage_now2761000 - -Andy -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHtG+yOjLpvpq7dMoRAq2TAJoCYOC+PD3gj/jRMpOPnBL5MZJkzQCfTJn4 9ebCrbNjtGtDMBsJuUXZ8HY= =ANtG -END PGP SIGNATURE- ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
solar power
Andy (or anyone else), if the whole back of the Neo would be a solar panel, and you would put it back side up into direct sunlight, say for 5 hours, how much could that charge the battery? Could you operate the phone without a battery (and without USB) power if you were standing in sunlight? Just curious, thanks for any answers, Wolfgang ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
proprietary firmware
Dear Community, Some of our chips or chipsets contain proprietary firmware in flash memory. For example, in GTA02 these include the Wi-Fi, GPS, and GSM chipsets. Ideally, we would have liked to use chipsets for which even the firmware code would be free, but they don't exist right now. So we accepted proprietary firmware, as long as it was in flash or ROM. Then we ran into problems when bugs were found in the firmware, and we wanted to update handsets out in the field. The vendors would give us firmware updates and reflashing tools, but they wouldn't let us redistribute those tools to our users. We asked for special licenses to allow us to distribute those flashing tools to our users, and got them in some cases, after months of licensing negotiations. Next we discovered that those reflashing tools had further issues: for example, they would only allow loading cryptographically signed firmware into the chipset flash memory. The tools do this because vendors are worried that people would disassemble, patch, and reassemble the firmware, triggering regulatory reclassification of their chipsets (software controlled radio). Furthermore, we see that for upcoming chipsets, vendors are switching from storing the firmware in flash memory to loading the firmware into RAM at run time. One reason for this is that RAM needs less power and is cheaper. In this case the firmware, whether original or updated, has to be loaded each time the device boots, requiring that the binary- only, restrictively licensed firmware updater be included in the OpenMoko distribution. This got quite frustrating, until we met Richard Stallman last weekend. And he cleared it up for us rather quickly :-) He suggested we treat any chipset with proprietary firmware as a black- box, a circuit. He suggested we ignore the firmware inside. If the firmware is buggy and the vendor needs the ability to update the firmware, we instead ask the vendor to reduce the firmware to the bare minimum, so that it can be very simple and bug free, and move the rest of the logic into the GPL'ed driver running on the main CPU. This way we completely avoid the issue of distributing proprietary firmware updates and binary firmware updaters with restrictive licensing that load only cryptographically signed firmware. We liked his advice. It speeds up our decision making and allows us to focus on what we do best: Developing Free Software that is available in full source code, running on the main CPU, that we and anyone else can modify and optimize. There are downsides: We will no longer offer reflashing tools to update proprietary firmware, under any license. For critical firmware bugs, we will accept returns, or in some cases fix the bug in-house. We will push vendors to simplify the functionality of their proprietary firmware, so we can implement more of this on the main CPU as Free Software. Maybe some vendors will even open up firmware for Free Software development, that would be the ideal outcome we are working towards. We hope this helps clarify OpenMoko's current position on proprietary firmware: Ignore them while they stay inside of a chip or chipset, and refuse to touch them. Focus on what Free Software can do. Feedback and comments are always very welcome. Best Regards, Wolfgang ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Wiki - confusion
JW, Michael - we had an internal discussion about this and I think everybody is on the same page now: GTA01 = Neo 1973 GTA02 = Neo FreeRunner Brand: Neo Model: 1973 Version: gta01 'gta' for all gta-series class devices Hope this helps, going forward we will try to get better at keeping internal (engineering) names and marketing names separate, because they travel at different speeds :-) Wolfgang On Feb 6, 2008, at 1:00 AM, Michael Shiloh wrote: JW wrote: so did we get any official pronouncement from the Openmoko team yet? Are Wolfgang Spraul and me right (gta1=neo gta2=freerunner) Or is Piotr right (neo1973 = class of phones covering phase 0 and phase 1 incl gta01 and gta02 and only public release or phase2 = freerunner) Hope i represented Pioter view properly (check further up thread) Would be good to know from one of Openmoko team members (michael?) so wiki can reflect correct picture I haven't had a chance to triple-check, but I'm 99% sure it's this: GTA01 = Neo 1973 GTA02 = Neo FreeRunner Thus both are members of the Neo family. 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: Wiki - confusion
JW, Pietro, roh - OK, the confusion even exist within OpenMoko :-) So it's definitely something we need to find out soon. I think it's like JW said, roh thinks it's like Pietro said. Stay tuned, we will find out soon... Wolfgang On Feb 3, 2008, at 5:29 PM, Joachim Steiger wrote: Pietro "m0nt0" Montorfano wrote: JW ha scritto: Hi Openmoko community The wiki needs to present clear information. There is one area where it is pretty bad at the moment and that is in all the confusing references to neo's and GTA01s and GTA02s. It seems to me there is now a clear structure 1) Neo1973 has internal codename (GTA01xxx) 2) Freerunner has internal codename (GTA02xxx) [snip] Hey, i think that you are a bit confused, asi've understood the names are: Neo 1973 -> the phone, gta01 or gta02, is always the neo 1973 gta01xxx -> first version of the phone for devs gta02xxx -> second version of the phone that has to be released soon (oh we are waiting for it... :D) FreeRunner -> another name to refer to the gta02xxx just to have a friendly name instead of GTA02 Is it right? yes. also all the drivers got fixed just recently to reflect that original naming scheme. Neo1973 is a class of devices, not only one specific model. gta01 and gta02 are models. FreeRunner a synonym for gta02 release version kind regards -- Joachim Steiger developer relations/support ___ 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: Wiki - confusion
JW - Should i just go ahead and change the core structure to being correct and the rest will follow?Is there someone overlooking wiki structure? Yes, I think you can move ahead with those changes. Let's see what others are saying... It seems to me there is now a clear structure 1) Neo1973 has internal codename (GTA01xxx) 2) Freerunner has internal codename (GTA02xxx) That is correct. Is there someone overlooking wiki structure? We just hired a full time editor for the wiki. Her name is Brenda and she will start working after Chinese New Year (mid February). She has many years experience publishing and writing technical books. I'd say give her a few weeks to familiarize herself with the whole thing, then she will slowly start to 'edit' the wiki by cleaning up broken links, rearranging/grouping content, maybe doing some translations into Chinese, etc. If you like please get back to me around mid-February so I can introduce you to Brenda (she doesn't have an openmoko e-mail account yet). We are very determined to get the wiki into better shape. Brenda will help as an editor. We also try to improve things on the server. The wiki version we are using needs to be updated and improved. Search is abysmal. The theme doesn't look good. etc. But we have great content, and we will push more internal content into the wiki as well. Hope this helps, thanks a lot for your initiative! Feel free to make the changes you suggested, at least from my perspective it sounds good. Wolfgang On Feb 3, 2008, at 12:31 PM, JW wrote: Hi Openmoko community The wiki needs to present clear information. There is one area where it is pretty bad at the moment and that is in all the confusing references to neo's and GTA01s and GTA02s. It seems to me there is now a clear structure 1) Neo1973 has internal codename (GTA01xxx) 2) Freerunner has internal codename (GTA02xxx) However wiki pages are mixture of terms that doesn't make sense anymore because they have been used interchangeably over the last year. I changed a bit of section 1 of the FAQ page and started to look at tidying up the main pages at least to make this less confusing and I can do it the only problem is that i may break the pages/links of others This happens especially where the wiki page title needs to be changed. For example the Neo1973 page has loads of refs to GTA02 (which need moved to the, as yet blank Freerunner page) but it is linked to by 50 other pages many in other languages Should i just go ahead and change the core structure to being correct and the rest will follow?Is there someone overlooking wiki structure? JW ___ 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
