Re: standard API for linux phones?
On Jun 11, 2007, at 10:00 PM, [EMAIL PROTECTED] wrote: I'm not sure if this is useful. It sounds a bit more like a marketing group. You have to pay a fee to join. On Mon, 11 Jun 2007, Dean Collins wrote: Long overdue and if it is a standard then lets all jump onboard and work with it from inside rather than throwing rocks from the outside. It costs a bunch to join ... so it's hard to work on the inside. It's interesting the more you pay, the more votes you get in the forum. http://lipsforum.org/downloads/legal/LiPSInternalPolicay.pdf The press release says they have released a specification ... but nothing is visible on the web site. I am not sure how Linux compatible this group is at least in philosophy. The participation is closed, the forum allows patented code (as long as the license is non-discriminatory). Even with these issues, I'd still be very interested in seeing what they are cooking up. Paul Cheers, Dean -Original Message- From: [EMAIL PROTECTED] [mailto:community- [EMAIL PROTECTED] On Behalf Of Robin Paulson Sent: Monday, 11 June 2007 7:16 PM http://lipsforum.org/downloads/legal/LiPSInternalPolicay.pdf To: community Subject: standard API for linux phones? the register has a piece about a draft of a standard API for linux phones, concerning basics such as interaction with the address book, texting, ui and voice-calling. future revisons to increase the coverage http://www.theregister.co.uk/2007/06/11/lips_mobile_linux/ and from TFA http://www.lipsforum.org/ does anyone here have any further knowledge about this, beyond the blurb on the site? is it worth adhering to, or a thinly-veiled atttempt for one company (it's backed by orange) to foist propietary/their own standards on everyone else? does it compare at all to what the linux mobile group (backed by samsung, motorola and others) are trying to achieve? and of course, has it been considered for openmoko/the neo? ___ 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: standard API for linux phones?
On Tuesday 12 June 2007 08:19:34 Paul A. Lambert wrote: compatible this group is at least in philosophy. The participation is closed, the forum allows patented code (as long as the license is non-discriminatory). Even with these issues, I'd still be very interested in seeing what they are cooking up. From what I understood looking at their documents, they are currently soliciting a reference implementation of a Linux phone (software and hardware, OpenMoko should work for software and Neo might fit hardware, albeit they have something about a serial port in their requirements and VGA display is not clearly allowed, either). pgpemVd0bvieY.pgp Description: PGP signature ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
R: Concern for usability and ergonomics
Well I don't like this statement at all. Don't get me wrong, I can guess (some of) the reasons behind the plain words. But then I wonder whether there is really any transparency in the development of Neo/OpenMoko? What does it mean, being silent and talking in riddles seemingly for our own benefit? What about the collaborative FOSS effort, community involvement, etc? Br Michele -Messaggio originale- Da: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Per conto di Sean Moss-Pultz Inviato: lunedì 11 giugno 2007 19.01 A: Miguel A. Torres Cc: community@lists.openmoko.org; [EMAIL PROTECTED] Oggetto: Re: Concern for usability and ergonomics [snip] Believe me when I say that we are working on new stuff that will address these issues. I have been quiet for the past few months because of some major internal re-allocations and new events. Within about a month we should be more or less finished and emerge with far more focus and resources. Until then, please accept my sincere apology for not being able to keep up with all your comments and questions. Internally all my time and energy is being used now. -Sean ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Open Moko Themes
I think the first theme concern should be different resolutions. Currently there's just a VGA theme, but QVGA and WQVGA (i guess... 480x272 anyways) for future phones, and non-FIC phones. (most phones and PDAs are QVGA). At least I'd like to see that come soon. -- LuitvD On 6/12/07, Jon Phillips [EMAIL PROTECTED] wrote: On Mon, 2007-06-11 at 19:19 -0500, Tim Shannon wrote: I know that there are going to be themes for the OpenMoko interface, but I'm just wondering if there is anyone who has started working on alternate themes? I think I'd like to take a crack at it, and I was curious if anyone has had any start yet. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community I haven't, but OpenMoko team and I have discussed how the main theme is going to be CC BY-SA licensed. It would be great to get other interfaces licensed under CC BY or BY-SA tooo! Jon -- Jon Phillips San Francisco, CA USA PH 510.499.0894 [EMAIL PROTECTED] http://www.rejon.org MSN, AIM, Yahoo Chat: kidproto Jabber Chat: [EMAIL PROTECTED] IRC: [EMAIL PROTECTED] ___ 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: R: Concern for usability and ergonomics
On 12/06/07, Michele Manzato [EMAIL PROTECTED] wrote: Well I don't like this statement at all. Don't get me wrong, I can guess (some of) the reasons behind the plain words. But then I wonder whether there is really any transparency in the development of Neo/OpenMoko? What does it mean, being silent and talking in riddles seemingly for our own benefit? What about the collaborative FOSS effort, community involvement, etc? Br Michele I agree entirely regarding transparency etc. but there are two distinct problems here. FIC's responsibility to their employees and FIC's commitment to Neo/Openmoko. Re-allocation in large companies can be tricky and stressful for everyone involved if not handled properly. I imagine Sean is working hard to get everything he feels he needs to really pick up the pace on the Neo hardware. That said, given that we accept the Neo hardware is not vapourware, the community has plenty to be getting on with in terms of Openmoko. Lets keep faith in the passion that Sean has shown so far and keep providing encouragement for the core team. -Pete Good things come to those who wait :) -Messaggio originale- Da: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Per conto di Sean Moss-Pultz Inviato: lunedì 11 giugno 2007 19.01 A: Miguel A. Torres Cc: community@lists.openmoko.org; [EMAIL PROTECTED] Oggetto: Re: Concern for usability and ergonomics [snip] Believe me when I say that we are working on new stuff that will address these issues. I have been quiet for the past few months because of some major internal re-allocations and new events. Within about a month we should be more or less finished and emerge with far more focus and resources. Until then, please accept my sincere apology for not being able to keep up with all your comments and questions. Internally all my time and energy is being used now. -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: Web-based GUI technology for OpenMoko
WOW. I'm shocked. We were going the same way as how the iPhone works, without knowing any of it ! IP over USB kindof sucks on a Win box (have to install shitty drivers). UMS storage gives direct access to hardware storage. Which leaves BT Wifi for samba + webservices. The way i saw it, the best way to use the phone from a regular computer is exposing the internal fonctionality using desktop widgets and a web app. I bet there will be an OSX Dashboard widget for the iPhone, allowing to do everything without touching it. Please check out this project, which i find very interesting for this topic: http://gnetvibes.rubyforge.org If they are exposing services as local (and shareable) webservices, then it means their entire interface is webkit-based. They have OpenGL ES acceleration, it's a certitude now. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Open Moko Themes
Making your icons/panels/butons in svg-format and make a shell-script that (using imagemagick for example) converts all of them to the requered resolution in png. It shouldn't be the worry of the designer in what resolution use intend to use OpenMoko.The program/GTK should take care of that. On 6/12/07, Luit van Drongelen [EMAIL PROTECTED] wrote: I think the first theme concern should be different resolutions. Currently there's just a VGA theme, but QVGA and WQVGA (i guess... 480x272 anyways) for future phones, and non-FIC phones. (most phones and PDAs are QVGA). At least I'd like to see that come soon. -- LuitvD On 6/12/07, Jon Phillips [EMAIL PROTECTED] wrote: On Mon, 2007-06-11 at 19:19 -0500, Tim Shannon wrote: I know that there are going to be themes for the OpenMoko interface, but I'm just wondering if there is anyone who has started working on alternate themes? I think I'd like to take a crack at it, and I was curious if anyone has had any start yet. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community I haven't, but OpenMoko team and I have discussed how the main theme is going to be CC BY-SA licensed. It would be great to get other interfaces licensed under CC BY or BY-SA tooo! Jon -- Jon Phillips San Francisco, CA USA PH 510.499.0894 [EMAIL PROTECTED] http://www.rejon.org MSN, AIM, Yahoo Chat: kidproto Jabber Chat: [EMAIL PROTECTED] IRC: [EMAIL PROTECTED] ___ 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: The actual release date of NEO1973
On 6/6/07 6:07 PM, De Villiers, Jaco [EMAIL PROTECTED] wrote: Can you please tell me if you will be shipping to South Africa when the phone is released ? Also , at what time can we expect the phone to be released ? September ? Or closer to 2008 ? Thank you for your time We don't have these phones for sale yet. Please signup for our announce mailing list and we'll notify you as soon as we're ready. -Sean ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Open Moko Themes
UI for these different screen resolutions and potentially form factors is going to be more then a case of image resizing. It will be whole different layouts. I am quickly coming round to the idea of a near complete separation of GUI from application. It is the only way to really present the same apps on the different Openmoko hardware platforms. At the same time I am not convince that html is the way to go. What are the options here? -Pete On 12/06/07, Frank Coenen [EMAIL PROTECTED] wrote: Making your icons/panels/butons in svg-format and make a shell-script that (using imagemagick for example) converts all of them to the requered resolution in png. It shouldn't be the worry of the designer in what resolution use intend to use OpenMoko.The program/GTK should take care of that. On 6/12/07, Luit van Drongelen [EMAIL PROTECTED] wrote: I think the first theme concern should be different resolutions. Currently there's just a VGA theme, but QVGA and WQVGA (i guess... 480x272 anyways) for future phones, and non-FIC phones. (most phones and PDAs are QVGA). At least I'd like to see that come soon. -- LuitvD On 6/12/07, Jon Phillips [EMAIL PROTECTED] wrote: On Mon, 2007-06-11 at 19:19 -0500, Tim Shannon wrote: I know that there are going to be themes for the OpenMoko interface, but I'm just wondering if there is anyone who has started working on alternate themes? I think I'd like to take a crack at it, and I was curious if anyone has had any start yet. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community I haven't, but OpenMoko team and I have discussed how the main theme is going to be CC BY-SA licensed. It would be great to get other interfaces licensed under CC BY or BY-SA tooo! Jon -- Jon Phillips San Francisco, CA USA PH 510.499.0894 [EMAIL PROTECTED] http://www.rejon.org MSN, AIM, Yahoo Chat: kidproto Jabber Chat: [EMAIL PROTECTED] IRC: [EMAIL PROTECTED] ___ 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 ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Home Brew StarTrek Communicator
With the FCC 700 mhz spectrum coming up soon I thought some of you might like to join us for the Yi-Tan call next week? http://deancollinsblog.blogspot.com/2007/06/home-brew-startrek-communica tor.html Regards, Dean Collins Cognation Pty Ltd [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] +1-212-203-4357 Ph +61-2-9016-5642 (Sydney in-dial). ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Home Brew StarTrek Communicator
Dean Collins wrote: With the FCC 700 mhz spectrum coming up soon I thought some of you might like to join us for the Yi-Tan call next week? http://deancollinsblog.blogspot.com/2007/06/home-brew-startrek-communicator.html Unfortunately. Part of the reason mobile phones work reasonably well - 2W will get you some 15Km or so in good conditions - is that they have relatively low and controlled noise levels. The towers can have beam shaping and are closely planned, so they don't interfere overly with each other. The transmissions are closely scheduled, so that interference is greatly reduced. With no regulation, people will want applications like - for example - streaming music from their home server. Collision avoidance technologies help a little. But the problem is that you can't do collision avoidance of signals you can't recieve. But those signals still interfere. Consider an infinite plane of trancievers, evenly distributed. As you go away from the source, the contribution of an individual transmitter to your noise level falls off as the distance squared. But, the number of sources increases as the distance squared too. The noise sums to infinity. In practice, it won't be quite that bad - 700Mhz doesn't have infinite range, but it can reach hundreds of kilometers especially in some atmospheric conditions. I don't know how wide the band that is proposed is - say 20Mhz. Using really good coding, in good channel conditions, you may get 20 megabytes a second. Neglecting distant interference, and assuming collision avoidance works - you get possibly 10 megabytes/sec shared amongst the users. With a 2Km range (say) - if you've got phones scattered every 100m, then there are 300 or so phones in range. It doesn't take more than a few percent of these users to be doing stuff like streaming MP3 radio before it basically stops working. And then you get people who when their connection stops working, they ramp up the power, or ignore collision avoidance. It also gets worse as as the noise level rises, the bitrate drops rapidly. Mobile phones don't really have these problems, as they are closely controlled by the operator. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: Home Brew StarTrek Communicator
Hi Ian, Thanks for your input. As discussed in the article the concept of the freespace is to allocate bandwidth to devices that meet 'requirements' but is otherwise uncontrolled. Maybe it didn't come across in the blog but the idea is that in this space you can build alternative devices no longer controlled by a single entity like the carriers. But yes your comments about people stepping outside the rules are valid - hopefully you'll be able to join the conference call with your thoughts next week. Regards, Dean Collins Cognation Pty Ltd [EMAIL PROTECTED] +1-212-203-4357 Ph +61-2-9016-5642 (Sydney in-dial). -Original Message- From: Ian Stirling [mailto:[EMAIL PROTECTED] Sent: Tuesday, 12 June 2007 8:55 AM To: Dean Collins Cc: OpenMoko Subject: Re: Home Brew StarTrek Communicator Dean Collins wrote: With the FCC 700 mhz spectrum coming up soon I thought some of you might like to join us for the Yi-Tan call next week? http://deancollinsblog.blogspot.com/2007/06/home-brew-startrek- communicator.html Unfortunately. Part of the reason mobile phones work reasonably well - 2W will get you some 15Km or so in good conditions - is that they have relatively low and controlled noise levels. The towers can have beam shaping and are closely planned, so they don't interfere overly with each other. The transmissions are closely scheduled, so that interference is greatly reduced. With no regulation, people will want applications like - for example - streaming music from their home server. Collision avoidance technologies help a little. But the problem is that you can't do collision avoidance of signals you can't recieve. But those signals still interfere. Consider an infinite plane of trancievers, evenly distributed. As you go away from the source, the contribution of an individual transmitter to your noise level falls off as the distance squared. But, the number of sources increases as the distance squared too. The noise sums to infinity. In practice, it won't be quite that bad - 700Mhz doesn't have infinite range, but it can reach hundreds of kilometers especially in some atmospheric conditions. I don't know how wide the band that is proposed is - say 20Mhz. Using really good coding, in good channel conditions, you may get 20 megabytes a second. Neglecting distant interference, and assuming collision avoidance works - you get possibly 10 megabytes/sec shared amongst the users. With a 2Km range (say) - if you've got phones scattered every 100m, then there are 300 or so phones in range. It doesn't take more than a few percent of these users to be doing stuff like streaming MP3 radio before it basically stops working. And then you get people who when their connection stops working, they ramp up the power, or ignore collision avoidance. It also gets worse as as the noise level rises, the bitrate drops rapidly. Mobile phones don't really have these problems, as they are closely controlled by the operator. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Open Moko Themes
This is where XAML or XUL are particularly suited. The idea is that the UI will be mostly svg commands or in some cases images.. But rendered completely by the engine. Look up what you get for using it and you will see what I am talking about. There is work to be done getting XAML to function on linux.. But it would be worth the effort, IMHO. BTW, mono has started a project called moonlight which aims to bring silverlight applications to mono. Maybe we can help accelerate some of that work? --Tim On Tue, 12 Jun 2007 4:29, Peter A Trotter wrote: UI for these different screen resolutions and potentially form factors is going to be more then a case of image resizing. It will be whole different layouts. I am quickly coming round to the idea of a near complete separation of GUI from application. It is the only way to really present the same apps on the different Openmoko hardware platforms. At the same time I am not convince that html is the way to go. What are the options here? -Pete On 12/06/07, Frank Coenen [EMAIL PROTECTED] wrote: Making your icons/panels/butons in svg-format and make a shell-script that (using imagemagick for example) converts all of them to the requered resolution in png. It shouldn't be the worry of the designer in what resolution use intend to use OpenMoko.The program/GTK should take care of that. On 6/12/07, Luit van Drongelen [EMAIL PROTECTED] wrote: I think the first theme concern should be different resolutions. Currently there's just a VGA theme, but QVGA and WQVGA (i guess... 480x272 anyways) for future phones, and non-FIC phones. (most phones and PDAs are QVGA). At least I'd like to see that come soon. -- LuitvD On 6/12/07, Jon Phillips [EMAIL PROTECTED] wrote: On Mon, 2007-06-11 at 19:19 -0500, Tim Shannon wrote: I know that there are going to be themes for the OpenMoko interface, but I'm just wondering if there is anyone who has started working on alternate themes? I think I'd like to take a crack at it, and I was curious if anyone has had any start yet. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community I haven't, but OpenMoko team and I have discussed how the main theme is going to be CC BY-SA licensed. It would be great to get other interfaces licensed under CC BY or BY-SA tooo! Jon -- Jon Phillips San Francisco, CA USA PH 510.499.0894 [EMAIL PROTECTED] http://www.rejon.org MSN, AIM, Yahoo Chat: kidproto Jabber Chat: [EMAIL PROTECTED] IRC: [EMAIL PROTECTED] ___ 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 ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Home Brew StarTrek Communicator
Dean Collins wrote: Hi Ian, Thanks for your input. As discussed in the article the concept of the freespace is to allocate bandwidth to devices that meet 'requirements' but is otherwise uncontrolled. Maybe it didn't come across in the blog but the idea is that in this space you can build alternative devices no longer controlled by a single entity like the carriers. But yes your comments about people stepping outside the rules are valid - hopefully you'll be able to join the conference call with your thoughts next week. Possibly, though unlikely. IMO, this is the wrong fix. The right way is to make it easier for people to provide services on others networks, at a similar rate to what the internal costs of the provider are. However, this only really works for GSM devices. Long range popular communication without carriers is simply an almost intractable problem. Especially with no standards. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Web-based GUI technology for OpenMoko
On 6/11/07, Tim Newsom [EMAIL PROTECTED] wrote: Interesting... Web services... I wonder if that makes it possible to export the web service off the phone To a program running somewhere else... Or if its limited to some local channel. I think these services are available within the Safari context on the iPhone, there is no talk of having them be exportable directly. However with a javascript application you could post information back to a central web service to do things like location tracking. The public reaction seems to be negative overall, people wanted to be able to port their existing J2ME based apps to the iPhone. There isn't an existing base of mobile apps written in AJAX/Safari because there wasn't a platform until now. I think an interesting focus for the OpenMoko community is to figure out how to get a full AJAX capable browser (FireFox?) to run well enough on the device, and to build similar or identical web service interfaces to the phone functions, so that new AJAX apps written for the iPhone work on OpenMoko as well. Adrian And, anyway.. That only means you would have to wrap it in another, fully exportable, web service for such integration. --Tim On Mon, 11 Jun 2007 20:51, Matthew S. Hamrick wrote: Wow. once again Apple justifies our lead. On Jun 11, 2007, at 5:54 PM, adrian cockcroft wrote: Also, Apple's announcement today about iPhone development using AJAX and exposing internal phone functions as web services to the iPhone's safari browser is tipping everything in the same direction. Cheers Adrian On 6/11/07, Matthew S. Hamrick [EMAIL PROTECTED] wrote: Yeah... we're thinking that we were going to totally separate the model and domain processing from the view/controller part of the application. That way we could have a couple different HTML interfaces as well as a SVG/ECMAScript interface. I'm not terribly familiar with XAML or XUL, but I understand that most (if not all) of the Firefox / Mozilla / Navigator interface was written in XUL. This is one of the benefits to this approach, IMHO. Separating the interface allows us to experiment with a number of different interface technologies. And the only thing the experimenters need to know is the semantics and syntax of the XML interface. -Cheers! -Matt H. On Jun 11, 2007, at 9:18 AM, Tim Newsom wrote: If we are heading in the direction of web interfaces, I think we should look at XAML or XUL or something similar.From what I can tell, they will be adding silverlight support to mono, so using XAML will be possible.This also separates the code for functionality from the interface and can allow skinning of the entire application interface set. This will abstract you from every widget set.Each action could be exported and called from the UI without needing to worry about all that. At least, that's my take on it currently. --Tim On Mon, 11 Jun 2007 8:44, Florent THIERY wrote: Here's a little look-and-feel example that could be done with an opensource AJAX framework [javascript required]: http://demo.qooxdoo.org/current/showcase This may allow easier separation between apps and GUIs. Of course, as usual we have no idea how well such an app would perform (little gratuitous prediction: very bad), benchmarking is needed but ... who knows ? This is going along with the ongoings gdk webkit port and gsmd XmlHttpRequest interface (was topic: embedded webserver). What do you think ? Is it REALLY unrealistic ? Could anybody try the url on it's Nokia N770 (lots of happy owners here, right?) and rough feedback the responsiveness ? Cheers Florent ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Idea: emulate GSM-basestation/IMSI-Catcher?
Just some things that came to my mind concerning OpenMoko/the Neo: a) Is the GSM-modem capable of simulating a GSM-basestation? And if so... b) ... can the GSM-modem act as an 'IMSI-Catcher' http://en.wikipedia.org/wiki/IMSI-catcher ? c) If the GSM-modem is not able of doing the things mentioned above, could it be used for communication using the GSM-band but not some mobile service provider or one of their GSM-basestations with other (OpenMoko-enabled?-)phones? Like a regular walkie-talkie. Over the GSM-band ;-) d) What about law based frequency-regulations concerning c) ? tim/minime (Please don't bash me for having 'evil ideas'. Discussing the reasons for and against IMSI-catching is a different item, this is just about the feasibility.) ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: Open Moko Themes
Luit van Drongelen wrote: (most phones and PDAs are QVGA). Actually most phones sold today are 176 x 220, whereas most PDAs are QVGA. There's still a lot of phones today that are 128 x 160 and the Sidekick III is still 240 x 160. - John ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Openness (was RE: Concern for usability and ergonomics)
Michele Manzato wrote: Don't get me wrong, I can guess (some of) the reasons behind the plain words. But then I wonder whether there is really any transparency in the development of Neo/OpenMoko? One of the things I've seen while lurking on the list is the propensity for people to want Neo to be *exactly* what they want for their particular niche market/use. Whether or not it has a camera. Whether the accelerometers in GTA02 are accurate enough for inertial nav. Etc... When you design hardware by (large) committee, you don't get good results. Case in point is the Space Shuttle. Its design is a very non-optimal compromise between NASA's requirements for a manned medium-lift reusable shuttle and the US Department of Defense's requirements. NASA would probably have used a lifting body design had the DOD not required the ability to divert a planned Edwards landing to White Sands or one of the other secondary landing spots *after* reentry. And that's only one of the many, many compromises that made the shuttle more expensive and less capable than it could have been even with 1970's technology. Openness and transparency does not equate to everyone having a say in what the final feature set of the hardware is. It does not mean everyone on this list gets a vote. Nor does it mean that we get minutes of every meeting about new designs or even frequent status reports. What it does mean, to me, is that when they decide the feature set for the -03, -04, etc. handsets, that we know once they have crunched the features and cost and form factor to a point where they think they have something to plan for. It means this project where we have access to the entire phone stack, and are able to modify the software to tailor the phone to our niche markets. It means not having to get permission from the manufacturer to build an app for the phone (Hello Apple!). It means having a direct line of communication to the people actually building the thing for technical answers. I've been writing games on cell phones for four years. I'm now creating a lower level of software to be integrated at the OEM layer. I've seen just how hard (or impossible) it is to get this kind of support from the rest of the industry. This project is a unique collaboration between a manufacturer and open source. Let them do what they need to do to make the manufacturing decisions for their company. And thank them for the access they are giving within an industry that is extremely closed. By all means give them feedback, tell them your desires, etc. But please don't complain at them when they let you know that the GTA02 isn't the end of the line. That they're working on follow-up models. That they didn't put your must-have feature in the next rev. - John ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: Open Moko Themes
Tim Newsom wrote: This is where XAML or XUL are particularly suited. The idea is that the UI will be mostly svg commands or in some cases images.. But rendered completely by the engine. On Tue, 12 Jun 2007 4:29, Peter A Trotter wrote: UI for these different screen resolutions and potentially form factors is going to be more then a case of image resizing. It will be whole different layouts. Peter brings up a very good point. As images get smaller--because of fewer pixels available, not smaller pixels--it becomes much less reasonable to use scaled artwork. Whether that is SVG rendered into the smaller pixels or bitmaps resized, when you get down to the sizes required for today's common screen sizes, you need hand-tuned artwork. Working in the games industry since 1981, I've seen many kinds of artists. Most of today's artists do not have the skills to work at the pixel level. They may be wizards in Maya or 3DS Max, but couldn't design a 16 x 16 icon if their life depended on it--much less an animation in that many pixels. Having the combination of ability and patience to push the pixels around is a rare thing--but one absolutely necessary for a polished interface on a 1/8th VGA device. When we're dealing with a 300dpi VGA screen, the on-the-fly rendering from XML/SVG may be great. But it's not a panacea. On the other hand, I think it would be great to be able to not only skin individual apps, but be able to combine elements from multiple apps into one presentation. For example, suppose you had a CRM (customer relations) database wherein you kept notes about your clients. It would be great if the last note from that were available on the incoming call screen along with their name. But that would require a customized incoming call screen that aggregated the output of the dialer and the CRM app. At JavaOne there was a presentation on JSR 258 about a skinning architecture, but it only seemed to address appearance of elements, not layout nor the ability to combine features. - John ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openness (was RE: Concern for usability and ergonomics)
I agree definitely with the parts that I excerpted below from what John said, and would further like to point out what I personally see as one of the major strengths of this project: To show the world and other device makers that there can be a market for open mobile devices/phones. Of course this phone isn't going to be perfect or meet everyone's needs, but a successful neo means a better chance for OTHER open devices on which to run openmoko/software of one's choosing, beyond the revisions made to the neo. One of the things I've seen while lurking on the list is the propensity for people to want Neo to be *exactly* what they want for their particular niche market/use. Whether or not it has a camera. Whether the accelerometers in GTA02 are accurate enough for inertial nav. Etc... . . . This project is a unique collaboration between a manufacturer and open source. Let them do what they need to do to make the manufacturing decisions for their company. And thank them for the access they are giving within an industry that is extremely closed. By all means give them feedback, tell them your desires, etc. But please don't complain at them when they let you know that the GTA02 isn't the end of the line. That they're working on follow-up models. That they didn't put your must-have feature in the next rev. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openness (was RE: Concern for usability and ergonomics)
First, the mailing list is to be used for ideas and communication. You are absolutely correct that FIC will have to make the final decisions about what is and isn't included. However, suggesting that people shouldn't be expressing their interests about features no matter how niche/picky/whatever is just plain wrong. FIC will hopefully use some of the ideas (and mailing list reaction to those ideas) as a mini focus group to determine what features users will really want/use. There will always be complainers, that is just life...ignore them. Overall, I thought your post was full of fluff (and somewhat out of left field). On the other hand I was someone who posted my disappointment with the amount of communication that has been given back to us lately. Do they have to keep us in the loop? Absolutely not, most companies aren't even near this open about future products. However, my frustration (if you want to call it that) is the missed delivery date. They set a concrete date, missed it, and then just told us soon. I don't think that is very professional. I was going to put my disclaimer about how I am 100% for FIC and OpenMoko, but its on my original post so don't think that I am trying to bash Sean and the gang. I'm just disappointed at how the last three months have progressed. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SVHMPC] linux phone standard
Well... I used to work for PalmSource, one of the LiPS founding members. I've been trying to find something nice to say about LiPS for the last 24 hours and the best I can come up with is, It's not Microsoft. But yeah... my impression has always been that some of the companies involved (PalmSource) always believed that the value of their offering was based in the software. I would argue that the value of PalmOS is not in PalmOS itself, but in the community of users and developers that surrounded it. Motorola is used to dealing with proprietary mobile OSes and is only slowly coming to internalize some of the benefits of open source. So... my take on this is... the guys involved have a mental model of how successful products are built, and it involves dealing with the software group. These businesses have processes based on a risk model that puts the software group in a distant location from the hardware group. In my experience, companies that pay dogmatic attention to API standards outside of customer requirements don't last long (Posix and Win32 being possible exceptions.) Companies that pay close attention to customer requirements spend more of their time solving their customer's problems than going to meetings to discuss which options of which API calls will be supported. LiPS was formed by a group of software companies who, when given a kernel, a process model, a framebuffer device driver or two, and GTK, couldn't figure out how to make a compelling product, much less a platform. The LiPS guys will tell you that in order to create a development community, you've got to have a consistent API for developers to work with. I've always argued that given a compiler, an emulator, prototype hardware, a JTAG connector and enough stock options and coffee, skilled engineers can make anything work. What is difficult is for small, innovative companies to release their products in a market dominated by a few powerful players with long buying cycles. This is not to say that LiPS is irrelevant, just that as an ISV, I just don't see why it's that interesting. -Just my $0.02 -Cheers! -Matt H. On Jun 12, 2007, at 8:22 AM, Paul A. Lambert wrote: On Jun 12, 2007, at 6:53 AM, mtd wrote: hello, it seems that LiPS group tries to make linux phone specifications. http://arstechnica.com/news.ars/post/20070611-linux-phone-standards- group-to-publish-specifications.html Yes .. the specifications are now available: http:// www.lipsforum.org/index.php?option=contenttask=viewid=54 These are largely overviews, some doxygen output, and some header files. No code. You need to be a member to get the code :-( API standards are difficult to enforce, but could be useful to help align some of the most basic services for a phone (like the phone book). These specifications will be used for industry developed 'closed' phones. The 'open' community will need to produce similar parallel work not as APIs, but as code :-) The LiPS documents could server as an interesting starting point for some designs. Paul -- Martin Tomasek ___ SVHMPC mailing list [EMAIL PROTECTED] http://telefono.revejo.org/mailman/listinfo/ svhmpc_telefono.revejo.org Paul A. Lambert CTO, PicoMobile Networks, Inc. 256 Gibraltar Drive, Suite 108 Sunnyvale, CA, 94089 cell: +1-650-787-9141 ___ SVHMPC mailing list [EMAIL PROTECTED] http://telefono.revejo.org/mailman/listinfo/svhmpc_telefono.revejo.org ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: Openness (was RE: Concern for usability and ergonomics)
Jonathon Suggs wrote However, suggesting that people shouldn't be expressing their interests about features no matter how niche/picky/whatever is just plain wrong. I specifically said, in my summary paragraph: By all means give them feedback, tell them your desires, etc. But please don't complain at them when they let you know that the GTA02 isn't the end of the line. That they're working on follow-up models. That they didn't put your must-have feature in the next rev. Nothing in my comments suggested that people shouldn't give them suggestions. Just don't expect them all to make it into the phone or complain when they don't. There will always be complainers, that is just life...ignore them. It is, indeed, the complainers that I was commenting on. The one that I quoted was complaining that stuff was being hidden from us because FIC is working on new specs and hasn't shared them yet. However, my frustration (if you want to call it that) is the missed delivery date. They set a concrete date, missed it, and then just told us soon. I don't think that is very professional. Missed dates are not exceptional in this industry... - John ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SVHMPC] linux phone standard
Really well put, Matt. I agree with your analysis, and like you, for the past 24 hours have been trying to figure out why this doesn't seem like such a big deal. You have nicely expressed my feelings. Michael On Tue, 12 Jun 2007, Matthew S. Hamrick wrote: Well... I used to work for PalmSource, one of the LiPS founding members. I've been trying to find something nice to say about LiPS for the last 24 hours and the best I can come up with is, It's not Microsoft. But yeah... my impression has always been that some of the companies involved (PalmSource) always believed that the value of their offering was based in the software. I would argue that the value of PalmOS is not in PalmOS itself, but in the community of users and developers that surrounded it. Motorola is used to dealing with proprietary mobile OSes and is only slowly coming to internalize some of the benefits of open source. So... my take on this is... the guys involved have a mental model of how successful products are built, and it involves dealing with the software group. These businesses have processes based on a risk model that puts the software group in a distant location from the hardware group. In my experience, companies that pay dogmatic attention to API standards outside of customer requirements don't last long (Posix and Win32 being possible exceptions.) Companies that pay close attention to customer requirements spend more of their time solving their customer's problems than going to meetings to discuss which options of which API calls will be supported. LiPS was formed by a group of software companies who, when given a kernel, a process model, a framebuffer device driver or two, and GTK, couldn't figure out how to make a compelling product, much less a platform. The LiPS guys will tell you that in order to create a development community, you've got to have a consistent API for developers to work with. I've always argued that given a compiler, an emulator, prototype hardware, a JTAG connector and enough stock options and coffee, skilled engineers can make anything work. What is difficult is for small, innovative companies to release their products in a market dominated by a few powerful players with long buying cycles. This is not to say that LiPS is irrelevant, just that as an ISV, I just don't see why it's that interesting. -Just my $0.02 -Cheers! -Matt H. On Jun 12, 2007, at 8:22 AM, Paul A. Lambert wrote: On Jun 12, 2007, at 6:53 AM, mtd wrote: hello, it seems that LiPS group tries to make linux phone specifications. http://arstechnica.com/news.ars/post/20070611-linux-phone-standards- group-to-publish-specifications.html Yes .. the specifications are now available: http:// www.lipsforum.org/index.php?option=contenttask=viewid=54 These are largely overviews, some doxygen output, and some header files. No code. You need to be a member to get the code :-( API standards are difficult to enforce, but could be useful to help align some of the most basic services for a phone (like the phone book). These specifications will be used for industry developed 'closed' phones. The 'open' community will need to produce similar parallel work not as APIs, but as code :-) The LiPS documents could server as an interesting starting point for some designs. Paul ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
unbundling of phone services
sorry for the partly off-topic, slightly rambling post, but i feel this has partial relevance to openmoko one of the hot topics where i live (NZ), is LLU, unbundling of monopoly-controlled internet connections to the home/business, to allow any other companies to have access to the network at a fair price. this is seen by many as the holy grail of open internet access, spurring innovation and driving down prices. a number of countries where one company/entity has monopoly control of the lines have taken, or are about to take, this route. there has been lots of talk around the iphone/openmoko about what could potentially be done in the way of innovative use of mobile phone networks, but as the networks are locked down and controlled by their operators, there is very little considering how old/how pervasive the technologies are. so my question is: is there a similar movement anywhere for the equivalent of LLU for mobile phone networks? i.e. allowing other operators to use networks of vodafone/state-owned telco/sprint/whoever at reasonable price? most countries don't have monopolies providing mobile services (even nz has 2 providers), but they still act as though they are monoplies, providing (in my experience) vastly overpriced, very limited services at the moment, the innovative things that could potentially be done are restricted to using wi-fi connections, but wi-fi is not anywhere near as pervasive as gsm/cdma coverage ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: Openness (was RE: Concern for usability and ergonomics)
You are all going to become slaves of capitalists (Sean on behalf of FIC). Better to support guys from xda-developers.com (like cr2) to make machines like HTC Universal a real free phones Milan At 22:51 12.6.2007, you wrote: Jonathon Suggs wrote However, suggesting that people shouldn't be expressing their interests about features no matter how niche/picky/whatever is just plain wrong. I specifically said, in my summary paragraph: By all means give them feedback, tell them your desires, etc. But please don't complain at them when they let you know that the GTA02 isn't the end of the line. That they're working on follow-up models. That they didn't put your must-have feature in the next rev. Nothing in my comments suggested that people shouldn't give them suggestions. Just don't expect them all to make it into the phone or complain when they don't. There will always be complainers, that is just life...ignore them. It is, indeed, the complainers that I was commenting on. The one that I quoted was complaining that stuff was being hidden from us because FIC is working on new specs and hasn't shared them yet. However, my frustration (if you want to call it that) is the missed delivery date. They set a concrete date, missed it, and then just told us soon. I don't think that is very professional. Missed dates are not exceptional in this industry... - John ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: unbundling of phone services
On 6/12/07, Robin Paulson [EMAIL PROTECTED] wrote: so my question is: is there a similar movement anywhere for the equivalent of LLU for mobile phone networks? i.e. allowing other operators to use networks of vodafone/state-owned telco/sprint/whoever at reasonable price? most countries don't have monopolies providing mobile services (even nz has 2 providers), but they still act as though they are monoplies, providing (in my experience) vastly overpriced, very limited services If I understood you correctly, there is something like this in the US. These mobile carriers are called MVNOs (Mobile virtual network operators -- http://en.wikipedia.org/wiki/MVNO ). There are a number of options for service from MVNOs, but it's nearly all prepaid. The MVNOs in the US were reviewed by C-Net, and you can read about it here: http://reviews.cnet.com/4520-3504_7-6260217-5.html?tag=arw . It definitely feels like you're making a deal with devil when you sign up for any kind of mobile service anywhere. I just bought a T-Mobile prepaid phone, but I haven't used a US carrier yet so I'm not sure what to expect. My best experience so far was with Vodafone in Japan, but when I was in Australia, Optus wasn't too bad. Joe ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
AW: unbundling of phone services
Well unbundling of the last mile certainly helps getting a competition going in DSL lines. OTOH, it's still unclear what produces a competitive mobile market. Comparing Austria with Germany, Austria traditionally had better deals than Germany, despite lacking virtual operators for a long time. The differences are that stricking, that I've used my Austrian SIM card for over a year in roaming till I found a calling plan that makes at least so sense for me. OTOH, not everything is clear cut, e.g. Austrian operators still do not have a 100% real UMTS flat rate, while such data plans are available in Germany for some years now. Hard to understand what drives competition in mobile markets :( Andreas -- Ursprüngl. Mitteil. -- Betreff:unbundling of phone services Von:Robin Paulson [EMAIL PROTECTED] Datum: 12.06.2007 21:27 sorry for the partly off-topic, slightly rambling post, but i feel this has partial relevance to openmoko one of the hot topics where i live (NZ), is LLU, unbundling of monopoly-controlled internet connections to the home/business, to allow any other companies to have access to the network at a fair price. this is seen by many as the holy grail of open internet access, spurring innovation and driving down prices. a number of countries where one company/entity has monopoly control of the lines have taken, or are about to take, this route. there has been lots of talk around the iphone/openmoko about what could potentially be done in the way of innovative use of mobile phone networks, but as the networks are locked down and controlled by their operators, there is very little considering how old/how pervasive the technologies are. so my question is: is there a similar movement anywhere for the equivalent of LLU for mobile phone networks? i.e. allowing other operators to use networks of vodafone/state-owned telco/sprint/whoever at reasonable price? most countries don't have monopolies providing mobile services (even nz has 2 providers), but they still act as though they are monoplies, providing (in my experience) vastly overpriced, very limited services at the moment, the innovative things that could potentially be done are restricted to using wi-fi connections, but wi-fi is not anywhere near as pervasive as gsm/cdma coverage ___ 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: Openness (was RE: Concern for usability and ergonomics)
Seems like xda-developers.com is focused on reverse engineering cell phones. Specifically because the company that made those phones wouldn't give them the information. And that's better than FIC how? FIC is giving us the information! How is that bad? -Steven On 6/12/07, Milan Votava [EMAIL PROTECTED] wrote: You are all going to become slaves of capitalists (Sean on behalf of FIC). Better to support guys from xda-developers.com (like cr2) to make machines like HTC Universal a real free phones Milan ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openness (was RE: Concern for usability and ergonomics)
Becose is clear who is a foe and who is a friend Sorry you are to blinded to understand... At 00:31 13.6.2007, Steven ** wrote: Seems like xda-developers.com is focused on reverse engineering cell phones. Specifically because the company that made those phones wouldn't give them the information. And that's better than FIC how? FIC is giving us the information! How is that bad? -Steven On 6/12/07, Milan Votava [EMAIL PROTECTED] wrote: You are all going to become slaves of capitalists (Sean on behalf of FIC). Better to support guys from xda-developers.com (like cr2) to make machines like HTC Universal a real free phones Milan ___ 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: Openness (was RE: Concern for usability and ergonomics)
(correction) Because is clear who is a foe and who is a friend Sorry, you are already too blinded to understand... At 00:31 13.6.2007, Steven ** wrote: Seems like xda-developers.com is focused on reverse engineering cell phones. Specifically because the company that made those phones wouldn't give them the information. And that's better than FIC how? FIC is giving us the information! How is that bad? -Steven On 6/12/07, Milan Votava [EMAIL PROTECTED] wrote: You are all going to become slaves of capitalists (Sean on behalf of FIC). Better to support guys from xda-developers.com (like cr2) to make machines like HTC Universal a real free phones Milan ___ 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: Clarification Rant
On 6/8/07, Jonathon Suggs [EMAIL PROTECTED] wrote: I understand being careful with what you say, but even something like We've built X devices with a defect ratio of Y. We want that ration to be Z before we push the production line full steam ahead would be promising. That is unless X=0 Y=100 and Z is anything greater than zero, THEN we'd be a little disappointed. I also agree. But right now I do not believe we will get the phone before September/October (just a feeling). If it was a little problem, I believe they would keep us informed. I don't know why they don't inform us but I also don't know what the problem is. Anyway... I am really excited and I check several times each day (I have done that since January). I hope it will become available soon. If the problem is software related, I personally think they should not hold the device back. There is many great developers out here that is ready to hack the device. I don't want to sound negative I am just really excited. I think Sean and the rest of the team is working really hard now to find a solution to whatever the problem might be. They are under a lot of pressure and they don't need a lot of demotivating complains. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: unbundling of phone services
A Mobile LLU (Local Loop Unbundling) system would be slightly different that an MVNO. MVNO's mostly differentiate themselves on branding instead of services. LLU is what you get when you force ILECs (Incumbent Local Exchange Carriers) to allow third parties to connect to the local loop (the wire running from the carrier's central office to the customer premises.) The mobile equivalent would be to force the wireless network operators to provide value add third parties with rack space in mobile base-stations or like UNE/P an ATM interface to data, video or voice data from the handset without passing it through the carrier's network. Some of the services you could expect from such a setup would be: a. you could pick your long distance company for your mobile phone the same way you pick your long distance company for your wireline (at least in the US.) But since virtually all mobile plans now include free long distance calling, the only time this would be interesting is if you did a lot of international calling. b. enhanced 411 service. I'm on t-mobile, and their 411 service totally, absolutely, completely blows. It should be straight-forward with LLU to, on a per-subscriber basis, route 411 calls to non- sucktastic competitors. c. Mobile to Skype interface. d. MMC (Mobile to Mobile Convergence) - In theory, if I was able to put one of my boxes on the SS7 network managed by the carrier, I could advertise a SIP like service that would let me do UMA-like handoff between my home / office WiFi network and the cell network. Such services tend to give the carriers fits, so you're unlikely to see anything like this in the near future. Well... not from the established carriers anyway. They wound up overpaying for spectrum back in the 90's and are still looking for ways to amortize that cost. MVNOs on the other hand, essentially resell the mobile services provided by an established carrier, but use their own billing systems and marketing channels. -Cheers -Matt H. On Jun 12, 2007, at 2:54 PM, Joe Friedrichsen wrote: On 6/12/07, Robin Paulson [EMAIL PROTECTED] wrote: so my question is: is there a similar movement anywhere for the equivalent of LLU for mobile phone networks? i.e. allowing other operators to use networks of vodafone/state-owned telco/sprint/whoever at reasonable price? most countries don't have monopolies providing mobile services (even nz has 2 providers), but they still act as though they are monoplies, providing (in my experience) vastly overpriced, very limited services If I understood you correctly, there is something like this in the US. These mobile carriers are called MVNOs (Mobile virtual network operators -- http://en.wikipedia.org/wiki/MVNO ). There are a number of options for service from MVNOs, but it's nearly all prepaid. The MVNOs in the US were reviewed by C-Net, and you can read about it here: http://reviews.cnet.com/4520-3504_7-6260217-5.html?tag=arw . It definitely feels like you're making a deal with devil when you sign up for any kind of mobile service anywhere. I just bought a T-Mobile prepaid phone, but I haven't used a US carrier yet so I'm not sure what to expect. My best experience so far was with Vodafone in Japan, but when I was in Australia, Optus wasn't too bad. Joe ___ 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: Openness (was RE: Concern for usability and ergonomics)
Am Mittwoch, 13. Juni 2007 00:31 schrieb Steven **: Seems like xda-developers.com is focused on reverse engineering cell phones. Specifically because the company that made those phones wouldn't give them the information. And that's better than FIC how? HTC phones are commodity hardware that anybody can buy right here and right now. Linux on HTC Universal supports WIFI and UMTS _today_ ( http://handhelds.org/moin/moin.cgi/UniversalStatus ) Unfortunately many people prefer to whine about the features of future unreleased devices, instead of writing some productivity software useful for the end-users ;-) Oleg. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openness (was RE: Concern for usability and ergonomics)
(sorry for my english) I'm subscribed for this this thread for about 6m now. I don't want to be rude but: 1/ 99% of this thread is about an unrealistic things to be implemented on a non existent (underpowered) device. Who in the World cares about things being discussed in this thread? People wants to use their pones, to make calls, send sms/mms/emails. I'm being tired to read over and over about these obscure requirements and ideas posted here. Animations like on an iPod? Buy an iPod! 2/ I believe we are going to be a victims of a huge manipulation. There is a company like FIC. There are some adventures like Sean who are looking for their fortune. What's the way? To offer to companies like FIC a product like Neo with reduced costs. Why the costs are reduced? It's simple. There is bunch of people around the globe waiting to spare their time to help. You just have to pretend to be one of them 3/ As you can see, the 'openness' of this project is at least in question. As time goes by, there is more blah blah then some concrete information. There are some vague information about GTA1/GTA2 but overall, the entropy is going to 0. Milan At 01:02 13.6.2007, Andrew Becherer wrote: My mother told me to never feed the trolls but when I see an obvious misrepresentation of the opensource and free software movements I have to pipe up for posterity and the google cache. Not to knock the work of people like cr2 (who based on a Google query is an awesome resource for Linux on proprietary handsets) but xda-developers.com is an entirely different ball of wax than OpenMoko. I once had the opportunity to meet with Peter Brown (the executive director of the Free Software Foundation). Peter told me that one of the greatest things about Richard Stallman is his role as a reference point for all of us involved in opensource and free software. We can each measure how free we are based on where we place ourselves as compared to RMS. He is THE free software benchmark. That said Richard Stallman stated his only objection to the Neo1973 and OpenMoko was the closed source GPS code. The Neo1973 and OpenMoko are just about as free as a phone can be and it is my understanding that the GPS code can be replaced with free software thereby making it a free phone! Let's compare this to the xda-developers site. Currently on the front page of xda-developers is the following news item: For years and years, xda-developers has offered access to a collection of ROM images for 'our' phones. These images, often released by mobile carriers or device resellers, contained a version of the Microsoft Windows Mobile OS (or one of its predecessors) as well as customization added by one or more OEMs in the chain. FIC with its Neo1973 hardware and OpenMoko with free software are creating a truly open platform. Trading in hacked up images of proprietary software distributed against the terms of the licensing agreements isn't the type of freedom of which I would want a point. Should the Neo and OpenMoko come to pass they will be a true alternative to proprietary phones. FIC and the all developers who participate in the development of OpenMoko should be applauded and remarks such as yours should be ignored. -- Andrew Becherer Undergraduate, Computing and Software Systems University of Washington, Tacoma ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openness (was RE: Concern for usability and ergonomics)
damn, wrong address, sorry oleg. repost. twice can someone at openmoko fix the auto-generated reply-to fields on this mailing-list? every time this gets me On 6/13/07, Oleg Gusev [EMAIL PROTECTED] wrote: HTC phones are commodity hardware that anybody can buy right here and right now. Linux on HTC Universal supports WIFI and UMTS _today_ ( http://handhelds.org/moin/moin.cgi/UniversalStatus ) Unfortunately many people prefer to whine about the features of future unreleased devices, instead of writing some productivity software useful for the end-users ;-) two words: microsoft tax impressive specs though as a sidenote, the familiar project which they are using on these devices probably overlaps with openmoko. http://familiar.handhelds.org/ are we duplicating work? familiar is 6+ years old, i'm sure they must have some good ideas that can be used? maybe we can make openmoko a fork from their project? ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: unbundling of phone services
From: Matthew S. Hamrick [EMAIL PROTECTED] A Mobile LLU (Local Loop Unbundling) system would be slightly different that an MVNO. MVNO's mostly differentiate themselves on branding instead of services. LLU is what you get when you force ILECs (Incumbent Local Exchange Carriers) to allow third parties to connect to the local loop (the wire running from the carrier's central office to the customer premises.) The mobile equivalent would be to force the wireless network operators to provide value add third parties with rack space in mobile base-stations or like UNE/P an ATM interface to data, video or voice data from the handset without passing it through the carrier's network. One huge difference I see between a wired CLEC and a mobile LLU as you describe it is that a CLEC can start small by putting equipment into the COs of a single marketing area and potentially have a viable product. I have trouble seeing too many customers getting exciting about a mobile product that has spiffy features but can't roam, so you need to put equipment in an awful lot of racks. Or am I missing something? --Jon Radel smime.p7s Description: S/MIME Cryptographic Signature ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openness (was RE: Concern for usability and ergonomics)
Am Mittwoch, 13. Juni 2007 01:42 schrieb Robin Paulson: are we duplicating work? familiar is 6+ years old, i'm sure they must have some good ideas that can be used? maybe we can make openmoko a fork from their project? Robin, please read down to the bottom of the status page. All modern GUI environments (openmoko,gpe,opie and qtopia/opie2) are supported. Oleg. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openness (was RE: Concern for usability and ergonomics)
On 6/13/07, Milan Votava [EMAIL PROTECTED] wrote: (sorry for my english) I'm subscribed for this this thread for about 6m now. I don't want to be rude but: why so long? you must be interested or you would have long since left 1/ 99% of this thread is about an unrealistic things to be why are they unrealistic? think big implemented on a non existent (underpowered) device. Who in the World non-existent? lots of hardware units around - sun has one, they think it's useful/important. developers have them. it's a step. we've seen hardware revs already. there will be more. openmoko isn't limited to neo, it will expand cares about things being discussed in this thread? People wants to me. lots of others use their pones, to make calls, send sms/mms/emails. I'm being tired to read over and over about these obscure requirements and ideas couldn't give a monkey's how obscure it it. you want to do what mainstream does, fine. i want to do this stuff. i like doing it in itself, and it's useful to me as well. freedom to tinker posted here. Animations like on an iPod? Buy an iPod! no. too expensive. too closed. unreliable. apple and their users are smug gits. can do better 2/ I believe we are going to be a victims of a huge manipulation. maybe. i'm after a product. if i have to jump through hoops, that's fine as long as i think the steps are worthwhile There is a company like FIC. There are some adventures like Sean who are looking for their fortune. What's the way? To offer to companies like FIC a product like Neo with reduced costs. Why the costs are reduced? It's simple. There is bunch of people around the globe waiting to spare their time to help. You just have to pretend to be one of them how are they pretending? they've been a lot more open than most phone manufacturers? they're smart - give a little, take a little. sharing 3/ As you can see, the 'openness' of this project is at least in some of it, possibly. do not judge all of it on recent happenings. i'm confident sean will give more details when they pass the current roadblock question. As time goes by, there is more blah blah then some concrete information. There are some vague information about GTA1/GTA2 but overall, the entropy is going to 0. not vague. we know the new proc, the accelerometer details, wireless chipset and some other stuff. more will come out, i would expect it to be incremental. see the bigger picture ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: Openness (was RE: Concern for usability and ergonomics)
Milan Votava writes: You are all going to become slaves of capitalists (Sean on behalf of FIC). Better to support guys from xda-developers.com (like cr2) to make machines like HTC Universal a real free phones Better to work on a machine in spite of the manufacturer rather than with the manufacturer? I don't follow. The day FIC wants me to sign an NDA or claims ownership of my code, I'll agree with the slaves of capitalists comment. I don't see any prospect of that happening. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openness (was RE: Concern for usability and ergonomics)
Milan Votava writes: 1/ 99% of this thread is about an unrealistic things to be implemented on a non existent (underpowered) device. Who in the World cares about things being discussed in this thread? People wants to use their pones, to make calls, send sms/mms/emails. I'm being tired to read over and over about these obscure requirements and ideas posted here. Animations like on an iPod? Buy an iPod! I care. I don't really care if nobody else does. I really don't care what people want. What *I* want is the potential that PalmOS had at one time, for me to be able to not just make phone calls, but also to develop and install what I want. Being able to listen to music without buying a second device will be nice, but it's not really the point. 2/ I believe we are going to be a victims of a huge manipulation. There is a company like FIC. There are some adventures like Sean who are looking for their fortune. What's the way? To offer to companies like FIC a product like Neo with reduced costs. Why the costs are reduced? It's simple. There is bunch of people around the globe waiting to spare their time to help. You just have to pretend to be one of them I think my eyes are wider open than you think they are. Yes, FIC gets what you're suggesting out of the deal. But I get what I asked for in the first paragraph of my response. I understand that, and I regard it as a fair trade (for myself, anyway). The idea that somehow I'm better off working on reverse-engineering a phone so the company doesn't get any benefit... escapes me. I've done enough reverse-engineering, thanks. I'd prefer to never do it again. 3/ As you can see, the 'openness' of this project is at least in question. As time goes by, there is more blah blah then some concrete information. There are some vague information about GTA1/GTA2 but overall, the entropy is going to 0. Yes, I'd like more details on exactly where the problems are. But this is so far ahead of what I've seen from any other compnay, I'm not terribly worried. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openness (was RE: Concern for usability and ergonomics)
Joe Pfeiffer wrote: Milan Votava writes: You are all going to become slaves of capitalists (Sean on behalf of FIC). Better to support guys from xda-developers.com (like cr2) to make machines like HTC Universal a real free phones Better to work on a machine in spite of the manufacturer rather than with the manufacturer? I don't follow. The day FIC wants me to sign an NDA or claims ownership of my code, I'll agree with the slaves of capitalists comment. I don't see any prospect of that happening. im guessing its something like: better to have a device out there in the hands of people that you can free, then a device with high hopes that never shows up in many hands. or whatever... to me it sounds like a donkey chasing a carrot on a stick. the stick will always be just out of reach. unlike the PC market, where commodity parts are everywhere, and if you dont like what dell, HP and other sell preassembled you can do your own, the mobile market is about locked down devices that, after its made, cant change no matter what. hell, my guess is that by the time xda-developers.org is done, HTC have a new and better device out that people will flock to. one that the xda firmware cant work on, or at best will have some nasty flaws. and so the cycle starts again. at best one is squeezing a couple of extra years out of a obsolete device. but the neo seems to be designed from day one to be made from virtually of the shelf parts. FIC is just the hired factory (like how apple do for their stuff or microsoft does for the xbox's), they hold no copyright or patent on the neo iirc. so if FIC comes up short, one can take the parts and find some other factory willing to have a go at it. until we get home assembly kits for mobiles, thats the second best option. hell, it got a usb port that can run in host mode. can someone point me to a windows smartphone that have a similar option? it means that with the right drivers one can plug virtually any usb device into the neo and have it work. sounds to me like it can be molded into doing a lot of things. maybe if one could get it to charge of a solar cell it can act as a mobile modem for usb connected sensor ecquipment or similar. but in the end i dont care what hardware it runs on as long as it has a code core thats open to anyone to modify after their liking. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
OpenMoko != Neo1973 (Was: Openness (was RE: Concern for usability and ergonomics))
kenneth marken wrote: but the neo seems to be designed from day one to be made from virtually of the shelf parts. FIC is just the hired factory (like how apple do for their stuff or microsoft does for the xbox's), they hold no copyright or patent on the neo iirc. so if FIC comes up short, one can take the parts and find some other factory willing to have a go at it. FIC owns the hardware design. They are not just a hired factory. You can be sure that they very much *do* hold copyright and perhaps patents on the hardware design. And that has *nothing* to do with the openness of OpenMoko. OpenMoko is a software distribution, not a hardware design. OpenMoko (the registered organisation, separate from FIC the company who is creating the first piece of hardware designed for the OpenMoko software) never promised open hardware. They promised open software (the OpenMoko software, which is being developed *completely* in the open), and they gave some dates that they *expected* (not promised) FIC (the hardware company) to be ready to sell some hardware (the Neo1973) that the OpenMoko software runs on. People on this list should remember that OpenMoko is a piece of software which has been freely available and developed in the open for months now, not an FIC hardware device (which may or may not be delivered by the hardware company on a particular date). When there are multiple devices available from multiple manufacturers, this will all be much clearer. But in the meantime, please keep the distinction between OpenMoko (a piece of software) and the Neo1973 (just one of the hardware platforms on which OpenMoko can run) clear. If you want to complain about Neo1973 delays, then call them Neo1973 delays, not OpenMoko delays. If you want to complain that FIC doesn't share the hardware circuit diagrams with you, then tough - they never promised to, and I expect they never will. If you want complain about OpenMoko, then get your terminology correct first, cause OpenMoko exists today in an SVN repository that anyone can download and contribute to. If you think you can get an openmoko-compatible hardware platform to market quicker than FIC can, then please do so (either by reverse-engineering an existing closed phone, or creating your own open phone). See if you can beat FIC to the punch! OpenMoko is about the software, not which hardware platform happens to appear first. -- Rod (not employed by FIC or OpenMoko) ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Neo1973 Update!
[EMAIL PROTECTED] skrev: the GPS daemon would need to be updated to allow for kallman filtering using those accelerometers, so that the GPS apps could continue pointing the phones location inside tunnels and stuff Unfortunately not. As already pointed out on that list, the accelerometers error would add up itself. But if it's as good as GPS for 10-15 sec it should be possible to interpolate 10 - 15 GPS measurements while on the move. Must move fast enough so the start vector can be known. But while moving so fast the accelerometers can be calibrated over time by GPS data cramming absolutely maximum accuracy from them! Maybe detect moving in and out of GPS echoes and compensate the results to. It will also add real time info on acceleration making it easier to detect shift of line, change in speed (warn if a speed limit is up ahead). While still or moving slowly - orientation will be lost :-( But for car navigation it will be a boost! And for games... Think flipper with tilt :-) Besides: Its only two accelerometers. You can do 2-dimensional 'navigating' with that, no more. No tilting/rotating. Thats assuming each accelerometer is a single point. But if the tree axes is measured with a small offset from each other? That would give more info so thats how I guess they are built. /LaH ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: unbundling of phone services
Yeah... good point. I believe one of the ways the UNE system could be configured was where data from the subscriber was transported to a distant physical location via ATM, SoNet, etc. In fact, most of the centralized modem banks in the states were replaced with banks of modems at each CO. Modem calls were terminated at the CO and data was carried over frame relay over ATM to various ISPs. This made sense for the ILECs as it cut down on the number of circuits that had to traverse the network. So that could be a model. Maybe the third party equipment could be located at the carrier's data center and hook directly into their terrestrial SS7 network. That way it would be accessible to the whole network. -Cheers -Matt H. On Jun 12, 2007, at 4:49 PM, Jon Radel wrote: From: Matthew S. Hamrick [EMAIL PROTECTED] A Mobile LLU (Local Loop Unbundling) system would be slightly different that an MVNO. MVNO's mostly differentiate themselves on branding instead of services. LLU is what you get when you force ILECs (Incumbent Local Exchange Carriers) to allow third parties to connect to the local loop (the wire running from the carrier's central office to the customer premises.) The mobile equivalent would be to force the wireless network operators to provide value add third parties with rack space in mobile base-stations or like UNE/P an ATM interface to data, video or voice data from the handset without passing it through the carrier's network. One huge difference I see between a wired CLEC and a mobile LLU as you describe it is that a CLEC can start small by putting equipment into the COs of a single marketing area and potentially have a viable product. I have trouble seeing too many customers getting exciting about a mobile product that has spiffy features but can't roam, so you need to put equipment in an awful lot of racks. Or am I missing something? --Jon Radel ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: OpenMoko != Neo1973 (Was: Openness (was RE: Concern for usability and ergonomics))
On 6/12/07, Rod Whitby [EMAIL PROTECTED] wrote: OpenMoko (the registered organisation, separate from FIC the company who is creating the first piece of hardware designed for the OpenMoko software) never promised open hardware. They promised open software (the OpenMoko software, which is being developed *completely* in the open), and they gave some dates that they *expected* (not promised) FIC (the hardware company) to be ready to sell some hardware (the Neo1973) that the OpenMoko software runs on. Yes, most of the hardware designs and schematics aren't distributed, but there are shadows of scraps here and there thanks to Werner ( http://svn.openmoko.org/developers/werner/usb-pullup/new.spice ). The Neo appears to be a well-assembled collection of chips and parts not designed or fabbed by FIC. They took some Legos and made a remarkable product. It's like a capstone design project on steriods. Given that this phone is meant to be opened and tinkered with, I imagine that schematics could be drafted without too much strain. The phone could then be //conceivably// reproduced. However, I don't know at this point how valuable open hardware would to an individual be since silicon and copper aren't that easily modified or produced at home. Quality surface-mount soldering and RF noise are just a few of the smaller hurldes to jump over. Software has the advantage for now :-) Those simple text files are just too easy to change! Until we get our own fab-labs, Joe ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: OpenMoko != Neo1973 (Was: Openness (was RE: Concern for usability and ergonomics))
Joe Friedrichsen wrote: Yes, most of the hardware designs and schematics aren't distributed, Actually, I hope that we can release at least schematics of the debug board and the immediate surroundings of the MCU. There seems to be a lot of red tape surrounding all this, though :-( but there are shadows of scraps here and there thanks to Werner ( http://svn.openmoko.org/developers/werner/usb-pullup/new.spice ). Oh, that one. Don't worry, that never made it into hardware. What we currently have (in GTA02) is the circuit depicted in gates.fig In general, developers/werner/ is my personal junkyard, and I'm a messy person. So please don't jump to conclusions when sifting through it. - Werner -- _ / Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] / /_http://www.almesberger.net// ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: OpenMoko != Neo1973 (Was: Openness (was RE: Concern for usability and ergonomics))
Joe Friedrichsen wrote: Given that this phone is meant to be opened and tinkered with I'm not sure that that is actually the case. (Sean, please correct me if I am wrong in the following - I will be pleasantly surprised if you are able to do so). Yes, the OpenMoko software is meant to be fully open and tinkered with. No doubt about that at all. I haven't read anything in the OpenMoko manifesto (i.e. Sean's public slides on what OpenMoko is all about) about the project having a specific goal of designing the hardware to be open and tinkered with in general. Yes, there are instances where it seems that hardware design decisions have been made to allow access to standard interfaces like SPI, Serial, JTAG, for the knowledgeable community hardware developer to use (concidentally, those same interfaces are the ones that the original device hardware designers need access to anyway, so it could easily be just a happy by-product of good engineering), but that's very different from a phone that is meant to be opened and tinkered with in a general mass-market sense of that term (which may not be what you intended - I'm just making the distinction clear rather than disagreeing with you specifically). All I'm saying is that it is very clear that OpenMoko (the software) is meant to be fully open, and we should complain loudly if we see anything about the software which is not open (both in the code itself, and the development processes which create and maintain that code). It is not clear at all that the same holds for the hardware (and the processes required to design, manufacture, market and sell that hardware). We should be pleasantly surprised if *any* of that is open, cause that is not what was promised by the OpenMoko concept. We certainly (in my opinion) do *not* have the right to complain when something related to the development of the hardware by FIC (as opposed to the development of the OpenMoko software) is not open. Open hardware development was never promised - only open software development was promised. You can bet that in the future there will probably be totally closed hardware designs which run the totally open OpenMoko software. -- Rod ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: OpenMoko != Neo1973 (Was: Openness (was RE: Concern for usability and ergonomics))
On Tue, 12 Jun 2007, Joe Friedrichsen wrote: On 6/12/07, Rod Whitby [EMAIL PROTECTED] wrote: OpenMoko (the registered organisation, separate from FIC the company who is creating the first piece of hardware designed for the OpenMoko software) never promised open hardware. They promised open software (the OpenMoko software, which is being developed *completely* in the open), and they gave some dates that they *expected* (not promised) FIC (the hardware company) to be ready to sell some hardware (the Neo1973) that the OpenMoko software runs on. Yes, most of the hardware designs and schematics aren't distributed, but there are shadows of scraps here and there thanks to Werner ( http://svn.openmoko.org/developers/werner/usb-pullup/new.spice ). The Neo appears to be a well-assembled collection of chips and parts not designed or fabbed by FIC. They took some Legos and made a remarkable product. It's like a capstone design project on steriods. Given that this phone is meant to be opened and tinkered with, I imagine that schematics could be drafted without too much strain. The phone could then be //conceivably// reproduced. However, I don't know at this point how valuable open hardware would to an individual be since silicon and copper aren't that easily modified or produced at home. Quality surface-mount soldering and RF noise are just a few of the smaller hurldes to jump over. Software has the advantage for now :-) Those simple text files are just too easy to change! Until we get our own fab-labs, Joe Good points, Joe and Rod. To add to this, consider that this device has a JTAG port, and that you can buy the necessary interface card and cable for $150, and that the debugger is open source. So even with though the hardware was not promised to be open, we have tremendous visibility into it. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
