re: spam
On Sun, 25 Jan 2009, arne anka wrote: > the best course of action, is to delete an forget it, the subject is a > pretty good hint ... And perhaps for openmoko to start publishing SPF records Paul ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Version 2 -- New community distribution hackable1
On Wed, 17 Dec 2008, Marcus Bauer wrote: > * GPS works out of the box > It comes as a tarball, thus you need a 2 GB SD card (SanDisk work well) Is the GPS+SD card problem solved yet? Paul ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: maps for others country?
On Sat, 9 Aug 2008, Tick Chen wrote: > Yes, Locations will automatically download maps from Open Street Maps. > IF the backend found that it can access to the network. > > Therefore, you can create your own personal map, (even package for > sharing). > > How? > 1. Let Neo connect to the Internet. > 2. Turn on Locations, > 3. Zoom in to the location you are interested and drag around. > 4. login to Neo > 5. follows the instruction of > http://wiki.openmoko.org/wiki/Om2008.8_Locations#Create_Offline_Maps > > Last time I and some colleagues went to KenTin http://www.ktnp.gov.tw/ > for holidays, we just create a map before departure, it's very > interesting. Is there a way to preload map packages from openstreemaps based on coordinates? So that we can create city or country maps, without actually being there ? :) Paul ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: $106 in Brokerage!!?!!?!
On Tue, 15 Jul 2008, Matt Manjos wrote: > NEVER again am I shipping with UPS, if I can avoid it. I've found > their brokerage fees are almost always applied and they're always > ridiculous. We had no choice. It was the only shipping option into Canada, and Koolu seemed way sketchier with their google apps nonsense, false 'on stock' messages, etc Paul ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
slightly off topic: Rogers Canada slashes data plan pricing
http://www.theglobeandmail.com/servlet/story/RTGAM.20080709.wgtiphone0709/BNStory/Technology/home?cid=al_gam_mostemail Customers who purchase an iPhone and sign up for a three-year contract any time between July 11 â when the device goes on sale â and the end of August will be eligible for a $30-per-month data plan giving them access to 6-Gigabytes of data. Rogers previously had charged $100 for a 6-GB plan. Though mostly meant for the iphone, they say: The special plan is available not just to iPhone customers, but any Rogers customer with a 3G next-generation smart phone. Though Rogers claims to have "listened to customer feedback", the article also quotes: One blog posting on AppleInsider.com, a popular Apple rumour site, stated that Apple would divert some iPhone shipments that had been earmarked for Rogers to Europe for punishment over the negative publicity, leaving some Rogers outlets with as few as 10 iPhones to sell. Time to get a USB 3G dongle that works on laptop and openmoko. Though getting the 3G subscription might allow you the same rates on the 2G network perhaps? Paul ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: OpenMoko is the only 100% F/OSS-based Linux smartphone project
> > At LinuxTag 2008 I learned that Motorola is giving you the kernel > sources but are using signed kernels and the bootloader to prevent you > from putting your own kernel on the device. I expect that phones > provided by LIMO and OHA will have the same 'feature'. Unfortunately its > the linux kernel's GPLv2 which has no clause against such misuse. Even GPLv3 won't help you against motorola's dead man's switch. I tried to convince RMS, but he was just too far gone in his own world to understand why GPLv3 was not good enough, and could not ever, protect against this. Motorola phones have two parts, like openmoko. A baseband CPU, which is restriced and handles all GSM protocol, and the OS CPU, which is what you can tinker with all you want. Between the two CPU's is a virtual serial line. Now imagine the OS being linux with no restrictions, fully GPLv3 compatible. Now imagine one propretary binary running on that GPLv3 platform, which sends a signature based on the OS/kernel contents to the baseband via serial. If it is not a known good signature, the baseband CPU cuts power to the GPLv3 CPU after 60 seconds. No where here is there a license violation of GPLv3, you are not restricted from modifying and using code, but in practise you have been prevented to do so - in compliance with GPLv3 - since it is the baseband CPU that takes the decision, and not any GPL code. This is exactly what Motorola does. It is the "60 seconds" of working phone with "openezx". > So even if soon Linux-based smartphones from LIMO and OHA will appear > soon. All with great hardware, fancy graphics and whatnot they managed > to rip all the fun and freedom out of it. :| I wonder what Nokia will do once they own all of their OS. They promised to open it up, I wonder about the restrictions. I'm glad I purchased an openmoko though. I'm tired of fighting against mobile phone vendors. Paul ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Shipping to canada...
> For a single phone the fees are $50. However if you chose the more > expense shipping method from openmoko, $50 extra, you don't pay the > fees. > > http://www.ups.com/content/ca/en/shipping/cost/zones/customs_clearance.html > > So in the end its the same amount of money, but you get your phone much > faster. > > There will be GST, but I don't know what duties their may be. There will also be a "handling fee" because UPS gets away with it. UPS is the worst method for shipping things into Canada. Paul ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Let us impact the material world
On Fri, 27 Jun 2008, Nelson Castillo wrote: > I think encrypted messages are crucial for freedom. I also think most > people don't know how easy it is for others to see what they send > through the networks. I cannot wait to see those Encrypted messages > traveling free through _their_ networks to deliver _our_ messages. That means: - Phase out SMS in favour of IM (SMS char limit makes crypto hard, cheaper too) - Use OTR with IM (http://otr.cypherpunks.ca) I am not sure at the current state of IM clients, but there are python bindings for OTR at http://pyotr.pentabarf.de/ I will go at it as soon as I can order my Freerunner in Canada Paul ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: handwriting recognition?
On Tue, 17 Jun 2008, ramsesoriginal wrote: > As far as i know, there's already a handwriting rekognition on the openmoko.. Can we use it to unlock the phone instead of using a pincode? :) Paul ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Yummy new CPU/GPU combo
On Tue, 3 Jun 2008, flexd wrote: > > the day nvidia comes with open drivers for this... we can begin to take an > > interest :) > > > > To be honest, (i myself do not really care if the drivers are open or > not, i do not have the require level of geekyness to change them :p) i > couldnt care less if the drivers are open or not. > > Aslong as we/someone could run a opensource OS on it, such as OM, i'd > love it! You get the phone. It crashes. You report the bug. Opensource developers tell you "it's the nvidia driver, we cannot do anything". Then what? Thank you openmoko for your stance on using ONLY opensource drivers for open hardware specs. > I want the ability to change everything, but having a different cpu/gpu > driver isnt exactly a high priority. Ofcourse this would be great, but a > closed driver will do fine if my phone can have specs as good as that! It won't. Vendor lock will lead to closed phones. If I wanted that, I would already own an iphone. Paul ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Possible App - Security
On Wed, 18 Jul 2007, COMINT wrote: > I'm interested in putting together an encryption app to allow secure > voice calls over the GSM data call facility. You need IP layer encryption, not application based enpcryption. So ipsec, openvpn, l2tpd, OTR, GPG. I'd recommend using IPsec with a ppp connection if you want to do GSM data calls - unless you want to do a "cryptophone" style DiffieHellman. I am not sure if the latter one is patented. Paul ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: IM application and other questions
On Fri, 6 Jul 2007, Nick Johnson wrote: > Is anyone more familiar with OpenMoko and the Neo able to give a quick > overview of what's involved? Am I right in assuming that all that's > required is a UI and an understanding of the AT commands to send and > receive SMS messages? > > If so, I may have a go at this myself if nobody else gets in first. :) Integration of "SMS buddies" with "IM buddies" would be nice :) I would really like to see 1 application for messaging, not multiple. I've seen this too many times where phones have seperate menus depending on the transport and the type of message. (The Parawireless HIPI for one is awful in that respect) Paul ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: IM application and other questions
On Thu, 5 Jul 2007, Jeff Andros wrote: > > > 1. Is the IM application SMS based or data plan based? > > > > What were you planning to code? > > Semi-serious. There isn't one. > > > > Do we have any pidgin devs on here? how heavy is libpurple, it would be > really sweet to build a mobile version (what kind of bird is smaller than a > finch? sparrow?) I'm the packager for gaim-otr/pidgin-otr. I do hope that pidgin can be build for the Openmoko. I haven't looked at the required effort though. Paul ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: How many women on OpenMoko?
On Thu, 5 Jul 2007, london cowgirl wrote: > It's important that OpenMoko is designed with both sexes in mind (especially > since women love to talk to so much). Are you trying to fight a prejudice by using a prejudice (even if meant jokingly)? The "women in technology" debate is about the extra effort women have to put in, and extra shit they have to endure, to be seen as equal to male developers. It is not about the Readers Digests prejudice of "women talk more on the phone" or the "different design of a GUI based on gender". Paul > So a quick show of hands - how many women do we have following the OpenMoko > project? > > Carla > > > > > > > No need to miss a message. Get email on-the-go > with Yahoo! Mail for Mobile. Get started. > http://mobile.yahoo.com/mail -- Building and integrating Virtual Private Networks with Openswan: http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155 ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Location Privacy Protocols, was Re: GPS trail - crazy idea
On Wed, 4 Jul 2007, Werner Almesberger wrote: > Trails of multiple users, shared in real time, would be the > "killer application". I don't think anyone is doing that at the > moment. A typical scenario would be to meet someone in a city > both don't know. Street names aren't very useful, but knowing > roughly where the other person is at the moment, would be. Actually, some good research is being done at the University of Waterloo, Canada. A paper was presented at the Privacy Enhancing Technologies conference in Ottawa a few weeks ago: Louis, Lester and Pierre: Three Protocols for Location Privacy Ge Zhong, Ian Goldberg, Urs Hengartner (University of Waterloo) See: http://petworkshop.org/2007/papers/PET2007_preproc_Louis_Lester.pdf Especially, an implementation of the Pierre protocol would be interesting. In essence, using the protocol, two people can reveal each others location but only when they are close to each other. In other words, if you are not close to each other, the other person does not obtain your location information. Additionally, you can lie about your location if you just do not want to be found right now, without revealing to the other person that you are lying. This would be a very cool IM plugin for Openmoko, and a good use of the GPS in Openmoko without losing your privacy. The authors have even implemented this protocol in an open source library, though AFAIK, it has not yet been released (but is available upon request) > Directing a taxi to the other person's location should be fun, > though ;-) Though you joke about this, the abuse for revealing your location is going to be a huge problem. Another interesting paper tracked the dyndns.org records of thousands of individuals and they managed to track and locate the identity of some, and followed others across a north-american trip on a day to day basis: Identity Trail: Covert Surveillance Using DNS Saikat Guha and Paul Francis (Cornell University) http://petworkshop.org/2007/papers/PET2007_preproc_Identity_trail.pdf Which brings up an interesting point of how to deal with DNS requests on Openmoko phones. How do we prevent revealing our location while at the same time informing our friends of it. This is especially important when considering ENUM. Paul ___ 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, Steven Milburn wrote: > First, if one concedes that the typical sensor can be easily fooled, I still > think fingerprint sensors tend to add security to most phones. That's > because I think most users cannot be bothered to hide data behind a decent > pass phrase they would have to type on a tiny keyboard. Joe Average is much > more likely to adopt a concept that works something like: Swipe one of your > eight fingers (up, down, left, or right) (thumbs can be dexterally > difficult) and you are authenticates and one of 32 pre-selected actions > happens (call a speed dial, open email, open calendar, etc). It doesnt add more security compared to a "scribbled login pattern". And it doesnt require a fingerprint reader. Paul ___ 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, Knight Walker wrote: > I vote no on this one, primarily due to not being able to access this > information without nearby people hearing (Or possibly recording) the > pass phrase (Think about trains, planes, buses, business meetings, etc). > A user-defined symbol drawn on the screen or a password/PIN tapped into > the screen would be ideal, preferably with a user-defined timeout period > (1-minute, 5-minutes, until-phone-goes-to-sleep, etc). Excellent idea. Let's ditch the passphrase/pin though, because once we copy the data off phone to another device, brute forcing anything you can type comfortable using a pin or keyboard will be trivial. I really like the "custom drawn symbol" idea. It introduces a lot of variables. Not only the lines, but also the timestamps on when scribbling it. Paul ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: 'My Account' - a way to store information about the phones owner, so they can be reunited if it's lost.
On Thu, 1 Mar 2007, Ian Stirling wrote: > Reflashing never gets you back a different account number, it keys off the > IMEI, which is not flashable. (well, perhaps it is, but it's not flashable > from the linux side, and AIUI, nobody else knows how at the moment.) I really hope the IMEI number is not available to every application or even the kernel itself. Perhaps only when booting the phone with some special setting in which case it refuses to use the GSM network, so people cannot be coerced into enabling this identifying mark. We already went through this with the pentium serial number. Paul ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: 'My Account' - a way to store information about the phones owner, so they can be reunited if it's lost.
On Thu, 1 Mar 2007, Ian Stirling wrote: > http://wiki.openmoko.org/wiki/My_Account is an overview of some ideas. > > Briefly, a way for anyone with the phone to access a history of the phone > (bought/sold status, reported as stolen, ...), a way for the user to set these > as well as contact information for people to return the phone in some way. > > Thoughts? Phone is lost. Someone finds it. If they are honest, they will call the last number and say "i just found this, you know who this phone belongs to?". If they are dishonest, they remove SIM and keep using the phone, perhaps reflashing it. The phone is up for sale, either by owner or by thief. Someone buys it. If they are honest, they notice phone is stolen. I doubt many people would return the phone to its owner after having just paid for it. If less honest, they don't care. The only way you could possible do something is to enforce it. Eg ensure people cannot use the phone without your permission. Per definition, any opensource friendly phone cannot have such a feature. You can make it difficult, but not impossible. A block might work while the neo is a niche market phone - not when it becomes a giant success. I would use a combination of "making it hard" and "phoning home" regularly with the SIM number and GPS coordinates, perhaps include address entries or camera photos or what not. The idea is to try and leave a trace before the thief/new owner can disable the feature. I would however use a preset of target SMS, target email, or target website address within the phone. I see no advantage to a centrallly run repository. (and I do see disadvantages of such privacy stores. Paul ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Itch3: Anti-lost/theft protection
On Wed, 28 Feb 2007, Wolfgang S. Rupprecht wrote: > Personally I like the idea of periodic SMS messages with the > lat/lon/altitude. When in stolen mode, having the phone receive SMS > msgs containing commands for the phone would seem to be very useful. The first thing that happens to a stolen phone is that the SIM is chucked. You won't be able to *send* SMS messages, since you will not know the phone number. Unless you make sure it SENDS you its new phone number as well. > Something as simple as having a way of remotely submitting a short > shell script would do the trick. Stuffing something useful in 160 chars is hard. It's better to design things beforehand, so you can just send simple commands with arguments. I wonder if you can send SMSes on the Neo without the user noticing anything, or wether things like the backlight will be turned on (by the closed off chip hardware). Paul ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: openswan klips and nat-t patches for openmoko added
On Wed, 14 Feb 2007, Richi Plana wrote: > On Wed, 2007-02-14 at 17:44 +0100, Paul Wouters wrote: > > I built the 2.6.17.7 kernel using all the patches from quilt. Worked > > like a charm. > > When you say "Worked like a charm", did you just mean that it compiled Actually, I meant it patched fine :) Of course, we did find a bug in the nat-t patch today that in fact broke nat-t when using NETKEY. The fix is confirmed and comitted to cvs and will be in openswan-2.4.8 which I'll release tomorrow. So whoever is gathering patches for openmoko, wait until the 2.4.8 nat-t patch is on the ftp server tomorrow. > cleanly? Or that you tested the compiled kernel (either on an emulator > or similar hardware ... or, dare I hope, the actual Neo1973!)? It took me a few hours today to get a working environment going, and openmoko has been compiling for a few hours now and is still running. So no compile test yet. And no, I have no physical hardware yet to test :P Besides, this is just the kernel part. We also need to package up openswan userland for the openmoko. But it will take me a while to get used to the openmoko build system. I am new to SVN, openembedded, monotome and bitbake, since for openswan we actually use git for the new trees, and cvs for the 2.4 tree. Paul ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: Voice over GPRS?
On Sat, 3 Feb 2007, Ian Stirling wrote: > Even a really anemic processor can manage AES or whatever at 8Kbit/sec, in > realtime. > However, as a near-zero CPU option, you could always use one-time-pads from > the SD. > Key management is substantially more annoying - you need 3M or so of pad per > person per hour, and you can't reuse it. > However, as long as nobody copies the pad, or compromises the phone, it's > perfectly secure, even from advances in decryption. > Overwrite the flash several times as the pad is read, and then take out and > crunch the SD between your teeth if you need to destroy it. The pad can be stolen from both ends, and you'd have no perfect forward secrecy. Using a onetime pad directly is inheritantly dangerous. You are better of using the one-time pad to authenticate a diffie-hellman key exchange, and then use session keys which are never stored to flash, written to disk, and can be safely intercepted. And that's all provided your onetime pad is truly random, which it won't be, and that people won't accidentally use the same page twice. Paul ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: Voice over GPRS?
On Fri, 2 Feb 2007, Mikko Rauhala wrote: > > > Of course, you can make a GSM data call (I presume) and thus reserve > > > > That's what www.cryptophone.de does to avoid latency issues. Some networks > > block mobile to mobile data calls though. > > Righto, so somebody's doing it already on free software. Good for us > all :) cryptophone's phone cost 1500 euro. It's not free software. The source has been published for peer review, but you're not allowed to use it on your own phone. > I was referring to simply that the carrier will likely charge extra for > data calls (in comparison to voice calls). Though now that I check the > figures, they _have_ come down at least here since last I checked. Which > was a while ago. Well, most offer a $100/month or so flatrate. It's expensive, but if all your calls are going through a cheap SIP provider and your asterisk to your GPRS connection, your *voice* calls would go down to $0/month. Then, $100 for unlimited voice calls isnt that expensive. Paul ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: Crytped calls through 9600Baud GSM-data connections?
On Fri, 2 Feb 2007, Robert Michel wrote: > Did you discussed OTP, using less mobile device batterypower to add > to the voicestream to build an encrypted connection between on users > mobil and his homeserver? Nope. In general, devices these days have enough cpu power to just do AES. CPU isn't the limiting factor, latency and/or bandwith are. (for voice encryption at least) > I thought about that maybe GSM-data connections with 9600Baud would > be interesting: > -would piping through such a connection possible without TCP or other > overhead? If you do a gsm dat call, you can of course run your own protocol like cryptophone does. But I want to try using just a standard ppp/ipsec connection. Again, I think devices are fast enough and latency is more of a problem then bandwidth, so this approach seems much easier to implement then a custom serial/crypto protocol. > This GSM data connection is used by every commercial cryptophone > and avoid the delays of GPRS... Yes, that is what cryptophone is using. > PS: I made advertisement on this list for your presentation in Berlin, > and that this video is no online - but good that mention that it > is online again - it worth for the most here on the list to see it. I moved some files and removed the ASF file in favour of the mp4 file, since the ASF file caused a lot of problems for people to get to play. Paul ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: Encrypting voice comunications..
On Fri, 2 Feb 2007, Mikko J Rauhala wrote: > No. The GSM processor does its own audio de- and encoding, and its And echo cancellation. When using any VOIP app, you will need to put in your own echo cancelation code. I listened to the Windows Mobile 5 Skype client, and even that was pretty awfull. You'll need to use a headset. Paul ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: Voice over GPRS?
On Fri, 2 Feb 2007, Andreas Kostyrka wrote: > > AFAIK, only T-Mobile did that, and they removed that clause a few months > > ago. > > Eplus does have that clause too. Ahh, not too familiar with the German markets. > Plus running standard VoIP protocols like SIP and friends over a NAT > firewall that is not cooperating is not possible anyway. So you would > need to add a tunnel to some endpoint on the Internet, and add that > latency to the bad latency of GPRS/UMTS :( that's why our firmware will include both IPsec (with NAT-Traversal) as well as OpenVPN. If that wouldn't work often enough, we'll try and do encapsulation over port 443. But yes, guaranteed in-order delivery of telco networks is really not a very nice basis to run UDP (or TCP) over. Guess the telco world still believes in the OSI model :( Paul ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: Voice over GPRS?
On Fri, 2 Feb 2007, Mikko J Rauhala wrote: > Of course, you can make a GSM data call (I presume) and thus reserve That's what www.cryptophone.de does to avoid latency issues. Some networks block mobile to mobile data calls though. > (Also, _this_ is how you can accomplish a proper encrypted phone call > using the GSM network with Neo, if you're into security and don't mind > it costing a bit. It doesnt need to cost a bit. In fact, this is why I am on this list and why I'll be getting a Neo phone. We presented at CCC: http://events.ccc.de/congress/2006/Fahrplan/events/1495.en.html The video is available at: http://chameleon.cypherpunks.ca/ In essence, a phone using Openswan, Xl2tpd, openvpn, pjsua, Jabberclient talking to an server running Openswan, Xl2tpd, openvpn, asterisk, jabber server. We hope to have Neo firmware available before you can order the hardware :) For more details, see our presentation. Paul ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: Voice over GPRS?
On Fri, 2 Feb 2007, Terrence Barr - Evangelist, Java Mobile & Embedded wrote: > Also, most data plans specifically prohibit VoIP usage > and may even prevent it technically. AFAIK, only T-Mobile did that, and they removed that clause a few months ago. Paul ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: Voice over GPRS?
On Fri, 2 Feb 2007, Robert Michel wrote: > Does anybody has experiances/ideas about Voice over GPRS? See: http://www.cl.cam.ac.uk/~rc277/globe02.pdf They discuss tcp as well as udp performance over GPRS. > How long is the delay? It could maybe used for asyncron > voice communication Talk2Talk (instead of pushing a button) > By using 1KB/s for audio and some overhead, let > us say 2 KB/s 0.24Euro/MB = 24 Cent for 500 seconds, > 60 seconds makes then about 3 cents. When both using > this 6 cents. Hmm that would be interesting when > the user makes often make brakes/pause in their talk. Using speex, you'd need 1.6kb upstream. So bandwidth is not the issue. Latency is. The uplink will have between 0-1 sec of latency, so it's not really an issue . Downlink however, commonly has 2 or 3 second latency, ruining voice in an "interactive" way. In other words, you are probably forced to use a "push to talk" style conversation, meaning long monologues. And that is in good conditions, with a non-mobile connection. Things will get much worse when travelling, especially in the city with many small cells, as you'll be stuck hopping from cell to cell without actually getting much communication done. Paul ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: Possibilities for commercial software?
On Fri, 26 Jan 2007, David Schlesinger wrote: > I still don't see how trying to limit people's choices is "more free" than > letting them make their own choices. You are leaving out one important issue here. The "free" market is in fact already forcing non-free decisions on you. You can try to avoid all of those forced decisions, but like you said, you wouldn't be able to live a normal life. Look at how apple used BSD code to trap users into not running their own software on the apple hardware. Is it their freedom to enforce that upon us? Or has freedom been taken away from us? Look at Fairplay/itunes, and realise that Fairplay is proprietary code, which is probably using a lot of BSD code in there. Is that the "freedom" we wanted to give when writing BSD code? I guess it is, which is why I am a GPL person, despite the fact that I do own an OSX laptop. So to answer your question, are you "more free" due to BSD code in apple products, or "less free"? I believe you are less free. Paul ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: Possibilities for commercial software?
On Fri, 26 Jan 2007, Simon wrote: > > GPLv3? > > The GPLv3 does nothing to stop people from using DRM to protect > proprietary software. Yeah, but try writing DRM sofware without the GNU software, which includes glibc for your proprietary software (which realisticly, would be linked against a GPLv3 glibc in the future). And it is not the DRM on video playing on an openmoko phone that people would want to prevent. It is the "flash this firmware on the phone or else the custom app won't run", where you can only decide on an "all or nothing" approach that I think we would want to prevent. As an example, having a commercial (protected) skype client on the phone would be good. Having the skype client disallow sip software, either by licence or by software enforcement, would be wrong (and violate GPLv3) But on the other hand, imagine someone wanting to use openmoko to build a "super secure phone". One of its functions would be to not allow untrusted other binaries to run on its "secure firmware" image. Would this violate GPLv3? Probably not, since the user "agrees" to be put under a DRM voluntarily. But what if the (stupid) user wants to add one application to the secure firmware, defeating the whole security of that firmware load? Suddenly the user no longer consents to the DRM, and thus makes the "secure firmware" a GPLv3 violation Paul ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: Possibilities for commercial software?
On Fri, 26 Jan 2007, Harald Welte wrote: > So I sincerely doubt that OpenMoko would ever actively support > proprietary applications (e.g. by DRM hooks). We certainly cannot do > anything against them, though. GPLv3? Paul ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
