RE: atomic clock / radio-receiver chip
I have one (or something equivalent) in my watch (Casio Pathfinder Wave Ceptor). It synchronizes the time of my watch every night at midnight. /shrug --Tim -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of cdr Sent: Sunday, June 01, 2008 11:26 AM To: community@lists.openmoko.org Subject: atomic clock / radio-receiver chip And portable thermonuclear bomb. Just in case. (Well, phone is already hand interface to several orbital atomic clocks, isn't it?) the atomic clock(s) arent orbiting the earth, to receive the one in Colorado (or Hawaii, 3330 in Canada..), youd need some chip like Si4735 http://www.silabs.com/public/documents/marcom_doc/mcoll/Broadcast/Radio_Tune rs/en/Si473x_Presentation.pdf their doc shows ipods, phones, and handheld PCs. has anyone besides the DSP-Rado people actually put this in _any_ product, let alone a phone? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: .Mac like service
-Original Message- From: Robin Paulson [EMAIL PROTECTED] Sent: Tuesday, April 29, 2008 6:29 PM To: List for Openmoko community discussion community@lists.openmoko.org Subject: Re: .Mac like service /snip alternatively, an application to sit on my pc and do all this stuff locally would be very useful To add to this, giving the application the ability to log into the service and sync locally, or update the service with more up-to-date info would be useful. --Tim. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: Loosing your moko
-Original Message- From: David Pottage [EMAIL PROTECTED] Sent: Wednesday, April 09, 2008 8:15 AM To: List for Openmoko community discussion community@lists.openmoko.org Subject: Re: Loosing your moko On Wed, April 9, 2008 2:39 pm, Sebastian Billaudelle wrote: Yes, i think a normal hijacker has no skills to flash the image - it is unusual with normal phones. I think nearly all of them don't know about a function like the one we are discussing here. But i think there is another problem: I don't know if it legal to track the position of a person without his/her permission - even if he/she has stolen my phone... Will the cops be allowed to use this information? There are lots of crazy laws... Is a lawyer here on this list? Yes, i think a normal hijacker has no skills to flash the image - it is unusual with normal phones. I think nearly all of them don't know about a function like the one we are discussing here. But i think there is another problem: I don't know if it legal to track the position of a person without his/her permission - even if he/she has stolen my phone... Will the cops be allowed to use this information? There are lots of crazy laws... Is a lawyer here on this list? I am not a lawyer, this is my amateur analysis: As I see it, there are three issues to contend with: 1. Is it legal or ethical for openmoko to keep a database of where users are and have been without their explicit consent? 2. In what circumstances should law enforcement be granted access to the database of where users are? 3. In what circumstances should the owner of a phone be able to tell where it is? The first issue is about big scary companies keeping big brother like databases on all their users. We all tend to think of openmoko as a friendly community effort with no ill intent, but pretend for a moment, that the phone comes from someone big and scary like Microsoft or Verzon. Would you be happy about them tracking you by default? Over the years some tech publications like www.theregister.co.uk have published scandals and trade conspiracies to reduce consumer choice, invade privacy and create vendor lock in. I dare say they would have bad things to say about this plan unless strong safegards are built in, and we find a way to make this off by default (but still trap anyone who re-flashes the phone). My solution to the privacy problem is this: In the box with a new phone is a card explaining how to create an account with the location DB. The user would normally setup an account with that DB. If they are paranoid about privacy, they can throw away the card without doing anything. In normal operation, the phone contacts the location DB from time to time with its serial number and current position, however if the phones owner has not registered, the DB informs the phone that it is not registered. The phone will store that setting in non volatile memory, and will never contact the location DB again. That way, for users who are concerned about their privacy, or who just dont read the instructions, Only one location will ever be released. If the user later changes their mind the DB registration site will have instructions on how to manually flip the send locations parameter back to true, via a deeply hidden menu or config file. If someone re-flashes the phone, then the parameter will be automatically reset. If it is stolen the rightful owner would have to quickly register with the DB before the phone is re-flashed. The second issue is about law enforcement access to the database. If a bad guy such as a drug dealer is using an openmoko equipped phone, then the police might legitimately want access to the database to find out where they have been. Likewise if there has been a serous crime such as a murder, then the police would want to know who was at the crime scene during the crime. I think that most community members would agree that a request for information in these circumstances should be granted. On the other hand, many people are concerned about warantless wiretaps in the United States at the moment, and worry that the police might make big dragnet like requests to invade privacy. For example issuing speeding tickets automatically if the DB showed that you where moving faster than the posted limit. In some circumstances the owner of the phone might want access to the database to prove their innocence for example to establish an alibi, or to prove that they where not speeding. I would suggest that a good compromise would be for the DB admin to give out to the police information about the movements of any specific user, or all users who where in a specified area for a specified period of time, if the request is made by the registered owner or suitably senor police officer or judge. There is a problem that some law enforcement agencies might try to bypass any privacy rules we setup, and try to get a court order for the entire database. To prevent this we should setup the database in a
Re: Qtopia coming for Neo1973
On Wed, 26 Sep 2007 8:57, [EMAIL PROTECTED] wrote: As far as I'm concerned, this should have ended last week. The original question asked was why continue with OpenMoko development when Qtopia is available, faster, more complete and stable?. It was debated and some pretty conclusive reasons came out (as posted last Thursday) 1) Redundency is good, if Qtopia fails for some reason, there's an alternative. 2) A greater number existing applications can be ported easily to an X based framework. There is also precedent in the Maemo project of where this has been very useful. I'd like to add a 3rd: Competition breeds innovation. :-) I guess a 4th reason that's come out now is some people just prefer the GTK+ api and maybe a 5th reason some people prefer the LGPL over the GPL. So there you go, there's the 5 reasons why OpenMoko development will continue.Agree or disagree those are the reasons. Perhaps these could be added to the wiki to avoid future debates running over the same ground? Cheers, Tom PS: The faster, more complete and stable bit refers to the _current_ state of OpenMoko and not to what OpenMoko will obviously become. I guess my only comment is that while I don't really care which interface people use on their phones, it seems like the data interfaces should be the same... If I open up qtopia phone edition and look at my contacts or maybe even edit them and then close it down and open up my OM interface and look at them, they should be the same. All edit are visible.. No double entry. In general, I think that all of that should be possible regardless of which interface you use to view/interact with the phone. Gives a little more isolation of the interface from the implementation of where everything is, and it gives people the option to switch at any time without fear that they need to copy / backup-restore their data when switching. Especially with the relevation about being able to run them both at the same time. (Qt has x11 libraries/bindings right?) So you could write qt apps which interact with GTK+ apps through the common data infrastructure. --Tim ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Yet another finger keybord (gui mock-up).
On Sun, 26 Aug 2007 9:36, Lars Hallberg wrote: Josef Wolf skrev: [ I warm-up this old thread again... ] On Mon, Mar 05, 2007 at 12:02:31AM +0200, Lars Hallberg wrote: a mock-up on a 90-key by one stroke finger keyboard. Think this might be an usable and pretty efficient input method. http://www.micropp.se/openmoko/ This looks very promising. I like this idea. The only issue I see is that the least used characters (numbers) are the easiest to enter. IMHO, the mostly used characters should be accessible without dragging. I think it's a good default as it reuses the users knowledges from t9 systems. It's important to be easy to pick up. But an alternative layout optimised for text input is good, as is a possibility for power users to define there own layout, or even special layout for different programs/tasks. /snip /LaH What about a continuously variable system which starts with the most commonly used letters and then adjusts itself based on user input. It could learn which letters a specific person uses to type and make them more prominent. Then, depending on modes the programming or web searching or other keyboards would automatically adapt to the best layout based on the users individual behavior. --Tim ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Yet another finger keybord (gui mock-up).
On Sun, 26 Aug 2007 11:35, Andraž 'ruskie' Levstik wrote: On 20:15:37 2007-08-26 Edwin Lock [EMAIL PROTECTED] wrote: So you have to get used to it every time again? doesn't seem like a very good idea. My experience is that people like to get used to things and do them like the got used to, not change.. - Edwin A dynamic input... I like it... But let's put it this way... it shouldn't be to hard to add an option to either use a dynamic input or a pre-defined/custom static one. Give the user the final choice. But then that's just me... I like the user having as much choice as possible. -- Andraž ruskie Levstik Ok, I didn't actually mean after each and every keystroke. I was trying to float the idea. The actual implementation would obviously be up to some kind of experimentation. I can't see how removing the unused characters and adding more used characters could be a bad thing. Granted you let the user decide to switch and always have the ability to go back to default.. But each user will have a different vocabulary and thus a different optimization specifically for them. as a bad example take someone who always talks in leet speek when messaging. That will be a very different layout than someone who does short hand or abbreviated messaging. If the program could figure out, say each night or when the user chooses or what not, which letters or symbols they use most and build an appropriate step heirarchy then you could optimize the path for fewest drag type operations and more click operations. Or at least that's how it seems to me. Then once the sequences are determined, let the user position them on the grid in a manner that feels right to them. For each user that might be different. Anyway, some will like it and some will disable it in favor of the default or non-assisted but customly defined layout. Personally, I would not mind having the least used letters changed out for more used letters based on my usage patters in a semi automatic way, if I could anchor my most used letters to positions where they feel comfortable. --Tim ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
another linux platform platform
I just noticed this: http://www.linuxdevices.com/news/NS5539544742.html They claim to have many of the features we have talked about on the list... however, I am wondering about the pending patent related to placing security in the bootloader for signature checking of a boot image. Does anyone know if this is available GPL or if they have somehow managed to get around all of that? -- -- Tim ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Data Link Disable Capability?
On Thu, 26 Jul 2007 12:32, Giles Jones wrote: Anything and everything is possible. Obviously, you mean this withing the realm of programming openmoko. Otherwise, its a very broad and bold statement. /grin --Tim ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: whee!
On Thu, 26 Jul 2007 19:06, Mark Eichin wrote: Ok, now I feel stupid. Guess you get to call me a muppet after all :-} The batteries and cards were all wrapped together in one of the foam cutouts. I don't know how I missed it this morning, when I got home I went through every compartment to double check and they were right there. (I think I saw white, shiny and thought must be documentation. Or maybe I just hadn't had my coffee yet.) Apologies to all involved! Actually... They tracked down your shipment by tracing the gps location as reported by your phone back to the mothership. They just added those components while you were out to make you look like a muppet. /grin. Joking.. Of course.. Good to see you found them. --Tim ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: another linux platform platform
Err... That was supposed to br linux phone platform... On Thu, 26 Jul 2007 8:35, Tim Newsom wrote: I just noticed this: http://www.linuxdevices.com/news/NS5539544742.html They claim to have many of the features we have talked about on the list... however, I am wondering about the pending patent related to placing security in the bootloader for signature checking of a boot image. Does anyone know if this is available GPL or if they have somehow managed to get around all of that? -- -- Tim --Tim ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Camera on GTA02
On Mon, 23 Jul 2007 10:27, coomac wrote: Rather than alienate one group over the other, why not have something for both? A non camera version for those who don't need the feature as well as a camera version with the exact same specs for those who can't live without it? I mean, why have a chip with camera support if there are no plans to use if fully? Tag on a $50 difference or something. Problem solved. It won't be feasible in the near future if it involves a major holdup or deviation from the current product, but if it's doable, why not? Guys Gals... There have been talks of add on packs that let people increase thickness of the case and do things that were not really intended originally. Since we have a pretty strong idea that the GTA02 will not include a camera.. We can add it as a wishlist item for GTA03.. And no need to argue over it. BUT there is the chance that some kind of addon pack could be made for the GTA02 after its sold. In this case, a production molded back plate could be included so no drilling would be required. If its planned out right, these addon packs could be simply unscrew backplate, snap new addon pack down, screw on backplate, install new software. Now I will also be the first to say that it won't be this easy in the beginning... But it *could* eventually. For Instance, forget about connecting with the camera pins if they are not exposed and use something else, we have (maybe not optimal) I2C, Spi?.. But how about an option that doesn't require wires?.. Say bluetooth, wifi... Maybe use I2C to control the device and bluetooth to transfer the data.. The point is, that for now its not going to happen.. But think a little outside of the box for ways to make it happen as an option. --Tim ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: projects of interest? - mebot
On Wed, 18 Jul 2007 11:27, Jeff Andros wrote: On 7/18/07, Tim Newsom [EMAIL PROTECTED] wrote: snip You could expand this a little and possibly select items from multiple location lists and then select Find the shortest route to complete all tasks snip --Tim just don't expect it to do so very fast... and make sure it runs as a REALLY low priority http://en.wikipedia.org/wiki/Traveling_salesman_problem http://en.wikipedia.org/wiki/NP-hard -- Jeff O|||O Actually, I was thinking of offloading that work to a mashup like interface.. Say google maps or what not and just displaying the result. --Tim ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: ringtones?
On Wed, 18 Jul 2007 17:02, Jeff Andros wrote: I haven't used a mac other than casually (checking email) since os9... so I'm not so up on growl. I'd like basically arbitrary code execution, but with some (read LOTS) of protection on how that gets registered (can't let Sean's dad install malware that fire off every time the phone rings, can we?). I'm also still liking a shell script that gets fired off, yeah, it's got a bit of overhead, but if you get into binary programs as fast as possible, and just use the script to link up the purpose built programs ( I.E. the whole reason shell scripts exist) it might not be too bad... something to investigate I guess Why not use something like a sandbox? I found a something on sourceforge something like sandboxing.sourceforge.net... But basically it just prevents applications in the sandbox from doing things without permission. And it can be set to either send an error or block and send an event to some queue for other action... Seems like we can set it up so that: The installer is trusted... Signed applications (with approved cert) can be auto full trusted User can choose to give trust levels if desired... Etc.. If its flexible enough, might this (or something like it) provide some or most of the unauthorized program access protection we want? --Tim ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Fwd: Not the free phone
On Mon, 16 Jul 2007 11:28, Daniel Bartholomew wrote: Well, since Apple has gone iThis and iThat with everything and dropped their use of PowerThis and PowerThat, why not co-opt that? How would you like a PowerPhone? -- Daniel Bartholomew Well, in a similar vein (throwing in my own silly thoughts..) Why not call it the UPhone... UPhone.. Make it what you want it to be... UPhone.. Its your phone, do what you want with it.. UPhone.. What do U want on it? Lol.. Ok, very silly. --Tim ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Not the free phone (was: Re: Again: Advertising thoughts
OK.. Great minds think alike... Or maybe not. /grin On Mon, 16 Jul 2007 12:11, Shawn Rutledge wrote: How about simply the youPhone, or uPhone? On 7/16/07, Ian Darwin [EMAIL PROTECTED] wrote: I completely agree. My idea is to make two advertisment campains: one on maisntream media: maybe tv, maybe radio, flyre, poster, newspapers, wathever. This ads would be something like: The free phone, OpenMoko. The only one with The OpenMoko: now with builtin navigator and so on. Don't even THINK of using based on Linux Kernel 2.6.xx or With powerful ssh acess Calling it the free(d) phone to consumers (as opposed to developers) is going to engender an enormous amount of confusion and ill-will. Why? Because (at least in North America) the major carriers have spent years, and billions of dollars, totally subverting the meaning of the phrase free phone to mean we give you the cheapest phone we can find and don't charge you for this piece of junk when you lock into a two- or three-year plan at some exorbitant rate that obviously includes the cost of the phone amortized. Seriously, ask consumers what a free phone means. at least 11 out of 10 will give you the definition above, at least the parts they understand. A consumer ad campaign is NOT the place to push the free as in beer vs free as in speech argument. The phrase free phone already means the opposite of what we want it to mean. It's done, finished, over. Move on. Call it something else in the consumer market. The Flexible Phone. The Does-what-you-want-not-what the big corporations want. I don't know. ___ 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 --Tim ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Charging the NEO1973
On Thu, 12 Jul 2007 9:42, [EMAIL PROTECTED] wrote: Or hack a USB socket onto one of the many discarded 5V chargers you have lying around. If your house is like mine, they seem to show up out of nowhere. Michael So that's what happens to all of the 5v chargers I place in the drying machine!! Now if I could only find out where the socks go --Tim ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Linux
Um... Japan does have GSM service... I am positive as I recently had guests in my house from japan. They brought their cell phones and I showed them how to make them work in the US. As far as I know... Granted, making them work in the us meant dropping the 3g and switching to GSM service... But since the option was available in a japanese phone it would seem to indicate that they can use it. PLUS so called world phones or quad band phones include GSM service frequencies for other places and I am pretty sure one of those is Japan. I could be wrong... But I don't think I am. It just might not use the 3G mode but only GSM and it might mean that the extra internet capability might not work. Does EDGE fall back to gprs? Does 3G fall back to EDGE or GPRS if the phone doesn't support it? I think those are the right questions. --Tim On Sun, 8 Jul 2007 11:13, David Pottage wrote: On Saturday 07 July 2007, Vicente Alcañiz Buceta wrote: I just want to have a Linux mobile phone but maybe is not going to be release in Japan??? As Jason Elwell says, the Linux mobile phone is released today, so you can buy at the unsubsidised price. Unfortunately you won't be able to use it in Japan (or Korea) as it is GSM only. I guess if you are realy keen, you could buy one as a Linux PDA, or to develop software, but otherwise, you will have to wait and hope that FIC produce a 3G model with W-CDMA support some time next year, that you will be able to use on the Softbank (formerly Vodaphone) network. -- David Pottage ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community --Tim ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Location Privacy Protocols, was Re: GPS trail - crazy idea
On Fri, 6 Jul 2007 12:25, Wolfgang S. Rupprecht wrote: Another good reason from an open-source product. Maybe there is a vast untapped market for selling open-source phones to the governments of the world (to protect them from the other governments of the word. ;-)) -wolfgang Except that as far as I know (someone please correct me if I am wrong ) the GSM part is the side which the telcos can tap into for their readings and its closed to us. We can be open everywhere else and unless we have the firmware to the GSM piece we could not prevent the telcos from tracking us. Its possible that the government has specially designed phones but I don't really know. It may not even be in the GSM piece, but at the tower and control center that they track you.. In which case there is nothing you can do even if the firmware were open. Again, that's just guessing. --Tim ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: An alternative gaming top case
On Tue, 3 Jul 2007 4:01, Robin Paulson wrote: excuse my ignorance, but do you mean a 3d scanner as in a device for measuring a 3d object? http://en.wikipedia.org/wiki/3D_scanner if you do, and have a Neo, that would be awesome. any chance of using it to produce an electronic model of the case that you could share with us? as for formats - i presume you mean file formats. something open like .blend would be good, or more commonly, .stl: http://en.wikipedia.org/wiki/STL_(file_format), those are accepted by pretty much every 3d modeller out there Yep. But unfortunately I do not yet have a neo1973. .stl I gathered but I had not thought of .blend Basically all a 3d scanner does is build up a point cloud for the contours of an object and then kinda wrap it in a skin. If the resolution of the point cloud is high enough you can make out some pretty fine detail. In this case (no pun intended) I believe it will work pretty well. --Tim ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Custom case designs...
I have been thinking a little more about this and I struck upon an idea... What if you could buy a custom case with a custom message on it. I am not talking about painted messages but letters and shapes cast into the plastic shell. Raised, sunk, custom fonts etc. Naturally we can't just replicate the exact neo1973 shell without permission, but maybe something like it and removing the FIC logo (unless we get permission to use it) or the like. This is more of a vanity thing than a functional thing.. But what do people think of it? --Tim ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Custom case designs...
On Tue, 3 Jul 2007 8:59, no_use wrote: these are exactly the reactions i got from my friends.. specially as the mainbord seems rectangular, i wouldn't like to see it with this rounded top and bottom.. ..and all i want is 3G.. :( So add case design ideas to the wiki where previously noted. I guess we will see what's possible once we get them in our hands and all that. --Tim ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: community Digest, Vol 34, Issue 17
On Tue, 3 Jul 2007 9:50, Michael Sersen wrote: About custom case design for the Neo and beyond; I am very interested in this idea. I have a cnc router at my disposal and can make custom parts from materials such as Corian and exotic hardwoods and some soft metals. I'd love to see some spec's, maybe .dwg's or .dxf files of the current case, for measurments of stand-offs and such. ~ MAS This makes 2 of us.. Are there others with similar equip? I was working on the idea that it may be possible to use custom plastic injection or some other forms of liquid plastics to build custom shells. In addition, it may also be possible (assuming someone wanted to pay for it ) to cast in stirling silver or various gold alloys (careful about scratches) etc.. Just some ideas anyway.. --Tim ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Custom case designs...
There are several types of clear plastic which could be used to fulfill this idea.. Both as plastic injection and liquid casting material. --Tim On Tue, 3 Jul 2007 9:50, Shakthi Kannan wrote: Hi, On 7/3/07, Ben Burdette [EMAIL PROTECTED] wrote: Case modding for phones, cool. Maybe we should have like transparent (see-through) casing. Why do we need closed cases for open hardware and software? SK -- Shakthi Kannan http://www.shakthimaan.com --Tim ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Custom case designs...
That's not necessarily true.. Look at plastic bottles. Clear soda bottles are fairly strong and not nearly as brittle as some other clear plastics. Plus, that plastic is useful as injection material. Plus, if it were cheap enough to get new cases, most people would not care if they dropped or scratched one for a while as it would be easily replaced. --Tim On Tue, 3 Jul 2007 10:37, Jeffrey Thomas wrote: Maybe we should have like transparent (see-through) casing. Ah, but transparent plastic is always more brittle than coloured plastics... I would hate my Neo cracking as easily as a CD case... On Tuesday 03 July 2007 11:35:57 Shakthi Kannan wrote: Hi, On 7/3/07, Ben Burdette [EMAIL PROTECTED] wrote: Case modding for phones, cool. Maybe we should have like transparent (see-through) casing. Why do we need closed cases for open hardware and software? SK -- Jeffrey Thomas Sierra Bravo 952.948.1211 x1046 952.567.6346 Direct www.sierra-bravo.com 9201 East Bloomington Freeway Suite CC Bloomington MN 55420 --Tim ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Come see OpenMoko at Ubuntu Live
On Tue, 3 Jul 2007 11:24, Sean Moss-Pultz wrote: Dear Community, Michael Shiloh has volunteered to setup a booth at Ubuntu Live (http://www.ubuntulive.com) July 22 to 24 in Portland, Oregon. He'll be demoing and talking about both the platform and the Neo. If you're in town, please stop by! Thanks so much for the help Michael! -Sean I am in portland so I will definitely stop by and take a look. I will try very hard not to drool all over the phone too. Lol. --Tim ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Custom case designs... (the business perspective)
On Tue, 3 Jul 2007 12:56, Matthew S. Hamrick wrote: Also.. to follow up on what Adrian recently said.. The tech shop also has a CNC milling machine. I'm no expert, but I believe that the idea is that you put a CAD file in one side and take out a completed part out the other. So... if you have the CAD files for a case, you could feed them into the CNC milling machine instead of the 3D printer and viola! aluminum case. Jim Newton at the TechShop also mentioned he's looking into getting an injection molding machine. I've seen a couple of these sorta 1 shot injection molders. You use the CNC machine to create your mold, then you pour plastic pellets in the top, press a button and an electric motor turns the screw that forces the semi-molten pellets into the mold. So.. you could have any number of different cases made for your Neo. My back of the envelope calculations for the cost are: Fixed Costs: Mold Design Time5h $0 Mold Milling Time 3h $75 Variable Costs: (per production run) Mold setup 1h $10 Variable Costs: (per case) Plastic Pellets (1/10)h $3 So assuming a CAD file for the NEO case were to magically fall out of the sky, perhaps as part of a program to seed a third party ecosystem (*hint*hint* Sean, are you going to be in the bay area soon? *wink*wink*) The cost per case for a production run of 10 and 100 identical cases would be: 10 cases: 9h, $115 100 cases: 18h, $385 Let's say that I'm terribly impressed with myself and I want to pay myself $65 / hr. for my time, the price goes up to: 10 cases: $700 100 cases: $1555 But I'm not going to sell them myself. I'd rather sell them through SparkFun or even GumStix.com (but I don't know if either of these guys would be interested.) So, I'm going to add a little bit of margin. This is a risky business, so I'm adding 35%. 10 cases: $945 100 cases: $2100 Nathan and/or Gordon are going to want a margin as well, but I'm thinking I'm going to offer them a low-risk proposition: just put the SKU on your website and I'll handle the fulfillment. So I'm going to argue them down to 7% margin. So in other words, I'm going to pay them a commission for every case they sell. That fee would be: 10 cases: $65 100 cases: $147 We're not talking about a lot of coin, here. From a business perspective, the reward of $147 for selling 100 isn't that great. It's probably not going to pay for Nathan or Gordon's time to setup the SKU in their system. But there's always eBay... Let's say sales taxes are an additional 8.5%: 10 cases: $86 100 cases: $191 Shipping and handling: 10 cases: $90 100 cases: $900 End Price: 10 cases: $1186 ( $118.60 per case ) 100 cases: $3338 ( $33.38 per case ) So... the question is... a) is it possible to convince Nathan or Gordon to sell these things through their websites for $65 - $147? b) is there actually a demand for 10 or 100 of these after-market cases? c) is there a one size fits all design that will satisfy everyone who wants an after-market case? So, I'm not saying I want to get into the business of making after- market Neo cases, but someone who was thinking about getting into this market would do an analysis just like this. So... if there was a solid demand for 100 cases, it's possible the price could be brought down to about $35-$40. This is definitely an interesting analysis of a set of costs associated with this kind of business. I think the costs could be a bit cheaper for the end user depending on material and costs to build the molds. But then again, I have not actually sat down and worked it out yet. /grin I do think there is a market here though.. --Tim ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Custom case designs... (the business perspective)
Note... I did ask about permission and we were told to wait on discussing with official personel till phase 2 of the phone. So scanning the actual case and building a knockoff would (in my opinion and until I am corrected by FIC / Sean or other person with some authority) be a violation of their IP. However, it is hardly a violation of their IP to build new designs from our own imagination and make them open / sell them by our own means. I just can't see how we could possibly be upsetting them by adding accessories for their devices which will in some way improve customer experience or at the very least satisfy some vanity impulse. --Tim On Tue, 3 Jul 2007 14:32, Robin Paulson wrote: Is it legal to sell these cases? The design may be based in no small part on work done by FIC, who will not be impressed by us stamping on their IP. We don't want to take the piss - they are helping us a lot. Making a few one-offs for ourselves, with no profit is ok, but as soon as we start marketing them, things may change. When he's not so busy, this would be one for sean to enquire about. On 7/4/07, Dr. H. Nikolaus Schaller [EMAIL PROTECTED] wrote: So... the question is... a) is it possible to convince Nathan or Gordon to sell these things through their websites for $65 - $147? I can sell it through my website: http://www.handheld-linux.com although I currently focus on the European markets only (due to tax and duty complexity). b) is there actually a demand for 10 or 100 of these after-market cases? Depends on the number of total units of the OpenMoko being sold. I would assume 1% after sales as a first rough guess. c) is there a one size fits all design that will satisfy everyone who wants an after-market case? Probably not. I remember that we did have approx. 50 - 100 different custom designs at Siemens mobile phones. Nikolaus Schaller The Handheld-Linux Shop http://www.handheld-linux.com operated by Golden Delicious Computers GmbHCo. KG Buchenstr. 3 D-82041 Oberhaching http://www.goldelico.com Make the customer come back and not the product ___ 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 --Tim ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: An alternative gaming top case
On Mon, 2 Jul 2007 17:39, Robin Paulson wrote: I have added a sub-section to the Neo1973 hardware section of the wiki, concerning alternate cases. there are a few ideas as starters, including one with a d-pad and a steampunk design. Anyone with any other ideas/more info to flesh out what i've put there, head over to http://wiki.openmoko.org/wiki/Category:Neo1973_Hardware#Alternate_cases If FIC do not have the resourcs at the moment/will not ever supply schematics, then we need someone to measure their phone and upload some drawings I have a 3d scanner that I am planning to employ for building models if no one gets to it before I do. I would be interested in finding out which formats people think should be used for the models.. Also, assuming I can get things together what is the interest level for case kits and other accessories? --Tim ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: An alternative gaming top case
Sean, Supposing some company decided to provide alternate case designs or add on products for the neo1973, who do they need to talk to about branding / authorization to sell them to the public? OR Is it possible that FIC or the OpenMoko company will have a section on their sales page supporting 3rd party add-ons, etc? --Tim On Sun, 1 Jul 2007 18:10, Robin Paulson wrote: well, i'm definitely interested in someone doing something like this - and my background is in CAD/engineering/materials with a bit of CAM, so i might as well start things off. i can't see any schematics/CAD drawings up on the wiki - can someone point me in the direction of accurate, precise drawings of the internals and the case? if not, then to sean: will FIC be releasing good engineering drawings of the component(s) or will we be going down the route of measuring hardware and drawing our own? if we are going the reverse-engineering route, is someone willing to whip out their micrometer and a decent (open-source) CAD package and make some up for us? On 7/2/07, Jeff Andros [EMAIL PROTECTED] wrote: On 7/1/07, Robin Paulson [EMAIL PROTECTED] wrote: snip want a case made from brass with diamonds inset, and a 200mm joystick - go for for it. snip The real question is, how long before we see a really good steampunk case? anyone out there want to show off your 3D Cam skills and start putting them up for sale... I'd buy ( rapidobject.com was previously mentioned if you need a place to do the work) -- Jeff O|||O --Tim ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re:Graphics Accelerator needs matching joystick and keys
There's also the possibility of adding some kind of attachment to a specially designed battery or backpack which could add this ability by interfacing with the I2C or SPI ports available. --Tim On Fri, 29 Jun 2007 16:43, Joe Pfeiffer wrote: Kenshin writes: I think there is a huge benefict in addind a joystick and keypad to the OpenMoko. This would allow users to play old classics in emulators; run new (java) games and assign keyboard shortcuts. I don't think that adding a joystick and a keypad is a big technological endeauvour :-) Is there any reason for not having them? Space. Not everybody wants them (I don't, for instance), and they take up room. Hopefully FIC will move in that direction with some of their future devices -- but hopefully they won't abandon those of us who don't want it. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Graphics Accelerator needs matching joystick and keys
Hehe, I know that.. I was mentioning it for the benefit of the previous person who was asking about joysticks. --Tim On Fri, 29 Jun 2007 19:22, Steven ** wrote: Someone has already mentioned on this list about using the Wii Nunchuck. Apparently it will connect to the I2C fairly easily. Search the archives. -Steven ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: An introduction
Plus, since moonlight is technically language agnostic, those who want to write in c# could, those who like c or c++ could.. With IronPython or IronRuby or even Javascript there are a number of options for scripting and having user interfaces that work seamlessly together.. Regardless of the technology used to build the application code underneath. From my understanding.. We could even mix with different UI elements interacting with different types of applications ... By that I mean portions of the same UI could be sending events to scripts or C# or c/c++ code. Is that right? And XAML can be created dynamically giving the ability to not just theme/skin but completely alter the UI at runtime. By that I mean you don't have to have a static interface with a skin file and theme but the interface could be radically changed as new code is added and new xaml nodes are created.. Does that make any sense? --Tim On Wed, 27 Jun 2007 5:49, Vladimir Giszpenc wrote: On 6/27/07, Tim Newsom wrote: This could provide the xaml parser for use in an interface design some of us have spoken about. Separating the interface from the actual code that processes the events... Or that's how I understand it. Its a truely awesome development. Yes it certainly could and would provide a XAML parser. Read this http://jacksonito.blogspot.com/2007/06/mono-developers-guide-to-writing-xaml.html for some more details. They are planning for tools written in MoonLight so that you could develop on Linux or even a Mac (though I sense no love lost on Apple products on this list :). On 6/27/07, Hans De Croix wrote: Under what license exactly is silverlight/moonlight? The Mono part of Moonlight uses the DLR. So... Microsoft's DLR is a layer on top of their Common Language Runtime (CLR), which provides support for dynamically typed languages such as Python, Ruby and JavaScript. The great news is that the DLR is released under Microsoft's Permissive License—their way of saying open source. Microsoft's .NET/DLR implementations of Python and Ruby, named IronPython and IronRuby respectively, are both covered by the same Permissive License as DLR. Mono as a whole has this answer to the license question: What license or licenses are you using for the Mono Project? We use three open source licenses: * The C# Compiler and tools are released under the terms of the GNU General Public License (http://www.opensource.org/licenses/gpl-license.html) (GPL). * The runtime libraries are under the GNU Library GPL 2.0 (http://www.gnu.org/copyleft/library.html#TOC1) (LGPL 2.0). * The class libraries are released under the terms of the MIT X11 (http://www.opensource.org/licenses/mit-license.html) license. Both the Mono runtime and the Mono C# Compiler are also available under a proprietary license for those who can not use the LGPL and the GPL in their code. For licensing details, contact [EMAIL PROTECTED] Specifically Moonlight... Novell will be requiring copyright assignments or contributions to be made under the MIT X11 license to Moonlight to ensure that we can ship this plugin with proprietary drivers if necessary (and also to relicense Moonlight for embedded system users). I imagine the OpenMoko embedded system is a special case since it is open but the license is definitely open source. On 6/27/07, Florent THIERY wrote: I'd be surprised if no hardware acceleration was needed... It is not needed though it is used if available. They got help from their Xgl+Compiz+Glitz guy David Reveman. Here is Miguel de Icaza describing the development decisions some more... The other consideration to move away from C# to C at the time had to do with the early conversations with David Reveman who wanted to hardware accelerate this. The idea was to turn the Silverlight high-level operations into a scene description that we could transfer from the client applications directly onto the compositing manager (On modern X installations this is what actually puts the bits on the screen and what has enabled all those spicy effects like the rotating cube). The idea here is that the Silverlight client could detect if it was running under a compositing manager that offered rendering on the server and it would off-load all the rendering to the layer that can talk directly to the OpenGL hardware. Vlad ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: An introduction
This could provide the xaml parser for use in an interface design some of us have spoken about. Separating the interface from the actual code that processes the events... Or that's how I understand it. Its a truely awesome development. --Tim On Tue, 26 Jun 2007 19:58, Vladimir Giszpenc wrote: Hello OpenMoko community, OpenMoko is very exciting. I and many Mono developers like myself would like to get involved. The Mono team has developed Moonlight -- a port of Microsoft's SilverLight to Linux. Here are some of the things it can do http://www.youtube.com/watch?v=qRSO7p0HAIw It is Open Source, small, fast and works well with others. The Mono team has made it easy for .Net developers to access this technology but it is not limited to them. You don't need Mono to use MoonLight. The Mono team would help you create hype give you access to millions of C#, VisualBasic, JavaScript, IronPython and Ruby developers because it not only has ported the .Net CLR but they made Microsoft's DLR work on Linux as well. The DLR is licensed with a BSD type license. How do we get involved? Thanks, Vlad ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Let's play...
OR... They could have it being developed on an internal developer machine and not go live till they are ready. On Tue, 19 Jun 2007 18:07, [EMAIL PROTECTED] wrote: ...Guess the OpenMoko Web Store URL! Sooner or later, they have to start selling. But from where? webstore.openmoko.org?? store.openmoko.com?? Perhaps an Fic site?? Lots of possibilities. If anyone finds the store under construction, should that info be shared?? Alan mail2web.com – Enhanced email for the mobile individual based on Microsoft® Exchange - http://link.mail2web.com/Personal/EnhancedEmail ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community --Tim ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Let's play...
Oh... And the neo1973 will probably be sold at some FIC site ... I mean... OpenMoko is not just for the neo1973 and they are only related because OpenMoko can run on the neo1973. Indeed, suns new java phone os and probably windows mobile will also run on the device. Plus, since its an FIC phone, it just makes sense. The phone isn't called The OpenMoko phone after all... --Tim On Tue, 19 Jun 2007 18:07, [EMAIL PROTECTED] wrote: ...Guess the OpenMoko Web Store URL! Sooner or later, they have to start selling. But from where? webstore.openmoko.org?? store.openmoko.com?? Perhaps an Fic site?? Lots of possibilities. If anyone finds the store under construction, should that info be shared?? Alan ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Open Moko Themes
On Wed, 13 Jun 2007 4:52, Buddy wrote: On 6/13/07, Emre Turkay [EMAIL PROTECTED] wrote: On 6/12/07, Tim Newsom [EMAIL PROTECTED] 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. Look up what you get Loading the burden of SVG rendering to the run-time, for a very static environment like a mobile platform (you don't plug a screen with a different resolution to your cell phone generally) IMHO not a very good idea. They may be vector graphics at the development phase but they should be compiled (translated into bitmap) before deployed onto the real device. My motivation is, why should we decrease the performance to get the same effects, both for UI eye-candy and usefulness? emre SVG can be used for scaling with same resolution and the average filesize will be very small Exactly what I was going to say. Ok.. So imagine that you have this wonderful 640 x 480 screen. Text is very readable to the average user.. However, the skin / theme is too small for some visually impared people in some circumstances Svg allows you to magnify with perfect clarity to any size without distortion. Ok, but the text is a raster font (is that the right word?) not some vectorized font right? Does it have to be? Why not handle translation of rasterized to vectorized fonts for the magnified area? Is that possible? I don't know but I imagine it should be. Or use vectorized fonts everywhere. Going another way, with svg, you can draw perfect thumbnails of the current state of any application in a task manager context by rendering the view of that frame in a scaled window. You could even allow those windows to be interactive so that 2 applications could be operated side by side. Without drawing and rendering each available scale of static image (which would be very huge in size) how else can you get the same functionality? The ability to skin an application, move the buttons around and test out a new layout without altering a single line of application code is huge in my mind. Also, the ability to mashup (to overuse an overused word) application functionality is huge too. Example: You have an ftp program but you don't necessarily like the file manager program... However, you have a file manager program you do like but you don't like the layout as much.. It would seem to me that if we build this correctly we should be able to combine which ever file manager and ftp program we want into a new (again...) Mashup and have something we like and never touch the application behind. Why is this possible? Because drag and drop exist at the os level maybe... Or because the UI glue code can handle any correctly defined and used interface on the app code... Or because all file managers and ftp apps follow specific guidelines which allow combining them in new ways. /shrug.. Ok.. Now do that with a static interface. --Tim ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Open Moko Themes
On Wed, 13 Jun 2007 7:08, Emre Turkay wrote: On 6/13/07, Peter A Trotter [EMAIL PROTECTED] wrote: If the application is then used on a different form factor device you can simply produce a new SVG file. All the UI script and images are linked to the SVG. This also gives us a nice separation of people who are good at making things look good and those of us who know the loop preconditions / postconditions without even thinking. If openmoko is to deal with multiple different devices/resolutions this will be a key feature. I totally agree that openmoko graphics should be in a vector graphics format. Generate the bitmaps bigger for neo and maybe smaller for iphone, etc. Storing the generated bitmaps in .png or .svg files does really don't much matter. If .svg provides embedding bitmaps, why not. emre As I understand it, you would not even need to build a different svg file. You could use the same one and it could automatically scale because the engine would scale it.. It should be possible (in my mind) to take a layout for 320 x 240 and draw it perfectly at 648 x 480.. Any image bitmaps would be out of sync unless you changed them but if its all done in svg it would render perfeclt. Same the other way.. All ratios would be the same (assuming a smaller display in the same orientation and proportional dimensions) so the exact same skin and theme would not need translation at all (except any embedded bitmaps). Again, that's how I understand it currently. --Tim ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Open Moko Themes
On Wed, 13 Jun 2007 11:15, John Seghers wrote: Tim Newsom wrote As I understand it, you would not even need to build a different svg file. You could use the same one and it could automatically scale because the engine would scale it.. It should be possible (in my mind) to take a layout for 320 x 240 and draw it perfectly at 648 x 480.. Scaling up vector graphics is certainly less likely to cause problems than scaling down. However, when you start talking about QVGA or smaller, every pixel counts and hand-tuned graphics are going to give a better presentation than generated graphics. However, even staying at the same DPI... what about a landscape vs. portrait orientation? Moving from 640 wide x 480 high to 480 wide x 640 high is going to need more than scaling. You are going to want to use the display differently. So yes, a different SVG file would likely be needed. - John If you will check the snipped out portion of my email, you should notice that I mention the assumption you are in the same orientation.. I will grant you that every pixel counts, but if each portion of the display is drawn with vector graphics and unless you are going way beyond the capabilities of the display... Within reasonable bounds the display should scale correctly. As for different orientation, sure, make 2 files for the alternate layout.. But that's incredibly more efficient than making 30 bitmaps (images or whaterever you call them) for each resolution setup and orientation combination. Granted, its my opinion. Granted, rendering a vectored image takes more processing than blitting an image from memory to the screen.. But from what I heard last time, at least the first public version of the neo will have a hardware graphics processor to handle most of that work. And anyway, I don't have a good feeling for the amount of time it would take to render a screen (skin which is theme plus layout) for something like the neo but without graphics processor. I am simply stating my own opinion and I expect others to do the same. /grin that's what the community is all about right? Someone with some extensive svg experience in this realm can give real hard core information. --Tim ___ 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: standard API for linux phones?
From what I read, the LIPS group is creating an 'open' standard. The impression I got from that was the other phone standards group was 'closed' whatever that means. If we are going to back a group, maybe FIC should join it and help in the development process of the standard. None of the members are small (as far as I can tell), and it does at least have the backing of some operators.. Either way, we will need to either submit a standard at some point or follow one so that others can interop with us.. Right? --Tim On Mon, 11 Jun 2007 16:55, 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. Cheers, Dean -Original Message- From: [EMAIL PROTECTED] [mailto:community- [EMAIL PROTECTED] On Behalf Of Robin Paulson Sent: Monday, 11 June 2007 7:16 PM 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
Re: Web-based GUI technology for OpenMoko
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. 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
Yet another contender in the market?
Has anyone else seen the samsung F700? Its features are pretty nice... No idea on the OS but I would definitly take one over an IPhone... If it performs anything like it looks... Hehe. Its got very good specs. --Tim ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Yet another contender in the market?
Hmm... I thought it listed wifi and bluetooth on samsungs website... --Tim On Thu, 7 Jun 2007 8:57, Mark McClellan wrote: nice. very nice. i really hope this is close to the Moko v2 hardware. it's what i'm waiting for Mark On 6/7/07, Eric Heinemann [EMAIL PROTECTED] wrote: If I remember correctly, the F700 is using a Flash lite interface. Even though it does not have WiFi, it does have 7.2M HSDPA :) I am pretty sure it does have bluetooth though. Look here: http://www.gsmarena.com/samsung_f700-1849.php or here: http://www.phonearena.com/htmls/Samsung-SGH-F700-phone-p_1941.html -Eric - Original Message From: Steven ** [EMAIL PROTECTED] To: Openmoko community@lists.openmoko.org Sent: Thursday, June 7, 2007 9:44:30 AM Subject: Re: Yet another contender in the market? The wallpaper on the F700 from the first Google result ( http://gizmodo.com/gadgets/cellphones/apple-iphone-vs-samsung-f700-which-is-touchscreenier-235112.php ) is a total rip-off of the Ubuntu default theme. I doubt that they're actually running Ubuntu (although I think Ubuntu is getting into the mobile market). The features don't really seem comparable. No wifi and no bluetooth. And the screen is even smaller and lower resolution than the iPhone. -Steven On 6/7/07, Tim Newsom [EMAIL PROTECTED] wrote: Has anyone else seen the samsung F700? Its features are pretty nice... No idea on the OS but I would definitly take one over an IPhone... If it performs anything like it looks... Hehe. Its got very good specs. --Tim ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community Never miss an email again! Yahoo! Toolbar alerts you the instant new Mail arrives. Check it out. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- Dangling carrots usually contain a hook. 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 --Tim ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Yet another contender in the market?
You and *I* feel that way... But the general public will be taking stock of the appearance and ease of use etc... Besides.. I mentioned it so that we can take a look at the view some general person my have of a new device and see how we can improve upon any weaknesses. There will be no shortage of devices competing for the top spot... And against the iphone. Many, Many all touchscreen devices will be out there.. And we are not going to be first... So we can at least acknowledge the competition and work to improve what we can. --Tim On Thu, 7 Jun 2007 11:18, Thomas Gstädtner wrote: There already was Samsung phones with HSDPA support which was slower than normal UMTS phones of other manufacturers. Also flash lite might be good looking, but it is definately no smartphone platform. At least you cannot use the UI for additional apps (must be an overlay). The display resolution is very poor for a such big screen. For me this devices is pretty uninteresting, and even if it'd be able to run openmoko that wouldn't matter for me. Why should I give my money to a company that doesn't support opensource only to use their hardware with hacks and openmoko? Let's hope OpenMoko and the FIC Neo1973 will be successful and FIC produces more open phones in future. 2007/6/7, Tim Newsom [EMAIL PROTECTED] : Hmm... I thought it listed wifi and bluetooth on samsungs website... --Tim On Thu, 7 Jun 2007 8:57, Mark McClellan wrote: nice. very nice. i really hope this is close to the Moko v2 hardware. it's what i'm waiting for Mark On 6/7/07, Eric Heinemann [EMAIL PROTECTED] wrote: If I remember correctly, the F700 is using a Flash lite interface. Even though it does not have WiFi, it does have 7.2M HSDPA :) I am pretty sure it does have bluetooth though. Look here: http://www.gsmarena.com/samsung_f700-1849.php or here: http://www.phonearena.com/htmls/Samsung-SGH-F700-phone-p_1941.html -Eric - Original Message From: Steven ** [EMAIL PROTECTED] To: Openmoko community@lists.openmoko.org Sent: Thursday, June 7, 2007 9:44:30 AM Subject: Re: Yet another contender in the market? The wallpaper on the F700 from the first Google result ( http://gizmodo.com/gadgets/cellphones/apple-iphone-vs-samsung-f700-which-is-touchscreenier-235112.php ) is a total rip-off of the Ubuntu default theme. I doubt that they're actually running Ubuntu (although I think Ubuntu is getting into the mobile market). The features don't really seem comparable. No wifi and no bluetooth. And the screen is even smaller and lower resolution than the iPhone. -Steven On 6/7/07, Tim Newsom [EMAIL PROTECTED] wrote: Has anyone else seen the samsung F700? Its features are pretty nice... No idea on the OS but I would definitly take one over an IPhone... If it performs anything like it looks... Hehe. Its got very good specs. --Tim ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community Never miss an email again! Yahoo! Toolbar alerts you the instant new Mail arrives. Check it out. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- Dangling carrots usually contain a hook. 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 --Tim ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Iphone 3rd party development allowed...
So apparently Jobs decided to allow 3rd party software on the phone after all... Interesting development. --Tim ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Iphone 3rd party development allowed...
AhI see. /shrug. --Tim On 6/5/07, David Schlesinger [EMAIL PROTECTED] wrote: I am sure Jobs and company are not blind to the strength of open source software and the boon it would provide if they made a freely available dev kit for the phone. As someone who worked at Apple for ten years, I can assure you that, for the most part, Jobs and company haven't got the slightest interest in open source software, other than a minimal amount of stuff available under a BSD-like license, allowing them to take it, do what they want with it, and then keep it to themselves. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Neo1973 Update!
If your tracking movement with 2 3D accelerometers... What would another one provide. As far as I can tell (I am not an expert...) Tracking all 6 vectors will tell you absolute movement in space. I.e, when 2 vectors point in the same direction with the same magnitude at approximately the same acceleration as gravity.. Its probably laying or positioned flat on that side. If they vary and you have 4 vectors.. (Necessary when its tilted beyond the error amount...) You can figure out its orientation and angle. If its spinning around its center (and assuming that the accelerometers are on opposite ends...) Then at least 4 vectors will point away from each other at approximately the same magnitude as its opposite but matched vector. (The other 2 may point down or up depending on if its spun flat or thrown or dropped. But they should be the same for a flat spin..) All vectors should be able to tell you the moment of movement and the phones basic translation in space... Especially if you keep track of the last known states... Right? I mean if we know the rest orientation and then suddenly get pointed at something it would seem like the 3d vectors will show a specific values and directions for the 2 ends of the phone depending on the center of the arc or movement that acted on the phone. I would say that we can get yaw, pitch and roll just fine.. But again, I am no expert. --Tim On Mon, 4 Jun 2007 18:38, kkr wrote: If I well understand, three accelerometers are necessary to fully define all phone's movements. Isn't it? http://lists.openmoko.org/pipermail/community/2007-May/005216.html So, what's the reason to have only two, and not three 3D accelerometers? - the cost?... 3 $US (But I don't know if it's a 2D or 3D chip). http://lists.openmoko.org/pipermail/community/2007-January/002085.html - the lack of free space? - ... Is-it a 3D or a 2D chip? Regards, ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: First impressions of Neo1973
Thanks, that helps quite a bit. But if that's accurate, the neo is not that big. The sidekick 3 is slightly smaller and thinner than a sidekick 2 (my current phone) and the neo is considerably smaller than that... Maybe its large to someone who uses a flip phone or set616 type phone. To me, it seems perfect. In comparison, the Ipod phone is only about 2/3 or 3/4 the thickness (yeah, that a large gap.. But hey its eyeballed) and only a tiny fraction shorter. The widths are pretty much the same. --Tim On Wed, 16 May 2007 2:38, Peter A Trotter wrote: Nice Jose, I added the Sidekick3 dimensions... http://www.sizeasy.com/page/comp/1842 -Pete On 16/05/07, Jose Manrique Lopez de la Fuente [EMAIL PROTECTED] wrote: Hello, I've just done a fast sizeasy comparison: http://www.sizeasy.com/page/comp/1840 And, yes, the Neo1973 is big! 2007/5/16, Tim Newsom [EMAIL PROTECTED]: On Tue, 15 May 2007 22:15, [EMAIL PROTECTED] wrote: On Tue, 15 May 2007, Tigran Zakoyan wrote: Jason Elwell wrote: I dont know whats more sad... You creating a paperdoll of an OpenMoko, or the fact that I downloaded it and made one for myself! LOL! Me too :) BTW, can't agree 1973 is too big. It just fits the size of my QTEKs110, which size's been really handy for me two years I use it. Not to mention the difference in functionality :) Me three. Next to my Sidekick, the Neo is petite. It's all relative. M Could you, or someone who just happens to have both, post a picture containing them side by side and edge on for comparison? I figured it would be about the same dimensionally (HxWxD) as the sidekick. Is it smaller? Thinner? Wider? Shorter? --Tim ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- J. Manrique López de la Fuente http://www.jsmanrique.net msn: [EMAIL PROTECTED] jabber: [EMAIL PROTECTED] ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community --Tim ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Durability of the Neo1973?
On Tue, 15 May 2007 18:16, Ian Stirling wrote: FIC is not a small company. http://www.fic.com.tw/about.htm Over 5000 employees isn't small. Smaller than Nokia/Sony, sure. But they are well over 20 times the size of Trolltech, who launched the greenphone. Ahh.. But who manufactured the hardware for the greenphone Trolltech?... Probably not. --Tim ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Durability of the Neo1973?
No problem.. It was more of a rhetorical(sp?) question anyway. I was just trying to point out that the situation was a bit different. --Tim On Tue, 15 May 2007 18:41, Robin Paulson wrote: ahh, damn gmail shitesorry tim from trolltech.com Q. Did Trolltech design the phone? Are there other models to choose from? A. Trolltech worked very closely with one of our Qtopia-licensed ODM partners in China, Yuhua Teltech, to make this first, open platform Greenphone a reality. Trolltech envisions a continuing collaboration with Yuhua for future models based on different hardware configurations. odm = original design manufacturer. so trolltech probably didn't make it regardless, both look awesome phones - i can't wait to get my hands on OM. a few weeks late won't put me off Smaller than Nokia/Sony, sure. But they are well over 20 times the size of Trolltech, who launched the greenphone. Ahh.. But who manufactured the hardware for the greenphone Trolltech?... Probably not. ___ 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: First impressions of Neo1973
On Tue, 15 May 2007 22:15, [EMAIL PROTECTED] wrote: On Tue, 15 May 2007, Tigran Zakoyan wrote: Jason Elwell wrote: I dont know whats more sad... You creating a paperdoll of an OpenMoko, or the fact that I downloaded it and made one for myself! LOL! Me too :) BTW, can't agree 1973 is too big. It just fits the size of my QTEKs110, which size's been really handy for me two years I use it. Not to mention the difference in functionality :) Me three. Next to my Sidekick, the Neo is petite. It's all relative. M Could you, or someone who just happens to have both, post a picture containing them side by side and edge on for comparison? I figured it would be about the same dimensionally (HxWxD) as the sidekick. Is it smaller? Thinner? Wider? Shorter? --Tim ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: OpenMoko light web server
On Tue, 17 Apr 2007 3:54, Alexander E Genaud wrote: Tim, I believe Microsoft created the non-standard XMLHttpRequest object through Active X around IE 5 but it has become something of a standard implemented by Firefox, Safari/Konquerer, Opera, and perhaps others. I've been using a nice wrapper, Sarissa, successfully for a few years in many environments. http://dev.abiss.gr/sarissa/ I believe the asynchronous flag is implemented in those major browsers. Alternatively, you can create an HttpConnection class with it's own timeout, abort, polling (4K), threading, etc. While the details are different across browsers, it seems that threads never context switches unless explicitly asked to do so (such as Timeouts and alert dialogs). In other words, a ring might come in, but if you are calculating the Fibonacci numbers to the umpteenth power, the ring thread probably won't alert you in good time. I believe that is true regardless of the async flag. Alex Alex, Hmm, that's interesting... It seems like a poor implementation if you can't guarantee that the event will fire asynchronously. Why offer it at all? Strange. --Tim ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: OpenMoko light web server
On Mon, 16 Apr 2007 13:58, Matthew S. Hamrick wrote: Okay.. a few points: snip Q. javascript? on a phone? Isn't that going to suck down the power? A. in a word, yes. But I think the main problem will not be the added overhead of using javascript, it's going to be the frequent request / response. In the old days when we bundled ORBs with browsers, we could execute java (and presumably have a javascript interface) that would receive asynchronous messages from the server. Why is this important? Because the phone (on the other side of the http interface) is going to ring or receive an sms message or the signal is going to go up or down. And these are things that occur outside the context of a client request. So, if you want to see if the phone just rang, you have to keep pinging the web server every second or so, and if it responds with I'm ringing, you fire off the javascript that draws the I'm ringing icon on the interface. All in all this is pretty substandard. Ok.. Well this is probably somewhat browser specific, but in the XMLHttpRequest methods there is a synchronous or asynchronous flag. Synchronously will behave in the normal request response method and wait for a return before continuing to execute... Async will allow the code to continue executing and then fire the response once it sees it. I don't know if there are timeouts or not and I have not played around with it much, but it seems like you could build several request objects... One might be dedicated to the ringing function.. Then place a timer on it and if there is no response by the timeout you could reset. All the request would do is ask if the phone rang and wait.. Then your cgi code could sit for the period of the timeout waiting for either a request (to cover the situation of the phone ringing between requests) or responding when the phone rings... This should be more like the subscription model where you ask to be notified and at any point it could happen. But, like I said, it may be browser specific. /shrug Just something to look into maybe. --Tim ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Blacklist/whitelists
On Fri, 6 Apr 2007 8:35, Andreas Kostyrka wrote: You cannot block them. But you can make the phone completly ignore it. OTOH, that's not the same thing because combined with a delivery report, somebody else can see when you turn your phone on :( Andreas Is it possible to turn delivery reports off? --Tim ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Blacklist/whitelists
On Fri, 6 Apr 2007 9:41, Martin Raißle wrote: Is it possible to turn delivery reports off? --Tim I think it's not .. at least not for the receiver of a message ... martin That seems weird... Even in email you can turn off read receipts... It seems like an invasion of sort (though a minor one) to not allow disabling of delivery reports for the receiving party. If the sending party can enable it and the receivers phone automatically responds, then you can always know when someones phone is turned on/available. Does the sms message system work while the phone is in call mode? Does that require multiplex code also like the gprs while on a call does? If it doesn't work while calling, you can always find out when someone is done talking on the phone / is available to talk (assuming they are at the phone) by sending an sms with delivery report first... Right? Seems like there should be some kind of control message that could be sent over the serial port via 'AT' commands which would enable and disable this. --Tim ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Blacklist/whitelists
On Fri, 6 Apr 2007 11:22, Jonathon Suggs wrote: Ok, I'll be honest that I have no proof that this is how it actually works, but I don't think it works the way you are saying it does. Again, not 100% positive, but the receipt that you receive is only a message that it has been successfully transfered to the carrier. The carrier will then try to push the SMS to the recipient whenever they become available. So there are two discreet actions. 1) Transfer from sender to carrier 2) Transfer from carrier to destination. Rather than get all worried about big brother, just do a simple test. Turn off a phone and send a text message to it. See if you get a receipt. If you do, then I'm right. If you don't get a receipt until the phone you sent a text message to is turned back on THEN commence the meetings of the tin foil hat club. -Jonathon Ahh. You obviously mis-understand my comments. Besides, what is the point of a delivery message to send to the carrier? It doesn't provide any value to the user over the message on the phone saying 'your message was sent'. That would be confirmation to me that the carrier got the message. In fact, on my sidekick 2, if the message could not be sent for some reason then I get a message saying it could not be sent, I.E. The carrier didn't get it. In either case, I always turn off any kind of receipt regardless of program. --Tim ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Blacklist/whitelists
On a related note to all of this sms talk... Can you send an sms with delivery receipt to a range of addresses and get back notification for all phone numbers which actually exist? (Obviously it will be one at a time, not boradcast) Or does it just return success once it changed network providers and it doesn't matter? Basically, could you use this to find out the network that owns a bunch of numbers or to find out which network a number belonged to in some way? --Tim ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Proposal: Personal Data Encryption (maybe SoC?)
On Thu, 22 Mar 2007 10:17, Joe Pfeiffer wrote: Thoughts? From what I remember of the discussions so far, that seems to meet the majority of requirements for encrypted file storage and also manages many of the things related to authentication that we have been discussing. Now, if we can specify the manner in which the password is entered (gesture, pin, etc.) then maybe its just this 'easy' ? Lol. Easy being relative because its already built. IMHO that would work pretty well. At least for what I am interested in. --Tim ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Proposal: Personal Data Encryption (maybe SoC?)
On Thu, 22 Mar 2007 12:13, Tim Newsom wrote: On Thu, 22 Mar 2007 10:17, Joe Pfeiffer wrote: Thoughts? From what I remember of the discussions so far, that seems to meet the majority of requirements for encrypted file storage and also manages many of the things related to authentication that we have been discussing. In a semi related note, how would we enable this ability for things like the contacts database? Or any other application database for that matter? Any ideas? --Tim ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Regarding encryption on openmoko...
On Wed, 21 Mar 2007 1:33, Gabriel Ambuehl wrote: I don't really see why one would want to use Truecrypt when there's been LUKS in the Linux kernel for years now... Well, for one I had never heard of LUKS till earlier yesterday. Now I will have to go check it out. (Grin) --Tim ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Proposal: Personal Data Encryption (maybe SoC?)
On Wed, 21 Mar 2007 9:34, Joe Pfeiffer wrote: Tobias Gruetzmacher writes: Right -- these look like good approaches, but to a different problem. /please excuse my direct manner.. Its just how I write (smile) What do you mean by different problem? Maybe I don't fully understand. The way I see it you have a few interoperating components... Dbus can be the primary transport mechanism, some reader plugin which abstracts the actual source of the data.. Be it the filesystem or a file which sits on the filesystem that has its own filesystem.. Or a dbfile system (I have not heard much about that recently)... A writer plugin which does pretty much the same thing, but for writing and not reading.. Maybe they are even the same plugin.. /shrug Then you have some authenticating system which allows various methods of authenticating a user.. Be it fingerprint reader or pincode or whatever based on the currently selected provider/plugin... And you have the application. At the lowest level is the encryption/decryption system.. Right above the filesystem somewhere. Now, when the phone is idle long enough or locked and a user tries to do something, the currently configured login / unlock / whatever you want to call it authentication plugin is activated and asks for the required information / gesture / whatever. Once obtained the user is granted whatever rights they configured for that action.. By default it can be nothing or a pincode and the default level can also be set to wide open, no encryption and full access. That's the state of almost every phone on the market right? Ok.. So an advanced users phone may have 3 or 4 levels of authentication and access / encryption.. Maybe even different algorithms are used. Who knows? When they log in they probably set it to the lowest level of access.. The notes application can read plain text with no problems and any unsecured data is visible.. Including contacts, notes, pictures, music, whatever. Now suppose this individual decides to read an encrypted file or runs an application configured to access an encrypted file or file system.. The authentication system would then ask for additional authentication and once granted handle the key pass to the decryption system / whatever to read the file. Now I don't have any experience with truecrypt or LUKS yet.. But they were mentioned along with encryptfs etc as a means of handling the encryption part. Maybe you can help me with where I missed out on the problem so that I can get my head around it? (Grin) I would love to make sure I fully understand what you are saying. --Tim ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Proposal: Personal Data Encryption (maybe SoC?)
On Wed, 21 Mar 2007 13:03, Joe Pfeiffer wrote: Hope my notes above are helpful... Hehe that's great. At least I am certain that you and I are on the same page now. I thought from my very quick glance at truecrypt that it could encrypt individual files also but I have not had a hard look and so no definite answer there from me. I know there are many many solutions to encryption and it would be nice to have a mechanism to install and use whatever the user wanted to setup and configure. Say gpg provider where you specify your keyring.. Or Encryptfs, truecrypt, LUKS, name your encryption method, whatever and handle the technical issues only once at install/config time maybe with recommended parameters based on the device and expected use or something. /shrug. Your ahead of me on looking at the code. --Tim ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Compressed SMS (and other text messages)
On Wed, 21 Mar 2007 14:35, Jonathon Suggs wrote: My challenge is just to think bigger. Think how this could be incorporated to work with *any* phone. Then you can have a much larger group of people to brainstorm, test, and bugfix. We have enough protocols and standards to support. Creating yet another one isn't really going to help that much. Also, I don't know anyone else that is planning on getting a OpenMoko device, so its pretty pointless for me at this point. I know you've got to start somewhere, but starting out a battle fighting uphill isn't the best of ideas. Sorry if I completely missed the point. So one approach might be to investigate the java implementation on other phones and see if you can gain access to sms for receiving and sending messages. Then you could write it to test the waters on openmoko.. Then build a java version for other phones that done have openmoko installed. /shrug Its an idea anyway.. But its only worth 1 cent since I didn't take the time to see if java can do that with any of the midp/whatever version that's common now. --Tim ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Proposal: Personal Data Encryption (maybe SoC?)
On Wed, 21 Mar 2007 14:35, Joe Pfeiffer wrote: But it has the encryption jail drawback. So maybe one way to deal with these issues is to build out the framework by constructing a new api for reading and writing data based on this provider concept.. Including the authentication. Then deal with and flesh out the issues we encounter along the way. At the same time or sometime later, another task can be started to hook into the os level read/write calls and make it work for every application the same. Maybe as some kind of layered filesystem driver or something, I don't know. Anyway, the point is that there are many many tasks to deal with related to the entire framework for this to work at all, right? And in the short run, all OM applications have a specific api anyway to make them work with the gui etc. The risk to security of doing it this way is minimal as using a program without the encryption hook just means that the program sees an encrypted file. Sure, it could damage the file if it wanted but for the most part the information will remain secure once encrypted with whatever mechanism. Later once the framework is up and some demo plugins are in place to show encryption providers and authentication providers and data readers/writers for various filesystem/database flavors, maybe we can deal with the issues related to 'all other applications'. That is, unless someone just happens to know off the top of their heads that its about x lines of code to do this by hooking into the os read/write routines with x being some number less than infinity?( ok, that was meant as a little joke) --Tim ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Proposal: Personal Data Encryption (maybe SoC?)
On Wed, 21 Mar 2007 14:59, Henryk Plötz wrote: Moin, Plus: If you really want per-file encryption that would only need some minimal modifications to the existing solutions. Or use unionfs. That's very interesting and opens up lots of potential. Your right, key management along with many other topics have not been discussed in any detail. --Tim ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Proposal: Personal Data Encryption (maybe SoC?)
On Tue, 20 Mar 2007 2:08, Jim McDonald wrote: Tim Newsom wrote: The best part is that if you don't want it, you don't use it. And those that do want it, can use it and its all completley transparent to the applications. But not at all transparent to the end user. Again assuming that there is some sort of key caching going on, what is the real consumer benefit to having multiple ways of categorising data to different levels of security versus having a simple protect my data against unauthorised access checkbox somewhere that blanket-enables encryption? (Alternatively there could be some way in which these configuration settings are pluggable and people with the more complex requirements could download the advanced settings plugin and leave normal users with a simple yes/no choice.) --Tim Cheers, Jim. I don't think you want security which is transparent to the user.. If the user does not know it exists then they won't know they are using it.. And then they might do something which causes problems later on. The user should have full knowledge of what they are doing. That doesn't mean it has to be difficult or have 200 commands at the prompt to set up. It can be easy and guided.. And possibly just an advanced menu somewhere which contains the necessary jump points into the security configs. Remember, most users (the average mom and dad) will not use the security features anyway. Some because they don't know how, some because they don't think of it and some because they just can't be bothered to set it up. Now, the ones that don't know how may at some point try to learn, so it needs to be able to help them through it. More advanced configs don't have to be set up by the average person either. Its the flexibility that is desired. Maybe it ships with password / gesture providers by default and someone can 'load new security providers' where it connects to a trusted source for signed openmoko security engin plugins (providers being easier to say). Once connected they could read descriptions of available providers, install them and during the install it asks some questions about how they want it initially configured. If they have not set up any security before, maybe it asks them the 'first time questions'... It can educate them on potential dangers without spreading FUD and open their eyes to the awesome potential that is the openmoko platform. Lets also not forget that openmoko is not just for phones.. But also other devices. This scheme could be used by anything... From a laptop with someones fingerprint reader and using a fingerprint security provider or some not thought of security mechanism to the next hand held multimedia player device (though why you would want security on it is your guess... Maybe security camera videos of a sensitive nature?).. Lets think universal and try to apply what we are creating to a larger set of devices. --Tim --Tim ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Proposal: Personal Data Encryption (maybe SoC?)
On Tue, 20 Mar 2007 8:12, Jim McDonald wrote: Tim Newsom wrote: [Encryption options] Yep I understand that there are lots of possibilities and options, I just think that if something ships by default it should provide end users with a very simple dialog that is basically an on/off switch for 'protection of personal data' (or something else that doesn't even mention encryption) and the additional levels of configuration can be made available through plugins or whatever. Perhaps I've spent too long battling with ugly interfaces, but I think that if OpenMoko is going to have a broader audience than the people on this list and their kindred-in-geekness then a large amount of the effort will be deciding how to keep the interface as simple and streamlined as possible rather than loading the default build with every option imaginable... --Tim Cheers, Jim. I completely agree. --Tim ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Regarding encryption on openmoko...
After reading about truecrypt on slashdot I think that could pose as a suitable start to the encryption solution... At least as a starting place to build a framework on and test out some ideas. --Tim ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Proposal: Personal Data Encryption (maybe SoC?)
On Mon, 19 Mar 2007 18:25, Jim McDonald wrote: Clare Johnstone wrote: On 3/20/07, Jim McDonald [EMAIL PROTECTED] wrote: continually asking the user to decide which data is to be encrypted and which not. There is the concept of folders which could be used :) clare True, but that's just another choice to be made when storing the data plus of course you have filesystem folders, arbitrary categorisation through tags, automatic classification depending on the type of data etc. so there are lots of concepts that can be used, and each one is a potential set of confusion (I tagged the data as 'sensitive' but the system didn't encrypt it because I accidentally put it in the 'public' folder). I just think that this is a good example where having an all-or-nothing approach is preferable to fine-grained control, as the benefits are minimal compared to the complexity for development and day-to-day effort for end-users that have to use such a system. Cheers, Jim. Ok.. Lets assume for a moment that there is an encryption / security engine.. And its hooked through dbus somehow.. Lets also assume there is a mechanism that handles all requests to save data from any application... Will just call it the save data mechanism.. (Grin)... So on the encryption / security engine it seems like there should be the ability to define user selectable levels of encryption / security.. Such as no encryption but password required.. Light encryption password required... Heavy encryption picture/gesture required (and maybe a certainty level for fuzzy matching like 90% /shrug).. or no password and no encryption.. Etc. Ok. There should be some kind of configuration for the save data mechanism which says select the published security levels (I.e. Those the user created in the security config) and then select which applications follow those rules.. So notes could be no security/no password or it could be 'ask me each time'... Calendar could be the same.. File browser could be heavy encryption with picture.. Etc.. Then each application does not need to know anything about the security levels at all. It just calls the save information api (whatever that is) and hands dbus the data to save. The save mechanism looks at the request and notes the application its coming from and then hands it off to the security engine to encrypt appropriately.. And then it hands it back at which point the save data mechanism can write it to the file system.. Reading is the same.. Except the read data mechanism looks at the application making the request and in the case of ask me data looks at the data to see if its encrypted/secured.. If so it tells the security mechanism which asks the user for the appropriate level of password information and then decrypts or authenticates the read action and the user gets to read the data. Combined with the sudo idea about a configurable amount of time for authorized idleness... And add to it the ability elevate permission levels.. So that once you have authorized to read highly sensitive information you can also just read password protected but not encrypted info.. And then I think it might meet everyones needs. By default no security is provided and none required.. Once configured it could handle almost any level of detail for encryption assuming someone wanted to go through the trouble of making it happen that way. And you could build new security mechanisms that plug into the architecture and allow for some people gesture authentication and for others hand writing codes or voice codes or numeric codes or anything. Um... Yeah.. Ok so that might be 10 cents worth. --Tim ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Proposal: Personal Data Encryption (maybe SoC?)
On Mon, 19 Mar 2007 22:09, Joe Pfeiffer wrote: I like this -- except it doesn't quite match my sample-of-one user study. My degree-of-security-wanted is by data, not by application. The same app is used for things like VINs and tire sizes and oil filters for cars (no security) and for student presentation grades. It's also not clear to me that more than two levels of security (open/password protected) are needed -- where password protected means encrypted using whatever scheme we've got. See that's where the 'ask me' setting comes in.. If an application can store encrypted vs not then its an 'ask me' then on a per data basis you can set it. The multi level security might not be necessary, but this scheme can handle it just in case. The best part is that if you don't want it, you don't use it. And those that do want it, can use it and its all completley transparent to the applications. --Tim ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Proposal: Personal Data Encryption (maybe SoC?)
On Sun, 18 Mar 2007 18:05, Henryk Plötz wrote: Moin, /snip Some feedback will be necessary so the user can see that the gesture was correctly detected before sending the PIN to the SIM. I propose some sort of bubblebabble-digest. -- Henryk Plötz Grüße aus Berlin ~ Help Microsoft fight software piracy: Give Linux to a friend today! ~ Can't you just draw the lines that correspond to the locations touched? A gesture can be 1 symbol drawn over the entire screen without picking up the pin/fingertip... Or it could be a 5 second drawing of kanji or some other symbol.. In addition, since it has to be fuzzy, the gesture needs to be ralative to the start position of the drawing and should give a configurable amount of time to enter the entire picture/gesture. Then someone could draw whatever they like in 5 seconds or 10 or whatever.. Or they could do something simple with their finger tip or they could actually write words on the screen, etc. Plus, if you are going to have a 3x3 grid, you might want to make that configurable also.. To add a lot of variability in the supposed gesture / key. Just a few thoughts... Flame away. /grin --Tim ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Fw: Re: Possible security hole for Dialers/troyan horses
Sorry, got caught in the reply to issue. -Original Message- From: Tim Newsom [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Possible security hole for Dialers/troyan horses Date: Mon, 5 Mar 2007 7:02:58 -0800 On Mon, 5 Mar 2007 0:05, Evgeny wrote: On Fri, 2007-03-02 at 07:35 -0800, Tim Newsom wrote: On Fri, 2 Mar 2007 6:09, Evgeny wrote: It still Linux based phone — there is absolutely no real-life viruses for Linux at this time, trojans are possible treat, but user have to install them by himself. That's a pretty strong statement.. Are you absolutely sure there are no viruses for linux in the wild? Nope. If you find one, let me know I'll get, compile $ run the beast a little (In virtual machine of course). Well if then you speak about trojans, the cure is DO NOT INSTALL THEM. Security holes may exist, but patching them is simple then you know about them, and in OpenMoko it will be automated by ipkg. Read trough http://tldp.org/HOWTO/Security-HOWTO/ it contains some basics of security in Linux. When we will speak the same language. There is no Norton Internet security, that can protect you from unknown treats. When you know about trojan or something, you simple don't use (it if you don't wont to). -- Sincerely Evgeny I realize nothing can protect you from every possible manner of attack, but I do know there are vulnerabilities that exist in linux. If not, SELinux would not have been necessary. If you say there are no viruses, I would say that's either because no one has written them or they are just not popular right now because windows is a much easier target to hit. My statement was that something like Norton Internet Security combined with the ability to run programs in isolated memory should provide a lot of protection. The isolated memory would prevent the infected programs from accessing the memory of other running programs (something that's possible on windows for sure) and the anti-malware program could do like someone previously suggested and check a hash of the program to see if it is a known and accepted version with allowed rights, etc. Maybe check the hash and a signature so show authenticity? While you can't detect unknown threats automatically (though I thought an anti-virus company said they could do that recently) you can block the unexpected behaviors automatically and recommed to the user certain actions. Remember, there are rootkits out there too. Maybe it would be nice to have a startup mode where the system goes into rootkit detection mode and scans the physical memory of the device and filesystem or something. Regardless, I think its better to have a pound of caution when a half pound would do... --Tim --Tim ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Possible security hole for Dialers/troyan horses
On Fri, 2 Mar 2007 6:09, Evgeny wrote: It still Linux based phone — there is absolutely no real-life viruses for Linux at this time, trojans are possible treat, but user have to install them by himself. That's a pretty strong statement.. Are you absolutely sure there are no viruses for linux in the wild? It would seem to me that the time to think about protection is before you have a problem. Granted, you will never catch everything up front. However, thinking about and dealing with the trojan, virus , issue is not too different from the steps we were taking to notify about unintended actions of programs. I.e. Getting a notification and deciding on how the action should be handled, etc. I think Norton Internet security does an excellent job on windows.. It knows about many, many applications and versions of them, can tell you if it was modified or contains known threats including trojans, lets you know when a program does something it was not explicitly allowed to do and does it pretty well without making my laptop crawl. Combined with a rootkit detection system of some kind it would be great, but I am sure there are still holes in it I don't see. Right? I would use it on my phone if it existed for that platform. --Tim ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Possible security hole for Dialers/troyan horses
On Thu, 1 Mar 2007 14:42, Tomasz Zielinski wrote: 2007/3/1, mathew davis [EMAIL PROTECTED]: then give it a rating of some sort 1 - being safe/trusted program and 10 - being known bad binary/ don't use at any cost unless you really want bad things to happen. Well, nobody will recognize difference between rating 2 and 3 or 6 and 7. I think set of three values is sufficient: 1 - allow network/GSM activity, 2 - ask every time app is trying to open connection/send SMS/make voice call, 3 - ban without asking. I wonder if OpenMoko system/library calls can be overriden or catch at layer which will be able to show dialog popup for setting 2. -- Tomek Z. [EMAIL PROTECTED] What about a mobile virus/trojan/malware protection system.. Say like norton antivirus or insert your favorite here designed to help identify and protect the user from known threats... Having that installed you could scan it when it was saved and alert on the threat, protect against unknown activity when it starts or while its been running and kill it/quarantine it if necessary. Combined with its own protected memory area so that it can't harm or investigate running programs it would seem to provide the best of all worlds.. Is something like that available? What do you think it would take to convert a currently available linux based program similar to the above to do this? --Tim ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: lets be nice
On Mon, 19 Feb 2007 21:35, ryan lerch wrote: hi all, just a friendly reminder that we are getting a lot of people subscribing to and posting to this community list that may not know all the mailing list etiquette that you do. So please be nice to these new-comers, and be patient with them; * if a topic is raised that has been discussed and resolved before - point them to the mailing list archives or where they can read about the answer. Even better, find a place to summarise and document the discussion on the wiki - a formatted wiki page is 100 times easier to read than digging through months of mailing list archives... :P * if they ask, what is in your eyes a stupid question remember that at one stage you knew little or nothing about the openmoko project: they are just interested in getting an opensource mobile device (just like the rest of us.. :P ) * i have also noticed that many newcomers obviously have not been members of online communities or online development communities before; if you come across one of these people, be nice and show them the ropes. Is it possible to have the 'welcome' email point them to those locations automatically? Then they could have the information right from the start.. Plus maybe some general guidelines for posting... Might be good also. Just a thought. --Tim ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Encrypting voice comunications..
So, though possibly inefficient, we could not some how take the analog audio stream, do some predictable and reversible encoding/encrypting then convert into sounds again.. Like doing base64 encoding for binary data.. In that way we are still sending audio information and letting it get encoded by the gsm module. Having access to send audio over gsm could be useful in another way.. Say call your phone and when it answers have it read its location to you via text to speech or something. We must have the ability to do something like that, or how would asterix (sp?) work on the phone? On Fri, 2 Feb 2007 9:29, Mikko J Rauhala wrote: On pe, 2007-02-02 at 09:06 -0800, Tim Newsom wrote: If we have access to the mic and speakers while a call is in process, and we have the ability to record conversations etc... Where does the processor sit in that chain? Can we consume the voice, encrypt it and feed an encrypted datastream back out to the gsm module which would transmit it and another neo1973 user could receive the stream, process through decryption and play out? No. The GSM processor does its own audio de- and encoding, and its connection to the audio i/o is analog, as reported by LaF0rge on irc a while back (any misunderstanding is probably mine if present, though). We can get at the audio via the a/d converters, but not do anything really fancy directly. Thus, I refer you to my last mail; make a GSM data call (phone-to-phone if possible, if not, both dial out and arrange the call via some server), transmit encrypted Speex stream. There would still be a bit of latency, but you would get reserved bandwidth at least. This of course costs extra. Probably one of the principal reasons why GSM chips don't like you sending your own digital data over voice calls. :] -- Mikko J Rauhala [EMAIL PROTECTED] University of Helsinki ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community --Tim ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Other uses for the gsm/gprs hardware....
While the phone is not on a call, can we use the gsm audio codec or other hardware/software to do useful work? For instance, decoding of some audio file or something like that. I know we don't have access to the bare metal of the chip, but its probably at least an arm processor with some dsp or something right? I would think it could be useful in some way other than just phone calls/data transfer. --Tim ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: idea for Neo 2nd generation: Accelerometer
On Thu, 25 Jan 2007 23:12, Jeff Andros wrote: as I understand it, you can get more value out of the accellerometer than that in the simplest case, we know a gps can be off by a certain percent. say you leave the phone still for a long time, you could average the error and get more precise over time (yeah, there'll be some skew... but we can trust the law of averages to help us out some) now, say you were aware of the motion of the device, you could still account for that motion in the averaging process (A-meter says I've gone 2 feet, gps says I've gone 3... pretty safe to say I'm between those) one of the real weaknesses of the accellerometer(INS) are long-term integration errors, and the biggest weakness of gps is short term precision... put the two together and they complement each other REALLY well. our (US) military has been using this combination for years with really great(horrible?) results... it'd be great to put this to a peaceful use as well -- Jeff O|||O We also need to take into account that accelerometers measure acceleration. If you accelerating or decelerating it will be able to tell you the magnitude of the force and you can time the duration to find the distance traveled. However, suppose that you are moving at a constant velocity, the accelerometer will measure 0 (zero) acceleration. Most true vehicle dead reckoning systems also include a sensor for the vehicle speed, which in combination with gps can provide you with something the accelerometer can't. The ability to know how far you have traveled at a constant or accelerating speed. Anyway, since attaching a sensor to the car may not be possible its a moot point. Just thought I would add a few more cents in. As a side note... In the US and probably other countries there is a standard for the interface to the car computer. From that interface you can get the vehicle speed and diagnostic information about how the engine is running. It might be interesting to have some kind of bluetooth car interface to obtain that information and display it for you while you are in your car. Anyone ever heard of anything like that? --Tim ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: Neo Carputer (was: idea for Neo 2nd generation: Accelerometer)
You're speaking of OBD or CAN. There are some good interfaces out there, though the auto companies try to protect their information. It would be neat to build a plotter/scanner interface for measuring the car sensors on the Neo using either bluetooth or serial/usb. Bluetooth OBD scanner: http://www.vitalengineering.co.uk/ Open-source OBD scanner python software: http://www.cs.unm.edu/~donour/cars/pyobd/ See my del.icio.us bookmarks (http://del.icio.us/nilspace/carputer) for more links (and others on del.icio.us) Andrew You got it. That's what I was thinking about. It would be sweet to have all that information sent to and plotted real time as the car is running. --Tim ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: idea for Neo 2nd generation: Accelerometer
On Fri, 26 Jan 2007 9:12, Steven Milburn wrote: yes, accelerometers measure acceleration. The first derivative of acceleration is velocity. Granted errors in the accelerometer compound when deriving velocity, but you've usually got GPS information to calibrate against (As Jeff was saying). A typical dead reckoning system always knows your current velocity, and when GPS goes away, it can apply changes to the velocity by knowing only your current acceleration. The errors associated with this would typically be small enough to not matter during the length of a tunnel or building related GPS blackout. So, an accelerometer (actually, three) is all that is needed for a complete navigation with dead reckoning. snip --Steve Ok Steve. I grant you that the first derivative of acceleration is velocity... How do you propose to gain any velocity information when the acceleration measured is zero as would be the case if you are at a constant velocity? This is why I am saying you would need some better source for velocity. I grant you that the times when a car is at a constant velocity may be few... Or it may be that when on cruise control on any flat road you may actually see zero or almost zero acceleration. OTOH, detecting the direction that a person turned with the accelerometer may be very useful in dead reckoning. --Tim --Tim ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: idea for Neo 2nd generation: Accelerometer
On Fri, 26 Jan 2007 11:18, Steven Milburn wrote: Wow, I can't believe I got that backwards, thanks for the correction. Kind of embarrassing considering I actually work on this stuff. However, it doesn't invalidate that you don't need any more information than the accelerometer and a starting point in order to track velocity and position. I'm going to go work on removing the foot I shoved so far into my mouth earlier. --Steve Ahh its been years since I did any of that in highschool, but I remembered it like you said it. Though now I think I should go back and review it. Lol. --Tim ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: idea for Neo 2nd generation: Accelerometer
For GeoPointing to work right, you would also need an electronic compass module in the phone Right? Cause accelerometers don't know which direction your pointing and gps isn't probably accurate enough to derive what you pointed at when you moved it maybe 2 or 3 feet during the gesture. With the compass module you would have Gps location + orientation + direction means what is that building? Then depending on the orientation you could have the phone limit distance.. Say face up is 100 feet. Face left is in 500 feet. Face down is 1 mile... Etc. Then have it return the name of the first known object that is on the ray extending from your location in that direction with in the defined distance. /shrug Now, pair the accelerometer w/ GPS and you have GeoPointing. What is that building over *there*? Sure people do that already (http://geovector.com/), but not on O/S platforms. ;) --Tim ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: idea for Neo 2nd generation: Accelerometer
Yeah.. I was using the accelerometer in my example to tell the program what the phone orientation was so that you could limit distance without having to touch the interface. If you had it set up to run from a free external button, you could push it And orient the phone and point and the phone could vibrate a little when it found the answer. Then you can look at the face to see what it was. On Wed, 24 Jan 2007 9:27, Gabriel Ambuehl wrote: On Wednesday 24 January 2007 17:04, Tim Newsom wrote: For GeoPointing to work right, you would also need an electronic compass module in the phone I think that's actually the only thing you really need for it to work. Not sure how an accelerometer would help figuring out what direction the phone has? ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community --Tim ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Fw: Re: built-in scripting languages
Bah, forgot to reply all. I think that's an excellent idea actually... A website where you can log into, set up preferences about the packages you have installed and build an image based on that. Is that ability already in existence? I mean, I am sure ipkg has the ability to update all of your currently installed packages, but it doesn't build an image for you to clean install on your system.. Right? Or am I out of touch again (it happens often I think lol). Or would anything be gained by clean installing a new image on your device? Is there anything which can't be upgraded or installed by ipkg? --Tim On Mon, 22 Jan 2007 22:59, Carlo E. Prelz wrote: I have a suggestion: a do-it-yourself main distribution packaging site from FIC, where you can choose selected alternative components, and receive as a result your own personalized 64MB. Then, naturally, I will have to see if it is acceptable for me not to use all those applications that require those scripting languages for which there is no space on my main memory. --Tim ___ 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)
There is going to be bluetooth on the phone. The range is small, but the possibility of a bluetooth to wifi adaptor might be interesting... Maybe something small enough to clip on a belt. Then connect to it through bluetooth and have it connect to wifi and redirect network traffic. I am sure its possible.. Has anyone ever heard of anything like that? Thanks, --Tim On Fri, 12 Jan 2007 9:15, Rob wrote: Hi... I just stumbled across this project yesterday while getting over my disappointment at the announcements that the iPhone would be a closed system - not a surprising announcement at all, but disappointing nonetheless. Anyhow, I'm pretty fired up about this project now that I've come across it. I've been hoping for a truly open phone for years, thanks for making it happen. It's a shame it won't have wifi, as that would make the device incredibly useful to me... It would be amazing to be able to make VoIP calls when a 802.11 is available, and data plans from celphone carriers in Canada are really expensive. There's wireless all over downtown Toronto now though, and it would be great to have a phone that could use it. The combination of gps and wireless would make it possible to do some pretty cool stuff with maps. I'm sure it's been said ad nauseam, but this would really be an amazing product with wifi. I'm just sayin', is all... Anyhow, even without wifi I'll probably be lining up to buy one of these things even if only to show that there is a market for an open phone - I'll hope there's wifi in v2. In the meantime, I was thinking about how I could get around the lack of wifi last night and something occurred to me... Would it be possible with this phone to set up a PPP dialup server on my machine at home, and get dialup access to the internet by calling my home number? This would be a lot cheaper than downloading via GPRS because Canadian wireless carriers are all apparently run by a bunch of jerks. Would any extra hardware (eg: a modem) have to be built into the phone in order to get PPP dialup access this way, or could it just be done through software? If hardware is needed, is it too late to consider adding it to the specs? There any other non-obvious options for Internet access with this phone that don't involve GPRS? I suppose IP over Avian Carriers would work... I apologize if this has come up on the list before, I didn't read every message. --Tim ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: FPGA
Bah! I meant to copy the list on that question. Thanks for the answer though. Maybe someone else can also help clarify? I thought fpga were basically PLDs and that they worked exactly the same. I didn't know they lose config without power and need to be reprogrammed. --Tim On Fri, 8 Dec 2006 5:51, Ole Tange wrote: As far as I understand it is like RAM: It looses state if it looses power. So it will have to read its config from some storage to start working. From http://en.wikipedia.org/wiki/CPLD: Non-volatile configuration memory. Unlike many FPGAs, an external configuration ROM isn't required, and the CPLD can function immediately on system start-up. /Ole On 12/7/06, Tim Newsom [EMAIL PROTECTED] wrote: Ok... So how many times can you reprogram it before it wears out? Like flash has a max number of times it can be written and eprom and eeproms did... What's that number for FPGAs? On Thu, 7 Dec 2006 15:40, Ole Tange wrote: You cannot use them simultaneously, but you can change set in 10 ms. /Ole ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/cgi-bin/mailman/listinfo/community --Tim ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
Re: Will the Neo1973 support Dual-SIM with SPST?
On Fri, 1 Dec 2006 7:59, Sean Moss-Pultz wrote: On 12/1/06 11:28 PM, Gabriel Ambuehl [EMAIL PROTECTED] wrote: Why not just copy the sim card into the phone? We use Linux, so we can do whatever we like I'm not sure, but doesn't the GSM module want to talk to the SIM card directly? The SIM card initialization details are handled by the closed system. The open processor (2410) can only talk over AT commands. -Sean That only means you can't do it without some modification of the motherboard and module. I was planning on building my own linux based phone from components before I found this project. Assembled from modules, it would not be hard, just the sofware side would take time... Right..? So I also thought about this multi-sim thing and I concluded that the protocal for talking to a sim is available.. Indeed, you can build something to copy the sim to your laptop if you wanted... So I thought of making a virtual sim software which would store and allow switching between multiple copies of sims... Then you wire the sim interface from the gsm module to gpio on the processor and write the necessary driver to make it look like a sim. The technical aspect isn't really that hard. Just time consuming. --Tim ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
Re: Light sensor
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? 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? 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. Seems like a fairly interesting concept. Do I understand the concepts or am I missing something? --Tim ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
Re: Another idea for an application for the Neo: Instant sync to web page duplicating info on phone
I love this idea and I would like to suggest a method of handeling a portions of it... Use web services... Web methods or whatever you call it. If you build an api for uploading sets of data they could be implelented in almost any lauguage and used natively like normal objects. Perl, php, python, java, c# can all do that and it means the backend does not have to be rewritten every time someone wants to use it in a language. Also, you could then provide a bundle of code for the server backend that handles the web service requests which anyone could run and point their own phone at their server. Authentication included. /shrug just an idea. --Tim ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
Re: Another idea for an application for the Neo: Instant sync to web page duplicating info on phone
Yeah. But more specifically I am defining the type of api as web services or web methods (they are the same thing usually). Basically, the web method is a standard used to define the remote method calls, their required parameters and types of acceptable data from within a program. Any program which can use web methods could use the same backend services. Its language neutral. Its also transport neutral. You can define encrypted channels to be used as the communication mechanism and regardless of which channel is used, the api does not get altered. Web services isolate the data transport mechanism from the application. I could draw up the architecture but its pretty simple. App -- calles web method from remote server and passes in data. The data gets stored.. The reverse is also true if you want a fetch process to occur. Web services also define types of activity as synchronus and asynchronus... Synchronus would be like a normal web request where you specify the url, sometimes with parameters and get a page back immediately. Asynchronus is more like subscribe/notify. You tell the service you want something and when its available or changed, based on the implementation, the response is sent back to you. Its all bi-directional since any request can send some kind of data and properly implemented, there is no reason you could not share data between multiple neo's using the same interface. I hope that's a little clearer... Maybe other with web services background can help me explain the concept and maybe correct me if I stated anything in error. --Tim ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
Re: Another idea for an application for the Neo: Instant sync to web page duplicating info on phone
Right.. For peer to peer or requests directly to the phone that's true. There is no reason we could not build a community shared server to be the intermedary between the phones however... Something that doesn't store the data longer than necessary for another phone to retreive the information. Then you could pass encryped information securely, even if the server itself was not secure by encrypting it in advance of sending it to the share. Obviously, accessable ip addresses on the phone would be preferred but might not be possible. --Tim ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
Re: Please think about incrementel sync Re: Another idea for an application for the Neo: Instant sync to web page duplicating info on phone
Web services are XML data transfer. The problem with xml is that it is
wordy for data (size) but good for parsing. What I mean by that is that its
not the most efficient way to transfer data ( ok thats obvious) but its a
defined format and easy to parse just about anywhere.. just slow.
If you are keeping a copy of the current versions locally then diffing and
sending only the diffs would be easy... but to my knowledge svn only keeps
the diffs between versions at the repository. Someone who knowns please
correct me. If I understand what you are saying and based on my
knowledge...
You either keep an old version for diffing purposes and replace it with the
current version when you do the commit. All changes happen to the original
not the old copy
OR
You would have to have the repository local and commit the changes locally
but that doesn't help with the storage part. The only way to sync up would
be through the dock.
My understanding of svn is that it transmits the entire file and the svn
server does the diff and only stores the differences between the files at
the repository. I could be wrong about that though.
If you don't keep a repository locally then one way or another you will have
to obtain a copy of the old version in order to just sync changes somehow..
Its an interesting thought.. does anyone know for sure if SVN sends back
only the changes and how it does that if it doesn't fetch the previous
version for comparison?
--Tim
btw.. I tend to over explain things so if I don't go far enough please ask
me (I am trying to cut back) ;-)
Also, feel free to correct me if I state something wrong.. I like to be
correct in my understanding and if I don't have all the necessary
information I would like to know what I am missing out on. ;-)
On 11/29/06, Jeff Andros [EMAIL PROTECTED] wrote:
snip
Without thougths like that you will have an incredible GPRS traffic =
costs.
ICS is really simple so
we could host that from the device as well. If Apache isn't small
enough,
even stripped down, there are several server apps that are optimised
for
this kind of environment
I don't do a lot of data on my phone at the moment mostly I use bluetooth
for this kind of thing, so I hadn't thought about costs... the other thing
we could try is an XML transfer of just the data, offloading the formatting
onto another server... the cool thing about this is we could run both
directly from the phone or from an intermediary depending on preferences and
the particular situation.
When you use an intermediary server, that will handle the heavy lifting on
building the page and you could have a nice ajax-y interface, direct from
the phone you could remotely store an XSL-T stylesheet to give you the
frontend. this minimizes the data that needs to go back and forth. sending
files back and forth I'd rather use something else, but in a pinch we could
use an svn client which does send only the file diffs back and forth, plus
storing the whole machine's drive on subversion gives us a nice backup in
case someone throws you into the pool with your phone in your pocket (it's
all fun and games until someone loses thier {email | phonebook | files |
blackmail photos of drunk friends}) you could also use this like so:
{user to phone} request update/commit cycle from phone to repository
{user on desktop} update local copy of phone filesystem
{user on desktop} make appropriate changes to files
{user on desktop} commit to repository
{user to phone} request update from repository
where you are not on your phone, and are making commands from a browser
Apache/whichever servers we're running handles the encryption, and now you
can get to the current version of your system through websvn from anywhere
--Jeff
___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
--
-- Tim
___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
Re: Please think about incrementel sync Re: Another idea for an application for the Neo: Instant sync to web page duplicating info on phone
So here is a document talking about some of the things we have mentioned...
From the link to nokia...
http://research.nokia.com/tr/NRC-TR-2006-005.pdf
Interesting, they have thought of quite a bit of this already.
--Tim.
On 11/29/06, Jeff Andros [EMAIL PROTECTED] wrote:
On 11/29/06, Tim Newsom [EMAIL PROTECTED] wrote:
Web services are XML data transfer. The problem with xml is that it is
wordy for data (size) but good for parsing. What I mean by that is that its
not the most efficient way to transfer data ( ok thats obvious) but its a
defined format and easy to parse just about anywhere.. just slow.
ah, but XML has a lot of good tools to offload the pretty portions onto
other servers... and we can pull a Google and use one-letter tag names to
cut down on space. to see what I mean check out here:
www.asu.edu/clubs/paddle http://www.asu.edu/clubs/paddle all the stuff
that makes the site pretty is in the xsl-t page... I'm pretty sure we can
cut down on the bloat by setting up our schema for minimum size
If you are keeping a copy of the current versions locally then diffing and
sending only the diffs would be easy... but to my knowledge svn only keeps
the diffs between versions at the repository. Someone who knowns please
correct me. If I understand what you are saying and based on my
knowledge...
You either keep an old version for diffing purposes and replace it with
the current version when you do the commit. All changes happen to the
original not the old copy
Now that you mention it, I'm not really that sure either... but I think
you're right.
snip
--Tim
btw.. I tend to over explain things so if I don't go far enough please
ask me (I am trying to cut back) ;-)
Also, feel free to correct me if I state something wrong.. I like to be
correct in my understanding and if I don't have all the necessary
information I would like to know what I am missing out on. ;-)
amen, brother, amen
On 11/29/06, Jeff Andros [EMAIL PROTECTED] wrote:
snip
Without thougths like that you will have an incredible GPRS traffic
=
costs.
ICS is really simple so
we could host that from the device as well. If Apache isn't small
enough,
even stripped down, there are several server apps that are
optimised for
this kind of environment
I don't do a lot of data on my phone at the moment mostly I use
bluetooth for this kind of thing, so I hadn't thought about costs... the
other thing we could try is an XML transfer of just the data, offloading the
formatting onto another server... the cool thing about this is we could run
both directly from the phone or from an intermediary depending on
preferences and the particular situation.
When you use an intermediary server, that will handle the heavy
lifting on building the page and you could have a nice ajax-y interface,
direct from the phone you could remotely store an XSL-T stylesheet to give
you the frontend. this minimizes the data that needs to go back and forth.
sending files back and forth I'd rather use something else, but in a pinch
we could use an svn client which does send only the file diffs back and
forth, plus storing the whole machine's drive on subversion gives us a nice
backup in case someone throws you into the pool with your phone in your
pocket (it's all fun and games until someone loses thier {email | phonebook
| files | blackmail photos of drunk friends}) you could also use this like
so:
{user to phone} request update/commit cycle from phone to repository
{user on desktop} update local copy of phone filesystem
{user on desktop} make appropriate changes to files
{user on desktop} commit to repository
{user to phone} request update from repository
where you are not on your phone, and are making commands from a
browser
Apache/whichever servers we're running handles the encryption, and now
you can get to the current version of your system through websvn from
anywhere
--Jeff
___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
--
-- Tim
___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
--
--Jeff
___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
--
-- Tim
___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
Re: X and Matchbox
Related to this, was my question about themes. I will have to check out the abilities of the gtk theme engine in regards to this, but I have an interest in porting the LCARS theme from the 770 or other themes to the phone. It would seem to me (and maybe I don't understand as well as I thought I did) that the ability to theme the interface could help usability studies / testing of new phone interface designs. The ability to design and quickly switch between different designs would be of importance in that situation. Note, when I talk about themes I am not talking about just changing the graphics but also the locations of various rendered buttons and interface elements in order to find optimal locations. I am not sure how far you could go with it, but if its easy to do then you know people will jump on it. --Tim ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
