Re: Myth Busting FTW
On 8/31/07, Mike Hodson <[EMAIL PROTECTED]> wrote: > * Where on any official blogs/websites have you seen the OpenMoko team > or FIC say that they were making an "iPhone killer" or "anti-iPhone?" It looks like Apple have beaten FIC to the punch anyway: http://newsvote.bbc.co.uk/2/hi/technology/7017660.stm Give me a phone that isn't actively fighting against me, anyday! Richard ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Myth Busting FTW
Heh! It's an Apple fan site, so you can't expect any attempt at objectivity - as the forum following up the article shows: http://roughlydrafted.com/forum/comments.php?DiscussionID=290&page=1#Item_0 Given that Apple fans already have the phone of their dreams, it is quite the compliment that they should feel the need to devote such time, energy and FUD to attack their perceived 'rival'. As when Microsoft compared Linux with Communism - the more rabid the attack, the more insecurity lies beneath. Oh, and attacking the ideas wiki rather humourously misses the point ;-) Nuthin' to see here iThink... Richard On 8/28/07, Nkoli <[EMAIL PROTECTED]> wrote: > Somebody really has their knickers in a bunch. > http://www.roughlydrafted.com/RD/RDM.Tech.Q3.07/B10AE668-EAD3-46DC-A042-5EF3461D63EF.html > All that FUD is making me woozy @_@ > > ___ > 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: Neologics
On 3/7/07, Jon Phillips <[EMAIL PROTECTED]> wrote: This is interesting to see the larger ambitions of the project. It might also help to expand upon what types of devices could be constructed with this logic, in addition to neo1973. I'm thinking remotes, media players, watches, etc... What if you mated Elite with Yahoo Pipes - instead of RSS feeds, you have extensible data streams.. and instead of planets you have conceptual nodes. Instead of trade routes, by clicking on a node you can see and edit which data streams it imports and exports, and can be anything from a simple wrapper to the GPS device, to a user, an application or represent a physical device such as your desktop or Neo. Here's an early demo picture, although the lack of structure makes it look rather too complex at the moment: http://www.flickr.com/photos/[EMAIL PROTECTED]/413592619/ Instead of adding a security layer later, each node could have its own private/public key combo from birth, and would (by default) be authenticated by the node representing the physical device layer. The user node may use a third-party to authenticate themselves, which would allow them to travel between devices, or may choose to operate in a reduced security domain which allows local authentication - simply drag a new node from your 'parent' user-node, un-check the security domains you don't want it to access, and allow password authentication for that 'child' node. To set up communication between nodes, the device authentication layer would handle the swapping of public keys - transparently if requested between multiple physical devices, but the utility arises from this ability to dynamically create overlapping security domains (e.g. my work, friends, family, spouse, etc). I think I've failed in the description somewhat, as I'm still in the early-prototype stages - but I think it could provide access to conceptual and physical resources as simple building blocks, which is fundamental for emergence to flourish. Richard ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Neologics
I found the section on emergence/Neoforms _very_ interesting - I've recently been expanding upon this ( http://www.linuxtogo.org/gowiki/OpenMoko/Ideas/ConceptualFramework ) from which I've going down similar lines of thought - do you have more ideas about Neoforms? Richard On 3/1/07, Sean Moss-Pultz <[EMAIL PROTECTED]> wrote: Dear Community, For those of you who couldn't make it FOSDEM or Etel, I've posted our presentation here: http://www.openmoko.com/files/OpenMoko_Neologics.pdf Happy reading! -Sean ___ 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 is open
On 2/14/07, Piotr Duda <[EMAIL PROTECTED]> wrote: and so bugzilla: http://bugzilla.openmoko.org/ and also: svn co http://svn.openmoko.org/trunk trunk :-) Richard ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: Wiki is open
On 2/14/07, Tomasz Zielinski <[EMAIL PROTECTED]> wrote: It looks like http://wiki.openmoko.org is open to public :-) Neat! http://bugzilla.openmoko.org/ is now open too - should be enough info to chew upon for a while :-) Richard ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: OpenMoko / FIC Neo1973
On 2/5/07, denis <[EMAIL PROTECTED]> wrote: Hello! Yeah I know that. But don't you think it would be useful to offer interested users, that heart from others something about the phone, more easy to access content? Most of the official knowledge/content is already on the openmoko website and the wiki - the mailing list sometimes gets tidbits of information leaked onto it a bit earlier, however these are usually very-specific technical developer-orientated details. We may discuss ideas and possibilities on this mailing list, but it shouldn't be confused with concrete information which holds utility for the 'average' user/ As far as 'official' knowledge/content goes - that the 'average' consumer could use -the fact that there aren't spectacular/vaporware promises being made at this stage is somewhat encouraging to me :-) Richard ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: Hint for all webmail-user Re: Hint for gmail-users: How to mute a conversation
I do not think that we should encourage or advocate considerate subscribers to leave, due to the actions of inconsiderate users. Richard On 1/28/07, Declan Naughton <[EMAIL PROTECTED]> wrote: You can also unsubscribe from the list @ https://lists.openmoko.org/mailman/listinfo/community :) Other lists: https://lists.openmoko.org/mailman/listinfo/ On 1/28/07, Robert Michel <[EMAIL PROTECTED]> wrote: > Salve Sencer,*! > > > First I thought your tipp would be to avoid >100 lines of quote by > using a webmailer > > > > To avoid that non gmail-users thing that mailing with gmail is more > comfortable/better than with a normal emailclient my tipp: > > On Sun, 28 Jan 2007, Sencer wrote: > > > Hello fellow openmoko users, > > > > For all gmail-users there is an easy way to deal with the threads that > > just won't die. > > Well when you use a normal (good) MUA (Mail user agent) it will thread > your mails. When you have a filter, that all mails from this mailinglist > came into jut one openmoko-community mailinglist it feels not like mail- > flood anymore. > > So with such a > - separate mailbox > - MUA (mail client) that organize mail as threads > I've no problem with "thread that just won't die". > > And when you want to access the mails of this list flexible - I use > the non-GUI MUA mutt, together with GNU-Tool screen and ssh on a > virtual server I rent for 3 Euro/month (1GB space, 1 Domain, unlimited traffic) > Feel free to ask me in PM (private mail) about this - I dislike > spreading popularity of big companies services like skype, > hotmail/gmail (doing money with analysing mails and personal networks) > > Greetings, > rob > > ___ > OpenMoko community mailing list > community@lists.openmoko.org > https://lists.openmoko.org/mailman/listinfo/community > -- Declan Naughton ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: OMG wiki license
On 1/27/07, Jon Phillips <[EMAIL PROTECTED]> wrote: > I don't see a legal case being made out of this. Right, but better to protect ourselves. Also, companies, like FIC/OpenMoko have to take every precaution. So, if we want our content included, we need to be cautious as well. Agreed - but I think the risk here is so minimal, that we can decide upon a license and push the deadline back one week, which would give contributors a chance to add the new license to their own pages. Pros: * We may get revised/improved/edited content by increasing the number of people involved. * Intent or nuance will not be accidentally changed. I also thought about going through and deleting a page, putting a GNU FDL 1.2 statement at the top of the page, and then summarizing/redoing the old content. This way, any future contributions are protected. Cool? Yet again, I propose we do this at 11:59 PM PST SAT JAN 27 so we can knock this out. What do you think? Unless we have any parties - FIC, individual contributors or editors - who feel that extending that deadline by one week would be putting them under additional risk, then I'd say +1 week is an appropriate response to a pragmatic estimate of the extreme unlikelihood of the occurrence or significance of the threat. Richard ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: GNU discussion
On 1/28/07, Corey <[EMAIL PROTECTED]> wrote: BSDL contains an inherent self-destruct gene, GPL contains a built-in propagation gene. And Non-Free Software contains a built-in propagation gene which cannot evolve its medium (technology) as quickly as the license-gene for Free Software can. But evolution requires competition, and this is why I think the relationship between free and non-free software is becoming increasingly sybiotic - when private companies do something which benefit themselves and improve the quality of Free Software - it's a win/win for Freedom and Technology. Richard ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: GNU discussion
On 1/27/07, David Schlesinger <[EMAIL PROTECTED]> wrote: More importantly (and very relevantly to this list) you can't compete for consumers on a basis of "Not as good, but _more free_." If completely open phones are going to achieve any sort of dominance, then the same kind of work will have to go into project to support the capabilities that consumers want. Exactly - the one bonus that OpenMoko receives, in addition to the number of developers, is that we're not tied to any Corporate restrictions in design, contract or politically restricted technology - new software features 'saved up' for the next marketing phase. More likely, this will prompt other phone manufacturers to try to find ways to compete with the iPhone in as reasonable a time as possible. Some of those ways will likely be based on Linux, and will likely wind up being a mix of proprietary and open source software, but the net outcome will be that there will be a larger amount of more capable open source software available in the product space, and more open source software being used in more devices like the NEO. In evolutionary terms, this is a favourable environment for open vs closed software models. All free software written on open or selectively open hardware platforms, strengthens free software. Richard ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: GNU discussion
On 1/27/07, Renaissance Man <[EMAIL PROTECTED]> wrote: Well you managed to miss the point of my *metaphor* (not straw man), even though I spelt it out for you: "The point is real "freedom" is measured on a "whole picture" basis, not on an individual basis." A metaphor is simply a linguistic model, a blunt attempt to predict the countless variables which interact and effect the universe at different layers, from quantum to molecular to planetary. Emergence results from simple interactions, e.g: http://www.flickr.com/photos/[EMAIL PROTECTED]/370487910/ As you point out, with Apple taking BSD software and 'competing against BSD', the market share for vanilla BSD is reduced. You can't however know whether in the medium-long term this is an 'overall good' which sped up Freedom through other interactions in the future or an overall bad. Apple geeks may migrate more easily to vanilla BSD because they are exposed to the standard terminal, and are frustrated at the limitations they find. Maybe it could have benefited Linux in the same way if Apple was granted the Freedom to make its modifications to that code-base? I don't know. Neither do you. If either of us could predict the future we'd be more likely to be down the bookies. Or somesuch. It's okay to have opinions, but unless you actually can see into the future, and have amassed evidence to that end.. then you're claiming the role of prophet, whilst wearing the cloak of the economist/philosopher. The bottom line is that thinking things in simple terms such as "all non-free software is bad" is not historically valid.. and certainly not the logical conclusion to draw simply from the belief that "free software is great!". With OpenMoko we have the chance to add another brick to the wall of evidence showing the benefits of free software.. we don't need to try to knock down the wall of evidence showing benefits from closed-software - we'll dwarf that evidence in the end - real change requires real work - words are cheap.. and none cheaper than knocking something else down rather than building something of your own. So let's build :-) Richard ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: OMG wiki license
I think this is all a bit overkill. I don't see any license other than the description "this mailing list is for open discussion and feedback", for this mailing list.. yet these potentially copyrightable messages are mirrored by openmoko.com, gmane, etc. Why isn't everyone being sued? In our case, the source was either: a) An intentional email sent without copyright notice, to a membership-unknown public mailing list, with full knowledge that it would be stored and made freely available. b) An intentional edit made to a freely accessible public wiki. I don't see a legal case being made out of this. However, if a legal case could be made then linuxtogo are already liable as they have already published copyrighted material? http://en.wikipedia.org/wiki/Wikipedia:Copyrights#Using_copyrighted_work_from_others "Note that copyright law governs the creative expression of ideas, not the ideas or information themselves. Therefore, it is legal to read an encyclopedia article or other work, reformulate the concepts in your own words, and submit it to Wikipedia. However, it would still be unethical (but not illegal) to do so without citing the original as a reference." Why don't we take a snapshot of the current wiki, and reword the content into a new licensed wiki? It's less work than doing everything all over again, we lose no contributions, and it's an opportunity to reorganise a bit. I'll volunteer to do a chunk of that work if we go that route. Richard On 1/27/07, David Schlesinger <[EMAIL PROTECTED]> wrote: On 1/27/07 3:26 AM, "Jon Phillips" <[EMAIL PROTECTED]> wrote: > On Thu, 2007-01-25 at 16:21 +0100, Harald Welte wrote: >> On Thu, Jan 25, 2007 at 07:29:47AM -0500, Richard Franks wrote: >>> then there is no copyright issue as the contributors have implicitly >>> put their words into the public domain? > > This is not true and for sure in the US, where the instant someone > contributes, their contribution is governed under copyright. Correct. You can't "implicitly" put anything into the public domain under US copyright law: you'd have to make a specific and concrete declaration to do so, or (more usually) simply wait for the copyright on it to expire... If you're interesting in folding all the Wiki content under the FDL, and you want to avoid running afoul of potential copyright entanglements, you're going to have to start over from scratch, I believe. You're also going to need to have each participant explicitly agree (probably when their account is created) to get explicit agreement that they abandon any interests they hold in any content they create on the site and assign copyright to such content to "The OpenMoko Project" or whatever. You might well also want a statement to the effect that any content they submit must not be derivative of material held under copyright elsewhere and be free of other encumbrances, etc., etc... This could get complicated, see...? ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: Unified Profile Management
> Example. Instead of a calendar app just muting the phone when in a > meeting (nice feature) it would activate a profile (maybe "silent" or > "meeting"). Other apps could also use those profiles. For instance a > GPS location aware app could know to use the same "silent" or "meeting" > profile when you were at movies, church (or anywhere you wouldn't want > your phone to ring). We have the opportunity to re-think 'profiles', they do have their limitations! > Not only will this make for a MUCH better user experience (less > redundant work). It will GREATLY speed up application development (no > complex interface for "what to do" just a single simple dropdown "what > profile" for this action/trigger). I'm thinking of something mostly transparent to the end-user, which has the same benefits you list.. I may finally make some time to get this off the drawing board this weekend :-) http://www.linuxtogo.org/gowiki/OpenMoko/Ideas/ConceptualFramework Richard ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: OMG wiki license
IANAL (or a hobby lawyer!) but I think if someone has contributed to the unofficial wiki without checking for a license, and without specifying their own license... then there is no copyright issue as the contributors have implicitly put their words into the public domain? At least, I think it would be very hard to make a problematic legal case from this. Richard On 1/25/07, Aloril <[EMAIL PROTECTED]> wrote: As subject implies I have proposal I fear might lead to long flamewar. I hope I'm wrong. Given these assumptions/facts: 1) We want to copy stuff from unofficial wiki to official wiki when it becomes available. 2) Unofficial wiki doesn't have any copyright statement 1) looks legally problematic given 2) Proposal: 1) Anybody who has contributed more than few lines to unofficial wiki gives permission to copy their contribution to official wiki no matter what license official wiki will use. 2) Statement like "You allow your contribution to be copied to official wiki under license official wiki will be using." is added to unofficial wiki when user is editing page. -- Aloril <[EMAIL PROTECTED]> ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: Ready For Prime Time?
On 1/24/07, Duncan Hudson <[EMAIL PROTECTED]> wrote: What about the multi-point touch screen? It's wonderful, but doesn't Apple have a patent on that? I would have thought that whoever owns copyrights for Star Trek should win prior art for multitouch - the software UI for the transporter console had that back in the 60s! Richard ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: How to get involved (HELP!!!)
On Wed, 2007-01-24 at 22:58 +0100, Marc Verwerft wrote: > Jonathan, > > Probably, you're on your own right now. If I were you, I wouldn't make > a sourceforge project yet as in the announcement of Sean he mentioned > this: > * http://projects.openmoko.org/ -- for user-contributed projects <--- > That's what you want, I guess. I don't think it would cause any harm - repositories are easy to move, especially for the limited scope of pre-hardware apps. I'd certainly be interested in taking a look at any project, and I would have put something on sourceforge already if my project ideas had any functionality yet ;-) Richard ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: When Good Agendas Turn Bad - Linux/GNU, etc
On Wed, 2007-01-24 at 19:59 +, Declan Naughton wrote: > "Threat to unregister" I never knew you considered me to be such a > valuable asset. I posted pretty much exclusively to the GNU/Linux or > Linux related threads. The point of a community is that everyone has something to contribute. > Whenever I registered I did think freedom discussion would be on the > agenda, and valued, but if it explicitly isn't, that's exactly > opposite to what I was expecting. "Free Your Phone!", "OpenMoko" - Freedom is the foundation to this project.. and as this kicks off it is going to be invaluable to have opinions from people who care this much about Freedom to help keep the balance. Technology when abused decreases Freedom after all. > I would not really be unregistering > in protest, but believe what you want. Then I choose to believe you - apologies for jumping off the wrong side of ambiguity. > "an issue the community can solve itself" I think if the project's > father/s projected their views, what they intended when they began the > project, people who may have gotten the wrong idea can leave if they > wish. "No particular scope" would be my personal guess. However you wouldn't show up at a Linux Users Group meeting, and keep interrupting by yelling "Windows Sucks!" every five minutes - and I think this is somewhat similar - I may agree with you, but the disruption caused is overshadowing the technology. I think we can be stronger if we pool our energy - in terms of Freedom, the Neo1973 is breaking new ground - the computer you carry in your pocket will grow to become your main interface to the electronic world - the frameworks we create now will eventually define this era of computing. If we were to lose the FSF perspective at any stage down the road, then we could end up only able to buy highly sophisticated yet crippled devices which actively impose upon our Freedoms. Like now, but worse. In that sense, I imagine the Neo1973 as a platform which furthers the aims of the FSF through its success.. and retains its integrity through that symbiotic relationship. So although I'd rather we didn't have hundreds of posts saying pretty much the same thing again and again... linking repeatedly to the FSF website for reference.. if accepting this silently is the only way to retain your input, then fine :-) Richard ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: When Good Agendas Turn Bad - Linux/GNU, etc
On Wed, 2007-01-24 at 19:08 +, Declan Naughton wrote: > > The "Free Your Phone" post was perhaps the most interesting announcement > > we've had yet - Sean thinks we're going to be building the foundation > > for Ubiquitous Computing - I think he's right, but this positive message > > was completely overshadowed by an external Agenda and childish > > bickering. > > > When I hear from Sean that freedom discussions are offtopic, I'll > gladly unregister. I got the idea that freedom WOULD be on OUR agenda > - not only mine and a good couple of others. If that was ill informed, > I apologise and I will be out. > > Thanks for letting me know, though. "The side who care about their personal Agenda foremost, and will take any and every opportunity to present their personal Agenda. Even if it means misunderstanding or twisting nuance - because, very simply.. the more we talk about it.. the more free advertising the Agenda gets." I did not state that anything was off-topic - use your own judgment. However - this and the threat to unregister if you are asked to stop pushing your Agenda is a simple case of you escalating the issue to draw more attention to your Agenda. Similarly, in light of the threat to unregister, an attempt to invoke Sean to step in to settle an issue the community can solve itself, is another escalation. Or are you saying in other words that you are going to continue pushing your Agenda at the expense of the community, until explicitly requested not to, by the list-owner.. at which point your interest in the technology will magically disappear and you'll unregister, just because you didn't get your own way? This is what I meant by "schoolyard politics". Richard ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: When Good Agendas Turn Bad - Linux/GNU, etc
On Wed, 2007-01-24 at 18:19 +, Declan Naughton wrote: > On 1/24/07, Richard Franks <[EMAIL PROTECTED]> wrote: > > How about we let our Agenda be the cool technology and innovation > > instead? > > So freedom has nothing to do with it? > > I wouldn't be too surprised. I read some nice stuff from Sean alright, > but IF you just wrote an apt description of "our Agenda", it would > seem, as isn't unusual, that freedom is offered only such that it > helps towards "cool technology and innovation". At that, naturally, > this wouldn't be a great place to suggest using GNU/Linux instead of > Linux (and I for one wouldn't be too slow to drop it :) . I have my own opinions about freedom, which I'd be more than happy to engage in via personal email. But I didn't join this list to talk about freedom, I joined this list to talk about interesting technology and innovation. Your Agenda is as relevant in this context, as a discussion about gay marriage, religion or abortion. Signal or Noise - it's your choice. If this were a community designed for debating "Freedom according to the FSF", then all would be good.. but I see this continual Agenda pushing as destructive to the community. The "Free Your Phone" post was perhaps the most interesting announcement we've had yet - Sean thinks we're going to be building the foundation for Ubiquitous Computing - I think he's right, but this positive message was completely overshadowed by an external Agenda and childish bickering. Richard ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: Neo1973: Mobile Phone or Mobile Computer?
On Wed, 2007-01-24 at 18:16 +, Al Johnson wrote: > Getting a flash-capable browser will be another problem entirely... I wondered about that before posting, but I found this link, so it looks like options may be available.. although I gather the standard approach is to have the manufacturer negotiate the license with Macromedia: http://board.flashkit.com/board/archive/index.php/f-62.html But I think the bigger issue may be if mobile phones are subjected to different legislation than your regular PC - I can see the major phone manufacturers lobbying this point of view to protect and lock-in their market shares. Richard ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: Idea for OpenMoko: Kid Mode
On Wed, 2007-01-24 at 11:33 -0600, Paul Jimenez wrote: > How about a locked-down 'kid version' of the UI with touchable pictures for > 'mommy', 'daddy', etc ? Maybe not even labelled, but just the pictures? Nice idea - I see where you're going with this, not making it too complex.. for slightly older kids though, you could also have an "add friend" button too, perhaps triggering auto-detection via bluetooth. Or games which only work at scheduled breaks during the school day. Most calculator applications I've seen on mobiles really suck.. but that could be an area of improvement too. Also, the back-end would not have to be locked down - parents could still connect to their kids Neo and get whatever information they feel they need. I'm not sure I'd want to write code to allow parents to eavesdrop on their kids, but it'd be easy to do once we start networking our Neo's to home/work machines and that infrastructure is solid. Schools themselves may find it appealing to be able to restrict cell-phone use during class, and with bluetooth, there's another option to distribute homework other than email or paper.. and with the stylus the kid could do their homework (whilst showing the working), on the bus ride home. Richard ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Neo1973: Mobile Phone or Mobile Computer?
The distinction may become more relevant if you get hit with a cease and desist - "YouTube has blocked a small company from making YouTube videos available on mobile phones": http://www.theregister.co.uk/2007/01/23/youtube_blocks_mobile_video_encoder/ If we have a browser with Flash support capable of displaying YouTube video, and then run it on the Neo.. are we suddenly going to have to worry about litigation such as this company did? "We were informed by YT their action was largely due to pressure from their new mobile partner, Verizon." Richard ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
When Good Agendas Turn Bad - Linux/GNU, etc
On 1/24/07 6:11 AM, "Dave Crossland" wrote: > Hi Sean, > > On 23/01/07, David Ford wrote: >> You must be reading a different link. Sean's email most clearly states >> "in the form of a user's manual that will give credit to GNU." He also >> clearly stated "We'll just call it OpenMoko." > > Could you confirm that if FIC writes that OpenMoko is based on a > popular free software operating system, that will be described as > "GNU/Linux" instead of "Linux"? Well come now, you made enough noise and then forced a direct response out of possibly the busiest person involved in this project.. and because someone else yanks your chain, you hit back with an even bigger demand. Cripes. There are three sides to this discussion: 1) The side who care about their personal Agenda foremost, and will take any and every opportunity to present their personal Agenda. Even if it means misunderstanding or twisting nuance - because, very simply.. the more we talk about it.. the more free advertising the Agenda gets. 2) The side which thinks that logic or reasoning or well-thought out debate will change anything - it won't - your words will be mangled into something which gives side #1 another opportunity to repeat EXACTLY THE SAME THING AGAIN AND AGAIN (their Agenda), without risking accusations of spamming blatantly. 3) The side which thinks that this bickering and ill-feeling generated risks fragmenting our community, makes it harder for genuine questions to be answered, associates OpenMoko with school-yard politics, and altogether sets a rather bleak precedent. Sides #1 and #2 are equally responsible in this scenario. How about we let our Agenda be the cool technology and innovation instead? Richard ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: Idea: Desktop wakeup on user proximity
On 1/23/07, David Ford <[EMAIL PROTECTED]> wrote: Actually this idea is already in use. Set up your Bluetooth to lock/unlock your desktop when you are in the vicinity of it etc. :) Ha! I thought it sounded a bit too obvious. We get to enchance the idea with GPS though.. hmm - two new uses: 1) GPS location looks like I'm a few minutes from the office on a workday - start coffee machine through a relay. 2) Need Insurance $$$ - start coffee machine through a relay, repeat Richard Richard Franks wrote: > So when I walk into my office in the morning my computer wakes the > monitor and logs in, opens up a browser with slashdot, etc. > > So when I walk towards my house at night, my computer is already cuing > up some music for me. > > Detection could be via GPS/data connection, but in many workplaces, > bluetooth detection could be sufficient, plus your Neo only needs to > start up bluetooth when it already knows that it is close to an > activation spot. > > Richard > > ___ > OpenMoko community mailing list > community@lists.openmoko.org > https://lists.openmoko.org/mailman/listinfo/community > ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Idea: Desktop wakeup on user proximity
So when I walk into my office in the morning my computer wakes the monitor and logs in, opens up a browser with slashdot, etc. So when I walk towards my house at night, my computer is already cuing up some music for me. Detection could be via GPS/data connection, but in many workplaces, bluetooth detection could be sufficient, plus your Neo only needs to start up bluetooth when it already knows that it is close to an activation spot. Richard ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
OpenMoko-ID
Will we have something like this? Do we want something like this? It could be useful for contact-sharing, authentication, access to services on the OpenMoko site, keeping track of gaming friends, referencing file/data resources on the users home 'or otherwise' machine etc. Richard ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: an idea: GPS blog?
On 1/23/07, Dean Collins <[EMAIL PROTECTED]> wrote: The big problem with a lot of these applications being suggested is it will require back end servers to store the data. I'm yet to see anyone suggest "SAAS" pricing models for FIC applications on a monthly/annual basis or is everyone on this list still thinking that open source means free. I'm not discounting this, but I'll be opening up a port or two on my firewall first - most home-use router/gateway boxes support port forwarding quite easily now - and with something like xampp, even most windows-based folks can set up a database server on their home machine quite easily too. To connect the 'home-servers' together, you could use dynamic dns or a centralised server which takes a known OpenMoko-ID and spits back the current IP/Port and/or operational status. Richard ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: an idea: GPS blog?
On 1/23/07, Oleg L. Sverdlov <[EMAIL PROTECTED]> wrote: Videoblogging has its niche, but how about a small application that remembers where you've been during a day , and how long; and then visualizes everything in form of nice coloured curves, and publishes to your blog? I'm definitely looking forward to something like this. What I'd find useful is something which uploads the GPS traces to my home machine database, then makes that data available to other sources through access control. 1) So I can select an area downtown, and see my most (or least) favourite places or travelled routes through it for the time period of my choice. 2) If I'm going to a planned meeting with a Neo-Owning-Friend (NOF?), the Neo could check my agenda and automatically enable Location-Sharing until we find each other. Actually, as there are a bunch of GPS Google API mashups out there already - if the Neo can run Google Maps then it will be quite easy to integrate access control, editing, uploading (to home/openstreetmap/etc), quering home machine DB, all into the same webapp. Richard ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Buttons
There seems to be a bit of confusion about the references to "2 additional buttons", and how they may be used. 1) Are they simple microswitches, or something else? 2) Will they have hard-wired functionality? 3) Does OpenMoko have standardised usage models for them - e.g. power/profile selection? 4) Where are they positioned upon the phone? These factors seem to affect whether applications or games can use/remap one or both of these buttons for their own purposes! Richard ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: built-in scripting languages
On 1/22/07, Derek Pressnall <[EMAIL PROTECTED]> wrote: On a different (but related) track, I've always wanted to have a web browser that was capable of executing local cgi scripts without the need for client-side http server. Pah! Internet Explorer has had that for *ages*. But for non-windows, this might come a closer depending upon your need: http://code.google.com/webtoolkit/ As your server-side java classes can be shared with a client-side java app. Richard ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: GNU discussion (was re:Free your phone)
On 1/22/07, David Schlesinger <[EMAIL PROTECTED]> wrote: It simply never ends, does it? One can hope :-) Next time I get another argument on this subject in my inbox, I'm going to simply email this back-to-sender, not the entire list: http://www.linuxtogo.org/gowiki/OpenMoko/Debate-GNU-Linux Thus hopefully, we can get back to the fun and interesting stuff! Of course, it may be vandalised, or 'improved' upon, but I'm also not going to touch that page again, so go ahead! Richard ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: WiFi
On 1/21/07, David Schlesinger <[EMAIL PROTECTED]> wrote: >What is the rationale behind the exclusion of WiFi? The long and short of it is that there's no sufficiently low-power WiFi chip available which has an open driver, or at least there wasn't when the hardware design got nailed down. It's too late in the process to add one now, but maybe in some future version of the hardware. (Whereby we illustrate the need for an FAQ, if only to answer this specific question...=D) Done: http://www.linuxtogo.org/gowiki/OpenMoko/QuestionsAndAnswers Richard ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: Free Your Phone
On 1/20/07, Renaissance Man <[EMAIL PROTECTED]> wrote: And the more people who are aware of Free Software (as opposed to simply open source software) and its significance, the more likely Free Software will prevail and people will continue to benefit from it. I agree, and I agree that this would generally be A Good Thing. But I think it that it would make the Neo just a little bit harder to market - if a potential customer is asking themselves "What does a GNU do?" rather than reading the feature-list, then this is A Bad Thing. I care about the technology first, the more popular the platform - the quicker Open Source technology progresses. My reasoning is that simple. Although I support the goals of the FSF, I hold progress ahead of my political philosophy. Richard ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: Free Your Phone
On 1/20/07, Dave Crossland <[EMAIL PROTECTED]> wrote: I was requesting that FIC's full title for the system replaces "Linux" with "GNU/Linux" for the good and clear reasons that we are familiar with, if it includes that name at all. "Linux" as a marketing phrase is very well-established, "GNU/Linux" may be the 'correct' term, but it's not as marketable by a *very* long shot: http://www.google.com/trends?q=linux,+gnu+linux,+gnu/linux&date=all&geo=all&ctab=0&sa=N Changing the system title to include GNU/Linux, would increase public awareness of GNU, but I don't see how it would directly improve the technology or how it would sell more Neo's, and thus it feels more like agenda-pushing. Richard PS. Are there people who actually say GNU/Linux in conversation and/or correct themselves if they forget the GNU part? ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: is google.com down?
On 1/18/07, Bryan Fink <[EMAIL PROTECTED]> wrote: > The community archives online are not easily searchable and not the > best way to get a definite answer. Gmane to the rescue! http://dir.gmane.org/gmane.comp.hardware.openmoko.general Nice! Thanks for the link! Richard ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: is google.com down?
On 1/18/07, Koen Kooi <[EMAIL PROTECTED]> wrote: Hi, It seems google.com is down, since a a great deal of topics posted to the list can be answered by spending 2 minutes google-ing. Please, do some research before wasting our time. If there was a central source for up-to-date information publicly available.. I think this would be a valid complaint. The community archives online are not easily searchable and not the best way to get a definite answer. Thus until we have a trusted resource for OpenMoko information, asking questions to the list is the natural solution for newcomers. As long as it's not about wifi ;-) Richard ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: Neither iPhone or OpenMoko are revolutionary
On 1/18/07, Renaissance Man <[EMAIL PROTECTED]> wrote: > P.S.: Thanks for finally realising that it is better if you drop > the debate about including wifi in the first generation device. Be > it whether the fundamental point people having been trying to make > to you, got through, or because you decided to move on to > cheerleading and trolling for some other revolutionary product. Hey, no problem. Sorry for being so inconvenient as to have a different view to start with. I know how awful it can be for people like you if others don't think the same way as you to begin with. You've won my vote for troll, too. On the upside though, I'm definitely interested in the possibilities of using VoIP with bluetooth for home/office, which I wasn't before this thread started - handy? Yes. Cost-effective? Yes. Revolutionary? Debatable, but let's not -- I'm upset that the Neo won't come with a bunch of magical time pixies who transmogrifiy new paradigms into productivity quanta.. but since I'll have to wait until v2.0 at least for that, there's no point complaining endlessly about the magical pixie-less v1.0! Richard ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: Wish for 2nd generation Neo: USB 2.0
On 1/18/07, Sven Neuhaus <[EMAIL PROTECTED]> wrote: While you're at it, please include some kind of hardware graphics acceleration to speed up video playback and maybe allow cooler games... I quite like the idea of the display being in system memory for games - quick pixel read times allow for cpu cycles and memory to be spent on more 'fun' endeavours. For certain types of game you waste more time trying to approach the read-speed of system-memory graphics. That said, if we're talking V2, upgraded memory/CPU+hardware graphics acceleration would please everyone! Richard ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: what is the difference between openMoko and windows mobile based phones
On 1/18/07, hank williams <[EMAIL PROTECTED]> wrote: I believe too many cooks spoil the stew, which is often a problem in open source, in my opinion. Its also often also a problem inside corporate development efforts. When there is no clear and absolute leadership, product design suffers. This is of course my opinion, based on my 30 years of software development. It is, nevertheless an opinion. Your mileage may vary. I see this being true for monolithic projects such as a kernel, or an office productivity suite.. I would say that it's debatable whether the same holds true for the types of micro-application which are going to be created using the OpenMoko API (which as a foundation does appear to have clear leadership). Monolithic product design I believe arose from distribution and OS layer limitations - when you simply couldn't download weekly updates or patches, the product had to get it right the first time. It didn't always happen that way of course, but there was no real alternative as the network infrastructure hadn't been built up yet. Communication accelerates standardisation, and standardisation paves the way for smaller tighter applications. Given the diversity of interests shown on this list, I don't think we'll run into the too-many-cooks issue any time soon. Out of interest, which Open Source projects have fallen victim to the too-many-cooks problem? Richard ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: what is the difference between openMoko and windows mobile based phones
On 1/18/07, hank williams <[EMAIL PROTECTED]> wrote: Now I am not saying open source isnt great. But from your *average* users perspective I would love to hear the advantages of the open source for these devices. Is this just a geek issue? It seems like most of the apps described on this list could be done with any of the windows mobile phones. I'd just love, for my own edification, to hear why this is wrong. I don't think it's simple enough to categorise neatly right now.. but think of it in terms of computer evolution - warehouse sized computers, mainframes, desktop, laptop.. the next stage of that evolution is a computer you can carry around in your pocket that does everything you want/need it to. Mobile phones have flirted with that category for a while now, but their closed nature - artificial limits placed upon development and software functionality - seriously impede their potential. So what I'm banking upon is that mysterious future potential that comes from fully realising the next stage of computer evolution, and being a small part of that coming revolution. You are right in that technically a windows mobile phone could run the same applications - the source will be open, after all... but that is then a game of catch-up and if some of the wacky ideas we've collected so far turns out to be extremely useful and more difficult for large companies to negotiate, administer and incorporate into their business models.. then Open platforms will gain market lead purely due to their agility. So right now it is a geek issue, which in my opinion will become a user issue when we start seeing the next generation of mobile applications. Richard ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: Neither iPhone or OpenMoko are revolutionary
On 1/17/07, Renaissance Man <[EMAIL PROTECTED]> wrote: The reason is neither of them have VoIP via WiFi. Who do I talk to ask them to include WiFi connectivity with the OpenMoko? I'll sell my body parts to get hold of such a device. Why does no organisation (even Apple) seem to get it that the mobile communications revolution is through VoIP via WiFi. This is the killer app. I disagree - VoIP via WiFi is an obvious evolution rather than revolutionary. I don't think it's a 'killer app' either - in the terms of the phone manufacturer who is more likely to benefit from getting 6-12months lead and market share in an unexploited but growing market (Open Source Mobile Phones). I think that market is going to be revolutionary, and we'll see the innovation occur upon the Neo1973 first simply because it's going to be the first of these new toys to play with. Look at the way that Linux patches come out faster and more efficiently than Windows patches do - this market situation will become increasingly bleak for the existing large phone manufacturers as their old business model won't be able to create and distribute new features or applications or games as quickly to their proprietary handsets. Think about how many geeks ever wanted to own and program their own Tricorder ;-) Wifi is going to be great, but the revolution will have already started upon an Open Source foundation by the time it comes. Richard ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: Gaming oportunities
On 1/17/07, Stuart Gray <[EMAIL PROTECTED]> wrote: As a games programming student I see alot of potential for games on the touchscreen phones. Although there are no buttons (or none we can really use for the games) Assuming that the placement of the two buttons is suitable.. unless they both have hard-wired functions, it should be possible to use at least one of them for an additional function (fire/select)? If so I'm not too concerned - worse case scenario, there are thousands of great games out there that just used up/down/left/right/fire.. best case scenario, we can write games like that _plus_ games which use the touchscreen in innovative ways! Richard ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: Gaming oportunities
On 1/16/07, Gabriel Ambuehl <[EMAIL PROTECTED]> wrote: Unless your game can be controlled with a touchscreen, you won't like it as gaming device. I've got a mockup I did for a Gravity Power port I've been putting off for too long: http://www.flickr.com/photos/[EMAIL PROTECTED]/359950380/ With a bigger input wheel for the stylus, I think this could work quite nicely. The darker coloured direction arc's are the deadzone, one phone button = fire- and I'd imagine it'll be relatively simple to make this resizeable/transparent/movable/skinnable. It's physically analagous to the old up/down/left/right/fire joysticks - in that you can't do up+down at the same time, but you can do up+right, etc. Richard ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: Non-gprs Internet access options without wifi (cel-dialup)
On 1/13/07, Rob <[EMAIL PROTECTED]> wrote: Anyhow, I've been thinking about it, and at 9600 baud or whatever it wouldn't be worth bothering with. I think what I'll do is build a little pocket sized battery powered usb hub with an attached usb 802.11 dongle. While I'm at it, I'll probably put an sd card reader and an extra usb port or two on it as well. It could be kept pretty small by custom building it in an altoids case or something. You're in Toronto too? I'd buy one! With regards the home dialup/modem/proxy idea.. I thought it should be possible to strip+optimise content (e.g. images sent rescaled) and thus reduce required bandwidth. Richard ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Apple iPhone
On 1/11/07, el jefe delito <[EMAIL PROTECTED]> wrote: On 1/11/07, Richard Franks <[EMAIL PROTECTED]> wrote: > In a year after release we will probably have two things: > 2) A Neo (released or in the works) which can provide all the 'eye > candy' decoration to those paradigms which we would ever need - So we shouldn't expect this hardware to be able to do the fun stuff? The qualifier was "assuming we run into graphical limitations in the first place." :-) The user manual does have some interesting clues as to what the performance *should* be: http://www.samsung.com/Products/Semiconductor/MobileSoC/ApplicationProcessor/ARM9Series/S3C2410/2410UserManual.pdf Although the S3C2410 is at the core of the Neo1973, until we start experimenting with the SoC and integrated components in hardware, I think we are in speculation land, based upon the premise "In theory there is no difference between theory and reality - in reality, there is." But I did a lot of optimisation for 8bit/16bit games as a kid, and as the Neo1973 is far more powerful than those platforms, I am confident we can find ways to exceed expectations which may arise from a simple comparison between the phone specs and modern desktop systems! Richard ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: suggested development toolkit for games?
On 1/10/07, Sven Neuhaus <[EMAIL PROTECTED]> wrote: Richard Franks wrote: > In terms of retro gaming though, it's the perfect platform for 2d games: Unfortunately, in the last 4 years of using a Sony Ericsson P800 phone I've learned that there're only a handful of decent games (genres) that can be played well without 5+ hardware buttons (two aren't enough). Unless it's because a hardware limitation on the touchscreen interface, I'd have to disagree. When I say retro, I'm thinking of all the Spectrum/Commodore 64/Amiga games which worked beautifully with five inputs - up/down/left/right/fire with a non-analogue joystick. A 64x64 (resizeable/semi-transparent?) directional input square (on bottom right or bottom left corner) should be big enough with a stylus to provide directional input, and fits into the joystick/joypad physical limitations. This also leaves the option of interpreting input as analogue, although the platforms mentioned above provided over a decade of excellent games with just those simple digital inputs. In fact, digital inputs makes multiplayer a *lot* easier - each game round can map the player input into only 5 bits.. which can be reduced with a 3 bit time-offset if the game allows for retroactive application of 'world transmittable' events - in most cases ~1/5 of a second is an acceptable maximum lag. If bandwidth is less of an issue then you can trade that off for more CPU cycles. Either way, there is a lot of development flexibility with only 5 digital inputs. I haven't looked into Bluetooth networking too much, but if it could be used for multiplayer games, then you've got a *very* attractive platform for gamers - upload games to friends for free + start playing. Fun still beats out the 'wow factor' - case in point: GTA on the PSP. If the digital input/stylus idea doesn't work, then there are still options: http://www.gamasutra.com/features/20050602/green_01.shtml http://www.rav.efbnet.com/1w1b2/results.html Richard ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Apple iPhone
On 1/10/07, Dave Crossland <[EMAIL PROTECTED]> wrote: On 10/01/07, Attila Csipa <[EMAIL PROTECTED]> wrote: > Conceptually very similar to the FIC1973, with of course the > added Apple candy and design team efforts. I wonder how the FIC1973's graphics capabilities will compare - all the slick XGL style swooshing around and zooming in makes the multitouch interface really 'wow!' Think of it this way though - we get the best of both worlds - a stable UI foundation means that we can prototype and build whatever swooshing interfaces we want in specific applications we want (e.g. one for mapping, a different one for IM), whilst still using more traditional widely understood metaphors for the day-to-day stuff like dialing. Things like 'point & click', 'copy & paste', 'trashcan', 'drag & drop' are now so obvious to us, that it's easy to forget how revolutionary these computing metaphors ever were -- the point is that the optimal metaphors do build upon their 'simple' ancestors.. and that isn't so much a property of your design team, but emergence/evolution. With OpenMoko, I believe we'll be able to leverage from these emergent forces precisely because it is (will be!) open and the UI does not lock us into highly speculative UI design pattern, which always have more potential to become an evolutionary dead end. In a year after release we will probably have two things: 1) Tried and tested new UI paradigms/metaphors. 2) A Neo (released or in the works) which can provide all the 'eye candy' decoration to those paradigms which we would ever need - assuming we run into graphical limitations in the first place. Richard ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: suggested development toolkit for games?
On 1/7/07, Andreas Jellinghaus <[EMAIL PROTECTED]> wrote:
I wrote a game in turbo pascal a decade or two ago.
if I wanted to rewrite it for openmoko, which toolkit
etc. would I use for the graphics and sound effects?
I'd use SDL if/when available, if not.. then there are plenty of
sound/image libraries to take away the pain of gfx/sfx IO. I'd be
surprised if the OpenMoko API did not have its own wrappers for this
anyway, as it's a common function for many applications.
In terms of retro gaming though, it's the perfect platform for 2d games:
* Hardware smooth scrolling support for vertical/horizontal..
* Screen memory held in main memory - very fast pixel read times :-)))
* extra DMA channels to play with
* multiple screen resolutions
* possibility of hacking display driver to optimise speed or create
interesting effects
* you can do a lot with only 4 directional + 1 fire button - lack of
keys not a killer issue
I'm thinking of it in terms as a rather powerful Commodore Amiga
(7.5Mhz vs 266Mhz) and ('blitter' chip vs 4 dma channels).
OpenWorkBench anyone? ;-)
Richard
___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: AGPS closed source drivers = DRM for public data
On 12/27/06, Marcus Bauer <[EMAIL PROTECTED]> wrote: Most likely this battle will be settled by Global Locate paying license fees to SiRF. [...snip...] communicate to GL that open specs are indeed a selling point. It seems a bit unreasonable to suggest that a company who are 'most likely' going to be forced over a barrel to pay license fees for their technology, then have the ability to simply ignore that and open up their source anyway. And I don't see that happening just because they were 'pushed a little bit' on a mailing list, but I do see that antagonism causing unnecessary conflict and hard feelings. I have a bit more patience on this matter because: 1) I believe that the OpenMoko team would love to see a 100% Open Source phone that pleases everybody. 2) I believe that there is a lot of information which cannot be shared publicly with the community due to NDAs or ongoing negotiations. 3) I believe that the FIC team have a strong product strategy for the future, which again, it would be foolish for them to disclose at this stage. 4) I believe that by attempting to second-guess that which we don't know, then standing upon that shaky foundation and attempting to apply pressure to companies who have a relationship with FIC, we risk more harm than potential reward. How about we give FIC a chance to deliver on their promises first? Richard ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: AGPS or: Global Locate's Marketing debunked
Did I miss something, or are tempers actually flaring here? It's a phone, folks. But let us not make things more difficult and ugly by being immature and throwing around phrases like "arrogant jerks", and antagonising the very companies working with FIC on this project in the first place. I don't see how that can be constructive. The airing of grievances has concluded, Happy Festivus! ;-) Richard ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: capacitor to call the police without battery and SIM card *g* Re: Fun with Stolen/Lost Phones..
On 12/15/06, Robert Michel <[EMAIL PROTECTED]> wrote: Did I alread mentioned the idea to have a capacitor parallel to the battery? So the Neo1973 cold call the police even without battery and the simcard and transmitt the coordinates of the phone. ***g*** (of course with black screen...) Well.. you could implement a virtual battery - say at 5% of the total battery charge, which could be reserved for 'emergency' type tasks. If the user chooses to explicitly override this (the option need not be obscured), then it's with the knowledge of the risks which entail. The more I think about the anti-theft ideas, the more I start to think that you can do certain things, like implement locks when the battery has been removed.. but for the serious thief, or one with access to the internet, if the battery is removable then there isn't much you can do. Now, if there was something like this guy: http://www.maxim-ic.com/getds.cfm?qv_pk=2917 Whereby, in hardware, the device would require activation for each uniquely coded battery - possible to do via USB/PC Client... then you might have the basis for an open security system, as the options boil down to: 1) Steal phone, keep battery in, no control over what the phone is doing, who it is talking to. 2) Steal phone, remove battery, unable to get over hardware lock upon reinsertion of even the same battery.. as the volitile ram holding the bootstrap code has not been filled via the USB authentication yet. Along with encrypted filesystems, this could become a very secure device, as in your handset may be stolen, but your private data can't. I don't think we can do any better, short of keeping the handset locked up in a safe. Richard ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Killer Application
I think it's vital to be able to fiddle with a system, but especially in Windows applications, the UI design often seems to represent the features which the developer wants to show off the most, rather than being directed by how a user interacts with a system. There is a misconception that you develop a UI for either Geeks or Grandmothers, but not both at the same time. But reformulated, does this not simply state that UI design is still an infant science? Think of it like the VHS vs Betamax 'war', and how many people care about this now we have downloads and dvds? Yet we have the opportunity to take the best UI design elements from *anywhere*, we're not stuck upon one format... Usability and Configurability won't be mutually exclusive concepts forever -- the Neo1973 is looking like a great platform to start solving this problem with. Richard On 12/18/06, Terrence Barr - Evangelist, Java Mobile & Embedded Community <[EMAIL PROTECTED]> wrote: Gabriel, Sorry, but I can't leave this undisputed. I agree there is definitely a line at which a UI is so dumbed-down that it is inflexible and doesn't accommodate anything but the most basic operations. That is the case for many "consumer" applications (including some of the Apple i* apps). The audience for those applications is very specific and if one needs more feature-richs apps you can simply install something better. However, the case of "stubborn, lowest common denominator" can certainly *not* be made for OS X. Have you actually ever used OS X? I am a computer engineer and I do *everything* on my Mac, including hard-core engineering work. Over the last 15 years I've used most versions Windows, various flavors of UNIX, and various embedded OSes. I find that OS X gives me by far the greatest productivity of all systems pretty much regardless of the task. And at the end of the day that is what counts for me, not the degree to which I can *fiddle* with a system. Just wanted to set that straight (and get that flame-war started ;-) -- Terrence Gabriel Ambuehl wrote: > On Friday 15 December 2006 19:53, Richard Franks wrote: >> Apple doesn't have 'killer applications' as such, but each application >> which comes close draws upon a consistent coherent interface - the >> 'just works' philosophy. I'd say this is even more crucial for a >> mobile phone as you have less opportunity to 'fix' things without >> ready access to a keyboard. > > Not meaning to start a flamewar, but if your idea of just works is the same as > the one on OSX, i.e only the lowest common denominator features with a GUI > that allows one way to do it and one only (i.e. very stubborn) then I'll > gladly pass on OpenMoko. The one reason I'm not using OSX is exactly the fact > that it wont allow me to chose how I want to work... > > We have enough dumb phones (even most so called smart phones), why not make a > smart one for a change... > > > > > ___ > 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: Idea: Optimal noisy vibrator
If it's anything like this: http://www.mpja.com/category/DC__Motors/6mm_CELL_PHONE_VIBRATOR_MOTOR_16053_MD.asp then it could be possible to monitor any current generated from the DC motor as a result of the phone being moved (along certain axis'). Richard ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: capacitor to call the police without battery and SIM card *g* Re: Fun with Stolen/Lost Phones..
On Fri, 2006-12-15 at 21:00 +0100, Koen Kooi wrote: > A phone that sends an sms to itself every week, how is that going to stop a > thief that has > my phone + simcard? Hmm. You are absolutely correct - security through obscurity + sneaky tricks aren't going to work medium-long term. Imagine you wanted to steal my Neo, how could I stop you from using it? Does the bootloader reside in SDRam or flash or somewhere else? In other words, how hard would it be for someone who knows what they are doing to use a backdoor, to bypass all our userspace security fun? Richard ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Killer Application (was: a lot of things)
Salve Rob! On 12/15/06, Robert Michel <[EMAIL PROTECTED]> wrote: And who think know - "nice" - but this will no "killer application for a phone" does still haven't understood that beside good core phone function there will be no single "killer application" for a smartphone. smartphone = mobil PC + GSM/GPRS In my eyes is the "killer function" of OpenMoko/Neo1973 that nearly everything that you could do with a PC will be possible to do with this smartphone. Apple doesn't have 'killer applications' as such, but each application which comes close draws upon a consistent coherent interface - the 'just works' philosophy. I'd say this is even more crucial for a mobile phone as you have less opportunity to 'fix' things without ready access to a keyboard. Unfortunately, all the major brands have the 'just works' thing already, by tightly controlling which software can or can't run on a particular phone. I'd imagine this will cause headaches for the OpenMoko maintainers - do you allow a potentially 'killer' application onto the feed, even if it doesn't play as nice with the rest of the system as it could? I really can't wait to see how this is addressed in OpenMoko! Richard ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GPLv3 and Mobile Phones
On 12/15/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: "For dessert I'd like the apple pie with no whipped cream" "I'm sorry sir, we're all out of whipped cream" "Very well. I'll have it without ice cream" [ Error whilst processing directive: 000816 ] ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Idea: datatransmission using ultrasound
On Fri, 2006-12-15 at 16:08 +, Ole Tange wrote: > Apparently the Neo may be capable of transmitting ultrasound (20 KHz - > around 45 KHz). If the Neo is also capable of receiving this (using > the microphone) then we should be able to transmit data that way. This > may be useful for close range network (e.g. transmit business card). > > The protocol will be similar to wireless ethernet. The range will be > similar to Bluetooth. It's definitely a neat idea :-) My concern though, is that the exact frequency coming out of the Neo is determined by the physical properties of the individual handset - e.g. if the speakers are positioned slightly differently as an artifact of the manufacturing process.. this could affect the range/pitch which is measurable externally. It's possible that a Neo could calibrate itself by simultaneously sampling the pitch it is outputting.. but then you have to factor in other unknowns like internal resonance, or whether the microphone will register the pitch at different levels depending on the source orientation. I don't know enough about audio engineering to say whether these are relevant factors or not.. but until we are able to start testing these things out with production models or an audiologist chimes in.. I'm more cautious than excited about this possibility. Even if we did have bluetooth, I still think there would be room for this idea if it works. Richard ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GPLv3 and Mobile Phones
On 12/15/06, Koen Kooi <[EMAIL PROTECTED]> wrote: This mailinglist and #openmoko, but I was protesting against presenting things as actual facts, when things aren't sure. Dragging this back on-topic, you bring up an interesting example. Creating an ethic such as "information should be free", and then following it to the letter, isn't always the most positive course of action. Like giving someone a Christmas present, but telling them what it is before they unwrap ;-) But ethics are easier to follow than thoughtfully considering each circumstance individually, which is my main beef with the arguments way above. Richard ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GPLv3 and Mobile Phones
On 12/15/06, Koen Kooi <[EMAIL PROTECTED]> wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Oleg Gusev schreef: > I think any reasonable person understands that wifi/BT was left out Bluetooth left out? That's not what I heard. Really!? Cool! Where did you not hear it? Richard ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Something like a Wiki
On 12/14/06, Alessandro Iurlano <[EMAIL PROTECTED]> wrote: I was just thinking about the lack of a wiki at the actual moment and the waste of thoughts and energy that will go lost because nobody will probably look at all the archived mails in the list again. On the other hand, the list as it is forms the perfect evolutionary ground for ideas - only those ideas with obvious fitness will keep getting talked about.. the weaker ideas fall into obscurity where they belong. If a good idea appears weak, then it's up to the individual to reshape it until it quacks and walks like a good idea. If the individual can't reshape it until it looks good, then it probably isn't a great idea anyway. As FIC have someone scouring the list for ideas, the chances are even slimmer that geniunely good ideas with bad presentation will be lost. A wiki would be nice just now, but as the community knows very few details for certain, we'd probably fill it with facts which aren't completely correct.. which in of itself defeats the point of a wiki, and increases the workload for FIC wrt corrections. I do have the suspicion that FIC didn't expect the level of community interaction it received ~two months before release, if that's true, then they've done a great job with the limited time available! Richard ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GPLv3 and Mobile Phones
On 12/10/06, Dave Crossland <[EMAIL PROTECTED]> wrote: (I also am sad to see a very logical and well reasoned position being smeared as 'religious' all the time, but I'm about to go on holiday and will reply to all that in January :-) I think I hold the dubious honour of first using the word 'religious' in this debate, so let me say that it wasn't intended as a smear, but a simple observation that a philosophy which contains absolute ethics which are subjective and not drawn from social consensus, which seek to place their invented limitations on what individuals can or can't do (e.g. the dangling carrot of FSF approval only if OpenMoko does not contain or link to or even mention closed-source drivers).. has more in common with religion than any modern philosophy I know of: http://en.wikipedia.org/wiki/Moral_absolutism IIRC, the reason for the lack of Wifi in the Neo1973 was due to the lack of an open-source driver. How much of this was down to the core team members, and how much was because the Neo1973 would lose geek credibility in a world of black and white? I respect the decision of the core team - it's their baby (until January - evil heh heh heh), and I also respect any business analysis reasons which might have suggested that the Open Source Community would reject the Neo1973 if it had a closed-source wifi driver. What I do not respect, is attempts by others to try to restrict my liberty, because it offends the ethical code which they have adopted for themselves. Furthermore, by suggesting it is an ethical issue, it implies that by disagreeing I am unethical or just uneducated. Finally, the absolutist stance taken has in the past and continues to restrict human liberty and choice by putting non-consensus unprovable 'ethics' ahead of technology. A case in point: "If a module arguably isn't a derived work, we simply shouldn't try to say that its authors have to conform to our worldview... [snip] ...nobody should be forced to behave according to our rules just because they _use_ our system." http://lkml.org/lkml/2006/12/13/370 The 'doomsday scenario' conveniently neglects other world economies and assumes new hardware components will all be closed-source, 'as if they can get away with it'.. as if there is no possible technological or financial benefit available to companies supporting the open source movement: http://lwn.net/Articles/162686/ I did think that this subject was getting a little off-topic, but then I realised that if the decision to leave out Wifi was not a purely technical one -- then the decision was forced by those who can shout "ETHICS!" the loudest. If so, this becomes relevant to all of us potential Neo1973 owners! Richard ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Global Locate Ephemeris Data
Would we be violating the license by redistributing this data, or additional data based entirely upon that data source to other Neo1973 units? I'm wondering about the possibility of leveraging off the fact that all Neo1973 units should have a very unified idea of the current time to increase the fix accuracy. For example, if you have three Neo1973s in a rough geographic triangle, such that: Neo 1 - has LOS to satellites a,b,c,d Neo 2 - has LOS to satellites c,d,e,f Neo 3 - has LOS to satellites a,c,d,f Each unit computes a positional fix with 5m accuracy as normal, but all at the same coordinated time. Scaling this up to a downtown city environment, where you could have 100 Neo1973's with a 5 mile radius... if they all took positional fixes at the same time, would it be possible to use all of this coordinated data, plus the ephemeris info, to increase the fix accuracy? Richard ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: The audio IC Wolfson WM8753 is cool :)))))
On Tue, 2006-12-12 at 21:54 +0100, Gabriel Ambuehl wrote: > I dont think you cound go round and stick a FPGA into Neo1973 at this point > of > time, either. I took the FPGA stuff as Neo ideas - is doesn't seem that far-fetched to imagine a future model with an expansion port for a bunch of different things, so this may have some utility after all :-) > I agree. I just don't think the FPGA is really needed for that. More > dedicated > hardware and some more general purpose CPU power would help more (it surely > would be useful if the SoC could actually do VGA @ 30FPS) in the next > generation. The datasheet certainly suggests that the SoC is capable of VGA @ 30FPS, I think someone suggested that it couldn't, but they didn't provide any sources when I asked and I lost track of the thread.. so I'm still under the assumption that the datasheet is correct. Although, it is dependent upon the driver implementation - DMA seems to take the brunt of the load, but there was a lot of other stuff in the LCD Controller section which, frankly, scared and perplexed me and I didn't take time to understand it properly. Richard ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Hurra Richard! Wofson WM8753 ; ) doing distance messuring with ultrasonic?
On 12/12/06, Robert Michel <[EMAIL PROTECTED]> wrote: Doing distance messuring with ultrasonic? ;)) 40kHz example: http://www.parallax.com/dl/docs/prod/audiovis/Distance28015.pdf Interesting article... 3.3m ping is not insignificant, especially in dark/smoke-filled environments. I remember doing something similar with LegOS (using the infrared port) with the original LEGO Mindstorms. I wonder if you could also defend against bears or dogs by playing with these frequencies.. mind you, 6m away from a grizzly, that UI better be clean and fast. No pressure ;-) Richard ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: The audio IC Wolfson WM8753 is cool :)))))
Salve Rob! On Tue, 2006-12-12 at 18:51 +0100, Robert Michel wrote: > Sorry, I'm not a electral engineer (student). So how hardware things are > solved will never be my excellence Please don't feel the need to disclaim your experience - those of us who went to university were all students once too ;-) In fact, those people I met in uni who found the technology fun and enjoyable, were significantly better off just 2-3 years down the line, than those who were just there for something to do.. or not to do (UK students seem to suffer from the latter)! I've found many of your posts filled with nuggets of inspirational ideas, and I'd hate to think that yourself, or anyone else would not post an idea or question because they were afraid to look stupid or inexperienced due to aggressive 'policing' of the list. OpenMoko = Open. Whether it's for ethical or pragmatic reasons, whether you can solder your own circuit boards with your teeth, or whether you have to get out a manual to figure out how to hold the TV remote properly.. I welcome all input - please post, people. Richard ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: The audio IC Wolfson WM8753 is cool :)))))
On Tue, 2006-12-12 at 17:56 +0100, Koen Kooi wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Robert Michel schreef: > > > PS: Again, it seems that an FPGA between the I/O connectors > > and the other chips would encrease the power of the Neo1973, > > e.g. the FPGA could switch the second audio jack to mono output. > > As can a GPIO. Stop with the fpga nonsense and get a devboard to play with That's a little bit harsh, dude. I agree that an FPGA is not a panacea, but all we have is ideas just now, so there's no harm playing with them! Richard ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Fun with Stolen/Lost Phones..
http://en.wikipedia.org/wiki/Teen_Buzz If the speaker can produce 17.4kHz then it could be sufficiently annoying to any potential 'teenage hooligan' running off with your phone. Add in some remote-access features, such as lock-down, sync/wipe local data, gps/voice recording+uploading.. if everything worked together, you could get enough info, then print a message on the screen: "Thank you for borrowing my phone, there is a McDonalds approx 100m north of your current location.. leave it on a table there and I will not prosecute. Your voice and locations have been recorded and uploaded to the internet (see map of your travels below). This means that destroying this phone, although fun, will not make it harder to identify you. [i agree] [i disagree]" Upon choosing the latter option, the poor thief would be berated by whatever messages you like through the speaker: * I think the Government is Hip! * Help! I'm being stolen by a silly person! * I wish to be stolen by someone less inept! etc, etc I guess the first stage of lockdown would be cutting off all private data access, whilst tracking and recording take place.. so that any outgoing calls could also be monitored and recorded. It would be very nice to do this monitoring from a web-interface too.. Richard ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GSM security question, mic directly connected to the GSM chip? Re: GPLv3 and Mobile Phones
Hurrah Robert! I'm not an audio engineerologist, however a quick read of the datasheet shows input/output rates of up to 96kHz.. so the theoretical highest frequency at that level would be 48kHz.. meaning there may be room in the non-audible spectrum for comms depending upon the sensitivity of the mic/speaker components. Is anyone else excited about having a 96Khz ADC with programmatic access in their pocket? I'm still a bit fuzzy regarding whether there is a physical wire connecting the microphone to the GSM (has its own ADC?), or whether the 2401 provides the GSM with the converted digtal stream? Richard On 12/12/06, Sean Moss-Pultz <[EMAIL PROTECTED]> wrote: On 12/12/06 9:43 PM, "Robert Michel" <[EMAIL PROTECTED]> wrote: > BTW: Do you have some more info for us about the audio/soundcard? ;)) > stereo(?) audio out, 2,5mm jack, frequency 20(?)-2(?)Hz > stereo(?) audio in(?), 2,5mm jack(?), frequency 20(?)-2(?)Hz Only because it's you who asked ;-) http://www.wolfson.co.uk/products/WM8753/ -Sean ___ 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: audio link Re: Peer Discovery
On 12/11/06, Robert Michel <[EMAIL PROTECTED]> wrote: > > 10 bonus points if it sounds like R2D2. efficient data transmission via audio mustn't sound well for the user - DTMF for transmitting your phonenumber would be acceptable, but the other modulations? Heh! That idea was intended just for handshaking/swapping business cards - very small amounts of data. Hands up who wouldn't sacrifice a little speed, for a phone that shared business cards with a fellow Neo1973 with cute 'threeps' and 'twerps'? To beem your virtual business card via audio it would be nice when the data transmission would be encoded into a non uggly modification of a voice output: "I'm beaming you now my virtual buseness card - complete" Or multiplexing a higher frequency data signal, if the hardware supports it? Such a solution could be also run on other smartphones with java - send and receive business cards and more without Bluetooth or IRDA nor cable nor online connections. I wonder if it's possible to support the basic modem signalling protocol in software? I haven't touched anything like that, but if for the price of a local phonecall and an old PCI modem, I could call a PC and encrypt whatever I liked through that connection.. it could end up being a cheaper, secure, alternative than GPRS? Richard ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Neo1973 + PSP == wifi proxy?
Hi, Homebrew isn't an option for the firmware they now ship with (2.8+).. AFAIK there still isn't a degrader option for those revisions. So doing it that way would be cheating! I'm running under the hard assumption that bluetooth won't be in V1, if it was included then, as you say.. there'd be very little point trying to piggyback in this contrived fashion onto closed systems with network connectivity (e.g. PSP, internet cafe PC's, etc). Regards, Richard On Mon, 2006-12-11 at 22:24 +0300, Alex Savvutin wrote: > Hi, > > PSP is not an open platform (Sony SDK costs $1), but there is the > "homebrew" SDK (http://ps2dev.org/psp), it's kind of hacking but it is > possible sometimes to get the "homebrew" apps to run on the PSP. So wifi > proxy can be implemented in C++ (PSP 2.7/8/+ firmware also supports Flash). > > I think it's interesting to make a more abstract project, I mean unified > wifi/bluetooth/etc proxy for various platforms. Just another example: Neo1973 > <=> Bluetooth <=> Desktop PC <=> Internet. And so on. > > Best wishes, > Alex > > > -Original Message- > From: "Richard Franks" <[EMAIL PROTECTED]> > To: OpenMoko > Date: Mon, 11 Dec 2006 10:08:02 -0500 > Subject: Neo1973 + PSP == wifi proxy? > > > > > I dropped the original idea below because of its limited utility, and > > this follow-up has even less utility.. however, since there is some > > javascript support in the PSP browser.. and the PSP would export its > > file-system to the Neo.. it should be technically possible. I wouldn't > > like to guess at the approximate bandwidth though ;-) > > > > Richard > > > > > > On 11/29/06, Richard Franks <[EMAIL PROTECTED]> wrote: > > > On 11/29/06, Richard Franks <[EMAIL PROTECTED]> wrote: > > > > Oh wait. You mean hosting the HTML file(s) on the Neo? By pointing the > > > > PC browser to the HTML file on the Neo's memory, you could in effect > > > > set up a meta-refresh every second or so, or use AJAX to read files > > > > (requests) from the Neo's memory, and pass them on to the external > > > > Server as subsequent requests. > > > > > > > > GWT has a nice feature whereby it regards return requests as > > > > asyncronous events. > > > > > > > > All it would require is javascript support. > > > > > > Hey! This is the first project idea which we (the community) could > > > start today and complete even before the first Neo1973 ships, without > > > access to the SDK or any other data. Booya. > > > > > > There would be three components: > > > > > > 1) A small utility (cpp? Preferences?) which: > > > * Runs on the Neo and opens up a localhost port - the Neo would connect > > > to this. > > > * Sets up a ring-buffer (implemented by files: request1.html > > > request10.html) > > > * Forwards results it receives back from the server (via the browser) > > > to the localhost client > > > > > > 2) The AJAX part which handles the PC end of the bridge > > > > > > 3) The server utility which speaks to the PC and understands the > > > Neo1973 requests it receives... or just passes it on in the case of an > > > SSH tunnel. > > > > > > There is actually a disconnect on the AJAX-Neo side - not sure of the > > > best way to get the return data from the browser back onto the Neo's > > > filesystem for dissemination, without invoking the file-download > > > dialog. Streaming is one way, but would require kernel hacking to > > > implement a file as a ring-buffer? If it's not a ring-buffer then you > > > run out of storage space. > > > > > > Oh wait, the file the PC browser writes to on the USB stick, can be > > > implemented as a symlink by the Neo.. to a device instantiated by the > > > app (1). > > > > > > Ok, good - did I miss anything? Who wants to help develop this? > > > > > > Richard > > > > > > > ___ > > 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
Neo1973 + PSP == wifi proxy?
I dropped the original idea below because of its limited utility, and this follow-up has even less utility.. however, since there is some javascript support in the PSP browser.. and the PSP would export its file-system to the Neo.. it should be technically possible. I wouldn't like to guess at the approximate bandwidth though ;-) Richard On 11/29/06, Richard Franks <[EMAIL PROTECTED]> wrote: On 11/29/06, Richard Franks <[EMAIL PROTECTED]> wrote: > Oh wait. You mean hosting the HTML file(s) on the Neo? By pointing the > PC browser to the HTML file on the Neo's memory, you could in effect > set up a meta-refresh every second or so, or use AJAX to read files > (requests) from the Neo's memory, and pass them on to the external > Server as subsequent requests. > > GWT has a nice feature whereby it regards return requests as asyncronous events. > > All it would require is javascript support. Hey! This is the first project idea which we (the community) could start today and complete even before the first Neo1973 ships, without access to the SDK or any other data. Booya. There would be three components: 1) A small utility (cpp? Preferences?) which: * Runs on the Neo and opens up a localhost port - the Neo would connect to this. * Sets up a ring-buffer (implemented by files: request1.html request10.html) * Forwards results it receives back from the server (via the browser) to the localhost client 2) The AJAX part which handles the PC end of the bridge 3) The server utility which speaks to the PC and understands the Neo1973 requests it receives... or just passes it on in the case of an SSH tunnel. There is actually a disconnect on the AJAX-Neo side - not sure of the best way to get the return data from the browser back onto the Neo's filesystem for dissemination, without invoking the file-download dialog. Streaming is one way, but would require kernel hacking to implement a file as a ring-buffer? If it's not a ring-buffer then you run out of storage space. Oh wait, the file the PC browser writes to on the USB stick, can be implemented as a symlink by the Neo.. to a device instantiated by the app (1). Ok, good - did I miss anything? Who wants to help develop this? Richard ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GPLv3 and Mobile Phones
On 12/9/06, Oleg Gusev <[EMAIL PROTECTED]> wrote: I have an original Zaurus 5500, and it still does not support SD/SDIO in the 2.6 kernel. An experienced kernel hacker can easily write a driver, because the card is on a simple SPI port. It was not done to protest against the decision made by Sharp to include a binary driver. Was it really a pragmatic choice ? This is a rhetorical question? :-) Richard ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
Re: GPLv3 and Mobile Phones
Hi Dave, On 12/9/06, Dave Crossland <[EMAIL PROTECTED]> wrote: I thought this blogpost from the FSFE might be of interest to the list and also relates to the question I asked earlier about how the openmoko relates to the FSF philosophy: OpenMoko = Open Mobile Communications Platform Neo1973 = physical handset using OpenMoko applications I think it may depend on how the Neo1973 specific code is distributed? OpenMoko is intended to run upon many different mobile architectures, so it would make a certain amount of sense (although this is an assumption) to not contain any Neo1973-specific code in the OpenMoko repository, but supply it through a software feed via the OpenMoko servers. I can also see the reasoning behind a kernel-type distribution, where support for (almost) everything comes in the same tarball. But I think the answer to that question probably shapes the answer to your question :-) Richard ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
Re: GPLv3 and Mobile Phones
On 12/9/06, Paul Bohme <[EMAIL PROTECTED]> wrote: Would like to avoid similar again, if at all possible. Loading firmware into a device is no big deal - it doesn't link into any other code so might as well be any random opaque blob of data. Having to deal with the contortions involved when one of the modules you need is pinned in time while the rest of the system is straining to grow is something else entirely. Logical and reasoned argument like that above, is one thing. Turning it into an ethical issue implies that there is an ethical absolute which imbues ones opinion or preference with more 'correctness' than the next persons opinion or preference or logical argument. For example, it would be possible to support a even a 1.x closed-source, binary module in any kernel release version you wish. You might have to perform some really ugly hacks to ensure this backwards compatibility, and it may even affect overall system performance - but it's still a pragmatic choice - the Zaurus was stuck on principle, the unwillingness to invest significant kernel changes or compromises because of a closed-source module. But I don't think there is a 'right' or 'wrong' way here - everyone is free to choose what amount of closed-source software they are comfortable with. I'm just not comfortable seeing ethics and philosophy used as intellectual sledgehammers to crush dissenting viewpoints. It's not exactly honest! Richard ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
32bit/64bit datatype issues
We had some major headaches with this - mostly because legacy code written for 32bit architectures tends to make silly assumptions that pointers can be cast to integers. But there also a number of tricky cases where it wasn't immediately obvious that the datatype discrepancy was the root cause. As it becomes harder to find 32bit desktop processors, this is going to become increasingly significant, especially for services or applications which communicate between the Neo1973 and a 64bit home/work PC. I noticed that the GIMP project has its own typedefs (guint, guint8, gint16, etc).. so I was wondering if OpenMoko will be supplying its own definitions too? Going into the future, it would mean that there is a level of protection against having to go back through reams and reams of code and finding obscure errors that could have been avoided very easily. On a more present-day note, if it had native conversions for big/small endianness, that would be really really nice, too. Richard ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
Blackberry Wishlists
I haven't misposted again. No, really. Inspired by Christopher Heinys thrust, I started wondering about what actual 'average' consumers want. It's my impression that the BlackBerry currently holds the crown for the "if I wanted a phone that could also do XYZ": http://www.google.com/trends?q=blackberry%2C+nokia%2C+motorola%2C+pda%2C+palm&ctab=0&geo=all&date=all Whilst the number of people searching google for "pda" remains relatively constant, over the course of ~3 years, the number of people searching for "blackberry" has grown to match the number of people searching for "pda". Not that this is conclusive in any way - it's just a trend, not an explanation of such. So why not look up "[product] wishlist" on google, to see which areas can be improved? Interestingly, a lot of end-user gripes seem to focus exclusively on the closed-source applications - based upon my five-minute research, I'd say the very act of providing a simple way for end-users to change/manage their applications for free, is a massive step forward. That said, those applications have to grant the wishes out there.. i'll start off with this one: http://blackberryforums.pinstack.com/1389-blackberry_wish_list.html Amusingly, note the special significance of Post #2 on this thread. Richard ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
Re: ideas with SMS
Salve Rob! On 12/7/06, Robert Michel <[EMAIL PROTECTED]> wrote: ?cologne I will go to cologne by train on 10.12.2006 14:12h from Aachen central trainstaion. ?cologne.* Have affair at 19:00, don't tell wife or bishop. The issues I see are: 1) The feasibility of entering all of your day-to-day info in such detail 2) How to logically secure access to that information once it is present This goes a bit beyond the medium (SMS) and into the mechanism (???). The latter interests me more as assuming you have this information available to SMS, you have it available for any other application too? A computer you carry in your pocket is a very different beast than one you go to work or university to meet. It knows you more intimately (location/recent contacts) for a start. Although I suppose that difference - the ease-of-access to that information is a function of the reduced complexity of the platform, which is endangered by the steady advance of OpenMoko. When there's only one of every type of application - it's easier to integrate. But I wonder if there are general-knowledge schema's which would actually benefit the user and aid in collating information? For example, you enter "trip to cologne" in your calender, an unintrusive UI element changes in relation to this - e.g. the phrase is highlighted. So you follow that link: * Obtain return date * Disambiguation - "trip to Cologne, Germany" vs "trip to Cologne Museum, Stinkville, USA" * Query whether user wishes to enter info about: - accomodation (if yes - who with? Add contact list entry?) - business or personal (or, as in this example, both) - meetings (contact info, specific location details, time etc) - attractions * Access info - notifications? etc, etc. But then, assuming this information is available system-wide.. another utility could independently compare GPS locations with commitments - one button press to email apology with estimated time of arrival. Do knowledge based schemas like that exist anywhere in the public domain? Is it worth the trouble of implementing them? Richard ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
Re: Conceptual/Data Framework
On 12/5/06, Jeff Andros <[EMAIL PROTECTED]> wrote:
On 12/5/06, Richard Franks <[EMAIL PROTECTED]> wrote:
> I started coding this beast last night. Not much to see, but if it
> garners any interest I'll chuck up on Sourceforge. There are still
> plenty of things to be decided, so if you'd like to contribute code or
> ideas, please do :-)
>
> Cheers,
> Richard
>
> P.S. Rereading that first sentence makes me think that "Beast" is a
> better name than not having a name, but it's all open.
>
yeah, if you want to put it up somewhere I'd like to give you a hand
Awesome! I've been debating over the last few days whether the scope
is valid. On one hand, it would be very nice to stream data from my
home pc, with a simple call such as:
dataFlow *myVideoFlow =
transformManager->subscribe("homepc:/sharedmedia/video1.avi",
"scale:160x120", "period:~");
However, I can think up many more uses for abstracted concepts, than
data-streams and there are many more applications which would derive
immediate benefit from a unified source for concepts than
data-streams.
Say you want to do a little post-processing upon the GPS location, to
take account of velocity and acceleration vectors to produce a
prediction of location +5 seconds:
dataFlow *myGPSFlow = transformManager->subscribe("projected GPS
location", "delta:5s");
Is that an abstracted concept, or a data-stream?
dataBlock *myGPSDataBlock = myGPSFlow()->getNextDataBlock();
float lat = myGPSDataBlock->getValue("lat");
vs the video example earlier:
dataBlock *myVideoDataBlock = myVideoFlow->getNextDataBlock();
char *myVideoFrame = myVideoDataBlock->getValue("frame buffer");
uint32 frameSize = myVideoDataBlock->getValue("frame buffer size");
or availability:
dataFlow *myAvailabilityFlow =
transformManager->subscribe("workpc:availability");
dataBlock *myAvailabilityDataBlock = myAvailabilityFlow->getNextDataBlock();
uint8 myAvailabilityNumber =
MyAvailabilityDataBlock->getValue("numeric availability");
char *myAvailabilityText =
MyAvailabilityDataBlock->getValue("textual availability");
My point is that conceptual states and conventional data-steams have
many similarities, indeed, the distinction can only be made by the
application which subscribes to it.
However, time-sensitive data-streams - such as audio processing are
going to be tough to handle because they need to have very small
data-blocks to 'simulate' asynchronous processing.. which is where
questions of efficiency start to raise their head with the increased
context switching.
So, I'm considering leveraging from the API similarities for concepts
and data-streams, by focusing on tuning the transformManager for
concepts only -- this means that, if required, low-latency data-stream
support could be integrated fully into the transformManager at a later
date, but the initial release would not be overly cumbersome and would
perform one task fantastically, rather than both tasks less
fantastically.
In that case, a data-stream transform could be written to perform any
task anyway.. but the system would not be optimised for low-latency
high-bandwidth streams initially.
What do you think?
Richard
___
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: Conceptual/Data Framework
I started coding this beast last night. Not much to see, but if it
garners any interest I'll chuck up on Sourceforge. There are still
plenty of things to be decided, so if you'd like to contribute code or
ideas, please do :-)
Cheers,
Richard
P.S. Rereading that first sentence makes me think that "Beast" is a
better name than not having a name, but it's all open.
On 12/4/06, Richard Franks <[EMAIL PROTECTED]> wrote:
I've been thinking a lot more about this idea over the weekend:
http://lists.openmoko.org/pipermail/community/2006-December/000512.html
But it's probably time to present these ideas a bit more
comprehensively to elicit constructive feedback.
Terminology:
transform - takes input, processes, outputs.
data stream - the output to input path
To recap, the purpose is to provide a combined scalable framework for
both the transmission and processing of both data-streams and
arbritrarily abstract concepts. The framework would present a
homogenious interface for all applications, and by passing on
computational load to the framework, applications subscribing to the
same transform could share resources efficiently.
An simple example of a shared set of transforms, might be a voice
recorder which operates at the same time as an incoming call, both
requiring the same level of audio-filtering.
An example of a 'concept' may be 'user availability' (e.g. 0-100) or
'network usage' (0-100). In each conceptual instance, text could
further abstract the pure number - user availability of 0 = "no
contact". 1-10 = "high priority only".
A concept can be constructed from a transform in two ways:
1) Subscribing to 'statistics' of the transform. E.g. subscribing for
a callback every second on an audio transform would keep your
application notified of the higher-level downstream status.
2) From one or more existing concepts or system-states.
I'd say conceptually the system (let's call it
swan - "system without a name", for now) could be broken down into two main
areas:
1) The transform-manager which handles calls/subscription requests -
creates/unloads transforms dynamically as needed. So you have a single
entity which knows the structure of the network at any one time.
2) The transforms/plugins themselves
Since an application never interacts directly with the transforms,
they could reside as shared libraries (e.g. /usr/lib/swan/lib*.so)..
whether the transform is a kernel-module, or a library itself
(undecided - preferences?) the application should just be able to do
something similar to:
#include
...
// Transform Manager as a singleton
//
transformManager *tman = transformManager::Instance();
// Creates a hook into the raw microphone audio device, at a rate of 44k,
// and returns data blocks 1000 milli-seconds long.
//
dataFlow *myDataFlow = tman->subscribe("raw audio input", "rate:44000",
"period:1000");
while ( !mainloopEndCondition ) {
while (myDataFlow->unprocessedDataBlocks() > 0) {
// get access to the data
//
dataBlock *myDataBlock = myDataFlow()->getNextDataBlock();
// ... do whatever you want with the data ...
}
// other main loop stuff
...
}
Now, instead of subscribing to "raw audio input" above, your
application subscribes to "myhomepc:raw audio input", then you've got
the basis for a very powerful application. Except the example above
has no error-checking, but still.
Because all transform-related calls would be directed to the Transform
Manager, the application does not need to worry about how to connect
to other remote machines, that code (Local Transform Manager to Remote
Transform Manager comms) only needs to be written once.
Finally, what is the best way to implement the transforms?
What if each transform allocated a shared memory segment for its
output buffer, and each transform was a self-contained thread? When
the output buffer is full, it could relinquish its share, and pass
ownership onto the next upstream transform or application. It then
allocates a new shared memory output buffer and continues the pattern.
For some data-streams, e.g. video/audio processing.. the buffer size
does not change, only the contents - so by passing on shared memory
segments in a controlled manner, it is possible to avoid expensive
copying.
When a transform has >1 subscriber, only one subscriber could
legitimately write to the same shared memory segment - this could be
handled by the transform-manager.
It would be rather easy to write and redistribute transforms, as the
Framework would be providing all the major hooks and the base classes
to handle the multi-threading/memory segment sharing stuff.
Any thoughts/comments/criticisms/xyz does it already statements, welcome :-)
Cheers,
Richard
___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
Re: Synchronize Calendar, Contacts of Neo with Lotus Notes, Outlook, etc.
On Tue, 2006-12-05 at 20:50 +0100, Dennis Günnewig wrote: > Hey @all, > > at the company we use Lotus Notes. As I'm really interested in using the > neo for business and private purposes two things are important for me. > > 1)A software packet which enables me to synchronize my calendar, contacts > etc. on Neo with Lotus Notes and/or MS Outlook. I know that OpenMoko partnered with Funambol, to provide synchronisation services: http://www.funambol.com/ But we don't know the details or scope of that deal - certainly it appears that Funambol have hooks into Lotus/Outlook - whether that is included as part of the deal I couldn't speculate really. Richard ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
Re: Is it portable? [scanned]
On Tue, 2006-12-05 at 19:37 +0100, Robert Michel wrote: > Explain me - what would be the long term benefit to run OpenMoko on a > THC device in the next month? I'm not a corporate marketing-ologist, but surely the more hardware platforms OpenMoko runs on, the more credibility it will receive. > Do you just like to have a "toy" for yourself or do you like to > revolutionise? What will be your aim? I want a sexy toy which I can whip out of my pocket in the street, show off, and do wonderful revolutionary things with. Oh wait, wrong list. The distinction I make is suggesting the lack of distinction between toy and and revolution - in that the revolution will be 'playing' with small application components (toys), to create flexible component networks dynamically without fear of 'breaking' anything. Sure - LEGO comes with instructions and guides, but the fun is the unlimited potential - because the hard work was already done by the LEGO designers to abstract the nuts and bolts of a car into reusable components.. you can make a car or a plane or a...? You're only limited by your imagination. There doesn't exist a platform today which you could just play rather than work with, in the same way. > Why wasting time with reverse engineering - when we now have a hardware > producer we can talk with *directly*?¹ Does FIC produce hardware components, or package them together/send to manufacturing? I assumed the latter, although, you are right - corporate weight behind a friendly ear to the communities desires.. a good thing. > So hacking OpenMoko solutions to a HTC device would be a cool hack, > but *not* smart it would *not* power up OpenMoko - it would weaken > OpenMoko/FIC > and delay or risk a next Neo version with Wi-Fi and camera. It's a strong statement to make - I recall reading somewhere that a goal of OpenMoko was to encourage many different vendors to implement it on their hardware? Certainly, that was one of the positive points which drew me to the project, having never before heard of FIC. I think maybe it's unwise to spend too much time second guessing FICs business strategy - we have an open communication channel with FIC now, and it can work both ways if required. Richard ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
Re: Is it portable? [scanned]
Will the OpenMoko repository contain drivers for all supported platforms, or will the drivers be distributed and bundled by the hardware vendor into a specific SDK - in this case FIC for the Neo1973? Or is that still to be decided? Richard ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
Conceptual/Data Framework
I've been thinking a lot more about this idea over the weekend:
http://lists.openmoko.org/pipermail/community/2006-December/000512.html
But it's probably time to present these ideas a bit more
comprehensively to elicit constructive feedback.
Terminology:
transform - takes input, processes, outputs.
data stream - the output to input path
To recap, the purpose is to provide a combined scalable framework for
both the transmission and processing of both data-streams and
arbritrarily abstract concepts. The framework would present a
homogenious interface for all applications, and by passing on
computational load to the framework, applications subscribing to the
same transform could share resources efficiently.
An simple example of a shared set of transforms, might be a voice
recorder which operates at the same time as an incoming call, both
requiring the same level of audio-filtering.
An example of a 'concept' may be 'user availability' (e.g. 0-100) or
'network usage' (0-100). In each conceptual instance, text could
further abstract the pure number - user availability of 0 = "no
contact". 1-10 = "high priority only".
A concept can be constructed from a transform in two ways:
1) Subscribing to 'statistics' of the transform. E.g. subscribing for
a callback every second on an audio transform would keep your
application notified of the higher-level downstream status.
2) From one or more existing concepts or system-states.
I'd say conceptually the system (let's call it
swan - "system without a name", for now) could be broken down into two main
areas:
1) The transform-manager which handles calls/subscription requests -
creates/unloads transforms dynamically as needed. So you have a single
entity which knows the structure of the network at any one time.
2) The transforms/plugins themselves
Since an application never interacts directly with the transforms,
they could reside as shared libraries (e.g. /usr/lib/swan/lib*.so)..
whether the transform is a kernel-module, or a library itself
(undecided - preferences?) the application should just be able to do
something similar to:
#include
...
// Transform Manager as a singleton
//
transformManager *tman = transformManager::Instance();
// Creates a hook into the raw microphone audio device, at a rate of 44k,
// and returns data blocks 1000 milli-seconds long.
//
dataFlow *myDataFlow = tman->subscribe("raw audio input", "rate:44000",
"period:1000");
while ( !mainloopEndCondition ) {
while (myDataFlow->unprocessedDataBlocks() > 0) {
// get access to the data
//
dataBlock *myDataBlock = myDataFlow()->getNextDataBlock();
// ... do whatever you want with the data ...
}
// other main loop stuff
...
}
Now, instead of subscribing to "raw audio input" above, your
application subscribes to "myhomepc:raw audio input", then you've got
the basis for a very powerful application. Except the example above
has no error-checking, but still.
Because all transform-related calls would be directed to the Transform
Manager, the application does not need to worry about how to connect
to other remote machines, that code (Local Transform Manager to Remote
Transform Manager comms) only needs to be written once.
Finally, what is the best way to implement the transforms?
What if each transform allocated a shared memory segment for its
output buffer, and each transform was a self-contained thread? When
the output buffer is full, it could relinquish its share, and pass
ownership onto the next upstream transform or application. It then
allocates a new shared memory output buffer and continues the pattern.
For some data-streams, e.g. video/audio processing.. the buffer size
does not change, only the contents - so by passing on shared memory
segments in a controlled manner, it is possible to avoid expensive
copying.
When a transform has >1 subscriber, only one subscriber could
legitimately write to the same shared memory segment - this could be
handled by the transform-manager.
It would be rather easy to write and redistribute transforms, as the
Framework would be providing all the major hooks and the base classes
to handle the multi-threading/memory segment sharing stuff.
Any thoughts/comments/criticisms/xyz does it already statements, welcome :-)
Cheers,
Richard
___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
Re: openmoko on other FIC platforms as well?
Hi Koen, On Mon, 2006-12-04 at 10:59 +0100, Koen Kooi wrote: > Software can't magically fix a slow framebuffer. Last I heard you couldn't > trigger full > redraws at 20fps on the s3c2410fb, so all the decoding power in the world > couldn't get you > fluid playback if you can't get it on the screen in time. Do you have a link relating to this? This thread, and the hardware manual link inside (although the tech-info is lifted directly from the manual) seem to state otherwise: http://lists.openmoko.org/pipermail/community/2006-November/000346.html Framerate is quite significant to me :-) Do you know if the discrepancy a driver issue? Cheers, Richard ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
Re: Can The Proprietary GPS Daemon Be Removed?
On 12/3/06, Dave Crossland <[EMAIL PROTECTED]> wrote: On 03/12/06, Richard Franks <[EMAIL PROTECTED]> wrote: > I'm happy to support open source development where appropriate. I > think in this case though, reverse engineering a proprietary driver > for something as single-purpose as a GPS chip is overly aggressive. > And to what end? The point of Free Software is to drive proprietary software out of existence. I'm sorry to hear that you've been told it was anything other than that. That is the reason GNU/Linux exists, and will continue to exist. If this seems strange, I recommend reading the essay "Why Software Should Not Have Owners" at http://www.gnu.org/philosophy/shouldbefree.html It explains why all proprietary software is wrong, and why we cannot tolerate it if we're to live in an ethical, sustainable, friendly way. I am aware of the arguments - I simply, respectfully, disagree with all-or-nothing idealism. I would love to live in a reality where the goals of the FSF were fully reached, but we have to deal with the reality we're dealt too! > If it is without the cooperation of Global Locate, > then surely they can switch off AGPS access if they choose? Please could you re-explain this - I don't understand enough about how AGPS works to understand what you mean. It's my understanding that Global Locate undertake to supply positional data for the AGPS systems they make. > Even with > their blessing, how long would we expect it to take to improve upon > the efforts of their expert full-time development and QA staff who > surely take into account balancing not only individual unit > performance but that of the overall network? Imagine someone arguing that creating a society where we have free elections, where everyone's allowed to vote, isn't worthwhile because it will take a long time to overthrow a tyrant dictator and set up a senate/congress/parliment. They would be missing the point. Skipping dictators/ideals/voting - the point is how long would it take to reverse-engineer and develop a new GPS driver, test it, obtain blessing from Global Locate? If you think longer than a month, then for the first release, it's a moot point as it's simply not going to happen. > What if we used the open-source replacement and accidentally crashed > their servers in the process? What if someone else crashes their > servers on purpose? It is naieve to expect that if you offer a network service to the public, no one will act in bad faith. Spammers and crackers will come knocking. Therefore I would expect anyone offering network services to maintain good security practices. Efforts to create a good-faith Free Software client for a network service should therefore be unable to crash their servers. FC6 download? ;-) If they need to write better servers, they need to write better servers. Traditionally GPS devices exist in closed-embedded environments - which mitigates security concerns somewhat. I think Global Locate deserve credit for seeing the potential of what the OpenMoko/Linux/GPS/Phone combo could acheive. I know of a lot of small companies who live or die based upon 1-2 low-margin hardware products which they develop. Please explain how it is possible to stop someone reverse engineering a protocol and writing a Free Software implementation. I don't believe its theoretically possible. The difference between theory and reality is that in theory there is no difference between the two, in reality there is. Otherwise we'd all be running open-source ATI drivers, no? > Supporting open source initiatives does not mean that one has to > methodologically seek to remove or replace all instances of closed > source. I'm sorry you've misunderstood what's going on here. That is precisely what the GNU/Linux operating system developers are doing. "The idea is not just to produce a scattering of free programs that were nice to use. Rather, the idea is to systematically build free software so that one can escape completely from non-free software. Non-free software is basically antisocial, it subjugates it users, and it should not exist." - http://www.zmag.org/content/showarticle.cfm?ItemID=9350 The point at which it starts approaching religious fundementalism, is the point at which I jump off the train. I support open source, and I'd love to see every bit of software free. But at the end of the day I don't publicly upload all of my companies proprietry software, because in our reality, that would be unethical. When you start talking of ethical absolutes, regardless of social consensus, you're talking religion. When a developer makes proprietary software available to the public, the code and algorithms are published. If a developer wishes for them to be secret, they are foolish to make them available t
Re: Can The Proprietary GPS Daemon Be Removed?
I'm happy to support open source development where appropriate. I think in this case though, reverse engineering a proprietary driver for something as single-purpose as a GPS chip is overly aggressive. And to what end? If it is without the cooperation of Global Locate, then surely they can switch off AGPS access if they choose? Even with their blessing, how long would we expect it to take to improve upon the efforts of their expert full-time development and QA staff who surely take into account balancing not only individual unit performance but that of the overall network? What if we used the open-source replacement and accidentally crashed their servers in the process? What if someone else crashes their servers on purpose? Opening up the GSM stack holds similar concerns -- what's the point of having a 100% open (all device drivers and all) phone, if you can't use it because the commercial carrier has decided that they are tired of a few people abusing their servers? Supporting open source initiatives does not mean that one has to methodologically seek to remove or replace all instances of closed source. Open Source is Good, not a God - we have the freedom to choose when it works best for us, and to permit ourselves a pragmatic flexibility when it doesn't. The AGPS driver will have code or algorithms which, for whatever reason, Global Locate wish not to publish. That is their choice, and as long as they supply a great product which I derive benefit from, by choosing their product I am explicitly agreeing to their terms. Dave Crossland <[EMAIL PROTECTED]> wrote: "I'm essentially asking if its theoretically possible that this phone might be FSF endorsed - non-free firmware is fine by the FSF as long as it is burned onto a ROM and can never present an ethical problem." So... if the APGS driver was burned onto ROM, and not present as a closed-source binary driver which can be updated and improved.. the FSF would be happy to endorse a phone which supplied no upgrade/bug-fix options to the end-user? Assuming that is the FSF's position, and it does seem to this end-user to be following idealism to a rather religious extent, then fine - everyone has a choice - this individual end-user could care less. "However, straight up, while the proprietary GPS daemon is included by default, or in fact recommended/mentioned by OpenMoko, its not going to be endorsed by the FSF:" What good is freedom of software, if it comes at the cost of freedom of choice? So any product with a FSF Endorsement is therefore unable to even mention an alternative closed-source replacement which may provide me with better functionality? I have to say, as far as PR in the market-place of ideas goes, it would make me think twice about picking up a phone with a FSF endorsement, as my first thought would be.. how hard do I have to hunt if I want to use this phone to its full potential? Anyway, back to the fun stuff :-) Cheers, Richard ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
Re: Light sensor
On 11/30/06, Tim Newsom <[EMAIL PROTECTED]> wrote: > the problem with doing it this way, is you'd need some way to notify > each application of all the sensors available at runtime, or you > re-compile each availability sensitive app for every combination of > sensors (having that many versions of software is sure to turn off > Sean's dad) there's definately more to think about on this one Are you thinking of not only notifying each application on the number of sensors.. (That would be easy enough in the api) but also to let them have access to the setup/configure api for each one? Yes - each transform (raw audio, touch screen state, last user activity time, user availabity,etc) can decide on its own how to handle subscription requests -- e.g. for when >1 application makes a request to the same datasource. Also, another bonus is that you don't need to recompile anything whenever the transform-network changes - it would change quite often. When a transform handles its last 'unsubscription', it could unload itself -- this way resources are saved, and the dead branches of the network are pruned. When an application tries to subscribe to that transform next time, the transform-factory which handles the request can instantiate it - that way you have: 1) User opens 'voice recorder' 2) Application loads, and request is made for (filtered audio:44k) 3) transform-manager creates (filtered audio) with given parameters 4) (filtered audio) makes a request for (raw audio:44k) 5) transform-manager creates (raw audio) with given parameters - direct hardware interface 6) Another Application makes a request for (raw audio:22k) 7) Transform-manager passes request onto existing (raw audio) with parameters 8) The (raw audio) interface can be written to multiplex its output to both Applications or create another instance of (raw audio) with the 22k parameter Enumerating over each sensor that is active would be fairly easy using the plugin mechanism previously described... If every plugin had the same output ranges... Say 0 to 255 or whatever and using the probability scenario he talked about the application would only need to know one interface, I.e. Availability. As I understand the proposal, and I might be wrong, it would end up a heirarchy. Lower level plugins could be accessed at any level but the common usage would be to build behaviors going up from the sensors and applications would interface with that... Is that right? Yup - and because >1 application can share the same logical processing, you save CPU cycles too. With that in mind, each plugin would register with some service which handles the interface to applications. Each behavior created would do the same and gain access to the sensors available. Then a control panel could be created to enable/disable some but not all plugins at the will of the user, though that would modify the behaviors, they would then act on the information currently available. The flexibility and security of the network both become especially crucial when you start referencing external nodes: homepc:(user availability) bobsneo:(user availability) tomsneo:(microphone audio) Upon a subscription to the last one, a dialog would be displayed upon Toms neo1973 asking whether he accepted that level of security access. It would then appear in that control panel if it was a brand new connection. The higher-risk security vulnerabilities should be a compile-out option for the cautious ;-) Although, that would make it very simple to write a little program to make a walkie-talkie over GPRS. Seems like a fairly interesting concept. Do I understand the concepts or am I missing something? I think you did a better job than me of describing the idea :-) Richard ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
Re: Light sensor
On Thu, 2006-11-30 at 13:47 -0700, Jeff Andros wrote: > ok, I was thinking more like /dev/random pulls seeds from all the > devices registered with it, or the way that mythtv detects commercials > based on plugins, create a virtual device that returns a read of 0-255 > based on the probability that you're available... as each device(light > sensor, etc) is added, it would register with /dev/available as a > detection device, and provide a function to return another byte value > of what it thinks the user's doing. the available device would > perform some kind of heuristic on this. then when a call comes in, > the receiver daemon checks with /dev/available, then uses the value > returned to decide what to do. different events could have different > values ( e.g. the girlfriend calls, it'll ring if the value is greater > than 3 (basically not dead... probably from a VOC sensor) but if the > bill collectors call, the value better be 250+ or I'm not getting > bothered) As a matter of personal preference, I'd prefer to avoid sticking abstracted concepts into /dev - start with /dev/available and you end up with 100's of entries including /dev/probability-of-the-user-feeling-like-a-grilled-cheese-sandwich -- it's not as scalable. A 'plugin' is a high-level user concept - the transforms I described also work as 'plugins', but I think we're talking about the same thing.. so written down in transforms, what you describe would be: [multiple sinks] => -> (user availability) And whether or not the phone rings when a call comes in: Sinks: (caller) (user availability) Process: compares scores Sources: (ring/silent notification/vibrate/ignore) The difference in implementation is moving away from a rigid rule-based system (there was an article posted a day or so ago describing these) as with rules, each component decides too much upon its own, and it has no way to deal with rule-conflicts as each application is left to construct its own closed-decision-chain. In this system, each application doesn't have to waste system resources (read:battery life) reinventing the wheel. >From your example, say 'availability' was a datasource between 0-255, with user-defined cutoffs (e.g. 250 = anyone but smelly john can call me) then the application still has the freedom to override the system-consensus, but such deviations are explicit. Richard ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
Re: Light sensor
On Thu, 2006-11-30 at 11:51 -0700, Jeff Andros wrote: > > It almost sounds like we should make a plugin framework for > availability detection, with plugins for the light sensor, PIM > calendar, microphone (can we set an interrupt if the ADC receives a > level greater than X?) and so on and so forth as people figure out > other ways to detect it I'd prefer something a little more generic.. how about considering it as a network of transforms? Where each transform is a simple plugin, of the sink/process/source variety? For example, the physical hardware would be a series of available datasources, I'll start with the simplest: (microphone voltage sample) So a voice recording utility could subscribe to the (microphone voltage sample) for a duration of its choosing - and it now has a recording. Except, you may want to filter out snaps and crackles.. so you load the filtering transform: (microphone voltage sample) -> (snap and crackle filter) -> (processed microphone sample) The application above can now subscribe to the (processed microphone sample) instead of the raw voltage sample, if it chooses. Now say we want to know what the average volume is over one second. We load another transform (average amplitude), and pass it the parameter duration:1000ms: (microphone voltage sample) -> (average amplitude) -> (average amplitude:1000ms) You could have another application which wants to know what the average is over two seconds.. so now the (average amplitude) transform is servicing two datasources: (average amplitude) -> (average amplitude:1000ms) -> (average amplitude:2000ms) So in the end, the (activity-monitoring) transform would be built from: (microphone voltage sample) -> (average amplitude) -> (input1) (light sensor value) -> (average amplitude) -> (input2) (time of day) -> (schedule comparison) -> (input3) (time since last user activity) -> (input4) etc etc.. But in the end, you have system-wide consensus with regards whether the user is active, and each application which cares just has to subscribe to the (activity-monitoring) data-source to find out. There's a *lot* of implementation details I've skipped over, but in essence I think such a system gives the power to grant conceptual abstraction and system-wide consistency, with simplified and less redundant development. Er, in other words, I can't think of another way in which we could avoid the scenario whereby you have two similar applications which come to separate conclusions based upon the same inputs - one concludes the user is awake, the other concludes that the user is not. Richard ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
Re: Small evaluation, city: 4 Internet Cafes, 3 Copy Shops, 2 Photo services; university: 1 library , 1 computer room
On Thu, 2006-11-30 at 20:20 +0100, Koen Kooi wrote: > > any spare(ish) cycles you have I'd vote for using them to put up a > > basic community wiki - makes it easier for project ideas to get off the > > ground when there's a common source for information, not least with > > relation to the ability to upload design diagrams + status tracking. > > > > Yup - it could become an incoherent jumble, but as a stop-gap until the > > repositories/tracking are in place, it would be ideal. > > You could use the http://www.linuxtogo.org/gowiki/ wiki for that till the > official wiki > goes live in 2007. I see this as an issue of centralisation vs. fragmentation. I'd prefer to have one source to go to for all things Moko. :-) Cheers, Richard ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
Re: Small evaluation, city: 4 Internet Cafes, 3 Copy Shops, 2 Photo services; university: 1 library , 1 computer room
On Thu, 2006-11-30 at 12:00 +0800, Sean Moss-Pultz wrote: > On 11/30/06 6:12 AM, "Richard Franks" <[EMAIL PROTECTED]> > wrote: > > > Unless it already exists, I'll do some research tonight.. anyone > > interested in joining the coding/design effort? > > CC me. I'd love to follow your work. I have very limited time now, but I'll > see if there is anything we can do to support your efforts. Hi, any spare(ish) cycles you have I'd vote for using them to put up a basic community wiki - makes it easier for project ideas to get off the ground when there's a common source for information, not least with relation to the ability to upload design diagrams + status tracking. Yup - it could become an incoherent jumble, but as a stop-gap until the repositories/tracking are in place, it would be ideal. Thanks, Richard ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
Re: Light sensor
On Thu, 2006-11-30 at 09:48 +0100, Sven Neuhaus wrote: > Sean Moss-Pultz wrote: > > > On 11/30/06 3:32 AM, "Robert Michel" <[EMAIL PROTECTED]> wrote: > >> >> But this light sensor could also combined with localisation, time and > >> >> provile (or movement sensor) > >> >> E.g. when I'm at home and the light sensor detects light at 2 o'clock > >> >> in the morning, I will still be reachable for calls from my frinds. > > > > > > Combined with automatically switching profiles (AGPS stuff) this is > > > really an amazing idea. > > Agreed - fascinating possibilities! FYI, the Motorola L2 phone has a light > sensor (it toggles the keypad light), so it's been done already, but - of > course - the closed software on that phone doesn't fully utilize it... I'm assuming that acquiring/monitoring the microphone input doesn't come for free.. but ambient noise level could also be used as an indicator of activity - either polling for one second every minute or so, or (if the ADC can be directed to acquire at a lower data rate) a continuous sample over a longer period of time -- you don't require too much resolution to monitor the presence of ambient noise. You would want to base it on an probabilistic analysis in either case, else it might pick up car headlights swinging across the window, a neighbours security light being triggered by raccoons, etc. Oh wait, that wouldn't work... if you had the phone in the bedroom it would allow incoming calls if you were snoring. Bah. Richard ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
Small evaluation, city: 4 Internet Cafes, 3 Copy Shops, 2 Photo services; university: 1 library , 1 computer room
On 11/29/06, Koen Kooi <[EMAIL PROTECTED]> wrote: > > Hey! This is the first project idea which we (the community) could > > start today and complete even before the first Neo1973 ships, without > > access to the SDK or any other data. Booya. > > That isn't true. You can start coding a a pure gtk+ app right now, and it will run on the > neo quite well. You just sank my Booya. Without access to the SDK/API, or an understanding of the hooks or capabilities or feature-support in the API, or what screen resolutions/depths/modes will be natively supported by the first release, I don't imagine we'll see many *useful* GTK+ apps which take advantage of the Neos features until then. Yes it is possible, just terribly unlikely. So okay - it's the first community project idea I've read which could be developed, *fully tested*, and be ready to go on day #1 of the release of the Neo1973, without ever seeing the hardware or requiring more information than we already know. Unless it already exists, I'll do some research tonight.. anyone interested in joining the coding/design effort? Richard ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
Re: Small evaluation,city: 4 Internet Cafes, 3 Copy Shops, 2 Photo services; university: 1 library , 1 computer room
On 11/29/06, Richard Franks <[EMAIL PROTECTED]> wrote: Oh wait. You mean hosting the HTML file(s) on the Neo? By pointing the PC browser to the HTML file on the Neo's memory, you could in effect set up a meta-refresh every second or so, or use AJAX to read files (requests) from the Neo's memory, and pass them on to the external Server as subsequent requests. GWT has a nice feature whereby it regards return requests as asyncronous events. All it would require is javascript support. Hey! This is the first project idea which we (the community) could start today and complete even before the first Neo1973 ships, without access to the SDK or any other data. Booya. There would be three components: 1) A small utility (cpp? Preferences?) which: * Runs on the Neo and opens up a localhost port - the Neo would connect to this. * Sets up a ring-buffer (implemented by files: request1.html request10.html) * Forwards results it receives back from the server (via the browser) to the localhost client 2) The AJAX part which handles the PC end of the bridge 3) The server utility which speaks to the PC and understands the Neo1973 requests it receives... or just passes it on in the case of an SSH tunnel. There is actually a disconnect on the AJAX-Neo side - not sure of the best way to get the return data from the browser back onto the Neo's filesystem for dissemination, without invoking the file-download dialog. Streaming is one way, but would require kernel hacking to implement a file as a ring-buffer? If it's not a ring-buffer then you run out of storage space. Oh wait, the file the PC browser writes to on the USB stick, can be implemented as a symlink by the Neo.. to a device instantiated by the app (1). Ok, good - did I miss anything? Who wants to help develop this? Richard ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
Re: Small evaluation,city: 4 Internet Cafes, 3 Copy Shops, 2 Photo services; university: 1 library , 1 computer room
On 11/29/06, Robert Michel <[EMAIL PROTECTED]> wrote: *IDEA* Wait, because these systems support USB mass storage device - couldn't we use a normal browser and on download to a FIFO file and an upload to a FIFO to FIFOs on our server? So no local installation, nor Java support (I would have doubts that Java will be allowed to access the USB mass storage device, especialy not a USB network device...) So with this trick we could run an SSH tunnel via the FIFOs and would have Internet connection on our NEO at all these locations :)) This would avoid the need for and USB eterneth adapter and the best: - Our device would be charged during visiting the internet cafe - no softwareinstallation on the workstation neccesary - no network configuration - AND it would work with other people PC/Laptop as well - beeing on the campus / caffe / airport lounge where other use Wlan - just ask them to plug in your USB cable and use a ssh tunnel over bidirectional "webbrower to USB mass storage device" routing I thing this "hack" would need some keep alive packed from time to time ;) A possible problem with the FIFO-file for networking idea is that it's a bit trickier to determine exactly when the PC side will send data to the Neo, instead of caching the file locally. Or maybe I don't understand the implementation of your idea? How would the browser 'know' how to automatically use a FIFO-file? If I'm in a web-cafe, I hook my Neo into the USB, point the PC browser to my trusted server.. there's a link missing: Neo/USB/?FIFO?/browser/server Now.. you could hack the PC-side to write-immediately to the USB device, but files are not FIFO in the ring-buffer sense.. that could be hacked on the Neo end.. hmm.. I guess the results stream could be just that - the equivalent of downloading a file of unknown size. To upload (Neo-Server) requests.. that may be more tricky.. because you want to upload without continuously hitting the 'file upload' dialogue -- a fetch will (IIRC) see a file of X bytes, and upload just those X bytes. Still not sure about the Neo-PC-Server communication path, although the Server-PC-Neo path is easier but with some hacking. Oh wait. You mean hosting the HTML file(s) on the Neo? By pointing the PC browser to the HTML file on the Neo's memory, you could in effect set up a meta-refresh every second or so, or use AJAX to read files (requests) from the Neo's memory, and pass them on to the external Server as subsequent requests. GWT has a nice feature whereby it regards return requests as asyncronous events. All it would require is javascript support. Neat! Richard ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
Re: multicolour multi-touch screen Re: OpenMoko/Neo1973 is pure (r)evolution :))) - do you recognized the power of "multi-touch gesture recognition"
Skip all that, and go straight to monitoring EEG brain signals - one sensor (array), all input handled. Fashion it into a nice hat. Actually, no.. all I really want to do with the Neo1973 is get a ring-tone to do the "beep beep boop bop" from CTU/24. Now I think of it though.. AGPS/GPRS... urban Counter-Strike! Whenever you hear the designated call-chime, you can answer and hear pre-recorded 'mission' data. To which you can respond loudly: "What!? The British Agent is about to have a cup of tea and scones at a cafe down the road?! I'll take him out." etc Richard On 11/29/06, Robert Michel <[EMAIL PROTECTED]> wrote: Salve! Robert Michel schrieb am Mittwoch, den 29. November 2006 um 20:02h: > Or for the power user, paint different color points on your finger > tips (multiple (different) coloured points on one or more of your Ok nerds would paint their finger tips with colour, but who else? What about light frequency outside of our cognition? Or black-light and special colour to use the multi-touch sensor with multi colour? Or let us work with the pattern of our fingermarks The colour finger tips could be an intermediate step for nerds and developer ;) rob ___ 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: [Spam?] Re: google earth - [was: Re: Another simple GPS+GPRSidea]
On 11/28/06, Richard Franks <[EMAIL PROTECTED]> wrote: however for all the towns and cities I've lived in, the actual street layouts and names don't change terribly often. Let me qualify this rather anecdotal statement.. I don't think street-layout/renumberings change often enough to be show-stopper problem for a project like OpenStreetmap. If you work a lot with streetmap data, then you probably deal with renumbering/layout changes on a daily basis. But what percentage of roads require such changes per year? What percentage of the total streetmap mileage is affected? Does this occur more frequently in urban, suburban, or rural areas? I think you'd need to take account of at least these variables to determine the extent of the problem, and the ease of the fix. I'm also thinking in terms of highway maintainance -- if one section is under maintainance, and traffic from both directions are forced to share one side of the highway.. then temporary traffic information could be mined quite easily if the highway is wide enough to draw conclusions from the offset in expected GPS vectors. Likewise for accidents, or temporarily blocked roads. All it requires is a few more programmable GPS devices on the roads who share data, and you have the basis for an automonous dynamic nagivation system, which has the potential to report back issues rather quickly. Richard ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
