Re: Shiny geek toy?
On 12/7/06, Christopher Heiny <[EMAIL PROTECTED]> wrote: What exactly is it that we want OpenMoko to be? Do we really want a shiny geek toy? Something that is super cool and technologically advanced, but only nerds will want to hack on? Or should we be working toward a solid OpenSource platform that will encourage other phone manufacturers to build on it and in turn give their work back to the community? I think it is possible to do both. To take a recently discussed example: an FPGA is really super cool and flexible and you can do just about anything with one. But the downside is that it is HARD to do that stuff. Even if you, personally, find VHDL or Verilog to be easy to work with and understand, the average engineer working at someplace like Samsung or Nokia (or wherever) will not have the same skills you do. Sorry, I do not quite understand you there. It sounds as if you think the _only_ way to program a FPGA is through VHDL or Verilog. One of the things you can put on a FPGA is a generic microprocessor (e.g. a PowerPC or SPARC). You can then program the processor as you normally do. In fact I would expect this approach: Use some of the FPGA for a generic microprocessor (e.g. handling the UI and phonebook) and only use the rest of the FPGA for compute intensive operations (e.g. software radio, video decoding). Please check out General Purpose, Low Power Supercomputing Using Reconfiguration http://video.google.com/videoplay?docid=-4969729965240981475 It really opened my eyes to what might be possible. Additionally, it takes time (lots of time) even for skilled engineers to design, implement, and debug new features for FPGAs. Agreed. But most of the user facing functionality would be in the generic microprocessor. Time to market is critical for most phone manufacturers, especially in countries such as Korea where product lifetimes are often measured in months. This argument is exactly why I think a FPGA is the right way to go: My phone does not do WiFi, but I would find it tremendously useful if I could install WiFi just by installing software. With FPGA you open the possibility to upgrade the phone with functionality that would otherwise require a new hardware. Five of the critical enablers to this are: - rock solid reliablity. Anything in the phone should "just work", and it must do it every time. By stripping down the FPGA to just include GSM and a generic microprocessor as default, I think that would be doable. - easy to customize or extend. Not just by VHDL aces and Perl wizards, but by the average C/C++/Java programmer two years out of university. His boss is going to choose a platform that plays to his skills (or lack thereof). I whole heartedly agree. With the generic microprocessor included on the FPGA this can achieve both goals. - support fast development. That young coder in the previous bullet is going to be under a LOT of time pressure. His boss is going to choose the platform that he feels will best help him meet schedule, and will see C++ and Java as enablers, VHDL and Perl as barriers. That depends on what you are trying to develop. If you are trying to develop video decoding or software radio you might limited by processing power. This limit might be moved with FPGA. But again: I do not see any reason why you need to make a choice between VHDL and Java when you can have both. I do not see FPGA as realistic for neither v1 nor v2. But for v3 it just might be a possibility. /Ole ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
Re: Shiny geek toy? [scanned]
On Thu, 2006-12-07 at 14:15 +0100, Markus Stehr wrote: > Argh, why does it always have to be some obscure object orientated > language? C/C++/Java are obscure? > I would rather like to see some procedual Basic, like FreeBasic or > QBasic, on this little buddy. I'd argue strongly against this. I have a lingering affection for Blitz Basic on my windows box - I can prototype ideas and algorithms very quickly and the integrated debugger is nicer than DDD or printf's. But the lack of strong typing, even in compiled Basic, leads to quirky unpredictable behaviours when scaled. For deployment on a "i just want it to work, now" system such as a mobile phone, a proliferation of basic/weak typed languages could be fatal. I seem to recall, although maybe I just dreampt it, that the UI interface is written in C, rather than C++. I'm pretty sure it was an October entry from Harold Weltes blog, although I can't find it now: http://gnumonks.org/~laforge/weblog/index.html (interesting info on the GSM implementation here too!) > Benefits: More applications. > Everyone and his dog can produce decent apps and games with Basic as the > learning curve isnt so steep as with C++/Java. I disagree with the 'decent apps and games with basic' line: 1) They still require hooks into the OS, but are completely dependent upon those hooks for system interaction. If a hook doesn't exist for a certain bit of functionality, then your basic program has no way to use it. 2) Even at 80% efficiency, that's still a waste of CPU/Battery life for ZERO end-user benefit. I agree that it'd be nice to present a safe development sandbox for people who don't want to wade through reams of documentation but have some coding experience. However, I think the way to do that should be through simple, well-documented API's. Richard ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
Re: Shiny geek toy?
On Thu, 2006-12-07 at 08:38 -0800, Christopher Heiny wrote: > Part of my day job is to nudge (or sometimes thump) the fantasies of my own > team back into line with reality. It looks like I let that leak over into > OpenMoko, too. I'll have to be more careful about that in the future. Not at all, I found your points very well considered and welcome. Reality after all, is only a fantasy which has gained concensus - such as project deadlines, or the validity of economic systems. If there were separate areas for Neo1973 discussions, and Neo discussions, then I'd subscribe to both, but as traffic on this list isn't likely to grow substantially until release or another announcement.. I'm happy to read ideas from both angles! Cheers, Richard ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
Re: Shiny geek toy?
On Thursday 07 December 2006 05:08, bullet holes in a road sign were found to spell the following message: > I think you are generally right, with some caveat. > > It's really a chicken/egg problem. Will the carriers come first, or > the applications? > > It is possible that in 2007, linux based extensible phones will become > the rage. We have greenphone, Access, and open moko. But if carriers > feel that these platforms threaten their lock on the platform, they > may not adopt. In that case it will require cheap phones and 3rd party > software communities to make a killer app that drives carriers to > adopt. If this is the case then this first version is really more a > shiny geek toy that ultimately motivates some great applicaton(s) that > then drive carrier adoption. Well, yeah, you're right in that in certain ways OpenMoko >is< a shiny geek toy. But I think what we want it to be is the shiny geek toy that makes as many people as possible say "Hey, we can build our next market dominating phone on that!" rather than "Hey, that would be great in my hobby workshop next to the Heathkit". ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
Re: Shiny geek toy?
On Thu, 7 Dec 2006, Christopher Heiny wrote: On Wednesday 06 December 2006 20:28, bullet holes in a road sign were found to spell the following message: Hi Christopher, You are very right, of course. However, fantasies have their place in product design. They inspire ideas. Out of 100 (or 1000) of our completely wild fantasy ideas, one of them might turn out to be really useful and practical. Thanks for the reality check Michael. You're very right that the fantasy process has its place in product design - in fact, it's very very important. Part of my day job is to nudge (or sometimes thump) the fantasies of my own team back into line with reality. It looks like I let that leak over into OpenMoko, too. I'll have to be more careful about that in the future. Well, don't let me squelch you, either. Fantasy ideas are easy to come up with. Knowing how to nudge them back to reality - now that's a rare skill. There is room, and need, for us all. Michael ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
Re: Shiny geek toy?
On Thursday 07 December 2006 05:15, Markus Stehr scribbled in crayon on the back of a kid's menu: > Hi! > > Christopher Heiny: > >and will see C++ and Java as enablers, VHDL and Perl as barriers. > > Argh, why does it always have to be some obscure object orientated > language? > I would rather like to see some procedual Basic, like FreeBasic or > QBasic, on this little buddy. Then you're making a shiny geek toy. Very few coders fresh out of college know any dialect of Basic - most of them are going to know C++ and/or Java, and that's about the only one(s) they'll be capable of coding well in. Management is notoriously aadverse to people spending time on training or learning, especially when on very tight schedules. I'm not arguing that one language or another is better for developing applications or running an embedded system. What I'm trying to point out is that management is going to play to the lowest common denominator in the engineering staff. Requiring all (or most) of your people to learn a new language in order to use OpenMoko is going to be a major inhibitor to adoption of OpenMoko, regardless of the superiority of that language. That said, there's nothing standing in the way of porting as many Basic dialects to the platform as your heart desires. As I think someone pointed out in another thread last month, you can do that with Python. But all the good stuff you point out below isn't going to matter to the pointy haired bosses. > Benefits: More applications. > Everyone and his dog can produce decent apps and games with Basic as the > learning curve isnt so steep as with C++/Java. > And that a Basic compiler can produce fast code we see on FreeBasic. > Version 0.17 and it produces codes that is ~80% as fast as the same > programm coded in GCC-C and you can do the same stuff you can do in > GCC-C but with a language everyone understands, plain English. > Maybe someone with some knowledge in the Gnu Compiler Collection could > help Andre Victor, the author of FB, converting the standalone compiler > (BASIC -> x86 ASM -> Opcodes) to a GCC frontend (BASIC -> "GCC Pseudo > Asm" -> Opcodes). Its on the todo list but first Andre wants optional(!) > OO support. Its there but needs some extensive testing ;) > If FB gets frontended then we would have our Basic *g* > > Greetings, > Markus Stehr > > > > ___ > OpenMoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/cgi-bin/mailman/listinfo/community ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
Re: Shiny geek toy?
On Wednesday 06 December 2006 20:28, bullet holes in a road sign were found to spell the following message: > Hi Christopher, > > You are very right, of course. However, fantasies have their place in > product design. They inspire ideas. Out of 100 (or 1000) of our > completely wild fantasy ideas, one of them might turn out to be really > useful and practical. Thanks for the reality check Michael. You're very right that the fantasy process has its place in product design - in fact, it's very very important. Part of my day job is to nudge (or sometimes thump) the fantasies of my own team back into line with reality. It looks like I let that leak over into OpenMoko, too. I'll have to be more careful about that in the future. > I love exploring the FPGA idea. I think it's creative, different, and > inspires further creativity. But I completely agree with you that a > developer-reprogrammable FPGA in this device is completely impractical. > > When we have a wiki, we will have a section for fantasy wishes. We will > play there to our hearts content without thinking of practical aspects. > And, once in awhile, an idea from the fantasy pages may be transferred to > the list of features to be implemented. > > Until we have the wiki, I believe that Sean and the others are able to > sort our ideas into the proper categories. Definitely. > I do appreciate your clear, well-thought out and well-written comments. > Perhaps they, or something similar, should be preserved on the wiki to > help put discussions in the proper category. > > Sincerely, > Michael ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
no :) Re: Shiny geek toy?
Salve Sean! On Thu, 07 Dec 2006, Sean Moss-Pultz wrote: > On 12/7/06 12:00 PM, "Christopher Heiny" <[EMAIL PROTECTED]> wrote: > > > Do we really want a shiny geek toy? Something that is super cool and > > technologically advanced, but only nerds will want to hack on? > > > > Or should we be working toward a solid OpenSource platform that will > > encourage other phone manufacturers to build on it and in turn give their > > work back to the community? > > The latter please ;-) I don't see a big dualism, big contradiction in the two statements. The hacks of the nerds could be good backends for smart solution. E.g. to make things faster, more efficient and reduce the needed bandwidth as much as possible. The frontent/GUI usability concepts is a different point, I beleave that all of use want that thier ideas and hacks are useable and will be used from as much as possible people - so usability is a second important point. Development is like walking into circles - it is not so important where to start, but it is importanted to change the perspective as much as possible - e.g. see the backend hacks from the prespective of end users regulary (from time to time) and then go back to make the backends more usable/powerfull. Also drawing (new) concepts for the user IO (GUI) would be helpfull, but IMHO isn't it needed that the GUI is realy programmed as first stepp - just some short text or quick drawings should be good enough. Second, adding SPI contacts to the circuit board or adding on FPGA to the Neo1973 isn't just a "geek toy". Since > 7 years there is a growing market for GSM-terminals, used into -maut systems -maschines for remote access -wether stations -traffic systems -... GSM + mobil computer isn't only belong to handheld mobil phones. These GSM-terminals are expensive, because they are sold for the expensive industrial embedded system marked. A dual use product - same device - maybe other case or selfmade modification would encrease the market potential of the Neo1973 dramaticaly. Together with AGPS the Neo1973 and open Linux will break into this embedded system market and will open new markets. THIS is also important for FIC and for their stock holder. It would be a big foult to think one about another multimedia smartphone. Thinking in a way smartphone = mobil PC + GSM/GPRS + AGPS is absolutly *not* the idea of a shiny geek toy that I like to play with - I think about a revolution of mobil PC power with a high industrial, commercial power. The Neo will be much more than a phone - giving them more IO capacy (SPI) or even more better a special eddition with on FPGA will be moblilPC-revolution² (power of two). It will also give all OpenMoko developer much much more economic perspective when the Neo1973 is not only a dumb smartphones like the others on the market. AGPS + 480x640 + Gnu/Linux will make the Neo1973 very interesting for navigation devices (AFAIK is there no AGPS pocket navigation system on the market, yet). Just one SPI connection to one FPG - or better one FPG with SPI (or better connection) between SoC and SD could be used to shortend the time for routing calculation dramaticaly: http://lists.openmoko.org/pipermail/community/2006-December/000635.html So this FPGA could be placed into design now, without having the FPGA programming to use it. OpenMoko hacker would find a solution and the Neo1973 would beat every pocket navigation system - and this enhancement would be flashable for all Neo1973 users: - good press feedback to sell more Neo1973 - good press feedback for the FIC stock quotation So don't think in category of "toy" - even when playing with ideas is the spring of new ideas. Cheers, rob PS: And remember the power of opencores And it seems that here are some free cores: http://www.opencores.org/browse.cgi/by_category 10/100 Mbit/s Ethernet USB 2.0 With the FPG between SoC and USB jack, the usb port could become to be Ethernet When the neo1973 would have two audio connectors - audio in/audio out - audio out/composit video out or even maybe - audio in/composit video in All with the same connectors, the solutions could be done by some hackers and be become official part of OpenMoko some day. But the "culture medium" the basic for all such development would be a hardware which would makes hardware/FPGA developm
Re: Shiny geek toy?
Sean Moss-Pultz wrote: On 12/7/06 12:00 PM, "Christopher Heiny" <[EMAIL PROTECTED]> wrote: Do we really want a shiny geek toy? Something that is super cool and technologically advanced, but only nerds will want to hack on? Or should we be working toward a solid OpenSource platform that will encourage other phone manufacturers to build on it and in turn give their work back to the community? The latter please ;-) Absolutely. The last thing I want is another neat but essentially dead-end device.. (AgendaVR3, anyone..?) I'm really stoked about the specs I've read thus far - enough to work with, enough to be modern/marketable, but not overloaded to the point of killing the price and attractiveness of the device. -P ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
yeah flame war about program languages to use a FPGA that isn't in v1 :) Re: Shiny geek toy? [scanned]
Salve Markus! Markus Stehr schrieb am Donnerstag, den 07. Dezember 2006 um 14:15h: > Christopher Heiny: > >and will see C++ and Java as enablers, VHDL and Perl as barriers. > > Argh, why does it always have to be some obscure object orientated > language? This thread belongs to FPGA ;) And there is no roadmap when the first OpenMoko phone would have a FPGA inside - so isn't it a little too early to start a flame ware about languages to use with a FPGA now? > I would rather like to see some procedual Basic, like FreeBasic or > QBasic, on this little buddy. Oh, I would prefer Python or maybe ruby and when we want to do parallel computing on a FPGA, Erlang would worth a look *G*. In erlang is also written the good jabber server ejabberd. :) http://en.wikipedia.org/wiki/Erlang_programming_language Just for fun - back to the roots of telephonie server: "erlang - the movie" http://video.google.com/videoplay?docid=-5830318882717959520 > Benefits: More applications. > Everyone and his dog can produce decent apps and games with Basic as the > learning curve isnt so steep as with C++/Java. When everyone and his dog should be able to produce a app, squeak would be a tool for them, but again, this thread is about FPGA. BTW programming languages: But does e.g. debian care which language is used? NO. So I don't see the need to start a language flameware now - and the OpenMoko SDK will answer which languages we will use to start with :) And remember everybody will be free to install the language that he likes... IMHO there is no reason why to discuss which language is the best - different tasks gives reason to deside from case to case which language to choose. Cheers, rob Markus, one wish: Could you please use your MUA (email client) in a way that it use References in the email header in a proper way? With out that your mails could not be sorted into the thread. mercie ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
Re: Shiny geek toy?
On 12/7/06 12:28 PM, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > Until we have the wiki, I believe that Sean and the others are able to sort > our ideas into the proper categories. Definitely. We've got some _really_ long lists! -Sean ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
Re: Shiny geek toy?
On 12/7/06 12:00 PM, "Christopher Heiny" <[EMAIL PROTECTED]> wrote: > Do we really want a shiny geek toy? Something that is super cool and > technologically advanced, but only nerds will want to hack on? > > Or should we be working toward a solid OpenSource platform that will > encourage other phone manufacturers to build on it and in turn give their > work back to the community? The latter please ;-) -Sean ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
Re: Shiny geek toy?
On 12/7/06, Christopher Heiny <[EMAIL PROTECTED]> wrote: What exactly is it that we want OpenMoko to be? Do we really want a shiny geek toy? Something that is super cool and technologically advanced, but only nerds will want to hack on? Or should we be working toward a solid OpenSource platform that will encourage other phone manufacturers to build on it and in turn give their work back to the community? I think it is possible to do both. To take a recently discussed example: an FPGA is really super cool and flexible and you can do just about anything with one. But the downside is that it is HARD to do that stuff. Even if you, personally, find VHDL or Verilog to be easy to work with and understand, the average engineer working at someplace like Samsung or Nokia (or wherever) will not have the same skills you do. Sorry, I do not quite understand you there. It sounds as if you think the _only_ way to program a FPGA is through VHDL or Verilog. One of the things you can put on a FPGA is a generic microprocessor (e.g. a PowerPC or SPARC). You can then program the processor as you normally do. In fact I would expect this approach: Use some of the FPGA for a generic microprocessor (e.g. handling the UI and phonebook) and only use the rest of the FPGA for compute intensive operations (e.g. software radio, video decoding). Please check out General Purpose, Low Power Supercomputing Using Reconfiguration http://video.google.com/videoplay?docid=-4969729965240981475 It really opened my eyes to what might be possible. Additionally, it takes time (lots of time) even for skilled engineers to design, implement, and debug new features for FPGAs. Agreed. But most of the user facing functionality would be in the generic microprocessor. Time to market is critical for most phone manufacturers, especially in countries such as Korea where product lifetimes are often measured in months. This argument is exactly why I think a FPGA is the right way to go: My phone does not do WiFi, but I would find it tremendously useful if I could install WiFi just by installing software. With FPGA you open the possibility to upgrade the phone with functionality that would otherwise require a new hardware. Five of the critical enablers to this are: - rock solid reliablity. Anything in the phone should "just work", and it must do it every time. By stripping down the FPGA to just include GSM and a generic microprocessor as default, I think that would be doable. - easy to customize or extend. Not just by VHDL aces and Perl wizards, but by the average C/C++/Java programmer two years out of university. His boss is going to choose a platform that plays to his skills (or lack thereof). I whole heartily agree. With the generic microprocessor included on the FPGA this can achieve both goals. - support fast development. That young coder in the previous bullet is going to be under a LOT of time pressure. His boss is going to choose the platform that he feels will best help him meet schedule, and will see C++ and Java as enablers, VHDL and Perl as barriers. That depends on what you are trying to develop. If you are trying to develop video decoding or software radio you might limited by processing power. This limit might be moved with FPGA. But again: I do not see any reason why you need to make a choice between VHDL and Java when you can have both. I do not see FPGA as realistic for neither v1 nor v2. But for v3 it just might be a possibility. /Ole ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
Re: Shiny geek toy?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tomasz Zielinski schreef: > 2006/12/7, [EMAIL PROTECTED] <[EMAIL PROTECTED]>: > >> Until we have the wiki, I believe that Sean and the others are able to >> sort >> our ideas into the proper categories. > > I can set up temporary (or not temporary, but independent community) > MediaWiki for OpenMoko. Should I? Sean already vetoed that in an earlier mail to this list. regards, Koen -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iD8DBQFFeBOoMkyGM64RGpERApyQAJ4k1RykoHoDfRR2IZQV2EcBClNLDwCfVnb1 XepyFyJzmBukOImrvZ3why8= =G9Ab -END PGP SIGNATURE- ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
Re: Shiny geek toy? [scanned]
Hi! Christopher Heiny: >and will see C++ and Java as enablers, VHDL and Perl as barriers. Argh, why does it always have to be some obscure object orientated language? I would rather like to see some procedual Basic, like FreeBasic or QBasic, on this little buddy. Benefits: More applications. Everyone and his dog can produce decent apps and games with Basic as the learning curve isnt so steep as with C++/Java. And that a Basic compiler can produce fast code we see on FreeBasic. Version 0.17 and it produces codes that is ~80% as fast as the same programm coded in GCC-C and you can do the same stuff you can do in GCC-C but with a language everyone understands, plain English. Maybe someone with some knowledge in the Gnu Compiler Collection could help Andre Victor, the author of FB, converting the standalone compiler (BASIC -> x86 ASM -> Opcodes) to a GCC frontend (BASIC -> "GCC Pseudo Asm" -> Opcodes). Its on the todo list but first Andre wants optional(!) OO support. Its there but needs some extensive testing ;) If FB gets frontended then we would have our Basic *g* Greetings, Markus Stehr ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
Re: Shiny geek toy?
I think you are generally right, with some caveat. It's really a chicken/egg problem. Will the carriers come first, or the applications? It is possible that in 2007, linux based extensible phones will become the rage. We have greenphone, Access, and open moko. But if carriers feel that these platforms threaten their lock on the platform, they may not adopt. In that case it will require cheap phones and 3rd party software communities to make a killer app that drives carriers to adopt. If this is the case then this first version is really more a shiny geek toy that ultimately motivates some great applicaton(s) that then drive carrier adoption. Regards Hank On 12/6/06, Christopher Heiny <[EMAIL PROTECTED]> wrote: What exactly is it that we want OpenMoko to be? Do we really want a shiny geek toy? Something that is super cool and technologically advanced, but only nerds will want to hack on? Or should we be working toward a solid OpenSource platform that will encourage other phone manufacturers to build on it and in turn give their work back to the community? To take a recently discussed example: an FPGA is really super cool and flexible and you can do just about anything with one. But the downside is that it is HARD to do that stuff. Even if you, personally, find VHDL or Verilog to be easy to work with and understand, the average engineer working at someplace like Samsung or Nokia (or wherever) will not have the same skills you do. Additionally, it takes time (lots of time) even for skilled engineers to design, implement, and debug new features for FPGAs. Time to market is critical for most phone manufacturers, especially in countries such as Korea where product lifetimes are often measured in months. Yeah, we can trowel on all kinds of creamy technological goodness. Myself, I want a dozen A-to-D channels so that I can use the phone for data collection and analysis in my race car. Honest - that would absolutely rule! But it's not what the customer on the street wants, and it's not what the manufacturer trying to sell to that customer wants. To be a success, in the same way that OpenSource projects like OpenOffice, Apache, Firefox, and others are successes, OpenMoko will have to provide a compelling reason for phone manufacturers to choose it over closed source options such as WinCE, Rexx, and others. Five of the critical enablers to this are: - rock solid reliablity. Anything in the phone should "just work", and it must do it every time. - complete functionality. There should never, ever, be a greyed out button in the GUI. Sure OpenMoko might support four different kinds of software radio, but if the manufacturer has to do their own I18N to pick up OpenMoko, they'll choose WinCE instead. - desirable functionality. Does the functionality provided by OpenMoko appeal to the typical human-on-the-street purchaser of this class of phone? Phone manufacturers are going to choose platforms that will help them sell the most phones, even for halo products. - easy to customize or extend. Not just by VHDL aces and Perl wizards, but by the average C/C++/Java programmer two years out of university. His boss is going to choose a platform that plays to his skills (or lack thereof). - support fast development. That young coder in the previous bullet is going to be under a LOT of time pressure. His boss is going to choose the platform that he feels will best help him meet schedule, and will see C++ and Java as enablers, VHDL and Perl as barriers. Shiny geek toys are cool, and I love them. But if we want to rule the world, they don't help that happen. Once we've achieved world domination, we can add all the sparkly bits to OpenMoko we want. Heck, people will probably be doing it for us. Chris ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/cgi-bin/mailman/listinfo/community ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
Re: Shiny geek toy?
2006/12/7, [EMAIL PROTECTED] <[EMAIL PROTECTED]>: Until we have the wiki, I believe that Sean and the others are able to sort our ideas into the proper categories. I can set up temporary (or not temporary, but independent community) MediaWiki for OpenMoko. Should I? I don't want to disturb OpenMoko developers with starting site competitive to openmoko.org. -- Tomek Z. [EMAIL PROTECTED] ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
Re: Shiny geek toy?
Hi Christopher, You are very right, of course. However, fantasies have their place in product design. They inspire ideas. Out of 100 (or 1000) of our completely wild fantasy ideas, one of them might turn out to be really useful and practical. I love exploring the FPGA idea. I think it's creative, different, and inspires further creativity. But I completely agree with you that a developer-reprogrammable FPGA in this device is completely impractical. When we have a wiki, we will have a section for fantasy wishes. We will play there to our hearts content without thinking of practical aspects. And, once in awhile, an idea from the fantasy pages may be transferred to the list of features to be implemented. Until we have the wiki, I believe that Sean and the others are able to sort our ideas into the proper categories. I do appreciate your clear, well-thought out and well-written comments. Perhaps they, or something similar, should be preserved on the wiki to help put discussions in the proper category. Sincerely, Michael On Wed, 6 Dec 2006, Christopher Heiny wrote: What exactly is it that we want OpenMoko to be? Do we really want a shiny geek toy? Something that is super cool and technologically advanced, but only nerds will want to hack on? Or should we be working toward a solid OpenSource platform that will encourage other phone manufacturers to build on it and in turn give their work back to the community? To take a recently discussed example: an FPGA is really super cool and flexible and you can do just about anything with one. But the downside is that it is HARD to do that stuff. Even if you, personally, find VHDL or Verilog to be easy to work with and understand, the average engineer working at someplace like Samsung or Nokia (or wherever) will not have the same skills you do. Additionally, it takes time (lots of time) even for skilled engineers to design, implement, and debug new features for FPGAs. Time to market is critical for most phone manufacturers, especially in countries such as Korea where product lifetimes are often measured in months. Yeah, we can trowel on all kinds of creamy technological goodness. Myself, I want a dozen A-to-D channels so that I can use the phone for data collection and analysis in my race car. Honest - that would absolutely rule! But it's not what the customer on the street wants, and it's not what the manufacturer trying to sell to that customer wants. To be a success, in the same way that OpenSource projects like OpenOffice, Apache, Firefox, and others are successes, OpenMoko will have to provide a compelling reason for phone manufacturers to choose it over closed source options such as WinCE, Rexx, and others. Five of the critical enablers to this are: - rock solid reliablity. Anything in the phone should "just work", and it must do it every time. - complete functionality. There should never, ever, be a greyed out button in the GUI. Sure OpenMoko might support four different kinds of software radio, but if the manufacturer has to do their own I18N to pick up OpenMoko, they'll choose WinCE instead. - desirable functionality. Does the functionality provided by OpenMoko appeal to the typical human-on-the-street purchaser of this class of phone? Phone manufacturers are going to choose platforms that will help them sell the most phones, even for halo products. - easy to customize or extend. Not just by VHDL aces and Perl wizards, but by the average C/C++/Java programmer two years out of university. His boss is going to choose a platform that plays to his skills (or lack thereof). - support fast development. That young coder in the previous bullet is going to be under a LOT of time pressure. His boss is going to choose the platform that he feels will best help him meet schedule, and will see C++ and Java as enablers, VHDL and Perl as barriers. Shiny geek toys are cool, and I love them. But if we want to rule the world, they don't help that happen. Once we've achieved world domination, we can add all the sparkly bits to OpenMoko we want. Heck, people will probably be doing it for us. Chris ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/cgi-bin/mailman/listinfo/community ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
Shiny geek toy?
What exactly is it that we want OpenMoko to be? Do we really want a shiny geek toy? Something that is super cool and technologically advanced, but only nerds will want to hack on? Or should we be working toward a solid OpenSource platform that will encourage other phone manufacturers to build on it and in turn give their work back to the community? To take a recently discussed example: an FPGA is really super cool and flexible and you can do just about anything with one. But the downside is that it is HARD to do that stuff. Even if you, personally, find VHDL or Verilog to be easy to work with and understand, the average engineer working at someplace like Samsung or Nokia (or wherever) will not have the same skills you do. Additionally, it takes time (lots of time) even for skilled engineers to design, implement, and debug new features for FPGAs. Time to market is critical for most phone manufacturers, especially in countries such as Korea where product lifetimes are often measured in months. Yeah, we can trowel on all kinds of creamy technological goodness. Myself, I want a dozen A-to-D channels so that I can use the phone for data collection and analysis in my race car. Honest - that would absolutely rule! But it's not what the customer on the street wants, and it's not what the manufacturer trying to sell to that customer wants. To be a success, in the same way that OpenSource projects like OpenOffice, Apache, Firefox, and others are successes, OpenMoko will have to provide a compelling reason for phone manufacturers to choose it over closed source options such as WinCE, Rexx, and others. Five of the critical enablers to this are: - rock solid reliablity. Anything in the phone should "just work", and it must do it every time. - complete functionality. There should never, ever, be a greyed out button in the GUI. Sure OpenMoko might support four different kinds of software radio, but if the manufacturer has to do their own I18N to pick up OpenMoko, they'll choose WinCE instead. - desirable functionality. Does the functionality provided by OpenMoko appeal to the typical human-on-the-street purchaser of this class of phone? Phone manufacturers are going to choose platforms that will help them sell the most phones, even for halo products. - easy to customize or extend. Not just by VHDL aces and Perl wizards, but by the average C/C++/Java programmer two years out of university. His boss is going to choose a platform that plays to his skills (or lack thereof). - support fast development. That young coder in the previous bullet is going to be under a LOT of time pressure. His boss is going to choose the platform that he feels will best help him meet schedule, and will see C++ and Java as enablers, VHDL and Perl as barriers. Shiny geek toys are cool, and I love them. But if we want to rule the world, they don't help that happen. Once we've achieved world domination, we can add all the sparkly bits to OpenMoko we want. Heck, people will probably be doing it for us. Chris ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
